跳到正文

Cambium

这是一套给 LLM 维护的知识语料用的治理标准,随它一起发布的还有执行这套标准的参考工具链。内核是规范层,按编号分成若干域;每个仓库只选一份档案,档案可以把一个扩展点填满或收紧,但永远关不掉内核的任何一条规则;三本账必须互相吻合;确定性的工具负责检查、写入与编译;而追加式回执决定一件工作在收尾之前必须具备哪些证据。

Screenshot of Cambium
编辑截图, 1 Oct 2026Cambium ↗

这是什么

Cambium 是一套治理标准,外加一套参考工具链,管的是维护知识语料这件事本身,而不是语料的内容。它分成三层。规范层是内核,按编号分成若干域,规则既写成给人读的正文,也写成给机器读的契约;每个仓库只选一份档案,档案可以填满或收紧某个扩展点,但永远不能把内核规则关掉。采纳是一次显式事务:把上游引用解析成完整的 commit SHA,作为唯一的 Standards 身份,任何一步失败都会恢复先前的控制面。运行时状态归采纳方所有,其中覆盖账、必需队列、进度账这三本账必须互相吻合,但彼此不能替代。再往下一层是确定性的工具,负责检查、写入与编译;每个写入器在给出 --apply 之前都只是 dry run,共享状态的写入只允许 integrator,回执是追加式 JSONL,一次结果不确定的追加会保留它的锁。README 最后点名它不做什么——不调度 agent、不认证身份、不保护整个工作区免受并发改动——理由是宿主不能为它证明不了的能力宣称证据。

谁做的仓库的 400 次提交里,379 次归在他的账号名下,用了三个不同的名字和三个不同的邮箱;十五次记在 claude 账号名下、三次记在 codex 名下、两次是另一个人,还有一次的邮箱地址被一对弯引号包住,于是 GitHub 干脆没把它关联到任何账号。95 次提交带共同作者尾注,其中 67 条写 Claude Opus 5、28 条写 Claude Fable 5。

它是怎么搭起来的

组成 · 6

这套模型是一个三项相加的式子,而仓库里几乎每一个决定都来自「别把这三项混在一起」。内核是规范层,写成正文加机器契约,于是一条规则既能被人读,也能被程序校验;它按编号划分的每个域各自拥有语义、不变量与扩展点,而编号是稳定身份,不是显示顺序。档案是一个仓库全部答案的唯一去处——范围、语言、架构、来源、优先级、角色与扫描配置——它可以把某个扩展点填满或收紧,但不能关掉内核规则。运行时状态归采纳方所有,而且刻意做成物理的而非抽象的:有一个模块被指定为当前路径拼写与对象分类的唯一机器所有者,于是 README 不再维护第二份目录契约。其上是确定性的工具层,边缘很薄、底下分组——每个工具一个公开命令,四个经过机器检查的领域放实现,命令行、MCP、元数据、宿主配置与各类目录则由声明编译成生成的投影,而不是手写维护。面向 agent 的那一面就是这些投影之一:每个工具自己的命令行声明,加上一份封闭的能力策略,一起编译成 MCP 工具集与按宿主区分的配置,覆盖 Claude Code、Codex、Kimi Code 与 dsh。推进工作的 runner 是被刻意限界的——它从当前状态推出唯一一个绑定身份的下一步动作,只调用已注册的能力,把结果读回来,并在每一个语义边界停下;它既不是调度器,也不是第二套策略引擎。还有两个习惯横穿整套东西:状态改动一律走 dry run,要求显式给出 --apply;长时工作由三本账跟踪,它们必须互相吻合,同时按 README 的说法,彼此「not interchangeable task lists」。

