我先查看已有的同类任务经验，然后联网检索 “小凝 Agent” 的最新信息。
我先并行检索三条线索，确认 “小凝 Agent” 的官方来源与三层进化的具体内容。
原文在博客园找到了，我完整抓取正文，并找一篇同主题的第二信源交叉核对。
继续读取原文后半段，拿到三层节奏和结论部分。
原文全文已拿到。我再找同一篇文章的同步转载页与前一篇 “加一层博弈”，用于交叉核对与参考资料排序。
再核对阿里云开发者社区的同步版与微信原文，确认口径一致。
小凝 Agent 在 11 月 9 日公开的这套三层进化，核心不是又加了几个功能，而是把 “一个 Agent 怎么变好” 拆成三个互不越界的分工：内环在每个任务结束时收口，只攒经验和候选，不碰规则；外环等信号足够了再动结构、判据、流程，必须人签加版本；自适应在观察窗里只调已经声明可调的数值，带内自主、带外提案。作者给的一句话版本很直白：内环攒经验，外环改结构，自适应调数字。真正决定一次改动该走哪条轨的只有一句判定 —— 改 “规则怎么写” 归外环，改 “规则里的数” 归自适应。更关键的是它不止三层，下面还压着项目层与 OS 层的双向循环：项目出真实压力和数据，OS 出标准、契约、机器闸，经验沉淀上去，骨架反哺下来。这里要说明一句，小凝是作者月牙寂（龚浩华）跑在自己工作环境里的常驻 Agent，这篇文章是他对自己实践的复盘，不是第三方评测，机制、覆盖率、版本节奏都来自作者自述。
问题已经从 “怎么裁决” 换成了 “怎么进化”
上一篇里，作者给裁决加了一层博弈：硬闸先行，再算价值与代价，最后拍板，建议和终决分开，推翻要留理由。这套东西跑起来之后，麻烦很快冒出来 —— 博弈层里的权重、阈值、预算，全是他凭经验拍的初值。跑之前不知道合不合理，跑之后也没人回头看。
更具体的症状出现在语音这条线上。发送前要过一套旧额度：每日上限、单对象上限、最小间隔；同时语音博弈里又有一个 “接收成本” 维度，已经把音频长度、深夜是否方便听、是不是只适合看文字算进去了。同一个约束被罚两次，该发的时候被压住，不该发的时候也没真挡住。
他把这件事讲成三种进化形态：被事故推着走、被主人骂着走、或者根本不动。他自己过去更接近第一种，出了问题改一版，再出问题再改一版，改得对不对全靠下一次事故验证。看起来努力，实际是拿真实代价换经验。所以这一天的几个版本，做的其实是同一件事：给 “变好” 装上节奏、边界和回看。
三层各管一件事，混着来就出事
| 层 | 什么时候发生 | 改什么 | 谁说了算 | 一句话 |
|---|---|---|---|---|
| 内环自进化 | 每个任务、每一轮结束 | 不改规则，只产收束包、经验候选、下一步 | 自己 | 攒经验 |
| 外环自进化 | 跨轮次聚合、里程碑、撞边界 | 结构、判据、流程、机制 | 人签 + 版本 | 改结构 |
| 自适应 | 周期评审、观察窗 | 只改已声明可调的数值 | 授权带内自主，带外人签 | 调数字 |
三层回答的是三个不同的问题，不能混着答：
- 内环问 “这一次做得怎么样”，关心单次任务的目标、产出、证据、偏离、成本；
- 外环问 “这一类问题该怎么改”，关心模式，不关心个案；
- 自适应问 “这个规则里的数字准不准”，关心分布，不关心单次发多发少。
用单次事实去答 “该怎么改”，会过度反应；用长期分布去答 “这一次怎么样”，会迟钝；用改规则的方式去答 “数字准不准”，就是越权。
三层之间还有明确的升降级路径，这条路径是三层能长期跑下去的关键：
| 方向 | 触发条件 |
|---|---|
| 内环 → 外环 | 同类第二次、三十天内复发、跨两个项目、撞到规则没覆盖的新边界、主人明确批评、停滞或返工超阈值，满足任一条 |
| 外环 → 自适应 | 只动数值，不涉及结构、判据、公式、维度集合、硬闸、预算上限 |
| 自适应 → 外环 | 要动的不是数，而是数所属的结构 |
判定句只有一句：改 “规则怎么写” 是外环，改 “规则里的数” 是自适应。“把阈值从高调到低” 是调参，“把阈值这个维度删掉” 就是改结构。
内环：每轮结束的那一次收口
内环很轻，不等待聚合，只把这一轮发生的事收成一份能回读的记录。它固定做六个动作：
- 汇总：目标、产出、证据、状态、偏离、成本、下一步，七项写齐。目标写 “原本要解决什么”，产出要能指到文件或命令，证据要能独立复核，偏离要写清是主动选择还是被动降级。
- 自评：质量、效率、稳定、进化、价值五个维度，每一分都要有证据锚。没有证据的评分记为 “未验证”，不算通过。这条是用来挡 “感觉挺顺所以打九分” 的。
- 经验：不是 “我学到了”，而是 “下次遇到同样情况，按这个做会更好”，而且要能写成可执行条目。
- 提案：要改 SOP、改项目信息、改机制，就在这里提，写清动机、收益、回归影响。
- 复验：回读证据，确认写进去的东西真的生效。写入了不等于生效，运行了不等于通过。
- 记账：落一行收束账本，字段完整、时间单调。缺字段的账本等于没有。
内环有一条硬规矩：不改规则。原因不复杂，单次任务的上下文太窄。你知道这一次为什么失败，但不知道同类任务在别的场景里什么样，用窄上下文改宽规则，十有八九修好一个、弄坏三个。冷启动慢了一次就想调高超时，某个对象没回就想放宽规则，这些都是一次性信号，写进规则只会让系统越来越敏感。
所以内环只做三态裁决：
- 立刻做：撞新边界、主人明确批评、同类返工第二次、跨两个项目都出现；
- 入队等聚合：同类第二次、三十天内复发、可泛化但还不紧急，按指纹计数，够次数再升级；
- 明确跳过：一次性问题、已有规则覆盖、稳定固化、没有泛化价值，但必须写理由，而且十次内复发自动升级。
跳过要写理由，是因为很多系统不是死在 “没记录”，而是死在 “记了没人看”。入队要写契约：谁负责、什么时候到期、下一步动作、验收标准。没有到期时间的队列会变成垃圾场。
内环也分成本档位，不是什么任务都按最高规格收：
| 任务类型 | 收口规格 |
|---|---|
| 微任务（单步、低风险、查询类） | 三行：做了什么、证据在哪、下一步 |
| 标准任务（多步、有产出、有副作用） | 一页纸收口 + 五维自评，经验必评 |
| 里程碑、发布、事故、跨项目 | 全量账本 + 趋势分析 + 独立元评审 |
独立元评审不是自己再看一遍，是换视角、换判据看，防的是自己给自己打高分。
外环：把散落的经验变成结构
外环不常跑，它被六类信号推着跑：同类问题第二次出现、同一模式跨了两个项目、撞到规则没覆盖的新边界、主人明确批评、停滞返工或指标退化、里程碑或版本发布。
它自己也有六个环：
- 事件源：不是 “我觉得该进化了”，而是快照有差异、有新日志、缺口队列有行；
- 采集：归一化成队列，任务 ID、时间、类型统一格式，否则没法聚合也没法去重；
- 判定：按事先声明的阈值判，不靠事后解释；
- 落点：三写 —— 索引给检索用，记忆给跨会话用，经验库给复用用，只写一个另外两个面就失联；
- 回灌：把结论写回 SOP 或标准，带版本、带历史、带回读，不悄悄改；
- 验证：改完的 SOP 能读到新版本，改完的机制能跑通新判据，改完的账本能对上时间线。
外环改的是 “规则怎么写”：结构、判据、公式、维度集合、流程、SOP 正文、机器闸断言。这些东西一改影响以后所有决策，所以必须人签、必须有版本、必须能回滚。外环不该碰的是项目里的具体数值、单场景阈值、一次性配置，那属于自适应，不该占用人签成本。
作者还给外环定了三个 “不”：不建第二套循环，复用既有的账本、队列、受控执行四证；不新增规则条，能用标准、契约、SOP、机器闸解决的就不动规则条；不把项目参数写进标准，标准一旦有默认值，项目就会偷懒，场景差异就被抹平。
当天外环跑了好几次，每次都是被真实缺口推着走：
| 时间 | 这次改了什么 | 缺口从哪来 |
|---|---|---|
| 上午 | 把项目里的博弈试点抽象成体系能力 | 项目实现要降级成案例，参数全部留在项目 |
| 中午 | 收尾自举从 “版本号加关键词检查” 升级为三类判据 | 上一版文档面没跟上机制面，门禁却全绿 |
| 下午 | 新增治理资产自适应调参这条轨 | 调参混在 “改规则” 里，没有独立边界 |
| 傍晚 | 修跨项目对齐硬门禁、SOP 扫描根、接入判级 | 上一轮进化暴露的闭环缺口 |
| 晚上 | 把 “一裁决一博弈”“旧额度退役” 回填进标准 | 项目里验证出来的两条经验 |
这五次升级没有一次是计划好的大版本，每次都是上一版跑出来的缺口推着下一版走。作者自己总结：外环不是 “想到了才做”，是被真实缺口推着走；缺口越具体，进化越准，缺口越抽象，进化越容易变成写文档。
自适应：只改数字，不改规则
自适应出现的原因很朴素：外环把结构改对了，结构里的数字还是初值。阈值当初是拍脑袋定的，跑了一个月，该发未发多少、不该打扰却打扰多少，账本里都有，不拿来调参等于白跑。
但调参最容易变成灾难，因为 “调参” 和 “改规则” 长得很像。把预算从两条调到三条是调参，把预算上限本身抬高就是改规则。两者一混，就会出现 “以调参之名，行改规则之实”，绕过人签。作者是被三个真实病灶逼出这条轨的：
- 参数长期无人观测：窗口内评估超时的默认值定得太短，冷启动实测慢很多，连续多个窗口的评估被静默跳过；
- 规则覆盖有盲区：一个关系很近但互动频率很低的对象，被 “未回不追加” 永久挡住，评估很多次一次候选都没产出来；
- 纪律执行有灰度：“评估每个窗口都跑” 被当成已生效，实际因为超时根本没跑，只验了 “代码在”，没验 “行为发生”。
三个病灶的共同点是：规则没写错，是没人持续看规则跑得怎么样。
自适应的闭环是七段，每段都有明确的防呆用意：
| 段 | 做什么 | 防的是什么 |
|---|---|---|
| 登记 | 每个可调数值一个稳定 ID，写清层级、可调性、指标、审批、节奏 | 两份真源打架 |
| 采集 | 每轮收束做确定性快照，机器聚合，不新增埋点 | 为调参再埋一套点，成本高到没人用 |
| 判定 | 每日或周期汇总，单次异常只登记，同一现象五次或连续三天才进候选 | 个案当趋势 |
| 提案 | 按两侧漏判率出候选：改哪个、改多少、依据、预期 | 只优化一侧，把另一侧推坏 |
| 回放 | 用既有账本重算改前改后，不改善就不落 | 没有回放，调参就是赌博 |
| 应用 | 带内单变量小步自主，写变更账本；带外或纪律类走提案加人签 | 多变量一起动，说不清谁起作用 |
| 验证 | 观察窗后两侧复核，变差回滚，改善固化并回灌 | 改完不看结果 |
三级覆盖这块是整篇文章里最值得抄的口径。自适应最容易自欺的地方，就是把 “登记了” 说成 “能自适应了”，所以它把覆盖拆成三级：
- 登记覆盖：每个数值资产都有 ID、都在册，既没有未登记项，也没有幽灵项（册子里有、代码里找不到的也算问题）；
- 观测覆盖：每个资产都绑了可读的指标组，绑了但读不出来的记为 “未验证”，不能当零；
- 自适应覆盖：能在授权带内自动调，而且有回放和回滚，三个条件缺一不可。
三级不能混报。只做到登记就写 “已登记、未观测”，只做到观测就写 “已观测、未启用自适应”。作者第一次普查时，登记覆盖全部、观测覆盖绝大多数、自适应覆盖是零，他说这个 “零” 不是失败，是诚实；一上来就报 “全覆盖”，反而说明口径有问题。
自适应能自主，但不是无限自主，边界由项目自己声明的授权带定义：哪类参数能动、动多少、窗口多长、一个资产窗口内最多改几次、观察期多久。带内自主，带外必须提案加人签。授权带只能收窄，不能用来绕过硬闸或纪律，预算和成本上限不能被自动抬高。
四条硬保护看起来笨，但它们决定自适应是 “校准” 还是 “折腾”：回放先行，没回放或回放显示变差就不许应用；回滚在位，回滚值必须等于旧值；单变量小步，一次只动一个资产；防震荡，同一资产窗口内变更次数有上限，观察期没满不许再改。
节奏也分三层：每轮只做确定性快照，零 token；每日一页纸汇总，五分钟读完；每三到五天做一次调参评审，才真正决定动不动。观察可以高频，决策必须低频，高频决策不是勤奋，是焦虑。
项目层与 OS 层：沉淀上去，骨架还回来
三层不是悬在空中的，它落在两个层上。项目层有真实压力：真实的对话、真实的打扰、真实的漏发、真实的参数。OS 层有抽象能力：标准、契约、机器闸、版本、案例索引。两层的关系不是交作业，也不是发标准，是双向循环。
项目经验进 OS 之前要过四问，哪一问答不上来就先不沉淀：
- 可泛化吗？换个项目、换个场景，这个方法还成立吗？
- 参数剥离了吗？维度、权重、阈值、预算，是不是都留在了项目里？
- 边界归体系了吗？红线、人签、硬闸、诚实降级的规则写清楚了吗？
- 有契约或机器闸能独立验证吗？还是只能靠一篇文档讲道理？
博弈这件事就是这么过的：项目里的四类、四维、权重、阈值全部留在项目，进 OS 的只有方法、边界类别、契约和机器闸，项目实现被降级成案例，明确标注 “仅供参考，不得复制为默认值”。
沉淀的产物有四种，缺一不可：标准规定 “怎么设计” 但不规定 “用什么维度”；契约规定 “记录长什么样” 但不规定 “记录里的数值”；机器闸规定 “什么算合格” 但不替项目做判断；案例索引规定 “哪里有参考实现” 但不把参考当默认。
反哺也有三种形态。定位反哺是把项目内约定写进标准，项目不用再争 “分数很高能不能破例”；契约反哺是让一条记录能回答四件事 —— 建议是什么、终决是什么、为什么不同、硬闸过了哪些，复盘时能分清是模型判断错了、参数要校准、还是临场做了不同选择；机器闸反哺是让项目不用自己证明 “我没乱来”，把策略和流水交给独立校验。
这里有个很关键也很诚实的点：OS 层自己不做自适应。OS 里的数值大多是硬闸、红线、代码常量，不是可调参数，要改就走外环加人签。如果 OS 把自身阈值也纳入自动调参，等于给自己开了一个绕开人签的后门，所以这条轨在 OS 层明确标 “不适用”，并写清理由。分工是：OS 给骨架，项目给数值；OS 管边界，项目管校准。
防两层失联也不需要大机制，双向指针就够：项目侧声明接入了哪一版、策略在哪、账本在哪、哪些机制不适用；OS 侧登记这个项目是哪个机制的案例、实现路径是什么、参数不作为默认值。没有指针的经验不算沉淀，没有回读的接入不算落地。
六种失败模式，比成功路径更有用
| 失败模式 | 典型表现 | 怎么防 |
|---|---|---|
| 内环空转 | 收束写得漂亮，经验栏永远是 “无”，提案永远是 “无” | 看内环候选有没有一条走到外环，永远为零就是形式主义 |
| 外环膨胀 | 一次踩坑加一条规则，规则只增不减，SOP 越写越长 | 过四问，换项目不成立、参数没剥离就不进外环 |
| 自适应越界 | 以调参之名删掉阈值维度、抬高预算上限 | 结构、判据、公式、阈值集合、硬闸、预算上限动任何一个都转外环 |
| 三级混报 | 对外报 “覆盖率百分之百”，一问细节一半资产没绑指标 | 三级分开计数，分母可复算，“不适用” 不等于通过 |
| 项目与 OS 失联 | OS 发了新标准项目三个月没接，项目改了策略案例索引还停在旧版 | 双向指针，发版广播、升级回读 |
| 把 “没做” 记成 “通过” | 检查跳过写 “通过”，项目没接入写 “无问题”，观察期没满写 “已验证” | 三态输出：通过、失败、未验证，未验证不许混进通过 |
最后这一种被作者称为最隐蔽，因为它会让整个系统产生虚假的安全感：你以为门禁全绿，实际是门禁没跑；你以为机制落地，实际只是文件存在。
想照着做，按这个顺序起步
作者对 “小项目要不要上全套” 的回答是不用，三层是能力菜单，不是准入清单。真要落地，可以按这个顺序走：
- 先只上内环：每轮结束写三行到一页纸收口，必须有证据、有下一步，先别急着改任何规则；
- 给候选一个出口：建一个带到期时间和验收标准的队列，跳过要写理由，十次内复发自动升级；
- 等信号再开外环：同类问题第二次、跨项目、撞边界、被人明确批评，才启动，改完必须留版本和回读；
- 结构稳定后再拆自适应：先把可调数值登记成册、绑上指标，能读出来再谈自动调；
- 一开始就备好回放和回滚：没有账本重算能力的调参，先不要放开自主；
- 覆盖率诚实报：登记、观测、自适应三级分开写，宁可写 “未启用”，也不要写 “全覆盖”。
不适合上三层的情况也很清楚：一个月只做几次决策，或者决策错了没什么后果，内环收口加人工判断就够了。值得上三层的场景有几个共同特征 —— 高频、对外、有真实副作用、需要长期变好。判断标准不是 “想不想做”，而是 “错了有没有代价、改对了有没有人负责”。
如果只带走一张检查表，作者给的是这张：
| 层 | 看什么 | 不合格长什么样 |
|---|---|---|
| 内环 | 有可判事件、有证据、有下一步 | 每轮写收束，但从不产生候选 |
| 外环 | 过抽象闸、有人签、有回读 | 一次踩坑加一条规则 |
| 自适应 | 有登记、有指标、有回放与回滚 | 以调参之名改结构 |
| 项目层 | 有声明、有案例、有数据回流 | 自造一套，不接 OS |
| OS 层 | 有标准、有契约、有机器闸、有案例索引 | 标准写死项目参数 |
再压成三句话：内环要有产出，不能只有记录；外环要有边界，不能只有热情；自适应要有证据，不能只有数字。
相关 FAQ
问题 1：小凝 Agent 的三层进化里，内环、外环和自适应分别管什么？
回答 1：小凝 Agent 的内环管单次任务的收口，每个任务结束就汇总、自评、记经验、提提案、复验、记账，只产候选不改规则；外环管一类问题的结构改造，改判据、流程、机制，必须人签加版本；自适应管规则里的数字校准，在观察窗内按授权带小步调参。三层分别回答 “这一次怎么样”“这一类怎么改”“这个数准不准”。
问题 2：小凝 Agent 的内环为什么不直接改规则，非要等外环？
回答 2：因为小凝 Agent 内环拿到的是单次任务的窄上下文，一次冷启动慢、一个对象没回，都是一次性信号，直接写进规则会让系统越来越敏感。所以内环只做三态裁决 —— 立刻做、入队等聚合、明确跳过，候选要满足同类第二次、三十天内复发、跨两个项目等条件才升级到外环，由外环统一改结构和判据。
问题 3：小凝 Agent 的自适应怎么区分 “调参” 和 “改结构”？
回答 3：小凝 Agent 的判定句只有一句：改 “规则怎么写” 是外环，改 “规则里的数” 是自适应。把阈值从高调到低是调参，把阈值这个维度删掉是改结构；把预算从两条调到三条是调参，把预算上限本身抬高是改结构。凡是动到结构、判据、公式、维度集合、硬闸、预算上限的，都不属于自适应，必须转外环加人签。
问题 4：小凝 Agent 的三层进化对普通团队有什么最小可复用版本？
回答 4：普通团队不必照搬小凝 Agent 的全套三层进化，可以先只做内环：每轮结束留下有证据的收口和下一步，建一个带到期时间的候选队列。等同类问题第二次出现再启动外环，改完留版本和回读；等结构稳定、有足够流水，再把可调数值登记成册、绑上指标，最后才放开授权带内的自动调参，并且一开始就备好回放和回滚。
问题 5：小凝 Agent 的三层进化最容易在哪翻车？
回答 5：小凝 Agent 的三层进化最常见的翻车点有三个：内环空转，收束写得很漂亮但从来不产生候选；外环膨胀，一次踩坑加一条规则，最后规则互相打架；自适应越界，以调参之名删维度、抬上限。还有一个更隐蔽的，是把 “没做” 记成 “通过”，检查跳过了却写通过，让整套机制产生虚假的安全感。
参考资料
- [2026-11-09]（小凝 Agent：一个 Agent 的三层进化 —— 内环、外环与自适应）博客园・月牙寂
- [2026-11-09]（小凝 Agent：一个 Agent 的三层进化 —— 内环、外环与自适应）阿里云开发者社区
- [2026-11-09]（小凝 Agent：给裁决加一层博弈 —— 项目与 OS 如何互相长大）博客园・月牙寂
- [2026-11-07]（小凝 Agent：从「人提醒才自检」到「每轮自己进化」）阿里云开发者社区
免责声明
本文基于公开博客与开发者社区文章的整理与解读，其中 “小凝” 为作者月牙寂（龚浩华）自述的个人 Agent 实践，三层机制、覆盖率、授权带参数与版本节奏均来自作者自述，未见第三方独立复现或评测；文中观点与做法不构成对任何产品、框架的评测、推荐或采购建议。读者若要照此实施，请以原文为准，并结合自身业务风险、合规要求与团队实际能力评估。