MOSS源码级实验：生产级Agent自进化排行榜

针对Agent自进化的讨论正在升温。本文将深度解析论文——「MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems」。该论文提出MOSS源码级自进化系统，旨在面向生产级Agent基座，将自我改进的边界从文本层（prompt、skill、memory）直接推进至源码级重写——简言之，让系统具备直接修改自身代码的能力。

以往讨论Agent自进化，主要聚焦于文本层操作：更新prompt、沉淀skill、写入memory、调优workflow。这些手段固然有效，但始终停留在模型可读、可参考、可调用的范畴。MOSS则提出一个更尖锐的问题：若Agent的失败根源并非这些文本对象，而是深藏于系统执行层，它能否通过修改自身源码来完成进化？

论文的核心论断是：生产级Agent的多数失败，并非源于模型“如何思考”，而是系统“如何运行”。例如，消息路由错乱、工具返回结果合并错误、hook执行顺序颠倒、session状态传递丢失。这些问题归属于Agent Harness——通常固化在代码中，而非prompt、skill或memory内。因此，MOSS探讨的并非“Agent能否改代码”，而是Agent自进化如何从文本层跨越至源码层，尤其聚焦于Harness代码的改进。

现有自进化Agent的能力边界

论文首先点明了当前应用级自进化Agent的共同瓶颈：它们大多局限于修改text-mutable artifacts，即文本层的可变对象，包括skill、prompt、memory schema、workflow graph等。Agent可以在任务失败后撰写一条新skill；调整系统提示词，引导模型下次更严格遵循规则；或更新memory，持久化用户偏好与历史经验。这些方法确实能改善模型行为，但无法直接触及系统的执行逻辑。

论文将MOSS与Hermes Agent、SkillClaw、GenericAgent、EvoAgentX等系统进行了对比——核心差异在于，MOSS将harness纳入了可修改范围。

图注：不同自进化Agent的可修改范围对比——关键区别在于MOSS将Harness也视为可进化对象。

这张表格清晰揭示了现有Agent自进化的一条明显边界：多数系统能修改模型读取的文本，却无法更改系统实际执行的代码。

前文已提及，一个生产级Agent系统不仅包含模型和prompt，还囊括工具调用、路由、状态管理、hook、调度、会话生命周期等组件。这些组件决定了模型输出如何转化为实际动作。一旦这些环节出错，仅靠修改prompt很难根治。

用一个比喻来理解：prompt、skill、memory好比Agent的“认知材料”，而harness则是Agent的“执行结构”。前者影响模型看到什么、倾向如何决策；后者决定系统实际如何运转、工具如何调度、状态如何演变。

这正是论文强调源码级重写的原因。通过修改源码层，可以直接调整routing、state invariants、dispatch、hook ordering等系统行为；而修改文本层只能通过下达新指令间接影响结果，效果往往不够直接。

论文认为，相较于仅能修改文本层内容的text-mutable evolution，source-level adaptation（源码级自适应）面对着一个更大的搜索空间。原因有四：

• 图灵完备性赋予源码表达任意逻辑的能力；

• 源码层是prompt、skill、memory等文本层修改的严格超集；

• 源码修改的效果更为确定，不依赖模型每次是否准确理解并遵循提示；

• 源码逻辑不会因长上下文堆积而逐渐失效。

简言之：若Agent问题根植于系统执行路径，直接修改执行路径显然优于在prompt中追加提醒。

MOSS的系统定位：自修复编排层

MOSS并非新基础模型，亦非独立的coding agent。它更像一个围绕生产级Agent系统构建的自修复编排层。论文采用OpenClaw作为基座——即待进化的Agent系统。MOSS负责收集失败案例、控制进化流程、调用外部coding agent、验证候选版本，并在用户授权后执行容器替换。

图注：上图展示MOSS的主机侧拓扑。moss-gateway运行用户侧Agent与进化服务，host-daemon负责编排coding-agent CLI、trial workers、镜像构建与容器替换。

