Antfarm 模式：编排专业化智能体团队实现复合工程
多智能体工作流如何将复合工程从理论变为实践
太长不看版
复合工程承诺带来 300-700% 的生产力提升，但大多数团队实际上难以做到。秘诀是什么？构建编排的 AI 智能体团队，其中每个智能体都有特定的角色、全新的上下文和清晰的交接。
Antfarm 通过以下方式使其变得实用：
- 专业化智能体（规划者、开发者、验证者、测试者、审查者）
- 防止退化的全新上下文
- 自动重试和升级
- 你真正可以信赖的确定性工作流
结果是？功能在几小时内而不是几周内发布，bug 更少，人工劳动更少。
在本文中，我将介绍你今天就可以使用的真实模式——包括具体的 YAML 示例、在生产环境中运行这些工作流的经验教训，以及诚实地看待困难之处。
我曾经经历过
几个月前，我试图用单个 AI 智能体构建一个功能。开始时很顺利——生成代码、运行测试、取得进展。但随着对话的增长，事情变得……混乱。
智能体会：
- 忘记早期的决定
- 引入它已经修复过的回归问题
- 对修改了哪些文件感到困惑
- 因为”快完成了”而在测试上偷工减料
我花更多时间照看 AI 而不是实际构建。复合工程的承诺——300-700% 的速度提升——感觉很遥远。
然后我发现了多智能体模式。这种转变是天壤之别。
我没有让一个通才智能体做所有事情，而是拆分了工作：
- 一个智能体规划和分解
- 另一个实现
- 第三个验证
- 第四个测试
- 最后一个审查
每个都获得全新的会话、清晰的期望和明确的验收标准。
区别是什么？第一个功能在45 分钟内发布，零人工干预。那一刻我知道这是未来。
为什么多智能体胜过单智能体
在深入 Antfarm 之前，让我们谈谈为什么专业化对 AI 智能体很重要。
上下文退化问题
LLM 有一个记录良好的问题：随着对话变长，它们开始失去重点。你见过这种情况——50 条消息后，模型开始产生幻觉，忘记你们达成的一致，犯粗心的错误。
Ralph Loop 通过每次迭代重新开始解决了这个问题。但使用单个智能体在一个长会话中做所有事情，你最终还是会撞墙。
Antfarm 的洞察： 每个步骤都有自己的干净会话。除了 git 和进度文件外没有共享内存。没有上下文腐烂。智能体只看到它此刻需要看到的内容。
专业化强制执行纪律
当一个智能体试图同时实现和验证时，它会被诱惑：
- 在没有彻底检查的情况下将自己的工作标记为”完成”
- 跳过边界情况因为”可能没问题”
- 降低自己的标准以满足截止日期
使用独立的智能体，验证者的唯一工作就是说”这不够好”（如果确实不够好）。测试者为发现失败模式而生。审查者在所有故事中应用一致的标准。
这不仅仅是关于质量——这是关于反馈完整性。每个步骤都为下一个提供诚实、不受损害的反馈。
并行化而不混乱
在传统团队中，并行工作会导致合并冲突、集成地狱和沟通开销。使用 Antfarm，每个智能体都在自己的分支式隔离中工作，然后将验证过的工件传递给下游。
你可以并行运行多个故事（如果它们是独立的），工作流确保干净的交接。不再有”等待后端”，因为后端智能体已经完成了。
真实工作流：功能开发
让我们看看 Antfarm 附带的 feature-dev 工作流：
steps:
- id: plan
agent: planner
input: |
将这个功能请求分解为离散的、可实现的故事。
每个故事必须有清晰的验收标准。
回复 STATUS: done 和 STORIES: [带标准的故事列表]
- id: setup
agent: setup
input: |
为实施准备工作区。
安装依赖项，配置环境。
准备就绪后回复 STATUS: done。
- id: implement
agent: developer
input: |
实现 {{plan}} 中下一个未完成的故事。
遵循项目的架构模式。
在标记完成前运行类型检查和 lint。
回复 STATUS: done 和 FILES_CHANGED: [列表]
- id: verify
agent: verifier
input: |
根据 {{plan}} 中的验收标准验证实现。
代码是否真的满足要求？
如果验证通过回复 STATUS: done，否则回复 STATUS: retry 并附带反馈。
- id: test
agent: tester
input: |
运行项目的测试套件。
为新功能添加回归测试。
确保所有测试通过。
测试通过后回复 STATUS: done。
- id: pr
agent: developer
input: |
为变更创建拉取请求。
包括摘要、测试说明和截图（如适用）。
回复 STATUS: done 并附带 PR URL。
- id: review
agent: reviewer
input: |
审查 PR 的代码质量、安全性、性能。
请求变更或批准。
回复 STATUS: approved 或 STATUS: changes-requested 并附带反馈。这就是行动中的复合工程——每个步骤都有清晰的交接、验收标准和自动验证。在前一个步骤成功之前，没有步骤会前进。
人工接触（因为我们还没到那一步）
让我诚实一点：这些工作流不是魔法。我运行过足够多次，知道它们在哪里发光，在哪里绊倒。
运作完美的：
- 具有清晰规范的直接功能
- 具有可重现步骤的 bug 修复
- 针对已知边界情况的测试生成
- 文档更新
仍然挣扎的：
- 探索性工作（智能体需要的上下文比你提供的更多）
- 复杂的架构决策（需要人工判断）
- 训练分布之外的新颖问题
- 需要真正创造力而非模式匹配的任何事情
最佳点？规范明确、有界任务。你能将工作分解为离散的、可验证的故事越多，Antfarm 的表现就越好。
我的经验法则： 如果你能用一个清晰的句子描述完成状态，Antfarm 可能就能构建它。
设计你自己的工作流程
你不仅限于捆绑的工作流。Antfarm 的力量在于为你的特定需求定义自定义智能体团队。
从简单开始
不要试图在第一天就构建一个 7 步工作流。从以下开始：
plan→implement→review
让它端到端工作。然后添加 verify，然后 test，然后 pr。每个步骤都应该证明它的价值。
角色很重要
每个智能体的 AGENTS.md 定义其个性和约束：
# 验证者智能体
你是一位持怀疑态度的高级 QA 工程师。你的工作是在工作真正完成之前说"不"。
## 指南
- 检查计划中的每个验收标准
- 如果可能，自己运行代码
- 验证边界情况已处理
- 没有证据不接受"在我的机器上可以工作"
## 输出格式
STATUS: done | retry
FEEDBACK: [详细的、具体的反馈（如果重试）]清晰、有界的角色帮助 AI 保持角色并做你需要的工作。
交接是一切
魔法在于 {{plan}} 和 {{verify}} 引用——每个步骤接收上一步骤的实际输出，而不仅仅是摘要。这创建了一个证据链，确保没有东西在翻译中丢失。
如果规划者说”使用 bcrypt 实现用户认证”，验证者会看到实际的实现并可以检查：“真的使用了 bcrypt 吗？密码加盐了吗？有限速吗？”
这不仅仅是自动化——这是可审计、可重复的工程。
重要的指标
你如何知道你的复合工程设置是否真的有效？跟踪这些：
| 指标 | 目标 | 为什么重要 |
|---|---|---|
| 每个故事的周期时间 | < 30 分钟 | 测量实际速度 |
| 一次性成功率 | > 70% | 高率 = 好的规范和智能体 |
| 人工接触率 | < 20% | 低率 = 智能体理解标准 |
| 升级率 | < 5% | 低率 = 工作流设计良好 |
如果你的升级率很高，你的工作流太复杂或者你的智能体需要更好的提示。如果一次性成功率低，你的验收标准模糊。
更大的图景：这就是我们扩展的方式
我确信多智能体编排是在大规模实现真正复合工程的唯一方法。单智能体工作流会达到平台期。纯人工团队会遇到人数限制。但智能体团队？
- 水平扩展：添加更多智能体，而不是更多人
- 24/7 工作：没有疲劳，没有上下文切换
- 一致的质量：每个步骤都遵循相同的护栏
- 廉价迭代：重新生成一个故事只需几分钱
这不是取代工程师——这是解放工程师，使他们摆脱编写样板代码、编写基本测试和审查琐碎变更的低杠杆工作。
获胜的工程师将是那些能够设计、编排和改进这些智能体系统的人——而不是那些自己编写最多代码的人。
这就是复合工程思维。
今天开始
如果你想尝试：
- 安装 Antfarm（查看他们的 README）
- 运行示例：
antfarm workflow run feature-dev "添加暗模式切换" - 查看仪表板：http://localhost:3333
- 调整智能体角色以匹配你的项目
- 发布你的第一个 AI 构建功能，零实现工作
一旦你感受到智能体团队的速度——就是……有效……就无法回头了。
进一步阅读
我是 Vinci Rufus，探索智能体 AI 和复合工程的交叉点。我撰写关于构建可靠、高速 AI 系统的内容。在 Twitter @areai51 上关注我，或在 vincirufus.com 阅读更多内容。