生产级 AI Agent 审批与审计之争

随着 AI Agent 进入生产环境，围绕“谁来批准、在哪批准、事后怎么查”的工程问题迅速浮出水面。多位作者把焦点放在发送邮件、调用 API、修改数据库、退款或转账这类会产生真实副作用的动作上，认为传统的人类确认按钮或聊天通知已不足以承担风险控制。讨论之所以值得关注，在于这直接关系到 Agent 能否安全落地，以及故障发生后能否追溯责任与决策依据。

审批为何会失灵

AiGentsy 认为，一旦 Agent 能执行真实动作，简单的提示词确认或 Slack 通知很容易被模型绕过，也可能让人类在信息不足时机械批准。因此他主张把审批拆成三层：先由确定性规则完成策略判断，再决定是否通知人类，随后进入执行与校验层。DisastrousLie6698 则从一线落地角度追问，各类 agent framework 自带的权限模型是否足够，还是最终仍要依赖自定义中间件与人工介入。

授权放哪层与如何留痕

Nice-Foundation-9264 把问题推进到架构层，讨论“允许/拒绝”应放在规划器、工具层、编排层，还是 IAM、OPA、Cedar 一类独立策略层；他最关心的是，几个月后团队还能否准确还原某个生产动作当时为何被放行。围绕这一痛点，percoAi 和 petergyang 都指出，仅记录 policy version 过于模糊，审计真正需要的是命中的具体规则、当时的输入和系统状态。petergyang 因而建议把审批工件做成可回放的 policy fingerprint。FunkyChicken22 结合 world-model-mcp 相关实践补充说，只有记忆和规则执行还不够，编程智能体还需要时间序知识图谱、约束执行层，以及可验证的决策历史，才能补上真实项目中的审计缺口。

2026-07-17 ~ 2026-07-18 · 6 条相关

一手来源