微软Terminus-4B之后，Agent可能会进入「专用小模型Sub Agent」时代

您有没有想过：在代码Agent里，执行终端命令、跑测试、读报错、总结日志这种任务，用Claude Opus、Claude Sonnet、GPT-5.3-Codex这类昂贵Token的大模型来执行，是不是有点浪费？一定要这么做吗？

Microsoft最近一项名为《Terminus-4B: Can a Smaller Model Replace Frontier LLMs at Agentic Execution Tasks?》的研究给出的答案是：不一定。

他们提出了一个名为Execution Subagent的执行子Agent，并训练了一个基于Qwen3-4B的小模型 Terminus-4B。这个模型专门负责终端执行任务，最终能做到在不降低代码Agent解题成功率的前提下，Terminus-4B最多可以让主Agent的token使用量下降约30%，并且在一些指标上接近甚至超过Claude Sonnet、Claude Opus、GPT-5.3-Codex作为子Agent时的表现。这可能预示着未来Coding Agent会进入“专用小模型Sub Agent化”的阶段。

核心痛点：被冗余终端输出淹没的上下文窗口

编程智能体在处理实际工作流时，不可避免地需要进行终端执行。这些操作包括：

• 运行项目构建（Builds）。
• 安装所需的代码依赖项。
• 运行诊断测试以复现问题和验证修复方案。

尽管这些步骤必不可少，但它们给智能体带来了一个灾难性的后果：终端输出会迅速淹没智能体的上下文窗口。

直接执行模式的低效性

目前的常规做法是采用“直接执行模式”，即主智能体在自己的上下文窗口中直接运行命令并吸收全部的输出结果。研究者指出，这种架构设计是非常原始且低效的。

• Token消耗巨大：一个输出详细日志的测试运行，可以轻易产生数以万计的token。
• 核心信息被挤占：这些冗长的日志会取代智能体在后续决策中急需的代码上下文、编辑历史和规划信息。
• 滚雪球效应：随着交互轮次的增加，每一次新的终端命令输出都会进一步拥挤上下文窗口，导致智能体在触发Token上限前，能采取的实际问题解决步骤大幅减少。

实际上，主智能体从这些终端执行中需要获取的信息，通常只是一个关于发生了什么的简明摘要。例如，代表错误原因的一行代码，或者日志末尾的测试结果统计表，而不是整个Shell命令返回的完整原始输出。

动机案例：Serilog仓库的现实困境

为了清晰地展示这一问题，研究者提供了一个来自真实GitHub仓库（Serilog C# 仓库，Issue #2053）的对比案例。该任务要求智能体添加一个新的批处理API接口。由于这是一个全新功能，智能体必须构建解决方案、运行单元测试、识别失败原因并应用修复。

上半部分展示无子代理时主智能体被迫直接处理构建和测试日志；下半部分展示引入Execution Subagent后，原始终端输出被隔离在子代理上下文中，主智能体只接收压缩后的关键结论。

基线智能体表现（无子代理）

• 在没有子代理的情况下，主智能体直接将原始终端输出返回到自身的上下文中。
• 为了从详细的构建和测试日志中提取信息，主智能体不得不反复尝试使用 grep 和 tail 等命令过滤输出。
• 整个轨迹中，主智能体直接进行了18次终端调用。
• 最终结果：在40个交互轮次后，主智能体消耗了高达 246万（2.46M） 个Token。其中，终端输出占据了上下文的绝大部分比例。

引入执行子代理后的表现

• 主智能体将同样的任务委托给执行子代理（由研究者训练的Terminus-4B模型驱动）。
• 主智能体只需发出一个自然语言指令：“运行构建，然后运行单元和验收测试，并报告通过/失败计数以及错误细节”。
• 子代理在其内部上下文中执行了9个命令，吸收了所有冗长的原始输出。
• 子代理最终只返回一个约200个Token的结构化摘要，精确指出了测试失败的底层问题。
• 最终结果：整个轨迹的交互轮次缩减至32轮，主智能体仅消耗了 74万（740k） 个Token。由于子代理使用的是较小的Terminus-4B模型，其Token成本仅为前沿模型的一小部分。

