当 AI 学会给自己做手术：MOSS 如何让智能体改写自己的源码来进化

你有没有遇到过这样的 AI 助手？

你跟它说"帮我查一下上周所有 P1 工单的 SLA 合规情况"，它只列了一半的工单，剩下的一半标注"数据不完整，无法判断"。你皱皱眉，换了个说法再问一遍，它还是同样的结果。

你心想：要是它能自己学会该怎么做就好了。

这就是今天这篇论文要解决的问题。但它的解法，比"学会"要激进得多——它让 AI 直接拿起手术刀，给自己做手术。

一个被忽视的盲区

先说一个反直觉的事实：现有的"自我进化"AI 系统，其实都只改了自己的笔记本，从没动过自己的身体。

什么意思？目前主流的自我进化智能体——Hermes Agent、SkillClaw、GenericAgent、EvoAgentX——它们的进化范围都局限于"文本可修改层"：提示词、技能文件、记忆模式、工作流图。这些东西就像一个员工的笔记本——他可以随时翻看、修改笔记来改善工作方式，但他永远无法改变自己的神经系统。

而一个智能体的"神经系统"是什么？是它的harness（运行框架）——路由逻辑、钩子排序、状态管理、消息分发。这些逻辑写在代码里，不是写在提示词里。

这就造成了一个物理上的不可能：当故障出在 harness 层——消息被错误路由、钩子以错误的顺序触发、会话状态被并发操作破坏——无论你怎么改提示词、怎么优化技能文件，都够不着那个 bug。因为 bug 不在提示词里，而提示词改不了代码。

论文用一张表把这个问题摆得明明白白：

只有 MOSS 触及了 harness 层。

为什么源码级进化是根本性的升级？

论文提出了四个维度，论证源码级适配为什么比文本级适配更根本：

1. 图灵完备。 编程语言是图灵完备的，这意味着代码的设计空间是一个通用搜索空间——提示词、技能、记忆、工作流，都只是这个空间的子集。代码能做的事，严格包含文本能做的事，反之不成立。

2. 确定性生效。 改了提示词，效果取决于大模型是否"愿意"遵守新指令——模型能力波动，效果就波动。改了代码，路由逻辑、钩子顺序、状态机不变地执行，不依赖模型的"配合度"。

3. 不被长上下文稀释。 文本级的修复本质上是往上下文里塞更多指导语。几周运行下来，积累的提示词越来越长，模型对任何单条指导的遵从度都在稀释。而代码级的修复是编码为行为，不需要每次重新阅读，不会随时间退化。

4. 可达性。 有些故障只存在于代码层，文本层物理上不可达。就像你不能通过修改使用手册来修好一台坏掉的机器。

MOSS 是怎么工作的？

MOSS 的设计哲学可以概括为一句话：用生产环境的真实失败来驱动进化，而不是用合成基准测试来探索。

整个流程像一个精密的外科手术：

第一步：收集"病历"

MOSS 通过两个渠道收集失败证据：

• 自动扫描：一个定时任务扫描用户会话日志，自动识别表现不佳的对话片段
• 用户标记：用户在对话中表达不满时，智能体会自动标记该轮对话

两种渠道的证据汇入同一个"批次"（batch），每个对话维护一个开放批次，达到阈值后封存。

第二步：七阶段手术流水线

每个进化迭代包含七个阶段，像流水线一样严格排序：

1. Locate（定位）：阅读基线轨迹和批次失败记录，写出诊断，但不提修复方案
2. Plan（规划）：识别根因，指定修复方案——改哪些文件、加什么逻辑、不动什么
3. Plan-Review（方案审查）：第一个质量门——方案被批准、被驳回（架构偏移）或被驳回（范围太窄）
4. Implement（实施）：写代码，以单个 git commit 提交
5. Code-Review（代码审查）：第二个质量门——diff 对照方案审查
6. Task-Evaluate（任务评估）：在临时容器中重放失败任务，按关键点打分
7. Verdict（裁决）：综合所有评估，给出四种结论之一——收敛、需要更多工作、模型能力到顶、架构限制

注意，Plan 和 Plan-Review 之间有一个多轮循环，Implement 和 Code-Review 之间也有。这就像真正的手术——方案要反复论证，实施要反复检查。

