最近频繁被拉到同一类项目会上问题几乎是复刻的ERP、MES、WMS、QMS 的接口都签完了网关里几十个 API 全都调通Agent 查订单能查订单查库存能查库存质检数据也能给你拉出一大串。可一到业务判断环节就哑火——问它这批货能不能放行它抱着检测数据念了一遍给不出结论问它这个订单能不能插单它东拼西凑编了个答案业务部门根本不敢用。这不是个别现象。我这两年接触的智能体项目一半以上卡在这一环。大家普遍有个默认假设系统数据通了Agent 自然就有了判断依据。实际上数据可访问和业务可判断之间隔着的不是一层接口而是一整套语义对齐、规则建模和决策设计的工程。今天这篇就把这个从数据通到判断对之间的坑一层一层拆开讲。1. 先还原现场系统全通了Agent 怎么还在裸奔1.1 项目走到这一步问题出在哪把这类项目当初的设计逻辑拆出来看其实就三层第一层数据打通。ERP/MES/WMS/QMS 接口全部调通Agent 能查出任意系统的数据。第二层数据理解。Agent 知道每个表、每个字段大概是什么意思能把数据组织成回答。第三层业务判断。Agent 基于数据、规则和上下文给出可执行、有依据的结论。大部分项目止步在第一层偶尔摸到第二层,根本没往第三层走。问题不在 Agent 的技术能力而在于整个链路里缺了三样东西统一的业务语义、显性化的决策规则、可靠的上下文组装机制。说句公道话这个坑不是技术团队单方面挖的。业务方说你们把系统接好Agent 就能帮我决策技术方默认给 Agent 配好工具它自然就会分析两边都跳过了最麻烦的一步把判断这件事本身讲清楚。如果你现在也被系统都接上了判断还是做不了困住先别急着怀疑 Agent 框架选型九成概率是下面三个环节出了问题。1.2 为什么数据能查和业务能判差这么远打个比方你就懂了。你把全世界最好的图书馆管理员请来把所有书都搬到它面前它还是回答不了我该选哪本书送给一个喜欢推理小说的朋友——因为它没有读者的偏好数据更不懂推理小说在这个语境下到底指什么。系统对接解决的是书拿到了业务判断需要的是知道读这本书的人、写这本书的圈子、以及为什么推荐这本而不推荐那本。放到企业场景里Agent 做业务判断至少需要三样东西同时到位数据多系统里准确的、口径一致的数据。规则业务上明确规定的判断标准或者老师傅总结出来的决策经验。上下文当前场景特有的约束条件比如客户关系、产线状态、时间窗口、历史异常等。数据通了只解决了第一项。剩下两项恰恰是绝大多数项目没有建的。2. 数据不等于语义接口打通只是翻译了字段没翻译业务2.1 字段名一样意思可能完全两回事我见过一个真实的翻车案例。某制造企业的 ERP 和 MES 里都有完工这个状态但 ERP 的完工指财务记账维度的生产订单关闭MES 的完工指最后一道工序报工完成。Agent 从两边查到完工后直接把两条数据当成同一个概念去推理结果把一个财务上还没核销的订单判断成了可交付差点发错货。这种错误在业务上非常严重但技术侧根本发现不了因为两边字段名长得一模一样。类似的情况还有同样叫批次号ERP 里是采购批MES 里是生产批QMS 里是质量追踪批三者有关联但不是同一个东西同样叫库存WMS 里的库存是实物库存ERP 里的库存是账务库存账实差异本来就存在Agent 不区分数据口径判断必然偏。做接口联调时大家做的是字段级映射这个字段对应那个字段属于语法层面的对应关系。但业务语义层的对齐是另一件事——你要明确告诉 Agent这两个字段名虽不一样指向同一个业务对象那两边虽然字段名一样一个是财务口径一个是实物口径。这个工作我们叫业务数据字典可惜大部分项目根本没做。不做这个Agent 越勤奋错得越丝滑。2.2 容易漏掉的数据暗坑时效、单位、颗粒度、生命周期除了语义数据本身的潜台词也特别坑。整理几个我踩过或者看别人踩过的时效性。ERP 的数据经常是批处理同步的T1 是常态WMS 是实时库存MES 的工序数据可能是分钟级更新。Agent 同时拿到三个系统的数据等于把三个不同时间点的快照混在一起推理这在业务上是不允许的。比如库存判断按 WMS 实时库存算可能还有货按 ERP 账务库存算已经扣完了。Agent 得知道每个数据源的时效并且统一时间基准。单位。ERP 里可能用标准单位件MES 按 BOM 单位可能是套采购单用箱。数字对不上 Agent 又不做归一化直接算出错误的欠料数量。这个问题在离散制造业特别常见设计单位、工艺单位、包装单位混在一起光换算规则就能写一页。颗粒度。订单在 ERP 是行项目级别工单在 MES 是工序级质检报告按批次。层级不对齐数据拼不到一张图里。比如判断这个订单能不能按时交付需要把订单行、工单、工序进度、库存可用量逐层关联起来任何一个环节少了一个维度判断就是残缺的。生命周期。很多判断依赖状态变更的历史路径不只依赖当前状态。比如能不能变更工艺要看工单当前状态、有没有已领料、有没有已报工、有没有质检异常待处理。如果你只喂 Agent 一个当前状态字段它就没有足够信息做判断。2.3 给 Agent 补上下文两种行之有效的做法解决语义问题靠的不是运气而是工程手段。我验证过比较有效的有两类做法。第一种做一张业务对象地图也叫做语义层。不急着堆接口先梳理核心业务对象客户、订单、工单、批次、库存、质检报告、设备、工序……每个对象定义清楚主键、业务含义、状态机、跨系统映射关系。Agent 在回答问题前先通过语义层定位用户说的对象到底对应哪种数据再去系统里取数。这一步做扎实了后面所有环节都轻松。第二种给 Agent 配备场景数据包。针对每类判断场景比如订单可否承诺批次可否放行工单可否插单预先列出所需的全部数据项清单包括当前值、历史状态、关联单据、时间戳。Agent 判断前先组装数据包再进入决策逻辑。这比让 Agent 自己临时决定查什么、不问就下结论要可靠得多。我在这第二个方案上吃过甜头把数据包定义成标准协议之后换新场景只需要定义新模板Agent 侧代码几乎不动。但前提是语义层先建好否则数据包里的字段依然各说各话组装起来也是张冠李戴。3. 真正的门槛业务判断逻辑从来没有被写下来过3.1 规则不在系统里在人的脑子里这是最核心、也最被低估的一关。很多企业以为系统都接上规则自然就有了。实际上绝大多数业务判断逻辑根本没有被数字化过。老师傅的判断方式可能是这样的这个客户是老客户了上次虽然出过质量问题但后面处理得很配合这次优先级可以正常排。周五下午了产线马上排下周的班这个单子要是不今天放下去下星期就来不及。这个批次虽然数值合规但最近供应商换过生产线我得再看看过程数据才敢放。这个物料看着库存够但那批在途订单已经锁定了实际可用量没这么多。这些判断依据哪个系统里有ERP 里没有客户历史质量表现这个字段MES 里没有产线排产窗口这个逻辑QMS 里没有供应商变更记录的关联。Agent 面对这样开放的线索只能瞎猜更常见的是它不敢猜给你来一句根据现有数据我无法做出判断。业务方听到这句话直接判定项目失败。但真不是 Agent 不行是它根本没有拿到判断的依据也没人告诉它什么叫正确的判断。3.2 判断逻辑不只是规则还有优先级和例外就算把规则一条条列出来了事情也还没完。真实的业务判断至少包含三层结构硬性规则。比如无合格报告不得放行安全库存低于下限不得承诺交期。这类规则是确定的适合写成代码或规则引擎。权衡逻辑。交期、质量、成本三个维度经常打架要用优先级和权重来权衡。比如客户要求加急但加急会增加质量风险该怎么取舍这需要一套显性的权衡口径。例外与人工授权。规则总有例外比如该批次检测异常但客户允许让步接收紧急插单突破正常排产限制。这些例外在系统里没有登记但 Agent 完全不知道例外存在就会做出比人更僵化的判断。做业务判断的 Agent 如果只做了第一层充其量是个快的办事员称不上判断者。第二层和第三层才是它区别于查询工具的关键。但第二层往往需要业务专家深度参与第三层则需要一套人工处理流程异常上报、人工审核、操作留痕这些都需要组织配合技术团队自己关起门来搞不定。3.3 把人的判断萃取出来我的经验萃取方法我自己做过好几轮规则萃取攒了一些还算有用的方法第一别开大会要蹲现场。把业务专家按着聊一两个小时效果远不如跟着他们看半天实际作业。看他拿起电话问谁、翻哪个系统、核哪张单你会意外发现大部分判断触发条件藏在操作习惯里他自己都未必意识得到。第二记录例外事件比记录正常流程更有价值。正常流程在每个系统里多少有点影子例外才是知识盲区。我问专家时特别喜欢问上一次你做决定拿不定主意是什么事最后怎么解决的这个问题一抛出去能撬出大量珍贵经验。第三让规则接受真实数据的检验。萃取出来的规则必须用历史数据回测——拿过去半年上百个真实判断案例让规则跑一遍看跟实际决策结果差多少。反复迭代直到命中率可以接受再上线给 Agent 用。这个环节的投入远大于接口开发但是性价比最高。规则萃取做到位Agent 的每一个判断都有依据、可解释做不到位Agent 就是个会说话的报表。4. 把判断能力工程化三层架构与一套落地路径4.1 分层设计别让 Agent 单打独斗实践下来Agent 做业务判断的稳定架构是三层数据服务层。承接语义层职责负责多系统数据的统一取数、映射、组装。Agent 不直接面对几十个异构接口而是面对一个经过语义对齐的数据服务。这一层解决数据来源和质量的问题。规则与知识层。硬性规则决策表、规则引擎、业务知识实体关系、状态机、判断依据的元知识都放在这层。这一层解决依据什么来判断的问题。Agent 表达层。LLM 或 Agent 逻辑负责组织判断过程、解释判断依据遇到规则覆盖不了的灰色地带做初步判断并把存疑项提给人工。这一层解决怎么输出和沟通的问题。把三层职责分开就不再要求 Agent 一个人干所有活它只是最后一层理解用户意图调用规则和数据组织输出。这么做的好处是每一层的错误可以被隔离和追责不会出现Agent 一本正经地胡说八道你还不知道是哪一个环节出了问题。4.2 规则显性化把 SOP 变成可执行的决策模型规则层具体怎么落地我给一条实践路径第一步选一个高频且边界清晰的判断场景。别一上来搞全流程决策太贪。比如订单交期承诺或批次放行先做一个跑通了再扩。第二步把判断点和条件画出来。可以先用决策树表达但最终建议落在决策表上。决策表的优势是条件、动作一目了然业务专家看得懂、可以亲手纠错不会出现当时说的规则和最终落地的规则根本不是一回事。第三步把决策表落成可运行代码或规则引擎配置。我一般建议用规则引擎原因有二一是规则变更频率远高于代码变更改配置比改代码快得多二是规则引擎天然支持条件组合、优先级和冲突检测比手写一堆 if-else 好维护得多。第四步给每条规则配上解释文本。Agent 命中某条规则后输出结论的同时把命中了哪条规则、输入了什么数据讲给用户听。这是建立信任的关键——业务方一旦能看到判断依据才愿意把决策权交给系统。4.3 灰色地带的处理规则引擎兜底LLM 处理模糊地带这是团队最纠结的地方到底让 LLM 做判断还是规则引擎做判断我的经验是别搞二选一要搞分工规则能覆盖的让规则引擎果断输出。判据清晰、可复现、可解释这是规则引擎的主场速度快还稳定。规则覆盖不到的模糊地带让 LLM 做初步推理和方案排序输出几个候选方案和各自理由但最终结论必须落到推荐 人工确认的流程里。LLM 的输出必须套模板不能让它自由发挥直接定结论。模板至少包含前提条件、参考数据、可选结论、风险提示。模板一约束一本正经胡说八道的概率会大幅下降。这套分工背后是可靠优先的工程理念业务判断是要担责任的宁可生产率低一点稳定性和可解释性不可妥协。你也不希望你的 Agent 哪天在给客户的承诺交期上创作一把。4.4 落地节奏先跑通一条链路再谈规模项目推进节奏我建议拆成四个里程碑单场景单数据源验证一个判断场景、一个系统数据源把链路跑通。单场景多数据源加入语义层和数据包组装实现基于多系统数据的判断。多场景规则沉淀把验证过的规则沉淀到规则库形成可复用资产。人工闭环与持续迭代每一单判断结果保留人工反馈持续修正规则和模型。每一步设置明确的验证标准避免项目干到一半发现地基是歪的这种大返工。这个节奏我亲测有效关键是不贪多一个一个场景来。每次跟项目组开会我最怕听到的一句话就是我们准备一次性把全流程做出来这种项目我几乎没见过善终的。5. 踩坑实录这些问题我基本都踩过5.1 几个典型的翻车现场坑1接口映射当成语义对齐。项目组做了几百个字段的映射表就宣布数据层完成。结果 Agent 把数据库里的创建日期当成事件日期直接导致判断错了一天。从那以后我要求所有字段映射必须标清业务含义和口径说明不只写对应关系。坑2把希望全押在 LLM 的悟性上。一开始我们让 Agent 自由发挥觉得传几个 system prompt 它就能懂业务。事实证明没有规则支撑的 LLM 会生成非常流畅的错误答案而且每次错得都不一样极难排查。这种错误比干脆不回答还可怕因为你的注意力全被花费在验证它的答案上。坑3没有历史基准就上线。在批次放行场景里我们自认为规则萃取很完整结果业务专家试用第一周就不满意——漏了供应商变更后首件需加严检验这一条而那正好是当时某批次的关键问题。后来加了历史数据回测环节这类遗漏才被系统性发现。坑4忽略了判断可解释的硬需求。早期 Agent 给结论时只输出结论业务方完全不接受你们凭什么让我放行出了问题谁负责后来所有 Agent 输出改成结论 命中规则 关键数据 风险提示业务才真正接纳它。这件事给我启发很大业务判断系统的信任不是靠模型名气撑起来的是靠条条可查的理据撑起来的。5.2 排查速查表Agent 判断异常时查哪里遇到Agent 做不了判断或判断明显错误按这个表快速定位现象最可能的根因排查方向数据都能查到但结论离谱数据口径或语义未对齐检查字段映射表是否包含业务含义说明同一问题不同时间答案不一样依赖了未对齐的快照或临时上下文排查数据包组装是否有统一时间基准规则边缘情况总错规则萃取不全缺乏例外处理回测历史决策案例补齐规则和例外结论无法解释缺少规则命中和依据输出给规则层加解释文本用模板约束输出人为否决率高规则与业务现状有偏差组织业务专家重新评审规则和权重5.3 关于可审计性的补充做这类系统一定把操作留痕当一等需求来做。每次 Agent 判断的输入数据、命中的规则、输出的结论全部落库。没有这个业务上出了问题你根本没法定位是数据错了、规则错了还是模型错了。有了留痕排查就是查记录而不是靠回忆。这个功能越早做越好上线以后再补所有历史判断记录都是空白想复盘都没有素材。这是我不止一次用成本换回来的教训。6. 复盘体会最后分享几句实在话做过的类似项目越多越觉得最重要的认知是接系统是成本最低的事判断能力才是真正的工程。很多时候项目组把连上了当成做完了这种心态不改Agent 永远停在玩具阶段。数据接口只是地基地基上面还有语义层要建、规则层要填、信任机制要养全做完了才谈得上业务价值。节奏感也很重要。别试图一步到位选一个单点场景做透做出来的东西业务愿意用比十个半成品强十倍。跑通一个完整周期——需求萃取、规则建模、数据组装、人工闭环、回测迭代——这套能力就沉淀下来了复制到其他场景只是时间问题。最后给业务方一句实在话Agent 做业务判断本质是把你们组织里最好的判断经验变成公共资产。它不会替代人但它能让你少重复问这事以前怎么办的这种问题。这个转变需要技术团队和业务专家一起坐下来把判断过程一点点说清楚。麻烦但值得。