AI Agent提示词工程实战：让大模型真正听懂你的指令

最近在带几个朋友入门AI Agent，发现一个特别有意思的现象：大家选的模型一样、用的框架一样，最后做出来的Agent效果却天差地别。有人一句话就让大模型给出高质量结果，有人反复对话半小时，AI还在自顾自地跑偏。差别不在模型，而在提示词——怎么把你脑子里的需求，准确地翻译成大模型能执行的指令。

这个系列的第一篇我聊了Agent的整体概念和基础架构，这一篇想把"提示词与提示工程"彻底掰开揉碎讲清楚。标题写的是"让大模型真正听懂你说话"，其实是两个层面的意思：表面是让模型理解你的自然语言，深层是让你理解模型的"听力机制"。搞懂了后者，前者基本就是水到渠成的事。

这篇文章适合两类人：一是正在学AI Agent、准备用提示词做System Prompt的朋友；二是平时用ChatGPT、DeepSeek这类产品，但总觉得AI"不够聪明"的用户。整篇不会堆砌太多术语，更多是我自己从写"能跑通的demo"到"能上线的Agent"过程中总结出来的实操方法和踩坑经验。

1. 大模型的"听力"到底是怎么工作的：先看懂token和上下文窗口

1.1 你说的每句话，先被打碎再重组

很多人在写提示词时有个误区：把大模型当成一个人，觉得说"人话"就够了。但大模型不是"逐字阅读"你的整句话，它读的是token序列。

token是模型处理文本的最小单位。一个token可以是几个字符、半个词、一个汉字或者一个标点。不同模型的分词器切法不完全一样，英文大致是一个单词对应1到1.3个token，中文一个汉字往往占1到2个token。模型收到你的提示词后，会先把整段文字切成token，再做向量化，然后通过注意力机制建立词与词之间的关系。

注意，这里的关键点在于：模型并没有"语义理解"这个人类意义上的动作，它做的其实是根据已有的token，预测下一个token最可能是什么。当你提供了足够清晰的上下文时，token之间的关联强度更高，每一步预测都更稳；当你的提示含糊，模型只能靠训练数据里的平均概率去"猜"，输出自然飘。

理解这一点，会改变你对提示词的看法。提示词不是"给模型看的一段话"，而是"给模型的一组锚点"。信息密度越高、结构越清楚，每个锚点才能稳稳拉住后续的生成方向。

1.2 上下文窗口就是大模型的"工作台面积"

上下文窗口，指的是模型在一次对话中可以"记住"的最大token数量。你可以把它理解成一张工作台的面积：台面越大，你能同时铺开的资料越多，模型能够参考的素材也就越多。

现在的模型动辄32K、128K甚至更大的上下文窗口，看起来空间非常充裕，但实际可用的"有效上下文"并没有那么大。一个被反复验证过的现象是：当相关信息埋在长文本中间时，模型的利用效果会明显变差，遗忘概率高于开头和结尾。业界讨论很多，思路基本一致：注意力在长序列里会逐渐分散，中间段信息容易被忽略。

这对写提示词有非常直接的指导意义。关键指令、核心约束、任务目标，要么放在提示词开头，让模型从一开始就明确方向；要么放在离生成位置最近的地方，让模型在开口之前最后看到。千万别把最重要的要求埋在长段落中间——模型真的会"视而不见"。

1.3 理解这一步之后，你就知道为什么提示词重要了

当你意识到大模型是在做"概率预测"而不是"阅读理解"时，很多困惑就有了解释。

为什么"帮我写个方案"这种话，输出总是宽泛得像废话？因为模型在你的话里找不到任何约束条件，它只能按照训练数据里"方案"的平均样式去生成，输出的概率分布摊得非常平，什么行业都能套、什么场景都不精准。

为什么"帮我写一份智能家居产品的推广方案，面向25到35岁城市白领，预算10万，两周内上线，需要包含渠道选择、排期表和预算分配表"，输出质量会明显高一个档次？因为你的每一个限定词都成了筛选条件，模型在每一步生成时，候选范围都被压缩到一小块区域，真正相关的内容自然更容易被选中。

