KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

多 Agent 协作：从明确分工，到可验证的团队运行 — keel 龙骨

Multi-Agent Collaboration 的参考信息：多 Agent 协作：从明确分工，到可验证的团队运行

先面对一次真实的事件响应。支付服务出现超时，现有证据分散在指标快照、变更记录和事件描述里。一个 Agent 可以独自读取全部材料，但它的上下文会越来越大，分析与审查也混在同一次生成中。你准备增加两个专业 Agent：一个分析运行指标，一个检查最近变更；协调者负责拆分任务、收集证据并生成结论。

增加 Agent 之后，问题并没有自动变简单：

两个 Agent 是否真的在完成不同任务，还是只换了人设重复回答？
协调者怎样知道该把任务交给谁？
专业 Agent 应该看到完整对话，还是只看到完成任务所需的上下文？
并行任务有一个失败时，整次运行应该失败、降级还是等待重试？
Agent 的输出怎样带着来源进入最终结论，而不是变成不可追踪的文本？
一个 Agent 是否可以把自己的工具权限一并转交给另一个 Agent？

这些问题共同构成多 Agent 协作的工程核心。

先看一次团队运行

flowchart LR
    U[用户目标] --> H[Harness 创建 Team Run]
    H --> C[Coordinator 拆分任务]
    C --> M[指标分析任务]
    C --> D[变更分析任务]
    M --> A[Metrics Agent]
    D --> B[Change Agent]
    A --> X[带证据的 Artifact]
    B --> Y[带证据的 Artifact]
    X --> G[Gather 汇聚]
    Y --> G
    G --> R[Reviewer 检查]
    R -->|通过| F[最终报告]
    R -->|需修改且预算允许| C

图中至少有四种不同责任：

Harness 管理整次运行的状态、预算、事件和终止；
Coordinator 决定怎样拆任务以及怎样收束结果；
Worker Agent 在有限上下文中完成专业任务；
Reviewer 根据明确标准检查工件，不直接获得现实世界写权限。

多 Agent 架构的价值来自责任和上下文边界，不来自 Agent 数量。若一个模型加两个工具已经能稳定完成任务，就没有必要增加第二个 Agent。

走完这条路径，你应能解释什么

Agent、Role、Task、Tool、Worker 和 Coordinator 分别是什么；
多 Agent 系统与多个 prompt、多个工具调用、普通工作流有什么区别；
Task、Message、Artifact、Shared State 和 Memory 为什么不能混成聊天历史；
routing、delegation、handoff、fan-out/fan-in、review 各自改变了什么；
Supervisor、去中心化交接、顺序流水线和并行工作组适合什么任务；
为什么上下文隔离、任务所有权和输出契约比“角色人设”更重要；
如何处理重复委派、部分成功、超时、取消、迟到结果和重试；
为什么委派任务不等于委派身份、权限或工具凭据；
怎样记录跨 Agent 因果链，并定位错误最早出现在哪个任务；
怎样用单 Agent 基线、消融实验、质量、成本和延迟判断协作是否值得。

学习路线

章节	先解决的问题	主要产出
01. 第二个 Agent 真的有必要吗？	区分真实分工与多个人设	单 Agent 基线与采用条件
02. 协作为什么要从任务契约开始？	分清 Agent、任务、消息和工件	`CollaborationTask` 与 `TaskResult`
03. 让 Ollama 成为一个边界清楚的专业 Agent	用结构化输出实现专业工作者	第一次真实 Specialist 调用
04. Supervisor 怎样分派而不替 Worker 做事？	建立集中式协调和注册表	可测试的 Coordinator
05. Handoff 究竟转移了什么？	处理控制权、任务所有权和上下文	显式交接记录
06. 并行任务怎样汇聚而不丢失因果关系？	处理相关 ID、部分结果和背压	fan-out/fan-in 实验
07. 多个 Agent 应该共享什么？	区分消息、工件、状态和记忆	共享数据边界图
08. 审查者怎样改进结果，而不是制造争论？	建立证据化 review 和停止条件	evaluator-optimizer 循环
09. 一个 Agent 失败后，团队怎样收束？	处理失败传播、重试和取消	部分失败实验
10. 委派为什么不会自动转移权限？	建立身份、能力和信任边界	最小权限协作策略
11. 怎样证明多个 Agent 比一个更好？	建立轨迹、基线和消融评估	协作评估表
12. 完成事件响应协作组	把全部协议连成可测试运行	结课项目

先运行确定性协议，再观察真实模型

代码和运行方式写在 project/README.md 中。先验证任务契约、Agent 白名单、结果关联和失败策略：

python -m pip install -r courses/advanced/multi-agent-collaboration/course/project/requirements.txt
python courses/advanced/multi-agent-collaboration/course/project/examples/01_task_contract.py
python courses/advanced/multi-agent-collaboration/course/project/examples/03_parallel_team.py
python -m unittest discover -s courses/advanced/multi-agent-collaboration/course/project/tests -v

确定性边界通过后，再让真实 Ollama 承担专业分析：

ollama serve
ollama pull qwen3:8b
$env:OLLAMA_MODEL = "qwen3:8b"
python courses/advanced/multi-agent-collaboration/course/project/examples/02_ollama_specialist.py

模型用来完成语义判断；任务所有权、Agent 注册、权限、最大并行数、停止条件和事件顺序必须由程序验证。

从第 01 章开始。先证明单 Agent 的不足，再为协作增加第二个 Agent。

课程采用的资料依据和取舍记录在调研与课程设计依据中。

进入 keel 阅读