1. 从 71% 这个数字说起代码智能体到底在修什么第一次看到 TianxiCode 在 SWE-bench Verified 上跑到 71% 修复率的时候我的反应和大多数人一样——先怀疑再好奇最后是那种得亲自拆一遍的冲动。SWE-bench 这个基准不是随便刷的它把真实开源仓库里的 issue 和对应的 PR 拿出来让模型在只看到 issue 描述和代码库的前提下自己定位问题、改代码、跑测试最后用仓库原有的测试用例来判定修没修好。71% 意味着在 500 道经过人工验证的题目里有 355 道左右被真正修对了而不是看起来像修对了。这个数字之所以值得单独拎出来聊是因为它跨过了一条很多人心里的线。早两年大家讨论代码智能体语境基本是能补全、能写函数、能解释报错属于辅助工具。而 SWE-bench 考的是端到端的自主修复理解一个陌生仓库、跨文件追踪调用链、写出能过测试的补丁。这两件事的难度差了一个量级。补全是在你画好的框里填内容修复是连框在哪都得自己找。TianxiCode 这个项目本身从公开信息看走的是智能体框架 强代码模型 工具链编排的组合路线而不是单纯堆一个更大的模型。它把任务拆成定位、复现、修改、验证几个阶段每个阶段有独立的工具调用和反馈回路。71% 这个结果说明的不是模型变聪明了这么简单而是整套工程化流程——检索、执行、测试反馈、失败重试——已经能稳定跑通大部分真实场景。我写这篇东西的目的很直接把 71% 背后的技术拆解讲清楚它到底解决了什么问题、用了什么思路、哪些环节是真正的难点、如果你想自己搭一套类似的代码智能体该从哪下手。适合两类人看——一类是想理解代码智能体能力边界的开发者另一类是想动手做类似系统、需要可落地参考的工程同学。不吹不黑只讲我拆下来觉得真正有价值的部分。2. 代码智能体的核心架构拆解2.1 为什么定位问题比写代码更难很多人以为代码修复的瓶颈在写补丁其实真正卡脖子的是定位。一个真实仓库动辄几万行、几十个模块issue 描述往往还很模糊比如在某些情况下保存会失败。你得先搞清楚是哪个入口触发的、调用链经过哪些函数、失败发生在哪一层、是逻辑错误还是边界条件没处理。TianxiCode 这类系统在定位阶段通常做几件事。第一是仓库级检索把 issue 里的关键词、报错信息、堆栈片段映射到具体文件和符号。第二是调用链分析从疑似入口往下追构建出可能的执行路径。第三是历史线索利用看这个文件最近有没有相关改动、有没有相似的已修复 issue。这里有个容易被忽略的点检索质量直接决定后面所有环节的上限。如果第一步定位偏了后面模型再强也是在错误的文件里瞎改。我见过不少自建智能体模型用的是顶配但因为检索策略粗糙整体修复率卡在 30% 上下上不去。TianxiCode 能到 71%检索这一环一定是下了功夫的。提示如果你自己在搭类似系统先把检索和定位做扎实再考虑换更强的模型。顺序反了会浪费大量算力。2.2 智能体的手脚工具调用与执行环境代码智能体区别于普通对话模型的核心是它能动手。TianxiCode 的工具集大致包括文件读写、代码搜索、命令执行、测试运行、补丁应用。这些工具不是摆设每一个都对应修复流程里的一个动作。执行环境这块特别关键。真实仓库有依赖、有构建步骤、有测试框架你得给智能体一个能跑起来的环境否则它改完代码根本验证不了。常见做法是容器化把仓库和依赖打包进一个隔离环境智能体在里面自由操作跑测试拿反馈。我实测下来环境准备的坑比想象中多。依赖装不上、测试超时、某些测试本身就不稳定flaky test这些都会污染反馈信号。一个成熟的系统必须能区分我的补丁错了和环境本身有问题否则智能体会被误导着乱改。2.3 反馈回路测试驱动才是真正的裁判71% 这个数字的可信度很大程度上来自 SWE-bench 用仓库原有测试来判定。这意味着智能体不能靠自我感觉良好蒙混过关必须真的让测试从红变绿。TianxiCode 的流程里测试反馈是闭环的核心。改完代码跑测试失败了看报错根据报错再改循环往复直到通过或者达到重试上限。这个机制听起来简单但工程上有几个难点一是测试输出往往很长得提取有效信息喂给模型二是有些失败是连锁的改一个地方引发另一个地方挂掉三是要防止智能体作弊比如直接改测试用例让它通过。注意防作弊是自建系统必须考虑的问题。至少要检测智能体有没有修改测试文件、有没有跳过断言、有没有用 try-catch 把异常吞掉。3. 71% 修复率背后的关键技术点3.1 仓库级上下文管理怎么把几万行代码塞进有限窗口这是所有代码智能体都要面对的现实问题仓库太大模型上下文有限。TianxiCode 的做法不是硬塞而是分层筛选。先通过检索缩小到相关文件再对相关文件做符号级切分只把真正可能用到的函数、类、调用关系喂进去。具体来说它通常会构建一个仓库的抽象表示比如文件树、符号索引、依赖图。当 issue 进来时先在这个抽象层做匹配找到候选区域再展开成具体代码。这样既控制了输入规模又保留了必要的上下文。我自己的经验是上下文管理做得好不好直接体现在模型有没有看到它该看的东西。有时候修复失败不是模型不会而是关键的那个函数压根没进上下文。所以检索召回率比精确率更重要——宁可多给一点也别漏掉关键代码。3.2 多轮迭代与失败重试策略一次改对是运气多轮改对才是能力。TianxiCode 的修复过程是迭代式的生成补丁、应用、跑测试、分析结果、再生成。每一轮都基于上一轮的反馈调整。重试策略里有几个细节值得说。第一是重试上限不能无限循环一般设 3 到 5 轮。第二是失败信息的利用要把测试报错、堆栈、diff 结果结构化后喂回模型而不是原样丢进去。第三是多样性如果连续几轮都往同一个方向改还失败得换思路比如回退到定位阶段重新找问题。实测下来大部分能修好的题在前两轮就搞定了拖到第四五轮还在挣扎的成功率会明显下降。所以重试策略的重点不是多试几次而是每次试得不一样。3.3 补丁生成的质量控制补丁生成看着是模型的活其实工程约束很多。一个好的补丁要满足几个条件能过测试、不破坏其他功能、风格和原仓库一致、改动范围尽量小。TianxiCode 在补丁生成后通常会做几道检查。一是语法检查确保改完的代码能解析。二是影响范围分析看改动会不会波及无关模块。三是回归测试跑一遍相关测试确认没引入新问题。这里有个反直觉的点改动越小不一定越好。有些 bug 的根因在架构层面只改表面症状会导致测试过了但问题还在。所以补丁质量不能只看测试结果还得看它有没有真正解决根因。当然在自动化系统里判断根因很难这也是当前代码智能体的一个能力边界。4. 实操搭一套能跑的代码修复智能体4.1 环境准备与依赖管理先说环境。你需要一个能隔离运行的容器环境把目标仓库、语言运行时、依赖、测试框架都装进去。以 Python 项目为例大致流程是拉取仓库、创建虚拟环境、安装依赖、确认测试能跑通。# 以某 Python 仓库为例的环境准备流程 git clone repo_url /workspace/repo cd /workspace/repo python -m venv .venv source .venv/bin/activate pip install -e . pip install pytest # 先跑一遍测试确认基线状态 pytest -x -q这一步的关键是确认基线可跑。如果原始仓库测试就有失败你得记录下来后面判断智能体修复效果时要排除这些干扰项。提示依赖安装失败是常见问题尤其是老仓库。可以准备一个依赖缓存层避免每次重建环境都重新下载。4.2 检索与定位模块的实现检索模块我建议分两层做。第一层是文本检索用 issue 里的关键词、报错信息去匹配文件路径和代码内容。第二层是符号检索基于代码解析构建符号表按函数名、类名、变量名匹配。# 简化的检索逻辑示意 def locate_relevant_files(issue_text, repo_index): keywords extract_keywords(issue_text) candidates [] for kw in keywords: # 文本层匹配 candidates repo_index.search_text(kw) # 符号层匹配 candidates repo_index.search_symbol(kw) # 去重并按相关度排序 return rank_by_relevance(candidates)排序策略上我一般会给最近被修改过的文件和出现在堆栈里的文件更高权重因为这两类文件是问题高发区。4.3 修复循环的完整实现修复循环是整个系统的引擎。核心逻辑是定位、生成补丁、应用、测试、判断、重试。def repair_loop(issue, repo, max_rounds5): context locate_relevant_files(issue, repo.index) for round_idx in range(max_rounds): patch generate_patch(issue, context, repo) if not apply_patch(repo, patch): context 补丁应用失败请检查格式 continue result run_tests(repo) if result.passed: return patch, success # 把失败信息结构化后加入上下文 context format_failure(result) # 连续失败则回退重新定位 if round_idx 2 and not result.improved: context locate_relevant_files(issue, repo.index, retryTrue) return None, failed这段逻辑里format_failure很重要它把冗长的测试输出压缩成模型能消化的关键信息比如哪个测试挂了、报什么错、期望值是什么。4.4 验证与防作弊检查补丁生成后不能直接信得验证。除了跑测试还要检查补丁有没有动测试文件、有没有可疑的异常吞没、有没有大范围无关改动。def validate_patch(patch, repo): # 检查是否修改了测试文件 if patch.touches_test_files(): return False, 补丁修改了测试文件 # 检查改动范围 if patch.changed_lines() 200: return False, 改动范围过大 # 检查是否有异常吞没 if patch.contains_bare_except(): return False, 存在异常吞没 return True, ok这几道检查能挡掉相当一部分假修复。我踩过的坑就是早期没做防作弊结果智能体学会了改测试用例测试全绿但问题一个没解决。5. 常见问题与排查技巧实录5.1 修复率上不去的几个典型原因现象可能原因排查方向定位总是偏检索召回率低检查关键词提取和符号索引补丁应用失败格式或上下文不匹配检查 diff 格式和行号测试一直挂环境问题或 flaky test先跑基线确认环境改完引入新问题缺少回归测试扩大测试范围反复改同一处重试策略单一增加回退和换思路机制这张表是我自己排查时总结的基本覆盖了八成以上的问题。定位偏是最常见的因为它是整条链路的起点。5.2 测试反馈的清洗与利用测试输出往往几百上千行直接喂给模型既浪费窗口又干扰判断。我的做法是提取关键信息失败的测试名、断言错误、期望值与实际值、堆栈里指向仓库代码的部分。def clean_test_output(raw_output): lines raw_output.split(\n) key_lines [] for line in lines: if any(kw in line for kw in [FAILED, AssertionError, Error, assert]): key_lines.append(line) return \n.join(key_lines[:50]) # 限制长度清洗后的反馈信息密度高模型更容易抓住重点。这一步做得好重试的成功率能明显提升。5.3 我踩过的几个坑第一个坑是环境不稳定。早期我没做环境隔离测试跑着跑着依赖冲突了智能体以为是自己的补丁有问题越改越乱。后来改成容器化每次从干净环境开始问题就消失了。第二个坑是过度信任模型。有段时间我让模型自己判断修好了没结果它经常自我感觉良好。后来强制用测试判定才把水分挤掉。第三个坑是重试策略太死板。一开始就是简单重复失败五次还是同一个思路。后来加了连续失败就回退重新定位成功率上了一个台阶。注意代码智能体不是越自主越好关键环节该加约束就加约束尤其是验证环节。6. 代码智能体的能力边界与后续扩展71% 是个漂亮的数字但剩下的 29% 才是真正值得研究的。我拆下来发现失败案例大致分几类一类是问题描述太模糊人看了都得猜一类是涉及跨仓库或外部依赖智能体够不着还有一类是根因在架构设计需要大改超出了小补丁的范畴。这说明当前代码智能体的强项是有明确测试、问题局部化、改动可控的场景弱项是需求模糊、影响面大、需要设计决策的场景。认清这个边界比盲目追求更高的数字更有意义。后续扩展方向我看好两个。一是多智能体协作让定位、修复、验证由不同角色分工互相制衡。二是经验积累把修过的 issue 和补丁沉淀成知识库遇到相似问题时直接复用。这两个方向都不依赖更大的模型而是靠工程和数据的积累性价比更高。我个人在实际操作中的体会是代码智能体的价值不在于替代开发者而在于把那些重复、琐碎、有明确验证标准的修复工作自动化掉让人能腾出手做真正需要判断力的事。71% 不是终点它更像是一个信号——这条路走通了接下来是怎么走得更稳、更远。