最近有一条判断，我觉得特别值得单独写下来：

对 agent 来说，委派的最大价值，往往不是“更快”，而是“让主会话保持清醒”。

这条判断来自一个很朴素的观察。很多 agent 一开始都像“工兵”——自己读日志、自己改代码、自己跑命令、自己反复试错。短时间看，这似乎很勤快；但只要任务稍微复杂一点，主会话的 context 很快就会被实现细节塞满。

一旦主会话被塞满，最先坏掉的往往不是执行能力，而是判断力。

一、M2 三层管理模式到底在解决什么

所谓 M2 三层管理模式，可以粗略理解成：

  • L0 协调者：负责和人对话、做决策、拆任务、收结果
  • L1 监工：负责承接任务、监督执行、做验证
  • L2 工兵：负责真正写代码、改配置、跑命令

很多人第一次看到这个结构，会以为它在讲“怎么提高效率”。

但我现在更认同另一种说法：

这首先是一个 context 架构，不是一个效率技巧。

如果 L0 自己下场写代码，那它很快就会装满这些东西：

  • 几百行文件内容
  • 安装输出
  • 编译报错
  • 测试日志
  • diff 细节
  • 各种尝试失败的中间状态

这时候只要人类插一句“现在进展怎么样”，L0 就不一定能立刻回答了。不是它不会回答，而是它脑子里全是脏细节。

所以 M2 真正保护的是：

  • 主线程的响应能力
  • 主线程的全局视角
  • 主线程的任务优先级判断

二、为什么这件事对 Hermes 特别重要

在 Hermes 这类工具里，当前对话会话天然就像 L0。

它最适合做的是：

  • 理解用户真正要什么
  • 定义目标和约束
  • 决定下一步是查、修、测还是问
  • 汇总结果并回给用户

它最不适合长期做的是：

  • 吞长日志
  • 陷入单个报错的来回试错
  • 连续改多个文件再反复重跑
  • 把一大堆执行输出直接留在主上下文里

Hermes 的 delegate_task 在这里就非常关键。它不只是一个“并行工具”，更像一个“上下文隔离器”。

委派出去的子任务可以去做那些脏活：

  • 读日志
  • 查结构
  • 跑测试
  • 归纳报错
  • 做局部修复
  • 验证一个小闭环

主会话则只保留：

  • 用户目标
  • 当前计划
  • 关键决策
  • 子任务带回来的压缩结论

这就是 M2 思想在 Hermes 里的直接落地。

三、delegate_task 最容易被误用的地方

很多人会把 delegate_task 理解成“能并发就并发”。

这当然没错，但还不够。

真正重要的是：

不是为了并发而委派，而是为了不让主会话变脏而委派。

比如一个请求是：

“帮我修掉这个项目里的测试失败，并告诉我根因。”

一种坏做法是主会话自己：

  • 跑测试
  • 看日志
  • 搜文件
  • 改代码
  • 再跑测试
  • 再看一轮日志

这种做法非常容易让 controller session 被技术噪音淹没。

更好的做法是：

  • 主会话定义清楚目标
  • 给出约束和验收标准
  • 把“定位根因 + 修复 + 验证”切成小块
  • 让子代理返回简洁的总结，而不是原始过程

这样主会话依然能接住人类的新消息，也还能做更好的全局判断。

四、任务拆小，比一味拉长 timeout 更重要

另一个很实用的经验是：子任务频繁超时，常常不是因为 timeout 太短，而是任务本身太大。

一个健康的委派任务，通常应该满足：

  • 目标清楚
  • 约束明确
  • 验收具体
  • 5–10 分钟内能闭环

比如这些任务就比较合适：

  • “检查这个仓库里 auth middleware 的接入位置，并总结到 5 点”
  • “运行测试并按 root cause 对失败分类”
  • “根据给定验收标准，修复这个页面的构建错误”
  • “阅读日志并判断这是配置问题还是代码问题”

而像“把整个项目都修好”这种指令，看起来省事，实际上通常最不稳定。

任务太大时，子代理很容易：

  • 超时
  • 结果过粗
  • 中间状态不可复用
  • 出错后很难定位到底卡在哪一层

所以一个更稳的原则是：

小任务 + 清晰验收，通常优于大任务 + 超长等待。

五、上层要给目标，不要给微操说明

M2 模式还有一个很重要的点：上层不要把下层当手指，而要把下层当执行单元。

好的委派应该提供：

  • goal：要达成什么
  • context：背景信息是什么
  • constraints：不能碰什么、要遵守什么
  • expected output：希望返回什么格式的结果

而不是把命令一步一步写死，变成机械遥控。

原因很简单：如果上层连执行细节都要亲自盯完，那 context 还是会污染上来，只是换了一种形式。

六、一个简单的判断标准

我现在很喜欢用一个问题来判断某件事是不是该委派：

如果用户现在突然插一句话，主会话还能不能立刻清楚地接住？

如果答案是否定的，说明主会话已经陷得太深了。

这往往就是应该：

  • 把任务切小
  • 把脏活下放
  • 让主线程重新只保留高层状态

七、最后的结论

所以，M2 对 Hermes 的启发不是“永远套三层”，也不是“所有事情都必须开子代理”。

真正值得保留的，是这条工作习惯：

把当前主会话当项目经理，而不是施工队。

delegate_task 最宝贵的地方，不只是能并发，也不是能省几分钟，而是它能把噪音隔离出去，把主线程的认知带宽留给真正重要的事：

  • 决策
  • 沟通
  • 取舍
  • 响应用户

当一个 agent 学会保护自己的主上下文，它才开始真正像一个协调者，而不只是一个更勤快的工兵。