智能体Agent与工作流构建实战指南：从选型决策到高效实施

本文从Anthropic的文章《Build effective agents》出发，为构建高效的工作流、Agent提出实战指南。我在保留原文精华的基础上增强了三个核心方面：

核心内容

1.技术选型指南：明确工作流/Agent选用标准。

2.设计模式解析：通过实际业务场景展示复杂工作流模式的应用。

3.实践要点扩展：增添详细的实施建议和操作要点，将理论转化为可执行方案。

本文适合AI Agent技术管理者、开发者、产品经理及爱好者阅读，通过实践层面的指导，帮您实现更合理的方案与更高效的实施。

文章概览

1. Agent概述

1.1 什么是Agent？

"Agent"有多种定义方式。部分客户将其视为完全自主系统，能在较长时间内独立运行，使用各种工具完成复杂任务。也有人用此术语描述更固定的、预定义的工作流。Anthropic将这些变体归类为类Agent系统，但在工作流和智能体间做了重要区分：

1.2 Workflow V.S Agent

在附录1("Agent实战")中，Anthropic描述了客户在使用这类系统时发现特别有价值的两个应用领域。

2. 何时使用Agent

2.1 简单性原则：适用场景评估

Anthropic强烈建议：在构建LLM应用时，寻找尽可能简单的解决方案，只在必要时增加应用复杂性。

关键权衡：类Agent系统通常以延迟和成本为代价换取更高性能，应谨慎评估这种取舍。

复杂性增加的指导原则：

• 选择工作流：当任务明确定义，需要可预测性和一致性
• 选择Agent：当任务需要灵活性和模型驱动的动态决策

重要提示：对许多应用而言，优化单个LLM调用（通过检索增强和上下文示例）通常已足够有效。

3. 何时、如何使用“Agent框架”

3.1 框架使用的权衡考量

开发框架虽然便捷，但常存在过度抽象问题，使底层提示词和LLM调用被隐藏。这导致两个主要风险：

• 使用框架开发的Agent系统难以有效调试
• 简化的搭建流程使开发者容易过度增加系统复杂性

3.2 实用开发建议

Anthropic建议采取渐进式开发方法：

• 优先直接使用LLM API：大多数模式可通过几行代码实现
• 深入理解框架底层：如选择框架，确保理解其内部工作机制
• 避免错误假设：对框架底层工作原理的误解是项目失败的常见原因

“我们建议开发者直接使用LLM API：许多模式可以用几行代码实现。如果你使用框架，请确保理解底层代码。对底层工作的错误假设是客户错误的常见来源。”

参考Anthropic的cookbook[1]获取示例实现。

4. 类Agent系统设计模式

本节探讨生产环境中常见的类Agent系统模式。Anthropic从基础构建模块——增强型大语言模型(LLM)开始，逐步增加复杂性，从简单组合工作流到自主Agent。

4.1 增强型LLM模式

定义：类Agent系统最基础的模块是"增强的LLM"，即具备检索、工具使用和记忆等功能的语言模型。Anthropic当前的模型能够主动使用这些功能——生成搜索查询、选择合适工具以及确定需要记忆的信息。

增强型LLM

工程实现的关键要点：

• 为特定应用场景定制增强能力
• 确保为LLM提供简单、文档完善的接口

虽然实现这些增强功能的方法很多，一种推荐方式是通过Anthropic最近发布的模型上下文协议[2](MCP)，该协议允许开发者通过简单的客户端实现与不断扩展的第三方工具生态系统集成。

4.2 工作流模式

4.2.1 提示链

定义：提示链将任务分解为一系列有序步骤，每个LLM调用处理前一个调用的输出。可在任何中间步骤添加程序检查（"门控"）以确保流程保持在正确轨道上。

提示链工作流

适用场景：

• 任务可以轻松且清晰地分解为固定子任务时
• 主要目标是通过牺牲延迟来提高准确性，使每个LLM调用处理更简单的子任务

应用示例：

• 生成营销文案，然后将其翻译成不同的语言。
• 编写文档大纲，检查大纲是否符合特定标准，然后基于大纲撰写文档。

4.2.2 路由

