驯的是训练路线，不是更强的模型
我用 6 个自建后端任务压了 6 个编码 Agent，结果出乎意料：轻量的 deepseek-v4-flash 六个全过，和 gpt-5.6-sol 打成平手；而 grok-4.5-build 跑了 5 个任务，全部失败，一个文件都没改。更意外的是，同一个 Grok 运行器的 default 配置却是 6/6 全过——输的是链路，不是品牌。
这个结果指向编码 Agent 选型里最容易被忽略的事实：模型和工具是两回事，能不能用，常常先由底下那条 Agent 链路决定。
Meta 前几天发布 Muse Code，大部分注意力都放在"又一个编码工具"上。真正的看点在于，Muse Spark 1.2 与 Muse Code 工具壳做了协同训练，模型从训练阶段就知道自己要调用工具、拆解任务。这是两条完全不同的技术路线。
模型为当 Agent 训练，还是被套了壳
当前多数编码工具，是拿一个通用大模型，再包一层能跑代码、能读仓库的壳。模型本质上仍是那个接话的模型，只是多了一只手。
Muse Code 走的是另一条路。官方披露，Muse Spark 1.2 的训练数据里混入了工具壳的运行轨迹，术语叫 rejection sampled harness trajectories，模型学到的本领是"怎么当一个 Agent"，而不是"怎么接一句话"。至于 /plan、/grill、/goal 技能和本地事件日志、崩溃后断点恢复，是产品宣称的运行时能力，训练侧和运行时侧要分开看。
差异在底层。套壳的模型写代码能力并不弱，但"要不要拆子任务、拆到哪一步、要不要先验证"这类判断，始终由壳来补。协同训练的模型，这些判断才可能成为模型自身的一部分。
我跑的那组数据，说明的是另一件事：能不能用，会被壳和启动链路单独决定。同样是 6 个后端任务，deepseek-v4-flash、gpt-5.6-sol、glm-5.2、qwen3.8-max 各配各的 shell（opencode、codex 等）全部通过；grok-4.5-build 这个组合 agent 没正常启动，一个文件都没改，而同一个 Grok 运行器的 default 配置却 6/6。能正常工作的组合，差距只在耗时和成本。跑不起来的那个，输掉的是 Agent 链路本身。
挑编码 Agent，看三个可观察行为
与其盯着 benchmark 分数，不如看三个它在任务里会不会表现出的行为。
- 会不会自己开子任务并写回仓库。 一个 Agent 被丢进多文件任务时，是只会一通改，还是会拆成子任务、各自落盘、最后合起来跑通。
- 长任务中断后能不能接着干。 崩了、超时了之后，是回到现场续跑，还是要你从零重新解释一遍上下文。
- 会不会自己跑测试并改到过。 会反复执行测试、看着失败自己修、修到绿的 Agent，比只吐代码的壳高一个层次。
这三条行为都是能当场观察的，不需要厂商黑话。下次有厂商宣称自己的编码 Agent 更强，先抛开它给的分数，丢两个小任务进去看它怎么动：一个是会改文件的，一个是要跑测试到过的。 看它是主动拆任务、回写仓库、修到测试过，还是连启动都失败。这一看，比多读十个 benchmark 表都准。
