智能体该如何"看"代码？重新审视面向智能体软件工程的代码表示

查看 PDF HTML（实验性）

摘要：LLM 智能体越来越多地被用于仓库级软件工程任务。然而，大多数智能体仍通过原始文件、词法搜索和 shell 命令访问仓库，主要将代码视为文本。本文研究基于地图的代码表示工作流作为智能体软件工程中的一个设计变量，考察不同的仓库视图如何改变智能体的检索行为、任务成功率、token 使用量和延迟。
在本文中，我们研究了五种代码表示工作流：抽象语法树、调用图、模块依赖、文档增强搜索，以及将它们结合起来的混合工作流。每种工作流都提供一个仓库地图，智能体可在任务期间查询。我们在四个仓库级任务上，使用 Haiku 4.5 评估 Claude Code，并与原始工具基线进行对比：使用 LinuxFLBench 进行故障定位，使用 SWE-bench Pro 进行仓库级代码生成与修复，使用 SWT-bench 进行测试生成，以及使用 SecBench 进行安全补丁。
结果表明，当定位是瓶颈时，表示工作流作为节省 token 的工具最为有用；而当决定性步骤是编写补丁或测试时，其成功率提升幅度有限。在 LinuxFLBench 上，五种工作流均将 recall@10 提升至基线之上（0.757-0.829 对 0.717），并将 token 使用量减少 25-39%。在 SWE-bench Pro 上，解决率与基线接近（44.3-50.6% 对 49.0%），而 token 使用量下降 17-26%。在 SecBench 上，Callgraph 在本样本中具有最高的补丁解决率（34.3% 对 28.9%）且使用的 token 更少，但所有工作流都增加了延迟。在 SWT-bench 上，Hybrid 和 Docs 在本样本中具有最高的复现测试率（47.8% 和 47.2% 对 44.7%），但所有工作流都使用了更多 token 且耗时更长。总体而言，基于地图的工作流既改变了智能体检查的内容，也改变了其花费的多少，但其收益取决于任务，而非普遍适用。

提交历史

来自：Melika Sepidband [查看电子邮件]
[v1] 2026年11月5日星期四 01:08:43 UTC（759 KB）