原文链接：https://claude.com/blog/common-workflow-patterns-for-ai-agents-and-to-use-them
作者：Claude Team
译者：倔强青铜三
当你让一个 AI Agent 自主决策时，工作流就是你为这种自主性引入结构的方法。它为执行建立了模式，将 Agent 的能力引导至那些需要协调步骤、追求可预测结果以及精心编排时机的复杂任务上。
真正的决策点往往出现在你需要多个 Agent 协同工作的时候：究竟哪种模式最适合你面临的问题？
根据 Anthropic 与数十个构建生产级 AI Agent 的团队合作经验，有三种模式覆盖了绝大多数实际用例：顺序工作流、并行工作流和评估器-优化器工作流。选错模式可能会让你在延迟、Token 消耗或系统可靠性方面付出代价。
工作流与 Agent 如何协作？
如果你管理过团队，其实已经理解了工作流的概念。
想象一条制造装配线：每个工位都有一位熟练工人对自己的特定任务做出决策，但整体流程是预先设计好的——即使单个步骤可能涉及动态决策（比如路由或重试）。AI Agent 工作流的运作方式与此相同。
理解工作流与自主 Agent 的区别
工作流不会取代 Agent 的自主性，而是塑造了 Agent 在何处以及如何运用这种自主性。
- 完全自主的 Agent 决定一切：使用哪些工具、以什么顺序执行任务、何时停止。
- 工作流提供结构：它建立了整体流程、定义了检查点，并为 Agent 在每个步骤中的操作设置了边界，同时仍然允许在这些边界内进行动态行为。
工作流中的每个步骤仍然可以充分利用 Agent 的推理和工具调用能力，但整体编排遵循既定的路径。这种模式让你在每一步都能获得 Agent 的智能，同时在整个任务流程中保持可预测性。
三种核心的 Agent 工作流模式
在生产环境中，最常被观察到的就是以下三种工作流模式。你可以将它们视为构建模块而非僵化的模板——随着需求演进，你通常会组合或嵌套它们：
- 顺序工作流 — 按固定顺序执行任务。
- 并行工作流 — 在多个 Agent 间同时运行独立任务。
- 评估器-优化器工作流 — 用于需要迭代改进的输出。
每种工作流类型都针对特定问题，并在复杂性、成本和性能方面有明确的权衡。
| 模式 |
解决的问题 |
何时使用 |
权衡 |
优势 |
| 顺序 |
任务存在依赖关系：步骤B需要步骤A的输出 |
多阶段流程、数据管道、起草-审查-润色周期 |
增加延迟（每个步骤需等待前一步完成） |
通过让每个Agent专注于单一任务来提高准确性 |
| 并行 |
任务彼此独立，但逐一执行太慢 |
跨多个维度的评估、代码审查、文档分析 |
成本更高（多个并发API调用）且需要聚合策略 |
可以更快完成，并实现跨工程团队的关注点分离 |
| 评估器-优化器 |
初稿质量不够好 |
技术文档、客户沟通、针对特定标准的代码生成 |
成倍增加Token使用量并增加迭代时间 |
可以通过结构化反馈循环生成更优的输出 |
一个实用的建议是：从能解决你问题的最简单模式开始。默认情况下可以尝试顺序模式。当延迟成为瓶颈且任务可独立执行时，转向并行模式。只有当你能够明确衡量并需要质量改进时，才添加评估器-优化器循环。
模式一：顺序工作流
顺序工作流按照预定的顺序依次执行任务。每个阶段的 Agent 处理输入、做出决策、根据需要调用工具，然后将结果传递给下一阶段。这样就形成了一条清晰的操作链，输出线性地流经整个系统。
何时使用？
当任务自然分解为具有明确依赖关系的不同阶段时，顺序工作流表现出色。你通过让每个 Agent 专注于一件事，而不是试图一次性处理所有事情，从而以一些延迟为代价换取更高的准确性。
在以下情况使用顺序工作流：
- 多阶段流程，且每个步骤都依赖于前一个步骤的输出。
- 数据转换管道，每个阶段都会增加特定的价值。
- 由于固有的依赖关系而无法并行化的任务。
- 迭代改进周期，例如起草、审查、润色的循环。
何时应避免？
当单个 Agent 可以有效处理整个任务时，或者当 Agent 需要的是协作而非简单的顺序交接时，就应跳过顺序工作流。如果你在不适合该结构的任务中强行引入顺序步骤，只会增加不必要的复杂性。
示例
当每个步骤涉及截然不同的工作时，顺序工作流效果显著：
- 首先生成营销文案，然后将其翻译成多种语言。
- 先从文档中提取数据，接着根据模式进行验证，最后加载到数据库中。
内容审核管道也适合顺序工作：提取内容、分类、应用审核规则，然后进行适当的路由。
专业提示：首先尝试将你的整个流程作为单个 Agent 运行，将不同步骤仅作为提示词的一部分。如果这样就足够好了，那么你无需额外复杂性就解决了问题。只有当单个 Agent 无法可靠处理时，才考虑拆分为多步骤工作流。
模式二：并行工作流
并行工作流将独立的任务分配给多个同时执行的 Agent。你不需要等待一个 Agent 完成再启动下一个，而是可以并行运行多个 Agent，并最终合并它们的结果。当任务彼此不依赖时，这种模式可以带来显著的速度提升。
这种方法类似于分布式系统中的扇出/扇入模式。你将相同或相关的工作分发给多个 Agent，每个 Agent 独立处理，然后你再聚合或综合它们的输出。Agent 之间不直接交接工作——它们自主运行并产生有助于完成整体任务的结果。
何时使用？
当你能够将工作划分为可以受益于同时处理的独立子任务，或者当你需要对同一问题获得多个视角时，并行化就变得有意义。它也实现了关注点分离：不同的工程师可以独立拥有和优化各自的 Agent，而不会相互干扰。对于复杂任务，用单独的 AI 调用来处理每个考量因素，通常比在一次调用中试图处理所有事情效果更好。
考虑在以下场景使用并行工作流：
- 分区处理：不同的 Agent 处理不同的方面（例如，一个处理查询，另一个筛选安全问题）。
- 多维度评估：每个 Agent 评估不同的质量维度。
- 投票模式：多个 Agent 分析相同的内容，并聚合它们的评估结果。
何时应避免？
当 Agent 需要累积上下文或必须基于彼此的工作成果进行构建时，不要使用并行工作流。当资源限制（如 API 配额）使得并发处理效率低下，或者当你缺乏明确的策略来处理来自不同 Agent 的矛盾结果时，也应跳过此模式。如果结果聚合变得过于复杂或反而降低了输出质量，那么并行化可能就不值得。
示例
并行工作流适用于：
- 自动化评估（每个 Agent 检查不同的质量指标）。
- 代码审查（多个 Agent 并行检查不同的漏洞类别）。
文档分析是另一个强大的用例：并行提取关键主题、进行情感分析和事实验证，然后合并所有见解。
专业提示：在实施并行 Agent 之前，先设计好聚合策略。你是采用多数投票？平均置信度分数？还是听从最专业的 Agent？拥有明确的计划可以防止你收集了一堆相互冲突的输出却无法解决它们。
模式三：评估器-优化器工作流
评估器-优化器工作流在迭代循环中配对两个 Agent：一个负责生成内容，另一个则根据特定标准评估该内容，然后生成器根据反馈进行改进。这个过程持续进行，直到输出满足你的质量阈值或达到最大迭代次数。
这里的关键洞见在于：生成和评估是不同的认知任务。将它们分离可以让每个 Agent 专业化——生成器专注于创造内容，而评估器则专注于应用一致的质量标准。
何时使用？
当你有清晰、可衡量的质量标准可供 AI 评估器一致地应用，并且“首次尝试”与“最终质量”之间的差距足够大，以至于证明额外的 Token 消耗和延迟是合理的，那么此模式就会有效。
考虑将评估器-优化器工作流用于：
- 具有特定要求的代码生成（如安全标准、性能基准、风格指南）。
- 语气和精确性都至关重要的专业沟通。
- 任何初稿质量持续不符合要求的场景。
何时应避免？
当首次尝试的质量已经满足需求时，应跳过评估器-优化器工作流——否则你就是在不必要的迭代上浪费 Token。不要在需要实时响应的应用程序、简单的常规任务（如基本分类）或评估标准过于主观（以至于 AI 评估器无法一致应用）的场景中使用此模式。如果存在确定性的工具（如用于代码风格的 linter），请改用它们。此外，当资源限制的重要性超过了质量改进时，也应避免此模式。
示例
评估器-优化器工作流适用于：
- 生成 API 文档（生成器编写，评估器根据代码库检查完整性、清晰度和准确性）。
- 创建客户沟通邮件（生成器起草，评估器评估语气和政策合规性）。
- 生成 SQL 查询（生成器编写，评估器检查效率和安全问题）。
专业提示：在开始迭代之前，设置明确的停止标准。定义最大迭代次数和具体的质量阈值。没有这些护栏，你可能会陷入昂贵的循环：评估器不断发现小问题，生成器不断调整，但质量可能在迭代停止之前很久就已趋于稳定。知道何时“足够好就是足够好”。
如何选择正确的工作流模式？
正确的工作流模式取决于你的任务结构、质量要求和资源限制。
在选择模式之前，首先将任务作为单个 Agent 调用来尝试。如果这能满足你的质量标准，那么工作就完成了。如果不能，找出不足之处——这恰恰告诉你应该选择哪种模式。
以下问题可以帮助你决策：
- 单个 Agent 能有效处理此任务吗？如果能，根本不需要工作流。
- 任务有明确的顺序依赖关系吗？使用顺序工作流。
- 子任务可以独立且同时处理吗？更快的完成速度是否有帮助？考虑并行工作流。
- 质量是否会随着迭代改进而有意义地提高？考虑评估器-优化器模式。
一旦选择了模式，还需要考虑：
- 失败处理：为每个步骤定义回退行为和重试逻辑。
- 延迟和成本约束：这些决定了你可以运行多少 Agent 以及能负担多少次迭代。
- 衡量改进：用单个 Agent 的表现设置一个基线，这样你就能判断工作流是否真的带来了帮助。
关于模式组合
这些模式并非互斥的。你可以根据复杂的实际需求来嵌套它们。
- 一个评估器-优化器工作流可能会使用并行评估，让多个评估器同时评估不同的质量维度。
- 一个顺序工作流可能在某个阶段包含并行处理，即多个独立操作在进入下一步之前同时发生。
关键在于，让模式的复杂性与实际需求相匹配。不要因为“可以”就添加并行处理——只有当并发执行能带来明显好处时才添加。不要实施评估器-优化器循环，除非它们能以你可衡量的方式提高输出质量。
深思熟虑地演进你的工作流
我们能给出的最好建议是：从可行的最简单模式开始。如果顺序工作流就能处理你的用例，就不要添加并行化。如果首次尝试的质量已经足够好，就跳过评估器-优化器循环。
这三种模式为你在需求变化时提供了清晰的演进路径。顺序工作流可以在瓶颈阶段引入并行处理。代理方法可以在质量标准提高时添加评估步骤。而且，因为这些模式是模块化的，你通常不需要完全重写系统。
有关更详细的实施指导、具体示例和高级模式（包括混合方法），你可以查阅 Anthropic 的完整 技术白皮书：Building effective AI agents: architecture patterns and implementation frameworks (构建有效的 AI Agent：架构模式和实施框架) https://resources.anthropic.com/ty-building-effective-ai-agents。
如果你对更多 AI Agent 的架构实践和开发心得感兴趣，也欢迎到技术开发者社区 云栈社区 进行交流与探讨。
以下为原文中的相关微信文章链接，已按规则保留原始链接：
发表于 4 小时前
|
查看: 5|
回复: 0
