最近 Nous 这边的动作不少Hermes 更新之后圈子里讨论得最热闹的一个点不是模型本身的跑分又涨了多少而是子 Agent 被赋予了“查看、纠偏、停止”这三个权限。听起来好像就是把主从协作的控制权又分了一部分出去但真正落到实际项目里你会发现整套工作流的验收方式都得跟着改。这篇就专门聊聊我在实测和接入自己项目之后对这套机制的理解以及更关键的——面对一个能自己看过程、自己改方向、自己叫停的子 Agent你到底该怎么验收它的结果才不会被表面的“跑通了”糊弄过去。先交代一下背景这轮 Hermes 的更新面向的是 Agent 编排层也就是说它不再只是单纯地提升单模型指令跟随的能力而是把多智能体协作里的控制逻辑往前推了一步。以前我们习惯的主 Agent 派活、子 Agent 干活、最后交结果本质上还是一个“下发-回收”的异步模式中间过程基本是个黑盒。而这次改动之后子 Agent 的工作过程里主 Agent 可以在中途插入“查看状态、纠正方向、强制停止”三个动作等于把协作从离线变成了半在线。这个变化带来的直接后果就是你验收的不再只是最终产物而是整个执行过程中的每一个决策节点。下面我把这套机制的来龙去脉、验收思路和实操流程拆开讲。1. 从“结果导向”到“过程可控”Hermes 这次更新到底改了什么1.1 以前的主从 Agent 协作是典型的黑盒派活制先回顾一下旧模式。在 Cursor、各类 Agent 框架或者自建的多 Agent 系统里主 Agent 派给子 Agent 的任务通常是一段 prompt 加一个目标描述子 Agent 跑完把结果交回来主 Agent 再判断是否满足要求。这个过程里主 Agent 根本看不到子 Agent 中间做了什么——它调了哪些工具、读了哪些文件、在哪个分支上浪费了十几轮推理全都不可见。这在任务简单的时候问题不大。比如让子 Agent 总结一份文档、抽取几个字段结果对了就结束。但一旦任务变成“帮我排查这个项目的性能瓶颈”或者“把这段业务逻辑重构掉”黑盒派活制的毛病就全出来了子 Agent 可能跑偏了十分钟你才发现甚至它交回来的结果是一个“看起来正确但其实答非所问”的东西你要么自己重新读一遍过程要么直接推翻重来。1.2 “查看、纠偏、停止”三个动作的实际含义这次 Hermes 更新里三个权限其实是逐级递进的。查看是第一步它让主 Agent或者说调用方能够实时读取子 Agent 的执行状态当前在哪个环节、最近一次工具调用是什么、上下文里已经积攒了哪些中间结论。我以前做 Agent 系统排查问题最痛苦的就是子 Agent 卡在一个死循环里它自己意识不到我也看不到。有了查看权限至少能在它跑偏之前发现端倪。纠偏则更进一步不只是被动观察而是中途向子 Agent 注入新的指令或修正信号。比如它正在往一个错误方向分析数据主 Agent 可以直接插入一条“注意你刚才忽略了日志里的超时错误请调整方向”。这比等它跑完再返工高效得多。停止是最后一道保险既包括正常完成后的收敛也包括异常情况下的强制中止。这个能力的重要性在于不是所有子 Agent 的偏航都能被纠回来一旦发现它在一个原则性错误上反复打转最经济的做法就是停掉重来而不是继续烧资源。这三者放在一起才构成一个完整的监督闭环看得见、管得住、停得下。1.3 为什么说这改变了验收的底层逻辑过程可控带来的最大变化是验收的“标的物”变了。以前你验收的只有结果现在你可以、也应该验收过程本身。比如某个子 Agent 最终产出看起来没问题但它的执行路径里出现了三次方向性纠正——这说明最初的任务拆解是粗糙的下一次你应该在派活环节就把信息给足而不是依赖纠偏来补漏。这就像带人做事。以前你只能看下属交上来的报告现在你能看到他整个思考过程、草稿、中间版本。那你的评价标准就不能只是“报告是否合格”还应该包括“他的工作方法是否合理”“他在哪里浪费了时间”“他接受纠偏的效率高不高”。把这套逻辑迁移到 Agent 系统里就是这次的验收新课题。2. 子 Agent 的“查看、纠偏、停止”背后是怎样一套协作机制2.1 主 Agent 与子 Agent 的分工逻辑要理解这套机制怎么用先得把主从之间怎么分工搞清楚。从 Hermes 这次的实现来看主 Agent 的角色更接近一个“现场管理者”它负责高层目标拆解、资源分配和节点检查。子 Agent 则是“执行者”承担具体的搜索、代码编写、文档处理等工作。分工的关键是控制频率。如果主 Agent 事无巨细地去查看子 Agent 的每一步那这套系统等于退化成单 Agent 的逐个步骤执行多 Agent 的并行优势就没了。我个人的经验是主 Agent 的查看点应该设置在高风险切换处比如子 Agent 要修改核心文件之前、要调用外部 API 之前、要做出一个不可逆操作之前。至于那些低风险的中间计算过程没必要实时监控。2.2 查看权限到底能看多细很多朋友问这个“查看”能看到代码级的过程吗能。只要子 Agent 的执行上下文和工具调用链被完整透传主 Agent 就能看到它每一步在读什么、写什么、调用什么。这意味着你完全可以把子 Agent 的完整轨迹导出来作为验收时的审计依据。不过要提醒一点查看不等于记录所有原始 token那样成本太高。比较实用的做法是把查看权限和摘要机制结合起来子 Agent 主动维护一个执行日志记录每个阶段的输入、产出和决策原因主 Agent 按需拉取摘要而不是每步都同步全量信息否则多 Agent 协作会变成一场上下文灾难。2.3 纠偏与停止的指令链是怎么设计的纠偏和停止的机制我建议你理解成一个带优先级的指令通道。常规任务指令走队列而纠偏指令要能打断当前执行直接注入到子 Agent 的上下文最前面。这就是为什么单纯把纠偏消息拼到子 Agent 的 prompt 尾部效果很差——子 Agent 正在处理一个复杂的推理链末尾突然多出来的一句话很容易被它忽略。停止指令则涉及资源的真正回收。从一个子 Agent 被叫停到它的计算实例真正释放中间往往还有一个“善后窗口”让它把当前步骤写成检查点。这个设计很重要因为许多项目支持断点恢复被停止的任务之后还能从检查点续跑而不是永远从头开始。2.4 这套机制在 Cursor 等工作流里的对应形态提到 Cursor 里怎么用主 Agent 和子 Agent其实本质也是这套逻辑主 Agent 负责理解你的大体意图并拆解任务子 Agent 去执行具体的文件修改、代码生成。你的每一次“继续”“不对这里应该改成……”“先停一下”就是在行使查看、纠偏、停止三个权力。只不过在 Hermes 这类更底层的框架里这些动作被做成了可编程的接口你可以在自己的工作流里更精确地控制干预时机和干预粒度。3. 怎样验收结果从“跑通”到“达标”的四个层级3.1 第一层行为轨迹可审计我之前验收 Agent 任务第一件事是看最终输出现在第一件事变成了看轨迹。轨迹不是日志流水账而是子 Agent 执行路径的完整证据链它读了哪些文件、依赖了哪些信息、为什么在某一步做出当前选择、纠偏指令是什么时候注入的、注入后它做了什么调整。验收行为轨迹的方法不复杂核心是看“关键决策点是否有依据”。比如子 Agent 做了一个技术选型决策轨迹里得能看到它比较了至少两到三个备选方案而不是一拍脑袋。如果一个执行过程从头到尾一次纠偏都没发生而且产出质量很高这说明任务拆解成功如果全程纠偏了七八次才磕磕绊绊出来一个结果那就算结果合格过程本身也是不及格的。3.2 第二层纠偏后的产物是否做到闭环纠偏要验收的不只是“子 Agent 听不听话”而是它改完之后有没有把相关的地方一起改掉。这是我最常遇到的场景主 Agent 让子 Agent 把某个函数的返回类型从字符串改成对象子 Agent 确实改了函数体但调用这个函数的地方、对应的类型定义、测试用例全都漏了。从形式上看它“响应了纠偏”实际上只是打了一个补丁。验收纠偏闭环的实操方法是回归测试加依赖扫描。光看子 Agent 改了什么文件没用要看它改的这个点连带触发了哪些下游依赖这些依赖是否也被同步修正。如果框架支持最好在纠偏指令里就带上“请一并更新所有相关引用”的约束并且在验收阶段专门检查这一点。3.3 第三层停止机制是否真的有效停止权限的验收恰恰要故意设计一些“必须停止”的场景来测试。有个反直觉的坑很多系统的停止指令只是给模型发一个“请停止”的语义信号模型确实说自己停了但它背后还挂着等待中的工具调用或者还有已经发出去的 HTTP 请求没有回收。从业务角度看这叫“假停”。真停的判断标准很简单停止后检查子 Agent 有没有再发起新的工具调用、有没有继续消耗计算资源、上下文有没有被进一步写入。别只看它生成文本的结束符那玩意儿太好骗了。3.4 第四层从单次验收上升到质量基准线单次任务验收完就完了吗不够。我建议你把这套验收维度固化成一套打分卡每次子 Agent 完成任务后从正确性、完整性、路径效率、纠偏成本、停止及时性这五个维度打分。跑上二三十个任务之后你就有了一份属于自己项目的数据基线。这比任何“这个模型感觉挺聪明”的主观评价都靠谱。验收维度具体看什么常见扣分点正确性最终结果是否满足任务目标输出好看但关键逻辑错误完整性涉及的下游依赖是否同步更新只改了表面漏了引用路径效率是否在合理步数内完成绕远路、反复试错纠偏成本纠偏次数和纠偏后可执行度多次纠偏仍原地打转停止及时性停止后是否残留计算文本已停但工具调用未回收4. 实操中的一整套验收流程与验收清单4.1 验收之前先把“结果标准”定义清楚这个看起来是废话但真正做到的团队很少。拿“帮我优化这个模块的性能”来说什么叫优化成功是接口 P95 延迟降低 200 毫秒还是内存占用减少 100MB还是代码可读性提升标准不清晰后面对子 Agent 的纠偏也会失去依据你都不知道该往哪个方向导。所以动手验收前第一步是把任务目标翻译成可观测的指标。我给自己的硬性要求是目标至少要包含一个数值或者一个判定条件。没有数值的目标子 Agent 完成得好坏完全是玄学。这也是我在实际项目里和同事最容易产生分歧的点——他们常常凭感觉判断“优化得不错”我只认压测报告。4.2 分阶段的验收节奏不要等到子 Agent 全部跑完再做终验那种做法等于放弃了一半新能力。我的习惯是这样的阶段一启动后 10% 进度处做一次方向验证。这时候子 Agent 应该已经完成信息收集和方案雏形此时最值得检查的是大方向对不对。如果方向错了立刻纠偏成本最低。阶段二进度 50%-60% 处做一次中间产物验收。这时候一般已经产出了核心代码或核心输出重点看内容质量而不是继续看方向。在这个节点发现问题往往还能通过调整子任务来补救。阶段三全部完成后做完整的终验。这个阶段重点回归第一节说的四个层级轨迹、闭环、停止、基准线。4.3 时间陷阱纠偏越晚成本越高多 Agent 系统里有一个成本曲线很容易被低估任务执行时间越靠后的纠偏带来的返工成本是指数增长的因为后面的步骤往往建立在前面的结论之上。一个关于数据字段的纠偏如果发生在最后的报表生成阶段可能意味着前面所有统计分析都得重跑。因此验收节奏里最关键的其实是“早于子 Agent 的承诺时间进行干预”。子 Agent 会估算自己的完成时间但你别真等到它说完成了再去验。在时间进度过半时主动查看一次比等它自然结束再检查纠偏成本低得多。这个经验来自我连续几次被“看起来快完成了”坑过的经历。4.4 验收清单速查给你一份可以直接抄的清单我每次验收都过一遍关键决策点是否有轨迹依据还是凭空一拍脑袋纠偏注入后关联文件是否同步更新有没有只改表层停止指令后进程与工具调用是否全部回收有没有后台残留同一类任务连续跑三次结果稳定程度如何方差大不大纠偏响应时间从注入指令到执行变化通常不超过 2-3 步推理有没有在纠偏后保留当前检查点支持断点恢复5. 踩坑记录几个容易被忽略的“验收死角”5.1 子 Agent 太“听话”不一定是好事第一次用上纠偏能力时我发现一个有意思的现象有些子 Agent 纠偏之后过度服从。主 Agent 说“这里可能有问题你看看”它立刻推翻自己之前的整个分析哪怕原先的分析大部分是对的。这种“你说什么就是什么”的 Agent表面响应率 100%实际上丢了判断力。验收时要注意区分“响应纠偏”和“理解纠偏”。前者是机械地按新指令重做后者是理解纠偏背后的意图把改动精确限定在必要范围内。判断方法是在纠偏后再问它一句“刚才的纠偏里有哪些信息你认为是需要保留的”看它能不能给出有分辨力的回答。5.2 纠偏消息的“皮下注射”还有一个隐蔽的坑纠偏指令一次性塞太多子 Agent 只会执行最后一条。这有点像人类听多了指令会丢掉前面的重点模型也一样。我实测下来单次纠偏最多给三个要点超过三个后面基本就是无效信息。更合理的做法是给纠偏指令分层。第一层说明“为什么要纠偏”第二层才给具体调整方向。子 Agent 理解了原因调整起来才会自然只给“改成这样”的命令式纠偏结果往往生硬且伴随副作用。另外我强调一遍纠偏消息的注入位置必须是上下文的最前面放在末尾的效果会大打折扣。这不是玄学是注意力机制的特性长上下文场景里末尾指令经常被稀释掉。5.3 停止不等于失败它本身也是验收项很多人在验收时把“发生停止”当成负面信号其实不对。高质量的调度系统里停止是一个完全正常的控制动作。子 Agent 在执行中发现自己进入了低价值路径主动触发停止并请求更高质量的输入这恰恰说明它具备了“知道自己在做无用功”的元认知能力。我踩过的坑是为了不让任务中断强行让子 Agent 在一个错误方向上硬撑到最后结果产出一个从根上就错的答案验收时返工成本反而更高。现在我的原则是只要发现错误方向已经不可逆立刻停止宁可重新拆任务——停止反而是节省整体成本的动作。5.4 验收数据要单独留存最后一条经验凡是做到了“过程可查”的子 Agent 运行执行轨迹、纠偏记录、停止日志都应该单独留存不要塞在你的项目日志里。因为这些数据本身就是优化 Agent 配置的素材。留存一段时间后你可以回头分析哪些任务最容易偏航纠偏集中在哪个环节停止的发生有没有规律我就是靠这种历史数据把自家主 Agent 的任务拆解模板迭代了好几版子 Agent 的偏航率肉眼可见地降了下来。这套玩法如果不用那“查看、纠偏、停止”这三个新能力其实只发挥了一半价值。现在用我自己的项目做结尾我目前跑 Hermes 这套机制已经把它固定成了一套半自动的工作流主 Agent 负责拆任务、设检查点子 Agent 跑执行我只看检查点上的轨迹摘要和验收打分卡而不是盯着每一步输出。这样人虽然退出了高频操作但对整体质量的把控反而比以前更稳了。下一步我打算把打分卡的结果反馈回任务的派发模板里让主 Agent 根据历史验收数据自动调整子任务的粒度——这个做出来再单独写一篇实操记录给大家看。