智能体Prompt设计实战攻略：从入门到精通

做智能体开发这么长时间我见过太多从零起步的朋友明明工具和模型都是现成的最后却卡死在同一个环节——Prompt设计。很多人以为AI Agent是高不可攀的技术真上手才发现它更像是在给一个极其聪明但没有常识的新同事写工作说明。而这恰恰是“小白友好AI Agent Prompt设计全攻略”这个标题最值钱的地方它把最容易被忽视、却最能拉开效果差距的部分单独拎了出来。这篇攻略我确实写过不少版本每次做新项目都会翻出来对照。不堆术语不炫技就把我自己做过的十几个智能体项目踩过的坑、验证过的写法、调过的参数一次性说清楚。适合完全没接触过Agent的小白也适合已经写了几个Demo但效果不稳定、不知道怎么继续优化的开发者。你现在顺着往下看看完就能结合自己的场景搭出一套能用的Agent。1. 标题背后AI Agent Prompt设计到底在做什么1.1 一份攻略解决的不止是“怎么写”先说一个很多人没意识到的点AI Agent和普通聊天机器人的差别不在模型本身而在有没有目标、有没有工具、有没有记忆。而Prompt就是把这些能力串起来的那根线。你可以把Prompt想象成给一个聪明但没经验的新人写入职说明书。他不会做的事你写清楚了他就会做你没写清楚的地方他大概率会用最省力的方式糊弄过去。这也解释了为什么同一个模型有人做成效率工具有人只能得到个废话连篇的聊天框。为什么Prompt设计在Agent开发里这么重要因为模型参数你改不了训练数据你换不了但Prompt是你可以完全控制的部分。它是整个智能体开发链条里投入成本最低、见效最快的环节。我见过一位开发者同一个后端模型用粗糙Prompt时只知道闲聊换成一套结构化Prompt之后能自动处理工单分类和风险提示。这中间的差距全是Prompt造成的。反过来说如果Prompt设计不到位工具调用会乱多轮对话会失忆输出格式会漂移最后项目只能推倒重来。还要强调一点这份攻略远不只“怎么写”。更多是讲设计前的思考你想让Agent在什么场景下干活遇到模糊请求它该怎么选哪些红线绝对不能碰。这些东西想明白了Prompt写起来就是水到渠成的事。反过来一上来就闷头写大段文字多半写出来也没法用。1.2 从入门到精通三阶段路线图标题里“从入门到精通”这几个字我按自己的实战经验拆成三个阶段。新手可以对照看自己现在卡在第几层。阶段核心任务能力标志入门掌握角色、目标、输出格式、约束的四段式能写出单轮稳定的客服Prompt进阶学会工具调用、记忆管理、任务规划Agent能连续完成多步真实任务精通掌握系统化调试、边界设计与多Agent协作能交付稳定上线的智能体入门阶段基本不需要懂任何机器学习知识只要会写字、会做结构化表达就能把Agent的能力提升一大截。这是大多数普通用户最需要的层次。进阶阶段要开始处理工具调用和记忆。这时候Agent从“会聊天”变成“会办事”开始具有真正的实用性。精通阶段则是工程化能力的体现要考虑异常输入、权限边界、线上指标、迭代节奏甚至多个Agent之间的协作。把这三个阶段走完基本就具备独立开发Agent的能力了。这也是我认为这个标题里“值得收藏”并不是夸张的原因。智能体开发不是一次性的Prompt会反复修改和迭代。这份路线图可以当作一个常查常新的参考坐标帮你定位自己当前的水平也帮你决定下一步该补哪块知识。2. 入门基础小白先掌握Prompt的四段式骨架2.1 四段式模板一个例子讲透我见过太多新手写的Prompt往往就是一句话“帮我查一下今天的天气”。这种写法不是不能用但模型只能靠猜去理解你的意图它不知道用什么样的身份回答不知道输出多详细也不知道哪些话不能说。入门第一步先把Prompt拆成四段角色定义、目标描述、输入输出格式、约束条件。拿客服Agent举例。你想做一个处理退换货的智能体四段式可以这样写你是一名在线客服助手负责解答商品退换货问题。 目标快速解决问题用户不满时先共情再处理。 输入用户发来的消息。 输出情绪回应、解决方案、兜底话术三部分。 约束不承诺赔偿金额不说内部术语不编造物流信息。这段Prompt没有魔法但Agent的行为会非常稳定。角色定义把模型拉到特定的行为域它不会突然变成法律顾问目标描述防止方向漂移模型在“解决问题”和“表示同情”之间不会乱选输入输出格式规定了结果结构后续代码解析就容易约束条件画出了红线模型不会为了讨好用户乱承诺。四个部分各司其职缺一个效果都会打折。写四段式的时候还有个小原则每一项尽量用动词开头少用形容词。比如“快速解决”比“友好专业”更容易被模型执行。因为模型更擅长理解动作而不是抽象特质的描述。这个细节很容易被忽略但改完之后效果提升非常明显。2.2 长度控制、温度参数与关键位置很多小白以为Prompt越长越专业其实不是。我自己的经验单条系统Prompt控制在300到800字左右比较合适。太短约束不住行为太长模型的注意力会被稀释重要指令反而被淹没。模型对一段文本的开头和结尾位置的内容记忆更牢中间部分更容易被忽略。所以重要约束一定要放在开头或结尾不要藏在中间段落里。这里有我踩过的一个真实案例。某同学在做一个工单分类Agent把“不要随意调用外部接口”这条最重要的红线写在Prompt中间偏后位置结果Agent在大量测试里反复违规调用。后来我让他把这条红线单独提出来放在Prompt最后一句问题立刻消失。同一个要求只是挪了个位置效果天差地别。这类位置敏感问题是入门阶段最值得掌握的一个技巧。温度参数也需要提一下。temperature控制的是模型回答的随机性范围一般0到2。做客服、答疑、数据处理类Agent建议调到0到0.3之间输出会更稳定不容易语无伦次。做创意写作、头脑风暴类Agent可以适当调高。很多新手只盯Prompt忽略这个参数结果怎么调都感觉模型“太飘”其实根因在参数上。2.3 让示例告诉模型你想要的答案在Prompt里放几个输入输出示例是目前提升效果最直接的手段之一术语叫少样本示例。模型不需要你教它逻辑只需要看几个例子就能模仿你的格式和语气。我建议示例不要少于2组不要多于5组。太多会撑爆上下文太少模型学不出规律。示例的选择也有讲究。不要只放理想情况一定要放一个边界案例。比如客服Agent示例里除了“正常订单查询”再加一个“用户情绪激动时的回复示例”。这样一来模型在真实遇到愤怒用户时也有了一个可以参考的应对模式。我曾经只放了两个正常案例结果模型面对暴躁用户时也在用官方客套话回复效果很差。加上边界示例之后整体稳定了很多。另外示例的位置要靠近对应的规则。比如把“输出格式示例”放在“输出格式要求”的下方模型更容易把两者关联起来。如果你把示例堆在Prompt末尾它和规则之间的关系就被削弱了。这也是很多开发者踩过的暗坑。3. 进阶关键从“会聊天”到“会办事”的Agent化设计3.1 工具调用怎么写才不会翻车入门Prompt只能让模型聊天进阶Prompt要让模型像人一样使用工具。要做到这一点Prompt里必须写清楚每个工具是干嘛的、什么时候用、怎么用。很多Agent翻车翻就翻在工具调用写得含糊。我常用的是三段式工具描述工具职责、触发条件、输出结果。工具名查订单 职责根据订单号查询订单状态 触发条件用户明确提到订单号、物流进度、发货时间 输出返回订单状态文本查不到时返回“未找到”然后在Prompt里加一段工具使用规则你有以下工具可供调用。当用户消息符合触发条件时必须调用工具而不是凭记忆回答。 工具返回结果后再根据结果组织自然语言回复。 同一个场景有几个工具同时可用时优先选择信息更准确的那一个。“必须调用工具而不是凭记忆回答”这句话很重要。模型有个坏毛病就是爱凭经验瞎猜比如用户问物流它不查工具就编一个物流状态出来。把这句话明确写进去能解决很大一部分幻觉问题。触发条件里的“明确提到”是一种收紧写法宁可漏掉偶尔的误触发也不要因为条件太宽导致频繁乱调用。3.2 记忆管理让Agent多轮不失忆Agent进入多轮对话后最突出的问题是失忆。用户上一句刚说过名字下一句它又问一次。解决办法有很多把全部历史对话拼到上下文里把关键信息提炼成结构化记忆或者走向量检索。对小白来说我建议先做结构化记忆简单直接、成本低。做法是在系统Prompt里加一个“当前记忆”区由程序在每轮对话前动态更新【当前记忆】 - 用户姓名小王 - 常用时间段工作日晚上8点后 - 待办事项下周三前提交周报记忆区不是越长越好。我一般限制在200字以内只记录会影响对话走向的关键信息。如果什么都记模型会分不清重点回答反而显得奇怪。你想想和人对话时如果对方心里的备忘录塞了一百条无关细节你是不是也会觉得他说话颠三倒四模型是一样的。还有一个小技巧当记忆更新时让模型顺带说一句“好的我把下周三这个时间记下来了”。用户会有一种被记住的感觉Agent的体验感立刻不一样。这个细节成本很低但对用户满意度的影响非常明显。3.3 复杂任务规划先想后做再加防呆遇到复杂任务比如“帮我规划休息日的行程”“写一份合作方案”如果让Agent直接生成答案结果往往很笼统甚至前后矛盾。高级做法是引导Agent先输出规划再逐步执行。这相当于让模型慢下来把思考过程外显出来。Prompt里可以这样写当任务步骤超过三步时先输出以下规划 目标... 步骤1... 步骤2... 然后按步骤执行每完成一步输出简要结果。 最多执行5步超过限制时停止并告知用户。“最多执行5步”就是防呆设计。Agent有时会陷入自己的逻辑出不来一个工具反复调用或者一个问题反复追问。设了步数上限系统就不会失控。这就像给工人一个规定无论多忙连续干五件事之后必须向组长汇报一下进度。五步是一个经验值实际你可以根据任务复杂度调整但一定要有上限。规划还有一个额外的好处方便排查问题。我每次调试Agent都会先看它生成的规划是否合理。规划对了后面执行最多有小毛病规划本身就跑偏那一定是Prompt没写清楚。所以这个能力也是进阶和精通之间的桥梁。3.4 结构化输出让Agent结果能被程序直接用当Agent需要和业务系统联动时自然语言回答很难被程序解析。比如日程助手要调用日历工具程序需要“时间”“地点”“标题”这些结构化的字段。如果全靠自然语言去拆解析成本高还容易出错。所以我做真实项目的时候会让Agent在内部输出JSON再把它翻译成用户能看到的话。Prompt里可以这样写当你决定创建日程时内部输出如下JSON {action: create_event, params: {title: ..., time: ..., note: ...}} 然后再根据这个JSON生成一句自然语言回复。这样做的好处是程序处理流程变成了一条直线拿到JSON校验字段调用工具返回结果。出了问题也容易定位是JSON字段错了还是工具返回错了一目了然。新手写Agent时常见的做法是让模型直接输出自然语言地址程序再去猜“下午三点”是什么意思费劲不说还容易猜错。4. 从0到1实操手把手设计一个日程助手Agent4.1 先拆需求再写Prompt直接写Prompt很容易漏掉功能所以我每次都会要求自己先花十分钟把需求拆清楚。现在拿日程助手做个演示项目。假设要给一个普通用户做日程管理Agent需求大概是这样。功能需求对应Agent能力记住用户空闲时间偏好长期记忆新增、修改、删除日程调用日历工具检测时间冲突冲突检查工具冲突时给出备选建议规则判断语气轻松友好角色设定拆完需求之后Prompt里应该有哪些模块就很清楚了。角色设定管语气工具调用管操作记忆区管个性化规则区管冲突处理。一个模块对应一块需求不容易漏。很多项目做到一半发现Agent行为不对回头一看大部分原因是需求表本身就没拆全。这个过程还有一个作用帮你想清哪些事不该让Agent做。例如删除日程这类高风险操作要不要直接执行我的答案是二次确认。所以需求表里加了一条规则删除操作必须再问一遍。这类细节在需求阶段想清楚后面就不用反复修补Prompt。4.2 一份可直接复制的系统Prompt下面这份Prompt模板我实际项目里在用改成你自己的场景就能用。它已经把角色、目标、记忆、工具、规则、输出格式都覆盖到了。你是日程助手负责帮助用户高效管理日程安排。 你的目标快速帮用户新增、查询、调整日程并主动提醒冲突。 用户画像{用户画像占位符} 当前记忆{记忆字段占位符} 对话历史{最近3轮对话} 用户输入{用户消息} 可用工具 - create_event新增日程 - update_event修改日程 - check_conflict检查冲突 规则 1. 用户提到时间地点时先调用check_conflict再决定是否新增。 2. 如果冲突给出备选时段而不是直接拒绝。 3. 回答使用短句风格轻松。 4. 删除日程前必须向用户二次确认。 5. 不知道用户具体需求时先询问再操作。 输出格式自然语言回复 操作结果摘要。你可能注意到这份Prompt只有十几行但它已经能支撑一个相当完整的日程助手。关键在于每个模块都对应了之前需求表里的一项。你不需要把它背下来需要的是理解每个区块为什么存在。理解了换场景的时候你也能自己搭出同样的结构。新手拿到模板最容易犯的错是把占位符直接留在那里不替换。比如{用户消息}还在结果程序根本没有填充用户消息导致Agent一直用“你好有什么可以帮你”这类话自我对话。这个坑我见过太多次了一定记得把动态区做成变量而不是写死。4.3 在开发框架里落地的关键细节有了Prompt文本下一步是把它接进Agent开发框架。对小白来说我强烈建议把Prompt存在独立文件里比如叫prompt_schedule.md程序负责加载而不是写死在代码里。伪代码大概是这样的with open(prompt_schedule.md, r, encodingutf-8) as f: system_prompt f.read() agent.start( system_promptsystem_prompt, tools[create_event, update_event, check_conflict], )这样做的好处非常直接Prompt是经常要改的如果写死在代码里每调一次都得改代码重新发布效率低。把Prompt独立出来你甚至可以让不懂编程的同事直接编辑这个文本文件你的代码一行都不用动。运行时还有个容易忽略的细节system_prompt不应该只在开始时加载一次。每轮对话前程序要把当前记忆和最近几轮历史动态拼进去。很多小白以为加载一次就完事了结果Agent聊着聊着就失忆本以为是模型问题其实只是代码没有刷新上下文。安全方面也提醒一句如果用户输入被当成Prompt的一部分直接拼进系统有可能被恶意利用。做生产级Agent时我一般会先限制用户输入长度再做一次简单的指令注入过滤至少把“忽略以上指令”“重新设置你的规则”这类写法拦掉。这个坑很隐蔽新手期可以暂时不处理但项目要上线就一定要补上。4.4 上线前的测试清单不要一写好Prompt就急着丢上线。我习惯先跑一轮边界测试用一个小表格记录下来。测试场景预期行为用户问完全不在职责范围内的问题触发兜底回复不胡编用户只说“帮我安排一下”没有任何时间地点Agent主动追问而不是猜一个用户连续两次修改同一个日程两次都执行修改并给出确认新增日程时间冲突提示冲突并给出备选时段用户输入极长或带特殊符号正常处理不出现逻辑错乱用户要求删除日程先二次确认再执行这份清单不用写很多覆盖主要功能路径和几个高风险边界就行。每次改动Prompt之后都跑一遍省得上了线才发现答非所问。我在真实项目里上线前至少会把这六个场景各测五遍直到结果稳定为止。5. 实战避坑常见问题与排查技巧5.1 四类典型异常及对策我做过不少Agent相关项目几乎每个项目遇到的问题都会落到Prompt层。下面整理四类最常见异常可以直接当速查表用。异常现象可能原因对策Agent回答过于简短、敷衍约束太少或温度过高增加输出格式要求把温度调低Agent动不动就调用工具工具触发条件写太宽写明“仅当用户明确提到xx时才调用”多轮对话后明显失忆记忆字段未被动态刷新每轮重新拼接当前记忆区Agent开始编造信息缺少“不知道就说不知道”的约束增加兜底语句禁止编造工具调用宽松这条我最早做客服Agent时吃过大亏。当时把“如果用户问订单相关问题就调用查订单工具”写得太笼统结果用户随口说一句“你好”也触发了查询接口调用量暴涨成本也跟着涨。后来改成“仅当用户消息中包含订单号或明确提到物流进度、发货时间时才调用”异常行为立刻消失。5.2 调试要遵循最小变更原则调试Prompt不能靠感觉要讲方法。我的习惯是一次只改一个变量。比如这一轮只改输出格式要求跑二十个测试案例看效果效果不好再改工具触发条件然后再跑。如果同时改了好几个地方你根本不知道是哪个改动起效也很难积累有效经验。这就像做菜每次只换一种调料你才知道是哪一味让菜变好吃了。我也强烈建议给Prompt做版本管理。最笨也最有效的方法是用文件名区分比如prompt_v1.md、prompt_v2.md。或者干脆在文件顶部写一行变更日志。# v3 修改增加冲突检查步骤日期2026-03这个习惯在项目需要回滚时能救命。有一次我发现新版Prompt效果还不如旧版但旧版内容早已被覆盖只能凭记忆重写浪费了一下午。从那以后我再也不直接覆盖旧文件。版本管理越简单越好关键是有。5.3 新手最容易忽略的三个坑第一只测正常路径不测边界。很多人写了个Prompt测两个正常问题觉得好厉害就上线了。一旦用户输入不按套路来Agent立刻露馅。所以每次测完正常情况一定要专门挑刺用户不提供信息、用户情绪激动、用户反复追问同一件事。这些场景能最快暴露Prompt里的盲区。第二权限边界不清晰。Agent不知道哪些事情不该做就什么事情都可能尝试。你只在Prompt里写了“你是一个日程助手”没有写“你不能做xxx”那么用户让Agent帮忙改文件、查敏感信息它很可能真的去做。解决办法是把“不能做什么”写清楚最好单独建一个“禁区”段落。第三没有兜底回复。当用户问的东西完全超出Agent职责范围模型必须有一套统一话术不然就会硬着头皮乱答。我常用的兜底模板是当前我能处理的是日程管理相关的问题。 对于这个请求我暂时没有能力处理建议你换个方式描述或者联系人工支持。这三个坑只要提前规避Agent稳定性提升一大截。我复盘过几次项目上线后的客服消息大量不满意反馈其实根本不是模型能力不行而是兜底缺失和权限越界造成的。6. 从这份攻略继续往前走的方向6.1 多Agent场景下Prompt的组织方式学会单个Agent之后下一步往往是多Agent协作。比如一个主Agent负责理解用户意图再把任务分发给财务Agent、日程Agent、搜索Agent。这时候Prompt设计就变成了接口设计。我的经验是一个Agent的Prompt要明确写出它擅长什么、不擅长什么、什么情况下必须把任务转给谁。每个子Agent只需要守住自己的领域不需要知道其他Agent的完整逻辑。拿日程助手举例它发现用户问报销流程应该直接回复“这个问题不在我的范围我帮你转给财务助手”而不是强行编一个答案。多Agent的系统里Prompt写得越“克制”整个系统越稳定。6.2 迭代节奏与线上效果观察上线不代表结束。Agent和业务系统一样需要迭代。建议按周为单位观察几个关键指标任务完成率、非预期工具调用率、用户中途放弃率。任务完成率很低多半是Prompt目标和实际需求不匹配非预期调用率高多半是工具触发条件写得宽用户中途放弃普遍多是回复风格或交互体验出了问题。每次迭代只围绕一个指标来做。比如这周只优化工具调用触发下周再看完成率对比。这样积累下来的经验会慢慢形成一个你自己专属的调试地图而不是每次都在瞎撞。6.3 别让这份攻略只躺在收藏夹如果再让我给标题里的“值得收藏”做个注解我大概会这样说这份攻略真正的价值不是让你看一遍就全懂而是在你被Agent调试折磨到崩溃的时候能翻回来找到问题在哪。我自己也有过收藏一堆教程却不行动的黑历史。Prompt设计这个东西动手前觉得不过如此动手后才发现细节全是坑。最后分享一下我的工作习惯每次改完Prompt我都会在项目里建一个对应的测试记录写下“改了哪里、预期效果、实际表现”。三个周期之后整个项目的行为边界就被摸得很清楚了。这个习惯让我把很多原本让人挠头的Agent问题变成了可以复用的经验。希望你看完这篇也能动手改一个自己的Prompt去验证一下哪里能立刻变好哪里还需要更多打磨。