kernel/
规范层:从「K00 Standards Control」到「K13 Task Runtime and Execution Control」共十四个编号域,正文规则与 YAML、CUE、JSON 机器契约并排存放。K00 是控制类域里最大的一个,十九个文件;「K12 Quality Assurance」是全仓最大的域,三十四个文件、217 KB;K13 装着运行时状态模型。模块编号是稳定身份,模块搬走或退役之后不再回收。
Tools/
顶层 83 个文件,大多是以所执行操作命名的、很薄的公开命令;底下是四个经过机器检查的领域:governance 23 个文件 523 KB,knowledge 36 个文件 703 KB,execution 102 个文件 2,847 KB,platform 39 个文件 922 KB。再往下是 23 份 schema 模板、七份 YAML 策略(含一份 33 KB 的 agent 接口能力策略和一份 94 KB 的模块边界表),以及 380 个测试文件、3,241 KB。
Tools/compiled/
十个生成文件、合计 7.9 MB:317 KB 的命令行契约、120 KB 的 MCP 工具投影、56 KB 的元数据执行契约、1.45 MB 的工具目录、6.2 MB 的测试目录,外加 Claude Code、Codex、Kimi Code 与 dsh 四份宿主配置。它们是声明的投影,这正是同一套规则能同时喂给命令行、MCP 服务器和宿主配置、而不需要第二份手抄本的原因。
Card/ 与 Read Set/
十三对路线卡片,从 R01 Core Bootstrap 到 R13 Corpus Planning,合计 26 KB;每张卡片配一份 Read Set(合计 39 KB),声明这条路线必须加载哪些规范材料。它们是策展出来的、非权威的:卡片不够用或存在争议时,它的读回钩子会经配对 Read Set 解析到规范所有者。一份 60 字节的预算文件和一枚盖章工具负责让这套东西保持诚实。
profiles/
一份 165 字节的空候选模板、一份 18 KB 的访谈文档(驱动那场由 agent 协助的对话)、一份答案范式参考,以及两个明确不是默认值的实例:一个是给早先那个 Agent Systems Atlas 项目的 45 KB 档案,另一个是 19 KB 的规划示例,语料是自行车轮组的维护,覆盖账、缺口登记与全局地图一应俱全。
根目录文档与 .github/
一份 51 KB 的、按状态组织的路线图配 47 KB 中文译本,两份平行的 19 KB README,以及一份覆盖 issue 归属、缺陷升级与 pull request 契约的贡献指南。GitHub 目录里放着 387 字节的 pull request 模板、一份缺陷表单、一个把 issue 归属变成可检查项的脚本,还有两个工作流——12 KB 的 verify 流水线与 2.9 KB 的深度校验作业——由一个 39 KB 的影响面分析脚本驱动。

取舍,以及它替代了什么

  • 规范状态只能经由拥有它的写入器改动 替代 手工编辑状态文件

    README 把规则和理由写在一起:要用那个拥有它的写入器,好让修订、哈希、回执与恢复证据一起移动。一把残留的写入器锁被当作需要先对账的恢复证据,而不是直接删掉;一次结果不确定的追加会保留锁,而不是去猜回执落盘没有。

  • 只交付一份空的档案模板,外加明确声明为非权威的示例 替代 交付一份用户拿来就能直接选用的成品档案

    采纳意味着为一个仓库创建并批准一份档案,而复制模板或示例并不等于选定它。README 说示例只展示答案的形状,不得用来替代采纳方自己的档案;仓库是被刻意保持为未实例化的,因此不会生成任何编造出来的任务状态。

  • 拒绝复用一次成功的校验结果 替代 提供一个经过检查的视图缓存,并对同一批输入再叠一层哈希

    一次曾经通过的完整投影检查可能依赖组件指纹之外的解析器默认值,issue 说:去检查当前产物、或者对一组不完整的输入再加一层哈希,都不能确立等价。于是那个经过检查的视图缓存、Runner 装饰器、公开 API 声明,以及只针对缓存的断言,被一起退休。

  • 把渲染按能力拆开 替代 让解析、数学、图表与表格布局共用一条依赖浏览器的路径

    一次只做数学的检查会去探浏览器,不同义务会把同一个页面反复渲染,而初始化还可能悄悄选中操作者日常用的 Chrome。改动之后数学只走 Node,SVG 与布局按需拉取一个钉住版本的 Chromium,共享同一组渲染,并把证据依赖收窄到具体构造。

  • 在真正执行工作的那一层把重复劳动砍掉 替代 调高超时、砍掉 Python 3.14,或者把整条生命周期 mock 掉

    issue 把这三条都明确拒绝了。约 300 秒的目标与 360 秒的上限被保留下来,同时把重复的契约发现、注册表投影与证据消费归回它们各自的机器所有者;而超限必须判定为不达标,且不得把测量截断。

  • 把信任边界讲清楚,而不是宣称自己提供了保证 替代 把 SHA-256 绑定当成签名、把参与者标签当成经过认证的身份

    README 说这些绑定能发现漂移与历史不一致,但只在采纳方本地的信任域内成立,它们不是签名;参与者与审查者标签都没有经过认证;一个能同时改写仓库、工具与证据的人,可以构造出一段内部自洽的新历史。宿主可以增加能力,但不能为一项它证明不了的能力宣称证据。

依据完整的 README.md(18,930 字符)、kernel/ 各域与模块清单及其体积、横跨四个领域的 Tools/ 目录树连同 schema 模板与编译产物、Card/ 与 Read Set/、profiles/(含空模板与两个实例)、.github/,以及上文引用的各条 issue 与 pull request 正文。

制作过程

