干架构这行十几年，最怕听到一句话：“老王啊，这几个系统帮我们通一下呗。”每次听到，我脑子里已经浮现出一张几百个接口互相乱连的蜘蛛网，以及无数个“加个字段就要改三个系统”的深夜。今天不聊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系统是“status=3”，在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网关暴露成HTTP+JSON。这里强调一点：能通过接口接的就用接口，实在没有接口的系统，才考虑用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( name="query_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这套组合，目前还没夸张到能取代集成团队的程度，但它在“翻译字段”“查询多源数据”“自动生成流程草稿”这类脏活累活上，确实能把人解放出来。我个人最大的体会是：别把它当成无所不能的神，就当成一个很聪明但偶尔会走神的实习生。给它清晰的工具、明确的边界、完整的审计，它就能成为团队里干活最勤快的那一个。如果哪天你也要动手做类似的集成，我的建议很简单：选一个最折磨人的手工流程，先打透它，剩下的路会自己长出来。
