为什么你的 AI 代理需要黑盒

Source: Dev.to

请提供您希望翻译的完整文本内容，我将为您翻译成简体中文，并保持原有的格式、Markdown 语法以及技术术语不变。

介绍

我的 AI 代理失控了。

我经营一家电子商务店铺。几个月前，我部署了 AI 代理来处理客户邮件——退货、退款请求、产品咨询。起初运行得很好，直到它们不再正常。代理开始做出我们无法兑现的承诺：错误的退款金额、未授权的折扣、完全捏造的政策。“当然，我们会为您退款运费，即使我们的政策说不是这样。” “是的，您可以在 90 天后退回该商品。” 这些都不是真的。

最糟糕的不是它们的失误——那是可以修复的。最糟糕的是 我无法证明它们到底说了什么。当客户对 AI 的回复提出争议时，我一无所有。日志分散在三个不同的服务中，可变且不完整。我没有审计追踪，没有问责机制，也没有证据。

没有人谈论的鸿沟

当我寻找解决方案时，发现了大量可观测性工具——Langfuse、Helicone、LangSmith。它们在展示发生了什么方面非常出色。

但我需要证明发生了什么。

• 可观测性回答：“代理做了什么？”
• 可追溯性回答：“代理做了什么，并且你能证明它事后没有被篡改吗？”

在一个受监管的世界——欧盟 AI 法案部分生效，科罗拉多 AI 法案将在 2026 年 6 月生效，德克萨斯 TRAIGA 已经上线，SEC 正在将 AI 治理列为 2026 年的重点——这种区别至关重要。部署 AI 代理执行关键任务（批准贷款、处理投诉、撰写医疗摘要、处理交易）的公司将需要对其 AI 所说所做的内容拥有防篡改记录。不是普通日志，而是证据。

我构建的内容

我构建了 AIR——用于 AI 代理的开源黑盒。

就像飞机上的飞行记录仪，AIR 捕获你的 AI 代理所做的每一次决策、交互和工具调用。不同于分散的日志，AIR 创建 加密链（HMAC‑SHA256），以证明记录事后未被篡改。修改任意一条记录，整个链就会断裂。

快速开始（Python）

# python
from openai import OpenAI
import air

client = air.air_wrap(OpenAI())
response = client.chat.completions.create(...)
# Every call is now recorded with a tamper‑evident audit trail

每个提示、完成、工具调用以及模型决策都会被捕获——具备加密完整性——并存储在你的基础设施上，永不离开你的控制。

实际解决的问题

• 客户争议： 一份签名、带时间戳的完整对话记录——加密证明，而非可编辑的日志文件。
• 监管请求： AIR 自动生成符合 SOC 2、ISO 27001 和欧盟 AI 法案要求的合规报告（预映射 22 项控制项）。
• 脚本外行为： 确定性回放让你能够在隔离环境中精确重现任何 AI 决策的发生过程，以便调试。
• 模型或提示的更改： 使用相同输入进行前后对比，证明更改未引入新的失效模式。

生态系统

AIR 是一个跨越 19 个开源仓库的完整问责栈：

• air-blackbox-gateway – OpenAI 兼容的反向代理，捕获每一次 LLM 调用
• air-sdk-python – Python SDK，封装 OpenAI、LangChain 和 CrewAI
• agent-policy-engine – 分层风险自治：策略、紧急停止开关、信任评分
• eval-harness – 重放情节、评分结果、检测回归
• mcp-policy-gateway – 通过 MCP 对 AI 代理工具访问的防火墙

Python SDK 已在 PyPI 上发布：

pip install air-blackbox-sdk

在浏览器中尝试 interactive demo ——观察代理运行，检查审计链，篡改记录，并看到链路中断。

为什么现在

90 % 的企业在日常运营中使用 AI，但只有 18 % 拥有治理框架。对大多数公司而言，这些工具尚未出现，但很快就会成为必需：

• EU AI 法案执行 对高风险系统的监管将于 2026 年 8 月开始
• 科罗拉多 AI 法案 将于 2026 年 6 月生效
• 德克萨斯 TRAIGA 已上线（自 2026 年 1 月起生效）

如果您正在构建影响真实用户的 AI 代理，您需要现在就考虑问责，而不是等到出现首个客户争议或监管调查后才考虑。

AIR 是开源且免费使用的。困难的部分已经完成——代码是真实的，SDK 已上线，演示可运行。

GitHub:

Jason Shotwell 构建电子商务工具，并且在他的代理失控时，显然也在构建 AI 基础设施。