编码智能体中的模型选择与执行深度

在使用编码智能体完成开发任务时，常见的调参方式可以概括为两个维度：选择什么模型 ，以及让模型投入多少执行深度。这两个设置看起来都在影响"智能体是否更强"，但它们实际控制的是不同层面的能力。

模型选择主要决定系统能够理解和解决问题的上限；执行深度主要决定系统在一次任务中会投入多少操作、验证和迭代。区分这两个维度，有助于在质量、速度和成本之间做出更稳定的取舍。

一、两个控制维度

1. 模型：决定能力边界

模型可以理解为智能体的基础能力配置。不同模型拥有不同的知识容量、推理能力、代码理解能力、上下文处理能力和工具使用稳定性。更强的模型通常更擅长处理以下任务：

大规模代码库中的跨文件理解。
抽象程度较高的架构设计。
复杂重构和迁移。
需要从不完整信息中推断意图的任务。
涉及多个约束、多个系统边界或多个质量目标的问题。
需要在较少来回沟通中形成完整方案的工作。

切换模型本质上是切换到另一套能力基础。它不只是让同一个系统"更努力"，而是改变系统可达到的理解和解决问题的范围。模型越强，单个 token 或单次调用的成本通常越高，但在复杂任务中，它也可能用更少轮次完成工作。

2. 执行深度：决定投入程度

执行深度可以理解为智能体在一轮任务中愿意投入多少实际工作。它通常影响以下行为：

会读多少相关文件。
会不会主动搜索上下文。
会不会提出并比较多个实现路径。
会不会运行测试、类型检查或构建命令。
会不会在修改后重新验证。
会不会处理边缘情况。
会不会在遇到困难时继续尝试，而不是较早返回给用户。
会在多大程度上记录、解释或复盘自己的工作。

提高执行深度并不会改变模型本身的知识和推理上限，但会让智能体更愿意消耗时间和 token 去探索、执行、检查和修正。它更像是在同一个能力基础上增加工作量、耐心和验证强度。

二、如何判断该调模型还是调执行深度

在实际使用中，最重要的问题不是"哪个设置更强"，而是识别当前失败属于哪一类。

1. 需要更强模型的情况

如果智能体已经获得了必要上下文，也进行了认真尝试，但仍然无法提出正确方案、理解关键约束或完成任务，那么问题更可能出在能力边界上。这时应优先考虑使用更强模型。

典型信号包括：

已经读过相关代码，但仍然误解核心架构。
能看到错误信息，却无法建立正确因果关系。
对跨模块影响判断不稳定。
提出的方案在概念上不成立。
对领域约束理解不足。
多次尝试后仍停留在表层修补。
需要人类反复解释同一类抽象问题。

这类情况通常不是"再多跑几步"就能解决的。提高执行深度可能只会让系统在错误方向上消耗更多资源。更合适的做法是提高模型能力，或者先把任务拆得更小、提供更明确的上下文和验收标准。

2. 需要更高执行深度的情况

如果智能体具备解决问题的能力，但没有投入足够行动，就更适合提高执行深度。

典型信号包括：

没有读完必要文件就开始修改。
没有运行测试或构建。
只改了局部，没有检查调用方。
做了实现但没有验证行为。
遇到格式、依赖或环境问题时过早放弃。
没有检查相邻模块的约定。
只给出计划，没有推进到可运行状态。
只解决显性错误，没有处理明显的边缘情况。

这类问题不是模型"不懂"，而是执行投入不够。提高执行深度通常可以让它更积极地读代码、使用工具、运行验证、迭代修复，并把任务推进到更完整的状态。

三、三类模型角色

在编码任务中，可以把常见模型分成三类角色来理解：通用型、专家型和专门型。这不是严格等级划分，而是用于选择工具时的工作模型。

1. 通用型模型

通用型模型适合大多数日常开发任务。它在速度、成本和能力之间比较均衡，适合处理：

