AI Agents 正在做出无人能审计的决策
Source: Dev.to
没有人想谈论的问题
AI 代理现在无处不在。它们在调用 API、查询数据库、执行代码，在某些情况下甚至会自行花费真实金钱——全部都是自动完成的。用于构建它们的框架令人惊叹。CrewAI、LangChain、AutoGen、OpenAI 的 Agents SDK——它们让你轻松搭建一个能够完成实际工作的代理。
但这些框架都没有给你的东西：对代理实际行为的可视化。
- 没有审计日志。
- 没有紧急停止开关。
- 发生错误后无法回放过程。
- 在危险操作执行前没有策略强制执行。
- 没有个人信息脱敏——每个提示和完成结果都会直接发送到你的可观测性后端，客户数据、API 密钥以及内部信息完整无缺。
我接触的每个团队处理方式各不相同。大多数根本没有处理。
为什么这是基础设施问题，而不是应用程序问题
想想 TLS。没有人在每个微服务中都以不同的方式实现 TLS。它是一个标准化的层，位于应用代码之下，负责为其上层的所有内容提供加密。
代理安全也需要以同样的方式工作。
如果每个团队都自行构建日志、自己的终止开关、自己的策略检查——就会出现不一致、漏洞，以及导致上文 50,000 次请求事故的“以后再处理”做法。
安全层需要具备：
- 框架无关 – 无论你使用 CrewAI、LangChain、AutoGen，还是自定义方案，都能工作
- 基础设施级 – 在网络路径和遥测管道中运行，而不是在代理代码内部
- 标准化 – 使用 OpenTelemetry，这样就能接入你已有的可观测性栈
我构建的内容
我一直在开发一个开源项目，名为 AIR Blackbox —— 可以把它想象成 AI 代理的飞行记录仪。它位于你的代理和 LLM 提供商之间，捕获所有交互。
架构
Your Agent ──→ Gateway ──→ Policy Engine ──→ LLM Provider
│ │
▼ ▼
OTel Collector Kill Switches
│ Trust Scoring
▼ Risk Tiers
Episode Store
Jaeger · Prometheus只需一行修改——替换你的 base_url——所有代理调用即会通过它。无需更改 SDK，也不需要代码重构。
组件
- Gateway – 用 Go 编写的兼容 OpenAI 的反向代理。它拦截所有 LLM 流量，生成结构化的 OpenTelemetry 跟踪，并在转发请求前检查策略。任何兼容 OpenAI 的客户端均可直接使用，无需修改。
- Policy Engine – 实时根据 YAML 定义的策略评估请求。支持风险等级（低、中、高、关键）、信任评分、可编程的紧急停止开关，以及针对高风险操作的人机交互门控。治理在操作 之前 完成。
- OTel Collector – 为
gen_ai遥测定制的处理器。提供基于哈希和预览的 PII 脱敏（48 字符预览 + 哈希）、成本指标以及循环检测，能够捕获类似 50,000 次请求的异常情况。 - Episode Store – 将单个跟踪聚合为任务级别的“剧集”，便于回放。当出现问题时，你可以像倒带磁带一样回放整个剧集，而不是在原始日志中逐条查找。
我没预料到的部分
当我开始构建这个项目时，我以为最大的难题会是技术架构。事实并非如此。OpenTelemetry 为你提供了坚实的基础。Go 在代理方面表现出色。实际的底层实现反而是相对直接的部分。
真正的难题在于说服人们在事故发生之前就认识到他们需要它。
我接触的每个团队都会以某种形式说：“我们已经很小心了。” “我们的代理很简单。” “我们以后再加监控。”
随后却会出现生产事故、泄露的 API 密钥，或是审计员提出的无人准备的问题。
在受监管行业（如医疗、金融等）部署代理的公司已经知道，他们必须能够回答以下问题：
- “我们能证明我们的代理做了什么吗？”
- “我们能立即将其关闭吗？”
- “我们能保证个人身份信息（PII）不会泄露到我们的追踪后端吗？”
ISO 27001 审计员和 SOC 2 审核员已经开始提出这些问题。仅将日志记录到 CloudWatch 已经不够。
接下来
AIR Blackbox 完全在 Apache 2.0 许可证下开源。它跨越 21 个仓库，且完全模块化——你可以使用整个堆栈，也可以只使用所需的部分。
- 支持 CrewAI、LangChain、AutoGen 和 OpenAI Agents SDK 的信任插件。
- 五分钟快速入门即可在本地使用
make up运行完整堆栈。
如果你在生产环境中部署 AI 代理——或计划这样做——我真诚地期待你的反馈。你看到哪些不足？有什么让你夜不能寐？
GitHub:
README 中有交互式演示，若你想在不安装任何东西的情况下进行探索。
我构建 AIR Blackbox 是因为我认为代理安全不应在第一次事故后才被事后加上。它应该是基础设施——平凡、可靠，并在第 50,001 次请求尝试触发时已经在运行。