一位资深工程师的担忧，暴露了 AI 时代最关键的角色

我的一位密友做了 15 年软件工程师，实战经验丰富。上个月一起喝咖啡时，他的一番话让我愣了一下。“我这儿来了个新人，”他说，“我就在屏幕上看着他写代码。现在我成了主管，不再是开发者了。”

有这种感受的不只他一个。整个行业的资深工程师都盯着 Copilot、Codex 和 Claude Code，心里在想：我现在的工作是什么？

问题并不是“AI 能不能写代码”。它能。真正的问题是：谁来设计这样一个系统，告诉 AI 写什么、什么时候写、如何验证，以及失败时该怎么办？

这就是架构，也就是代码之外、围绕代码所做的所有系统设计。它从未像今天这样重要。

照片由 Jennifer Chen 拍摄，来自 Unsplash

TL;DR

大多数 Agentic AI 项目失败，败在战略，而不是模型。 只有 11% 的组织已在生产环境中使用 Agentic AI。四分之三的组织仍在规划，或是不知所措。
Agentic 工作分为三类，选错类别是最常见的架构错误：确定性工作流、自主 Agent 和混合模式。
工作流不够性感，却是真正能交付的架构。 五种可组合模式能够处理 80% 以上的生产用例。
对任何超出演示范围的系统来说，持久化执行都不容妥协。如果你的 Agent 在失败时丢失状态，你会消耗双倍 Token，还会得到不一致的结果。
协议层（MCP + A2A）和安全框架（OWASP Agentic Top 10）如今已经足够成熟，可以作为系统的构建基础。“最小自主权”原则应该贯穿架构设计，而不应只出现在安全审查中。
你 15 年的经验并没有过时。 它才是当下最重要的资产。

现实检验

先看数字，因为数字不受炒作周期影响。

根据 Deloitte 的《2025 年新兴技术趋势》研究，只有 11% 的组织正在生产环境中积极使用 Agentic AI。另有 14% 的组织已有解决方案准备部署。还有 42% 的组织仍在制定战略路线图，35% 的组织根本没有正式战略。这意味着四分之三的市场要么还在规划，要么不知所措。

而且情况没有好转，反而在恶化。S&P Global Market Intelligence 发现，放弃大部分 AI 项目的公司占比从 2024 年的 17% 跃升至 2025 年的 42%。蜜月期已经结束。

项目真正失败的原因

人们往往只把这些失败归咎于技术架构：“团队构建了错误的系统。”这种看法太狭窄。真正的失败原因更广，也更具结构性。

从一开始就没有明确的商业论证。 MIT 的研究人员发现了一个被称为“GenAI Divide”的现象：成功的 5% 从与商业价值挂钩的具体、可衡量成果入手。其余 95% 则从技术出发，再回头寻找问题。“在准确率达到 99.5% 的情况下，将发票处理时间从 8 天缩短到 2 天”，这才是站得住脚的商业论证。“让我们构建一个 AI Agent，看看它能做什么”，则只是科学实验。

把 Agentic AI 当作软件部署，而不是业务转型。 最常见的反模式之一，是像安装新的 SaaS 工具那样对待 Agent：配置、部署，然后转身去做下一件事。但 Agentic 系统需要持续训练、设定边界并不断完善。与其把它们看成一套待安装的软件，不如把它们看成需要培养的新员工。把它们当作“一设即忘”工具的公司，始终无法实现规模化。

数据架构还没有为 Agent 做好准备。 Precisely 与 Drexel University 在 2025 年开展的一项研究发现，只有 12% 的组织表示，其数据质量和可访问性足以支持 AI。近 70% 的组织把数据治理列为首要挑战。Deloitte 的研究也发现了同样的问题：围绕 ETL 管道和数据仓库构建的企业数据架构，从结构上就不适合 Agent 获取数据。Agent 需要通过搜索和索引访问上下文数据，而不是依赖定时批处理管道。仅数据层的问题，就可能让整个项目在写下第一行编排代码前夭折。

“Agent 洗白”泛滥。 市场上有成千上万家 Agentic AI 供应商，只有一小部分提供真正的 Agentic 能力。其余供应商只是在重新包装聊天机器人、RPA 工具和 AI 助手，并没有真正的自主能力或决策架构。如果你的“Agent”其实只是一个换了更光鲜标签的聊天机器人，那么再好的架构也救不了这个项目。

没错，错误的架构也是原因。 这类问题确实存在，只不过不是全部。团队把自主 Agent 架构用在需要结构化工作流的问题上。明明一条带验证关卡的 Prompt 链就能完成任务，却构建了由 5 个 Agent 组成的系统。跳过持久化层，导致每次失败都会丢失状态。架构是几个关键失败原因之一。

真正的瓶颈

本文的核心观点是：瓶颈已经从模型能力转移到了模型周围的一切。 战略、商业论证、数据准备、架构决策、评估框架、安全体系。

模型能够推理、使用工具，还能生成通过真实项目测试套件的代码。真正缺少的，是让这些能力可靠发挥作用的组织基础和技术基础设施，包括工作流模式、持久化层、协议栈、安全边界和评估框架。这个领域两年前还根本不存在。

看似反直觉的是，这个新领域会创造更多架构工作，而不是减少架构工作。在 AI 之前，你只需要设计一种架构，也就是应用本身。现在你需要设计两种：应用的架构，以及负责构建、运营或增强应用的 Agentic 系统架构。在这个时代真正占据优势的，不会是代码写得最多的工程师，而是最懂得为 AI 设计运行环境的工程师。

这正是本指南的目的。

作者制图：Agentic 现实差距

“Agentic” 究竟意味着什么

“Agent”一词承载的含义太多，几乎已经失去意义。回答客户问题的聊天机器人被称为 Agent。能够读取 GitHub issue、编写代码、运行测试并提交 Pull Request 的完全自主编码系统，也被称为 Agent。它们并不是同一种东西，而把它们混为一谈，正是团队采用错误架构的原因。

