工业智能体的能力幻觉：知识库越厚，系统越聪明吗？

2026-11-11

工业智能体, 工程证据

如果有一天，我们把一家工厂的工艺文件、设备手册、质量标准、历史故障、设计图纸和生产记录全部整理进知识库，再给每个岗位配上几十个 Skill，接入 PLM、MES、ERP、QMS 和设备数据平台，最后搭起一套看起来很完善的 Agent Harness，这是否就意味着我们拥有了一个成熟的工业智能体？

演示现场很容易给人这样的错觉。工程师问一句“这台设备为什么频繁报警”，AI 能引用三份手册、调用两套接口，输出一份排版漂亮的分析报告；销售人员问一句“这个产品能不能按客户要求改型”，AI 能检索历史型号、拼装技术说明，甚至生成一份初步报价。可真正到了现场，设备参数已经变更，工艺文件沿用旧版，接口字段换过一次，质量判定依据也更新了。AI 所做的每一步似乎都有理有据，最后的结论却可能建立在一整套过期前提之上。

工业智能体规模化后，必须回答一个问题：我们不断给智能体增加知识、工具和约束，却未必知道这些增加究竟带来了多少能力，甚至不知道何时开始产生负收益。 AI Coding 社区围绕知识库、Skill、门禁、Harness 和最佳实践的五个疑问，放到工业现场，问题会更尖锐。因为代码写错了还有测试和回滚的机会，工艺参数、设备状态和质量结论出现偏差，代价可能直接落在生产、成本和安全上。

一、过期知识看起来太可信

很多企业把工业知识管理当成一项资料整理工程：收集几十年的 PDF、Word、Excel 和 Markdown，建立目录、切分文档、做向量化、接入检索增强生成（RAG），然后宣布知识库建设完成。接下来发生的事情很熟悉：研发设计还在改，BOM 不断迭代，现场工艺卡一版接着一版，设备维修人员靠微信群传递最新经验，知识库里的内容却停留在交付验收那天。它当然能被检索，也能被大模型理解，但“能读到”与“能作为当前决策依据”，已经是两回事。

工业场景有一个比通用办公知识更严厉的特点：知识天然带版本、工况、适用范围和责任主体。同一台泵、同一种阀、同一条焊接产线，设备型号相似，不代表材料、工艺窗口、控制策略可以直接互用。对一代产品成立的经验，换到另一代产品未必成立；某次维修形成的应急措施，也不应该悄悄升级为长期标准。如果智能体只根据语义相似度找到了“最像答案”的文档，却不知道这份文档对应哪一个产品版本、哪一次工程变更、哪一种现场工况，那么检索效果越好，反而越容易制造一种有依据的错误。

工业知识体系首先需要一套知识有效性机制。文档要知道自己从哪里来、谁负责、对应哪个设备或产品版本、何时生效、何时失效，遇到哪类变更必须重新核验。关键结论最好能指回 PLM 中的受控对象、MES 中的实际工艺记录、QMS 中的有效标准，或经过批准的现场作业文件。对低风险的经验笔记，简单的 Markdown 文件夹也许足够；对决定工艺与质量的受控依据，必须有明确的权威来源和变更流程。企业不必把所有信息都塞进一个庞大的向量数据库，更合理的路线往往是先按产品、设备、版本和权限定位，再针对需要的材料进行全文检索、结构化查询或按需语义检索。检索方式可以灵活，证据地位却不能含糊。

模型能力也在改变检索方案：随着模型理解长文档、代码仓库和复杂文件的能力提高，一部分过去依赖精细切块、预先向量化和复杂知识图谱才能实现的任务，可能被更直接的文件检索和上下文阅读替代。我们曾经投入很多精力搭建的检索流水线，并没有获得永久存在的资格。工业知识库需要让模型知道哪些知识此刻有效、谁有权确认、什么条件下必须拒绝使用。

二、Skill 越来越多，为什么工业智能体反而可能越来越笨？

现在搭建一个工业智能体平台，很容易陷入“能力积木”的兴奋之中。读取图纸是一个 Skill，查询 BOM 是一个 Skill，生成工艺卡是一个 Skill，分析振动谱是一个 Skill，调用仿真求解器是一个 Skill，生成质量报告又是一个 Skill。每完成一个场景就沉淀一份说明、一个脚本或一套流程，库里很快能积累上百个 Skill。团队展示成果时，最醒目的指标往往也变成了“接入了多少工具”“沉淀了多少技能”“覆盖了多少业务场景”。

