前阵子搭一个自动化处理任务需要大模型在不同数据表之间做判断、跳转、汇总前后涉及十几步操作。一开始我用自然对话的方式把需求一股脑怼给模型结果它答非所问经常在某一步返工。后来我把Prompt改写成一套指令集把角色、目标、边界、输出格式全部写死任务立刻顺了十几个步骤几乎零返工。这件事让我彻底明白一个道理Prompt本质上是指令不是聊天。这个认知直接决定了你搭出来的Agent是真能用还是只能用来演示。很多人问过我同一个问题Agent和大模型到底有什么区别我通常会反问一个问题——你是把模型当一个会聊天的同事还是当一个能执行任务的工人如果你的回答是后者那你已经在Agent的门口了。Agent的核心从来不是模型本身而是怎么通过Prompt把模型的输出行为约束成一条可靠的流水线。本文不聊那些玄乎的框架概念就围绕如何用Prompt驱动大模型执行复杂任务这件事拆开揉碎了讲清楚。1. 先搞清楚Agent到底在做什么1.1 Agent的底层循环感知、规划、行动无论外面讲的Agent方案多花哨剥开外壳核心都是一个循环模型先理解当前状态然后规划下一步做什么接着调一个工具或者输出一段内容再根据结果决定下一步。这个循环有点像人做菜先看冰箱里有什么感知决定做哪几道菜规划洗菜切菜下锅行动尝尝咸淡再调整。在代码层面Agent的循环由控制器实现而这个控制器的大脑就是大模型。模型本身不执行代码不会读文件、不会发请求真正干活的是工具或函数。Prompt是模型和工具之间的粘合剂模型根据Prompt里的指令决定什么时候调用哪个工具、传入什么参数、拿到结果后又如何处理。很多人搭Agent失败原因就出在这里他们以为把多个工具挂在模型上就是Agent结果模型根本不知道该在什么条件下调用哪个工具。不是模型不行是Prompt里没有把什么时候做什么写成明确的决策规则。1.2 Prompt在Agent循环里的真正位置我把Prompt在Agent里的角色拆成三层理解这三层你就能明白为什么指令型写法比对话型写法重要一百倍。第一层是系统角色约束。这个层级的Prompt定义模型你是谁、你要达成什么目标、你做事的原则是什么。比如你让它当数据清洗专员它就会主动检查空值、格式、重复项如果你只是闲聊式地说帮我处理一个表格它就不知道自己要负什么责任。第二层是一次任务流的执行计划。这一层就是把复杂任务的目标和边界条件讲清楚相当于给模型一份任务书而不是抛一个问题。任务书里要有输入、处理流程、输出标准、异常情况处理。第三层是分支决策逻辑。复杂任务一定会遇到多种分支情况比如用户输入不明确、工具返回异常、模型推理中途发现缺数据。这些决策规则用if-then式的语言写进Prompt模型才能自主判断否则一遇到边界情况就卡壳或者胡编。1.3 为什么对话式不够用我见过最多的翻车场景是这样开发者先说一句帮我分析这个数据模型反问什么数据再补一句再反问……一来一回看似是AI在对话实际效率很低而且一旦对话轮次超过5轮模型很容易把之前的约束忘掉。对话式Prompt的问题是信息是增量累积的每一轮都在覆盖之前的设定模型经常分不清哪条指令还有效哪条已经失效。而指令式Prompt是静态完整的。你一次性把目标、规则、工具清单、输出格式全部声明清楚模型每次都是基于同一份指令执行。这就像给新员工一本操作手册而不是靠大家口头传话。Google得再清楚一点对话是面向过程的指令是面向结果的。Agent要的是结果所以必须用指令式写法。2. 指令型Prompt的设计原则复杂任务拆解技法2.1 目标要写成可验收的交付物而不是愿望我说一个最常见的废话式Prompt请帮我做一个市场分析。你猜模型会输出什么一篇看起来通顺但没有任何执行力的综述。这句话没有验收标准没有产品边界没有数据来源模型只能自行脑补。设计指令型Prompt的第一步是把目标改写成可验收的交付物。你需要问自己四个问题输入是什么格式处理过程要经过哪些步骤输出是什么结构怎么判断输出是对的把这些问题写进Prompt模型才知道自己交付的是什么东西。举个例子把分析市场改成读取附件中的销售数据CSV文件按地区维度统计近三个月的销售额变化输出包含各地区增长率、排名和异常波动提示的Markdown表格数据不足时明确标注数据缺失。这才是指令目标被拆成了输入、处理、输出、异常四个部分每部分都能检验。2.2 复杂任务必须拆成多段式子任务模型一次性处理的信息量是有限的尤其当任务超过6个步骤的时候指令的复杂度会指数级上升。我常用的做法是把一个任务拆成三个层次任务级描述一两句话说清楚整个任务目标步骤级执行链按顺序列出主流程的每一个关键步骤原子级操作指令每步用什么工具、输入什么参数、返回什么结构。拆完之后Prompt的长短不是问题关键是层级要清楚。别用一大段话把所有信息推到模型面前而是用分段结构让模型能顺着流程走。实际上主流的指令型Prompt框架都是这么设计的你在外层设定系统行为内层给任务上下文再底层给工具规则。层级越清晰模型输出越稳定。2.3 给模型精确的工具边界与调用触发条件在Agent场景中模型不一定非要用工具它可以纯靠推理输出。这就引出一个关键问题如果Prompt没有明确说明什么时候必须调用工具模型就会自己脑补计算结果。我踩过一个坑让它先查数据库再回答问题结果它直接把猜测值当成了查询结果因为Prompt里没写你只能基于检索结果回答。给工具设定边界的写法分三部分工具描述讲清楚工具是干什么的触发条件说明什么时候必须调用它禁用条件说明什么情况下禁止调用。比如一个天气查询工具触发条件要写成当用户询问任何地点的天气时必须调用get_weather工具后回答禁用条件写成当用户询问历史天气时禁止调用该工具并提示暂不支持。工具边界本质上是在给模型立规矩。规矩越多模型的自由度越低但任务的执行可靠性就越高。你要想清楚一个取舍模型自由度是拿来换创造力的不是拿来换准确率的Agent场景里准确率优先。3. 实操用Prompt驱动一个复杂任务的全流程拆解3.1 第一步写清输入定义与预处理规则进入实操我们先模拟一个真实的复杂任务我用它验证过指令型写法效果稳定。任务背景是这样的某个电商运营团队每天会收到一份订单汇总表里面混着不同渠道的原始数据有重复行、格式不统一、金额带单位符号等问题。业务需求是每天自动清理数据、汇总各渠道销售额并生成一份简报。先把输入定义清楚。我在Prompt里写明输入是一个CSV文件路径包含用户ID、订单号、金额、渠道、时间五个字段其中金额字段可能包含¥符号和千分位逗号时间格式存在2024/1/1和2024-01-01两种写法。这些细节全部在白纸黑字写明模型就不会在清洗环节偷懒。再写预处理规则。这里建议用列表逐条声明。我写的规则包括金额字段去除货币符号和逗号转换为浮点数时间字段统一转为标准日期格式按订单号去重同一订单号保留最新一条记录渠道字段归一化比如微信和wxxcx要统一成微信小程序。每一条规则都是一个可执行的判断模型拿到之后能直接照着做。3.2 第二步设计主流程的步骤链主流程是任务的中枢建议用编号列表逐条写出顺序并且每一条都要指明依赖条件。我给这个清洗任务设计了这样一串流程读取CSV文件检查文件是否存在不存在则直接返回错误码。按3.1中的预处理规则清洗数据逐条处理字段。将清洗结果按渠道分组合并计算每组订单总量、销售总额、客单价。对比数据中的异常订单金额为负、时间为空单独生成异常清单。把所有汇总数据按模板输出。流程写完之后我在Prompt中又加了一条总约束严格按照上述顺序执行不允许跳步每一步输出必要的中间结果供检查。这一步相当重要因为模型默认会压缩步骤把好几步攒在一起一次性输出既不便于检查也容易出错。加了这条之后模型就老实多了会一步一步走中间结果也会留出来。3.3 第三步写清输出格式与分支处理规则输出格式是Agent场景里的重中之重。我在实际开发中发现模型只要开了自由发挥的口子输出格式就一定会飘。所以我在Prompt里直接给出一份JSON输出模板并声明只允许输出以下JSON结构不允许任何额外文字说明。输出模板我一般会具体到每个字段名和类型summary字段里放总销售额、总订单数、有效订单数channel_stats是个数组每个元素包含channel、total_amount、order_count、avg_order_valueanomaly_list数组里放异常订单的订单号和异常原因。字段命名我还会额外加一条要求的英文小写下划线命名法。分支处理规则指的是数据异常时的应对策略。我写的是如果某个渠道完全没有数据不允许猜测或补零直接在提示里标注该渠道无数据如果发现金额为负的订单把它放进异常清单而不是直接丢弃如果CSV字段缺失返回错误码FIELD_MISSING并列出缺失字段名。这些规则的作用是防止模型在遇到边界情况时自作聪明。3.4 第四步在Prompt里注入工具调用指令上面还只是模型纯推理的输出要接入真正的工具执行还需要在Prompt里指定工具调用的语法。以常见的function calling机制为例我会在Prompt中声明可用的工具清单并为每个工具写明名称、功能描述、参数schema和返回结构。比如一个工具叫calculate_summary参数包括data_source字符串类型填数据文件路径和group_by数组类型填分组维度列表。我在Prompt里给模型的指令是当需要计算销售汇总时必须调用calculate_summary工具并把结果作为最终输出的数据来源禁止基于猜测直接填写数字。这个写法的关键点是数据来源四个字。模型在没有外部数据时特别喜欢编数字你只要让它明确答案必须来自工具返回,它就不敢瞎编。配合上一条工具返回异常时如实返回错误信息的约束整个链路才算完整。4. 完整Prompt模板可直接抄作业的复杂度写法4.1 一套经过验证的指令型Prompt结构我把上面整个流程沉淀成一套模板分五个区块角色定义区、任务目标区、输入规则区、执行流程区、输出规范区。每个区块用固定分隔标注这样模型能准确识别结构的边界。角色定义区往往是很多人忽略的但它的作用比你想象的大。我给那个清洗任务定义的角色是资深数据分析助理并补充了一句人格约束你做事严谨不允许猜测不允许省略中间校验步骤。这个角色不是摆设它让模型在输出行为上更接近一个谨慎的助手而不是天马行空的聊天模型。这五个区块的顺序也有讲究角色在最前让模型先进入工作状态目标和输入规则紧接着让模型明确任务边界执行流程在中间是模型工作的主线输出规范放最后起到约束出口的作用。从信息处理顺序上看这个排列跟模型逐块理解上下文的方式匹配。4.2 模板逐字段解析参数设计背后的逻辑我用表格把这个模板的核心字段拆一遍方便你直接对照检查自己写的Prompt里缺了什么。字段区块核心内容设计逻辑常见缺失角色定义角色身份、人格约束让模型以特定行为模式工作完全没有角色设定任务目标一句话目标、交付物让模型清楚最终要交什么只有问题没有目标输入规则字段定义、清洗规则避免模型自行脑补数据格式输入描述含糊执行流程有序步骤链、依赖关系保证模型逐步推进不跳步流程揉成一团没有顺序输出规范JSON模板、禁止项让结果可以直接被程序消费让模型自由发挥写作文注意输出规范区块里的禁止项尤其需要重点设计。我写禁止输出Markdown以外的文字、禁止输出空字段、禁止用省略号表示数据、禁止在JSON里加注释这些都是从实际翻车案例里提炼出来的。模型默认会输出解释性文字你要把它关掉它才知道这是纯输出格式任务。4.3 一个双工具调用的完整场景演示单一工具指令不难难点在于多个工具之间的切换。我扩展一下前面的场景除了calculate_summary再加一个export_chart工具用于生成销售趋势图表。两个工具的触发条件必须明确分开只有在做数据汇总计算时调用calculate_summary只有在用户明确要求趋势图或图表展示时调用export_chart。完整的工具调用指令我这么写工具调用规则execute_calculation用于数据计算当你需要任何数字结果时必须调用generate_chart仅当你被要求画图展示趋势生成图表时调用。如果一次任务需要两个工具先执行execute_calculation拿到数据再调用generate_chart不允许并行调用。我建议用不允许并行调用这种强约束因为有些模型在工具充裕时经常自作主张同时调多个工具结果数据还没算完图就生成了。实际测试下来把调用顺序和条件全部写清之后工具切换的正确率提升非常明显。5. 实际过程中的踩坑和调试经验5.1 模型假装执行了任务我踩过的头号大坑是模型在没有任何工具调用的情况下凭空输出了一版看起来合理的汇总结果。日志里没有任何工具调用记录它却把金额、单量算得头头是道。这种情况的解释很简单模型基于训练数据里的常识在编答案但它编出来的数字几乎必错。排查方法有两个方向。一是看日志如果模型回答内容涉及数据统计但你压根没看到函数调用记录那八成就是假装执行。二是在Prompt中加数据来源声明强制模型在输出末尾带上本次数据来源比如数据来源calculate_summary工具返回如果它写不出来说明没有真调用。这招对我帮助很大建议直接抄。5.2 指令冲突导致的死循环另一个让人抓狂的问题是模型在步骤间反复重复比如数据清洗做完一遍汇总的时候又清洗一遍甚至把同一份数据反复处理。出现这种情况往往是因为Prompt里多次出现了同一个动词模型分不清边界。我的修复办法是给每个步骤加状态标记用步骤2输出-用于步骤3输入这种箭头写法把数据流转关系写清楚并加一条总约束每个处理阶段只能执行一次禁止重复处理已经进入下一阶段的数据。你会发现指令里的歧义多半不是句子不通而是信息流方向不明确。5.3 调试Agent Prompt的三步排查法如果你搭的Agent不稳定别上来就改Prompt先按顺序排查。第一步看模型有没有正确调用工具检查日志里的函数调用列表工具都没调后面全是瞎谈。第二步看输入数据到模型里的实际表现是不是数据格式描述和真实数据不一致模型被误导了。第三步做单步隔离测试把执行流程里的某一步单独抠出来喂给模型看它在这步上的行为是否正确。三步排查能筛掉大部分问题。我自己最深刻的体验是很多Agent不稳定不是模型笨是Prompt把不相关的指令揉在一起模型每轮都在猜哪条是当前有效指令。把每块指令隔离清楚之后整个系统的行为立刻变得可预测。5.4 提高输出稳定性的几个独家小技巧分享几个压箱底的小经验。第一在Prompt结尾加一条重新审视指令输出前请重新检查是否所有工具调用都有结果支撑是否所有字段都有值是否符合指定的JSON结构。这一句能显著减少低级错误。第二固定分隔符。我在区分数据内容和指令时用三引号包裹例如原始数据这里放数据内容模型对这种边界更敏感不容易把数据内容当成执行指令。第三温度参数降下来。指令型Agent任务的温度参数建议设为0或者0.1。温度高了创造力就高创造力在Agent场景里就是编造数据的元凶。这条写在配置里不写进Prompt。第四用如果……那么……否则……句式写分支规则。模型对这种条件句式的理解能力比自由描述强得多分支一多用条件句清晰程度直接上一个台阶。6. 几个值得扩展的方向当你能用指令型Prompt稳定驱动单个Agent之后下一步其实还有不少好做的方向。多Agent协作就是其中之一。你可以把一个大任务拆给多个子Agent每个子Agent只负责一个模块再用一个编排层把它们的输出串起来。这时候指令型Prompt的价值更大因为你得让每个子Agent都遵循同样的输出规范否则最后汇总的时候数据格式对不上。我的经验是给每个子Agent定义独立的角色和输出schema汇总时用统一格式校验比在一个Agent里塞所有任务要稳定得多。另外一个方向是把Prompt模板工程化。我看到过一种做法把角色、目标、工具清单、输出schema都变成配置文件里的字段运行时渲染成完整Prompt。好处是改参数不用重新编译代码业务人员也能自己调整某个模块的描述。这个思路相当于把Prompt当作代码来管理版本、权限、灰度都能跟进去。如果你在做真实业务落地建议多记录一些失败样本反哺到Prompt里作为负面示例。模型从不要做什么里学到的往往比要做什么更直接。把一个具体的错误案例放进禁止项区块下次再遇到同类情况翻车率会明显下降。我个人实际做下来最深的体会是写指令型Prompt不靠灵感靠的是结构化和穷举边界条件就像写产品需求文档。把目标、流程、例外、输出每一层都想清楚模型自然就像个靠谱的执行者。反过来你哪一层偷懒模型就在哪一层发挥它发明的本性。把这套思路练熟你会发现所谓Agent核心并没有那么玄本质上就是一套纪律严明的沟通协议。