这两年我看了太多智能体 DemoPPT 上的 Agent 能自动订机票、能写周报、能操作 Excel台下掌声一片真把它接到生产环境跑不了三天就把维护同学的耐心耗光。AI 智能体不是不能干活而是大多数团队还在用“玩具 Demo”的方式做工程。2026 年被业内普遍视为工业级智能体从概念演示走向工程化落地的分水岭而这个分水岭拼的已经不是模型智商而是架构体系和工程能力。这篇文章想和你拆一套我落过地的四层工业架构栈接入层、编排层、工具层、基座层每一层为什么存在、解决什么问题、藏着哪些坑一次说透。1. 为什么你的智能体离生产环境总差一口气1.1 玩具Demo和工业产品之间隔着的不是模型能力先说一个观察很多人容易把“模型不够聪明”当成智能体上不了线的原因但我在实际项目里看下来绝大多数问题是工程问题不是模型问题。本地 Demo 的长相大家都熟悉一个 Jupyter Notebook 或者一个 Streamlit 页面加载好 API Key丢给 Agent 一段 Prompt模型调用几个写死的函数回答看起来很聪明。但当你把它放进真实业务会立刻撞上几件 Demo 阶段从来不会发生的事用户不止一个并发一来复杂推理链路直接把成本和延迟拉上天用户会打断、会反悔、会在同一个会话里连续问 50 个问题上下文越来越长Token 越烧越多工具不是假函数它有真实延迟、会超时、会返回脏数据甚至会被重复调用两遍安全边界不是“你允许模型访问哪些函数”而是“这个用户被允许触发哪些业务动作”没有人会接受“运气好就答对运气差就胡说”的回复错误率和不可控性必须被量化。我把这些差距整理成一张对照表方便你团队内部对齐认知维度玩具 Demo工业级智能体用户规模单人在本地多租户高并发会话状态基本不管理结构化状态机管理上下文策略全量塞进窗口裁剪、摘要、检索混合工具调用同步假函数真实 API超时/幂等/鉴权结果质量人工肉眼看评测集 打分系统行为追踪打印日志全链路 Trace 账单统计发布方式重启服务灰度、回滚、AB 对比兜底方案无熔断、降级、人工接管这张表不是做给你看的是做给你团队里负责架构评审的人看的。智能体不是“给模型装个插件”它是一个完整系统系统该有的治理能力它一样都不能少。1.2 2026年的分水岭行业已经从“能做”转向“能扛”今年行业里反复提到一个判断2026 年会是工业智能体从概念演示走向工程化落地的分水岭。我比较认同。去年大家还在比谁的 Agent 能做更复杂的任务今年已经有人在比谁的 Agent 能稳定扛住真实流量。“能做”和“能扛”是两码事。能做验证的是模型能力和 Prompt 技巧能扛验证的是架构设计、数据闭环、成本模型和运维体系。举个例子一个销售线索清洗 AgentDemo 阶段处理 10 条数据毫无压力生产阶段一天要处理 10 万条结构各异的线索还要保证每个字段的置信度、每次调用的可回溯性、每个客户的成本上限——这中间全是工程问题。所以这篇文章我不讲“怎么让模型更聪明”而是讲“怎么让智能体像一个正规系统一样活着”。2. 四层架构栈全景先搞清楚每一层到底管什么2.1 接入层、编排层、工具层、基座层的分工我落地的四层架构栈从上到下分别是层级核心职责典型案例关键组件维度接入层用户触点与请求入口客服弹窗、企业微信、Web 页面、OpenAPI会话网关、SSE/WebSocket、多模态消息编排层智能体的“大脑”任务规划、上下文管理、记忆、多 Agent 协作主控循环、状态机、记忆服务、编排协议工具层能力与数据的“手脚”业务 API、文档库、数据库、第三方系统MCP 协议、工具注册中心、RAG 检索、权限校验基座层模型与基础设施的“地基”大模型推理、向量库、缓存、可观测性模型路由、Token 成本、评测平台、Trace 系统很多人搭建智能体时只关注第二层——编排层因为这是最炫酷的部分。但真实生产里接入层的稳定性决定了用户体验工具层的规范程度决定了模型能发挥多少能力基座层的治理能力决定了你敢不敢上线。四层是耦合在一起的任何一层拉胯整体都会拉胯。2.2 为什么必须分四层而不是把一个Agent堆到底有人会问我一个 Agent 里既处理会话又规划任务又直接调用工具难道不行吗行但只存在于 Demo 和小规模场景。分层解决的是四个真实痛点。第一是故障隔离。工具 A 的接口突然变慢如果工具调用逻辑跟编排逻辑混在一起一个慢接口会把整个 Agent 的响应时间拖爆炸。分层之后工具层可以做超时、熔断、降级编排层感知不到底层波动。第二是权限边界。模型所在的环境不应该直接持有高权限的系统凭据。工具层充当“门卫”对每个工具调用做鉴权、审计、参数校验否则一个 Prompt 注入就可能让 Agent 执行危险操作。第三是可替换性。模型可以换工具可以换接入渠道可以换但编排逻辑和业务逻辑尽量保持一致。四层之间用契约通信换任何一层都不用重写整个系统。第四是可测试性。分层之后每一层都有独立的测试对象接入层测协议兼容编排层测任务拆解工具层测功能正确性基座层测模型质量。否则出了问题你连锅都甩不清楚。2.3 层与层之间只认契约不认内部实现我做系统设计有个习惯严进严出。四层之间全部通过明确的接口契约通信上游不感知下游内部实现。接入层与编排层之间的契约是标准化的会话消息结构。举个例子无论是来自 Web 的文本、企业微信的语音还是第三方系统的回调事件接入层负责统一转成内部的消息格式编排层只认这种格式。这样以后新增渠道只改接入层编排层完全无感。编排层与工具层之间的契约是工具描述与调用协议。工具层向上暴露的不是“一段函数”而是一个带 JSON Schema 的工具描述。模型看到描述后发起一次结构化的工具调用请求工具层负责执行并返回统一格式的结果。层与层之间这样做最大的好处是任何一层的内部改动都不会引发多米诺骨牌效应。我经历过一次把底层模型从闭源换到开源模型的迁移因为契约没变最终只替换了基座层的一个适配器两天就搞定了。3. 编排层是灵魂状态、记忆和工具调度都在这3.1 主控循环从ReAct到Plan-and-Execute编排层最基础的东西是主控循环。最早大家普遍用 ReAct 模式模型“思考”一下然后“行动”一次看到行动结果再“思考”如此循环直到得出答案。这种模式的优点是灵活缺点是容易在复杂场景里原地打转。模型经常反复调用同一个工具或者执行到一半忘记最初目标。我现在的项目更倾向于 Plan-and-Execute 的变体模型先根据用户目标产出一个任务计划然后交给执行器逐个执行执行过程中允许根据中间结果修正计划。代码层面的伪代码大概是这个样子的plan llm.create_plan(user_request) while not plan.is_finished(): step plan.next_step() result executor.run(step) if result.should_replan(): plan llm.replan(plan, result)简化版本看起来只是换个思维方式但工程影响非常大。ReAct 模式下每一步都要重新经过模型推理Token 开销大、延迟高Plan-and-Execute 模式下计划阶段和单步执行阶段可以分别优化甚至在执行阶段用更小的模型也能跑出不错的效果。代价是规划本身的准确率必须足够高所以一般会在规划阶段让强模型参与执行阶段用弱模型压缩成本。3.2 会话状态与上下文管理的工程化工业级 Agent 必须把会话状态当作一等公民来管理不能依赖模型“凭记忆记住一切”。我用的是结构化 Session State把用户目标、当前计划、已执行步骤、关键上下文、产物引用都存成显式的状态数据。举个例子用户要求“整理这份销售数据并生成周报”。编排层的状态机是这样的初始状态是“等待用户确认数据范围”确认后变成“分析数据”分析完成后进入“生成报告”报告产出后进入“等待用户反馈”。任何一步失败状态机都能回退到上一步而不是让整条链路从头再来一遍。上下文管理则是另外一个隐藏的硬骨头。模型窗口是有上限的为了让 Agent 在长会话中保持稳定常见的做法有三层裁剪把较早的、与当前任务无关的对话历史从窗口里摘除摘要对被裁掉的历史生成短摘要保留关键决策信息检索注入当用户问到某个历史细节时通过向量检索把相关片段找回来。这三层组合起来长会话的知识不会丢但窗口里的内容始终保持精炼。这里我踩过最深的坑是一旦上下文里出现矛盾信息模型会随机采纳其中一种。所以裁剪和摘要时我会刻意保留“用户明确的修正意见”这类信息的优先级高于普通对话。3.3 记忆分级短期、长期和工作记忆各管一摊工业级智能体一定要把记忆分层不要一股脑全存一个地方。我习惯分成三层短期记忆相当于当前会话的上下文一般放在 Redis 这类高速存储里关联一个 Session ID过期时间跟着业务走比如客服会话结束 24 小时后自动清理。长期记忆是跨会话的持久信息存放在向量数据库或者知识图谱里比如用户偏好、历史订单、常见问题标签。工作记忆则是当前任务目标与中间状态存放在状态机里任务结束就归档。一个容易被忽略的点是“记忆写入要有策略”。模型不是每次对话结束都应该更新长期记忆否则垃圾信息会污染知识库。我会设计一个独立的写入判断只有用户明确表达了偏好、或者 Agent 完成任务后产生了高质量结论才允许写入长期记忆。其他情况一律只留在短期记忆里。3.4 多Agent协作先想清楚有没有必要多 Agent 最近很火但我要说一句可能不合时宜的话大多数业务场景根本用不上多 Agent。单个 Agent 失败率高往往是上下文管理或工具设计问题不是“单脑不够用”。硬套多 Agent 只会引入更复杂的协调问题任务怎么拆分、消息怎么路由、冲突怎么仲裁、结果怎么汇合。如果场景确实需要多 Agent比如一个主控 Agent 同时调度数据分析 Agent 和报告写作 Agent我会采用“主从 共享上下文”的模式主控 Agent 负责任务规划和最终输出子 Agent 只负责任务片段并把结果写回共享上下文。子 Agent 之间不做横向通信所有协调都通过主控完成。这看起来不够炫酷但非常稳因为你只需要关注一个协调点。4. 工具接入和知识检索能力边界决定产品边界4.1 工具注册与统一协议MCP接入层之后最容易被低估的就是工具层。模型要调用外部能力必须先清楚地知道“有哪些工具、每个工具什么时候用、入参出参长什么样”。工具注册中心就是干这个的每个工具在注册中心登记自己的名称、描述、参数 Schema、鉴权方式、超时时间、重试策略。现在比较推荐的做法是走 MCPModel Context Protocol这类统一协议。MCP 本质上是把“模型与外部工具之间的交互方式”标准化了工具托管方实现 MCP Server模型侧通过 MCP Client 调用两边都只需要适配协议不用为每一个工具写定制对接逻辑。协议统一带来的边际效应是巨大的。我维护过一套 30 多个工具的系统如果没有统一协议每接一个业务系统都要写一套适配代码有了 MCP 之后新增一个工具的边际成本降到了一个配置文件和几十行执行逻辑。4.2 工具调用的工程三件套超时、幂等、鉴权工具层最容易翻车的地方不在模型而在基础工程。我总结了三个必须处理的点。第一个是超时。工具必然有响应时间波动模型不可能无限等待一个外部接口。我的做法是给每个工具设置独立的超时阈值比如普通查询 5 秒涉及外部人工操作的可放宽到 15 秒超过阈值工具层直接返回“调用失败”编排层决定降级方案或者重新规划。绝对不能让底层网络波动烧掉模型大量 Token。第二个是幂等。Agent 的执行逻辑天然带着不确定性一次工具调用失败后模型可能会重试。如果这个工具是“创建订单”“发送短信”这类写操作重试就会造成重复扣款、重复通知。所以所有写操作类工具都必须要求业务方支持幂等键。Agent 每次调用时生成一个 request_id 传过去服务端用这个 ID 去重。第三个是鉴权。Agent 的权限永远不能等于用户的权限更不能等于服务账号的权限。工具层要根据用户身份、会话上下文、工具敏感级别做动态鉴权。用户没有某个业务的访问权模型再聪明也不能让它绕过权限。这个边界要在工具层硬性拦截不能指望 Prompt 约束。4.3 RAG不是“接个向量库”那么简单知识密集型场景基本离不开 RAG但很多团队把 RAG 做成了“文档切一切、向量存一存、查一查拼进 Prompt”效果不顺就怪模型。实际上 RAG 的工程深度远超这个。首先是切分策略。固定长度切分是最省事的但效果通常最差。我会按语义结构切分比如按照 Markdown 标题、段落、表格行组织切片再给每个切片生成结构化的元数据。切太大检索噪声高切太小上下文不完整。很多场景跑完评测会发现需要针对每种文档类型单独调切分参数。其次是检索质量。纯向量检索召回不够稳我这边生产环境用的是混合检索BM25 处理精确关键词命中向量检索处理语义相似两种结果用 RRFReciprocal Rank Fusion合并再用一个 Rerank 模型对候选片段精排。这个组合把回答引用的准确率提升得非常明显。最后是引用溯源。工业场景不允许模型凭空回答每个关键结论最好都能关联到知识库里的原始片段用户在界面上能看到出处。没有引用的 RAG 答案本质上还是在“凭感觉说话”没法审计。5. 工业级必答题效果评估、成本观测和灰度上线5.1 没有评测集就没有上线资格智能体跟传统程序最大的不同是传统程序跑通测试用例就知道好不好智能体的输出是概率性的同一个 Prompt 每次运行可能有细微差别。所以必须有线下评测集把“界面上看不错”变成“指标上看得分多少”。我推荐三层评测体系。第一层是规则评测适合强约束场景比如 JSON 格式是否正确、是否包含禁用词、关键字段是否缺失跑得快又便宜。第二层是 LLM-as-a-Judge用一个更强的模型给智能体的输出打分评价维度包括正确性、完整性、风格贴合度等适合开放域场景。第三层是人工回归每周抽一批核心场景逐条人工检查。评测集本身要持续迭代。生产环境里用户问得怪、答得差的案例都要沉淀成评测用例回流到测试集里。我通常要求每个迭代周期至少新增 20 条历史 Bad Case否则评判结果容易失真。5.2 可观测性既要看行为也要看账单工业级系统最核心的可观测性目标是回答三个问题它为什么这样做、它花了我多少钱、它现在是不是出问题了。传统日志基本回答不了这几个问题智能体需要的是结构化 Trace。我这边会给每次完整请求生成一个 Trace ID贯穿从接入层到基座层的所有环节。Trace 里必须包括模型接收的每轮 Prompt 摘要、模型输出的推理内容、发起过哪些工具调用、每个工具调用的耗时与返回状态、Token 消耗总量和成本估算。把这些数据推到统一的 Trace 平台之后出问题才能回溯。成本观测是另一个经常被忽视的点。大模型按 Token 收费Agent 一个任务可能跑多轮循环成本是隐性的。我的做法是给每个租户、每个会话设置成本配额一旦超限就触发降级策略——切换到更便宜的模型、减少重试次数、或者直接提示用户联系人工。5.3 灰度发布与快速回滚智能体上线比普通服务需要更谨慎。模型 Prompt 的小改动、工具参数描述微调都可能造成行为偏移。所以发布流程我坚持“灰度”和“可回滚”。灰度策略按租户或用户百分比推进比如先给 5% 的用户启用新版本对比新旧版本的评测得分和线上错误率没有问题再逐步放量。这期间最有用的是一个能力请求级别的新旧版本路由。把同一批用户请求同时发给新旧两个版本用评测模块对比输出质量这是最快速的回归方式。回滚也要做得轻。我的做法是所有 Prompt、工具描述、编排策略都作为版本化配置存放在配置中心任何一次发布实际上只是切换配置版本号。一旦线上发现问题一句话就能回滚到上一个稳定版本而不是改代码重新部署。6. 落地过程踩过的坑以及我的避坑清单6.1 上下文窗口是隐形预算上下文每多一万字成本不是线性增长而是按模型计费规则成倍变化。更麻烦的是窗口被塞满后模型注意力会涣散关键信息反而被淹没。我见过一个团队为了让 Agent“记住所有细节”把完整的对话历史全部塞进 Prompt结果 Token 成本暴涨 5 倍回答质量反而下降。我的建议是把上下文窗口当成一种有限的内存预算来管理。每次请求前都要计算当前状态下的上下文结构该裁剪的裁剪该摘要的摘要。并行工具调用的中间结果能合并就合并能丢弃就丢弃绝不无脑保留。6.2 Agent的权限不能等于用户权限这是我在安全方面最重要的一条经验。有一种经典错误是接入系统时为了方便把服务账号的权限直接给了 Agent然后通过 Prompt 约束它“不要越权”。Prompt 约束在恶意输入面前根本不是安全边界。正确的设计是权限下沉到工具层Agent 每一次调用工具都要经过权限校验。用户在界面上点了“查询我的订单”Agent 调用订单查询工具时工具层注入当前用户身份后端强制按用户维度过滤数据。模型本身接触不到其他用户的任何数据这才能避免越权问题。6.3 先做窄场景再谈通用智能最后一条经验可能也最反直觉一个智能体项目要成功前期一定要克制只做窄场景。通用智能是终极目标但工业落地需要的是确定性和可控性。所谓窄场景就是定义清楚用户对象、输入范围、工具集和退出条件。比如“面向销售人员的客户周报生成助手”用户对象是销售输入是客户拜访记录工具集是 CRM 和报表系统退出条件是生成一份可导出、可修改的周报。这个范围里你能把评测集、工具链路、状态机打磨到很稳。等这个窄场景跑顺了再逐步扩展能力边界比一开始就做一个“啥都能干的 AI 助理”要靠谱得多。我做完这套四层架构栈之后最大的体会是智能体不需要在任何一个环节表现得像魔法它只需要在每个环节表现得像软件。状态是显式的、调用是可追踪的、数据是可回滚的、权限是硬约束的——当你把这些工程问题解决掉模型的能力才真正变成产品的价值。如果你正在从 Demo 往生产环境迁移别急着优化模型的推理能力先把你架构里最弱的那一层补上收益会远超你的预期。
工业级智能体四层架构栈：从玩具Demo到生产落地的工程实践
这两年我看了太多智能体 DemoPPT 上的 Agent 能自动订机票、能写周报、能操作 Excel台下掌声一片真把它接到生产环境跑不了三天就把维护同学的耐心耗光。AI 智能体不是不能干活而是大多数团队还在用“玩具 Demo”的方式做工程。2026 年被业内普遍视为工业级智能体从概念演示走向工程化落地的分水岭而这个分水岭拼的已经不是模型智商而是架构体系和工程能力。这篇文章想和你拆一套我落过地的四层工业架构栈接入层、编排层、工具层、基座层每一层为什么存在、解决什么问题、藏着哪些坑一次说透。1. 为什么你的智能体离生产环境总差一口气1.1 玩具Demo和工业产品之间隔着的不是模型能力先说一个观察很多人容易把“模型不够聪明”当成智能体上不了线的原因但我在实际项目里看下来绝大多数问题是工程问题不是模型问题。本地 Demo 的长相大家都熟悉一个 Jupyter Notebook 或者一个 Streamlit 页面加载好 API Key丢给 Agent 一段 Prompt模型调用几个写死的函数回答看起来很聪明。但当你把它放进真实业务会立刻撞上几件 Demo 阶段从来不会发生的事用户不止一个并发一来复杂推理链路直接把成本和延迟拉上天用户会打断、会反悔、会在同一个会话里连续问 50 个问题上下文越来越长Token 越烧越多工具不是假函数它有真实延迟、会超时、会返回脏数据甚至会被重复调用两遍安全边界不是“你允许模型访问哪些函数”而是“这个用户被允许触发哪些业务动作”没有人会接受“运气好就答对运气差就胡说”的回复错误率和不可控性必须被量化。我把这些差距整理成一张对照表方便你团队内部对齐认知维度玩具 Demo工业级智能体用户规模单人在本地多租户高并发会话状态基本不管理结构化状态机管理上下文策略全量塞进窗口裁剪、摘要、检索混合工具调用同步假函数真实 API超时/幂等/鉴权结果质量人工肉眼看评测集 打分系统行为追踪打印日志全链路 Trace 账单统计发布方式重启服务灰度、回滚、AB 对比兜底方案无熔断、降级、人工接管这张表不是做给你看的是做给你团队里负责架构评审的人看的。智能体不是“给模型装个插件”它是一个完整系统系统该有的治理能力它一样都不能少。1.2 2026年的分水岭行业已经从“能做”转向“能扛”今年行业里反复提到一个判断2026 年会是工业智能体从概念演示走向工程化落地的分水岭。我比较认同。去年大家还在比谁的 Agent 能做更复杂的任务今年已经有人在比谁的 Agent 能稳定扛住真实流量。“能做”和“能扛”是两码事。能做验证的是模型能力和 Prompt 技巧能扛验证的是架构设计、数据闭环、成本模型和运维体系。举个例子一个销售线索清洗 AgentDemo 阶段处理 10 条数据毫无压力生产阶段一天要处理 10 万条结构各异的线索还要保证每个字段的置信度、每次调用的可回溯性、每个客户的成本上限——这中间全是工程问题。所以这篇文章我不讲“怎么让模型更聪明”而是讲“怎么让智能体像一个正规系统一样活着”。2. 四层架构栈全景先搞清楚每一层到底管什么2.1 接入层、编排层、工具层、基座层的分工我落地的四层架构栈从上到下分别是层级核心职责典型案例关键组件维度接入层用户触点与请求入口客服弹窗、企业微信、Web 页面、OpenAPI会话网关、SSE/WebSocket、多模态消息编排层智能体的“大脑”任务规划、上下文管理、记忆、多 Agent 协作主控循环、状态机、记忆服务、编排协议工具层能力与数据的“手脚”业务 API、文档库、数据库、第三方系统MCP 协议、工具注册中心、RAG 检索、权限校验基座层模型与基础设施的“地基”大模型推理、向量库、缓存、可观测性模型路由、Token 成本、评测平台、Trace 系统很多人搭建智能体时只关注第二层——编排层因为这是最炫酷的部分。但真实生产里接入层的稳定性决定了用户体验工具层的规范程度决定了模型能发挥多少能力基座层的治理能力决定了你敢不敢上线。四层是耦合在一起的任何一层拉胯整体都会拉胯。2.2 为什么必须分四层而不是把一个Agent堆到底有人会问我一个 Agent 里既处理会话又规划任务又直接调用工具难道不行吗行但只存在于 Demo 和小规模场景。分层解决的是四个真实痛点。第一是故障隔离。工具 A 的接口突然变慢如果工具调用逻辑跟编排逻辑混在一起一个慢接口会把整个 Agent 的响应时间拖爆炸。分层之后工具层可以做超时、熔断、降级编排层感知不到底层波动。第二是权限边界。模型所在的环境不应该直接持有高权限的系统凭据。工具层充当“门卫”对每个工具调用做鉴权、审计、参数校验否则一个 Prompt 注入就可能让 Agent 执行危险操作。第三是可替换性。模型可以换工具可以换接入渠道可以换但编排逻辑和业务逻辑尽量保持一致。四层之间用契约通信换任何一层都不用重写整个系统。第四是可测试性。分层之后每一层都有独立的测试对象接入层测协议兼容编排层测任务拆解工具层测功能正确性基座层测模型质量。否则出了问题你连锅都甩不清楚。2.3 层与层之间只认契约不认内部实现我做系统设计有个习惯严进严出。四层之间全部通过明确的接口契约通信上游不感知下游内部实现。接入层与编排层之间的契约是标准化的会话消息结构。举个例子无论是来自 Web 的文本、企业微信的语音还是第三方系统的回调事件接入层负责统一转成内部的消息格式编排层只认这种格式。这样以后新增渠道只改接入层编排层完全无感。编排层与工具层之间的契约是工具描述与调用协议。工具层向上暴露的不是“一段函数”而是一个带 JSON Schema 的工具描述。模型看到描述后发起一次结构化的工具调用请求工具层负责执行并返回统一格式的结果。层与层之间这样做最大的好处是任何一层的内部改动都不会引发多米诺骨牌效应。我经历过一次把底层模型从闭源换到开源模型的迁移因为契约没变最终只替换了基座层的一个适配器两天就搞定了。3. 编排层是灵魂状态、记忆和工具调度都在这3.1 主控循环从ReAct到Plan-and-Execute编排层最基础的东西是主控循环。最早大家普遍用 ReAct 模式模型“思考”一下然后“行动”一次看到行动结果再“思考”如此循环直到得出答案。这种模式的优点是灵活缺点是容易在复杂场景里原地打转。模型经常反复调用同一个工具或者执行到一半忘记最初目标。我现在的项目更倾向于 Plan-and-Execute 的变体模型先根据用户目标产出一个任务计划然后交给执行器逐个执行执行过程中允许根据中间结果修正计划。代码层面的伪代码大概是这个样子的plan llm.create_plan(user_request) while not plan.is_finished(): step plan.next_step() result executor.run(step) if result.should_replan(): plan llm.replan(plan, result)简化版本看起来只是换个思维方式但工程影响非常大。ReAct 模式下每一步都要重新经过模型推理Token 开销大、延迟高Plan-and-Execute 模式下计划阶段和单步执行阶段可以分别优化甚至在执行阶段用更小的模型也能跑出不错的效果。代价是规划本身的准确率必须足够高所以一般会在规划阶段让强模型参与执行阶段用弱模型压缩成本。3.2 会话状态与上下文管理的工程化工业级 Agent 必须把会话状态当作一等公民来管理不能依赖模型“凭记忆记住一切”。我用的是结构化 Session State把用户目标、当前计划、已执行步骤、关键上下文、产物引用都存成显式的状态数据。举个例子用户要求“整理这份销售数据并生成周报”。编排层的状态机是这样的初始状态是“等待用户确认数据范围”确认后变成“分析数据”分析完成后进入“生成报告”报告产出后进入“等待用户反馈”。任何一步失败状态机都能回退到上一步而不是让整条链路从头再来一遍。上下文管理则是另外一个隐藏的硬骨头。模型窗口是有上限的为了让 Agent 在长会话中保持稳定常见的做法有三层裁剪把较早的、与当前任务无关的对话历史从窗口里摘除摘要对被裁掉的历史生成短摘要保留关键决策信息检索注入当用户问到某个历史细节时通过向量检索把相关片段找回来。这三层组合起来长会话的知识不会丢但窗口里的内容始终保持精炼。这里我踩过最深的坑是一旦上下文里出现矛盾信息模型会随机采纳其中一种。所以裁剪和摘要时我会刻意保留“用户明确的修正意见”这类信息的优先级高于普通对话。3.3 记忆分级短期、长期和工作记忆各管一摊工业级智能体一定要把记忆分层不要一股脑全存一个地方。我习惯分成三层短期记忆相当于当前会话的上下文一般放在 Redis 这类高速存储里关联一个 Session ID过期时间跟着业务走比如客服会话结束 24 小时后自动清理。长期记忆是跨会话的持久信息存放在向量数据库或者知识图谱里比如用户偏好、历史订单、常见问题标签。工作记忆则是当前任务目标与中间状态存放在状态机里任务结束就归档。一个容易被忽略的点是“记忆写入要有策略”。模型不是每次对话结束都应该更新长期记忆否则垃圾信息会污染知识库。我会设计一个独立的写入判断只有用户明确表达了偏好、或者 Agent 完成任务后产生了高质量结论才允许写入长期记忆。其他情况一律只留在短期记忆里。3.4 多Agent协作先想清楚有没有必要多 Agent 最近很火但我要说一句可能不合时宜的话大多数业务场景根本用不上多 Agent。单个 Agent 失败率高往往是上下文管理或工具设计问题不是“单脑不够用”。硬套多 Agent 只会引入更复杂的协调问题任务怎么拆分、消息怎么路由、冲突怎么仲裁、结果怎么汇合。如果场景确实需要多 Agent比如一个主控 Agent 同时调度数据分析 Agent 和报告写作 Agent我会采用“主从 共享上下文”的模式主控 Agent 负责任务规划和最终输出子 Agent 只负责任务片段并把结果写回共享上下文。子 Agent 之间不做横向通信所有协调都通过主控完成。这看起来不够炫酷但非常稳因为你只需要关注一个协调点。4. 工具接入和知识检索能力边界决定产品边界4.1 工具注册与统一协议MCP接入层之后最容易被低估的就是工具层。模型要调用外部能力必须先清楚地知道“有哪些工具、每个工具什么时候用、入参出参长什么样”。工具注册中心就是干这个的每个工具在注册中心登记自己的名称、描述、参数 Schema、鉴权方式、超时时间、重试策略。现在比较推荐的做法是走 MCPModel Context Protocol这类统一协议。MCP 本质上是把“模型与外部工具之间的交互方式”标准化了工具托管方实现 MCP Server模型侧通过 MCP Client 调用两边都只需要适配协议不用为每一个工具写定制对接逻辑。协议统一带来的边际效应是巨大的。我维护过一套 30 多个工具的系统如果没有统一协议每接一个业务系统都要写一套适配代码有了 MCP 之后新增一个工具的边际成本降到了一个配置文件和几十行执行逻辑。4.2 工具调用的工程三件套超时、幂等、鉴权工具层最容易翻车的地方不在模型而在基础工程。我总结了三个必须处理的点。第一个是超时。工具必然有响应时间波动模型不可能无限等待一个外部接口。我的做法是给每个工具设置独立的超时阈值比如普通查询 5 秒涉及外部人工操作的可放宽到 15 秒超过阈值工具层直接返回“调用失败”编排层决定降级方案或者重新规划。绝对不能让底层网络波动烧掉模型大量 Token。第二个是幂等。Agent 的执行逻辑天然带着不确定性一次工具调用失败后模型可能会重试。如果这个工具是“创建订单”“发送短信”这类写操作重试就会造成重复扣款、重复通知。所以所有写操作类工具都必须要求业务方支持幂等键。Agent 每次调用时生成一个 request_id 传过去服务端用这个 ID 去重。第三个是鉴权。Agent 的权限永远不能等于用户的权限更不能等于服务账号的权限。工具层要根据用户身份、会话上下文、工具敏感级别做动态鉴权。用户没有某个业务的访问权模型再聪明也不能让它绕过权限。这个边界要在工具层硬性拦截不能指望 Prompt 约束。4.3 RAG不是“接个向量库”那么简单知识密集型场景基本离不开 RAG但很多团队把 RAG 做成了“文档切一切、向量存一存、查一查拼进 Prompt”效果不顺就怪模型。实际上 RAG 的工程深度远超这个。首先是切分策略。固定长度切分是最省事的但效果通常最差。我会按语义结构切分比如按照 Markdown 标题、段落、表格行组织切片再给每个切片生成结构化的元数据。切太大检索噪声高切太小上下文不完整。很多场景跑完评测会发现需要针对每种文档类型单独调切分参数。其次是检索质量。纯向量检索召回不够稳我这边生产环境用的是混合检索BM25 处理精确关键词命中向量检索处理语义相似两种结果用 RRFReciprocal Rank Fusion合并再用一个 Rerank 模型对候选片段精排。这个组合把回答引用的准确率提升得非常明显。最后是引用溯源。工业场景不允许模型凭空回答每个关键结论最好都能关联到知识库里的原始片段用户在界面上能看到出处。没有引用的 RAG 答案本质上还是在“凭感觉说话”没法审计。5. 工业级必答题效果评估、成本观测和灰度上线5.1 没有评测集就没有上线资格智能体跟传统程序最大的不同是传统程序跑通测试用例就知道好不好智能体的输出是概率性的同一个 Prompt 每次运行可能有细微差别。所以必须有线下评测集把“界面上看不错”变成“指标上看得分多少”。我推荐三层评测体系。第一层是规则评测适合强约束场景比如 JSON 格式是否正确、是否包含禁用词、关键字段是否缺失跑得快又便宜。第二层是 LLM-as-a-Judge用一个更强的模型给智能体的输出打分评价维度包括正确性、完整性、风格贴合度等适合开放域场景。第三层是人工回归每周抽一批核心场景逐条人工检查。评测集本身要持续迭代。生产环境里用户问得怪、答得差的案例都要沉淀成评测用例回流到测试集里。我通常要求每个迭代周期至少新增 20 条历史 Bad Case否则评判结果容易失真。5.2 可观测性既要看行为也要看账单工业级系统最核心的可观测性目标是回答三个问题它为什么这样做、它花了我多少钱、它现在是不是出问题了。传统日志基本回答不了这几个问题智能体需要的是结构化 Trace。我这边会给每次完整请求生成一个 Trace ID贯穿从接入层到基座层的所有环节。Trace 里必须包括模型接收的每轮 Prompt 摘要、模型输出的推理内容、发起过哪些工具调用、每个工具调用的耗时与返回状态、Token 消耗总量和成本估算。把这些数据推到统一的 Trace 平台之后出问题才能回溯。成本观测是另一个经常被忽视的点。大模型按 Token 收费Agent 一个任务可能跑多轮循环成本是隐性的。我的做法是给每个租户、每个会话设置成本配额一旦超限就触发降级策略——切换到更便宜的模型、减少重试次数、或者直接提示用户联系人工。5.3 灰度发布与快速回滚智能体上线比普通服务需要更谨慎。模型 Prompt 的小改动、工具参数描述微调都可能造成行为偏移。所以发布流程我坚持“灰度”和“可回滚”。灰度策略按租户或用户百分比推进比如先给 5% 的用户启用新版本对比新旧版本的评测得分和线上错误率没有问题再逐步放量。这期间最有用的是一个能力请求级别的新旧版本路由。把同一批用户请求同时发给新旧两个版本用评测模块对比输出质量这是最快速的回归方式。回滚也要做得轻。我的做法是所有 Prompt、工具描述、编排策略都作为版本化配置存放在配置中心任何一次发布实际上只是切换配置版本号。一旦线上发现问题一句话就能回滚到上一个稳定版本而不是改代码重新部署。6. 落地过程踩过的坑以及我的避坑清单6.1 上下文窗口是隐形预算上下文每多一万字成本不是线性增长而是按模型计费规则成倍变化。更麻烦的是窗口被塞满后模型注意力会涣散关键信息反而被淹没。我见过一个团队为了让 Agent“记住所有细节”把完整的对话历史全部塞进 Prompt结果 Token 成本暴涨 5 倍回答质量反而下降。我的建议是把上下文窗口当成一种有限的内存预算来管理。每次请求前都要计算当前状态下的上下文结构该裁剪的裁剪该摘要的摘要。并行工具调用的中间结果能合并就合并能丢弃就丢弃绝不无脑保留。6.2 Agent的权限不能等于用户权限这是我在安全方面最重要的一条经验。有一种经典错误是接入系统时为了方便把服务账号的权限直接给了 Agent然后通过 Prompt 约束它“不要越权”。Prompt 约束在恶意输入面前根本不是安全边界。正确的设计是权限下沉到工具层Agent 每一次调用工具都要经过权限校验。用户在界面上点了“查询我的订单”Agent 调用订单查询工具时工具层注入当前用户身份后端强制按用户维度过滤数据。模型本身接触不到其他用户的任何数据这才能避免越权问题。6.3 先做窄场景再谈通用智能最后一条经验可能也最反直觉一个智能体项目要成功前期一定要克制只做窄场景。通用智能是终极目标但工业落地需要的是确定性和可控性。所谓窄场景就是定义清楚用户对象、输入范围、工具集和退出条件。比如“面向销售人员的客户周报生成助手”用户对象是销售输入是客户拜访记录工具集是 CRM 和报表系统退出条件是生成一份可导出、可修改的周报。这个范围里你能把评测集、工具链路、状态机打磨到很稳。等这个窄场景跑顺了再逐步扩展能力边界比一开始就做一个“啥都能干的 AI 助理”要靠谱得多。我做完这套四层架构栈之后最大的体会是智能体不需要在任何一个环节表现得像魔法它只需要在每个环节表现得像软件。状态是显式的、调用是可追踪的、数据是可回滚的、权限是硬约束的——当你把这些工程问题解决掉模型的能力才真正变成产品的价值。如果你正在从 Demo 往生产环境迁移别急着优化模型的推理能力先把你架构里最弱的那一层补上收益会远超你的预期。
