联想TianxiCode登顶代码智能体榜单

联想拿下SWE-bench-Live Lite第一名

联想天禧AI自主研发的代码智能体框架TianxiCode，近日以71%的问题解决率登上SWE-bench-Live Lite榜单第一名。此次参评并非TianxiCode单独完成，而是由TianxiCode负责工程流程、工具调用与补丁验证，DeepSeek-v4.1-Flash负责代码理解和推理，两者共同组成完整的软件工程智能体系统。

**TianxiCode是联想天禧AI面向代码生成、缺陷修复和工程开发场景打造的代码智能体框架。**与普通代码补全工具不同，它不仅生成一段看起来合理的代码，还需要读取仓库、定位相关文件、修改实现、运行测试，并在失败后继续调整补丁。

截至2026年10月9日，联想公布的核心结果如下：

| 项目 | TianxiCode参评结果 | |---|---| | 评测榜单 | SWE-bench-Live Lite | | 问题解决率 | 71% | | 基础模型 | DeepSeek-v4.1-Flash | | 智能体框架 | TianxiCode | | 核验状态 | Verified，已通过官方运行轨迹审查 | | 核心任务 | 真实GitHub项目问题定位、补丁生成与测试验证 | | 后续方向 | 向联想AI硬件及开发者工具链落地 |

这个第一名有分量，但需要准确理解它代表什么：71%是智能体系统在指定评测集上的问题解决率，不是基础模型单独跑出的代码能力分数。换句话说，这次成绩既属于DeepSeek-v4.1-Flash的推理能力，也属于TianxiCode对工具、上下文、测试和重试流程的组织能力。

SWE-bench-Live测的不是代码补全

**SWE-bench-Live是一个持续更新、以真实开源仓库问题为基础的软件工程智能体评测基准。**参评系统会收到一个代码仓库和对应的问题描述，需要理解现有实现、找到故障位置、生成补丁，并通过评测方设置的测试用例。

这类任务与传统代码生成跑分存在明显区别。传统评测经常要求模型补全函数、回答算法题，或者根据一段自然语言生成独立代码；SWE-bench-Live面对的却是完整仓库，问题可能横跨多个文件、依赖历史实现，并受到测试、运行环境和项目约定的共同约束。

| 能力维度 | 传统代码补全 | 单轮代码问答 | SWE-bench-Live智能体任务 | |---|---|---|---| | 输入范围 | 当前文件或局部上下文 | 问题描述与少量代码 | 完整仓库与真实Issue | | 主要目标 | 预测下一段代码 | 给出解释或代码片段 | 生成可执行、可验收的补丁 | | 是否操作工具 | 通常不需要 | 通常不需要 | 需要搜索、编辑、运行测试 | | 是否处理失败 | 很少 | 多由用户继续追问 | 智能体自动读取错误并重试 | | 成功标准 | 代码相似度或单元测试 | 回答是否合理 | 补丁通过目标测试且不破坏既有功能 | | 与生产开发距离 | 较远 | 中等 | 更接近真实缺陷修复流程 |

SWE-bench-Live的关键变化在于“Live”，即评测内容会持续吸收新的软件问题。静态题库公开时间越长，越容易被训练数据覆盖，最终可能测到的是模型是否见过答案，而不是能否独立解决问题；动态更新无法彻底消除污染，但可以缩短题目暴露时间，提高直接记忆答案的难度。

Lite分榜则是完整任务集合的精简版本，主要目的是降低评测成本并加快迭代。TianxiCode登顶的是SWE-bench-Live Lite，而不是所有SWE-bench系列榜单的绝对第一，因此更准确的表述应当是：它在本次Live Lite榜单及对应评测配置中取得71%，并位列第一。

71%也不能直接换算为企业生产环境中71%的缺陷都能自动修好。榜单任务拥有明确的问题描述、可复现仓库和相对标准化的验收条件，而现实项目还会遇到内部服务依赖、缺失文档、模糊需求、权限边界、跨团队协作和无法稳定复现的线上故障。

Verified让成绩更可信，但不是万能背书

**Verified核验是评测方对参评系统运行过程、信息隔离和结果可复现性进行审查的机制。**根据此次公开信息，TianxiCode与DeepSeek-v4.1-Flash组合提交了完整运行轨迹，评测方检查了输入、工具调用、补丁生成和执行过程，并排查测试答案或隐藏结果提前泄露给智能体的可能性。

运行轨迹的重要性在于，它能回答系统究竟是怎样得到答案的。一份完整轨迹通常会记录智能体查看了哪些文件、执行了哪些命令、生成过哪些补丁、遇到什么报错，以及如何根据测试结果继续修改。

通过Verified审查意味着71%不是只提供结果、不公开过程的自报数字。它至少说明评测组织方能够检查并复现这条任务链，也降低了通过人工干预、数据泄露或特殊规则绕过评测的嫌疑。

Verified依然不等于所有工程指标都已经透明。联想目前披露的信息尚不足以回答单个任务平均消耗多少Token、需要多少轮模型调用、运行多长时间、失败任务如何分布，以及系统为了得到最终结果使用了怎样的搜索预算。

这些数据会直接决定产品价值。一个解决率71%但每个任务需要运行数小时、进行几十次模型调用的系统，和一个在几分钟内完成同样任务的系统，部署成本与开发体验完全不同；如果缺少延迟、费用和资源消耗，排行榜只能说明能力上限，暂时不能证明商业效率。

TianxiCode的价值在于把模型变成工程师