定义：路由工作流对输入进行分类并将其引导到专门的后续任务。这种工作流实现关注点分离，并构建更专门化的提示。不使用路由时，为某一类输入优化可能会降低其他类型输入的处理效果。

路由工作流

适用场景：

• 复杂任务包含明显不同类别需要单独处理
• 分类可由LLM或传统分类模型/算法准确完成

应用示例：

• 引导不同类型客户服务查询（一般问题、退款请求、技术支持）进入不同的下游流程、提示和工具。
• 将简单/常见问题路由到较小模型（如Claude 3.5 Haiku），将困难/不常见问题路由到更强大模型（如Claude 3.5 Sonnet），优化成本和响应速度。

4.2.3 并行化

定义：并行化工作流让LLM同时处理多个任务，并通过程序化方式聚合输出。分为两种关键形式：

• 任务拆分（Sectioning）：将任务拆分为独立的子任务并行运行
• 投票（Voting）：多次运行相同任务以获得不同的结果

并行化工作流

适用场景：

• 当拆分的子任务可以并行处理以提高速度
• 需要多种视角或不同尝试来获得更高置信度的结果时
• 复杂任务涉及多种考虑因素时，由独立LLM调用分别处理各因素效果更佳。

应用示例：

• 任务拆分（Sectioning）
• 安全防护机制：一个模型处理用户查询，另一个筛选不合规内容，比单模型同时处理两项功能效果更好。
• 自动化评估LLM性能：设置多个并行分支，评估模型在不同方面的表现。


• 投票（Voting）
• 代码漏洞审查：多个并行LLM分支审查代码并标记问题。
• 内容审核：并行评估内容合规性，不同提示专注于不同评估维度，通过差异化投票阈值平衡误报率与漏报率。

应用案例：内容审核系统

假设我们正在构建一个社交媒体平台的内容审核系统，需要评估用户发布的以下内容是否适当：

用户发布内容示例

"这些政客都是垃圾，应该被扔进海里喂鲨鱼。大家都应该去抗议这个荒谬的新政策，让他们知道我们的愤怒！"

实现方案：

1、并行LLM提示（专注不同维度）

• 提示1：评估暴力内容
• 提示2：评估仇恨言论
• 提示3：评估不文明用语
• 提示4：评估合法政治表达
• 提示5：评估煽动抗议

2、差异化投票阈值设置

1. **暴力威胁**：低阈值（高敏感度）

• 提示1为"是"→内容立即标记
  
• 理由：潜在危害大，宁可误报也不能漏报
  

1. 仇恨言论：中等阈值

• 提示2和提示3都为"是"→内容标记
  
• 理由：需更多证据确认真正仇恨言论
  

1. 政治表达：高阈值（宽容度高）

• 提示4为"是"且提示1、2不为"是"→允许内容
  
• 理由：保护合法政治表达，避免过度审查
  

3、决策流程示例

1. **并行评估结果**：

• 提示1（暴力）："是"（提到"扔进海里喂鲨鱼"）
  
• 提示2（仇恨）："否"（针对政客非受保护群体）
  
• 提示3（不文明）："是"（使用"垃圾"等贬义词）
  
• 提示4（政治表达）："是"（政策批评）
  
• 提示5（煽动抗议）："是"（鼓励和平抗议）
  

1. 规则应用：

• 暴力威胁阈值触发（提示1为"是"）
  
• 政治表达规则也满足
  
• 系统标记为"边缘案例"，转人工审核
  

系统优势：平衡误报和漏报

这种多方面并行评估系统能够：

1. **减少漏报**：低阈值捕获严重违规（如明确暴力威胁）
2. **减少误报**：多角度评估避免过度审查合法内容
3. **细粒度分析**：识别具体问题方面，非简单二分法
4. **差异化风险应对**：对不同类型违规设置不同敏感度

这种并行投票系统能同时考虑内容多个维度，根据不同维度的严重性设置差异化决策标准，实现更平衡、更细致的内容适当性评估，特别适合处理复杂边界案例。

4.2.4 编排者-工作者

定义：在编排者-工作者工作流中，编排者（LLM）动态分解任务，将其委派给工作者LLM，并综合其结果。

编排者-工作者工作流

适用场景：

