分享下我在多 Agent 管理时的一点经验：

1. 不要把任务切分的太细，重点放在设计和验收
   
   正如宝玉老师所说，管多 Agent 正如管人一样。新的技术管理者最容易陷入的误区就是事无巨细的管，导致自己最容易成为瓶颈
   
   管 Agent 也是，如果每个 Agent 的执行粒度是几分钟的话，很快人的脑袋就晕了，上下文切不过来，也容易管出问题
   
   我目前体会是每个任务控制在小时粒度（长的话有几小时的）是最舒服的，这就需要设计阶段多花些时间和 Agent 调研和讨论，形成文档化的共识后让它去慢慢跑。与此同时我再切到下一个 Agent 讨论和布置任务
   
   
2. 验收要落在实处，“多少测试用例绿了” 不能说明任何问题
   
   Agent 在跑长程任务后很容易跑出几十上百个单元测试，这些不是质量证据，甚至不能说明 spec 的遵从度。只有从设计角度出发，写一套符合需求的端到端验证，拿到验证证据才算数
   
   这方面特别推荐使用 pstack 的以下两个元技能（用来创建skill的skill）：
   /create-verification-skill
   /create-formal-verification-skill
   
   第一个能帮你创建一个 e2e 测试的基础设施、以及当前项目的功能地图，根据功能地图进行真实的e2e测试：
   
   https://t.co/oAV599JOyu
   
   第二个是对第一个测不到的地方的补充，比如无法枚举的测试、并发竞态条件等，用形式化验证来做数学证明，确保复杂状态的正确性
   
   相对应的 lauren 还提供了两个维护更新这两个skill的元skill，简单说就是项目功能在不断迭代过程中，验证类的skill也要随项目不断更新才行
   
   
3. 与多 Agent 的沟通方式：不要打乱自己的节奏
   
   刚开始管理多 Agent 的时候，我开很多窗口，一有 Agent 完成任务了我就切过去看，很快证明这样马上就会乱成一坨
   
   多 Agent 管理必然是异步沟通的方式，这有点像是 CPU 的时间片切换，不应该一有消息就马上切，而是 Agent 异步通知 → 我看到通知了 → 等我把手头的一个检查点工作做完 → 再切过去接收
   
   Agent 永远是在挂起等我反馈，而我只有做完当前“线程”的阶段性事务才会切我的注意力过去
   
   目前我的窗口极限大概就3-4个，这和当前 AI 的长程能力也息息相关（如果未来Agent可以按天高质量交付了，这个窗口数就能扩大）
   
   
4. 反模式：单任务不要过大
   
   按照当前的前沿模型能力，我认为单任务最长控制在小时级别是合适的，到天级别很容易跑歪
   
   之前我跑了一个几天的长程任务，跑完发现一堆问题，最后还是不得不全部回滚了
   
   这还是上面说到的原因：当前最前沿模型的能力，我的感觉还到不了天级别
   
   上下文窗口、幻觉、自动压缩、指令遵从性等等，会让 Agent 在长程任务上的问题会逐渐放大到不可控
   
   ---
   
   以上就是我在管理多 Agent 上的一点经验，欢迎讨论下：你现在能控制几个 Agent ？每个的平均时长是多少？如何把控质量？