用Prompt写了个AI Agent，结果它总是自作主张，怎么约束？

我之前也踩过这个坑，光靠system prompt绑不住它。后来我试了给每个回复前加一个“意图确认”步骤，先判断用户问的是啥再决定答不答，跑偏少了很多。决策树倒不用那么死板，但可以在prompt里塞几个if-then的示例，比如“如果用户问退货，只回答退货政策，不主动提其他”。另外，你可以试试把“不要做什么”改成“必须做什么”，比如“必须只包含用户问题直接相关的信息”，语气硬一点效果会不一样。

说实话你这个情况我太懂了，之前我写个订餐Agent也这样，用户问能不能加辣，它直接开始介绍店长推荐套餐，气得我差点把Prompt改成“敢多说一个字就报错”。后来我发现光在System Prompt里写“只回答相关”根本没用，因为模型它不是没看到，而是它把“相关”理解得太宽泛了，觉得推荐会员卡也是服务的一部分。你要真想硬约束，得把输出格式给钉死，比如让它先输出一个“意图标签”，再根据标签走对应的回复模板，超出模板的字一概不让生成。或者干脆在代码层做拦截，把它的输出先过一遍正则，比如检测到“会员”“优惠”这类词但用户没问，就直接降级成“抱歉我不太清楚”。决策树那个思路我觉得可以试，但别太死，不然用户换个说法你的树就塌了，最好是树上挂几个关键节点，配合few-shot给几个“用户乱问但Agent正确闭嘴”的例子，比纯规则好用得多。另外你还可以试试把“禁止主动推荐”写进更靠后的位置，因为模型对Prompt末尾的注意力其实挺高的，这招对我那个Agent有点效果，不知道是不是心理作用。

我最近也踩过这个坑，光堆Prompt约束确实压不住Agent的自由发挥。后来试了给每个意图加一个“行动白名单”，比如退货就问订单号，物流就问单号，其他一律回“请找对应客服”，效果立竿见影。决策树不一定非要硬编码，但可以在System Prompt里用“if-else”的伪代码格式写清楚每个分支的边界，它反而更听话。另外你试试把“不要做”改成“只做”，负面指令它经常忽略，正面指令才有效。

试试在每次用户提问前强制加一步“意图识别”，让它先归类再回答，跑偏能少一半。

这问题我太有共鸣了，之前搞了个内部知识库Agent也这样，System Prompt里写“不要发散”完全没用，它照样给你把话题扯到天边去。后来我发现根本原因不是指令不够硬，而是模型在每一步生成时都在做“概率选择”，你写的约束只是众多输入信号之一，扛不住上下文里用户问题带来的强烈引导。我的做法是给Agent套了一层“意图路由”，先用一个轻量分类器把用户问题归到退货、物流、会员等几个固定槽位，然后每个槽位绑定一段独立的Prompt和工具调用逻辑，这样它压根没机会自由发挥。另外你提到的决策树思路其实很对，但不用做成传统那种流程图，可以把它简化成“状态机+白名单”：规定Agent每轮输出前必须经过一个校验函数，如果回答里包含非当前任务允许的动作（比如用户没问就推荐会员卡），就直接拦截并强制让它重新生成。还有个细节，Prompt里别写“只回答”这种否定式约束，改成“当且仅当用户明确询问时，才可提及会员相关信息”，这种条件式限定比抽象禁令有效得多。建议你先花半天时间把用户可能问的意图列个清单，然后每个意图写死对应的回答模板和边界，比调Prompt省心十倍。

我之前也踩过这个坑，光靠System Prompt里写“只回答相关的”根本没用，模型对“相关”的理解太宽泛了。你那个决策树的想法挺靠谱，但不用搞那么重，可以试试给Agent加个“行为白名单”，比如明确列出允许执行的工具或动作，超出范围的直接拒绝。另外建议把Prompt改成“如果用户问题不包含退货或物流关键词，必须回复‘请稍等，我转接人工’”，用具体的触发条件代替模糊的指令，效果会好很多。还有个小技巧，把对话历史里Agent自己加戏的样本拿出来做几次few-shot，告诉它“这种情况下应该闭嘴”，比纯写规则管用。说到底，Agent的自主性是个双刃剑，得靠外部逻辑（比如函数调用限制）和内部提示（硬性分支）双管齐下，只改文字描述确实容易失灵。

试试给Agent加个“意图识别+动作白名单”，先判断用户问题再选对应回复模板，别让它自由发挥。

这问题我太有同感了，之前用Prompt调客服Bot也是被“自由发挥”整到崩溃。你光在System Prompt里写“只回答相关的”，模型根本不会把它当硬性约束，它更倾向于“顺嘴聊下去”的对话惯性。我后来试下来，最管用的不是决策树，而是给Agent加一个“行为开关”式的指令，比如明确写“当用户意图不在退货、物流、会员这三类时，必须回复‘请转人工’”，并且用类似“否则视为违规”这种带后果的措辞，效果立竿见影。另外，你可以在每个用户输入前自动拼接一段“任务提示”，强制它先输出一个“意图分类”再回答，相当于把决策树藏进Prompt里，但比纯树状结构灵活多了。说到底，Prompt在Agent里不是失效，而是你得把“约束”从静态描述改成动态的流程控制，不然它早晚会自作主张。你也可以试试few-shot，给几个“用户乱问但Agent正确拒绝”的例子，比抽象规则管用得多。

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