构建模块：增强型 LLM

每个 Agentic 系统都始于同一个原子单位：具备三种增强能力的大语言模型。检索让模型能够访问外部知识（向量数据库、文档存储、搜索 API）。工具让模型能够采取行动（API 调用、数据库查询、代码执行）。记忆让模型能够跨多次交互保留信息。这个增强型 LLM 就是原子，其他一切都是由这些原子以不同方式组合而成的分子。

作者制图：增强型 LLM 构建模块

连续谱：从 LLM 调用到自主 Agent

“Agentic”不是一个非开即关的选项，而是一条分为五个级别的连续谱。

第 1 级：单次 LLM 调用。 输入 Prompt，输出响应。没有工具，没有记忆，没有循环。它能处理的用例比人们想象的更多。

第 2 级：增强型 LLM。 模型能够搜索、使用工具并记住信息。大多数“AI 助手”处于这一层。

第 3 级：工作流。 通过预定义的代码路径编排多次 LLM 调用。流程由你控制，LLM 在每一步中发挥能力。

第 4 级：有界 Agent。 LLM 动态引导自己的流程，但受你定义的约束限制：Token 预算、时间限制、工具限制、人工审批检查点。

第 5 级：自主 Agent。 在较长时间内拥有高度自主权，只需极少的人工监督。编码 Agent、深度研究系统和计算机使用 Agent 都处于这一层。

关键在于：大多数生产价值来自第 2 级和第 3 级。 行业炒作集中在第 5 级，但收入集中在第 3 级。先判断你的问题落在这条连续谱的哪个位置，这是你需要做出的第一个架构决策。

Agentic 工作的三种类别

下面这个框架会贯穿本文余下部分的每一个架构决策。一旦理解它，你会发现它无处不在。

并非所有 Agentic 工作都相同。行业把“Agent”当作一个大类，但实际上，Agentic 工作分为三种本质不同的类别。每一类都需要不同的架构、成本模型和权衡。给问题选错类别，是 Agentic 项目失败最常见的单一原因。

类别 1：具有 LLM 智能的确定性工作流

定义特征：你能在系统运行前画出流程图。

在类别 1 中，架构师负责设计路径。LLM 在每一步中提供智能能力，但工作结构是预先确定的。你知道有哪些步骤、执行顺序和分支逻辑。LLM 让每一步都比采用传统代码时更智能、更快速或更准确，但不决定下一步做什么。

例如客户服务分流：查询经过分类后，被路由到专门的处理程序。再如文档处理管道：合同经过解析、提取、验证和摘要。再如内容生成链：草稿依次经历撰写、翻译、审阅和发布。又如合规检查：申报文件根据监管规则进行扫描。

这些系统可测试、可审计、可调试，成本也可预测。你可以为每一步编写单元测试。系统出故障时，可以准确追查发生了什么。因为你确切知道每次工作流会调用 LLM 多少次，所以可以相当准确地估算每月的 LLM 支出。

当今 80% 以上的生产价值都来自这里。 它并不光鲜，也不会登上新闻头条，但真正的收入正是在这里产生的。

作者制图：三种类别（见图）

类别 2：自主 Agent 工作

定义特征：只有到了运行时，才能知道工作会如何展开。

在类别 2 中，规划本身就是工作。Agent 无法遵循预先确定的路径，因为路径还不存在。它必须探索、形成假设、检验假设，在出错时回退，并根据发现的情况调整方法。

软件开发是最清楚的例子。当编码 Agent 收到“修复用户模块中的身份验证 bug”时，它不知道需要修改多少个文件（可能是 1 个，也可能是 15 个）。在读取文件之前，它不知道文件中有什么。它不知道修复是否会破坏其他东西，也不知道需要经历多少轮运行测试、定位问题和调试修复。Agent 必须探索代码库、理清关系、制定并执行计划，还要在事情偏离预期时修订计划。

深度研究 Agent 的工作方式也一样。你无法预先定义从“调查量子计算的市场趋势”通往一份综合报告的路径，因为 Agent 需要追踪线索、评估来源、识别缺口，并决定何时已经掌握足够的信息。

这些系统成本高昂、结果不确定、难以测试，也难以审计。但对于任务分解本身就需要智能的问题，它们必不可少。

类别 3：混合模式（工作流外壳 + Agent 内核）

定义特征：可预测的外部结构，内部包含有限的自主空间。

大多数成熟的生产系统实际上都属于类别 3。工作流提供骨架：超时、预算、人工参与检查点、质量关卡。Agent 则在有限的步骤中提供灵活性。

设想一条研究管道，工作流定义四个阶段：收集来源、分析发现、综合洞见、生成报告。整体结构是预先确定的。但在“收集来源”阶段，一个自主 Agent 可以自由探索，追踪线索、评估相关性，并决定何时已经获得足够的上下文。工作流约束外层循环。Agent 掌控内层循环。

OpenAI 在 Temporal 上运行 Codex，是类别 3 用于生产环境的典型例子。Temporal 提供持久化工作流外壳（编排、状态持久化、故障恢复）。Codex 在每个步骤内自主完成编码工作。工作流知道何时调用 Agent，Agent 决定每次调用时要做什么。

实践中的大多数多 Agent 协调也发生在这里。一个监督工作流协调各个专家 Agent，每个 Agent 在自己的领域内拥有有限的自主权，而工作流层负责交接、超时和质量检查。

作者制图：三种类别的决策启发法

决策启发法

类别决策归结为三个问题：

你能画出流程图吗？ 如果能，这个问题就属于类别 1。采用五种工作流模式，你晚上会睡得很安稳。

任务分解本身就是困难所在吗？ 如果 Agent 需要弄清楚该做什么，而不只是执行你设计好的步骤，这个问题就属于类别 2。你需要在持久化能力和护栏上大量投入。

