调优本地 Qwen 编码 Agent：哪些改善了，哪些仍会失败

给这套本地 Qwen 编码 Agent 更多单次响应空间后，输出上限从 8K 提高到 16K、再到 32K，观察到的成功交付数从 5/24 → 14/24 → 20/24。随后保持 32K 上限不变，将推理设置从 medium 改为 xhigh，结果达到 23/24。代价是等待更久：整段调优过程中，单次任务耗时中位数从 245.5 秒升到 775.8 秒。

这是有价值的开发集结果，还不能证明 Agent 的通用编码能力提高了。各轮复用了较早的对照，以及同一批八道题。后续降低温度的测试少完成了一次交付，而独立留出集确认一次也没有运行。

这篇延续本地部署教程和 MTP 对比，把两次调参决定分别讲清楚：先让一次响应有空间完成，再在相同空间内比较推理设置。前两篇采用不同协议，得分没有混入本轮。

写作说明：本文由 AI 辅助，根据实验记录和经过审查的开发集导出数据撰写。公开检查脚本验证的是汇总计算，不验证补丁语义，也不能证明泛化能力。

四个容易混淆、作用却不同的设置

OpenCode 负责读文件、调用工具、修改代码和运行测试。本地 llama.cpp 服务生成 reasoning（思考输出）、工具请求和文本。一次修复可能经历多次模型响应，最后才由 Agent 给出交付说明。

因此，需要把四个限制分开看：

• 单次输出上限： 一次模型响应最多生成多少 token。思考、工具请求和最终文本共用这份额度；8,192-token 上限并不是思考结束后，还能留给答案的 8,192 tokens。
• 推理设置： 通过模型聊天模板选项传入的 effort 标签，本文比较 medium 和 xhigh。两者都开启 thinking。标签不是测得的内部计算量，也不保证生成某个数量的思考 tokens。
• 上下文容量： 服务最多容纳 131,072 tokens 的上下文，输入与输出共享空间。这不表示每次响应都能输出这么多，也不证明在满容量下的编码质量。
• 整次任务预算： 每次修复最多 1,800 秒、65,536 个生成 tokens、120 次工具调用。它约束跨多次响应的整个任务；提高单次输出上限，不会同步提高这些预算。

成功也分两层。功能成功（functional success）要求候选代码通过所有必需的独立评分检查，并保持配置不变。交付成功（delivered success）还要求 Agent 完成规定轮次、正常退出、完成自身被识别的验证，并在工具执行后给出最终文本。四个主批次的两项计数恰好一致，但后面的温度测试出现了差别。

第一阶段：提高输出上限，保持 medium 推理

尝试扩大额度有一个具体理由。在之前的部署和 MTP 实验中，部分任务把整份 8,192-token 响应额度花在思考上，还没修改生产代码就结束了。增加上下文解决不了这个限制。因此，本轮开发集要问的是：更大的单次输出额度，能否让更多修复走到可用补丁和最终交付？

这一阶段始终开启 thinking，推理保持 medium，只将配置中的输出上限从 8,192 → 16,384 → 32,768 tokens 逐步提高。上下文仍为 131,072，温度仍为 1.0，整次任务预算也不变。

下表每行都是同样八道开发题，每题重复三次。第四行属于下一阶段，那时输出上限不再变化。

来源：批次汇总。中位数包含失败任务，不含服务启动、任务间休息和独立评分。这是观察到的等待时间，不是完成相同工作的加速比。

改善出现在几种不同修复上。考查并发数量限制与失败恢复的异步任务池，从 8K 下的 0/3 提高到 16K 下的 3/3。考查确定性依赖规划和兼容性的构建规划器，随上限提高，从 0/3 → 1/3 → 3/3。这些例子说明，比起生成了多少 tokens，更值得看的是完成了多少修复。

但空间更大，也没有解决所有问题。分页任务到 32K 时达到 2/3；考查精确金额和安全错误处理的 CSV 账本，在三个 medium 上限下始终为 0/3。这个剩余缺口引出了下一步：保持响应空间不变，换一种推理设置，是否会有帮助？

等待成本也要算进去。8K 到 16K 的耗时中位数翻了一倍多，32K 又进一步增加。一次失败很快结束，不等于成功修复很快；更大额度也可能只是让一次无效尝试继续更久。

第二阶段：固定 32K，比较 medium 与 xhigh

这一阶段把配置中的 reasoning_effort 从 medium 改为 xhigh。日常讨论中提到的“extreme high”，在这次记录里对应的就是 xhigh。输出上限仍为 32,768，两种模式都开启 thinking。 这不是开启与关闭思考的对比。

