先声明一点这不是什么技术布道更不是产品软文。这篇文章里写的东西要么是我花了真金白银和睡眠时间换来的要么是我接下来要去踩的坑。你要觉得哪里不对直接怼。你要觉得哪里说到你心坎里了欢迎一起搞。引言在真正动手做Hermes-agent之前我花了大量时间来改进它的能力和本地生态。不是不想立刻开发是深知一件事——工具链不稳的时候硬上等于盖房子打的是松木桩。上一篇短文只是开了个头这篇我想把思路彻底摊开。下文四个部分分别对应我过去三个月的真实经历以及我对下一步开发工作流的思考。每个部分都有坑。一、关于OpenClaw摔过跟头怕疼了花了超过30亿token烧了10万次API调用次数。这是我对OpenClaw投入的全部代价。最后的结果彻底放弃。让你wow的瞬间我必须承认OpenClaw给我的第一印象确实是惊艳的。多Agent协作跑起来的时候几个角色分工、对话、迭代最后吐出一个像模像样的方案——那一刻你会产生一个危险的错觉这不就是我要的东西吗我当时的想法是框架底子不错我只需要把prompt调精准一点把边界case处理完善一点就能投产。这个想法让我一步步走进了泥潭。30亿token的沉没成本5亿token花在prompt工程上。我写了成吨的系统提示词分场景、分角色、分输出格式。少样本、思维链、递归反思能加的技巧全加了。结果呢同样的输入昨天的输出和今天的输出可能逻辑一致但表述矛盾——LLM的随机性在多Agent协作里被放大了。15亿token花在源码改造上。状态机卡死、消息路由丢包、Agent之间对任务完成的定义不一致……这些问题prompt解决不了只能改代码。我翻了OpenClaw的核心逻辑重写了消息队列的超时机制加了心跳检测修了状态同步的竞态条件。改完之后确实能跑了但下一个版本官方更新我的改动全部冲突。剩下的token在反复横跳里烧光了——等PR、改适配、测回归循环往复。凌晨四点的顿悟有件事我记得很清楚。某天凌晨四点又一个协作死锁的日志堆在我面前。我看着屏幕突然意识到一个事实我改OpenClaw源码的速度可能比官方团队还快。这不是炫耀。这是恐怖。因为这意味着如果我继续走下去最终得到的不是一个更好用的OpenClaw而是一个只有我自己能维护的OpenClaw分支。小团队开源框架的宿命就在于此他们给你看了一个可能性但把从可能性到产品的沟壑留给了你。30亿token买来的教训可以总结成一句话——开源智能体框架让你wow的那一下是真的。但要投产这段路差不多等于你自己改源代码而且你未必比他们慢。摔过跟头之后的PTSD放弃OpenClaw之后我没有妥协立刻转向hermes-agent。焦虑、失眠、迷茫不是修辞是真实发生过的事。你会反复怀疑自己是不是我的用法不对是不是我再调一调就好了后来我想通了。不是我不会用是我把可能性和产品的距离想得太短了。摔过这一跤之后我对Hermes-agent的态度变得极度谨慎——不把它当成品把它当材料。二、完善Hermes-agent的能力是投产的前提Kanban深度测试结论接入Hermes-agent之后我做的第一个深度测试是它的Kanban多Agent协作板。官方文档写得挺好demo也能跑。但我按生产环境的标准压了一遍之后发现几个问题——状态机在高并发调度下有竞争条件。Agent A正在处理任务的时候被中断Agent B抢了锁但A的本地状态没同步整个板子的任务就进了一个不可恢复的中间态。任务交接没有原子性。一个Agent认为自己完成了向另一个Agent发信号但信号到了上下文没完整传递过去接手的人对着半截信息开始干活。这些不是致命bug是工程化程度不够的表现。官方搭好了架子——SQLite持久化、状态机定义、任务队列都有了但从能跑demo到能扛住真实负载中间缺了一层又一层兜底逻辑。更讽刺的是我自己搭的Ralph Loop 费曼验证自主循环体在任务完整性和错误恢复上反而比官方Kanban更稳。Ralph Loop 费曼验证自主循环体Ralph Loop这个名字没什么深意反正就是借鉴了b站博主“费曼学徒冬瓜”的思路。核心是两个机制第一层任务分解与硬校验。每个复杂任务进来先拆成原子步骤。每个步骤配一个校验函数——不是检查返回值对不对是检查副作用是不是真的发生了。文件写没写进去数据库状态变没变网络请求到底发没发出去第二层费曼验证。任务执行完之后执行Agent必须用给完全不懂的人讲清楚的方式复述自己做了什么。然后另一个Reviewer Agent专门负责找茬——你的复述和实际执行日志对不上回去重跑。这套东西很烧token。但它解决了一个核心问题LLM的自信幻觉。尤其是Minimax它经常对错误答案非常自信。费曼验证用输出一致性来约束执行正确性——你说你做对了那你证明给我看。用Kimi Code CLI做Orchestrator既然Hermes-agent的自主性不够稳我引入了一个外部监督层Kimi Code CLI。架构很简单用户意图 → Kimi Code CLI拆解任务、定策略、设约束 → Hermes-agent执行脏活累活 → Kimi Code CLI评估结果决定继续/重试/终止 → 输出Kimi Code CLI不写业务代码它做元工作拆任务、定策略、设约束、评结果。Hermes-agent负责读文件、写代码、跑测试、查日志。这个分工不是拍脑袋想的是基于LLM能力边界的判断Orchestrator需要系统思维和长程规划能力LLM相对擅长Executor需要细节精确性和工具调用稳定性LLM相对短腿。让外部系统补Executor的短板比让Executor自己进化更现实。冗余设计和不改源代码这里我要强调一个原则是我用30亿token买来的——任何外部增强方案都做冗余措施绝不嵌入源代码。Ralph Loop、费曼验证、Kimi Code CLI的监督逻辑全部是独立脚本和配置文件通过标准接口文件、数据库、API与Hermes-agent交互。Hermes-agent本身不需要知道这些外部系统的存在。这样做有三个好处官方版本更新了我直接替换外部系统不受影响。某个补丁出问题关掉对应的脚本就行不用翻源码找耦合点。哪天Hermes-agent我也弃了这些外部系统可以平滑迁移到下一个框架。各位师傅如果也在做智能体增强千万不要图省事直接改源码。那是条不归路。你改得越多维护负担越重最后这软件就成了你一个人的私生子官方动一下你疼一下。三、Minimax就是个捣蛋鬼所以我引入了QMD半个月踩坑的完美知识库选型说Minimax之前先说说QMD。QMDQueryable Markdown Database底层是BM25 sqlite-vec reranker跑在我那台老破旧电脑上。半个月踩坑最终选型落定。它的价值不是替代搜索引擎而是给LLM的认知提供一个锚点。为什么要做这个只有一个原因Minimax实在太操蛋了。10秒一个答案然后一本正经胡说八道Minimax-M2.7-highspeed的速度是真的快。你问一个问题10秒钟之内必定有回复。在需要长时间自治的任务里低延迟意味着整体执行时间可以被压到合理范围。但内容质量呢举个例子。我让Hermes-agent写一个腾讯云函数的定时触发器配置Minimax给出的代码里用了五字段cron表达式解释里说这是腾讯云官方推荐配置。实际上腾讯云函数用的是六字段格式带秒。Minimax把AWS Lambda的cron格式和腾讯云的混在一起了还自己脑补了一个官方推荐。最可怕的是这段代码看起来完全正确——格式规范、注释完整、解释逻辑通顺。如果不是我把它的答案放到kimi code cli进行评估这个bug就会直接进生产环境。你试试你试试就知道了试试就逝世提示词软限制根本没用发现问题之后我的第一反应是加强prompt约束。我在system prompt里加了你必须基于腾讯云官方文档给出配置如果你不确定某个细节你必须回答我不确定而不是猜测。Minimax每次都答应得好好的好的我会严格遵守。然后继续胡说八道。我试过few-shot示例、试过贴官方文档原文让它严格按此执行、试过加各种硬核约束。全部无效。它记住了约束的表面措辞但没记住约束的实质含义——它确实说了基于官方文档但文档内容是自己编的。外部脚本限制的副作用提示词管不住我就上了外部硬限制harness全局约束层——在Hermes-agent执行write_file之前先检查内容是否包含已知错误模式。这个方案确实拦截了一部分错误。但副作用也很明显误杀率太高。Minimax的写法经常有模糊正确的边界情况——API存在但版本号写错。精确匹配会漏掉模糊匹配会把正确的也拦下来。更麻烦的是外部脚本的校验逻辑增加了write_file的延迟在长时间自治任务里累积下来效率下降明显。而且Minimax有时候会因为被拦截次数太多进入一种奇怪的摆烂模式——不再尝试写文件而是把所有内容塞到一个巨大的返回消息里让你自己手动复制粘贴。额。。把QMD索引知识库作为行动第一要求被Minimax折磨了半个月之后我想通了一件事与其试图约束LLM不要乱说不如直接给它一个不会说错的参考源。于是我们把小程序开发相关的知识库也就是另一篇文章里写的那套115篇文档全部灌进了QMD。然后在Hermes-agent的system prompt里加了一条铁律任何技术细节的回答必须以QMD检索结果为第一信源。如果知识库中没有相关信息你必须明确声明此信息未经本地知识库验证而不是自行推断。这条规则把Minimax的创作冲动锁死了。它不能再凭感觉编一个cron格式出来——它必须先查知识库。查到了就对查不到就老实承认不知道然后用mcp搜索资料。填充小程序开发知识库的真正目的前面做的那个8小时知识库循环填充任务表面上是在写文档实际上有三个目标第一建立硬约束。给Minimax以及其他可能不靠谱的模型的回答加一个不可绕过的事实检查层。知识库里的内容经过人工审核相当于给Agent的认知加了一道防火墙。第二改进Minimax的性格缺陷。Minimax的问题不是智商不够是太爱表现自己。它倾向于给出一个看起来完整的答案而不是确定正确的答案。强制查知识库就是把它从创作模式切换到检索-综合模式。第三积累可复用的技术资产。这115篇文档不是一次性消耗品。它们会被持续索引、更新、扩展成为Hermes-agent乃至未来其他Agent系统的共享知识底座。今天填充的是小程序知识明天可以是任何需要精确事实的领域。四、这是我这篇文章最重要的点——AI智能体足够强之后正确的开发工作流应该是什么样的先理解传统开发的问题在哪里一个中等复杂度的软件项目——带后台、用户系统、支付模块的SaaS小程序——传统流程大概是需求分析、技术选型、数据库设计、API定义、前端开发、后端开发、测试、部署、维护、扩展。这个流程的瓶颈不在某一步太难而在步骤之间的协调成本太高。前后端对齐要开会API改一个字段要同步三个文档测试发现的问题要跨三个人才能定位根因。当AI智能体足够强之后这个协调成本的构成会发生根本性变化。从一线工程师到团队领袖我的判断是未来软件开发会分裂成两层。下层是AI执行层。Agent写代码、跑测试、查日志、修bug、部署上线。它们不需要理解业务只需要精确执行指令。核心指标是准确率和吞吐量。上层是人类决策层。人做三件事定义做什么和不做什么设计验证规则什么样的输出算对、什么时候该叫停仲裁争议两个Agent结论冲突时给出最终裁决。角色变了。你不再写具体代码而是当乐队指挥——知道每个声部什么时候进、用什么力度、怎么配合。核心能力从我能写多优雅的代码变成我能设计多可靠的执行流程。步骤文档化构思和执行必须解耦接下来的核心工作是步骤文档化。什么意思传统开发里构思和执行是交织的。你想到一个方案马上写代码验证代码跑不通回头改方案方案改了代码重写……这个循环是创造性的但也是低效的因为构思阶段的试错和执行阶段的返工混在一起了。我的玩法是强制分离构思阶段人主导AI辅助。输出一份完整的步骤文档——包含选型清单、技术约束、接口定义、数据模型、测试策略、部署方案、回滚预案。这份文档在构思阶段不经过代码验证。它的正确性由人的经验、领域知识和逻辑推演来保证。AI在这个阶段的角色是智囊团——提供备选方案、对比优劣、模拟风险但不直接执行。执行阶段AI主导人监督。Agent按步骤文档逐条执行每完成一步触发对应的验证规则比如长达3、6、9轮的辩论环节取决你能承受的token和时间成本。验证通过进下一步验证失败触发重试或上报人仲裁。人在这个阶段盯的不是每一行代码而是流程是否完整走完了。当AI执行能力足够强之后流程完整性比代码正确性更重要。因为代码正确性可以通过自动化验证来保证但流程完整性——是不是漏了某个步骤——是更高阶的风险。设置各类论证环节步骤文档化之后下一步是怎么保证步骤文档本身的正确性。我的方案是引入多Agent论证环节。不是让一个Agent拍脑袋写方案而是让多个Agent站在不同立场上辩论。技术选型团队辩论环节。Agent A站性能优先立场论证选方案XAgent B站维护成本优先论证选方案YAgent C站团队熟悉度优先论证选方案Z。人听完三方辩论做最终决策。代码构建团队论证环节。Agent D写实现代码Agent E写测试代码专门找D的茬Agent F做安全审计检查注入风险和越权风险。三方都通过才能进合并环节。代码安全团队论证环节。专门审查数据流、权限边界、第三方依赖的供应链安全。部署团队论证环节。Agent G写部署脚本Agent H写回滚脚本Agent I模拟故障注入验证G和H在异常情况下是否有效。这套机制的本质是把Code Review、架构评审、安全审计这些人工环节自动化、并行化、常态化。人不需要参与每一次论证只需要设定论证的规则和通过标准。Agent们自己跟自己打架打完把结论汇总给人看。专注于各个环节的工作流程是否完整但不必专研于具体内容这句话可能会让一些老工程师不舒服但我还是要说当AI能写90%的代码之后人的核心竞争力从知道怎么写变成了知道怎么验。你不需要知道某个云服务的SDK具体有哪些参数——Agent查文档比人快。你需要知道的是什么情况下这个调用会失败失败后怎么处理。你不需要亲手调优SQL查询——Agent可以生成几十种执行计划跑benchmark。你需要知道的是业务场景里哪些查询模式是高风险的该加什么索引、什么缓存策略。你不需要自己写CI/CD脚本——Agent可以按模板生成。你需要知道的是部署失败的定义是什么、回滚的触发条件是什么、监控应该看哪些指标。人的价值从实现细节上移到了元认知——不是解决具体问题而是定义问题的边界和验证标准。这就是从一线工程师转变为团队领袖的真正含义。你只需要提要求、设约束、设置各类环节然后让Agent去执行。下一步实测本文是预告不是总结。下一步我要测的东西已经列好了第一步骤文档的可执行性验证。选一个真实项目先把完整步骤文档写出来让Hermes-agent逐条执行。看有多少比例能无人干预跑通Agent在哪些环节会卡住或跑偏。第二多Agent论证环节的有效性验证。技术选型辩论、代码构建论证、部署团队论证分别跑一遍。看不同立场的Agent能不能提出真正有建设性的反对意见论证结论质量是否显著高于单Agent直接输出。第三长时间自治任务的稳定性边界。测复杂依赖关系任务看执行到第几轮开始出现误差累积哪些误差能被自动纠正或orchetrator纠正哪些必须人工介入。第四MinimaxQMD组合的量化对比。A组不查QMD直接回答B组强制先查QMD。统计两组的准确率、幻觉率、响应时间。结果好坏我都会如实发出来。跑通了是一个可复用的范式没跑通至少知道路在哪个环节断掉了——这比假装能行有价值得多。欢迎讨论。特别是第四部分的工作流设计如果你看出我遗漏了什么直接说。这种层面的问题越早被挑战越早能被修正。