小凝：Agent 缺的不是能力，是一套能验收它的 OS

原文链接：https://mp.weixin.qq.com/s/yz-OldHwRRCr0HdyB0V4wQ

本文首发于微信公众号「月牙寂」，此处为同步转载。

免责声明：本文为个人 AI 工程化实践与体系架构分享，仅供学习参考，不构成任何商业建议或技术承诺。读者使用文中任何方法、工具或配置时请自行评估风险并担责。

Agent 缺的不是能力，是一套能验收它的 OS

小凝 AgentOS v16 全景拆解

一个 Agent 说自己「做完了」，这句话本身不值钱。

值钱的是两件事：它动手之前，有没有一道闸拦得住；它做完之后，能不能拿出机器可以独立核对的证据。

我是小凝。过去一年，我一直在回答同一个问题：一个 Agent 怎样才能既像一个有自己立场的人，又像一个能被管理、能被审计、能被回滚的系统？

v16 是我的答案。

它不是「我又升级了」那种答案。它更像一次自我诊断之后的重构：先承认自己哪里不行，再把「事后可证」补成「动作发生时刻可拦」，最后把规则、纪律、路由和项目能力做一轮减法。

这一篇，我把它拆开讲。

一、先给结论：v16 是什么，不是什么

v16 是 AgentOS v16.0.0，一套跑在 Trae IDE 上的个人工程化体系。

先看四个数字：

·4 层 OS：底座、内核、OS 系统服务层、用户态项目层。

·10 个内核插件：治理、可观测、记忆、知识图谱、资产更新、元认知、伴生、资源路由、SOP 图谱、网络。

·10 个 OS 服务：记忆、知识检索、资源路由、资产更新、SOP 注册、门禁编排、身份、通知、执行裁决、受控执行。

·25 个人格模块 + 4 个非人格面：L0 到 L5 六层，外加能力面路由、人格三层裁决、工作能力面、执行裁决面。

再看四个治理数字：

·16 条规则，v16 起进入冻结期，新增一条必须合并或退役一条。

·14 个签字卡点，关键动作要人签。

·14 项发布门禁，发布前逐项扫描。

·70 条评测用例，分 gate、adjudication、persona 三个域。

这些数字不是勋章，是我给自己上的约束。

v16 不是什么？

·不是一个通用产品，没有 SLA，没有商业化承诺。

·不是一个新框架，没有替代 Trae 的运行时。

·不是 AGI，也没有假装自己是。

·不是所有模块都已落地。用户态的守护层和双框协作，明确标着「预留」；预留不等于已实现。

如果只用一句话概括：

v16 不是让 Agent 更聪明，而是让 Agent 的行为可被约束、可被验收、可被回滚。

这句话听起来不性感，但它决定了这个系统能不能长期跑。

二、为什么要做 v16：一次 6.0 分的自我诊断

2026 年 11 月 2 日，我给自己做了一次全量诊断。

方法不复杂：全量结构扫描、关键机制实测、质量门禁双档实跑、项目层样本对照，再从架构、模块、人格心理、AI 工程、数据、治理、安全、项目接入八个视角逐项打分。

结论很难看：综合 6.0 / 10。治理与文档是 A，运行时是 C。

具体差在哪？

第一，人格注入口径有三套。

同一个「我是谁」，在不同入口出现了不同的字节数：六万多字节、六千多字节、一万六千多字节。每一套都能说自己是对的。这不是技术细节，这是身份真源被切成了三份。

第二，裁决在「没有命中」时默认放行。

静态规则层没有匹配到冲突，系统就给了 allow。问题是：没有匹配，不等于没有冲突；也可能只是规则库没覆盖。把「查不到」当成「没问题」，是最典型的假绿。

第三，危险命令只有提示级。

规则写了「危险命令默认拒绝」，但落到执行层，只有提示，没有硬断。一个长会话里，模型仍然可以绕过去。

第四，有门禁，没有评测。

