Kodezi Chronos：编程界第一款「调试优先」大模型，80.33% SWE-bench Lite 准确率背后的工程秘密

图1：Kodezi Chronos 官方项目封面

一句话总结

Kodezi Chronos 是一款专门为代码调试而训练的大语言模型，在 SWE-bench Lite 基准上以 80.33% 的准确率刷新了业界纪录，比 GPT-4.1 等通用模型高出近 6 倍，其背后依赖的核心技术是自适应图引导检索（AGR）与持久化调试记忆（PDM）。

背景：通用大模型「写代码」很强，但「修 Bug」很弱

你可能用过 ChatGPT 或 Claude 帮你写代码——它们确实很擅长从零生成函数、接口或完整模块。但当你的代码已经跑起来了，却因为一个难以定位的 Bug 导致崩溃时，通用大模型的表现就会急剧下降。这不是模型能力的问题，而是任务本质不同。

代码生成只需要理解「要做什么」，而代码调试需要理解「为什么会出错」——这要求模型能够跨越整个代码仓库，追踪变量在多个文件之间的传递路径，理解并发状态、依赖版本差异，甚至团队内部的命名规范和历史代码债务。

SWE-bench Lite 基准测试揭示了这个鸿沟：Claude 4.5 Sonnet 在代码生成任务上达到 72.7%，但在调试任务（需修改已有代码）上跌至 14% 左右，差距接近 60 个百分点。正是在这个断裂地带，Kodezi Chronos 应运而生。

Chronos 的核心设计哲学：从「补全」到「修复」的范式转移

与主流大模型追求更长上下文窗口（128K、200K token）不同，Chronos 选择了一条更务实的路线：用更少输入、生成更精准输出。

具体而言，Chronos 的输入 token 通常不超过 10K，但输出可达 2-4K，专注于给出结构化的修复方案，而非泛泛地描述问题所在。这种「输出密集型」的设计理念是 Chronos 在调试任务上显著优于通用模型的关键原因之一。

模型在 1500 万条真实调试会话上进行了专项训练，涵盖了从 bug 报告、错误定位、多轮尝试、失败回退到最终成功的完整轨迹。这种「完整轨迹」训练方式让模型学会的不只是「bug 长什么样」，更学会了「debugger 是怎么思考的」。

核心技术一：自适应图引导检索（AGR）

代码调试的难点之一在于：错误的根因往往不在报错位置本身，而在千里之外的依赖链上。一个 NullPointerException 的根源可能是某个配置文件缺少了默认值；一个内存泄漏可能来自对象生命周期管理不当的隐藏角落。

传统检索方式（BM25、密集向量相似度搜索）只能找到字面相似的内容，无法理解代码之间的依赖关系和调用链路。AGR 的核心创新在于：在运行时动态构建代码依赖图，然后执行 K-hop 自适应遍历，找到与错误症状真正相关的代码片段。

架构文档显示，AGR 在 5000 场景的 MRR 基准测试中实现了 92% 的精确率和 85% 的召回率，每次检索的平均迭代次数仅 7.8 次，算法复杂度为 O(k log d)，兼顾了精度和效率。

核心技术二：持久化调试记忆（PDM）

PDM 是 Chronos 的第二块基石。它不是一个简单的向量数据库，而是一个融合了时序代码快照、错误特征库、历史修复库、团队习惯图谱的多层记忆系统。

当模型修复了一个 bug，修复方案会写入 PDM，供后续相似错误参考。更重要的是，PDM 会追踪代码库的历史变更——哪个 commit 引入了这个 bug、哪个 PR 曾经修复过类似问题、不同版本之间的 API 行为差异，这些信息都在 PDM 中被持久化下来。

这意味着 Chronos 不是每次调试都从零开始，而是在一个积累了团队智慧和历史教训的「调试知识库」上工作。

七层架构：从输入到可解释的完整闭环

Chronos 的架构分为七层，从底层到顶层依次是：

