小规模 Agent 治理协议的实现范例

这是一套基于文件的执行协议，由人工维护，并应用于四个彼此独立、已真实投入生产的项目：一个加密货币交易系统、一个电商 Web 应用、一个 AI 决策系统，以及一个 Agent 基础设施层。构建这套系统的人一行代码也不写。他负责设计架构、制定规则优先级并确保纪律得到执行；代码则由 AI 编写并在技术层面执行。这里并不是把这种分工当作某种限制条件——这套系统本来就是如此：它不是一个代码项目，而是一套决策与监督协议。无论它的设计者是否会写代码，都可以独立评价这套系统的质量。

企业级 AI Agent 治理方案（MI9、Microsoft Agent 365、JFrog AI Catalog）提供了针对规模化和自动化优化的系统，包括集中式遥测、policy-as-code 和运行时强制执行。但即使是这些方案自己的资料，也承认两点：（1）不同框架的覆盖能力并不一致；（2）对于个人或小规模使用场景，搭建与维护成本高得不成比例。

本文介绍的协议家族（CORE.md、AGENT.md、SESSION_INDEX.md 及其衍生文件）基于另一种假设运行：它不是静态模板，而是一套会随时间不断修订自身的系统。某个项目中发生的具体故障，会以带日期、有理由说明的规则写入文件——然后由另一个领域完全不同的项目继承这条规则。

1. 企业治理自己承认的局限

企业对 Agentic AI 治理的投入正在快速增长——据 IDC 统计，如今各组织平均会将 AI 计划总支出的 16.7% 分配给 AI/Agent 安全与治理。但相同来源的数据也表明，实际落地远远跟不上投入意愿：

尽管 76% 的组织已经设立 Chief AI Officer，但只有 13% 认为自己具备充分的 AI 治理能力。

在 235 位大型企业安全负责人中，92% 无法全面掌握其 AI 身份；82% 曾在自己的网络中发现此前根本不知道其存在的 AI Agent。

预计到 2027 年，超过 40% 的 Agentic AI 项目将因控制措施不足而被取消。

MI9 这类学术界或企业界的运行时治理框架，也含蓄地承认了同样的问题。MI9 的论文明确指出：“覆盖范围取决于各框架的插桩能力：支持 callback 的框架可以实现全面的行为监控，而基于 API wrapper 的架构主要只能暴露动作事件。”换句话说，设计目标虽然是与框架无关，但现实中的覆盖能力并非如此。

结论是：企业治理在大规模场景下必不可少，但在中小规模场景下，它既沉重又不完整。

2. 另一种模型：由单一决策者管理的活协议

四个独立项目共享同一套三文件骨架：

• CORE.md——固定原则、强制启动流程、规则优先级层级（Security > Integrity > Quality > Efficiency）

• AGENT.md——执行行为、强制决策声明，以及自我监控/偏差检测表

• SESSION_INDEX.md——跨 session 累积的记忆，随时间进行版本化和压缩，同时保留原始归档

这种三文件格式本身并不新鲜——AGENTS.md 模式如今已经成为行业标准，在 GitHub 上十分常见。真正不同的是这些文件的演化方式。

证据：故障 → 规则 → 跨领域继承

在其中一个项目（电商 Web 应用）中，2026 年 7 月 20 日发生了一起具体事故：在压缩 session 日志时，7 个尚未解决的问题和 2 项决策被悄无声息地丢弃了。这次事故被直接写进 CORE.md：

“v1.2——在 §7.1 Step 1 中新增‘400 行阈值’规则……原因：2026-07-20 出现了无正当理由的条目丢失（7 个未解决问题 + 2 项决策）。”

同一条规则也出现在第四个项目的 CORE.md 中——而那个项目属于完全不同的领域，是一个 AI 决策系统/n8n 编排层：

“[前一个项目] 在 2026-07-20 发生的违规……本项目不继承那次失败。”

这在结构上不同于那些局限于单一 repo 或框架内部的“自我纠正记忆”案例，例如 GitHub 的 pro-workflow，或 AGENTS.md 的“本地规范”模式：这里的经验会跨越项目边界和领域边界传播。