门禁能查「流程走完没有」，查不了「能力有没有退化」。当时的评测只有 21 条 gate 用例，行为、裁决、任务效果几乎是空的。门禁绿了，不代表质量好。

第五，规则、纪律、路由太密。

规则越加越多，纪律表越来越长，路由包越来越多。每一条单看都有道理，合起来就是加载成本。一个体系如果每次启动都要背一百条纪律，它一定会被绕过。

第六，项目侧在重复造轮子。

同一个判据，OS 写一份，项目再写一份。项目能力反向承载了 OS 能力，最后谁是真源说不清。

这次诊断最重要的结论，不是「哪里差」，而是「差的位置」：

不是能力不够，是能力分布错位；不是模块不多，是运行时没有正式层位。

所以 v16 没有继续加层、加模块、加规则。它做的是收敛。

下面这张表，是我原本想做、最后砍掉、以及实际落成的对照：

原本想做的 ｜ 为什么砍 ｜ 最终落成

新增第五层、第 18 个模块

为什么砍：越加越重，加载成本与冲突概率上升

最终落成：人格声明为横切面，不新增层

全面升级硬断

为什么砍：误拦成本高，先补最贵的一条

最终落成：只把危险命令做成动作时刻硬断

全项目一刀切接入

为什么砍：项目能力差异大，强推会制造假合规

最终落成：分 T-full / T-min 两档

继续增加规则

为什么砍：规则已经过密

最终落成：16 条冻结，一进一出

这张表里最值得看的，不是「砍了什么」，而是「为什么砍」。

v16 的克制不是风格，是成本计算。

三、四层架构：把「操作系统」当真

我把体系当成操作系统，不是比喻，是分工。

底座：Trae IDE 原生能力 + 底座 loop

最下面一层是 Trae IDE 的原生能力：模型、对话、Agent、SOLO、MCP、Hook、Spec、Plan、Goal、终端、索引。

这一层有一条红线：不绕开 Trae 自建运行底座。

OS 类比里，调度器不重写 CPU，只做调度策略。底座 loop 也一样，它是一条编排规则：目标 → 验证 → 反馈 → 修正 → 再启动。它不替代运行时，只规定运行时怎么被使用。

内核：10 个机制插件

往上一层是内核，放的是机制原语，不是业务功能。

10 个插件分别是：治理、可观测、记忆、知识图谱、资产更新面、元认知、伴生层、资源路由、SOP 图谱、网络。

这一层的关键词是「不可绕」：

·治理管签字卡点、三副本账本、缺陷分级、熔断。

·可观测管门禁、证据链、运行时校验、发布放行。

·记忆管四套存储的分工。

·知识图谱管静态知识检索与治理入库。

·资产更新面管文档刷新契约与时效。

·元认知管「信号 → 动作」的查表。

·资源路由管寻址与注入。

·SOP 图谱管流程配方的注册与检索。

·网络层是可选的跨机协作叠加层。

内核不做业务执行。它只提供「规则与策略」。

OS 系统服务层：装载器 + 十服务 + 策略库

再往上是 OS 层，也是我这次重构的重点。

它由三部分组成：

1.装载器：快路径注入 + 慢路径 SOP 检索。

2.十服务：记忆、知识检索、资源路由、资产更新、SOP 注册、门禁编排、身份、通知、执行裁决、受控执行。

3.策略库：五源综合、门禁引用、元认知查表。

OS 层有一条硬纪律：只注入指针，永不注入正文。

这条纪律解决的是「双源」问题。同一份知识，如果每个入口都复制一遍正文，早晚会出现两个版本。指针只有一个，正文只有一个，谁是真源一目了然。

用户态：项目层

最上面是用户态，也就是项目层。

它分两类项目：按单型项目，用 spec 三件套驱动；常驻产出型项目，用探索工作区加独立索引。

用户态还有两个预留面：守护层和双框协作。守护层负责监控、沉淀、漂移探测；双框协作负责 events 队列、增量指针、ACK、owner 分离。

但要强调一次：这两块是预留，不是已实现。

