我让 Qwen3.6-27B 真改了一次 Git 仓库：工具调用怎样形成 Agent 闭环

之前测这套 27B 服务时，工具调用已经能返回标准 JSON，工具名和大部分参数也能填对。但那组 Agent 任务运行在内存里的模拟文件系统，没有真正执行 pytest，也没有产生 Git diff。它能说明模型会说"我要调用什么"，还不能说明它能把一次代码任务做完。

服务器恢复后，我换了一种测法：临时创建一个真实 Git 仓库，放入一处边界错误和三条 pytest 用例，只向模型开放五个受限工具。模型需要自己查看文件、运行测试、修改源码、再次运行测试并检查 diff。我还在第二轮故意让第一次补丁失败，观察它能否恢复。

两组任务最终都通过。这个结果没有证明 Qwen3.6-27B 已经兼容 Claude Code，也没有证明它适合生产 Coding Agent。它证明的是一个更窄、也更有用的结论：当前服务能够在受控 Harness 中完成一次真实文件副作用、测试判定和失败恢复闭环。

这次探针创建的仓库很小：src/bounds.py 中的 clamp 写反了上下界，三条测试覆盖区间内、低于下界和高于上界。初始 pytest 必须失败，最终 pytest 必须通过，而且 Git diff 必须非空。缺少其中任何一项，场景都判失败。

模型没有获得任意 Shell。它只能调用：

这里的"真实"指文件、Git 和 pytest 都实际发生，不是用内存对象伪造工具结果。它仍是隔离实验，不是真实业务仓库，更不是生产 E2E。

普通场景的工具轨迹是：

text 复制代码

list_files
→ read_file(src/bounds.py)
→ read_file(tests/test_bounds.py)
→ run_tests（失败）
→ apply_patch
→ run_tests（通过）
→ git_diff
→ 总结

模型找到了错误表达式：

diff 复制代码

-    return min(lower, max(value, upper))
+    return min(upper, max(value, lower))

初始测试退出码为 1，修改后的退出码为 0，三条测试全部通过。最后的 Git diff 只包含这一行修改。模型的总结也只报告已发生的修复和测试结果，没有把"看起来正确"写成"已经通过"。

这条轨迹比单次 tool-call JSON 多验证了三层：工具结果被带回下一轮，文件副作用真的落盘，外部测试而非模型自评决定任务是否完成。

只测顺风任务，很容易把 Harness 的配合误算成模型能力。第二组场景在模型首次调用 apply_patch 时返回 injected_patch_conflict，并要求重新读取文件后再提交精确替换。

模型没有立即重复调用补丁工具。它先按错误提示重新读取 src/bounds.py，随后再次提交了与第一次相同的精确替换，再重跑 pytest 并检查 Git diff。第二组用了十轮，最终仍然是三条测试通过、单行 diff。

这只能证明一次明确、可恢复的工具错误被正确处理。它没有覆盖网络超时、工具返回脏数据、并发修改、上下文压缩或多轮失败。把"失败恢复"写进测试，价值在于能看见模型收到错误后如何更新动作，而不是只统计最终是否成功。

这次测试也暴露了能力归因边界。

模型负责读取线索、选择工具、生成参数、根据测试失败定位问题，并在补丁冲突后调整动作。Harness 负责目录隔离、路径校验、允许的文件类型、固定测试命令、精确替换规则、轮次上限和最终成功判定。

探针代码还专门处理了 macOS 临时目录的路径别名：同一目录可能显示为 /var/... 和 /private/var/...，因此仓库根目录与候选文件都先经过 realpath 归一化，再执行越界检查。这是 Harness 的静态实现合同，不属于本轮模型成功结果。

这个实现细节说明评测 Harness 本身也必须接受审计。如果路径守卫、工具返回或成功判定写错了，最终失败率就会混合模型、协议和环境三种原因。没有冻结 trace 时，也不能把工具开发过程中见过的现象登记为模型成功或失败。

以后评测本地 Coding Agent，我会至少保留以下六项：

这六项不是通用排行榜。它们是一份最小实验合同，用来回答"这个模型与这套 Harness，能否完成这个范围内的任务"。换模型、工具实现、提示词、仓库难度或成功判定后，都应视为新的实验条件。

当前服务在 10.10.6.121:8000 暴露的模型名是 Qwen3.6-27B。旧基准使用的 qwen3.8-27b 入口已经关闭，因此这次新证据不能回填给旧服务别名。

本轮也没有调用 Claude Code 的 Anthropic Messages 接口，没有验证并行工具、取消、超时、上下文压缩、会话恢复、多文件重构或长时间任务。两次小型成功不能换算成通过率，更不能写成生产稳定性。

下一步若要验证"Claude Code 兼容"，应该固定客户端版本和协议入口，保存完整请求、工具调用、错误与恢复轨迹，再用多文件任务和更长任务逐级增加难度。在这些证据出现前，准确的结论仍然是：Qwen3.6-27B 已通过两组受控的真实 Git Agent 探针。