经过一番努力，我终于能稳定地进行测试了。测试过程中出现了许多令人困惑的小错误。我的项目目录中没有.mcpignore文件，代理程序就只能在项目目录中漫游，寻找更好的例子来使用提示。第一次几次运行的token使用量在几百个token之间似乎很奇怪。另外，越大的上下文越容易导致单元测试失败，这意味着试图扩展到更大的功能会导致明显的错误。找到了一份神秘的godot模板，我迭代了一项简单的功能，直到我锁定了概要设计。与claude-ai的免费token进行比较，我能够在没有过于具体到方法的基础上排除掉一些单元测试。设置了约6个模型配置和3个mcp配置。基于godot文档，我构建了一个RAG chroma-db，并允许fetch工具和各种迭代。随后关闭了RAG和fetch工具，结果自然是最差的。迭代还没有测试，但我注意到一些未被跟踪的工具调用失败。这个数据集表明系统提示和温度并不重要，但未经过调整的模型仍然会出现各种错误。目前我知道的最好结果的组合使用了最高的token数量。但是，低token用户、低服务用户和低运行时间的组合肯定是遭受着静默的未跟踪错误。目前我观察到的系统提示中，我鼓励它进行子代理代码审查，但这并没有发生。测试了一次仅仅调用子代理，结果显示在指标中，但两个模型都没有调用子代理。mlflow的一个好处是它仅仅是一个数据收集器。因此，可以设置任何管道，并且有方法来收集数据。最初我打算比较另一个mcp-go-lang主机，但最终我发现我最初尝试的mcp-host在交换tab和空格时出现问题，这对于godot来说是一个非起始点。一旦我意识到问题，我就没有再回头了。现在我有一个客观的方法来测试和衡量本地模型。可以确定RAG服务是否值得使用，或者仅fetch就足够了。另一个有趣的见解是尝试自我压缩系统提示时，低温度会导致更多的工具调用；有利于更详细的描述和更大的创造性/温度范围以获得更好的结果。目前我仅尝试了Qwen3:30b和Gemma4:26b，但还没有手动测试Qwen。真正让我感兴趣的是，如果管道能够适应RL e2e测试和更新这些测试。使用gemini来建议与两个模型相似的目标参数。令人惊讶的是，稍微更具创造性（更高温度）的模型似乎更好，但我的见解目前仍然是有偏见的。我也尝试了Claude，它能够很好地实现目标，但需要一些后续提示。开放模型在一次性提示中表现得更好。我希望能在github上分享一些内容，但在我精简和扩展测试套件时又出现了更多的错误。我只是很高兴终于能稳定地进行测试，并且所有脚本都能正常工作了……但我也很高兴能够通过模板的方法测试系统提示和提示。