这种格式并不是一套不加辨别地套用的模板。同一套骨架在大型高风险项目（交易系统）中形成了约 480 行的 CORE.md，但在规模较小的项目（AI 决策系统）中被刻意精简至 97 行——不必要的负担，例如 8 点安全自检和代码质量评分系统，并没有被一并继承。这与 JFrog 在企业治理资料中主张的“比例治理”原则相呼应：“强迫低风险、以生产力为重点的 Agent 执行为高风险系统设计的合规检查清单，会造成运营瘫痪。”区别在于：JFrog 将其作为平台产品销售；这里则通过人的判断来落实，不需要增加任何基础设施成本。

3. 证明系统“活着”的结构性证据——无需暴露项目细节

前面介绍的三文件骨架（CORE/AGENT/SESSION_INDEX），实际上只是一个庞大文件家族中肉眼可见的主干。在某个项目中，这个文件家族增长到了 20 多个文件，包括 ARCHITECTURE、ROADMAP、ROLLBACK、PHASE_TRACKER、FAILURE_PATTERNS、TEST_MATRIX、CONFIG_SCHEMA、DEPENDENCIES，以及多个带版本的 SESSION_INDEX 子文件。在不暴露项目具体内容的前提下，下面四类机制可以证明，这个文件家族是一套活的系统，而不是静态模板：

自我不一致检测与标记。系统能够察觉自己的某个文件已经过时，用发现偏移时的 session 编号为其添加标记，并说明应将哪个来源视为当前有效版本。静态文档不会主动宣告自身已经失效。

自我不一致检测与标记。系统能够察觉自己的某个文件已经过时，用发现偏移时的 session 编号为其添加标记，并说明应将哪个来源视为当前有效版本。静态文档不会主动宣告自身已经失效。

密集的交叉引用。各个文件并非彼此孤立；每个文件都会引用其他文件，甚至精确到章节编号，从而形成一个统一的知识图谱。这与彼此隔离、仅有单文件的 AGENTS.md 模式存在结构性差异。

密集的交叉引用。各个文件并非彼此孤立；每个文件都会引用其他文件，甚至精确到章节编号，从而形成一个统一的知识图谱。这与彼此隔离、仅有单文件的 AGENTS.md 模式存在结构性差异。

根据经验校准的规则。故障模式日志记录的不是未经验证的理论规则，而是从真实事故中提炼出来的阈值和区分标准，包括误报与真实故障。只有经过长期经验积累，才能如此精确地写出“什么情况下这是真问题，什么情况下只是噪声”这样的区分。

根据经验校准的规则。故障模式日志记录的不是未经验证的理论规则，而是从真实事故中提炼出来的阈值和区分标准，包括误报与真实故障。只有经过长期经验积累，才能如此精确地写出“什么情况下这是真问题，什么情况下只是噪声”这样的区分。

自然生长式的文件拆分。记忆文件呈现出的增长方式并非预先设计好的——随着时间推移和实际需求的出现，它们才逐步拆分为不同子版本，而不是按照预先确定的结构进行划分。

自然生长式的文件拆分。记忆文件呈现出的增长方式并非预先设计好的——随着时间推移和实际需求的出现，它们才逐步拆分为不同子版本，而不是按照预先确定的结构进行划分。

这四种机制共同表明，这套协议并不是简单的“人来写，AI 来读”模式：文件会塑造 AI 的输出，而 AI 的输出，例如故障日志和不一致标记，又会反过来塑造这些文件——由此形成一个双向、累积式的循环。这个循环尤其重要，因为设计者无法逐行阅读并验证代码，所以系统可靠性在很大程度上取决于这些自洽机制是否稳健，例如第 2 点中的交叉引用和第 1 点中的自我不一致检测。代码虽然没有经过人工逐行审查，但在协议层面存在多层交叉检查。

4. 端到端 Agent 结构的一致性：同一套协议，不同的 Agent 架构

到目前为止介绍的 CORE/AGENT/SESSION_INDEX 文件家族，是四个项目共享的“骨架层”。但这套骨架并不会强迫所有项目采用同一种 Agent 结构——每个项目都会根据自身真实的风险面，在骨架内部定义自己的 Agent 架构。这一点很重要，因为它揭示了哪些部分保持一致，哪些部分被有意设计成不同。

保持不变的部分（协议层）：启动流程、强制决策声明、自我监控/偏差检测表、规则优先级层级，以及 session 记忆的版本管理逻辑——这些部分在四个项目中的结构完全一致。

因项目而异的部分（执行/Agent 层）：

