← 返回信息流

dev.to #ai新闻

为AI代理操作构建审计追踪

dev.to作者:sekera-radim教程产品AI评分:50/100

本文介绍如何为AI代理的操作构建审计追踪,无需自建日志层。通过将副作用操作路由到审批门,自动记录每次操作的完整生命周期,包括创建、规则应用、批准/拒绝、执行等,并记录决策者身份(如Slack用户名),支持查询和导出,满足合规审查需求。

当智能体自行发送邮件或发布内容时,“它做了什么、谁批准的”需要真实的答案——以下是如何在不自建日志层的情况下,为AI智能体行为构建审计追踪。

事后才出现的问题

没人会在出事之前要求审计追踪。他们总是在事后才问:客户说从未批准过退款邮件,同事想知道为什么一篇博客文章在凌晨2点发布,或者合规审查需要证明每一个智能体发起的行为背后都有一个具名的人。如果唯一的记录是零散的应用日志——或者更糟,什么都没有——那就没有好的答案。

智能体行为的审计追踪要真正站得住脚,需要满足三件事:必须将提案与决策分开记录,必须知道是谁做的决定(而不只是有人做了决定),并且必须具有足够的防篡改性,确保没人能在事后悄悄修改历史记录。

仅通过使用闸门就能自动记录的内容

如果你的智能体已经将产生副作用的行为路由到审批闸门,那么审计追踪就是该闸门的副产品,而不是需要单独构建的东西。通过Impri推送的每个行为都会以追加写入的方式记录其完整生命周期——已创建、已应用规则、已批准或已拒绝、已过期、已执行或已失败——事后没有任何途径可以编辑或删除单条记录。完整模式参见audit-log。

对问责制最关键的部分:通过聊天审批渠道做出的决定会记录一个人类可读的操作者,而不仅仅是一个密钥ID。

渠道操作者值示例
REST API调用API密钥的ID
Web收件箱调用API密钥的ID
Slack按钮radim (Slack)
Discord按钮Radim (Discord)
Telegram按钮@radim (Telegram)

这就是“某个API调用批准了此事”和“Radim于14:32从Slack批准了此事”之间的区别——后者才能在真正的事故审查中站得住脚。

查询特定行为的追踪记录

给定一个action_id,将审计查询过滤到该行为的生命周期:

import fetch from "node-fetch";

async function getActionHistory(actionId: string) {
  const res = await fetch(
    `https://api.impri.dev/v1/audit?entity_id=${actionId}`,
    { headers: { Authorization: `Bearer ${process.env.IMPRI_API_KEY}` } }
  );
  const { items } = await res.json();
  return items; // 按最新优先排序:created, rule_applied, approved/rejected, executed
}

const history = await getActionHistory("act_8f2b1c");
for (const row of history) {
  console.log(`${new Date(row.created_at * 1000).toISOString()}  ${row.event}  actor=${row.actor ?? "system"}`);
}

一个智能体发起的邮件的典型结果:

2026-07-29T09:12:04Z  action.created       actor=key_prod_agent
2026-07-29T09:12:04Z  action.rule_applied  actor=null
2026-07-29T09:14:51Z  action.approved      actor=radim (Slack)
2026-07-29T09:15:02Z  action.executed      actor=null

这是一个智能体行为的完整有序记录——由哪个密钥提出、匹配了哪条规则、由哪个具名的人批准、并确认已执行——而智能体本身不需要任何自定义日志代码。GET /v1/audit需要管理员权限,并且始终限定在已认证密钥所属的项目范围内,因此一个项目的历史记录不会泄漏到另一个项目的查询结果中。

为合规审查导出数据

对于定期审查而非单次事件,GET /v1/audit/export会将完整的过滤后历史记录以NDJSON或CSV格式流式输出,而不是通过查询端点分页获取:

curl -s "https://api.impri.dev/v1/audit/export?since=1719792000&format=csv" \
  -H "Authorization: Bearer $IMPRI_API_KEY" \
  -o agent-actions-q3.csv

该接口每个密钥限速5次/分钟——它是为定期拉取设计的,不适合循环轮询。如果你需要为合规框架设置按请求的保留期限(例如“保留180天,不超过”),那是实例上的AUDIT_RETENTION_DAYS设置,而不是导出调用本身能控制的。

这不会给你什么

审计追踪记录的是行为发生了以及谁做的决定——它不评估决定是否正确。如果一个人批准了一篇糟糕的草稿,该批准会被如实记录;Impri不会质疑人类审核者的判断,它也不是内容审核系统。它还只覆盖真正经过闸门的行为:如果你的智能体有一条通往同一服务的旁路(一个可以直接调用的原始API密钥,而不是通过包装后的执行器),那条路径在这里不会留下任何记录。追踪记录的完整性取决于瓶颈是否真正存在——参见SDK集成中关于包装执行器的部分,确保不存在第二条路径。

获取密钥并推送你的第一个行为

如果你还没有接入push/poll/execute模式,How to Add Human Approval to an AI Agent完整介绍了这三个调用,quickstart则引导你在云端或自托管环境中获取API密钥。

阅读原文