提示词的本质，就是压缩大模型输出的概率空间，让更合理的答案落在概率最高的位置。你给的上下文越清晰、约束越具体，模型的选择范围就越小，输出的一致性和质量就越稳定。这个认知是整个提示工程的地基。

2. 把提示词当成一份"岗位说明书"来写：四段式结构拆解

2.1 角色设定：告诉AI"你是谁，你现在干什么"

角色设定大概是流传最广的提示词技巧，但很多人用的方式不对。单纯写"你是一位专家"几乎没用，因为"专家"这个词在训练语料里出现得太频繁，模型无法从中获得足够的约束信息。

有效的方式是"职级+专业方向+风格偏好"。比如：

"你是一位有7年跨境电商运营经验的推广专家，擅长亚马逊Listing优化与站内广告投放。你偏好用数据说话，结论先行，善用表格汇总对比结果。"

这个角色描述里面包含了好几层信息：行业背景（跨境电商）、具体能力（Listing和广告投放）、输出习惯（数据支撑、结论先行、表格）。模型在生成时，会更多地调用这个领域相关的术语、案例和分析方式，不会再说出那种"放之四海而皆准"的废话。

但我也要说句公道话：角色设定不是万能的。如果你需要模型做数学计算、查事实、写JSON，角色加成并不明显，甚至可能让模型变得更爱铺垫。角色设定的核心作用是引导表达风格和分析视角，并不能直接提高事实准确性。想要事实准确，靠的是上下文资料而不是人设。

2.2 任务描述：写清目标、输入、验收标准

角色解决"谁来做"，任务描述解决"做什么、做到什么程度算完成"。

很多新手只给一句"帮我处理一下这份数据"，模型根本不知道你想怎么处理，是总结、提取、清洗还是转格式？好的任务描述应该包含四个要素：

• 任务目标：你最终想要什么产物，是分析报告、代码、建议清单还是一封邮件？
• 输入数据：给模型的东西是什么，是否需要说明格式或来源？
• 处理要求：对输入做什么操作，是总结、改写、转换还是多选一？
• 验收标准：什么样的输出算合格，有没有字数限制、条数要求、特定视角？

验收标准是最容易被漏掉的一项，但恰恰最值钱。"输出不超过800字"、"必须包含至少3个备选方案"、"每个建议后附一条风险提示"——这些可量化的验收标准，能极大压缩模型的自由发挥空间。模型其实非常擅长"挤字数"和"回避重点"，你给了验收标准，它才会奔着那个点去。

2.3 约束条件与输出格式：少让AI自由发挥

约束条件可以分成两类：内容约束和格式约束。

内容约束负责"防幻觉"：不许编造数据、不评价特定品牌、遇到不确定的信息明确说"不知道"。这些都是在显式地给模型的生成空间画边界。

格式约束负责"防混乱"：用JSON返回、用Markdown表格展示、分三个小节、先给结论再给理由。格式约束的价值不只是让人看着舒服，更是让下游程序能够稳定解析。尤其是Agent场景，模型输出格式一乱，解析代码就要多写一堆防御逻辑。

一个非常实用的细节：当你需要模型输出JSON时，最好直接在提示词里给一个最小示例。比如：

返回格式示例： {"title": "标题", "summary": "摘要", "keywords": ["关键词1", "关键词2"]}

只写"请返回JSON"是不够的。模型有时会把JSON包在Markdown代码块里，有时会在JSON前后加上一行"以下是结果："，这些都会直接破坏程序解析。给一个具体模板，等于提前把坑填平。

2.4 实战对比：同一个需求，两版提示词的效果差

为了说明问题，我拿同一个需求做过对比测试。

第一版： "帮我把这个产品的卖点写一下。"

