为什么这篇值得看

很多自我改进 Agent 的讨论，最后都会落在几个可编辑文本上：system prompt、skill 文件、workflow 配置、memory schema。这样做容易理解，也容易上线，因为文本改动风险较低。MOSS 的切入点更硬：如果失败来自系统代码本身，文本层再怎么调也只是绕路。

论文把这类问题叫作 agent harness 无法触达的结构性失败。比如路由条件写错、hook 顺序不合理、状态不变量没有被 enforced、dispatch 逻辑漏掉边界。它们重点是运行系统本身提供了错误轨道。

这也是它对产品团队的提醒：Agent 失败不总是 prompt 失败。很多时候，失败是系统设计没有留下可验证的修复路径。

方法到底做了什么

MOSS 的流程不是让模型在生产环境里随便改自己。它先自动收集生产失败证据，把失败样本整理成批次；再让外部 coding-agent CLI 生成源码级候选修改；随后在临时 trial worker 里回放这些失败批次，验证候选镜像是否真的改善结果。

只有候选修改通过回放，系统才进入用户同意、容器替换、健康探针和回滚阶段。这套设计的把「自我改进」拆成可审计步骤，而不是把权限交给一个不可控循环。

论文报告的结果也很具体：在 OpenClaw 上，一轮循环把四个任务的平均 grader score 从 0.25 提升到 0.61。这个数字不能被夸大成通用结论，但足以说明源码层确实能修一部分文本层碰不到的问题。

它对工程实践的启发

第一，失败证据要能复用。生产日志如果只用于事后排查，而不能形成回放集，就很难支撑自动修复。第二，Agent 系统需要分清可编辑层级：prompt、skill、配置、工作流和源码分别对应不同失败类型。

第三，自动修改必须有硬边界。临时 worker、回放测试、健康探针、用户同意和回滚，重点是这类系统能不能进入生产的前提。

更现实的判断是：多数团队暂时不需要完整 MOSS，但都应该建立「失败样本到回归测试」的完整流程。没有这个完整流程，自我进化只会停留在漂亮叙事。

局限和风险

这篇论文的评测规模还不大，OpenClaw 上四个任务的提升不能直接推出所有 Agent 系统都适合源码级自修复。源码修改的风险也明显高于 prompt 修改：一个候选补丁可能修好当前失败，却引入新的安全边界问题。

另外，论文把外部 coding-agent CLI 作为可插拔修改器，最终效果仍受底层 coding agent 能力限制。系统能控制流程和验证，但不能保证生成的补丁总是高质量。

所以 MOSS 的价值在于把自我进化从口号拉回工程问题：证据、候选、验证、同意、回滚，缺一项都不该上线。