6 个阶段
  1. 01

    标准是从另一个项目整个搬过来的,而它一个 release 都没有

    仓库里最早的一次提交停在 2026-07-31,提交信息本身就是一份来源声明:「Baseline: Knowledge Base Standards v2.3 verbatim snapshot from Agent Systems Atlas」。仓库建于四天之后,也就是 2026-08-04——所以 Cambium 的起点不是一个空目录,而是一份从更早那个知识项目原样搬来的标准文档,两个示例档案里至今还有一个以那个项目命名。此后它跑得很急:六周 400 次提交,七月 13 次、八月 309 次、九月头十一天 78 次,最后落在合并第 224 号 pull request 上。这段时间里它没有产出过一个 release 或一个 tag,两个数字都是零。版本身份因此由别的东西承担:采纳事务把上游引用解析成完整的 Git commit SHA,并把它记成唯一的 Standards 身份;adopt_standards.py 把一件已经在跑的任务迁到已批准的修订上,而不重写它的生命周期历史;内核则规定模块编号是稳定身份,模块搬走或退役之后编号不再回收。本文读到的三十条 issue 与 pull request 从 195 号排到 224 号,编号本身就是这套回合的记录:奇数号是 issue,紧跟其后的偶数号就是关掉它的 pull request。三十条全部已关闭,周围是 478 个星、31 个 fork、12 个 watcher、四位贡献者和四条仍开着的 issue。

  2. 02

    哪一层归谁改

    有效治理被定义成一个加法——Cambium 内核,加上恰好一份选定的档案,加上采纳方自己持有的运行时状态——而这三个加数带着不同的权限。内核是规范层;档案可以把一个扩展点填满或收紧,但不能把内核规则关掉;工具执行已经声明的规则,但不做最终的语义判断。运行时命名空间归采纳方所有,README 把对应的禁令写得很直:不要手工编辑规范状态,要用那个拥有它的写入器,让修订、哈希、回执与恢复证据一起移动。共享状态的写入只允许 integrator,并且在工具要求的每一处都要给出当前的修订或哈希;而每一个写入器在出现 --apply 之前都只是 dry run。采纳这件事被刻意挡在 agent 之外:它始终是一次显式的命令行维护事务,它那个指向外部上游仓库的输入从不作为不受限制的 MCP 参数暴露出去。事务把选定的档案连同由此产生的契约与证据绑定在一起,把上游引用解析成完整 commit SHA,任何一步失败就恢复先前的控制面,并且从不对采纳方手上的上游材料重新盖章或改写。槽位的含义与合法值归内核和领域契约;TOML 编码、文件布局与呈现归工具;当别的消费者也需要某份领域契约时,现有的 YAML 仍然是唯一所有者,它的 CUE 投影是被生成、被校验出来的,而不是另写一份。同样的纪律一直伸到草稿:没回答的字段就继续空着,因为省略不等于同意关掉某个选项;而机器上的有效、用户的确认、以及采纳,始终是三件不同的事。

  3. 03

    一次改动的形状:一条 issue、一条 pull request,和几行测试数

    Cambium 用一套固定的形式来审自己的治理。本文引到的每一条 pull request 都先讲问题,再谈别的;样本里的小节标题是 Problem、Scope、Required behaviour、Evidence、Validation,改动按它触及的机器所有者分组,并且会明说哪些边界被保留了。收尾的论据通常是一张表:先是 make check,然后 fast 898/898、integration 231/231、端到端 4/4,再加一个随改动变化的聚焦数字——某一处是 64 个聚焦的生命周期测试,另一处是 74 个聚焦的内核与工具测试,第三处是 39 个聚焦测试。三十条里只有两条带评论,而两条评论都是维护者在公开地诊断性能,给出运行编号、固定的源码提交和一张秒数表。同样的回路也写在提交里:400 次提交中有 95 次带共同作者尾注,其中 67 条写 Claude Opus 5、28 条写 Claude Fable 5;另有十五次提交记在 claude 账号名下、三次记在 codex 名下。审查在这里不只是文字:issue 归属是放在 .github/scripts/ 下的一个脚本,而贡献指南被描述为覆盖 issue 归属、缺陷升级与 pull request 契约。

  4. 04

    一件工作要具备什么,才算可以收尾

    证据是这套模型里棱角最硬的部分。回执是 JSONL 而且是追加式的;一次结果不确定的追加会保留锁,而不是去猜那条回执到底落盘没有;一把残留的写入器锁本身就是恢复证据,在写入器、状态文件、回执、待处理 delta 与归档动作全部对账清楚之前不许删。退出码 2 被明确定义为 hold——既不是成功,也不是普通的失败。报告与生成的投影只是视图,永远不能当作规范输入;仓库自带的校验代码不会被自动执行。机制是被点名写出来的,而不是留给读者推断:只有一个追加式的 evidence-invalidation-v1 生产者,带精确的目标绑定、dry run、幂等的事件身份,并且要通过命令行与 MCP 两条路都确认发布。它之所以存在,是因为一次具体的失灵:审查者可以记下一条结构上合法、内容却错误的判断,而生命周期没有任何受控的办法把这条主张撤回,除非改掉源内容或者丢掉历史;一个被标为不适用的检查项能被它的生产者接受、被下游复用,而它冻结的审计计划里仍然列着必需依赖。修法划的是权限线,而不是加一层认证:一份声明可以由它自己的作者撤回、由既有的语义权限撤回,或者由用户的明确决定撤回,而 integrator 在这个过程中并不获得判断权限。记录里写得很清楚:这些是操作者与宿主给出的断言,不是一套认证系统。

  5. 05

    裁定「陈旧的那条」和「当前的那条」

    这个仓库里最锋利的一类缺陷不是崩溃,而是对「哪条记录才算当前」的分歧。其中一条报告讲的是最普通的情形:一个页面在已打开的批次里改了,生产者正确地生成了后继审计回执,运行时的 currentness 所有者把前任标成陈旧。可对消费这条评审的稳定校验来说,只要没有传入实时的 currentness 集合,它就把每一条匹配到的历史回执都当成当前的,于是这个消费者被判成有多个当前尝试而拒绝——尽管它引用的正是唯一的当前后继。所有者对缺陷的概括本身就是这条规则最清楚的表述:陈旧的历史仍然是合法的历史,它不该挡住当前批次。修法把两道检查拆开——稳定校验只读消费者记下的那些不可变引用,实时校验则独立地检查这些引用是否等于 currentness 投影。更晚的一对条目把同一条缝继续往下游封住:回执的阶段性选择必须一路活过批次关闭与终端消费,于是一次合法修订不会因为在合并前选中的是新证据,就在关闭时被重新读成两个互相竞争的当前候选。那条修法还否掉了它自己的廉价版本:把扫描范围收窄到被选中的生产者,会丢掉更早的对账历史,以及验证第二轮评审所必需的第一轮正文。

  6. 06

    给治理者本身做预算,以及把它长出来的东西退场

    治理工具链自己也要被治理,而在这里治理它的是一块秒表。必需链条的目标是约 300 秒、硬上限 360 秒,而端到端场景的一次固定样本跑了 911 秒——issue 直接说这不算达标,尽管那次运行在十五分钟的作业超时内算是通过的。随后它把测量摊开来讲:在钉住依赖的两套环境上各跑一次,Python 3.10.21 与 Python 3.14.7 上的自然命令时长分别是 463.52 秒与 485.36 秒,既有端到端模块是 454.02 秒与 476.94 秒,超出 360 秒上限之外还剩 103.52 秒与 125.36 秒的工作量。超限必须判定为不达标,但不能把测量截断,所以执行另外拿了一个独立的 1,800 秒安全期限。有一处空白是被如实记下、而不是被解释掉的:同一套场景、同为一致的源码树,一次在 3.14 上更慢、另一次在 3.10 上更慢,而现有日志无法把这处反转归因给解释器。被提出的几条捷径也被否掉了——issue 写明,这不是在请求调高超时、砍掉 Python 3.14,或者把整条生命周期 mock 掉。接下来是一长串退场:一个被取代的别名直接删掉而不是留着当别名;一个空的回执终结模块被移除;一份重复的命令行/MCP 列表形状算法被合并掉;而一整组不安全的复用——一个经过检查的视图缓存、Runner 装饰器、一份公开 API 声明,以及只针对缓存的断言——被一起退休。

