KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Multi-Agent Collaboration — keel 龙骨
先面对一次真实的事件响应。支付服务出现超时，现有证据分散在指标快照、变更记录和事件描述里。一个 Agent 可以独自读取全部材料，但它的上下文会越来越大，分析与审查也混在同一次生成中。你准备增加两个专业 Agent：一个分析运行指标，一个检查最近变更；协调者负责拆分任务、收集证据并生成结论。
先面对一次真实的事件响应。支付服务出现超时，现有证据分散在指标快照、变更记录和事件描述里。一个 Agent 可以独自读取全部材料，但它的上下文会越来越大，分析与审查也混在同一次生成中。你准备增加两个专业 Agent：一个分析运行指标，一个检查最近变更；协调者负责拆分任务、收集证据并生成结论。
章节目录
- 01. 第二个 Agent 真的有必要吗？ — 支付服务出现超时。你已经有一个 Agent，它能读取事件描述、指标快照和部署记录，并给出分析。现在有人提出：“再加三个 Agent，让它们分别扮演 SRE、开发和审查员，效果一定更好。”
- 02. 协作为什么要从任务契约开始？ — “请指标 Agent 看一下这个故障”对人类同事或许足够，对程序不够。系统至少不知道：看什么数据、输出什么结构、何时算完成、失败能否重试，以及结果应该回到哪次运行。
- 03. 让 Ollama 成为一个边界清楚的专业 Agent — 现在只实现一个指标分析 Agent。它不会决定团队结构，不会给自己分派新任务，也不会读取所有运行状态。它接收一个已经授权的 CollaborationTask，返回结构化 FindingArtifact。
- 04. Supervisor 怎样分派而不替 Worker 做事？ — 指标 Agent 已经能完成一个独立任务。现在需要一个组件接收事件目标，决定生成哪些子任务，并把它们交给合适的 Worker。这个组件是 Coordinator；当所有路由和结果都回到它时，形成 Supervisor 拓扑。
- 05. Handoff 究竟转移了什么？ — 用户一开始只说“支付服务异常”。Triage Agent 识别到这是运行指标问题，把当前任务交给 Metrics Agent；Metrics Agent 发现需要数据库权限，再把任务交给人工值班人员。
- 06. 并行任务怎样汇聚而不丢失因果关系？ — 事件诊断需要同时检查指标和最近部署。两个任务只依赖同一份事件摘要，彼此不依赖，因此可以 fan-out 并行执行，完成后再 fan-in 汇聚。
- 07. 多个 Agent 应该共享什么？ — 多 Agent 系统最容易出现的设计是一个全局 messages 列表：每个 Agent 都读取全部内容，也把所有输出追加进去。开始时很方便，运行变长后会出现上下文膨胀、并发覆盖、敏感数据扩散和错误假设互相强化。
- 08. 审查者怎样改进结果，而不是制造争论？ — Metrics Agent 生成了候选发现：“连接池耗尽是根因。” Reviewer 应该检查什么？如果只提示“请严格审查”，它可能改写措辞、提出新猜测，甚至与生成者无限往返。
- 09. 一个 Agent 失败后，团队怎样收束？ — 并行运行中，Change Agent 查询部署服务超时。此时 Metrics Agent 已经成功返回。你不能简单地把整次运行标成成功，也不能把已完成结果全部丢掉。
- 10. 委派为什么不会自动转移权限？ — Coordinator 有权把“查询事件”交给 Metrics Agent，不代表 Metrics Agent 获得了 Coordinator 的全部数据访问和写操作权限。
- 11. 怎样证明多个 Agent 比一个更好？ — 最终报告看起来更专业，不代表协作有效。你需要能够回答：哪一个 Agent 产生了哪个工件、哪次委派增加了延迟、哪个失败导致了降级、最终质量相对单 Agent 是否真的提升。
- 12. 完成事件响应协作组 — 现在把事件诊断做成一个完整的 TeamRun。目标不是展示多个 Agent 互相聊天，而是交付一条能解释、能降级、能停止、能测试的协作运行。