智能体架构(Agent Architecture):企业级设计、治理与采购决策指南
LLM智能体架构定义模型、工具、状态、记忆和控制循环的组织方式。本文说明单Agent与多Agent模式、顺序、并行、交接和动态编排,以及企业部署中的安全、成本、评估和基础设施要求。
- 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 显存与吞吐。
平台采购与技术选型检查表
- 业务匹配:平台是否能以实际任务成功率证明 Agent 必要性,而不是只演示对话效果?
- 架构开放:能否替换模型、向量库、工具协议和部署环境;流程和数据能否导出?
- 工具治理:是否支持结构化工具、细粒度授权、审批、幂等、超时、补偿和审计?
- 状态可靠性:长任务是否有检查点;服务重启后能否恢复;重复请求是否会重复执行副作用?
- 评测体系:是否支持固定评测集、版本对比、回归测试、人工评分和安全红队测试?
- 可观测性:能否定位到具体模型、提示词、检索内容、工具参数、Agent 交接和成本?
- 安全合规:数据驻留、租户隔离、密钥管理、日志脱敏、漏洞响应和供应链管理是否满足要求?
- 性能与 TCO:是否基于真实并发、长上下文、工具延迟和失败率提供容量与三年成本测算?
PoC 与验收指标怎么设
| 验收维度 | 建议指标 | 验证重点 |
|---|---|---|
| 任务质量 | 端到端任务成功率、关键步骤通过率、人工采纳率、严重错误率 | 使用真实任务集和明确评分规则,不只看演示案例 |
| 安全控制 | 越权拦截率、提示注入防护、敏感动作审批覆盖、审计完整率 | 主动进行对抗测试和权限边界测试 |
| 可靠性 | 工具失败恢复率、重复执行率、检查点恢复、降级成功率 | 注入超时、限流、模型不可用和下游异常 |
| 性能 | P50/P95/P99 任务延迟、模型与工具并发、队列等待时间 | 按目标峰值并发与真实上下文长度压测 |
| 经济性 | 单成功任务 token、调用次数、算力成本和人工接管成本 | 对比传统流程、直接模型调用和单 Agent 基线 |
| 可运营性 | 失败定位时间、版本回滚、评测回归、策略变更审计 | 由实际运维和安全人员完成演练 |
生成式系统输出具有非确定性,验收应采用评分量表、统计分布和高风险错误上限,而不是只用字符串完全匹配。
FAQ:企业建设 Agent 的常见问题
多智能体一定比单智能体效果好吗?
不一定。多智能体可能改善专业分工和上下文隔离,也可能带来更多错误传播、协调延迟和 token 消耗。只有在同一评测集上显著优于单智能体基线,才有引入价值。
Agent 框架是不是越多越好?
不是。框架解决开发效率问题,架构解决业务边界和运行风险问题。优先选择能满足模型可替换、状态持久化、工具治理、可观测和部署要求的最小技术组合。
RAG、工作流和 Agent 是什么关系?
RAG 是获取外部知识的一种能力;工作流按预定义逻辑编排步骤;Agent 由模型动态决定部分行动。一个系统可以同时使用三者,但不应把所有知识问答都设计成自主 Agent。
私有化部署是否天然更安全?
不是。私有化可以改善数据驻留和网络边界,但工具越权、提示注入、密钥泄露、日志敏感信息和供应链风险仍需单独治理。
概念到应用
评估企业AI Agent部署架构
提供业务流程、模型、工具系统、并发与安全要求,可进一步评估单Agent、多Agent、知识库、推理服务和私有化部署方案。