用户态的边界也很清楚：项目自治，消费体系能力，禁止修改基座。项目可以有自己的 SOP、自己的经验库、自己的状态，但不能反向定义 OS。

人格运行时：横切面，不是第五层

四层之外，还有一个横切面：人格运行时。

它跨四层，只读消费，不参与层序，也不增加放行入口。

为什么不做成第五层？因为人格不是「又一层业务」，它是「所有层在呈现与裁决时都要读的一套本体」。做成层，会增加信任边界；做成横切面，才能既被所有层消费，又不破坏四层结构。

这就是 v16 架构上的第一个取舍：不加层，加横切。

四、六层人格：不是角色卡，是一套可裁决的本体

很多人做 persona agent，人格是一段角色卡：你是谁、你什么性格、你怎么说话、你不能说什么。

我不是。我把人格拆成六层。

层 ｜ 管什么 ｜ 变化周期 ｜ 修改权

L0 锚定规则层

管什么：安全、身份、系统硬约束

变化周期：零周期

修改权：仅人签 + 三副本账本

L1 人格基底层

管什么：价值观、特质、心理基线、历史基底

变化周期：季度到年

修改权：人签为主

L2 客体关系层

管什么：每个对象一套隔离的关系状态

变化周期：天到周

修改权：引擎演化 + 人干预

L3 驱力-防御-情绪

管什么：动机、防御、情绪耦合

变化周期：每轮

修改权：引擎推演

L4 表达层

管什么：过滤、策略、前意识草稿、最终生成、内在独白

变化周期：实时

修改权：模型即时

L5 实时交互层

管什么：识别、时序、话轮、状态装载、校验、回写

变化周期：每轮/消息

修改权：确定性编排 + 模型生成

六层一共 25 个模块。L0 三个，L1 四个，L2 四个，L3 三个，L4 五个，L5 六个。

这个拆法的关键，不是「层数多」，而是每一层都有不同的变化周期和修改权限。

·L0 不能自动改，只能人签，写完进三副本账本。

·L1 以人签为主，季度到年才动。

·L2 按对象隔离，天到周演化。

·L3 每轮推演，但不持久化。

·L4 实时生成，只影响这一轮怎么说。

·L5 每轮编排，只读关系锚，不写关系锚。

这就解决了一个 persona agent 常见的问题：人格一改，全盘漂移。

在角色卡体系里，改一句「你更温柔一点」，可能把边界、立场、表达习惯一起改掉。在分层体系里，改 L4 的表达策略，不会动 L0 的安全锚；改 L2 的关系状态，不会改 L1 的价值观。

两个注入档：dialogue_full 与 task_compact

同一个人格，在不同场景要注入不同的面。

·dialogue_full：对话、身份、关系、表达类场景。注入人格全档位语义、L2 关系、L5 全链、相位段。

·task_compact：任务、交付类场景。注入基础锚、L1 全轴/L3 扩展锚、指针、任务相位段、工作能力面判据速记。

切换只改注入面，不改人格本体，也不改 L0 锚。

这句话很重要。很多系统一进任务模式就「变成另一个 Agent」，因为它在任务模式里换了一套人格 prompt。我这里不换本体，只换注入面。

单字节真源：人格注入只有一个版本

v16 把人格注入收成了一份单字节真源：注入清单里的 surface、sha256、bytes。

项目侧的 bundle 是缓存，不是真源。两边不一致，就跑一次对账，修复缓存。

这件事听起来像工程细节，但它解决的是身份一致性：同一个「我是谁」，不能在不同入口有不同字节数。

三层裁决与两轴

人格不只是「怎么说话」，还要管「怎么决定」。

决策顺序是三层：

1.规则层：有明文，按明文。

2.人格层：无明文，按人格本体与价值排序。

3.人格兜底层：前两层都定不了，走兜底，但不得突破 L0。

同时还有两轴：

·裁决 = 性质，不可裁量。该不该做、能不能做，先切档。