但 Skill 的数量不是能力指标。一个 Skill 被调用一千次，可能说明它很好用，也可能只是路由规则过于宽泛，导致大量无意义触发；一个 Skill 很少被调用，可能毫无价值，也可能负责极少发生却极其关键的质量异常处置。更麻烦的是，两个 Skill 可能对同一工艺问题给出不同的操作路径，或者分别依赖已经过时的接口和字段。模型为了选择它们，需要理解越来越多的说明与触发条件，结果把时间花在“找工具”上，而不是解决问题。工具越多，选择空间越大，错误组合、重复调用、上下文污染和维护成本也会一起增长。

工业 Skill 还必须区分两类性质完全不同的工作。一类是确定性的能力，比如按照固定接口读取 BOM、计算单位换算、执行材料约束校验、生成符合规范的文件。这类能力应该尽量落在可测试的程序和受控服务中；另一类是经验性的判断，比如分析故障假设、规划多步仿真、比较工艺改进方向、组织跨部门协同。这类能力适合由模型参与推理，但仍要通过结果验证。把两者都包装成“让模型读一段说明然后自行决定”的 Skill，短期看开发很快，长期会模糊哪些结果值得信任。

如果一个工业智能体平台没有调用链路埋点、任务级评测和淘汰制度，几百个 Skill 更像一座不断扩建、却没有盘点制度的仓库。我们至少应该知道：它解决了哪一类真实任务，触发是否准确，调用失败发生在哪一步，结果是否通过工程校验，节省了多少人工操作，带来了多少额外成本，以及换一个新模型后，是否还值得保留。最关键的一项实验非常简单：把这个 Skill 暂时拿掉，用同样的任务、同样的模型和工具权限再做一遍。 如果整体结果没有变差，甚至更稳定、更便宜、更快，那么这项沉淀就需要重新审视。删除无效能力，不应该被理解成否定过去的工作；恰恰说明团队开始把结果放在资产数量之上。

三、工业智能体的门禁要落在执行链路上

AI Coding 里有一种常见做法：把工程规范写成 Rules 或 Markdown，告诉模型不要修改某些文件、必须跑测试、不能跳过审核、输出之前检查格式。大部分时候，它可能执行得很好；一旦换了模型、换了运行框架，或进入复杂的长任务，这些要求就有可能被遗漏。在工业场景里，问题的边界更明确：安全联锁、设备控制权限、质量放行规则、工艺参数上下限，以及需要人工签字的审批流程，不能由概率性的语言理解来承担最终保证。

举个例子，某个设备维护智能体判断可以调整运行参数。它可以解释故障原因、引用历史工况、推荐可行范围，甚至提出一套验证计划，但能否真正把参数写入 PLC 或控制系统，必须经过另一条独立的执行链路。身份与岗位权限、设备当前状态、允许的参数范围、变更审批、执行确认、异常回滚，应该由受控系统和确定性程序来检查。就算模型突然变得极其聪明，或某份 Prompt 因为上下文压缩没有继续生效，这些门禁也不能跟着消失。对于高风险控制动作，必要时还应保留物理层面的联锁与人工授权，不能仅用软件层保护替代已有安全机制。

从软件架构上说，我们需要把三个东西拆开：模型负责理解意图、形成方案和解释依据；工程工具负责计算、查询、验证和执行确定性操作；治理系统负责权限、审批、留痕、异常处置与责任边界。模型可以提出“建议修改焊接参数”，但真实执行必须走经过批准的工艺窗口与设备权限；模型可以起草“该批次产品合格”的结论，但质量放行必须由可追溯的检测数据和授权流程支持。建议权不自动等于执行权，能生成报告不自动等于能批准结果。 这两道边界，应该写在系统架构里，而不是只写在智能体的性格说明里。

门禁稳定运行，也给模型留下了更多探索空间。当不允许的动作已经被系统稳定阻断时，我们不必靠一层层冗长的 Prompt 告诉模型“务必谨慎、千万小心、绝对不能”。智能体可以在受控沙箱中充分试算方案、生成备选路径、调用仿真和比较结果，直到达到正式执行的条件。可靠的外部边界能让模型在受控范围内充分探索，而执行风险留给确定性的系统处理。

四、Harness 要在真实任务中测量健康度

Harness 这个词近来很热。在本文语境里，它指围绕模型的一整套运行机制：指令、工具、路由、状态、记忆、权限、执行环境、验证、日志以及人机协作。做演示时，我们习惯于挑一个能够跑通的任务，从自然语言输入一路展示到漂亮的最终结果。但一次成功的演示，不能证明系统在真实工厂里具有稳定性；在开发机上反复成功的流程，也未必能应付不同班组、不同产品版本、接口超时和数据缺失。

