Napalys Klicius是GitHub构建代理系统的软件工程师。他的职业生涯使他从模型检查到低级C + +无人机系统和静态分析，以及最近教代理如何在不迷路的情况下检查代码。为客服代表提供更好的工具，它应该可以做得更好。不管怎样，这就是本能。
当您打开拉取请求时， Copilot代码审查会读取差异并浏览周围的代码，以便在发货前找到重要的问题。为此，它使用了自己的代码探索工具。因此，当我们更换了维护更好的共享工具，为Copilot CLI、grep、glob和view提供支持时，我们期待的是一次干净的升级。相反，在我们的基准中，我们发现评价的成本更高，发现的问题更少。
但工具并不是问题所在。这些说明是。一旦我们根据评价者实际阅读拉取请求的方式重写了这些说明，回归就变成了一场胜利：平均评价成本降低了大约20%，同时保持了相同的评价质量。以下是围绕工具调整工作流程如何引导我们进行修复的故事。
同样的工具，错误的本能如果你在代理框架之上构建，你可能也继承了它的工具。它们起作用，所以你保留它们，直到有一天你的用例远离它们的设计目的，他们悄悄地开始与你作对。这就是我们所处的情况。在尝试使用共享CLI工具之前， Copilot代码审查使用了自己的代码探索工具。
该工具层的灵感来自早期的代理系统，包括来自SWE代理风格存储库导航和GitHub Copilot Autofix的想法：列出目录、搜索文件、搜索目录和读取代码。这些工具是有效的，但它们是特定于Copilot代码审查的，并且它们是为当时模型的行为而设计的。早期的代理编码模型进行的工具调用较少，并且在必要的上下文中自动拉动情况较差。