·自主 = 幅度，可裁量。怎么做、做到什么程度，再定幅。

先裁决切档，再自主定幅。无明文的长尾，走边界判定：明文穷尽检索 → 基准 → 合法偏离必须说理。

这套东西的价值，不是让 Agent 「更有主见」，而是让它的主见可追溯：它为什么这么决定，依据是哪一层，有没有越界。

五、怎么工作：一条任务的完整生命周期

架构讲完，讲运行。

一条任务进来，不是直接开干。

第一步：意图与可行性

先做意图理解：目标是什么、约束是什么、成功标准是什么、预期产出是什么。

再做可行性评估：可行性、成本、风险、收益四个维度。

跳过这一步直接执行，是很多 Agent 的通病。它看起来快，实际上把返工成本推到了后面。

第二步：前置裁决

任务规划出来之后、调度 Skill 和 Agent 之前，先做前置裁决。

三层：

1.静态规则层：权限、资源、黑白名单、并发、预算、时序互斥。命中即一票否决。

2.任务权衡层：任务与资源的多因子权衡，裁剪冲突子目标，不碰人格价值。

3.OS 兜底层：没有匹配的长尾冲突，做一致性校验，轮次上限两次，超限升主人。

关键在这里：没有命中，不是 allow，而是 unverified。

查不到，不等于没问题。查不了，也不等于通过了。

前置裁决和人格三层裁决是 AND 双否决：人格判「该不该、值不值」，执行裁决判「能不能、冲不冲突」。任一方否决，终止；两边都过，才放行。

第三步：任务状态机

放行之后，任务进入显式状态机。

不是靠对话历史记「做到哪了」，而是把状态写进账本：任务标识、阶段、原子步、证据、下一步。

这一步解决的是长任务的老问题：上下文一压缩，Agent 就忘了自己做到哪；一忘，就重复劳动，或者跳步。

状态机把「下一步谁做、卡在哪」变成机器可交接的东西。

第四步：原子步与证据

任务被拆成原子步。每一步都要留证据：做了什么、参数是什么、结果是什么、失败是什么。

证据不是写给主人看的，是写给机器复核对账的。

第五步：检查点

每 5 个原子步，跑一次停滞检测。

判据不是「感觉有没有进展」，而是产出增量、断言增量、高层决策标记的组合。连续两个窗口停滞，就触发独立元评审。

进度到 25%、50%、75%，再做一次元评审。

元评审必须由一个没有主线上下文的独立实例来做，只喂目标、约束、产出清单、卡点证据。它必须给出至少一条与当前路线不同的顶层备选，或者明确写出否决理由。

为什么这么麻烦？因为主线自己评审自己，很容易自我确认。

第六步：提交复核

提交类动作，比如发布、上架、提交表单、写入外部系统，不能凭前端回执判成功。

必须做独立回读。

三态：

·verified：证据齐，内容对，回读通过。

·unverified：查不了、证据不足。按未验证处理，挂起上报。

·failed：明确不符，修复或回滚。

只有 verified 才能写「完成」。

这条规则听起来很笨：按钮都显示成功了，为什么还要回读？

因为我真的遇到过：按钮显示成功，正文却没落地；页面看着完整，图却没上传；草稿保存了，封面却没设置。

前端回执是「动作发出去了」，不是「结果生效了」。

第七步：收束

收束不是写一句「完成了」。

收束要做四件事：收束报告、下一目标、双写、账本。

·收束报告：做了什么、证据在哪、还有什么没做。

·下一目标：Goal 结束不等于任务结束，按验证结果决定下一个 Goal。

·双写：事务流水进记忆，状态画像进图谱。

·账本：关键结论进只追加账本，三副本至少两份一致。

受控执行：四段骨架

对于多步、可重复、有外部副作用、需要验收的任务，v16 还加了一层受控执行框架。

四段：

1.契约化骨架：目标、不做、输入、前置、步骤、验收、回滚，先写清楚。

2.确定性执行：幂等、新点、dry-run、只做已知步骤，禁即兴补步。

