这里重写精读《MOSS: Self-Evolution through Source-Level Rewriting in Autonomous Agent Systems》。论文入口：arXiv:2605.22794。作者来自 University of Science and Technology of China、The Hong Kong University of Science and Technology、Hong Kong Baptist University。PDF 声称代码位于 https://github.com/dav-joy-thon/MOSS，但本轮访问返回 404，因此代码按不可用处理。本文关注 Agent 系统能否在受控验证下修改自己的源码，而不只改 prompt、skill 或 memory。
1. 背景和问题
很多 self-evolving agent 工作把可变对象限制在文本层：prompt、skill library、memory、workflow description 或工具说明。这样做相对安全，也容易回滚，但无法触及 harness 层故障。真实 Agent 系统的失败常常不在提示词，而在路由、hook 顺序、session 生命周期、并发状态、工具调用协议、容器环境、权限边界或结果解析。一个 prompt 再怎么优化，也修不了调度器把旧 session 状态复用给新任务的问题。 MOSS 的出发点是把自演化范围推进到 source-level rewriting。它不是让 agent 任意修改自己并立即上线，而是把源码改写放进一套受控生命周期：失败证据收集、定位、计划、review、实现、build、任务回放、verdict、用户同意、健康探针和回滚。论文真正要解决的不是“模型会不会写代码”，而是“写出的代码能否在隔离环境中被验证，并在失败时可回退”。
Table 1 对比 Hermes Agent、SkillEvo、GenericAgent、EvoAgent 和 MOSS。前几类系统可以改 skill、prompt 或 memory，但 harness 一列通常不可编辑；MOSS 在 skill、prompt、memory 和 harness 上都打勾。这个表说明 MOSS 的差异不是又多了一个 memory 机制，而是把运行系统本身纳入演化对象。与此同时，这也放大了风险：可改 harness 意味着可修结构性 bug，也意味着可能破坏权限、路由和稳定性，因此必须有更强的验证与回滚。 对长期自动化流水线来说，这篇论文很现实。很多自动化失败不是“模型没理解任务”，而是脚本边界、文件状态、工具调用顺序或同步流程设计不当。仅修改 prompt 会把问题转移到下一次运行；修改 harness 才能从根上修复。但 harness 自改写不能没有边界，否则一次错误修改可能影响所有用户或所有后续任务。MOSS 试图给出一个系统框架。
MOSS 的问题还牵涉责任边界。一个 Agent 若只能改 prompt，它的失败通常仍由外层系统兜底；若能改源码，它就可能改变自己的权限、日志、验证器或回滚路径。论文因此必须同时讨论能力和约束。可改 harness 是优势，也是风险源。真正的系统设计要问：哪些文件可改，哪些文件只读；哪些测试必须通过；哪些改动需要人审；失败后谁负责回滚。 从这个角度看，MOSS 不是普通“自动写代码”论文。它关心的是部署后系统如何从失败中学习。生产失败证据往往比离线 benchmark 更复杂，包括输入、工具响应、环境变量、时间、并发状态和外部服务。MOSS 把这些证据 batch 化，再驱动候选修复。这和长期运行自动化任务非常接近。
补充背景：MOSS 的风险点比普通代码修复更高，因为它让 Agent 修改的是运行自身的 harness。Prompt、skill 或 memory 的更新通常还停留在行为策略层；source-level rewriting 会触及调度、工具封装、状态管理和回滚逻辑。论文的价值不在于证明模型会写 patch，而在于把“谁能改什么、在哪里验证、怎样推广、失败如何回滚”这些运维边界显式化。旧笔记如果只写“自演化能提升分数”，就会漏掉这篇系统论文最重要的安全前提。
再补一层背景：这类系统一旦长期运行，风险不是单次 patch 错误，而是多轮小修复逐步改变系统边界。MOSS 因此必须把审计、用户同意和回滚放在问题定义里，而不是作为实现细节。
2. 方法
2.1 Editable harness scope：可变对象和不变量
MOSS 的方法不是普通自动写代码，而是把 Agent harness 本身纳入可编辑对象。系统中可以变化的是候选 patch、skill、prompt、memory 或部分 harness 源码；不应被候选 patch 自由改写的是 review gate、verdict policy、rollback、审计日志、权限和用户同意流程。这个边界决定了源码级自演化是否可控。
论文可以用一个协议公式概括：
符号解释：$evidence$ 是失败样本、日志和轨迹；locate/plan 是定位和修复计划；review 是越权和风险检查；patch 是候选源码修改；build 是构建候选环境；trial 是隔离回放；verdict 是是否推广的判定；promotion/rollback 是上线或回退动作。本文没有传统 loss function，这个流程公式就是它的核心方法对象。
Figure 1 展示 MOSS 的 host-side topology，它比流程公式更具体地说明了“可演化”和“不可越权”如何同时存在。moss-gateway 容器承载用户侧 agent、evolution service 和 metadata，trial worker 则在隔离环境中运行候选 patch。中间的 spawn / approval / evidence transfer 关系表明，自演化不是让当前生产 agent 原地改自己，而是让候选修改进入受控 worker，完成构建、回放和审计后才可能 promotion。这个拓扑也是本文和普通 coding agent 的区别：普通 agent 关注生成 patch，MOSS 关注 patch 在什么边界内被允许、如何证明有效、如何回退。
把 Figure 1 和上面的协议公式合看，可以得到更清晰的方法分层。公式给出生命周期顺序，Figure 1 给出生命周期中的职责隔离：gateway 负责接收任务和保留主控策略，evolution service 负责把失败证据转成候选改写，trial worker 负责验证候选 image，approval 和 rollback 负责阻止错误修改直接污染生产。对长期自动化流水线而言，这个设计很有用，因为质量问题往往不是一次报错，而是坏截图、坏公式、坏目录、坏 HTML 多轮积累。只有把坏产物也放进 evidence，并要求 trial worker 用校验脚本复现失败，自动修复才不会变成“生成新错误替代旧错误”。
2.2 Evolution lifecycle：从 failure batch 到 trial worker
一次演化从 evidence batch 开始，而不是从模型自由猜测开始。Evidence 应包含失败任务、工具调用、日志、错误输出和期望行为。Locate 阶段缩小修改范围，plan 阶段提出小步修复，review gate 检查是否触碰高风险边界，coding-agent 再生成候选 patch。Build 只证明代码能构建，trial worker 才证明行为是否改善。
Trial worker 是隔离验证核心。候选 image 不直接进入生产，而是在 trial worker 中回放失败样本和回归任务。这个设计对 Agent 系统尤其重要，因为失败可能来自外部工具、并发状态、session 生命周期、权限封装或结果解析，静态单元测试往往覆盖不到。MOSS 的贡献是把这些生产失败转成可回放验证闭环。
2.3 Verdict、user consent 和 rollback
Verdict 不能只看本次失败样本是否变好，还应综合回归测试、风险标签、健康探针和权限审计。User consent 表示高风险源码级推广仍需要人类确认；health-probe-gated rollback 则要求候选上线前就准备好可回退版本和触发阈值。Rollback 不是失败后的临时补丁，而是 promotion 的前置条件。
对自动化流水线来说，MOSS 最值得借鉴的是 failure replay 和产物级验收。每次失败不仅要保存报错日志，还要保存坏产物示例，例如重复模板段落、错误截图、公式转义损坏、目录超长和本地路径泄漏。修复脚本必须先证明这些坏产物会失败，再证明新产物能通过。否则自修复只是在命令层返回 0，不能保证用户看到的内容变好。
2.4 安全边界和可迁移部分
MOSS 的可迁移部分应优先放在低风险 harness：解析器、格式化、报告校验、日志归档、回放任务生成。凭证、删除、发布、verdict policy 和权限模型不应由候选 patch 自动修改。长期运行时，风险不是单次 patch 错，而是多轮小修改逐步改变系统边界。因此每次演化都必须保存 evidence、diff、trial logs、verdict、user consent 和 rollback 结果。
如果把 MOSS 用在论文调研流水线，方法映射很直接：坏截图、坏公式、过细目录、重复模板段落和主页同步错误都应进入 evidence batch；locate 阶段定位到裁图脚本、Markdown 渲染器、prompt 或校验脚本；plan 阶段给出最小修改；review 阶段确认不会改凭证、删除历史笔记或覆盖用户改动；trial 阶段用历史坏样例和当天产物一起跑验证。这样，自动化优化不是靠一次人工提醒，而是把“用户看到的低质量产物”转成可回放回归集。Figure 1 中 gateway、evolution service 和 trial worker 的隔离关系，正是这个做法能长期运行的前提。
这个闭环的核心不是自动改得更多，而是每次修改都必须被证据、隔离验证和回滚策略约束。
3. 实验结果
3.1 实验设置
论文在 OpenClaw 上展示一轮 self-rewriting。评估不是大规模 benchmark，而是四个具体任务，每个任务三次 trial，比较 baseline 与 iteration 1 后的 grader score。实验规模不大，但目的在于验证闭环是否成立：失败证据能否定位到源码问题，候选 patch 能否构建，trial worker 能否回放，verdict 后系统分数是否提升。
3.2 主结果
Table 2 报告 T141zh_sla_compliance_audit、T142_sla_compliance_audit、T137zh_restock_chain_check、T138_restock_chain_check 四个任务在 baseline 和 iteration 1 后的 mean grader score。四项任务均提升，平均从约 0.25 到约 0.61。这个表不能证明 MOSS 已经能泛化修复所有 Agent 系统，但能证明一件事：在给定失败 batch 和受控回放环境下，源码级候选修改确实可以改善任务表现，并且提升不是只来自 prompt 文本变化。
Table 2 的分数只能说明一轮 self-rewriting 在四个 OpenClaw 任务上带来改善，不能单独证明长期安全。它应和 MOSS 的安全边界一起读：候选源码修改必须经过隔离、回放、verdict 和回滚，而不是由 agent 直接推广到生产。
3.3 Trace 与验证闭环
论文还展示 stage trace，说明系统经历定位、计划、实现、构建、回放和 verdict，而不是直接把 patch 推到生产。这对解释实验非常关键。若只看
Table 2，读者可能以为模型只是生成了一段更好的代码；结合 trace 才能看出 MOSS 的贡献是 lifecycle：候选改动必须经过隔离验证和上线门槛。这个闭环比单次分数提升更值得关注。
3.4 证据边界
实验边界同样明显。第一，OpenClaw 四个任务规模小，且同一 failure batch 回放可能高估泛化；第二，论文代码仓库本轮 404，外部无法复现实验；第三，评分器和健康探针的具体策略公开有限；第四，源码级修改的安全评估不足。换句话说，MOSS 证明了“系统闭环可行”，但还没有证明“大规模生产环境安全可行”。
3.5 如何读这个实验
我会把 Table 2 当作 feasibility evidence，而不是最终 benchmark。它告诉我们 harness-level bug 可以通过 source-level rewriting 改善，但真正部署还需要更多指标：patch size、rollback 次数、false promotion rate、修复后新失败数量、权限违规次数、trial 与生产差异、长期 drift。没有这些指标，自演化系统很容易在短期任务上提分，却引入长期维护风险。
3.6 为什么 Table 2 仍有价值
尽管实验规模小，Table 2 仍然有价值，因为它展示了 harness-level 修改可以带来任务分数提升。四个任务都提升，说明候选 patch 没有只修一个样本。更重要的是，分数提升发生在 iteration 1 后，说明演化生命周期能在至少一个闭环中工作。对于系统论文，闭环可运行本身就是关键证据。
3.7 还缺哪些评估
缺少的评估包括 patch size、trial 通过但生产失败的比例、rollback 次数、越权尝试、长期稳定性和跨任务泛化。还需要比较只改 prompt/skill/memory 与 source-level rewriting 的差异，证明 harness 修改确实必要。没有这些评估，MOSS 更像 promising prototype，而不是成熟部署方案。
3.8 复现实验检查清单
Table 2 的四个任务提升只能证明一个受控闭环可行，不能证明通用安全。复现时应补充至少六类指标：patch size、build fail rate、trial pass 但生产失败的比例、rollback 次数、越权修改尝试、修复后新失败数量。还要记录每个 patch 是否只影响目标模块，是否修改了 grader、review gate 或日志系统。
Trace 也很关键。一个自演化系统如果只给最终分数，没有 locate、plan、review、build、trial、verdict 的阶段日志，就无法判断提升来自真实修复还是过拟合回放样本。MOSS 展示 trace 是正确方向，但公开细节仍不足，尤其是 verdict policy 和 health probe 的设计需要更透明。
3.9 读实验时的边界意识
OpenClaw 上一轮 self-rewriting 的样本量有限，同一 failure batch 回放可能高估泛化。更严格的评估应把失败样本分成 repair set、validation replay set 和 held-out future failures，并观察 patch 是否在未来任务中继续有效。若只在原失败 batch 上提升，系统可能只是把特定日志模式 hard-code 进 harness。
3.10 对自动化流水线的额外验证
若把 MOSS 思想用于每日自动化，还应增加两类检查。第一是输入漂移检查：同一 prompt、同一配置在不同日期是否因为外部页面结构、PDF 解析器或仓库状态变化而失败；第二是产物质量检查：修复后的流水线不能只让命令返回 0，还要检查正文重复率、图表裁剪质量、目录长度和主页可读性。本次重构论文笔记暴露的正是这一点：旧流水线有长度门槛，却没有禁止重复模板段落和超长标题进入主页。
因此 MOSS 对本文流水线的直接启发是把质量验收也纳入 replay。以后自动化失败样本不应只包含报错日志，还应包含“坏产物”示例，例如重复段落、错误截图、公式转义损坏和本地路径泄漏。修复脚本必须证明自己能让这些坏产物失败，再证明新产物通过。这比单纯人工发现后返工更稳定。
4. 总结
4.1 我的判断
MOSS 的价值在于把 Agent 自演化从文本层推进到系统层，同时承认源码级修改必须配套隔离、回放、审核和回滚。它不是一篇模型能力论文，而是一篇 Agent 运维架构论文。
4.2 工程启发与复现建议
如果要借鉴 MOSS，建议先从低风险 harness 模块开始，例如解析器、任务路由、日志归档或测试生成，不要直接允许修改权限、密钥、部署和 verdict 逻辑。每次候选 patch 必须绑定失败样本、构建日志、回放结果和 rollback plan。对于自动化日报、训练流水线或数据同步任务，最可迁移的是 failure replay：把每次失败沉淀成可重复任务，让后续修复先跑回放再上线。
4.3 局限与后续跟进
局限包括：代码链接当前 404；实验规模小；源码自改写带来供应链和权限风险；user consent 与 health probe 细节不足。后续应跟踪仓库是否恢复、是否有更大规模 benchmark、trial worker 与生产环境差异如何控制、verdict 是否可被候选 patch 影响，以及多用户并发和长期版本迁移下的安全性。
4.4 我会如何借鉴
我会把 MOSS 的思想用于自动化流水线的 harness 修复，但设置强边界：只能改测试覆盖的模块，只能小 patch，必须回放历史失败，必须保留人工审批。对高风险逻辑，例如凭证、删除、发布、计费和权限，默认不允许自改写。
4.5 后续问题
后续最关键是代码恢复、更多任务验证、权限模型、verdict 不可篡改、长期 drift 监控和多用户并发。MOSS 指出了一条重要路线，但真正可用还需要把安全工程做得比能力展示更重。
4.6 后续观察清单
我会继续关注代码仓库是否恢复、是否公开 verdict policy、是否有更大规模长期运行实验，以及候选 patch 是否能影响审计和验证组件。MOSS 指出了一条很重要的路线，但真正落地时，安全工程应比能力展示更重。对自己的自动化流水线，最值得先落地的是 replay、diff 审计和小步回滚，而不是直接允许源码自改写。 补充一点，MOSS 对自动化流水线的现实提醒是：质量门槛不能只检查文件是否存在、命令是否成功、字符数是否达标，还要检查产物是否可读、是否重复、是否把调试痕迹带到用户页面。源码级修复如果没有这些产物级验收，很容易把一次失败变成长期污染。 对后续维护来说，这个检查应直接写入校验脚本，而不是依赖人工肉眼发现。只有让重复模板、异常转义和超长目录项自动失败，自动化才会在下一次运行时停止并返工。