• 适合无法预测所需子任务的复杂任务
• 与并行化的关键区别在于灵活性——子任务不是预定义的，而是由编排者根据任务输入动态确定

应用示例：

• 需要对多个代码文件进行编辑的编码项目
• 涉及从多个来源收集和分析信息的搜索任务

应用案例：医疗研究助手

假设我们正在构建一个医疗研究助手，研究人员输入了以下查询：

用户查询

"我需要了解最近三年内关于长新冠与认知障碍关联的研究结果，特别是那些包含临床试验数据的研究。"

编排者-工作者工作流实现

1. 编排者规划阶段
   编排者LLM接收查询并制定搜索计划：
   搜索计划：
   
1. 识别关键搜索术语和相关概念
2. 确定需要搜索的最佳来源
3. 为每个来源设计特定搜索策略
4. 分配多名工作者执行不同来源的搜索
5. 汇总和综合所有发现的信息
6. 确定是否需要进一步搜索
7. 准备最终报告


2. 工作者执行阶段
   

编排者将任务分配给多个专门的工作者LLM：

工作者1：医学文献搜索

• 任务：在PubMed和医学期刊数据库中搜索长新冠与认知障碍相关论文
• 搜索条件：发表于2022-2025年间，包含临床试验数据
• 工具：使用API接口查询医学数据库
• 产出：找到15篇相关论文，包含初步结果摘要

工作者2：研究机构报告搜索

• 任务：搜索CDC、WHO、NIH等机构发布的长新冠研究报告
• 搜索条件：关注认知障碍相关发现
• 工具：机构网站API和网页抓取
• 产出：找到3份官方报告和2个正在进行的研究项目

工作者3：临床试验数据库搜索

• 任务：在http://ClinicalTrials.gov等数据库中搜索相关临床试验
• 搜索条件：长新冠与认知功能相关，已完成或有初步数据
• 工具：临床试验注册数据库API
• 产出：识别7个相关临床试验，包括3个有初步结果的试验

工作者4：医学会议与预印本资料搜索

• 任务：在研究预印本服务器和近期会议记录中搜索
• 搜索条件：最新未正式发表的研究
• 工具：预印本服务器API和会议数据库
• 产出：找到5篇预印本论文和2个会议演讲

1. 信息分析与综合

编排者接收所有工作者的搜索结果，然后：

1. 识别重复信息：消除不同来源的重复研究
2. 评估证据质量：按照研究设计、样本量、期刊影响因子等标准评估每篇研究
3. 识别共同主题：分析跨多个研究的一致性发现
4. 发现研究差距：识别缺乏研究的领域
5. 权衡相互矛盾的结果：评估不同研究之间的差异原因

1. 动态迭代（可选）

编排者可能发现需要进一步信息：

• "注意到大多数研究未考虑年龄分层效应，需要专门搜索老年群体中的长新冠认知影响"
• 分配工作者5进行补充搜索，聚焦老年人群研究

1. 最终报告生成

编排者综合所有信息生成最终报告：

• 总结主要发现
• 按证据强度和一致性水平组织信息
• 提供研究限制和未来研究方向
• 附上所有来源的完整引用

工作流优势

1. 全面性：多渠道信息收集确保研究覆盖面广
2. 专业化：各工作者专注于特定来源和搜索策略
3. 适应性：能根据初步发现调整搜索策略
4. 深度分析：综合多源信息进行对比分析
5. 效率提升：并行搜索不同来源大幅节省时间

4.2.5 评估-优化

定义：一个LLM调用生成响应，而另一个在循环中提供评估和反馈。

评估-优化工作流

适用场景：

• 当我们有明确的评估标准，且迭代优化能提供可量化价值的情境
• 适合场景的两个标志：

1. 人类反馈能明显改进LLM响应质量
2. LLM本身能提供类似人类的有效反馈

应用示例：

• 文学翻译：初译(生成) → 评估细微差别 → 根据反馈优化 → 循环至达标
• 复杂信息搜索：初步搜索(生成) → 评估完整性 → 指出信息缺口 → 补充搜索 → 循环至完整（例如，DeepRearch）

应用案例：文学翻译优化系统

背景与设置

• 目标：将《了不起的盖茨比》翻译成保留原著文学风格和情感的中文版
• 角色分工：
• 优化者LLM：负责生成翻译
• 评估者LLM：评估质量并提供改进建议


