简介：智能体运行效果不仅取决于底层模型，还受提示词、工具编排、护栏和经验策略等运行外壳影响。本文对比固定式运行外壳与递归式自改进方案在架构、成本、稳定性、扩展性和适用场景上的差异，帮助开发者理解为什么模型不换也能提升任务表现，以及如何在不同工程阶段选择更合适的智能体优化路径。
做智能体开发的工程师大多有过类似体验：同一个底层模型，只调整系统提示词、工具调用方式或记忆策略，任务完成质量就可能出现明显波动。模型权重没有变化，但最终效果却大不相同。这说明影响智能体能力的因素，远不止模型本身。
当模型在特定任务上表现不理想时，很多团队的第一反应是升级到更大规模的模型。这条路径虽然直观，但成本高、周期长，且未必能解决所有问题。尤其在任务结构复杂、上下文预算紧张或工具返回结果不稳定的场景下，换模型带来的提升可能被运行外壳的短板抵消。
因此，一个值得深入讨论的问题浮现出来：如果不换底层模型，只优化模型之外的运行外壳，能否获得稳定且可量化的能力提升？这就引出了两种典型的技术路线对比——固定式运行外壳与递归式自改进运行外壳。
运行外壳在智能体语境中，指模型之外让模型真正成为“智能体”的整套运行系统。它通常包括：
固定式运行外壳的特点在于：这套规则由开发者在设计阶段预先定义，在任务执行过程中保持相对静态。即使具备一定的条件分支能力，其调整范围也局限于设计者事先预料到的场景。
递归式自改进运行外壳的核心思路是：在测试或执行阶段，根据智能体的实际运行表现动态调整外壳配置。具体来说，系统会在任务执行过程中收集反馈信号，识别提示词、工具指引、护栏策略或经验库中的薄弱环节，然后自动生成改进方案并应用到后续执行中。
这种方案的关键在于“递归”二字——改进不是一次性的，而是多轮循环。每一轮优化都基于上一轮的执行结果，逐步收敛性能差距。即使面对设计者没有预料过的新任务，系统也有机会通过反馈机制找到更合适的运行配置。
两种方案在目标层面存在一致性：
都承认运行外壳对智能体能力的关键影响。 无论是固定式还是递归式，都认同一个基本判断：模型负责“想”，外壳负责“怎么想、怎么做、做错了怎么纠正”。同一模型套上不同外壳，在代码生成、数据分析、表格处理等任务上表现可能差异显著。
都依赖反馈信号驱动优化。 固定式外壳在开发阶段也依赖测试反馈来调整提示词和工具规则，只是这种反馈循环发生在部署之前。递归式方案则把反馈循环延伸到运行阶段。
都面临上下文预算约束。 系统提示词会在每一轮工具调用和推理中被重复送入上下文，因此两者都需要控制提示词长度，避免挤占观察工具返回和规划下一步所需的空间。
都需要解决“建议”与“强制”之间的平衡问题。 规则写得过软，模型可能不遵守；规则写得过硬，又可能限制模型在复杂场景中的灵活性。
固定式外壳采用设计期集中配置的架构。开发者根据经验、测试和文档编写提示词与规则，部署后基本不再变更。优点是可预测性强、调试链路短；缺点是面对分布外任务时缺乏自适应能力。
递归式外壳采用运行期动态调整的架构。系统在每次任务执行后生成评估结果，识别外壳配置中的不足，并自动生成改进补丁。这个补丁不是简单地在提示词末尾追加文本，而是经过结构化处理后注入到对应组件中。架构上需要额外引入评估器、改进生成器和配置管理模块。
固定式外壳的 Token 成本相对可控。开发者在设计阶段可以精确计算系统提示词占用的上下文长度，并在测试中验证其对任务执行的影响。
递归式外壳的 Token 成本呈动态变化。简单地把踩过的坑直接追加到系统提示词中，会导致成本膨胀：每新增一条约束，意味着每一轮推理都为其付费。提示词越堆越多，留给工具返回观察和后续规划的空间被挤占，任务可能做到一半就被截断。因此递归式方案必须采用结构化策略来管理提示词增长，例如将部分规则转移到外部知识库，或通过触发条件来按需加载。
固定式外壳在稳定性上具有优势。规则在设计阶段经过多轮验证，行为可预测，便于审计和回滚。对于合规要求严格的场景，每一次规则变更都可以纳入版本管理流程。
递归式外壳的稳定性挑战更大。自动生成的改进规则可能存在冲突、冗余或过拟合风险。如果改进模块的判断逻辑不够健壮，可能把偶发失败误判为系统性缺陷，从而引入噪声规则。因此通常需要额外的校验机制，例如在应用改进前执行回归测试，或设置改进幅度上限。
固定式外壳的适应性受限于设计者的预期范围。当任务类型、数据结构或用户输入模式发生系统性变化时，原先调好的提示词可能失效，需要人工介入重新配置。
递归式外壳在适应性上更具弹性。面对未见过的任务形态，系统可以通过多轮反馈逐步调整策略。但需要注意，这种适应性并非无限——如果底层模型本身缺乏处理某类任务的基础能力，单纯优化外壳无法突破模型的能力上限。
固定式外壳的工程实现相对简单。核心工作集中在系统提示词设计、工具接口定义和基础错误处理上，适合快速搭建原型。
递归式外壳需要额外的评估与改进基础设施。至少包括：任务执行结果的自动评估模块、外壳配置的结构化表示、改进规则生成与冲突检测模块、改进效果的回归验证流程。这些组件本身也需要维护和调试，增加了整体系统的复杂度。
| 对比维度 | 固定式运行外壳 | 递归式自改进运行外壳 |
|---|---|---|
| 配置时机 | 设计期集中配置 | 运行期动态调整 |
| 适应性 | 仅覆盖预设场景 | 可应对部分未见过的任务 |
| Token 成本 | 可预测、相对固定 | 动态变化，需结构化管控 |
| 稳定性 | 较高，行为可审计 | 依赖回归验证与约束机制 |
| 工程复杂度 | 较低，适合快速搭建 | 较高，需评估与改进基础设施 |
| 调试链路 | 短，问题定位直接 | 长，需追踪改进决策来源 |
| 升级成本 | 每次调整需人工介入 | 改进自动生成，但需人工审核 |
| 适用阶段 | 原型验证、固定流程任务 | 长期运行、任务形态多变场景 |
选择固定式还是递归式方案，不能脱离具体工程条件。以下几个判断维度可供参考：
团队工程能力。 递归式方案对基础设施要求更高。如果团队已经具备完善的日志采集、指标监控和自动化测试能力，引入递归改进模块的边际成本较低。反之，如果基础监控都尚未建立，应先补足固定式外壳的观测能力。
任务变化频率。 任务类型越稳定，固定式方案的优势越突出；任务变化越频繁，递归式方案的长期收益越大。
上下文预算敏感度。 对上下文窗口紧张的场景，递归式方案需要更谨慎地设计提示词管理策略。如果无法有效控制 Token 膨胀，固定式外壳反而更安全。
可接受的风险边界。 递归式改进引入了一定程度的不可预测性。对稳定性要求极高的生产系统，可以采用混合策略：核心流程使用固定式外壳，非核心的探索性任务启用递归改进，并设置人工审核关卡。
如果从固定式外壳切换到递归式方案，需要关注以下几点：
结构化配置表示。 递归改进要求外壳配置能够被程序化读取和修改。提示词、工具规则、护栏策略不应以纯文本形式散落各处，而应拆分为结构化字段，这有助于改进模块精准定位需要调整的部分。
回归验证机制。 每次自动生成的改进规则在正式启用前，应在历史任务集上执行回归测试。验证指标可以是任务完成率、输出质量评分或特定业务的准确率。只有验证通过的改进才被纳入正式配置。
改进幅度控制。 设置单轮改进的变更上限，例如限制每次修改的系统提示词条目数或字符数。这可以避免一次引入过多变化导致效果难以归因。
人工审核留痕。 对于关键业务场景，即使实现了自动改进，也应保留人工审核环节。每次改进的内容、触发原因、验证结果和审核状态都应完整记录，形成可追溯的演化历史。
回滚机制。 递归式方案必须具备快速回滚能力。当某轮改进导致整体性能下降时，应能一键恢复到上一个稳定版本，并隔离出问题规则以供分析。
智能体的能力边界并非完全由底层模型决定。运行外壳的质量直接影响任务执行的稳定性与效果。固定式外壳以可预测性和低复杂度见长，适合任务稳定、资源有限的场景；递归式自改进外壳以自适应能力和长期收益见长，适合任务多变、运行周期长的场景。
两者的核心差异不在于模型的强弱，而在于改进机制发生的位置：一个在设计期，一个在运行期。前者的代价是适应性受限，后者的代价是工程复杂度与稳定性风险上升。理解这一本质区别，才能结合自身业务特征做出合理的技术选型。