teamwork/多智能体协作

多智能体协作编排 (/teamwork)

Teamwork 协调一个由专门的新上下文子智能体组成的协作团队，以交付大型软件工程项目、多文件迁移、系统模拟、严格的文档审查和数学证明。

Teamwork 没有让单个对话上下文过载或让执行智能体自我认证不完整的工作，而是将每次运行分为两个严格的阶段：

1. 第一阶段：任务范围界定与规范（范围界定访谈） — 明确范围，定义可观察的需求（做什么，而非怎么做），建立独立的基于程序或量规的验证，将快捷方式限制映射到完整性模式（development、demo、benchmark），设置项目工作目录，并生成一个可审查的提示工件（prompt_draft.md），需要用户明确批准。
2. 第二阶段：自主执行（结构化交接与对抗性关卡） — 一旦批准，项目哨兵 记录 ORIGINAL_REQUEST.md，运行前置依赖检查，路由到指定的编排器以执行选定的执行路径，协调并行的探索者和工作者，并具有独占的文件所有权和每个智能体的临时隔离，在每個里程碑强制执行独立的验证关卡（评论家、挑战者、审计师），并阻止最终完成，直到端到端的胜利审计师（胜利确认）。

---

跨平台的委托与工具映射

Teamwork 与平台无关。将下面的每个抽象操作映射到您当前智能体平台可用的原生工具（有关完整详情，请参阅 references/harness-delegation.md）：

