真正在跑的是什么
下面每个机制都带一个徽章,徽章本身就是主张的一部分 · Macheng Shen × agent · 2026-09-07
本节提到的每一个机制都带两种徽章之一,徽章是主张的一部分,不是脚注。running(在跑)意味着有代码在强制执行这个机制,而且能指名强制执行点在哪——哪个文件、哪个函数、哪一步检查在动作发生前先跑一遍。specified(已规定)意味着有一份书面设计、一个 schema、一条 agent 被要求遵守的规则——但没有公开代码强制执行它,或者存在的代码没有强制执行这一部分。第三个限定词 private(私有)标注一个机制:它确实在跑,只是跑在本 fleet 之外任何人都读不到的仓库里。
把这条摆在列出任何"能用"之前的原因是:一份描述某项控制的文档,和一套真正在跑这项控制的系统,不是同一件事;把二者当成可以互换,正是本节从头到尾要指名的那个失败本身。本页立于 theory/agent-safety-stewardship.md 已发布的不变式之下——它不重述那些不变式,而是审计它们今天究竟成立到什么程度。
主张与代码分歧的地方
一次对本项目自己公开仓库的审计——就在写这页的同一天跑的——找出了三处文档与代码各说各话的地方,而且它该放在这里、放在最前面,而不是放进一条更正脚注里。
architecture-v1 里的 Safety Charter 写明六项硬机制:memory provenance(记忆溯源)、write-protected memories(写保护记忆)、untrusted-content quarantine tagging(不可信内容隔离标记)、带敏感联系人门的 outbound audit(出站审计)、一个 kill switch,以及给已沉淀安全标志的反传播 TTL。它配套的公开实现 reference-impl,机制二到六一项都没实现。机制一它其实也没实现,而且是从两头都没实现:章程说 provenance 块不完整的写入会被拒绝,而代码里 provenance 是一个可选字段,创建时根本没有这项检查;随后 update 接口又会覆写章程声明为 write-once(只写一次)的同一个字段。所以代码不只是没做到章程——在它看上去唯一碰过的那一条上,它两头都与章程相反。
starshard-communication 里的通信 spec,把一个带签名的 authority envelope(授权信封)当成头号安全原语来展示。而那个本该演示它的示例文件,在自己的注释里写着——"DESIGNED, not implemented."(已设计,未实现。)
agent-continuity-demo 在 GitHub 上那一行简介宣称有四个协作原语(coordination primitives)。它自己的 README 明明白白否认了其中三个;这个仓库真正证明的是两个。
这些都不是外部审阅者挑出来的,而是拿仓库去对照它们自己声明的主张查出来的——这恰恰是本页要求读者对下面每一条都套用的那把标准。诱人的做法是悄悄把 README 改干净,再发一页干净的、讲验证的文章——那会是同一种失败往后退一步:一个主张之所以过了关,是因为没人拿它去对照真正在跑的东西检查过。这里选的是另一条路:把差距报出来,文档按它自己的节奏另行修,把徽章规则收紧到——如果从第一天就这么执行,本该在第一天就抓住这个问题。
公开代码里在跑的东西
下面这些是 running,不是 specified——直接从每个仓库的源码里读出来的,不是从文档里推断的。每一行都点名它防的是哪类失败,以及强制执行实际落在哪个文件里。
| 机制 | 防的是 | 位置 |
|---|---|---|
| 仅限 owner 的出站白名单 | 后台 agent 在没有人类介入的情况下给第三方发邮件 | agent-mail-stack — bin/fire-and-forget-deliver |
| 落盘而不外泄(spool-don't-leak) | 带着邀请 token 的消息正文,泄漏进其他 agent 能读到的存储 | agent-mail-stack — bin/zhizi-mail |
| 发布前 release gate | 把凭证或私人身份信息发布到公开面 | selfhost-chat — verify/release_gate.py, verify/scrub_check.py |
| 结构性回归检查 | 未来一次改动悄悄开出新的出站点或新的 PII 读取路径 | selfhost-chat — open-signup/verify/no_outbound_check.py, pii_check.py |
| 租户隔离,机器测试过 | 跨租户泄漏、一个可探测会话是否存在的 oracle、不花钱就能白嫖的探测 | selfhost-chat — open-signup/verify/test_isolation.py |
| 信念冲突隔离(belief-conflict quarantine) | agent 进程之间静默互相覆写彼此的信念 | agent-continuity-demo — hub.py |
| 协作记录形状(shared fact、work claim、receipt、conflict signal) | 跨运行时的信念冲突、重复劳动、缺失审计线索——仅对配合的调用方有效 | fleet-coordination-protocol — fcp/hub.py, SPEC.md |
| 假阴性监控 | 重要消息被静默过滤,且没有任何东西显示发生过过滤 | starshard-communication — reference-impl/monitor.py |
协作协议自己的 spec 值得直接引用,因为它做了一件比交付一项功能更少见的事:写明了自己的边界。SPEC.md 说这个协议不提供权限强制执行、不提供经过认证的 principal、没有 absorbing cancellation(吸收式取消)、没有 retry budget、没有独立验证者、也没有 exactly-once 语义。一份把自己不做什么和自己做什么并排写清楚的 spec,并不比一份对自己的缺口保持沉默的 spec 更弱——它是唯一一种读者真能据以行动的 spec。这正是本页通篇在主张的那种行为,而且是被它自己的一个研究对象亲手示范出来的。
私有 fleet 里在跑的东西
以下这些今天都在跑,只是代码不公开。整张表诚实的徽章是 private。状态用的是一套比 running/specified 更细的词汇,因为这里大多数工作不是二元的:enforcing(强制,会拦)、shadow(影子,只分类记录,不拦)、advisory(建议,只提醒)、partial(部分,已建成但没接到所有地方)。
| 机制 | 防的是 | 状态 |
|---|---|---|
| 签名 authority envelope(可运行实现) | Confused deputy / 靠转发洗出权限——sub-agent 分不清"owner 真这么说的"和"我的调用方声称 owner 这么说的" | 对 provenance 是 enforcing;有据可查的局限——这只是 provenance,不是安全边界。公开的部分只有 schema,而且只是 specified。 |
| Action ledger + 双票守护动作 | 验证绑定在代码路径而不是动作本身上——新入口继承不到任何检查 | 对被包住的动作是 enforcing,外加一个独立的、fail-open 的旁路检测器持续在跑 |
| Work-claim gate | 两个 session 抢着做同一个不可逆动作 | enforcing,协调存储不可达时 fail-closed——仅限 bright-line 动作 |
| Approval gate | 未经审查的破坏性 / 花钱 / 身份 / 外发类动作 | shadow——今天只分类记录,不拦任何东西 |
| Blocker-verification gate | "在等 owner"这类从没被真正测过的说法 | 对机械判据是 enforcing;对一条更松的 prose-matching 支路只是 advisory,因为发现它会在否定句上误触发 |
| Delegation-bound gate | 派出去的 sub-agent 没有 deadline、没有调用上限、没有部分汇报契约 | advisory,fail-open —— 而且这一条是公开的,所以它是 running 而不是 private;它自己的 docstring 就写明它从不拦截 |
| 每次动作前重新校验(合成输入) | 一个只在多分钟序列开头验一次、就假定整段都成立的前置条件 | partial——针对一个正在冲突的前台 app 自测过,但截至审计当天,在其它输入注入工具里调用方是零 |
| 跨 provider 回执账本 | 自报成功——进程还活着不是完成的证据 | enforcing;只要它的判定还是 unreconciled(未对账),就没有 agent 可以对外说任务做完了 |
| 送达 vs 触达记账 | 把消息发出去了,就当成它已经到了 | enforcing——成功发送本身从不计入"已触达" |
| 注意力预算 | 警报淹没系统里唯一稀缺的资源 | enforcing,靠 hook 实现 |
| 模型路由下限 | 把每个角色默认派到最贵档位造成的成本爆炸 | enforcing,派发前拦截,每条路由决定都记录在案 |
| 平台自动化黑名单 | 一条只写在某个 skill 文字说明里的规则,对从没加载过那个 skill 的工作流形同不存在 | 对启动时会读它的四个工具是 enforcing |
| 实时往返 canary | 一个依赖在 --version 和 status 上一直报健康,而每次真调用都失败 | enforcing,是在它得名的那次事故之后加上的 |
| Context 压力与规则重复提醒 | Context 耗尽;owner 反复讲过的规则,因为活在可检索记忆里而不是常驻加载的底座里而衰减 | advisory,fail-open |
覆盖率数字
2026-09-07 跑的一次审计,把每一个(工具,入口)对都拿去对照本该覆盖它的每一道 gate 数了一遍。163 对完全没有 gate 覆盖。这条仍标记为未结,见 roadmap 页面。
同一次审计还发现了一件比这个原始数字更具体、也更有用的事。既有的外发 gate,匹配的是一份 helper 二进制文件白名单——其中好几个在跑它的机器上早就不存在了——而今天真正在发邮件的那些工具,压根就没被加进那份名单。一个 fail-safe-allow(默认拒绝、显式放行)的设计,就这样悄悄退化成了 always-allow(始终放行),因为白名单不再跟踪现实,而且没有任何东西察觉到这个漂移。
普遍的教训不是"再加几道 gate"。而是:绑定在某条代码路径上的验证,能存活的时间恰好等于那条代码路径还是通往那个动作的唯一路径。一个新入口——一个新工具、一个新二进制、一处改写过的调用点——能抵达同一项能力,却继承不到任何检查,因为那个检查从来就没绑在动作本身上。它绑的是通往动作的一条路。
反复出现的那条规则
有一个设计选择在这张表里反复出现,值得单独说一句:仅在动作不可逆时 fail-closed;其余一律 fail-open。Work-claim gate 是最干净的例子——它的协调存储不可达时会硬拦,但只针对 bright-line 动作。其余情况,它让路。
理由不是对系统其余部分抱有乐观。而是:一道会拦住日常工作的 gate,会被它惹恼的那个人悄悄移除——在赶 deadline 的压力下,事后比一个写明的 fail-open 默认值难审计得多。一项能扛住一个被惹恼的操作者的控制,比一项纸面上更严格、实际上会被删掉的控制更值钱。而且这也不是巧合——它正是本页开篇那条徽章规则的形状:老老实实说清楚什么真的在跑,老老实实说清楚什么没在跑,让差距保持可见,而不是被悄悄抹掉。