会探索，但不知道这个 issue 最好怎么探索
模型在大量代码上训练过，已经大体知道怎样探索一个代码仓：搜索、阅读、复现、测试。它无法事先知道的，是在这个代码仓里，这个任务最好怎么入手：该用哪条实践，先检查什么，修改又要怎样和现有代码契合。
没有什么能保证对的实践在对的时刻被想起来，而私有代码库本来就不在训练数据里。于是提升只能靠多试：更多采样，更多重试。覆盖面变大了，针对这个 issue 的方向却没有。
相关工作：测试时扩展，先采样大量候选补丁再从中挑选，例如 Trae、DARS、DEI。
01 · 动机
隐性知识告诉开发者该往哪里看。
有经验的开发者面对一个 issue，是怎么入手的？在开始探索之前，他们其实已经知道一些东西。
在学习和工作中，开发者自然积累了隐性知识：某一类问题该怎么理解、怎么分析、怎么解决。新问题很少和旧问题完全一样，所以他们会从很多过去的案例里抽出几个共通的模式，由这些模式一起决定先去哪里看。知识在前，探索在后。
有经验的开发者
借助过去案例的共通之处
从一个慢页面出发，可以走的路有很多。开发者只走其中一条：经过视图和 ORM，找到逐条发出的查询，并且很早就排除了一条岔路。编号的几步就是过程；而“为什么”让这个过程能用到下一个慢页面上，哪怕换了一个代码库。这就是过程性知识：一类问题怎么诊断、怎么修，以及为什么。它是隐性的：存在于经验里，不在代码里。
过程性知识
当页面加载很慢时：
- 1数一数数据库查询的次数
- 2找到发出这些查询的循环
- 3在查询日志里确认
为什么逐条查询，即 N+1 问题，是常见原因。
今天的 coding agent 如何探索
同样的情境下，coding agent 带着三样东西
1
模型自身的知识
存在权重里的通用编程经验：很强，而且每一代模型都在变强。
2
当前的代码仓
它现在的代码和文档。
代码库与文档
3
探索与遍历
采样、分支、重试：很多条轨迹。
③ 借助 ① 去探索 ②。那么问题来了：面对这个 issue，对的那条经验会被想起来吗？
今天的 agent 缺什么
不一定，原因有两个。
现在的 agent 在一般意义上很会探索。但有两件事，让这种探索没能沿着适合当前 issue 的过程进行。
没有过程性知识，或只把历史当原始数据用
很多 agent 完全不用：它们只依据现在的代码和文档工作，而这些只记录了当前状态，没有记录类似的 issue 当初是怎么处理的。用到历史的那些，也只是把它当原始数据：以文本形式检索过去的 issue 报告和补丁。改了什么保留了下来，背后的过程却丢了：这个 issue 是怎么诊断的，为什么这样修。
照搬的修改只有在新 issue 几乎一模一样时才有用。真正能迁移的，是修改背后的过程。
Issue 报告
当作原始数据保存
丢失的：过程性知识
- 怎么诊断的根因分析步骤
- 为什么这样修修复模式
- 怎么验证检查清单 · 测试
- 怎么契合代码设计实践
最终补丁
相关工作：使用当前代码仓的代码图和 AST，例如 Agentless、AutoCodeRover、CGM；以文本形式使用相似的历史 issue，例如 SemAgent。
灵犀做了什么灵犀从代码仓自己的历史 issue 和补丁中恢复过程，把它抽象成能迁移到类似 issue 的知识；新 issue 到来时，再把相关的部分摆到 agent 面前。过去的修复是知识的来源，agent 拿到的是过程。
02 · 方法
离线恢复过程，引导每一个新 issue。
灵犀分三个阶段。阶段 1 对每个代码仓的历史只运行一次；阶段 2 和 3 针对每个新 issue 运行：检索到的知识先引导分析，再引导规划和修复。
1阶段 1 · 离线知识构建
从针对具体 issue 到可迁移的知识。
一次历史修复只留下两样东西：issue 报告和最终补丁，中间的过程是缺失的。知识 agent 分两步把它找回来。第一步做逆向推理：从补丁出发，浏览 issue 发生时的代码仓快照，解释每一处修改为什么能修好这个 issue。第二步把结果抽象化，使它能迁移到相似但不完全相同的 issue 上。
知识按代码仓、从它自己的历史中构建；对每个目标 issue，只使用在它之前创建的 issue。
第一步 · 逆向推理
针对具体 issue 的知识
知识 agent 从补丁出发，沿 14 个维度解释每一处修改为什么能修好这个 issue。
理解 8 个维度
定位并理解这个 issue 需要什么
代码
相关架构依赖分析调用链
问题
缺陷分类根因分析当前行为与预期行为
使用
使用场景示例功能特性
修复 6 个维度
修好它并验证修复需要什么
修改
修复模式具体修复步骤
验证
修复检查清单测试用例
契合
设计模式与编码实践解决方案结论
根因分析 · django #14200 · 第一步"The bug was caused by:
- Direct instantiation of
RegexURLResolverinstead of using the memoizedget_resolver()- Each request created a new
RegexURLResolverinstance, even when processing the same URLconf- The memoization optimization in
urlresolvers.get_resolver()was bypassed- No consideration for memory/performance impact of creating new resolver instances"
第二步 · 抽象
可迁移的知识
把同样的知识改写给刚接触这个代码仓的人看：通用、可操作，并且结构化，便于后续阶段使用。
理解
通用、可操作
代码
相关架构依赖分析涉及的类与方法
问题
通用根因分析步骤缺陷分类功能特性
修复
供规划和修复直接使用
修改
通用修复模式
验证
通用修复检查清单
契合
设计模式与编码实践
通用根因分析步骤 · 同一个 issue · 第二步
- "Identify the request handling flow and URL resolution process
- Review how URL configuration is managed during request processing
- Analyze object creation patterns and resource usage
- Check for performance optimization opportunities like caching/memoization
- Verify thread-safety and resource cleanup mechanisms
- Test behavior with different URL configuration scenarios"
这个 issue：每个请求都新建一个 URL resolver，而不是复用已缓存的那个，白白浪费内存和时间。第一步点名了具体的类和被绕过的带缓存函数。第二步把它变成了在任何代码库里诊断类似问题的方法：顺着请求流程走，看看每次请求都创建了哪些对象，再检查是否有现成的缓存被绕过。
2阶段 2 · 知识引导的分析扩展
每个分析 agent 一份知识。
新 issue 到来后，灵犀先把它总结成四个字段，再检索相似历史 issue 的知识：向量检索保留前 20 个，重排模型排序后，保留最相关的 3 个。
为什么一个 agent 只给一份知识？如果把检索到的知识都塞进一个长提示里，模型往往会丢掉埋在中间的内容。所以每份知识各自引导一个分析 agent：三份知识，三个 agent，各自沿着不同的过程分析，各写一份报告。分析综合再保留其中有支撑、互补、准确、完整的部分，形成一份综合分析。相关知识不再靠模型自己想起来，而是直接摆到 agent 面前。
3阶段 3 · Issue 解决
用分析结果和 issue 修复知识来规划和修复。
分析说明了哪里出了问题；阶段 3 用两个 agent 把它变成补丁。检索到的知识中与修复相关的部分，同时引导这两个 agent。
来自阶段 2
综合分析
根因 · 范围 · 约束
哪里出了问题、在代码的什么位置、修改不能破坏什么，由多路并行分析合并而成。
来自知识库
Issue 修复知识
- 通用修复模式
- 通用修复检查清单
- 设计模式与编码实践
→ 决定计划改什么，以及改动怎样和代码库保持一致
规划 agent
探索 → 复现 → 规划
参考分析结果和 issue 修复知识，给出根因判断和精确到行的修改计划。它会探索代码、复现 issue，并把每一处计划中的修改和它要解决的问题对应起来。
修复 agent
实现 → 测试 → 完善
实施修改，运行复现测试，不断完善直到测试通过，得到最终补丁。检查清单告诉它要验证什么。两个 agent 都使用四个工具：目录查看、文件查看、关键词搜索和字符串替换编辑器。
03 · 实验评估
效果如何？哪类知识最有用？
所有实验都在 SWE-bench Verified 上进行：来自 12 个开源 Python 项目的 500 个真实 GitHub issue，每个都由隐藏测试检验。 Pass@1 是单次生成的补丁通过测试的 issue 比例。对每个目标 issue，知识只来自在它之前创建的 issue。
商用模型的实验均在 2025 年 9 月前完成RQ1 · 整体效果
在相同基础模型下，灵犀解决的 issue 最多。
怎么看每组使用同一个基础模型，所以组内唯一的区别是框架。基线是排行榜上使用同一基础模型的领先方法，不包括多模型集成。
说明了什么使用 Claude 4 Sonnet 时，灵犀达到 74.6%，比最强的对比框架 OpenHands 和 Augment v1（70.4%）高 4.2 个百分点。使用 Kimi-K2 时为 70.3 对 65.4。使用 GPT-4.1 mini 时，灵犀几乎是 mini-SWE-agent 的两倍：45.2 对 23.9。跨组来看，更强的模型让同一框架的成绩更高（红线），而灵犀在每一组都排第一。知识是在模型之上的补充，而不是替代。
RQ2 · 消融实验 · 抽样 218 个 issue · Claude 4 Sonnet
提升来自可迁移知识，并行分析在此基础上发挥作用。
无知识 · 单路分析
67.43
无知识 · + 并行分析
67.74
原始 issue–patch 对 · + 并行分析
68.30
可迁移知识 · 单路分析
72.48
灵犀 · 可迁移知识 · + 并行分析
74.80
+6.5 pp原始 issue–patch 对 → 可迁移知识68.30 → 74.80，两者都使用并行分析
+2.3 pp知识引导下的并行分析72.48 → 74.80，两者都使用可迁移知识
怎么看提升来自知识，还是来自并行的多个 agent？每一行去掉或替换灵犀的一个部分。这 218 个 issue 是统计抽样（95% 置信度，5% 误差范围）。
说明了什么没有知识时，Pass@1 为 67.4 到 67.7。使用原始 issue–patch 对，也就是只有修复、没有过程，达到 68.3。可迁移的过程性知识带来最大的一步，到 74.8。并行分析在此基础上发挥作用：有知识时，它再带来 2.3 个百分点，因为每一路都沿着自己的那份知识分析，结论再合在一起；没有知识时，对同一份 issue 报告做多路并行分析，结果和单路分析接近。两者相互配合。
这里的差值是绝对百分点；论文表 3 用相对 Δ 报告同样的结果。218 个 issue 的子集与 RQ1 中 500 个 issue 的结果范围不同。
RQ3 · 哪类知识有用，在什么时候
设计实践最重要，各类知识的作用随阶段变化。
| 知识维度 | 分析阶段 1 | 规划阶段 2 | 修复阶段 3 | 总计全部阶段 |
|---|---|---|---|---|
| 根因分析步骤 | 7 | · | · | 7 |
| 相关架构 | 7 | · | · | 7 |
| 缺陷分类 | 3 | · | · | 3 |
| 功能特性 | 3 | · | · | 3 |
| 设计模式与编码实践 | · | 11 | 4 | 15 |
| 通用修复模式 | · | 6 | 8 | 14 |
| 修复检查清单 | · | 3 | 8 | 11 |
怎么看我们选取了 20 个灵犀解决、而去掉知识的版本没解决的 issue。两位作者对比了每个 issue 的两条轨迹，标出每个阶段起决定作用的知识维度（Cohen's κ = 0.66）。格子里的数字是该维度在该阶段起决定作用的 issue 数；每个阶段一列的总和为 20。
说明了什么分析阶段，根因分析步骤和相关架构占主导；规划阶段，设计模式与编码实践接手；修复阶段，修复模式和检查清单领先。总体来看，设计模式与编码实践最重要。
设计实践长什么样 · sympy-23413
非方阵的 Hermite 标准形计算有误。
检索到的知识里有两条来自更早 sympy issue 的实践，在这个 issue 里变成了具体动作：
处理完整结构，而不是按形状猜测来自 sympy #10785
处理所有行，而不是
min(m, n) 行加上边界保护来自 sympy #17130
列用完时停下：
if k < 0: k = 0; break同一流程，去掉知识
把问题归到 return 语句上，只修了表面，最终失败
模型大体上知道这些实践。检索到的知识让它在这个 issue 上想起对的那一条。
04 · 局限与展望
agent 遵循知识时，知识的作用最大。
500 个 issue 中仍有 127 个未解决。我们抽取了其中 20 个失败案例分析原因。在 15 个案例中，相关知识其实已经给到，但 agent 把它放在一边，按自己的推理行事（论文称为 uninformed autonomy）；在另外 5 个案例中，检索到的知识太少，不足以引导修复。知识以什么方式、在什么时机到达 agent，和恢复知识本身同样重要。
上限 · 理想选择器，并非系统结果
79.2%
如果在灵犀的分析之后采样三个补丁，并由一个理想选择器在存在通过的补丁时总能选中它，500 个中会有 396 个通过。灵犀并没有这样的选择器；这个数字表示补丁选择还有提升空间。
下一步
- 把知识引导从分析阶段延伸到补丁生成。
- 在 agent 的自主性和知识引导之间取得平衡。
- 在 Python 之外验证：知识讲的是过程而不是语法，但 SWE-bench Verified 只覆盖 Python。
05 · 讨论
从论文到实践：代码从不记录的东西。
来自论文过程性知识，即 issue 怎么诊断、怎么修以及为什么，补上了当前代码无法呈现的东西。
它和你可能已经在用的工具互为补充。以 astropy issue #14182 为例：RST 表格目前只写一行表头，需求是让写出器能再加几行表头，比如单位。放到时间轴上，三类工具给出三种回答。
过去
灵犀来自历史修复的过程与理由
来自 #386 · 功能特性（原文）
- Supports reading/writing fixed-width formatted data
- Handles configurable header structures
- Supports various header configurations through
header_rows
现在
DeepWiki基于代码的文档、架构说明和问答
io.ascii · RST 页面 示意
- RST 格式位于
io/ascii/rst.py - 基于定宽表格类实现
- 每种格式有各自的表头类和数据类
计划中的改动
OpenSpec提案、需求、设计和实现任务
提案 · RST 多行表头 示意
- 为什么RST 输出需要单位
- 做什么支持
header_rows - 任务☐ 参数 ☐ 写出表头行 ☐ 测试
同一个 astropy 问题，三种回答：视角互补，而非互相替代。DeepWiki 和 OpenSpec 两栏为示意；灵犀一栏引自 astropy #386 的可迁移知识原文。
相关插件 · Lingxi Advisor
给你的 coding agent 用上过程性知识
灵犀离线构建知识，日常使用并不方便。Lingxi Advisor 是基于同一思路的独立插件，把过程性知识带进日常使用的 coding agent。支持 iCode 和 OpenCode。
Runtime使用
agent 拿不准时，检索为这个代码仓准备好的过程性知识并加以应用，同时给出来源。
Prepare挖掘
从历史 issue 及其补丁中提炼过程性知识，可以逐个处理，也可以批量处理。
说明。Lingxi Advisor 是相关插件，不是本文的复现：它和论文共享核心思路，即为 coding agent 提供过程性知识，但流程是它自己的，不是论文中评测的系统。本页所有数字都来自论文的研究实现，杰出论文奖属于论文本身。安装方式和支持的平台见插件 README。
06 · 引用
引用本文。
灵犀发表于 ISSTA 2026，并获杰出论文奖。如果用到本文，请引用：
@inproceedings{yang2026lingxi,
title = {Lingxi: Repository-Level Issue Resolution Framework
Enhanced by Procedural Knowledge Guided Scaling},
author = {Yang, Xu and Zhou, Jiayuan and Pacheco, Michael and
Zhu, Wenhan and He, Pengfei and Wang, Shaowei and
Liu, Kui and Pan, Ruiqi},
booktitle = {Proceedings of the ACM SIGSOFT International Symposium
on Software Testing and Analysis (ISSTA)},
year = {2026},
note = {Distinguished Paper Award. Preprint: arXiv:2510.11838}
}