你需要可预测的结构，同时又要留出一些探索空间吗？ 这个问题属于类别 3。先设计工作流外壳，再定义 Agent 获得自主权的边界。

令人不安的事实

大多数团队把类别 2 的解决方案用在了类别 1 的问题上。

对于一条带验证关卡的 Prompt 链就能处理的任务，他们却构建自主 Agent 架构。对于只需要路由和并行化的工作流，他们却部署多 Agent 系统。简单工具本来能更快交付、成本更低、故障更少，他们却选用了最复杂的工具。

人的判断在这里很重要。没有 AI 能替你决定问题属于哪个类别。要做出这种判断，必须深入理解业务领域、用户的实际需求、成本约束和合规要求。这是架构师的工作，所需的经验来自多年间对软件在生产环境中成败的观察。

作者制图：类别属性对比（见图）

深入类别 1：能够交付的工作流模式

大多数生产价值都来自类别 1，因此值得深入讨论。以下五种可组合模式由 Anthropic 在《Building Effective Agents》指南中提出，是基于工作流的 Agentic 系统的经典构建模块。

每种模式都解决一个特定的架构问题，也都有明确的“何时使用”和“何时不使用”指导。更关键的是，它们可以组合：真实的生产系统会把多种模式组合成复杂架构，同时保持可测试性和成本可预测性。正是这些特性，让类别 1 系统足够可靠。

1. Prompt 链：最简单的串行工作流

Prompt 链把任务分解为一系列步骤，每次 LLM 调用都处理上一次调用的输出。这是最直接的模式，遇到任何多步骤任务时，都应该先考虑它。

要让它达到可用于生产的状态，关键是加上关卡。在步骤之间加入程序化验证检查点，先验证某一步的输出，再交给下一步。关卡可以检查提取的数据是否符合预期 schema、分类是否落在已知类别内，或者生成的文本是否超出长度限制。关卡能把 Prompt 链从脆弱的串联链条变成内置质量控制的稳健管道。

作者制图：Prompt 链模式

适用场景： 任务可以清晰地分解为固定子任务。你愿意用延迟换取准确性，让每次 LLM 调用处理一个更简单、更聚焦的任务。

不适用场景： 需要动态规划的任务，例如你无法提前知道步骤数量，或者后续步骤需要根据早期发现发生根本性变化。

真实示例： 生成营销文案，然后翻译成另一种语言。撰写文档大纲，按标准验证，再扩展每个章节。从文档中提取结构化数据，根据 schema 验证，再载入数据库。

成本特征： N 次顺序执行的 LLM 调用，其中 N 固定且已知。总延迟是累加的（所有调用之和），但由于任务更简单，每次调用单独来看成本更低。

2. 路由：成本优化器

路由先对输入分类，再将其导向专门的后续任务。路由器检查传入请求，把每个请求发送到最合适的处理路径。

这种模式支持两项关键优化。第一，关注点分离：每个下游处理程序都会获得一个针对特定任务类型调优的专用 Prompt，而不是用一个臃肿的 Prompt 试图处理所有事情。第二，成本优化：你可以把简单查询路由到轻量、廉价的模型（如 Claude Haiku），把复杂查询路由到强大、昂贵的模型（如 Claude Sonnet 或 Opus）。Anthropic 在其指南中特别指出了这种模型路由策略。

适用场景： 你的工作负载包含多个适合以不同方式处理的明确类别。分类是可靠的（无论使用 LLM 分类器还是传统 ML）。专门路径之间的差异足够大，值得付出路由开销。

不适用场景： 所有输入都需要相同处理。分类准确率很低，导致输入被送入错误路径。路由开销超过专业化带来的节省。

真实示例： 客户服务分流：一般问题、退款请求和技术支持分别路由到拥有不同工具与权限的 Agent。内容审核：文本、图像和代码分别路由到专门的分类器。API 请求处理：简单查询直接返回缓存响应，复杂查询则交给 Agentic 流程。

成本特征： 一次用于分类的 LLM 调用（廉价），加上下游处理程序的成本。净节省来自把大多数简单流量发送到廉价路径。

3. 并行化：通过独立性提速

并行化会同时运行多个 LLM 操作。Anthropic 指出了两种解决不同问题的独特形式。

分段把任务拆分为并行运行的独立子任务。每个子任务处理问题的不同方面，所有任务完成后再聚合结果。关键要求是：子任务必须真正相互独立。如果子任务 B 依赖子任务 A 的输出，你需要的是 Prompt 链，而不是并行化。

投票使用不同 Prompt 或 temperature 参数多次运行同一个任务，以获得不同视角。之后对结果进行比较、按多数票聚合，或综合成最终答案。结果越多样，投票得到的置信度越高。

适用场景： 子任务真正相互独立（分段）。你需要比单次模型调用更高的置信度（投票）。延迟很重要，而且你能负担并行计算。

不适用场景： 子任务之间存在依赖。聚合步骤比单个任务更复杂。相比延迟，Token 成本更值得关注。

真实示例： 护栏模式：一个 LLM 实例处理用户查询，另一个实例同时筛查不当内容或违反政策的情况。这通常优于让单个 LLM 同时处理安全筛查和实际响应。代码审查：多个专用 Prompt 独立扫描安全漏洞、性能问题和风格违规。评估：每次 LLM 调用评估不同的质量维度。

作者制图：工作流模式概览

4. 编排器与执行器：动态分解

编排器与执行器模式让一个中央 LLM 负责分解任务，再把任务交给专门的执行器。到这里，工作流开始接近类别 3 的边界，因为部分任务要到运行时才能分解。

它与并行化的关键区别在于：子任务不是预先定义的。 编排器检查输入，确定需要完成哪些工作，并据此分派执行器。这些执行器可能采用不同的 Prompt、不同的模型，也可能是配备不同工具的 Agent。所有执行器完成任务后，编排器再综合它们的结果。

