其竞争对手最重要的收获在于其如何解决“情境熵”——即随着长时间会话复杂度增加，AI智能体容易变得困惑或产生幻觉。

泄露的源头揭示了一种复杂的三层内存架构，摒弃了传统的“存储所有内容”的检索方式。

正如开发者分析的，该架构采用了“自我修复记忆”系统。

其核心是一个轻量级指针索引（每行约150个字符），会不断加载到上下文中。该索引不存储数据;它存储位置。

实际的项目知识通过按需获取的“主题文件”分布，而原始转录从未被完整读回上下文，而是仅通过特定标识符。

这种“严格写入纪律”——Agent必须在成功写入文件后更新索引——防止模型因失败尝试而污染上下文。

对竞争者来说，“蓝图”很明确：建立怀疑的记忆。代码确认，X的Agent被指示将自己的记忆视为“提示”，要求模型在继续前验证实际代码库的事实。

通过它暴露的架构。XX不仅仅是附加在编码环境中的智能模型。LLM调用只是系统的一部分。真正的产品存在于会话持久化、权限piprline、工具注册、上下文管理、错误恢复和运营的可观察性中。智能不仅仅存在于模型中。它存在于所有围绕模型构建的架构中。

这一区别远远超出了AI编码工具本身。对于目前PLM/MES（MOM）厂商声称在未来“添加人工智能”到现有平台的人来说，这很重要。因为一旦你了解了生产型AI系统的实际样貌，驱动当今PLM/MES（MOM）平台的 AI战略的假设就会开始产生“崩溃”的设想。

第一种设想：为什么更智能的AI模型并不能让PLM/MES（MOM）变得智能

其理由是：人工智能模型正在以惊人的速度进步。每一代人都处理更复杂的推理、更长的背景和更细腻的层次。所以如果你把一个足够强大的模型连接到你的PLM/MES（MOM）系统，智能就会从组合中产生。平台通过关联变得智能。

XX 泄露直接指出了这一逻辑的缺陷。

对该泄露的分析清楚表明，即使是构建世界上最强大模型之一的X，也不会仅依赖模型能力来构建可用的人工智能系统。数据直接说明了这个故事（）。LLM调用本身只是X代码工作原理中的一小部分。其余部分是围绕其构建的架构：会话状态、权限门控工具执行、三层内存系统、多代理协调、上下文预算管理、错误恢复和运营可观察性。而且，这个细节应该让每个PLM/MES（MOM）厂商都感到警惕，系统明确设计成不信任自身记忆——每个Agent都被指示将记忆视为线索，并在行动前与真实来源进行核实。如果去除周围的架构，单靠模型无法在真实环境中产生可靠且可操作的行为。

依托残缺零散的产品数据、相互割裂的业务流程，即便搭配更优化的提示词，也无法搭建出智能化产品体系，仅能生成看似更精准的推测结果。对接老旧产品生命周期管理数据库的模型会笃定地总结过时数据记录，生成看似合理的建议，却无法分辨哪个数据源具备权威属性；同时，由于输出内容逻辑通顺，这类模型出现故障时更难被察觉。

生产系统中的智能并非模型本身具备的属性，而是模型运行所依托的运维架构所具备的特性。多数厂商如今仍在推行与之相悖的观点。厂商宣传宣称的性能与该架构实际可承载能力之间存在巨大差距，且这一差距并未快速缩小。

第二种设想：AI 智能助手与 AI Agents对比：PLM/MES（MOM）管理需要的不仅仅是智能助手

第二种设想分为两种截然不同的类型，需要区分看待。

智能助手模式至少能如实体现自身定位。智能助手伴随用户同步工作，可内容总结、解答疑问、辅助操作系统，但不会对平台本身做出改动，仅协助用户与现有平台完成交互。这类工具具备实用价值，能够降低操作阻碍，但它只是一款效率工具，无法实现平台层面的革新。

而Agent模式对应的设想，则存在严重的误导性。

Agent绝非功能更强的智能助手，它是一种本质完全不同的系统参与主体。它需要在长达数小时乃至数日的完整工作流程中持续留存运行状态；能够依据不断变化的场景信息自主判断后续操作；可直接对接各类系统执行操作，而非仅向用户提供建议；任务中途出现故障时具备故障恢复能力；执行关键操作前会主动申请权限，操作完成后可同步说明执行详情；清晰界定自身可操作范围，并始终严格遵守权限边界。

这是大多数PLM/MES（MOM）厂商目前模糊的界限。他们用“Agents”来描述的功能其实是智能助手的，因为Agent在产品推介中听起来更具变革性。但底层架构和工作流程都没有改变，业务工作流也一如既往。

第二种类型的重要性远超表面看上去的程度。现有的PLM/MES（MOM）平台均基于标准化工作流搭建，这类工作流专为人工与数据交互设计。工作人员发起变更申请、填写表单字段、上传附件文档、提交审批、等待反馈，随后推进至下一流程节点。这套工作流在设计之初就预设每一个环节都由人工主导，默认会有人查看界面信息、解读业务背景上下文并判定后续操作。

