为什么 Muse Code 让 agent 全程保持存活

「创建即弃」的问题

大多数多 agent 编码工具遵循同一套配方：任务来了，起一个帮手 agent，分给它一片工作，收回结果，然后销毁。这是一个干净的抽象，却带着丑陋的成本。每个新创建的 agent 都从零开始——它必须重新读仓库结构、重新摸清构建系统、重新学习你代码库遵循的约定。在一个包含十个任务的会话里，这笔收集上下文的税要交十次。

这笔税还不只是 token。它是延迟——每次冷启动都在拖慢真正的工作——也是引导成本，因为一个忘了自己一小时前学到什么的 agent，会把同样的问题问你两遍。

Muse Code 的答案：常驻

Muse Code 的架构是一个简单的主 agent 循环，加上一组异步后台 agent——而这些后台 agent 在整个会话期间保持活跃。它们不是为单个任务创建的。每一个都各有专长，随会话推进不断积累上下文，并自行判断什么时候有值得向主 agent 汇报的东西。

最后这个细节比听起来更重要。后台 agent 不会阻塞主循环等待指令，也不会用状态更新把它淹没。它们独立执行下一步，只在关键时刻沟通。Meta 陈述的理由正是上面那两项成本：常驻降低了延迟，也减少了在困难的多步骤任务上对人工引导的依赖。

worker 并行干活，reviewer 后台把关

实际用起来，你的体验更像一支有固定岗位的团队，而不是一队临时工。worker 并行执行改动；reviewer 在输出到达你之前，持续在后台批判性审查。发布时的说法——“默认多 agent”——很精确：协作不是一个需要开启的模式，而是每个任务的运行方式。你交付得更快，不是因为哪个单独的 agent 更快，而是因为质量控制是并发进行的，而不是事后补课。

训练进模型里，而不是外挂上去

这套 harness 设计与 Muse Spark 1.2 搭配的效果好于任何通用模型套壳，是有原因的。这个模型是与 Muse Code harness 联合训练的——它的训练配方明确优化了 subagent 行为，连同目标管理和上下文压缩。主循环与常驻专才之间的分工不是叠在上面的 prompt 工程技巧；模型在训练时就见过它。“更少重试、更好的工具使用”这些说法正是从这里来的，我们那篇关于 Muse Spark 1.2 如何训练的文章有深入讲解。

常驻解决不了的问题

长期存活的 agent 并发编辑同一个仓库，本会是 merge 灾难的配方——如果它们共享一份工作副本的话。但它们不共享。当工作扇出时，每个有写权限的子 agent 都会得到自己独立隔离的 git worktree，并行工作永远不会在文件上相撞。这套隔离机制值得单独讲一篇：agent 扇出与 git worktree。而当你想知道这些 agent 在你没盯着的时候到底干了什么，只增不改的 event log 有完整的答案。