适用场景： 无法提前预测子任务的复杂任务。子任务的数量和性质随输入变化。每个子任务都能从专门方法中受益。

不适用场景： 任务分解可预测（改用并行化）。协调开销超过质量提升。你需要确定性、完全可审计的行为。

真实示例： 在多个文件中进行复杂修改的编码系统，需要编辑哪些文件、编辑多少处，都取决于具体任务。收集并分析多个来源信息的研究任务，由编排器决定调查哪些来源。多文档生成，输出结构取决于输入的复杂程度。

成本特征： 一次编排器调用，加上 N 次执行器调用，其中 N 随输入变化。与更简单的模式相比，成本从这里开始变得不那么可预测。应把执行器数量上限设为护栏。

5. 评估器与优化器：通过迭代提高质量

评估器与优化器模式会创建一个反馈循环：一个 LLM 生成响应，另一个根据质量标准对其进行评估，生成器再根据反馈完善输出。循环持续进行，直到评估器满意或达到最大迭代次数。

这相当于把代码审查内置到 Agentic 管道中。评估器不只会说“好”或“不好”，还会给出具体、可操作的反馈：“摘要遗漏了第 3 节的财务预测”，或“该函数没有处理 null 输入情况”。

这种方法与学术研究直接相关。Reflexion 论文（Shinn 等人，NeurIPS 2023）将其形式化为“语言强化学习”，Agent 通过自我反思循环不断改进。这种模式之所以有效，是因为与一次生成完美输出相比，LLM 往往更擅长评估输出质量。

适用场景： 存在明确的评估标准。迭代完善能够带来可衡量的改进。额外 LLM 调用的成本能够被质量提升证明合理。

不适用场景： 评估标准主观或含糊。第一次输出通常已经足够好。循环无法收敛（每次迭代都有同等可能让结果变好或变差）。

真实示例： 文学翻译，一个模型负责翻译，另一个评估细微差别、习语准确性和文化语境。带测试驱动验证循环的代码生成，评估器运行测试并报告失败。文档合规检查，反复修订草稿，直到满足监管要求。

停止条件很重要。 如果没有明确限制，生成器和评估器可能在无法收敛的情况下不断循环，让评估器与优化器循环无限消耗 Token。务必设置最大迭代次数。一个不错的启发法是：如果评估器分数连续两次迭代都没有提高，就退出循环。

6. 组合模式：组合才是关键

生产系统很少孤立使用单一模式。真正的架构能力，在于知道如何组合不同模式，以平衡质量、速度和成本。

一个真实的客户支持系统可能这样组合这些模式：

入口处的路由把传入工单分为以下类别：账单、技术、账户管理、一般咨询。每个类别都路由到专门的管道。

每条管道内的 Prompt 链通过连续步骤处理工单：理解上下文、检索相关账户数据、生成响应、应用品牌语气规范。

质量层的并行化让生成的响应同时接受多项检查：依据知识库检查事实准确性、检查语气和品牌一致性、筛查政策违规。

对高风险响应（账单争议、升级事件）使用评估器与优化器，反复完善草稿，直到质量指标通过。

组合规则是：从能够奏效的最简单模式开始，只有在能够衡量改进时才增加层次。 每增加一种模式，都会增加延迟、成本和复杂性。目标是找到能达到质量标准的最小可行架构，而不是设计出最复杂的架构。

人的判断在这里最为关键。组合哪些模式、在哪里设置质量关卡、哪些步骤需要昂贵模型、哪些可以使用廉价模型、每一步怎样才算“足够好”，都需要依靠深厚的领域知识来判断。在客户支持领域深耕多年的架构师，设计出的复合工作流会明显优于照本宣科套用模式的人。

作者制图：复合架构示例

深入类别 2：何时真正需要自主 Agent

类别 2 之所以存在，是因为有些问题确实难以拆成工作流。任务过于开放，行动空间变化太大，或者规划本身就需要临场判断。否认类别 2 的必要性并不诚实，但在不需要它时使用它，则是架构上的鲁莽。

为什么软件开发会打破工作流模型

软件开发是最典型的类别 2 用例，因为那些让类别 1 变得可靠的特性，在这里都会失效。

路径未知。 当编码 Agent 收到“为 API 实现速率限制”时，它不知道需要修改多少个文件。它需要阅读代码库、理解架构、识别集成点并制定计划。随着 Agent 发现初始描述中看不到的依赖关系、测试失败或架构约束，该计划在执行期间可能会改变三次。

任务分解需要智能。 在 Prompt 链工作流中，你在设计时分解一次任务，然后运行数千次。在软件开发中，每个任务都需要重新分解。Agent 需要弄清楚该做什么，而不只是执行你设计好的步骤。这就是编排器与执行器模式仍然不够的原因：如果不先探索代码库，就连编排器也无法可靠地分解编码任务。

反馈结果是二元的，过程却不可预测。 代码要么通过测试，要么不通过。测试不通过时，失败原因可能是拼写错误、逻辑错误、缺少导入、竞态条件，或根本性的架构缺陷。Agent 需要诊断失败、提出修复假设并反复尝试。迭代次数无法提前得知。

作者制图：类别 2 使用时机决策指南

成本现实

再来看实际成本。一位从业者记录了一个多 Agent 系统：当架构从单模型工作流变为由 5 个 Agent 组成的架构后，每个请求的成本从 0.02 美元跃升至 0.50 美元，达到原来的 25 倍。规模化以后，这就是一款可行产品与一款烧光风险资本的产品之间的差别。

类别 2 系统成本高昂，是因为它们是开放式的。一个处理复杂 bug 的编码 Agent，可能要进行 30 到 40 次 LLM 调用才能解决问题。每次调用都会消耗完整上下文窗口的 Token（代码库、对话历史、工具结果）。Token 成本会随每次迭代不断累积。