Agent并不适用于该模型。它不会停留在表单页面等待操作，也不会按照预设流程在不同人工操作环节间流转。Agent能够保存运行状态、研判上下文信息、自主做出决策、执行对应操作、处理故障恢复，还可跨系统协同工作 —— 其处理的诸多步骤往往是现有工作流引擎从未预判、也并非为适配此类场景而设计的。将Agent直接嵌入专为人工界面交互搭建的工作流，并不能让这套工作流具备智能化能力，反而会产生流程阻滞、系统脆弱性与业务断层等问题，Agent只能绕开这些障碍勉强运行，无法顺畅打通全流程。

打造适配真实Agent的平台，意味着重新审视该平台的核心定位。这要求我们将实时更新的进行中的工作状态视作系统核心，而非仅以审批完成的归档记录为中心；同时，需要重构工作流，不再将其设定为固定不变的人工交互流程，而是打造具备自适应能力、可供机器参与的处理流程，让Agent从流程起始阶段就成为核心参与主体。关键问题不在于Agent能否调取产品生命周期管理数据，而在于PLM/MES（MOM）系统能否提供Agent开展实际工作所需的开放式、结构化、具备关联识别能力的上下文信息。

第三种设想：传统产品生命周期管理（不是狭义的PLM系统，而是广义的PLM整个链条）数据模型为何无法适配AI Agent

传统PLM/MES（MOM）系统围绕文件、版本、审批流程、对象数据表、工艺流程、生产制造流程等梳理产品设计及制造相关信息。这套架构是为人工查阅设计的：设计/工艺/生产/质量等工程师调取零件档案、核对版本信息、查阅物料清单、跟进变更指令。所有信息分散在独立记录中，工作人员依靠自身积累的经验与脑海中留存的背景信息，才能读懂这些数据。

AI Agent无法以这种模式开展工作。

Agent需要区分信息的权威来源与非权威来源；它需要知晓变更内容与变更缘由，而非仅获知存在新版本；它需要理清各项数据的依赖关系，避免给出会导致下游装配失效的零件替代方案；它需要明确当前场景下允许执行的操作、支撑自身逻辑判断的依据，以及需留存至后续流程环节的信息 —— 部分业务流程可能持续数天。

但更深层次的问题源于底层架构。绝大多数产品生命周期管理的相关系统的数据模型，仅用于支撑精细化、事务性操作：新建零件、更新字段、上传附件、提交变更、发布版本。这些均为独立的增删改查操作，彼此割裂，每项操作都由单人在特定时间点完成。现有数据模型正是基于这一前提搭建，从未适配Agent的实际工作模式。

Agent不会依次执行一连串孤立的事务操作。它依托随时间不断积累的完整业务场景开展工作，场景内多项操作同步推进，人工与Agent共同维护持续更新的数据状态。这就需要一套更贴近协同工作空间的载体，而非仅存储零散记录的数据库。在该工作空间中，一次变更不再是单一事务，而是多方信息的集合：工程师录入的数据、自动化校验结果、智能体从计算机辅助设计（CAD）、物料清单、企业资源计划（ERP）、MES（MOM）系统中整合的背景信息。所有信息逐步汇总，支撑最终决策，而非单纯记录已敲定的结果。多数传统系统并未原生支持这种多方参与、信息持续累积的共享业务场景。缺少该载体后，Agent只能游离于核心业务流程边缘开展工作。

这一痛点，正是之前提出的产品记忆或者说产品的整个生命周期所涉及的数据或流程记忆的核心出发点。当前绝大多数系统仅记录决策最终结果：归档发布后的版本、审批通过的物料清单、签字确认的变更指令。但系统无法留存得出这些结果的完整逻辑：曾考量过哪些备选方案、哪些约束条件左右了最终选择、过程中做出了哪些假设、接受了哪些利弊取舍。这些关键背景信息散落在邮件往来、会议纪要中，或是仅存储在工程师的记忆里，而相关工程师次年很可能不再负责该项目。

状态记录不等同于完整记忆。一套仅记录审批结果的系统，无法说明审批通过的原因、被否决的备选方案，以及业务场景变动后哪些原有假设会失效。对于人工查阅而言，这类信息缺失虽令人困扰，但尚可通过人为补充信息解决；可对于AI Agent，这种信息缺失会直接导致其无法正常工作。若智Agent缺少可追溯的完整背景信息，只能基于相互割裂的资料与过时记录进行逻辑推导。即便它能生成看似合理的输出，也无法稳定可靠地运行。而在工程设计与制造领域，不可靠的输出是完全无法接受的。若是智能体给出错误的零件替代、版本修改或公差偏离建议，引发的负面影响会在企业各部门持续扩散，且长期留存。

以对象为核心的系统架构是如何制约AI Agent应用

