ERP 主数据修改交给 Agent，改错怎么追？

ERP 主数据修改交给 Agent，先让 Agent 用自己单独的账号，每次修改都记下改了哪条、哪个字段、改前改后值、谁提的需求、依据哪张单据；供应商银行账户、信用额度这类高风险字段，Agent 只准备修改，由人批了再生效；改错了按修改日志找回原值、查清影响了哪些单据。

Agent 登录身份与字段修改权限分级

系统管理员先为 Agent 在 ERP 中开设专用的系统接口账号，不共用也不借用员工的个人账号。这样日志里看得出哪些是 Agent 改的，哪些是人改的。

数据字段按照业务敏感度实施分级授权。对于物料的包装规格、辅助计量单位或开票税码等常规信息，允许 Agent 接收业务指令后直接写入；涉及客户结算方式、账期条款与供应商核心信息，系统只开放拟制草稿权限。

权限管控的边界要在接入业务前设定清楚。在正式接驳生产环境前，先在隔离环境用仿真数据验证权限隔离效果，具体测试方法见 Agent 测试环境：接 CRM 前先用模拟数据？。

每次改动记下改前改后值与依据

Agent 执行任何一条主数据写入动作，都要在审计表里留下一条不可篡改的修改日志。日志记录包括修改的具体数据表、目标字段名称、修改前旧值、修改后新值，以及操作执行的时间戳。这份字段变更记录和 ERP 自带的日志分开存。

比如采购员通知修改某家供应商的常用发货地址，Agent 记录该字段由原地址变更为新地址。日志不仅记载数值变化，还会附上采购员的工号、单据编号或者审批截图附件，把业务需求来源绑定在一起。

日志存储权限独立于 Agent 的运行环境。Agent 本身没有修改或删除日志的接口权限，确保即便模型逻辑产生异常或者外部指令存在缺陷，所有的变更轨迹依然完好保留。

银行账户与信用额度高风险先批后改

供应商银行账户、纳税人识别号与客户信用额度属于高风险关键字段，Agent 执行先批后改逻辑。当接收到变更这类字段的诉求时，Agent 自动提取业务凭证并生成待办审批流，推送到财务与风控负责人席位。

比如变更供应商的收款银行账户，往往伴随着商业欺诈风险。Agent 只准备变更单，财务按原来留存的联系方式找供应商核实，核实之前新账户不生效。

线下人工复核通过并在系统签署电子意见后，Agent 才把新账号写进主数据。

改错之后怎么按修改日志回滚定责

如果发现 Agent 依据错误指令修改了主数据，管理员第一时间调出日志表定位改动范围。按日志里的改前值把字段改回去，改回去这一步也记一条日志。回滚以字段变更记录里的改前值为准。

改回去以后，还要查改错期间用过这条数据的单据，责任怎么分见 Agent 已经执行出错了，怎么回滚、责任算谁的。管理员调取变更流水，排查在改错期间有哪些新生成的销售订单、采购订单或对账单引用了错误数据，并列出清单交由业务负责人处理。

业务负责人根据影响清单决定是作废重开还是进行差额补齐。同时技术团队把导致改错的那条指令和规则找出来，在测试环境中复现并修补规则，验证通过后再更新规则库。

ERP 主数据修改：常见问题

Agent 能不能批量修改大批主数据？

Agent 可以承担批量修改任务，但需经过小范围试点与人工预审。处理大批量数据变动时，先由 Agent 导出包含修改前后对照的预览清单交由业务主管签字；经确认后先拿少数几条数据试跑，验证无误再全量执行。

业务员能不能直接发指令让 Agent 修改？

普通业务员不能随意指令 Agent 修改核心数据。Agent 严格校验发起人的岗位权限，仅限常规非关键字段能根据业务单据自动流转；遇到高敏感属性，要走审批流获得授权后方可执行。

ERP 自带的字段变更记录够用吗？

原生系统提供的记录往往只记录数值变动，缺乏对业务上下文的关联。如果系统自带的字段变更记录无法追溯是谁让 Agent 改的、依据哪张单据发起，企业就在 Agent 这一侧补齐业务日志，把发起人与附件凭证完整关联保存。