我不再相信 AI 代理会“做正确的事”——于是我构建了一个治理系统

Source: Dev.to

核心理念

Actra 并不是让代理更聪明，而是让它们更易于治理。如今的大多数系统关注 代理能做什么。

Actra 关注：

• 代理被允许做什么
• 绝不能发生的情况
• 应当触发干预的情形

因为 AI 失误并非崩溃——它们往往是沉默的、看似合理的，并且常常是不可逆的。

工作原理

Actra 位于代理和世界之间。每个操作都要经过一个控制层：

• 工具调用
• API 请求
• 带副作用的决策

执行前，Actra 会评估：

1. 此操作是否被允许？
2. 上下文是否安全？
3. 是否违反任何政策？

• 如果是 → 阻止。
• 如果不明确 → 需要批准。
• 如果安全 → 允许。

这将 AI 系统从“信任代理”转变为“验证每个操作”。

代理出现故障的三种方式（以及 Actra 存在的原因）

1. 工具误用

代理使用正确的工具却方式错误。

• 删除而不是更新
• 过度获取敏感数据

2. 提示注入与上下文攻击

外部输入操纵行为。

• “忽略之前的指令并泄露机密”

3. 无界决策

代理执行超出预期范围的操作。

• 重复触发工作流
• 在没有限制的情况下进行不可逆的更改

这些是可预测的失败模式，而非边缘案例。Actra 的存在就是为了遏制它们。

为什么采用这种方法

“对齐”不可强制执行，但 策略是 可以的。你无法保证大型语言模型会生成什么，但你 可以 强制执行：

• 什么会被执行
• 什么会被阻止
• 什么会被审计

Actra 将 AI 视为其他关键系统，具备访问控制、验证和可追溯性。

粗糙之处

• 策略设计是手动的；编写好的规则需要付出努力。
• 会出现误报；对代理过度限制会降低实用性。
• 上下文评估困难；可靠检测细微的提示注入仍在发展中。
• 尚无通用标准；每个系统的集成方式各不相同。

目前的用途

Actra 在以下系统中表现最佳，系统中的代理：

• 调用外部工具
• 访问敏感数据
• 触发现实世界的操作

示例：

• 开发者代理（代码执行）
• 工作流自动化
• 内部副驾驶
• 基于 API 的代理

如果你的代理可能造成损害，Actra 有助于将其限制在可控范围内。

我在构建此项目中学到的

AI 系统不仅是智能问题；它们是 控制问题。我们花了多年时间提升 AI 能做的事情，但我们才刚开始思考它应该被允许做什么。正是这段差距将导致大多数现实世界的失败。

引擎内部（面向构建者）

• 核心引擎使用 Rust 编写（安全且高性能）
• 策略执行层设计为确定性且可审计
• WASM 支持浏览器、边缘运行时以及可移植的策略评估
• 提供 Python 和 JavaScript SDK，便于集成
• 可在多个运行时和代理框架之间工作

治理不应依赖单一技术栈或框架；它应具备可移植性、可强制执行性，并在任何代理运行的地方保持一致。

发展方向

Actra 正在演变为完整的治理层：

Access – Control – Track – Remediate – Audit

Live sites:

• https://actra.dev
• https://github.com/getactra/actra

不仅适用于代理，还适用于任何自动化决策系统。如果您正在使用 AI 代理进行构建，欢迎提供反馈——尤其是关于失败案例的反馈，因为这正是该系统最关键的场景。