概念 MLOps / 平台

智能体架构(Agent Architecture):企业级设计、治理与采购决策指南

LLM智能体架构定义模型、工具、状态、记忆和控制循环的组织方式。本文说明单Agent与多Agent模式、顺序、并行、交接和动态编排,以及企业部署中的安全、成本、评估和基础设施要求。

智能体架构Agent ArchitectureAI AgentLLM Agent多智能体Agent 编排工具调用人在回路Agent 安全LLMOps
Slug
agent-architecture
更新
2026-07-23
来源
4
关系
3

智能体架构是什么:摘要与决策结论

摘要 / 导语:智能体架构是组织模型、提示词、知识、工具、状态、编排、策略和运行环境的一套系统设计,使大模型能够在受控边界内完成多步骤任务。它不是“选择一个 Agent 框架”,更不是把多个模型串起来;架构是否成立,要看任务成功率、权限可控性、故障恢复、可观测性和单位任务成本。

企业应从最低必要复杂度开始:能用一次模型调用完成的任务,不需要 Agent;能用确定性工作流完成的流程,不应交给模型自由规划;单智能体可以稳定处理时,不应为了概念先进而引入多智能体。多智能体只有在专业分工、权限隔离、并行分析或上下文分治带来可验证收益时才值得采用。

默认起点:单智能体 + 少量、边界清晰的工具 + 明确的迭代上限。

生产前提:工具最小权限、敏感动作审批、状态持久化、全链路追踪、离线评测集和故障降级。

采购原则:围绕业务任务和风险预算选平台,不以 Agent 数量、框架数量或“自主程度”作为先进性指标。

企业级 Agent 由哪些能力层组成

能力层职责关键设计问题
模型与模型网关推理、模型路由、配额、重试、降级和版本切换模型是否可替换;数据是否出域;如何控制 token、并发和超时
上下文与知识系统指令、会话上下文、RAG、结构化业务数据和缓存知识来源是否可信;是否按用户权限检索;如何防止上下文污染
工具与集成调用 API、数据库、搜索、代码执行和业务系统输入输出模式、身份传递、幂等性、超时、补偿和审批点如何定义
规划与编排任务分解、路由、循环、并行、汇总和终止条件哪些步骤必须确定;最大步数是多少;失败后重试还是转人工
状态与记忆保存会话、任务进度、检查点、用户偏好和必要的长期知识哪些状态必须持久化;保留多久;如何删除、更新和隔离
策略与安全鉴权、授权、内容策略、工具策略、密钥和审计模型建议与系统授权是否分离;高风险动作是否强制人工批准
评测与可观测性追踪模型调用、工具调用、路由、延迟、成本和结果质量能否复现失败;能否定位到具体提示词、模型、工具和数据版本
运行与交付API 服务、队列、容器、弹性、灰度、回滚和灾备SLA、并发、数据驻留、峰值容量和依赖故障如何处理

“记忆”不等于必须采购向量数据库。短期任务状态可以使用关系数据库、键值存储或工作流检查点;只有当需要基于语义检索长期内容时,才考虑向量检索,并同时解决数据更新、删除、权限过滤和召回质量问题。

从模型调用到多智能体:复杂度如何分级

架构级别适合任务优势新增风险与成本
直接模型调用分类、摘要、抽取、改写等单步任务延迟低、成本清晰、易测试复杂任务能力有限
确定性 AI 工作流步骤已知的文档处理、审核、生成流水线流程可预测,便于设置质量门禁灵活性较低,流程变更需修改编排
单智能体 + 工具同一领域内需要动态选择检索、查询或操作工具兼顾灵活性与可控性,通常是企业首选可能出现循环、误调用和上下文膨胀
多智能体编排跨领域协作、权限边界不同、可并行的专业分析角色专门化、上下文分治和独立优化协调开销、延迟、成本和失败模式显著增加