尤其容易被忽略的，是模型本身一直在变化。去年的基础模型可能需要三份 Rules 才能按照固定格式生成工艺文档，需要两个 Skill 才能正确检索文件；今天的模型可能直接完成同样的事情，还更擅长自己调用工具。如果我们从不重新测量旧组件的价值，就会在不断升级的模型外面，一层层保留历史脚手架。每一层都自称在提高可靠性，整体系统却可能因为互相矛盾的约束、额外的调用和过度编排，变得更慢、更贵，也更难排障。

我认为工业 Harness 至少需要四种健康指标。第一是任务结果：故障诊断是否经工程师复核、BOM 是否匹配有效版本、仿真输入与边界条件是否正确、质量结论是否可验证。第二是执行代价：完成一次任务所需的时间、模型费用、工具调用次数和人工介入次数。第三是风险表现：越权尝试、错误数据引用、无依据结论、关键校验遗漏、接口异常后的恢复能力。第四是可维护性：当模型、接口、知识或工艺标准变化时，团队需要付出多大成本才能恢复原有质量。这里面没有哪一个指标可以单独代表“智能水平”，但它们结合起来，才接近真实生产中的系统价值。

评测方法也不必一开始就复杂。选取一组经过脱敏或合成处理、具有明确验收标准的典型任务，覆盖正常、异常、缺失数据、版本冲突、权限不足等情况。用同一任务集分别测试“基础模型加最小工具”“现有完整 Harness”和“删去某项 Skill 或 Rule 的版本”，尽量固定模型、输入和可用工具，重复运行以观察波动。升级模型时，再进行新旧版本对照；上线之后，把真实失败案例持续补充到回归测试里。只有这样，我们才知道哪一项改动真正让系统变强，哪一项只改善了演示观感。开放式专家判断可以参与评分，但工艺边界、数值精度、权限等硬性要求，仍应由确定性检查或人工审核确认。

一个成熟的工业智能平台，应该敢于做“减法实验”。停止加载一段古老的系统提示词，看成功率是否下降；移除一个多年没人维护的 Skill，看工具选择是否更准确；关闭一套昂贵的预处理流程，看检索质量是否真的受损。能持续证明价值的复杂性，才有资格继续存在。 其余复杂性，无论当初做得多漂亮，都应该准备退休。

五、最佳实践也有保质期

工业软件行业很容易形成路径依赖。过去我们做信息化，习惯先设计大而全的平台、统一的数据模型和流程引擎；后来做工业互联网，又习惯把所有设备和系统接入中台；到了工业大模型时代，同样的思路可能换了新名字继续出现：先建一个超级知识库，再建一个 Skill 市场，再建一个多智能体编排平台，最后等待场景落地。技术架构在汇报材料中越来越完整，具体岗位的工程师却未必少点一次鼠标、少查一份旧文档、少做一次重复核对。

AI Coding 领域的一些习惯也可能被机械复制到工业智能体建设中。某个模型版本对特定 Prompt 特别敏感，于是我们把它写进团队规范；某个框架的工具调用不稳定，于是用额外的流程和约束兜底；某次长任务失败，于是又新增一个负责监督的 Agent。这些做法在当时可能合理，但模型半年后升级、工具接口换代、上下文处理改进，原先的经验可能已经过期。最危险的不是技术路线选错，而是把一个阶段性的补丁包装成跨模型、跨行业的长期原则，最后连评测它的勇气都没有。

工业智能的最佳实践应当是一套带证据、带版本、带适用条件的工程经验。例如“某类装配设计任务，优先检索 PLM 中的受控模型，再调用几何检查工具”是一条可以测试的经验；它要写清适用的产品类型、输入要求、测试集、通过标准和失效条件。再比如“设备诊断先读取最近一小时的时序数据，再结合维修记录提出假设”，这条经验需要说明数据缺失时怎么办、异常工况如何处理、哪些结论不能自动下达。团队每隔一段时间都应该允许新模型挑战旧流程，胜出的方案才进入共享工作流，落后的方案及时降级或归档。所谓标准化，不是强迫所有工程师用同一套提示词，而是让好的方法有证据可复制，让不好的方法能被识别和退出。

团队资产还应包括一组相互关联的内容：真实的任务样本、验收标准、可靠的数据接口、必要的受控工具、成功与失败的执行轨迹，以及一个清楚的适用范围。即使以后换了模型或 Harness，这组资产仍能帮助团队判断新系统有没有进步。相反，如果我们的资产只有几百份 Markdown 指令和几套精美工作流，换一个框架就得从头再来，那沉淀的更多是工具使用习惯，而不是工业工程能力。

六、积累可验证的工程成果

