供应商打来电话，说这批料要晚 20 天。
采购员的动作是有固定顺序的：先查这个料还够几天用，再看在制的单子有没有它，然后问计划哪些成品要停，最后翻客户订单看哪几家的交期会砸。这四步走完，通常两个小时过去了，中间还要打三四个电话——因为库存、在制、客户订单分别躺在三个人的电脑里。
Infor 在 11 月 12 日发布的材料里，把这四步写成了一条链路：Claude 顺着那个延迟的零部件，穿过生产订单、子件、成品，一路找到受影响的客户交付；然后给出两个选项，一个是按急需数量下加急采购单、原单保留覆盖其余需求，另一个是另找供应商或替代料。采购员看完，批准其中一条，交易以他本人的 M3 身份执行。
很多人把这条新闻读成「Claude 能操作 ERP 了」。我觉得重点在别处：它先算出这张单会牵连谁，然后才允许动。
一、三条工作流，一个共同动作
Infor 与 Anthropic 的这次合作叫 Infor Industry AI for Claude，目前只对部分 Velocity Suite 客户开放，公开的配置指南写的是 M3。首批放出来的角色只有三个：生产计划员、采购员、客服代表。这个克制值得注意——不是「全公司都能用」，是「三个岗位、三件事」。
| 角色 | 会问什么 | 要先追的链条 | 允许改什么 |
|---|---|---|---|
| 生产计划员 | 哪些生产订单有风险？是缺料、产能还是人手 | 已发料、可用库存、在途采购能否赶上；换产能方案是否可行 | 重排生产订单日期、创建计划采购单 |
| 采购员 | 这家晚 20 天，会砸到哪些客户 | 延迟件 → 生产订单 → 子件 → 成品 → 客户交付 | 下加急采购单（原单保留）、调整采购单 |
| 客服代表 | 客户要提前，到底行不行 | 各仓成品库存、已被占用量、生产能否补上缺口 | 更新计划订单日期、重新分配库存 |
三条工作流表面各不相同，底层是同一个动作：先把牵连关系摊开，再挑一条改动最小的路。客服那条最能说明问题——客户要提前一天，仓库里确实有货，但货已经被另一张订单占了。系统要做的不是「有没有货」，而是「把货挪过来会伤到谁」，然后把这个被伤到的订单也摆到台面上，让客服当着客户的面决定。
这是 ERP 智能体与聊天机器人的分界线。聊天机器人回答「有没有货」；ERP 智能体回答「有货，但动了会影响 A 客户周四的那一单，你要不要动」。前者的错误是一个数字，后者的错误是一串连锁反应。
二、要设计的不是提示词，是角色剧本
Infor 的架构分成两半：一个走 MCP 的连接器，经 Infor ION API Gateway 把选定的 M3 交易暴露出来；一个按角色提供指令与看板的插件。工具调用以登录用户的身份运行，单点登录和既有角色权限决定这个人能看哪些记录、能做哪些交易。
真正体现设计功力的是管理员那一层。管理员可以裁剪返回给 Claude 的字段，可以逐个关掉交易工具；把会改记录的工具省略或禁用，就等于配成了只读。写权限打开时，每一次变更都要一次显式批准。通过连接器执行的动作，记录留在 Infor 里面。
翻译成实施语言，这四件事分别是：可裁的字段、可关的工具、必过的确认、可查的记录。四件凑齐，一个角色才敢放到生产环境里。
这里有个容易被跳过的问题：谁来写这份角色剧本？不是 IT，是业务。计划员每天要回答的三个问题、采购员判断替代料的四条经验、客服承诺交期时的两条底线——这些东西不在任何一份需求文档里，只存在人的习惯里。把它们写出来，比调模型难得多，也值钱得多。
能改多少，取决于能算清多少。一个算不清影响面的智能体，给它写权限就是在放大事故范围。
三、这次发布里没有数字
翻遍 Infor 的公告，找不到一个效果数字。Oldcastle APG 的副总裁 Jessica Vincent 的表态停在「可以让员工更容易找到相关业务数据，同时满足公司的治理要求」。公告里也明确写了，没有这家客户部署后的实测结果。三条工作流的公开演示排在 12 月 3 日。
这不是黑点，反而是这个阶段该有的样子。2026 年下半年，ERP 厂商的智能体大面积从「预览」走向「部分客户可用」，能拿出实测数字的很少，原因也简单：真正跑起来的样本还不够多，跑够三个月能算账的更少。凡是发布会上直接给出「效率提升 40%」的，基本都能追到一次内部试点或者一个精心挑选的场景。
对甲方来说，这意味着尽调方式要换。不要问「效果怎么样」，要问三件事：这个动作在哪个界面里被批准、批准页上显示哪些字段、批准之后系统里留下什么记录。这三个问题答不上来的供应商，功能演示再顺也别急着签。
四、回到 Odoo：影响面其实是查得出来的
Odoo 里没有叫「影响面」的按钮，但支撑它的数据结构是现成的。做制造业实施的人对这几条链路不陌生：
- 上下游追溯：
stock.move上有move_orig_ids与move_dest_ids，一层层串起来就是「这张采购单 → 这道工序 → 这个成品 → 这张销售单」的完整链条。委外业务里，组件发到分包商库位的那一段也在这条链上。 - 供需缺口：产品的预测报表（Forecasted）把在手、在途、已分配、待出一次摊开，比「库存数量」这一个字段有用得多。
- 日期联动：确认销售订单时，Odoo 会按路线生成采购或生产建议，计划日期随之前后移动。改一个日期，动的是整条链上的多个日期。
- 留痕：字段上打开
tracking=True，每次变更都会写进 chatter，谁改的、改前改后是什么，翻得到。
所以给 Odoo 加一个「影响面查询」的能力，不需要重写 ERP，需要的是三样东西按顺序搭起来：
| 层次 | 智能体能做什么 | 必须留给人的动作 |
|---|---|---|
| 只读 | 按订单号、客户、物料查上下游链路，输出受影响的单据清单 | 判断这份清单是否完整（有没有漏掉不走系统的部分） |
| 起草 | 生成加急采购单草稿、重排建议，列出改动前后的差异 | 逐条看差异，尤其是数量和日期 |
| 执行 | 直接确认单据、改承诺日期、调动已分配库存 | 每一次都要点确认，并留下批准人 |
第三层是最容易出事的地方，因为它看起来最省事。一个直接调用确认动作的智能体，出错时不会报错，只会安静地把库存占了、把交期改了，然后在一周后的客户投诉里被发现。Infor 的处理方式是「逐笔显式批准」，这个做法不新鲜，但值得照抄：把确认键做成智能体流程里唯一不能自动化的部分。
五、三条可以在下周就做的事
第一，把「影响面查询」当成第一个交付物，而不是最后一个。先让智能体只会查、只会列出受影响的单据，跑两周，让业务同事挑错。挑出来的错，就是后面写角色剧本的素材。
第二，给每个角色写一张三列的表：会问什么、要追什么、允许改什么。第三列留空的角色，先别上写权限。这张表比任何一份 AI 规划都更能约束项目范围。
第三，把批准页当成产品来做。批准页上要能看到：改的是哪张单、改前改后差在哪、会牵连哪些单、上一次类似改动是谁批的。四行信息，决定这个人敢不敢点。
回到开头那个电话。真正让人头疼的从来不是「料晚了 20 天」这个事实，而是这个事实要在四个系统、三个人之间传递两小时，还没人敢保证传全了。智能体在这里的价值，不是替采购员做决定，是把那两小时里该看的东西一次摆齐，让决定在十分钟内做出，并且事后能说清是谁做的。
至于它能不能改单，那是后面的事。先让它学会算牵连。
信息来源：ERP News（2026-11-12，Infor 与 Anthropic 合作公告及 M3 配置指南整理）、Infor 官方发布材料。文中涉及 Odoo 的技术说明基于公开文档与实施经验，具体实现依版本与业务配置而定。
广州众谛信息 · 企业数字化观察 · 2026-11-13