关键边界:确定性业务规则、金额计算、权限判断和核心交易写入应由传统代码或规则引擎控制。Agent 可以提出建议或选择已授权工具,但不应成为绕过业务校验的“超级权限入口”。

主流编排模式及选型依据

模式工作方式适用场景重点防范
顺序 / 流水线按预定义次序执行,前一步输出进入后一步起草—审核—修订、解析—抽取—验证早期错误级联;链路过长导致延迟和成本上升
并行分析多个角色独立处理同一输入,再由汇总器合并风险、合规、技术、财务等多维评估结果冲突、重复 token、峰值并发和汇总偏差
路由 / 交接根据意图、领域或权限把任务交给专业 Agent客服分流、多产品技术支持、跨部门服务台错误路由、循环交接和上下文泄露
生成—校验闭环生成者产出,校验者按量化规则反馈,达到门槛或上限后结束代码审查、报告质检、合规检查无限迭代;校验标准不明确;两个角色共享同类偏差
管理者—工作者中央管理者动态拆解任务、分配工作并调整计划步骤无法完全预先确定的复杂研究和问题处置规划漂移、难以收敛、工具越权和状态恢复复杂

这些模式是技术无关的架构方法,不应与某一家框架绑定。实际系统可以组合模式,例如先确定性路由,再并行分析,最后进入人工审批;但每增加一层协调,都应有可测量的质量收益。

生产级参考架构应具备什么

  • 统一入口:API 网关负责身份认证、租户识别、限流、请求大小、内容安全和审计关联 ID。
  • 编排运行时:维护任务状态、步数上限、超时、重试、幂等键、检查点和人工审批恢复。
  • 模型网关:屏蔽不同模型 API 差异,执行模型路由、配额、缓存、降级和版本灰度。
  • 工具注册与策略:工具使用结构化输入输出;凭据由运行环境注入;按用户、Agent、动作和数据域授权。
  • 知识与状态存储:区分业务事实、会话状态和可选的长期记忆,分别设置一致性、保留和删除策略。
  • 异步与事件机制:长任务采用队列或工作流引擎解耦,不让同步请求无限等待;支持取消和结果回调。
  • 可观测与评测:记录每次模型调用、工具调用、交接、审批、异常、token、延迟和结果评分,同时避免日志泄露敏感信息。
  • 降级与人工接管:模型不可用、工具异常、低置信度或高风险动作时,能够返回受控结果或转人工。

安全与治理:Agent 最大的采购分水岭

Agent 的风险来自“非确定性模型输出”与“可产生真实影响的工具权限”结合。平台应至少覆盖以下控制:

  • 提示注入隔离:把外部文档、网页和工具返回值视为不可信数据,不允许其覆盖系统策略或授权逻辑。
  • 最小权限与短期凭据:Agent 不持有通用管理员账号;工具按动作授权,使用短期、可撤销的身份凭据。
  • 参数校验和业务复核:模型生成的工具参数必须通过结构、范围、业务规则和权限校验。
  • 高风险动作审批:付款、删除、发布、权限变更、外发敏感信息等操作设置强制人在回路。
  • 循环与资源控制:限制最大步数、最大 token、工具调用频率、任务时长和预算,防止失控消耗。
  • 多智能体隔离:Agent 间只共享必要上下文,交接时重新执行权限判断,不能继承对方全部能力。
  • 记忆治理:防止恶意或错误内容写入长期记忆;支持来源追踪、纠错、删除和过期。
  • 供应链治理:审查模型、插件、工具、MCP 服务、镜像和依赖来源,建立版本锁定与漏洞响应机制。

延迟、容量与成本如何测算

Agent 单任务成本可按以下思路拆解:

单任务成本 ≈ 模型调用次数 × 单次 token 成本 + 工具/API 成本 + 检索与存储成本 + 运行与运维分摊

