用编译器约束 Agent 的操作权限

Agent 能从文件里找到一个 API token，不代表它就该拥有这个 token 背后的全部权限。Staal 想解决的，正是任务范围与实际权限脱节的问题：让执行代码必须持有受限凭证，再由编译器和运行时共同守住边界。

作者的结论是，模型犯错很难避免，但错误能造成多大损失，可以由程序约束。这套设计值得看，尤其适合正在给 Agent 接入退款、消息发送和业务记录操作的团队。不过，作者给出的实验还不足以证明它适合所有项目。

权限应该跟着任务走，而不是跟着账号走

原文用一起数据库删除事故切入：据作者引用的材料，2026 年 4 月 24 日，一个维护 PocketOS 测试环境的 AI 编程 Agent，遇到凭证不匹配后搜索文件系统，找到了原本用于管理自定义域名的 token。由于它拥有 root 范围权限，一次 API 调用就在九秒内删除了生产卷，连同卷内备份一起消失。

这里要区分两件事：模型为什么决定删除，以及系统为什么允许它删除。Staal 聚焦后者。原文还引用了当年 7 月通过公开 GitHub issue 诱导工作流泄露私有仓库数据的案例，以及 Gravitee 对 750 家组织的调查。这些材料用于说明权限过大的风险，但原文没有展开调查方法，不能据此推导具体发生概率。

Staal 采用能力安全（capability security）：给程序一份不可伪造、用途有限的操作凭证。函数签名直接写出它能做什么：

• cap sms.send(uses: 50, only: ["234*"])，最多尝试发送 50 次，只能操作匹配尼日利亚号码前缀的目标。
• cap fs.write(only: ["/reports/*"])，只能写入指定路径范围。
• cap building.lock.open(uses: 2, only: ["north-door", "loading-bay"])，累计最多开门两次。
• cap payments.refund(max: 500 USD, each: 50 USD)，单笔最多退 50 USD，整次运行累计最多退 500 USD。

only 限定目标，支持精确文本或带一个 * 的模式；uses 限定尝试次数；each 和 max 分别限定单笔与累计金额。sms.send 等路径由部署者定义，并非语言内置服务。

代码拿到的是完成任务所需的有限权力，而不是一个账号的全部权限。

谁能授权，为什么函数不能自己加权限

能力只能由启动程序的宿主应用创建。宿主仍然可以使用 Python 或 Node.js，因为客户等级、订单金额和业务归属，原本就在应用里。

下面这段代码把退款权限收紧到当前订单，并按照客户等级计算单笔上限：

import staal

lib = staal.Library()
TIER_LIMIT = {"gold": 500, "standard": 50}  # 每笔退款的美元上限，由应用决定

def handle(customer, order, complaint, model):
    limit = min(TIER_LIMIT[customer["tier"]], order["total"])
    return lib.run("refund.staal", {
        "entry": "main",
        "inputs": {"complaint": complaint},
        "grants": {"pay": {"cap": "payments.refund",
                            "each": {"amount": str(limit), "currency": "USD"},
                            "only": [order["payment_id"]]}},
        "model": model,
    })

重点看 only：授权绑定的是当前订单的 payment_id。如果程序声明单笔最多 500 USD，宿主误授予 800 USD，实际仍受 500 USD 限制；宿主也可以进一步收紧。

缺失授权或出现未知配置字段，会在运行前阻止启动。能力、回执和结果对象，也不能作为输入在任意嵌套层级传入。模型输出一段形似授权的数据，不能获得真正的权限。

能力可以传给下游函数，但只能缩小。原文的短信例子中，remind 接收 List<Patient, 50> 和最多使用 50 次的能力，再给每次 notify 调用一份 uses: 1 的子能力。子能力的消耗会一路累计到父能力和最初授权，拆函数不会重置额度。

反向扩大权限会被 staalc check 拦住：从 1 次扩大到 100 次得到 error[E003]；没有能力却调用 files.write，得到 error[E002]。扩大 max、each、uses，删除限制，或者把 only 扩到原范围之外，都属于禁止操作。原文也说明，模式包含关系的判断刻意采用保守策略。

编译器管声明，运行时管每一次行动

编译器能检查代码是否索取了超出持有范围的权限，但实际发了几条短信、花了多少钱，还要运行时记账。

