最近 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 根据历史验收数据自动调整子任务的粒度——这个做出来，再单独写一篇实操记录给大家看。