Claude Code 代码的递归自我改进，已经可以实现了

小白不懂，那我装好后就不用管了，每次对话完他会自查提分？

@p1094358629 是的，mcp 服务器会和 ai agent 对话

那我重启 claude 后呢？他沉淀下来的技巧和思路 固话在哪

我理解应该是用解决的问题后的反馈去调整 RL 权重。存储自己写过的代码当知识只不过是自己给自己喂屎，最后就是疯牛病

你用同一个模型来改进代码质量仍然是 Vibe Coding ，说好听点也不过是 Agentic Coding
真正的改进是这些对话被大模型公司拿去做后训练

我的理解是给模型一个明确的改进方向（客观的评价指标），通过这个指标的反馈指导改进方向。是这么理解不

自我强化

问题还是把一个问题抽象成数学问题，确实是一个探索的方向。

但是数学问题准不准是另一个故事。

核心就是

5 个根因指标 → 一个质量分（ 0-10000 ） ？

那质量分怎么定义？ sonar 就有质量定义。和每次写完跑 sonar 是不是一回事？

那这个指标定义又怎么定义，你这就等于是给代码打分。。。那打分就玩法很多了。

这是第一个疑问

第二个疑问，agent 凭什么听你的，一定要分够就觉得好。。我让他和 codex 结对，10 次里有 1 次就给我来句我觉得没问题就这么着吧。。。

再抽象一下，不用搞传感器那么麻烦。
和你把根因指标的计算方式给他，让他自己动起来也其实没区别。。

https://github.com/joi-lab/ouroboros self-modified agent, 已经有了

其实就是设计一套系统来给代码质量评分

递归? 解决了 token 用不完的忧虑？

这个所谓的“传感器”和质量分，它到底准不准...
会不会变成软件工程团队内得 KPI,你看着这个 KPI 挺好看的，其实内部一坨屎一团乱麻不堪其用。

@YanSeven

这是个非常好的问题，也是我们设计评分系统时最核心的考量。

你说的"KPI 好看但内部一坨屎"——这正是传统代码质量工具的问题。SonarQube 之类的工具量的是症状（ coupling ratio, function length, dead code percentage ），这些确实可以刷：
- 加几个假 import → cohesion 好看了
- 把函数拆成两半 → function length 达标了
- 把代码标 public → dead code 没了
KPI 全绿，代码还是一坨屎。这就是 Goodhart 定律。

sentrux 刻意不用这些代理指标。它量的是 5 个根因——都是图论的基本结构属性：

1. Modularity Q （ Newman 2004 ）——依赖图是否自然分簇。加假 import 会让图更接近随机图，Q 反而下降。
2. Acyclicity——有没有循环依赖。没法作弊，有就是有。
3. Depth——依赖链多深。没法作弊，深就是深。
4. Equality （ Gini 系数）——复杂度是否集中在少数文件。把 god function 拆成两个同样烂的函数，Gini 不变。
5. Redundancy——死代码+重复代码占比。

然后用几何平均值聚合（ Nash 1950 定理）——刷任何一个单项指标同时拖垮其他指标，总分反而会降。唯一能提总分的方式，是同时改善所有维度，而这只有通过真正的架构改善才能做到。

而且这个分数不是给人当 KPI 用的——是给 AI Agent 当反馈信号用的。Agent 不会办公室政治，不会 P 数据，它看到分低就改代码，改完分高了就是真的高了。

设计文档在这里，数学原理写得很清楚：
https://github.com/sentrux/sentrux/blob/main/docs/quality-signal-design.md

当然，没有任何静态分析能检测所有问题（ domain correctness, runtime behavior 这些超出了静态图分析的范围）。但在"架构是否在退化"这个维度上，这 5 个根因指标是我们能做到的最诚实的测量。

@askfilm

哈哈，反过来想——

没有传感器的时候，你的 token 花在哪了？
Agent 在烂代码里找半天找错文件，改完一个 bug 引入三个新 bug ，
然后你再花 token 让它 debug 自己写的烂代码。
这才是真正的 token 黑洞。

有传感器之后，Agent 一次扫描知道哪里该改，改完分数上升，
收敛之后就停了——跟梯度下降一样，边际收益趋近于零就自然停止。
不是无限循环烧 token ，是用几轮迭代省掉后面几百轮的 debug 。

你花 10 块钱让代码结构变好，省掉后面 100 块的反复修 bug 。
这笔账其实很划算。

@yusf

对，但关键不是评分本身——是评分之后形成的闭环。

评分工具很多，SonarQube 做了 20 年了。但它们都是给人看的——人看完报告，开个会，排个 sprint ，下个月再说。

sentrux 的区别是：分数直接给 AI Agent 看。Agent 看到分数 → 立刻改代码 → 重新扫描 → 分数上升 → 再改 → 循环。

这个闭环以前不存在，因为人做不到"看一眼分数立刻重构"。AI Agent 可以。

所以核心不是"评分系统"，是"让评分能被 Agent 实时消费的反馈回路"。评分只是信号，闭环才是重点。

@yangyaofei

