干架构这行十几年最怕听到一句话“老王啊这几个系统帮我们通一下呗。”每次听到我脑子里已经浮现出一张几百个接口互相乱连的蜘蛛网以及无数个“加个字段就要改三个系统”的深夜。今天不聊PPT上的数字化转型就聊聊刚过去的这大半年我自己动手用大模型Agent这套组合替某制造企业把四套核心系统之间的数据孤岛和流程断点打穿的过程。方案思路、技术选型、落地步骤、踩过的坑我都会摊开讲算是一份能直接参考的实战记录。这套思路与传统集成最大的区别在于它不追求把所有系统揉进一个平台而是让Agent变成一个“懂业务语义的翻译官”加“流程调度员”在系统之间做一层不那么厚重的智能胶水。先说结论如果你正准备搞一套“全域数据中台”或者正在考虑要不要再买一套ESB升级版我建议你先停下看完这篇文章再决定。1. 先看清问题企业集成为什么总变成“屎山”1.1 传统集成方案的三个死穴很多企业的系统集成史就是一部踩坑史。最常见的路数是点对点集成两个系统之间拉一条直线三五个系统还受得了到了二三十个系统就成了一张越缠越紧的网。每接入一个新系统都要跟老系统单独对接一遍接口数量差不多是O(n²)级别的增长。我今天在A系统加一个字段明天就得去B、C、D三个系统同步改接口改错一个数据对不上业务部门马上来问。后来有人受不了了引入ESB企业服务总线做集中式路由。理论上所有系统都挂到总线上点对点连接变成星型连接规则统一在总线上做。但实际用下来问题也不少总线配置本身就极其复杂报文转换、路由规则、协议适配每一层都是配置地狱。想改一条字段映射要提需求单、走审批、排期上线快则一周慢则一个月。日子一长总线上挂满了没人敢动、也说不清楚作用的旧规则ESB本身又成了一座新的屎山。还有更麻烦的大量业务规则其实硬编码在系统代码里。状态审批流、字段转换逻辑、异常分支判断全散落在各个项目的代码仓库中。外包团队换了一茬又一茬接手的人看着一段几百行的状态机转换代码根本不敢动因为没人知道当时为什么这么写。三类传统方案的核心问题总结成一个字就是“闷”改了不知道影响哪里加需求不知道从哪里下手出了问题不知道如何排查。方案类型典型表现成本特征变更风险点对点集成接口数量随系统数平方级膨胀开发成本线性上升后期维护成本爆炸改一个字段牵连一片ESB/中间件配置复杂规则脚本冗长前期采购和实施成本高老规则无人敢动硬编码规则业务逻辑散落在代码深处短期开发快长期债务重人员流动后知识断层1.2 数据孤岛不只是系统没打通我遇到过很多次业务部门抱怨“数据不通”技术团队第一反应是“再拉一条接口”。但真正堵点往往不在接口而在三个层面。第一层是物理隔离。各系统用了不同的数据库、不同的接口协议、不同的部署环境有些老系统还是十年前的技术栈连个像样的API都没有只剩一个数据库连接串。第二层是语义隔离。这是最容易被忽略的。同一个“客户”在CRM里叫customer_id在ERP里叫client_no在MES里叫partner_code长度、类型、枚举值都不一样。“订单状态”在A系统是“已审核”在B系统是“status3”在C系统里干脆叫“放行”。传统做法是维护一张字段映射表靠人工一条条对人对得上就有数人一离职这套规则就埋进了系统的某个XML配置文件里再也没人说得清。第三层是流程断点。系统之间即使数据通了业务流程也是断的。销售要查订单生产进度得先从CRM登录看合同再切到ERP看订单再去MES看工序状态三个系统三套账号来回切换五六次。一旦发现交付延期还得自己写邮件、打电话去催。这套“人工搬运人工判断”的模式才是效率黑洞的根源。所以“打穿数据孤岛”这件事真正的难点不在于把接口接通而在于让系统之间、人和系统之间能用统一的语言协作起来。2. 大模型Agent的定位干“胶水层”的活不碰业务核心里去2.1 Agent的两种核心能力看懂需求、调用工具很多人一听到Agent就想到全自动智能机器人觉得它能自己思考、自己决策、自己搞定一切。实际用下来Agent最核心的价值就两个看得懂模糊需求调得起具体工具。看得懂模糊需求靠的是大模型对自然语言的理解能力。销售说“查一下SO20240101这个单子什么状态了”传统接口需要前端页面去解析、拼参数、查库而Agent可以直接从这句话里抽取出订单号、意图和查询范围。再进一步销售说“最近一周有哪些订单可能要延期帮我整理个清单发给计划部”这种跨系统、跨语义的复合指令传统接口只能摇头Agent却能拆解成“查ERP交期→查MES进度→比对差异→生成报告→调用OA”一系列动作。调得起具体工具靠的是Function Calling函数调用机制。大模型本身不会直接连数据库、调HTTP接口但我们可以把每个系统的能力封装成“工具”注册给Agent。工具描述里写明名称、功能、入参出参的JSON Schema大模型面对用户的自然语言请求时会自己决定该调哪个工具、传什么参数。配合ReAct思考-行动-观察循环Agent还能根据工具返回结果决定下一步动作。用生活类比就是你让一个实习生“把上个月的销售数据整理出来发我”。他不懂SQL语法也不一定知道数据库表结构但他知道先去打开BI系统、选中日期、导出Excel、再粘贴到邮件里发给你。Agent就是那个实习生大模型就是他的脑子工具就是他能用的那台电脑。2.2 为什么不是再买一套ESB或RPA第一次给团队讲这个方案时有个老开发当场就问这不就是ESB加了个聊天框吗RPA不是早就干这个事了吗不是。ESB解决的是系统间报文传输和路由它不理解业务语义。ESB知道把A系统的订单报文转发给B系统但它不知道用户说的“可能延期的订单”该怎么翻译成查询条件。RPA擅长模拟人在界面上的点击操作但本质上它是按脚本执行页面一改、按钮一挪脚本就碎了维护成本极高。大模型Agent和它们不是替代关系而是上下层关系。Agent负责“理解意图、拆解任务、做决策”至于实际去查ERP、写MES、发OA可以调用接口也可以指挥RPA去操作那些没有API的老系统。换句话说Agent站在ESB和RPA之上把原来需要人来做的那层“翻译”和“判断”接了过去。当然Agent也不是万能的它的边界我得说清楚涉及实时交易、财务结算、生产指令下发的核心动作不要让Agent直接做。它就是编排层不是执行引擎更不是业务系统本身。3. 参考架构与技术选型从零搭一套Agent集成层3.1 四层架构接入层、语义层、编排层、审计层真正动手设计这套集成层时我没有一上来就写代码而是先画了四层架构每一层管一件事互不越界。接入层负责把遗留系统的能力封装成标准接口。不管底下是SAP、Oracle还是某个老掉牙的MES统一通过API网关暴露成HTTPJSON。这里强调一点能通过接口接的就用接口实在没有接口的系统才考虑用RPA采集。禁止让Agent直接连数据库一票否决后面会讲为什么。语义层是整个方案的关键。把各系统五花八门的字段、实体、枚举统一成一套“语义模型”。例如“客户”“订单”“物料”“工序”这些核心实体在语义层里定义成统一的JSON Schema字段名、类型、含义、别名都写在里面。Agent读的是这套统一模型而不是某一个系统的原始接口文档。编排层负责流程。每一条业务流程被定义成一组有序节点每个节点可能是一个工具调用、一个条件分支、一个并行任务也可能是一个人工审批点。Agent在编排层里做决策、调用工具、检查结果流程引擎负责控制流转。审计层负责留痕。Agent每一次的思考摘要、工具调用入参出参、耗时、决策路径全部落库。没有审计层的Agent系统上线后一旦出错连甩锅的素材都找不到。四层分开的最大好处是哪一层出了问题排查范围一缩就锁定了。流程走到一半卡住了先看编排层节点状态数据字段对不上去语义层查映射接口超时了去网关看日志不需要再从一堆乱麻里从头捋。3.2 技术栈选型模型、框架、网关选型这件事每个人都有一套道理我说说我的取舍。大模型选了一款对中文业务术语理解较好、支持Function Calling、上下文窗口足够大的商用通用模型。为什么不用开源小模型因为企业业务文档和流程描述里到处都是“非标准化”写法小模型的工具调用稳定性和指令遵循能力在实际场景里差距非常明显。为了省一点算力钱让Agent天天理解错需求不值当。当然成本敏感的场景可以用小模型先初筛、大模型做决策这个后面再聊。编排框架选了一套基于“图编排”思路的开源Agent框架。它支持条件分支、循环节点、并行执行还有人审确认节点这两个能力是关键。很多早期Agent项目死在“只能走直线”上——流程稍微有个分叉、来一个“如果延期货大于等于X天则走催办”的规则框架就僵住了。图编排框架天然把流程当有向图而不是线性链来建模复杂分支就自然了。接入层直接用了开源API网关把四个系统的接口全部挂上去统一鉴权、限流、超时控制。这块没必要自研网关的成熟度已经很高了自己造轮子纯属浪费。选型我列了一张对照表方便自己团队复盘用层面选项最终选择理由大模型商用通用模型 / 开源模型商用通用模型工具调用稳定术语理解力强编排框架自研 / 开源图编排框架开源图编排框架支持分支循环、人工确认、可视调试API网关商用网关 / 开源网关开源网关成熟稳定统一鉴权限流审计存储关系库 / 日志系统关系库对象存储留痕可查询大对象存文件3.3 语义层设计与工具注册语义层我花了整整两周来做因为这直接决定了Agent的“智力上限”。做得糙Agent看到的是各系统自己那套字段命名靠大模型硬猜做得好Agent看到的是一个结构清晰、自解释的业务数据模型理解准确率会高一大截。以“客户”为例我在语义层定义了统一Schema把四个系统里的客户相关字段全部收拢进来。字段命名、类型、枚举值都标准化同时保留各个系统的别名映射。这样Agent拿到用户的查询请求后先映射到统一模型再通过别名找到具体系统里的实际字段整个翻译过程对用户完全透明。工具注册就是一个装饰器的事把接口元信息描述清楚Agent就能看到并调用。agent_tool( namequery_order_status, description查询订单在ERP和MES中的生产状态及延期风险, parameters{ type: object, properties: { order_no: {type: string, description: 业务订单号格式如SO20240101} }, required: [order_no] } ) def query_order_status(order_no: str): # 先查ERP订单头信息再查MES工序明细 erp_order erp_client.query_order(order_no) mes_stages mes_client.query_stages(order_no) return { order_stage: erp_order[stage], next_due: erp_order[delivery_date], progress: mes_stages[overall_progress], risk_level: calculate_risk(erp_order, mes_stages) }每次新增接入一个系统团队只需要做两件事在网关上登记接口然后按统一模型把该系统涉及的数据实体注册成若干工具。这样Agent的能力池就跟着扩展不用改任何流程代码。这里有个经验工具描述写得越详细Agent的选择准确率越高。别用“查询订单”这种一句话描述要把入参含义、返回值字段含义、使用场景注意事项都写清楚它才不容易选错。4. 核心环节落地某制造企业的跨系统流程自动化全记录4.1 第一步把遗留系统封装成“Agent工具”前两个月的项目核心场景是做“客户360度视图”和“销售催单自动化”。原来的流程是销售想催订单先登录CRM看合同信息切到ERP看订单交期再登录MES看生产工序最后根据延期情况判断要不要发催办邮件。一整套下来熟练的人也要十五分钟不熟练的可能半小时而且经常漏看某一个系统的关键节点。改造第一步就是把四个系统的接口封装成Agent工具。CRM提供合同查询、ERP提供订单与交期、MES提供工序进度、OA提供审批与消息发送。每类能力都注册成上面那种带完整描述的工具。光这一步就花了不少时间跟老系统对接有些系统连接口都没有只有报表导出功能后来用RPA模拟导出再解析文本才补上。封装时有一个细节要特别注意必须保持工具的输入参数强校验。我一开始没做严格校验Agent在用户没提供订单号时居然自作主张猜了一个单号去查结果查出来的是别人的订单。后来在工具装饰器层加了两道保险必填参数缺失直接报错要求Agent补充询问参数格式不合法也不允许透传。宁可让流程卡住也不能让错误参数进系统。4.2 第二步定义统一数据模型消除“叫法不一致”语义层建成后最明显的效果是Agent终于能听懂业务人员的行话了。销售说“帮我看看A客户那批货现在到哪一步了”Agent不会傻乎乎地去找一个叫“A客户”的字段而是通过统一模型定位到客户实体再根据上下文里的时间、产品信息匹配到对应的订单和工序。这一步怎么实现的举例MES里将订单类型分为“量产”和“试产”ERP里则称为“正式订单”和“样品订单”语义层枚举标准化后统一映射为“量产正式订单”“试产样品订单”等对应关系。Agent查询时自动按映射关系处理不会因为叫法不同而漏查。数据模型统一这块偷不得懒各系统字段的真实情况一定要找业务人员逐条确认不能对着数据库字段名硬猜。{ entity: order, aliases: [订单, 销售订单, SO], fields: { order_no: {type: string, alias: [订单号, SO编号]}, customer_id: {type: string, alias: [客户编号, customer_id, client_no]}, delivery_date: {type: string, format: date, alias: [交期, 承诺交付日]}, status: { type: enum, values: {confirmed: 已确认, producing: 生产中, delayed: 已延期}, alias: [状态, 订单状态] } } }4.3 第三步编排一条真实流程——销售催单自动化当四套系统的能力被封装成工具、语义模型也跑通之后剩下的就是流程编排。拿销售催单自动化来说我把原来人工操作的六个步骤直接转换成了Agent编排层的六个节点。整个过程是这样的销售在协同办公软件里输入“帮我看下SO20240101这个单子现在到哪步了如果按计划要延期帮我通知计划部”。Agent先抽取订单号调用查询工具拉取ERP交期再查MES工序进度比对当前日期与计划日期如果偏差天数超过阈值则走到“生成延期说明”节点根据各系统数据生成一段“说人话”的汇报内容最后调用OA接口发起一条待审批的通知流程。这里最重要的设计是“人工确认节点”。Agent生成延期通知草稿后不会直接发送而是先把草稿推送给销售确认。销售看内容没问题点一下确认才真正发起OA流程。这一点必须坚持因为Agent是根据数据推断的延原因没有业务人员把关直接发给计划部万一推断错了就是一场尴尬的跨部门事故。流程上给一个关键节点示意用户输入请求Agent解析意图与订单号调用ERP接口查询订单交期与状态调用MES接口查询当前工序与进度计算延期风险若风险低于阈值返回汇总结果流程结束若风险高于阈值生成延期说明草稿推送人工确认人工确认后调用OA接口创建催办任务并通知计划部全程记录审计日志流程状态可查这套流程上线后单次催单从十五分钟降到了三分钟以内其中大头还是人工确认那一步。销售不需要再登录三个系统来回翻了Agent把所有数据都聚合在一张卡片里。4.4 写操作、人工确认与兜底策略在整套方案里我坚持一个原则查询类操作可以全自动写操作必须有人审。Agent能查询订单状态、能汇总延期清单、能生成通知草稿但它不能直接改ERP的交期不能直接发起付款不能直接给客户发正式函件。这些写操作全部要经过一个显式授权节点Agent先输出建议指令和理由由有权限的人审核后再调用对应系统接口执行。这个兜底策略背后有个惨痛教训。项目早期我关闭了某个测试环境的人工确认开关想观察Agent全自动跑批的效果。结果Agent在一条数据上判断出错把一个供应商的付款建议金额从我预期的整数金额算成了另一个数,还好测试环境不影响生产但那次之后所有写操作一律恢复人工审批“先确认再生效”成了团队内部铁律。5. 踩坑实录与排查技巧从幻觉、超时到权限失控5.1 Agent“幻觉”引发误操作怎么防前面提到Agent在缺参数时自己编了一个订单号这就是典型的模型幻觉。大模型本质上是概率生成它会在上下文里“填空”如果上下文里没有它就会根据经验猜一个最像的。防幻觉没有一招鲜我做了四件事。第一工具层强制校验。必填参数缺失、格式不对直接返回结构化报错不让模型蒙混过关。第二查询结果返回候选列表。当订单号无法唯一匹配时Agent返回多条候选让用户选择而不是默认取第一条。第三上下文里显式声明“如果没有确切信息必须继续询问”。这个指令写进System Prompt能显著减少猜答案的概率。第四审计复盘。把每次Agent工具调用的入参记录下来每周复盘一次看看哪些参数是模型“编”出来的针对性补充校验规则。5.2 调用超时与重试风暴Agent串行调用多个工具时有一个很现实的问题外部接口响应慢单个接口耗时2秒串行调四个就是8秒加上大模型推理时间用户等得烦躁。我还遇过一次外部系统抖动Agent调用失败后按默认策略重试结果引发了重试风暴把本就吃力的老系统直接打挂了。应对办法第一给每个工具调用设置超时时间超过3秒直接标记失败不让请求无限挂起。第二重试次数严格限制默认最多一次且要加上随机退避避免所有重试在同一瞬间涌过去。第三对写操作引入幂等键用“业务类型目标单号操作内容”生成唯一标识就算重试系统也只会处理一次,不会重复写入。幂等说起来抽象其实就像超市收银员同一瓶水不小心扫了两遍但结账系统记住这是同一个商品只收一次钱。这里给一张常见问题速查表都是我实际踩过、排过的现象可能原因解决办法Agent编造参数调用工具上下文缺少明确参数模型在猜工具参数强校验候选列表确认提示词显式要求追问工具调用响应超时外部系统慢串行链路累积设置单次超时总预算控制引入异步队列重试导致下游被压垮重试策略太激进限制重试次数随机退避写操作做幂等Agent调错工具工具描述不清晰、相似工具太多丰富工具描述明确区分使用场景定期复盘错误日志流程卡住无响应模型死循环或等待未知输入设置最大循环步数超时转人工保留上下文快照5.3 权限模型与审计追踪Agent集成层最容易忽视、也最容易出事的就是权限。因为Agent是“人”但又不是人它不会累、不会烦但如果权限给大了它会造成远超人类的破坏速度。我的权限模型分三档只读、需审批、禁用。默认所有Agent拥有的都是只读权限能查、能读、能汇总但任何修改类、发送类、执行类操作都在“需审批”档里必须经过人工确认。至于“禁用”档不解释明确标注哪些系统、哪些操作不允许Agent触碰例如直接写数据库、修改财务凭证。审计追踪方面Agent每一次工具调用的入参出参、耗时、模型决策summary都会同步到审计库。这样一旦出了数据问题可以回放整个决策链路几分钟就能定位到是哪一步、哪个系统、哪个模型版本导致的。5.4 关于模型调用的成本控制还有一个不能回避的坑大模型按Token计费Agent一次流程跑下来可能调用好几轮模型成本积少成多。我做了两层优化。第一层简单查询走规则引擎不经过大模型。比如“查订单状态”这种结构化明确的请求先用意图规则直接命中省掉模型调用。第二层先用小型模型完成意图分类只把复杂流程交给大模型决策。实测下来四成请求可以走轻量路径成本能省将近一半。6. 几点真心建议先打小切口再谈平台化6.1 从“最痛的手工活”入手如果你也想做类似的事情我的首要建议是别一上来就搞全域数据中台。先找一条最痛、最重复、出错最多的手工流程入手比如客服查订单进度、销售催单、跨系统对账差异解释。这样的场景业务痛感强上线后效果立竿见影团队才有信心继续投入。我这次选择催单流程就是这个原因它跨三个系统、重复性高、每单都要做比做一张全公司报表有价值得多。6.2 留好人工兜底别信Agent的“自信”大模型的输出常常带着一种“笃定感”哪怕它自己也不太确定。所以在涉及资金、合同、生产这类高影响操作时默认“建议加人工确认”永远不会错。Agent负责把活干到“万事俱备只欠确认”的程度人做最后一道把关效率和风险控制都能兼顾。6.3 越用越顺手关键是复盘Agent系统不是上线就完事了。我每个月会拉一次工具调用的失败记录把那些高频报错、模型理解偏差的案例拎出来要么补充校验规则要么优化Prompt要么在语义层里加别名映射。这套系统越用越“懂”业务靠的就是持续复盘没有第二种捷径。最后说点真心话。大模型Agent这套组合目前还没夸张到能取代集成团队的程度但它在“翻译字段”“查询多源数据”“自动生成流程草稿”这类脏活累活上确实能把人解放出来。我个人最大的体会是别把它当成无所不能的神就当成一个很聪明但偶尔会走神的实习生。给它清晰的工具、明确的边界、完整的审计它就能成为团队里干活最勤快的那一个。如果哪天你也要动手做类似的集成我的建议很简单选一个最折磨人的手工流程先打透它剩下的路会自己长出来。