Agent Swarm 执行机制

Agent Swarm 用多个 Agent 协作完成复杂任务。它适合可以拆分、需要并行探索或需要独立评审的工作，但会带来更高的成本、延迟和协调复杂度。

基本流程

用户任务
  ↓
Orchestrator 接收与校验
  ↓
Seed / 初始分析
  ↓
Proposal / 子任务方案
  ↓
Agent 分配与并行执行
  ↓
Review / 结果评审
  ↓
Retry 或 Reopen
  ↓
Aggregation / 聚合
  ↓
Patch、测试证据与最终报告

关键阶段

Seed

Seed 阶段用于建立任务的初始理解，包括目标、范围、仓库结构、约束、验收条件和潜在风险。Seed 不是最终方案，而是后续拆分的共同上下文。

Proposal

Proposal 将任务拆成可以独立执行或评审的子任务。好的拆分应减少文件冲突、明确输入输出，并为每个子任务指定验收条件。

Agent 执行

每个 Agent 根据分配的角色、模型、工具、工作区和预算执行任务。不同 Agent 是否共享工作区、上下文和 Secret，取决于具体部署配置。

Review

Review 应检查实际修改、测试证据、任务范围和潜在回归，而不是只评价自然语言总结。评审结果可以接受、要求重试、重新打开任务或升级人工处理。

Aggregation

Aggregation 将多个 Agent 的有效产出合并为最终结果。聚合器应处理重复结论、冲突修改、失败子任务和不完整证据。

Team Lead 的作用

Team Lead 负责协调和决策，不应只是转发其他 Agent 的总结。典型职责包括：

• 判断任务是否需要继续拆分；
• 处理 Agent 之间的冲突；
• 决定是否 retry 或 reopen；
• 检查最终工作区与总结是否一致；
• 标记无法验证的风险；
• 在需要时请求用户审批。

Team Lead 的通过不等于代码已经经过独立 CI 或人工 Review。

状态含义

具体状态名称可能随版本变化，应以当前界面和 API 为准。

Retry 与 Reopen

Retry 通常针对同一子任务的临时失败，例如模型超时、工具失败或结构化输出解析失败。Reopen 通常表示任务曾被认为完成，但后续发现结果不完整、测试失败或验收不通过。

无限重试会放大成本并重复相同错误。系统应设置最大次数、退避策略和失败分类。

工作区与冲突

多 Agent 可以使用共享工作区、独立分支或独立 Sandbox。无论采用哪种方式，都应明确：

• 修改何时对其他 Agent 可见；
• 文件冲突如何检测；
• 谁拥有最终合并权；
• 失败 Agent 的修改是否保留；
• 测试针对哪个最终状态运行。

上下文与记忆

Agent 不应默认获得整个历史记录。为了降低上下文成本，系统可能只传递任务摘要、相关文件、工具结果和共享状态。摘要丢失关键限制时，Agent 可能重复工作或偏离目标。

成本与预算

Swarm 的总成本通常由以下因素共同决定：

• Agent 数量；
• 每个 Agent 使用的模型；
• 上下文长度和输出长度；
• 工具调用次数；
• retry / reopen 次数；
• Sandbox 或 VM 运行时间。

提交任务前应设置模型、并发、轮数、Token、时间和资源上限。

完成标准

一个 Swarm 任务不能只因为所有 Agent 停止运行就被视为成功。最终结果至少应包含：

• 完整的修改文件列表；
• 冲突处理结果；
• 实际执行的测试与退出码；
• 未完成或失败的子任务；
• 人工介入记录；
• 最终可应用 Patch 或明确的无修改结论。