为什么Antfarm的「确定性工作流」比单个全能Agent更可靠？多智能体设计哲学思考

为什么Antfarm的「确定性工作流」比单个全能Agent更可靠？多智能体设计哲学思考

【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm

在 AI Agent 领域，"一个超级聪明的全能 Agent" 是许多人的第一反应。但 Antfarm 给出了相反的答案：它用确定性工作流编排一支多智能体团队——planner、developer、verifier、tester、reviewer 各司其职，按固定顺序执行，一条命令即可搭建。这篇文章从设计哲学角度拆解：为什么这种「分工 + 验证 + 确定性流水线」的方式，比单个全能 Agent 更可靠。

单Agent的三个可靠性陷阱

把一个大任务丢给单个 Agent，看似简单，实际会踩中三个坑：

Antfarm 的 README 用一句话点破了本质：确定性工作流意味着"Same workflow, same steps, same order. Not 'hopefully the agent remembers to test.'（同样的流程、同样的步骤、同样的顺序，而不是'希望 Agent 记得去测试'）"。

确定性流水线：像传送带一样跑任务

以 feature-dev 工作流为例，它的流程是写死的（定义见 workflows/feature-dev/workflow.yml）：

plan → setup → implement → verify → test → PR → review

• planner把任务拆成有序的用户故事（Story），每个故事必须能装进"一个上下文窗口"
• setup建分支、跑基线构建和测试
• developer逐个 Story 实现并写测试
• verifier逐条核对验收标准
• tester做集成/E2E 测试
• reviewer最后审 PR

关键设计是：每一步谁来做、按什么顺序、产出什么格式，全部在 YAML 里声明，而不是指望 Agent"到时候自己决定"。流程的确定性 + 每个 Agent 的专业性 = 结果的可预期性。

同样的思路也体现在 bug-fix 工作流里：triage → investigate → setup → fix → verify → PR，见 workflows/bug-fix/workflow.yml。

新鲜上下文：每个Agent都从零开始

Antfarm 基于 Ralph 循环模式：每个 Agent 每次都在全新会话中运行，上下文是干净的。跨会话的记忆不靠"聊天历史"，而是靠 git 提交和 progress 进度文件——这是记忆与状态分离的经典解法。

这就避免了单 Agent 最常见的退化：任务后半段质量断崖式下降。每个 Story 的实现者都是一位"精力满格"的开发者。

Agent互相验证：开发不给自己打分

这是多智能体设计中最核心的一条哲学。Antfarm 的 verifier（验证者）角色被明确设计为不可写代码（verification角色只有读和执行权限），它的"灵魂"设定写在 agents/shared/verifier/SOUL.md 里：

"You trust evidence, not claims. 'I did it' means nothing — passing tests and actual code mean everything." （你相信证据，不轻信声明。"我做了"毫无意义——通过的测试和真实的代码才有意义。）

它的检查逻辑（见 agents/shared/verifier/AGENTS.md）非常"较真"：

1. 先看真实的 git diff，而不是听 developer"声称"改了什么——diff 为空或只是版本号变更，直接打回
2. 逐条核对验收标准，跑完整测试套件
3. 检查有没有敏感文件（.env、密钥）被提交
4. 不合格就返回STATUS: retry和具体问题清单，developer 带着反馈重做，最多重试 2~3 次

单 Agent 模式下，写代码和验收代码是同一个"大脑"，自我确认偏差无法避免；多智能体模式把生产者与质检员物理隔离，可靠性来自结构而非自觉。

失败不沉默：自动重试与人工升级

单 Agent 失败往往"悄悄错下去"，而 Antfarm 的每个步骤都有明确的失败契约：

• expects: "STATUS: done"— 输出必须包含这个标记才算成功，否则触发重试
• max_retries: 2— 自动重试，且 verifier 的反馈会注入重试的 prompt
• escalate_to: human— 重试耗尽后升级给人，绝不静默吞掉失败

配合 Web 看板（antfarm dashboard），每一步的状态——done / running / pending / failed——都实时可见，运行状态由 SQLite 持久化，随时可以antfarm workflow resume从失败点恢复。

白盒设计：你能读到每个Agent的"脑回路"

Antfarm 刻意保持极简技术栈：YAML + SQLite + cron，没有 Redis、Kafka、容器编排。每个 Agent 的行为由三个 Markdown 文件定义：

• AGENTS.md— 职责、流程、边界（"什么不该做"）
• SOUL.md— 人格与行事风格
• IDENTITY.md— 名字与角色

这意味着在运行任何 Agent 之前，你都能通读它将被如何指示——对要在自己机器上执行代码的 AI 团队来说，这种透明本身就是可靠性的一部分。

如何构建自己的确定性工作流

如果你会写 prompt，就能定义自己的工作流：

1. 参考官方指南 docs/creating-workflows.md
2. 在workflows/下新建目录，编写workflow.yml和 agents 人格文件
3. 角色（role）决定工具权限：analysis只读、coding可写、verification只读可执行——权限隔离是多智能体可靠性的底层保障
4. 运行antfarm workflow install <id>即可上线

官方文档给了四条值得记住的设计原则：

• 输入模板要具体，模糊的输入只会得到模糊的结果
• 每个步骤都要声明输出格式
• 一定要加验证步骤——verify → retry 循环能自动抓住大多数质量问题
• 一个 Agent 只干一件事：不要在同一 Agent 里混合"诊断"和"修复"

小结：可靠性来自结构，而非模型

回到文章开头的问题——为什么确定性工作流比单个全能 Agent 更可靠？

Antfarm 的答案很朴素：把"不可靠"交给结构去兜底。模型会犯错，但当流程是确定的、验证是独立的、失败是可见的，错误就变成了可重试、可追踪、可升级的事件——这正是多智能体设计哲学的精髓所在。

【免费下载链接】antfarmBuild your agent team in OpenClaw with one command.项目地址: https://gitcode.com/gh_mirrors/antf/antfarm