智能体提示词这事儿，最近后台咨询量明显上来了。很多人拿着大模型跑得很溜，一碰到Agent就抓瞎，总觉得模型“不听话”，拆解不了任务，或者调工具时频繁出错。问来问去，问题多半不在模型能力上，而是出在喂给智能体的那段提示词上。
我在实际项目里调试过不少智能体，从简单的对话机器人到复杂的多步任务流都有涉及。今天这篇就把我自己写智能体提示词的核心方法论、真实踩过的坑，以及可以直接抄走的模板框架一次说清楚。内容会有点长，但保证全是实操层面的硬货，新手能当入门指南，有基础的朋友也能对照着查漏补缺。
1. 为什么Agent的提示词和普通提示词不是一回事
1.1 普通对话与智能体任务的本质差异
先做个对比。你用普通对话提示词问模型一个问题，它只需要理解意图并给出一个答案。但智能体不一样，它要完成的是“理解意图 → 拆解步骤 → 调用工具 → 观察结果 → 调整策略 → 输出结论”这样的闭环。这中间的每一步，都依赖提示词去约束和引导。
我常打一个比方：普通提示词是给一个实习生布置一道题，说清楚题目就行；智能体提示词是给一个项目负责人下指令，你得告诉他目标是什么、有哪些资源可以用、遇到什么情况该找谁、哪些红线不能碰、最后要交付什么形式的结果。这里面的信息量完全不是一个量级。
我第一次做Agent项目时犯过一个典型错误：把给ChatGPT写问答提示词的思路直接套到Agent上。结果就是Agent经常死磕一个问题不放手，或者死活不肯调用该用的工具，甚至出现了把一句话重复生成五遍的怪事。后来才明白，智能体提示词需要额外承载三层信息，缺一不可：
- 角色职能边界：这个Agent是谁，负责什么，不负责什么。
- 环境交互规则：它手上有哪些工具，什么情况下必须用，什么情况下禁止用。
- 任务循环控制：一轮动作完成后，如何判断结果是“可交付”还是“需要继续”。
这三层内容，普通对话提示词里基本不会涉及，却是智能体能不能稳定工作的根基。
1.2 从单轮问答到多轮任务循环的转变
普通提示词的触发逻辑是“问-答”一次就结束，但智能体往往要跑多轮。每一轮里，模型要自己做决策：是继续搜索信息、调用工具，还是直接输出最终答案。这种决策能力，一部分靠模型底座，另一部分完全靠提示词中的决策指引。
举个真实场景。我做一个信息收集类的Agent时，最初提示词只写了“帮我搜索资料并总结”。结果它在第一次搜索后就开始总结，完全无视还有两个重要信息源没查到。后来在提示词中加入了这样一段：
在完成最终总结前，你必须至少完成三次信息获取。每次获取后，检查现有信息是否覆盖了用户的全部问题点。如果有遗漏，继续搜索；只有全部覆盖或确定某信息无法获取时，才可以输出最终结论。
加了这段之后，Agent的工作轨迹立刻变得可预测了。这就是多轮任务循环和普通对话的本质区别：提示词要教给模型的不只是“回答什么”，更重要的是“下一步做什么、什么时候停”。
2. 写智能体提示词前必须想清楚的四个问题
2.1 目标定义：到底希望Agent交付什么
很多提示词写不好，根源在于写的人自己都没想清楚这个Agent到底要交付什么。是产出一份报告？一个结构化数据？还是一个完成特定操作的结果？交付物定义得越具体，提示词就越容易写。
我自己的经验是，目标定义至少要包含三个维度：
- 交付物形态：一段文字、一份表格、一个JSON、还是某个系统里的状态变更？
- 质量标准：什么样的结果算好？比如字数范围、信息源的权威性要求、格式规范。
- 完成边界：做到哪一步就可以停止，不需要额外发挥。
比如我帮某电商团队做一个竞品分析Agent时，最初目标描述是“分析竞品详情页”。这个描述太模糊了，Agent给出的结果每次都不一样。后来改成这样：
生成一份竞品详情页分析报告，输出为Markdown表格，包含以下字段：竞品名称、主图卖点、价格策略、促销活动、评价高频词、差异化建议。只分析用户指定的竞品店铺，不主动扩展其他竞品。单次任务输出不超过500字。
目标一具体，后面的所有环节都顺了。
2.2 工具边界：哪些能用、哪些不能用、何时用
智能体区别于普通对话模型的最大特征就是工具调用，而这恰恰是提示词工程里最容易翻车的地方。工具边界没有定义清楚的情况下，常见的翻车姿势有两种：一种是模型该调工具时不调，凭记忆瞎编；另一种是不该调时狂调，浪费token还拖慢响应。
我建议在提示词里单独开一个“工具使用规则”区段，明确三件事：
- 每个工具的触发条件：什么情况下必须调用、什么情况下禁止调用。
- 工具的输入要求：调用前需要准备哪些参数，参数从哪来。
- 工具的结果处理方式：拿到结果后，是直接引用、需要二次加工，还是当作决策依据。
举个例子，如果我给Agent配了天气查询工具和穿衣建议生成器，那提示词里就要写清楚：查询天气后要对比用户所在城市与目标城市的温差，再决定调用哪个穿衣建议模板。如果不写这一步，模型就可能拿到天气数据后直接套一个通用模板，完全不管适配性。
2.3 约束条件：速度和质量的取舍标准
智能体的响应速度和输出质量往往是一对矛盾。提示词里如果不明确取舍标准，模型就会默认选择“最稳妥”的方式——也就是多跑几轮、多调几次工具，结果用户等得不耐烦。
我通常会在提示词的约束区段放一条显式的速度与质量权衡逻辑。例如：
如果用户明确要求“快速回答”，则最多调用一次工具，基于已有知识回答，不追求信息完整性；如果用户没有明确速度要求，则优先保证信息完整，最多调用三次工具。
有了这条之后，Agent在高并发场景下的表现会稳定很多。用户提了一个简单问题，它不会莫名其妙地连搜五次资料才肯回答。
2.4 上下文管理：哪些记忆要保留，哪些要丢弃
多轮对话场景下，上下文管理是智能体提示词里绕不开的话题。我见过不少开发者把“万物皆可记”当成默认策略，结果对话进行到第20轮时，上下文爆炸，模型开始把前面几轮的错误结论当成事实使用。
更好的做法是在提示词里定义清晰的“遗忘策略”：
- 哪些信息需要长期记住，比如用户偏好、项目关键参数、历史决策结论。
- 哪些信息是一次性的，用后即弃，比如中间计算过程、临时查询结果。
- 当上下文空间不足时，优先丢弃哪类信息。
实际操作中，很多智能体框架会提供“记忆窗口”或“摘要压缩”功能。但提示词里还是得写清楚优先级，否则框架的默认策略可能和你的业务逻辑打架。
3. 我一直在用的智能体提示词六要素框架
3.1 角色设定：不是“你是谁”，而是“你被期望成为谁”
角色设定是智能体提示词的地基，但很多人理解偏了。写角色时不要只写“你是一个智能助手”，这种设定对模型的行为约束力几乎为零。有效角色设定要包含：身份、职责边界、专业倾向、行为禁忌。
我常用的一种写法是这样的：
你是某公司的售后客服智能体，负责处理退换货、物流查询和产品使用问题。你不负责处理订单修改、价格谈判、投诉升级等超出范围内的需求。当遇到超出范围内的问题时，明确告知用户转接人工客服，不得自行处理，不得编造处理结果。
注意，这里面既有加分项（专业倾向），也有扣分项（行为禁忌），还有边界场景的处理方式。信息密度很高，模型才能精准执行。如果你只写“你是客服”，模型会在遇到任何问题时都硬着头皮回答，编造成本极低、出错概率极高。
3.2 工作流拆解：从目标到步骤的可执行路径
提示词里最值钱的部分，就是把模糊目标拆解成模型的每一步动作。这一步做得好不好，直接决定了Agent的智能程度和稳定性。
我通常会给出一个明确的步骤清单。以摘要类Agent为例：
执行步骤如下：
- 接收用户提供的文档链接或文本，确认可读性。
- 提取文档中的核心论点、关键数据、结论，忽略细枝末节。
- 将提取结果按照“背景-核心观点-数据支撑-结论”的结构整理。
- 输出前检查是否遗漏用户指定关注的信息维度，如有遗漏则补齐。
- 输出最终摘要，控制在300字以内。
别小看这种清单式的指引，它等于给模型画了一条思考轨迹线。没有这条线时，模型可能在“提取论点”和“生成摘要”之间反复横跳，输出非常不稳定。有了这条线，模型的每一次输出都像是同一个人写的。
3.3 约束与反模式：告诉模型“不要做什么”
做提示词的朋友应该都有体会：光是告诉模型“要做什么”是不够的，还必须明确告诉它“不要做什么”。智能体场景下尤其如此，因为Agent有工具能力和行动自由度，“做什么”的诱惑比纯对话模型大得多。
我整理过一份高频反模式清单，几乎每个Agent项目里都能用到几条：
- 不要编造工具调用结果，如果工具返回异常，如实报告错误。
- 不要重复询问同一信息，优先基于上下文推断。
- 不要输出与用户问题无关的信息，禁止主动扩展内容。
- 不要连续多次调用相同工具而不改变策略。
- 不要在未获得用户确认时执行有副作用的高风险操作。
这些“反模式”不是一次性写进去就完事了，而是要跟着Agent的实际运行情况持续迭代。每次出现新的负面行为，就把它补充到反模式区段里，一次加一条，效果会越来越好。
3.4 输出格式控制：结构化之外还要防幻觉
输出格式控制是提示词工程里的基本功，但智能体场景下，格式问题还会延伸到工具调用和中间输出。我见过不少团队，最终答复格式没问题，但中间调工具时参数格式乱掉，或者把中间日志和最终输出混在一起。
我的做法是单独定义两类输出格式：交互输出格式和工具调用格式。交互输出格式控制用户能看到的回复；工具调用格式则控制模型在每一轮决策时怎么选择、调用并解释工具。把两者分开，逻辑清晰很多。
另外还要专门防幻觉。做法是在提示词里加一条输出置信度指令：
当你不确定某个事实、数据或信息来源时，必须明确标注“信息未验证”，不得使用肯定语气给出猜测性结论。宁可少给一个信息，也不要多给一个编造的信息。
加了这条之后，Agent在信息不足时的“一本正经胡说八道”现象会明显减少。
3.5 迭代提示：Agent如何自我修正与重试
智能体执行任务的过程中，出错几乎是必然的。提示词里如果没有定义“出错之后怎么办”，模型就会在错误路径上越走越远，或者反复重试完全相同的操作。
我建议在提示词中加入一个重试机制区段，大致逻辑是：
当工具调用失败时，先分析失败原因。如果是参数错误，修正参数后重试一次；如果是网络或服务不可用，等待10秒后重试；如果连续三次失败，停止尝试，告知用户当前服务异常。 当输出被判定为不符合要求时，检查是对要求的理解偏差还是信息缺失。如果是理解偏差，重新解读要求后再次生成；如果是信息缺失，补充获取信息后再次生成。
这套重试机制写进去之后，Agent的“老板感”会弱很多，不再为了交差而盲目重复，反而会展现出一种类似真实员工的解决问题思路。
3.6 成功标准：让Agent知道“完成了是什么样子”
最后这个要素最容易被忽略。很多提示词把任务目标写得天花乱坠，但从未定义“完成的判据”。没有完成判据，Agent要么永远不知道何时停止，要么草草收场输出一个半成品。
我通常会在提示词末尾写一个“完成检查清单”：
输出最终答案前，请检查以下项目：是否覆盖了用户的所有问题点；是否包含有效数据或引用来源；是否遵循了指定的输出格式；是否超出了字数或复杂度限制。所有检查项通过后，才能输出最终答案。
这个检查清单往小了说能提升交付质量，往大了说能直接改变Agent的行为模式，让它从“能跑就行”变成“跑完要跑好”。
4. 从零到一：一个内容质检Agent的完整提示词实操
4.1 背景设定与提示词初稿
前面讲了不少方法论，这部分我用一个完整的案例，把整套东西串起来。假设我要做一个“内容质检Agent”，用来审核团队内部的推文草稿，检查语法问题、事实错误、情绪倾向，并给出修改建议。
初版提示词我可能会这样写：
你是一个内容质检专家，负责审核用户提交的推文草稿。请检查语法错误、事实错误和语气问题，并给出修改建议。
看起来很完整？实际跑起来问题不少。最大的问题就是：模型没有工具可用——它判断“事实错误”时只能凭自身记忆，出现误判的概率很高。另一个问题是输出没有结构，建议写得很散，用户根本不知道优先改哪里。
这正是很多Agent项目从Demo到可用之间巨大鸿沟的缩影：提示词框架不完整，工具未接入，输出没有约束。后面按六要素框架去拆解补齐，效果完全不一样。
4.2 补全工具配置与决策规则
针对初版的缺陷，我做了第一轮升级，核心是给Agent配备事实核查工具，并在工具使用规则区段写明触发条件和决策逻辑：
工具：事实核查数据库 触发条件：当草稿中出现具体数据、人物头衔、事件时间等可核验信息时，必须调用该工具核实。 禁止情况：对主观判断内容、个人观点等内容不进行事实核查，避免过度审核。 处理逻辑：如果工具返回“信息有误”，在反馈中明确指出错误原信息和正确信息；如果返回“无法核验”，标为“待确认”而非直接判定错误。
这个改动非常关键，因为我意识到模型自己觉得“正确”的事实不一定真的正确，只有把事实核查从“模型脑内”搬到“工具协作”上，质检结果才真正有可信度。
4.3 模拟一次完整质检流程
工具配好后，我又在提示词里补了工作流拆解，保证整个质检过程有清晰路径。完整流程大概是：
- 接收推文草稿，判断文本长度和主题。
- 提取所有可核验事实点，整理成待核查清单。
- 依次调用事实核查工具，逐条比对，记录结果。
- 对全文做语法检查和语气扫描，输出问题清单。
- 按严重程度分级：严重事实错误 > 轻微事实偏差 > 语法问题 > 语气建议。
- 输出结构化的质检报告，包含原文引用、问题描述、修改建议三列。
加了这个工作流之后，质检Agent的输出稳定度提升很多。真实用户一眼能看出这个Agent不是“读一遍就给几条模糊建议”，而是真的在做系统性审核，建议的颗粒度细到了“第几段的第几句、引用了哪个数据、建议怎么改”。
4.4 多轮对话中的记忆与上下文控制
内容质检Agent还有一个特殊需求：用户会反复上传不同草稿，希望Agent记得团队的行文规范和过往反馈风格。这种场景下，上下文管理就很重要了。
我在提示词里专门加了规范记忆区段：
用户上传草稿时，如果上传前附带或使用过“团队规范”，请将规范内容作为本次审核的最高优先级标准。规范与通用标准冲突时，以规范为准。对话进行中，你不需要记住每一份草稿的具体内容，每次新草稿视为独立任务，但需要记住团队规范和历史审核偏好。
这里的关键点是“记住规范、忘记内容”。很多Agent工程师在上下文管理上吃过亏，恨不得让模型记住一切，结果规范被内容稀释，审核标准越来越飘。明确了取舍逻辑，长期对话的质量才稳得住。
5. 高频踩坑记录与排查方法
5.1 智能体跑飞了：不按提示词执行怎么办
“跑飞”是Agent场景里最高频的抱怨。用户给了一句“帮我看看这个报告的逻辑问题”，Agent倒好，先联网搜了作者的背景资料，又写了一篇竞品分析出来。问题就出在约束不硬。
排查思路一般是三步走：
- 第一步，检查是否有明确的“不做什么”区段。如果没有，先补上。
- 第二步，检查目标定义是否有歧义。“看看逻辑问题”本身就很模糊，改成“只审视论证结构、指出逻辑断点、不扩展任何外部信息”试试。
- 第三步，检查是不是模型本身的指令遵循能力不够强。如果是，可以升级底座模型，或把关键指令重复强调两次。
我在实践中发现，极多“跑飞”案例的根因，是指令里有歧义而不是模型笨。把指令改精确之后，问题消失的概率高得惊人。
5.2 提示词越长越不听话？可能是犯了堆砌病
有一种很常见的误解，觉得提示词写得越长越详细越好。但实测下来并非如此。提示词太长时，模型对关键指令的注意力会被稀释，尤其在Agent任务循环中，长提示词会显著加剧指令冲突和上下文浪费。
我见过一个团队，把提示词写到了上万字，几乎把整个业务手册塞进去了。结果Agent在关键时刻频频无视核心约束，反而被那些低频的边缘规则带偏了节奏。
我自己的体感是：提示词长度应该保持在“刚好覆盖所有必要要素”的程度。一个实用原则是，与核心任务无关的背景介绍能短就短；与核心任务直接相关的操作规则，宁可多写几行也要写透。给提示词做定期“剪枝”——每次迭代时删掉不再生效的旧指令，合并重复啰嗦的表述，这样才能保持提示词的精炼和指令权重。
5.3 工具调用混乱：参数错误到疯狂空转
工具调用是Agent的另一大翻车重灾区。常见症状包括：模型反复调用同一个工具但每次参数都缺位；拿到工具返回结果后不知道怎么用，继续空转；甚至为了凑够调用次数而调无关工具。
这类问题排查时，先把工具描述写得足够清晰。很多框架会把工具描述喂给模型来决定调用行为，而描述里的“模糊词”会导致一连串参数错误。比如“获取天气”这种描述就太笼统了，改成“获取指定城市未来三天的天气预报，返回最高温、最低温、降水概率，输入必须是城市名简体中文”会好很多。
另一个技巧是在提示词里限制工具调用的最大次数。比如加一条“单次任务中，工具调用总次数不得超过5次”，Agent就不会陷入无限空转的圈子里出不来。
5.4 提示词迭代的版本管理与回归测试
最后这条是给已经上手的读者的。写智能体提示词是一个持续迭代的过程，我就栽过“改爽了但改坏了”的跟头。有一次为了增强格式适配，调了几个约束词，结果直接导致工具调用率从60%跌到20%，整体效果反而大幅退化。
这里强烈建议做两件事：提示词版本管理和回归测试。每改一版，就存一个带版本号的记录，说明改了什么、为什么改、预期效果是什么；每次改完，先跑一遍固定的测试集（比如10条标准任务），确认老功能没坏，再去看新功能的收益。这样看起来有点繁琐，但长远来看，它省下的调试时间几倍于这点维护成本。
6. 关于工具链与提示词组合的几条心得
写智能体提示词这件事，工具链选型也很重要。目前主流的Agent框架大多支持可视化编排和代码式编排两种形态，我自己的倾向是：复杂项目先用代码式把逻辑理清楚，然后配合可视化面板做快速验证，二者并不冲突。
提示词的存放方式也值得讲究。强烈建议把提示词和代码分开存放，采用配置文件管理。这样提示词的调试不需要改代码、重新部署，几秒钟就能完成一轮迭代，效率会高很多。我见过太多人把提示词直接硬编码在代码里，每改一次都要走一次发版流程，极其痛苦。
另外，有条件的话请务必记录Agent的每一次调用日志。日志里能看到模型实际采取的决策路径、工具调用序列、以及最终输出。很多提示词问题，单看提示词本身是看不出来的，一看日志就一目了然，比如“它调用工具的顺序和我想的不一样”“它拿到结果后又绕了一圈”。日志是提示词迭代的最重要依据，没有之一。
关于智能体提示词，我在实际调试中收获最大的一点是：它其实是一个动态演化的系统，没有一劳永逸的完美版本。从初稿上线，到根据日志逐步微调约束、补充反模式、优化工具规则，每一步都是增量改进。现在我的习惯是，任何新Agent项目都先按六要素搭一个基础版本，让它在真实环境里跑一段时间，再根据实际问题做针对性修改，而不是做“一次性到位”的幻想。
写提示词和带新人很像，你把边界划得越清楚，期待管理做得越明确，反馈机制定得越具体，对方的稳定性和可靠性就会越高。这大概是智能体提示词这份工作里，最接近“人心”的部分了。
