SmolAgents项目中规划步骤导致后续动作执行异常的技术分析

问题背景

在SmolAgents项目开发过程中，我们发现了一个与规划步骤(planning step)执行相关的技术问题。当系统完成一个规划步骤后，该步骤会被记录到消息历史中，作为后续LLM生成输出的上下文参考。然而，这种设计在实际运行中会产生一些非预期的行为模式。

问题现象

具体表现为两种典型异常情况：

1. 代码块闭合干扰：当规划步骤以三重反引号(```)结尾时，模型会误认为需要继续完成代码块闭合，导致后续输出格式混乱。例如可能产生类似`python\nprint("Doing next action")\n````这样的异常输出。

2. 空响应问题：有时模型会直接返回空响应，因为它认为规划步骤已经完成，不需要继续生成内容。

技术原理分析

这种现象的根源在于消息角色的处理机制。当前实现中：

• 规划步骤被记录为"assistant"角色消息
• 当LLM接收到以assistant角色结尾的消息历史时
• 许多API会将其解释为需要继续完成上一条assistant消息

这种设计导致模型处于一种"续写"模式，而非开始新的响应生成。从模型的角度看，它认为自己是在完成一个未完成的响应，而非开始新的动作执行。

潜在解决方案评估

方案一：使用不同消息角色

考虑将规划步骤标记为不同于assistant的角色：

优点：

• 逻辑上更清晰地区分规划与执行

缺点：

• 大多数模型仅支持system/user/assistant三种标准角色
• 若使用user角色，会不恰当地提升规划步骤的权重
• 可能破坏现有的角色处理逻辑

方案二：添加虚拟用户消息

在规划步骤后附加一条虚拟用户消息：

实现方式：

1. 可以添加如"开始执行！"这样的提示
2. 或者设计更通用的提示模板

优点：

• 明确告知模型需要开始新的响应
• 保持现有角色体系不变
• 可定制化程度高

挑战：

• 需要谨慎设计提示词，避免引入偏见
• 可能需要在提示模板系统中增加特殊处理

最佳实践建议

基于当前技术评估，推荐采用方案二并遵循以下原则：

1. 提示设计：虚拟消息应保持中性，如"请继续执行后续步骤"
2. 模板化：将提示内容设计为可配置项，提高灵活性
3. 上下文感知：可根据前序规划步骤内容动态调整提示
4. 兼容性测试：确保方案在不同模型API下的表现一致

总结

这个问题揭示了在构建基于LLM的agent系统时，消息历史处理的重要性。规划与执行阶段需要明确的上下文分隔，而简单的角色标记可能不足以实现这一目标。通过精心设计的虚拟消息方案，可以在不破坏现有架构的前提下，实现更可靠的执行流程控制。