agent-">专用小模型与前沿大模型：代码Agent执行子任务的选型对比

一、对比背景：为什么“执行类子任务”值得单独讨论

在代码Agent的典型工作流中，任务往往被拆成两类截然不同的环节：

• 规划与推理环节：理解需求、拆解任务、生成补丁思路、决定下一步动作；
• 执行与反馈环节：在终端里执行命令、跑测试、读取报错、解析日志、汇总结果。

过去，很多实现会用同一个前沿通用大模型（以下简称“前沿LLM”）包办所有环节。这样做的直接后果是：执行环节消耗了大量高价值Token，而这类任务本身往往并不需要顶级的复杂推理能力——它更需要的是稳定的指令遵循、对终端输出的准确解析、对错误的快速归纳，以及对结构化格式的可靠输出。

因此，一个自然的工程问题出现了：能否用专用小模型（以下简称“专用SLM”）来承担执行子Agent角色，从而在不降低整体解题成功率的前提下，降低主Agent的Token开销？

本文对比的对象正是这两类方案：

• 方案A：前沿LLM作为执行子Agent——由通用大模型统一承担规划与执行；
• 方案B：专用SLM作为执行子Agent——规划交给主Agent，执行交给专门训练的小模型。

需要说明的是，本文讨论的是架构范式与选型逻辑，不针对任何具体厂商或产品系列。

二、对象定义：两类方案分别解决什么问题

方案A：前沿LLM作为执行子Agent

由一个能力全面的通用大模型同时负责推理与执行。其优势是“一个模型打通全流程”，无需额外的模型调度与角色分工；缺点是执行环节的边际成本较高，且在长会话、多轮工具调用场景中Token累积明显。

方案B：专用SLM作为执行子Agent

将执行环节独立出来，交给经过专项训练的小参数模型。主Agent只负责高层规划与决策，执行子Agent负责：

• 生成并执行终端命令；
• 运行测试并读取输出；
• 解析报错信息；
• 汇总日志并返回结构化摘要。

这种“主从分工”本质上是一种能力分层：把昂贵推理留给规划，把高频、模式化的执行交给低成本模型。

三、相同点分析

尽管两类方案在成本与实现上差异明显，它们在目标层面高度一致：

1. 都服务于同一个代码Agent目标：提升解题成功率、减少人工干预；
2. 都需要具备工具调用能力：能生成命令、读取返回、决定下一步；
3. 都依赖上下文管理：需要处理历史命令、报错、日志等长上下文；
4. 都要保证输出可解析：执行结果通常需要结构化，便于主Agent消费；
5. 都面临稳定性与安全边界问题：如命令误执行、权限越界、输出截断等。

换言之，两者不是“能做什么”的差异，而是“由谁来做、以什么代价做”的差异。

四、核心差异分析

1. 技术架构与角色分工

• 方案A：单模型单角色，规划与执行耦合在同一上下文；
• 方案B：主Agent + 执行子Agent的双层结构，职责分离，上下文可隔离。

职责分离带来的直接好处是：执行子Agent的上下文可以独立裁剪，不必把全部规划历史带入执行环节，从而减少无效Token。

2. 功能能力与使用限制

• 方案A：通用能力强，面对未见过的新型报错、复杂日志关联时更从容；
• 方案B：在训练覆盖的任务分布内表现稳定，但遇到高度陌生的错误模式时，泛化能力可能弱于前沿LLM。

这意味着方案B更适合任务模式相对固定的执行场景。

3. 成本结构

• 方案A：执行环节消耗高价值Token，成本随轮次线性上升；
• 方案B：执行环节使用低成本小模型，主Agent的Token消耗可显著下降。

在公开研究中，这类分层方案在保持解题成功率的前提下，可将主Agent的Token使用量降低约三成，这正是其核心工程价值。

4. 性能与延迟

小参数模型通常在单位推理延迟上更具优势，尤其在需要频繁、短小的执行调用时，响应更轻快；而前沿LLM在单次复杂判断上更强，但单次调用开销更高。实际表现取决于部署方式（本地推理还是托管推理）与批处理策略。

5. 运维与扩展

• 方案A：运维对象单一，升级模型即整体升级；
• 方案B：需要管理两个模型的版本、路由与回退逻辑，运维复杂度上升，但扩展性更好——可以独立替换执行模型而不影响规划逻辑。

6. 安全与合规

两类方案都需要关注：命令白名单、沙箱隔离、权限最小化、输出审计。方案B由于执行模型能力有限，反而更容易通过受限动作空间来约束行为；但同时也需要防止其在边界情况下产生误判。

五、对比表格

对比维度	方案A：前沿LLM执行	方案B：专用SLM执行
角色分工	单模型统一承担	主Agent规划 + 执行子Agent
推理能力	强，泛化好	集中在执行类任务
Token成本	高	执行环节显著降低
延迟	单次较高	通常更轻量
运维复杂度	低	中，需要路由与回退
扩展性	受限于单模型	可独立替换执行层
适用任务	复杂、未知场景	模式化、高频执行
主要风险	成本累积	泛化不足、边界误判

六、典型场景选择

• 探索型任务：如排查从未见过的构建错误、跨系统疑难问题，方案A更稳妥；
• 高频执行型任务：如反复跑测试、读日志、汇总结果，方案B收益明显；
• 成本敏感型团队：调用量大、Token预算有限时，方案B的分层架构更具吸引力；
• 强合规场景：需要严格限制执行动作空间时，方案B的受限子Agent更易管控。

七、选型建议

1. 先分层，再选型：把任务拆成规划与执行两类，分别评估；
2. 用指标说话：关注解题成功率、Token消耗、端到端延迟、失败回退率；
3. 保留回退通道：当执行子Agent置信度低时，自动升级到前沿LLM；
4. 不要一刀切：混合架构往往比纯A或纯B更实际。

示意性路由伪代码：

if task.type == "planning":
    result = frontier_model(context)
else if task.type == "execution" and confidence > threshold:
    result = small_model(context)
else:
    result = frontier_model(context)  # 回退

八、迁移与使用注意事项

• 接口适配：执行子Agent的输出格式需与主Agent约定一致；
• 上下文隔离：避免把规划全量历史灌入执行模型；
• 权限与沙箱：执行层必须限制可运行命令范围；
• 监控与审计：记录每次执行调用与结果，便于回溯；
• 版本管理：执行模型升级需回归测试，防止成功率波动。

九、总结

前沿LLM与专用SLM在执行子任务上的对比，本质是通用能力与专用效率之间的权衡。方案A胜在泛化与简单，方案B胜在成本与可扩展。对于大多数代码Agent而言，更务实的路径是：规划用强模型，执行用专用小模型，并保留回退机制。这样既能守住解题成功率，又能把Token花在真正需要推理的地方。