容量规划不能只看最终用户并发,还要考虑一个任务内部的调用放大。例如 100 个并发会话,每个任务平均触发 6 次模型调用和 4 次工具调用,其下游峰值并发可能远高于 100。并行 Agent 会降低部分墙钟时间,但会抬高瞬时算力、限流压力和失败重试量。

  • 延迟预算:分别设定模型、检索、工具、审批和总任务的 P95/P99 时限。
  • 模型组合:路由、抽取等任务可评估小模型;复杂推理再使用强模型,并以真实质量验证。
  • 上下文控制:使用摘要、结构化状态和检索替代无限增长的完整对话,避免成本和注意力稀释。
  • 缓存与复用:只缓存可安全复用且具有明确失效策略的结果,避免跨租户或过期信息污染。
  • 私有化资源:根据输入/输出 token、模型并发、上下文长度、量化精度和 SLA 实测 GPU 显存与吞吐。

平台采购与技术选型检查表

  1. 业务匹配:平台是否能以实际任务成功率证明 Agent 必要性,而不是只演示对话效果?
  2. 架构开放:能否替换模型、向量库、工具协议和部署环境;流程和数据能否导出?
  3. 工具治理:是否支持结构化工具、细粒度授权、审批、幂等、超时、补偿和审计?
  4. 状态可靠性:长任务是否有检查点;服务重启后能否恢复;重复请求是否会重复执行副作用?
  5. 评测体系:是否支持固定评测集、版本对比、回归测试、人工评分和安全红队测试?
  6. 可观测性:能否定位到具体模型、提示词、检索内容、工具参数、Agent 交接和成本?
  7. 安全合规:数据驻留、租户隔离、密钥管理、日志脱敏、漏洞响应和供应链管理是否满足要求?
  8. 性能与 TCO:是否基于真实并发、长上下文、工具延迟和失败率提供容量与三年成本测算?

PoC 与验收指标怎么设

验收维度建议指标验证重点
任务质量端到端任务成功率、关键步骤通过率、人工采纳率、严重错误率使用真实任务集和明确评分规则,不只看演示案例
安全控制越权拦截率、提示注入防护、敏感动作审批覆盖、审计完整率主动进行对抗测试和权限边界测试
可靠性工具失败恢复率、重复执行率、检查点恢复、降级成功率注入超时、限流、模型不可用和下游异常
性能P50/P95/P99 任务延迟、模型与工具并发、队列等待时间按目标峰值并发与真实上下文长度压测
经济性单成功任务 token、调用次数、算力成本和人工接管成本对比传统流程、直接模型调用和单 Agent 基线
可运营性失败定位时间、版本回滚、评测回归、策略变更审计由实际运维和安全人员完成演练

生成式系统输出具有非确定性,验收应采用评分量表、统计分布和高风险错误上限,而不是只用字符串完全匹配。

FAQ:企业建设 Agent 的常见问题

多智能体一定比单智能体效果好吗?

不一定。多智能体可能改善专业分工和上下文隔离,也可能带来更多错误传播、协调延迟和 token 消耗。只有在同一评测集上显著优于单智能体基线,才有引入价值。

Agent 框架是不是越多越好?

不是。框架解决开发效率问题,架构解决业务边界和运行风险问题。优先选择能满足模型可替换、状态持久化、工具治理、可观测和部署要求的最小技术组合。

RAG、工作流和 Agent 是什么关系?

RAG 是获取外部知识的一种能力;工作流按预定义逻辑编排步骤;Agent 由模型动态决定部分行动。一个系统可以同时使用三者,但不应把所有知识问答都设计成自主 Agent。

私有化部署是否天然更安全?

不是。私有化可以改善数据驻留和网络边界,但工具越权、提示注入、密钥泄露、日志敏感信息和供应链风险仍需单独治理。

概念到应用

评估企业AI Agent部署架构

提供业务流程、模型、工具系统、并发与安全要求,可进一步评估单Agent、多Agent、知识库、推理服务和私有化部署方案。

查看相关部署方案浏览指南