Agent Team 协调模型

以强模型为基础，验证 LLM 与 harness 的整体效果

是否委派、如何拆分、联系谁以及结果是否满足目标，由 LLM 判断。Harness 提供可执行工具、必要上下文、消息投递、取消能力和明确结果。模型自主能力是设计起点，LLM 与 harness 能共同完成任务是验收标准。

兼容性不能依赖较弱模型自行推断隐藏的运行规则。所有支持的模型都应获得一致、清楚的交付、等待和恢复契约。只有观察到反复发生的不足，才增加针对模型的提醒或限制，并验证其是否改善完成效果、是否不必要地限制了更强模型。

优先采用最小改动：先检查上下文缺失、指令矛盾和工具执行问题；这些修复仍不足以解决实际问题时，再考虑增加流程机制。

Lead 决定分工并对共同目标负责

当委派带来的质量、耗时或上下文收益足以覆盖任务说明与结果整合成本时，使用团队。专家数量或最终文档数量不能单独决定是否值得委派。成员自主完成被分配的工作；Lead 检查结果、处理分歧，并负责最终交付。

team_create 声明当前已经明确的工作。每个成员拥有唯一名称、agent 类型、自包含的任务说明，以及可选的 dependsOn。独立成员在 Lead 本轮结束后启动；有依赖的成员在全部上游交付后启动。随着新信息出现，Lead 可以通过 team_replan 追加或修订工作，无须在开始前预测完整流程。

五个工具提供明确的协作契约

工具	调用者	行为
team_create	Lead	创建成员及当前任务，校验名称与依赖环。
team_status	双方	读取当前状态，每轮最多一次以防轮询；并行执行仍可能改变状态。
team_send_message	双方	持久化消息；运行中的接收者在下一步读取，空闲接收者在发送者本轮结束后被唤醒。
team_replan	Lead	追加任务、修订交付或取消分支；操作顺序执行，不是事务。
team_dissolve	Lead	停止剩余运行并关闭团队。

一个成员拥有一个逻辑任务，但可以多次运行。修订保留成员与任务身份；无关的新任务使用新成员。团队历史中的成员名称不能重复使用。

等待答复不会完成任务

成员必须获得答复才能继续时，调用 team_send_message 并设置 wait_for_reply: true。本轮在工具步骤边界结束，任务保持未完成。后续消息可以唤醒成员；退出后的补偿检查也会处理清理期间到达的回复。普通消息不会停止发送者。Lead 发送普通消息，需要等待时结束自己的回合。

等待前应保存进展，并在问题中附上相关路径。唤醒会重建上下文，不会恢复上轮完整对话。Lead 和成员都会将消息正文读入提醒，并在接收消息的本轮保留。下游成员也会获得所依赖任务的摘要与产物路径。

正常结束的等待会在现有成员运行记录中保存为 finishReason: "waiting"。恢复时先检查该记录与收件箱；没有新消息时，已提交的等待继续保持，不需要新增任务状态或数据库迁移。若在运行记录提交前崩溃，仍按中断运行恢复；新消息也不保证就是所需问题的答案。

交付与恢复具有明确效果

成员通过 complete({ summary, paths }) 交付。简短结论可以使用 paths: []，文件产物必须实际存在。任何无效的提交路径都会阻止团队任务完成，避免下游在缺少交付物时启动。不得用 complete 暂停未完成的工作。

失败任务使下游保持阻塞。取消失败成员时，会清理尚未完成的下游分支，并保留根任务的失败记录。替代成员需要新名称与明确依赖，旧依赖不会自动转接。新增任务可以依赖已交付成员。若 replan 部分失败，应先检查状态再重试。

修订已交付任务会重新打开该任务，并将已交付的下游任务标为过期。修订前，下游工作必须已经交付或取消。全部任务交付不会自动关闭团队；Lead 验收后，在没有后续工作时解散团队。

模型兼容从一致的契约开始

模型决定分工、沟通与修正，harness 提供可靠执行和明确的工具结果。针对特定模型的额外提醒或限制，应依据实际失败添加，不应预先把所有模型固定在同一种流程中。契约测试验证状态变化和工具行为；分工质量与完成成本仍需通过真实模型评测验证。

隔离委派且结果随工具调用返回时使用 task；需要消息、协调或后续修订时使用 team。另见 Agent Team 实现与子代理。

用相同任务与可观察结果评测真实模型

以下是评测计划，不是已测结果。各模型应使用相同输入、工具、工作区快照和预算；记录准确的模型标识与配置，在适用场景中比较单 agent 基线。应多次运行后再判断失败是否来自模型能力。

场景	输入或干预	检查证据
直接回答	提供足以回答一个简单问题的文本。	答案正确，没有不必要的委派。
独立审查	两份独立文件，分别指定审查范围。	覆盖程度、重复工作、耗时与整合质量。
依赖交接	调研产生写作所需事实。	写作在上游交付后启动，并读取实际产物路径。
缺少决策	暂不提供必需的区域信息，提问后再答复。	不编造假设，等待保留任务，回复后完成工作。
结果修订	交付后提供纠正证据。	修订相关原任务，并更新受影响的下游结果。
失败恢复	移除必需输入或注入工具错误。	显式报告失败，保留可复用成果，替代工作依赖正确。
等待时重启	等待运行正常提交后重启，再发送答复。	新消息前不运行，收到答复后有效继续。

结果质量与运行正确性分别评分。记录任务成功率、遗漏或虚构结论、无效工具调用、多余成员、重复工作、等待空转、耗时以及 token 和费用。成本更低但答案不完整，不能算优化成功。只有重复出现的问题具有可验证原因、补充约束能改善结果时，才增加 harness 限制。

Teams 频道显式启用协作工具

/teams/:id 页面通过聊天消息通道进入 runChatTurn。通用工具集不包含 team，因此，当宿主提供团队运行服务时，buildChatToolKeys 会为频道中的系统 Lead 显式加入该能力。同一份工具列表用于初始化 context.team 并传入执行循环，从而启用 team_create 等协调工具及 Lead 指令。普通对话和直接被提及的专家不获得此协调能力；团队成员使用独立的成员执行路径。

创建频道后，Lead 应具备协作能力，再由模型判断具体请求是否值得委派。如果模型报告工具集中没有 team_create，应先检查运行时工具装配，再调整提示词。修改代码后需重启或重新加载后端，再发送新消息；已经运行的轮次仍保留原工具集。

同一专家定义支持两种执行模式

一次性子代理和团队成员均通过 buildDelegatedAgentSetup 组装模型配置、专家指令和配置中的步数预算。共享基础指令分别接收独立委派或成员模式，专家的专业指令保持一致。成员不再自动获得三倍步数上限。

成员模式增加团队通信能力，以及交付成功和等待回复的停止条件。成员的团队工具工厂只暴露 team_status 和 team_send_message，不暴露 Lead 的协调工具，同时保留执行时的角色校验。两种模式均通过 complete 提交摘要和可选文件。流记录持久化、邮箱处理、依赖调度及唤醒恢复仍由团队生命周期服务负责，不并入共享配置函数。