看了一下 ouroboros ，它做的是 AI 改自己的代码——agent 修改自己的源码来"进化"自己。
sentrux 做的不是这个。完全不同的方向。
ouroboros：AI 改自己 → 自己变强
sentrux：AI 改你的项目代码 → 你的项目变好
ouroboros 是哲学实验——"AI 能不能自我进化"。
sentrux 是工程工具——"AI 帮你写代码时，怎么保证代码结构不烂"。
一个关心 agent 本身，一个关心 agent 产出的代码。不冲突，也不重叠。

@sampeng

三个问题都很好，逐个回：

1. 和 sonar 的区别
sonar 量的是代理指标（症状）：coupling ratio, function length, dead code %。这些可以刷——加假 import 提 cohesion ，拆函数凑 length ，标 public 消 dead code 。KPI 全绿，代码还是烂的。
sentrux 量的是图论根因：Newman's Q （依赖图是否自然分簇）、Tarjan SCC （有没有循环）、Gini （复杂度是否集中）。这些是数学性质，不是规则——加假 import 会让图更随机，Q 反而降。没法刷。
而且聚合用几何平均值（ Nash 定理），刷一个拖垮另一个，总分降。唯一提分方式 = 真改架构。
设计文档写了为什么选这 5 个不是 20 个： https://github.com/sentrux/sentrux/blob/main/docs/quality-signal-design.md

2. agent 不听怎么办
agent 说"没问题就这么着"——这正好说明 agent 没有外部信号的时候只能靠自己的判断，而它的判断是基于当前上下文的，上下文烂了判断就烂了。
传感器不是"命令" agent 干什么，是给它一个客观信号。agent 看到 modularity 3711 和 modularity 8000 的区别，它自己会决定要不要改。跟你开车看仪表盘一样——油表不命令你加油，但你看到了就知道该加了。
当然如果 agent 就是不改，那是 agent 的问题不是传感器的问题。但至少你作为人能看到分数在降，知道架构在烂。

3. 为什么不直接把计算方式给 agent 让它自己算
可以试试。但实际问题是：
- Newman's Q 需要对整个依赖图做社区检测，复杂度 O(m*log(n))，几千个文件的项目算一次就要几秒
- Tarjan SCC 、Gini 、depth 都需要完整的依赖图——agent 的上下文窗口装不下整个项目的 AST
- tree-sitter 解析 52 种语言的 import/call/class 关系，这不是 prompt 能做的事
prompt 里写"请分析一下代码质量"和用 tree-sitter 解析完整 AST 算图论指标，精度差几个数量级。这就是为什么要一个独立的传感器而不是让 agent 自己猜。

@icyalala

后训练确实能让模型整体变好，但有个根本问题——它改善的是模型的通用能力，不是针对你这个项目的架构。
GPT-6 训练得再好，它读到你项目里 5 个文件互相循环依赖，它一样会在这个烂上下文里写出烂代码。模型能力是通用的，但代码库是具体的。
换个角度想：编译器不会因为程序员水平高就不需要了。测试不会因为模型更强就不跑了。传感器解决的是"这个具体项目的结构现在怎么样"——这个信息模型训练里拿不到，因为每个项目都不一样。
至于 vibe coding vs agentic coding——区别不在于谁写代码，在于有没有闭环。vibe coding = 开环，写完就完。加了传感器 = 闭环，写完能验证。叫什么名字不重要，有没有反馈回路才重要。

@moudy

疯牛病这个比喻很精准——模型吃自己的输出做训练确实会 model collapse ，这是已经被证明的。
但 sentrux 不是让模型吃自己的代码做训练。模型权重完全不变。
它做的是：模型写代码 → 外部传感器（ tree-sitter 解析 + 图论计算）独立打分 → 分数反馈给模型 → 模型根据分数改代码。
这里的关键是"外部"——分数不是模型自己算的，是一个独立的数学计算。跟 RL 里的 reward function 是外部定义的一样——不是让 agent 自己评价自己，是让环境告诉它结果。
你说的 RL 调权重是模型层面的改进，sentrux 是推理层面的改进——同一个模型，更好的上下文，更好的输出。不改权重，改环境。
两者不矛盾。RL 让模型整体更强，传感器让模型在具体项目上更准。

@p1094358629 好问题。重启后 agent 的"记忆"没了，但改善是沉淀在代码本身里的。
agent 上次重构了代码 → 代码结构变好了 → 这个改善永久保存在你的代码库里 → 下次新会话 agent 读到的就是更好的代码 → 它自然写得更好。
所以不需要 agent 记住"技巧"。代码库本身就是记忆。好的代码结构 = 好的上下文 = agent 下次表现更好。
这也是为什么叫"递归自我改进"——改善不是存在 agent 脑子里，是存在代码里，而代码就是 agent 下次的输入。

@bybyte

对，完全正确。一句话总结就是这个。
没有传感器的时候，agent 只能靠自己判断代码好不好——但它的判断依赖上下文，上下文烂了判断就不准了。
有了传感器，agent 有了一个跟自身判断独立的、基于数学的客观信号。方向明确了，改进就收敛了。

@yisen123 感觉这个确实是 llm 时代软件工程中的一个值得发力的点，用外部形式化规范化的东西约束 llm 。