AI Agent 的决策盲区：谁来决定什么可以打破

当 AI Agent 从实验室走向生产环境，一个被低估的难题浮出水面：它不知道什么可以破坏。

Dev.to 上的 Daily Context 栏目最近发表了一篇文章《Agents Can't Decide What's Okay to Break》，由 Jonathan Gottfried 撰写，直指自主 Agent 的核心困境——在执行任务时，哪些操作是可以接受的妥协，哪些是绝对不可触碰的底线？

这篇文章获得了 22 个表情反应和 4 条评论，说明这个问题正在引发开发者社区的共鸣。Jonathan Gottfried 也是 Major League Hacking 的联合创始人，长期关注开发者工具和 AI 工作流。

Agent 为什么分不清"可接受的破坏"

软件工程中存在大量灰色地带。重命名测试文件、删除临时缓存、重置本地数据库——这些操作在开发环境中完全正常，但在生产环境可能是灾难性的。

人类工程师通过上下文、团队约定和风险直觉来判断边界。但 Agent 缺乏这种判断力。它们可以精确执行指令，却无法理解"这一步是否会破坏某些重要的东西"。

问题的根源在于：Agent 的操作空间是平坦的。所有 API 调用在它眼里具有同等的权重，它没有"这个接口很危险"的先验知识，也没有"上次类似的改动导致了事故"的经验记忆。

**操作空间平坦性（flat action space）**是理解 Agent 风险感知缺失的关键框架。在强化学习中，Agent 通过状态-动作-奖励的循环学习策略，但大语言模型驱动的 Agent 通常不具备这种在线学习能力。它面对的是一个未经加权的 API 或工具列表，每个函数调用在向量空间中具有相似的表示强度，模型不会因为某个接口的副作用更大而赋予其更高的"注意力"或"犹豫权重"。这类似于一个没有痛觉的机器人：它可以精确地移动手臂，却无法区分碰到的是棉花还是玻璃。弥补方式通常是外部注入先验——在系统提示中显式标注危险等级、在工具描述中写入约束条件，或通过检索历史事故案例来构造上下文中的"经验记忆"。但这些仍然属于人类知识的注入，而非 Agent 自主习得。

人类仍在定义边界

原文中的核心共识是：这一步仍然需要大量人类努力来实现。

这意味着当前的解决方案不是让 Agent 自己学会判断，而是由人类提前划定安全边界。常见的做法包括：

权限分层：将 Agent 的操作权限按风险等级划分，只读操作自由执行，写操作需要审批，破坏性操作直接禁止。

环境隔离：让 Agent 只在沙箱或预发布环境中运行，确认结果后再由人类决定是否推到生产环境。

操作白名单：与其告诉 Agent 不能做什么，不如列出它可以做什么。白名单模式虽然限制了灵活性，但大幅降低了风险。

这些方案本质上都是人类的判断力在替 Agent 做决策。Agent 负责执行效率，人类负责风险控制。

权限分层在工程上通常对应 OAuth 的 scope 机制、Kubernetes 的 RBAC 角色以及云服务的 IAM 策略。以 IAM 为例，可以定义只允许 s3:GetObject 的只读角色，以及包含 s3:DeleteObject 的高风险角色，并将 Agent 绑定到前者。环境隔离则依赖容器化与网络分段：Docker 或 Firecracker 提供进程级沙箱，Terraform 的 plan/apply 两步执行让人类在 apply 前审查变更集。操作白名单在 Agent 工具设计中常表现为"tool allowlist"——只向模型暴露经过审计的函数集合，而非整个 shell 或全部 API。这三类方案可以叠加使用，形成纵深防御。它们的共同前提是：人类在部署前完成风险分类，而分类的粒度越细，Agent 可安全自主执行的范围就越大。

这个问题的深层挑战

如果 Agent 无法自主判断"什么可以打破"，那它在多大程度上算是自主的？

这不是一个纯技术问题。它涉及责任归属——当 Agent 执行了一个破坏性操作，谁来承担后果？如果人类事先设定了规则，那责任在规则的制定者；如果规则本身有模糊地带，那 Agent 的"判断"就成了一种不可解释的随机行为。

从工程实践角度看，当前最务实的做法是接受这个限制。Agent 在明确边界内工作，超出边界时暂停并请求人类介入。这听起来不够"智能"，但它是目前唯一可靠的方式。

责任归属在现有法律与工程框架下仍缺乏清晰答案。若 Agent 造成数据丢失或服务中断，追责链条通常指向部署者，而非模型提供方或 Agent 本身。这使得"人类设定规则"不仅是技术选择，也是责任转移的手段。从可解释性角度看，Agent 在规则模糊地带的"判断"往往表现为概率采样，而非基于理解的推理。同一个边界场景，两次运行可能产生不同结果，这种不确定性在生产环境中比明确的失败更难排查。因此，将不可逆操作强制转为人类确认，本质上是用流程确定性替代模型不确定性，是当前阶段控制尾部风险的最低成本手段。

对开发者的实际启示

如果你正在构建或使用 AI Agent，这篇文章传递的信息很明确：不要假设 Agent 能理解什么可以妥协。

在设计 Agent 工作流时，把"不可逆操作"单独隔离出来，要求人类确认。这不是对 Agent 能力的不信任，而是对工程可靠性的基本尊重。

Agent 的自主性越高，人类需要提前定义的边界就越多。这个看似矛盾的关系，恰恰是当前 AI 工程化的真实写照。