KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
多 Agent 协作术语地图 — keel 龙骨
Multi-Agent Collaboration 的参考信息：多 Agent 协作术语地图
先把术语放进同一条运行链路，再进入具体模式。
| 术语 | 专业含义 | 工程边界 |
|---|---|---|
| Agent | 能围绕目标选择下一步并使用能力的运行单元 | 不等于一个 prompt 或一个角色名称 |
| Agent instance | 一次运行中可寻址的 Agent 实例 | 同一种 Agent 可以有多个实例 |
| Role | 对职责、目标和行为约束的描述 | 角色文字本身不提供权限和隔离 |
| Capability | Agent 声明能够承担的任务类型 | 必须映射到真实工具、模型和策略 |
| Task | 有目标、输入、约束、所有者和完成条件的工作单元 | 不应只是一条模糊聊天消息 |
| Task owner | 当前负责推进任务并报告结果的执行者 | 同一时刻应能确定唯一所有者 |
| Delegation | 一个协调者把子任务分配给另一个 Agent | 不自动转移调用者身份和权限 |
| Handoff | 把当前任务或会话控制权显式交给另一个 Agent | 必须记录新所有者、原因和剩余预算 |
| Routing | 根据类型、能力或策略选择下一处理者 | 可以由规则、分类器或模型完成 |
| Coordinator | 拆分、分派、汇聚并决定下一步的组件 | 不应偷偷承担所有专业任务 |
| Supervisor | 具有集中控制权的 Coordinator 模式 | 是拓扑选择，不表示更高业务权限 |
| Worker | 接收有限任务并返回结果的专业 Agent | 不应读取与任务无关的全部上下文 |
| Message | Agent 或运行时之间传递的协议消息 | 不是共享数据库，也不等于完整状态 |
| Artifact | 一个任务产生的可引用工作成果 | 应带生产者、任务 ID、版本和证据来源 |
| Shared state | 当前团队运行共同维护的状态 | 需要并发控制和明确写入者 |
| Memory | 跨运行仍可能有价值的持久信息 | 不能用来传递当前任务所有权或权限 |
| Context | 某次模型调用实际看到的材料 | 应按 Agent 职责最小化，而非全量广播 |
| Fan-out | 把一个目标拆成多个可并行子任务 | 子任务必须足够独立 |
| Fan-in / Gather | 收集多个结果并按策略汇聚 | 必须处理缺失、重复和迟到结果 |
| Handoff chain | 多个 Agent 依次接管同一任务的路径 | 需要跳数、时间和成本上限 |
| Review | 根据标准检查工件并给出结构化反馈 | 不是无限自由辩论 |
| Consensus | 多个输出满足某种汇聚或一致规则 | 多数同意不能证明事实正确 |
| Partial success | 一部分子任务成功、一部分失败 | 最终状态取决于哪些结果是必需的 |
| Backpressure | 下游处理能力不足时限制上游继续产生任务 | 不能靠无限创建 Agent 解决拥塞 |
| Collaboration topology | Agent 之间允许通信和转移控制的结构 | 拓扑越自由，验证和权限控制越难 |
| Trace | 一次运行中任务、消息、工件和状态变化的因果记录 | 仅保存最终文本无法定位协作失败 |
| Baseline | 用于比较的更简单实现，通常是单 Agent | 没有基线就不能证明多 Agent 有价值 |
| Ablation | 移除一个 Agent 或协作步骤后的对照实验 | 用来判断增益来自哪里 |
一条最小协作链可以写成：
Team Run
-> Coordinator 创建 Task
-> Registry 选择有能力且获准的 Worker
-> Worker 生成 TaskResult 和 Artifact
-> Gather 按 task_id 收集结果
-> Reviewer 给出 ReviewResult
-> Harness 完成、降级、失败、取消或等待人工处理
看到任何多 Agent 代码时，先问四件事：当前任务属于谁、该 Agent 看到了什么、它能做什么、结果怎样被验证。