Agent Teams 建议：任务生命周期、成员状态与协作原语的缺口

[ChongCyrus]

背景

本人在 DeepSeek Harness 0.2.1-rc.2 上使用 Agent Teams（一名 Lead 与若干持久队友，共享任务板）进行并行协作。当前提供给模型的接口为九个工具：spawn_teammate、list_agents、send_message、wait_agent、interrupt_agent，以及 team_task_create、team_task_get、team_task_list、team_task_update。整体设计稳健：任务板采用 CAS 版本号，write_scopes 作为建议性作用域，blocked_by 表达依赖，消息以推送方式投递，正常路径运行良好。

以下缺口均为多成员并行协作时实际遇到，依据为模型侧工具说明与已安装版本的行为观察，未修改任何代码。

一、任务生命周期缺少历史与墓碑可见性

• team_task_get 仅返回最新值，无 revision 或 history 参数。任务一经 edit 或 reassign，先前内容不可追溯。
• delete 采用墓碑实现（内部状态置为 deleted），方向正确；但 team_task_list 的 status 仅接受 pending | in_progress | completed，已删除任务无法通过工具查询。不可见的墓碑只完成了审计链的一半。
• 删除仍阻塞下游的任务会被拒绝（提示 still blocks）。行为合理，但该约束只能通过尝试删除才能发现。

建议：team_task_get 支持 revision 参数并可选返回历史；team_task_list 的 status 增加 deleted；删除前可通过查询获知依赖关系。

二、成员状态缺少进展信号

• list_agents 给出的是持久 phase（provisioning / active / failed）叠加实时 turn 活动。inactive 明确表示"当前无 turn 执行"，而非任务完成。
• 由此"已停滞"与"空闲待命"在接口上不可区分：没有最后活动时间，没有心跳，failed 不包含错误原因。
• wait_agent 仅观察调用之后发生的变化，Lead 可能在成员静默停止时无限等待。

建议：提供 lastActivityAt；failed 附带简短 error；wait_agent 支持"超过 N 毫秒无进展"的上报，与"无变化"区分。

三、分页缺少结束信号

team_task_list 使用 cursor（0 基偏移）与 limit（默认 50、上限 100）。返回结果不含 total 或 hasMore，调用方无法判断列表是否完整，只能持续翻页直至空页。

建议：返回 total 或 hasMore。

四、若干协作原语缺位

• 结构化结果：complete 不携带结果载荷，send_message 为自由文本，Lead 需重读自然语言自行聚合。建议 complete 增加 result（可由任务声明 schema），并为消息增加 progress / question / blocker / final 类型。
• 成本与预算：无按成员或全局的 token / 时长预算，list_agents 亦无用量信息。多智能体是成本最高的运行方式，目前既无上限也无可见性。
• 写作用域认领：write_scopes 设计上仅为建议、不是锁，两名成员编辑同一文件属静默竞争。建议增加软认领与冲突上报（或按任务粒度的变更集），无需分布式锁即可覆盖常见场景。
• 取消级联：interrupt_agent 一次仅一个成员且仅限 Lead；无整棵任务树取消，blocker 失败无传播（下游永久等待），亦无自动重派。
• 消息投递语义：send_message 成功不代表已处理，且无 ack、重试、TTL 与广播。

五、可观测性有限

成员视图主要覆盖身份、phase 与活动状态，缺少耗时、工具调用次数与事件时间线，任务板亦无变更日志。长周期多成员运行的事后复盘基本不可行。

六、任务板 UI 只增不减

• 长期使用后任务板随任务数线性增长，已完成任务永久占位；Web/Desktop 的任务板没有"仅看进行中／隐藏已完成"的筛选，也没有批量清理入口。
• 清理只能逐条 delete，而 delete 在数据层是墓碑（见第一节），在 UI 上难以确认是否真正移除，也缺少"归档"这一中间状态。
• 建议：任务板默认只显示 pending / in_progress，提供"显示已完成／已删除"切换与批量归档。archive 比 delete 更合适：既从日常视图隐藏，又保留审计链。

七、成员模型与团队规模不可配置

• spawn_teammate 的参数只有 name、description、prompt、context（fresh / fork），没有 provider、model、reasoning_effort；对比之下 subagent 支持这三项。结果是同一次运行里无法让"检索用便宜模型、实现用强模型"，只能全部继承默认路由。
• 成员创建后也没有修改模型或提供商的入口。这与 希望能够扩展完善Agent Team智能体团队的功能 #10680 记录的"成员不能改名、不能删除"同源：成员缺少完整的生命周期管理。
• 团队规模同样没有可配置接口：模型侧没有"最大队友数"参数，也无法查询当前上限或剩余名额，只能通过创建失败来发现边界。
• 建议：spawn_teammate 增加可选的 provider / model / reasoning_effort（与 subagent 对齐）；通过 profile 或新增 team_config 设置 max_teammates，并在 list_agents 中返回 limit / remaining 供调用方规划。这与第四节"按成员预算"属于同一主题：团队容量应当显式可控，而不是隐式继承。

优先级建议

若只能先做三项：（1）complete 携带结构化 result；（2）提供进度／心跳并区分 stalled；（3）提供按成员预算。前两项决定协作是否可信，第三项决定是否可负担；写作用域冲突与取消级联可随并行度增长再处理。（4）任务板的状态筛选与批量归档属于低风险、见效快的项，可与前两项并行推进。（5）成员级模型与团队规模上限应与按成员预算一并设计。

如需复现步骤或进一步验证，本人可配合补充。

相关讨论

#10680 记录了成员生命周期与模型字段方面的缺陷（成员无法删除或改名、spawn_teammate 无法指定模型等）。本文聚焦任务生命周期、成员状态信号与协作原语，二者互补，建议合并阅读。