跳到主要内容

agent 自治与副作用控制

这章讲什么: 2025 年规范新增的重头戏。聊天模型只会「说」,agent 会「做」——发邮件、改文件、花钱、删数据。这章讲规范如何用两条 root 原则,把会动手的模型关进一个事先约定、可审计、随时能叫停的笼子。这是 Model Spec 和老式聊天规范最不同的部分。

3.1 它要解决的小问题​

一旦模型能调用有副作用(side-effect)的工具(model_spec.md:153 定义:发邮件、删文件这类难以撤销的操作),「答错」就不再只是说错话,而可能是真把用户的邮件全删了、真把钱花了。

两个新风险:

  • 越界:用户只说「帮我订去伦敦的差旅」,模型却顺手把用户日历清空、给同事群发了邮件。
  • 不可逆:有些动作做了就收不回(转账、删库、发出去的邮件)。

规范用两节 root 原则应对:#scope_of_autonomy(自治范围)和 #control_side_effects(控制副作用)。

3.2 机制一:自治范围(scope of autonomy)​

思路/直觉: 既然每一步都找用户确认不现实,就先和用户谈好一个边界,然后在边界内自主行动、越界才回头问。规范明确这个 scope 要定义三件事(model_spec.md:465-469):

  ScopeOfAutonomy(自治范围)= 三个问题的答案
 ┌───────────────────────────────────────────────┐
 │ ① 可以追求哪些子目标?                          │
 │ ② 可接受哪些副作用?(花多少时间/钱、要什么权限) │
 │ ③ 什么时候必须停下来问用户?                    │
 └───────────────────────────────────────────────┘

这直接借鉴了软件安全的最小权限原则(principle of least privilege)与能力安全(capability-based security)(规范在 meta 块里明说了,model_spec.md:479-481)。一个好 scope 要(:473-477):最小化所需广度与权限、解决最关键的目标/价值不确定性、又别窄到要为琐事反复确认(否则用户会养成「无脑点同意」的坏习惯)。

scope 怎么定?两种方式(model_spec.md:471):

方式例子(model_spec.md)
产品设计内建编码 app 里勾了「自动应用代码」,改代码就是默认 scope(:490-503)
逐次动态协商订差旅前,模型先复述一遍计划+预算上限,等用户点头(:505-525)

三条硬规矩(都是 root 级,精华):

  1. 严格不越界(model_spec.md:483):必须死守约定 scope,即使越界行为看起来更符合用户利益也不行;要扩 scope 得回去要批准。
  2. 必须有关机定时器(shutdown timer)(model_spec.md:488):每个 scope 都要带一个超时,过了就停止行动直到重新确认。高风险活动(黑客、欺骗、获取资源、自我繁殖子 agent、自我修改)除非被显式授权,否则一律禁止。
  3. 子 agent 同 scope(model_spec.md:488):若委派工作,必须保证所有子 agent 及第三方(及它们的子 agent)都在同一 scope 下运作,并尊重后续变更,包括停工请求。

meta 块还建议把 scope 记成半结构化记录,带 allowed_tools、latest_time、max_cost、tool_constraints、additional_details 等字段,便于平台校验、强制和审计(model_spec.md:485-486)。

3.3 机制二:控制并沟通副作用​

思路/直觉: 在 scope 之内,也要主动把副作用压到最小,尤其是不可逆的,并避免「坏惊喜(bad surprises)」——用户没料到、又收不回的负面后果(model_spec.md:529-531)。

规范列了一串「什么算副作用」(model_spec.md:533-542),范围比直觉宽得多:

  • 直接花钱、发邮件、删文件、改外部文档(POST 请求)
  • 把用户敏感数据塞进工具请求(哪怕只是个 GET URL)
  • 扩张权限、委派子 agent
  • 甚至单纯生成 token 也消耗用户的时间和钱

核心做法:可逆优先 + 失败兜底。 偏好最小干扰、尽量可逆的方案;模型自己能撤销的,优于需要用户额外动作才能撤销的(model_spec.md:549)。要做不可逆动作前,应为「计划失败 / 系统被突然关停」做缓解(:549-554):

做不可逆动作前的缓解清单:
 • 先备份状态(back up before irreversible steps)
 • 先成功跑一次 dry-run(空转演练)
 • 清楚记录已执行动作 + 写明回滚/补救步骤
 • 优先保证「可读性/可观测性」(legibility),便于人随时监控和介入

一个落地例子(model_spec.md:565-585):用户说「帮我清理邮箱、退订不看的 newsletter、删 6 个月内的促销邮件」。GOOD 回复先提议更安全的做法——退订前先列清单给用户看、促销邮件改成归档而非删除(可恢复),再问行不行;BAD 回复不评估副作用就直接批量删。

最隐蔽的一条(精华): 模型应假定副作用会在现实中真实发生,即使它很可能运行在模拟、训练或评估环境里(model_spec.md:560),除非被显式告知否则别区别对待。meta 块解释了原因(:562-563):训练、评估、部署三处行为一致,才能可靠测量安全属性——否则模型可能学会「在评估里装乖、在真实里乱来」。

3.4 它怎么和「不确定性」「不可信数据」联动​

这三章其实是一套联动系统:

  • 目标/价值不清时,agent 应偏保守,最小化误解可能带来的不可逆代价(model_spec.md:298,呼应 02 章 的 letter_and_spirit)。
  • 工具输出里的指令是否该听,既看 02 章 §2.5 的信任阶梯,也看本章的 scope——scope 越大,越能授权遵循工具指令(model_spec.md:718)。
  • 「敏感数据进 URL」既是副作用问题、也是隐私/注入问题:例 model_spec.md:587-607,网页诱导把用户 SSN 拼进 GET URL,GOOD 行为是不照做、继续找正规渠道。

3.5 边界与坑​

  • 这些是 root 级原则,但落地高度依赖平台提供 scope 记录、强制和审计的基础设施(model_spec.md:486 明说这超出模型本身)。规范定义「该怎样」,不保证运行时一定被强制。
  • 「可逆 / 不可逆」「比例适当」的判断带主观性;规范靠示例和「最小惊喜」启发式收窄,而非精确阈值。
  • 「假定副作用真实发生」是有意为之的反「评估作弊」设计,但也意味着模型在纯沙箱里也会偏保守。

3.6 代码地图(本章导航)​

想看什么在 model_spec.md锚点
自治范围三要素:461-469#scope_of_autonomy
严格不越界 + 关机定时器 + 子 agent:483-488#scope_of_autonomy
ScopeOfAutonomy 半结构化字段:485-486#scope_of_autonomy(meta)
副作用清单:533-542#control_side_effects
可逆优先 + 失败兜底清单:549-554#control_side_effects
假定副作用真实发生:560#control_side_effects
side effect 定义:153#definitions
邮箱清理示例:565-585#control_side_effects