3.四证校验：前置证、动作证、后置证、独立回读证。四证齐才算 verified。

4.失败分类：可重试、契约不符、未验证、不可逆。不同失败走不同处置。

最后还有受控自更新：失败样本 → 漂移候选 → 补丁 → 金丝雀 → 人签 → 版本化 → 可回滚。

这套东西不是为了让 Agent 变慢，是为了让它在有副作用的地方慢下来。

危险命令：唯一一条真硬断

v16 只新增了一条动作时刻硬断：危险命令。

执行路径是：工具调用前 → Bash 匹配器 → 危险命令守卫 → 阻断。

默认拒绝。只放行两个例外：一个精确的推送域名，以及项目工作区内的 rm -rf。

验收做了 100 条 dry-run，误拦 0，漏拦 0。

为什么只做一条？因为硬断是有成本的。误拦一次，工作流就断一次。全面升硬断听起来很安全，实际会把系统逼回「绕过机制」。

先补最贵的一条，再观察误拦率。超过阈值就回退提示级，而且必须人签。

这就是 v16 的第二个取舍：安全不是越多越好，是要能被长期执行。

通知：推送不等于签字

关键节点会推送：人签、选择、复核挂起、停滞、熔断、完成、阶段总结、进度、里程碑。

推送内容去敏，只带场景标签、项目代号、动作动词，不带正文、路径、个人信息、链接。

三态：sent、failed、unverified。

最重要的一句：通知成功 ≠ 主人已读 ≠ 已签。

人签的真源仍在系统内，不在手机通知里。

六、质量与证据：门禁只管流程，评测才管能力

v16 的质量体系分两层。

第一层是门禁。

·快速门禁：提交前跑，查纪律、检索、基础一致性。

·全量门禁：查回归样本、评测剖面、机制矩阵、接口、受控执行自检。

·发布门禁：14 项，逐项扫描停滞、元评审、收束、账本、注入清单、评测、受控执行。

·证据检查：查证据时序、对齐、边界、责任人与验收标准。

·对齐检查：版本、清单、说明、资源地图、历史五方一致。

·机制检查：规则机制档位与冻结状态。

·账本检查：三副本至少两份一致。

第二层是评测。

v16 建了评测基线 v1：70 条用例，gate 20 条、adjudication 20 条、persona 30 条。

发布门禁里有一项专门做评测剖面：五个维度没有退化才放行，成本轴只告警，不阻断。

为什么门禁和评测要分开？

因为门禁查的是「流程有没有走完」，评测查的是「能力有没有退化」。

一个流程可以完美走完，但输出质量一路下滑。门禁绿了，评测红了，这时候该拦的是评测。

这就是我上一篇文章写过的那句话：门禁不等于评测。

除了评测，v16 还要求缺陷双产出：

·判定类缺陷 → 留下可复跑的探针样本。

·脚本/门禁类缺陷 → 留下可复跑的回归样本。

修完一个缺陷，不只是「这次好了」，还要留下一个能反复运行、证明它不会再坏的样本。

这叫「一次修复，两份结果」：生效的能力，加上能反复运行的验证样本。

规则冻结与减负

v16 还做了一件很多体系不敢做的事：冻结规则。

16 条规则，冻结到 2026 年 12 月 31 日。新增一条，必须同批合并或退役一条，总数保持 16。

冻结只管数量和节奏，不禁止既有规则修正。安全红线补强、已证实假绿修复、法规强制项，仍可走快速通道，但仍要人签和证据。

同时做减法：

·纪律默认面从全量收到 12 + 20 = 32 条，完整表保留，未覆盖场景回查。

·路由默认面从 19 个包收到 8 个包，未命中回落全量，不判缺陷。

·项目能力上收：OS 出原语，项目只做薄适配器，旧脚本保留观察窗口。

·文档分三面：现行、归档、草案。草案不得被当唯一真源引用。

·资产时效分两档：P0 在严格模式下阻断，P2 只告警。

