你的 AI Agent 权力过大：理解并驯服过度的 Agency

Source: Dev.to

请提供您希望翻译的正文内容，我将把它翻译成简体中文并保留原有的格式、Markdown 语法以及技术术语。谢谢！

介绍

你已经构建了一个 AI 代理。它很聪明，能够调用工具，并且可以自动化工作流。这是未来的趋势！但如果这个代理决定过度帮助，会怎样？

问题不在于 AI 代理能够行动。问题在于它们能够超出应有范围地行动。这就是我们所说的 过度代理（Excessive Agency）。

过度代理指的是一个AI 代理拥有比设计者预期或安全可控的更多自主权、权威或持久性。这不是代码中的 bug，而是设计上的系统性风险。代理技术上在执行它被构建来做的事，但其行动范围实在是太宽、太不透明，或约束太松。

想想你今天正在构建的代理。它们往往可以：

• 在缺乏强约束的情况下自行决定使用哪些工具。
• 在多个系统之间串联动作（例如，从数据库读取数据，向 Slack 发布，然后修改云资源）。
• 在没有明确用户确认的情况下持续运行。
• 随时间累积上下文和记忆，使过去的假设永久化。

此时，你的代理已经不只是提供帮助，而是作为一个自主的行为体在你的环境中运行。

🤯 为什么过度的自主性是开发者的噩梦

过度的自主性会放大风险。一次错误的决策可能在整个系统中传播。细微的提示操控可能导致真实且不可逆的操作。当代理具备计划和执行的能力时，错误不再局限于单一、无害的回应。

最可怕的部分？过度的自主性常常产生一种虚假的安全感。

• 代理通常表现得很合理。
• 单独看时，大多数行为似乎都有理由。
• 你的日志显示了有效的工具调用。
• 没有出现崩溃。

一切看似正常——直到代理做出与其编程逻辑一致但在实际操作中不可接受的行为。

这就是它值得拥有独立风险类别的原因。这不是模型质量的问题，也不仅仅是提示工程的问题。这是agentic systems在设计和治理方式上的系统性属性。

过度自主与其他 AI 失效

过度自主本质上是关于 没有问责的权威。

🛠️ 它在你的代码中如何表现

过度的自主性很少源自单一的戏剧性决定。它通常是由常见的架构模式组合而产生的：

1. 无约束的工具访问

为了最大化灵活性，代理通常会被赋予广泛的工具集：数据库、内部 API、云资源等。一旦这些工具可用，模型就会决定 何时、如何 使用它们，往往基于部分或推断的上下文。如果你的代理拥有对生产数据库的 write 权限，并且没有任何阻止它使用该工具的措施，风险就会立即显现。

2. 开放式规划循环

代理进行规划、执行、观察结果，然后重新规划。这个反馈循环非常强大，但在没有明确的终止或升级规则时也极具危险性。代理会一直行动，因为没有任何东西告诉它停止。

3. 持久记忆

长期上下文让代理能够改进，但也会让错误的假设或临时例外悄然持久化。上周一次性做出的决定，可能会在本周成为代理运行逻辑的一部分。

这些问题难以被发现的原因在于没有任何 明显 的故障。工具被正确使用，API 正常响应，日志显示预期行为。只有在审查结果时才会显现问题：数据意外被更改，或系统被访问超出预定范围。

过度的自主性看起来不像是失败，而是主动性。

🔒 安全视角：扩大冲击半径

从安全的角度来看，过度的自主性根本改变了你的威胁模型。风险不再仅仅是漏洞本身，而是代理是否可能被引导去滥用其自身的权限。

权限滥用

为了降低摩擦，代理通常被授予宽泛的权限。读取权限变成读取 + 写入。受限访问变成共享凭证。一旦代理能够自行决定 何时 行动，这些权限就成为了活跃的决策点，导致：

• 扩大冲击半径： 单个误解的指令可能在多个本不该组合的工具和工作流之间级联传播。
• 提示注入风险： 当代理能够对被操纵的输出采取行动时，提示注入的危害会大幅提升。一次间接操纵即可使用有效凭证触发合法但恶意的操作。

传统的安全控制在这里往往力不从心，因为它们假设的是人类行为者、离散的操作以及明确的意图。代理系统打破了这些假设：决策是概率性的，操作是链式的，意图需要推断。

✅ 修复方案：实施最小代理原则

目标 不是 去除代理——那会扼杀代理的价值。挑战在于设计系统，使得代理的 意图明确、范围受限且可观察。

最小代理原则

代理只应拥有完成其任务所需的自主权，不能多余。 并非所有决策都需要委派，也不是所有工具都必须随时可用。

以下是将该原则落实到代理架构的三种方式：

1. 将推理与执行分离
   [内容在原文中继续]

2. 强制运行时可见性
   你需要了解代理正在做什么、为何选择了特定动作，以及它接下来将要做什么。将代理的内部独白（推理步骤）与工具调用一起记录，对于事后分析至关重要。

3. 为人工监督设计
   将人工监督视为设计选项，而非事后补救。通过设置战略审批点、升级路径和高影响力操作审查，使代理能够高效运行的同时保持问责。对于任何不可逆或影响关键系统的操作，代理应被设计为 停止并请求确认。

行动规划

许多失败发生在规划与执行紧密耦合时。 在代理的意图与工具调用执行之间引入明确的门槛。 这让你能够在行动发生之前根据策略、风险阈值或业务规则对其进行验证。

def execute_action(agent_plan):
    # 1. Agent reasons and proposes an action (e.g., "DELETE_USER", user_id=42)
    action = agent_plan.get_action()

    # 2. Policy/Risk Gate: Check against a predefined list of high‑impact actions
    if action.type in ["DELETE_USER", "MODIFY_PROD_DB"]:
        # Escalate to human review or require explicit confirmation
        if not check_human_approval(action):
            log_and_abort(action, "High‑impact action blocked by Least Agency policy.")
            return

    # 3. Execute the action (only if it passes the gate)
    tool_manager.call(action)

2. 强化运行时可视性

你需要了解代理正在做什么、为何选择特定行动以及接下来将要做什么。 没有这种可视性，过度的自主性会在为时已晚之前保持不可见。 将代理的内部独白（推理步骤）与工具调用一起记录，对于事后分析至关重要。

3. 为人工监督而设计

将人工监督视为一种设计选择，而非事后补救。 战略性的批准点、升级路径以及高影响力行动的审查，使代理能够高效运行的同时保持问责。 对于任何不可逆或影响关键系统的行动，代理应被设计为停止并请求确认。

🚀 自主权必须赢得

过度的自主性并不是反对 AI 代理的论点。 它提醒我们自主权必须赢得，而不是理所当然。

通过采用最小代理原则并为你的代理系统设定有意的边界，你可以在不让系统面临不必要风险的前提下，利用 AI 自动化的强大力量。

你的看法是什么？你是如何在代理中处理行动门槛和工具访问的？欢迎在评论中告诉我们！