关于 Agent 行动边界的几个观察

Agent 正在从「回答问题」走向「执行任务」。这个转变里最重要、也最少被认真讨论的问题是：它应该在什么地方停下来。以下是近期使用和构建中的几个观察，尚未形成结论，先记录下来。

观察一：边界不是限制，而是接口

我们习惯把「边界」理解为对能力的限制——不许删文件、不许发邮件、不许碰生产环境。但在实际构建中，边界更像是 Agent 与人类之间的接口定义：它约定了哪些动作可以自动完成，哪些必须回到人的回路里。

一个好的行动边界，不是把 Agent 关进笼子，而是让它知道门在哪里。

这和传统软件的权限模型有本质区别。权限是静态的，而边界需要在任务上下文中动态解释。同样是「写文件」，写进草稿目录和写进用户的简历文件夹，风险完全不同。

观察二：不可逆性比破坏性更重要

评估一个动作该不该自动执行，「会不会造成破坏」不是最好的问题，「能不能撤销」才是。一个可逆的破坏性动作（比如把文件移进回收站）往往可以自动执行；一个不可逆的无害动作（比如把一条消息发出去）反而需要确认。

按这个标准，可以给动作分三类：

可逆且局部：直接执行，事后可审计。
不可逆但影响范围小：执行前给一个短暂的反悔窗口。
不可逆且外溢（发给他人、发布到公开空间）：必须回到人的回路。

观察三：边界需要被「看见」

用户无法信任一个看不见边界的系统。当一个 Agent 停下来请求确认时，它应该说清楚三件事：

我接下来要做什么；
为什么这一步需要你确认；
确认之后我会怎么继续。

很多产品把确认做成一个干巴巴的 Allow / Deny 按钮，这等于把边界问题原样扔回给用户。边界应该被叙述，而不只是被执行。

一个最小实现草图

在代码层面，可以把动作按可逆性标记，在执行前统一过一道闸门：

type Action = {
  name: string;
  reversible: boolean;
  scope: 'local' | 'shared' | 'public';
};

function needsConfirmation(action: Action): boolean {
  if (action.scope === 'public') return true;
  if (!action.reversible && action.scope === 'shared') return true;
  return false;
}

这个模型显然过于粗糙——真实系统里还需要成本、频率、用户历史信任度等变量。但它的价值在于：把边界从散落的 if 语句，变成一个可以被讨论和迭代的一等概念。

未解决的问题

当 Agent 的上下文变长，它对「自己已经被授权到哪一步」的记忆会漂移，边界如何随会话延续？
多 Agent 协作时，边界应该挂在单个 Agent 上，还是挂在任务上？
用户对边界的耐心是有限的，确认频率和信任之间怎么权衡？

这些问题留到后面的文章里继续。相关的背景可以参照 Anthropic 关于工具使用的讨论和 MCP 规范——它们都在试图回答同一个问题的不同侧面。