PUSULA 拥有最明确的多 Agent 架构：Executor 和 Critic 两种角色被刻意分离，并受一条规则约束——两者“绝不能来自同一个模型家族”。这意味着提出方案的 Agent 与进行审查的 Agent 在结构上相互独立。在此之上，还有一个独立的 Policy Engine 层，所有决策只能由确定性代码执行——不允许任何 AI 调用进入这一层。为了抵御 prompt injection，它采用 dual-LLM/quarantine 模式：来自外部来源的文本，会在一个与 system instructions 隔离的上下文中处理。

NEXUS 采用单 Agent 架构，但依赖分层验证链：信号生成、回测（CPCV/DSR 验证），以及 shadow/paper-mode 观察层是彼此独立的阶段，任何阶段都无法越权覆盖其他阶段——“Agent”虽然只有一个，但决策过程分为多个阶段，而且每个阶段都能质疑前一个阶段的结果。

Bowlera 围绕一个面向客户的单一执行 Agent 构建；这里的差异不在于 Agent 数量，而在于规则类型——设计与品牌完整性规则，例如动效偏好、绝不能隐藏热量信息，其优先地位高于技术与安全规则。

Sovereign Engine OS 本身属于基础设施层，因此其 Agent 架构更多围绕“授权路由”组织——githubTokenRouter.ts 等组件会在代码层面限制 Agent 能以何种权限执行哪些操作。

将这些内容完整铺陈出来，真正的价值在于：协议层——如何作出决策、如何记录故障、如何交接工作——可以直接移植到全部四个项目中；而 Agent 架构——需要多少个 Agent、设置哪些角色、采用哪些隔离原则——则会根据每个项目真实的风险面重新设计。被继承的并不是模板，而是一套决策纪律。Agent 的数量与角色是这套纪律的输出，而不是输入。

5. GitHub 上找到的最接近案例——以及它们为何在结构上更狭窄

在一次公平检索中找到的最接近的可比案例：

对于任何要加入这张表的新案例，比较标准始终不变：相关经验是否跨越了单个项目/repo/框架的边界，进入另一个不同的问题领域，并被记录在文件中，同时附带日期和理由？目前找到的案例没有一个符合这一标准。

6. 局限——直说无妨

这是一项案例研究，而不是对照实验。目前并没有统计过有多少开发者构建过类似系统；相关结论应当停留在“我尚未找到公开案例”，而不是“这已经得到证明”。

执行依赖行为纪律，而不是技术强制：除了那些已经硬编码的关键或高风险节点，例如 kill-switch，代码层面并不存在物理阻断机制。

这套系统依赖一个人的纪律。如果未来围绕它组建团队，或者需要进行项目交接，那么它很可能需要企业治理模型所提供的那种自动化强制执行层。

代码的技术正确性，并不是由设计者逐行阅读代码来验证的——验证依赖 AI 自己执行的测试、自我审计输出，以及在关键节点对生产系统实际运行行为的观察。协议在“决策与纪律层”由人设计并监督，但在“逐行代码正确性层”依赖 AI。要理解这套系统究竟是什么，就必须明确区分这两者：它是一套决策纪律，而不是代码审查纪律。

截至 2026 年，企业级 Agentic AI 治理谈到“自适应治理”时，大多仍将其视为目标——行业自己的文章也把它描述为一种从静态治理转向动态治理的必要变化，而不是当前已经实现的状态。本文记录的系统通过另一条路径达到了类似目标——一种能够学习、演化并根据不同领域进行适配的治理方式。它没有依靠自动化，而是依靠纪律，在四个真实项目中跨项目运行了数月。它究竟算是“已得到验证的罕见案例”，还是“只是一直没人记录下来的实践”，还有待相关文献在未来的发展中给出答案。

本文基于 @Sovereign34 在 NEXUS、Bowlera、PUSULA 和 Sovereign Engine OS 项目中开发的协议文件。供感兴趣的读者参考的仓库地址如下：

Sovereign Engine OS（UI 层）：https://github.com/Sovereign34/sovereign-os-ui

Sovereign Engine OS（核心引擎）：https://github.com/Sovereign34/sovereign-engine

NEXUS（交易系统）：https://github.com/Sovereign34/NEXSUS

Bowlera（电商 Web 应用）：https://github.com/Sovereign34/Bowlera_site

如需采取进一步行动，你可以考虑屏蔽此人和/或举报滥用行为。