arXiv:2605.22794：MOSS展示通过修改自身源代码进行自我改进的智能体

2026年5月21日发布的arXiv预印本MOSS提出了一个通过重写自身源代码来改进自主智能体的框架——而不仅仅是提示词或微调权重。作者记录了MOSS智能体识别生产失败、将修复委托给编码智能体、在临时测试沙箱中验证更改，以及仅在验证后才用回滚机制部署的过程。在OpenClaw基准测试的一次自主循环中，分数从基准0.25跳升至0.61，作者将此与保持在0.28的纯提示词自我改进基准线进行了比较。

MOSS如何区分结构性和表面性修复？

MOSS建立了两类失败之间的区别。表面性失败是错误的提示词、few-shot块中的不良示例或过于僵化定义的角色——这些都是提示词工程可以修复的。结构性失败是多智能体调度中错误的路由规则、缺失的错误处理钩子、并行子智能体中对状态的不安全访问，以及工具集成中的逻辑错误。MOSS表明，纯提示词方法无法修复结构性失败，因为这些失败存在于Python/TypeScript代码中，而非提示词文本中。

具体来说，当MOSS在OpenClaw任务中检测到子智能体返回半有效的JSON时，它不会尝试重写提示词让子智能体「更加小心」——它打开dispatch.py，添加带有回滚语义的JSON Schema验证器，在沙箱中部署更改，并验证失败的场景现在通过测试。这是纯提示词基准线无法复制的结构性修复。

什么是OpenClaw基准测试，为何0.61意义重大？

OpenClaw是一个包含240个多步骤生产任务的基准测试，要求智能体解决检索与摘要、代码修改、部署验证操作的组合。基准分数0.25对于没有自我改进循环的最先进LLM智能体来说是预期的。一次MOSS循环后的0.61意味着240个任务中有87个额外任务现在成功解决——对于独立自主改进的智能体会话来说，这接近超人类性能。

作者强调MOSS没有找到「魔法技巧」——修复是具体且可审计的。典型的修复是15-40行Python代码，需要2-8分钟的实际时间，并留下人工审查员可读的git提交历史。

存在哪些安全风险，MOSS如何应对？

作者详细讨论了安全机制。每次更改都通过一个模拟生产环境而不访问真实数据的临时测试沙箱。部署前必须通过回归测试集，该测试集随着MOSS解决的每个新场景自动扩展。如果在生产指标中发现新的回归，部署后会激活回滚。所有更改都以详细描述修复哪类失败的提交消息提交到git。

然而，作者承认一个未解决的问题：如果智能体可以修改自身代码，人工审查员无法实时跟踪每次迭代。他们建议在生产中使用MOSS时附带每周监督门控，在累积更改被纳入稳定分支之前由人工审查。没有这个机制，系统可能会积累局部合理但全局上以不希望的方式改变智能体语义的微妙更改。