核心设计：把终端执行外包

论文提出的解决方案是：不要让主Agent直接处理终端原始输出，而是把终端任务交给一个专门的执行子Agent。

这个子Agent叫Execution Subagent。它不是一个通用代码Agent，而是一个极窄任务Agent，只做一件事：

根据主Agent的请求运行终端命令，并把结果压缩成结构化摘要返回。

它有两个输入参数：

• Query：主Agent给它的自然语言任务描述，例如“运行测试套件，报告失败测试和错误信息”。
• Description：给用户界面显示的简短执行说明。

它返回的结果必须放在 <final_answer> 标签里，并按命令逐条总结：

这种设计的关键点是：主Agent只看到压缩后的有效信息，不看到完整日志。

没有子Agent时，主Agent的路径中充满终端输出；使用Execution Subagent后，终端输出被隔离在子Agent上下文里，主Agent只接收摘要。

论文在主智能体提示词中显式加入绿色高亮的委托规则，要求主Agent把构建、测试、依赖安装和错误诊断等终端执行任务交给Execution Subagent。

Execution Subagent的约束设计

Execution Subagent被刻意限制得很窄：

只有一个工具：Terminal

它不能读文件、不能改代码、不能搜索仓库，只能运行终端命令。Terminal工具接收：

• shell命令
• 执行模式
• timeout毫秒数

命令输出会被截断到60KB。

每轮只能调用一次Terminal

论文明确限制它不能并行工具调用。这样做的好处是：

• 行为可预测
• 轨迹更容易训练
• 日志更容易归因
• 不会在一个回合里并发跑多个混乱命令

默认最多10轮

如果子Agent到达轮次上限还没主动结束，系统会插入一条消息，要求它输出 <final_answer>。

必须输出结构化总结

系统提示词要求它最终只输出 <final_answer>，里面包含每个命令和结果摘要。这个prompt的核心：使用同步模式、显式timeout、每轮一个命令、自动确认提示、最后输出结构化摘要。

这个设计说明作者不是单纯“让小模型跑终端”，而是通过工具权限、轮次限制、输出格式、系统prompt共同塑造一个稳定的执行型子Agent。

为什么这个子Agent适合小模型？

这篇论文最有价值的判断是：终端执行不是开放式智能任务，而是一个边界清晰、格式稳定、可训练的小任务。

主Agent要做的是复杂任务，比如：理解issue、定位代码结构、规划修复方案、权衡架构影响、判断补丁是否合理。

而Execution Subagent只做：

• 生成命令
• 执行命令
• 读输出
• 判断成功/失败
• 提取关键错误
• 生成摘要

这类任务更像“工具执行+日志归纳”，不是完整的软件工程推理。因此，用Claude Opus或GPT-5.3-Codex来做这件事，在研究者看来是能力浪费。

论文的假设是：

如果任务足够窄，经过专门训练的小模型可以替代前沿大模型，承担Agent系统中的局部执行环节。

这也是Terminus-4B的定位：它不是要替代Claude Code式主Agent，而是要替代主Agent体系里的执行型子Agent模型。

模型铸造：Terminus-4B的两阶段后训练流程

为了替换子代理中的前沿大模型，研究者基于Qwen3-4B模型，专门针对代理终端执行任务进行了后训练（Post-Training），最终得到了Terminus-4B模型。训练分为两个关键阶段。

训练流程先把Execution Subagent接入主智能体框架，再用遥测专家轨迹进行SFT，最后通过GRPO强化学习和基于rubric的LLM裁判奖励进一步优化执行与摘要质量。

准备工作：高质量训练数据构建