第二版： "你是一位电商产品文案，面向25到35岁女性用户。下面是我提供的产品资料，请提炼出5个核心卖点，每个卖点用一句话概括，并附一句对应的用户痛点说明。不要编造资料中没有的数据，输出为Markdown无序列表。"

同一个模型，第一版得到的基本是"产品质量好、价格优惠、服务贴心"这类没有任何信息量的空话；第二版则会围绕产品资料里的具体特性展开，比如材质、工艺、使用场景拆出实实在在的卖点。

两版的差距，根本原因就是提示词提供了多少锚点。第一版除了"卖点"两个字，什么都没有，模型只能调用大众化的文案模板；第二版给了角色、受众、数量、结构、数据边界，模型每一步生成都有据可依。

到这里可以看清一个事实：提示工程不是玄学，而是信息密度的管理。你写的每一条约束，本质上都是在帮模型降低猜测成本。

下面是差版与好版的对照总结：

3. 当提示词遇上AI Agent：从"对话提示"升级成"系统指令"

3.1 普通问答与Agent调用的本质区别

前面聊的方法，本质上还停留在"人机对话"场景。但做AI Agent时，情况变化很大——我们面对的不是"一次性问答"，而是"带状态、带工具、带目标的多次调用"。提示词的作用也随之质变。

区别主要有三点。

第一，输出不是给人看，而是给程序用。Agent场景下，模型的输出常常直接对接函数调用、结构化解析和流程分支，所以格式稳定性比内容文采更重要。一个JSON格式不稳定的Agent，比一个措辞平庸的Agent更难维护。

第二，对话不是一次，而是一串。Agent要连续处理多轮对话，每一轮都要保持上下文和主题一致。提示词里必须写清楚"什么时候继续推进任务""什么时候主动让用户补充信息""什么时候结束当前任务"。

第三，模型有了"手"。Agent会调用搜索、计算、数据库等外部工具，提示词需要告诉模型：工具有哪些、各自用途是什么、什么条件下用哪个、调用失败怎么办。这是普通提示词完全不需要考虑的内容。

3.2 System Prompt的整体框架：角色、能力边界、工作流

在Agent架构里，真正承担"底层宪法"角色的是System Prompt（系统提示词）。无论用户说什么，这条系统提示词都固定在上下文窗口前端，约束每轮生成行为。写不好System Prompt，Agent几乎必然表现飘忽。

我写过的Agent不算少，系统提示词基本包含五块内容：

这里特别强调"能力边界"。很多Agent翻车，不是因为能力不够，而是因为不知道自己不该做什么。用户提了一个越界请求，模型觉得"硬着头皮也得回答"，于是开始编。系统提示词里明确"如果你无法回答，直接告知用户局限性"，比在几十条用户提示词里反复强调都管用。

写系统提示词的心态也要调整：它不是写作文，而是写制度。稳定、可重复、结构清晰，比任何花哨的表达都重要。

3.3 工具调用场景的提示词：让模型学会"先查后答"

Agent一定会调工具。工具调用相关的提示词，要回答模型的几个核心问题：有哪些工具可用？每个工具的职责是什么？什么时候必须用、什么时候不能用？调用失败怎么办？

我在一个知识库问答Agent里写过这样一段系统提示：

你有且仅有以下三个工具： 1. search_docs：检索知识库文档，返回摘要。当用户问题涉及事实信息时，必须优先调用该工具，不得凭记忆作答。 2. calc：执行数学计算。任何涉及计算的场景都必须调用calc，不得心算。 3. get_weather：查询天气。非当天日期的问题，必须先向用户确认城市和时间，再调用工具。 当你无法获取所需信息时，直接回复"我暂时无法回答这个问题"，并说明缺少哪些关键信息。

这段提示词的要点，是把"工具的决策逻辑"写成规则。模型本身不具备"什么时候该查资料"的直觉，只有规则足够清晰，它才会稳定触发正确的工具。