相关档案

全部档案 →

第 119 号

headcount

一个按公司组织的 agent 组织——一位首席执行官之下是十六个可独立安装的部门和 172 个技能:每个技能是一个 Markdown 目录,请求与它的描述匹配时自己加载;同一棵树既能装进 Claude Code,也能装进 ChatGPT,因为两边只有清单不同;而那 184 份真正裁决问题、而不是给答案做装饰的外部权威——监管机构、标准组织、成文法——就放在它们所服务的技能旁边,每一条都标着 agent 拿它可以做什么。

第 071 号

Open Mercato Skills

一包四十一个 agent 技能,装进任何仓库就能跑完整条 pull request 流水线——计划、在隔离的 worktree 里实现、自查、用真实浏览器验证的 QA 关卡、合并——三条入口(一份任务简报、一份规格文档、一个 tracker issue)汇入同一条评审环;所有与项目相关的取值都来自一个提交进仓库的配置文件;tracker 命令被收进随包发布的描述文件(GitHub、GitLab、Linear、Jira 各一份);每个技能交给下一个的,是一行可被机器解析的 PR 引用行。

第 065 号

GSD Core

「Git. Ship. Done.」——一个元提示、上下文工程与规格驱动开发的框架,每个里程碑都重复同一条五步回路:讨论、计划、执行、验证、发版。重活被推给上下文全新的子 agent,主会话因此保持轻量;每一项决定都写进规划目录下的 Markdown 与 JSON,而不是留在对话里。