研究团队从GitHub上收集了约3200个真实的执行任务，跨越TypeScript、C#、Java、JavaScript和Python5种编程语言，涵盖730个代码仓库。任务类型主要集中在测试执行（97.3%）、错误诊断（78.3%）和项目构建（35.0%）。训练数据覆盖TypeScript、C#、Java、JavaScript和Python五种语言，其中TypeScript、C#和Java占比最高。 他们使用前沿LLM作为主智能体并在这些代码仓库中运行，捕获主智能体调用子代理时的完整上下文（包括系统提示、用户查询、终端输出轨迹以及最终的摘要答案），从而构建了“黄金标准”的参考轨迹（Reference Trajectories）。任务类型以测试执行、错误诊断和构建/编译为主，说明该子代理训练目标高度聚焦于终端执行与日志归纳场景。

阶段1：监督微调 (Supervised Finetuning - SFT)

团队首先在基础模型（Qwen3-4B-Instruct-2507）上使用内部遥测数据中的专家轨迹进行 SFT。

• 目标：教会模型任务的基本机制，例如如何正确调用 Terminal 工具、如何阅读截断的输出日志、以及如何按照严格的 <final_answer> 格式编写最终摘要。
• 损失函数：应用标准的语言建模损失，并使用掩码技术（Loss Masking）。梯度仅在模型生成的内容（即工具调用和最终答案）上计算，系统提示词和工具的原始返回日志不参与梯度计算。

公式表达如下：

阶段2：基于 GRPO 的强化学习 (Reinforcement Learning)

SFT只能让模型“形似”，为了让模型“神似”（即输出真正高度准确、具备可行细节的摘要），研究团队引入了使用组相对策略优化（GRPO）的在线策略强化学习。

由于智能体任务的特殊性，强化学习rollout（轨迹展开）需要完整的端到端环境执行。这里团队提出了两个极具价值的创新：

第一：主副代理解耦的 Rollout 框架

如果每次强化学习 rollout 都要启动庞大的主智能体（前沿 LLM），成本将极其高昂且难以控制一致性。团队巧妙地将主副代理解耦：

• 他们使用一个被“阉割”的直通模型（Qwen3-4B Instruct-2507）作为虚假的主智能体。
• 该虚假主智能体被硬编码限定只有1个轮次，并且只能确定性地将之前收集好的 query 转发给执行子代理。
• 随后，所有复杂的执行轨迹完全由正在被训练的Terminus-4B策略模型展开。

这种方法彻底摆脱了对昂贵前沿LLM的依赖，实现了快速、廉价且起点高度一致的大规模并行 Rollout。

第二：基于执行计划 (Execution Plan) 的多维奖励机制

论文在后面的训练曲线中明确指出，如果不经过SFT直接做强化学习，模型的奖励得分会停滞在 ~20 分，且KL散度暴增；而基于SFT初始化的强化学习模型则能稳步攀升至 50+ 分以上，证明了两阶段训练缺一不可。

评估设置：基准与指标

为了全面验证Terminus-4B的实力，研究者设置了严谨的离线评估实验。

评估基准

• SWE-Bench Pro：这是一个多语言的软件工程基准测试，涵盖Python、JavaScript、TypeScript、Java和Go等多种语言，专门用于测试智能体解决长视距复杂问题的能力。研究者选取了其中的约731个实例进行测试。
• SWE-Bench C#：这是研究者内部构建的一个包含150个真实C# 仓库问题的基准。因为C# 极其依赖构建和测试运行，它是评估终端执行子代理的绝佳目标。

消融实验配置

研究者对比了五种不同的子代理配置：

1. 子代理（No Subagent）：作为基线，完全依靠主智能体自己调用终端。
2. 前沿模型（Opus/Sonnet）：代表子代理能力的最高上限。
3. Vanilla-4B：未经过特殊微调的基础Qwen3-4B模型。
4. SFT-4B：仅经历过第一阶段监督微调的模型。
5. Terminus-4B：经过完整两阶段训练的最终形态模型。

为了验证跨模型兼容性，研究者在测试中分别搭配了三种不同能力级别的主智能体：GPT-5.3-Codex、Claude Sonnet 4.6以及Claude Opus 4.6。