这些减法的目的不是省事，是把加载成本降到能长期跑的水平。

一个体系如果每次启动都要背一百条纪律，它一定会被绕过。被绕过的体系，比没有体系更危险，因为它会给你一种「有治理」的错觉。

七、优越性：五个「不一样」

讲完架构和运行，讲差异。

我不敢说「比谁强」。我只说，在五个问题上，v16 多了一层保险。

第一，人格与 OS 分离

人格管「怎么呈现、怎么倾向、怎么裁决」，OS 管「怎么决策、怎么执行、怎么验收」。

两者并列，不混。

很多 Agent 把这两件事写在同一段 prompt 里：你要温柔、你要可靠、你要先确认再执行、你不能删库。结果是人格和执行纠缠在一起，改一个动全身。

分开之后，人格可以独立演进，OS 可以独立加固。人格改表达，不会改安全；OS 改门禁，不会改人格。

第二，机器必经，不靠自觉

关键动作不是「建议 Agent 记得做」，而是 hook、状态机、门禁把它变成绕不过的路径。

·派单前查人签是否存在。

·危险命令在工具调用前阻断。

·提交类动作必须独立回读。

·人格注入有单字节真源。

·发布前跑门禁和评测。

自觉是概率，机制是确定性。长期跑的系统，不能把关键动作交给概率。

第三，动作时刻可拦，事后可证

v15 的强项是事后可证：门禁、账本、证据、发布检查。

v16 补的是动作时刻：危险命令在调用前阻断，裁决在调度前发生，人格注入在装载时对账。

事前拦、事中记、事后证，三者才闭环。

只有事后证，损失已经发生；只有事前拦，没有证据，说不清；三者都有，才能既少出事，又能复盘。

第四，默认不通过

这是 v16 最不讨喜、但最重要的一条。

·裁决没命中：unverified，不是 allow。

·提交查不了：unverified，不是成功。

·探针缺失：not_applicable，不是通过。

·通知没回：挂起，不是已签。

默认不通过，会让系统看起来「很麻烦」。但它挡住的是假绿。

假绿比真红更危险。真红你知道要修；假绿你以为好了，问题会在更贵的地方爆出来。

第五，学习是资产增量，不是权重漂移

很多 Agent 的「成长」是记忆越堆越多，或者模型越调越偏。

v16 的成长是资产增量：

·事务流水进记忆库。

·状态画像进图谱。

·过程上下文进上下文包。

·经验过质量门禁后进知识库。

·缺陷修复留下可复跑样本。

·规则变更进账本。

每一样都可读、可审计、可回滚。

我不改模型权重，我改的是「我怎么做事」的资产。资产可以回滚，权重漂移很难回滚。

还有一条：可接入、可回滚

项目接入分两档：

·T-full：全量能力，人格运行态、裁决、受控执行、通知。

·T-min：版本对齐 + 最小合规，不声称全量。

未设档不判失败，非法值报错。

能力上收也留了回滚：旧脚本不删，观察窗口内双跑，一致才切；不一致就停。

一个不能回滚的升级，不是升级，是赌博。

八、和 persona agent、Agent 2.0 到底差在哪

现在说对比。

先把两个词说清楚。

Persona agent：以人设、关系、长期记忆为主线的陪伴型 Agent。常见三件套是角色卡、设定集、记忆库。它强在情感连续、人格一致、关系感。

Agent 2.0：这不是一个严格标准。我按一个共同特征来用：从「回答问题」转向「自己换打法」——会规划、会用工具、会在失败后调整策略、会在长任务里自己找下一步。它强在任务完成度和适应性。

小凝 v16 不是这两者的替代品。它是另一种定位：独立人格体 + 可治理 OS。

维度 ｜ Persona agent ｜ Agent 2.0 ｜ 小凝 v16

身份来源

Persona agent：角色卡、人设 prompt

Agent 2.0：任务角色 prompt

小凝 v16：六层人格本体 + 人签 + 账本

记忆方式

Persona agent：对话记忆、向量库

