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 。

@yisen123 我知道你的意思，让 ai 能拿到代码工程质量的反馈，我提几个我自己的看法；我觉得你可以改成 skill + cli 的方式，我感觉现在 mcp 这套不够友；我自己其实拿 codex 试了下，确实帮我列巨了不少问题，但是我目前担心的点其实我怎么能保证列举的点确实符合我项目的工程要求呢? 比如有的项目 feature-first 有的项目 type-> schema -> repo -> service -> ui 分层，可能有时候在你这套打分系统被评判为低分的，在我个人项目就应该这样写，所以我觉得其实还需要脱离你这套评价体系，使用类似于 sub-agent 来对你系统反馈出的问题在根据项目结构来进行一个修改的必要性评判，或者这个打分体系需要用户来参与（比如支持 prompt ，但是这样复杂性会提高）

你的评分器是一个悖论。 如果评分器的分数能决定代码好坏（非 lint 层面） 那么这个评分器自己就能按照更优的结构去改进 而不需要引入大模型

/, codex 现在这么不配么? 其他的支持都写了, 唯独它被归到 any MCP 里了.

点赞. 方向认可, 思路还有待检验. 持续关注. 感觉跟 Karpathy 的 AutoResearch 核心思路有些想通. 如果要降低 AI 的接管率, 那么就一定需要一个可量化的标准, 不然 AI 没办法针对你的项目做自我提升或者选择相对优解.

@yusf 说得很好，几个点回一下：

MCP 不够友好这个认同，我们在考虑更轻量的接入方式。

关于"低分但在我项目就应该这样写"这正是为什么我们只量根因不量规则。sentrux 不会说"你的函数太长"或"耦合太高"这种主观判断。它量的是图论属性：依赖图是否有环、模块是否自然分簇、复杂度是否集中。这些是数学事实不是风格偏好不管你是 feature-first 还是分层架构，循环依赖就是循环依赖，god file 就是 god file 。

但你说的"项目自己的工程要求"确实是需要的这就是规则引擎做的事。你可以在 .sentrux/rules.toml 里定义你项目的架构约束，比如哪些层不能依赖哪些层、最大允许循环数。这部分是你定义的，不是我们定义的。

至于 sub-agent 来评判修改必要性我觉得这个应该是 agent 自己的判断，不是传感器的职责。传感器只负责给信号，agent 自己决定要不要改、怎么改。跟温度计一样，温度计不决定你要不要开空调。

@009694

这不是悖论，这是 P vs NP 。
检测循环依赖 = O(V+E)，Tarjan 算法跑一遍就知道 A→B→C→A 有环。
修复循环依赖 = 要理解代码语义才能决定：是让 A 不依赖 B ？还是 B 不依赖 C ？还是抽一个共享模块 D ？ D 里放什么？
测量是多项式时间的，改进是需要语义理解的。温度计能告诉你 39 度发烧了，但不能开药方。开药方需要理解发烧的原因，不是量个温度就行。
这正是为什么需要大模型传感器负责"发现哪里有问题"，大模型负责"理解代码语义然后决定怎么改"。两个能力不在同一个复杂度层面上。

@yisen123 #16 我觉得是一样的,只不过是目标不一样(loss 不一样, rl 的 reward 不一样), 剩下的都一样, 证明了可以这么做. 每个工程/软件/或者叫别的什么 的这个 loss 是不一样的, 只要能定义, 就没什么区别了