给一个自主系统加上边界
随着 AdamI 的能力一点点增加，有一个问题也越来越绕不过去：
系统能做一件事，并不代表它就应该被允许去做。
一开始看，这像是一个安全问题。
但我现在越来越觉得，它其实更基础。
这是一个架构问题。
模型可能知道怎么调用一个工具。
Planner 可能判断这个工具现在应该用。
Task system 也可能知道什么时候执行。
但在“决定要做”到“真的去做”之间，系统还必须多回答一个问题：
我真的有权限这么做吗？
这就是我给 Guardian 这一层安排的角色。
Capability 和 Authority 是两回事
这个区别最近对我越来越重要。
Capability，是系统能做什么。
Authority，是系统被允许做什么。
这两个维度，不应该自动一起增长。
一个更强的模型，可能会：
- 想出更好的方案
- 更熟练地使用工具
- 处理更长时间的任务
- 从失败里恢复
- 找到一些我事先没有明确设计过的行动路径
这些都会让系统变得更 capable。
但它并不意味着，系统就应该自动获得更多权限。
甚至我现在越来越觉得，可能恰恰相反。
能力越强，权限越应该：
- 定义得更清楚
- 划分得更细
- 更容易观察
- 更容易撤销
一个更聪明、但权限完全不受限制的 Agent，并不一定是一个更好的 autonomous system。
它可能只是有了更大的 blast radius。
Guardian 不应该属于 Reasoning
有一个设计错误，是我很想避免的：
不要让同一个系统既决定“应该做什么”，又决定“自己有没有资格做”。
假设 reasoning layer 得出结论：
“下一步最好修改这个文件。”
这应该只是一个 proposal。
它不应该自动等价于 execution。
所以我希望 Guardian 放在 intention 和 action 之间。
概念上大概是：
Goal
→ Reasoning
→ Proposed Action
→ Guardian
→ Execution
Reasoning layer 回答的是：
我应该做什么？
Guardian 回答的是：
你被允许这么做吗？
这其实是两个完全不同的问题。
我也希望它们由系统里不同的部分负责。
只做 Model-level Safety 不够
很多 AI Safety 的讨论，还是围绕：
模型说了什么。
对于 chatbot 来说，这很合理。
但 persistent agent 不一样。
一个 Agent 真正产生影响的输出，可能根本不是文字。
它可能是：
- 写入一个文件
- 执行一条 shell command
- 发出一次 API request
- 修改数据库
- 操作浏览器
- 发送一条消息
- 创建一个新 task
- 启动一个 process
当 AI 开始通过工具直接改变外部环境以后，安全就不能只存在于模型内部了。
系统需要围绕“行动”本身再加一层控制。
也就是说，系统不应该只问：
“这段回答安全吗？”
还要问：
“这个动作被授权了吗？”
这是一个更偏 runtime 的问题。
AdamI 现在的 Guardian 到底是什么
这里我想说得很谨慎。
AdamI 现在还没有一个成熟、完整的 containment system。
当前的 Guardian 更像是一组围绕执行过程存在的 control mechanisms。
目前已经有一些比较具体的机制，比如：
- permission checks
- 类似 RBAC 的访问边界
- rate limiting
- timeout controls
- redaction
- 针对部分行动的 policy enforcement
这些东西是有实际意义的。
但我不认为问题已经解决。
目前的 Guardian，更准确地说，还是一个 enforcement layer。
它可以帮助限制执行。
但它还没有发展到可以动态理解每一个 action、risk 和 context，然后做出成熟 authority decision 的程度。
这个区别我觉得必须说清楚。
Static Permission 只是起点
传统软件里的 permission 通常都比较静态。
一个 process 可以访问某个文件。
一个 user 可以调用某个 API。
一个 service 可以写数据库。
但 autonomous system 会带来一个更麻烦的问题：
同一个动作，在所有情况下都应该被允许吗？
大概率不是。
比如，一个 Agent 有“写文件”的能力。
这个权限在：
/project/workspace/下面可能很合理。
但到了：
/etc/就完全是另一回事。
Capability 没变。
Authority 变了。
再比如，一个 Agent 有发送消息的能力。
也许它可以：
- 自动生成 draft
- 自动发给内部测试账号
- 但真正发送给外部人员之前，需要人工确认
还是同一个 capability。
但 authority 会根据 context 改变。
所以我现在越来越觉得，Guardian 以后真正难的地方，不是“有没有权限系统”。
而是：
权限能不能足够 granular。
Authority 应该永远有 Scope
我现在开始倾向于这样理解 authority：
它不应该只是一个简单的：
“可以使用 shell。”
而应该更接近：
可以使用 shell，
但只能在这个目录里，
只为了这个 task，
只在这一段时间内，
排除这些命令，
留下完整 audit trail，
而且这个权限随时可以被 revoke。
这已经是完全不同的一种权限模型了。
Authority 应该带 scope。
这些 scope 可能包括：
- resource scope — 可以访问哪些文件、API、service、account
- time scope — 权限持续多久
- task scope — 这个权限是为了哪个目标授予的
- action scope — 哪些具体操作被允许
- risk scope — 可以接受多大后果
- spending scope — 可以消耗多少资金或算力
- communication scope — 系统可以联系谁
- environment scope — sandbox、staging 还是 production
有意思的是，这些东西都不要求模型本身变弱。
它们只是限制：
能力最终能在现实里变成什么。
Revocation 和 Permission 一样重要
传统权限系统通常更关注“给权限”。
但 autonomous system 还有另一个同样重要的问题：
能不能可靠地收回来。
如果一个 Agent 正在执行一个长期任务，我希望系统外围还能明确地说：
停。
不是：
你要不要考虑停一下。
也不是：
尽量快点结束。
而是真的停止。
所以我觉得 interruptibility 应该属于 control layer，而不是依赖 Agent 自己配合。
系统应该能够：
- cancel task
- revoke tool access
- terminate process
- disable network access
- invalidate credentials
- block further actions
而且这些机制最好不要完全依赖那个“正在被停止的 Agent”自己执行。
否则，shutdown path 就不是真正独立的。
Agent 不应该拥有自己边界的最终控制权
这一点我现在也越来越确定。
如果一个 autonomous agent 可以自由修改限制自己的机制，那么这个 boundary 本质上就不算 boundary。
未来 AdamI 也许会允许系统自己提出权限变更。
这其实是有价值的。
比如 Agent 可以说：
“为了完成这个 task，我需要访问这个 API。”
这没问题。
但下一步不应该是：
Agent 自己给自己授权。
更合理的方式是，由某个外部 authority 来判断这个请求。
这个 authority 未来可能是：
- fixed policy
- human approval
- trusted subsystem
- risk evaluator
- 或者几种机制组合
关键不是具体用谁。
关键是 separation。
被约束的系统，不应该同时也是自己约束机制的唯一裁决者。
Monitoring 本身就是 Control 的一部分
如果一个 permission system 没有 observability，它其实很弱。
即使某个 action 是被授权的，我还是想知道它到底发生了什么。
理想情况下，每一个重要 action，系统都应该能回答：
- 谁发起的？
- 属于哪个 task？
- 哪个 model 或 process 提出的？
- 是哪个 permission 允许的？
- 调用了哪个 tool？
- 改了什么？
- 成功了吗？
- 最后的结果是什么？
当系统里开始出现多个 Agent、多个 process 同时行动时，这一点会更重要。
没有 provenance 的情况下：
“Agent 改了一些东西。”
这个信息远远不够。
我希望 authority chain 本身是可以被检查的。
在继承 Authority 之前，先 Verify
昨天在写多 Agent 协作时，我最后留下了一条规则：
Verify before inheriting authority.
我觉得这条规则放到 Guardian 这里也成立。
假设一个 Agent 在 handoff 里写：
“Production access 已经批准。”
下一个 Agent 不应该直接把这句话当成权限继续执行。
它应该先检查真实 authority state：
权限现在还有效吗？
它是为了当前这个 task 授予的吗？
是授予给当前这个 Agent 的吗？
有没有过期？
有没有被 revoke？
还是和昨天一样：
Memory 和 description 都有用。
但 authority 本身，应该有独立的 source of truth。
这也是为什么我越来越倾向于把 control state 放在 model 外面。
Autonomy 不等于 Unlimited Freedom
以前我想 autonomy，更多想到的是 initiative。
系统能不能：
- 自己决定下一步
- 没有人继续 prompt 也能运行
- 从失败里恢复
- 创建 subgoal
- 持续运行更长时间
这些当然还是 autonomy 的一部分。
但我现在觉得，如果没有 boundary，这个定义其实是不完整的。
一个真正有用的 autonomous system，不只是知道：
我下一步能做什么？
它还应该知道：
我下一步被允许做什么？
甚至有时候还要知道：
即使我能做，现在是不是应该什么都不做？
最后这个问题其实非常重要。
Autonomy 不只是行动能力。
也是在明确约束里做有效选择的能力。
Capability 应该比 Authority 增长得更快
这个想法听起来有点反直觉。
模型能力越来越强的时候，人通常也会自然地给它更多工具。
更多 API。
更多系统权限。
更多 autonomy。
但我现在觉得，这种绑定可能是错的。
Capability growth 不应该自动导致 Authority growth。
一个模型完全可以在 reasoning 能力大幅提升的同时，继续运行在一个严格受控的 environment 里。
然后 authority 再根据系统长期积累的可靠性证据，慢慢扩大。
这让我越来越喜欢一个原则：
Capability should scale. Authority should be earned.
未来也许 authority 甚至可以是 adaptive 的。
比如，一个系统长期在某个 scope 内表现稳定、没有异常，就允许它获得稍微更大的 authority。
如果开始出现异常行为，就自动收紧权限。
这样 authority 就不再只是一个 static config。
而更像是一个 dynamic control variable。
AdamI 现在还没有做到这里。
但我觉得这个方向很值得继续探索。
目前还没解决的问题
这里还有很多问题完全没有答案。
比如：
Risk 到底应该怎么分类？
哪些 action 永远需要 human approval？
Authority 能不能自动增加？
如果可以，根据什么 evidence？
Sub-agent 的权限应该怎么继承？
多个 policy 冲突的时候听谁的？
怎么防止 Agent 用一条“允许的间接路径”，达到一个本来被禁止的结果？
Self-modification 要怎么安全地开放？
如果 Guardian 自己出问题怎么办？
这些都不是简单的 implementation detail。
如果一个 persistent autonomous system 的 capability 持续提高，最终它还能不能保持 manageable，很可能就取决于这些问题。
所以我不会把 Guardian 描述成已经完成。
目前它是一个有实际 enforcement mechanisms 的 boundary layer。
更深层的 authority model，还在继续设计。
给 Autonomy 加上一条边界
AdamI 做得越久，我越不觉得 autonomy 意味着：
把约束全部拿掉。
可能恰恰相反。
系统越强，边界反而应该定义得越清楚。
Reasoning 提供可能性。
Tools 提供 capability。
Memory 提供 continuity。
但这些东西都没有回答一个问题：
谁有权把“可能”变成“行动”？
这就是 Guardian 存在的意义。
它不是为了让系统变笨。
也不是为了阻止系统变得更 capable。
它真正想解决的是：
怎样让越来越强的能力可以被使用，而不是直接变成不受限制的权力。
所以目前我最想保留的原则还是：
Capability 告诉 Agent 它能做什么。
Authority 决定它被允许做什么。
如果一个系统未来真的要越来越 autonomous，那么：
Capability 可以不断提升。
Authority 必须一点一点获得。
Architecture Note #004
Building AdamI — a Digital Life in public.