简介：本文围绕智能体执行稳定性问题，对比传统固定式提示词调优与递归式外壳调优两种思路。文章会先说明二者解决什么问题、为什么模型相同但表现差异很大，再从架构、成本、扩展性、适用场景等维度展开分析，并给出选型建议。读完可以更清楚地判断：在模型不变的前提下，应该继续堆提示词，还是引入可自动调整的运行外壳。
做智能体开发的工程师经常遇到一种情况：底层大模型没有更换，只是调整了系统提示词、工具编排或记忆策略，同一个任务的完成质量就会发生明显变化。模型能力并没有波动，变化来自模型之外的“运行外壳”。
这个现象说明，决定智能体真实水平的并不只是模型权重本身，还包括模型如何接收任务、如何调用工具、如何读取历史信息、如何在失败后纠正自己。很多团队在模型表现不理想时，第一反应是切换更大规模的模型。但模型升级往往意味着更高的调用成本、更长的响应时间和更大的工程适配量，并不总是短期内最经济的选择。
因此，一个更值得讨论的问题是：如果暂时不更换模型，能否通过优化模型之外的运行系统来提升智能体表现？在这个问题上，目前主要有两类做法。一类是传统的人工提示词调优，由开发者根据测试结果不断修改系统提示词和规则；另一类是递归式外壳调优，让智能体在执行任务时根据实际反馈自动调整提示词、护栏、工具指引和经验库。
本文将围绕这两类思路进行对比，重点分析它们在架构、成本、扩展能力和适用场景上的区别。
传统提示词调优通常由开发者手动完成。开发者根据智能体在测试任务中的失败表现，补充新的提示规则、限制条件或工具说明。例如，当智能体在表格任务中没有正确识别表头位置时，开发者会在系统提示中加入“先读取前五行，再判断表头所在行”的规则。
这种方式的优点是简单直接，不需要引入额外系统。开发者在调试阶段就可以快速验证规则是否有效。缺点也很明显：规则依赖人工经验，只能覆盖设计者已经遇到过的场景。任务结构一旦变化，原本有效的规则可能失效。
递归式外壳调优的核心思路是：把智能体运行所需的系统提示词、工具调用说明、任务拆分方式、校验规则和经验记录看作一个可调整的“外壳”。这个外壳不参与模型训练，而是在运行过程中根据任务反馈进行动态更新。
这种方式的典型流程是：智能体先使用当前外壳执行任务，系统记录执行轨迹和结果，再根据失败原因或低效环节调整外壳内容，形成新的运行配置。新配置继续用于下一轮任务执行，如此循环。
与传统提示词调优相比，递归式外壳调优更强调自动化与闭环。它不依赖开发者逐条修改提示词，而是由系统根据反馈生成改进方案。
两种思路的目标高度一致：在不修改底层模型权重的前提下，提升智能体在具体任务上的稳定性与成功率。
它们的基础依赖也相同，都认为模型之外的运行配置会显著影响最终表现。无论是人工修改提示词，还是系统自动调整外壳，调整对象都集中在系统提示、工具说明、记忆策略和护栏规则上。
此外，两种思路都承认同一模型在不同任务上可能需要不同配置。没有一套固定提示词能够通吃所有场景，这是二者共同的前提判断。
传统提示词调优依赖开发者根据测试结果手工修改文案。每次调整都需要人工分析失败原因，再判断应该增加哪些规则。这个过程在任务种类较少时可控，但当任务组合增多、交互步骤变长时，人工分析的成本会快速上升。
递归式外壳调优则将调整过程交给系统。系统可以基于执行轨迹自动判断哪个环节出现问题，并尝试修改对应外壳内容。调整频率可以远高于人工方式，也不需要开发者逐条参与。
提示词调优有一个容易被忽视的成本：系统提示会在每一轮工具调用和推理时重复发送。每增加一条规则，就意味着所有后续调用都要为该规则支付 Token 开销。规则越堆越多，留给工具返回结果、上下文推理和下一步规划的预算反而被压缩。
递归式外壳调优也需要消耗 Token，但它的目标不是无限增加规则数量，而是通过结构调整和经验压缩来控制上下文长度。系统可以有选择地保留有效经验，淘汰不再适用的旧规则。这在一定程度上缓解了提示词膨胀问题。
不过，递归式外壳调优会引入额外的计算流程，例如需要记录执行轨迹、进行差异分析、生成新的外壳配置。这些步骤本身也需要计算资源。因此，它在小任务上可能显得较重，而在复杂任务上更有优势。
传统提示词调优的适应性取决于开发者是否提前遇到过类似问题。它更适合任务结构相对稳定、失败模式可预测的场景。例如固定格式的数据抽取、固定流程的工单处理等。
递归式外壳调优更适合任务结构可能变化的场景。因为它可以在运行中根据反馈调整配置，理论上能够对设计者没有预料到的新任务逐步收敛表现。当然，这种收敛不是无条件的，它仍然受限于底层模型的推理能力和反馈信号的质量。
人工提示词调优的最大优点是可控。开发者清楚每一条规则为什么要加、什么时候会被触发。出现问题时，可以直接定位到具体提示内容。
递归式外壳调优则相对较难解释。系统自动修改后的外壳可能包含大量冗余信息，也可能删除某条对开发者来说很关键的约束。调试时，开发者需要同时理解原始外壳、修改过程以及最终配置，链路更长。
人工提示词调优如果不频繁修改，配置本身是稳定的。缺点是它可能长期停留在次优状态。
递归式外壳调优虽然可能找到更优配置，但也存在修改失败的风险。系统可能错误删除了有效规则，或者引入了与现有逻辑冲突的新规则。因此，实际使用时通常需要配合版本记录、回滚机制和人工审核节点。
| 对比维度 | 传统提示词调优 | 递归式外壳调优 |
|---|---|---|
| 调整方式 | 开发者手工修改提示词与规则 | 系统根据执行反馈自动调整外壳 |
| 调整频率 | 低频，依赖测试周期 | 可高频，接近每次任务后更新 |
| Token 成本 | 规则越多，每轮重复消耗越高 | 通过经验压缩控制上下文，但引入额外分析流程 |
| 适应性 | 适合稳定、可预测的任务结构 | 更适合任务结构变化或未知场景 |
| 可控性 | 高，规则来源清晰 | 较低，需要版本管理与回滚机制 |
| 可解释性 | 高，问题定位直接 | 较低，需还原修改链路 |
| 工程复杂度 | 低，直接改文案即可 | 较高，需要记录轨迹、分析反馈、生成新配置 |
| 适用团队 | 小型团队、快速验证阶段 | 中大型团队、长期运行且任务复杂的系统 |
如果智能体任务比较固定，例如企业内部固定格式的报表生成、固定字段的信息抽取、按固定流程处理的审批辅助等，人工提示词调优通常已经足够。开发者在测试阶段可以收集到大部分失败样本，通过补充规则即可达到可接受的成功率。
这种场景下引入递归式外壳调优反而可能增加不必要复杂度。因为任务本身变化不大，自动调整带来的收益有限，但需要额外搭建轨迹记录和反馈分析流程。
如果智能体需要面对开放任务，例如用户提问方式不固定、工具返回内容结构多样、任务步骤无法提前枚举，那么仅靠人工预设规则很难覆盖全部情况。此时递归式外壳调优可以提供更持续的改进能力。
尤其在办公自动化、信息检索、多工具协同等场景中，智能体经常需要根据中间结果动态决定下一步操作。外壳中的工具指引、校验规则和经验记录如果能够随任务反馈自动调整，对成功率的帮助会更明显。
实际项目中，两种思路往往结合使用。开发者先通过人工方式搭建基础外壳，保证智能体在主要路径上表现稳定；再引入递归调整机制处理长尾场景和未知失败。这样既能保留基础配置的可控性，又能获得自动化的适应能力。
如果团队规模较小，任务范围明确，当前主要目标是快速验证智能体能力，建议优先使用传统提示词调优。它的工程负担低，调试链路短，能够快速判断模型与任务是否匹配。
如果团队已经进入长期运行阶段，任务类型多、交互步骤长、失败模式难以穷尽，可以考虑引入递归式外壳调优。但应同步建设配置版本管理、回滚检查与人工确认机制，避免自动调整引入新的不稳定因素。
从成本角度看，如果任务调用量很大，提示词膨胀带来的 Token 成本可能迅速超过自动调优系统的额外计算成本。此时更需要关注上下文长度控制和经验的动态替换。反过来，如果任务调用量小，但任务变化频繁，人工分析成本高，自动调优的价值也会更突出。
如果从人工提示词调优转向递归式外壳调优，不能直接把原有提示词全部交给系统自动管理。建议保留基础系统提示词和核心护栏，由系统主要调整工具指引、校验规则和经验记录。这样即使自动调整出现偏差，底层行为仍然可控。
同时需要记录每次调整前后的配置差异，保存执行轨迹。出现异常时，可以根据轨迹判断是哪一步的外壳改动影响了结果。回滚机制应尽量支持单类配置的独立回退，而不是整体恢复旧版本。
在上下文管理方面，应限制经验区的最大长度，避免系统把所有历史教训都保留下来。可以设置经验优先级或衰减机制，让高频有效的经验优先保留，长期未被触发的经验自动淘汰。这样可以减少 Token 增量和提示词膨胀风险。
此外，自动调整流程最好增加人工审核节点。对于关键任务，可以要求系统生成的重大外壳变更在生效前由开发者确认；对于非关键任务，可以采用先灰度生效、再观察成功率的策略。
传统提示词调优与递归式外壳调优并不是互斥关系，它们分别解决了不同阶段和不同复杂度下的配置优化问题。传统方式胜在简单、可控，适合任务稳定、团队较小或快速验证阶段；递归方式胜在自动适应，适合任务开放、长周期运行或人工分析成本较高的场景。
理解二者的核心差异，关键在于区分“规则从哪来”和“规则如何变化”。如果规则主要来自开发者经验，且任务结构不变，传统调优足够；如果规则需要根据运行反馈持续演进，递归式外壳调优更能体现优势。
在决定是否引入递归式外壳调优前，建议先评估任务的开放程度、调用量、上下文成本、团队工程能力和可接受的风险范围。只有把这些条件考虑清楚，才能在不更换模型的前提下，选择更合适的智能体性能提升路径。