Agent 能改数据之前，人审这一步怎么设计

让 AI Agent 只回答问题，风险有限；一旦它能往 CRM 里改客户状态、往 ERP 里建单据、在协同平台上发起审批，每一次操作都会落到真实数据上。人审这一步，要在 Agent 动手之前就设计好。

结论先说：人审放在写操作之前，读取类操作默认放行，写操作默认先停下、等人确认；确认请求发给对这份数据负责的人，写清改什么、依据是什么；每次操作都留下可导出的记录。

一、先分读和写

Agent 的操作可以粗分成两类：

• 读：查询、汇总、检索文档。不改变任何数据，默认放行。
• 写：新增、修改、删除记录，发起审批，对外发消息。会改变数据或产生外部影响，默认先停下等确认。

这个默认值可以按实际风险逐项调整：某个写操作风险低、天天在做，可以放宽；某个读操作涉及敏感数据，也可以收紧。调整的单位是具体的某一个操作，而不是整个系统一刀切。

二、确认请求发给谁

确认请求不要统一发给 IT 或管理员，而是发给对这份数据负责的人：改客户信息找销售负责人，建采购单找采购，改合同台账找法务或合同管理员。他们更清楚这次改动对不对。

跨系统的任务尤其要拆开看。比如 Agent 从 CRM 读数据、写进 ERP、再通过飞书发通知，其中写 ERP、发通知两个环节可以分别要求不同的人确认。

三、确认时要看到什么

一个只写着「是否同意执行」的弹窗，等于让人盲签。确认请求里至少要有：

• 改的是哪个系统、哪条记录；
• 改之前是什么，改之后是什么；
• 依据从哪里来，比如哪份文件、哪条消息；
• 这是哪个任务里的第几步。

信息看得清，确认的人才能在几秒内判断，而不是每次都去系统里再查一遍。

四、「始终同意」要慎用

确认的人通常有四种选择：本次同意、始终同意、本次拒绝、始终拒绝。「始终同意」能省掉重复确认，但只适合风险低、反复出现、出错也容易改回来的操作。给出去的「始终同意」要列一张清单，定期回看，业务变了就收回来。

五、每次操作都留记录

无论放行还是拦下，每次操作都要留下记录：时间、操作人、连接的系统、执行的动作、参数和返回结果。记录要能按条件筛选和导出，出了问题能回溯，做合规检查时也有材料。

六、先从一个写操作试起

不必一开始就把所有系统都接上写权限。先挑一个写操作频繁、规则清楚的场景，比如把会议纪要里的待办写进任务系统，跑几周，看确认请求的信息够不够、谁在确认、有没有被一路点同意，再往下扩。多个协同平台同时在用的企业，入口怎么接可以参考钉钉、飞书、企业微信都在用，一个 AI 助手怎么同时接。

小结

Agent 改数据之前的人审，关键是：读写分开、写操作默认先停；确认发给数据的负责人，并写清改什么、依据是什么；「始终同意」有清单、定期回看；每次操作都留可导出的记录。

作为参照，北京飞沐网络科技有限公司的 FIM One 是可自托管的企业 Agent 平台，写操作在执行前自动暂停，向指定人员发起确认，确认人可选择本次或始终同意、拒绝；门控可以细到单个操作，每次操作的记录可筛选、可导出。机制说明见人审卡在哪一步，安全与审计能力见安全与部署。FIM One 为源码可见软件。