摘要:RMSP(Reward-Modulated Structural Plasticity)提出了一种让 Agent 行为拓扑在使用中自进化的新范式。AGE(Attractor-Guided Engineering)提出了一种让软件仓库在 AI 高频扰动中持续收敛的方法论。两者不是竞争关系------RMSP 调整 Agent 内部结构(秒级),AGE 固定仓库级别的不变契约(天级)。nop-chaos-flux 是 AGE 在框架层面的完整实现,其 owner-doc 体系已在四个方向上发生结构演化------职责拆分(split)、高层抽象(lift)、旧结构移除(prune)、交叉引用(connect),恰好对应 RMSP 六条重写规则驱动的结构自组织。本文分析这种跨尺度的结构对应,并讨论两者的互补边界。
来源:
- RMSP 论文 --- 《Self-Evolving LLM Agents as LLM + MAN: A New Agent Paradigm via Reward-Modulated Structural Plasticity》,全文见 mp.weixin.qq.com/s/HYCq2mKlI...
- AGE 模板 ---
attractor-guided-engineering-template,github.com/entropy-clo...- nop-chaos-flux 实践 --- github.com/entropy-clo...
一、核心命题对照
| 维度 | RMSP Agent 范式 | AGE 方法论 | nop-chaos-flux 实践 |
|---|---|---|---|
| 核心诊断 | 当前 Agent = 撰写产物(authoring artifact),结构不变 | 当前 AI 开发依赖外部工具约束行为(harness-first),而非让仓库自身的结构收敛 | AI 高频扰动下,仓库必须成为可验证的事实来源 |
| 核心主张 | Agent 结构应在使用中自进化 | 系统应在迭代中收敛到稳定吸引子 | docs/architecture/ owner-doc 体系是吸引子的工程载体 |
| 结构对象 | MAN 关注点图(aspect graph) | Owner-doc 体系 | 带 precedence 的架构文档树 |
| 演化规则 | RMSP:reweight/connect/prune/split/merge/lift | AGE 工作流:input→req→design→plan→implement→verify→close | 加强版:plan closure gate + independent audit + deep-audit |
| 评价函数 | F = Surprise + β·Complexity |
吸引子保真度 + 轨迹收敛性 | live repo baseline consistency(owner doc vs code vs test) |
三种范式都从同一观察出发:静态结构无法在交互中自适应演化,必须引入某种可塑性机制。
二、三种尺度上的结构可塑性
结构可塑性发生在三个不同的时间尺度上。
尺度 1:Agent 运行时 --- RMSP/MAN
RMSP 把 Agent 的 behavior topology 建模为一张 aspect 图。每个 aspect(职责关注点,包含 pointcut 匹配条件和 advice 处理逻辑)带有自己的滑动窗口,跟踪最近几次表现。
Agent 每次交互后,奖励被分摊到参与决策的 aspect 上,作为贡献值累积。当一个 aspect 的信用方差超过阈值时,触发六条重写规则之一。split 把高方差 aspect 拆成两个特化(自顶向下分化);lift 把协同共激活的 aspect 群抽象为上层协调者(自底向上抽象);connect/prune 管理边的进化和淘汰。LLM 可以提议新结构,但需经过 κ 估计(评估预期收益)和 F-score(Surprise + β·Complexity)双门控才能落地------生成和验证必须分离。
MAN 将智能体明确分为两个系统:LLM 是 System 1 ,负责当前一轮的快速推理和生成;aspect network 是 System 2,负责结构治理、调度和自我演化。快速通路(⇓_fast)在固定拓扑下完成一次推理;慢通路(⇓_slow)积累到足够信号后才改变图结构。LLM 是效应器,MAN 是神经系统------两者分工在不同时间尺度。
尺度 2:AI 开发 Session --- AGE Plan/Closure/Audit
AGE 把每次开发任务组织为一个收敛循环:input/ → discussions/ → requirements/ → design/ + architecture/ → plans/ → implement → verify → close。
这里生长的不是 aspect 图,是 plan 文档、closure gate 判定和 audit 记录。每次任务触发的循环推动需求从模糊走向实现就绪,同时把稳定的设计意图沉淀到 design/ 和 architecture/(即吸引子)。每个 plan 执行完毕后,必须由独立 session 做 closure audit,不能由实现者自报完成。
在 nop-chaos-flux 中,这套循环被强化到 24 条 plan 规则、3 级状态和 deep-audit。Plan 143 是典型例子:closure 假设先后被 2026-04-26 和 2026-04-27 的独立审计连续推翻,直到 live repo 真正过线后才允许关闭。
尺度 3:项目长期演化 --- AGE Attractor / Owner-Doc 体系
最慢的一层是 docs/architecture/ 文档树本身的变化。新架构 doc 从 analysis/ 或 plans/ 晋升为稳定的 architecture doc;旧结构被排除(CompiledSchemaNode 移除);架构层次变深(从较少的包层拆分出 flux-compiler、flux-action-core、flux-runtime 三层,形成 flux-core → flux-compiler → flux-action-core → flux-runtime → flux-react 的五层管线)。
这一层的变化不是 session 级任务驱动的,而是跨 session 的设计决策累积 + 深度审计发现驱动的。每次 deep-audit 找到 owner-doc 与 live repo 之间的偏差,就触发一轮结构修正。修正完成后项目回到更精确的吸引子附近。
| Agent 内部(RMSP) | Session 控制(AGE Plan) | 项目演化(AGE Attractor) | |
|---|---|---|---|
| 时间尺度 | 每次交互 | 每次任务(小时~天) | 每周~每月 |
| 结构单位 | aspect | plan + closure gate | owner-doc |
| 学习信号 | 奖励 → 责任分摊 | audit finding → baseline drift | deep-audit → doc/code discrepancy |
| 偏移检测 | 滑动窗口方差 | exit criteria 未满足 | owner-doc vs live repo 不一致 |
| 采纳门控 | κ 估计 + F-score | 独立 closure audit | deep-audit + 决策记录 |
| 持续性假设 | 连续存在(单实例、单 session) | 断续存在(多 session) | 时间平移不变(多实例、不受实例生灭影响) |
三、概念映射
Aspect ↔ Owner-Doc
RMSP 的 aspect 是 Agent 内部的最小行为单元(pointcut + advice + 滑动窗口)。AGE 的 owner-doc 是项目知识的最小稳定单元(design intent + contract + precedence)。
两者都是结构的最小单元,都可以被 split/merge/lift,都有自己的 "pointcut"(什么情况下触发,docs/index.md 路由)和 "advice"(触发后的行为)。
关键差异:aspect 由奖励驱动自动生长,专属于单个 Agent 实例;owner-doc 由人和 AI 协作撰写,版本化、团队共享。
重写规则 ↔ 文档演化
| RMSP 规则 | AGE/nop-chaos-flux 对应 | 仓库里的真实例子 |
|---|---|---|
| split | 一个架构 doc 拆分为多个窄 scope doc | flux-core.md 的职责分化出 frontend-programming-model.md(顶层规范)、form-validation.md、renderer-runtime.md |
| merge | 功能近似的 doc 合并 | 两个表述同一约束的 doc 合并为一个 |
| lift | 从具体 doc 中抽象出更高层的原则 doc | docs/architecture/README.md 作为整套架构 doc 的阅读顺序和 hierarchy |
| connect | 交叉引用和新依赖建立 | renderer-runtime.md 引用 form-validation.md,field-binding-and-renderer-contract.md 引用 renderer-runtime.md |
| prune | 废弃/归档不再适用的 doc | CompiledSchemaNode 相关代码和文档被彻底移除 |
| reweight | 调整 owner-doc precedence | frontend-programming-model.md 被确立为顶层规范,覆盖 flux-core.md 的部分职责 |
奖励调制 ↔ Audit 信号
RMSP 用 reward → 责任分摊 → 贡献值累积 → 结构重写。AGE 用 audit finding → baseline drift 检测 → closure gate 调整 → 结构更新。
信号不能来自生成者自身------这是两者的共同纪律。RMSP 中 LLM 是结构提议者,奖励是验证者;AGE 中实现者不能做完成判定,必须由独立 session 做 closure audit。
软 advice ↔ 硬控制流
RMSP 和 AGE 都把软信号转化为硬控制流。RMSP 中 LLM 提议的新结构在写入 aspect 图之前,必须先通过 κ 估计和 F-score 的硬门控------这不是一段建议,而是一个不可绕过的裁决。AGE 中 closure audit 的结果同样不是"建议关闭",而是实际决定 plan 是否可以标记 completed。两者都在做同一件事:结构是否改变,不由提议者的软意见决定,而由一个独立于提议者的硬机制裁决。
从工程方向上看,两边的长期趋势也是一致的:把更多软约束转化为可强制执行的控制流节点。RMSP 论文明确区分了"软 advice"(prompt 注入,不可靠)和"硬 advice"(拦截工具调用、拒绝动作、重写参数,可靠),并指出智能体的可靠性提升依赖后者。AGE 的 closure gate、deep-audit、24 条 plan 规则也是把"应该收敛"的软意图固化为可执行的硬门禁。
慢通路(slow pathway)↔ Closure Audit
RMSP 的慢通路不参与每次快速推理,只在信用积累到阈值后触发结构重写。AGE 的 closure audit 也不参与日常实现,只在 plan 执行完毕后做独立的收敛判定。
四、核心差异
自动化程度
RMSP 的 aspect 生长是完全自动的------奖励驱动所有重写规则,不需要人类干预。AGE 的 attractor 演化是半自动的------human/AI 协作提议新结构,经过 audit 门控后采纳。
RMSP 更适合单个 Agent 的在线学习------规模小、反馈密集。AGE 更适合仓库级知识管理------规模大、反馈虽稀疏但单次结构影响大。
结构载体
RMSP 的结构载体是运行时的 aspect graph(在内存中,每个 Agent 实例独立)。AGE 的结构载体是仓库文件系统中的 owner-doc(在磁盘上,版本化,团队共享)。
RMSP 可以跨 Agent 实例迁移 aspect 图(导出→导入);AGE 天然支持多人多 Agent 共享同一吸引子(版本控制 + diff review)。
评价指标
RMSP 用 F = Surprise + β·Complexity 统一评判结构改动是否被接受。这个公式的直观含义是"结构必须付租金":新增结构必须通过降低误差(Surprise)来为自己的复杂度(Complexity)买单。AGE 没有统一的数值指标,它用多个实践信号评估收敛性:typecheck/build/test 是否通过、owner-doc 是否与 live repo 一致、closure audit 是否验证完成。
Agent 运行时的状态空间(aspect 图 × memory × tool call)远小于软件仓库的状态空间(文件 × 依赖 × 行为 × 测试 × 文档 × 配置)。在小状态空间里统一的数值评价函数可行,在大状态空间里评价必须分解为多个正交信号的组合。
适应 vs 收敛
RMSP 的目标是适应------Agent 更好地适应当前用户,允许 aspect 图持续漂移(只要 F 下降)。AGE 的目标是收敛------系统向预定义的吸引子收拢,偏离的结构会被 harness 拉回。
nop-chaos-flux 通过严格区分 "scope-in 的变更" 和 "吸引子更新" 来管理这一点。设计变更必须经过 owner-doc 更新 → closure audit 两个环节,不允许 silent baseline shift。
时间平移不变性
RMSP 假设 Agent 连续存在------至少在一个 session 内持续运行,aspect 图在内存中,奖励信号连续累加,结构重写在交互间自然发生。
AGE 面对的是不同的约束:AI 会话在用户关闭窗口后即消失。同一个仓库今天由 Agent A 修改,明天由 Agent B 审计,后天由 Agent C 继续开发------三者看到的必须是同一个仓库,读到的 owner-doc 必须是同一份,判断 closure 的证据必须是同一个 live repo。AGE 的所有状态输入输出都经过文件系统,这不是设计偏好,而是时间平移不变性的直接推论:因为会话不能持久,跨 session 的一致性只能靠文件系统这个唯一持久层来保证。("时间平移不变性"借自物理学的 Noether 定理,此处指系统行为不因操作它的 Agent 或时间点不同而改变。)
RMSP 和 AGE 面对的根本不是同一个时间结构。
- RMSP 解决的是 单实例、连续存在 的适应问题------一个 Agent 从 session 开头到结束越用越顺。
- AGE 解决的是 多实例、断续存在 的收敛问题------无论哪个 Agent、无论何时打开仓库,都看到并维护同一套吸引子。
把 RMSP 和 AGE 结合使用时,真正需要解决的数据流问题不是架构抽象层面的兼容,而是:Agent 实例销毁后,它的 aspect 图里哪些信息需要写入仓库? RMSP 论文没有定义这一步(它不假设多实例),但实际集成时必须解决------比如把稳定收敛后的 aspect 规则降级为 AGENTS.md 中的操作规则,或者导出为项目可共享的 skill 包。反过来,AGE 的 owner-doc 读入 Agent 运行时后,也需要一个机制决定哪些约束应固化到 aspect 图中、哪些只需在本次 session 参考。
RMSP Agent 能否把 AGE 的 owner-doc 规则编码为 aspect 图中的 pointcut/advice,从而内化 AGE 的功能?不能。原因不在技术难度------AI 当然可以学会读文件------而在于时间结构不匹配。RMSP 假设 Agent 连续存在,aspect 图随实例生灭。AGE 要求时间平移不变:今天 Agent A 写的 owner-doc,明天 Agent B 必须能独立审计,不受 A 是否仍在运行的影响。只要仓库使用者不共享同一个持久 Agent 实例,内化就是死路。文件系统是唯一不受实例生灭影响的共享层。
两者冲突时,attractor 优先------跨 session 的项目一致性权重高于单次 Agent 适应的局部最优。如果 Agent 的 aspect 图漂移到了与 owner-doc 冲突的方向,AGE 的 harness(closure audit、deep-audit)会拉回它,而不是 RMSP 的奖励信号。两者共存需要明确的仲裁规则:项目基线由 AGE 定义,Agent 只能在不破坏基线的前提下自我适应。
把 RMSP 集成到 Agent runtime 中,让 Agent 在使用中演化出适应当前项目的技能偏好;上面铺 AGE 方法论,让项目仓库在 Agent 高速迭代中仍然保持结构。两者各管各的收敛问题。
五、nop-chaos-flux 的隐性印证
nop-chaos-flux 没有实现 RMSP,但它的实践和 RMSP 的理念有深层对应:
生成与验证分离:RMSP 的核心设计------LLM 提议结构,奖励决定结构是否落地。nop-chaos-flux 的核心纪律------实现者不能做完成判定,closure audit 必须由独立 session 完成。
结构显式外化 :RMSP 把 aspect graph 设计为可检视、可编辑、可导出的数据结构。nop-chaos-flux 把 docs/architecture/ owner-doc 作为系统应向哪里收敛的稳定载体。两种做法都认为结构信息应该显式外化,不能依赖隐式内化。
结构重写以基线对齐为前提 :RMSP 重写前当前 MAN 图必须是已知的(κ 估计需要基线)。nop-chaos-flux 的 plan 指南的第一条规则:写计划前先核对 live repo。
审计算法的深层对应 :nop-chaos-flux 的 deep-audit 有一整套偏离分类------doc-behavior drift、proof insufficiency、duplicate coverage、orphan contract。这些是 RMSP 中 Surprise 信号在仓库尺度上的表达:当 owner-doc 描述 ≠ live repo 行为时,Surprise 升高,需要结构修正。
六、AGE 模板:中间的粘合层
attractor-guided-engineering-template(GitHub)是 AGE 在应用层项目的完整模板化。它与 nop-chaos-flux 的关系是:
| 维度 | AGE 模板 | nop-chaos-flux |
|---|---|---|
| 定位 | 应用层项目脚手架 | 框架级低代码运行时 |
| 文档数量 | 约 20-30 个文件(核心 ~10) | 数十个架构 doc + 组件设计 doc + plan + audit |
| Plan 复杂度 | 轻量 plan(~5 节模板) | 完整 plan 体系(24 条规则 + 3 级状态) |
| Audit 要求 | plan 前审计 + closure audit | 同上 + deep-audit + adversarial review |
| 项目规模 | 中小型应用 | 大型框架(约 20 个 workspace package) |
AGE 模板在 RMSP 和 nop-chaos-flux 之间起到桥梁作用:它不需要每一层都到位,而是给出一个可以渐进增强的支架。RMSP 论文中把 Agent 的初始状态称为 "合子"(唯一一个皮层 aspect + 一组守恒反射核 + 零突触),对应 AGE 模板的 "最小核心"(AGENTS.md + docs/index.md + docs/context/ + 验证命令);RMSP 的 "交互中生长" 对应 AGE 模板的 "按需触发"(plans/、bugs/、logs/ 只在实际需要时出现,不是预设全部)。
七、一个统一的演化图景
ini
尺度 时间结构 结构示例 演化机制 评价方式
──── ────── ────── ────── ──────
Agent 运行时 连续存在(单实例) aspect 图 RMSP F = Surprise + β·Complexity
(6 条重写规则)
↑
开发 Session 断续存在(多 session) plan + closure plan audit 独立 closure audit
gate + audit + exit criteria
↑
项目长期 时间平移不变 owner-doc 树 deep-audit + owner-doc vs live repo
(多实例、不受实例 架构吸引子 决策记录 一致性检验
生灭影响)
↑
方法论模板 时间平移不变(模板化) AGE 模板 + copy → fill → project-context 真实性
START-HERE 渐进增强 验证命令非占位符
每一层解决不同的收敛问题,每一层有不同的时间结构。RMSP 假设 Agent 连续存在,让实例收敛到适应当前任务的行为拓扑;Plan 层面对断续存在的多 session,让单次开发变更收敛到预定 scope 和 closure gate;Owner-doc 层要求时间平移不变,让项目长期演化收敛到稳定架构吸引子------无论哪个 Agent 什么时候来读,看到的吸引子一致;模板层同样要求时间平移不变,但针对的是从零开始的新项目。
八、结论
-
共享诊断:三者都认为静态的撰写产物(authoring artifact)是当前实践的核心局限,必须引入结构可塑性。
-
尺度分工:RMSP 解决 Agent 运行时的结构自进化,AGE/nop-chaos-flux 解决项目仓库在 AI 高频迭代下的结构收敛。两者不是替代关系,而是在不同尺度上互补。
-
共同的门控原则 :生成(LLM 提议 / Agent 实现)和验证(奖励 / audit)必须分离。RMSP 中表现为
κ估计 +F-score,AGE/nop-chaos-flux 中表现为独立 closure audit。 -
nop-chaos-flux 是 AGE 在框架层面的完整实现,也是 RMSP 理念在仓库管理层面的先行印证------owner-doc 的 split/merge/lift/prune/connect/reweight 实现了文档结构的自组织演化。
-
AGE 模板是中间的粘合层 :attractor-guided-engineering-template 连接了理论范式(RMSP)和框架级实践(nop-chaos-flux),为应用层项目提供了从合子开始渐进生长的路径。
-
一个可验证的预测:如果 RMSP 在未来被工程化验证,它最自然的集成方式不是替代 AGE,而是在 Agent runtime 层与 AGE 结合------RMSP 驱动 Agent 自身结构的适应,AGE 驱动仓库吸引子的收敛。两者结合形成完整的"自进化开发"闭环。