实际记录的 OpenCode 配置里，输出上限是 limit.output，effort 标签是 body.chat_template_kwargs 中的 reasoning_effort，同处还设置了 enable_thinking: true。两者是不同控制项。xhigh 通过模板请求另一种推理模式，但这不能证明每次响应都用了更多计算，也不表示服务分配了一个已知的额外思考预算。记录支持的是配置对比，而不是内部思考深度测量。

两项成功数都从 20/24 提高到 23/24。三次配对改善全部来自两道题：账本从 0/3 提高到 2/3，分页从 2/3 提高到 3/3。其余六题都保持 3/3。账本仍有一次失败，因此这个开发集结果也不是每次都成功。

任务耗时中位数从 586.6 秒增加到 775.8 秒。这才是编码工作流需要衡量的取舍：这些题里更多修复完成了，但这些记录中，典型的一次任务需要等待更久。它不能证明 xhigh 会改善所有任务或所有本地模型。

为什么改善仍然只是初步结果

各批次的题目和重复标签能够对应，但对照来自较早的运行。输出和推理轮次都是看过前一轮结果后进行的顺序扩展，没有重新随机交错运行对照。休息策略和恢复历史也有变化。因此，配对标签能描述观察到的转变，不能单独归因于 xhigh。

主批次包含八道不同的小题，而不是 24 个独立生产仓库。重复运行共享题目和检查，后续工具操作也可能分叉。选出的 xhigh / 32K / temperature 1.0 整套配置值得继续验证；这些结果还不能确定通用最优配置，也不构成新的采用决定。

降低温度，暴露了补丁与交付的差别

推理对比之后，在 xhigh/32K 下对账本和分页测试了 temperature 0.8，每题三次。这两题是根据此前失败挑出的。温度 1.0 对照复用了原 xhigh 批次的六次运行，没有同时新跑六次对照。

账本运行 a0100 通过了两次独立评分，但在 1,800.017 秒触及时间上限，以退出码 -15 结束，没有最终文本。它算功能成功，却不算完成交付。另一条账本运行 a0101 正常退出，Agent 自己的测试通过，也有最终文本，但独立验收检查失败，因此两项成功都不计入。

这两个例子说明，Agent 自测全绿、补丁正确、最终交付完成，需要分别记录。按题目和重复标签配对，温度 0.8 有一次功能改善、一次回退；交付则有一次改善、两次回退。这个定向结果不支持把 0.8 当作更好的默认值。

独立确认根本没有启动

冻结的留出集协议计划用四道新题、每题三组配对、两种配置比较 medium/8K 与 xhigh/32K；两者均采用温度 1.0 和 131,072 上下文容量。合计应有 24 次运行、12 组配对。

启动前检查因历史 CPU machine-check（机器检查）记录所反映的硬件就绪问题未解决而停止。原因仍不明：这些记录不能诊断哪个部件损坏，也不能证明问题由确认实验引起。后续保留的观测中没有新匹配事件，本身也不足以解除硬件阻塞。另一个独立前提——OpenCode 资源归属——也未解决。两道检查都没有被绕过。

确认运行数为零，完整配对为零，没有任何确认质量测量。 缺失观测不能写成每种配置 0/12 成功，也不能算模型失败。没有进行确认实验的模型推理、运行时身份测量或新权重哈希。继续测试需要独立解决硬件就绪和软件资源归属；仅凭开发集，还不能回答改善是否能迁移到新题。

6760f39c13e67f0814edbdaf314b3572d985c30c8ef94752631e551482e423cd

在自己的工作流中怎样比较

有用的顺序是先辨认失败。如果某次响应达到输出上限，还没有产生有用修改，可以固定推理设置，比较更大的输出额度。理解这一步之后，再固定上限比较推理设置。把独立验收、失败运行和耗时放在同一份记录里，也检查实际 diff 和最终交付说明。

修改正常工作的部署前，保存配置，记录实际请求额度、thinking 选项、采样字段和模型摘要；回退时恢复保存的配置。部署教程介绍接入方法，本文提供的是历史配置数值，不是完整启动命令或开箱即用的基准测试框架。

{
  "limit": { "context": 131072, "output": 32768 },
  "body": {
    "chat_template_kwargs": {
      "enable_thinking": true,
      "reasoning_effort": "xhigh"
    }
  }
}

f5f1dd8920d417aac2718b0bda3403da274301efdd6760b4f0f4b864ff2ad57d

下载数据，重新计算结果

公开导出包可以不启动模型，直接重新计算汇总。将以下八个文件下载到同一目录：

• README.md
• protocol.json
• attempts.json 和 attempts.csv
• aggregates.json 和 aggregates.csv
• check.py 和 SHA256SUMS

使用 Python 3.10 或更新版本执行：

python3 check.py

不需要网络或模型，也不会写文件。文件缺失、修改或出现非预期文件时，检查失败。这只是汇总计算复现，不会重跑推理或评分、验证补丁，也不能证明原始记录为真。