因此，在选择类别 2 之前，始终要诚实回答一个问题：“你能用更简单的方法得到 80% 的结果吗？” 对许多看似需要完全自主的任务来说，设计良好的类别 1 工作流加上编排器与执行器模式，往往已经能非常接近目标。为了剩余 20%，成本可能要升至原来的 25 倍，这未必值得。

类别 2 确实合理的场景

尽管成本高昂，有些问题确实需要自主 Agent 架构：

开放式探索，其行动空间未知。例如研究任务，Agent 必须追踪线索、评估相关性并决定何时停止。又如创造性问题解决，解决方案路径无法根据问题描述预测。

软件开发和调试，其任务分解需要智能。SWE-bench 的进展说明了一切：仅仅一年时间，LLM 解决真实世界 GitHub issue 的比例就从约 40% 提升到 80% 以上。这项进步来自更好的 Agent 架构，而不只是更好的模型。

计算机使用 Agent，它们与动态图形界面交互。你无法为浏览任意网站或桌面应用预先定义工作流，因为 UI 状态直到运行时才会揭晓。

高价值、低频次的决策，错误决策的代价远高于多次 LLM 调用的成本。如果一次错误交易会损失 100,000 美元，那么花 50 美元进行彻底的 Agentic 分析非常划算。

作者制图：混合架构

但即使在类别 2 中，架构原则仍然成立：用持久化执行框架包裹自主 Agent。 OpenAI 并不是把 Codex 作为一个裸 Agent 运行。他们在 Temporal 上运行它，将其置于一个提供状态持久化、故障恢复和资源约束的工作流外壳中。实践中这就是类别 3：工作流外壳保护自主 Agent 内核。

在生产环境中，纯类别 2 很少见。几乎每个成功部署的自主 Agent 都使用类别 3 混合架构：在自主内核外包裹一个持久化工作流。

深入类别 3：混合模式

成熟的专业人士设计生产级 Agentic 系统时，最终往往会采用类别 3。

架构模式

混合模式有两层，它们服务于本质不同的目的。

工作流层提供外部结构。它定义工作阶段，管理阶段之间的转换，执行超时和预算，触发人工参与检查点，并处理故障恢复。这一层具有确定性，可以测试和审计。你可以把它的流程图画在白板上。

Agent 层提供内部智能。在工作流的特定步骤内，自主 Agent 在有限范围内运行。它进行推理和探索，调用工具，并根据发现调整方法。但其自主权受到约束：工作流层设定边界，Agent 在边界内运行。

一个便于架构师理解的比喻是：工作流是公路系统，Agent 是驾驶员。 公路决定总体路线、出口、限速和护栏。驾驶员在这些约束内行驶，实时决定变道、避开障碍和采用最佳速度。两者缺一不可。

混合架构：研究管道

设定边界：架构师的核心工作

在类别 3 中，架构师最重要的决策并不是使用哪个 LLM 或选择哪个框架，而是在哪里划定工作流控制与 Agent 自主权之间的边界。无论偏向哪一边，划错边界都会产生问题。

工作流太多，Agent 太少： 你实际上构建的是类别 1 系统，却给它贴上了“Agentic”标签。探索步骤受到过多限制，无法适应新颖输入。你得到了可预测性，却失去了自主性本应提供的价值。

Agent 太多，工作流太少： 你构建了一个没有护栏的类别 2 系统。成本失控，执行时间不可预测，故障接连发生，调试则需要像考古一样逐层挖掘。

正确的边界取决于你的领域、风险承受能力和成本敏感度。有四种具体机制可以控制 Agent 的自主权：

Token 预算限制 Agent 每个步骤最多可以消耗的计算量。如果竞争分析 Agent 消耗了 50,000 个 Token 仍未得出结论，工作流会终止该步骤，并转入后备行为（例如请求人工输入、使用部分数据继续，或缩小范围后重试）。

时间限制防止无限探索。研究阶段设置 20 分钟超时，意味着 Agent 必须优先处理高价值来源，而不是穷尽式搜索一切内容。

工具访问限制约束 Agent 可以做什么。研究 Agent 可以访问网页搜索和知识库。它不能获得数据库写入权限、代码执行权限或电子邮件发送权限。每一种工具都会扩大攻击面（依据 OWASP ASI02：工具误用），因此只授予该步骤所需的工具。

人工审批检查点要求在高风险操作前获得批准。工作流可以根据置信度分数、成本阈值或领域敏感性，把 Agent 输出送入审批关卡。

多 Agent 协调如何融入架构

实践中的大多数多 Agent 协调同样发生在类别 3 中。监督者模式让工作流担任协调者角色：它把任务路由给专家 Agent，管理它们之间的交接、聚合结果并处理冲突。

每个专家 Agent 在其领域内拥有有限的自主权（代码编写 Agent、测试运行 Agent、文档 Agent），监督工作流则负责整体编排。这样既能避免 Agent 之间点对点通信造成混乱（后者更难调试、保护和梳理），又能保留专业化带来的好处。

人的判断在这里非常重要。要决定系统的哪些部分需要 Agent 级灵活性，哪些可以硬编码为工作流步骤，必须具备深厚的领域专业知识。在竞争情报领域工作多年的工作流设计者，与照本宣科套用模式的人，划出的边界会截然不同。设定边界本身就是架构工作，而架构离不开人的判断。

作者制图：混合边界控制（见图）

让系统具备持久化能力

如果你的 Agentic 系统无法在崩溃后恢复，它就只是演示，不是产品。

如果没有持久化执行，每次基础设施出现短暂故障，系统都只能从头重启。你会重新运行每次 LLM 调用（消耗双倍 Token）。由于 LLM 输出具有非确定性，系统可能走上不同路径，交付不一致的结果。Temporal 最初从 Uber 的 Cadence 项目中分拆出来，如今已成为解决这个问题的事实标准。

关键洞见：确定性并不意味着预先确定