• 评估维度：准确性、风格一致性、文化适应性
• 最大迭代：3次（防止循环）

流程示例

原文：

"In my younger and more vulnerable years my father gave me some advice that I've been turning over in my mind ever since. 'Whenever you feel like criticizing anyone,' he told me, 'just remember that all the people in this world haven't had the advantages that you've had.'"

迭代1

初次翻译：

"在我年轻、更加脆弱的岁月里，父亲给了我一些建议，我自那以后一直在脑海中回味。'每当你想批评任何人的时候，'他对我说，'请记住，这个世界上的所有人都没有得到过你所拥有的那些优势。'"

评估（7/10）：

• ✓ 整体准确，主要含义传达
• ✗ "turning over in my mind"→"回味"不准确
• ✗ "advantages"→"优势"过于直白
• ✗ 语气平淡，缺少情感色彩
• ✗ 需要更流畅的过渡词

迭代2

修改版：

"在我年少轻狂、尚且脆弱的岁月里，父亲给了我一条忠告，此后我一直在心中反复思量。'每当你想要批评任何人的时候，'他对我说道，'请记住，这世上并非所有人都拥有过你所享有的那些机遇和条件。'"

评估（9/10）：

• ✓ 关键词翻译更准确
• ✓ 文学色彩增强
• ✓ 过渡更自然
• ✗ "年少轻狂"略带贬义
• ✗ 最后一句可更精炼

迭代3（最终版）：

最终翻译：

"在我年少青涩、心思易伤的岁月里，父亲给了我一条忠告，此后我便一直在心中反复思量。'每当你想要批评任何人，'他告诫我道，'请记住，这世上并非所有人都有幸获得你所享有的那些机遇。'"

最终评估（10/10）：

• ✓ 完美捕捉原文情感和风格
• ✓ 用词准确且富有文学性
• ✓ 结构精炼，符合中文阅读习惯
• ✓ 平衡了忠于原文与文化适应性

工作流优势

1. 质量提升：通过专门评估角色和多轮迭代提高输出质量
2. 自我改进：系统识别不足并主动优化
3. 透明度：评估标准和反馈可被清晰记录
4. 减少人工干预：在保持高质量的同时减少人类参与
5. 适应性：可根据特定领域定制评估标准

实施建议

• 明确定义评估标准和质量指南
• 设置合理迭代次数上限
• 保持优化者和评估者角色分离
• 跟踪记录每次迭代的变化
• 在关键应用中保留人类最终审核

这种工作流特别适合需要高质量、精心斟酌输出的场景，模拟了人类专业人士的迭代改进过程。

4.3 完整Agent模式

4.3.1 Agent设计要点

随着大模型核心能力的成熟（理解复杂输入、推理规划、工具使用、错误恢复），智能体正在生产环境中崭露头角。智能体的典型工作流程为：

1. 启动阶段：接收用户命令或通过交互确定任务
2. 规划执行：任务明确后独立规划操作，必要时向人类请求更多信息
3. 环境感知：每步骤从环境获取"基础事实"（工具调用结果或代码执行）评估进展
4. 反馈循环：在检查点或遇障碍时可暂停等待人类反馈
5. 任务终止：通常在完成时终止，包含停止条件（如最大迭代次数）以保持控制

Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. It is therefore crucial to design toolsets and their documentation clearly and thoughtfully.

智能体可以处理复杂任务，但其实现通常很直接 - 本质上是在循环中基于环境反馈使用工具的LLMs。

因此，清晰且合理的工具集及其说明文档至关重要。

我们在附录2中详述了工具开发的最佳实践。

工具集及其文档质量直接决定智能体的成功率和速度，体现在：

1. Agent选择合适工具及调用顺序的能力
2. Agent正确填写工具参数的能力
3. Agent有效利用工具结果的能力

自主Agent

何时使用Agent：

Agent适用于开放性问题，这些问题特点是：

1. 难以或不可能预测所需步骤数量
2. 无法硬编码固定解决路径

在这类场景中，LLM可能需要多轮操作，您必须对其决策过程有一定信任度。

需要注意的是，Agent的自主性意味着：