**代码智能体框架是连接大语言模型与真实开发环境的一套任务规划、工具调用、上下文管理和反馈闭环系统。**如果把DeepSeek-v4.1-Flash看作负责理解和推理的大脑，TianxiCode承担的就是读取仓库的眼睛、修改文件的双手、运行命令的工具箱，以及决定下一步动作的工作流程。

基础模型并不会因为“懂代码”就自然掌握一个陌生项目。面对大型仓库，系统首先要识别目录结构和技术栈，再根据Issue描述搜索符号、调用关系与相关测试；如果一次性把大量文件全部塞进上下文，不仅成本高，还会让真正关键的信息被噪声淹没。

TianxiCode的工程重点之一，是让智能体围绕任务逐步获取上下文。系统需要先形成问题假设，再选择文件和命令验证假设，最后只把相关代码送给模型推理，这与开发者排查问题时从日志、调用栈和测试失败位置逐步缩小范围的过程相似。

**闭环补丁生成是指智能体在修改代码后主动执行验证，并依据执行结果继续修订补丁。**一次生成的代码即使语法正确，也可能破坏其他功能；闭环流程会把测试结果重新反馈给模型，让系统判断是实现错误、环境问题，还是最初定位方向不对。

**测试驱动自愈是指系统利用编译、静态检查和自动化测试的反馈，自主发现并修正补丁缺陷。**它的价值不在于保证每次修改都正确，而在于把失败转化为下一轮可利用的信息，使代码生成从单次猜测变成能够验证的搜索过程。

| 系统环节 | 基础模型主要作用 | TianxiCode框架主要作用 | |---|---|---| | 理解Issue | 分析自然语言需求与错误现象 | 整理任务状态并规划调查步骤 | | 浏览仓库 | 判断代码语义和模块关系 | 搜索文件、符号与依赖关系 | | 生成补丁 | 推理修改方案并生成代码 | 控制修改范围、写入文件并保存状态 | | 执行验证 | 解读错误日志与测试结果 | 调用编译器、测试框架和检查工具 | | 失败重试 | 反思原因并提出新方案 | 管理迭代轮次、上下文与停止条件 | | 输出结果 | 总结修复逻辑 | 汇总补丁、测试结果和操作轨迹 |

这也是此次71%成绩最值得关注的地方：在基础模型确定后，智能体框架仍然可以显著改变最终的软件工程表现。模型决定推理能力的上限，框架则决定这些能力能否稳定转化为正确补丁；工具选错、上下文混乱或测试闭环缺失，都会让一个强模型在真实仓库中迅速失效。

联想真正要做的是端侧开发智能体

TianxiCode并不是联想准备单独展示的一次榜单实验，而是天禧AI专业智能体能力的一部分。联想表示，相关能力未来将进入AI硬件产品，并逐步沉淀到开发者实际工具链中。

硬件厂商进入代码智能体市场，优势不只在于预装一个聊天窗口。联想掌握PC工作负载、设备资源调度、企业终端管理和本地数据边界，如果TianxiCode能够与本地文件系统、开发环境、NPU和企业权限体系深度结合，就有机会处理云端编程助手不容易触及的私有仓库与离线开发场景。

端云协同可能是TianxiCode更现实的落地形态。高难度推理可以交给云端模型，本地端负责代码索引、敏感信息过滤、工具执行和轻量模型推理，在性能、隐私与成本之间取得平衡；完全依赖本地计算虽然更利于数据控制，但当前PC端模型在长上下文和复杂规划上的能力仍有限。

企业采用代码智能体时最关心的也不只是解决率。权限隔离、命令白名单、补丁审计、依赖安全、许可证风险和敏感代码外发控制，都会决定系统是否能从个人试用走向团队部署；硬件厂商如果能把这些治理能力预置到设备管理体系，反而可能形成区别于纯软件工具的竞争点。

TianxiCode目前仍缺少几个决定产品竞争力的信息，包括是否向外部开发者开放、支持哪些IDE与语言、能否连接企业私有模型、是否提供本地部署，以及运行数据会不会离开设备。没有这些答案，71%首先是一项技术验证，还不能直接等同于成熟可用的商业产品。

代码智能体的竞争正在从模型转向系统

代码智能体市场已经进入“模型能力加工程框架”的系统竞争阶段。仅比较模型在算法题上的正确率，很难预测它能否修复一个包含数十万行代码、复杂依赖和大量历史约定的真实项目。

TianxiCode此次登顶说明，国内团队不必只依赖更大参数规模参与竞争。通过更好的仓库检索、上下文压缩、工具编排、测试反馈和失败恢复，同一个基础模型可以释放出更高的软件工程能力，这也给企业自建智能体提供了明确方向。

开发者应该把71%理解为一个高水平起点，而不是“自动程序员已经完成”的终点。剩余29%的失败任务往往更值得研究，因为它们可能集中在跨模块修改、隐含需求、复杂环境配置或测试反馈不足等难点上，而这些恰恰是生产项目最常见的问题。

联想下一步需要用真实产品证明这套框架的效率与边界。如果TianxiCode能够公布更完整的运行轨迹、成本和耗时数据，并在IDE或联想AI PC中提供可验证的开发体验，它的意义就会从一次榜单登顶，转变为可供开发者长期使用的软件工程基础设施。

参考来源

• SWE-bench官方开源仓库：介绍SWE-bench任务定义、评测流程、数据结构与复现实验方法，是理解真实仓库问题修复评测的基础资料。

注：TianxiCode的71%成绩、DeepSeek-v4.1-Flash配置、Verified状态及产品规划来自联想天禧AI于2026年10月披露的信息；受文末来源域名范围限制，未列出相关国内媒体转载链接。