北京
大多数团队试着把大模型接到ERP旁边，一周之内就会撞上同一堵墙：演示很惊艳，然后财务的人问了一句，"那什么阻止它去改一张已过账的发票？"
这个问题问得对。ERP是记录系统。如果模型能随便往里写，每一次幻觉都会变成一条账目记录；如果它完全碰不到，那模型就只是个靠猜的聊天机器人。
实际采用的做法是：模型直接读，但它只能提出写入建议，每一处改动都由人来批准。听起来简单，也确实简单——这正是重点。
把世界分成两条道
把读和写当成两套完全不同的系统，而不是同一套系统上的两个权限。
- 读道：智能体可以查询主数据、未结单据、库存、账簿和状态字段，结果作为上下文回传给模型。
- 写道：智能体永远不能调用写入接口，它只能创建一份"提案"——一条描述它想做什么改动的结构化记录——放进ERP之外的队列里。
最关键的设计决定是：写道根本不存在于智能体的工具集里。它不是某个写着"别写"的开关，而是那个工具压根就没有。
让读道真正只读
"只读"应该由ERP来强制，而不是靠提示词。
- 给智能体建一个专用技术账号，只给显示权限，任何业务对象上都没有创建或修改授权。
- 读取通过一层薄薄的服务层暴露（OData、REST或数据库视图），而不是让模型自己拼裸SQL。
- 把智能体能看到的实体和字段做成白名单。薪资表、银行信息以及任何个人数据默认排除在外。
- 记录每一次查询，连同触发它的用户问题。当有人问"智能体为什么这么说"，你需要它当时看到的那几行原始数据。
如果某个对象在ERP里没法干净地表达"仅显示"，那就先别暴露它，以后再补。
把每次写入变成一份提案
当智能体判断某件事该变——释放一张被冻结的采购订单、更新交期、开一张贷项通知单——它输出的是这样一份提案：
- 动作：update_delivery_date
- 对象：PO 4500012345 / 行项目 10
- 当前值：2026-11-12，建议值：2026-11-19
- 理由：供应商11月6日的确认邮件称发货推迟一周
- 证据：邮件8831、采购订单历史4500012345
- 发起方：智能体；置信度：中
几条规则让这套东西跑得起来：
- 展示改动前后。审批人不必打开ERP就能看懂这次改动。
- 附上证据。每份提案都链接到支撑它的文档或数据行。
- 一份提案只对应一处改动。不要打包，打包会被橡皮图章式地一路盖章通过。
审批队列就是人坐的地方
队列是一个小应用（或者你现有工具里的一个频道），由指定的人对每份提案批准、修改或驳回。只有批准之后，一个独立的、非大模型的服务才会用它自己那份范围极窄的凭据去执行改动。
这个执行器故意做得很无聊：按schema校验提案，重新读取当前值确认提案生成后没有变化，应用改动，再把结果写回队列。
审批权限沿用你现有的授权矩阵。如果某个采购员今天在ERP里改不了价格，那他也批准不了智能体提出的价格改动。
把闭环合上
驳回也是数据。把原因存下来（"供应商错了""已经处理过""政策不允许"），再喂回智能体在类似场景下的上下文里。几周之后，提案质量会上升，驳回率会下降——而且你有一份书面记录说明原因。
盯三个数字：每周提案数、批准率、批准所需时间的中位数。批准率低，说明智能体需要更好的上下文；批准时间长，说明提案写得不够清楚。
你能得到什么
- 不用迁移。ERP仍是记录系统，什么都不用重建。
- 可审计。每处改动都有一个问题、一份证据、一份提案和一个具名的批准人。
- 安全的爬坡。从只读问答开始，给一个低风险动作加上提案，等数字说话了再扩。
从哪儿开始
挑一个你团队每天要问ERP十遍的问题（"这单到哪了？""这张发票为什么被冻结？"），只为它建读道，先上线，然后加第一种提案类型。
这套模式本身与厂商无关，在SAP、Oracle、Dynamics、Tally或自研系统上都能用。Suvishaz Tech的ERP Knowledge Agent采用的就是这个思路。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
