Serena 到底能不能省 Token 、提高重构质量？公开基准、企业实测和真实用户数据整理
Serena 是一个面向编程代理的代码工具集，通过模型上下文协议接入 Claude Code、Codex、OpenCode 等工具。它提供符号查找、引用分析、跨文件重命名、移动符号和安全删除等能力，目标是让编程代理像 IDE 一样按代码符号工作，而不是只依赖文本搜索和文件读取。
Serena 官方称这类语义工具在大型、复杂代码库中可以提高效率和可靠性。围绕这一点，目前已经出现第三方可复现实验、企业项目测试、社区单次对照、竞品作者基准测试，以及 Serena 自己发布的评估数据。不同测试得到的结果并不一致。
agent-bench：强模型没有提升，弱模型获得语义保护
2026 年 6 月，agent-bench 使用 OpenCode 对 Serena 做了可复现对照测试。测试模型包括 Qwen3.6-35B 和 Mistral-Small-4。基准组只使用 OpenCode 自带的搜索、读取、编辑和终端工具，Serena 组在这些工具之外增加 Serena。
测试使用确定性检查判断任务是否成功，不使用大模型作为裁判。简单任务重复 5 次，较困难任务重复 3 次。作者明确说明，这些数字用于观察成功率和变化方向，不进行统计显著性推断。
在简单 TypeScript 重命名任务中，两组成功率都是 100%，代码改动也相同，但 Serena 增加了输入 Token 。
| 模型 | 基准组输入 Token | Serena 输入 Token | Serena 增幅 |
|---|---|---|---|
| Qwen3.6 | 75,628 | 195,171 | +158% |
| Mistral-Small | 99,286 | 149,351 | +50% |
16 个文件的批量重命名任务中，Qwen3.6 的工具调用从 44 次下降到 39 次，但两组在成功率和最终代码质量上没有差异。作者把这类机械式任务的结果归为 Serena 带来额外开销。
区别出现在存在同名方法的模糊重命名任务。任务要求把 UserRepository.save 改成另一个名字，同时不能修改无关的 Logger.save。
| 模型 | 设置 | 成功率 | 平均工具调用 | 平均输入 Token | 平均改动文件 |
|---|---|---|---|---|---|
| Qwen3.6 | 基准组 | 100% | 15.7 | 146,708 | 4 |
| Qwen3.6 | Serena | 100% | 13.0 | 151,871 | 4 |
| Mistral-Small | 基准组 | 0% | 24.0 | 313,080 | 8 |
| Mistral-Small | Serena | 33% | 11.0 | 152,721 | 1.7 |
Qwen3.6 在两种设置下都正确完成任务。Mistral-Small 在没有 Serena 时 3 次全部失败，每次都误改了无关的 Logger.save，而且错误代码仍然能够通过类型检查和代码检查。
加入 Serena 后，Mistral-Small 有 1 次成功，另外 2 次没有完成全部修改。平均误改文件数量从 8 个下降到 1.7 个，输入 Token 也从约 31.3 万下降到约 15.3 万。作者最终把 Serena 定义为一种“情境型工具”：对于已经能正确完成任务的强模型，它可能只是额外开销；对于弱模型，它可以充当语义保护栏，但不能保证任务一定成功。
ManoMano：36,407 行 Java 项目大型重构测试
ManoMano 工程团队在 2026 年 2 月 2 日使用 Claude Sonnet 4.5 做了一次企业代码库测试。目标项目是一个 Java 多模块支付服务，包含 381 个类、36,407 行代码和 1,017 个测试。
他们比较了三种设置：原生 Claude、Claude 加内置语言服务器、Claude 加 Serena。测试包含业务规则查询、方法引用查询、复杂度分析和跨文件大型重构。
大型重构任务要求从 Payment 类中抽取新的 PaymentDates 结构，修改所有相关使用位置，并最终通过完整构建和 1,017 个测试。
| 设置 | 时间 | 成本 | 最终结果 |
|---|---|---|---|
| 原生 Claude | 约 1 小时 | 23.54 美元 | 未得到可构建项目 |
| Claude + 内置语言服务器 | 约 1 小时 | 28.63 美元 | 3 次迭代后仍有 9 个测试失败 |
| Claude + Serena | 45 分钟 | 27.30 美元 | 构建成功，1,017 个测试全部通过 |
原生 Claude 在任务中启动了 12 个子编程代理；Serena 方案使用了 4 个。文章还记录，Serena 在该重构任务中通过自己的缓存读取了超过 6,900 万 Token 。
但同一组测试在简单查询任务上得到相反结果。查找一个业务规则时，Serena 的成本接近原生 Claude 的 4 倍，执行时间多约 60%。查询方法使用位置时，原生 Claude 和 Serena 都正确完成，而且成本接近。
ManoMano 团队最终给出的使用规则是：简单只读探索使用原生工具；涉及大型重构、架构修改和复杂写入时使用 Serena。
Sense 作者的 MCP 基准测试：Serena 排在无 MCP 基准组之后
网页地址：dev.to/luuuc/how-d…
2026 年 5 月，Sense 作者 Luc B. Perussault-Diallo 公布了一套代码智能 MCP 基准测试，同时比较 Sense、Probe、Serena、GitNexus 和没有额外 MCP 的 Claude Code。
作者主动披露自己也是参测产品 Sense 的作者。测试固定使用 Opus 4.7 和 100 万 Token 上下文，并公开代码、场景、评分规则、执行记录和裁判提示词。测试还建立了 3 个保留场景，并要求自动评分与人工评分的 Spearman 相关系数达到 0.85 以上。
公开结果如下：
| 设置 | 公平性评分 | 质量 | Token | 时间 | 成本 |
|---|---|---|---|---|---|
| Sense | 81.3% | 85.4% | 10,896 | 141 秒 | 6.22 美元 |
| Probe | 77.7% | 84.8% | 12,119 | 162 秒 | 6.23 美元 |
| 无 MCP 基准组 | 77.2% | 84.2% | 12,716 | 185 秒 | 7.57 美元 |
| Serena | 75.2% | 83.4% | 14,800 | 191 秒 | 7.57 美元 |
| GitNexus | 74.9% | 84.5% | 12,964 | 173 秒 | 6.87 美元 |
Serena 的质量为 83.4%，低于无 MCP 基准组的 84.2%； Token 从 12,716 增加到 14,800；时间从 185 秒增加到 191 秒；成本同为 7.57 美元。
这套测试还单独检查了回答中的文件和代码位置引用是否真实存在。Serena 的引用落地率为 61.9%，无 MCP 基准组为 80.8%，Sense 为 89.2%。作者据此给出的结论是，在他的默认测试配置中，Serena 和 GitNexus 都排在无 MCP 基准组之后。
30 万行 Java 代码库实测：请求上下文减少约 64%，时间增加 2.36 倍
2026 年 7 月 29 日，一名用户在 Serena GitHub Discussion 中公布了一次 OpenCode + GPT-5.5 的 Serena 开关对比。
测试项目是约 30 万行的 Java 多项目代码库。两次运行执行同一个请求，测试目标是观察 Serena 是否能降低大型代码库分析时的上下文占用。
没有 Serena 时，请求执行时间为 56.8 秒，最终会话上下文为 27,042 Token 。
开启 Serena 后，初始化 Serena 花费 51.6 秒，初始化完成时上下文已经达到 21,286 Token 。随后执行相同请求花费 2 分 14 秒，最终上下文为 31,016 Token ，这一阶段新增 9,730 Token 。
作者给出的单次实验结论是：与请求相关的上下文占用约减少 64%，但请求执行时间增加到 2.36 倍。如果把 Serena 和语言服务器初始化计算在内，冷启动总时间为 3 分 5.6 秒。
Serena 维护者 MischaPanch 随后回复称，可以把 Serena 作为长期运行的 HTTP 服务，从而去掉每次启动的初始化时间；他同时指出 Java 的 JDTLS 初始化较慢，而 JetBrains 后端在 Java 上运行更平滑。他还表示，长会话可以逐步摊薄最初约 2.1 万 Token 的上下文开销。
Serena 官方 Claude Code 评估：跨文件重构减少调用，小修改反而增加负载
网页地址：oraios.github.io/serena/04-e…
Serena 官方在 2026 年 4 月使用 Claude Code + Opus 4.6，对 Tianshou Python 项目进行了 20 个任务的对照评估。Tianshou 约有 26,000 行代码和 43 个源文件。
每个任务分别使用 Serena 和 Claude Code 内置工具执行，实际修改代码后通过 git diff 检查，再恢复到原始状态。
跨文件重命名任务中，Serena 使用 1 次调用完成 4 个文件的定义、导入和使用位置修改。内置工具需要 1 次搜索、4 次读取和 4 次编辑，共 9 次调用。
官方还记录了不同规模编辑的请求负载：
| 编辑任务 | Serena 负载 | 内置编辑负载 | 官方记录 |
|---|---|---|---|
| 13 行方法中修改 1 行 | 约 550 字符 | 约 120 字符 | 内置工具约小 4.5 倍 |
| 中等规模方法重写 | 约 550 字符 | 约 1,000 字符 | Serena 约小 1.8 倍 |
| 55 行完整方法重写 | 约 2,200 字符 | 约 4,400 字符 | Serena 约小 2 倍 |
| 跨 4 文件重命名 | 约 100 字符 | 约 800 字符 | Serena 约小 8 倍 |
这组数字测量的是编辑调用负载，不等于完整会话的输入 Token 消耗。
官方评估给出的结论是：Serena 的主要价值集中在跨文件重命名、移动、引用查找和类型层级等语义任务；对于 1～3 行的小修改，Claude Code 内置编辑工具发送的数据更少。纯阅读任务和小型文本编辑中，Serena 的收益有限。
Serena 官方 Junie 评估：部分 IDE 已经具备相同能力
网页地址：oraios.github.io/serena/04-e…
Serena 还使用 JetBrains Junie + Claude Opus 4.6 在同一个约 26,000 行的 Tianshou 项目上进行了测试。
由于 Junie 本身已经拥有 JetBrains 的一部分语义重构能力，测试中 Serena 的跨文件重命名不再形成优势。一次 CollectStatsBase 的跨文件重命名涉及 4 个文件和 10 处替换，Serena 和 Junie 内置重命名工具都只需要 1 次调用，结果相同。
差异出现在移动符号等操作中。把 get_stddev_from_dist 从一个模块移动到另一个模块时，Serena 通过 1 次调用修改了源文件、目标文件和测试文件，并自动更新导入；官方估计使用 Junie 内置工具完成相同工作需要约 7 次操作。
官方还估计，在典型会话中，Serena 可以增强的工作约占 35%～50%，其余任务包括配置文件、文档、自由文本搜索、终端、Git、测试运行和新建文件等，仍由内置工具处理。
GitHub 用户实测：Serena 需要 1～2 小时修复，Claude Code 6 分钟完成
2025 年 4 月，一名用户在 Serena Discussion 中公布了自己对 Serena 和 Claude Code 的使用结果。
该用户称，Serena 在他的 UI 开发任务中每次提示都会引入多处错误，需要人工调试 1～2 小时才能得到约 80% 完成度的结果。作为对比，他使用 Claude Code 完成 3 个较大的 UI 组件，总时间约 6 分钟，其中提示输入约 60 秒，最终结果不需要继续修改。
用户还记录其中一个 Claude Code 任务的接口成本为 3.92 美元。
Serena 维护者 MischaPanch 当时回复称，他们还没有进行大规模的并排测试，希望用户提供代码仓库、起始提交和提示词，以便复现差异。他随后再次说明，Serena 团队当时并没有声称 Serena 与 Claude Code 在性能上相当，因为团队尚未进行定量和定性的系统对比，而且当时对 TypeScript 的测试也很少。
这条记录发布于 2025 年 4 月，早于 Serena 2026 年发布的正式评估体系。
agent-bench 作者后续修正：小型测试不能验证 Serena 的省 Token 能力
agent-bench 发布测试结果后，Serena 维护者 opcode81 在 Discussion 中提出异议。他指出测试项目只有少量极小文件，部分文件最多只有 6 行，因此并不代表真实大型项目。
维护者给出的理由是：使用 Serena 重命名符号时，编程代理不需要读取所有出现该符号的文件。文件越大，省掉这些读取操作的价值越高；在几行代码的测试文件中，这种差异无法体现。
agent-bench 作者随后接受了这一点，并更新文章。他明确补充：自己的测试测量的是确定性正确率，不是 Serena 在大型代码库中的 Token 缩减能力；测试表中的 Token 变化只适用于这些小型任务，不能作为 Serena 在大型项目中 Token 经济性的结论。
作者表示，验证 Serena 省 Token 的公平方法应该使用大型、存在大量交叉引用的真实代码库，并把它作为单独实验。
Serena 官方评估方法和限制说明
网页地址：oraios.github.io/serena/04-e…
Serena 后来建立了自己的评估体系。官方没有把 SWE-bench 等固定基准作为主要测试，而是让编程代理在真实代码库上完成约 20 类任务，包括代码理解、小型编辑、大型编辑、跨文件重构、可靠性和工作流操作。
这套方法有一个明确特点：执行任务和评价工具的是同一个编程代理。官方称这是有意设计，因为编程代理本身就是 Serena 的直接使用者，可以记录工具调用、负载和前置步骤。评估提示词要求同时记录正面、负面和无收益的情况。
目前官方公布的评估包括 Claude Code、Codex、Copilot CLI、GLM 5.1 和 JetBrains Junie。
另一个限制是，目前这些官方评估全部使用 JetBrains 驱动版本的 Serena。官方说明，这是因为 JetBrains 后端功能更多、重构和导航能力更强；普通语言服务器后端只覆盖其中一部分能力。因此，官方 JetBrains 版本的评估结果不能直接视为普通语言服务器版本得到相同结果。
总结
现有公开测试没有得到“安装 Serena 后一定更省 Token 、更快或成功率更高”的统一结果。
在 agent-bench 的小任务上，强模型 Qwen3.6 无论是否使用 Serena 都能达到 100% 成功率，而 Serena 在简单重命名中让输入 Token 增加 15%～158%。测试作者后来也明确修正了适用范围：这些小文件不能用于判断 Serena 在大型代码库中的省 Token 能力。
在 30 万行 Java 项目的单次社区测试中，Serena 把请求相关的上下文占用降低约 64%，但请求执行时间增加到 2.36 倍，而且还有 51.6 秒初始化时间和约 2.1 万 Token 的初始上下文。这个结果只来自一次运行。
ManoMano 的企业 Java 测试给出了更积极的重构结果：原生 Claude 和内置语言服务器都没有完成大型重构，Serena 在 45 分钟内完成并通过 1,017 个测试。但同一个测试中，简单业务规则查询使用 Serena 的成本接近 4 倍，耗时多 60%。
Sense 作者的独立 MCP 基准中，Serena 的质量、 Token 和执行时间都没有超过无 MCP 的 Claude Code 基准组。该测试作者同时也是参测竞品 Sense 的作者，并在文章中公开披露了这一身份以及测试代码和评分方法。
官方评估和第三方大型项目测试较一致的部分，是 Serena 在跨文件重命名、移动符号、查找引用、类型层级和大型重构中的价值。官方自己的数据也承认，小型单文件修改可能使用更多负载，部分已经具备 IDE 语义能力的编程代理也会缩小 Serena 的优势。
因此，从现有公开数据看，Serena 更接近一个针对大型代码库和语义重构任务的专用工具，而不是通用的“省 Token 插件”。项目规模越小、任务越简单、模型和编程代理自身的代码导航能力越强，额外的模型上下文协议工具描述和初始化成本越难摊薄。大型代码库、跨文件引用和语义重构，则是目前公开测试中 Serena 得到正面结果最集中的场景。
还需要区分官方结果使用的后端：Serena 目前公开的正式评估全部基于功能更完整的 JetBrains 后端，不能默认普通语言服务器版本会获得完全相同的结果。
