最近在开发和调试模型应用时，常常感到困惑，当我的智能体表现跟预期不一样，我该改哪里？
可能是模型犯傻，可能是提示词写得不够好，可能是我的智能体架构没办法完成这么复杂的问题，那么，该从哪里入手呢？
决策指南：系统化的调试排查清单
面对问题，不要盲目尝试，应该遵循一个系统化的排查路径，从最简单、成本最低的开始。
第一步：基准测试 - 剥离框架，测试模型本身
行动：将出错的复杂任务进行拆解，取出最核心、最单一的推理或知识问题，直接向模型提问（使用一个干净简单的Prompt）。 目的：判断问题出在模型能力边界还是你的框架设计。
- 如果模型连这个核心子问题都解决不好：那么问题很可能在于模型能力。你需要考虑更换一个在该领域更强的模型。
- 如果模型能很好地解决核心子问题：那么问题大概率出在你的应用架构或提示工程上。请进入第二步。
示例：你的ReAct智能体在回答“梅西今年赢得了多少个冠军？”时出错了。
- 基准测试：直接问模型“梅西在2024年赢得了哪些冠军？”。
- 如果模型回答错误或胡说八道 -> 说明模型的知识截止或事实性能力不足。考虑换用支持联网搜索的模型或知识更新的模型。
- 如果模型能准确列出冠军 -> 说明模型能力是够的，问题在别处。
第二步：提示工程优化 - 检查“沟通方式”
行动：在现有的智能体架构内，优化你给模型的提示词。特别是ReAct中的“系统提示”，它定义了智能体的角色、规则和思考格式。 目的：确保你清晰、无歧义地告诉了模型“你要做什么”和“你该怎么思考”。
- 检查是否提供了高质量、具有代表性的示例。
- 检查指令是否清晰。将“一步步思考”改为“请按照以下步骤推理：1. 理解问题... 2. 制定计划...”。
- 简化指令，去掉可能产生冲突的冗余描述。
第三步：架构调整 - 重构“工作流程”
行动：如果提示工程优化到一定程度后效果依然不佳，考虑调整智能体架构本身。 目的：可能是当前的工作流不适合该任务。
- 任务是否过于复杂？ 考虑引入分层或多智能体协作。比如，用一个“主管智能体”负责拆解任务，再调用不同的“专家智能体”执行。
- ReAct的步长是否合适？ 有时让模型一步做太多决策容易出错。可以考虑更细粒度的步骤分解。
- 是否需要引入更多工具？ 也许模型不仅需要搜索，还需要计算、代码执行等其他工具的辅助。
核心原则总结
- 拥抱黑盒，关注接口：对于模型的内化能力，我们通常将其视为黑盒。重要的是理解它的输入输出特性（比如，这个模型的“深度思考”模式擅长什么？不擅长什么？），并将其作为系统的一个组件来使用。
- 正交性思考：将模型能力、提示工程、智能体架构视为相对正交的维度。调试时，尽量固定其中两个，只变动一个，这样才能有效定位问题。
- 成本与收益的权衡：
- 换模型：成本最高，但可能带来根本性提升。
- 调架构：成本中等，需要对系统有较好的设计。
- 优化Prompt：成本最低，应该是首选和持续进行的动作。
结论是，您不需要严格区分“模型原生”和“外部工程”，而是要将它们视为一个完整的系统。 您的角色从一个“提示词编写者”转变为一个“系统架构师”。您的核心任务是基于对模型能力（包括其原生内化能力）的深刻理解，设计出最能发挥其优势的、鲁棒的智能体工作流。 当出现问题时，按照上述的排查清单（基准测试 -> 提示优化 -> 架构调整） 来执行，就能高效地找到解决方案，而不是在困惑中盲目尝试。