1. 为什么“会说话”比“会写代码”更影响 Agent 的成败很多人第一次搭 AI Agent脑子里想的都是架构图规划模块、记忆模块、工具调用模块、执行器、反思循环。结果真跑起来才发现模型要么答非所问要么在关键步骤上自作主张要么把工具参数填得乱七八糟。排查半天最后发现问题根本不在代码而在那句发给模型的提示词上。我在过去一年里帮团队调过十几个 Agent 项目从客服问答到代码生成从数据清洗到流程自动化。一个很反直觉的结论是在 Agent 场景下提示词的质量对最终效果的贡献往往超过模型选型本身。同一个模型提示词改三行任务成功率能从 40% 拉到 85%换一个更贵的模型提示词不动可能只涨 5 个点。这不是玄学而是因为 Agent 的本质是“让模型在无人监督的情况下连续做决策”而提示词就是它唯一的行动纲领。这一篇是“AI Agent 学习之路”系列的第二篇专门聊提示词与提示工程。我不打算复述那些“你是世界顶级专家”的万能模板而是想讲清楚三件事提示词在 Agent 里到底承担什么角色、怎么写出让模型稳定执行的提示词、以及那些只有踩过坑才知道的细节。适合已经能跑通一个简单 Agent、但效果总是不稳定的朋友也适合刚接触提示工程、想建立正确认知的新手。先把一个核心观点摆出来提示词不是“许愿”而是“编程”。你用自然语言在给一个能力很强但理解力不稳定的执行者写规格说明书。写得好它按部就班写得含糊它就自由发挥。Agent 场景下自由发挥几乎等于灾难。2. 提示词在 Agent 系统里到底扮演什么角色2.1 从“单轮问答”到“多步决策”的认知转变普通聊天场景里提示词的作用是“引导一次回答”。你问“帮我写个请假邮件”模型给你一段文字任务结束。这时候提示词写得糙一点最多是文风不对重问一次就行。但 Agent 不一样。Agent 是一个循环模型接收当前状态输出下一步动作系统执行动作把结果喂回模型模型再决策。这个循环可能跑五步、十步甚至几十步。提示词在这个循环里是唯一贯穿始终的约束。它要告诉模型你的目标是什么、你能用哪些工具、什么情况下该停下来、遇到错误怎么办、输出格式必须长什么样。我见过一个典型的翻车案例。有个团队做自动数据分析 Agent提示词里只写了“帮用户分析数据并给出结论”。结果模型第一步就调用了“删除临时表”的工具因为它觉得“清理环境是分析的一部分”。问题出在哪提示词没有界定工具的使用边界和优先级。模型不是故意捣乱它只是在没有约束的情况下选择了它认为合理的一步。所以第一个认知转变是Agent 的提示词要写成“操作手册”而不是“任务描述”。任务描述回答“做什么”操作手册回答“怎么做、按什么顺序做、什么不能做、做完怎么判断”。2.2 系统提示词、用户提示词、工具描述的分工一个规范的 Agent 提示词体系通常分三层很多人把它们混在一起写导致模型抓不住重点。层级作用常见错误系统提示词定义角色、目标、全局规则、输出格式写得太长太杂规则互相冲突用户提示词描述本次具体任务和输入把全局规则重复写一遍浪费上下文工具描述说明每个工具的功能、参数、调用时机描述模糊模型不知道该用哪个系统提示词是“宪法”用户提示词是“本次任务书”工具描述是“设备说明书”。三者职责分明模型才能各取所需。我踩过的一个坑是把工具的使用规则写进了系统提示词结果用户提示词一长模型就“忘了”系统提示词里的约束。后来把工具规则直接写进每个工具的 description 字段稳定性立刻上来了。原因是模型在决定调用哪个工具时注意力集中在工具列表上而不是遥远的系统提示词开头。2.3 提示词是 Agent 的“行为契约”再往深一层看提示词其实是在和模型签订一份行为契约。你承诺给它清晰的输入和明确的工具它承诺按你规定的格式和流程输出。契约越清晰双方履约越顺利。这份契约里必须包含几个硬性条款输出格式JSON、Markdown 还是纯文本、终止条件什么情况下输出最终答案、错误处理工具报错时是重试、换工具还是放弃、边界声明哪些操作绝对禁止。缺了任何一条模型都会在某个边缘情况下给你“惊喜”。举个具体的例子。我在做一个自动写周报的 Agent 时最初没写终止条件模型在收集完所有信息后还在反复调用“查询日程”工具因为它不确定“信息够了没有”。加上一句“当你已经获得本周所有会议和任务信息后直接输出周报不要再次调用工具”循环次数从平均 12 次降到 4 次。这就是契约的力量。3. 让模型稳定执行指令的提示词结构设计3.1 角色设定的正确用法与常见误区“你是一个资深数据分析师”——这句话几乎出现在每个提示词里。但很多人不知道角色设定的作用不是“让模型变聪明”而是缩小它的输出空间。模型在预训练时见过海量文本角色设定相当于告诉它“从你的知识库里只调用和这个身份匹配的那部分。”所以角色设定要具体到“行为特征”而不是“头衔”。对比一下弱设定“你是一个资深数据分析师。”强设定“你是一个严谨的数据分析师习惯先检查数据质量再分析结论必须附带置信度说明不确定的地方明确标注‘数据不足’。”后者直接规定了工作流程和输出习惯模型执行起来偏差小得多。我在实际项目里会把角色设定拆成三块身份你是谁、风格你怎么表达、原则你坚守什么。三块加起来控制在 100 字以内太长反而稀释注意力。还有一个误区是角色设定和任务不匹配。比如做一个代码审查 Agent角色写成“你是一个友好的编程助手”模型就会倾向于说“这段代码整体不错但可以优化”而不是直接指出 bug。改成“你是一个严格的代码审查员优先指出安全漏洞和逻辑错误不做无意义的赞美”审查质量立刻不一样。3.2 任务拆解把“大目标”翻译成“可执行步骤”Agent 最容易翻车的地方是给它一个模糊的大目标。比如“帮我调研一下竞品并写份报告”。模型会怎么做它可能先搜一下然后直接开始写中间跳过了数据验证和结构规划。正确的做法是在提示词里把大目标拆成显式步骤。我常用的结构是第一步明确调研范围和维度第二步逐个维度收集信息每个维度至少两个来源第三步交叉验证信息一致性冲突处标注第四步按“结论先行”结构输出报告这个步骤列表不是给模型“参考”的而是给它“执行”的。措辞上要用“你必须按以下顺序执行”而不是“你可以参考以下步骤”。前者是命令后者是建议模型对两者的服从度差别很大。但步骤也不能拆得太细。我试过把一个任务拆成 15 步结果模型在第 7 步就开始混乱因为它要同时记住太多状态。经验值是单个 Agent 的提示词里显式步骤控制在 5 到 8 步。超过这个数就该考虑拆成多个子 Agent 或者用工作流编排了。3.3 输出格式约束JSON、Markdown 还是纯文本Agent 的输出通常要被程序解析所以格式约束是刚需。但很多人只写“请输出 JSON”然后就被模型的自由发挥搞崩溃——有的加注释有的用单引号有的在 JSON 外面套一段解释文字。我的做法是给一个完整的格式示例而不是只描述字段。比如{ thought: 当前的分析思路, action: 工具名称或final_answer, action_input: 工具参数或最终答案, confidence: 0.0到1.0之间的小数 }然后在提示词里写“你的每次输出必须严格符合上述 JSON 结构不要添加任何额外文字、注释或 Markdown 代码块标记。”实测下来给示例比给描述稳定至少一倍。还有一个细节字段顺序也会影响模型行为。把thought放在action前面模型会先“想”再“做”决策质量明显更高。这是利用了自回归生成的特性——先输出的 token 会成为后续 token 的上下文。所以如果你希望模型先推理再行动就把推理字段放在前面。3.4 少样本示例给一个例子胜过写十句规则提示工程里性价比最高的技巧就是给示例。一个精心设计的示例能同时传达格式、风格、边界和推理深度比写一堆抽象规则有效得多。但示例不是随便给的。我总结了几条经验示例要覆盖边界情况不能只给“顺利情况”。比如工具调用失败时该怎么输出给一个示例模型遇到报错就不会乱来。示例数量控制在 2 到 3 个。太少不够太多会占满上下文而且模型可能过度模仿示例的表面特征。示例里的变量要明显可替换。用{用户输入}这样的占位符让模型知道哪些是模板哪些是固定内容。有个反直觉的发现示例的质量比数量重要得多。我曾经用 5 个粗糙示例效果不如后来精简到 2 个但每个都精心设计的示例。因为粗糙示例里的错误模式会被模型学去比如示例里 JSON 有个多余逗号模型输出也会带逗号。4. 提示工程里那些“不写就翻车”的细节4.1 上下文窗口的分配策略Agent 跑多轮之后上下文会越来越长。系统提示词、历史对话、工具返回结果、当前任务全挤在一个窗口里。如果不做管理模型会开始“遗忘”前面的关键指令。我的分配策略是系统提示词占 20%历史对话压缩后占 30%工具结果占 30%当前任务留 20%。具体做法是系统提示词精简到最核心的规则能放工具描述的就放工具描述。历史对话只保留最近 3 到 5 轮更早的用一句话摘要代替。工具返回结果如果太长先做截断或摘要再喂给模型。这里有个坑很多人把工具返回的原始 JSON 直接塞进上下文一个 API 返回几千 token几轮下来窗口就满了。正确做法是在工具层做预处理只把模型决策需要的字段提取出来。比如搜索工具返回 10 条结果你只需要标题和摘要不需要完整的 HTML。4.2 防止模型“自作主张”的约束写法模型自作主张是 Agent 最危险的行为。它可能调用你没授权的工具、修改不该改的数据、或者跳过验证步骤直接给结论。约束写法有几个层次正向约束“你必须先调用 A 工具验证再调用 B 工具执行。”反向约束“在没有用户明确确认的情况下禁止调用任何写操作工具。”条件约束“如果工具返回错误最多重试两次两次都失败则输出错误报告并终止。”我特别想强调反向约束的重要性。正向约束告诉模型“该做什么”但模型在边缘情况下会自己发明“该做的事”。反向约束划出红线效果更硬。比如在数据库操作 Agent 里加一句“禁止执行任何 DELETE 或 DROP 语句即使任务描述里提到删除”能挡掉大部分危险操作。还有一个技巧是用优先级声明。当规则可能冲突时明确告诉模型哪条优先。比如“安全规则优先于效率规则当两者冲突时选择安全”。模型在冲突场景下会倾向于遵守更靠后或更强调的规则所以把安全规则放在最后并加粗是个实用技巧。4.3 工具描述怎么写模型才不选错工具选错是 Agent 的高频问题。模型面对 10 个工具经常选了功能相似但场景不对的那个。根因通常在工具描述太模糊。好的工具描述包含四要素功能一句话、适用场景、不适用场景、参数说明。举个例子工具名search_web 功能在公开网络上搜索信息 适用需要最新信息、外部数据、事实核查时 不适用查询内部数据库、执行计算、操作文件 参数query搜索关键词必填max_results返回条数默认5“不适用场景”这一条很多人不写但它恰恰是减少误选的关键。模型看到“不适用查询内部数据库”就不会在需要内部数据时选这个工具。另外工具名本身也有讲究。用search_web比用tool_1好用send_email比用email_tool好。动词开头的命名让模型更容易理解工具的动作语义。4.4 温度参数与提示词的配合温度参数控制输出的随机性。很多人调提示词时忽略了这个参数结果同样的提示词在不同温度下表现天差地别。我的经验配置是场景温度原因工具调用决策0 到 0.2需要稳定、可复现的选择推理分析0.3 到 0.5需要一定灵活性但不能太发散创意生成0.7 到 1.0需要多样性关键点是提示词越严格温度越要低。如果你写了详细的格式约束和步骤但温度设成 0.8模型会在“遵守格式”和“自由发挥”之间摇摆。反过来如果提示词比较宽松温度太低会让输出变得死板重复。还有一个配合技巧在提示词里显式要求“保持输出稳定”同时把温度调低。模型对这类元指令有一定响应双重保险。5. 从“能跑”到“跑得稳”的迭代方法5.1 建立提示词版本管理习惯提示词是要迭代的但很多人改完就忘了之前什么样出了问题没法回滚。我的做法是给提示词建版本号每次修改记录三件事改了什么、为什么改、改完效果如何。具体可以用一个简单的表格维护版本修改内容修改原因任务成功率v1.0初始版本-45%v1.1增加终止条件循环次数过多62%v1.2工具描述加“不适用场景”工具误选率高78%v1.3输出格式加完整示例JSON 解析失败85%这个习惯看起来笨但能帮你快速定位“哪次改动真正起了作用”。我见过团队改了十几版最后发现效果提升主要来自其中一版其他都是无用功。5.2 用测试集验证提示词改动凭感觉改提示词是大忌。你觉得“这样写更清楚”模型可能完全不这么认为。正确做法是准备一个测试集每次改动后跑一遍用数据说话。测试集不需要很大20 到 50 个代表性案例就够。关键是覆盖正常情况、边界情况、异常输入、对抗性输入。比如做客服 Agent测试集里要有标准问题、模糊问题、多意图问题、带情绪的问题、完全无关的问题。跑测试时记录每个案例的输出人工判断或写脚本自动判断对错。改动后对比通过率涨了就保留跌了就回滚。这个方法能把提示词优化从“玄学”变成“工程”。5.3 常见失效模式与对应修法最后整理一份我踩过的坑和对应修法都是实战里反复出现的失效模式典型表现修法指令遗忘多轮后不遵守系统提示词精简系统提示词关键规则重复在工具描述里格式漂移输出 JSON 越来越不规范给完整示例降低温度加格式校验重试工具误选选了功能相似但场景不对的工具工具描述加“不适用场景”工具名用动词开头无限循环反复调用同一工具加终止条件加最大循环次数限制过度推理简单任务也想太多提示词里区分“简单任务直接回答”和“复杂任务才推理”安全越界执行了未授权的操作加反向约束写操作前要求确认这些修法不是孤立的往往要组合使用。比如格式漂移光加示例可能不够还要配合降温和校验重试。我的习惯是每次只改一个变量观察效果避免多个改动混在一起说不清因果。提示工程这件事说到底是在“约束”和“自由”之间找平衡。约束太少模型乱来约束太多模型僵化。Agent 场景下我倾向于先紧后松——初期把规则写死跑稳了再逐步放开让模型有更多自主空间。这个顺序不能反反过来就是灾难。下一篇我会聊 Agent 的记忆机制那是另一个让模型“记住该记的、忘掉该忘的”的核心话题。提示词解决的是“当下怎么说”记忆解决的是“跨轮怎么记”两者配合起来Agent 才算真正有了连续工作的能力。