第一层：多源输入层——接收 bug 报告、错误堆栈、相关代码文件等异构信号。第二层：自适应检索引擎——AGR 实现，支持动态图构建和 K-hop 遍历。第三层：调试专用 LLM 核心——在 1500 万调试会话上专项训练的 Transformer 架构。第四层：编排控制器——管理整个调试循环，决定何时检索、何时生成修复方案、何时进入下一轮迭代。第五层：持久化调试记忆——PDM 知识库，跨会话积累调试经验。第六层：执行沙箱——在隔离容器中运行修复后的代码，通过单元测试、集成测试、类型检查等多重验证手段确认修复有效，同时自动检测是否引入新问题。第七层：可解释性层——向开发者输出人类可读的修复理由和决策依据。

性能数据：不是数字游戏，而是真实场景的碾压

Chronos 在三个关键基准上的表现：

SWE-bench Lite（行业标准代码修复基准）：80.33%（241/300），比第二名（ExpeRepair + Claude 4.5 Sonnet，60.33%）高出 20 个百分点，比 GPT-4.1（13.8%）高出 4 倍以上。分仓库来看，在 sympy（符号数学库）上达到 96.1%、sphinx（文档工具）上 93.8%、django（Web 框架）上 90.4%，覆盖了从底层库到上层应用的完整谱系。

MRR 多随机检索基准（5000 场景）：67.3% 成功率，每次修复平均成本 1.36 美元，而同类方案（如 Auto-GPT + Claude）的成本超过 5.53 美元。人类评审的偏好率达到 89%。

调试周期缩短：与传统基于序列的方法相比，Chronos 将平均调试周期缩短了 40%。

部署与使用：开源评估框架，但模型本身是专有的

这是理解 Chronos 的重要前提：模型权重和训练代码不开源。这个 GitHub 仓库实际上是研究论文 + 评估框架，不是可以直接运行模型的代码库。

仓库中包含的内容：完整的评估基准（benchmark）、架构设计文档（architecture/ 目录）、Jupyter Notebook 分析工具（notebooks/）、可视化脚本（visualizations/）、部署配置（deployment/Dockerfile、benchmarks/docker-compose.yml）。项目本身通过 setup.sh 提供了一键环境配置。

对于想使用 Chronos 的开发者，官方路径是加入 waitlist（chronos.so），预计 2025 年 Q4 开放企业 beta，2026 年 Q1 通过 Kodezi OS 平台公开可用。

局限与争议

需要诚实指出几个问题。首先，模型专有性是最大的争议点——虽然顶着开源仓库的形式，但真正的模型权重和技术细节并不开放，这与主流开源 AI 项目（如 Meta 的 LLaMA、Mistral 系列）的开放策略形成鲜明对比，也引发了一些社区质疑。其次，80.33% 的 SWE-bench Lite 准确率虽然惊艳，但 SWE-bench 本身是一个相对封闭的测试集，在真实生产环境中的泛化能力还需要更多验证。再者，Chronos 的成功高度依赖 PDM 和 AGR 等工程组件，这些组件需要针对每个代码库进行初始化和适配，冷启动成本不可忽视。

行业意义：从「辅助写代码」到「自主修 Bug」的跨越

Chronos 的出现代表了一个值得关注的趋势：AI 编程工具正在从「代码补全助手」进化为「自主调试代理」。这不仅意味着开发者可以把更多时间从重复性调试中解放出来，更重要的是，它验证了一个假设——专项训练的模型在特定任务上可以大幅超越通用模型，即使后者参数规模更大。

从技术路线来看，Chronos 的 AGR + PDM 架构也为行业提供了一种新的参考：用图结构建模代码依赖关系，用持久化记忆积累调试经验，而非单纯依赖更长的上下文窗口。这与当前业界追求百万 token 上下文的路线形成了有趣的对比。

图2：Chronos 七层架构总览，从多源输入到可解释性输出的完整闭环

---

数据来源：Kodezi/Chronos GitHub 仓库（https://github.com/Kodezi/Chronos），截至 2026 年 7 月更新。SOTA 数据基于 SWE-bench Lite 基准测试（https://arxiv.org/abs/2507.12482）。