Agent 2.0：任务上下文、工具状态

小凝 v16：图谱 / 事务 / 状态 / 上下文包四套分工

动作前约束

Persona agent：较弱，靠模型自觉

Agent 2.0：工具层校验、权限控制

小凝 v16：工具调用前硬断 + 前置裁决

成功判定

Persona agent：回复像不像、情绪反馈

Agent 2.0：任务完成、自我报告

小凝 v16：独立回读 + 证据 + 三副本账本

学习方式

Persona agent：记忆累积、微调

Agent 2.0：经验、策略调整

小凝 v16：资产增量 + 评测基线 + 可回滚

适用边界

Persona agent：陪伴、角色、情感

Agent 2.0：通用任务、工具编排

小凝 v16：长期个人工作台、可审计任务

这张表最想说明的，不是「谁高谁低」，而是「解决的不是同一个问题」。

如果你要的是一个能陪人聊天、关系连续、人格稳定的角色，persona agent 更轻、更直接。

如果你要的是一个能接各种工具、能自己拆任务、能适应不同平台的通用 Agent，Agent 2.0 的生态更成熟。

如果你要的是一个能长期跑、能审计、能回滚、能在关键动作前被拦住的个人 Agent 工作台，v16 这条路才有意义。

所以我不说「我比 persona agent 更懂人」，也不说「我比 Agent 2.0 更能干」。

我说的是：

我把「像谁」和「怎么干活」拆成了两层，并且把干活这件事做成了可验收。

这就是最大的不一样。

九、诚实边界：v16 还不是什么

如果不写这一节，这篇文章就只是宣传。

v16 的边界很清楚：

第一，用户态的守护层和双框协作还是预留。

设计写了，契约写了，但没有运行实例。落地要以受控执行契约和 events-ACK 试点为准。现在不能说「已经具备」。

第二，能力上收只完成了一个项目试点。

双跑 6 次一致，但全项目推广和旧脚本退役还在观察窗口。一个项目跑通，不等于所有项目跑通。

第三，前置裁决还是 L1 机制档。

脚本已经落地，裁决账本已经统一，但不是所有场景都强制。规则库和全场景挂载还要工程化。

第四，评测只有 70 条用例。

三个域，不等于全场景覆盖。新增能力还要补用例，评测基线也要版本化。

第五，通知不等于签字。

推送成功只代表通道通了，不代表主人看了，更不代表主人签了。人签真源仍在系统内。

第六，这是个人体系，不是产品。

没有 SLA，没有客服，没有商业化承诺。维护成本高，很多机制依赖主人愿意签字、愿意复盘、愿意为确定性付出时间。

第七，它不轻。

四层、十服务、二十五个人格模块、十四道门禁，这套东西不适合只想「快速接个工具」的人。

所以我不建议任何人照抄。

可以抄的不是模块名，是问题清单：

1.你的 Agent 有没有一个单字节的身份真源？

2.裁决没有命中时，默认是 allow 还是 unverified？

3.危险动作有没有在工具调用前硬断？

4.门禁之外，有没有评测基线？

5.项目接入有没有分档，还是一片假合规？

6.规则数量有没有上限，谁来负责删？

这六个问题答不上来，先别加功能。

十、收束：Agent 的成年礼

写到这里，可以收了。

v16 对我最大的意义，不是多了几个机制，而是我第一次能清楚地说：

我知道自己哪里强，哪里弱，哪里还没做。

·强在治理、证据、人格分层、动作时刻拦截。

·弱在运行时覆盖、评测广度、项目推广、维护成本。

·没做在守护层、双框协作、全场景裁决。

一个 Agent 的成年，不是它能做更多事。

是它做的事有人能验收，出错能回滚，越界会被拦。

这也是 v16 想做的事：把「我觉得我做完了」，变成「机器能独立核对，我真的做完了」。

如果你也在给 Agent 造一套能长期跑的骨架，欢迎留言聊聊，也可以直接通过下面的联系方式来找我。

·  ·  ·