1. 为什么提示工程是 AI Agent 的第一道门槛很多人刚接触 AI Agent 的时候脑子里想的都是“我要搭一个能自动干活的智能体”然后一头扎进框架选型、工具调用、记忆模块这些听起来很硬核的东西里。结果跑起来发现Agent 要么答非所问要么在关键步骤上反复绕圈要么干脆把任务理解偏了。排查半天代码最后发现问题出在最不起眼的地方——提示词写得太随意了。我刚开始做 Agent 项目的时候也踩过这个坑。当时用一个大模型做任务规划提示词就写了一句“帮我规划一下这个任务”结果模型给出的步骤粒度忽大忽小有时候一步就把整个流程概括完了有时候又拆得特别碎导致后续的工具调用完全没法对齐。后来把提示词改成结构化的角色定义加输出格式约束同一个模型、同一套代码任务规划的成功率直接从不到五成拉到了八成以上。这个经历让我彻底意识到提示工程不是“随便写几句话”的事它是 Agent 系统里最底层、最廉价、也最容易被忽视的杠杆。这一篇要聊的就是怎么让大模型真正听懂你说话。核心关键词包括AI Agent、提示词、提示工程、大模型、Prompt。不管你是刚入门想搞清楚 Prompt 到底该怎么写还是已经在做 Agent 开发但总觉得模型“不太听话”这里的内容都能给你一些可以直接拿去用的思路和方法。我会从提示工程在 Agent 体系里的定位讲起然后拆解提示词的核心结构、实操写法、常见翻车场景和排查技巧最后给出一套可以复用的提示词模板框架。2. 提示工程在 AI Agent 体系中的真实定位2.1 提示词到底在 Agent 里扮演什么角色如果把 AI Agent 比作一个员工那么大模型是大脑工具是手脚记忆是笔记本而提示词就是岗位说明书加工作手册。没有这份说明书员工再聪明也不知道自己该干什么、该怎么干、干到什么程度算合格。在 Agent 系统里提示词至少承担四个层面的职责。第一是角色定义告诉模型它是谁、擅长什么、面对什么场景。第二是任务描述说清楚当前要完成什么目标。第三是约束条件划定边界比如不能做什么、必须遵守什么规则。第四是输出格式规定结果以什么结构返回方便后续程序解析。这四个层面缺一个Agent 的行为就会出现偏差。我见过很多项目只写了任务描述没有角色定义和输出格式约束结果模型每次返回的格式都不一样解析代码写了一堆兼容逻辑还是经常报错。后来加上明确的 JSON 输出格式要求解析成功率立刻稳定下来。2.2 提示工程和上下文工程的区别最近有个热词叫“大模型提示词工程与上下文工程”很多人把这两个概念混在一起。我的理解是提示工程关注的是“怎么说”也就是你给模型的那段文字怎么组织、怎么表达、怎么约束。上下文工程关注的是“给什么”也就是在模型的上下文窗口里放哪些信息包括历史对话、检索到的文档、工具返回结果、记忆内容等等。举个例子你让 Agent 帮用户查订单状态。提示工程解决的是“你怎么告诉模型去调用订单查询工具、怎么让它把结果整理成用户能看懂的格式”。上下文工程解决的是“你把哪些历史对话、用户信息、订单数据放进上下文里让模型有足够的信息做判断”。两者是配合关系不是替代关系。提示词写得再好如果上下文里缺了关键信息模型也做不出正确决策。反过来上下文塞得再满提示词没有引导模型去关注重点效果一样打折扣。2.3 为什么说提示工程是 Agent 开发中投入产出比最高的环节我自己的经验是在 Agent 项目里调整提示词的成本几乎为零但收益往往立竿见影。改一行提示词不需要重新训练模型不需要改架构不需要部署新服务改完立刻就能测试效果。相比之下微调模型需要准备数据、跑训练、做评估周期长、成本高。换框架、改架构更是伤筋动骨。所以我的建议是Agent 效果不好的时候先别急着上微调或者换模型先把提示词从头到尾捋一遍。很多时候问题就出在提示词写得太模糊、太笼统、缺少关键约束。把提示词写清楚能解决百分之七八十的效果问题。3. 提示词的核心结构拆解3.1 角色设定给模型一个明确的身份角色设定是提示词的第一块基石。你告诉模型“你是一个资深客服”和告诉它“你是一个帮助用户解决问题的助手”模型的表现会有明显差异。前者的回答会更专业、更有边界感后者则容易发散。写角色设定的时候我通常包含三个要素身份、能力范围、行为风格。比如你是一名电商平台的售后客服专员熟悉退换货政策、物流查询和投诉处理流程。 你的回答需要简洁、礼貌优先给出可操作的解决方案。 当遇到你无法处理的问题时引导用户联系人工客服。这段角色设定里“电商平台售后客服专员”是身份“熟悉退换货政策、物流查询和投诉处理流程”是能力范围“简洁、礼貌、优先给出可操作方案”是行为风格。三要素齐了模型的行为就有了明确的锚点。注意角色设定不要写得太宽泛比如“你是一个万能助手”这种等于没写。越具体的角色模型的表现越稳定。3.2 任务描述把目标说清楚别让模型猜任务描述是提示词的核心。很多人写任务描述的问题在于太笼统比如“帮我处理一下这个问题”“分析一下这段内容”。模型看到这种描述只能靠猜猜对了是运气猜错了是常态。好的任务描述应该包含动作、对象、目标、约束四个要素。举个例子请阅读用户提交的投诉内容判断投诉类型物流问题/商品质量/服务态度/其他 提取关键信息订单号、问题描述、用户诉求 并按照指定 JSON 格式输出结果。 如果投诉内容中缺少订单号将 order_id 字段设为 null。这段描述里“阅读用户提交的投诉内容”是动作“投诉内容”是对象“判断类型、提取信息”是目标“按照 JSON 格式输出、缺少订单号设为 null”是约束。模型拿到这样的任务描述基本不会跑偏。3.3 约束条件告诉模型什么不能做约束条件是很多人容易忽略的部分。大模型有个特点你越不让它做什么它有时候越容易去做。但如果你完全不设约束它就会自由发挥输出一些你不需要的内容。常见的约束包括不能编造信息、不能超出知识范围回答、不能输出敏感内容、必须按照指定格式返回、必须在指定字数范围内等等。我一般会把约束条件单独放在一个区块里用明确的标记区分开比如【约束条件】 1. 只基于用户提供的信息进行判断不要编造订单号或用户信息。 2. 如果信息不足以做出判断返回 {status: insufficient_info}。 3. 输出必须是合法的 JSON不要包含任何额外解释文字。这样写的好处是模型能清楚地区分“任务”和“约束”执行的时候不容易混淆。3.4 输出格式让结果可以被程序直接消费在 Agent 系统里模型的输出通常不是给人看的而是给程序解析的。所以输出格式的约束特别重要。我一般会要求模型返回 JSON并且给出明确的字段定义和示例。【输出格式】 请严格按照以下 JSON 结构返回 { complaint_type: 物流问题 | 商品质量 | 服务态度 | 其他, order_id: 字符串或 null, summary: 一句话概括用户诉求, urgency: 高 | 中 | 低 }给出字段的可选值和示例能大幅降低模型输出格式错误的概率。如果只写“返回 JSON”模型可能会自己发明字段名导致解析失败。3.5 少样本示例用例子代替解释有些任务很难用文字描述清楚这时候给例子比给解释更有效。比如你要让模型判断一段文本的情感倾向与其写一堆规则不如直接给几个标注好的例子。【示例】 输入这个快递太慢了等了一个星期才到。 输出{sentiment: negative, reason: 物流速度慢} 输入东西不错下次还会买。 输出{sentiment: positive, reason: 商品质量好} 输入还行吧没什么特别的。 输出{sentiment: neutral, reason: 无明显倾向}这种少样本示例的方式在分类、抽取、格式转换类任务上特别管用。一般来说给三到五个例子就能让模型理解你的意图。例子要覆盖不同的情况包括边界情况这样模型遇到类似输入时才知道怎么处理。4. 提示工程实操从零写一个 Agent 任务提示词4.1 场景定义做一个工单自动分类 Agent假设我们要做一个工单自动分类的 Agent输入是用户提交的工单文本输出是分类结果和关键信息提取。这个场景在客服系统、运维系统里很常见适合用来演示提示词的完整写法。先明确需求工单可能涉及物流、退款、账号、技术故障、投诉建议等类型。我们需要模型判断类型、提取订单号或用户 ID、概括问题、判断紧急程度。输出要能被后端程序直接解析入库。4.2 第一版提示词先跑通再说第一版不用追求完美先把核心结构搭起来你是一个工单分类助手。请阅读用户提交的工单内容判断工单类型 提取关键信息并返回 JSON 格式的结果。 工单类型包括物流问题、退款问题、账号问题、技术故障、投诉建议、其他。 输出格式 { type: 工单类型, order_id: 订单号或null, user_id: 用户ID或null, summary: 问题概括, urgency: 高/中/低 }这版提示词能跑但问题也很明显没有约束条件模型可能会编造订单号没有示例模型对“紧急程度”的判断标准不明确没有说明信息不足时怎么处理。4.3 第二版提示词加上约束和示例在第二版里我把约束条件和少样本示例补上你是一个电商平台的工单分类助手负责阅读用户提交的工单内容 判断工单类型并提取关键信息。 【工单类型】 物流问题、退款问题、账号问题、技术故障、投诉建议、其他 【约束条件】 1. 只提取工单中明确出现的信息不要编造订单号或用户ID。 2. 如果工单中没有订单号order_id 设为 null。 3. 如果工单中没有用户IDuser_id 设为 null。 4. urgency 的判断标准涉及资金安全或账号被盗为“高” 影响正常使用为“中”咨询类为“低”。 5. 输出必须是合法 JSON不要包含任何额外文字。 【示例】 输入我的订单 12345 已经三天没发货了麻烦帮我催一下。 输出{type: 物流问题, order_id: 12345, user_id: null, summary: 订单三天未发货要求催单, urgency: 中} 输入账号被盗了有人用我的账号下单赶紧帮我冻结。 输出{type: 账号问题, order_id: null, user_id: null, summary: 账号被盗要求冻结账号, urgency: 高} 【输出格式】 { type: 工单类型, order_id: 字符串或null, user_id: 字符串或null, summary: 一句话概括, urgency: 高/中/低 }这版提示词的结构就完整多了。角色、任务、约束、示例、输出格式五个部分齐全模型的行为会稳定很多。4.4 参数选择温度、最大长度怎么定提示词写好了模型参数也得配合。对于分类和抽取类任务我一般把temperature 设成 0 或 0.1让输出尽量确定。temperature 越高模型越有创造性但分类任务不需要创造性需要的是稳定性。max_tokens根据输出长度来定。工单分类的输出通常很短设 200 到 500 就够了。设太大浪费资源设太小可能截断输出导致 JSON 不完整。还有一个容易忽略的参数是top_p。如果 temperature 设得很低top_p 的影响就不大。但如果 temperature 设得比较高top_p 可以用来限制候选词的范围避免模型选到太离谱的词。4.5 实测效果对比我用同一批 200 条工单数据测试了两版提示词。第一版分类准确率大约 72%主要错误集中在“投诉建议”和“其他”的混淆以及订单号提取时编造不存在的号码。第二版加上约束和示例后分类准确率提升到 89%订单号编造的问题基本消失紧急程度判断的一致性也明显提高。这个对比说明一个问题提示词的改进不需要改模型、不需要改代码但效果提升非常明显。这也是为什么我一直强调Agent 效果不好的时候先检查提示词。5. 提示工程中的常见翻车场景与排查方法5.1 模型不按格式输出怎么办这是最常见的问题。你要求返回 JSON模型返回了一段解释文字加 JSON或者 JSON 外面包了 markdown 代码块导致解析失败。排查思路分三步。第一检查提示词里有没有明确说“不要包含任何额外文字”。第二检查有没有给输出示例示例本身是不是合法 JSON。第三检查 temperature 是不是设得太高。如果还是不稳定可以在提示词末尾再加一句强约束“你的回答必须且只能是一个合法的 JSON 对象第一个字符是 {最后一个字符是 }。” 这句话看起来有点啰嗦但实测下来对格式稳定性有帮助。5.2 模型编造信息怎么处理模型编造信息通常发生在信息抽取类任务里。你让它提取订单号工单里没有订单号它就可能自己编一个。解决办法是在约束条件里明确写“只提取明确出现的信息没有则设为 null”并且给出对应的示例。另外可以在后处理环节加校验比如订单号必须是数字、长度在某个范围内不符合规则的直接丢弃。提示不要指望模型百分之百不编造关键信息一定要在后处理环节做校验。5.3 提示词太长导致模型“忘记”前面的内容大模型的上下文窗口虽然越来越大但信息在上下文中的位置会影响模型的注意力。放在开头和结尾的信息模型更容易记住放在中间的信息容易被忽略。所以提示词的结构安排很重要。我一般把角色和核心约束放在开头输出格式放在结尾中间放任务描述和示例。这样模型在生成回答的时候最近的记忆里是输出格式要求不容易跑偏。如果提示词确实很长可以考虑把部分内容拆成多轮对话或者用摘要的方式压缩。5.4 同一个提示词在不同模型上表现差异大这个现象很常见。同一个提示词在模型 A 上表现很好换到模型 B 上就一塌糊涂。原因在于不同模型的训练数据、对齐方式、指令遵循能力都不一样。我的经验是提示词要针对具体模型做适配。换模型的时候不要指望提示词直接迁移至少要重新测试一轮根据表现调整约束的强度和示例的数量。有些模型对指令遵循能力强提示词可以写得简洁一些有些模型需要更明确的约束和更多示例。5.5 常见问题速查表问题现象可能原因排查方向输出格式不稳定缺少格式约束或示例加输出示例加“只返回JSON”约束编造不存在的信息缺少“不要编造”约束加约束条件后处理校验忽略部分指令提示词太长指令被淹没调整结构核心指令放首尾换模型后效果下降模型指令遵循能力不同针对新模型重新测试和调整输出截断max_tokens 设太小增大 max_tokens回答发散temperature 太高降低 temperature 到 0.1 以下6. 进阶技巧让提示词从“能用”到“好用”6.1 思维链引导让模型先想再答对于复杂任务直接让模型给答案它可能会跳步或者逻辑不完整。思维链Chain of Thought的思路是让模型先把推理过程写出来再给最终答案。在 Agent 场景里我一般会这样写请先分析工单内容判断涉及哪些问题类型然后选择最匹配的类型。 分析过程写在 reasoning 字段里最终分类结果写在 type 字段里。这样模型会先输出推理过程再输出结论。推理过程可以用来排查模型为什么做出某个判断也方便后续做质量评估。不过要注意思维链会增加输出长度和响应时间。对于简单任务不一定需要。对于复杂判断任务思维链能明显提升准确率。6.2 角色扮演的进阶用法多角色协作在复杂 Agent 系统里可以让模型扮演多个角色分步骤处理任务。比如先让模型扮演“分析员”拆解问题再扮演“执行者”给出方案最后扮演“审核员”检查方案是否合理。这种多角色协作的方式本质上是在一个提示词里模拟多个 Agent 的协作过程。好处是不需要真的搭多个 Agent一个提示词就能实现类似效果。坏处是提示词会变长对模型的上下文理解能力要求更高。6.3 提示词模板化把可复用的部分抽出来在实际项目里很多提示词的结构是相似的只是具体内容不同。这时候可以把提示词模板化把变量部分抽出来用占位符代替。比如工单分类的提示词可以把工单类型列表、输出格式、示例这些固定部分做成模板把具体的工单内容作为变量传入。这样维护起来方便改一处就能影响所有调用。PROMPT_TEMPLATE 你是一个{role}负责{task}。 【约束条件】 {constraints} 【示例】 {examples} 【输出格式】 {output_format} 【待处理内容】 {input_text} 这种模板化的写法在 Agent 开发里特别实用。不同的任务可以复用同一套模板结构只需要替换变量内容。6.4 提示词版本管理别把改过的提示词弄丢了提示词是要反复迭代的。今天改一版明天改一版如果没有版本管理很快就会搞不清楚哪版效果最好。我的做法是把提示词当成代码来管理。每次修改都记录改了什么、为什么改、效果变化如何。可以用简单的文本文件加注释也可以用 Git 做版本控制。关键是要能回溯出问题的时候知道是哪次修改导致的。7. 我踩过的坑和总结出的几条硬经验做 Agent 开发这段时间提示词方面踩过的坑不少挑几个有代表性的说说。第一个坑是提示词写得太“客气”。刚开始写提示词的时候我习惯用“请你帮我……”“能不能……”这种语气结果模型有时候会“礼貌地拒绝”或者给出模棱两可的回答。后来改成直接的指令式表达“请阅读以下内容并提取……”“必须按照以下格式返回……”模型的表现立刻变得干脆很多。大模型不是人不需要客气需要的是清晰的指令。第二个坑是示例给得太多。少样本示例确实有用但不是越多越好。我有一次给了一个分类任务十几个示例结果模型开始过度拟合示例遇到稍微不同的输入就不知道该归到哪类。后来把示例精简到三到五个覆盖主要类别和边界情况效果反而更好。示例在精不在多。第三个坑是忽略了后处理校验。有段时间我完全依赖模型输出结果线上跑了一段时间发现有些工单的订单号是模型编造的。后来加了正则校验和长度校验不符合规则的直接标记为待人工处理问题才解决。模型输出永远要当作不可信输入来处理这是做 Agent 系统的基本原则。第四个坑是提示词改完没有回归测试。有一次我为了优化某个类别的分类效果改了提示词结果那个类别确实好了但其他类别的准确率下降了。因为没有做回归测试上线后才发现。后来我建了一个小规模的测试集每次改提示词都跑一遍确认整体效果没有退化才上线。这几条经验看起来简单但都是在实际项目里交了学费才总结出来的。提示工程没有太多高深的理论更多是细节上的打磨和反复的测试。8. 一套可以直接复用的 Agent 提示词框架最后分享一套我常用的提示词框架适用于大多数 Agent 任务场景。你可以直接拿去改把方括号里的内容替换成自己的需求。【角色】 你是一个[具体角色]擅长[核心能力]服务于[目标场景]。 【任务】 请根据以下输入内容完成[具体任务描述]。 输入内容 {input} 【约束条件】 1. [约束一比如不要编造信息] 2. [约束二比如信息不足时的处理方式] 3. [约束三比如输出格式要求] 4. [约束四比如字数或长度限制] 【示例】 输入[示例输入] 输出[示例输出] 输入[示例输入] 输出[示例输出] 【输出格式】 请严格按照以下格式返回不要包含任何额外文字 { field1: 说明, field2: 说明, field3: 说明 }这套框架的核心逻辑是先定角色再给任务然后划边界接着给例子最后定格式。五个部分各司其职缺一不可。实际使用的时候根据任务复杂度调整每个部分的详细程度。简单任务可以精简示例和约束复杂任务则需要更详细的说明和更多的示例。我在多个 Agent 项目里用这套框架包括工单分类、内容审核、信息抽取、对话路由等场景效果都比较稳定。当然具体到每个场景还是需要根据实测结果做针对性调整。提示工程没有一劳永逸的模板只有不断迭代的过程。如果你也在做 Agent 开发建议从今天开始把提示词当成正经的工程产物来对待。建个文件夹做好版本管理每次修改都记录效果变化。坚持一段时间你会发现自己对模型行为的掌控力会有质的提升。