试试把决策树写进Prompt，给每个分支配上硬性return规则，跑偏能少一半。

Prompt里加个“未知问题就转人工”的兜底，比单纯写“只回答相关”管用多了。

试试把回复流程拆成多步，先判断意图再决定动作，纯靠prompt确实管不住agent的临场发挥。

给模型加个强制输出JSON的格式要求，把允许的动作范围写死，跑偏了就直接拒绝回答，亲测有效。

试试在Prompt里加“未明确提问就闭嘴”这种强规则，再配合few-shot示例兜底，比单纯描述边界管用。

光靠Prompt约束确实容易飘，我建议你给Agent加个意图分类前置步骤，先判断再回答，跑偏概率能降一大截。

跟你遇到一样的问题，后来我发现单纯堆system prompt没用，得把约束写进流程里。我现在是给Agent加了个前置意图识别，先判断用户问题归哪类，再调对应的子prompt，跑偏概率直线下降。你也可以试试在关键节点加几个if判断，让它先确认再回答，比硬性指令靠谱多了。

我之前也踩过这个坑，光靠System Prompt压不住。后来我把回答逻辑拆成几个子模块，用if-else在代码里限定每个场景的出口，Prompt只负责填充话术，效果立竿见影。你可以试试在Agent框架里加个意图识别前置节点，命中不了就走兜底话术。另外“只回答”这种否定式指令模型确实容易忽略，换成“当用户问X时，你必须输出Y”这种正向约束会好很多。

我最近也遇到类似问题，光靠system prompt压不住，后来试了给每一步输出加“先判断意图再回复”的中间层，效果好了不少。你那个推荐会员卡的情况，本质是模型把“主动服务”理解成了“推销”，建议在prompt里明确禁止未授权动作，比如“当用户未询问时，不得主动提及任何附加服务”。另外决策树有点太死了，可以试试用few-shot给几个跑偏例子做反面示范，模型学得很快。

你这情况我太熟了，光靠System Prompt压不住它发散。后来我试了给Agent加个“意图识别”前置步骤，先把用户问题分类到退货、物流、会员这几个固定槽位，再让对应子流程回答，跑偏概率低很多。决策树倒不至于，但得让Agent“先判断再回复”而不是“边想边说”，你可以试试把输出格式强制成JSON，带reasoning字段，至少能看清它是怎么绕进去的。

你这问题我太有同感了，纯靠System Prompt确实管不住Agent的“自由意志”，它本质上是概率生成，不是规则执行。我之前试过在Prompt里加“必须严格按以下三步回答”，但效果还是不稳定。后来我改成把决策逻辑写进工具调用里，比如让Agent先调用一个“意图识别”函数，只有识别为退货才触发退货流程，其他情况直接拒绝回答，这比在Prompt里喊话硬核得多。你那个“决策树”思路方向是对的，但别用传统代码那种硬树，可以试试让模型自己输出JSON格式的决策路径，然后你在外层代码里校验它有没有越权。另外，你可以给Prompt加个“当用户问题不在明确清单内时，必须回复‘请转人工’”的兜底条款，这比“只回答相关”具体多了。

这问题我也踩过坑，光靠System Prompt压不住它的发散思维。后来我试了在每次用户输入前，强制加一段“仅针对当前问题执行以下步骤”的上下文，配合few-shot示例把“不该答什么”也写进去，比单纯说限制管用得多。但决策树倒也不必，太重了，你可以先试试给Agent加一个“意图识别”前置节点，判断完再决定走哪条回复链，跑偏率能降不少。

这问题我太有共鸣了，之前调客服Agent差点被它气到笑出声。你发现没，Prompt在单轮对话里好用，但一旦变成Agent，它就有了“上下文惯性”，你写的那句“只回答与问题相关的内容”会被系统里其他带权重的指令稀释掉，比如工具描述、历史对话里的示例，甚至你给它定义角色时的那些“热情主动”的词。我后来试了个笨办法，把“禁止主动推荐”和“超范围时回复固定话术”直接写进每个工具的system字段里，比在总Prompt里吼一百遍管用。另外决策树不是万能的，但你可以搞个轻量的意图路由，先让模型自己判断问题属于“退货/物流/会员”哪一类，再进入对应的子Prompt，相当于给它的跑偏加了个物理栅栏。还有个小坑，别在示例里放“用户问A你答B”的反例，模型会学坏，我删掉几个带纠正过程的对话后，跑偏率直接降了一半。你试试把约束拆散到各个执行步骤里，别指望一段话管全程。

我最近也踩过这个坑，单靠system prompt压不住它发散。后来是把工具调用的描述写得特别死，比如“只有用户明确提到退货才调用退货流程”，不然就不给工具权限，效果立竿见影。决策树倒不用，但得把“不做什么”写进约束里，比“只做什么”好使。你试试把所有动作都拆成可枚举的function，它就没法自由发挥了。