小到中等规模 bug 修复。
常规功能开发。
代码解释。
简单重构。
测试补充。
文档更新。
常规脚手架和配置任务。

如果任务边界清楚、上下文规模不大、失败成本可控，通用型模型通常是默认选择。

2. 专家型模型

专家型模型适合更复杂、更模糊或更高风险的工作。它通常在深度推理、跨文件理解和长期任务保持方面更强，适合处理：

复杂架构修改。
大型代码库迁移。
多服务或多包协同变更。
性能、安全或可靠性问题分析。
高风险重构。
需要精细权衡的技术决策。
需要减少人工往返次数的任务。

专家型模型的单次成本更高，但在复杂问题中可能减少返工、减少错误尝试，并降低总体交互成本。

3. 专门型模型

专门型模型可以理解为针对某些工作流优化过的模型。它可能在特定任务上表现非常强，例如复杂项目执行、长程代码修改、工具使用、持续迭代或大型上下文中的工程操作。

它适合用于：

需要较强端到端执行能力的任务。
普通模型在任何执行深度下都难以完成的工作。
需要从探索、实现、验证到总结一体化推进的复杂任务。
对可靠性和完成度要求很高的工程任务。

专门型模型不一定适合所有任务。对于简单修改，它可能成本过高；对于高度开放的产品策略问题，也未必比专家型通用模型更合适。它的价值主要体现在特定工程场景中的完成能力。

四、执行深度不是"思考时间"的简单开关

执行深度常被误解为"让模型多想一会儿"。更准确地说，它会影响智能体在一次任务中的整体行为策略。

较低执行深度通常意味着：

更快返回。
更少工具调用。
更少主动探索。
更少验证步骤。
更适合简单、明确、低风险任务。

较高执行深度通常意味着：

更愿意探索代码库。
更愿意运行测试和检查命令。
更愿意处理失败后的修复。
更可能完成多步骤任务。
更适合复杂、模糊或高风险任务。

因此，执行深度既影响结果质量，也影响耗时和 token 消耗。它不是免费的质量提升，应根据任务风险和复杂度选择。

五、成本并不总是"小模型更便宜"

直觉上，小模型和低执行深度看起来成本最低。但在真实开发任务中，总成本取决于单价、轮次、返工和人工介入成本。

简单任务通常适合低成本组合。比如改一个文案、补一个小测试、调整一个样式，使用通用模型和较低执行深度往往更划算。

复杂任务则不同。如果模型能力不足，它可能需要多轮解释、多次失败尝试和大量人工纠偏。此时虽然单次调用便宜，但整体成本可能更高。更强模型或更高执行深度可能一次性完成更多工作，从而降低总成本。

可以用以下方式理解：

简单任务：低能力配置也能完成，重点是速度和成本。
中等任务：通用模型加适中执行深度通常足够。
复杂任务：更强模型可能减少返工。
高风险任务：更高执行深度可以增加验证覆盖。
模糊任务：需要先提高上下文质量，再决定是否提高模型或执行深度。

成本优化的目标不是永远选择最便宜的设置，而是选择能以最低总成本达到可接受质量的设置。

六、质量风险与验证强度

编码智能体的输出质量不仅取决于模型回答是否看起来合理，还取决于它是否经过足够验证。执行深度越高，越可能覆盖更多验证步骤，但仍然需要明确任务的完成标准。

常见验证方式包括：

运行单元测试。
运行类型检查。
运行 lint。
运行构建。
打开或执行关键路径。
检查错误日志。
比较变更前后的行为。
阅读调用方和被调用方。
增加或更新测试用例。
总结剩余风险。

如果任务影响生产路径、支付、权限、安全、数据迁移或用户关键体验，应主动提高验证强度。此时执行深度比单纯生成代码更重要，因为主要风险来自未验证的假设。

七、常见任务的推荐组合