还有一个容易忽略的细节：工具调用的结果也需要设计"使用规则"。比如search_docs返回了摘要，要在提示词里引导模型"根据摘要优先作答，并标注信息来源，不要扩展摘要之外的信息"。否则Agent很可能拿到检索结果后继续自由发挥，看似回答了，实际上还是幻觉。

3.4 调试提示词的三种方法：迭代、对比、加断点

写Agent提示词很少有一步到位的，调试是必然环节。我个人常用的方法有三个。

迭代法最基础：先写个粗糙版本，跑一个用例，看输出哪里不对，再回头修改提示词中对应的句子。整个流程就是"跑用例、找差距、改提示、再跑"。这里改的不是某一个形容词，而是补齐约束条件。

对比法适合判断"是提示的问题还是模型的问题"：把同一段提示词放到不同模型上测试。同一个System Prompt在不同模型上的表现差异可能相当大，尤其风格偏好、JSON稳定性和指令跟随能力。对比能帮你找出"哪个部分是各家模型通用的写法"，后续换模型时的迁移成本会低很多。

加断点法是我觉得最被低估的：把Agent每一轮工具调用之后的完整上下文打印出来，完整看一遍。你会发现很多问题的根源根本不是提示词写得不细，而是多轮对话中上下文被污染了——一次工具返回混入一大段噪音数据，后续几轮模型就分不清主次。这时候继续堆提示词完全没用，正确操作是清洗上下文、缩短历史长度、把关键约束重新注入。

4. 提示工程的"上游"：上下文注入与动态提示模板

4.1 上下文工程：给模型的信息环境比指令更决定成败

最近圈子里都在讲一个趋势：提示词工程正在向"上下文工程"演进。这个概念并不复杂——提示词不仅仅是"指令文字"，还包括你喂给模型的所有上下文资料。很多时候，输出质量的天花板是由上下文质量决定的，而不是指令措辞。

举个很常见的例子。让Agent写新能源汽车行业分析，一个版本只传了"你是一位分析师，请写一份行业分析"；另一个版本先检索了最近三个月的行业新闻、三篇头部券商报告摘要，再让模型基于这些资料写。后者写出来的内容明显更扎实、更有依据，因为模型不是凭空生成，而是有素材可依。

所以在开发Agent时，不要只盯着提示词模板优化，还要想清楚：哪些信息必须在模型看到问题之前就主动注入？哪些信息让模型自己检索？注入的顺序是什么？资料太长时怎么压缩提取？这一整套设计就是上下文工程。掌握了它，很多"提示词怎么写都不对"的问题会迎刃而解。

4.2 动态模板：用变量组织提示词，而不是硬编码

在代码层面，很多初学者容易把提示词硬编码成一整段字符串。这在小规模验证时没问题，一旦进入真实项目，维护成本会迅速失控。更合理的做法是设计提示词模板，把经常变化的部分抽成变量。

我常用的模板是这个样子：

system_prompt = f""" 你是{role}，负责解决{task_area}领域的问题。 用户画像：{user_profile} 本次任务目标：{task_goal} 已知资料：{data_context} 约束条件：{constraints} 输出格式：{output_format} 请严格按照以上要求执行，不要编造未知信息。 """

用变量动态注入的好处有三个：一是方便复用，换一个业务只需要替换对应变量；二是方便调试，哪天输出质量下降，能快速定位是哪一块上下文出了问题；三是方便协作，非技术人员也能维护"资料区""约束区"这些内容，不必改动代码逻辑。

我建议变量里的内容尽量来自结构化数据，而不是把大段原始文本直接拼进去。原始文本太长会稀释关键信息，模型容易"捡了芝麻丢了西瓜"。先做提取、摘要、去重，再注入模板，效果会稳定得多。

4.3 Few-shot示例：给模型"参考答案"，比讲道理更管用

模型对抽象规则的跟随能力是有限的，但对具体示例的学习能力非常强。这就是few-shot（少样本示例）的价值来源。

我在做意图识别Agent时，一开始在系统提示词里写"你是意图识别专家，请判断用户意图属于查询、操作还是闲聊"，效果时好时坏，边界情况经常出错。后来我改成在提示词里放三个示例：