这张图有助于理解MOSS的角色分工。moss-gateway container是长期运行的主容器，承载用户实际交互的Agent、进化服务与moss CLI。host-daemon运行于宿主机，负责主容器无法或不宜自行完成的任务——例如启动外部coding-agent CLI、构建候选镜像、启动trial workers、执行swap与回滚。

如此设计有其现实考量：容器替换无法由主容器自身完成。候选版本收敛后，旧容器需停止并由新镜像替换；一旦主容器退出，它便无法再负责启动新容器。因此，MOSS将容器生命周期与swap supervisor置于宿主机上的host-daemon中。

外部coding-agent CLI同样是该架构的关键组件。MOSS本身不绑定特定模型，而是通过runner接入Claude Code、OpenAI Codex、DeepSeek-TUI、OpenCode等工具。MOSS负责阶段顺序、循环退出、判定与上线时机，coding agent则负责具体的代码修改。换言之，MOSS并非取代coding agent，而是将coding agent纳入一个有目标、有阶段、有验证、有上线控制的流程之中。

如何将真实失败转化为源码修复

让Agent修改自身源码，风险显而易见。MOSS的处理策略并非让Agent随机修改自身，而是将每次进化锚定到一批真实失败样本上。论文称之为directed evolution。

这一点与许多benchmark-driven（基准驱动）的自进化系统截然不同。在研究环境中，可让Agent面向固定benchmark反复试错，哪个版本分数高就保留哪个。但生产级Agent很难如此操作。真实用户并不关心系统在某个榜单上提升了多少分数，他们更在意自己遇到的问题是否被修复。

因此，MOSS的进化目标源于production-failure batch（生产环境失败样本批次）。失败样本有两个来源：

1. 后台周期性扫描用户session JSONL，识别表现不佳的对话片段；

2. 当用户在对话中表达不满时，Agent可通过调用moss evo flag标记当前问题。

两类证据均进入同一batch，后续的定位、计划、实现与验证均围绕这批失败展开。

该设计解决了一个根本问题：真实环境中，Agent应根据什么进化？MOSS的答案是“依据真实失败进行修复”。它不要求Agent无方向地探索整个代码空间，而是要求每次修改服务于一个明确目标：修复这批失败样本暴露的缺陷。

这也使得源码级自修改更贴近实际工程排障的思维。开发者处理线上问题时，通常不会先问“系统整体能否更强”，而是先检查哪条链路失败、日志中有什么线索、能否复现、修改哪个模块可避免同类错误。MOSS试图将此流程自动化。

如何约束、验证与上线代码修改？

MOSS并非将整个代码库交给一个coding agent，然后让其一次性完成诊断、计划、实现与验证。论文将一次进化拆分为七个阶段：Locate、Plan、Plan-Review、Implement、Code-Review、Task-Evaluate、Verdict。

上图展示MOSS evolution的四层结构：pre-loop baseline、iteration loop、stage pipeline，以及stage内部的retry round。

此图说明，MOSS的进化并非一次性patch，而是一个嵌套流程。最外层先有pre-loop baseline，用于确定当前失败表现；随后进入iteration loop，每一轮执行固定的七阶段pipeline；在Plan-Review与Code-Review等质量门内部，还可进行多轮重试。

这七个阶段可理解为一套机器可执行的工程修复流程：

• Locate仅负责定位问题，不急于给出修复方案；

• Plan负责提出修改计划，明确需修改哪些文件、增加何种逻辑、哪些部分不应改动；

• Plan-Review是首个质量门，用于判断方案是否偏离架构或范围过窄；

• Implement才真正修改代码；

• Code-Review检查diff是否符合计划；

• Task-Evaluate负责对候选版本的运行结果进行评分；

• Verdict最终决定是否收敛、是否继续迭代，或是否属于模型能力或架构限制。