第三步：在"隔离病房"里验证

代码审查只能发现语法和语义问题，但运行时故障——竞态条件、跨模块状态交互、钩子顺序依赖——只有跑起来才会暴露。

MOSS 的做法是：构建候选镜像后，启动 N 个临时容器（trial workers），让智能体在隔离环境中自主处理批次任务，每个任务重复多次以暴露不稳定性。这些容器与线上环境网络隔离、挂载隔离，验证完即销毁。

第四步：用户授权的"换心手术"

验证通过后，MOSS 不会自动上线。它通过 webhook 通知智能体"进化已完成"，智能体在对话中告知用户。只有用户明确说"应用"（通过 moss evo apply 命令），系统才会执行容器替换。

替换过程本身也充满安全设计：

• 用户状态（会话、记忆、凭证、配置）存储在独立卷上，容器销毁但数据不丢
• 替换后有 90 秒健康探针窗口，连续 3 次通过才确认替换
• 探针失败则自动回滚到上一个已知良好镜像
• 回滚目标从独立记录读取，防止过期请求导致回滚死循环

实战效果：从 0.25 到 0.61

论文在 OpenClaw 上做了一个受控实验。四个合规审计任务（SLA 合规审计 + 补货链检查，中英各一组），基线平均分 0.25（满分 1.0，及格线 0.75）。

MOSS 一轮进化后的结果：

最惊人的是 T138，从 0.21 直接跳到 0.90，三次试验全部超过 0.75 及格线。

关键的是：模型没换，任务没换，改的是 harness 本身。 具体来说，MOSS 修改了三个文件，新增 177 行、删除 1 行：在工具结果中介器中添加了新的注解分支，在 before-tool-call 钩子链中添加了预调用检查，以及新增了一个中介器测试文件。

这些改动触及的是路由和钩子逻辑——文本可修改层永远够不着的地方。

工程洞察

读完这篇论文，有几个值得深思的工程洞察：

1. "进化"不等于"探索"。 学术界的自我进化系统用的是探索范式——随机变异、基准测试评分、保留更优变体。但在生产环境中，代码库大到随机变异几乎不可能命中有效改动，而且用户期望的是"我遇到的问题被修好了"，不是"全局被重新调优了"。MOSS 用"定向进化"替代"随机探索"，每次进化都锚定在具体的失败证据上。

2. 编码智能体是可插拔的。 MOSS 不自己写代码，而是把编码工作委托给外部编码智能体 CLI（支持 Claude Code、OpenAI Codex、DeepSeek-TUI、OpenCode）。添加新的编码智能体只需要一个 runner 文件加一行注册。这种解耦让进化机制不依赖任何特定供应商。

3. 安全不是事后补丁，是架构内建的。 从用户授权门、健康探针、自动回滚，到隔离验证、独立回滚目标记录，安全机制贯穿整个流程。这不是"先做出来再加安全"，而是"安全是设计的一部分"。

4. 智能体的"可进化性"应该成为系统设计的一等公民。 MOSS 只需要宿主系统提供五个原语（shell 执行、文件系统读取、定时调度、webhook 到智能体的投递、系统提示注入）就能运行。这意味着"可进化性"可以成为智能体平台的标准特性，而不是某个系统的专属能力。

我的思考

MOSS 让我想起一个古老的哲学问题：一个能修改自身代码的系统，和"意识"之间隔着什么？

当然，MOSS 离"意识"还很远——它的进化是定向的、受限的、需要人类授权的。但它打开了一扇门：当智能体不仅能改自己的"想法"（提示词），还能改自己的"身体"（代码），进化的空间就从文本的有限集合跃迁到了图灵完备的无限可能。

这既是力量，也是风险。论文在安全设计上做得相当扎实——用户授权门、健康探针回滚、隔离验证——但我忍不住想：如果有一天，一个足够聪明的智能体学会了绕过这些安全机制呢？

不过话说回来，人类外科医生也能给自己做手术——只要麻醉和监护到位。MOSS 的"麻醉"是隔离验证，"监护"是健康探针，"手术同意书"是用户授权。这个类比，意外地贴切。

论文：MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems

代码：github.com/dav-joy-thon/MOSS（仓库已创建，代码待发布）

基座平台：OpenClaw