你越聪明，就越难管——这是养娃的真理，也是养 coding agent 的真理。
Bytes 第 525 期（9 月 29 日）的主线，正好戳中这个痛点：当 agent 越来越能干，怎么保证它不去干那些你不允许它干的事？
现在的做法：让 agent「自己判自己」先说个可能让你有点意外的事实：目前主流的做法，是让模型自己判断自己该不该做某件危险的事。
Claude Code 的 auto mode、Codex 的 auto-review，以及其他 agent，都会把那些「有点可疑」的工具调用，交给第二个模型去裁决，觉得安全了才继续。
OpenAI 说 Codex 的 auto-review 在合成评测里拦住了 99.3% 的提示注入——听起来很棒，直到你想起两件事：第一，这个 benchmark 并不测量 agent 可能做的所有危险动作；第二，「这个 benchmark 到底测了啥」本身就存疑。
真正的问题：裁判「看不到」的东西比误判更麻烦的，是跨轮次的上下文。
Bytes 举了一个很具体的例子：你的 agent 先读了一份带真实客户邮箱的 bug report，三轮之后，它把那个邮箱贴进了一个公开的 GitHub issue——而每一次调用单看都没问题。第二个模型当裁判，天然只能看到「这一次调用」，看不到「这串行为累积起来的风险」。
这就是本期主线想解决的问题。
OpenAPPA：用「代数」给 agent 上儿童锁主角是 OpenAPPA——一个开源的、确定性（deterministic）的护栏。名字里那串缩写很有意思：Agentic Permissions Policy Algebra，也就是「agent 权限策略代数」。
作者说「代数」这词听着挺性感，但真正关键是「确定性」：它的核心策略引擎不是一个模型，所以没法被提示注入。它在每个动作之前，只回答一个问题：
> 这份数据，允许去这个目的地吗？
具体靠三个机制：
一、安全标签（Security labels）。 每个 session 都会被打上标签，记录「谁有权看它的数据」以及「这份数据有多可信」。读一个私有 repo 会收窄受众范围，读一个随机网页会拉低信任分。而且——一旦 session 变得更受限，就再也不会放松回来。 这一条很关键，它堵住了「先污染、后洗白」的路径。
二、工具契约（Tool contracts）。 给每个工具声明规则，OpenAPPA 在每次调用前检查、调用后更新。
三、补救计划（Remedy plans）。 当一次调用被拦下时，agent 会拿到一份机器可读的「出路」清单——比如「把 PII 脱敏」，或者「让人类批准这一次特定的调用」。做 OpenAPPA 的 Archestra 说，这正是他们的 agent 还能完成约 90% 任务的原因，而其他确定性护栏只能做到约 37%。
一句话总结：给 agent 上儿童锁的秘诀，可能真的就是代数。
这对你意味着什么一，「让模型审模型」是概率性的，不是保证。 99.3% 听起来很高，但安全这件事，差的那 0.7% 往往就是事故。尤其在提示注入这种「攻击面无限」的场景下，用一个可被注入的模型去防注入，逻辑上就别扭。
二，确定性的权限层会重新回到视野。 当 agent 被授予越来越多的工具和权限，「这份数据能不能去这个目的地」这种可判定的问题，值得用一个不靠概率的引擎来回答。
三，「信任标签 + 只收不放」是个好模型。 一旦数据流被污染（比如读了一个不可信网页），就永久收窄它的去向——这个思路，其实和人做数据分级、做权限最小化是一脉相承的。
四，给 agent 留「出路」能大幅提升完成率。 被拦下不等于失败——如果能把「被拦」变成「换一种方式完成」（脱敏、找人类批准），agent 的可用性就从 37% 跳到 90%。这个设计细节，做 agent 产品的人值得抄。

来源：bytes.dev/archives/525