示例1： 用户：我想把API的请求超时时间改成5秒 意图：操作 示例2： 用户：你们系统支持Webhook吗？ 意图：查询 示例3： 用户：今天天气不错 意图：闲聊

识别准确率立刻有了可感知的提升。原因很简单：示例相当于给了模型一把"标尺"，模型不需要抽象推理"什么算操作、什么算查询"，只需要把输入和示例做模式匹配。人对模糊规则的理解靠领悟，模型对模糊规则的理解靠参考，没有参考就容易漂。

选示例也有一些讲究：贴近真实场景、覆盖最容易出错的边界情况、示例之间差异明显。数量上3到5个精选的就够了，堆10个雷同示例反而会让模型困惑。对于Agent场景，few-shot还能帮助模型理解状态切换规则，比如"用户对结果不满意时，Agent应当主动追问细节而不是直接重做"，这种过程性的示例往往比抽象描述管用得多。

5. 我在实际项目中踩过的坑，以及一份自查清单

5.1 三个最容易翻车的提示词误区

第一个误区：把提示词写成没有逻辑的"短句列表"。"你是一个专家。请参考以下资料。输出要专业。不要胡说。请使用中文。"这种拼凑式写法，模型很难建立整体理解，往往只抓住了列表开头和结尾的几条，中间的约束全部漂移。我的习惯是把提示词写成有逻辑的短文，角色、任务、约束、输出格式分段清晰，每一段之间有承接关系。

第二个误区：提示词里写满"禁止"，却没有任何替代方案。模型对否定指令的执行能力天然偏弱，你写"不要输出JSON以外的格式"，不如写"请严格输出JSON格式，结构如下"，前者给的是禁止项，后者给的是明确的目标形态。指令工程里有个朴素原则：在提示词层面，说清楚"要什么"永远比反复强调"不要什么"更有效。

第三个误区：只顾着堆System Prompt，不管上下文是否污染。我调试过不少表现不稳定的Agent，最后发现根源不是初始提示写得不细，而是跑了几轮之后，历史对话和工具返回值把初始指令"冲淡"了。系统提示词再长，窗口里堆积的无关内容一多，它也会慢慢失去约束力。这时候需要定期清洗上下文、压缩历史记录、把关键约束重新注入，有些项目甚至要在每轮结束后重建精简版的上下文。

5.2 一个可复制的Prompt自查清单

写完一段提示词之后，我会逐条做下面这些检查，任何一条不满足就回头改：

• 角色定义是否具体到"什么专业背景+什么风格偏好"？
• 任务描述是否包含目标、输入、处理要求、验收标准四项？
• 约束条件是不是以"正面引导"为主，而不是满屏的"不要"？
• 输出格式是否给过具体示例模板？
• 关键信息是否放在提示词开头或结尾，而不是埋在中间？
• 注入的上下文资料是否已经清洗、摘要、去重，而不是原样堆入？
• 工具调用的触发条件、失败处理、结果利用规则是否写明？
• 是否给了3到5个精选few-shot示例来固定输出纪律？
• 同一份提示词换一个模型跑，表现是否依然可靠？

这张清单基本就是我写Agent提示词的最终质检流程。很多次我觉得"这提示词已经完美了"，跑一遍用例也正常，结果一查清单才发现漏了输出格式的示例，或者能力边界没有写清。把清单固化成习惯之后，排查问题的效率提升非常明显。

最后说一点个人体会。学了这么久，我最大的感触是：提示工程不是玄学，它是一门"把需求表达得足够精确"的手艺。大模型的听力一直在变强，但"听懂"的前提，永远是你先把话说清楚。在我看过的绝大多数"AI不行"的案例里，提示词本身往往至少有三个可以改进的地方。如果你手里正有一个表现不稳定的Agent，先别急着换模型，也别急着加更多工具，把它的提示词按上面的框架重写一遍，多半会有意外收获。