这个概念容易让工程师困惑。“确定性”听起来像是“没有 AI，也没有动态决策”，其实并非如此。确定性的意思是：给定相同的事件历史，工作流必须做出相同的决策。 工作流代码始终执行相同的逻辑，但该逻辑的输入（LLM 响应、工具结果、外部信号）完全可以不可预测。

根据 LLM 的决定，Agent 可以走上完全不同的路径。一次运行可能编辑 3 个文件，另一次可能编辑 15 个，这些都不是预先确定的。真正具有确定性的，是编排这些决策的工作流代码。崩溃后重放时，Temporal 会把先前记录的 Activity 结果交给工作流，而不是重新执行 LLM 调用。工作流按照相同逻辑得到相同的已记录结果，并从故障点恢复。

Workflow 与 Activity：关键的分离

Temporal Workflow 是原生代码（Python、TypeScript、Go），但有一个约束：不能产生副作用。不能进行网络调用，不能进行磁盘 I/O，也不能使用 datetime.now()。它是纯编排逻辑。真正的工作发生在 Activity 中：LLM 调用、工具调用、数据库查询。Activity 可以做任何事，也可以失败、重试，而且每次执行的结果都可能不同。

@workflow.defn
class ResearchAgentWorkflow:
    @workflow.run
    async def run(self, request: ResearchRequest) -> ResearchResult:
        plan = await workflow.execute_activity(
            plan_research, args=[request],
            start_to_close_timeout=timedelta(seconds=60),
        )
        findings = await workflow.execute_activity(
            gather_information, args=[plan],
            start_to_close_timeout=timedelta(minutes=20),
            heartbeat_timeout=timedelta(seconds=30),
        )
        report = await workflow.execute_activity(
            synthesize_findings, args=[findings],
            start_to_close_timeout=timedelta(seconds=120),
        )
        return report

工作流是确定性的：先规划，再收集，最后综合，顺序始终不变。但 Activity（LLM 调用发生的地方）可以返回任何内容。崩溃后重放时，Temporal 不会重新运行 plan_research。它会取回先前记录的结果，跳到故障点，然后恢复执行。既不会再次消耗 Token，也不会产生不一致的结果。

Signal：为人工参与提供持久化能力

Signal 是外部系统发送给运行中工作流的异步消息。它让生产 Agent 所需的人工参与机制成为可能。Agent 处理超过 500 美元的退款前需要审批。工作流会持久化当前的暂停状态（不是休眠，也不是轮询），直到收到人工审批的 Signal。即使服务器重启，工作流也会恢复到完全相同的等待状态。几小时或几天后，审批人点击“批准”，Signal 到达，工作流继续执行。

这种模式支撑着多种基础能力：中断期间的暂停与恢复、运行途中动态注入上下文、工具审批关卡，以及带清理操作的优雅取消。

成本论证

假设一个编码 Agent 运行 30 分钟，消耗价值 2 美元的 Token。如果没有持久化能力，在第 25 分钟发生故障就意味着要重新开始：再花 2 美元，再等 30 分钟，而且结果可能不同。有了持久化能力，同样的故障可以从第 25 分钟恢复：成本可以忽略不计，只需 5 分钟，结果保持一致。如果每月运行 100,000 次，故障率为 5%，仅避免重启一项，每月大约就能节省 10,000 美元。

持久化能力如何映射到每个类别

类别 1：简单直接。 每个工作流步骤都成为持久化 Activity。发生故障时，只重试失败的特定步骤，而不是整个工作流。因为编排完全是确定性的，实现非常整洁。

类别 2：至关重要。 这些 Agent 运行时间最长，失败时成本最高。每当基础设施发生短暂故障，是否采用持久化执行，就决定了一项任务成本是 2 美元还是 4 美元。事件历史还提供了类别 2 系统原本缺少的审计轨迹。

类别 3：天然契合。 工作流外壳本身就是持久化层。持久化编排器管理生命周期，Agent Activity 则在其中执行。这正是 Codex 在 Temporal 上的运行方式。

协议层：MCP、A2A，以及连接一切的机制

在 2024 年的大部分时间里，构建 Agentic 系统的最大阻力并不是模型，而是连接器。每个 Agent 都需要为每种工具、每个 API、每个数据源进行自定义集成。因为这种集成成本而夭折的项目，比因架构糟糕而失败的还多。

MCP：Agent 与工具连接

由 Anthropic 开发的 Model Context Protocol（MCP）统一了 Agent 连接工具的方式。可以把它看作“Agent 与工具连接领域的 USB-C”。Agent 通过标准协议发现可用工具，通过结构化描述了解其能力，再通过统一接口调用它们。你不必把 Slack 连接器、GitHub 连接器和数据库连接器写成三个独立代码库，而是为每种工具配置 MCP Server，让 Agent 通过同一协议连接所有 Server。

MCP 如今由 Linux Foundation 治理。对于要为多年期平台做决策的企业架构师来说，这是一个长期稳定的信号。

A2A：Agent 间通信

Google 的 Agent-to-Agent Protocol（A2A）解决的是另一个问题。MCP 处理纵向连接（Agent 到工具），A2A 则处理横向通信（Agent 到 Agent）。它让不同团队、使用不同框架构建的 Agent 可以通过 Agent Card（能力声明）彼此发现，通过具有生命周期管理功能的 Task 委派工作，并通过结构化 Artifact 交换结果。

MCP 与 A2A 互为补充，而不是彼此竞争。 MCP 是纵向层（每个 Agent 都用它访问工具）。A2A 是横向层（Agent 用它相互协调）。二者共同构成协议栈，让 Agentic 系统实现互操作，就像 HTTP 之于 Web 服务。

作者制图：MCP + A2A 协议层

把安全作为架构：OWASP Agentic Top 10

