AI Agent 架构设计：从单智能体到可靠的生产系统

设计 AI Agent 架构，先从一个能调查问题、提出操作建议，并在执行前等待审批的智能体做起。模型和通用基础设施可以采购；业务规则、权限边界，以及证明任务确已正确完成的证据，则需要自己构建。

客服智能体能把客户消息与正确的账户、政策和操作关联起来，才算有用。而要让它值得信赖，外围应用还必须说得清它访问了什么，拦得住未经授权的变更，并能在工具出错后恢复处理。

可以把这套系统想成交通网络：模型负责选路线，工具通往各个目的地，记忆保存沿途信息，编排负责调度。防护机制和审批关口控制通行权限；评估与日志则用来确认乘客有没有到达正确的地方。

下文对各组件的说明，已于 2026 年 10 月 25 日对照 Anthropic、OpenAI、Google Cloud 的资料及 Model Context Protocol 规范核实。文中的客服流程是设计示例，不代表某个客户系统已按此部署。

AI Agent 架构：哪些由模型决定，哪些由系统负责？

架构要划清两件事：模型可以选择什么，应用必须强制执行什么。这条边界比选哪个框架更重要。

Anthropic 提出的增强型大语言模型（augmented LLM），也就是接入检索、工具和记忆的语言模型，适合作为基础组件。其指南区分了两种方式：工作流的路径由代码预先规定，智能体则动态选择下一步操作。指南建议，只有任务确实需要时，才增加复杂度。Anthropic 智能体构建指南

以客服分流为例，模型可以决定先搜索故障排查指南，还是先查看订单。但它能读取哪个客户的记录、退款建议是否获准，以及运行中途停止后该怎么办，仍应由应用代码决定。

可预测的工作就按确定的规则执行。账户身份验证、权益检查、已完成操作的记录，都不需要智能体临场发挥。把有不确定性的部分交给模型：理解消息、挑选相关证据，并提出有用的下一步建议。

AI Agent 架构图：各层如何连接？

智能体需要一个受控的执行循环，周围配有持久化状态和检查机制。下面的各层代表不同职责，不意味着每一层都要单独部署服务或购买订阅。

把图中的连接看成一个循环：应用组装上下文，模型请求操作，运行时检查并执行操作，再把结果加入上下文，供下一次决策使用。智能体执行循环指南详细介绍了这一过程及其停止条件。

模型：理解问题，提出下一步操作

OpenAI Agents SDK 是用于构建智能体工作流的开发库，它把模型、指令和工具封装在一个 Agent 中；模型负责理解工单，并提出下一步该做什么。在本设计中，模型收到客户无法访问账户服务的问题后，会先请求相关权益记录，再起草回复。选择模型时，应使用有代表性的客服案例进行评估：文笔流畅，并不能证明它选对了工具，也不能证明它有权执行操作。OpenAI 智能体定义文档

工具与 MCP：接入业务系统

Model Context Protocol（MCP）为 AI 应用与外部能力提供标准接口。它通过 inputSchema 定义具名工具，用 tools/list 发现工具，再用 tools/call 调用。账户查询既可以通过 MCP 提供，也可以通过调用业务 API 的普通函数实现；无论采用哪种方式，后端服务都必须校验参数，并确保只能访问获准访问的账户。MCP 统一的是连接方式；MCP 详解进一步说明了协议及其信任边界。MCP 工具规范

记忆：保留合适的上下文

Google 的智能体开发框架 Agent Development Kit（ADK）使用 Session 和 state 管理一次交互内的信息，并通过 Memory Bank 等组件支持跨会话记忆。用于客服时，应把当前问题和待审批事项存入应用自己的存储，从源系统获取最新账户事实，仅在适当时保留客户偏好。这几件事要分开设计；智能体记忆指南解释了上下文、会话存储与长期记忆的区别。Google Cloud 架构指南

编排：管理进度、暂停与恢复