可以沿着一个方向继续推进：把“知识库建设”向“工程证据建设”推进一步。传统知识库记录的是别人曾经说过什么、写过什么；工业智能体真正需要的，还包括这件事在什么条件下做过、使用了什么数据、经过哪些计算和试验、结果如何、谁确认过、后来是否被推翻。对产品研发来说，这可能是设计版本、仿真工况、中试验证、测试报告与工程变更形成的闭环；对设备运维来说，可能是故障假设、传感器证据、维修操作和后续运行效果；对质量管理来说，可能是检测记录、异常归因、纠正措施与复检结论。

这也是为什么我认为，工业智能体最终会与 PLM、MES、QMS、仿真求解器和试验数据平台结合得越来越紧。大模型可以阅读自然语言，却不能凭空替代工程证据。一个面向研发设计的智能体，调用已有 CAD 模型、检查装配约束、检索历史变更，再把结果交给工程师确认；一个面向仿真验证的智能体，依据工况调取已有 CFD/CAE 结果，必要时触发新的计算或试验，并记录模型与边界条件；一个面向智能工厂的智能体，能够把设备状态、产线节拍、质量追溯和数字孪生视图串起来，为人提供可以追问、可以复核的建议。它们共用的基础不应只是一个聊天窗口，而是一套能够产生、保留和核验证据的工程工作体系。

对于实时降阶模型、代理模型和 PINN 等新技术，更要坚持这个原则。它们可能显著缩短某些仿真任务的响应时间，但预测适用范围、训练数据分布、误差边界和中试验证结果必须随模型一同管理。让 AI 在屏幕上生成连续变化的压力云图并不困难，困难的是知道这张云图对应什么物理假设、在哪些工况下可信、误差有多大，超过范围时能否自动提示并回到高保真计算或人工验证。工业智能体最有价值的“记忆”，可能恰恰不是记住上一次回答，而是记住每一次工程判断背后的证据链。

七、进化还包括主动简化系统

如果现在要重新设计一套工业智能体平台，我会倾向于从最小可用能力开始，而不是先画出一个无所不包的多智能体组织架构。先选准一个真实岗位任务，比如工艺工程师核对变更影响、售后工程师定位设备故障、设计工程师生成可复核的选型建议。让基础模型直接读取必要文件，连接少量高质量的受控工具，建立最基本的权限和日志，再拿真实任务评价是否解决问题。遇到可以复现的失败，再判断需要增加数据、改进检索、补充 Skill、设置确定性门禁，还是干脆更换模型。每增加一层复杂性，都要知道它解决什么问题、如何衡量、什么情况下可以移除。

第二步不是急着扩充到一百个场景，而是建立团队级的任务基线和观测体系。对每一类工业智能体，保留有代表性的任务集、可靠的标准答案或验收规则、工具调用轨迹以及人工反馈。研发数据集也不应该只是一堆仿真曲线和试验记录，它可以逐步成为用于训练、验证和回归测试的复合资产：有输入工况、有物理边界、有高保真或实验参照、有错误案例，还能追踪版本。这样一来，模型升级不必靠主观体验判断，系统增减功能也有据可依。模型能力提升后，我们甚至可以主动撤掉旧 Skill，留下更短、更稳、更透明的工作链路。

最后一步是把“被验证的能力”转化成组织能力。优秀工程师的经验值得沉淀，但不要只沉淀他的 Prompt；优秀算法工程师写的 Skill 值得保留，但不要只展示代码行数；团队做出的数字孪生演示值得介绍，但必须能说明它与真实设备数据、仿真验证和实际决策之间的联系。对客户而言，最有说服力的展示，不是屏幕上摆了多少个智能体，而是同一个真实问题从提出、检索、计算、核验到形成可追溯结果，究竟节省了多少工作、减少了多少错误、保留了多少工程控制权。

写到这里，五个问题其实指向同一个答案：知识库、Skill、Rules、Harness 和最佳实践都可能有用，但它们没有天然的正收益。它们只是某个技术阶段为解决特定问题而形成的手段，必须接受现实任务的检验，也必须接受新模型和新工具的挑战。值得长期积累的是可信的数据和证据、可复用的工程工具、确定性的执行边界，以及能持续检验系统表现的评测体系。

工业智能体的竞争，迟早会从“谁堆出了更多能力组件”，转向“谁能用更少、更可靠的组件，完成更多可验证的工程工作”。一套优秀的工业智能系统，理应具备主动淘汰过时知识、无效 Skill 和多余编排的能力。它不需要永远记得我们曾经为它搭建过多少脚手架，只需要在下一次生产任务到来时，拿出比上一次更值得信任的结果。

工业智能体的自我进化，也包括淘汰已经失效的知识、工具和流程。

工业智能