先说一台充电桩。
无锡博美芯做新能源充电桩，荷兰 BUCOMEC 集团的全资子公司，产品出口欧洲为主，卖到 50 多个国家。听起来是标准生意，但真正麻烦的地方藏在细节里：同一个功率的产品，因为各国电网标准不同，会衍生出好几个配置版本；核心电控自研，钣金结构件和电源模块委外加工，进口元器件和国内零部件混着买；每一台出厂的桩，都要用一个唯一的 SN 码关联到具体那份 BOM。
够复杂了。现在问题来了：这样一家企业要上 AI，第一步该干什么？
大部分人第一反应是选模型、挑场景、找供应商。但我看 11 月 9 日用友发布的那场启动会材料，反而觉得答案在另一个地方——他们把一期工程的目标定成"订单可视、成本可算、质量可溯"，先把主数据集中管理、按需下发，把物料、BOM、客户、供应商、科目统一口径，再做订单化运营监控和 MRP 联动。
换句话说：先花半年把地基夯平，再谈智能。这不是保守，这是唯一走得通的路。
一、上下文不是数据量，是来龙去脉
为什么地基这么重要？看同一天的另一条消息就明白了。
日立 11 月 9 日开始提供 TWX-21 调达 AI，第一批做采购运营。它的底气不是模型，而是 TWX-21 这个企业间交易平台二十多年攒下的网络——公开口径约 8.7 万家企业挂在上头。有了这层关系，Agent 才知道这家供应商上次为什么延期、那个料号上次涨价是哪一年、谁的报价一向偏高。
这类信息有个特点：它不在数据库里，它在流程的褶皱里。邮件、传真、微信、采购员的笔记、三年前的一次退货。你把这些东西丢掉，给 Agent 十个大模型也没用，因为它手里只有一张干净的报价单，看不出任何异常。
Rillet 的故事是另一种证明。这家三个月前刚拿到 1 亿美元 C 轮、估值 10 亿美元的 agentic ERP，11 月 9 日宣布进英国，目前服务近 1,000 家客户、覆盖 75 个国家。它客户里 Black Forest Labs 的 CFO Dave Arkell 说了句话，我觉得比所有产品介绍都准：技术栈需要 AI 在核心里，"而不只是 MCP 连接这类功能"。
这话从一个甲方 CFO 嘴里说出来，分量不一样。他不要一个能问数据的聊天框，他要的是同一份数据既能被人操作，也能被 Agent 操作，而且口径一致、权限一致、审计一致。
把这两件事合起来看，所谓"上下文"，不是把公司所有数据都塞给模型。它是一段有前因后果的业务记录：这笔单为什么改、这家供应商为什么留着、这个物料为什么用替代件。这些答案写在流程里，不在文档里。
二、多组织多口径，是最贵的一课
回到博美芯这个案例，它把出海制造企业的痛点写得比方案 PPT 还清楚：
| 业务特征 | 给系统出的题 | AI 之前必须先解决 |
|---|---|---|
| 三国法人（无锡 / 布科美科 / 香港） | 跨境多法人独立核算 + 集团财务集中管控 | 科目、币种、税则口径统一 |
| ETO/MTO 混合、按项目定制 | 设计变更频繁，交期跟着变 | 订单变更可评估、可重排 |
| 自研 + 委外 + 混采 | 计划与执行脱节、缺料与呆滞并存 | MRP 能算清采购、委外、生产、库存联动 |
| 同一功率多国配置版本 | 版本与工程变更管控压力大 | BOM 版本与有效性日期说得清 |
| 每台桩唯一 SN 关联 BOM | 正向与逆向质量追溯 | SN、批次、库位贯穿进料到出货 |
| 报价靠经验 | 成本报价粗放、毛利算不准 | 材料费、制造费、人工费、销售费用四项可拆 |
这张表里，没有一行是"AI 需求"。全是 ERP 的活。但它们决定了后面 AI 能不能接上——如果 SN 和 BOM 版本对不上，你连"这批货有没有问题"都答不出来，还谈什么智能质检、智能追溯。
还有个细节值得抄作业：博美芯在项目组织里设了主数据守门人。这个角色不是软件功能，是人，有名字，要对物料、BOM、客户、供应商的口径负责。项目按模块分步推进，一般问题对项目经理，重大事项提交指导小组决策。
我在项目里越来越相信一件事：主数据治理失败的项目，八成不是缺工具，是缺一个"说了算且愿意担责"的人。上一个 MDM 系统，不如先指定这个人。
研发、营销、生产、配件销售与香港财务纳入同一底座：主数据集中管理、按需下发，从源头保证业财一致
三、老系统上做 AI，现实的选择是什么
不是每家企业都能重建一套 Rillet。绝大多数甲方手里是一套跑了五到十年的 ERP，改不动也换不掉。这时候"AI 长在架构里"这句话该怎么落地？
我的经验是三个判断标准，跟选哪个模型没关系：
- 数据在不在一个库里。跨三个库、两张中间表拼出来的"实时"，其实是"每小时同步一次"。Agent 判断交期时看到的库存，可能已经是两小时前的。
- 规则能不能读。业务规则如果只存在于某位顾问的脑子里，或者封在一个看不见源码的黑盒里，你就没法向审计解释"为什么这单走了特批"。
- 权限能不能细化到记录。不是"这个用户能看销售模块"，而是"这个用户只能看自己区域的客户"。粗粒度的权限，Agent 一接进来就是数据泄露的入口。
以 Odoo 为例，它在这三点上的天然优势是：单一 PostgreSQL 库、业务逻辑在 Python 源码里可读可改、权限分到模型级和记录级（ir.model.access + ir.rule）。SN 与批次追踪、MRP、委外加工（subcontracting）这些制造场景是原生模块，不需要外挂。
但也要说清楚它的短板：社区版没有内置的智能体能力，要自己搭。这意味着上下文注入、工具封装、审计留痕这些活儿，得由实施方一项项做出来，而不是装个应用就完事。
这里有个坑我踩过：为了赶进度，把 Agent 的查询动作写成超管权限执行。系统跑得很顺，直到某天业务问"为什么华东的销售能看到华南的价格"，才发现权限表早就形同虚设。Agent 用的账号，必须和它服务的那个真人同权限，多一点都不行。
还有一件常被低估的事：历史数据的迁移量，直接决定 Agent 能往回看多远。我见过一个项目，新系统上线只迁了期初余额和未结单据，三年前的发货记录留在老系统里。结果采购 Agent 判断供应商交期可靠性时，样本只有三个月，遇到季节性波动就失灵。后来补迁两年历史单据，工作量比原计划的"数据清洗"整整翻了一倍。
所以规划阶段就得问一句：这个场景需要多长的历史窗口？采购判断交期偏差，通常要 12 到 24 个月；质量追溯要看完整的 BOM 版本变更链；成本分析至少覆盖一个完整的报价周期。窗口算清楚了，迁移范围和工期才有依据，不然一定是在 UAT 时才被发现。
四、给实施负责人的三条
- 先画"上下文地图"，再定 AI 场景。拿一张 A3 纸，把这个场景涉及的单据、主数据、历史记录、审批链全画出来。画不出来的部分，就是 Agent 一定答错的地方。这张图比需求清单有用。
- 把口径统一当成一期工程，不是前置条件。很多项目把主数据清洗放在"上线后优化"，结果第二年还在补。博美芯的做法是把主数据下发机制放进一期范围，配一个守门人，这个顺序值得学。
- 选能读源码的路线。不一定是 Odoo，但一定要能回答"这条规则写在哪"。AI 时代最贵的能力不是让系统跑起来，是出问题时能说清为什么。
Delight.ai 那套客户 Agent 的做法也能佐证这一点。它把购物、预约、支持、留存放进同一个 Agent，共享客户身份、偏好与历史，覆盖聊天、语音、短信、邮件和 WhatsApp。卖点不是"渠道多"，而是购买前的推荐和购买后的服务接上了同一份上下文。同一份，意味着不用重复问，也不会自相矛盾。
所以这篇文章的结论其实很朴素：企业不需要先买到更强的智能，需要先把自己的流程说清楚。SN 怎么编、BOM 版本怎么生效、委外回来怎么检、变更谁批、成本按什么口径摊——这些问题的答案，才是 Agent 真正的能力边界。
模型会一代代换，流程和口径不会自己长出来。谁先把地基打完，谁就能在下一轮模型升级时少折腾一次。
资料来源：用友网络《无锡博美芯选择用友BIP超级版：让多组织运营"订单可视、成本可算、质量可溯"》（2026-11-09）、日立 TWX-21 调达 AI 发布（11-09）、Rillet 英国扩张公告及客户引述（GlobeNewswire，11-09）、Delight.ai Customer Agent 发布（11-09）。文中客户规模、客户数与部署范围均为厂商公开口径。
众谛信息（Zodioo）· 企业数字化观察 · 2026-11-10
