KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA

调研与课程设计依据 — keel 龙骨

Multi-Agent Collaboration 的参考信息：调研与课程设计依据

这份记录回答两个问题：主流资料怎样讲多 Agent，以及哪些内容值得进入一条面向项目实践的学习路径。它不是正文的前置阅读。

调研范围

调研于 2026-08-22 完成，优先使用框架官方文档、课程官方页面和论文原文。

样本	重点内容	值得吸收的部分	需要补足的部分
LangChain Multi-agent	subagents、handoffs、skills、router、custom workflow	先问为什么需要多 Agent；按上下文、并行和交互方式选择模式	框架模式需要还原为任务、状态和权限协议
AutoGen Design Patterns	group chat、reflection、sequential、concurrent、handoff	把协作模式定义为消息协议产生的结构	示例较贴近框架 runtime，需要先建立框架无关概念
Google ADK Workflows	graph、dynamic、collaborative、sequential、loop、parallel	明确区分确定性节点与模型驱动节点	需要补充任务所有权、失败语义和授权边界
CrewAI Crews	agent、task、sequential/hierarchical process、manager、checkpoint	Agent 与 Task 分离，结果和运行数据结构化	role/backstory 容易让初学者误以为人设就是架构
Anthropic: Building Effective Agents	routing、parallelization、orchestrator-workers、evaluator-optimizer	从简单方案开始，只在收益明确时增加复杂度	需要把模式落实为可测试的 Python 协议
DeepLearning.AI: Multi AI Agent Systems with crewAI	角色、工具、记忆、串行/并行/层级协作和业务案例	用连续业务案例快速形成整体印象	需要增加失败恢复、权限、轨迹和基线评估

论文给出的技术线索

AutoGen 强调可定制、可对话 Agent，以及自然语言和代码共同定义交互行为。
CAMEL 展示了 role-playing 对协作研究的价值，但角色一致性不等于生产系统中的身份、能力或权限。
MetaGPT 用标准操作流程和中间产物减少朴素对话链中的逻辑不一致，说明工件和流程契约比自由聊天更可靠。
ChatDev 用专业角色和沟通链组织软件开发阶段，说明自然语言消息可以连接不同任务，但仍需要阶段和输出边界。
AgentVerse 研究动态团队和群体行为，提醒系统设计既要利用正向协作，也要约束负向群体行为。
Mixture-of-Agents 展示分层聚合多个模型输出的模式，但更高 benchmark 分数不能替代特定业务的成本、延迟和可靠性评估。
Why Do Multi-Agent LLM Systems Fail? 将失败归入系统设计、Agent 间失配和任务验证等类别。课程因此把任务协议、上下文、验证和轨迹放在“角色扮演”之前。

从样本中得到的五个判断

1. 多 Agent 是有代价的架构选择

更多模型调用意味着更多延迟、token、失败点和观测数据。只有上下文隔离、独立开发、并行处理、专业能力或明确审查能带来可测收益时，第二个 Agent 才有理由存在。

2. 协作首先是任务和消息协议

“研究员”“审查员”只是角色标签。生产代码还需要任务 ID、所有者、输入范围、输出 schema、证据、超时、重试和状态。没有这些对象，多 Agent 只是难以调试的多轮聊天。

3. 确定性编排和模型决策应该混合使用

固定依赖、权限检查、最大并行数、停止条件和结果关联适合代码；开放式拆解、语义分析和内容综合可以交给模型。把所有路由都交给模型会失去可预测性，把所有步骤都写死又失去 Agent 的适应性。

4. 上下文工程决定协作质量

专业 Agent 不需要完整聊天历史。它需要完成当前任务的最小材料、可用工具、输出标准和来源引用。全量广播不仅浪费 token，还会传播提示注入、陈旧状态和其他 Agent 的错误假设。

5. 评估必须包含简单基线

先比较单 Agent；再分别移除 reviewer、并行分支或模型路由做消融。只有任务质量提升足以抵消成本、延迟和复杂性时，多 Agent 方案才成立。

课程采用的线性顺序

顺序遵循“先有稳定对象，再增加协作自由度”：

单 Agent 基线
  -> Task/Result 契约
  -> 单个 Ollama Specialist
  -> 集中式 Supervisor
  -> Handoff
  -> 并行 Gather
  -> 共享数据治理
  -> Review 循环
  -> 失败与安全
  -> 评估与生产映射

前半段使用确定性替身验证协议，避免把模型随机性误认为协作逻辑；中段接入 Ollama Structured Outputs；后半段用失败注入和对照评估把系统拉回生产判断。

进入 keel 阅读