译者说明：本文译自 Anthropic 官方工程博客。原文面向系统开发者，但五种模式描述的是任务组织方式，不依赖编程即可借鉴。文末附研究咨询场景的对照。

构建有效的智能体

智能体 vs 工作流：核心区别

Anthropic 在架构上区分了两种做法：

工作流（Workflows）是这样的系统：大模型和工具沿着预先定义好的代码路径运作。它们为定义明确的任务提供可预测性与一致性。

智能体（Agents）是这样的系统：大模型动态地指挥自己的流程和工具使用，自主掌控如何完成任务。当需要灵活性和模型驱动的决策、且要规模化时，它们表现出色。

基础构件：增强版大模型

每个智能体系统都始于一个被增强过的大模型——增强手段包括检索、工具、记忆。

现代模型能够主动使用这些能力：自己生成搜索查询、选择合适的工具、判断该保留什么信息。

---

五种工作流模式

一、提示词串联（Prompt Chaining）

把任务分解成顺序执行的步骤，每次模型调用处理上一步的输出。可以在中间插入程序化的检查点（「门」）来验证中间结果。

适合：能被干净地分解为固定子任务的任务，且用延迟换准确率是划算的。

例子：先生成营销文案再翻译；或先写好文档大纲并校验，再展开成全文。

二、路由（Routing）

对输入分类，然后导向专门的后续处理。这实现了关注点分离，并能针对不同的输入类别分别优化。

适合：包含明显不同类别、且分别处理更好的复杂任务——前提是分类本身足够可靠。

例子：把不同类型的客服问题导向对应流程；或把简单问题路由给高效的模型、复杂问题给能力更强的模型。

三、并行化（Parallelization）

多个模型同时处理任务，输出再汇总。有两种变体：

• 分段（Sectioning）：把任务拆成独立的子任务并行跑
• 投票（Voting）：同一个任务跑多次，获得多样的输出

适合：通过并行获得速度，或通过多重视角获得信心。

例子：并行运行防护规则（一个负责筛查、一个负责回应）；自动化性能评估；用多个不同的提示词审查同一份代码的漏洞。

四、协调者—工作者（Orchestrator-Workers）

一个中心模型动态地拆解任务、分派给工作模型、再综合结果。

它与并行化的区别在于：子任务是动态确定的，不是预先划好的。

适合：子任务无法事先预测的复杂任务。

例子：需要跨多个文件改动的编码任务；需要从多种来源分析信息的检索任务。

五、评估者—优化者（Evaluator-Optimizer）

一个模型生成回应，另一个模型提供评估和反馈，形成循环。

适合：有清晰评估标准、且迭代精炼能可衡量地改善输出的任务。

例子：有微妙要求的文学翻译；需要多轮分析的复杂检索。

---

自主智能体

智能体独立运作：由人类发起任务，然后智能体自行规划和执行，中途可能暂停以获取反馈。

实现方式通常很直接——

本质上就是大模型基于环境反馈、在循环中使用工具。

适合：开放式问题——你无法预测需要哪些步骤，也无法硬编码一条固定路径。

例子：跨多个文件解决复杂问题的编码智能体；自主完成任务的计算机操作智能体。

---

核心忠告：优先保持简单

整篇文章最重要的一句：

在大模型领域，成功不在于构建最精巧的系统，而在于为你的需求构建正确的系统。

从简单的提示词开始，把它彻底优化好之后，再考虑增加复杂度。智能体系统**「往往是用延迟和成本换取更好的任务表现」**——这个取舍值得仔细掂量。

什么时候不该用智能体

对许多应用来说，优化单次模型调用、配上检索和上下文示例，通常就够了。

三条原则

1. 保持简单
2. 优先透明——显式地展示规划步骤
3. 精心设计智能体与环境的接口——通过完善的工具文档与测试

结论是：

只有当更简单的方案不够用时，才加入多步智能体系统。

---

译后附记：换成研究咨询的说法

五种模式描述的是任务该怎么组织，跟会不会编程无关。对照如下：

串联：分步做，每步设检查点

别让它一步跑完整条链。

❌ 「读这 40 份访谈，编码，然后写出发现章节」 ✅ 分三步：① 转录并校对术语 → ② 按框架编码 → ③ 基于编码结果写发现

每一步的输出你都能验一次。中间错了，你在第二步就发现，而不是在成稿时。

路由：先分类，再分流

一批混杂的材料（有访谈、有问卷开放题、有客户提供的内部文档），不要用同一套提示词处理。

先分类，每类走各自的处理方式。原文提醒的前提很重要：分类本身要可靠——如果连你自己都分不清某份材料属于哪类，就别指望这一步。

并行—投票：同一件事跑多次

这是研究工作里最被低估的一招。

对判断性的任务——「这段发言反映的核心诉求是什么」——跑三次，看三次结果是否一致。

• 三次一致 → 这个判断比较稳
• 三次不一致 → 这里本来就是模糊的，需要你自己看

这比让它跑一次然后你通读一遍，效率高得多，因为它直接告诉你该看哪几处。

评估者—优化者：生成完再换个身份评审

写完提案初稿，换一个对话、以评审的身份来挑毛病，而不是让同一个对话自我表扬。

（提案场景的具体做法见写提案：行业标准方法论里的 Red Team 提示词。）

最重要的还是那句

「只有当更简单的方案不够用时，才加入多步系统。」

大多数研究咨询任务，一次设计良好的提问 + 必要的背景材料，就已经够了。先把提示词写好，再谈流程。 反过来做，你会得到一套复杂但不好用的东西。