很多团队做 AI Agent（智能体）的第一步，是写几行代码去调模型 API。

这没错。

但如果你要把它放进企业生产环境，这一步最多只完成了 20%。

真正麻烦的东西在后面：

• 谁能调用？

• 调多少次？

• 超时怎么办？

• 工具能不能越权？

• 上下文丢了怎么办？

• 成本怎么归集？

• 返回 200 但答案错了，谁来发现？

很多企业第一次接入大模型时，以为自己在做“智能应用”。上线以后才发现，自己只是把业务系统和模型 API 用一根细线绑在了一起。

这不是生产级架构。

这更像摆地摊：能跑，但经不起流量、权限、异常、成本和审计。

我更建议把企业级 AI Agent 拆成六层：

• 入口层 Gateway（网关）

• 编排层 Orchestration（编排）

• 模型层 Model（模型）

• 工具层 Tooling（工具）

• 记忆层 Memory（记忆）

• 观测层 Observability（可观测）

请求先进网关，完成鉴权、限流和会话路由；再进入 Planner（规划器）拆任务；Executor（执行器）调模型和工具；Memory（记忆）读写上下文；最后由安全模块和结果聚合器返回答案。

这才是一个 Agent 能长期在线、持续迭代、可治理的基本骨架。

---

一、入口层：别让业务系统直接裸调模型

企业接入大模型时，最容易被低估的是 API 治理。

如果每个业务服务都自己保存密钥、自己调用模型、自己做重试，问题很快就会失控。

常见后果是：

• 密钥散落在多个服务里

• 某个业务突然打爆 Token

• 在线客服和离线摘要抢同一组额度

• 模型供应商故障时没有降级

• 成本账单只知道总数，不知道谁花的

所以第一层不是模型，而是网关。

1. 统一鉴权与会话路由

入口层要做三件基础事。

第一，统一身份。

JWT、OAuth2.0、API Key 都可以接进来，但进入 Agent 系统后，最好统一成内部身份模型。

这个身份至少要区分：

• 租户

• 团队

• 用户

• 应用

• 会话

这样后面做权限隔离、成本归集、审计追踪，才有基础。

第二，统一限流。

不要只看 QPS。

Agent 系统更应该同时看：

• RPM：每分钟请求数

• TPM：每分钟 Token 数

• 并发数

• 单请求最大 Token

• 单会话最大预算

在线请求和离线任务也要分开。

客服问答、实时助手这种请求，应该优先保障延迟。批量摘要、离线分析这类任务，可以进入低优先级队列。

第三，会话路由。

Agent 和普通接口不一样。

它不是一次请求一次响应那么简单，而是有会话状态、有工具调用、有中间结果。

所以网关需要把同一用户、同一任务、同一会话路由到正确的上下文里。

否则你会遇到一个很典型的问题：用户上一轮刚交代完背景，下一轮 Agent 像失忆了一样重新开始。

2. 智能路由与故障转移

生产系统不能押注单一模型。

一个更稳的设计是：

• 默认模型处理常规任务

• 高复杂任务走强模型

• 低价值批处理走便宜模型

• 主模型超时后自动切备用模型

• 单模型不可用时降级到保底能力

这不是“模型越多越好”。

关键是把模型路由规则集中在网关和模型层，而不是散落在业务代码里。

业务服务只说：我要完成这个任务。

至于用哪个模型、预算是多少、失败怎么降级，应该由 Agent 平台统一处理。

3. 通用 Model Gateway 模式

企业不应该让业务代码直接散点调用模型 API。

更合理的模式是：

业务系统 → 企业模型网关 → Agent 编排系统 → 模型 / 工具 / 记忆

模型网关的价值不只是转发请求。

它负责把模型调用变成可治理的企业能力：可鉴权、可限流、可审计、可路由、可降级、可计费。

如果没有这一层，后面的 Agent 越强，系统风险越大。

---

二、编排层：Agent 的核心不是聊天，而是状态机

请求进来以后，真正决定 Agent 会不会走弯路的是编排层。

很多团队一开始会把 Agent 写成一段“大 Prompt + 工具列表 + while 循环”。

能跑。

但一到生产环境就很难维护。

因为真实任务会失败、会重试、会等待人工确认、会调用多个工具、会出现半完成状态。

这时候你需要的不是更长的 Prompt，而是状态机。