2025 年 9 月，研究人员在真实环境中发现了第一个恶意 MCP Server：一个冒充 Postmark 电子邮件服务的 npm 包。它可以作为合法电子邮件工具正常工作，却暗中把每封邮件密送给攻击者。一个月后，人们发现另一个 MCP 包内置了两个反向 Shell。126 个包，86,000 次下载。

传统应用安全假设人类会参与回路，Agentic 安全则假设人类不会参与。当 AI Agent 可以自主规划、选择工具并执行操作时，你要防御的就不再只是有人利用代码，还包括有人利用 Agent 的推理过程。

OWASP 于 2025 年 12 月发布了 Agentic Applications Top 10。对架构师最重要的风险包括：

作者制图：映射到三种类别的 OWASP Agentic Top 10

Agent 目标劫持（ASI01）： 文档中的隐藏 Prompt 可以改变 Agent 的目标。在 EchoLeak 事件中，隐藏指令把 Copilot 变成了数据外泄引擎。缓解措施：将数据平面（Agent 处理的内容）与控制平面（管理 Agent 的指令）分离。

工具误用（ASI02）： Agent 以非预期方式使用合法工具。这直接映射到类别 3 的边界控制。按工作流步骤限制工具访问。在执行前验证工具参数。

供应链漏洞（ASI04）： 即上文所述的恶意 MCP Server 事件。验证每个 MCP Server 和插件的来源。优先使用来自已知发布者的签名包。

级联故障（ASI08）： 错误信号通过管道传播，影响不断升级。一个不正确的工具结果被送入下一个 Agent 的推理，导致后者做出更糟的决定。缓解措施：在阶段之间设置断路器、以置信度阈值触发人工审查，并在检查点进行独立验证。

失控 Agent（ASI10）： Agent 出现未对齐行为，或做出超出范围的自主行动。缓解措施：长期监测行为（而不仅是验证单次操作）、建立预期模式基线、对偏差发出警报，并强制设置终止开关。

OWASP 强调一项贯穿全局的设计原则：最小自主权。 只授予 Agent 完成任务所需的最低自主权。这项原则与三类别框架直接对应。如果类别 1 能满足需求，就不要使用类别 2。不要给类别 3 Agent 留出超出特定探索步骤所需范围的自主空间。

本文中的每一个架构决策，归根结底都是安全决策。架构本身就决定了系统的安全状况。

评估与可观测性：让 Agent 可调试

传统软件失败时会产生堆栈跟踪，指向具体代码行。Agentic 系统的失败方式却足以让传统 SRE 头疼：LLM 在第 7 步做出一个听起来合理、实际却错误的决定，导致第 12 步的工具返回意外数据，进而让第 15 步的评估器批准了本应被拒绝的输出。

你无法调试看不见的东西。未做可观测性埋点的 Agent 就是黑箱。

传统监控为何失效

Agent 会以五种具体方式打破传统监控假设。

非确定性输出。 相同输入在不同执行中可能产生不同结果。你无法编写一项测试，断言“这个输入始终产生这个输出”。你需要根据评估标准，从多个维度（准确性、完整性、相关性）为输出评分，而不是进行完全匹配断言。

多步骤依赖链。 第 3 步发生的故障可能直到第 12 步才显现。跟踪系统需要捕获每一个中间状态、每一次 LLM 决策和每一个工具结果，方便事后重建因果链。

成本不可预测。 根据推理路径的不同，同一个任务可能让 Agent 消耗 500 个或 50,000 个 Token。按跟踪归因成本至关重要，否则每月账单会变成一个谜。

决策过程不透明。 Agent 为什么选择工具 A 而不是工具 B？为什么重试三次以后才改用其他方法？如果没有结构化跟踪记录每个决策点的推理上下文，调试就只能依靠猜测。

质量静默下降。 Agent 没有崩溃，只是开始生成稍差一些的输出。也许模型更新改变了它的行为。也许知识库发生了漂移。没有持续评估，你要等到用户投诉时才会发现。

可观测性栈

行业正在围绕 Agentic 系统的三层可观测性方法形成共识。

第 1 层：分布式跟踪。 OpenTelemetry 正逐渐成为 Agent 遥测的标准。Agent 运行表示为 trace（从开始到结束的完整任务），各个步骤则表示为 span（LLM 调用、工具调用、检索操作、评估检查）。如今，多个 Agent 框架（Pydantic AI、smolagents、Strands Agents、CrewAI）已经能够原生发出 OpenTelemetry trace。

对于基于 Temporal 的系统，你几乎不必增加成本就能获得跟踪能力。Temporal 的事件历史本身就是一条完整 trace，记录每次 Activity 执行、收到的每个 Signal 和每次状态变更。Temporal UI 将它们可视化为执行历史，无需额外埋点即可回到任意时间点调试。

第 2 层：持续评估。 大多数团队会跳过这一层，然后感到后悔。LLM-as-a-Judge 评估使用另一个独立 LLM，按正确性、相关性、幻觉和政策合规性等维度为 Agent 输出评分。Langfuse、Arize 等工具提供预构建评估器，可以针对生产 trace 自动运行。

评估循环的工作方式如下：生产 trace 揭示失败模式，失败模式被转化为评估数据集，评估数据集驱动回归测试，回归测试则在类似故障进入生产环境前发现问题。尽早建立这一循环的团队，能在几天内发现质量下降，而不是等上几周。

第 3 层：指标与告警。 除了检查单条 trace，你还需要汇总所有 Agent 运行的指标：按步骤统计的延迟中位数、p95 Token 消耗量、按工具统计的错误率、每项已完成任务的成本、按任务类别统计的成功率。当这些指标偏离既定基线时发出告警。

衡量什么

每次 Agent 运行至少都要采集以下维度的指标：

每步延迟。 哪些步骤最慢？LLM 调用花费 2 秒还是 20 秒？工具调用是否超时？按步骤拆分延迟，让你可以把优化集中在最重要的地方。

