智能体应如何看待代码？重新思考面向智能体的软件工程中的代码表示

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，耗时也更长。总体而言，基于图谱的工作流既改变了智能体检查的内容，也改变了其资源消耗，但其收益取决于具体任务，并非普遍适用。