这里的关键不在于阶段数量，而在于职责拆分。MOSS不允许coding agent一次性“想明白并改好”，而是通过阶段边界约束其行为。计划需先审查，代码需再审查，运行结果单独评估。

对Agent Harness而言，仅进行静态代码审查或单元测试并不足够。许多错误仅在真实执行链路中才会暴露——例如工具结果如何被模型消费、hook顺序是否影响状态、session生命周期是否正确、多个工具调用的输出能否被准确归因。

因此，MOSS在Code-Review之后还会进行runtime验证。host-daemon构建候选镜像，随后启动多个临时trial workers。这些trial workers是短生命周期的容器，用候选镜像运行同一批失败样本。任务完成后，MOSS再比较候选版本与baseline的表现。

这与仅运行单元测试的思路不同。MOSS验证的不是代码看起来是否合理，而是候选系统在同一批失败任务上是否产生了更优的行为。对于Agent系统而言，这一区别至关重要。因为一个patch可能语法正确，也能通过局部测试，但在工具调用链、状态传递与上下文组织中仍可能失败。

候选版本通过验证后，也不会直接替换线上系统。论文设计了用户授权步骤：当evolution loop给出CONVERGED verdict后，系统会通知用户，等待用户执行moss evo apply。只有用户确认后，host-daemon才会执行容器替换。

上线过程并非简单重启。MOSS采用原容器环境swap：主容器被替换为候选镜像，但用户状态保存在独立volume（数据卷）中，因此sessions、memory、credentials、agent configs均不会丢失。替换后，host-daemon进入90秒的健康检查窗口，每5秒检查一次。仅当连续3次通过，swap才算成功；否则回滚至last-known-good image（最后一个已知良好的镜像）。

归根结底，MOSS真正强调的并非代码生成能力，而是将代码修改置于一个可验证、可回滚的工程闭环中。

OpenClaw实验：它到底修复了什么？

论文在OpenClaw上进行了案例研究。OpenClaw是一个生产级agentic system，包含多渠道网关、插件与hook机制、session与skill管理，以及持久化用户状态。实验采用DeepSeek V3.2作为底层模型。

实验任务来自CLAWEval，覆盖4个operations / compliance-audit场景，可概括为两类：SLA合规审计与补货链路检查。

在SLA合规审计中，Agent需识别优先级为P1的违规工单，并依据不同SLA规则计算其合规状态。

在补货链路检查中，Agent需跨调度任务、集成配置、库存水平等多个服务进行链路追踪，从而定位执行失败的任务、断开的集成配置，以及库存不足的商品。

这些任务有一个共同点：均要求Agent多次调用工具，并保持多实体之间的准确对应关系。baseline表现并不理想，四个任务平均分仅为0.2526，远低于0.75的通过线。失败表现包括：仅列出部分工单、无法判断部分合规状态、混淆客户名称，以及无法完整串联补货链路。

在MOSS的Locate阶段，研究者发现问题并非单纯源于模型能力不足，而是出在执行框架的tool-result handling（工具调用结果处理）上。

具体而言，Agent经常选择一条较为通用的执行路径，即generic execution path。但mediator并未为此路径准备对应的annotation branch，导致工具返回的结果缺乏必要标注。

另一个问题是，当Agent将多个查询合并成一个shell命令结构时，底层的dispatch-synthesis pipeline会将多个结果混合输出，导致后续难以判断每个结果分别来自哪个查询。

最终，模型看到的工具结果不够清晰：它可能只能拿到一段难以归因的混合输出，后续回答便容易出现半截答案，或将错误归因到错误的地方。

MOSS最终的修复发生在harness层，即负责组织任务执行、工具调用、结果返回与状态流转的运行框架。它在tool-result mediator（工具结果中介层）中增加了一个annotation branch，用于为工具返回结果补充更清晰的说明；当执行路径返回multi-entity payload（多实体结果）时，系统会注入更明确的使用提示，帮助Agent判断每一段结果对应的对象。同时，还在before-tool-call hook chain中增加了一个pre-call deny gate，在工具真正被调用前拦截某些容易制造混乱的batched-shell pattern（批量shell调用模式），引导Agent改用更易解析的独立调用。论文提到，此次实现共修改了3个文件，新增177行，删除1行。

