怎么搭建 Agent Harness

Anthropic 总结了 5 种从简单到复杂的 Agent 架构模式。原则只有一条：能用简单的就别用复杂的。

核心原则

在看具体模式之前，先记住 Anthropic 的忠告：

"只在确实能改善效果时才增加复杂度。"

— Building Effective Agents

很多团队犯的第一个错误就是上来就搞最复杂的架构。大多数场景，一个好的提示词 + 简单的工作流就够了。

5 种架构模式（从简单到复杂）

模式一：提示词链（Prompt Chaining）

一句话：把一个大任务拆成几步，一步一步做，每步之间有质量检查。

输入 → 第一步AI处理 → 检查点 → 第二步AI处理 → 检查点 → 输出

适合场景：

• 生成商品文案（先写初稿 → 检查是否合规 → 润色排版）
• 写课程脚本（先列大纲 → 展开每个章节 → 统一风格）
• 翻译校对（先翻译 → 检查专业术语 → 调整语感）

效果数据：比单次调用准确率提升 30-50%（Anthropic 实测）

老板怎么理解：就像你让员工写方案，不是让他一口气写完交上来，而是先写大纲给你看，确认方向对了再写细节。

什么时候用这个

你的任务可以清晰地拆成 2-4 个步骤，每步的输出格式和质量标准都很明确。这是最常用的模式。

模式二：路由分发（Routing）

一句话：先判断任务类型，然后分发给不同的专家处理。

输入 → 分类判断（用便宜模型）
       ├── 简单问题 → 便宜模型处理
       ├── 复杂问题 → 强力模型处理
       └── 敏感问题 → 转人工

适合场景：

• 客服系统（简单咨询 AI 答，退款投诉转人工）
• 内容审核（正常内容通过，可疑内容人工复查）
• 订单处理（常规订单自动处理，异常订单人工确认）

效果数据：成本降低 40-60%（简单任务不用浪费贵的模型）

老板怎么理解：就像公司前台，简单的问题前台直接答，复杂的转给相关部门，投诉直接转给经理。

模式三：并行处理（Parallelization）

一句话：同一个任务让多个 AI 同时做，或者把任务拆成独立的子任务并行处理。

两种玩法：

玩法 A — 分工并行：

大任务 → 拆成3个子任务
         ├── AI-1 处理子任务A
         ├── AI-2 处理子任务B  （同时进行）
         └── AI-3 处理子任务C
         → 合并结果

玩法 B — 投票表决：

同一个任务 → 3个AI各做一遍
              ├── AI-1 的结果
              ├── AI-2 的结果  → 选最好的 / 取共识
              └── AI-3 的结果

适合场景：

• 内容审核（多个 AI 同时审，有一个说有问题就标记）
• 竞品分析（分别分析价格、功能、口碑，最后合并）
• 代码审查（分别检查安全性、性能、可读性）

老板怎么理解：玩法 A 像分工合作，一个人查价格一个人查功能。玩法 B 像让三个人分别写方案，最后选最好的。

模式四：编排-工人模式（Orchestrator-Workers）

一句话：一个"经理 AI"负责拆解任务和分配工作，多个"工人 AI"负责执行。

经理AI（看全局、拆任务）
├── 派工人A做第一件事
├── 看结果，决定下一步
├── 派工人B做第二件事
├── 根据情况调整计划
└── 汇总所有结果

跟模式三的区别：模式三的子任务是提前定好的，模式四的子任务是"经理"根据情况动态决定的。

适合场景：

• 复杂的数据分析（先看有什么数据，再决定怎么分析）
• 多文件代码修改（先理解需求，再决定改哪些文件）
• 市场调研（先确定调研方向，再分配具体调研任务）

老板怎么理解：就像一个项目经理，不是一开始就把所有任务分好，而是边做边根据情况调整计划。

模式五：生成-评估循环（Evaluator-Optimizer）

一句话：一个 AI 负责干活，另一个 AI 负责挑毛病，反复迭代直到质量达标。

生成AI → 产出初稿
              ↓
