前阵子和一位做Agent应用的开发者聊天他说了句让我印象很深的话以前写提示词像是在教一个聪明人答题现在写提示词像是在给一个执行力极强的实习生写工作手册——一句话没说清楚他就敢自己发挥。这句话基本就是Agentic AI提示工程和传统提示工程的分水岭。过去两年提示工程的核心在于训练模型“答得对”而进入Agentic AI阶段后提示工程的核心变成了让模型“做得稳”。当AI应用架构师把应用从“用户提问—模型回答”升级成“模型规划—调用工具—执行任务—自我纠错”的Agent形态时提示词就不再是一段描述需求的文字而是整套行为的操作系统。这篇文章想把Agentic AI提示工程掰开揉碎聊清楚它和传统提示词到底差在哪Agent提示系统有哪些设计原则从零搭一套可用的Agent提示方案要经过哪些步骤上线后哪些坑几乎人人都会踩。内容主要面向AI应用架构师也适合正在转型做Agent应用的后端工程师、提示词工程师。我尽量少堆概念多讲我在项目里实际拆过的方案和踩过的坑。1. 为什么说Agentic AI提示工程是AI应用架构师的新基本功1.1 Agent根本不是“大号聊天框”很多人第一次接触Agent会觉得它无非就是“带工具的聊天机器人”提示词写长一点、把工具说明贴进去就完事了。这个理解会让人在后面付出惨痛代价。Agentic AI和传统对话应用的本质区别在于传统应用里模型是“答题者”用户给一个问句模型给一个答案上下文靠历史消息硬堆而Agent应用里模型是“执行者”它要自己判断该做什么、该调用哪个工具、返回结果是否合理、要不要继续换一种方式重试整个过程是多步、循环、有副作用的。我常用一个类比传统提示词是给一位门卫写岗位说明你只需要告诉他“看到谁该放行、看到谁该拦下”Agent提示工程则是给一位项目经理写授权书你不仅要告诉他项目目标是什么还要告诉他优先级、资源边界、哪些决策必须请示、哪些情况可以直接收工甚至还要给他一套“做错之后怎么补救”的SOP。门卫只需要判断项目经理需要规划、决策、执行、纠偏两者的复杂度完全不在一个量级。举个例子一个订机票的Agent它不能只“生成一段订票建议”而是要依次完成查询可用航班、比对价格和时间、推荐最优方案、调用预订接口、向乘客确认行程、处理订票失败后的候补策略。中间任何一步出错后面都会连锁跑偏。假如提示词里没有写清楚“查询结果为空时怎么办”模型很可能编造一个航班号然后继续下单——这种幻觉在传统问答里只是答错题在Agent应用里就是真实事故。1.2 传统提示词的三个天花板我在团队里带过不少自称“会写提示词”的同学他们写的Prompt单看质量并不差策略清晰、用词严谨但一接到Agent场景就集体失灵。原因不是他们不会写提示词而是传统提示词的三个结构性短板被Agent场景放大了。第一个短板是单轮思维。传统Prompt的默认假设是一问一答模型不需要考虑“我上一步做了什么下一步该做什么”上下文里塞再多的历史对话模型仍然是在“接话”而不是在“推进任务”。Agent要求模型具备任务状态感它得知道当前做到哪一步、还剩几步、哪些前置条件没满足这些单靠扩张上下文是补不出来的必须在提示结构层面设计出来。第二个短板是只说不做。传统Prompt再长模型的输出边界仍然停留在文本。它不会真的去查数据库、不会发请求、不会改配置。Agent的提示系统必须让模型学会“借助外部工具落地动作”而工具的选取、参数的填充、返回值的解读每一个环节都会有全新的错误形式。我见过很多Prompt写得天花乱坠但工具描述写得像天书模型根本不是不会选工具而是看不懂每个工具到底是干什么的。第三个短板是缺乏闭环。传统Prompt答错了就答错了用户多问一句模型换个说法再答一遍没有任何自我修正的压力。Agent不一样工具返回错误、业务校验不过、任务执行超时这些反馈都必须能回到模型侧让模型意识到“刚才那条路走不通我换一种策略”。如果提示系统里没有设计这种反馈回路模型就会带着错误的中间结果一路狂奔最后给你一个逻辑自洽但完全错误的答案。1.3 急着学Prompt技巧前先认清这三类人的不同任务我观察到不同角色对Agentic AI提示工程的需求是完全不同的搞清楚自己属于哪一类学习路径才不会跑偏。第一类是AI应用架构师。这类人最需要的是“提示系统”而不是“提示技巧”。他们要设计System Prompt、工具描述框架、上下文管理策略、失败兜底机制甚至要把提示词当成软件模块去管理版本、做回归测试。对他们来说提示工程已经变成了一种架构设计工作核心命题是怎么让大模型驱动的系统在无人值守时依然稳得住。第二类是正在做Agent应用的后端或全栈工程师。他们的痛点通常是“模型调用我接了工具我也注册了可是Agent总在奇怪的地方卡住”。这类人需要的是可复用的排查方法比如工具描述怎么写、输出怎么校验、循环怎么打断。我给团队定的要求是遇到Agent行为异常先不要怀疑模型笨而是按“提示描述歧义→工具返回缺失→上下文污染→缺少终止条件”这个顺序去查大概率一查一个准。第三类是提示词工程师。他们原有的“单条Prompt优化”能力依然有用但必须补上一个新维度多轮状态设计。Agent场景下最考验功力的不是辞藻而是你能不能设计出“模型随时知道自己在干什么、该干什么、干不动了怎么办”的提示结构。这部分人转型做Agent提示优势是有扎实的语言敏感度劣势是容易停留在“把提示写美”的老路上必须刻意训练工程思维。2. 设计Agent提示系统前请先想清楚这五个问题2.1 你写的是提示词还是一整套提示系统很多Agent项目死在第一步产品经理甩过来一句话你的Prompt呢然后就看着你一个人趴在键盘上憋一段长文本。真正在做Agent应用时我从来不会先写最终的那段Prompt而是先画一张“行为地图”。行为地图要回答五个问题这个Agent的边界在哪里它从哪个入口接收任务第一步做什么遇到异常找谁干完怎么收尾回答完这五个问题你才会意识到Agent根本不需要“一段提示词”它需要的是“一整套提示系统”。这套系统至少包含System Prompt身份与边界、工具描述集能力清单、历史消息策略短期记忆与长期记忆、输出校验规则防止不合格结果、失败反馈回路错误如何回到模型、兜底策略放弃时怎么办。我把这套系统画成一张表放在项目文档首页每个模块都有对应的提示词片段或代码逻辑。这样做的最大好处是当Agent行为出问题时你可以像查日志一样定位是哪个模块出了问题而不是面对一整段Prompt无从下手。一个反直觉的经验是把Agent的提示拆得越碎模型反而表现越稳。因为每个模块的职责单一模型不会在几百行的长文本里迷失重点。2.2 System Prompt三段式框架身份、任务、边界我看了大量网上流传的System Prompt普遍问题是“什么都想写什么都没写透”。总结下来真正有效的System Prompt只需要三段式结构这三段的优先级从高到低不可颠倒。第一段是身份。告诉模型“你是谁、你在哪个系统里、你服务谁”。身份不是用来卖人设的而是用来设定立场和能力范围。比如“你是企业IT服务台的自动处理助手负责处理员工提交的运维工单不负责解答财务报销问题”。这句话看着简单但它直接决定了模型面对超范围请求时的第一反应是礼貌拒绝还是强行回答。第二段是任务。任务不能只写目标必须写执行流程。我会在System Prompt里用编号列出标准作业顺序“收到请求后先判断是否属于工单范围→属于则提取关键字段→调用工单创建工具→根据返回结果输出工单号→工单异常时转交人工”。每一条都对应一个明确的模型行为模型在真实运行时就有了“照章办事”的依据而不是凭语义猜下一步。写任务段落时我有个铁律每个动词都必须能对应到一个具体动作或一次工具调用凡是表达模糊的词语全部删掉。第三段是边界。这一段的地位被我放得极高因为Agent最大的风险不是“不干活”而是“乱干活”。边界要写清三件事绝对不能做的事如不可逆操作必须二次确认、必须请示的情况如涉及金额、权限升级、何时强制终止如达到最大重试次数。边界描述的标准是可以逐条判定比如“当用户明确要求删除数据时必须回复无法自动执行并转人工”没有灰色地带。下面是我在项目里用过的一版简化模板你可以直接拿来改造# 身份 你是[角色]运行在[系统名称]中服务对象是[用户群体]。 你的能力范围是[列举能力]。不在范围内的请求直接拒绝并说明原因。 # 任务 当收到用户请求时严格按照以下顺序执行 1. 判断请求是否合法、参数是否完整 2. 若需要调用工具选择最合适的工具并填写参数 3. 读取工具返回结果判断是否符合预期 4. 若结果异常最多重试N次每次重试前分析失败原因 5. 输出最终结果格式为[具体要求]。 # 边界 - 禁止[具体不可逆动作]除非用户明确二次确认 - 当出现[情况A]或[情况B]时立即停止执行并转交人工 - 不要编造工具返回值。工具报错时如实报告错误内容 - 当用户说“停止”或达到最大尝试次数时立即终止。2.3 让Agent“会用工具”的提示策略描述语义是核心资产Agent和工具之间的交互本质上是一个“模型读描述、选工具、填参数、读结果”的过程。工具列表在模型眼里就是一排“商品说明”你的描述写得好不好直接决定它选得准不准。我在项目里总结出的工具描述四条经验已经成了团队内部的标准。第一条工具名称用“动词对象”的格式。比如search_employee_info比get_info清晰得多create_leave_request比do_task好。模型在十几个工具里做选择时名称就是最高权重的信息命名含糊等于给模型埋雷。第二条描述里必须写“什么时候用”和“什么时候不用”。这条是最容易被忽略的。比如一个查询年假余额的工具描述不能只写“查询年假余额”要写“当用户询问可休假天数、年假余额、剩余假期时使用当用户询问请假审批流程时不要使用此工具应调用leave_approval_status”。正反两个方向的约束能把误调用率压下去一大截。实测下来加了“不要使用场景”之后工具选择准确率能提升将近十个百分点。第三条参数描述要带格式示例和边界说明。模型填参数也会犯错常见的是把日期格式写错、把ID类型搞混。我在每个参数的description里都会追加“格式示例”和“注意边界”比如“amount数字单位元支持两位小数例如298.50注意不接受负数”。这些小注释不占多少token却能把参数校验错误率降下一大截。第四条为容易混淆的工具配Few-shot示例。工具数量一多模型不可避免会出现“A工具能解决但选了B工具”的情况。我的办法是在System Prompt里单独放一个“工具选择示例”小节用两到三个完整例子展示“用户请求→应当选择的工具→填入的参数”让模型模仿这个决策链路。这个做法比我反复在工具描述里加形容词有效得多。2.4 上下文和记忆不给Agent吃“营养过剩”的垃圾Agent执行过程中每一轮工具调用都会产生大量中间结果这些东西如果全部堆进历史消息很快会撑爆上下文窗口而且会把模型的注意力带偏。我见过一个真实案例某Agent在执行到第四步时突然“忘了”最初的任务要求原因就是中间日志太多重要信息被淹没。我的做法是把上下文分成三层。第一层是任务上下文也就是用户最初的目标、关键参数、约束条件这一层始终放在消息列表的最前面并且每次更新时保持精简。第二层是执行上下文也就是已经完成的步骤和工具调用结果这部分要做结构化压缩比如只保留“调用了某工具、返回是否成功、结果摘要”而不是把原始JSON全量塞回去。第三层是临时上下文比如中间的错误日志、调试信息这类内容用完即弃不进入下一轮。如果Agent任务跨度很长还应该给模型一个“状态小结”机制每隔若干轮要求模型用一句话总结当前进展、已完成步骤、剩余步骤、最新风险。这个小结会替换掉前面杂乱的执行历史既节省token又让模型时刻有一张清晰的进度地图。很多Agent跑着跑着就“失忆”本质上就是上下文管理没做好而不是模型的记忆能力不行。3. 从零搭一套Agent提示方案核心环节实操拆解3.1 第一步把业务任务拆成最小可执行单元我习惯用一个最朴素的工具来开场一张A4纸把某个Agent要完成的业务任务从入口到出口画成流程图。不用画得花哨重点是拆分到每个节点都能回答两个问题这一步是纯文本判断还是需要调用工具如果是调用工具输入输出分别是什么用一个内部门禁系统Agent的例子。业务任务是“员工提交门禁异常工单后Agent负责初步处理”。我拆出来的单元是意图识别判断是不是门禁类问题→身份核验从请求中提取工号并查询员工信息→权限检查判断该员工是否在本楼宇有访问权限→异常诊断查询最近门禁记录判断是否设备故障→处理动作调用远程重置权限工具或派发维修单→结果反馈告知员工处理结果或转人工。拆完这一步你是不是发现最终那段System Prompt其实就是把这六个单元连起来外加每个单元的触发条件和异常出口而已。如果没有这一步你写Prompt时就会特别心虚因为你不确定模型会在哪些节点需要什么信息、会遇到什么异常。拆解完成后我会顺手统计每个单元是调用工具还是纯对话这个比例决定了Prompt的技术复杂度也决定了后续测试的重点。3.2 第二步编写工具Schema与Few-shot示例工具Schema是Agent提示系统里最容易被低估的部分。很多开发者写工具描述时像写代码注释惜字如金但模型不是编译器它靠自然语言理解工具用途描述必须转换成语义清晰的“用户视角”语言。我放一个实际用过的工具定义片段你可以对照感受一下差距{ name: query_leave_balance, description: 查询员工的年假余额。当用户询问我还有多少年假、年假剩几天、今年还能休几天等类似问题时使用如果用户询问的是请假审批进度请改用query_leave_approval不要调用本工具。, parameters: { type: object, properties: { employee_id: { type: string, description: 员工工号格式如E10086员工本人查询时无需传参默认取当前用户 }, year: { type: integer, description: 查询的年假年度默认是当前自然年例如2025 } }, required: [employee_id] } }这里有个很关键的设计employee_id默认取当前用户。一般来说Agent系统会通过身份认证自动注入用户ID不需要用户自己报工号也不应该允许用户随便传别人的工号。把这个逻辑写进参数描述能有效防止水平越权。工具写完我还会在System Prompt里附上三个Few-shot示例。第一个是正常场景展示正确的工具调用链路第二个是边界场景展示一个看起来能调用、实际不该调用的情况比如“员工查年假但实际想查加班调休”模型应输出“解释并引导用户使用调休查询工具”第三个是拒绝场景展示用户请求超出权限范围时模型如何礼貌拒绝并转人工。这些示例不需要多每个工具组两到三个模型就能在类似决策上获得足够参照。3.3 第三步引入“先想后做”的推理与反思机制Agent提示系统里还有一个绕不开的模块怎么让模型在执行途中保持清醒。如果只写“请一步一步处理”模型确实会分步但它不会主动评估“这一步的结果是否合理、下一步是否要继续”。所以我在Prompt里显式植入了一个推理循环让模型每走一步都经过“状态分析-决策-行动-观察”的闭环。这个循环的提示写法有很多变体我目前用的是一套稳定的四段式结构在处理任务时你必须在每轮输出前按以下格式推理 Thought: 当前任务进行到什么阶段我手上有哪些信息下一步的关键决策是什么 Action: 我决定调用什么工具或做一次什么判断 Observation: 刚才的动作返回了什么信息是否符合预期如果不符合失败原因可能是什么 然后根据Observation决定继续执行还是调整策略。当所有必要步骤完成且结果得到确认时输出Final Answer。这套模式的本质是让模型把“推理”显式化。模型在生成文本时先想后写的概率远大于直接写而这段Thought/Action/Observation就是给模型筑了一条“强制思考”的轨道防止它跳跃式决策。实测中显式说明推理结构之后复杂任务的成功率有明显提升因为模型不再贸然从一个状态跳到下一个状态。反思机制我放在任务快要结束的时候。我会在System Prompt里加一条硬性要求在输出最终结果前必须做一次自查检查三点我是否真的调用了工具而不是凭记忆回答工具返回的数据是否都体现在结论里有没有超出用户授权的操作这一条能拦住相当一部分“完美但错误”的答案。3.4 第四步建立Agent行为的质量评估基线没有评估就上线是Agent项目最危险的赌博。因为Agent行为是动态生成的你无法像测普通接口一样断言输出字符串必须建立一套多维度的评估基线。我建议至少盯五个指标。第一是任务成功率指端到端是否达成业务目标这是北极星指标。第二是工具选择准确率指Agent选择的工具和专家标注的一致比例这个指标能单独暴露工具描述的问题。第三是无效调用率指Agent调用了工具但参数校验失败或工具返回业务错误的次数占比这个指标高说明理解有偏差或参数描述不清。第四是平均任务轮数轮数太长说明Agent在低效试探拖慢了响应也烧了token。第五是成本指标无谓的重试、过长的上下文都是成本黑洞所以要统计单任务平均token消耗并设置超时熔断。评估集怎么造我基本不依赖公开Prompt模板而是直接从历史真实请求里采样覆盖正常请求、模糊请求、缺参请求、恶意越权请求四类。每种至少二十条标注好“期望工具调用序列”和“期望最终结果”。每轮迭代后跑一遍回归用我前面说的五维指标对比变化。这个评估集是Agent提示系统的生命线没有它后续任何Prompt调整都是盲改。4. Agent上线后最容易翻车的四个场景与排查实录4.1 场景一Agent在工具调用里原地打转有一次我负责的一个工单处理Agent出现了这种情况它不停调用查询工具每轮都返回“工单不存在”而它下一个动作居然是“再查询一次”如此反复直到触发最大重试次数。从日志看模型每一轮都在认真分析但分析内容其实是一模一样的复读机。排查下来根本原因是提示系统里缺少两个关键约束终止条件和不重试说明。System Prompt里只写了“如果查询失败则继续尝试”没有定义“连续失败多少次必须停止并转人工”。工具描述里也没有说明“工单状态仅为关闭时返回不存在此时应引导用户提交新工单”。模型在信息不充分的情况下只会机械地重复同一个动作。解法很简单一是在System Prompt边界段加入“同一工具调用失败超过两次禁止继续重试必须输出失败报告并转人工”二是丰富工具描述中的失败语义把“返回为空”和“查询不到但应该存在”以及“查询不到且任务无效”区分开。修复后这类死循环几乎绝迹。4.2 场景二上下文越滚越长行为越来越离谱另一个项目里Agent本来沿着正确路径执行但在第十五轮左右突然开始偏离任务去回答和初始目标完全不相关的问题。查日志时发现它的上下文里堆了大量工具返回的原始JSON包括一些历史工单的描述文本模型被这些无关信息“带跑”了。这就是典型的上下文污染。长期记忆没做筛选中间结果被无差别塞进历史。我的修复方案分三步第一工具返回结果入库时做字段裁剪只保留模型决策真正需要的核心字段第二每隔若干轮插入一次Agent状态小结用一段一两句话的摘要替换掉前面冗长的执行历史第三在System Prompt里明确“只有最近一次工具返回和状态小结属于当前有效上下文之前的历史记录仅供参考”。这样改造后Agent的长任务稳定性明显提升token费用也降了将近三成。4.3 场景三Agent自作主张做了越权操作这类问题最吓人。某次测试中用户只是问“查询某同事是否在通讯录里”Agent居然在用户没有明确授权的情况下调用了一个“发送通知”工具试图给该同事发一条系统消息。幸运的是当时还在灰度测试阶段没有造成实际影响。越权行为的根源一是工具描述写得太宽泛让模型误以为“这个工具可以被任何查询场景顺带使用”二是System Prompt的边界段里没有明确“发送通知、修改数据、删除数据”属于高权限动作必须二次确认。我把工具描述里与发送、修改、删除相关的动词全部加了“必须获得用户明确授权”的前置条件并在System Prompt中新增一条硬规则任何产生外部副作用的工具调用都需要独立的用户确认步骤不能在推理过程中隐含触发。自那以后监控里再也没出现一次未授权副作用调用。4.4 Agent故障排查速查表与三条兜底原则为了减少排查时试错时间我整理了一张速查表每次Agent行为异常团队都先按这张表定位现象可能原因排查方向常用解法反复调用同一工具缺少终止条件查看System Prompt边界段增加最大重试次数与失败转人工规则选了错误的工具工具描述存在歧义检查工具名与description增加“何时不用”的反向描述参数填错或格式错误参数description不明确查看参数示例和约束补充格式示例、枚举值和边界说明执行中丢失初始目标上下文被中间结果污染分析最后几轮历史消息引入状态小结和上下文裁剪调用高权限工具边界规则缺失检查System Prompt边界段增加二次确认机制和权限分层编造工具返回值返回结果未校验检查输出校验逻辑增加工具结果的规则校验与回填三条兜底原则是任何任务必须有终止条件任何有副作用的动作必须有确认环节任何连续异常都必须有降级到人工的通道。把这三条写进系统Agent的“胆子”就会被牢牢关在笼子里。5. 进阶方向让Agent提示系统更稳更省钱的几条经验5.1 提示词版本管理与回归测试Agent提示系统上线后改动是必然的但很多团队把Prompt当“一次性文案”直接改到线上出了事再回滚。这种粗放做法在Agent场景下风险极高因为一次提示措辞的微调可能不影响普通对话却会连锁改变工具调用行为。我现在的做法是把所有Prompt文本按模块存进Git仓库每次改动都有diff记录commit message写清楚原因和预期影响。同时维护一套自动化回归脚本每次改动后跑一遍前面提到的评估集如果任务成功率或工具选择准确率下降超过一个百分点就必须重新调整。这个流程一开始会有些繁琐但对Agent项目来说Prompt就是核心代码不纳入工程化管理是没法长期迭代的。5.2 多Agent协作场景下的提示职责拆分复杂业务很少靠单个Agent全流程包干我最近在做的系统里就有路由Agent、执行Agent和审计Agent三个角色。多Agent场景下提示工程的重点从“写执行步骤”变成了“写协作协议”。路由Agent的System Prompt最核心的职责是分类和分派它不需要掌握具体业务工具的细节只需要识别请求类型并决定交给哪个下游Agent。执行Agent的System Prompt要写清楚自己的专业边界超出边界的请求必须回退给路由Agent不能硬答。审计Agent最特殊它的System Prompt里全是“检查什么、记录什么、什么情况下必须告警”它的输出不面向用户只面向日志和监控系统。三个Agent之间还会约定一种内部消息格式用纯文本的“请求方→目标方→意图→关键参数”结构传递信息比让Agent自由对话要可控得多。5.3 个人体会提示工程的本质是给不确定性上保险做Agent提示这行快两年我最大的体会是Agentic AI提示工程本质上不是“把提示词写得更华丽”而是“把不可控的行为空间压缩到可控范围”。模型本身有不确定性同样一句提示不同轮次可能产生不同结果架构师能做的就是用结构化的提示系统、严格的边界规则、完善的事后校验把这种不确定性圈起来让系统在绝大多数情况下稳定可用。我也踩过不少次坑。早先总想着让Prompt“聪明一点”给模型更大的自由去规划结果Agent自由过了头做了很多我没想到的事。后来学乖了每条Prompt都先问自己一句如果这是一个真实实习生我给它的指令够不够明确它遇到异常知道该问谁吗它会不会误解我的意图去干别的这几次自问往往就能筛掉大半问题。如果你也正在做Agent应用我的建议是少看那些“惊艳”的Prompt炫技多花时间在工具描述、边界设计、上下文治理和回归评估上。Agentic AI提示工程的功夫大多花在提示词之外。