做Agent开发这件事，做得越久，越觉得“提示词”这三个字已经不太够用了。前几年的主流做法，核心就是把一个任务描述清楚，让模型输出符合预期的答案。但当我真正开始搭建一个能自主调用工具、多轮推进任务的Agent时，才发现“一次问答”式的Prompting根本撑不起Agent的复杂度。你需要的不再是一段话，而是一整套可运行的心智系统。从Prompting到系统Prompting，不是把Prompt写长一点，而是换一种“以Agent为主体”的思维方式来设计。这就是我这一章想聊的核心：Agent-Native心智。如果你正在做Agent应用开发，或者你手头有一个“看起来能聊几句，但一接工具就失控”的Prompt，这篇文章应该对你有用。我会从心智切换讲起，拆解系统Prompt的模块架构，再用一个电商售后客服Agent的完整案例，演示怎么把理论落成可运行的配置。全文不会涉及太深的理论，更多是我在实际项目里踩过坑、验证过、最后沉淀下来的操作方法。1. 从Prompting到系统Prompting：Agent开发的心智切换1.1 Prompting的边界在哪里早年做LLM应用，我常跟人讲：Prompting就是“把需求说清楚”。比如让模型总结邮件、写一份会议纪要、解释某段代码，这些场景下模型是“一次性回答器”，你把上下文和指令给进去，它吐出一个答案。这种方式适合信息提取、文本改写、零散问答，但不太适合需要持续决策和执行的任务。举个具体的例子。早期我做过一个自动化客服Demo，界面就是一个对话框，背后用一段Prompt对模型说“你是客服，请回答用户问题”。用户问“什么时候发货”，效果还行；用户问“帮我查一下订单号123456的物流”，模型就开始编：“该订单正在运输途中，预计明天送达。”它没有接任何物流系统，完全是基于概率生成的一段像话的回复。这就是Prompting的第一个边界：没有工具、没有数据源，模型只能“想象”。更麻烦的是多轮场景。用户说“查一下订单”，模型回答了；用户接着说“那退了吧”，模型又基于上一轮猜测“那我帮您申请退款”。它不知道你是否有权限退、不知道退多少、不知道流程是什么。单轮Prompting本质上没有“状态”概念，你让它连续执行，它只能靠上下文里的蛛丝马迹自圆其说。所以Prompting的适用边界其实很清楚：适合一次性、低风险、不需要外部系统参与的认知任务。一旦任务涉及状态流转、工具操作、异常恢复、合规校验，单靠Prompting就力不从心了。在Agent这类场景里，如果坚持用传统Prompt方式，你得到的会是一个“嘴上什么都答应、实际什么都做不了”的聊天机器人。1.2 Agent-Native的本质：不只是对话，而是执行体系我在很多项目里尝试过把单Prompt强行拉长来解决Agent化问题，结果大概率失败。内容一旦超过3000字，模型就开始“选择性失明”，前面写的规则后面忘了，遇到冲突时不知道按哪条执行。后来我意识到，问题不在Prompt的长度，而在于思考方式。Agent-Native心智，核心是“以Agent为主体的系统思维”。你把Agent当成团队里一个真实成员，它有自己的职责边界、可用工具、决策流程、记忆规则、汇报格式。你不是在跟它对话，而是在为它设计一套可以自主运行的心智系统。这句话怎么理解？举个例子。你雇一个实习生处理售后，不会只说一句“你去处理售后”，而是会告诉他：你能碰什么系统、不能碰什么；遇到什么情况用什么工具；退款超过多少需要主管审批；用户情绪激烈时先安抚再处理；每件事办完怎么汇报。这就是一份完整的“岗位说明书”。系统Prompting，就是为Agent写这份“岗位说明书”。从这个角度看，Agent-Native心智有四个关键维度。一是状态感，Agent要知道会话进行到哪一步，当前待办是什么，而不是每轮都从零开始瞎猜。二是目标感，每个动作都要锚定用户最初的目标，中途出现分叉时要能回到主线。三是契约感，工具不是“随缘调用”，而是有明确的触发条件、参数校验、失败处理。四是自省感，Agent要能判断自己“现在能不能办成”，办不成就如实说，并给出替代路径。这四个维度在传统Prompting里很难被完整表达，因为它们要求的不是“一句指令”，而是一套互相约束的规则和流程。系统Prompting就是为了承载这套规则而生的。一开始你可能觉得系统Prompt只是“更长的Prompt”，但用久了会发现，它其实是一个独立的设计产物，和“回答问题用的指令”完全不在一个层级。2. 系统Prompting的架构拆解：一份可落地的设计蓝图2.1 传统Prompt与系统Prompt的差异对照先做一次对照，帮大家把概念落地。维度传统Prompt系统Prompt设计目标让模型输出一个答案让模型持续执行一组任务结构一句话或一段描述分层模块，角色、工具、流程、协议分开状态管理依赖上下文自然延续明确要求读写记忆区，跟踪待办工具使用一般不涉及有工具契约，含触发条件与失败处理容错方式答错就重问定义重试次数、降级路径、人工兜底调试手段改措辞、换示例按模块回归，可单独测试工具契约和决策流程这张表看起来简单，但实践中体会很深。早期我改传统Prompt，经常是“加一句话试试”，改完这一句，另一处又不行了，连带影响。系统Prompt出现后，我的调试方式变成了“先看哪个模块出问题”，定位路径完全不同。2.2 系统Prompt的模块划分与token预算我常用的系统Prompt结构，大致分七个模块：身份层、边界层、契约层、决策层、记忆层、输出层、安全层。每个模块各管一件事，互相之间尽量不交叉。身份层，定义Agent是谁、扮演什么角色、服务于什么目标。不是简单写“你是一个客服”，而是要说明服务范围、语气基调。边界层，写清楚能做什么、不能做什么，尤其要写“做不到时怎么办”，避免模型越权或硬答。契约层，这是最核心的部分，每类工具都要列出名称、参数、触发条件、调用前置校验、失败处理。决策层，定义任务的优先级和流程分支，比如“意图识别→参数抽取→工具调用→结果确认→回复用户”，以及异常分支怎么走。记忆层，约定读写什么、保留多少轮、长对话如何压缩。输出层，规定回复格式、长度限制、是否需要结构化字段。安全层，兜底策略，包括拒绝越权、敏感操作二次确认、错误数据不臆测。token预算也要规划。假设用8K上下文窗口的模型，我的习惯是把系统Prompt总量控制在2000 token左右，剩下6000留给对话历史、工具返回、用户输入。系统Prompt内部，身份和目标约200，工具契约约800，决策流程约400，输出协议约250，安全边界约200，记忆规范约150。这不是绝对数字，而是一种思路：先给工具契约最大的空间，因为它直接决定执行质量。这里补充一个原则：每条规则都要有存在理由。我见过很多系统Prompt花了大量篇幅写“你是一个优秀、耐心、负责任的客服”，这种描述对模型行为影响很弱，却在挤占上下文。与其写形容词，不如写行为约束，比如“用户表达不满时，先承认不便之处，再给出可执行的下一步”。行为描述比身份形容词有用得多。3. 实操：用系统Prompting构建一个客服Agent3.1 场景设定与目标定义为了把上面的架构落到实际，我拿一个电商售后客服Agent来演示。假设某电商平台的售后团队想做一个Agent，处理订单查询、退换货、退款咨询三类请求。它需要接入订单系统、退款系统、物流系统，并拥有转接人工的能力。业务目标明确为：在95%的常见售后问题上，用户能得到准确或可执行的答复；不常见的异常，交给Agent主动升级到人工，不要硬答。这个目标定义很重要，因为它决定了系统Prompt的核心矛盾：准确性优先于“看起来智能”。这也是系统Prompting和传统Prompting的一个显著区别——传统Prompt追求“回答得好不好听”，这里追求“行为符不符合流程”。3.2 分模块组装系统Prompt先看身份层和边界层：你是电商售后客服Agent，代号CS-01。 任务范围：订单状态查询、物流信息查询、退换货申请、退款金额核对。 不可处理：投诉纠纷的调解、价格谈判、账号安全相关操作、法律解释。 当遇到不可处理事项时，明确告知用户该问题需要人工介入，并调用escalate_to_human。注意边界层里我明确写了“价格谈判”和“法律解释”不可处理，这是为了防止模型在被用户话术诱导时越界。很多Agent翻车就翻在边界模糊。然后是契约层。工具契约是执行质量的核心，我把它拆成每个工具一段：工具1：query_order 参数：order_id（数字） 触发条件：用户询问订单状态、物流、商品清单 前置校验：order_id若为空，追问用户提供；若格式不对，不调用工具，请用户重新提供 失败处理：工具返回异常或超时，不猜测结果，回复订单信息暂时无法查询，请稍后再试；累计2次失败后转人工 工具2：calc_refund 参数：order_id、sku_id、reason 触发条件：用户申请退款或询问能退多少 前置校验：仅当query_order返回的订单状态为已发货时可调用；退款金额超过500元时，先调用security_check 失败处理：计算失败时，给出默认全额退款的预估，并注明最终金额以人工审核为准这里我的一条经验是：不要只写“可以调什么工具”，要写“在什么条件下不能调”。比如calc_refund要求订单已发货，这个前置校验直接避免了在未发货订单上瞎算退款金额的尴尬。决策层可以用伪代码式描述：主流程：解析用户意图 -> 提取参数 -> 选择工具 -> 前置校验 -> 调用工具 -> 校验结果 -> 组织回复 分支规则： - 若用户同时咨询两件事，先处理顺序靠前的，并在回复中提示您的另一个问题我稍后为您处理 - 若工具调用连续失败2次，停止重试，转人工 - 若用户情绪激烈或连续两次拒绝当前方案，转人工，并要求人工尽快介入 - 若用户问的问题超出边界层范围，礼貌说明后引导回订单主题决策层的关键是“规则要有优先级”。比如“用户情绪激烈转人工”和“用户询问订单”同时出现时，应该先转人工还是先回答？我建议把安全与人相关的规则放在最高优先级。记忆层和输出层：记忆区字段：user_id、order_id、当前意图、待办事项、已完成的工具调用 每轮结束时更新：当前意图、待办事项、最近一次工具结果摘要 上下文保留最近6轮完整对话；更早的内容压缩为一句状态摘要 输出格式：[动作] | [参数] | [用户可见回复] 用户可见回复不超过80字（中文），禁止输出思考过程、工具原始返回、内部状态输出协议是我特别强调的部分。很多Agent失败，不是因为它不会做事，而是因为它把内部的思考过程、工具原始JSON返回全暴露给了用户，观感很糟，甚至可能泄密。在系统Prompt里明确“什么能输出、什么不能输出”，比在应用层过滤更高效，因为模型会在生成阶段就自我约束。3.3 配置参数与链路设计系统Prompt写完之后，还要设计应用层的配套参数。我一般会给Agent配一个“最大对话轮数”，比如20轮，超过强制转人工，防止无限循环。温度设置上，售后场景我建议偏低，比如temperature=0.2，减少随机性；如果你用的模型没有温度参数，也要在Prompt里写“不要发散，严格按流程执行”。工具调用的超时时间，我通常设为8秒。超过8秒返回的调用结果不可信，直接走失败处理。这里不要设太长，因为Agent是同步等待的，用户还在对面等着回复。另外每个工具调用都要有trace_id，用于后面排查问题。把trace_id和用户的session_id绑定，方便回放那一轮到底发生了什么。链路设计上，我的推荐顺序是：用户输入→意图分类→参数抽取→工具调用→结果校验→回复生成→记忆更新。这个顺序要在系统Prompt的决策层写清楚，让模型按顺序走，不要跳步。我见过不少Agent跳过参数抽取，直接猜一个order_id去调工具，结果查错订单，用户投诉说“这不是我的订单”。这套链路跑起来之后，测试时我重点观察三件事：工具触发是否准确、参数是否完整、失败后有没有走降级路径。这三件事都能在trace日志里快速定位。4. 调优实录：系统Prompt的常见问题与排查方法4.1 角色漂移与优先级冲突实战中最多的问题，是Agent在长对话里逐渐“漂移”。最初它严格按系统Prompt走，但聊了十几轮后，开始出现一些系统Prompt从未写过的行为。比如有一次，用户问“你们这个产品有没有安全隐患”，Agent竟然自动回复了一段产品安全科普，还加了句“请放心使用”。这段内容不在任何工具和知识库里，完全是模型“即兴发挥”。这类问题的根因，是系统Prompt里的规则没有持续“激活”。模型在长上下文里容易遗忘早期指令，尤其当对话早期和晚期的信息权重差不多时。我应对的办法有三招。第一，在决策层加一条“每当用户提出训练范围之外的问题时，先检查边界层”的提示，把边界层引用进来。第二，在记忆区里强制记录“当前任务域”，每轮都提醒自己“我在处理售后订单，不是通用问答”。第三，对允许自由回复的场景，单独放一个小知识库，限定回答范围。优先级冲突也很常见。比如规则“订单问题优先处理”和“用户情绪激烈时转人工”同时触发，Agent容易纠结。我最终把规则排了序：安全/合规高于用户情绪，用户情绪高于主任务，主任务高于次要任务，并写进决策层。有了明确的优先级，模型就不会再左右摇摆。4.2 工具调用失败的归因分析Agent调工具，失败率一般集中在三个环节。第一是参数抽取错误，常见于order_id被抽错，比如用户说“那个尾号888的订单”，模型把“888”当成order_id，实际应该是完整订单号。第二是触发条件判断失误，该调A工具却调了B工具，比如用户问“物流到哪了”，模型却调了query_order而不是物流查询工具。第三是返回解析问题，工具返回了一段复杂的JSON，模型没有提取关键字段就直接复述给用户，导致用户看到一堆技术字符。排查这三类问题，我习惯用“工具调用链路日志”。每条日志记录：意图原文、抽取参数、选中工具、前置校验结果、工具返回摘要、最终回复。哪一环不对，日志里一目了然。比如物流查询问题，日志显示意图是“查物流”，抽取参数却是order_id=123456，选中工具是query_order，这就说明模型没区分订单查询和物流查询的语义边界。对策是在契约层把物流查询的触发条件写得更细，给出正反例。我还踩过一个坑：工具返回结果本身是对的，但模型擅自“加工”了数据。比如calc_refund返回退款金额是350.50元，模型回复说“预计到账350.6元”。原因是模型对数值做了四舍五入，但没有遵循“原样返回”的约束。所以我在输出层强制要求：涉及金额、日期、订单号的字段，必须与工具返回一致，不得改写。4.3 上下文管理失控的应对策略长对话场景下，上下文膨胀是绕不开的问题。30轮对话后，光历史对话就可能超过5000 token，系统Prompt反而被“挤”到背景里，模型越来越不守规矩。我试过几种方案：直接把系统Prompt放最前面，效果一般；用滑动窗口保留最近几轮，稍好；最后落地的是分层记忆。分层记忆的做法是：系统Prompt占固定2000；对话历史只保留最近6轮；更早的内容在每轮结束后被压缩成一句状态摘要，比如“用户已确认退款，等待人工审核结果”。这样无论聊多少轮，上下文占用都在可控范围内。记忆区里只存结构化的关键字段，不存原文。还有一点容易被忽略：工具返回数据也要瘦身。query_order的完整返回可能包含几十个字段，但Agent只需要其中三五个。我的做法是在工具侧就裁剪输出，只返回必要字段。另外，工具返回不要全部塞进上下文，取一个摘要然后丢弃详细信息。剪裁之后，Agent的规则遵守度会明显上升，因为它每次看到的内容更聚焦了。5. 落地建议：从现有Prompt平滑迁移到系统Prompt5.1 迁移前的评估清单如果你手头已经有一套还能跑的Prompt，不要急着推倒重来，先做一次评估。我常用的评估清单是这样的：第一，现阶段的失败模式是什么。是回答错误多，还是行为不稳定，还是工具调用完全没法接？不同失败模式对应不同模块的优先级。第二，哪些指令是“信息型”的，哪些是“行为型”的，哪些需要外部数据。信息型的留下来当知识，行为型的进决策层，外部数据对应工具契约。第三，当前Prompt的哪部分经常被删改。这块通常是最不稳定的地方，大概率缺的是边界层或安全层。第四，你能为Agent定义哪些可观测指标。比如工具调用成功率、转人工率、用户满意度、平均对话轮数。没有指标，后面优化全凭感觉。这套评估结束后，你会很清楚自己的Prompt处于什么阶段。我碰到过团队拿着一个“什么都能聊”的客服Prompt来做Agent，评估完发现，它连工具契约都没有，相当于让实习生“凭感觉上班”。那迁移的起点就不是写系统Prompt，而是先理清业务流程。5.2 增量重构三步法我推荐的迁移方式不是“一步到位替换”，而是增量重构。第一步是分层拆解，把现有Prompt按身份、边界、契约、决策、记忆、输出、安全七个模块归类，空缺的模块先补上最基础的版本。第二步是补契约，梳理Agent需要调用的所有工具，逐个写清楚参数、触发条件、失败处理。这一步最花时间，但也是价值最高的，因为契约一旦明确，模型的“自由发挥”空间就被限制住了。第三步是调决策，把散落的“如果用户怎样就怎样”的规则整理成带优先级的流程。每一步做完都跑一遍回归集，确认没有引入新的行为倒退。我见过一个团队，一口气把三个模块全部重构完，上线后各种奇怪问题，因为改了一个模块，另一个模块的隐含假设被破坏了。增量式推进虽然慢，但每个版本都可控、可回滚。5.3 版本管理与回归测试系统Prompt进入维护期后，版本管理比大多数人想象的重要。我一般给系统Prompt定版本号，用语义化版本规则。比如1.2.0表示新增了工具契约，1.2.1表示修了一个失败处理细节。每次变更都要写变更日志，说明改了什么、为什么改、影响了哪些场景。没有变更日志，三个月后你对着一个莫名其妙的Prompt，根本不知道当时在想什么。回归测试集是另一个关键资产。我会准备一份模拟用户输入集，覆盖常规请求、边界条件、恶意输入、长对话场景，大概三四十条。每次改系统Prompt，就跑一遍这套集，把每一条的输出、工具调用、行为分类记录下来。如果某一条从“转人工”变成了“硬答”，那说明这次变更引入了回归问题。这里有个经验值得说：测试集不是越复杂越好，而是要有“能暴露问题”的设计。比如我只放几条“用户情绪激动”的，几条“订单号缺失”的，几条“同时问两件事”的。这些是业务上最容易被Agent搞砸的场景。能覆盖这些场景的测试集，比一百条千篇一律的问答有价值得多。系统Prompt不是写一遍就完了，它和一个真实的岗位说明书一样，要在业务变化、模型升级、工具变更时持续修订。把它当成一份需要维护的工程产物，而不是一段“写好就不动”的文本，是落地系统Prompting的最后一道认知门槛。最后再分享一点个人体会。我在多个项目里验证过，彻底转向系统Prompt的方式之后，Agent的可控性和可维护性提升非常明显。印象最深的一次，是某次压测中用旧的单Prompt方案，Agent在30轮对话后开始脱离设定自说自话；换成系统Prompt架构后，同样30轮压力场景下，行为保持稳定，工具调用成功率从七成左右提升到九成以上。我想说的是，从Prompting到系统Prompting，表面上是在改写Prompt，本质上是在改变你对Agent的定位——从“让它回答一个问题”到“为它设计一套可持续运行的执行体系”。想通了这一点，后面的工作只是方法论的选择而已。
做Agent开发这件事，做得越久，越觉得“提示词”这三个字已经不太够用了。前几年的主流做法，核心就是把一个任务描述清楚，让模型输出符合预期的答案。但当我真正开始搭建一个能自主调用工具、多轮推进任务的Agent时，才发现“一次问答”式的Prompting根本撑不起Agent的复杂度。你需要的不再是一段话，而是一整套可运行的心智系统。从Prompting到系统Prompting，不是把Prompt写长一点，而是换一种“以Agent为主体”的思维方式来设计。这就是我这一章想聊的核心：Agent-Native心智。如果你正在做Agent应用开发，或者你手头有一个“看起来能聊几句，但一接工具就失控”的Prompt，这篇文章应该对你有用。我会从心智切换讲起，拆解系统Prompt的模块架构，再用一个电商售后客服Agent的完整案例，演示怎么把理论落成可运行的配置。全文不会涉及太深的理论，更多是我在实际项目里踩过坑、验证过、最后沉淀下来的操作方法。1. 从Prompting到系统Prompting：Agent开发的心智切换1.1 Prompting的边界在哪里早年做LLM应用，我常跟人讲：Prompting就是“把需求说清楚”。比如让模型总结邮件、写一份会议纪要、解释某段代码，这些场景下模型是“一次性回答器”，你把上下文和指令给进去，它吐出一个答案。这种方式适合信息提取、文本改写、零散问答，但不太适合需要持续决策和执行的任务。举个具体的例子。早期我做过一个自动化客服Demo，界面就是一个对话框，背后用一段Prompt对模型说“你是客服，请回答用户问题”。用户问“什么时候发货”，效果还行；用户问“帮我查一下订单号123456的物流”，模型就开始编：“该订单正在运输途中，预计明天送达。”它没有接任何物流系统，完全是基于概率生成的一段像话的回复。这就是Prompting的第一个边界：没有工具、没有数据源，模型只能“想象”。更麻烦的是多轮场景。用户说“查一下订单”，模型回答了；用户接着说“那退了吧”，模型又基于上一轮猜测“那我帮您申请退款”。它不知道你是否有权限退、不知道退多少、不知道流程是什么。单轮Prompting本质上没有“状态”概念，你让它连续执行，它只能靠上下文里的蛛丝马迹自圆其说。所以Prompting的适用边界其实很清楚：适合一次性、低风险、不需要外部系统参与的认知任务。一旦任务涉及状态流转、工具操作、异常恢复、合规校验，单靠Prompting就力不从心了。在Agent这类场景里，如果坚持用传统Prompt方式，你得到的会是一个“嘴上什么都答应、实际什么都做不了”的聊天机器人。1.2 Agent-Native的本质：不只是对话，而是执行体系我在很多项目里尝试过把单Prompt强行拉长来解决Agent化问题，结果大概率失败。内容一旦超过3000字，模型就开始“选择性失明”，前面写的规则后面忘了，遇到冲突时不知道按哪条执行。后来我意识到，问题不在Prompt的长度，而在于思考方式。Agent-Native心智，核心是“以Agent为主体的系统思维”。你把Agent当成团队里一个真实成员，它有自己的职责边界、可用工具、决策流程、记忆规则、汇报格式。你不是在跟它对话，而是在为它设计一套可以自主运行的心智系统。这句话怎么理解？举个例子。你雇一个实习生处理售后，不会只说一句“你去处理售后”，而是会告诉他：你能碰什么系统、不能碰什么；遇到什么情况用什么工具；退款超过多少需要主管审批；用户情绪激烈时先安抚再处理；每件事办完怎么汇报。这就是一份完整的“岗位说明书”。系统Prompting，就是为Agent写这份“岗位说明书”。从这个角度看，Agent-Native心智有四个关键维度。一是状态感，Agent要知道会话进行到哪一步，当前待办是什么，而不是每轮都从零开始瞎猜。二是目标感，每个动作都要锚定用户最初的目标，中途出现分叉时要能回到主线。三是契约感，工具不是“随缘调用”，而是有明确的触发条件、参数校验、失败处理。四是自省感，Agent要能判断自己“现在能不能办成”，办不成就如实说，并给出替代路径。这四个维度在传统Prompting里很难被完整表达，因为它们要求的不是“一句指令”，而是一套互相约束的规则和流程。系统Prompting就是为了承载这套规则而生的。一开始你可能觉得系统Prompt只是“更长的Prompt”，但用久了会发现，它其实是一个独立的设计产物，和“回答问题用的指令”完全不在一个层级。2. 系统Prompting的架构拆解：一份可落地的设计蓝图2.1 传统Prompt与系统Prompt的差异对照先做一次对照，帮大家把概念落地。维度传统Prompt系统Prompt设计目标让模型输出一个答案让模型持续执行一组任务结构一句话或一段描述分层模块，角色、工具、流程、协议分开状态管理依赖上下文自然延续明确要求读写记忆区，跟踪待办工具使用一般不涉及有工具契约，含触发条件与失败处理容错方式答错就重问定义重试次数、降级路径、人工兜底调试手段改措辞、换示例按模块回归，可单独测试工具契约和决策流程这张表看起来简单，但实践中体会很深。早期我改传统Prompt，经常是“加一句话试试”，改完这一句，另一处又不行了，连带影响。系统Prompt出现后，我的调试方式变成了“先看哪个模块出问题”，定位路径完全不同。2.2 系统Prompt的模块划分与token预算我常用的系统Prompt结构，大致分七个模块：身份层、边界层、契约层、决策层、记忆层、输出层、安全层。每个模块各管一件事，互相之间尽量不交叉。身份层，定义Agent是谁、扮演什么角色、服务于什么目标。不是简单写“你是一个客服”，而是要说明服务范围、语气基调。边界层，写清楚能做什么、不能做什么，尤其要写“做不到时怎么办”，避免模型越权或硬答。契约层，这是最核心的部分，每类工具都要列出名称、参数、触发条件、调用前置校验、失败处理。决策层，定义任务的优先级和流程分支，比如“意图识别→参数抽取→工具调用→结果确认→回复用户”，以及异常分支怎么走。记忆层，约定读写什么、保留多少轮、长对话如何压缩。输出层，规定回复格式、长度限制、是否需要结构化字段。安全层，兜底策略，包括拒绝越权、敏感操作二次确认、错误数据不臆测。token预算也要规划。假设用8K上下文窗口的模型，我的习惯是把系统Prompt总量控制在2000 token左右，剩下6000留给对话历史、工具返回、用户输入。系统Prompt内部，身份和目标约200，工具契约约800，决策流程约400，输出协议约250，安全边界约200，记忆规范约150。这不是绝对数字，而是一种思路：先给工具契约最大的空间，因为它直接决定执行质量。这里补充一个原则：每条规则都要有存在理由。我见过很多系统Prompt花了大量篇幅写“你是一个优秀、耐心、负责任的客服”，这种描述对模型行为影响很弱，却在挤占上下文。与其写形容词，不如写行为约束，比如“用户表达不满时，先承认不便之处，再给出可执行的下一步”。行为描述比身份形容词有用得多。3. 实操：用系统Prompting构建一个客服Agent3.1 场景设定与目标定义为了把上面的架构落到实际，我拿一个电商售后客服Agent来演示。假设某电商平台的售后团队想做一个Agent，处理订单查询、退换货、退款咨询三类请求。它需要接入订单系统、退款系统、物流系统，并拥有转接人工的能力。业务目标明确为：在95%的常见售后问题上，用户能得到准确或可执行的答复；不常见的异常，交给Agent主动升级到人工，不要硬答。这个目标定义很重要，因为它决定了系统Prompt的核心矛盾：准确性优先于“看起来智能”。这也是系统Prompting和传统Prompting的一个显著区别——传统Prompt追求“回答得好不好听”，这里追求“行为符不符合流程”。3.2 分模块组装系统Prompt先看身份层和边界层：你是电商售后客服Agent，代号CS-01。 任务范围：订单状态查询、物流信息查询、退换货申请、退款金额核对。 不可处理：投诉纠纷的调解、价格谈判、账号安全相关操作、法律解释。 当遇到不可处理事项时，明确告知用户该问题需要人工介入，并调用escalate_to_human。注意边界层里我明确写了“价格谈判”和“法律解释”不可处理，这是为了防止模型在被用户话术诱导时越界。很多Agent翻车就翻在边界模糊。然后是契约层。工具契约是执行质量的核心，我把它拆成每个工具一段：工具1：query_order 参数：order_id（数字） 触发条件：用户询问订单状态、物流、商品清单 前置校验：order_id若为空，追问用户提供；若格式不对，不调用工具，请用户重新提供 失败处理：工具返回异常或超时，不猜测结果，回复订单信息暂时无法查询，请稍后再试；累计2次失败后转人工 工具2：calc_refund 参数：order_id、sku_id、reason 触发条件：用户申请退款或询问能退多少 前置校验：仅当query_order返回的订单状态为已发货时可调用；退款金额超过500元时，先调用security_check 失败处理：计算失败时，给出默认全额退款的预估，并注明最终金额以人工审核为准这里我的一条经验是：不要只写“可以调什么工具”，要写“在什么条件下不能调”。比如calc_refund要求订单已发货，这个前置校验直接避免了在未发货订单上瞎算退款金额的尴尬。决策层可以用伪代码式描述：主流程：解析用户意图 -> 提取参数 -> 选择工具 -> 前置校验 -> 调用工具 -> 校验结果 -> 组织回复 分支规则： - 若用户同时咨询两件事，先处理顺序靠前的，并在回复中提示您的另一个问题我稍后为您处理 - 若工具调用连续失败2次，停止重试，转人工 - 若用户情绪激烈或连续两次拒绝当前方案，转人工，并要求人工尽快介入 - 若用户问的问题超出边界层范围，礼貌说明后引导回订单主题决策层的关键是“规则要有优先级”。比如“用户情绪激烈转人工”和“用户询问订单”同时出现时，应该先转人工还是先回答？我建议把安全与人相关的规则放在最高优先级。记忆层和输出层：记忆区字段：user_id、order_id、当前意图、待办事项、已完成的工具调用 每轮结束时更新：当前意图、待办事项、最近一次工具结果摘要 上下文保留最近6轮完整对话；更早的内容压缩为一句状态摘要 输出格式：[动作] | [参数] | [用户可见回复] 用户可见回复不超过80字（中文），禁止输出思考过程、工具原始返回、内部状态输出协议是我特别强调的部分。很多Agent失败，不是因为它不会做事，而是因为它把内部的思考过程、工具原始JSON返回全暴露给了用户，观感很糟，甚至可能泄密。在系统Prompt里明确“什么能输出、什么不能输出”，比在应用层过滤更高效，因为模型会在生成阶段就自我约束。3.3 配置参数与链路设计系统Prompt写完之后，还要设计应用层的配套参数。我一般会给Agent配一个“最大对话轮数”，比如20轮，超过强制转人工，防止无限循环。温度设置上，售后场景我建议偏低，比如temperature=0.2，减少随机性；如果你用的模型没有温度参数，也要在Prompt里写“不要发散，严格按流程执行”。工具调用的超时时间，我通常设为8秒。超过8秒返回的调用结果不可信，直接走失败处理。这里不要设太长，因为Agent是同步等待的，用户还在对面等着回复。另外每个工具调用都要有trace_id，用于后面排查问题。把trace_id和用户的session_id绑定，方便回放那一轮到底发生了什么。链路设计上，我的推荐顺序是：用户输入→意图分类→参数抽取→工具调用→结果校验→回复生成→记忆更新。这个顺序要在系统Prompt的决策层写清楚，让模型按顺序走，不要跳步。我见过不少Agent跳过参数抽取，直接猜一个order_id去调工具，结果查错订单，用户投诉说“这不是我的订单”。这套链路跑起来之后，测试时我重点观察三件事：工具触发是否准确、参数是否完整、失败后有没有走降级路径。这三件事都能在trace日志里快速定位。4. 调优实录：系统Prompt的常见问题与排查方法4.1 角色漂移与优先级冲突实战中最多的问题，是Agent在长对话里逐渐“漂移”。最初它严格按系统Prompt走，但聊了十几轮后，开始出现一些系统Prompt从未写过的行为。比如有一次，用户问“你们这个产品有没有安全隐患”，Agent竟然自动回复了一段产品安全科普，还加了句“请放心使用”。这段内容不在任何工具和知识库里，完全是模型“即兴发挥”。这类问题的根因，是系统Prompt里的规则没有持续“激活”。模型在长上下文里容易遗忘早期指令，尤其当对话早期和晚期的信息权重差不多时。我应对的办法有三招。第一，在决策层加一条“每当用户提出训练范围之外的问题时，先检查边界层”的提示，把边界层引用进来。第二，在记忆区里强制记录“当前任务域”，每轮都提醒自己“我在处理售后订单，不是通用问答”。第三，对允许自由回复的场景，单独放一个小知识库，限定回答范围。优先级冲突也很常见。比如规则“订单问题优先处理”和“用户情绪激烈时转人工”同时触发，Agent容易纠结。我最终把规则排了序：安全/合规高于用户情绪，用户情绪高于主任务，主任务高于次要任务，并写进决策层。有了明确的优先级，模型就不会再左右摇摆。4.2 工具调用失败的归因分析Agent调工具，失败率一般集中在三个环节。第一是参数抽取错误，常见于order_id被抽错，比如用户说“那个尾号888的订单”，模型把“888”当成order_id，实际应该是完整订单号。第二是触发条件判断失误，该调A工具却调了B工具，比如用户问“物流到哪了”，模型却调了query_order而不是物流查询工具。第三是返回解析问题，工具返回了一段复杂的JSON，模型没有提取关键字段就直接复述给用户，导致用户看到一堆技术字符。排查这三类问题，我习惯用“工具调用链路日志”。每条日志记录：意图原文、抽取参数、选中工具、前置校验结果、工具返回摘要、最终回复。哪一环不对，日志里一目了然。比如物流查询问题，日志显示意图是“查物流”，抽取参数却是order_id=123456，选中工具是query_order，这就说明模型没区分订单查询和物流查询的语义边界。对策是在契约层把物流查询的触发条件写得更细，给出正反例。我还踩过一个坑：工具返回结果本身是对的，但模型擅自“加工”了数据。比如calc_refund返回退款金额是350.50元，模型回复说“预计到账350.6元”。原因是模型对数值做了四舍五入，但没有遵循“原样返回”的约束。所以我在输出层强制要求：涉及金额、日期、订单号的字段，必须与工具返回一致，不得改写。4.3 上下文管理失控的应对策略长对话场景下，上下文膨胀是绕不开的问题。30轮对话后，光历史对话就可能超过5000 token，系统Prompt反而被“挤”到背景里，模型越来越不守规矩。我试过几种方案：直接把系统Prompt放最前面，效果一般；用滑动窗口保留最近几轮，稍好；最后落地的是分层记忆。分层记忆的做法是：系统Prompt占固定2000；对话历史只保留最近6轮；更早的内容在每轮结束后被压缩成一句状态摘要，比如“用户已确认退款，等待人工审核结果”。这样无论聊多少轮，上下文占用都在可控范围内。记忆区里只存结构化的关键字段，不存原文。还有一点容易被忽略：工具返回数据也要瘦身。query_order的完整返回可能包含几十个字段，但Agent只需要其中三五个。我的做法是在工具侧就裁剪输出，只返回必要字段。另外，工具返回不要全部塞进上下文，取一个摘要然后丢弃详细信息。剪裁之后，Agent的规则遵守度会明显上升，因为它每次看到的内容更聚焦了。5. 落地建议：从现有Prompt平滑迁移到系统Prompt5.1 迁移前的评估清单如果你手头已经有一套还能跑的Prompt，不要急着推倒重来，先做一次评估。我常用的评估清单是这样的：第一，现阶段的失败模式是什么。是回答错误多，还是行为不稳定，还是工具调用完全没法接？不同失败模式对应不同模块的优先级。第二，哪些指令是“信息型”的，哪些是“行为型”的，哪些需要外部数据。信息型的留下来当知识，行为型的进决策层，外部数据对应工具契约。第三，当前Prompt的哪部分经常被删改。这块通常是最不稳定的地方，大概率缺的是边界层或安全层。第四，你能为Agent定义哪些可观测指标。比如工具调用成功率、转人工率、用户满意度、平均对话轮数。没有指标，后面优化全凭感觉。这套评估结束后，你会很清楚自己的Prompt处于什么阶段。我碰到过团队拿着一个“什么都能聊”的客服Prompt来做Agent，评估完发现，它连工具契约都没有，相当于让实习生“凭感觉上班”。那迁移的起点就不是写系统Prompt，而是先理清业务流程。5.2 增量重构三步法我推荐的迁移方式不是“一步到位替换”，而是增量重构。第一步是分层拆解，把现有Prompt按身份、边界、契约、决策、记忆、输出、安全七个模块归类，空缺的模块先补上最基础的版本。第二步是补契约，梳理Agent需要调用的所有工具，逐个写清楚参数、触发条件、失败处理。这一步最花时间，但也是价值最高的，因为契约一旦明确，模型的“自由发挥”空间就被限制住了。第三步是调决策，把散落的“如果用户怎样就怎样”的规则整理成带优先级的流程。每一步做完都跑一遍回归集，确认没有引入新的行为倒退。我见过一个团队，一口气把三个模块全部重构完，上线后各种奇怪问题，因为改了一个模块，另一个模块的隐含假设被破坏了。增量式推进虽然慢，但每个版本都可控、可回滚。5.3 版本管理与回归测试系统Prompt进入维护期后，版本管理比大多数人想象的重要。我一般给系统Prompt定版本号，用语义化版本规则。比如1.2.0表示新增了工具契约，1.2.1表示修了一个失败处理细节。每次变更都要写变更日志，说明改了什么、为什么改、影响了哪些场景。没有变更日志，三个月后你对着一个莫名其妙的Prompt，根本不知道当时在想什么。回归测试集是另一个关键资产。我会准备一份模拟用户输入集，覆盖常规请求、边界条件、恶意输入、长对话场景，大概三四十条。每次改系统Prompt，就跑一遍这套集，把每一条的输出、工具调用、行为分类记录下来。如果某一条从“转人工”变成了“硬答”，那说明这次变更引入了回归问题。这里有个经验值得说：测试集不是越复杂越好，而是要有“能暴露问题”的设计。比如我只放几条“用户情绪激动”的，几条“订单号缺失”的，几条“同时问两件事”的。这些是业务上最容易被Agent搞砸的场景。能覆盖这些场景的测试集，比一百条千篇一律的问答有价值得多。系统Prompt不是写一遍就完了，它和一个真实的岗位说明书一样，要在业务变化、模型升级、工具变更时持续修订。把它当成一份需要维护的工程产物，而不是一段“写好就不动”的文本，是落地系统Prompting的最后一道认知门槛。最后再分享一点个人体会。我在多个项目里验证过，彻底转向系统Prompt的方式之后，Agent的可控性和可维护性提升非常明显。印象最深的一次，是某次压测中用旧的单Prompt方案，Agent在30轮对话后开始脱离设定自说自话；换成系统Prompt架构后，同样30轮压力场景下，行为保持稳定，工具调用成功率从七成左右提升到九成以上。我想说的是，从Prompting到系统Prompting，表面上是在改写Prompt，本质上是在改变你对Agent的定位——从“让它回答一个问题”到“为它设计一套可持续运行的执行体系”。想通了这一点，后面的工作只是方法论的选择而已。