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. 如果工单中没有用户ID，user_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 常见问题速查表

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 开发，建议从今天开始，把提示词当成正经的工程产物来对待。建个文件夹，做好版本管理，每次修改都记录效果变化。坚持一段时间，你会发现自己对模型行为的掌控力会有质的提升。