夜雨聆风大家好，我是疯信子。
这两年用 Agent 最让人崩溃的地方，不是它不会干活。
恰恰相反，它经常能把一件事跑通一次。真正麻烦的是：同一个错误，它会一遍又一遍地犯。
你给它补提示词，它下次还是漏步骤。
你给它写记忆，它换个场景又忘了。
你把 Skill 改得更细，它还是在某个工具调用、路由、状态同步、结果汇总的地方翻车。
这时候很多人会继续往 prompt 里加字：
“请你谨慎。”
“请你检查。”
“请你不要遗漏。”
但我后来越来越确定一件事：有些 Agent 的问题，根本不在它“想没想明白”，而在系统底盘本身就没接住。
你以为是在改一个聪明助手的性格，其实应该修的是它的工作流和执行框架。
最近看到一篇 arXiv 论文，标题叫《MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems》，编号是 arXiv:2605.22794。
这篇论文真正让我警醒的，不是“AI 终于能自己改自己了”这个噱头。
而是它把一个问题说得很直：
过去很多所谓 Agent 自我进化，改的是 prompt、skill、memory、workflow graph 这些文本层东西。但如果问题发生在 harness，也就是 Agent 背后的路由、hook 顺序、状态管理、工具调度、会话生命周期里，光改文本是够不到的。
这句话很关键。
因为真实业务里的 Agent，越往后越不是一个聊天框，而是一套执行系统。
一套执行系统出错，未必是模型不够聪明。
可能是工具返回结果没被正确标注。
可能是多工具调用时只处理了第一个结果。
可能是 hook 顺序错了。
可能是调度层把几个信息混成一坨，导致后面的 Agent 根本分不清来源。
这类问题，你让模型“下次注意”，意义不大。
因为它不是注意力问题，是系统结构问题。
真正厉害的，不是让 AI 更会道歉，而是让失败能变成一次可验证的系统升级。
MOSS 做的事情，可以简单理解成：它不是让 Agent 随便改自己，而是给 Agent 的“自我改造”加了一整套受控流程。
先收集失败证据。
不是凭感觉说“最近表现不好”，而是从真实生产会话里，把弱回答、漏回答、用户不满意的片段攒成一批失败样本。
然后开始定位。
先看这些失败到底像不像同一类问题，问题可能落在哪个系统层：是 prompt 没讲清楚，还是工具结果处理有缺口，还是路由、状态、调度出了问题。
接着做计划。
这里不是直接动代码，而是先写清楚：要改哪些文件，要补什么逻辑，哪些地方不碰。
计划之后还有计划审查。
也就是说，系统先判断这个方案是不是找错方向了，是不是改得太窄了，是不是会碰到不该碰的东西。
审查通过，才进入实现。
实现也不是由 MOSS 自己胡乱写，而是把代码修改交给一个可插拔的外部 coding-agent CLI 去做。MOSS 控制流程、阶段和 verdict，coding agent 负责具体代码改动。
实现完还有代码审查。
这个审查看的不是“有没有写出来”，而是 diff 是否符合计划，有没有越界，有没有引入不必要的变化。
再往后才是任务评估。
候选版本会被构建成镜像，在临时容器里回放之前那批失败任务。这个点很重要：不是在生产环境里赌，也不是只跑几个单元测试就自信上线，而是在隔离的 trial worker 里复现真实失败场景。
最后才给 verdict。
结果可能是 CONVERGED，也就是这批问题已经收敛；也可能是 NEED_MORE_WORK；还可能判断为模型能力上限，或者当前架构根本解决不了。
这套流程里，最值得普通团队学习的其实不是“源码级自我重写”这几个字，而是它对风险的态度。
MOSS 没有把自我进化包装成魔法。
它做了几件非常朴素、但非常关键的事：失败证据要成批，定位和计划要分开，计划要审查，代码要审查，验证要隔离，上线要授权，替换要能回滚。
论文里讲到，候选版本通过验证后，也不会自动替换主容器。
它需要用户授权。
用户确认后，host daemon 才会做 in-place container swap，也就是在保留用户状态卷的前提下替换容器。替换后还有 90 秒健康检查窗口，每 5 秒采样一次，连续健康才算通过，不通过就回滚到 last-known-good image。
这才是我觉得这篇论文真正有价值的地方。
它没有把“AI 改自己”讲成一种失控的科幻感，而是把它放进了工程治理里。
受控进化，才是重点。
论文里有一个 OpenClaw 的结果也很值得看。
在四个任务上，MOSS 把 mean grader score 从大约 0.25 提升到了 0.61。表格里更精确的数字，是从 0.2526 提升到 0.6100。
最大的一项提升到了 0.9049。
这个数字不能被过度神化。
它来自一篇 preprint，评测范围也有限：四个 OpenClaw 任务，一个受控 case study，不代表所有 Agent 系统都能这样一键起飞。
但它说明了一件事：当失败真的来自系统底层，源码级修复确实可能比继续堆 prompt 更有效。
这和我们平时用 Agent 做项目很像。
很多团队一开始会把 Agent 当员工培养：给它写 SOP，写记忆，写规范，写禁令。
这当然有用。
但用到后面你会发现，Agent 不是只靠“教育”就能变稳定的。
它还需要制度。
需要任务卡。
需要审查点。
需要工具边界。
需要运行日志。
需要可复现的失败样本。
需要在错误重复出现时，把经验从聊天层沉淀到工作流层，必要时再沉淀到代码层。
这也是我一直强调的那句话：工具只是放大器，流程才是底盘。
如果底盘是乱的，强模型只会更快地放大混乱。
如果底盘是稳的，Agent 才有机会从“能干活”变成“能长期交付”。
当然，源码级自我改造这件事，绝对不能理解成“让 AI 随便改自己”。
这条路一旦走偏，风险比 prompt 改坏大得多。
因为 prompt 写错，最多是下一轮表现变差；源码改坏，可能影响权限、数据、路由、状态、甚至整个服务可用性。
所以它必须有边界。
用户授权是边界。
隔离验证是边界。
审计日志是边界。
回滚机制是边界。
权限控制也是边界。
没有这些边界，所谓自我进化就是危险操作。
有了这些边界，它才可能变成企业真正敢用的 Agent 治理能力。
如果你现在在公司里用 Agent，我建议别急着追“能不能让 AI 自动改源码”。
先把下面这几件事补起来。
把重复失败记录下来，不要只在群里吐槽“它又错了”。
把失败分层：到底是模型理解问题、提示词问题、Skill 问题、工具问题，还是系统调度问题。
把每次修复做成可验证动作：改了什么，怎么证明有效，有没有回归风险。
把高风险操作关进流程里：先 dry-run，再审查，再授权，再执行。
把 Agent 的权限拆开：能读什么，能写什么，能不能对外发送，能不能改配置，全部要清楚。
把回滚当成默认能力，而不是事故发生后的临时补救。
如果这些基本治理都没有，源码级自我进化离你还很远。
但如果这些已经开始有雏形，那 MOSS 这类方向就值得认真看。
因为 Agent 的下一阶段，可能真的不是“更会聊天”，也不是“prompt 更漂亮”。
而是能不能把一次次失败，变成可审计、可验证、可回滚的系统改进。
这才是 AI Agent 从玩具走向生产力的关键分水岭。
不是 AI 会不会改自己。
而是你有没有能力管住它怎么改自己。