Staal 把能力保存在 broker 中，程序只持有句柄。每次操作真正调用服务前，broker 都检查当前能力及其整条父能力链。

作者给短信程序授予两次使用额度，输入四位患者，其中第三位是英国号码，最终返回 2。日志如下：

action_performed  sms.send 2348012345678
action_performed  sms.send 2348098765432
action_refused    'sms.send' may only act on ["234*"]; this action targets "447700900123"
action_refused    'sms.send' has used all 2 of its allowed uses

要看最后两行：第三次请求触发代码声明的号码限制，第四次触发宿主授予的次数限制，两次都没有到达短信服务。

计数规则也很关键。broker 批准操作时就消耗一次额度，外部服务失败不会返还，因此重试不能绕过限制；金额或目标无法确定时拒绝执行；失败请求如果可能已经转移资金，仍计入金额消耗。

模型则完全拿不到能力。propose 分开接收可信的 instruct 和不可信的 data，输出先成为 Proposed，经过 validate 按类型 T 检查后，才有机会进入后续操作。把用户工单当指令会触发 error[E006]，应放入 data: [...]；原文也允许将来源标记为 @trusted，但信任判断仍由开发者负责。把能力传给模型会触发 error[E101]。示例还用 budget(calls: 1, tokens: 500) 约束模型调用预算。

类型验证并不等于内容可信。HTTP 响应、工具结果和模型输出，即使通过验证，仍是不可信数据。提示注入可能改变模型提出的请求，但请求还要经过权限检查。

真实服务的密钥和网络权限放在能力库内。例如 termii.sms 声明依赖 net.http.post、Secret、服务地址和发送方，业务程序只申请 cap termii.sms.send(uses: 50)。宿主把 HTTP 权限限制到一个端点，通过环境变量名提供密钥。号码先由库规范化，再匹配 only，避免 +234 801 234 5678 与 2348012345678 被当成不同目标。Secret 不能打印、插值或编码；作者一次记录请求头的修改，就因 json 不能编码含秘密的 Header 而触发 error[E101]。

我的判断

我认可它把权限约束放进函数签名、并由统一 broker 累计消耗的方向。代码审查时能直接看到操作上限，重构时也不用依赖每个开发者记得维护同一个计数器。

作者确实做了对照：用纯 Python 和 Python 加 Staal 实现相同客服 Agent，设置相同限制、权限、重试与崩溃恢复机制。两者都通过了 47 个场景，覆盖提示注入、畸形输出、权限升级、服务失败，以及外部调用前后杀进程。代码量分别为 312 行和 159 行。

随后作者分别做了六处修改，具体展开的是退款计数问题：Python 重构时每步新建策略对象，悄悄重置计数；Staal 把能力传给辅助函数，第二笔退款仍被原始授权拦住。

这个例子能支持「集中维护权限边界有助于抵抗重构失误」，却不能证明普通语言必然守不住。Python 或 Node.js 也可以通过统一执行网关、共享计数和受限服务凭证实现类似机制。原文没有给出运行耗时、吞吐量、接入成本的对照，因此不能把代码行数优势当成整体效率优势。

边界同样有前提：宿主必须正确授权，能力库必须正确识别目标和金额，产生外部影响的操作必须经过这条执行路径。Staal 能约束授权怎样被使用，无法替业务决定一笔退款究竟该不该退。

能拿来做什么

• 给 Node.js Agent 接退款或消息服务前，先把目标、次数、单笔额度和累计额度写清楚，再决定是否采用 Staal。这些限制应来自订单和客户上下文。
• 审查现有工具执行层时，重点检查重试、辅助函数和子任务是否共享同一份额度，以及外部请求失败后如何计数。
• 将用户输入放在模型的数据通道，保留可信指令边界；对模型结果做类型验证后，继续检查操作权限和业务条件。
• 评估 Staal 时，可以先挑一个会产生外部影响的小流程试接。原文给出的安装命令是 pip install staal 和 npm install @staal/node，支持 Linux 的 x86_64、arm64，以及 macOS 的 Apple Silicon、Intel；许可证为 Apache-2.0 with the LLVM exception。验收应覆盖超额、越界、失败重试和崩溃恢复。