该patch的重点并非提醒模型“回答时要更仔细”，而是改变系统执行路径，让模型更难走向那些容易混淆结果的调用方式。换句话说，MOSS修复的不是回答风格，而是工具调用与结果处理链路。

经过一轮进化后，4个任务的平均分从0.2526提升至0.6100。其中，T138_restock_chain_check从0.2090提升至0.9049，超过了0.75的通过线。两个SLA任务也有所提升，但最终仍停留在0.53至0.55左右。

图注：论文展示了四个claweval任务在baseline与iteration 1后的分数变化。平均分从0.2526提升至0.6100。

这组结果的重点不仅是分数提升，更是MOSS修复的位置。它没有仅修改prompt或skill，而是定位并修改了tool-result mediator与before-tool-call hook，即论文前文强调的harness层。这充分说明source-level rewriting确实能修复一类prompt、skill、memory难以触及的问题。

但该结果也有局限性。一次harness patch并未解决所有任务难点。SLA任务仍存在per-ticket时间差计算与SLA-tier分类等问题，这些可能需要后续迭代或其他层面的改进。

论文的启发与边界

这篇论文对于从事AI开发的同仁而言，有几点值得关注的启发：

1、切勿将Agent优化仅理解为prompt优化。Prompt固然重要，但它仅是Agent系统的一层。当应用进入生产阶段，工具返回格式、状态传递、hook顺序、错误恢复、权限控制与部署回滚，均会影响最终效果。

2、失败样本需要系统化保存。MOSS的定向进化依赖于失败样本。若期望Agent能持续改进，就必须记录关键执行trace，保存工具调用输入输出，支持失败任务回放，并允许用户标记问题。缺乏这些数据，Agent很难明确自身应修复何处。

3、AI coding需进入工程闭环。让模型生成代码仅是第一步，更重要的是将代码生成置于可审查、可测试、可回滚的流程中。对于Agent系统尤其如此，因为许多问题仅在运行时才会暴露。trial worker、沙箱环境、候选镜像、健康检查与回滚机制，将成为AI修改系统代码时的基础设施。

未来Agent框架的竞争可能不再局限于“能接多少工具”或“能支持多少模型”，而在于能否将真实失败转化为可验证的系统修复。一个成熟的Agent框架，可能需要内置失败采集、trace回放、代码修改、沙箱验证、用户授权与上线回滚这些能力。

当然，这篇论文的边界也较为明确。首先，实验规模较小，主要是四个任务上的案例研究。其次，进化batch与测试任务为同一批，因此结果更适合说明定向修复能力，而非泛化能力。第三，源码级自修改天然存在安全风险——例如错误patch、隐藏副作用、权限扩大、供应链风险，以及对失败样本过拟合。论文已设计用户授权、健康检查与回滚，但安全治理仍需更多探讨。

此外，MOSS仍依赖外部coding agent完成具体代码修改。MOSS负责流程与判定，但patch质量取决于外部coding agent的能力。随着coding agent能力提升，此类系统的效果可能更优；但这同时也意味着MOSS的上限并非由编排系统单独决定。

总结

这篇论文探讨的是一个本质问题：当Agent的失败源于工具链、状态管理、hook顺序或执行路径时，仅修改prompt、skill与memory无法触及问题根本。

MOSS给出的方案，是将真实失败样本转化为源码级修复目标，再通过分阶段计划、代码修改、运行时验证与容器级回滚，将此类修改纳入受控流程。其价值不在于证明Agent已能完全自我进化，而在于展示了一条更贴近生产系统的路径：让Agent不仅仅是记录失败，而是有机会将失败转化为可验证、可回滚的系统修复。

来源：互联网