当前绝大多数产品生命周期管理平台以文件、工作流、事务等对象为核心搭建架构。文件是承载产品知识的主要载体；工作流是预先设定好的人工审批流程；事务是系统交互的基础单元，例如创建零部件、提交变更申请、发布版本修订、订单分解、生成工单、指派任务，等等。这套架构在PLM/MES（MOM）等系统诞生之初十分适配，其初衷是为日益复杂的产品研发流程建立规范、实现管控。

但恰恰是这套架构，给Agent的应用设置了性能上限。以文件为核心的系统，无法将各类知识之间的关联关系转化为Agent可识别、可遍历的形式；以工作流为核心的系统，预设每一步操作都由人工主导，需等待审批节点放行才能推进后续流程；以事务为核心的系统将每一次交互视作独立事件，无法持续记录、理解交互背后完整的业务背景。

而Agent真正需要的是协同工作空间。它并非只能逐条查询、修改单条数据记录的数据库，而是一套可长期沉淀完整业务信息的运行环境，能够整合多类对象、多重关联关系、多方参与人员产生的全部业务数据。在该工作空间中，工程变更不再是单一事务，而是一套动态业务场景：同步完成零部件评估、关联关系追溯、方案对比、约束条件校验，同时接收人工与Agent并行作业输出的各类信息。系统可识别所有操作同属一项持续迭代的研发工作，并完整留存整套业务背景，直至相关工作完成、可走标准化归档流程。

多数PLM/MES（MOM）系统本身并不具备原生的工作空间逻辑。它们仅能记录变更审批完成后的最终结果，无法承载变更方案研讨、打磨的全过程场景。若Agent要介入这类系统开展工作，只能不断与系统底层架构逻辑冲突，被迫在适配传统业务的平台上层，模拟搭建工作空间的运行逻辑。

PLM/MES（MOM）等系统统一平台架构如何适配AI Agent

抛开抽象理论不谈，结合XX分析呈现的架构模式，以PLM为例，把生产环境的AI Agent的实际需求转化为PLM领域专属术语。

会话持久化指工程业务与变更工作上下文的永久留存。负责工程变更的Agent，即便工作中途中断、间隔数日、多名人员协同参与，都需完整留存本次变更的全部上下文信息。这并非简单的会话，而是一套持久化、结构化的在办工作数据载体。依托该载体，Agent可随时恢复工作、核查进度、迭代完善，无需全部推倒重来。

权限分层机制指代受策略管控的产品操作权限。智能体必须能够区分各类操作的差异：读取已发布物料清单、提议替换供应商、调整生产结构、创建正式变更申请、向下游供应商下发指令，这些操作完全不同。各类操作对应的风险等级、授权要求、操作失误带来的后果均存在区别。传统 PLM 系统仅配备基于角色的访问控制，这套权限模型面向人类用户设计；而Agent专属权限模型，需要细化管控机器在实际业务流程中的操作行为，管控粒度需精确至每一项独立操作，而非仅限制页面访问权限。

工作流的幂等性指代可稳定运行的长周期工程变更流程。一项工程变更往往涉及多套系统、多个零部件、多个专业领域与多名审批人，无法作为单一事务一次性处理。若Agent在统筹该变更的过程中出现中途故障，系统需回退至确定的正常状态，且不能损坏此前已完成的工作内容。多数 PLM 工作流引擎并非基于该需求设计，其适配场景为人工驱动的顺序审批流程，而非由机器统筹、具备安全故障恢复机制的长周期业务执行流程。

溯源，例如，电子批记录、生产谱系痕迹等指代可信产品全量信息存储。因为它是当前架构层面最核心的短板。Agent不仅需要知晓系统内存储的信息内容，还需掌握信息来源、更新时效、是否经过核验，以及该信息与周边关联数据的逻辑关系。PLM 数据库内的零部件档案仅记录零件编号、版本号与审批状态，无法说明为何该设计方案优于其他备选方案、哪些供应商约束影响了本次决策，或是设计背景发生变动后，哪些前置假设将不再成立。

系统交互集成平台指代一套可安全执行的跨系统操作模型，覆盖计算机辅助设计（CAD）、物料清单（BOM）、企业资源计划（ERP）、MES（MOM）及供应链系统。覆盖产品全生命周期运行的Agent，需要明确可交互的系统范围、各系统支持的操作类型，以及各类操作的执行许可条件。当前 PLM、ERP、CAD 、MES（MOM）与供应链系统之间的集成对接，大多为点对点简易连接，仅用于人工发起的数据同步，并非为机器持续自动化参与业务流程打造。适配Agent的安全操作模型，要求将系统操作能力显性化、划定操作边界，并全程留存操作审计记录。

事件日志指代操作可解释性与合规性保障。当Agent参与业务决策、修改业务档案或统筹工作流程时，仅记录变更内容远远不够。系统还需完整留存智能体读取的信息、考量的各项条件、遵循的管控策略、调用的工具，以及流程终止或向上提报的原因。在受行业监管的制造领域，例如，食品、制药、医疗器械、电子半导体，完整日志记录属于硬性要求。操作可解释性是业务可信运行的基础，无法自主说明操作逻辑的智能体，不能落地于正式工程研发环境。

【欢迎扫码关注与加入】