从Demo到生产：工业级AI Agent架构设计与落地实战

最近这一年各种Agent项目出现得非常频繁。我所在的团队负责“智能体来了”西南总部这个项目——一套面向企业内部的智能体工作平台目标是把业务人员从重复、多步骤的流程操作中解放出来。也就是让业务人员用自然语言发起需求由AI Agent自主完成拆解、调用工具、检查结果、回复结论这一整套闭环。项目从原型到生产环境中间踩了不少坑也沉淀出一套可以复用的架构方法。这篇文章把我们在西南总部的技术架构设计思路、生产落地过程中的关键取舍以及上线初期遇到的典型问题整理出来希望能给准备把Agent推到生产环境的技术团队一些参考。先说结论Demo阶段的Agent和工业级的Agent完全是两种物种。Demo只需要在精心准备的场景下跑通一次工业级则需要面对各种歧义表达、不确定的工具行为、突发的模型超时、业务数据权限边界以及看不见摸不着但月底就要对账的成本。下面从架构分层开始讲再聊稳定性设计、可观测性和成本控制最后复盘几个典型的坑。1. 为什么大多数Agent项目死在Demo之后工业级与原型系统的本质差距1.1 Demo只回答“能不能”生产要回答“稳不稳”我见过不少团队花一两周时间搭出一个Agent原型现场演示的时候让大模型调用两个API生成一份报告效果很惊艳。但一旦放到生产环境情况就完全不同用户可能把需求表述得含糊不清工具可能因为第三方接口抖动而失败模型可能突然抽风返回一段不可解析的内容业务数据可能涉及权限隔离而必须拒绝执行。Demo阶段可以接受“失败后人工重新输入一次”生产环境则要求系统自己具备恢复能力。对于企业业务而言Agent不是一个炫技玩具而是一个需要连续运行、可计算故障率的业务系统。1.2 工业级的第一道门槛可复现性大模型天然带有随机性。同一句话今天问和明天问模型给出的中间推理可能完全不同。这在自动化的生产系统里是不可接受的——出了问题连问题都没法重现更别提定位。我们在西南总部项目里从第一周起就建立了“全链路可复现”的意识。每一次Agent执行任务系统都必须记录完整的请求上下文用户原始输入、意图识别结果、编排后的任务DAG、每一层工具调用的输入输出、模型中间生成内容、最终回复。所有记录关联同一个trace ID这样任何一个线上问题都能按trace逐层回放。技术上要做到这一点需要三个条件所有模型调用统一走网关网关记录完整请求与响应工具调用层全部走统一接口入参和出参都结构化落盘编排引擎支持“按trace重放”而不是只能看最终结果。做不到这三点就谈不上工业级。1.3 第二道门槛责任边界Demo的Agent“说什么都对”生产环境却必须回答一个问题Agent做了决定之后谁负责金融场景里Agent能不能自动发起一笔支付运营场景里Agent能不能直接删除一批用户数据答案显然不是“能”或者“不能”这么简单而是要在架构上区分“建议权”和“执行权”。我们在西南总部项目里把Agent的能力分为三层只读型任务自动完成比如查询、统计、汇总操作型任务Agent生成操作方案关键节点需要用户确认后执行高风险型任务仅生成方案和建议由业务系统走正式审批流程。这个边界必须在编排引擎层面进行控制而不是靠提示词约束。不然模型一次“自由发挥”就可能产生业务事故。2. 四层架构设计意图路由、任务编排、记忆服务与工具网关2.1 为什么放弃“单一大模型一把梭”的架构最开始我们想过一个简单架构接收用户输入直接丢给大模型让它凭借自身能力决定调用哪些工具、以什么顺序调用。这个方案在Demo里很好使但很快就暴露了问题——模型对工具的选择不稳定同一个问题在不同轮次里可能给出完全不同的处理路径同时每次调用都走大模型成本高响应慢。后来我们调整为四层架构把“模型决策”和“确定性执行”拆开。模型负责理解意图、生成任务方案但方案一旦生成就交给一个确定性的执行引擎去执行。这样既保留了模型的灵活性又让执行过程稳定可控。2.2 意图路由层先搞清楚用户要什么意图路由层是整个系统的入口。我们不直接拿大模型来做全量对话而是先用一个轻量级的意图分类模型把用户请求映射到预先定义好的任务类型上。比如“查一下上个月的销售额”会映射到“数据查询”“帮我给华东区的客户发一份活动邮件”会映射到“营销触达”“整理一下这批合同的关键条款”会映射到“文档解析”。意图路由选择轻量模型而不是大模型核心原因有二一是响应速度和成本分类任务的准确率完全可以用小模型达到需要的水准没必要花大模型的钱二是稳定意图分类结果会作为后续编排的强约束分类字段进入系统的结构化协议而不是依赖自然语言。实际运行中意图路由还必须处理“未知意图”。我们维护了一个意图白名单当分类置信度低于阈值时系统不执行任何操作而是直接转为人工兜底对话。这个兜底机制很关键它有效避免了“模型自己臆造一个任务然后强行执行”的风险。2.3 任务编排层由模型生成DAG由引擎确定执行任务编排层是整个架构的核心。用户请求经过意图路由后会进入编排模块。编排模块让大模型根据当前任务生成一张任务DAGDAG中的每个节点是一个具体操作节点之间的依赖关系明确。比如“调研竞品并生成报告”这个任务DAG可能是先并行抓取三个竞品官网信息再汇总对比最后生成报告文档。DAG生成之后执行引擎以完全确定性的方式执行它。执行引擎负责以下事情并行节点并发执行串行节点逐个推进每个节点有超时时间超时后终止并触发重试策略分支节点根据前置节点的执行结果决定走哪条分支整个DAG记录执行状态任何一步失败都可以定位到具体节点。这个设计的价值在于模型的创造性体现在“任务怎么拆”上而“任务具体怎么跑”是由可靠引擎控制的。哪怕模型某次抽风生成了一张有环的DAG执行引擎也能通过DAG校验将其拦截下来而不是像纯对话式Agent那样一路错到底。2.4 记忆服务层让Agent拥有跨会话的业务上下文Agent如果每次都从零开始理解用户的需求体验会很差。用户可能上一轮已经提供了筛选条件这一轮只说“按同样的条件再来一版”Agent必须能接住。我们在架构中单独抽出一个记忆服务而不是把记忆塞在对话窗口里。记忆服务分两层短期记忆以会话为边界保存对话轮次、上下文摘要使用滑动窗口摘要压缩避免token长度失控长期记忆以用户或业务主体为边界保存跨会话的偏好、常查维度、常用报表模板存入向量库并按业务属性过滤。记忆服务独立部署是刻意的设计。它一方面成为所有Agent实例共享的上下文来源另一方面也方便做权限控制——每个用户只能读取自己有权限的长期记忆内容避免信息串号。2.5 工具网关层把工具接入变成标准协议对接一个Agent系统往往要接入大量内部系统BI系统、CRM、ERP、邮件系统、文档系统等。如果每个系统一套对接方式后期维护成本非常高。我们参照MCP的思路在中间加一层工具网关用统一的协议描述工具每个工具通过一个JSON Schema文件声明入参、出参、鉴权方式和调用方式工具网关负责统一处理鉴权、限流、审计日志大模型侧只拿到工具的Schema描述而不是直接访问工具地址。工具网关同时是安全边界。所有Agent对工具的调用都经过网关网关根据调用者身份和权限做校验。这样就能做到Agent模型本身“看到”的工具列表是一回事实际执行时“能用”哪些工具完全由网关控制。这个隔离是生产环境必需的设计。3. 生产环境稳定性会话状态、工具容错与模型兜底3.1 会话状态是Agent最容易出bug的地方Agent任务通常不是一次模型调用就完成的而是多轮工具调用、多步推理的过程。过程中会话状态如果丢失或错乱整个任务就会前功尽弃。我们在生产运行中遇到过几次状态错乱问题根源大多在于异步调用下状态更新的顺序不对。后来的方案是用支持事务的状态存储来管理会话状态每次状态变更都记录版本号读取时按版本获取。遇到需要并行更新状态的场景通过状态合并策略处理而不是简单覆盖。此外会话状态会定期快照到持久化存储中Agent实例重启后可以从最近一个快照恢复任务进度。这套设计就像是游戏里的存档机制。没有存档角色死一次就得从头打有存档哪怕执行进程崩溃也能按照断点续跑。千万别小看这一点Agent任务一旦执行时长超过几分钟断点能力就是刚需。3.2 工具调用失败重试、降级与换路工具调用是Agent系统里最容易出问题的环节。第三方接口延迟、某条数据查不到、权限临时变更都会导致工具调用失败。工业级Agent必须有一套完整的失败处理策略。我们的策略分为三级第一级是重试对于超时、临时性错误按指数退避重试同时要求工具调用具备幂等性第二级是降级如果重试仍然失败系统根据工具重要度降低处理方式比如从“实时同步调用”降级为“异步消息队列排队处理”第三级是换路Agent重新生成任务方案改用另一个等效工具完成目标。比如主数据源查询失败改为从数据仓库的备份表查询。这里有一个关键设计重试和换路不能无脑进行。每一次重试或换路都要记录原因并且设置最大次数限制。当总失败次数超过阈值时Agent必须停止自动处理将任务切换给人工处理同时输出已经完成的步骤和处理过程。这样既保证自动化效率又避免了自动系统在错误路径上无限循环。3.3 模型兜底不同任务用不同模型审校关口独立生产环境不可能只用一个大模型处理所有情况。我们按任务复杂度分了几个模型档位意图分类、DAG结构校验、信息抽取这类结构化任务用轻量级模型对话生成、复杂分析、报告撰写这类生成型任务用全量模型对高风险输出会额外增加一个独立的审核模型专门检查输出内容是否包含违规信息、是否偏离任务要求。审校关口独立是我们在实际项目中非常看重的一点。生成的模型和执行任务的模型如果同源就可能存在“自己审自己”的盲区。用独立的审核模型把关相当于让另一个视角来检查输出显著降低了风险内容漏过的概率。另外模型服务本身也可能超时或不可用。我们在网关层面做了多模型路由主模型超时后自动切换备用模型。这不是简单的故障转移——切换的同时会把已经消耗的token数量记录下来便于成本核算和品质追踪。4. 可观测性与成本控制生产环境最容易被低估的两件事4.1 全链路追踪Agent排障的基本功Agent系统比传统API系统复杂得多一个用户请求会引发一串模型调用、工具调用和数据读取。出了问题没有链路追踪根本无从查起。我们在西南总部项目中要求所有服务统一接入追踪协议将trace ID贯穿始终。从用户在页面上输入一句话开始trace ID就生成之后每一次模型调用、每一次工具请求、每一次状态变更都携带这个ID。有一次线上反馈说“某个报表生成任务经常失败”我们通过trace查看后发现失败原因不在Agent本身而是报表工具在凌晨定时任务高峰时响应变慢Agent等待超时。通过trace里的耗时分布我们把工具的调用时段错开问题就解决了。没有全链路追踪这种问题可能需要排查好几天。4.2 成本账不能只算token费用很多人觉得Agent成本就是大模型的token费用。实际算下来token只是成本的一部分。一个Agent任务可能包含多次模型调用每一次调用都有token费用还有首次失败后的重试调用、降级后的人工处理成本、工具调用的第三方服务费用。我们做了一个简单的成本核算表以“完成任务”为单位计算单位成本直接模型费用每次任务实际消耗的token费用重试费用首次失败后重试带来的额外模型费用兜底费用自动失败后转人工处理的工时成本链路费用工具调用涉及的第三方接口计费。测算下来重试费用可以达到直接费用的20%~40%不容忽视。控制成本的方向也因此变清晰提高首次调用成功率、减少无意义的模型重试、对简单的任务走轻量模型这些带来的收益比单纯压低单次token价格更明显。4.3 防护与合规工具网关对外要锁出口对内要设权限Agent系统因为能自主调用工具天然就是权限和安全的高危点。我们在工具网关层做了两道防护。第一道是出口白名单。Agent的模型服务如果调用外部API必须经过网关并且网关只允许访问预设白名单内的外部服务。这样即便模型被诱导生成了一段恶意请求也无法真正发出到非预期地址。第二道是权限拦截。网关在每次工具调用前会校验当前用户对目标数据的权限范围。比如一个销售主管的Agent可以读取全区的销售数据但一个销售专员只能读自己客户的数据。权限判断不是一个简单的布尔值而是在数据行级和列级做过滤。有一位刚接入的同事问过“权限在哪一层做比较好”。我们的经验是在工具网关层做一次粗粒度校验在数据服务层再做一次细粒度过滤。两层缺一不可。只靠网关遇到复杂数据模型容易漏只靠数据层Agent可能已经带着敏感数据走了一轮模型泄漏风险反而更大。5. 上线初期踩过的三个典型坑经验复盘5.1 上下文塞得越多效果反而越差最开始给Agent设计提示词时我们担心模型缺少信息在一个任务里把系统角色定义、工具说明、用户背景、历史摘要、业务规则全部塞进去。结果发现模型在处理复杂任务时经常抓不住重点采样的关键信息被大量无关上下文淹没。调整的方式是做上下文的分级管理。全局共性信息放进系统提示词任务相关信息放在用户提示词会话摘要由记忆服务按需注入工具说明只在对应DAG节点执行时注入。这样模型每次决策时面对的内容更聚焦响应质量和稳定性反而提高了。5.2 换个大模型不等于业务效果变好有一段时间内部测试反馈说“生成报告的质量不够好”团队第一反应是“换更大的模型”。结果换了之后报告文笔确实流畅了一些但核心数据错误率并没有下降反而因为大模型更“自信”出错时更难以被察觉。后来我们不再凭主观感受评判模型效果而是建了一个业务评测集。这个评测集覆盖了数据查询、报表解读、任务拆解、异常处理等高频场景每一项都有明确的对错标准。每次更换模型版本或调整提示词先在评测集上跑一遍看关键指标变化。评测集上线后模型效果的判断才真正变得客观可衡量。5.3 权限配置不完整工具越早放权风险越大一次联调中有同事发现Agent在测试环境里能读取另一个部门的数据。排查后发现是工具网关的权限配置漏了数据归属维度只做了用户维度的校验。这类问题在传统系统里可能很晚才暴露但Agent系统因为执行速度快、可并行的调用多暴露面和影响速度都更大。此后我们把“权限最小化”作为Agent工具接入的一项前置检查。每个工具在接入测试前必须提交权限矩阵明确哪些角色、哪些数据范围可用测试环节中专门增加越权用例确保Agent在“收到高权限指令但不具备实际权限”时会明确拒绝执行并告知用户而不是忽略权限盲目执行。如果让我重新做一次这个项目我会把可观测性体系搭建得更早。Agent的智能来自模型但工程系统的可靠性来自可观测、可复现、可控制这三个基本盘。模型更新很快应用边界也在不断被探索但围绕Agent生产落地的这些工程方法和经验在短期内会是更稀缺、也更值得被积累的东西。