任务类型	推荐模型角色	推荐执行深度	原因
改文案、改注释、轻量格式调整	通用型	低	任务边界明确，风险低
小 bug 修复	通用型	中	需要读相关代码并做基本验证
添加常规功能	通用型或专家型	中	取决于上下文规模和影响范围
跨模块重构	专家型	高	需要理解依赖关系和验证影响
大型迁移	专家型或专门型	高	需要长程执行、规划和多轮检查
架构方案设计	专家型	中到高	重点是推理质量和权衡能力
生产事故分析	专家型	高	需要证据链、日志和复现验证
安全、权限、支付相关修改	专家型或专门型	高	失败成本高，验证要求强
探索陌生代码库	专家型	中	需要快速建立系统地图
端到端复杂任务	专门型	高	需要从探索到验证持续推进

这张表不是固定规则。实际选择还要考虑代码库规模、测试质量、任务紧急程度、失败成本和用户是否能及时参与。

八、选择流程

可以用一个简单流程来选择配置：

先判断任务复杂度。

如果任务很小、边界明确、失败成本低，使用通用模型和较低执行深度。
判断是否需要跨文件或跨系统理解。

如果需要理解多个模块、历史约定或架构约束，优先提高模型能力。
判断是否需要强验证。

如果改动影响关键路径、测试覆盖不足或失败成本高，提高执行深度。
观察失败模式。

如果智能体没有认真找上下文、没有运行验证、过早停止，提高执行深度。

如果智能体已经认真尝试但仍理解错误，提高模型能力。
重新评估总成本。

如果低成本配置导致多轮返工，切换到更强配置可能更便宜。

九、提示词中的配套做法

模型和执行深度只是基础设置。要让智能体稳定工作，还需要在任务描述中补充清晰约束。

有效提示通常包括：

目标：要完成什么。
范围：哪些文件、模块或行为需要处理。
非目标：哪些内容不要改。
验收标准：怎样才算完成。
验证方式：需要运行哪些命令或检查哪些路径。
风险偏好：遇到不确定性时是继续尝试还是先询问。
输出要求：需要代码、说明、测试、提交信息还是总结。

例如，对于高风险修改，可以明确要求：

text 复制代码

请先阅读相关调用链并列出实现计划。
修改后运行现有测试和类型检查。
如果测试失败，先判断是否由本次改动引起，再修复。
最后总结改动、验证结果和剩余风险。

对于小任务，可以保持简短：

text 复制代码

只修改这个按钮的文案，不要调整样式或其他行为。
完成后说明改了哪个文件。

提示词越能明确目标和边界，越容易让较低成本配置完成任务；提示词越模糊，越需要更强模型或更高执行深度来弥补。

十、实践建议

可以把模型和执行深度当作两个独立旋钮：

当问题是"它不理解"时，优先提高模型能力。
当问题是"它没做够"时，优先提高执行深度。
当问题是"它不知道要做什么"时，优先改进任务描述。
当问题是"它做了但没验证"时，优先提高执行深度并明确验证命令。
当问题是"它多次验证仍找不到正确路径"时，优先提高模型能力或拆分任务。

最稳妥的工作方式不是每次都使用最高配置，而是根据任务的复杂度、风险和失败模式动态调整。简单任务使用轻量配置，复杂任务提高模型能力，高风险任务提高验证深度，长期任务则需要同时关注上下文管理、执行策略和成本边界。

十一、一个简洁判断公式

可以用下面的公式快速判断：

text 复制代码

任务结果 = 模型能力 × 上下文质量 × 执行深度 × 验证强度

四个因素中任意一个太弱，都可能导致结果不可靠。模型能力决定能否理解，上下文质量决定是否知道问题全貌，执行深度决定是否愿意把事情做完，验证强度决定结果是否可信。

在编码智能体的使用中，真正有效的配置选择不是追求单一最高项，而是让这四个因素和任务风险相匹配。