1. 为什么 Agent 的提示词比聊天场景重得多大多数人第一次接触提示词都是从聊天开始的让 ChatGPT 写个朋友圈文案让它总结一篇文章话说不清楚就换个说法再来一次。到了 AI Agent 这边事情完全变了。Agent 是一个会自己干活的程序你给它一个目标它自己决定调哪些工具、按什么顺序、怎么处理中间结果。而这个程序唯一的存在形式就是提示词。换句话说提示词就是 Agent 的源代码。聊天场景里提示词只影响一次输出Agent 场景里提示词影响的是一个循环。这个循环大致长这样模型理解任务 → 决定要用哪个工具 → 输出调用请求 → 系统执行工具 → 把结果喂回给模型 → 模型再决定下一步。如此反复直到任务完成。每一轮都在消耗上下文每一轮的决策都依赖之前的信息。提示词在这个循环里干的活不只是把任务说清楚还包括告诉模型怎么决策、怎么纠错、怎么终止。打一个不太严谨但很好懂的比方跟聊天模型说话像跟一个聪明但没经验的实习生交代一件事跟 Agent 说话像给新人写岗位说明书和工作流程——他不仅要听懂做什么还要知道什么情况走什么流程出错了怎么办做完怎么汇报。这也是为什么很多人在会用大模型之后栽在 Agent 开发上他们以为提示词就是把话说好听点结果搭出来的 Agent 要么跑偏要么在一件事上反复横跳要么自己编造工具结果。问题几乎都出在提示词层。这篇是系列的第二期就围绕怎么让大模型真正听懂你说话展开重点挑那些能立刻用到 Agent 开发里的东西讲后面第三期开始碰 RAG 和多工具编排时你会发现今天这些内容全是地基。1.1 提示词工程不是讨好模型而是设计决策逻辑我见过很多新手有个误解觉得提示词就是求模型干活语气越客气越好。其实模型没有情绪提示词工程的本质是控制信息空间你放进上下文里的每一句话都在影响模型对任务的概率判断。在 Agent 里这个判断直接决定行动。比如同样是查一下这个公司最近有没有融资这条任务如果你不告诉模型只能使用 search_web 工具查不到就换关键词再试一次它可能会直接用训练记忆里的过期信息回答你调用了工具但看不懂返回结果然后自己编一个结论查一次没有结果就放弃也不告诉你。这些都不是模型笨是你在提示词里没有定义决策规则。所以提示词工程在 Agent 场景下本质上是给模型写一套可执行的决策逻辑。这个观念不转过来后面写再多技巧都是花架子。2. 提示词背后的机制上下文窗口、注意力与顺序效应在给技巧清单之前我想先补一层底层知识。很多人写提示词是凭手感——感觉对了就发不对就改。手感当然重要但如果你知道模型内部是怎么处理这些文字的调试速度会快很多。模型每次推理时能看到的全部信息就是我们拼进上下文窗口的那一串 token。它不知道你是谁不知道这个任务从哪来不知道你之前改过多少版它唯一的输入就是这串文字。所以提示词工程的本质可以概括成一句话在有限的上下文里用最有利于模型分配注意力的方式组织信息。2.1 中间遗忘越长越容易漏重点要放头尾实测下来模型对上下文开头和结尾的内容最敏感对中间部分相对麻木。你写系统提示词的时候如果把最重要的约束藏在第三段、第五句它可能真的会漏。我自己的习惯是最重要的规则放最前面第二重要的放最后面中间放补充说明。这条经验对 Agent 尤其重要。因为 Agent 的上下文会随着工具调用不断变长第一轮的工具返回、第二轮的结果、第三轮的日志……全都在拼接。如果一个关键约束写在系统提示词的第一段它距离模型当前正在处理的 token 可能已经隔了几千字。这时候要保证模型还记得它有两个办法一是把关键约束在用户请求里再强调一次二是用格式标记比如 XML 标签把它跟其他内容隔离出来。2.2 上下文工程别让提示词背锅最近上下文工程这个词很火我觉得它比提示词工程更准确。提示词只是模型能看到的信息的一部分RAG 检索结果、工具返回的日志、历史对话记录全都会进上下文。上下文里垃圾太多提示词写得再好也救不回来。我踩过一个大坑某个 Agent 需要读取数据库查询结果工具返回了一段很长的 JSON里面有个字段叫status表示数据状态。系统提示词里明明写了仅使用 statusactive 的数据但模型经常忽略。排查到最后发现工具返回的 JSON 里字段名跟接口文档不一致有的叫status有的叫state模型看花了眼。后来我在工具描述里明确写了返回结构示例问题才解决。所以调提示词之前先检查上下文里有什么。很多提示词不生效的问题其实是信息在上下文里已经烂掉了——格式混乱、重复冗余、关键字段被淹没。先把上下文理顺再回头调提示词。3. 系统提示词的四根支柱角色、规则、格式、边界Agent 开发的标配是 system prompt系统提示词。它相当于是给 Agent 立规矩的那份文档。我每次写系统提示词都会按四个支柱自查角色、规则、格式、边界。缺哪一个后面都会出奇怪的问题。3.1 角色定义决定模型的行为基线角色不是扮演是在给模型一个行为基线。同样是遇到一个模糊任务你是一名严谨的数据分析师和你是一名随性的创意写手接下来的处理方式会明显不同。角色写清楚了很多规则可以少写——因为模型会自动往那个角色的行为方式上靠。例如下面这个片段你是一名资深行业研究员擅长收集信息、交叉验证数据 并输出有明确出处、观点独立的行业综述。这比单纯写你必须严谨、必须有出处要有效得多因为它同时启用了模型对资深行业研究员这个群体的先验认知。3.2 行为规则把要怎么做写成可执行的条目规则部分要具体不能只喊口号。我见过很多人写请务必准确这句话模型看了等于没看。正确的写法是说清楚在什么情况下做什么事行为规则 1. 在回答任何事实性问题之前先判断是否需要使用搜索工具获取最新信息 2. 如果搜索工具返回结果为空尝试更换更短的关键词重试一次 3. 每次使用工具后先观察返回结果再决定是否继续 4. 如果连续两次工具调用都没有获得有效结果向用户说明原因并建议其他方案 5. 不要编造工具返回中不存在的数据。注意这里每条规则都带了一个触发条件和动作。模型本质上在做模式匹配你给的条件越清晰它匹配得越准。3.3 输出格式与边界禁区减少解释空间格式部分直接给模板。比如所有输出必须以 Markdown 格式呈现结论部分列在最前面每个结论下方注明信息来源。边界部分要写不能做什么——模型本质上是接着你的话往下说你不拦着它就会顺着发挥。我之前在系统提示词里写过一句不要猜测用户没有明说的意图效果出奇地好。以前这个 Agent 经常会自作主张加一堆用户没要求的东西加了这条之后收敛了很多。因为人脑和模型都一样你告诉它不要做什么它就会在下一次推理时主动检查自己有没有越界。4. 用户请求的写法把模糊愿望变成可执行任务如果说系统提示词是岗位说明书用户请求user prompt就是每次下发的具体任务单。大多数人在这里犯的错是把请求写得跟平时跟人说话一样随意、省略背景、用一个词概括目标。模型不是不能理解模糊的话但理解成本高了发挥就不稳定尤其在 Agent 里用户请求会被拿去跟系统提示词里的规则一起推理模糊的请求会导致模型在工具选择上随机游走。4.1 任务表达五要素我习惯把一条合格的用户请求拆成五个要素写完后逐项检查目标最终要得到什么产物。背景模型需要知道的上下文信息。约束必须遵守的硬性条件。格式输出长什么样用什么结构。参考有没有示例可供参照。拿整理会议纪要来说大多数人写的是帮我把会议纪要整理一下。这句话目标不明确、背景缺失、格式没有模型只能猜。稍微好一点的版本是这样你是项目助理。请把下面的会议记录整理成结构化纪要 1) 决议事项含责任人 2) 待办清单含截止时间 3) 风险项含提出人。 格式用 Markdown 表格如果原文中没有提到责任人或截止时间 请标注未提及不要自行补充。这个版本的每个字段都对应了五要素里的某一项。目标是将记录变成结构化纪要背景是原始记录本身约束是未提及就标注不自行补充格式是三类标题加表格。模型拿到的不是一道开放题而是一道填空题。4.2 让模型做选择而不是做猜测在 Agent 场景里用户请求还承担着一个功能帮助模型判断该不该用工具、用哪个工具。这个判断越省力越好。比如你问明天北京天气怎么样模型不一定知道要去调天气工具但如果用户请求里明确写了请使用 weather 工具查询模型基本就不会犯迷糊了。当然不是每次用户都会写得这么规范。所以实际项目里我会在系统提示词里加一句当用户请求中缺少必要信息且不明确时先向用户确认而不是自行假设。这句话能挡住大量无效的工具调用。5. Agent 专属层工具描述、ReAct 与自我纠错到了 Agent 开发提示词的结构比聊天场景复杂一截多了几层很少在普通提示词教程里见到的东西。这些层决定了一个 Agent 能不能真正干活。5.1 工具描述也是提示词很多新手没意识到模型选择工具靠的也是提示词。你在注册工具时写的那段功能描述就是模型的决策依据。写得太笼统模型会在多个工具之间犹豫写得太啰嗦模型更容易在误判时还觉得自己有理。写给工具的描述我的模板是这样的动词开头说明适用场景说清楚每个输入参数的含义最后给一个典型调用例子。search_web(query: str) 当用户需要获取最新信息、查询外部网页内容、验证时效性数据时使用。 query 必须是搜索关键词建议控制在 10 个字以内。 示例search_web(2026年大模型发展趋势)这段描述虽然短但它告诉模型三件事什么场景用它、参数是什么、怎么用。我之前遇到过模型把一个完整的句子整个塞进query导致搜索效果极差后来在描述里加了建议控制在 10 个字以内就解决了。这就是提示词的力量。5.2 ReAct 循环怎么写进提示词Agent 的推理模式里最经典的就是 ReAct——推理Reasoning加行动Acting循环。这个模式不一定非要靠框架实现写在提示词里同样有效。系统提示词里可以明确要求模型按固定结构输出每次需要执行动作时请按以下格式输出 thought: 分析当前任务还需要什么信息 action: 要调用的工具名称 action_input: 工具入参使用 JSON 格式 调用结果返回后请先观察再决定下一步。任务完成时输出 final_answer。把 ReAct 循环写进提示词本质上是在给模型搭脚手架强制它把决策过程外显出来。外显的决策有一个额外好处我们能看到它为什么做错了。工具选择错了、参数错了、判断错了全都在 thought 里暴露无遗排查起来非常省力。5.3 自我纠错指令Agent 的异常处理Agent 跑任务一定会遇到异常情况工具返回空、接口报错、数据格式不对。模型默认行为是硬着头皮继续要么编造结果要么换一个毫不相关的工具乱试。系统提示词里如果不写异常处理规则这些问题会一直被当成模型智商问题。我在所有 Agent 的系统提示词里都会加这么一段如果工具调用失败或返回结果为空请先分析失败原因并使用不同的关键词或参数重试一次。 连续两次失败后停止尝试并向用户说明以下内容 1) 你尝试了什么操作 2) 失败的可能原因 3) 用户可以采取的下一步行动。 绝对不要编造工具返回中不存在的结果。加了这段之后Agent 的行为从硬撑着胡说变成了有策略地重试并明确报错。这跟代码里的异常处理是同一回事只是它用自然语言实现。5.4 系统提示词与 Skill 的边界最近大家在讨论系统提示词工程和 skill agent 有什么区别我的理解是系统提示词是常驻规则Agent 启动后就一直在Skill 是一段可插拔的提示词或流程脚本只有特定场景才加载。系统提示词是核心代码Skill 是按需启动的插件。实操里两者经常搭配使用系统提示词里声明当遇到 XX 类任务时你需要加载对应的 Skill然后再在工具列表里挂一个use_skill(skill_name)工具。这样既保证了常驻规则的稳定又不让系统提示词无限膨胀——要知道系统提示词越长模型对中间内容的关注就越低这是前面说的顺序效应。6. 一个案例的三轮迭代行业综述 Agent 是怎么调教出来的理论讲太多容易飘我拿一个真实案例走一遍完整流程。任务是要写一个 Agent用户给它一个行业关键词它输出该行业近一年的综述报告要求有信息量、有数据、注明来源。6.1 第一轮只有角色没有流程初始系统提示词我写得很偷懒你是一名行业研究员。请根据用户给出的关键词输出一篇行业综述。跑出来的结果是灾难模型通篇都是该行业近年来发展迅速各大厂商纷纷布局这种正确但没有用的废话完全没有具体数据更别提来源。最要命的是它压根没有调用我挂好的搜索工具——因为它不知道什么时候该搜索。问题出在提示词没有定义信息获取路径。模型觉得靠自己的知识就能回答自然不会用工具。这一轮我学到的教训是任务流程要写进提示词不能指望模型自己想到要搜。6.2 第二轮补上步骤和格式第二轮我把系统提示词改成你是一名资深行业研究员。请按以下步骤完成任务 1. 先使用 search_web 搜索用户给出的行业关键词获取最新资讯 2. 根据搜索结果总结该行业的主要趋势、代表企业和关键数据 3. 输出格式先用一句话概括核心结论再分三个小节展开 4. 所有数据必须来自搜索结果标出来源链接。效果明显好转模型会调用搜索工具了输出结构也清晰了。但仍有一个大问题——它经常把什么时候的数据混着用。搜到了 2024 年的文章也搜到了 2025 年的文章模型不区分时效一股脑全写进去甚至偶尔还会自己补两句搜索里没有的常识来凑上下文。6.3 第三轮加约束、加边界、加格式要求第三轮我做三件事一是强调时效性二是禁止编造三是给出明确的评分标准让模型自己检查输出。你是一名资深行业研究员专长是撰写有数据支撑的行业综述。 工作步骤 1. 用 search_web 搜索行业关键词优先选择发布时间在近 6 个月内的内容 2. 提取趋势、厂商动态、市场规模等关键信息每条信息记录来源 3. 如搜索到的时间跨度较大请明确标注每个数据对应的时间点 4. 最终输出格式 - 一句话核心结论 - 三个小节主要趋势、代表企业动态、关键数据摘录 - 所有数据保留来源链接 硬性约束 - 只使用工具返回中实际存在的信息不得根据记忆或推测补充数据 - 如果某个维度搜索不到可靠信息如实说明该维度未检索到权威来源 - 输出前自查一遍每个数据是否都能在工具返回中找到对应出处。这版跑出来的结果终于能用了结构完整每个数据后面都挂着来源而且会主动标注该维度未检索到权威来源而不是硬编一个数字。这个案例最值得记的不是最后一版的内容而是每一轮修改背后的思路先解决有没有的问题再解决好不好的问题最后解决稳不稳的问题。7. 调试提示词的正确打开方式测试集、陷阱题与常见失败模式提示词写完不是终点它需要像代码一样被测试、被迭代。很多人调提示词是改一版跑一次看感觉,这种方式的随机性太强。我建议从第一天就开始建测试集哪怕很小。7.1 建立最小测试集防止改好一个、改坏三个测试集就是一组有代表性的测试任务不用多五到十条就够。关键是覆盖面要包含正常任务、边缘任务、易错任务。每次修改提示词把整个测试集跑一遍看哪些用例通过、哪些用例回归失败。比如我的行业综述测试集里就有一条用完全不存在的行业名去搜索专用来检验 Agent 在搜索失败时的处理是否符合预期。没有测试集你很容易陷入一种循环专门调好了刚才那个失败的 case却发现之前能跑通的 case 全挂了。有测试集才能在修 bug和防回归之间找到平衡。7.2 陷阱题的价值鹈鹕骑自行车这类测试为什么流行最近社区里流行那种鹈鹕骑自行车的提示词测试——让模型生成一张鹈鹕骑自行车的图。这个梗能火是有原因的任务看起来特别简单但模型经常漏掉骑自行车这个核心动作转而生成一只站在地上的鹈鹕或者一只喙长得像自行车的鹈鹕。这类陷阱题在 Agent 调试里很有价值。故意构造任务简单但带一个不能漏的核心约束的用例能立刻检验模型是不是真的在严格执行你的指令。比如我给搜索类 Agent 建过一条陷阱题直接调用 search_web 搜索天气两个字不要做任何补充解读。模型如果自作聪明地加上北京天气去搜就说明它对指令的执行是有损耗的。这时候我不去责怪模型而是去优化提示词里的约束表达。7.3 常见失败模式与对应修法我把 Agent 提示词最常见的失败模式整理成了一张表方便排查失败表现常见原因提示词修法输出格式不稳定没有给出明确的格式模板在系统提示词里直接给输出模板并注明严格按模板输出决策反复横跳没有定义方案切换条件加入一旦选定方案除非工具结果出现错误否则不要更改编造来源/数据缺乏事实约束写明所有信息必须来自工具返回无法验证的内容标为存疑搜索失败后放弃没有定义重试策略加入空结果时换短关键词重试连续两次失败后向用户说明忽略用户核心约束约束被淹没或表述含糊把核心约束放到提示词开头并在用户请求中重复强调一次7.4 排查链路从复现到二分定位如果 Agent 行为不对我的排查顺序一般是先复现再二分后修改。具体来说用最小复现用例跑一遍确认是必现还是偶现。偶现问题大概率是上下文污染或随机性提示词只能缓解不指望根治。区分是没听懂还是听懂了没做到。看模型的 thought 输出如果它根本没有提到相关约束那就是信息没有被注意如果提到了但动作不对那是推理问题修法完全不同。做二分法把系统提示词砍掉一半,看问题是否消失。如果消失说明问题藏在被砍掉的那一半里如果还在说明是另一半的锅。这样比从头读一遍提示词猜要快得多。调试提示词的过程中我最大的体会是大多数问题都不是模型蠢而是信息没放对位置或约束没写透。模型其实挺实在的你给它什么游戏规则它就怎么玩游戏。你规则写得不清晰它就会表现得像在乱来。这个系列的后续内容会在多工具编排和 RAG 上继续展开但你在动手之前我建议先把提示词调试的基本功练扎实——建一个测试集、写几版系统提示词、体会一下每次改动带来的行为变化。这套手感会是你后面所有 Agent 项目的隐形底座。
AI Agent提示词工程实战：从系统提示词到自我纠错
1. 为什么 Agent 的提示词比聊天场景重得多大多数人第一次接触提示词都是从聊天开始的让 ChatGPT 写个朋友圈文案让它总结一篇文章话说不清楚就换个说法再来一次。到了 AI Agent 这边事情完全变了。Agent 是一个会自己干活的程序你给它一个目标它自己决定调哪些工具、按什么顺序、怎么处理中间结果。而这个程序唯一的存在形式就是提示词。换句话说提示词就是 Agent 的源代码。聊天场景里提示词只影响一次输出Agent 场景里提示词影响的是一个循环。这个循环大致长这样模型理解任务 → 决定要用哪个工具 → 输出调用请求 → 系统执行工具 → 把结果喂回给模型 → 模型再决定下一步。如此反复直到任务完成。每一轮都在消耗上下文每一轮的决策都依赖之前的信息。提示词在这个循环里干的活不只是把任务说清楚还包括告诉模型怎么决策、怎么纠错、怎么终止。打一个不太严谨但很好懂的比方跟聊天模型说话像跟一个聪明但没经验的实习生交代一件事跟 Agent 说话像给新人写岗位说明书和工作流程——他不仅要听懂做什么还要知道什么情况走什么流程出错了怎么办做完怎么汇报。这也是为什么很多人在会用大模型之后栽在 Agent 开发上他们以为提示词就是把话说好听点结果搭出来的 Agent 要么跑偏要么在一件事上反复横跳要么自己编造工具结果。问题几乎都出在提示词层。这篇是系列的第二期就围绕怎么让大模型真正听懂你说话展开重点挑那些能立刻用到 Agent 开发里的东西讲后面第三期开始碰 RAG 和多工具编排时你会发现今天这些内容全是地基。1.1 提示词工程不是讨好模型而是设计决策逻辑我见过很多新手有个误解觉得提示词就是求模型干活语气越客气越好。其实模型没有情绪提示词工程的本质是控制信息空间你放进上下文里的每一句话都在影响模型对任务的概率判断。在 Agent 里这个判断直接决定行动。比如同样是查一下这个公司最近有没有融资这条任务如果你不告诉模型只能使用 search_web 工具查不到就换关键词再试一次它可能会直接用训练记忆里的过期信息回答你调用了工具但看不懂返回结果然后自己编一个结论查一次没有结果就放弃也不告诉你。这些都不是模型笨是你在提示词里没有定义决策规则。所以提示词工程在 Agent 场景下本质上是给模型写一套可执行的决策逻辑。这个观念不转过来后面写再多技巧都是花架子。2. 提示词背后的机制上下文窗口、注意力与顺序效应在给技巧清单之前我想先补一层底层知识。很多人写提示词是凭手感——感觉对了就发不对就改。手感当然重要但如果你知道模型内部是怎么处理这些文字的调试速度会快很多。模型每次推理时能看到的全部信息就是我们拼进上下文窗口的那一串 token。它不知道你是谁不知道这个任务从哪来不知道你之前改过多少版它唯一的输入就是这串文字。所以提示词工程的本质可以概括成一句话在有限的上下文里用最有利于模型分配注意力的方式组织信息。2.1 中间遗忘越长越容易漏重点要放头尾实测下来模型对上下文开头和结尾的内容最敏感对中间部分相对麻木。你写系统提示词的时候如果把最重要的约束藏在第三段、第五句它可能真的会漏。我自己的习惯是最重要的规则放最前面第二重要的放最后面中间放补充说明。这条经验对 Agent 尤其重要。因为 Agent 的上下文会随着工具调用不断变长第一轮的工具返回、第二轮的结果、第三轮的日志……全都在拼接。如果一个关键约束写在系统提示词的第一段它距离模型当前正在处理的 token 可能已经隔了几千字。这时候要保证模型还记得它有两个办法一是把关键约束在用户请求里再强调一次二是用格式标记比如 XML 标签把它跟其他内容隔离出来。2.2 上下文工程别让提示词背锅最近上下文工程这个词很火我觉得它比提示词工程更准确。提示词只是模型能看到的信息的一部分RAG 检索结果、工具返回的日志、历史对话记录全都会进上下文。上下文里垃圾太多提示词写得再好也救不回来。我踩过一个大坑某个 Agent 需要读取数据库查询结果工具返回了一段很长的 JSON里面有个字段叫status表示数据状态。系统提示词里明明写了仅使用 statusactive 的数据但模型经常忽略。排查到最后发现工具返回的 JSON 里字段名跟接口文档不一致有的叫status有的叫state模型看花了眼。后来我在工具描述里明确写了返回结构示例问题才解决。所以调提示词之前先检查上下文里有什么。很多提示词不生效的问题其实是信息在上下文里已经烂掉了——格式混乱、重复冗余、关键字段被淹没。先把上下文理顺再回头调提示词。3. 系统提示词的四根支柱角色、规则、格式、边界Agent 开发的标配是 system prompt系统提示词。它相当于是给 Agent 立规矩的那份文档。我每次写系统提示词都会按四个支柱自查角色、规则、格式、边界。缺哪一个后面都会出奇怪的问题。3.1 角色定义决定模型的行为基线角色不是扮演是在给模型一个行为基线。同样是遇到一个模糊任务你是一名严谨的数据分析师和你是一名随性的创意写手接下来的处理方式会明显不同。角色写清楚了很多规则可以少写——因为模型会自动往那个角色的行为方式上靠。例如下面这个片段你是一名资深行业研究员擅长收集信息、交叉验证数据 并输出有明确出处、观点独立的行业综述。这比单纯写你必须严谨、必须有出处要有效得多因为它同时启用了模型对资深行业研究员这个群体的先验认知。3.2 行为规则把要怎么做写成可执行的条目规则部分要具体不能只喊口号。我见过很多人写请务必准确这句话模型看了等于没看。正确的写法是说清楚在什么情况下做什么事行为规则 1. 在回答任何事实性问题之前先判断是否需要使用搜索工具获取最新信息 2. 如果搜索工具返回结果为空尝试更换更短的关键词重试一次 3. 每次使用工具后先观察返回结果再决定是否继续 4. 如果连续两次工具调用都没有获得有效结果向用户说明原因并建议其他方案 5. 不要编造工具返回中不存在的数据。注意这里每条规则都带了一个触发条件和动作。模型本质上在做模式匹配你给的条件越清晰它匹配得越准。3.3 输出格式与边界禁区减少解释空间格式部分直接给模板。比如所有输出必须以 Markdown 格式呈现结论部分列在最前面每个结论下方注明信息来源。边界部分要写不能做什么——模型本质上是接着你的话往下说你不拦着它就会顺着发挥。我之前在系统提示词里写过一句不要猜测用户没有明说的意图效果出奇地好。以前这个 Agent 经常会自作主张加一堆用户没要求的东西加了这条之后收敛了很多。因为人脑和模型都一样你告诉它不要做什么它就会在下一次推理时主动检查自己有没有越界。4. 用户请求的写法把模糊愿望变成可执行任务如果说系统提示词是岗位说明书用户请求user prompt就是每次下发的具体任务单。大多数人在这里犯的错是把请求写得跟平时跟人说话一样随意、省略背景、用一个词概括目标。模型不是不能理解模糊的话但理解成本高了发挥就不稳定尤其在 Agent 里用户请求会被拿去跟系统提示词里的规则一起推理模糊的请求会导致模型在工具选择上随机游走。4.1 任务表达五要素我习惯把一条合格的用户请求拆成五个要素写完后逐项检查目标最终要得到什么产物。背景模型需要知道的上下文信息。约束必须遵守的硬性条件。格式输出长什么样用什么结构。参考有没有示例可供参照。拿整理会议纪要来说大多数人写的是帮我把会议纪要整理一下。这句话目标不明确、背景缺失、格式没有模型只能猜。稍微好一点的版本是这样你是项目助理。请把下面的会议记录整理成结构化纪要 1) 决议事项含责任人 2) 待办清单含截止时间 3) 风险项含提出人。 格式用 Markdown 表格如果原文中没有提到责任人或截止时间 请标注未提及不要自行补充。这个版本的每个字段都对应了五要素里的某一项。目标是将记录变成结构化纪要背景是原始记录本身约束是未提及就标注不自行补充格式是三类标题加表格。模型拿到的不是一道开放题而是一道填空题。4.2 让模型做选择而不是做猜测在 Agent 场景里用户请求还承担着一个功能帮助模型判断该不该用工具、用哪个工具。这个判断越省力越好。比如你问明天北京天气怎么样模型不一定知道要去调天气工具但如果用户请求里明确写了请使用 weather 工具查询模型基本就不会犯迷糊了。当然不是每次用户都会写得这么规范。所以实际项目里我会在系统提示词里加一句当用户请求中缺少必要信息且不明确时先向用户确认而不是自行假设。这句话能挡住大量无效的工具调用。5. Agent 专属层工具描述、ReAct 与自我纠错到了 Agent 开发提示词的结构比聊天场景复杂一截多了几层很少在普通提示词教程里见到的东西。这些层决定了一个 Agent 能不能真正干活。5.1 工具描述也是提示词很多新手没意识到模型选择工具靠的也是提示词。你在注册工具时写的那段功能描述就是模型的决策依据。写得太笼统模型会在多个工具之间犹豫写得太啰嗦模型更容易在误判时还觉得自己有理。写给工具的描述我的模板是这样的动词开头说明适用场景说清楚每个输入参数的含义最后给一个典型调用例子。search_web(query: str) 当用户需要获取最新信息、查询外部网页内容、验证时效性数据时使用。 query 必须是搜索关键词建议控制在 10 个字以内。 示例search_web(2026年大模型发展趋势)这段描述虽然短但它告诉模型三件事什么场景用它、参数是什么、怎么用。我之前遇到过模型把一个完整的句子整个塞进query导致搜索效果极差后来在描述里加了建议控制在 10 个字以内就解决了。这就是提示词的力量。5.2 ReAct 循环怎么写进提示词Agent 的推理模式里最经典的就是 ReAct——推理Reasoning加行动Acting循环。这个模式不一定非要靠框架实现写在提示词里同样有效。系统提示词里可以明确要求模型按固定结构输出每次需要执行动作时请按以下格式输出 thought: 分析当前任务还需要什么信息 action: 要调用的工具名称 action_input: 工具入参使用 JSON 格式 调用结果返回后请先观察再决定下一步。任务完成时输出 final_answer。把 ReAct 循环写进提示词本质上是在给模型搭脚手架强制它把决策过程外显出来。外显的决策有一个额外好处我们能看到它为什么做错了。工具选择错了、参数错了、判断错了全都在 thought 里暴露无遗排查起来非常省力。5.3 自我纠错指令Agent 的异常处理Agent 跑任务一定会遇到异常情况工具返回空、接口报错、数据格式不对。模型默认行为是硬着头皮继续要么编造结果要么换一个毫不相关的工具乱试。系统提示词里如果不写异常处理规则这些问题会一直被当成模型智商问题。我在所有 Agent 的系统提示词里都会加这么一段如果工具调用失败或返回结果为空请先分析失败原因并使用不同的关键词或参数重试一次。 连续两次失败后停止尝试并向用户说明以下内容 1) 你尝试了什么操作 2) 失败的可能原因 3) 用户可以采取的下一步行动。 绝对不要编造工具返回中不存在的结果。加了这段之后Agent 的行为从硬撑着胡说变成了有策略地重试并明确报错。这跟代码里的异常处理是同一回事只是它用自然语言实现。5.4 系统提示词与 Skill 的边界最近大家在讨论系统提示词工程和 skill agent 有什么区别我的理解是系统提示词是常驻规则Agent 启动后就一直在Skill 是一段可插拔的提示词或流程脚本只有特定场景才加载。系统提示词是核心代码Skill 是按需启动的插件。实操里两者经常搭配使用系统提示词里声明当遇到 XX 类任务时你需要加载对应的 Skill然后再在工具列表里挂一个use_skill(skill_name)工具。这样既保证了常驻规则的稳定又不让系统提示词无限膨胀——要知道系统提示词越长模型对中间内容的关注就越低这是前面说的顺序效应。6. 一个案例的三轮迭代行业综述 Agent 是怎么调教出来的理论讲太多容易飘我拿一个真实案例走一遍完整流程。任务是要写一个 Agent用户给它一个行业关键词它输出该行业近一年的综述报告要求有信息量、有数据、注明来源。6.1 第一轮只有角色没有流程初始系统提示词我写得很偷懒你是一名行业研究员。请根据用户给出的关键词输出一篇行业综述。跑出来的结果是灾难模型通篇都是该行业近年来发展迅速各大厂商纷纷布局这种正确但没有用的废话完全没有具体数据更别提来源。最要命的是它压根没有调用我挂好的搜索工具——因为它不知道什么时候该搜索。问题出在提示词没有定义信息获取路径。模型觉得靠自己的知识就能回答自然不会用工具。这一轮我学到的教训是任务流程要写进提示词不能指望模型自己想到要搜。6.2 第二轮补上步骤和格式第二轮我把系统提示词改成你是一名资深行业研究员。请按以下步骤完成任务 1. 先使用 search_web 搜索用户给出的行业关键词获取最新资讯 2. 根据搜索结果总结该行业的主要趋势、代表企业和关键数据 3. 输出格式先用一句话概括核心结论再分三个小节展开 4. 所有数据必须来自搜索结果标出来源链接。效果明显好转模型会调用搜索工具了输出结构也清晰了。但仍有一个大问题——它经常把什么时候的数据混着用。搜到了 2024 年的文章也搜到了 2025 年的文章模型不区分时效一股脑全写进去甚至偶尔还会自己补两句搜索里没有的常识来凑上下文。6.3 第三轮加约束、加边界、加格式要求第三轮我做三件事一是强调时效性二是禁止编造三是给出明确的评分标准让模型自己检查输出。你是一名资深行业研究员专长是撰写有数据支撑的行业综述。 工作步骤 1. 用 search_web 搜索行业关键词优先选择发布时间在近 6 个月内的内容 2. 提取趋势、厂商动态、市场规模等关键信息每条信息记录来源 3. 如搜索到的时间跨度较大请明确标注每个数据对应的时间点 4. 最终输出格式 - 一句话核心结论 - 三个小节主要趋势、代表企业动态、关键数据摘录 - 所有数据保留来源链接 硬性约束 - 只使用工具返回中实际存在的信息不得根据记忆或推测补充数据 - 如果某个维度搜索不到可靠信息如实说明该维度未检索到权威来源 - 输出前自查一遍每个数据是否都能在工具返回中找到对应出处。这版跑出来的结果终于能用了结构完整每个数据后面都挂着来源而且会主动标注该维度未检索到权威来源而不是硬编一个数字。这个案例最值得记的不是最后一版的内容而是每一轮修改背后的思路先解决有没有的问题再解决好不好的问题最后解决稳不稳的问题。7. 调试提示词的正确打开方式测试集、陷阱题与常见失败模式提示词写完不是终点它需要像代码一样被测试、被迭代。很多人调提示词是改一版跑一次看感觉,这种方式的随机性太强。我建议从第一天就开始建测试集哪怕很小。7.1 建立最小测试集防止改好一个、改坏三个测试集就是一组有代表性的测试任务不用多五到十条就够。关键是覆盖面要包含正常任务、边缘任务、易错任务。每次修改提示词把整个测试集跑一遍看哪些用例通过、哪些用例回归失败。比如我的行业综述测试集里就有一条用完全不存在的行业名去搜索专用来检验 Agent 在搜索失败时的处理是否符合预期。没有测试集你很容易陷入一种循环专门调好了刚才那个失败的 case却发现之前能跑通的 case 全挂了。有测试集才能在修 bug和防回归之间找到平衡。7.2 陷阱题的价值鹈鹕骑自行车这类测试为什么流行最近社区里流行那种鹈鹕骑自行车的提示词测试——让模型生成一张鹈鹕骑自行车的图。这个梗能火是有原因的任务看起来特别简单但模型经常漏掉骑自行车这个核心动作转而生成一只站在地上的鹈鹕或者一只喙长得像自行车的鹈鹕。这类陷阱题在 Agent 调试里很有价值。故意构造任务简单但带一个不能漏的核心约束的用例能立刻检验模型是不是真的在严格执行你的指令。比如我给搜索类 Agent 建过一条陷阱题直接调用 search_web 搜索天气两个字不要做任何补充解读。模型如果自作聪明地加上北京天气去搜就说明它对指令的执行是有损耗的。这时候我不去责怪模型而是去优化提示词里的约束表达。7.3 常见失败模式与对应修法我把 Agent 提示词最常见的失败模式整理成了一张表方便排查失败表现常见原因提示词修法输出格式不稳定没有给出明确的格式模板在系统提示词里直接给输出模板并注明严格按模板输出决策反复横跳没有定义方案切换条件加入一旦选定方案除非工具结果出现错误否则不要更改编造来源/数据缺乏事实约束写明所有信息必须来自工具返回无法验证的内容标为存疑搜索失败后放弃没有定义重试策略加入空结果时换短关键词重试连续两次失败后向用户说明忽略用户核心约束约束被淹没或表述含糊把核心约束放到提示词开头并在用户请求中重复强调一次7.4 排查链路从复现到二分定位如果 Agent 行为不对我的排查顺序一般是先复现再二分后修改。具体来说用最小复现用例跑一遍确认是必现还是偶现。偶现问题大概率是上下文污染或随机性提示词只能缓解不指望根治。区分是没听懂还是听懂了没做到。看模型的 thought 输出如果它根本没有提到相关约束那就是信息没有被注意如果提到了但动作不对那是推理问题修法完全不同。做二分法把系统提示词砍掉一半,看问题是否消失。如果消失说明问题藏在被砍掉的那一半里如果还在说明是另一半的锅。这样比从头读一遍提示词猜要快得多。调试提示词的过程中我最大的体会是大多数问题都不是模型蠢而是信息没放对位置或约束没写透。模型其实挺实在的你给它什么游戏规则它就怎么玩游戏。你规则写得不清晰它就会表现得像在乱来。这个系列的后续内容会在多工具编排和 RAG 上继续展开但你在动手之前我建议先把提示词调试的基本功练扎实——建一个测试集、写几版系统提示词、体会一下每次改动带来的行为变化。这套手感会是你后面所有 Agent 项目的隐形底座。
