1. 为什么提示词才是Agent真正的“第一道代码”很多刚接触AI Agent的朋友最初的兴奋点是“我能让AI帮我干活了”但写了几天提示词之后兴奋就变成了困惑为什么同一个大模型别人调出来的Agent很听话我调出来的像喝了假酒为什么我明明把需求说得很清楚模型还是给我答非所问这时候才反应过来提示词这件事远不是“说人话”那么简单。我在从0到1搭建AI Agent的实践里最大的体会是提示词就是Agent的“第一道代码”。传统的软件开发逻辑写死在Python、Java里而Agent开发里逻辑有很大一部分写在自然语言里。模型对你的需求理解得对不对直接决定了后面所有工具调用、任务拆解、结果输出的质量。你可以写很复杂的代码框架但如果提示词这个入口没把好关后面的链路全是空中楼阁。更关键的是提示词不仅仅是“把问题说清楚”。在Agent场景里提示词承担了三层职责第一定义模型的角色和立场第二拆解任务的目标和步骤第三约定输出的格式和边界。这三层职责如果只用一段大白话混在一起模型很容易“选择困难”。我自己最开始的失败案例就是告诉模型“你是一个智能助手帮我查天气并写一首诗”结果它一会儿查天气一会儿写诗两件事都做得稀碎。所以这一篇我打算把提示词工程拆开揉碎讲清楚。内容主要面向正在学习AI Agent、想从“会聊天”进阶到“会干活”的朋友也适合已经写过一些脚本但总觉得效果不稳的开发者。我会结合自己实际调过的案例把提示词的结构、原理、调优路径和常见坑都过一遍。2. 提示词的结构化拆解别再把需求“糊成一团”告诉我2.1 一个能稳定工作的提示词通常包含五个模块我早期写提示词基本靠“想到哪写到哪”后来被模型的教育次数多了逐渐总结出一套相对固定的结构。你可以把它理解成“给临时工下需求”角色、任务、约束条件、参考示例、输出要求缺了哪个对方就容易跑偏。角色设定告诉模型“你是谁”。比如“你是一名资深数据分析师”“你是一个严格的代码审查者”。这不是为了好玩而是为了激活模型在训练时见过的对应领域表达习惯。同一个问题用“数据分析师”角色和用“小学老师”角色回答的口径和详略会差很多。任务描述把要完成的事说清楚最好是一句话能概括的核心目标。注意任务描述要避免歧义尤其要避免“同时做A和B”这种并列结构。模型不是不能多任务但多任务需要明确优先级和交接方式。约束条件明确“不能做什么”。比如“不要编造数据”“如果没有把握直接说不知道”“回答控制在200字以内”。这一步是Agent稳定性的关键因为它直接抑制了模型最擅长的“一本正经地胡说八道”。参考示例给一两个正面或反面的例子让模型理解你要的风格和格式。示例的力量远大于抽象描述尤其是涉及JSON输出、表格生成、特定文体改写时一个好例子胜过十句解释。输出要求告诉模型“结果长什么样”。比如Markdown格式、JSON结构、必须包含哪些字段、是否需要最终结论。在Agent场景里这一步极其重要因为你后续还要让代码解析模型输出格式错了流程就断了。2.2 自行任务拆分为什么复杂的提示词必须分步写很多人会犯一个错误把一个大任务完整写进一条提示词里让模型“一步到位”。比如“帮我写一份市场分析报告包含数据收集、竞品对比、SWOT分析、策略建议”。结果模型确实给了你一份报告但每个部分都浅尝辄止甚至数据全是编的。这个问题的根源在于大模型在生成时是自回归的它倾向于“顺着往下写”而不是像人一样先规划再执行。当任务过大时模型会在第一段就锁定一种思路后面的内容只是这种思路的展开很难做到全局优化。所以对于复杂需求我建议把任务拆成多个步骤每一步单独设计提示词或者用一次对话中的多轮交互逐步推进。比如在做“市场分析”这个任务时我通常会拆成三步第一步让模型列出它认为分析一份市场报告需要哪些维度和数据来源。第二步针对每个维度单独让它给出分析框架和关键指标。第三步汇总前面的内容生成最终报告。这样的好处是每一步的输出都被前一步约束着模型不容易跑偏而且中间任何一步质量不满意我可以随时纠正不用推翻重来。在Agent里这种“分步提示”往往是通过LangGraph之类的编排框架实现的但底层逻辑都一样提示词不是一条巨无霸而是一组有先后顺序的指令序列。3. 提示工程的底层逻辑大模型到底是怎么“听懂”你说话的3.1 从“补全概率”到“意图对齐”想写好提示词就不能只把它当“语言技巧”得理解大模型的工作原理。大模型本质上是一个超大的概率模型它做的事情不是“理解”你的话而是根据你的输入预测最合理的下一个Token序列。这里的“最合理”是它在海量训练数据里学到的统计规律。这解释了一个反直觉的现象你觉得自己表达得很清楚但模型却理解偏了。因为“清楚”是对人而言的对模型而言它只看你输入的Token序列激活了它内部哪些知识路径触发了哪些上下文关联。你要是用了模糊的代词或者隐含的预设模型就会凭统计规律去猜猜的方向不一定是你想要的。所以提示工程的本质不是“把话说得更礼貌”而是把你的意图转化成模型更容易激活正确路径的Token组合。比如你想让模型“严格按事实回答”直接写“请严格按事实回答”效果一般但如果你写“如果你不确定请直接回复‘我不确定’”模型拒绝编造的概率会显著提升。为什么因为你给了它一个明确的“不知道”出口降低了它生成自信胡话的概率。3.2 温度参数和提示词之间的配合很多人在调提示词时忽视了采样参数。温度temperature控制的是生成随机性温度越高输出越发散温度越低输出越保守。在Agent场景里我建议区分任务类型设置不同的温度代码生成、数据提取、JSON输出温度设置在0.0到0.3之间越接近0越稳定。创意写作、头脑风暴、文案润色温度设置在0.7到1.0之间给模型更多发挥空间。这两者相互影响如果你的提示词已经非常明确哪怕温度设成1.0模型也不会跑太远但如果你的提示词本身模糊温度又高结果就会像脱缰的野马。我的习惯是先把温度调低验收提示词本身的效果再逐步升高温找到“稳定与创造性”的平衡点。不要把温度当作提示词质量的遮羞布。3.3 谁是最重要的Token位置偏置与指令漂移还有一个容易被忽视的细节大模型对指令的注意力并不是均匀分布的。研究表明模型对文本开头的指令位置偏置和结尾的指令近期效应响应更好中间部分容易被稀释。这意味着如果你的提示词非常长核心约束条件放在了中段模型很可能“看着看着就忘了”。针对这个特点我写长提示词时有一个习惯把最重要的指令放在开头和结尾各强调一遍。开头写“你是一名数据分析师必须严格按照以下JSON格式输出”结尾写“再次强调不要输出任何JSON以外的内容”。虽然听起来有点啰嗦但实测下来对模型输出的合规率提升非常明显。4. 系统提示词与用户提示词的边界Agent场景里的分工技巧4.1 为什么需要“双轨制”提示词在Agent开发中尤其是用API直接调用大模型时你通常会看到两个字段system prompt系统提示词和user prompt用户提示词。很多初学者把内容全塞在user prompt里这能跑但跑不出高质量。系统提示词的定位是“长期不变的规则层”它定义了模型的身份、工作原则、输出约束、禁止事项。用户提示词的定位是“每次请求的输入层”它承载的是具体任务、临时数据、即时问题。两者分离的好处是你可以把系统提示词当作“不变的代码框架”把用户提示词当作“传入的参数”这样既方便维护也让模型更容易区分“哪些是规则哪些是本次要处理的内容”。举个例子。我做一个“简历筛选Agent”时系统提示词里写了你是一名招聘专家有10年HR经验。你必须根据给定的职位要求评估候选人只输出一个JSON对象。如果简历信息不足以判断必须在备注字段里写“信息不足”不允许猜测。用户提示词里再传具体的职位要求和简历文本。这样无论来多少份简历系统提示词都保持不变模型始终知道自己的任务边界。如果你把系统内容也塞进用户提示词里每次请求都要重复一大段而且模型容易把“规则”和“待处理数据”混在一起处理效果就会打折。4.2 “习惯性指令漂移”如何避免我在实战中遇到的一个真实问题是模型处理几条消息后会逐渐“忘记”系统提示词里的某些规则尤其是比较长的规则。这被称为指令漂移。为什么会漂移因为每次对话都是把历史消息拼接起来作为输入当用户消息越来越长系统提示词占比越来越小模型注意力就会被后面新内容带跑。解决办法有几个按推荐顺序排列尽量缩短系统提示词把核心规则提炼到模型“不可能忽略”的程度。如果规则确实很多不要全部写在系统提示词里而是把规则做成“工具调用”或“代码分支”别指望模型凭记忆遵守所有规则。关键规则在每次用户消息前用一条简短的reminder重申。比如“记住只输出JSON。”这里有一个引申概念在Agent中不能把提示词当成唯一的能力来源。如果某个约束真的不能被突破你应该在代码层面拦截而不是只靠提示词。比如“不允许访问外网”这种硬性要求应该通过网络权限控制实现而不是在提示词里写“你绝对不能访问外网”。模型没有这个执行力它只会假装遵守。4.3 系统提示词工程和Skill/Agent的区别最近大家经常讨论“系统提示词工程”和“Skill/Agent”的区别。我个人的理解是提示词是Agent能力的“瘦客户端”Skill则是可复用的“行为包”。Agent是一个完整的决策执行循环它包含了大模型、提示词、工具、记忆、以及编排逻辑。单纯堆砌复杂的系统提示词并不等于做了Agent只有把提示词和工具调用、状态管理等代码逻辑结合起来才能形成真正的智能体。举个简单的区分方式系统提示词回答的是我是谁我怎么回答。Skill回答的是我遇到什么情况我该调用什么工具、执行什么步骤。Agent回答的是面对一个目标我如何拆解、决策、行动、反思。这三者不是对立关系而是层层包裹的关系。系统提示词是Agent的骨架Skill是器官Agent是完整的生命体。刚入门的朋友不用急着区分这些概念但心里要有这个层次否则很容易把“提示词越复杂越好”当成真理最后做出一个“什么都懂但什么都干不成的聊天机器人”。5. 上下文工程当提示词装不下整个世界时5.1 提示词有长度限制但任务往往没有随着你写的提示词越来越成熟你会遇到下一个瓶颈上下文窗口装不下了。比如你要让模型分析一份50页的文档或者给一个包含几千行历史记录的对话总结上下文。这时候单纯的提示词工程就不够了要进入“上下文工程”的范畴。上下文工程的核心思路是不是把全部信息硬塞给模型而是有选择地组织、压缩、排序信息让模型在有限的窗口内拿到最相关的内容。这也是很多Agent框架里Retrieval检索模块存在的意义——先检索出和当前任务最相关的片段再拼接到提示词里而不是一股脑全传进去。我在做一个“客服知识库Agent”时客户的知识库有几百篇文档远超上下文窗口。一开始我试图把所有文档都塞进系统提示词结果模型要么忽略大多数内容要么幻觉频出。后来改成“向量检索重排”的方案先把文档切片成段落并做向量化用户提问时检索出最相关的5-8个片段再和系统提示词拼接起来。效果立竿见影准确率大幅提升成本也降下来了。5.2 上下文窗口里的“记忆分层”在Agent对话中上下文不仅要管“外部知识”还要管“多轮对话的历史”。这里我有一套自己的“记忆分层”策略分享给大家基础层系统提示词不变的规则和身份。尽量压缩到500字以内。工作层最近对话最近3-5轮的用户指令和模型响应保留原始细节。压缩层历史摘要更早的对话由模型每10轮生成一次摘要用摘要代替逐字记录。外部层数据库/检索需要时通过工具查询不常驻上下文。这套分层方案像不像人类的大脑我们会记住最近聊了什么对几天前的细节靠回忆而对长期事实则依赖笔记。Agent的上下文管理本质也是如此。如果你把每一轮对话都原样留在上下文里几轮之后Token就爆炸了而且模型会被越来越久远的噪声干扰反而忘了当前的目标。5.3 自定义工具“清洗上下文”的野路子除了常规方案我有一个自己常用的“野路子”在Agent工具列表里加一个“对话压缩工具”。每次对话长度超过一定阈值就让模型调用这个工具把当前对话整理成一份结构化摘要然后清空中间对话历史只保留摘要和最新几轮。这个工具本质上也是让大模型自己写摘要但把它封装成工具后模型会明确“这是它主动执行的维护动作”而不是“用户要求它总结”执行起来的稳定性和时机把握都更好。有人可能会问让模型自己压缩历史不会丢失信息吗确实会但总比Token爆掉强。而且我们可以通过摘要模板来引导压缩重点不仅总结“说了什么”还要总结“做了什么决策”“有哪些未完成事项”“用户情绪如何”。这样压缩后的摘要反而更有利于后续任务的连续性。6. 一个完整的实战案例把糟糕提示词迭代成可用Agent6.1 初始版本一句话需求结果惨不忍赌为了让大家直观看到调优过程我分享一个真实案例做一个“竞品分析Agent”输入一个竞品名称输出一份结构化分析报告。第一版提示词很简单“你帮我分析一下竞品XX输出一份报告。”实际跑出来的结果是模型在没有任何真实数据的情况下编造了一堆“XX公司成立于2010年核心产品是……”看着像模像样实际全是幻觉。而且输出格式是散文体后续代码根本没法解析。这个版本的问题很明显角色缺失、任务模糊、没有约束、没有示例、没有格式要求。但有趣的是很多人初学提示词时写出来的就是这样。因为我们下意识觉得“AI什么都知道”实际上它只是“什么都能编”。6.2 结构化后的版本规则清晰但还不够第二版我把提示词重写成了这样角色资深市场分析师任务基于公开可验证的信息分析竞品XX的核心产品、定价策略、目标用户、市场定位、优缺点。约束如果你不确定某些数据不要编造标注“需要人工核实”只使用我提供的资料不要自行搜索假设。格式输出Markdown包含以上五个章节每个章节至少100字末尾给出综合评分1-10分。示例提供了一个简洁的Markdown输出样例。这次模型的表现好了一大截至少格式对了也不再大面积编造华而不实的内容但它仍然有一些“惯性编造”的残留在“定价策略”部分依然会写出类似“据公开资料显示其定价在XX美元左右”这种没有来源的信息。为什么因为我用了“公开可验证的信息”这种含糊表述模型不知道哪些算“公开可验证”只能凭感觉编。6.3 引入“信息来源标注”后的最终版于是我在约束里加了一条硬性规则每一项数据后面必须标注来源官网、财报、新闻、未知。如果是未知直接写“未知”禁止推测。这一条加上后效果发生了质变模型宁可写“未知”也不愿意编造了。因为“标注来源”这个动作打破了它凭空生成内容的顺畅回路。最终版本跑下来的结果虽然不是每一条都百分之百准确但至少每条都有出处哪些可信哪些不可信一目了然。我再在Agent的代码层加了一个过滤如果某章节出现三个以上的“未知”就触发人工介入流程。这样整套系统才能真正拿出去用而不是只在测试集上“看着还行”。这套迭代过程告诉我一个道理提示词调优本质上是在约束模型的能力边界而约束的抓手必须落在模型能明确执行的指令上。“不要胡说八道”是无效的“每项数据标注来源”是有效的。你在设计提示词时永远要问自己这句话模型有没有一个明确的操作抓手7. 关于提示词调优你可能不知道的五个“暗坑”7.1 “反向提示”是双刃剑很多人喜欢在提示词里写“不要输出JSON以外的内容”“不要使用列表”以此强调规则。但心理学和模型行为学研究都表明模型对“不要X”这种反向表述的理解往往不如正向表述可靠。因为它在生成Token时会把“不要”和对应的概念都激活反而增加了“输出JSON以外内容”的概率。我的建议是尽量用正向表述代替反向表述。比如“不要输出无关内容”改成“只输出与JSON格式一致的内容任何其他文字都不允许出现”。后者给模型提供了明确的替代路径。如果实在需要反向强调也请放在正向指令之后作为补充不要让反转指令成为主导。7.2 示例会“带偏”任务选示例要刻意给模型参考示例时示例不能只是“格式正确”内容导向也很关键。如果你给出的示例是一份“正面分析”的范文模型就会倾向于照搬这种风格和结论结构如果你希望模型有时要输出“负面看法”就必须在示例里涵盖这种负面表达否则模型会默认“顺着示例的语气走”。更严重的是示例中的细小错误会被复刻。比如你的示例里有一处笔误模型可能会原样模仿这个笔误。所以示例一定是你亲自验过、没有任何瑕疵的“金标准”而不是随便从网上复制一段看起来差不多的文本。7.3 千篇一律的角色设定会降低区分度“你是一名AI助手”是很多人的默认角色但这是最没区分度的角色设定。它告诉模型的信息量几乎为零。同样是整理会议纪要你用“你是一名高管助理”和用“你是一名AI助手”去跑产出的详略、口吻、结构化程度会差异很大。角色设定的价值在于让模型从训练数据中激活更符合目标场景的语域。不要怕给角色加细节“你有15年投资银行从业经验习惯用数据说话”这种设定会让模型的输出更有场景感。7.4 长提示词不一定更好有时候“减”才是“加”我见过不少同行为了追求稳定把提示词写成一篇小论文从背景到方法论到道德规范事无巨细。结果模型在长文本里迷失方向执行效率反而下降。大模型有“注意力稀释”问题前面提到过核心指令被淹没在大量修饰语里等于没有指令。我的策略是提示词遵循“最小充分原则”。能说清楚任务的不额外加背景能用一个词说清楚的不用一句话。把“为什么”写进你的思考笔记里就够了不要都塞给模型。模型不需要知道你为什么要做这件事它只需要知道做什么、怎么做、输出什么。7.5 提示词和代码之间要有“多次握手”最后是一个工程层面的坑很多人把提示词的输出直接当作最终结果没有在代码层做二次校验。比如要求模型输出JSON但模型偶尔会在JSON前后多出说明文字导致json.loads直接报错。我通常会在代码里做一次数据清洗和schema校验如果不符合要求就带着错误信息再回传一次给模型让它重新生成。这种“重试机制”比追求提示词“一次成功”要务实得多。提示词工程再怎么调也避免不了模型的概率性偶发代码层兜底才是Agent稳定的最后防线。8. 别急着背模板先建立你自己的提示词“测试集”8.1 为什么调优必须数据驱动我见过太多人调提示词靠感觉这一版不行加两句试试那版又说多了删掉再看。这样调上一天很难说清到底是哪个改动发挥了作用。提示词调优也应该像做软件测试一样维护一个固定的“测试集”。测试集里放10到20个典型用例覆盖了你Agent要处理的核心场景、边缘场景、异常场景。每次改动提示词就用这组测试集跑一遍对比输出质量的差异。没有测试集你只是在碰运气有了测试集你才能像看代码回归测试一样量化提示词变更带来的影响。我自己维护测试集的方式很简单用一份Excel表记录每条测试用例的“通过/部分通过/未通过”并在“部分通过”栏里写清失败原因。这样每次调整提示词后我都能准确知道哪些场景变好了哪些场景变差了而不是被一两个成功案例蒙蔽。8.2 如何构建一个实用的测试集构建测试集时不要只挑容易的场景。我建议按这样的比例分配核心场景50%用户最常问的那几类问题需要保证高质量。边界场景30%输入缺字段、信息不足、情绪化表达、间接提问等。异常场景20%超出任务范围的问题、恶意或不合理请求、空输入等。这些异常场景尤其重要因为Agent在实际使用中遇到的用户输入远比你想象中的更奇怪。比如我的客服Agent上线后收到了“你是真人吗”“我要找你老板投诉”“你帮我写作业”之类的请求。如果提示词没有覆盖这类情况模型就可能产生不合预期的回应。在测试集里提前设计好应对策略比事后紧急补提示词要靠谱得多。8.3 把调优结果固化为“提示词版本”最后我强烈建议你像管理代码一样管理提示词版本。每次改动记录下日期、改动内容、测试集通过率、以及典型失败的截图或日志。别小看这一步我因为在同一个Agent上调过太多次提示词好几次想回退到某个“当时效果还不错”的版本结果发现自己根本记不清当时具体写了什么。用Git管理提示词文本是一个好习惯。你的提示词文件、测试集、评估结果都可以纳入版本控制。这不只是“规范化”更是让你的Agent迭代过程可追溯、可复盘的前提。要知道提示词工程做到后面瓶颈往往不是你的语言表达能力而是你的实验方法和管理能力。