Agent 自动改了业务数据，审计记录至少要留下哪些字段

Agent 自动改了业务数据，审计记录应回答谁要求、谁批准、改了什么、工具做了什么，以及结果凭什么确认。对话全文和技术堆栈都不能单独回答这些问题。本文用合成 CRM 更新建立动作审计字段，适合已经允许智能体创建或修改业务对象的团队；模板是工程建议，不替代行业法规对日志的具体要求。

先区分意图、批准与实际执行

用户说“把日期改到周五”是意图，预览后的确认是批准，接口受理是发送结果，目标字段更新才是业务结果。四者应关联但分开记录。若只留最后一句“已完成”，无法解释错误发生在客户匹配、日期理解、确认还是接口调用。为一次业务动作建立稳定动作号，模型重试与接口重试分别记录，避免多个技术请求被当作多次独立授权。

基本字段包括动作号、关联任务号、请求人内部标识、入口、目标类型与 ID、工具名及版本、参数摘要、预览版本、确认人、确认时间与有效期。身份与角色由服务端获得，不使用模型自行填的姓名。记录申请人和实际调用服务账户的区别，才能在系统都显示机器人操作时仍追踪真实业务责任，管理员代操作也应有可解释的授权来源。

参数摘要要足以解释修改

以合成客户日期更新为例，摘要可写客户 ID、字段名、旧日期、新日期与目标版本；不必把完整客户资料放进日志。对大文件保存受控引用、版本与校验摘要，哈希本身不能让业务人员读懂修改，仍需要非敏感的变更说明。若字段值本身敏感，可按权限保存必要证据，在普通审计视图中展示掩码与动作类型。

OWASP 日志指南讨论事件属性、敏感数据排除与防篡改，可作为设计依据。审计表不应保存真实令牌、密码或完整认证头。错误详情也要先检查是否回显业务输入，再决定进入哪一类受控记录。将审计与调试日志分开，可以让业务人员查动作结果，同时限制开发者诊断细节的访问范围。

用三条动作记录验证字段是否够用

下载动作审计样例。第一条经确认写入成功并读回一致，第二条被权限系统拒绝且没有发送，第三条发送后超时、结果未知。三条均有请求人和工具，但只有真正批准的动作带确认摘要；拒绝记录不能伪造一个批准人。未知结果不填成功业务单号，而是关联后续查单任务，保留状态变化历史。

动作记录建议按事件追加，例如预览生成、确认通过、开始发送、结果核对、补偿完成，而不是不断覆盖一行最终状态。这样可以知道什么时候从未知转为成功，谁补充了证据。当前状态可由这些事件汇总生成，原事件应受到访问控制与完整性保护。错误修改日志内容不能用直接编辑掩盖，应追加更正说明并关联原记录。

审批绑定必须可以复核

确认记录绑定目标对象、参数摘要、目标版本与有效期，执行时校验一致性。预览后模型改动参数、等待时权限撤销或目标状态变化，都应留下拒绝或重新确认事件。批准人有权查看不代表有权修改，角色快照与实时授权决定应分开记录。日志展示“已人工确认”还不够，验收人员应能打开具体确认版本核对范围。

对于批量动作，记录批次与单项关系，不能只留“更新一百条成功”。每项都应有终态或待核对状态，部分失败能找到对应对象。人工接手以后，也按同一动作号记录处理人、证据与结果。补偿是新的业务动作，需要自己的权限与确认，并关联原动作；不能把原事件删除后只剩一条“恢复正常”。

审计系统失效时如何处理

如果重要动作必须可追溯，审计存储不可用时应暂停写入或进入明确的缓冲与补录机制，不能悄悄丢日志继续执行。缓冲本身要有容量、持久性与告警，达到上限时停止，避免系统故障时恰好失去最重要证据。时钟同步、时区和追踪号跨服务传递也要检查，否则事件顺序可能难以还原。

日志读取、下载与删除同样需要权限和记录，供应商排障只获取必要脱敏片段。保留期限按客户要求和适用规则确定，备份、第三方监控与导出副本分别盘点。所谓防篡改也需要明确技术与验证范围，不应仅因为表里有哈希列就宣布满足所有审计要求。验收要真实测试普通账号无法改写、受控管理员更正有痕，以及记录能按动作号检索。

审计查询还需要测试时区与排序。来自多个服务的事件可能迟到，显示时应同时保留事件发生时间与接收时间，避免误认批准发生在执行之后。若记录缺失，展示不完整状态并调查，不靠自然语言自动补出一段看似连贯的操作历史。

最后用一个业务争议问题演练：“为什么这位客户的日期变了？”接手人员应能从动作号找到输入依据、确认预览、接口发送和读回结果，无法确认的部分明确标未知。相关背景见流程自动化专题和项目失败原因，企业交付可查看集成服务。需要补齐现有 Agent 审计，可通过定制咨询提供脱敏动作链与查询诉求，确定最少必要字段和失败处置。