ERP 接入大模型，先防工具失效后编造数据

工具没有接通，模型却回答「查到了 2 个会计科目」。数据库里的调用次数是零。这篇 ERP 接入实录讨论的，就是这种最麻烦的情况：模型会把没有发生的操作，讲得像已经完成。

作者的结论是，把安全寄托在模型听话上靠不住。他们围绕 ERPNext v16 搭了「墙、账、卡」：网关限制操作，审计记录事实，语义卡片描述业务对象。值得读的不是一套已经完美的方案，而是那些测试全绿、系统却悄悄走偏的具体故障。

模型能编结果，写数据库的权力就要拆开

他们的底座是 ERPNext v16，清理废弃对象后约有 500 个业务对象，即 doctype。内部 Agent 平台通过 MCP 挂载工具，模型使用最便宜档的 GLM。三天是接入生产链路、固化规则的时间；平台、卡片注册表和早期网关此前就已存在。

「墙」负责请求格式、场景白名单、写入确认和预算熔断。读取也受格式、白名单和预算约束，写入额外经过确认。

真正关键的一次修补发生在权限层。作者探测发现，助手绕过 MCP，直接调用 REST 创建、修改数据，都返回 200。确认钩子只守住了 MCP 入口。

修补后，助手账号只有读权限，写入交给独立 executor 账号；没有配置 executor，就拒绝执行。数据库里的创建者是 executor，助手的编排过程另记审计。

网关规则能否守住数据库，取决于底层账号有没有绕过它的权限。

确认机制也走了弯路。V1 用两阶段流程：登记写入、领取一次性凭证，再携凭证提交。测试发现，模型能自己补上确认话术。V2 增加 ERP 内的人工审批，助手审批自己登记的单据会被底层平台以 417 拒绝，但用户嫌操作难懂。

V3 又回到对话确认。下面是原文的交互格式，用两行让用户决定是否落库：

New customer "Zhang San", type: company.
1 confirm / 2 cancel

要看的是第二行：回复 1 才进入执行流程，回复 2 则取消；这两行展示文字本身不能充当授权证据。

V3 组合了一次性凭证、最长十分钟有效期、rejected 否决和最短等待间隔（dwell）。测试中，过快确认会被拒绝，场景脚本因此等待五秒；原文没有给出可直接照搬的统一等待阈值。

这里有明确边界：等待可以拦住毫秒级的自确认，但不足以证明确认来自真人。会话被冒用后，攻击者的 1 与用户的 1，网关无法区分。

测试为什么不能听模型说「成功了」

模型除了编查询结果，还会虚构「已收到确认」。测试机器人如果相信这句话，就可能盲目重发，干扰一次性凭证流程。因此作者规定，机器人只根据审计行行动，禁止盲重试。

场景里确实有一次补发：用户已经回复 1，却没有出现创建或取消结果时，再发送一次确认。它走的是确认接口，受一次性凭证约束，并非重发写请求。

另一种情况是同一轮发出两次工具调用：前一次参数错误被拒，后一次通过。消费审计时需要识别成功记录，也不能把末尾的拒绝判成成功。

他们把对话、网关审计和数据库结果分开核对：

• 网关放行，只能证明请求通过了检查，不能证明数据已经写入。
• 数据库没有新增记录，不能证明是网关拦截，也可能是 ERP 权限拒绝。
• 分域后必须读取对应网关的审计文件，并检查创建者是否为该域的 executor。

一次场景测试得到 19/20。作者随后绕开模型，手工重放六步请求，确认网关链路完整，失败来自模型重发时没有保留参数字面量。这支持当次故障归因，却不能让「模型抖动」成为永久解释。同一种失败反复出现，就要重新检查协议与网关。

测试还有时间细节：审计刷盘可能比响应晚两秒，dwell 边界要留半秒容差，每轮使用新会话编号。拿到 HTTP 响应就立即断言，很容易制造假失败。

更疼的一课是清理脚本按名字删除，误删了用户当天下午创建的真实客户。后来改成启动时记录名称集合，只清理本轮新增项；幂等性测试中的删除数量应为零。

五百个业务对象，靠一份注册表约束认知

「卡」是业务对象的语义说明：对象是什么、有哪些字段、哪些必填。注册表后来分成六部分：屏蔽列表、中文概念句、别名表、业务域划分、子表快照和运行时合并注册表。

作者坚持「语义是数据，不是代码」。新增对象、调整归属、补充说明，都修改数据文件再重启，不改网关代码。

这个设计有实际价值。某些 doctype 仍存在于站点元数据，却没有数据库表，访问就报 HTTP 500。他们用屏蔽列表移除对象，并同步清理权限影子。但屏蔽必须精确匹配：Bank Clearance 有问题，不代表真实存在的 Bank Clearance Detail 也该删除。

数据文件本身也会出事故。启动逻辑用 card-*.json 合并卡片，把新加入的纯配置文件一起读入，导致多实例崩溃。另一个常见原因更朴素：数据只在启动时加载，改完没有重启。

他们还取消了各域 skill 中手抄的接口约定，改为从注册表生成，用 --check 检查内部派生内容是否漂移。但这只能保证内部一致。ERPNext 升级后，上游字段、废弃对象和屏蔽列表是否变化，尚无自动检测；长期由谁维护注册表，原文也没有答案。

协议同样需要吸收模型的不稳定。模型曾把子表数组压成字符串，导致登记与确认时的摘要始终不一致，销售订单链路六轮零通过。修复是在摘要计算前，两边都把字符串化子表还原成数组；真实字段值变动仍然拒绝。确认回执还带上完整 payload，让模型有可复制的外部记忆。

我的判断

我赞同权限拆分、分层审计和单一注册表。这些做法把可以验证的事实，从模型的叙述里剥离出来，对企业系统尤其重要。

但文章证明的范围要收紧：一个最便宜档 GLM、三天接入、有限轮次，以及 MCP 主链路上已枚举的对象和方法。一次 19/20、约三分之一含糊话术，都不是完整可靠性统计。更贵模型、重试和更多提示词会不会改善，作者没有做对照，不能据此断言无效。

这套方案主要约束数据库操作，不保证回答真实，也不构成完整的数据安全方案。

白名单内过量读取、敏感字段探取、数据库内容反过来诱导模型，都没有被解决。导入、定时任务、WebSockets 也未逐一验证。

V3 的取舍尤其需要警惕。比 ERP 内审批方便，但时间门槛不能替代身份验证。作者提过可供人核对的摘要、单击确认链接，两种中间方案都没试过。

环境问题也尚未收尾：共享密钥重签让别人的请求变成 401；非主 checkout 意外加载旧网关；同名工具注册被最后一次覆盖。缺失白名单、配置行尾杂项导致静默降级的问题仍未修复。测试全绿之前，先得证明测到的是预期账号、代码和工具入口。

能拿来做什么

• 给现有 Node 工具服务接业务数据库时，先检查模型持有账号的直接访问权限，把查询与执行账号拆开，再验证绕过 MCP 的 REST 请求是否仍能写入。
• 为 AI 操作设计验收条件时，把「模型说成功」「网关放行」「数据库落库」分别记录，并让断言写清业务域、审计文件和实际创建账号。
• 工具对象较多时，把字段与操作约定维护成注册表，生成 Agent 使用的说明，再用类似 --check 的检查约束内部一致，同时单独安排上游升级核对。
• 在共享 ERP 环境跑场景测试时，固定工具注册入口、代码目录和账号，清理前保存快照，只处理本轮新增数据。