为什么 Agent 会把企业推向更深的平台依赖
传统生成式 AI 工具主要读取文档、回答问题或生成内容。即使更换模型，企业通常仍能保留原来的业务系统。
Agent 不同。它需要知道订单处于什么状态、谁有权审批、库存能否承诺、供应商是否合格，还要调用系统执行创建、修改、支付或取消等动作。要做到这些，它会逐渐依赖四类平台能力：
当这些能力由同一家企业软件平台完整提供时，部署确实可能更快。但与此同时，Agent 的提示、工具、流程、评测、运行记录和业务知识也更容易与该平台绑定。
过去的锁定主要是数据格式和应用接口；Agent 时代还会增加一层“行为锁定”——企业不仅难以搬走数据，还难以搬走已经调试成熟的任务行为。
这包括：
如果这些资产只能在特定厂商环境中表达和运行，企业得到的就不只是一个更智能的系统，也是一笔持续增加的转换成本。
- **业务语义**：客户、物料、合同、成本中心等对象的准确含义及关系；
- **流程状态**：任务目前走到哪一步，前后步骤是什么，异常如何处理；
- **身份权限**：谁发起、谁批准、Agent 能代表谁执行哪些动作；
- **运行治理**：调用记录、质量监控、版本变更、事件调查和回退。
- Agent 如何判断一个采购请求是否完整；
- 遇到价格异常时调用哪些规则；
- 哪些情况允许自动执行，哪些必须升级；
- 如何生成供复核人员阅读的证据包；
- 使用哪些测试案例证明流程仍然可靠；
- 多个 Agent 如何交接状态并恢复失败任务。
最危险的不是选择一个平台，而是把三笔账混成一笔
企业讨论此类项目时，经常把以下三笔账放进同一份商业方案。
第一笔：业务流程改造
例如把采购申请补充、合规核查和审批材料生成从五天缩短到一天，减少返工并提高异常发现率。这是企业真正想购买的业务价值。
第二笔：核心平台现代化
例如更换 ERP 版本、清理定制代码、重建主数据、迁移接口和调整权限体系。即使没有 AI，旧系统也可能因为维护期限、安全、成本或业务扩展需要而升级。
第三笔：AI 运行能力建设
例如模型接入、Agent 编排、评测、监控、知识治理和人工接管。这些能力有些可以复用现有平台，有些需要新增。
三笔账相互影响，但经济逻辑并不相同。
如果把它们打包成“AI 转型项目”，一个原本可以用较小投入验证的业务场景，可能被迫承担整个 ERP 迁移的成本；反过来，一次本就应该进行的平台升级，也可能把尚未证实的 AI 收益写进投资回报，用来美化商业论证。
企业应分别回答：
1. 即使不迁移平台，这个流程改变是否仍值得做？ 2. 即使没有这项 AI 能力，核心系统是否仍有充分的升级理由？ 3. 迁移后新增的 AI 价值，能否覆盖由平台绑定、组织切换和持续运营带来的成本？
只有三个答案都清楚，组合投资才是可解释的。
用“最小可迁移闭环”验证，而不是先许诺全面自治
企业不必在“完全不换”和“全面迁移”之间二选一。更合适的起点，是选择一个边界完整、结果可测、即使失败也可恢复的业务闭环。
例如，不是笼统地做“自主采购”，而是限定为：
1. 读取低风险间接物料采购申请； 2. 检查字段、预算和合格供应商； 3. 对异常项给出证据并转人工； 4. 对满足明确规则的申请生成订单草稿； 5. 经授权人员确认后写入正式系统。
这个闭环要同时在两个层面验收。
业务层面关注周期、返工、异常漏检、人工时间和最终结果，而不是 Agent 调用了多少次。
可迁移层面关注任务定义、工具接口、策略、测试集、运行记录和业务状态能否被导出，能否在替代环境中复现关键行为。
欧盟《数据法案》已经将云和边缘服务的切换、数据可移植性与互操作列为明确要求。针对平台和软件服务，规则要求提供开放接口，并至少以常用、机器可读格式导出数据。欧盟委员会 2026 年发布的互操作研究也指出，真正有效的可移植性需要覆盖数据和应用，而不只是把文件下载出来。
NIST 2026 年修订的《云计算标准路线图》同样强调：云平台应支持数据在不同提供商之间安全、高效地移动，并使应用能以可接受成本迁移运行；迁云路径还应保护适合保留的既有技术投资，支持本地软件与云服务共存。
这些原则用于 Agent 时，企业需要把“可携带对象”进一步扩展到行为资产。
在采购合同里，至少拿回六类资产
企业评估嵌入核心系统的 Agent 平台时，不应只询问模型、功能和价格，还要确认以下资产是否真正属于自己并可以导出。
1. 任务定义
包括目标、输入、输出、停止条件、升级条件和人工责任。任务不能只存在于厂商专有的可视化配置中，至少应有结构化、可读的表达。
2. 工具与接口契约
明确 Agent 可以读取和修改哪些业务对象、调用参数、返回结果、错误代码以及幂等和撤销方式。接口开放不等于行为可迁移，但它是最基本的前提。
3. 企业策略
审批阈值、禁止动作、职责分离、地区规则和风险偏好应由企业控制。平台可以执行策略，不能成为策略唯一的保存位置。
4. 评测与回归资产
测试样例、期望结果、失败模式、评分标准和历史基线，是企业长期投入形成的质量资产。更换模型或平台后，没有这些材料就无法证明新旧能力是否等价。
5. 运行证据
不仅要导出最终回答，还应保留必要的输入来源、工具调用、策略判断、人工干预、版本和结果状态，以支持事故调查和业务审计。
6. 未完成任务的状态
长流程迁移最容易丢失的不是静态数据，而是正在进行中的工作。企业要知道哪些任务尚未完成、等待谁处理、已经产生哪些承诺，以及如何在新旧系统之间对账。
如果供应商只能导出数据，却不能导出这些行为与状态资产，所谓“可退出”仍然停留在基础设施层面。
平台原生能力可以用，但要保留替代的接缝
反对锁定不等于拒绝平台原生能力。为了追求形式上的多云或完全中立，把所有能力重新开发一遍，同样会增加成本、拖慢交付，并失去深度业务集成的优势。
真正需要保留的是几个关键接缝：
这些接缝不保证企业可以零成本切换。它们的作用是让转换成本可见、可估算，并避免某次产品升级或商务变化使企业失去选择权。
- 模型与业务规则分离，避免把确定性政策藏进提示词；
- Agent 编排与系统记录分离，正式业务状态仍由权威系统掌握；
- 企业评测集独立保存，不依附某个模型供应商；
- 高风险动作通过稳定、受控的业务接口执行；
- 运行日志使用可查询、可导出的企业格式；
- 对关键流程定期做替代模型或替代路径演练；
- 合同中约定数据、配置、评测、日志和未完成任务的退出安排。
把迁移能力本身作为验收项
企业通常会做上线验收，却很少在项目开始时测试退出。
更有效的方法，是在正式扩大范围前进行一次“小型迁移演练”：
演练结果会给管理层一个比合同承诺更真实的答案：企业究竟拥有这套 AI 能力，还是只拥有使用权。
同样，厂商宣称 AI 可以降低迁移工作量，也应通过企业自己的系统复杂度、定制范围和测试要求验证。SAP 公布的“超过 35%”属于厂商对其新工具的表述，不应直接外推为所有企业都能实现的迁移收益。
- 导出一个 Agent 的任务定义与策略；
- 在隔离环境中替换模型或编排组件；
- 使用同一批测试集比较任务结果；
- 迁移一组未完成任务并完成状态对账；
- 计算人工改造时间、功能损失和业务中断；
- 记录哪些资产事实上无法带走。
企业要争取的不是零依赖，而是有选择的依赖
任何核心企业系统都会形成依赖。成熟的架构决策不是消灭依赖，而是判断哪些依赖能换来足够高的业务价值，哪些依赖会削弱未来的议价权和调整能力。
AI Agent 深入 ERP 是一个重要进步：它有机会获得真实业务上下文，执行过去只能由人跨系统完成的工作。但这项进步也会让流程、数据、权限和智能行为更紧密地绑定在一起。
因此，企业不应把“自主运营企业”理解为采购一套更大的软件组合，而应把它视为一次业务能力重构。
先用最小闭环证明价值；把流程改造、平台现代化和 AI 运行能力分开算账；将任务、策略、评测、证据与状态纳入可移植范围；在扩大投入前真实演练一次切换。
这样做并不会阻止企业选择统一平台。相反，它会让选择更有依据：企业可以放心使用平台原生优势，同时知道自己保留了哪些关键资产、承担了多少转换成本，以及在条件变化时如何离开。
企业 AI 的专业性，不只体现在系统能否自主行动，也体现在管理层是否始终保有重新选择的能力。