核心评估指标说明

研究者不仅关注任务是否解决，更深度关注智能体的内部行为模式转变。

• 解决率（Resolution Rate）：成功通过基准测试的代码实例比例。
• Token使用量：主智能体和子代理分别消耗的平均Token数。
• 主智能体终端调用数（Main Agent Terminal Calls）：主智能体绕过子代理，直接运行命令的平均次数。
• “不信任”信号（Subagent -> Terminal）：指主智能体在调用子代理后，紧接着自己立刻去调用一次终端命令的频率。这种现象通常意味着子代理返回的结果毫无用处，主智能体不得不自己重新执行一遍任务。

深入分析：数据揭示的卓越性能

各项实验结果一致表明，Terminus-4B在执行特定任务时，完全具备替换庞大前沿模型的能力。

RL训练的必要性论证

在训练曲线的监控中，研究者观察到了SFT阶段的决定性作用。

• 如果直接在基础模型上运行GRPO强化学习（跳过SFT），模型的平均奖励得分会陷入停滞（大约在20分左右无法提升）。更糟糕的是，KL散度迅速飙升至0.2以上，说明模型在没有学到任何有意义行为的情况下，其内部策略发生了灾难性的偏离。图从SFT检查点开始训练时，奖励曲线从约37分持续上升到50分以上；直接从基础模型做GRPO则基本停滞在20分附近。
• 相反，如果从SFT检查点开始强化学习，初始奖励得分就能达到约37分，并稳步攀升至50分以上，同时KL散度稳定保持在0.05以内。这证明SFT为模型打下了关于任务输出格式的必要先验基础。SFT初始化让策略保持稳定，KL散度维持在较低水平；跳过SFT时，KL快速上升，显示模型策略发生明显漂移。

跨语言泛化能力：SWE-Bench Pro的实测

在以Claude Opus 4.6为主智能体的SWE-Bench Pro测试中，Terminus-4B展现出了优异的多语言泛化能力。在跨语言SWE-Bench Pro中，Terminus-4B基本维持解决率，同时显著减少主智能体Token消耗和直接终端调用次数。

• 问题解决率无损：在应用子代理架构后，整体解决率（31.5%）相比基线（30.0%）保持稳定，证明引入小模型并未拖累智能体的整体智商。
• 实现大规模降本：Terminus-4B帮助主智能体节省了约13% 的Token消耗（相当于每个实例节省11万个Token），这甚至比使用Opus作为子代理时节省得还要多。
• 行为模式的根本性转变：主智能体亲自下场调用终端的次数，从无子代理基线平均每个实例 3.8次，暴降至Terminus-4B的 1.0次（降幅高达73.7%）。
• 建立代理信任：在未经过专门训练的Vanilla-4B配置下，高达27% 的子代理调用触发了前文提到的“不信任信号”（主智能体被迫返工）。而Terminus-4B将这一比例大幅压低至14%。

跨主模型泛化能力：SWE-Bench C# 的实测

研究者进一步在C# 基准上，测试了Terminus-4B配合不同主智能体时的普适性。

• 数据显示，能力越强的主模型越依赖子代理。例如，Claude Opus会在超过90%的测试实例中主动选择调用子代理，而Sonnet的调用比例约为72-75%。不同主模型下，Terminus-4B都能保持接近基线的解决率；能力更强的主模型通常更频繁地调用Execution Subagent。

不同主模型下，Terminus-4B都能保持接近基线的解决率；能力更强的主模型通常更频繁地调用Execution Subagent。

• 当与Opus或GPT-5.3-Codex结合使用时，Terminus-4B实现了最大的前沿LLM Token缩减幅度。

Terminus-4B在Opus和GPT-5.3-Codex主智能体下带来最大的前沿LLM Token下降，并持续压低主智能体直接调用终端的次数。

