AI Agent 应用架构，是一套让大模型围绕业务目标持续感知、判断、调用工具并交付结果的系统组织方式。它要回答的核心问题是，模型之外的部分如何分工和协作：任务从哪里进入，谁负责拆解和编排，模型能看到哪些信息，可以调用哪些工具，在什么环境里执行，出错后如何恢复，结果由谁验收。
在企业语境里，这套安排决定了 Agent 能不能从演示走向生产。同样一个大模型，放在不同的应用架构里，表现可能相差很远。也正因如此，评估企业级 AI Agent平台时，只看模型参数或演示效果，很难判断它能否承接真实业务。
AI Agent 应用架构是什么
如果只用一句话回答 Agent 应用架构是什么意思，可以概括为：它描述一个 Agent 应用由哪些责任部分组成、这些部分如何协作、在哪里运行，以及如何被约束和改进。
这里有三个容易混淆的视角，可以分开看。
- 组件视角回答系统由什么组成，例如模型、编排逻辑、上下文、记忆、知识、工具、运行时、沙箱、网关、观测和评估。
- 平台视角回答这些组件在哪里运行、由谁负责，例如哪些能力由业务团队自建，哪些由共享平台提供。
- 生命周期视角回答系统如何从设计走到运行，再通过版本、轨迹、评估和回滚持续改进。
三个视角不能互相替代。组件齐全，不代表责任清晰；责任清晰，也不代表变更可控。一套架构是否成立，取决于责任边界是否清楚。责任边界清楚，比组件清单够长更重要。
阿里云《AI Agent 开发实战手册》把企业级 Agentic Application 的参考架构拆成业务与应用、构建与编排、生产运行、治理与控制、调优五个责任域。这个划分值得借鉴的地方在于，它先问谁负责，再问用什么组件。
和普通大模型应用、工作流有什么区别
区别主要在控制流。
Anthropic 在 2024 年 12 月的工程文章《Building effective agents》中给了一个清晰划分：工作流由预先写好的代码路径编排模型和工具；Agent 则由模型动态决定自己的执行过程和工具使用。前者追求可预测，后者适合步骤难以预先穷举的任务。
用一个执行循环来看，Agent 通常会经历目标理解、计划、行动、观察结果、调整计划，直到满足停止条件。Agent 的关键特征在于根据环境反馈决定下一步；工具调用只是其中一环。
| 形态 | 控制流 | 适合的任务 | 主要代价 |
|---|---|---|---|
| 单次模型调用 | 输入到输出 | 分类、摘要、翻译等单步任务 | 无法持续行动 |
| 固定工作流 | 代码预先规定路径 | 步骤稳定、依赖清楚的流程 | 遇到未预设分支容易中断 |
| 单 Agent | 模型在循环中动态决策 | 单一领域、工具较多、步骤不完全确定 | 成本、延迟和错误累积 |
| 多 Agent | 多个 Agent 分工与协调 | 跨领域、需要并行或不同安全边界 | 协调开销、故障模式增加 |
Microsoft Azure 架构中心的 Agent 编排指南也给出类似判断：企业场景的常见默认值是带工具的单个 Agent，只有当任务跨领域、需要并行专业化，或不同 Agent 需要不同安全边界时，多 Agent 才值得引入。
AI Agent 应用架构包含哪些层
不同厂商的参考架构名称不完全一样，但责任域高度相似。按从业务目标到运行治理的顺序，可以分成七层。
| 责任域 | 主要解决的问题 | 常见组成 |
|---|---|---|
| 业务与应用 | 为什么做、谁来用、什么算完成 | 对话入口、API、消息或定时触发、验收规则 |
| 编排 | 模型看到什么、下一步做什么、何时停 | 执行循环、指令与上下文、计划、工具与 Skill 管理、人工审批、结果校验 |
| 模型 | 理解、推理和工具调用决策 | 通用模型、领域模型、模型路由、降级策略 |
| 上下文与知识 | 这次调用需要哪些信息，组织知识从哪里来 | 上下文、任务状态、记忆、知识库、语义层、Skill |
| 工具与协议 | Agent 如何连接外部系统并产生影响 | API、函数调用、MCP、A2A、浏览器与代码执行 |
| 运行 | 任务在哪里持续、稳定、隔离地执行 | Runtime、沙箱、状态存储、网关、队列 |
| 治理与调优 | 谁被允许做什么，如何看见问题并改进 | 身份与权限、策略、审计、可观测、评估、版本与回滚 |
MCP 指模型上下文协议，负责把工具和资源以标准方式连接给模型；A2A 指 Agent 间协作协议，用于 Agent 之间的任务委派和状态交换。
这张表适合用来查漏，不适合当成建设清单。多数 Agent 不需要七层齐全；被授予的自主性越大，对应的运行和治理能力就越不能省。
编排层决定模型看到什么、能做什么、何时停
编排层是模型与运行环境之间的工程逻辑，负责构造上下文、组织任务循环、提供能力、约束行为并验证中间结果。
生产级编排通常要处理执行循环与终止条件、指令与上下文工程、任务拆解与委派、工具和 Skill 管理、策略钩子、长任务续接、人工审批和完成前校验。缺少终止条件，任务可能陷入循环；缺少工具结果校验，工具报错会被误当成模型判断错误；缺少完成前验证，任务可能看起来完成，结果却不可信。
上下文、状态、记忆、知识不是一回事
这几个词经常被混用，但在架构上承担不同责任。
| 对象 | 回答的问题 | 典型内容 |
|---|---|---|
| 上下文 | 这次模型调用应该看到什么 | 系统指令、任务说明、历史摘要、检索结果 |
| 状态 | 任务已经发生了什么、从哪里恢复 | 计划、待办、检查点、工具调用状态 |
| 记忆 | 过去哪些经验对当前任务有用 | 用户偏好、历史决策、跨会话事实 |
| 知识 | 组织已经有哪些知识可供检索 | 业务文档、指标定义、制度、产品资料 |
| Skill | 某类任务应该怎么做 | 方法说明、脚本、模板、检查清单 |
把它们全部塞进一个向量库，短期看省事，长期会同时失去权限、时效、版本和遗忘机制。知识决定 Agent 答得对不对，状态决定任务断了能不能接着做，两者不能用同一套治理方式。
运行与治理决定能不能上线
Runtime 负责任务生命周期，包括排队、并发、超时、重试、检查点和恢复。沙箱限制行动的影响范围，包括文件、网络、凭证和代码执行。状态存储把任务事实放在模型上下文之外，避免上下文压缩改变任务事实。网关统一处理模型调用、工具调用和任务预算。
治理与控制则回答谁可以发布、运行和修改 Agent，哪些资源可以被访问，版本如何流转，策略如何审计。观测、评估和安全更适合被当作运行前提。没有轨迹，就无法复现问题；没有版本化的发布单元，就无法证明一次改动真的带来了改进。企业需要把Agent 治理放进架构设计，等上线后再补流程，成本通常会更高。
单 Agent 还是多 Agent，怎么选
判断依据是任务结构，行业热度不能替代它。
带工具的单个 Agent 能覆盖不少企业场景。它能在一个领域内理解多种请求，按需调用数据库、搜索或业务 API，并通过循环修正结果。它的调试和测试相对简单，责任边界也更清楚。
多 Agent 的价值主要出现在三类情况：
- 任务跨多个专业领域，单个 Agent 的指令和工具集已经过载；
- 不同子任务需要并行处理，串行执行会明显拖慢结果；
- 不同 Agent 需要不同的数据权限或安全边界。
常见的编排方式有顺序、并发、交接、群聊和动态计划。顺序编排像一条流水线，适合阶段依赖明确的任务；并发编排让多个 Agent 同时从不同角度分析，适合时间敏感且结果可汇总的任务；交接编排把控制权转给更合适的专家，适合处理过程中才明确需求的场景；群聊编排通过共享对话做评审和共识；动态计划则由管理 Agent 维护任务账本，边执行边调整计划。
多 Agent 的代价也要算清楚。每增加一个 Agent，就增加一次模型调用、一段上下文传递和一组新的故障模式，协调开销、延迟和成本都会上升。多 Agent 是一种任务组织手段，不应当作架构成熟度的标志。 如果单个 Agent 加足够的工具和知识就能稳定完成，优先保持简单。需要用团队方式组织多个 Agent 时，可以参考多 Agent 协作的实践路径。
一个数据分析场景，把架构走一遍
假设运营负责人问：上周新用户次日留存为什么下降？
一个完整的 Agent 应用会按架构分工推进，模型不直接凭感觉作答。
- 入口层确认提问人身份、可访问的数据范围和期望的输出形式。
- 编排层把问题拆成几个子任务：确认指标口径、拉取分渠道和分版本数据、定位下降出现的节点、检查同期产品变更、生成结论。
- 知识层提供“次日留存”的统一定义、埋点规则和近期版本记录。指标口径不清，后面算得再快也没有意义。
- 工具层调用数仓查询、漏斗分析和日志检索，每次调用都经过权限判定和参数校验。
- 分析 Skill 按固定方法执行分群对比，避免每次分析都从零组织步骤。
- 校验环节检查样本量、时间范围和口径是否一致，再把结论、图表和来源一起输出。涉及发券或推送等动作时，进入人工审批。
- 运行层保存任务状态和中间结果，治理层记录轨迹、成本和数据访问，便于复盘。
同一句问题，如果知识层没有统一指标定义，不同 Agent 可能给出不同答案；如果运行层不保存状态，任务中断后只能重来；如果治理层没有审计，出了问题很难定位是模型、工具还是数据口径的责任。在企业场景里，知识治理和结果验证往往比换一个更强的模型更能改善 Agent 的表现。 这也是统一指标口径需要作为架构基础设施来建设的原因。
这也是 ThinkingAI 在企业级知识库上的切入点。它把企业文档、指标定义和业务规则加工成结构化、可追溯的知识，作为 Agentic Engine 的基础设施层，供客服问答、SQL 生成和数据分析等不同 Agent 共用。Agentic Engine 支持多 Agent 协作和私有化部署，适合对数据边界和运行环境有要求的企业。
判断架构是否够用的五个条件
- 结果能不能验证？ 有没有明确的验收标准、测试集或人工复核点，能否判断任务真的完成。
- 权限是否与自主性匹配？ Agent 能访问多少数据、调用多少工具、执行哪些不可逆动作，是否遵循最小权限。
- 状态能不能恢复？ 任务执行到一半中断，计划、工具结果和中间产物是否还在。
- 知识和口径是否可追溯？ 答案引用了哪份文档、哪个指标定义、哪个版本，能否回溯。
- 失败能不能看见并回滚？ 有没有轨迹、成本、延迟和错误记录，版本能否灰度、回滚。
这五个问题对应的是一套最低充分架构的思路：先识别任务的可预知程度、影响范围、数据敏感度、时间跨度和业务风险，再决定需要多少自主性和多少治理能力。原型阶段可以用应用内嵌 SDK 快速验证；数据边界允许时，托管运行时能省去不少基础设施工作；对数据主权和合规要求高的企业，更适合控制面与执行面分离，或采用完整的私有化部署。
架构的目标是让每一项被授予的自主性都有对应的边界、证据和验证手段。 组件可以少，边界不能缺。
FAQ
AI Agent 应用架构和微服务架构有什么区别？
微服务架构按业务能力拆分服务，重点在服务边界、通信和部署。Agent 应用架构在此之上增加了认知与决策循环：模型要根据环境反馈选择下一步，工具调用是非确定性的，版本不仅包括代码，还包括模型、提示词、知识、Skill 和评估基线。Agent 可以运行在微服务之上，但治理对象不一样。
一定要上多 Agent 吗？
不一定。带工具的单个 Agent 通常更适合作为企业场景的起点。只有当任务跨领域、需要并行专业化，或不同 Agent 必须隔离权限时，多 Agent 带来的协调成本才可能被收益抵消。
企业应该自建还是采购 Agent 平台？
自建还是采购，先看哪些能力构成自己的差异化。业务特有的提示词、Skill、工具、评估标准和人机协作流程，通常值得自己掌握；模型接入、任务托管、沙箱、状态存储、可观测和评估基础设施，更适合作为共享平台能力。数据边界、合规要求和长期运维成本，往往比功能清单更能决定最终选择。
架构中最容易被忽略的部分是什么？
任务状态和完成前验证。演示阶段通常只关注回答是否像样，进入生产后，任务中断能否续跑、结果能否复核、错误能否定位，才是更常见的失败点。
需要哪些团队角色参与？
业务负责人定义目标和验收标准，Agent 工程师负责编排和工具，数据和知识负责人维护口径与权限，平台与安全团队负责运行和治理，评估角色负责测试集和回归。角色可以合并，但责任不能空缺。
参考资料
- Anthropic，《Building effective agents》，2024 年 12 月，https://www.anthropic.com/engineering/building-effective-agents
- Microsoft Azure Architecture Center，《AI agent orchestration patterns》，https://learn.microsoft.com/zh-cn/azure/architecture/ai-ml/guide/ai-agent-design-patterns
- 阿里云，《AI Agent 开发实战手册》第 2 章《Agentic Application 参考架构》，https://aliyun.github.io/ai-agent-handbook/architecture/chapter-02.html