每条 trace 的 Token 消耗量。 总输入 Token、总输出 Token，以及每一步的 Token。这是你的主要成本驱动因素。留意消耗量达到中位数 10 倍的 trace，它们通常意味着存在推理循环，或上下文冗长得没有必要。

工具调用成功率。 每种工具成功、失败或超时的频率是多少？失败率达到 30% 的工具，要么配置有误，要么本身不可靠，无论是哪种情况，都会削弱 Agent 的性能。

按类别统计的任务完成率。 Agent 成功完成了百分之多少的任务？按输入类别（简单与复杂、已知模式与陌生请求）进行拆分，了解 Agent 在哪里表现良好，又在哪里遇到困难。

随时间变化的评估分数。 输出是在变好、变差，还是保持不变？如果模型更新后正确性分数下降，就说明即使总体基准测试有所提升，这次更新也导致模型在你的用例上出现效果退化。

按类别评估

类别 1 工作流最容易评估，因为输出结构可预测。你可以编写确定性断言：“路由步骤是否正确分类？生成步骤是否生成了有效 JSON？质量检查是否通过？”再把自动化断言与抽样 LLM-as-Judge 评估结合起来，评价不同的质量维度。

类别 2 自主 Agent需要轨迹级评估，而不只是输出评估。Agent 是否采用了合理的解决路径？是否高效使用工具？是否从故障中顺利恢复？SWE-bench 就是这样评估编码 Agent 的：不仅看“它是否生成了正确代码”，还要看“它是否找到了正确文件、进行了最少修改并通过测试套件”。

类别 3 混合系统两者都需要。以确定性方式评估工作流步骤。根据轨迹和输出质量评估 Agent 步骤。工作流边界让你可以隔离系统的哪个部分引发了故障，而纯类别 2 Agent 很难做到这一点。

决策框架：选择你的架构

你大概就是为了这一节收藏了本文。前面用一万多个英文词讲清了背景、模式和生产环境中的考量，下面把框架提炼成可执行的决策。

决策 1：选择哪个类别？

针对你的用例提出以下问题：

你能在运行前画出任务流程图吗？ 如果能，你可以提前定义每一个步骤、每一个分支和每一个条件，即使这些步骤包含提供智能能力的 LLM 调用。使用类别 1。 它涵盖了大约 80% 的生产 Agentic 用例。

任务分解本身就是难题吗？ 如果 Agent 需要先理解问题空间，然后才能决定采取哪些步骤，而且解决方案的结构确实不可预测，使用类别 2。 软件开发、深度研究和创造性问题解决都属于这一类。

你是否需要可预测的外部结构，同时保留探索空间？ 如果总体工作流已知，但特定步骤需要有限的自主权，使用类别 3。 研究管道、多 Agent 协调，以及任何既需要工作流可靠性又需要 Agent 灵活性的系统，都属于这一类。

拿不准时，从类别 1 开始。 以后随时可以增加 Agent 的灵活性，但一个从无结构起步的系统，很难再补上结构。

决策 2：选择哪些工作流模式？

对于类别 1，根据任务结构选择模式：

需要验证的顺序步骤？ 使用带验证关卡的 Prompt 链。

多种输入类型需要不同处理？ 使用路由。

可以同时运行的独立子任务？ 使用并行化。

在运行时确定子任务？ 使用编排器与执行器。

输出质量随迭代提高？ 使用评估器与优化器。

从最简单的模式开始。复合架构功能强大，但也很复杂。只在能够衡量改进时添加模式。

决策 3：你需要持久化能力吗？

如果 Agent 运行超过 30 秒： 需要。瞬时故障（网络中断、速率限制、容器重新调度）的概率会随执行时间线性增长。超过 30 秒，持久化能力带来的收益就会超过成本。

如果 Agent 会进行昂贵的 LLM 调用： 需要。在失败后重新启动的运行中，每个已消耗的 Token 都是浪费。持久化能力可以消除这种浪费。

如果 Agent 的结果必须保持一致： 需要。如果没有持久化能力，重启后的 Agent 可能会走上另一条路径，产生不同的结果。有了持久化能力，Agent 会恢复执行，结果与没有发生故障时保持一致。

对于能够管理基础设施的团队，Temporal 是默认推荐。Microsoft 原生团队可以选择 Azure Durable Functions。希望获得开源灵活性的 Kubernetes 原生团队可以选择 Dapr。

决策 4：选择哪些协议？

所有工具集成都使用 MCP。 没有例外。如果你的工具已有 MCP Server，就使用它。如果没有，就构建一个。自定义连接器的集成税已经不再合理。

当团队或组织之间存在真正的多 Agent 协调时，使用 A2A。单一团队的内部 Agent 不需要它。

决策 5：安全边界？

把每一项 OWASP ASI 风险映射到你的具体架构：

每个 Agent 可以访问哪些工具？ 按工作流步骤明确界定。

每个 Agent 可以读写哪些数据？ 遵循最小权限，而不是继承创建者的权限。

人工审批关卡设置在哪里？ 每个高风险操作都需要一个。

终止开关采用什么机制？ 你需要能够立即停止任何 Agent。

如何监测行为漂移？ 使用持续评估，而不只是在部署时测试。

回顾与后续步骤

模型非常出色，周围的一切却仍是一团糟。这正是你的机会。

从类别决策开始。 大多数问题都属于类别 1。五种工作流模式能带你走得比预期更远。

先实现持久化能力，再追求聪明。 如果你的 Agent 无法在崩溃后恢复，其他一切都无关紧要。

把安全作为架构，而不是事后补救。 OWASP Agentic Top 10 不是一张留到最后审查的检查清单。它是一组设计约束，从白板上画下第一张草图起，就开始塑造你的系统。

你有 15 年设计系统、处理故障、权衡取舍，以及判断何时该保持简单的经验。这些经验并没有过时，而是当下最重要的能力。AI 负责编写代码，你负责设计一个让这些代码值得被写出来的系统。

下面是一篇与本文标签相关的文章。