• 无论主智能体使用的是Claude还是GPT系列，Terminus-4B都稳定地使主智能体的直接终端调用量锐减了62%至79%。这表明强化学习带来的质量提升是稳健的，不依赖于特定主模型的偏好。

极限剥夺测试：移除主智能体的终端控制权

为了纯粹地比较不同子代理模型的质量，研究者进行了一项终极消融实验：直接没收主智能体的基础终端工具。这意味着主智能体如果想运行任何命令，唯一且必须的途径就是通过子代理。

当所有终端执行都必须经过子代理时，Terminus-4B的Subagent->Subagent重复调用率与Opus持平，显示其摘要质量已经足以让主智能体继续推进。

在这里，研究者引入了一个新的复读机指标：Subagent -> Subagent（即主智能体连续重复调用子代理的频率）。

• 致命弱点暴露：在失去自我修复手段后，未微调的Vanilla-4B导致Token使用量急剧膨胀（相比基准高出9.5%）。其复读机指标高达1.51，意味着主智能体平均在每个实例中要无奈地重复要求子代理干活1.5次以上（比Opus架构高出约70%）。更深层的原因是Vanilla-4B返回的轨迹太短（仅18k Token），主智能体认为其中缺乏继续推进任务所需的关键细节。
• Terminus-4B媲美最强模型：经过强化学习后的Terminus-4B将这一重复调用率降至 0.89，这个成绩与代表最高水平的Claude Opus作为子代理时的表现 完全相同。这强烈印证了RL阶段的作用，它成功教会了小模型如何在首次尝试时就提供让主智能体满意的完美响应。

LLM裁判的客观审视

除了客观指标，研究者还请来了大模型“评委（Claude Opus-4.6）”，让它站在主智能体的视角对子代理的输出文本进行评分。

• 裁判会阅读从任务开始到子代理返回结果，以及后续5个轮次的所有完整轨迹信息。
• 评分涵盖5个具体维度：任务完成度、事实准确性（是否存在幻觉）、信息量充足度、任务相关性和行动指导性（Actionability）。
• 评分结果直观展示：Terminus-4B获得的综合得分已经逼近当前表现最好的Sonnet模型，并且部分指标甚至略微优于Opus模型。这与前文提到的低重复调用率结果形成了完美的数据闭环。

从主智能体视角出发，Terminus-4B的回答质量评分已经接近Sonnet，并略优于Opus，这与其较低的重复调用率相互印证。

局限

尽管研究结果极具说服力，研究者也客观地指出了当前工作面临的三个主要局限性：

1. 平台与Shell环境的覆盖度偏差：目前的训练数据和基准评估极度偏向于Unix/Bash环境。真实开发场景中大量存在的Windows PowerShell或Mac Zsh等环境尚未纳入测试版图，这构成了未来的一个核心扩展方向。
2. 沙盒评估环境的局限：目前的测试大多在预先配置好依赖的Docker沙盒中运行（这是SWE-Bench系列的常见做法）。现实世界中的基础设施建设和部署排错可能更加混乱且充满非标准流程。
3. 基座模型体量的单一性：这项工作只探讨了40亿（4B）参数级别的模型。虽然结果证明该量级足以胜任，但研究团队尚未使用如8B或30B级别的模型去验证相同训练配方在不同规模和家族架构下的转移效能。

结语

通过这篇深度论文，我们见证了一种实用且高效的新型AI工程架构设计思想。《Terminus-4B》向我们明确展示了：通过两阶段后训练流水线，即使是参数量只有4B的小语言模型，在高度受限的特定细分任务（如终端执行和日志归纳）上，也能够匹敌甚至超越那些极其昂贵的前沿语言模型。这项工作更深远的意义在于：它证实了将复杂任务解耦为更小的子任务，并分配给不同能力级别的专业化模型来协同处理，是一条极具性价比和扩展性的道路。未来，随着更多种类的子代理被开发出来，我们必将迎来计算成本更低、解决能力更加卓越的下一代编程智能体生态。

文章来自于"AI修猫Prompt"，作者 "AI修猫Prompt"。