yisen123

@HeyWeGo 你好，刚刚网页已加入了极细的线帮助阅读，谢谢反馈！

@HeyHudy 很酷！！

@xxlsize 主要的价值是给出代码质量分数，ai agent 有了这个分数以后从 mcp 获取，可以改进代码质量

@zhady009 你好，可以先用桌面版测试一下， 桌面版测出来是好的，这可能是 rust 以及 webassembly 的一个 bug ，我们正在修复网页版中，桌面版是好的

@009694

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

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

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

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

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

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

@bybyte

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

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

@moudy

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