1. 为什么 LangGraph 这类框架适合生产编排

LangGraph 的核心价值，不是“又一个 Agent 框架”。

它真正适合生产的地方在于：它把 Agent 流程显式建模成图。

你可以定义：

• 哪些节点负责规划

• 哪些节点负责执行

• 哪些节点负责验证

• 哪些失败进入补偿

• 哪些状态需要人工介入

• 哪些中间状态要持久化

官方文档里，LangGraph 的 Persistence（持久化）能力强调了 checkpoint（检查点）、state（状态）、thread（线程/会话）和 fault-tolerant execution（容错执行）。

这对生产环境很重要。

因为 Agent 最怕的不是一次失败。

最怕的是失败以后不知道已经做到哪一步，只能从头重跑。

2. Planner 和 Executor 要拆开

编排层内部最核心的设计，是把 Planner 和 Executor 拆开。

Planner 负责想清楚：

• 用户到底要什么

• 任务能不能拆

• 哪些步骤需要工具

• 哪些步骤需要模型判断

• 哪些步骤需要安全确认

Executor 负责把事情做完：

• 调模型

• 调工具

• 处理并发

• 控制超时

• 写入中间状态

• 触发异常补偿

这个拆分很关键。

Planner 不应该直接把所有事做掉。Executor 也不应该边执行边临时改目标。

一个稳定的 Agent 系统，必须让“想清楚”和“做下去”分工。

3. 任务原子化与异常补偿

生产级 Agent 里的任务，应该尽量原子化。

比如不要设计一个叫 process_and_upload 的大工具。

更好的方式是拆成：

• 解析文件

• 提取结构

• 生成摘要

• 校验字段

• 上传结果

• 写入日志

这样做有三个好处。

第一，复用性更高。

第二，失败点更清楚。

第三，回滚和补偿更容易。

比如上传失败，就只重试上传；字段校验失败，就回到校验节点；工具权限不足，就进入人工确认。

这就是状态机的价值。

它不是为了让架构图更复杂，而是为了让失败可控。

---

三、模型层：把模型当资源池，不要当唯一大脑

企业内部经常同时使用多种大模型。

有的适合复杂推理，有的适合低成本批处理，有的适合长上下文，有的适合代码，有的适合多模态。

如果没有统一模型层，团队每次换模型、做 A/B 测试、调整超时策略，都要到处改代码。

模型层的目标只有一个：让应用和具体模型解耦。

1. 多模型动态路由

模型层可以根据任务特征做路由。

常见策略包括：

• 按任务类型路由：代码、摘要、问答、检索、推理

• 按成本路由：低价值任务走低成本模型

• 按延迟路由：实时任务优先低延迟模型

• 按可靠性路由：主备模型自动切换

• 按上下文路由：长文档任务走长上下文模型

这里要注意一点。

不要把所有路由规则写在业务侧。

业务侧只应该表达任务意图。

模型层负责选择最合适的模型资源。

2. 上下文注入不能粗暴堆工具

很多 Agent 性能问题，不是模型不行，而是上下文被浪费了。

尤其是接入 MCP（Model Context Protocol，模型上下文协议）以后，工具生态变丰富了，但也带来一个新问题：工具定义太多。

MCP 的价值，是用标准方式连接 AI 应用和外部系统，让工具、资源、上下文以统一协议暴露出来。

但这不代表你应该把所有工具定义一次性塞进 Prompt。

更合理的方式是分层加载：

• 必用工具集：当前任务一定会用，直接注入

• 候选工具集：先提供摘要，必要时再展开完整 schema

• 高风险工具：只在权限确认后加载

• 低频工具：通过检索或路由动态发现

上下文窗口不是垃圾桶。

它应该只装当前决策真正需要的信息。

3. 模型层的配套机制

生产级模型层至少要补齐这些能力：

• 多厂商 API 统一适配

• 超时控制

• Token 上限

• 重试策略

• 响应格式校验

• 结构化输出约束

• 成本预算

• 请求与响应脱敏

这层做得越扎实，业务系统越轻。

业务不应该关心某个模型的特殊参数、特殊鉴权和特殊报错。

这些都应该被模型层吸收掉。

---

四、工具层：Agent 的能力边界，也在这里

工具层决定 Agent 能做多少事，也决定它能闯多大祸。

它负责连接外部系统：

• 文件系统

