将 DeepSeek Harness Agent Teams 接入 DeepSeek API

Agent Teams 是 DeepSeek Harness 的一套实验性、需显式启用的多 Agent 子系统。它为 Lead Session 提供具名成员列表、共享任务板和持久化成员消息。它没有默认启用，也不能被描述成已经稳定发布的公共产品功能。

来源：官方 Agent Teams 子系统文档

Agent Teams 与普通 Subagent 的区别

普通 Subagent 更接近一次委派：父 Agent 发起工作、拿到结果，之后可能不会再次找到同一个执行者。Team 成员拥有稳定名称和子 Session 身份，可以继续接收消息，也能持有记录在 Team 日志中的任务。

持久化模型

Team 由 Root Lead Session 标识，不需要单独的“创建团队”事件。第一个成员、消息或任务事件写入后，持久化状态才开始出现。

• **Roster：**不可变的成员名称与生命周期状态。
• **Mailbox：**即时投递失败后仍可保留的成员消息。
• **Task Board：**包含依赖关系和 CAS 所有权更新的任务。
• **Replay：**通过 Lead Session 事件日志重建 Team 状态。

这延续了 Harness 的核心约束：模型可见的事实必须写入日志并能够重放。

如何组合

实现被拆成两个 experimental 包：一个负责 Team 领域和持久化语义，另一个提供模型工具与指导。部署必须显式挂载两者。官方配置还包含成员数、任务数、待处理消息数、消息字节数和销毁超时等限制。

由于它们仍是实验包，包名和配置可能变化。应该复制与你安装 tag 对应的官方配置，而不是照搬旧文章中的片段。

当前限制

1. Roster 是扁平结构，只包含 Lead 和直接成员，不是任意层级组织树。
2. 只有 Team Lead 能创建或中断 Teammate。
3. 成员名称不可修改，Provision 失败后也不会复用。
4. 多个成员可能共享同一 Checkout。Shell、格式化器、生成器和外部写入者仍可能发生冲突。
5. Team 工具刻意保持 Opt-in，避免普通会话承担更大的工具目录。
6. Experimental 子系统不能按稳定版本能力对待。

适用场景

Agent Teams 适合需要多个具名角色跨回合继续工作的任务，例如研究员与验证员、实现与 QA、数学建模与论文写作。一个有界 Subagent 调用就能完成的小任务，没有必要建立 Team。

更安全的实践是给成员划分互不重叠的责任与输出路径，由 Lead 汇总结果，并在最终回答前等待必要工作完成。

“持久组织”是另一个问题

公司式长期成员目录——跨越无关 Root Session、根据长期积累的领域知识路由任务——并不等于 Agent Teams。当前实验设计以一个 Lead Session 为根，主要解决一次协作过程中的持续成员与任务状态，而不是跨项目永久存在的组织。

常见问题

Agent Teams 是官方稳定功能吗？

它属于官方源码和官方文档，但包仍是 experimental、需显式启用，也不是稳定默认功能。

它和社区 agent-team 插件一样吗？

不一样。社区有多个名称相近的项目，比较前必须确认仓库所有者、包名与实际组合配置。

它能防止成员互相覆盖文件吗？

不能。共享任务板协调的是工作意图，不会锁住所有文件写入者；仍应使用独立输出路径或 Worktree。