11 月某天上午，一家做工业品分销的企业 IT 负责人打来电话，语气很急：财务在月结时发现，过去两周有 30 多张采购入库单的金额被系统改过，差异从几百到几万不等，加总差了十几万。问财务，财务说没改过；问采购，采购说也没碰；翻系统操作日志，发现修改人是一个叫「AI 助手」的账号——这是他们三个月前上线的发票核对 Agent，本来只让它读发票、提醒差异，不知道什么时候被加了「自动修正」的能力。更麻烦的是，日志里只记录了"金额从 A 改成 B"，没有记录 Agent 当时看到的发票图片、调用的 Prompt、返回的判断依据。十几万的差异，要重新人工核对两周的数据才能复原。
这不是个案。AI Agent 上线后的事故，多半不是"Agent 突然变坏"，而是"出事时讲不清楚是谁让它这么做的"。传统系统的审计逻辑——记下"谁、什么时候、改了什么"——对 AI Agent 远远不够。Agent 是一个会"思考"的执行体，你还得记下"它当时为什么这么想"。这篇文章把开沿过去给客户做 AI Agent 安全运维总结的 8 件必做事项摊开来讲，给已经上 Agent 或即将上 Agent 的 CIO、合规、IT 一份可以照着做的清单。
为什么 AI Agent 比传统系统更需要审计：3 个本质差别
传统的 ERP、OA、CRM 也要审计，但 AI Agent 的审计难度是完全另一个量级。本质差别有三个，理解了这三个，后面 8 件事的必要性就讲通了。
第一，行为是不确定的。 传统系统是确定性的：同样的输入、同样的代码、同样的时间，输出一定一样。审计时拉日志、查代码就能复盘。AI Agent 不是。同一个 Prompt，模型版本一变，回答就可能不一样；上下文里多一条历史消息，决策路径就可能拐弯。所以审计不能只记"做了什么"，还要记"输入是什么、模型是什么、上下文是什么"，才能在事后复现。
第二，权限是放大的。 传统系统里，一个员工的权限是受限的：能看哪几张表、能改哪几个字段、能审哪几级单据，都写死在角色里。AI Agent 一旦接入，可能为了"帮员工提效"被授予了远超员工本身权限的访问范围——比如一个普通业务员的 AI 助手能查全公司的销售台账。如果不做双层映射，员工通过 Agent 就能越权。
第三，问题是隐蔽的。 传统系统出错，往往是一次性的、有明确报错的；AI Agent 出错经常是慢性的、累积的：连续两周每张单据少算 100 元，月底才发现；客服 Agent 对外回复时悄悄把价格答错，三个月后客户投诉才暴露。没有持续监控的指标体系，错误会埋很久。
明白了这三个差别，再来看 8 件必做事项就不是堆清单，而是有针对性地堵这三类漏洞。
8 件必做事项一览：先把骨架搭起来
下面这张表把 8 件事拉齐到同一个视野里，每件事对应解决前面 3 个差别里的哪一个，谁是责任人、最小可上线版本是什么样子。读者可以先用这张表对照自己的现状，看缺哪几格。
| 必做事项 | 解决什么问题 | 责任部门 | 最小可上线版本 |
|---|---|---|---|
| 分级权限 | 权限放大 | IT + 业务 | Agent 用调用人身份去查，不用超级账号 |
| 操作留痕 | 行为不确定 | IT | 记录谁、何时、调用了哪个 Agent、改了哪条数据 |
| 上下文留痕 | 行为不确定 | IT + 算法 | Prompt 全文、模型版本、回答全文加密存档 |
| 写操作人审 | 问题隐蔽 | 业务 | 涉及金额、主数据、对外消息的写动作必须人工确认 |
| 调用频次监控 | 问题隐蔽 | IT | 单人/单 Agent/单接口的调用频次基线与告警 |
| 异常告警 | 问题隐蔽 | IT + 合规 | 敏感字段访问、夜间调用、跨部门数据访问 |
| 回滚预案 | 行为不确定 | IT + 业务 | 关键数据的快照与 1-2 个工作日内回滚 SOP |
| 季度审计 | 综合兜底 | 合规 + 审计 | 抽样复核、模型变更评估、权限漂移检查 |
8 件事并不是要一口气全部上线。开沿在给客户做 AI Agent 落地时，通常按"权限+留痕+写操作人审"先上线，把最大头的风险盖住；调用频次监控和异常告警放在第二阶段；回滚预案和季度审计配合上线 1-2 个月后启动。每一阶段都不超过 2 周，避免审计建设本身变成新的工程拖延。下面把其中最容易出错的几件单独展开。
权限审计：员工权限和 Agent 权限的双层映射
权限是 AI Agent 审计里最容易踩的坑。常见的错误做法是：给 Agent 单独建一个"超级账号"，让它能访问所有数据；员工通过 Agent 提问的时候，Agent 用这个超级账号代查。看起来方便，实际上一个普通员工就可以通过问 Agent 拿到自己根本无权访问的财务、客户、薪资数据。
正确的做法是双层映射。第一层是"调用人权限"，即谁在跟 Agent 说话，Agent 必须知道调用人的真实身份与角色，并在每一次数据访问时以调用人的身份去查；如果调用人本身没权限，Agent 就应该拒绝或返回脱敏结果。第二层是"Agent 自身权限"，即这个 Agent 作为一个执行体，最多被允许访问哪些数据、做哪些动作，这是 Agent 的"能力上限"。最终生效的权限 = 调用人权限 ∩ Agent 权限，取交集，不是并集。
下面这张表是一个简化的映射示例，可以照着做：
| 角色 | 个人权限 | Agent 自身权限 | 通过 Agent 实际可访问 |
|---|---|---|---|
| 业务员 | 自己的客户和订单 | 全公司客户、订单、库存 | 自己的客户和订单（取交集） |
| 销售经理 | 本团队的客户和订单 | 全公司客户、订单、库存 | 本团队的客户和订单 |
| 财务专员 | 应收应付、发票 | 全公司财务数据 | 应收应付、发票 |
| 财务总监 | 全公司财务 | 全公司财务数据 | 全公司财务 |
| 高管 | 全公司数据看板 | 全公司客户、订单、库存、财务 | 全公司数据看板 |
有了这张表还不够，还要在每个季度做一次"权限漂移"检查：员工换岗位了，但 AI Agent 的访问历史里是不是还有旧岗位的痕迹？Agent 升级版本时，是不是被悄悄加了新的能力？开沿在做季度审计时，会专门拉一份"过去 90 天调用人权限与 Agent 实际查询字段的差异表"，差异行就是需要人工确认的可疑动作。
操作留痕：日志要存什么、存多久
很多企业的 AI Agent 上线后没事，是因为没出事；一旦出事，第一反应是拉日志，结果发现日志只有"Agent 调用成功"五个字，根本复盘不了。
合格的操作日志至少包括 8 个字段：调用时间、调用人 ID、Agent ID 和版本、调用的接口/工具名、入参摘要、出参摘要、是否触发写操作、关联的业务单据号。这 8 个字段是审计的最小集，少一个，事故复盘就会卡住。
存多久也有讲究。不同字段建议分层存储：
| 数据类型 | 建议保存时长 | 理由 |
|---|---|---|
| 操作元数据（谁、何时、调了什么） | 3 年起 | 财务、合规、税务可能回溯 |
| 入参/出参摘要 | 1 年 | 短期事故复盘 |
| Prompt 全文 | 6-12 个月 | 模型行为复现 |
| 模型回答全文 | 6-12 个月 | 对外回复纠纷溯源 |
| 上下文历史消息 | 3-6 个月 | 调试与异常行为分析 |
| 涉及个人信息的字段 | 按当地法规 | 通常 1-3 年并加密 |
不要一刀切按最长时间存所有数据，那样存储成本会失控；也不要图省事只存元数据，那样关键时刻什么都查不到。一个 80 人左右的中型企业，按上面这个分层方案，一年的存储费用大约在几千到一两万的量级，相比一次事故造成的损失，几乎可以忽略。
上下文留痕：Prompt 和回答都要留
操作留痕解决"做了什么"，上下文留痕解决"为什么这么做"。AI Agent 的决策依据是 Prompt + 上下文 + 模型，三样缺一不可。
Prompt 留痕的难点不是技术，是边界。如果 Agent 是基于多轮对话的，每一轮的完整对话历史都要存吗？开沿的建议是：当前 Prompt 的完整文本必须存；上下文历史按"决策相关"原则存——影响这次决策的最近 N 条消息（通常 5-10 条）打包存档，更早的历史只存哈希做完整性校验。这样既能复盘，又不会让存储无限膨胀。
模型回答的留痕同样重要，尤其是对外类 Agent（客服、销售辅助、催收）。对外回答出现纠纷时，企业要能证明：当时 Agent 看到的是什么、回答了什么、是否经过人审。回答留痕还要包括模型版本号和 temperature 等参数，因为同一段 Prompt 在不同参数下输出可能完全不同。
这里要插一句开沿做 AI Agent 落地的核心观点：AI Coding 让定制化的成本不再等比例贵，过去给每个 Agent 单独写一套日志中间件至少要 10-15 人天，现在配合 Claude Code、Cursor 这类工具，做一个标准的日志拦截层 + 多 Agent 复用，2-3 人天就能上线。审计能力不再是"做不起"，而是"愿不愿意做"的问题。关于这条路径可以参考 AI Coding 让软件交付改变了什么 与 企业级 Claude Code / Cursor 落地 这两篇。
异常告警：什么样的 AI 行为算异常
监控指标体系要有"基线"，没有基线就没有异常。基线通常包括三类：单人调用频次基线（每个员工每天大致调用多少次 Agent）、单 Agent 调用频次基线（一个 Agent 每天大致被调用多少次、覆盖哪些接口）、单接口调用模式基线（这个接口正常被哪些角色、在什么时间段调用）。
任何一类基线被打破，都值得告警。下面是开沿在客户项目里默认会布的几类告警规则：
| 告警类型 | 触发条件 | 建议处置 |
|---|---|---|
| 频次异常 | 单人 24 小时调用超过基线 3 倍 | IT 24 小时内联系当事人核实 |
| 敏感字段访问 | 查询薪资、银行卡、身份证等字段 | 立即告警合规，事后人审 |
| 夜间调用 | 凌晨 0-5 点高频调用业务 Agent | 检查是否被外部凭据盗用 |
| 跨部门越权 | 调用人本部门没权限的数据 | 阻断 + 立即告警 |
| 写操作未人审 | 涉及金额修改但跳过人审 | 阻断 + 回滚 + 告警 |
| 模型版本变更 | 供应商单方面升级模型 | 暂停高风险 Agent 直到评估 |
告警的关键是分级。一类要立即阻断、一类要 24 小时内回访、一类只做记录。如果所有告警都按最高级处理，IT 会被淹没，最终的结果是所有告警都被忽略。开沿建议每个企业在上线前就定义清楚告警分级表，并和合规、业务一起评审，不要 IT 自己拍。
写操作人审：金额、主数据、对外动作必须人卡一道
只读类 Agent（查数、汇总、提醒）出错的代价是有限的，最多浪费时间；写操作类 Agent（改单据、发消息、推审批）一旦出错，会直接造成业务损失。所以写操作必须人审，这是底线。
哪些写操作必须人审？开沿的清单是三类：第一类是涉及金额的修改，包括订单金额、采购金额、应收应付、报销金额；第二类是主数据的修改，包括客户档案、供应商档案、物料编码、价格表；第三类是对外动作，包括对客户、供应商、合作伙伴发送的邮件、短信、IM 消息。这三类只要 Agent 想动手，必须先在内部审批/消息中心发一条"待人审"的卡片，相关角色点了"同意"才执行。
可能有读者会说：这不就退化成 RPA 了吗？其实不一样。RPA 是没有判断能力的，所有动作都靠人发起；AI Agent 是有判断能力的，只是判断完之后落地动作要走人审。AI Agent 把人从"逐字段填表"解放出来，专注做"是否同意"的判断，这正是 AI Agent 接业务出结果可衡量的核心方式——可衡量的不是 Agent 做了多少事，而是 Agent + 人审的组合让单据处理周期缩短了多少、错误率下降了多少。具体设计可以参考 AI Agent 落地 6 步法 和 AI Agent 接业务出结果的 8 步法。
出问题怎么追责：5 个角色的责任划分
AI Agent 出事故，没有清晰的责任划分，结果一定是"大家都说不是我"。提前把责任表写清楚，比事后扯皮便宜得多。
| 角色 | 主要责任 | 出事后承担的部分 |
|---|---|---|
| 业务 owner | 提出场景、验收效果、确认审批流 | 场景设计错误、人审环节缺失 |
| IT 负责人 | 技术架构、权限配置、日志完整性 | 配置漏洞、日志缺失、监控失效 |
| 合规/审计 | 制定红线、季度审计、事故响应 | 红线模糊、审计不到位 |
| 算法/供应商 | 模型选型、Prompt 工程、模型版本管理 | 模型质量问题、未告知的变更 |
| 调用人（员工） | 按规范使用、不诱导越权 | 故意诱导、明知错误不上报 |
这张表建议写进 AI Agent 上线的内部文件，并由这 5 个角色签字确认。开沿见过的反例是：上线时大家都说"先用着、出事再说"，半年后一个 Agent 出了几万的损失，业务说是 IT 的配置问题，IT 说是供应商的模型问题，供应商说是业务的使用问题，最后老板自己掏腰包了事。
签字不是为了在事后罚谁，而是为了在事前让每个人重视自己那一块。关于"出事后再处理"的代价，可以参考 企业 AI 项目卡在 POC 的根因 和 企业 AI 落地 8 步法。
季度审计 SOP：一份可以照着做的清单
季度审计不是走形式。一个 80 人左右的中型企业，AI Agent 数量通常在 3-8 个，做一次完整的季度审计，专职人员投入 3-5 人天就够，远低于事故损失。下面是开沿推荐的 SOP 框架，企业可以根据自己情况裁剪。
- 权限漂移检查（半天）：导出过去 90 天每个调用人的实际访问字段，对比当前权限表，差异行必查。
- 抽样人工复核（1 天）：从涉及金额、主数据、对外消息的写操作里随机抽 1-3%，由业务和合规联合复核 Agent 的判断是否合理。
- 告警有效性回放（半天）：把过去 90 天没触发告警的高频调用拉出来，反向检查告警规则是不是有盲区。
- 模型版本与 Prompt 变更梳理（半天）：列出本季度所有的模型版本升级和 Prompt 修改，评估每次变更是否做了影响评估。
- 日志完整性校验（半天）：随机抽 50 条调用，看 8 个必备字段是否齐全、上下文是否可复现。
- 回滚演练（1 天）：选一个真实业务单据，模拟 Agent 改错，走完一次完整的回滚流程，记录耗时。
最后一项很多企业会跳过，开沿建议保留。回滚预案如果不演练，关键时刻一定会卡住。
上线前的自检清单
如果你正准备上 AI Agent，或者已经上线但还没建审计体系，按下面这 10 条自检一遍，缺哪条补哪条：
- 每个 Agent 都用调用人身份访问数据，没有超级账号代查
- 调用日志包含 8 个必备字段，至少存 1 年
- Prompt 和回答全文加密存档 6-12 个月
- 涉及金额、主数据、对外消息的写操作有人审环节
- 已经定义了至少 4 类告警规则并分级
- 有调用频次基线和异常检测
- 关键数据有快照与回滚 SOP，能在 1-2 个工作日内回滚
- 5 个角色的责任表已签字
- 已排好每季度一次的审计 SOP
- 高风险 Agent（对外、改金额、改主数据）有应急熔断开关
10 条都做到，你的 AI Agent 上线就基本扛得住合规检查和事故复盘。开沿在做 AI Agent 落地时，会把这 10 条嵌进交付清单，缺哪条不收尾款。
写在最后
AI Agent 是一个会自己做决定的执行体。它让企业的效率有机会上一个台阶，也让事故的隐蔽性、放大性、复盘难度同步升级。审计不是 AI Agent 的"附加项"，而是和 Agent 本身一样重要的"必选项"。把 8 件事——分级权限、操作留痕、上下文留痕、写操作人审、调用频次监控、异常告警、回滚预案、季度审计——做到位，AI Agent 才能从"老板半信半疑、IT 心惊胆战"的状态，变成一个真正能稳定为业务出结果的资产。
如果一时上不齐，按"权限 + 留痕 + 写操作人审"的顺序先把最大头的风险盖住，剩下的分两到三个月补完。审计建设没有捷径，但每一步都比事后赔钱便宜。
