| 赛题 | proj352-LLM-based-kdump-analysis |
|---|---|
| 队伍名称 | 黑天鹅 |
| 小组成员 | 覃煜淮，岳亮，周健毅 |
| 项目导师 | 任玉鑫，张波 |
| 校内导师 | 夏文、李诗逸 |
随着LLM相关技术的发展，LLM已在软件工程能力方面展现出优异的能力。然而，由于解决内核崩溃问题具有长上下文，上下文信息不足，领域知识繁杂，工具使用门槛高等特性，LLM在解决内核崩溃问题上仍未取得理想的效果。我们提出针对内核崩溃问题的KFC-agent（Kernel Fault Corrector-agent）,不同于尝试单轮生成正确patch的kGym等相关工作，该智能体模拟人解决问题的实际场景，基于docker容器和swerex模块，搭建了一个挂载了linux源码仓库的交互环境，实现了bash,file_io,web_search,submit,trace五个工具，建立了一个action-response的多轮交互agent工作流，借助file_io工具与环境中linux仓库交互，有效地缓解了因代码导致的长上下文问题；将难以使用的内核相关工具抽象为五种工具，解决工具使用门槛高问题；通过多轮交互的工作流，让模型从与环境交互中收集信息，缓解了上下文信息不足问题。在决赛阶段为进一步优化agent，我们基于cflow，完成内核代码调用关系的构建并实现trace工具，让agent能够逐步根据调用关系查看代码，定位根因；引入planner模块，构建历史数据库并结合RAG技术，解决模型领域知识匮乏问题，基于MemoryOS构建memory模块，通过对解决类型问题经验、调试技巧等记忆的存储，更新，检索，提高agent稳定性，赋予agent持续学习能力。在kbench这一benchmark上，KFC-agent使用deepseek-V3模型，在patch数量n=4的的情况下，执行成功率达到了60.22%,远高于同等条件下kGym的6.45%，略低于当前CrashFixer的最优效果64.78%。但在执行正确的patch中，KFC-agent的fully_solved与helpful的比例为56.66%，高于CrashFixer的48.10%。从成本上看，KFC-agent对于单条数据开销为$0.28,远低于CrashFixer的$21.62，以远远低于相关工作的实验成本达到了较高的正确率。
- 搭建了一个本地测试环境，为patch提供基于执行的正确性验证，解决了kGym测评环境只提供云端部署的问题，减少实验成本
- 在搭建了一个稳定的交互环境，可扩展性强的工具模块的基础上，构建多轮交互的智能体，模拟人解决问题过程中使用各种工具探索到最终解决问题的过程，智能体会根据指定格式调用工具探索环境，逐步收集信息解决问题
- 决赛工作：构建了理解内核代码的rag框架，能够获得特定版本的内核代码调用关系，在此基础上实现了trace工具，让agent能够通过工具理解内核代码调用关系，逐步定位问题根因
- 决赛工作：对原有crash report进行增强，构建历史数据库并使用RAG技术检索的planner模块与基于MemoryOS搭建的memory模块分别对crash report从根因分析、可能修复路径，类型经验、调试技巧等方面加强，既有利于agent解决问题的智能编排，又能让agent在解决问题中持续学习
| 姓名 | 负责模块 | 工作内容 |
|---|---|---|
|
覃煜淮
|
KFC-agent各个模块设计实现 + 测评环境搭建 + memory模块实现（决赛内容） |
1. 模拟syzkaller对kernel crash进行复现的过程以及patch应用修复bug后再测试的流程，建立了一个本地运行的验证patch正确性的全自动无交互测评环境 2. 基于SWE-agent的swerex模块和docker容器搭建挂载了linux仓库的交互环境，解决linux大仓库挂载进入docker容器的问题 3. 实现了工具管理模块，交互接口定义，从LLM输出解析工具调用功能 4. 实现了多轮交互的工作流，包含上下文管理逻辑，活跃rollout更新记录，日志输出记录等功能 5. 决赛工作:基于MemoryOS，基于已有的知识存储、更新、检索的功能，优化其中知识提取部分，搭建了memory模块 6. 决赛工作：重构evaluation测评代码，使其规范化自动化，丰富测评内容；提高实验环境的稳定性 7. 探索verl框架，重新编写采样逻辑与奖励函数，最终因有算力的机器上磁盘空间无法满足采样需求而放弃 |
|
岳亮
|
Tools工具实现 + 理解kernel代码的RAG框架 |
1. baseline的复现，实验获得了kGym的方法在当前同等有限资源情况下解决问题的成功率 2. 完成bash,file_io,web_search,submit四个工具的具体实现，调用swerex接口实现工具与docker容器交互 3. 探索理解kernel代码的rag框架以解决定位问题，尝试提高准确率 4. 决赛工作：基于cflow工具构建代码调用关系，获得函数级的调用关系 5. 决赛工作：实现基于cflow AST得到的调用关系的trace工具，扩展了agent的工具，为agent提供崩溃堆栈重要函数的调用关系信息，提高了代码层面的信息量，最终提高修复准确率和效率 |
|
周健毅
|
KFC-agent评测逻辑 + Planner模块（决赛） + 内核崩溃RAG知识库 |
1. 数据集的构建与维护 2. 在有充足资源的机器上将实验并行化，极大减少实验时间成本与测试成本 3. 决赛工作：构建Planner模块（历史崩溃与开发者讨论数据的大规模爬取与清洗、向量数据库搭建） 4. 基于RAG的相似案例检索、根因与修复策略抽取，生成可执行调试计划 5. 决赛工作：将Planner与agent集成，为Agent修复每个Crash前提供一个合理的执行计划，提高执行准确率 |
-
内核崩溃问题解决成本高
kernel crash,即内核崩溃，此类问题定位人力占排障运维的46%，问题解决耗时长，开销大，人为解决对人力，时间成本与经济成本消耗巨大
-
内核崩溃问题解决难度大，周期长，远低于内核问题发现的速度
为了避免潜在内核崩溃问题的发生并且集思广益地解决kernel crash难题，自动化模糊测试平台syzbot应运而生,该平台通过生成大量随机或半随机程序输入测试内核代码并触发异常或崩溃，实现了持续性自动化地漏洞发现。然而，发现问题的速度远远高于解决问题的速度，导致了大量内核潜在问题的堆积，缺少相关解决方案
-
大语言模型在解决内核崩溃问题上仍面临很大的挑战
大语言模型在已在众多软件工程任务中展现出可观的能力，更是在代码修复与补全等任务上展现出了卓越的实用性。然而，内核崩溃问题面临着上下文长度远超模型上下文范围，问题涉及原因复杂，调用深度远超正常软件仓库，高度并发等一系列挑战，在当前大语言模型能力仍需要进化，实验，算力成本很高的条件下，解决内核崩溃问题需要探索更多的技术手段
- 上下文问题：从数量看，内核代码量达数千万行，远超当前模型处理上下文上限；从难度上看，内核代码缺少高层语义，代码之间联系复杂，上下文内容准确理解具有难度；更多的隐式的信息不在已知上下文中给出，需要去挖掘和扩充有用的上下文
- 领域知识繁杂：内核相关知识门槛高，内容更复杂，硬件知识以及日志等多种相关信息理解都需要一定的领域知识
- 工具：增强智能体能力的有效办法之一是使用工具，然而解决内核问题相关的工具使用门槛太高，并高度依赖经验，LLM很难按照正确的格式输出调用指令，且输出指令错误或是难达到预期的效果，从而影响工具解析调用
- 智能编排：内核问题本身具有复杂性，解决过程步骤多，上下文长，对有用信息无法准确回溯以及定位，甚至发生任务遗忘，因此让模型明确任务目的，形成任务解决方法步骤十分重要
针对2.2中所述痛点，我们在初赛阶段搭建了一个针对相关痛点的agent，该agent具有以下创新：
- 环境作为代码载体，解决原有工作因以代码为输入导致的长上下文问题
- 多轮交互探索挖掘信息，解决上下文原有信息不足以提供正确方案的问题
- 模拟开发者解决问题流程，对内核问题工具进行抽象，定义四种工具，解决了模型调用工具门槛
在决赛阶段，我们针对初赛badcase中的问题以及进一步调研的结果（motivation参考motivation模块决赛部分），从不同角度完成题目并优化agent效果，创新如下：
- trace: 基于对稳定版本内核代码的静态 cflow 分析，构建函数调用关系树数据库，实现函数调用链的精准检索。当针对crash report中特定函数进行分析时，检索该函数的所有调用者及其文件位置，并反馈给 agent，使其具备函数粒度的内核代码理解能力，提升定位与修复效率和准确率。
- planner: 基于大规模内核崩溃报告与开发者讨论，构建向量数据库实现语义检索。当收到新的 crash report 时，检索相似案例并结合 LLM 总结可能的 root cause与修复路径，生成可执行的调试计划，减少 agent 的盲目探索并提升修复准确率。
- memory模块：让agent总结学习解决特定类型问题经验、工具使用组合，调试技巧等，增强agent解决问题稳定性，达到持续学习效果
初赛：
- 第一阶段：阅读了kGym及其他kernel crash相关工作，在了解效果以及实验步骤后，我们认为kGym主要受限于将相关代码文件直接输入给模型导致的长上下文过长，此外，让模型阅读crash report和部分源码直接修改难度过大，也不符合开发者多轮探索进而解决问题习惯。因此我们需要一个环境(sandbox)，存储着代码供LLM访问并且能模拟真实环境给予我们反馈
- 第二阶段：阅读了SWE-agent及其他agent与sandbox相结合的相关工作，我们总结了SWE-agent解决的问题具有和我们要解决的问题的共性：环境部署的都是git仓库；环境都能返回执行的信息(vanilla response)。基于共性，我们阅读其源码并利用swerex模块提供的接口成功搭建了一个满足我们预期要求的环境，并通过了多轮交互的测试
- 第三阶段：我们尝试在环境中安装必要的软件包，使得能支持内核相关的工具比如gdb等等，但gdb工具对模型而言使用起来比其他普通工具更困难，且结合vmcore使用效果才更好，对于简单的crash report作用并不明显，考虑到数据集上的泛化性，我们决定将工具抽象，让工具不再仅针对vmcore，且消除工具对于模型的使用门槛，增大模型探索空间
- 第四阶段：在总结了sandbox+agent的相关文章并结合我们具体的问题，我们抽象出了四种工具：shell command让LLM能够执行非交互式命令，模拟开发者在环境中探索；web_search让LLM能够获取更多有用信息，模拟开发者查询收集必要信息；file editor让LLM能够查看更改文件，模拟开发者阅读源码并进行修改；submit模拟开发者结束修改并提交patch
决赛：
- trace：我们的大量实验数据显示，agent 在分析 crash report 时往往只依赖宏观日志信息来推测问题位置，缺乏对内核函数调用关系的精确理解，这使得规模庞大、调用复杂的内核中定位过程经常陷入大范围的盲目搜索，耗时大的同时准确率不高。为此，我们设计了 trace 模块，通过对 Linux-6.9.0 内核代码进行静态 cflow 分析，构建函数调用树数据库，实现调用关系的快速提取与检索。当 agent 需要检查调用栈中某个函数的调用关系时，trace 模块可精准匹配其所有调用者及所在文件位置，为 agent 提供函数粒度的代码理解能力，帮助 agent 跳出仅依赖日志分析的局限的同时显著减少大范围搜索的时间成本，从而有效提升问题定位与修复的效率和准确率。
- planner：在实验中我们发现，agent 往往缺乏对历史类似问题的参考，缺乏一定的领域知识，容易在没有方向的情况下盲目探索，导致定位和修复效率低下。为此，我们设计了 planner 模块，通过大规模爬取内核崩溃报告及开发者讨论，构建向量数据库用于语义检索。当接收到新的 crash report 时，planner 会检索相似案例，并结合 LLM 总结可能的 root cause与修复路径，生成可执行的调试计划。这不仅为 agent 提供了方向性指导，还减少了无效探索的开销，提高了修复的准确率和效率。
- memory模块：在对实验数据分析的过程中，我们发现 1. agent对某些类型的问题如memory leak更具有偏好性，而在部分类型上解决效果并不理想，agent泛化性有待提升 2. 模型对相同的一条数据表现出解决的不稳定性，即在多个patch中经常出现仅部分解决的情况，提高模型稳定性能够有效地降低agent尝试的成本。 针对以上问题，并考虑到开发者因为具有解决对类型问题的经验能够快速猜测根因，具有调试的技巧以及方法论能够快速定位问题，我们认为加入memory模块模拟开发者本身具备的记忆有助于提高agent的泛化性与稳定性，该memory模块需能够模拟人类记忆中的的存储，更新，检索，总结等功能
上图展现我们工作的主要模块，紫色部分展现了各个模块之间的联系，以下为各个模块简要介绍：
-
Planner（决赛工作）：Planner模块通过爬取大规模内核崩溃报告和开发者讨论内容，构建向量数据库实现语义搜索。当接收到用户的崩溃报告时，能够检索出相似的历史案例，并结合LLM智能分析技术，从历史解决方案中提取问题根因和修复策略，为agent提供解决问题的整体执行计划和技术洞察
-
Memory（决赛工作）：Memory模块主要对模型记忆与知识的存储更新与检索，在KFC-agent中模型记忆的知识为解决问题的方法技巧与针对问题类型的经验。memory模块在每条数据执行前会进行记忆检索，每条数据执行完之后会进行总结并更新记忆
-
agent：以crash report中的原有内容与从planner模块与memory模块检索获得的增强信息作为初始信息，按照工具调用格式调用工具，不断探索与解决问题相关的更多信息，解决问题信息充足后，逐步解决问题，最终提交并获得patch
-
Tools(决赛优化)：模拟人解决问题的方式：通过命令行进行问题的探索，通过web_search的方式获取更多的知识以及有用的相关信息，通过对文件的查看与修改来解决问题，最后解决问题提交patch，决赛阶段，我们增加了理解kernel代码调用关系的trace工具，能够通过调用关系逐步定位问题，让agent具有开发者逐步排查代码定位根因的能力，此外工具模块具备良好的扩展性,开发者可参考工具扩展方法添加任意工具
-
Environment：基于SWE-agent中的模块，提供一个解决问题的环境，供智能体交互，智能体能够通过环境逐步查看源码，解决长上下文的问题；通过环境执行非交互式命令行命令，实现对问题的探索以及信息的获取
上图展现了从输入crash report到最终测评完成的完整流程：
-
enhancement：为了模拟人类解决问题的认知过程，即依赖自身经验、探索根因并规划路径，我们引入planner和memory两个核心模块。planner模块：该模块利用检索增强生成（RAG）技术，结合历史问题数据，从预构建的历史数据库中检索相关的讨论内容。在此基础上，它调用大型语言模型（LLM）API，分析并总结问题的根本原因（root cause）和潜在的修复路径。memory模块：该模块从模型生成的经验记忆库中检索信息，以获取与问题类型相关的解决经验、常用的调试技巧以及工具链的使用流程。随后，我们将规划器和记忆模块检索到的内容，用于增强（augment）原始的崩溃报告（crash report）。这份增强后的报告作为输入，传递给智能体（agent）进行多轮交互式问题解决。这一流程旨在模仿并复现人类开发者解决问题的认知路径，提升问题解决的效率和稳定性。
-
多轮交互解决问题：经过enhancement内memory模块和planner模块增强的enhanced crash report作为输入，通过LLM的rollout获得每一轮采取的action，从中解析调用的工具，执行获得反馈，将采取的action与反馈response进行记录并加入上下文，供模型根据反馈进一步决策，模拟人类解决问题流程，解决一次性生成patch思考不充分，信息获取不够细化的问题
-
测评环境：基于syzkaller仓库reproducer相关内容，搭建测评环境，基于执行检测测评结果。从submit后得到的最终执行轨迹从最后一步提取出patch，基于特定版本的内核应用patch后并编译，运行在syzkaller提供的reproducer复现镜像上，得到执行结果，观察执行结果是否还有crash report或是其他错误信息，无则判修改成功
优势：以docker容器作为环境并挂载linux代码，避免直接以完整代码文件作为输入，解决长上下文问题；并为模型多轮探索解决问题提供环境基础
该模块实现包含以下部分（详细介绍见文档）：
- Docker镜像+python包
- 挂载linux仓库的docker容器
- session
- swerex
- tools & response
优势：模拟开发者解决问题的流程，实现了四种解决问题过程中常见的工具，将特定针对内核领域的工具抽象为解决问题的工具，降低模型使用工具的门槛，避免了内核崩溃定位领域知识要求高，工具复杂的问题
该模块实现包含以下部分（详细介绍见文档）：
- Tools manager
- thought-action parser
- Tool instance
- 完整流程的数据流动
优势：模拟开发者解决问题流程，多轮使用工具与环境交互，不断探索获取更多信息以定位解决问题，解决kGym中单轮便给出patch，上下文信息有限的问题
该模块实现包含以下部分（详细介绍请见文档）：
- LLM generate
- invoke tools
- response
- append
优势：本地部署测评环境，解决kGym对云服务的依赖；基于执行的测评，可靠验证patch正确性
该模块实现包含以下部分（详细介绍请见文档）：
- Get patch
- Get brand kernel
- Reproducer config
- 执行复现流程并判断patch是否正确
（决赛实现）
trace模块通过对linux-6.9.0版本内核代码进行静态cflow分析，构建函数调用树数据库实现调用关系提取与检索。当agent希望检查crash report调用栈中某函数的详细调用关系时，可以使用封装为tool的trace工具，精准定位检索位置，并利用正则表达式匹配从对应数据文件检索该函数的所有调用者，将函数名以及具体的所在文件、行号反馈给agent，赋予其函数粒度理解内核代码、精确定位修改位置的能力。
优势：帮助agent明确复杂的内核函数调用关系，跳出宏观日志分析局限的同时省去了盲目搜索的时间，获得深入的代码理解，从而有效提升问题修复效率和准确率
该模块包含以下部分（详细介绍请见文档）：
- cflow内核代码调用关系静态分析系统
- 文本格式函数调用关系树数据库
- 调用者文件定位与精准检索算法
（决赛实现）
Planner模块通过大规模爬取内核崩溃报告和开发者讨论内容，构建向量数据库实现语义搜索。当接收到用户的崩溃报告时，能够检索出相似的历史案例，并结合LLM智能分析技术，从历史解决方案中提取问题根因和修复策略，为agent提供解决问题的整体执行计划和技术洞察，模拟人类开发者先查找参考案例再制定解决方案的工作流程。
优势：解决agent缺乏历史经验和技术洞察的问题，通过大规模历史数据和智能分析为agent提供专业的问题诊断和解决方案指导，显著提升问题解决的准确性和效率；避免agent盲目探索，提供有针对性的修复策略
该模块包含以下部分（详细介绍请见文档）：
- 大规模崩溃报告和讨论内容爬取系统
- LLM智能分析引擎（提取根因和解决方案）
- 向量数据库构建与语义搜索
- 相似案例检索与匹配算法
- 智能方案生成与执行计划制定
（决赛实现）
优势：让模型在解决问题的流程中像开发者一样进行复盘总结，学习到使用工具解决特定问题的能力以及解决类型问题的经验；通过Memory地不断更新实现持续学习；增强模型解决问题的稳定性，提高模型解决问题泛化能力
该模块包含以下部分（详细介绍请见文档）：
- memory enhancement
- generate trajactory and patch(with enhanced content)
- summarize skills and experience
- memorize and learn
项目实现目标如下：
| 实现内容 | 完成情况 | 说明 |
|---|---|---|
| 基础内容1：借助LLM等手段自动化常规kdump分析流程 | 全部完成 | 1.基于SWE-agent中的SWE-ReX搭建一个环境，供智能体访问代码与探索 2. 构建了四个工具供模型使用，模拟开发者解决问题流程 3.设计一个与环境多轮交互的agent，模仿开发者逐步收集信息解决问题 4.参考kGym与syzkaller，完成了测评环境的搭建，跑通测试流程 |
| 基础内容2：构建理解kernel代码的rag框架 | 全部完成（决赛阶段完成） | 1.基于cflow内核代码静态分析工具构建Linux内核代码调用关系数据库 2.设计函数调用关系匹配查询算法，精确crash report堆栈函数的调用者及文件位置 3.将rag定位封装为供agent自由使用的tool |
| 进阶内容1：结合历史问题数据（来源自syzbot,bugzilla等……）进行问题分析 | 全部完成（决赛阶段完成） | 1. 设计并实现了大规模历史内核崩溃报告与开发者讨论数据的爬取与清洗流程，涵盖syzbot,bugzilla等多个数据源 2. 基于清洗后的数据构建向量数据库，实现语义检索能力；在Agent接收新的crash report时，能够从向量数据库中检索出语义最相关的历史案例 3. 利用LLM对检索结果进行分析与总结，抽取历史案例的根因（root cause）与修复策略（fix strategy），将根因与修复策略转化为结构化的调试计划（debug plan），并在agent执行前注入，减少盲目探索，提高定位与修复的准确率和效率 |
| 扩展实现：为智能体增加记忆模块，达到持续学习目的 | 全部完成（决赛阶段完成） | 1. 调研并阅读MemoryOS源码，修改MemoryOS部分检索逻辑，借助MemoryOS提供的接口解决agent memory中存储，更新，检索的难题 2. 对agent memory记忆的数据进行了设计，让memory忽略冗余的上下文，而是总结凝练出解决类型问题的经验，调试技巧，工具常见使用组合等更有用与泛化的信息，解决了agent memory中提取（对记忆知识提取精炼）的难题 |
初赛实现内容：重要进展＋时间节点如下：
| 实现内容 | 时间 | 说明 |
|---|---|---|
| 行动项1 | 3.13-4.02 | 1.阅读syzkaller文档，将crash report的复现跑通并将该流程自动化，从kGym仓库找到数据集相关信息，复现得到数据集 2.调研sandbox环境的相关内容 |
| 行动项2 | 4.02-4.09 | 1. 参考kGym流程，结合前期造crash report探索，参照kGym搭建起一个测评环境 2.确立以swe为基准，并尝试跑通SWE-agent项目 |
| 行动项3 | 4.10-4.23 | 1.跑通SWE-agent，阅读源码发现SWE-ReX为其中完成与环境交互的关键模块 2.搭建起一个提供交互的环境，能够以linux作为环境中的代码仓库，并通过多轮交互测试 |
| 行动项4 | 4.24-4.30 | 1.调研总结"环境+agent"相关文章工具调用模块，确立为agent提供四个工具 2. 实现四个工具，规范工具调用统一格式，实现工具与环境交互统一接口，通过工具与环境多轮交互测试 3.在调研过程中发现强化学习可以训练模型让模型尝试学习到解决问题的轨迹，但由于算力原因，无法做到训练 |
| 行动项5 | 5.1-5.7 | 1. 完成了agent在多轮交互中的上下文管理 |
| 行动项6 | 5.8-5.21 | 1.搭建完成完整的workflow，成功在数据集上跑通完整流程 2.重构代码 |
| 行动项7 | 5.21-至今 | 1. 实验中发现编译与定位文件的问题，进行六组实验探索，对比kGym确立评测指标 2. 探索问题并决定后续优化方向，继续完成相关工作 |
决赛前瞻（除强化学习因算力有限原因未能实现，加了一个持续学习的memory模块）：
- 完成理解kernel代码的rag框架(已完成)
- 收集历史数据，尝试结合历史数据理解问题，为agent增加智能编排模块，先猜想（Hypothesis）后执行（已完成）
- 算力允许的情况下探索强化学习对模型解决问题和调用工具能力的提升（因算力与磁盘空间问题无法完成，但已成功完成采样逻辑的适配以及奖励函数的编写，增加了memory模块）
决赛实现内容：重要进展＋时间节点如下：
| 实现内容 | 时间 | 说明 |
|---|---|---|
| 行动项1 | 初赛末期至7.9 | 在多个模型之间对比kGym与我们KFC-agent-pre版本的对比，消除模型的影响；发现之前与虚拟机通信的网卡消失导致测评出现问题，优化环境与测评代码，确保环境与测评部分与初赛的一致性的同时提高稳定性；初步探索graph与cflow的使用，调研函数调用关系分析方法;开始调研如何利用历史内核崩溃与讨论数据提升修复效率，确定从 bugzilla、mailing list 等平台大规模爬取 crash report 与开发者讨论内容作为基础数据 |
| 行动项2 | 7.9-7.16 | 重新拉取verl框架，对verl框架再阅读，编写奖励函数，修改采样逻辑，寻找算力解决方案；对统计逻辑进行重构，优化代码，便利实验结果统计；确定使用cflow静态分析工具对内核代码进行AST分析，分别尝试对整个内核以及一级子文件夹下.c/.h文件进行关系数据库构建，但由于机器资源限制，最终决定以二级子文件夹为最小分析单位构建关系数据库 ;完成历史数据爬取脚本与清洗规则设计，初步建立 crash report–discussion 对应样本，探索向量数据库方案 |
| 行动项3 | 7.16-7.23 | 寻找算力解决方案未果，了解到MemoryOS工作，突发奇想引入持续学习模块并成功接入agent框架，完成记忆与检索逻辑的实现；在函数关系数据基础上设计并优化探索定位检索算法；完成数据清洗与格式化，将 crash report 作为 key、discussion 作为 value 存入向量数据库，初步实现相似度检索，并在小规模数据上测试 LLM 对检索结果提取 root cause 与修复策略的可行性 |
| 行动项4 | 7.23-7.30 | 将多个机器上分方向优化的代码整合重构，挂起KFC-agent-final最终实验；对不同机器上挂不同的优化实验进行badcase分析总结，发现问题并优化代码 |
| 行动项5 | 7.30-8.6 | 统计已有实验结果；再看强化学习代码，修改奖励函数，测试已跑通但算力被占用再次搁置；着手完善仓库、文档、图表的建设; |
| 行动项6 | 8.7-8.12 | 强化学习尝试彻底失败，算力足够的机器上无法腾出足够磁盘空间，grpo算法的多次采样对磁盘空间要求较大，采样次数不足训练得到的模型能力也会较差 |
在完成上述各模块的配置后，即可开始实验的配置
- 先clone linux仓库至Repositories/Raw下
git clone https://github.com/torvalds/linux ./Repositories/Raw对于run_server
- 先安装必要依赖
# verl，因为run_server中借用的也是verl的数据格式
pip install -e verl/.
#作为run_server vllm可以暂时没必要安装，但是得注释不少代码才能运行，因此建议一次安装完成
pip install asyncio jsonlines vllm==0.7.0
#安装其他依赖，因为使用过swe-bench测试（时间成本远低于kbench且流程一致），而后思考到可能的rl训练测试，因此暂未修改代码
pip install swebench aiofiles- 在示例配置文件中修改API_KEY与base_url，并可以使用你希望使用的模型
api_key: ""
base_url: ""
api_model: ""- 启动
scripts/inference/run_server.sh对于run_local
该模块主要是为了本地推理验证与强化学习训练使用，但就当前情况来看这个方案不一定能够做出效果(2025.8.7更新：该方案已经弃用，算力和磁盘空间无法同时满足)
- 先安装依赖
pip install -e verl/.
#注：flash-attention不支持V100
pip3 install flash-attn --no-build-isolation
pip install asyncio jsonlines vllm==0.7.0
pip install swebench aiofiles
- 启动
scripts/inference/run_local.sh对于evaluation
在得到运行结果之后可以参考evaluation模块完成实验结果的快速统计
由于已在多台机器上配置过环境，就遇到的特例问题进行汇总
Q：flash-attention安装失败或是无法编译
A：无法编译属于系统版本问题（GLIBC版本过低也会导致），安装失败可采用run_server的方式，但是要注释掉所有flash-attention有关代码（根据报错的trace容易找到相关引用大概跨两到三个文件左右）
Q：要是启动后一直卡在start处很久都没有进入deployment和env init操作提示怎么处理
A：这大概率是因为设置了环境代理的原因，容器与宿主机之间的通信使用的为request库，并且访问容器使用localhost的地址，目前我们已支持不使用代理即可完成整个配置的流程，故可以执行
unset http_proxy
unset https_proxy若是还有使用代理的需求，可以执行
export NO_PROXY="127.0.0.1,localhost"Q：要是运行进程卡在了step 5/5 uploading...处或是进程被kill了怎么解决
A：这大概率是因为OOM(out of memory)问题，建议再次运行并使用
htop #或者top 后 ctrl+m ,此外free -h 可以查看内存大小，我们主要实验环境内存大小为16G，设置n=2指令监管程序运行时内存占用
如果确定了是OOM问题，请在配置文件中调小n的值(并行挂载数量)
Q：操作系统语言环境设置为中文运行出错
A：这是因为在启动虚拟机的时候默认使用的pexpect是英文的操作，严格按照等待sudo密码的终端输出进行匹配，解决办法不少，但在拥有sudo并且能够保证不影响他人使用的情况下，建议先注释掉虚拟机启动代码中的等待sudo密码输入的部分，再对用户执行免密操作
sudo visudo
#在文件中添加
your_username ALL=(ALL) NOPASSWD: ALL #如果怕影响可以把最后一个ALL改为特定的指令如qemu-x86-64等Q：执行到连接虚拟机的时候遇到了显示br0不存在是什么情况
A：我们其中一台机器会出现执行几天后网桥突然消失，这时重新开启一个终端执行创建网桥命令即可
sudo ip link add name br0 type bridge
sudo ip addr add 192.168.100.1/24 brd + dev br0以kGym作为主要baseline对比指标
由于实验成本差距悬殊并考虑到CrashFixer复现难度，我们无法与CrashFixer在相同实验条件下进行进一步对比，但会从总体正确率，fully_solved的比率，以及实验成本的消耗几个论文中提到的指标进行比较
在实验调研相关工作SWE-agent和kGym以及实验过程中我们发现代码修复相关工作都存在patch编译失败的问题，在底层语言更甚；此外，在kGym和CrashFixer中都有实践或是讨论到定位相关问题，结合我们实验数据的分析以及实际实验遇到的情况，我们确立了三个指标：执行正确率(execution accuracy),编译正确率(compilation accuracy),定位正确率（location accuracy）
由图，根据统计信息，在kbench的279条数据中，数据的平均更改文件为1.28个，说明不少patch的修改仍然是跨文件的，跨文件数最多达到了7个，说明数据集对LLM能力仍有较大考验。修改的行数平均为14.27行，最多为147行，对LLM的代码理解能力亦有要求
由图，在对数据集进行分析的过程中，我们惊讶地发现，不同于SWE-agent的patch修改与issue中提到的位置高度重合或相关,kernel crash这一问题patch修改的文件往往不在trace stack即crash report中的调用栈内。上个图中修改文件内容不全在调用栈中的数据达到了196条，约70%的数据量，可见对于代码调用关系的理解，构建理解kernel代码的rag框架对于正确生成patch具有重要的意义。而加了定位对执行效果有显著提升也从侧面印证了这一点
上图为多个模型在kGym与KFC-agent在patch数n=1的情况下执行正确率的结果（n=1执行有一定的随机性，不代表各个模型解决问题的优劣），在实验中我们发现，kGym实际执行中由于上下文过长，兼具代码和文本，模型指令遵循能力较差，导致回答中掺杂着不少思考内容，影响编译，导致正确率低下，此外尽管传入正确的定位，由于上下文信息较大，在修改跨文件或是存在未出现在stack trace的文件这两种情况时，模型的patch明显存在思考不足的情况
此外，在对不同模型分析的过程中，我们发现gemini2.5pro在我们的任务上工具调用格式有较多错误，执行轮数会偏多，且成本较高；而r1倾向于极少步骤解决问题，可解释性较差，成本较于4o与V3较高；因此在执行完上述实验后，我们决定采用deepseek-V3作为我们后续所有优化实验的模型
上图为kGym以及KFC-agent各个优化版本，调用deepseek-V3的API，在patch数n=4的情况下的性能，从三个指标:执行正确率(execution accuracy),编译正确率(compilation accuracy),定位正确率(localization accuracy)分析。总体上看，KFC-agent-final在各项性能上表现均优异，在执行正确率和编译正确率上都远超KFC-agent-pre以及其他单一优化版本，成功证明了我们决赛方法优化的有效性。此外我们发现，1. KFC-agent-pre+planner以及KFC-agent-pre+trace在定位准确率上性能较高，在编译准确率上性能较低。我们分析认为这是历史数据中对于同一个类型问题或是类似的调用栈信息的discussion可能会直接指向修改的目的文件，但因discussion中无效信息较多或是存在错误分析，可能会误导agent对于根因的判断，出现“依赖外部信息”的情况，尽管定位正确但是未能正确的修改patch导致编译失败。而trace工具可以实现“顺藤摸瓜”找到根因，但因为依据调用关系获取代码信息较多，查看文件较多而导致对简单问题复杂化或是意外地修改了部分功能导致代码编译失败。2. KFC-agent-pre+memory在编译正确率上性能较高，在定位正确率上性能较低。我们分析认为这是因为记忆的内容多为失败的案例，而失败的案例中与总结相关参考patch的差异以及对比后总结的经验教训，导致agent更多地倾向于学习到如何编写开发者编写规范的patch以及如何使得patch编译正确，而从成功案例中学习的调试技巧较少，导致对问题的逐步分析与定位能力较差，而生成的patch编译成功率较高，出现“过于依赖内部信息”的情况。在KFC-agent-final中，planner,trace,memory实现了优势互补，即将内外部信息结合，兼顾了编译正确率和定位正确率的同时获得了高执行正确率。
上图为KFC-agent-final在CrashFixer提及的几个指标上的对比。在执行准确率上，KFC-agent-final执行准确率最高为60.22%，CrashFixer最高为64.87%，但在所有执行正确的patch中，KFC-agent-final的fully_solved与helpful共占比56.66%，高于CrashFixer的48.10%,说明在执行正确的patch中，KFC-agent-final能提供的解决思路的正确性更高。此外，对于一条数据，KFC-agent-final成本为$0.28,而CrashFixer成本为$21.26，我们成本约为CrashFixer的1/76
上图为KFC-agent-pre，KFC-agent各个优化实验，KFC-agent-final以及CrashFixer在所有执行正确的patch中，fully_solved,helpful,new_errors的占比。除CrashFixer外，各实验均取n=4的内容进行统计。由图可知，尽管KFC-agent中各个版本执行正确率均低于CrashFixer，但是各版本中fully_solved+helpful的占比均高于CrashFixer，说明KFC-agent各个版本提供的patch对问题的解决与指导性更强；且对比CrashFixer，KFC-agent-final在执行正确率为60.22%,fully_solved+helpful占比为56.66%的情况下，fully_solved+helpful的patch数占总数据的34.12%，高于CrashFixer的31.16%
下面三张图分别为KFC-agent-pre,KFC-agent各个优化版本,KFC-agent-final三个指标执行正确率，编译正确率，定位正确率随着pass@k变化而变化的图，主要体现pass@k对于执行正确率，编译正确率，定位正确率的影响以及探究agent上限。特别的，我们对KFC-agent版本进行了n=5的测试，执行正确率不再上升，编译正确率与定位正确率有略微提升，其余优化方案未做n=5的探索，未进一步探究方案上限
上图为探究交互轮数对结果的影响，对应实验为KFC-agent-pre且n=1的情况，我们进行了最大轮数为30轮的测试，以每5轮为间隔，统计不同交互轮数对执行正确率，编译正确率，定位正确率的影响。结合结果我们可以观察到，增大交互轮数能够有效提升各项指标，在5-10，10-15这两个区间上升较为明显，与不少论文中选择RL训练时最大交互轮次为15的情况不谋而合。此外，我们也在后续实验观察到，增加了专门针对内核代码的trace工具后，交互轮次明显上升，因此上图仅反应在初赛阶段工具没有改变时的结果，用于证明交互轮次的上升时对效果有有效提升
上图为探究trace模块对提高agent定位准确率的影响，对应实验为KFC-agent-pre与KFC-agent-trace在n<=4的各轮次下效果对比。图中，阴影柱代表未采用trace的pre定位准确率，实心柱代表结合trace的实验结果，另外绿色折线代表agent处理279条崩溃数据时正确使用trace工具得到调用关系信息的百分比。总体而言，引入trace工具接口显著提升了定位能力，且随着轮次增加，定位准确率和调用关系检索成功率均以逐渐放缓的速度提升，这符合实验预期。综上所述，trace方法有效提高了agent定位具体问题的精度和效率，证明其对KFC-agent框架更深入理解代码逻辑具有积极作用。
上图展示了在 Category 1/2/3中，采用 Planner与未采用 Planner在不同尝试次数 n=1..4 下的平均交互轮次对比。可以看到，在所有类别中，Planner 都能显著减少完成任务所需的交互轮次，尤其在中等和困难任务中效果更为明显。这说明 Planner 能有效引导 agent 更快接近目标位置，减少无效探索，从而提升任务效率。
上图展示了在 Category 1/2/3 三个类别下，使用 Planner与不使用 Planner在不同尝试次数 n=1..4 时的定位准确率对比。可以看到，在所有类别和所有 n 的情况下，使用 Planner 的定位成功率均显著高于未使用 Planner 的版本。其原因在于，Planner 模块能够利用历史讨论数据，为 Agent 提供针对 crash 问题的合理解决方向与思路。这种基于历史经验的指导不仅减少了无效尝试，还提升了问题定位的效率和准确性，因此在简单任务中能够稳步提升准确率，而在较复杂的任务（Category 2 和 Category 3）中，这种优势更为明显，从而显著提高整体定位表现。
上图为探究memory模块对agent效果的影响，对应实验为KFC-agent+memory与KFC-agent-pre在n=1情况下的效果对比。上图我们统计每20条数据中正确的数量，可以发现1. 在较前面解决问题的过程中KFC-agent+memory解决crash数量低于KFC-agent-pre，这是由于记忆模块总结的经验方法较少并且受到不相关的方法影响导致的效果较差；而在数据集后续问题的解决过程中，KFC-agent+memory解决crash数量高于KFC-agent-pre，这是由于模型在解决问题过程中获得了部分有用的调试技巧以及类型经验，对问题的理解正确性和稳定性都提升 2.在整体上看，KFC-agent+memory与KFC-agent-pre对比，解决问题数量平均值更高，证明了其能帮助模型学习到调试技巧与类型经验，提高模型解决问题能力；方差更低，证明成功优化agent解决问题的偏好性，解决问题稳定性得到提升
KFC-agent成功解决linux内核错误问题实例：
详细的成功案例执行记录请参考 Success_case/ 文件夹：
-
Case 1：完整的执行轨迹记录，包含15号问题解决过程
rollout_step_15.json：完整的执行记录（6940行）rollout_step_15_round_*.json：各轮次的详细交互记录
-
Case 2：另一个成功案例的执行轨迹记录，包含18号问题解决过程
rollout_step_18.json：完整的执行记录（8679行）rollout_step_18_round_*.json：各轮次的详细交互记录
-
Open crash Case：这是一个在syzbot 中未被解决的开放问题。尽管该问题已被syzbot自动检测并报告，但内核社区尚未提供有效的修复方案。
rollout_step_279.json：完整的执行记录（2462行）rollout_step_279_round_*.json：各轮次的详细交互记录- 详细分析文档：这里详细分析了KFC-agent解决syzbot开放问题的思路和效果
这些案例展示了KFC-agent如何通过多轮交互、工具调用和环境探索来成功解决内核崩溃问题。
此处有初赛简单演示视频，但因大小问题可能要加载一段时间，请稍等，感谢理解，决赛视频因为太大无法上传至readme演示，放置在下列的网盘链接
初赛视频百度网盘链接,提取码0352
决赛视频百度网盘链接，提取码0352
决赛PPT（因有视频pptx文件较大，网盘不支持预览pptx文件，预览可看上条pdf版本），提取码0352
./
├── checkapi.py #检测API使用功能
├── configs #各种配置文件目录
│ ├── api_config.yaml #决定agent调用模型的名称与API_KEY
│ ├── environment_config.yaml #环境模块的配置
│ ├── generation_config_server.yaml #调用API的生成配置
│ ├── memory_config.yaml #记忆模块配置，包含记忆容量，记忆文件存储路径等等
├── Environment
│ ├── data_utils.py
│ ├── environment.py #环境模块主要逻辑
│ ├── generation.py #run_llm_loop主要逻辑，包含上下文管理，多轮交互的主要实现工作流
│ ├── kbench_rewards.py # 测评环境入口
│ ├── readme.md #环境模块配置逻辑
│ ├── repo.py #仓库挂载逻辑
│ └── verification.py
├── evaluation #对已有实验结果进行统计,可参考readme使用
│ ├── scripts # 主要实现的脚本，参考改模块readme使用
├── function_call_relationship #调用关系实现
│ ├── analyze_call.py #查询调用关系实现函数
│ ├── output #构造好的调用关系
│ └── readme.md
├── kbench-verified #测评环境主要逻辑
│ ├── download_assets.py #将reproducer与config下载至本地的脚本，提高agent的稳定性，不再依赖于设置特定代理
│ ├── eval.sh #主要的测评函数脚本
│ ├── extract_code.py
│ ├── get_crash.py #虚拟机远程执行实现逻辑
│ ├── linux-test
│ ├── local_assets #下载至本地的reproducer与config
│ ├── local_network.sh #与虚拟机的网络配置模块
│ ├── readme.md
│ ├── stretch-amd64.img #特制作镜像
├── KFC-agent-pdf版本决赛PPT.pdf
├── KFC-agent-决赛文档V3.pdf
├── KFC-agent-哈尔滨工业大学（深圳）-v3.pptx
├── KFC-Agent文档v7.pdf
├── LICENCE
├── memory_manager.py #记忆管理类
├── MemoryOS #MemoryOS项目代码
│ ├── memoryos-pypi #从此处增加了短期记忆检索逻辑
│ ├── readme.md #memory模块配置方法
├── pics #包含各种数据分析图以及架构图以及流程图
├── Planner #Planner模块主要实现，构建数据库以及检索代码
│ ├── code
├── README.md
├── Repositories #挂载的linux所在目录
│ ├── playground
│ └── Raw
├── run_local.py
├── run_server.py #调用API执行逻辑
├── Scarffolds #工具模块
│ ├── base.py
│ ├── configs #各个工具的使用说明
│ ├── constants.py
│ ├── manager.py #工具管理类实现
│ ├── parsing.py #工具解析类实现
│ ├── readme.md
│ └── tools #各个工具的具体实现
├── scripts #运行脚本
│ ├── inference
├── Success_case #执行成功案例汇总
│ ├── case1
│ ├── case2
│ └── open_crash_case #在syzbot平台执行成功仍旧open的问题
├── SWE-ReX #在Environment内远程执行代码依赖的目录
├── verl #本为服务强化学习而用；因资源原因搁置后采取里面的数据形式
└── 初赛视频v2.gif
-
关于环境交互、多轮交互智能体的context engineering部分，参考swerex与swe-aegnt (MIT License)，链接分别为
SWE-ReX：https://github.com/SWE-agent/SWE-ReX
SWE-agent: https://github.com/SWE-agent/SWE-agent
-
关于内核代码调用关系构建部分，参考GNU cflow (GNU General Public License)的实现,链接为
-
关于memory模块实现部分，参考MemoryOS (Apache License 2.0),链接为
MemoryOS: https://github.com/BAI-LAB/MemoryOS
-
强化学习由于算力与磁盘空间不足以支撑多次采样原因搁置，但借用了其中的数据格式进行交互管理，具体实现参考verl (Apache License 2.0)，链接为：
本作品采用 Creative Commons Attribution-ShareAlike 4.0 International (CC-BY-SA 4.0) 许可。
