比利时有一家做鱼子酱的家族企业，叫 Imperial Heritage Caviar。客户名单里有米其林三星餐厅、豪华酒店，还有一位私人游艇船东。公司不大，系统里约 500 个活跃客户。
它的订单入口很真实：WhatsApp、邮件、短信、电话。主厨们往往在晚市结束后才想起第二天要补货，消息常常整夜进来。过去，把这些订单敲进 Dynamics 365 Business Central，每天要花一到两个小时。生意越大，这两小时越像一根刺——它挤掉的不是行政时间，是跟客户说话的时间。
2026 年 11 月 11 日，微软把这个案例挂上了客户故事栏目。结果不难猜：手工录单压到 30 分钟以内，常规订单准备只需几秒，复杂订单的返工「几乎消失」。但真正值得看的不是这些数字，是他们怎么划边界。
一、两个智能体，三个技能，一个确认键
他们一开始想用 Business Central 预置的销售订单智能体。那个智能体主要处理邮件进来的订单，一条线索走到黑，满足不了多渠道的需求。更麻烦的是，公司里每个人偏好的 AI 工具不一样——有人习惯 Teams 里的 Copilot，有人习惯 Claude。
于是技术伙伴 Deltanexx 做了两个：一个基于 Microsoft Copilot Studio，一个基于 Anthropic 的 Claude。两个都通过 Business Central 的 MCP server 连接，能读、能写、实时执行。上层换了两个「脑子」，下层共用同一套接口。
技能只有三个，而且都是业务动作，不是技术动作：建销售订单、建客户档案、出客户跟进报表。看起来少，但每一个都对应一件每天必须发生的事。
| 技能 | 边界怎么划 | 为什么这么划 |
|---|---|---|
| 建销售订单 | 把自然语言翻成客户与物料记录，可以参照历史发票复现已谈定的价格和产品编码；先呈现明细，人确认后才创建 | 订单一旦落库就会占库存、算交期，错一张要连着改三处 |
| 建客户档案 | 新建之前，先查系统里有没有这个客户 | 重复建档不会报错，但会让对账、返点、信用额度全部错位 |
| 客户跟进报表 | 生成周报与销售概览，不发外部 | 报表是给人做判断的，不是给机器执行的 |
治理部分写得比功能更细，这才是案例的价值所在。Copilot Studio 那侧走的是 Business Central MCP 工具加微软预注册应用；Claude 那侧在客户自己的 Microsoft Entra ID 租户里单独注册应用，由管理员同意委派式访问。MCP 的配置本身界定了智能体可以调用哪些 API 和操作，Azure Application Insights 记录调用，供监控和支持。
翻译成大白话：不是给智能体一个超级账号，而是给它一份写清楚能开哪几扇门的通行证，再加一本进出登记簿。
这个案例的最小结构，可以照抄：一个入口（自然语言，渠道随意）+ 三个技能（建单、建客户、出报表）+ 一个确认键（落库前必须人看过）+ 一条审计日志（谁调用了什么）。四件东西凑齐，一个十几个人的公司就能自己维护，不需要立一个「AI 平台项目」。
二、真正难的不是读单据，是认得对
四天前，美国食品供应链公司 GrubMarket 发布了一个采购订单智能体。它做的事和上面很像：把供应商发票、收货单、甚至一段自然语言，转成结构化的采购订单，用户可以核对后一键写进 ERP。
产品说明里有意思的不是识别能力——支持照片、PDF、表格、纯文本，这已经是 2025 年的基本功。有意思的是它讲匹配的那一段：产品匹配不只比名称，而是用历史订单行为、按客户配置的「企业词典」，加上针对具体供应商的 AI 训练，把供应商写的品名映射到分销商自己的商品目录。
这句话点破了一件事。单据自动化的瓶颈早就不在「读得懂」，而在「认得对」。
| 环节 | 看起来的难点 | 实际上的难点 |
|---|---|---|
| 读单据 | OCR 准不准、格式多不多 | 已相对成熟，属于工程问题，肯花钱就能解决 |
| 认商品 | 名字对不对得上 | 供应商料号不等于内部料号；一物多名；新品没有历史可参照 |
| 算数量 | 数字抄对没 | 采购单位与库存单位不同，箱、件、公斤换算错一步，库存和成本一起歪 |
| 定价格 | 发票上有金额 | 含税与不含税、运费与附加费、临时议价，口径不同对账就打架 |
更麻烦的是，这四道关的错误不会互相抵消，而是各自放大。一张采购订单写错物料，库存多一批不存在的货，成本按错的单价摊进产成品，毛利分析跟着失真，应付账款最后还要跟供应商吵一次。读错一个字，四个部门各返工一遍。
这也解释了为什么「企业词典」这种听起来一点不性感的东西开始被产品化。它不是知识库，而是把公司内部的命名习惯固化成一张可维护的表：谁维护、多久更新一次、新旧料号怎么并存。这是管理问题，不是模型问题。
三、把这套东西放回 Odoo，是四道具体的关
如果你在做 Odoo 的实施，上面那些话可以一步步落到具体的表和字段上。Odoo 的好处是这些东西都在同一个库里，不用跨系统拼；坏处也是同一个——错一次，整个库一起错。
| 关卡 | Odoo 里对应什么 | 常见的坑 |
|---|---|---|
| 客户 | res.partner，按名称、邮箱、电话、税号做重复提示 | 提示不等于拦截。同名不同主体、集团与门店混建、海外客户缺税号，都会留下重复档案 |
| 物料 | product.product 的内部参考与条码；product.supplierinfo 上的供应商料号与供应商品名 | 供应商料号只存在于对方系统；同一物料多个别称；新品没有历史订单可参照 |
| 单位 | uom.uom 与 uom.category 的换算因子，采购单位可与库存单位不同 | 采购按箱、库存按件、销售按公斤，三个单位分属不同类别，换算写错就是系统性偏差 |
| 价格 | product.supplierinfo 的供应商价格、客户价目表、历史发票行 | 含税不含税混用；运费没进成本；临时议价进了单价却没人改回价目表 |
四道关里，最容易做、收益最大的是第二道。Odoo 的 supplierinfo 天生就是一张「供应商说法到我们说法」的对照表，只是很多项目上线时只填了价格和交期，没填供应商料号与品名。等到要做单据自动化，才发现这张表是空的——于是智能体只能靠模糊匹配猜，猜错的比例高到业务不敢用。
一个具体的建议：把 supplierinfo 当作数据资产来治理，而不是当作价格表来填。每个主要供应商的前 50 个常用物料，供应商料号、供应商品名、最小包装、交期四项补齐，单据自动化的准确率会有肉眼可见的变化。这项工作不需要 AI，只需要一个人和两周时间。
确认键该放在哪一层
微软那个案例里，确认发生在「订单创建之前」。放到 Odoo 里，对应的是明确的一条线：智能体只写草稿，确认动作由人触发。
- 销售侧：智能体建 sale.order 的草稿报价单，人核对后点确认；不要让智能体直接走到确认状态。
- 采购侧：智能体建 purchase.order 的询价单，人核对后转采购订单。
- 会计侧：智能体只写 account.move 草稿，过账由人做。
理由很朴素：草稿可以改、可以删、可以不算数；一旦确认，库存预占、交期承诺、财务凭证就会连锁发生。把不可逆的动作留给人，是这类项目最便宜的风险控制。
还有一件常被忽略的事：确认页面要给人「看得懂的差异」。只显示「智能体建议：客户 ABC、物料 XYZ、数量 200」，人没法判断。要显示的是与历史相比变了什么——客户换了、物料换了、单价比上次高了 8%、交期比标准承诺短了三天。差异才是判断依据，字段罗列不是。
四、给实施者的三条
第一，把别名表当成交付物。项目验收清单里加三张表：供应商料号对照、客户简称对照、单位换算对照。每张表要有维护人、更新频率、失效标记。没有这三张表，智能体再聪明也只能猜；有了这三张表，哪怕用最简单的规则匹配也能跑起来。
第二，先只做「读」和「起草」，别急着做「改」。读数据、生成草稿、给人看差异，这三件事错了代价很小。改价、改交期、删行、合并单据，这四件事错了要追溯半天。很多项目的翻车点不是能力不够，是第一天就把写权限开到了最大。
第三，用历史单据做回放测试，而不是用演示数据。抽上一个月的 100 张真实单据，故意覆盖四类情况：新客户、新物料、临时改价、退货。测两个指标：一次通过率，以及平均要人工改几个字段。这两个数比任何演示都诚实。
最容易被跳过的一步：回放测试里要包含「同一张单据用不同入口再跑一遍」。邮件进来的和聊天里说的，结果是否一致？不一致的地方，是渠道差异还是系统在猜？这个问题在演示阶段问不出来，只有回放能问出来。
回到那家比利时公司。他们的方案开发只用了几周，采购和供应商的 API 已经配进 MCP，下一步是做采购技能。这个节奏说明一件事：当接口、权限、技能边界都收在一处时，加一个新技能的边际成本很低。真正花时间的，是前面把边界想清楚的那几周。
国内很多企业卡在相反的地方：模型接了三家，接口写了十几个，技能做了二十个，但供应商料号还没人维护，客户档案里躺着三千个重复联系人。这时候上智能体，等于让一个新人拿着错电话本去拜访客户，跑得越快，错得越多。
一句话总结：AI 在单据上的竞争力，最后不落在模型上，落在你们公司有多少张没人维护的对照表上。模型三个月换一代，对照表不会自己长出来。
资料来源：Microsoft Customer Stories《Imperial Heritage Caviar doubles time saved on administrative tasks by adding AI to its Dynamics 365 Business Central platform》（2026-11-11，含公司所有者 Elisabeth Colman、Deltanexx 管理合伙人 Dhia Athmini 表述，以及 MCP 配置、Entra ID 应用注册、Application Insights 记录等治理细节）；PR Newswire《GrubMarket Launches AI Agent That Transforms Purchase Order Processing for Food Distributors》（2026-11-10，含企业词典、供应商专属训练、多渠道提交与 ERP 集成范围）。Odoo 侧字段与机制说明基于 Odoo 19/20 标准功能，具体行为随版本与本地化模块而异，实施前需在测试库验证。
数据口径说明：比利时案例的「每天 1 至 2 小时压到 30 分钟以内」「常规准备几秒」「返工几乎消失」均为客户方估算，未披露统计区间与样本量；GrubMarket 未披露匹配准确率、客户数量与定价。文中 Odoo 建议为实施经验判断，不构成对具体项目结果的承诺。
众谛信息（Zodioo）· 企业数字化观察 · 2026-11-12
