Qwen 3.6/3.8 自主编码 C 编译器的探索之旅

大家好，三月底，我开始尝试使用 Qwen 3.6 27b，发现像其他人一样，它在工具调用方面非常出色，之前我尝试的其他模型在几轮后就会偏离，而它能持续进行，并且在小模型之外表现得相当可靠。我决定尝试一下，看看能否定制一个检测系统，如果检测到重复、空答案等问题（后来通过更新的 Jinja 模板部分解决了其中一些问题），并结合一些新颖和基础的想法，这些想法在先进的智能体系统中很常见。 几周后，我有了一个看起来对简单测试应用/工具相当有效的系统，我遇到的大多数问题都与上下文有关——也就是说，我使用 llama.cpp 作为推理引擎，没有上下文切换，因此智能体的上下文管理极其重要，我有一些想法想在这里测试。 七月初，系统达到了我想要的状态，我想看看智能体和模型本身能被推到什么程度。整个想法是尝试强制模型进行研究然后执行，而不是依赖它的内建信息。同时应用一套非常严格的通用规则集，包含多个子代理——规划者、编码者、调试者、研究者、验证者等——专注于各自的任务，以进行结构化、重新规划和执行。 我给它一个提示：'我想制作一个能够生成可工作的 x64 ELF 文件的 C99 C 编译器'，于是它开始了。头几天（我的推理设备是 Tesla P100 加上 RTX 4070 用于 Qwen 模型，推理速度大约 13-14 token/s，预填充约 250 token/s），然后我在另一台机器上运行 Gemma4 12b 在 Intel Arc B580 上，这通常用作验证器。 除了对编排进行一些小调整（特别是上下文管理，更准确地说是压缩/修剪，这非常棘手，因为很容易陷入系统花费 6-7 分钟预填充然后预测直到下一次工具调用的情况，这又会触发强制修剪并破坏 KV 缓存，如此反复，这显然负面影响了系统速度——这也是它花费 6 周的主要原因，直到 3 周后我才找到好的解决方法），另一个主要问题是当它开始生成 x86 代码时，这非常令人沮丧，因为它宁愿凭空编造操作码也不愿去查阅，最终通过使编码者/调试者的系统提示更加严格并鼓励使用 libcapstone 等工具得到了改进，但不可否认这是最麻烦的领域，它在这里花费了大部分时间长达数周。 说到这个，它连续不间断运行的最长时间是 1 周，除此之外，对提示和编排器架构进行了大量改进和调整（我可能有一天会在另一篇文章中描述编排器架构，但我不想在细节上深入，直到或如果我开源它，目前它非常针对我自己的设备，并且我真的没有精力，因为我已经花了大约 6 个月几乎每天几个小时在这件事上，试图将其通用化）。 总之，我的目的只是提供一个例子，说明 Qwen 3.6/3.8（我在 3.8 发布当天升级了模型）27b 如果引导得当并给予合适的环境，是极其强大的。（我可能错了，但我相信这可能是我见过它产出的最先进的项目）。产出的项目可以在这里找到：https://github.com/Na1w/tc