OpenAI 的智能体构建指南将 Agents SDK 描述为处理工具循环、任务移交和防护机制的组件，为应用提供模型驱动任务的运行器。在运行器之外，还要持久化工单处于调查、待审核、执行中还是已完成状态，确保进程重启后仍能继续处理。智能体编排指南介绍了如何将智能体运行嵌入更长的业务流程。OpenAI 智能体构建指南

防护机制与人工审批：控制操作后果

OpenAI Agents SDK 将自动防护检查与审批中断分开处理；后者会暂停工具调用，并返回可用于恢复运行的状态。对客服智能体来说，应自动校验账户访问权限和拟用参数，再由获授权的人员批准敏感变更，之后才能执行。把强制检查放在真正产生业务操作的工具旁边；AI 防护机制指南详细说明了这些检查。OpenAI 防护机制与人工审核文档

评估与可观测性：还原过程，判断结果

OpenAI Agents SDK 的链路追踪会记录模型调用、工具调用、任务移交和防护活动；其链路评分指南则说明了如何按明确标准对工作流行为评分。可观测性让你看清一张客服工单经历了什么；评估则检查智能体是否选对账户、遵循政策，并给出了有依据的回答。先明确采集和保留哪些数据，再比较 LLM 可观测性工具。SDK 链路追踪文档、智能体评估文档

Google Cloud 的参考架构将 ADK、Cloud Run、模型访问、MCP 连接、Model Armor 和可观测性组合成一个具体的部署方案。文档明确说明，示例图省略了记忆和会话存储，因此工单状态如何持久化仍需自行设计，不能默认方案已经包含。参考架构

从收到工单到解决问题，流程怎么走？

交给智能体的问题应有明确边界，完成与否也应可验证。这个示例中，客户表示已经付费，却仍无法使用服务；智能体可以调查并准备修正方案。在初期上线阶段，账户变更和发给客户的回复都由客服负责人审批。

下面的工具名称代表需要自行实现的应用函数，并非厂商提供的现成客服集成。

1. 1

   接收工单，确认身份

   工单 webhook 是客服系统发送的事件，应用据此用工单的外部标识创建或恢复处理记录。通过现有账户流程验证客户身份；不能仅凭消息里填写的邮箱地址，就认定其有权访问相应账户。将收到的消息作为不可信的客户内容保存。

2. 2

   通过职责受限的工具获取证据

   为智能体提供 get_account_entitlement 和 search_support_policy 这类能力。在应用代码中，将账户访问范围绑定到已验证的身份，并返回相关记录和政策引用。这样，模型可以选择需要哪些证据，而不必获得不受限制的数据库访问权。

3. 3

   形成有证据支持的方案

   模型对照客户描述、账户记录和适用政策。如果证据支持修正账户权益，就起草拟议变更和回复；如果证据缺失或相互矛盾，就请求补充信息或升级处理。将证据引用与方案一起保存，便于审核人检查依据。

4. 4

   在执行实际业务操作前暂停

   按政策校验拟议操作，再保存待执行操作与审批状态。向客服负责人展示受影响的账户、具体变更、支持证据及拟发给客户的回复。若审批被拒，继续阻止写入，并将工单退回修改或转交人工处理。

5. 5

   执行操作，核实结果

   审批通过后，重新确认账户和方案仍与审核时一致，再调用修正工具。如果后端服务支持，就使用幂等键，即防止重试时重复应用同一操作的标识。先确认变更后的权益状态，再发送声称访问权限已恢复的回复；记录发送结果后，才能将工单标记为完成。

6. 6

   将处理结果纳入评估

   把执行结果、已批准的回复和工单最终状态关联到同一条追踪记录。结果不确定时交给人工判断，不要把超时直接当成成功或失败。审核发现错误后，将经过适当脱敏的案例保留在评估集中。

尤其要处理好写入结果不明的情况：账户服务可能已完成变更，只是应用没有收到响应。重试前，先与源系统核对状态。对话记录里写着“我会恢复访问权限”，只能证明有这个意图，不能证明权限真的变了。