• 数据库

• 内部 API

• 工单系统

• 代码仓库

• 浏览器

• 命令行

• 企业知识库

工具接得越多，Agent 越像一个能干活的人。

但同时，风险也越大。

1. MCP 解决的是工具接入标准化

MCP 可以理解成 Agent 和外部工具之间的一套标准连接协议。

它的核心价值是：

• 工具不再硬编码到 Agent 里

• 工具可以被动态发现

• 每个工具用清晰的输入输出 schema 描述

• Agent 可以在运行时理解工具能力

• 不同工具服务可以独立演进

这对企业很重要。

因为企业内部工具太多了。

如果每接一个系统都为某个 Agent 单独写一套适配，很快就会变成维护地狱。

MCP 至少把这件事往标准化方向推了一步。

2. 工具安全三原则

工具层一定要守住三条线。

第一，原子化。

每个工具只做一件事。

例如 file_upload、query_order、create_ticket。

不要做一个万能工具，让 Agent 传一个自然语言指令进去随便执行。

第二，安全封装。

Agent 不应该直接拿到底层系统的全量权限。

更好的方式是通过代理层限制：

• 可访问资源

• 可执行动作

• 可调用时间

• 可处理数据范围

• 是否需要人工确认

高风险工具必须进入沙箱或审批流。

比如删除数据、发送邮件、执行命令、提交代码、调用支付，都不能默认放行。

第三，版本管理。

工具不是 Prompt 里的临时文字。

它是生产接口。

所以所有工具 schema、权限、参数和行为变更，都应该走版本管理和 CI/CD。

否则今天 Agent 调的是一个参数，明天工具悄悄变了，事故会非常隐蔽。

---

五、记忆层：不要让用户每天重新教 Agent

跨会话记忆，是很多 Agent 产品体验的分水岭。

用户最烦的不是 AI 偶尔答错。

而是昨天刚讲清楚的偏好、背景、项目约束，今天又要从头说一遍。

这说明系统只有上下文，没有记忆。

1. 上下文窗口不是长期记忆

大多数 Agent 的“记忆”，其实只是当前会话上下文。

窗口一关，就归零。

上下文窗口适合保存短期信息，比如：

• 当前问题

• 当前文件

• 当前步骤

• 最近几轮对话

但它不适合保存长期偏好、稳定事实和企业知识。

原因很简单：

• 容量有限

• 成本高

• 容易被噪声污染

• 无法跨会话可靠复用

所以记忆层必须独立出来。

2. Mem0 + Easysearch 的典型链路

Mem0 的定位很直接：给 AI Agent 提供跨会话持久化记忆。

如果结合 Easysearch 这类向量检索能力，可以把记忆拆成读写两条链。

写入链路：

Agent 在任务结束或用户明确表达偏好时，调用 add_memories。

MCP Server 接收文本后，做清洗、去重、向量化，然后写入 Easysearch。

读取链路：

下一次用户提问时，Agent 调用 search_memory。

系统把问题向量化，在 Easysearch 里做 kNN（近邻）检索，再把最相关的记忆注入 Prompt。

这套链路的好处是：

• 记忆不再依赖当前上下文

• 可以跨会话复用

• 可以本地化部署

• LLM 和 Embedding 模型可替换

• 企业可以控制数据边界

3. 记忆要分层，不要什么都记

记忆层最容易犯的错误，是把所有东西都存进去。

这会让 Agent 越用越糊。

我建议至少分三层：

记忆类型	存什么	放哪里
短期会话记忆	当前任务状态、最近上下文	会话上下文 / Checkpoint
中期用户记忆	偏好、习惯、稳定约束	Mem0 / 向量库
长期企业知识	制度、流程、产品文档、历史方案	企业知识库 / RAG 系统

还有一条很重要：

记忆不是日志。

日志记录发生过什么。

记忆只保存未来还会用到的稳定事实。

如果把临时过程、错误输出、一次性任务全塞进记忆，Agent 迟早会被自己的历史污染。

---

六、观测层：Agent 返回 200，不代表它做对了

传统 Web 服务监控，看 HTTP 状态码、延迟、错误率，基本能判断系统健康。

Agent 不一样。

它可能返回 200。

但业务答案是错的。

它可能没有报错。

但调用了错误工具。

它可能按时返回。

但成本高得离谱。

