Prompt写了几十版效果还是不稳定，Agent场景下到底该怎么调？

温度调到0.2其实对规划稳定性帮助有限，模型偶尔跳过推理更多是采样路径的问题。可以试试把规划和执行拆成两个独立调用，规划那步只输出结构化步骤，别让它顺手把参数也编了。另外工具描述本身要写得像API文档一样死板，参数类型和枚举值都给死，模型自由发挥的空间越小越稳。我也踩过这坑，后来发现很多“不稳定”其实是工具schema太模糊逼着模型猜。

同感，光靠改Prompt确实很难稳住，我后来是把规划拆成两步走：先生成结构化JSON（工具名+参数），再拿这个JSON去执行，中间加一层校验，编参数的情况少了很多。另外温度0.2其实可以试试直接0，Agent场景下要的是确定性不是创造力。还有一点容易被忽略，few-shot示例别塞太多，超过5个反而会干扰模型对当前输入的判断，精简到2-3个高质量的就够了。

感觉你这个不是prompt的问题了，是架构层面的事。我之前也踩过一模一样的坑，改了无数版系统提示词，最后发现根本原因是把规划和执行塞在一个调用里——模型又要拆步骤又要填参数，注意力被分散，稳定性肯定崩。后来拆成两步：先让模型只输出任务分解的JSON，解析完再带着单个子任务去调工具，成功率直接从六成干到九成多。你可以试试用function calling或者结构化输出把格式约束从prompt里拿出来，交给API层面强制，比在提示词里写“必须输出JSON”靠谱得多。另外温度0.2其实还是有点随机性，做规划这种确定性任务直接设0就行。还有个容易被忽略的点：同一个输入忽好忽坏，很可能是上下文里累积的历史消息在干扰，每轮任务最好开个干净的session，别让上一轮的推理痕迹污染当前决策。至于方法论，我觉得prompt工程在Agent里顶多占三成，剩下的靠状态机设计和工具返回的错误处理，让模型拿到明确的失败信号比让它一次做对更现实。

一模一样的问题我也踩过，改到后面人都麻了。后来发现光靠堆Prompt是治标不治本，Agent的稳定性其实更多是架构问题而不是文案问题。你可以试试把规划和执行彻底拆开，规划阶段只让它输出结构化的步骤列表，参数填充交给单独的调用去做，别让一个Prompt同时干好几件事。另外温度0.2对工具调用来说还是偏高，我一般直接给0，采样空间越小越不容易胡来。还有个坑是few-shot示例放太多反而会干扰，模型有时候会强行往示例格式上套，覆盖主要场景就够了，别贪多。真正让我稳定下来的其实是加了校验层，每次工具调用前先检查参数schema，不合法就让它重新生成，而不是指望一次就写对。所以这玩意儿不是玄学，是你把太多责任压给Prompt了，该用代码兜底的地方就别偷懒。

我前段时间也卡在这个坑里，后来发现一个事：光靠改prompt去治“时好时坏”，基本是治标不治本。Agent和普通对话不一样的地方在于，它是个多步决策链，中间任何一步的输出漂移都会被后面放大，你看到的“胡编参数”往往是前面某一步的意图理解就已经偏了。我现在的做法是把prompt拆成几层：角色和边界一层、工具描述一层、输出schema一层，然后每一层单独去做小规模回归测试，而不是整段一起改。温度0.2其实不低了，规划环节可以再往下压，甚至对工具调用那一步用更严格的约束或者干脆走function calling的强制结构。另外你说的few-shot覆盖主要场景，但Agent最容易翻车的是“边缘意图”，比如用户话说到一半、参数缺失、要调的工具不存在，这些case才是稳定性的关键。我现在更倾向于把prompt当代码管，建一个几十条的测试集，每次改完跑一遍看通过率，比凭感觉改靠谱多了。真要说方法论，我觉得是把prompt工程转成eval驱动，而不是继续玄学调参。

光调Prompt不够，工具描述和参数校验也得跟上，模型一飘就让它重试。

同一个输入结果飘，大概率不是prompt本身的问题，而是工具返回的内容或者上下文拼装方式在变。我之前也踩过这坑，后来把工具描述写死、参数schema用JSON Schema严格约束，再在每步之间加一层校验，稳定性立马好很多。纯靠改prompt去堵模型的随机性，基本是徒劳的，不如把不确定性挪到代码层去兜。你可以先打个日志看看失败那几次的完整请求到底长啥样，很多时候问题就藏在里面。

有没有更详细的教程推荐？