原文：https://dev.to/debashish_ghosal/i-compared-a-local-4b-a-better-cloud-model-and-role-separation-the-results-were-weird-aj8（作者 @debashish_ghosal）
先前文章： 9个看似正常工作的系统Bug · 我构建了一个能重写自身提示词的AI · 一次修复4个任务却搞砸1个的编辑 · 我让LLM重写自身提示词。真正的赢家是拒绝它的门。 · 我尝试了4个模型来拯救我的自改进Agent。全部失败。
AgentSelfEdit 是一个开源的 sidecar，它从执行反馈中重写自己的系统提示词。它对编辑进行 A/B 测试，并仅提升经过统计证明有效的赢家。
仓库：github.com/deghosal-2026/agent-self-edit/tree/v0.3.0
我原以为这次对比会很无聊。
小的本地模型差。更大的云模型好。将角色分配到不同模型上，事情会变得更好。
这个故事会很干净。但它告诉我的会更少。
v0.3.0 实际展示的是更混乱但更有用的。
三种设置
我运行了三个相同自编辑循环的版本：
- 本地
Qwen3-4B-Instruct-2507-4bit - 云
mistralai/mistral-small-3.2-24b-instruct - 一个角色分离设置，使用不同的执行器和分析器
每次的基本流程相同：收集失败的跟踪，让分析器提出编辑，对候选与当前提示词进行 A/B 测试，然后运行门控。
对于主要分类现场测试，提升语料库有 40 个任务，保留集有 25 个任务，门控要求 p < 0.05，最小效应大小为 >= 5%。
所以这不是一次直觉对比。所有模型都面临相同的证据标准。
本地4B模型比我预期的更平
本地模型是 Qwen3-4B-Instruct-2507-4bit。
主要结果：
- 基线：
60.0% - 最终：
60.0% - 迭代次数：
5 - 提升次数：
0
这已经不算好了。但逐任务分解才让我明白。
大多数迭代没有效果。
- 迭代1：
0提升，0退步 - 迭代2：
0提升，0退步 - 迭代3：
1提升，1退步 - 迭代4：
0提升，0退步 - 迭代5：
1提升，1退步
这不是“统计隐藏了真正改进”的故事。它主要是一个空编辑故事。
本地模型仍然有用。它便宜、稳定，足够用于执行器或基线工作。但作为分析器，它一直在同一小块地上打转。
这是第一个意外。
更大的云模型有帮助，但帮助不大。
然后我切换到 mistralai/mistral-small-3.2-24b-instruct。
这是第一次运行，感觉可能真的教我一些新东西。
主要结果：
- 基线：
64.0% - 报告的最终保留工件：
68.0% - 迭代次数：
8 - 提升次数：
0
那个 64 -> 68 的数字需要警告标签。没有提示词实际被提升，所以这不是一个已部署的改进声明。现场测试报告对此很谨慎，它应该如此。
更重要的是 A/B 数据中的最佳迭代：
2提升0退步mean_delta = 0.05effect_size = 0.0625p = 0.79
这是项目首次产生小而干净的积极移动，而不是平局或抵消。
所以是的，更强的模型有帮助。
但它帮助的程度不如通常“使用更大模型”的故事所暗示。它使优化器更好。但它没有使其足够好。
这是第二个意外。
角色分离运行是所有结果中最奇怪的
v0.3.0 发布了一个角色分离的运行器，使得执行器、分析器和评判器可以是不同的模型。
这听起来是显而易见的下一步。使用更便宜的执行器，更强大的分析器，也许在需要时使用更强大的评判器。混合搭配，从每个角色中获得最佳效果。
首次运行使用了：
- 执行器：
qwen/qwen3-30b-a3b-instruct-2507 - 分析器：
mistralai/mistral-small-3.2-24b-instruct - 迭代次数：
3 - 留出样本：
5 - 提升样本：
10
然后，它做了一件我完全没预料到的事。
它没有产生任何提案。
不是差的提案，不是弱的提案，是零提案。
基准测试是正常的，为 60.0%，运行目录存在，analysis.json 文件存在，prompt-a.md 也存在，并且没有 error.txt 文件。但 prompt-b.md 和 ab-comparison.json 从未出现，因为运行根本没有进展到那一步。
这是第三个惊喜，也是最大的惊喜。
显而易见的理论是：更强的分析器等于更好的提案。
角色分离的运行表明这个理论是不完整的。
分析器不是对抽象的任务标签起作用，而是对失败的跟踪记录起作用。改变执行器，你就改变了失败。改变了失败，你可能改变了分析器是否能看到足够稳定的东西来转化为一次编辑。
这是一个比简单的排行榜有趣得多的系统性结果。
三次运行中保持不变的部分
这部分让我确信，瓶颈不仅仅在于模型规模。
即使模型改变了，失败模式仍然熟悉。分析器们持续地向同一类编辑方向偏移：
- 紧迫性边界重写
- 局部措辞澄清
- 狭窄的规则收紧
我较少看到的是：
- 结构性的提示更改
- 更广泛的任务分解更改
- 真正多样化的提案类别
- 从对失败的最初、最直接的解释中真正逃离出来
这指向一个搜索问题，而不仅仅是算力问题。
坦诚的比较
- 本地 4B 模型：便宜、稳定、适合机制性工作；大多产生无效编辑。适合执行器/基准工作，但分析器的搜索能力较弱。
- 单一模型 Mistral 24B：首次获得真正的积极信号；仍未达到提升。更大的模型有助于提升提案质量，但还不够。
- 角色分离 Qwen 30B + Mistral：运行器正常工作，基准正常；零提案。仅分析器更强是不够的；执行器的输出塑造了分析器的行为。
这不是我预期要写的那种结果。
这比我预期得到的结果更有价值。
我学到了什么
首先，更大的模型可以提升信号，但不能解决实际问题。这听起来显而易见，但人们常常混淆这一点。“更好”并不等同于“好到可以信任”。
其次，角色分离改变了优化的格局。我曾假设这主要是一个路由和成本的故事。结果却发现这是一个行为塑造的故事。不同的执行器输出给了分析器一个不同的失败表面来处理。
第三，对于此类系统，不检查产出物的模型对比过于肤浅。有用的真相不在于单个分数，而在于出现了多少提案、提案的类型是什么、哪些任务发生了变化，以及循环在哪里停止。
在 v0.3.0 中还有一点变得明显：在没有提升的运行中报告的最终准确率需要加一个警告标签。如果部署的提示词从未改变，一个看起来更好的最终留出数据并不等同于已发布的改进。这大概应该成为代理实验的标准报告规则，否则人们会将产出物中的变动误读为生产行为的改进。
开发者为何应该关心
如果你正在构建任何多模型代理系统，我认为重要的结论是：改变模型会改变失败表面，而不仅仅是分数。
这意味着一个更强的分析器可能仍然被困在一个狭窄的局部中。一个不同的执行器可能会改变分析器能注意到的东西。一个更复杂的架构并不会自动变得更好。
这不是反代理的建议，这只是提醒我们，耦合是真实存在的，即使图中的方框看起来很整洁。
我带着对更好模型的简洁故事的期待进入了 v0.3.0。
我得到的是一个关于模型质量在何时有帮助、何时没有帮助，以及架构本身如何快速地开始塑造系统所能学习到的内容的、更有用的故事。
如果你在选择下一个实验，你会运行什么：另一个更强的单一模型分析器、一个更深入的角色分离运行，还是用相同模型处理更大的语料库？当更大的模型只是在边际上有所帮助时，你如何判断问题是模型质量、搜索策略，还是仅仅是保守门控的数学问题？
原文：https://dev.to/debashish_ghosal/i-compared-a-local-4b-a-better-cloud-model-and-role-separation-the-results-were-weird-aj8（作者 @debashish_ghosal）