AI Agent 架构模式：什么时候值得增加一个智能体？

只要任务能共用一套协调一致的政策、工具和责任归属，就先保留单智能体。只有当专业智能体能解决明确的职责拆分问题时，才考虑引入，并验证新增协作成本后，收益是否仍然成立。

OpenAI 区分了两种模式：**移交（handoffs）**由专业智能体接管对话；**将智能体作为工具（agents as tools）**则由主智能体调用专业智能体，但仍负责最终回复。其指南建议，当指令、能力或政策存在实质差异时，再进行拆分。编排与任务移交文档

在客服场景中，搜索帮助文章和起草回复，并不天然需要两个智能体。账单争议则可能值得单独处理：它可能涉及不同政策、受限的财务工具，以及不同的审核人。可以让专业智能体在限定范围内给出判断，仍由客服智能体负责整张工单；如果应由账单流程接管，也可以明确移交处理责任。

多智能体架构图：沿职责边界拆分

政策不同是一个有用的拆分信号，但不是唯一条件。相互独立的证据收集任务，也可能适合交给并行执行单元；前提是最终负责人能够协调相互矛盾的结果，而且实际收益足以抵消额外的模型工作量。

增加专业智能体前，先写清它要修复什么问题：工具选错、指令冲突、上下文过多，还是缺乏专业知识。用同一批案例比较新旧设计，失败案例也要纳入。只有当结果改善足以抵消新增的延迟、用量、调试和审核工作时，才保留新设计。这是一条决策原则，不是性能提升的承诺。

给智能体起名叫“研究员”“评审员”“经理”，并不会让它们自动具备独立判断能力。如果共用的证据本来就错了，它们得出一致结论，也可能只是重复同一个错误。更完整的分类可参见 AI 智能体类型指南。

AI 智能体架构落地：哪些可以买，哪些必须自己掌握？

通用且可替换的基础组件可以买，业务约定要自己掌握。构建首个生产级智能体时，最有力的自建理由是：工作流需要某种行为，而现成组件无法实现或开放这种能力。

**给创始人：**如果托管智能体产品支持你的实际工作流、审批边界和证据导出，就可以采购。如果针对特定账户的政策或集成行为构成业务差异化，就围绕标准组件构建。演示再出彩，若无法恢复暂停的工单，或查清一次失败的操作，也还不够。

**给 CTO 和开发者：**业务工具的职责要窄，并且能够脱离模型独立测试。托管运行时可以承载应用，但它无法自行区分“提出退款要求的客户”和“有权发放退款的员工”。执行操作的服务必须明确区分两者。

**给运营负责人：**负责异常队列，并定义何时才算解决。明确未解决的工单由谁接手、接手人能看到哪些证据，以及何时允许关闭工单。审批收件箱无人处理，意味着工作流还没有完成。

这个客服智能体不一定需要执行代码。如果后续任务必须运行生成的代码，应单独评估隔离方案，并参考智能体代码沙箱指南；不要只是为了查询账户，就引入通用 shell。

人工审批放在哪里？上线之初该记录什么？

需要授权的操作，必须在执行前紧接着设置审批。如果账户已经变更，再去审核智能体写的文字，也阻止不了这次变更。

OpenAI 的审批机制会返回已暂停的运行及可恢复状态；应用处理待定决策后，再恢复执行。同一份文档也提醒，智能体级别的输入和输出检查并不会覆盖每一次中间工具调用，因此操作边界必须有独立校验。审批生命周期与工作流边界

在这个上线示例中，审核人会同时看到具体的账户变更和拟发送的回复。如果审核后操作、收件人或证据发生变化，就需要重新审批。记录清楚谁批准了什么、适用哪项政策，以及实际执行是否符合批准内容。

可以从下面这套日志约定起步。**追踪（trace）**将同一工单的各个事件串起来；**跨度（span）**记录其中的一次具体操作。