评估AI → 打分 + 反馈
              ↓
         达标？→ 是 → 输出
              → 否 → 生成AI根据反馈修改 → 再评估...

为什么不让同一个 AI 自己检查自己？

Anthropic 明确发现：自我评估存在系统性偏差——AI 总是倾向于给自己的作品打高分。必须用独立的 AI 来评估。

适合场景：

• 高质量文案（写 → 审 → 改 → 再审）
• 翻译润色（翻 → 检查准确性 → 调整 → 再检查）
• 方案设计（写方案 → 评估可行性 → 改进 → 再评估）

老板怎么理解：就像让一个员工写方案，另一个员工负责挑毛病，来回改直到满意。不是自己检查自己，是互相检查。

进阶：三 Agent 架构

当任务特别复杂（比如从零开始做一个产品）时，Anthropic 验证了一种 三 Agent 架构：

规划Agent（Planner）
├── 把一句话需求 → 拆成详细的产品说明书
│
生成Agent（Generator）
├── 按说明书一个功能一个功能地做
├── 每做完一个，自测一下
│
评估Agent（Evaluator）
├── 独立检查质量
├── 用"模拟用户"的方式测试（不是看代码，是像真人一样操作）
├── 不达标就打回重做

关键设计：

• 生成 Agent 和评估 Agent 在开工前要 谈好验收标准（"冲刺合约"）
• 每个功能独立做、独立测、独立验收
• 评估 Agent 用浏览器自动化测试，像真人一样操作

来源：Anthropic《Harness Design for Long-Running Apps》

选哪种模式？

你的任务是什么样的？

简单、步骤明确
└── 模式一：提示词链

需要分类处理
└── 模式二：路由分发

多个独立子任务
└── 模式三：并行处理

任务复杂、步骤不确定
└── 模式四：编排-工人

质量要求极高
└── 模式五：生成-评估循环

以上都需要？
└── 三 Agent 架构（组合使用）

Anthropic 的忠告

"很多团队一开始就上框架（LangChain、AutoGen 等），其实大多数场景用 API 直接调用 + 几行代码就够了。如果你要用框架，一定要理解底层原理，别当黑盒用。"

来源：Building Effective Agents

工具设计的反直觉发现

Anthropic 在工具设计方面有一个重要发现：

"在工具上投入的精力要跟在提示词上一样多。"

具体建议：

• 工具越少越好：Vercel 砍掉 80% 的工具后 Agent 反而更强了。超过 10 个功能重叠的工具，Agent 就会犯迷糊
• 防呆设计（Poka-yoke）：让 Agent 更难犯错。比如强制用绝对路径而不是相对路径
• 描述要像写提示词：工具的说明文档要包含使用示例、边界情况、输入要求

OpenAI 的两种编排策略

OpenAI 在他们的 Agents SDK 中提出了两种 Agent 编排方式：

策略	怎么做	适合
AI 自主编排	让 Agent 自己决定调用什么工具、委托给谁	灵活、适合开放式任务
代码控制编排	用程序逻辑控制 Agent 的执行流程	可预测、适合标准化流程

推荐做法：生产环境优先用代码控制（可预测、可调试），只在必要时才让 AI 自主决策。

实际搭建的技术选型

如果你的技术团队要动手搭建，以下是 2026 年主流的框架选择：

框架	出品方	特点	适合
直接用 API	—	最简单、最可控	场景简单，团队强
OpenAI Agents SDK	OpenAI	内置 Session、Guardrail、Tracing	用 OpenAI 模型为主
LangGraph	LangChain	状态图模型，有断点续传	复杂多步骤流程
Microsoft Agent Framework	微软	企业级，与 Azure 集成	微软技术栈企业

Anthropic 的建议

"先用 API 直接调用。大多数模式只需要几行代码。如果用框架，确保你理解底层在做什么——移入生产时要减少抽象层。"

一句话总结

从简单开始，只在需要时加复杂度。5 种模式覆盖 90% 的场景，选对了事半功倍，选错了反而更差。

下一篇：Agent Harness 的核心组件 — 一个完整的 Harness 到底包含哪些部分？