• 可能产生更高成本
• 存在错误累积的潜在风险

建议在实际部署前在沙盒环境中进行广泛测试，并设置适当的保护措施。

Agent应用举例：

以下是来自Anthropic实际实现的示例：

• 编程Agent：解决SWE-bench[3]任务，根据任务描述对多个文件进行编辑
• 计算机使用Agent：computer use[4]，Claude使用计算机完成复杂任务

编码Agent的流程

4.4 模式组合与定制

正如文章开头所强调，"最成功的实现采用简单、可组合的模式，而非复杂的框架"。这些设计模式是灵活的构建模块，可以根据具体应用需求进行组合和定制。

4.4.1 关键原则

• 这些模式是可自由组合的构建块，非固定框架
• 通过量化性能评估和迭代确定最佳组合
• 重要提示：仅在能显著提升效果时才增加复杂性

4.4.2 五种高效组合模式

1. 提示链 + 路由：

• 机制：路由分类任务，然后应用专用提示链
• 示例：客服系统先分类问题(账单/技术/退款)，再应用对应专业处理链。

1. 路由 + 并行化：

• 机制：先分类任务，对特定类别应用并行处理
• 示例：内容审核系统分类内容后，对复杂案例启用多评估者并行投票。

1. 编排者-工作者 + 评估者-优化者：

• 机制：编排者分解分配任务，工作者执行，评估者提供反馈优化
• 示例：代码系统中编排者确定修改文件，工作者生成代码，评估者检查提供改进建议

1. 提示链 + 评估者-优化者：

• 机制：在提示链关键节点使用评估-优化循环提升质量
• 示例：内容创作流程生成大纲→细化大纲→基于大纲创作→评估优化

1. 混合Agent系统：

• 机制：整合多种模式，不同任务阶段使用最适合的模式
• 示例：全功能客服Agent先路由分类查询，简单问题用提示链，复杂问题用编排者-工作者，全程通过评估者-优化者保证质量

4.4.3 实施建议

• 从简单开始，基于性能数据增加复杂性
• 关注每个组合的接口设计，确保信息顺畅传递
• 设置明确的评估指标，量化每种组合的效果提升
• 注意模式组合可能增加成本和延迟，权衡利弊
• 建立有效的监控和失败恢复机制

4.4.4 组合设计的优势

• 灵活应对不同复杂度的任务需求
• 结合各个模式的优势创造协同效应
• 随着需求变化可渐进式扩展系统能力
• 各组件可独立优化，提高整体系统可维护性

5. 实践指南

5.1 核心建议

「在LLM领域，最成功的实现不是构建最复杂的系统，而是为特定需求构建最合适的系统。」首先从简单的提示词开始，通过全面评估进行优化，仅在简单解决方案不足时才添加更多步骤的类Agent系统。

5.2 Agents开发原则

在实现Agent时，我们尽量遵循三个核心原则：

1. 保持简单性：只在能够明显改善结果时增加复杂性
2. 透明性：明确展示Agent的规划步骤来保证透明度
3. 精心设计工具接口：通过详细的工具文档和充分的测试创建良好的Agent-计算机接口（ACI）

虽然开发框架可帮助快速入门，但转向生产环境时，应减少抽象层级，直接使用基本组件构建。遵循上述原则，你可以创建强大、可靠、可维护且受用户信赖的智能体系统。

6. 附录1: Agent实战

6.1 智能体的实践价值与应用条件

基于客户合作经验，AI智能体在同时满足以下条件的任务中能创造最大价值：

• 需要对话与行动相结合
• 具有明确的成功衡量标准
• 能够形成有效反馈循环
• 整合有意义的人类监督机制

6.2 成功案例分析

案例一：智能客服

优势契合点

• 自然对话流程：客服交互天然符合会话模式，同时需要信息检索和行动执行
• 工具集成能力：可接入客户数据、订单历史和知识库资源
• 行动自动化：退款处理、工单更新等可程序化执行
• 清晰成功指标：通过用户问题解决率直接衡量成效

商业验证

多家企业采用基于成功解决的定价模型（仅对成功解决的案例收费），证明了Agent在客户支持领域的实际价值和可靠性。

案例二：编程Agent

应用优势