Agent对接ERP，不改造系统能走多远？跨系统读写与事务一致性的实践约束
“不改造ERP”是Agent落地时被频繁提及的约束，也是被容易误读的承诺。
不改造系统，意味着Agent必须在现有ERP的界面或接口之上工作，而不能依赖数据库层面的直接操作或系统内部的事务机制。这一定位在“读”和“写”上的能力边界差异很大，而事务一致性问题恰恰集中在“写”这一侧。
一、不改造能走多远：读与写的分层边界
读：覆盖范围较宽。 Agent通过API或界面自动化从ERP、MES、WMS等系统取数，在技术上不要求系统开放内部接口或进行二次开发。实在Agent的ISSUT视觉理解能力可以“看懂”任意系统界面，不依赖底层代码或原厂配合。对于报表生成、异常监控、数据归集等以“读”为主的场景，不改造模式的可行性较高。
写：受限于系统的事务机制。 这是不改造约束下最容易被低估的部分。ERP不是数据库：在数据库中，一个事务失败可以整体回滚；而在ERP中，单据一旦过账，状态变更往往无法通过简单的“撤销”回到原点。一个多步骤流程如果在第三步失败，前两步已写入的数据可能停留在“部分完成”的状态，需要额外的补偿逻辑来修复，而非依赖系统自身的回滚能力。
边界：不改造模式下，Agent的“写”是通过界面或接口逐动作提交，而非在ERP内部事务中原子执行。这意味着跨步骤的一致性不由ERP保证，需要由Agent所在的上层架构来设计。
二、事务一致性在不改造约束下的真实含义
ERP场景的一致性，通常不是“强一致”，而是“可补偿的最终一致”。这一判断的依据是：ERP涉及库存、财务、结算、物流等多个模块，外部系统不可控，业务本身允许“最终一致”，但不允许“状态错乱”。
在不改造ERP的前提下，Agent无法利用数据库的XA/2PC等强事务机制。可行的工程路径主要有两类：
第一类：幂等与补偿。 每一次写操作附带幂等键，确保重复提交不会产生重复单据；每一个正向操作预先设计对应的补偿语义，失败时按逆序执行冲正或红字冲销。Saga模式是这一思路的典型实现：将长流程拆分为一系列本地事务，每个事务声明正向操作和补偿操作，失败时逆序回滚。
第二类：对账兜底。 实时补偿无法覆盖所有失败场景。跨系统的单据状态需要以对账任务作为最后一道防线，按固定周期比对双方状态，发现和修复补偿机制遗漏的缺口。
两类路径的共同前提是：Agent的写操作必须被纳入一个可观测、可追溯的状态机中，每一步的意图、结果和补偿动作都有记录，而非“调用成功即结束”。IETF的一份草案指出了更复杂的情况：当自治Agent执行多步写操作时，传统幂等键和Saga编排器在计划中途停止或下游参数出现偏差时，无法保证确定性恢复。这意味着，写操作的粒度越细、步骤越多，一致性保障的工程成本越高。
三、务实的分工：Agent适合走到哪一步
在不改造ERP的约束下，将Agent的写操作按风险等级分层，比追求“全自动写入”更符合工程现实。
第一层：草稿与确认后提交。 Agent完成取数、校验和单据草稿的生成，提交动作由人工确认或预设审批流触发。这一模式在合同审核、订单分发等场景中已有落地：实在Agent完成信息提取和规则校验，生成经确认的草稿，最终提交由人完成。即使Agent的校验出现偏差，人工在确认环节仍有拦截空间。
第二层：低频、可逆的写操作。 对于状态变更简单、补偿路径清晰的操作（如台账更新、状态标记），可以在幂等和补偿机制就位的前提下由Agent直接执行。失败时触发预定义的补偿动作，将状态恢复到可接受的范围。
第三层：涉及资金、库存、总账的写操作，保留人工闸门。 这类操作的错误后果不可逆或补偿成本较高，属于“允许最终一致，但不允许状态错乱”的范畴。Agent的合理定位是准备经校验的写入指令，执行由人或受控流程完成。
四、实在Agent的落点：判断准备与受控执行
实在Agent在ERP对接场景中的路径，与上述分层逻辑一致：不改造现有系统，在ERP、MES、WMS、SRM之上模拟人工操作，承担取数、校验、草稿生成和受控提交的执行层工作。
在“读”侧，通过API与界面自动化的双轨架构完成跨系统数据归集，有接口的系统走接口，无接口的系统通过界面操作取数，降低对系统改造的依赖。在“写”侧，遵循“校验前置、提交受控”的原则：Agent完成字段映射、规则比对和草稿组装，提交动作由人工确认或审批流触发；对于涉及状态变更的操作，配合幂等设计和补偿逻辑，失败时按预定义路径恢复或转入人工处置。
全流程操作留痕记录每一步的读取范围、校验结果、提交内容和人工干预点，为事后追溯和补偿决策提供依据。这一模式不承诺“不改造即可实现任意写入场景的强一致”，而是在不改造的约束下，用取数能力、校验能力和受控提交机制，覆盖判断准备和执行辅助环节，将事务一致性的风险控制在可识别、可补偿的范围内。
💡 常见问题（FAQ）
Q1：不改造ERP，Agent能直接写入生产系统吗？
技术上可行，但需要区分场景。低频、可逆、补偿路径清晰的写操作，可以在幂等和补偿机制就位的前提下由Agent直接执行；涉及资金、库存、总账等后果不可逆的写操作，建议保留人工确认或审批流作为提交闸门。ERP的事务机制不保证跨步骤的原子回滚，Agent的写操作需要由上层状态机承担一致性保障，而非依赖ERP自身。
Q2：Saga模式能解决所有跨系统一致性问题吗？
Saga解决的是“可补偿的最终一致”，而非“强一致”。它的前提是每个正向操作都有明确的、可独立执行的补偿语义。对于写操作粒度细、步骤多的流程，补偿逻辑的设计和维护成本会上升；IETF的草案也指出，在Agent多步计划中途中断或下游参数出现偏差时，传统Saga编排器无法保证确定性恢复。Saga是工具之一，不是一致性的完整答案。
Q3：不改造模式下，一致性保障的最低要求是什么？
三条底线：幂等键（同一操作重复提交不产生重复结果）、操作留痕（每一步的意图、结果和状态可追溯）、对账兜底（以周期性对账发现和修复补偿遗漏的缺口）。缺少任何一条，跨系统写入的状态都可能在失败场景中失去可见性。
Q4：哪些场景适合作为不改造模式的首批落地选择？
以“读”为主或“写”可受控的场景优先级较高：跨系统取数与报表生成、单据草稿的生成与校验、异常监控与归因、审批流中的信息准备。这些场景的失败后果可回滚或可拦截，适合在不改造ERP的前提下验证Agent的取数能力和判断质量，为后续扩展写入范围积累数据和信任基础。