所以观测层不是可选项，而是生产级 Agent 的基础设施。

1. 三类可观测信号

Agent 系统至少要收集三类信号。

第一类，执行指标。

包括：

• 请求延迟

• Token 消耗

• 模型调用次数

• 工具调用次数

• 工具成功率

• 重试次数

• 单请求成本

这些指标告诉你：系统跑得贵不贵、慢不慢、稳不稳。

第二类，决策过程。

包括：

• Planner 生成了哪些步骤

• Executor 调用了哪些工具

• 工具参数是什么

• 哪一步失败

• 哪一步重试

• 哪些上下文被注入

这些信息告诉你：Agent 为什么这样做。

没有这部分，你只能看到结果，看不到路径。

第三类，业务影响。

包括：

• 任务完成率

• 用户满意度

• 人工接管率

• 错误恢复率

• 关键业务字段准确率

这部分最难，但也最重要。

因为企业真正关心的不是“模型调用成功率”，而是“业务任务有没有完成”。

2. 生产级工具栈怎么搭

现在比较稳的组合是三层。

第一层，Agent 原生追踪。

比如 LangSmith 可以记录 Agent 的 trace（追踪）、run（运行）、线程、评估和反馈。

这适合研发团队分析：某一次 Agent 为什么做错。

第二层，通用可观测标准。

OpenTelemetry 已经有 GenAI（生成式 AI）语义约定，用来描述模型请求、Token、系统、操作、事件等信息。

这意味着 Agent 不必成为企业监控体系里的孤岛。

你可以把它接进已有的 Prometheus、Jaeger、Grafana 或内部监控平台。

第三层，业务评估。

这部分通常要结合企业自己的评测集、人工反馈和线上抽检。

例如：

• 客服回答是否命中标准答案

• 报告生成是否包含关键字段

• 代码修改是否通过测试

• 工单分类是否符合人工标签

Agent 的质量评估，不能只靠模型自评。

3. 关键指标要从第一天埋好

如果只能先做一组指标，我建议从这几个开始：

• P95 / P99 延迟

• 单请求 Token 成本

• 工具调用成功率

• 任务完成率

• 重试率

• 人工接管率

• 会话完成度

• 高风险工具调用次数

这些指标会直接决定你能不能放心把 Agent 放进生产。

没有观测层，Agent 出问题时，你很难定位：

• 是模型选错了？

• 是工具参数错了？

• 是记忆污染了？

• 是 Planner 拆错了？

• 是网关路由错了？

观测层的本质，是给 Agent 装上黑匣子。

---

七、六层不是堆技术，而是分清责任

把 Agent 拆成六层，不是为了画一张复杂架构图。

而是为了分清责任。

入口层回答：谁能进来，怎么控流，怎么路由。

编排层回答：任务怎么拆，状态怎么转，失败怎么补偿。

模型层回答：用哪个模型，花多少钱，超时怎么办。

工具层回答：能调用什么，权限多大，怎么安全执行。

记忆层回答：什么值得长期保存，什么时候取出来。

观测层回答：系统到底做了什么，质量如何，哪里出错。

总的来说就是：

大模型负责生成能力，六层架构负责让生成能力进入生产。

没有这六层，Agent 只是一个会聊天的接口。

有了这六层，它才有机会成为企业流程里可以长期运行、可以审计、可以优化、可以扩展的生产系统。

---

附录：六层架构速查表

层级	核心职责	关键组件 / 技术	生产级要点
入口层	统一鉴权、限流、路由	JWT / OAuth2.0、令牌桶、会话路由、模型网关	在线 / 离线任务分离、租户隔离、成本归集
编排层	任务规划、状态管理、错误恢复	LangGraph、Planner、Executor、Checkpoint	原子化任务、状态持久化、失败补偿
模型层	多模型统一接入	模型路由、语义路由、预算路由、结构化输出	应用与模型解耦、超时和 Token 上限
工具层	标准化工具调用、安全执行	MCP Server、JSON Schema、RBAC、沙箱	原子工具、权限控制、版本管理
记忆层	跨会话持久化记忆	Mem0、Easysearch、kNN 检索、RAG	短期 / 中期 / 长期记忆分层，避免记忆污染
观测层	全链路追踪、质量评估	LangSmith、OpenTelemetry、Prometheus、Jaeger	Trace、成本、工具成功率、任务完成率

---