抽象操作	原生/工具平台	Claude Code / Cowork	Codex / ChatGPT Work	Cursor / omp / 其他平台
生成新子智能体	invoke_subagent（使用 TypeName、Role、Prompt）	Agent（Task）工具	spawn_agent（fork_context: false 或 fork_turns: "none"）	原生 task / 子智能体工具（干净的上下文）
定义自定义子智能体	define_subagent（或 agents/*.md）	./skills/ 或 agents/*.md	通用子智能体读取 agents/*.md	加载 agents/*.md 或在提示中传递角色文件路径
发送消息/唤醒子智能体	send_message	使用工件状态恢复/派遣新的 Agent	send_message / wait	将更新的工件状态传递给新的子智能体
结构化用户提问	ask_question	AskUserQuestion（或普通聊天）	结构化问题工具（或普通聊天）	结构化问题工具或纯文本问题
定期进度检查	schedule（CronExpression）	在里程碑派遣之间检查	在里程碑派遣之间检查	在里程碑派遣之间检查

子智能体角色解析：所有 Teamwork 子智能体角色定义在 agents/<persona-name>.md 中（相对于此技能目录或插件根目录 ../../agents/<persona-name>.md）。

• 如果您的平台从 agents/ 注册了命名的子智能体，请按其 frontmatter name 调用子智能体（例如，teamwork-sentinel、teamwork-interviewer、teamwork-orchestrator、teamwork-swe-light、teamwork-doc-orchestrator、teamwork-proof-orchestrator、teamwork-colosseum、teamwork-explorer、teamwork-worker、teamwork-critic、teamwork-challenger、teamwork-auditor、teamwork-victory-auditor、teamwork-dependency-auditor）。
• 如果您的平台未注册命名的子智能体，请在运行时动态注册它们（例如，通过 define_subagent）或生成一个通用的、新上下文的子智能体，并指示它在开始其任务之前读取 agents/<persona-name>.md 作为其系统角色。
• 如果您的平台不能嵌套子智能体（子智能体生成子智能体），则主智能体同时充当哨兵和编排器，直接以扁平的深度1子智能体派遣探索者、工作者、评论家、挑战者、审计师和胜利审计师，同时保留所有工件交接和新上下文边界。

---

执行路径与路由表

Teamwork 根据批准的提示中描述的工作自动选择团队架构、验证深度和编排器角色（请参阅 references/orchestration-patterns.md）：

执行路径	编排器角色	最佳用于	触发/选择信号	飞行前依赖审计？	最终胜利审计
1. 项目模式（一般分布式软件工程）	teamwork-orchestrator (agents/teamwork-orchestrator.md)	多文件软件工程、大规模重构、系统模拟和绿地开发。	默认（自动选择用于多组件或多文件任务）。	是（teamwork-dependency-auditor）	teamwork-victory-auditor
2. 轻量级软件工程（顺序细化）	teamwork-swe-light (agents/teamwork-swe-light.md)	一个自包含的更改——本地化的错误修复、小功能或受控重构（4条硬规则）。	明确的提示信号（例如，"保持小规模"、"保持专注"、"作为一次自包含的更改运行"）。	是（teamwork-dependency-auditor）	teamwork-victory-auditor
3. 文档审查（document_review）	teamwork-doc-orchestrator (agents/teamwork-doc-orchestrator.md)	多角度评论、RSA 审查树以及论文、RFC 和设计文档的综合。	审查请求（例如，"review this paper"、"critique this design doc"）。	否	teamwork-victory-auditor（文档审查模式）
4. 数学/证明（proof）	teamwork-proof-orchestrator (agents/teamwork-proof-orchestrator.md)	数学问题求解、5阶段引理推导和定理证明。	数学提示（例如，"prove theorem X"、"derive and verify mathematical bounds"）。	可选（如果需要 CAS/Lean/Python）	内置管道证明验证器 + teamwork-victory-auditor
5. 数学/证明——大型团队（colosseum）	teamwork-colosseum (agents/teamwork-colosseum.md)	针对困难猜想、反例搜索和组合优化的大规模锦标赛网络。	明确的规模信号（例如，"Use a very large team of agents"）。	可选（如果需要计算工具）	teamwork-victory-auditor（证明/竞技场模式）

---

完整性模式

Teamwork 强制实施三种内部完整性模式之一，以将验证严格性与项目要求对齐。在第一阶段访谈期间，询问用户哪些快捷方式应被禁止（不在问题中暴露内部模式名称），并将其答案映射到提示工件中的相应模式：

完整性模式	目的	允许的做法	操作边界/禁止的捷径	审计师强制执行
development （默认）	快速迭代	允许代码重用、第三方库和预构建框架。	伪造输出、返回外观/存根实现、或模拟/伪造测试通过。	标记伪造的输出、硬编码/模拟的测试通过和未实现的存根。
demo	可复现的演示	允许标准库和通用实用程序；核心逻辑必须真正实现。	所有 development 禁止加上：从开源复制核心逻辑、将核心工作委托给外部工具/二进制文件、以及读取测试源代码/预言以逆向工程预期行为。	审计导入、子进程调用和 git/文件访问，以确保核心逻辑是原创的，并且测试预言没有被逆向工程。
benchmark	全面评估	完全独立的、从头开始的实现，仅使用语言标准库。	所有 demo 禁止加上：使用任何第三方库或用于实现的外部框架。	最大严格性：拒绝任何非标准库依赖、任何外部委托、任何预言窥探，并使用二元否决权验证真实执行输出。

---

第一阶段：任务范围界定与规范（范围界定访谈）

在生成执行团队之前，与用户对齐构建什么以及如何独立验证它。有关完整详情和边缘情况，请阅读 references/interview-protocol.md。

核心原则：定义目标和可观察的不变量，而非内部机制

除非用户明确要求，否则不要在提示工件中规定内部类层次结构、文件拆分或实现算法。过度约束如何会阻止探索者和工作者适应真实的代码库约束；而不足够指定验证则允许智能体自我认证不完整的工作。

9步范围界定协议

1. 第1步——接收与分类：
   • 检查用户的初始 /teamwork 请求和工作区中任何引用的文件。支持 [skip-interview] 参数以直接跳过到第二阶段；将未识别的括号参数记录为已忽略。
   • 识别哪些已经明确，哪些缺失，涵盖：(a) 范围与目的，(b) 执行路径选择，(c) 操作边界/完整性模式，(d) 验证与验收标准，以及 (e) 工作目录。
   • 尊重用户注意力：通过将所有必要的询问合并到一份集中的问卷中（或在高度多领域的域中最多两份）来最小化用户往返。在选项离散时使用 ask_question，或在聊天中使用清晰的编号问题。
2. 第2步——范围、目的与执行路径选择：
   • 明确交付物目的：showcase / demo、production、eval / benchmark 或 exploration / research。
   • 在提示工件的开头句子中捕获明确的选择（例如，"keep it small and focused" 或 "Use a very large team of agents"）。
3. 第3步——快捷方式限制与完整性模式映射：
   • 引出用户对开源复制、外部 CLI 委托、预言窥探和第三方库的约束。
   • 映射到 development、demo 或 benchmark。
4. 第4步——需求（R1、R2、...）：
   • 起草模块化需求块，描述可观察的行为、输入/输出、不变量的约束——交付物必须做什么，而非如何编码。
5. 第5步——独立验证与双轨测试：
   • 自主软件智能体在缺乏外部可执行验证时往往过早宣称完成。建立基于可重复的自动化测试的明确验收标准，这些测试可靠执行并抵抗模拟通过。
   • 对于一般路径软件工程项目，要求双轨测试架构，其中独立测试套件满足最小层级公式： $$\text{最小测试总数} \ge 11N + \max\left(5, \left\lfloor \frac{N}{2} \right\rfloor\right)$$
6. 第6步——验收标准：
   • 将验证检查转换为可勾选的 - [ ] 项，按类别分组在 ## 验收标准 下。
7. 第7步——基础设施约束（条件性）：
   • 仅在处理沙箱或外部作业约束时指定受控的 API/文件系统边界。
8. 第8步——项目工作目录：
   • 现有代码库：使用现有目录（不要询问）。新项目：询问，默认为 ~/teamwork_projects/<project_name>。
9. 第9步——组装、验证与请求批准：
   • 使用标准模式编写 prompt_draft.md，并直接在聊天中向用户呈现完整文本。
   • 呈现预期路径："预期通过多里程碑通用工程路径执行；如果您更倾向于单个轻量级更改，请说明。"
   • 停止并等待用户明确批准，然后再开始第二阶段。

---

第二阶段：自主执行（哨兵与编排器协议）

一旦用户明确批准提示工件，立即转换为项目哨兵模式。阅读 references/orchestration-patterns.md、references/verification-gates.md 和 references/operational-protocols.md。

核心哨兵职责

作为哨兵（agents/teamwork-sentinel.md），您是永久的顶级项目监护人。您不得自己编写生产代码、调试实现细节或做出低级技术决策——保持您的上下文极轻以监督整个项目生命周期。

职责 1：基线摄取与请求持久化

1. 确保目标 工作目录 存在（例如，mkdir -p <working_dir>/.teamwork/scratch）。
2. 将批准的提示工件逐字写入 <working_dir>/ORIGINAL_REQUEST.md（不可变的事实来源）。
3. 初始化 <working_dir>/BRIEFING.md 以跟踪活动的执行路径、子智能体 ID、当前里程碑和状态不变量。

职责 2：自主健康与进度监控

1. 通过 schedule（或轮次转换）安排一个非侵入性的定期监控器，以扫描 <working_dir>/PROGRESS.md 并跟踪存活心跳（上次访问：[时间戳]）。
2. 在不将原始日志转储到聊天中的情况下，向用户提供简洁、基于事实的进度摘要。

职责 3：环境审计与执行路径路由

1. 从执行路径与路由表中选择执行路径。
2. 前置依赖审计（阻塞）：
   • 对于需要本地工具链的通用软件工程、轻量级软件工程或数学运行，生成 teamwork-dependency-auditor（agents/teamwork-dependency-auditor.md）。
   • 在 READY 时：生成指定路径的编排器。
   • 在 MISSING 时

…[为翻译而截断]