如何在编码代理中测试Qwen3.8-27B？

我已在本地运行Qwen3.8-27B并连接到EvoX。基本聊天功能正常工作。这是容易的部分。我想找出在编码任务变得复杂、代理需要读取代码库、调用工具、从错误的首次尝试中恢复并保持多轮对话时，我是否信任它。EvoX是我已连接到本地模型的框架。我将比较限制在该设置内，重点关注Qwen在代码库和工具介入后的行为。这不是为了排名桌面代理应用。我自己的大多数实验都是小型网络工具，因此我选择了能够检查代码和结果而无需模拟生产基准测试的任务。单个令人印象深刻的提示也告诉我太多。我读到的大多数早期Qwen3.8-27B测试都提到了同样的烦恼：xhigh可能长时间陷入推理，而medium通常看起来更实用。我想在主要比较中使用推理级别。我将从截图到页面的构建开始。low、medium和xhigh将分别使用相同的参考图像和提示，在一个干净的前端代码库副本中进行。工具、上下文限制和超时保持固定。EvoX经验重用将关闭，以便后续运行不能从第一次运行中继承有用的提示。我选择这个任务是因为它可能以明显的方式失败。页面初看可能接近，但按钮无效或资源损坏。模型也可能花费一半时间添加我从未要求的功能。我将比较首次工作的渲染与最终截图，然后检查构建输出、缺失交互、修正轮次和总时间。我还想要推理令牌计数和首次工具调用时间。如果模型花费十五分钟规划才接触文件，即使是一个好页面也吸引力大减。如果某个设置在结果和等待时间之间给出了明显更好的平衡，我将给它一个更难的第二次任务：构建USGS地震仪表板。我将从保存的GeoJSON固定数据开始，以保持数据固定，然后切换到实时馈送。该应用程序必须渲染地球、正确映射震级和深度、过滤可见事件、打开正确的详情并保持时间线可用。我将保留重复命令、浏览器检查、无关编辑以及仅在启用实时馈送后出现的任何失败。这听起来像一个公平的测试吗？我是否遗漏了重要的控制或失败案例？如果您在代理框架中使用过Qwen3.8-27B，您还会测量什么，以及您会尝试什么其他任务？