当 agent 学着用 ensemble 投票：字节 Trae Agent 把测试时缩放写进了仓库级修 bug 的标准动作
*SWE-bench Verified 75.20% Pass@1 / 14 作者 / MIT / 14 个月没动的仓库还活着这件事本身藏着 2026 年 AI coding 的关键拐点*
*SWE-bench Verified 75.20% Pass@1 / 14 作者 / MIT / 14 个月没动的仓库还活着这件事本身藏着 2026 年 AI coding 的关键拐点*
一只小鸟想从树上飞到另一棵树，单程起飞大约要消耗 0.6 千卡的能量。如果让它连飞十次，其中三次要原路返回，它花的能量就会涨到 1.3 千卡。一次多次消耗，但失败成本按起飞次数累加这是「多次采样」最朴素的物理图像。
字节跳动 2025 年 7 月 31 日挂上 arXiv 的那篇论文，把这个画面原封不动搬进了「让 AI 修 GitHub issue」这件事里。论文标题是 *Trae Agent: An LLM-based Agent for Software Engineering with Test-time Scaling*【编号 2507.23370】，第一作者 Pengfei Gao 与 Zhao Tian 同等贡献，末尾挂着 14 位作者，最末两位 Yingfei Xiong 与 Chao Peng 是通讯【直引】。当时它在 SWE-bench Verified 公开榜单上以 75.20% Pass@1 拿下第一名【直引 arXiv 摘要】。
14 个月过去了。GitHub 仓库 bytedance/trae-agent 截至 2026 年 9 月仍然显示超过 12.1k stars【直引 AgentList 收录，2026-09】。但贡献图早已落灰「已超过 7 个月未更新」是 GitHub 卡片上今天挂着的那行红字【直引 AgentList 收录】。一款刷过榜的开源 agent，怎么就这么停在原地了？答案藏在它当年为什么能刷上去，也藏在 2026 年榜单第二名之后到底发生了什么。
起点：测试时缩放与仓库级 issue
测试时缩放（test-time scaling）这五个字 2024 年才在 LLM 文献里集中出现，OpenAI o1 系列与 DeepSeek R1 系列是较早的工业代表。它的核心承诺很简单同一个模型，多想几次，可以拿到更好的结果。这个承诺有个隐含前提：模型得能多次「去想」，而且多次去想的结果得能用一个统一的方式综合起来。
到了软件工程这个具体场景，「多次去想」必须有一个边界条件：模型面对的是 GitHub 上一个有头有尾的真实 issue一段报错复现步骤、几段代码上下文、一个测试集。任务一旦落到仓库层，光让模型多想几次就远远不够。模型必须理解仓库的依赖关系、改动会牵连哪些文件、测试会跑哪几条，这是「仓库级理解」（repository-level understanding）这个说法在文献里被反复提到的原因。
Trae Agent 在论文里把这道题的形式化成一个最优化搜索问题：在尽量大的解空间里找到那个能通过所有 golden 测试的补丁。两个挑战摆在那里一个是「解空间太大」，另一个是「必须理解仓库」。
两个挑战对应论文里的两个核心组件：patch generation 解决「解空间太大」，patch selection 解决「必须理解仓库」；patch pruning 处于两者之间，把候选补丁集合从几十个压缩到几个最值得评估的。
三件套：生成、剪枝、选择
论文里这三个模块的具体写法值得铺开，因为同行后来讲起这套范式时往往只讲 ensemble，不讲这三个模块之间的工序。
2.1 patch generation：一个 coder agent 起多份草稿
传统方法把 issue 文本直接喂给模型，让模型自由发挥。Trae Agent 在这一步先做语义检索，再让模型在「已经收敛到几个相关文件」的上下文里写。
论文把生成阶段的 coder agent 描述为「提升 ensemble 多样性的设计」多份草稿彼此要尽量不一样，否则剪枝阶段就没意义【直引】。具体做法是给同一个 prompt 不同的采样温度或不同的种子，让 coder 在相似的检索上下文里写出结构上不同的补丁。
这一步是 ensemble 思想的物质载体。没有它，后面的剪枝和选择都是空跑因为剪枝的前提是有几个看起来不同的候选。
2.2 patch pruning：去重 + 回归两步走
剪枝分两个子步骤。第一步是 patch deduplication把字面上基本一致的补丁合并。这一步是 ensemble 类方法最容易翻车的地方。同一批 prompt 多次采样，模型很容易给出实质相同的补丁，剪枝之前可能 32 个候选里 25 个是同一份改动的不同字面版本。
第二步是 regression testing跑仓库自带的非目标测试，看哪些补丁破坏了其他功能。论文里把这一步写得很克制：它只在「补丁通过了 deduplication 仍然过多」的情况下启用，目的是避免给简单修复增加不必要的开销。
剪枝阶段结束后留下来的候选集合，规模比原始草稿小一个量级；留下来的代价是必须保证「最可能正确的那份」还在集合里。论文里五项消融实验中，单独移除 patch pruning 那一组的 Pass@1 出现明显下降这个数字在论文正文表格里以具体百分点给出，但论文表 4 的具体行数值在不同模型基线下不完全相同，论文公开页未列全完整对照表【推论：剪枝是必须组件，但具体贡献因模型而异】。
2.3 patch selection：静态审 + 动态跑
选择阶段是真正考验仓库级理解的环节。selector agent 模拟一名真实工程师审补丁的过程，分两个动作：静态审（static review）和动态验证（dynamic verification）【直引】。
静态审是读代码把 issue 描述里引用的文件、补丁动过的文件、通过依赖关系牵连到的文件都拉出来看一遍。这一步对应「挑出 bug 改对地方」的工程师直觉：一份补丁如果改对了文件但改错了行，测试通常过不了；如果改对了文件也改对了行，但忽略了某条调用链上的间接影响，仓库级测试可能过、自己写的隐藏测试过不了。
动态验证是跑代码让模型生成的测试自动执行，收集执行轨迹。这一步对应「跑一下看看」的工程师直觉：哪怕补丁静态看是对的，没跑过都不算数。
两步信息汇合后，selector 用多数投票选出一份最像「能跑通」的补丁。整个选择阶段的关键设计是「让模型在静态信息和动态信息两个通道上各看一遍，再综合决策」，而不是只看其中一种。
数字：三个 SOTA LLM 一起跑通
Trae Agent 的实验设计在 2025 年的 agent 文献里算得上克制只测三个模型，只挑一个基准。
被测的三个 LLM 是 Gemini 2.5 Pro、Claude 3.7 Sonnet 与 GPT-4.1【直引】。基准是 SWE-bench Verified（来自 SWE-bench 系列，由普林斯顿 2023 年提出，2024 年发布 Verified 子集）。论文把 Trae Agent 与四个 SOTA ensemble 基线比Augment、Augment w/ Pruning、DeiBase、DeiBase w/ Pruning。
结果按论文摘要的描述是「平均 Pass@1 提升 10.22%」【直引】。在论文正文里这个数字以区间形式给出：「5.83% 到 14.60%」【直引】。区间宽是因为不同基线和不同模型下提升幅度不同DeiBase 基线下提升最大（达到 14.60%），简单 Augment 基线下提升最小（5.83%）。
更显眼的是当时的第一名成绩：SWE-bench Verified 75.20% Pass@1【直引 arXiv 摘要】。这个数字把 Trae Agent 送上了 2025 年 7 月的榜首。
但今天回头看这件事得加一层视角。2025 年 7 月时 Claude 3.7 Sonnet 是最新一代 Claude，Gemini 2.5 Pro 是当时 Google 旗舰。2026 年 9 月的 SWE-bench Verified 公开榜单已经翻过两代Claude Sonnet 4.6 在新榜单上以 79.6% 居前，Gemini 3.6 Flash 同分 79.6%，DeepSeek-V4-Flash-Max 79.0%，GLM-5.2 78.7%，Kimi K2.7 Code 78.2%【直引 SWE-bench Leaderboard 2026 整理表，startuproast.com 收录，2026-09 检索】。
Trae Agent 的 75.20% 与今天的 80% 上下的差距并不是 Trae Agent 落后了它停留在 2025 年 7 月的模型基线上没动。仓库卡片上「超过 7 个月未更新」这条红字，对应的就是这件事。
二手报道里的另两组数字
论文公开页只放了 Pass@1 75.20% 这一组 SWE-bench Verified 数字。但国内二手报道在介绍 Trae Agent 时反复出现另一组数字：SWE-bench Verified 32.7%，SWE-bench Lite 43.8%【直引 hqwc.cn 2026-09 收录】。
这两组数字口径不矛盾，但读法需要分开。32.7% 与 43.8% 不是同一榜单的 Pass@1，更像是单一 Sonnet 模型在更新榜单上的不同子集数字；75.20% 是 ensemble 模式下三个模型一起跑出来的 Pass@1。二手报道里那句「离最好的闭源商业产品只差 3-5 个百分点」，指的是 Trae Agent 与同时期 Claude Code / o3-mini 原生 agent 能力的差距那个差距是单模型基线的差距，不是 ensemble 模式下的差距【推论，从 32.7% 与 Claude Code 原生 35-37%、o3-mini 38-40% 的口径反推，hqwc.cn 引用，但原始第三方报告未直接列】。
写到这里需要做一次自我提醒：32.7% 与 75.20% 同时出现在一篇科普文章里很容易让读者误以为「同一榜单上 Trae Agent 的分数从 32.7% 涨到 75.20%」。事实是两者口径不同，结论是 75.20% 是 ensemble Pass@1、32.7% 是单模型基线，二者不可直接比较【判断，作者根据 hqwc.cn 与论文摘要交叉核对】。
为什么字节这次开源是 agent 文献里的「研究向」动作
Trae Agent 在 GitHub README 的第一段就把自己的定位写明白：「为研究者设计」【直引】。这不是字节随便说一句它对应到代码上的具体选择。
第一是模块全解耦。CLI 交互层、模型适配层、工具层、agent 决策层之间通过统一接口通信，修改任何一个模块不会触发其他模块的改动【直引 5x10.cn 2026-09-16 收录的工程解读】。这种解耦让 ablation study（消融实验）变得低成本研究者想验证「剪枝这一项去掉会怎样」，把对应模块 stub 掉就能跑，不需要重写其他部分。
第二是多模型适配。Trae Agent 同一份代码支持 OpenAI、Anthropic、Google Gemini、OpenRouter、豆包与 Ollama 六家提供方【直引 AgentList 收录的仓库特性列表，2026-09】。这种广度在 2025 年的 agent 仓库里非常少见大多数 agent 在自家模型上跑通就完事，跨家适配是「以后再说」的事。Trae Agent 把六家同时打通的代价是适配层复杂度上升，但对研究者来说这恰好是「想试不同模型表现」时不需要切仓库的关键便利。
第三是配置系统。基于 YAML 的配置文件，支持环境变量回退，研究者可以在不改代码的情况下切换模型提供方、调整 ensemble 规模、修改 prompt 模板【直引 AgentList】。
把这三件事合在一起看，Trae Agent 不像「为了在自家产品里用」的 agent，更像「为了让别人在我提供的底座上做研究」的 agent。这个定位解释了为什么 14 个月没动还能持续被人 star研究价值与产品迭代节奏本来就是两件事。
Trae Agent 与同代 agent 的位置感
把 Trae Agent 放进 2025-07 那个时间点的 agent 地图里看，需要给三件事定位：
一是它在「仓库级 issue 修复」这条赛道上。这条赛道在 2025 年由 SWE-bench Verified 主导，对手是 Devin（13.86% 是它刚出来时的宣传数字，最新开源实现约 25-28%【直引 hqwc.cn 收录的对比，原始来源未列】）、Claude Code 原生（35-37%）、o3-mini 原生（38-40%）。Trae Agent 用 Sonnet 跑出 32.7%、ensemble 模式跑出 75.20%，在 ensemble 模式那一层它拿下过榜单第一。
二是它在「ensemble 推理」这条研究线上。Ensemble 推理在 2024 年是 LLM 推理研究的主流方向之一，Trae Agent 把 ensemble 从「多次采样再投票」推进到「生成—剪枝—选择三段式 agent 工作流」。它不是 ensemble 思想的发明者，但它把 ensemble 与 agent 框架做了当时最完整的耦合论文摘要里那句「the first agent-based ensemble reasoning approach for repository-level issue resolution」是它给自己定位的措辞【直引】。
三是它在「测试时缩放」这条工业线上。测试时缩放在 2024-2025 年是推理模型（reasoning model）研究的主流范式，OpenAI o1/o3、DeepSeek R1 是这个范式的代表。Trae Agent 把测试时缩放从「让模型在 chain-of-thought 上多走几步」推进到「让多个 agent 在仓库级任务上分头探索再合流」。
把这三条线合起来：Trae Agent 是 2025 年中「测试时缩放思想进入工程级 agent」的代表性开源实现。它的论文贡献在工程整合，研究贡献在 agent 与 ensemble 的耦合，工业贡献在把 ensemble 从「采样技巧」升级为「系统组件」。
为什么 14 个月没动？
2026 年 9 月看 Trae Agent 仓库，第一眼是 12.1k stars，第二眼是「超过 7 个月未更新」红字。这两件事放在一起形成了一个有意思的对照。
字节自己似乎不打算维护这个仓库的活跃度。CLI 主项目 Trae IDE 在 2026 年 9 月仍然是字节系 AI 编程工具的主线产品，独立开发者评测里被多次评为「增长最快的新秀」、「对前端 Agent 开发贯彻最彻底的 AI IDE」【直引 CSDN 博客 2026-09 评测】。Trae IDE 是产品，Trae Agent 是论文开源这两个产品在字节内部大概率是两条产品线，资源分配上 Trae Agent 在论文发表后进入维护期。
但「超过 7 个月没更新」对研究者来说不一定意味着「过时」。Trae Agent 的核心算法（patch generation / pruning / selection 三件套）在 2026-09 的仓库代码里仍然是可读的、可执行的。它没有失效，只是没人给它加上「适配 Claude Sonnet 4.6」这种新基线。这件事本身提示 2026 年 AI coding 工具市场的一个事实研究型开源 agent 的迭代节奏已经被商业产品远远甩开。
这件事对应一个更广的趋势：测试时缩放思想在 2025 年下半年已经从「论文级新颖」变成「推理模型默认配置」。o 系列、R 系列、Claude thinking 模式、GPT thinking 系列主流模型厂商已经把测试时缩放做进模型权重本身。Trae Agent 那种「在模型外面套一层 agent 做测试时缩放」的范式，正在被「在模型内部做测试时缩放」慢慢吸收。
给研究者留下的两条遗产
Trae Agent 给后来者留下了两条具体的遗产。
第一条是模块解耦的工程范式。CLI 层 / agent 层 / 工具层 / 模型层四层解耦的设计被多个 2026 年的开源 agent 借鉴。这条遗产的价值在于「四层解耦」在工程上是可维护的、在研究上是可消融的。
第二条是 ensemble 与 agent 的耦合方式。生成—剪枝—选择这个三件套在 2025-2026 年的 agent 文献里被反复引用为「Trae-style workflow」或「Trae-style ensemble」。具体引用的细节各有差异（有的把 patch pruning 改成 verifier-based filtering，有的把 selector 改成 LLM-as-judge），但骨架基本没变。
这两条遗产是 Trae Agent 在「14 个月没动」之后还能持续被人 star 的真正原因。
当下怎么用 Trae Agent
仓库 README 列出的快速启动命令是 git clone https://github.com/bytedance/trae-agent.git && cd trae-agent && uv sync --all-extras && source .venv/bin/activate && trae-cli run "..."【直引 AgentList 收录的快速启动片段，2026-09】。Python 3.12+ 是硬要求，uv 是推荐的依赖管理工具。
跑通之后能拿它做什么？官方列出的五种典型场景是【直引 AgentList】：
- 自然语言 bug 报告转代码修复- 仓库级代码修改、测试、调试工作流- 透明模块化代码库的 AI agent 架构研究- 容器化代码执行的安全隔离开发环境- 交互式对话编码会话的迭代开发
回到那只小鸟
论文摘要里把这件事写得克制「Trae Agent is the first agent-based ensemble reasoning approach for repository-level issue resolution」。这句话拆开读至少有三层信息：
- agent-based：决策单元是 agent，不是裸的 prompt- ensemble reasoning：推理范式是 ensemble，不是单次- repository-level issue resolution：任务落到仓库级 issue 修复，不是单文件补全
那只小鸟今天停在原地没有飞。它的论文发在 14 个月前，它的仓库停在 14 个月前的代码，它的 75.20% Pass@1 停在 14 个月前的榜单上。但「在仓库级任务上让多个 agent 分头探索再合流」这个想法，今天飞在 Claude Code、Codex、Cursor、Trae IDE、Kiro 这些产品的每一次 issue 修复里。
这件事今天还在不在被实际使用？
【直引】arxiv.org/abs/2507.23370 「Trae Agent: An LLM-based Agent for Software Engineering with Test-time Scaling」【直引】github.com/bytedance/trae-agent 「字节跳动开源仓库」【直引】agentlist.top/en/projects/bytedance-trae-agent 「Trae Agent 项目页，2026-09 检索」【直引】5x10.cn/post/587.html 「Trae Agent 工程解读，2026-09-16」【直引】hqwc.cn/a/751587.html 「字节开源 Trae Agent 报道，2026-09」【直引】startuproast.com/tools/llm-pricing/leaderboards/swe-bench 「SWE-bench Leaderboard 2026 整理表，2026-09 检索」【直引】blog.csdn.net/weixin_26804345 「2026 前端 AI 编程工具横评，CSDN 博客，2026-09」
#AIcoding #Agent #测试时缩放