Agent 调用外部工具出了错误操作，责任和审计怎么设计？
面试怎么回答
首先每次 Agent 执行都要完整留痕：发起人和原始指令、计划和推理摘要、每次工具调用的参数和返回、用到的数据口径、人工确认记录以及模型提示词和工具版本，并且不可篡改、和业务日志关联。Agent 本身不承担责任，要从记录里定位是指令不清、口径理解错、工具缺少上限和确认、确认信息不充分导致流于形式，还是权限过大。预防上资金、对外触达、批量类操作必须确认，确认信息要展示人数金额和口径定义；设置数量和金额上限；关键业务概念必须用语义层的标准定义；批量操作先预演或小比例执行；尽量可撤销；异常操作量实时告警。出了事按事故复盘，找系统和流程的问题。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
运营同学让 Agent「给上个月流失的高价值客户发一张优惠券」，Agent 把「高价值」理解错了，给 5 万个用户发了券，造成了几十万的损失。出了事要回答：谁的责任？哪一步错了？以后怎么避免？面试官问这题，想看你怎么在设计阶段就为 Agent 的操作建立审计和责任链。
先能还原全过程
每一次 Agent 执行都要有完整记录：
- 发起人：谁发起的任务，原始的指令是什么；
- 决策过程：Agent 的计划、每一步的推理摘要；
- 工具调用：调用了哪个工具、参数是什么、返回了什么；
- 数据依据：查了哪些数据、用了什么口径（比如「高价值」用的是哪个定义）；
- 确认记录：哪些步骤经过了人工确认，确认人看到的信息是什么；
- 版本信息：模型、提示词、工具的版本。
记录要不可篡改，和业务操作日志关联。
责任怎么界定
Agent 本身不承担责任，责任在设计和使用它的人与流程上。从记录中定位问题出在哪个环节：
- 指令不清：发起人的要求本身有歧义；
- 理解错误：Agent 用错了口径，「高价值」没有使用公司的标准定义；
- 工具设计缺陷：发券工具没有数量上限、没有二次确认；
- 确认流于形式：确认请求里没有展示「将向 5 万人发券、预计成本 X 元」这样的关键信息，确认人没看清就点了同意；
- 权限过大：这个场景本不该允许 Agent 直接执行批量发券。
设计上的预防
- 高风险操作分级：涉及资金、对外触达、批量操作的工具，必须人工确认；
- 确认信息要充分：展示影响范围（人数、金额）、关键参数、用到的口径定义；
- 限额：单次操作的数量和金额上限，超过需要更高级别审批；
- 口径约束：关键业务概念必须使用语义层的标准定义，Agent 不能自己发明；
- 先预演：批量操作先输出名单和统计，人确认后再执行，或者先小比例执行；
- 可撤销：尽量设计可撤回的操作（比如券可以作废）；
- 监控告警：异常的操作量、金额实时告警。
复盘
按事故复盘：时间线、影响、根因（找系统和流程问题，而不是只说「AI 错了」）、改进项。