• **工单身份：**工单标识、追踪标识、来源事件和已验证账户的引用。尽量使用引用，避免到处复制客户资料。
• **配置：**供应商返回的模型标识、指令版本、工具 schema 版本和政策版本。这些信息用于解释当时生效的是哪套行为配置。
• **证据：**检索到的文档标识、相关修订版本和访问范围。记录决策依据，避免不加选择地复制私密记录。
• **操作：**工具名称、脱敏后的参数、时间戳、耗时、结果状态，以及重试或幂等标识。保留足够信息，区分拟议操作与已完成操作。
• **决策：**校验结果、升级处理原因、审批状态、审核人引用和获批方案。
• **结果与用量：**工单最终状态、已确认的实际变更、消息送达结果、供应商报告的用量和评估标签。如果客服系统提供相关信息，也应跟踪客户纠正反馈或重新打开的工单。

这是建议采用的应用数据结构，并不意味着 SDK 会自动采集所有字段。限制访问、设定保留期限，并在导出前脱敏密钥等机密信息。不要把模型隐藏的推理过程列为日志必备项；审计记录应建立在可观察的输入、输出、操作和证据之上。

哪些边界最重要？哪些能力被高估了？

最重要的边界，是你授予了多大的权限。为运行时长、工具活动和资源使用设定明确上限，并提供清晰的升级处理路径。具体数值应来自实际负载和服务要求，而不是随手照搬某个演示里的限制。

**记忆不能充当权威事实来源。**如果保存的对话说客户有访问权限，账户系统却给出不同结果，应对照最新的权威记录调查差异。记住更多文字，并不能修复过时的证据。

**接入 MCP 不等于获得操作授权。**MCP 工具规范仍然要求访问控制和输入校验。如果连接器暴露的操作范围很广，就应和自定义 API 一样接受业务授权审查。MCP 安全要求

**运行结束，不代表问题已经解决。**评估时要确认：改的是不是正确账户、是否遵守政策、回复是否与实际结果一致。OpenAI 的评估指南从检查追踪记录进一步延伸到可重复使用的数据集，以便按一致标准判断变更效果。智能体工作流评估

**多个智能体，也必须有人对结果负责。**最终答案、共享证据和未解决的异常都要有明确负责人。专业智能体的价值来自职责差异，而不是让架构图显得更高级。

AI Agent 架构常见问题

什么是 AI Agent 架构？

AI Agent 架构，是对模型决策、工具、记忆、编排、控制机制和评估的整体安排，让应用能够围绕任务采取行动。对于业务智能体，架构还决定谁有权批准操作，以及如何验证任务已经完成。

AI Agent 是什么？

AI Agent 利用模型选择有助于达成目标的操作，观察结果，再决定如何继续。它能自主行动到什么程度，取决于应用提供的工具、权限和停止规则。

智能体架构有哪些类型？

一种实用的区分方式是：预定义工作流、在工具之间自主选择的单智能体，以及相互协作的专业智能体。具体选择取决于任务有多可预测，以及不同职责是否需要各自的工具、政策或责任归属。这些是实现模式，不是通用的分类体系。

智能体开发的第一步：先画清工单流程，再选技术栈

如果你已经有重复出现的客服工单、可访问的源记录，以及负责异常处理的人，就可以开始。选一个有代表性的案例，标出输入事件、允许读取的内容、拟执行的写入、审批点，以及关闭工单所需的证据。初期先让系统起草方案、交由人工审核，再根据实际暴露的问题，决定哪些权限可以审慎放开。

如果账户身份、政策归属或完成证据尚未明确，就先缓一缓自主执行。在补齐这些前提的同时，仍然可以改进检索和草稿质量。如果现有流程已按可靠的确定性规则运行，不需要模型判断，就保留这套自动化。

第一份交付物，应该是一个从接收到结果都能讲清楚的案例，包括审批被拒，或工具结果不明时会如何处理。

想获取构建和运营 AI 系统的实用指南，可以订阅邮件通讯。