提示词工程这个系列写到第七篇前六篇聊的都是单轮问答里的基本功怎么写清楚、怎么结构化、怎么做 Few-shot、怎么控格式。从这一篇开始镜头得拉远一点——因为当你开始做 Agent你会发现真正折磨人的不再是一条提示词怎么写而是几十条提示词怎么管、怎么编成一个能稳定干活的系统。这也就是这篇要聊的两件事提示词模板管理和 Agent 提示词编排。先说个现象。很多同学学完前几篇之后信心满满地去搭 Agent结果做出来的东西要么隔三差五抽风要么换个场景就废。我看了他们的工程文件夹问题几乎都出在同一个地方提示词散落在代码里、配置文件里、甚至是聊天记录里没有一套管理思路Agent 的系统提示词是“凭感觉”堆出来的没有编排逻辑。这篇就是来解决这两个问题的。适合正在从单一提示词往 Agent 开发过渡的人读也适合那些已经在做 Agent、但总觉得系统提示词不稳定的朋友参考。1. 先搞清楚这一篇到底解决什么问题1.1 从提示词到 Agent难的不是“写”而是“管”单一提示词和 Agent 提示词本质上是两个量级的事情。单一提示词你服务的只是一个“问答界面”写坏了重写一条就行影响面可控。Agent 不一样Agent 意味着模型自主决策意味着它会调用工具、读取记忆、拆解任务、自我纠错背后可能还挂着一整套业务逻辑。这时候系统提示词不再是一段“说明文字”而是一份“运行规则”它直接决定了 Agent 在无人值守的情况下会不会跑偏。我见过太多人在这儿犯同一个错误把 Agent 的系统提示词当成一条超大号的普通提示词来写堆了一堆形容词和背景故事结果模型表现忽好忽坏。问题就在——你只有一条提示词却期望它覆盖所有分支行为这本来就不合理。Agent 的行为应该被拆分、被组织、被分层而不是靠在一条提示词里“加话”来约束。所以这一篇讲的“管理”和“编排”其实是两件互为表里的事模板管理解决的是提示词的“生产过程”问题怎么定义变量、怎么复用、怎么版本化、怎么回归测试。Agent 编排解决的是“系统结构”问题一条完整的 Agent 系统提示词里各个模块怎么分工、怎么协作、怎么互相制约。你可以这么理解模板管理是“管零件”编排是“装整机”。没有好的零件管理整机迟早出问题没有好的编排思路零件再好也组装不出能跑的系统。1.2 两个容易混淆的概念模板管理 vs 提示词编排先把概念理清楚不然后面越看越乱。模板管理Prompt Template Management的核心是“复用与维护”。它关注的是一段提示词里哪些部分是常量、哪些是变量、变量怎么填、模板怎么更新、多个模板之间怎么组织。它更像工程里的“配置管理”目标是用最小的成本维护一批高质量的提示词资产。提示词编排Prompt Orchestration的核心是“行为组织”。它关注的是在一个 Agent 的运行过程中系统提示词里需要包含哪些模块角色、目标、工具、边界、协议、记忆等这些模块之间怎么排列、怎么动态切换、怎么互相影响。它更像“系统架构”目标是把模型的行为约束在既定轨道上。踩坑提醒很多教程把这两个概念混着用导致新手照着学也学不明白。你只要记住一条简单的线——模板回答“提示词从哪来”编排回答“提示词怎么用”。两者当然有交集但思考方向完全不同。1.3 顺带把面试高频概念理一遍热词里出现了一堆概念Skill、Agent、Harness、编排。串一条容易理解的线。模板Template是最小复用单元一段可填空的提示词骨架。Skill 通常指的是一组能力封装比如“写代码”“画图”内部可能包含模板、工具配置、调用流程。Agent 是基于模型、技能、工具、记忆组装出来的一个可自主运行的系统。Harness 是承载 Agent 运行的“壳”管模型调用循环、工具注册、上下文传递。编排Orchestration是更高一层的协调逻辑决定多个 Agent 或多个技能之间怎么配合。这个关系链可以用“员工-部门-公司”来类比Template 是工作表单Skill 是员工的专业能力Agent 是员工本人Harness 是公司给你的工位和流程编排则是管理层如何安排不同员工协同干活。面试的时候被问到“Agent 和 Skill 的区别”答案逻辑就藏在这里Skill 是能力封装Agent 是携带目标、记忆与决策能力的运行体一个 Skill 可以被多个 Agent 复用一个 Agent 也可以挂载多个 Skill。2. 提示词模板管理从“复制粘贴”到“工程化”2.1 为什么模板会失控三个真实现场先说三个我真实见过的失控场景你对号入座。第一个某团队做了十几个面向不同行业的营销文案 Agent系统提示词基本是“CtrlC/V”出来的。后来甲方要改一句品牌话术他们全局搜索替换结果复制版本和参考版本里那句话的上下文不一样替换出来语义完全变了项目上线后被客户连环夺命 call。第二个一个个人开发者把所有提示词直接写死在代码里后来模型升级某条提示词语法失效旧模型认 XML 标签、新模型开始输出多余前缀他只能逐个文件开着找花了整整一天定位到三处问题而那三处代码在写法上完全一样——因为没有统一模板同样的规则在三个地方各写了一遍改的时候也只改到了两个。第三个一个研究团队维护了 200 多条评测提示词每次改进想“微调一下语气”但每条都是独立的文本文件既没有版本记录也没有变更说明。一个月后他们自己都分不清哪个是“最新稳定版”最后无奈从 Git 历史里逐个恢复。这三个场景的共同病根是把提示词当“死文本”而不是“活资产”。提示词在整个 AI 应用里是有生命周期的创建、迭代、评估、废弃。没有管理的提示词就是对整个项目埋雷而且埋雷位置自己都不知道。2.2 模板的结构化设计槽位、块、协议三件套既然要把模板当工程资产第一步就得把模板本身设计成“结构化”的。我常用的模板骨架分成三大块槽位变量区、块条件渲染区、协议输出约定区。槽位是模板里可被外部参数填充的部分。我建议统一用双花括号语法{{变量名}}。为什么不用${}或者单花括号因为提示词里经常出现 JSON、Shell、SQL 片段单花括号和${}很容易跟这些语法冲突双花括号冲突概率极低。命名上要有纪律用角色、任务、输入这种语义化名称不用a、b、tmp否则填参数的人和使用模板的人会陷入互相猜忌。块是模板中可按条件包含或排除的内容。最简单的实现是用注释标记你是{{角色}}你的任务是{{任务}}。 !-- 如果启用专业术语模式 -- 你输出的内容应包含专业术语并在首次出现时给出解释。 !-- 结束 -- 请输出Markdown格式的回复。需要用代码实现条件渲染就在模板引擎里加 if 判断。但你得记住一个核心原则在渲染层做控制绝不让模型看到模板的控制语法。也就是说模型拿到的永远是渲染后的完整文本而不是“这里可能插入一段说明”这种半成品。否则模型会把渲染标记也当成内容输出的格式会变得不可控。协议是模板中规定输出结构的部分。比如要求 JSON、要求 Markdown、要求摘要加正文等。这个区域要尽量精确最好给一个具体例子。光写“请输出 JSON”是不够的要写清楚字段名和值的类型。输出协议 使用以下JSON结构响应 {status: success|error, result: ..., debug: ...} 注意不要输出JSON以外的任何内容。一个完整的结构化模板长什么样我帮你串一个最小示例你是{{role}}你的目标用户是{{audience}}。 本次任务{{task}} 约束条件 - {{constraint1}} - {{constraint2}} 参考资料 {{references}} 输出要求 1. 先输出一段不超过50字的结论摘要。 2. 再输出正文使用Markdown二级和三级标题不要使用一级标题。上线之前要跑一遍所有变量填充后的效果确认渲染结果读起来流畅、没有残缺句。模板里最忌讳的是变量填充后语法结构断裂比如“你是{{role}}你的任务是”当 role 为空时整句话就不知所云。这种情况一定要加默认值或渲染后校验。2.3 模板的版本管理改模板要像改代码一样留痕很多 AI 应用的开发流程是“模型调参提示词调优”提示词的改动对最终效果影响极大甚至超过模型权重本身。提示词模板完全应该纳入版本管理跟代码走同一套机制。我的习惯是项目仓库里单独建prompts/目录每个模板一个文件文件名严格按“场景-角色-版本”的规则命名例如marketing-copywriter-v2.md。同时维护一个CHANGELOG.md记录每个模板每个版本的关键改动和动机“v2 修改语气约束从专业改为口语化实测减少客户投诉约 20%。”这行记录将来你会感激自己写过的。变更记录里有三个字段必须填改了什么、为什么改、怎么验证的。光是“修bug”“优化效果”这种描述等于没写。我见过有效的记录长这样## v2.1.0 - 2025-06-12 - 修改在输出协议中增加禁止使用emoji约束 - 原因实测发现模型在回复中频繁插入表情符号影响正式渠道的排版 - 验证用21条历史case回归其中18条不再出现emoji3条仍出现需要进一步在第一批示例中放反例版本管理还有一个好处当模型升级后模板“突然变差”你能快速定位到底是哪一段改动导致的。否则你就会陷入“所有东西都变了不知道哪里出了问题”的迷雾。2.4 模板的组织与回归测试模板多了以后组织方式也很关键。三个原则按场景分目录、按标签归类、最小测试集兜底。按场景分目录就不用多说了「写作」、「客服」、「数据分析」、「代码生成」各建一摊。按标签归类是指给每个模板打上自定义标签比如稳定版、实验版、依赖模型:gpt-4o、适配中文优先生成。这样以后要“找出所有依赖旧模型行为的模板”一个筛选就能出来。最小测试集是我认为整个模板管理里最容易被忽略、却回报最高的一件事。做法是每个模板固定配 5~10 条输入用例覆盖正常情况、边界情况、异常情况。每次修改模板第一件事就是拿这组用例跑一遍确认输出质量没有下降。听起来有点重但等你维护的模板超过 20 条时你会发现没有回归测试的模板改动一律不敢上线。实操心得我见过有人把用例输入放在 Markdown 的 front matter 里也有人用 JSON 文件单独维护都行。关键是“每次改动必跑”。哪怕改一个字也要跑。因为你永远无法预测某个措辞变化对输出的影响有多大尤其是对高随机性的生成模型。模板里的一个语气词可能直接让输出从“专业严谨”变成“俏皮散漫”。3. Agent 提示词编排核心五要素与常见范式3.1 编排的本质给系统定三件事Agent 系统提示词的编排本质上是在做三件互相独立的事第一件事定义“它是什么”。给 Agent 一个角色并让这个角色在决策时提供稳定的偏好。比如“资深技术文档编辑”和“活泼的社区运营小编”面对同一个输入处理方式会完全不同。角色不是装饰它是一套决策过滤器。第二件事定义“它怎么干活”。告诉 Agent 完成任务的具体路径要不要拆解、先做什么再做什么、用什么工具、按什么格式输出。这是编排的主要工作量所在也是最考验系统设计能力的地方。第三件事定义“它不能干什么”。包括不做范围外的事、不调用禁止的工具、遇到不确定的情况时如何中止并上报。这条很多人不写但恰恰是不写才导致 Agent 在无人监督时发挥“创造性”把任务彻底带偏。用一句话总结编排的本质不是把规则写得更多而是把规则的逻辑捋清楚让 Agent 在任何输入下都有明确的行为准则。3.2 五要素法角色、工具、边界、协议、记忆我给自己的 Agent 项目编排系统提示词一直用“五要素法”每一版都过这五关第一角色定义。不是写一句“你是智能助手”就完事而是写清楚角色的专业背景、工作风格、处理问题的倾向。比如你是一名资深数据产品经理擅长用漏斗模型拆解业务问题。 你的写作风格是结论先行数据支撑逻辑严密不堆砌形容词。这里的关键是“角色→行为”的对应要自然。如果写“你是全球顶尖的量子物理学家”但后续任务只是写周报那角色设定就成了噪音既浪费 token 又让模型过度发挥。角色要与任务难度匹配。第二工具说明。Agent 能调用哪些工具、工具的参数怎么填、调用前要满足什么条件。为了避免模型把工具用劈叉可以在系统提示词里把工具当成“API”描述一样写清楚你可以使用以下工具 - search_web(query): 搜索公开网页仅用于事实查证输入必须为非空的自然语言问题。 - get_page(url): 抓取指定网页正文仅用于确认引用来源。 禁止把搜索工具用于生成式任务。工具说明的关键不是“列出来”而是“划边界”。你不告诉模型哪些情况不能用工具它就会在任何拿不准的时候都乱调工具白白消耗时间和额度。第三任务边界。明确“能做什么、不能做什么、什么时候停下来”。这是很多 Agent 项目稳定性差的最主要原因。边界描述我倾向用肯定句否定句组合你可以 - 根据用户输入做领域判断 - 在不确定时主动向用户提问澄清 - 调用工具确认事实 你不可以 - 编造未经验证的数据 - 在缺少关键信息时强行完成任务 - 访问或生成任何敏感内容这段在系统提示词里所占的篇幅可能只有 10%但它决定了 Agent 上线后出事故的概率高低。千万别省。第四输出协议。规定格式与交互节奏。不同的 Agent 有不同的输出协议比如“先出计划再执行”“只输出结论不输出过程”“每一步操作报告执行结果”。输出协议是“编排”中最能体现结构的一部分它让 Agent 的行为可被解析、被后续流程接管。第五记忆协议。需要 Agent 记住什么、记住多久、什么情况下忘掉。记忆协议常被新手忽略但一旦 Agent 任务生命周期变长连续多轮、跨会话记忆就成了行为稳定性的关键。我在记忆协议里一般做三档设置短期记忆当前会话内保留记录用户偏好与本次任务细节中期记忆在任务拆解中保留比如“已经完成到什么进度”长期记忆跨会话保存只放用户画像、重要偏好、历史结论三档记忆各有写法。短期记忆通常在上下文里自然存在中期记忆靠系统提示词里的“状态块”维护长期记忆则需要外部存储如向量库系统提示词只负责告诉 Agent“从哪里读、哪里写”。3.3 常见编排范式垂直单体、流水线、裁判-生产者有了五要素还要了解常见的编排范式也就是多个提示词模块如何组织起来。垂直单体是最简单也最常见的模式一个 Agent、一条系统提示词、包含了所有规则。它适合任务边界清晰、上下文不复杂、可以一步到位的场景比如“写一封回复邮件”“做一段内容摘要”。优点是实现快、调试简单缺点是当任务复杂度上升单条提示词会越来越长模型注意力分散规则之间互相冲突的风险增大。流水线模式是把任务拆成多个工序每个工序由一个 Agent 或一组模板负责。例如内容生产流水线选题 Agent 定选题 → 大纲 Agent 出框架 → 撰写 Agent 出细节 → 校对 Agent 查错误。每个 Agent 的系统提示词都只需要关注自己那一环复杂度被拆开了。这是工程上最稳的多步任务方案。代价是需要设计清晰的“工序接口”也就是上一个 Agent 的输出怎变成下一个 Agent 的输入这部分往往需要代码编排支持。裁判-生产者模式是让一个 Agent 负责产出、另一个 Agent 负责评价。产出的结果被裁判 Agent 按评估清单打分不达标就打回重写。这种模式能显著提升质量上限但会消耗更多 token 和时间。适合对内容质量有高要求、能接受生成延迟的场景比如研究报告、技术文档、创意文案。选范式没有标准答案核心是根据你的约束条件来权衡。如果你的上线时间紧张垂直单体先跑通是最理智的选择如果你要做多步骤复杂任务流水线迟早要上如果你在追求输出质量上限裁判-生产者几乎是必经之路。3.4 提示词级编排与代码级编排怎么选我收到过不少私信问“编排到底是在提示词里做还是在代码里做”这个问题问得特别好因为答案不是二选一而是按依赖关系分。提示词级编排指的是不依赖代码逻辑完全靠系统提示词内部的模块化结构、分步指令、输出协议来约束 Agent 行为。适合逻辑判断不复杂、分支有限、可以用“if-then”类描述覆盖的场景。优点是改动快、不需要重新部署缺点是复杂的条件分支写在提示词里会让文本长度爆炸且模型对复杂条件逻辑的执行遵守度比代码差得多。代码级编排指的是把流程控制交给程序代码比如用if判断决定调哪个 Agent、用for循环批量跑模板、用解析器校验输出格式。提示词只负责“单步行为描述”。优点是流程可控、容错强缺点是需要开发成本并且提示词与代码的耦合度变高不方便非技术人员调整。我的判断标准非常朴素如果这个决策分支少于 3 个、且错误后恢复成本低用提示词级编排即可如果分支多、错了会对下游造成连锁问题那无论如何都要挪到代码里做。所谓“编排”本来就该在最合适的层面做最合适的事。硬把复杂逻辑塞给模型是给自己挖坑。4. 完整实操一个技术写作 Agent 的编排全过程4.1 需求与边界拆解为了让你有个整体感受我拿自己做过的一个“技术写作 Agent”复盘一遍。需求很朴素输入一份技术要点的草稿输出一篇适合发在行业社区的技术博文初稿。看起来简单但实际操作时验证了几个容易被忽略的关键点草稿质量参差不齐有的给的是流水账有的给的是零散关键词输出不能太长否则后续人工编辑成本太高不能编造技术细节否则发布后翻车责任全在作者。基于这个我先把任务边界拆出来输入技术要点草稿可能不完整、不连贯输出一篇带完整结构标题、引言、主体小节的初稿正文总字数控制在 1500~2500 字禁止编造数据、虚构 API、凭空捏造代码逻辑特殊要求对拿不准的地方用[待确认]占位符标注而不是直接编边界拆完才开始写提示词。4.2 系统提示词第一版五要素逐一落地按照五要素法第一版系统提示词长这样【角色定义】 你是一名有多年经验的技术博客作者熟悉AI工程与后端开发领域。 你的写作风格直接、严谨、不堆砌抽象术语善用生活类比解释复杂概念。 【任务说明】 用户会给你一份技术要点草稿。 你的任务将其扩写为一篇结构完整的技术博文初稿。 【任务边界】 - 可以根据草稿内容扩展讲解、补充上下文关联、增加实操示例 - 可以在信息不足时使用 [待确认] 占位符 - 禁止编造数据、虚构API、伪造代码逻辑 - 禁止脱离草稿内容自行发明新技术名词 【输出协议】 1. 先输出文章大纲列出所有小节标题 2. 等待用户确认后再输出正文 3. 正文使用Markdown格式标题从二级开始不使用一级标题 4. 正文结束后额外输出一个写作说明部分说明你在哪些地方补充了内容 【记忆协议】 - 会话内优先记住用户对风格、篇幅、结构的反馈 - 不保存草稿之外的具体数据内容我把这份提示词拿去跑了几条输入总结出问题输出协议里“先输出大纲再等确认”这个设定在自动化流程里并不需要因为多数使用者希望一步到位——能一版拿到完整初稿再人工改。于是按代码级编排的思路把大纲确认这个环节去掉改成了“输入即出全文”。4.3 任务分解与自检模板的嵌入第一版跑通之后我发现 Agent 写出来的东西有时候逻辑松散甚至前后矛盾。原因在于它把“写文章”当成了一次性的生成行为没有经历“先想框架、再写内容、最后自查”的思考过程。我在编排里加了两段关键指令任务分解模板和自检模板。【任务分解】 在收到用户草稿后按以下流程处理 1. 抽取草稿中的核心论点与技术关键词 2. 判断论点的逻辑层级确定文章主线和各小节重点 3. 补齐支撑性说明公式、类比、示例、注意事项 4. 组织输出结构引言-主体-结尾 【自查协议】 在输出正文之前对生成的初稿进行一遍自查 - 是否所有技术名词都与草稿一致没有引入草稿之外的未知名词 - 是否包含至少一个生活化类比来解释核心概念 - 是否有结论先行的结构而不是平铺直叙 - 是否所有拿不准的数据都使用了 [待确认] 标记这两段指令本质上是“把人在写作时的流程知识写进了系统提示词”。模型不是天生会写文章它是根据系统提示词中的流程设定来复现你的思维过程。流程写得越细输出越稳。4.4 实测记录与调整过程用三条测试输入跑了整整一天我记录到了几个规律性的现象第一条输入给了一份很短的草稿只有一句话和一个关键词。模型输出的文章偏薄即使让它扩写也还是在原地绕圈。原因分析草稿信息量太低而系统提示词没有强调“优先引导用户补充信息”。于是我在任务边界加了一条“如果草稿信息量不足以支撑1500字正文直接在回复开头说明信息缺口并给出需要补充的问题清单”。这比强行生成一篇空洞无物的文章有诚意得多。第二条输入草稿里有一处明显的技术概念错误但我要求模型不编造它也没有识别错误的能力——它会把草稿里的错误原样写进文章。这是个关键发现任何写作 Agent 都不能默认“草稿是对的”。我更新了边界描述“如果发现草稿内容存在明显的逻辑矛盾或事实疑问使用 [待确认] 标记该处不擅自修正。”这样至少保证人工编辑能看到问题。第三条输入正常技术草稿结果模型开始长篇大论正文超过了 4000 字。原因不是它写多了而是输出协议只写了“正文使用 Markdown”没有字数上限。我加上了正文总字数控制在1500~2500之间如果草稿素材过多优先删减示例与重复说明保留核心逻辑链。经过三轮调整这个写作 Agent 的可用性明显提高。我的体会是Agent 编排不是一次到位的它跟机器学习调参数一样靠的是多轮实测反馈、逐步打磨系统提示词里的规则密度。5. 常见问题与排查实录5.1 高频故障速查表在实际跑 Agent 项目的过程中下面这些问题是出现频率最高的。整理成速查表供你排查时直接对照。故障现象最常见原因排查顺序修复方向Agent 无视系统提示词中的某项规则规则与更靠后的指令冲突或被示例带偏先看输出协议与示例再看角色定义将关键规则放到提示词最末尾并在示例中体现工具调用混乱频繁调用不该用的工具工具说明没有写“禁止”边界检查工具描述里的参数与触发条件给每个工具补充“在什么场景下不允许使用”输出格式不稳定时好时坏输出协议缺少示例模型只能用自然语言理解检查输出协议是否给了具体例子在协议中给一条完整的输出示例Agent 进入死循环缺少最大步数控制或终止条件看代码层有没有 step 上限在编排中加入“当检测到重复操作主动停止并上报”模型编造数据系统提示词里没有明确禁止编造检查边界描述中的否定句加入“禁止编造数据缺失用 [待确认] 标记”Agent 上下文中途爆掉没有做总结压缩或记忆分层检查上下文长度与 token 监控实现自动总结把长历史压缩成摘要执行中止terminated due to error输出解析失败或工具返回异常看报错信息和日志中的工具链先在代码层加解析容错再考虑调整提示词不要一上来就怀疑“模型能力不行”。大多数 Agent 行为异常本质上都是提示词编排的规则不够清晰或规则之间有冲突。排查顺序永远是先看提示词再看数据/上下文最后才看模型。5.2 模型“不听指令”的排查思路“我都写了禁止了它还是那样做”这是新手最常遇到的困惑。我分享一套排查思路。第一检查指令位置。大模型对上下文不同位置的注意力分布并不均匀系统性偏差决定了末尾指令的执行优先级往往高于中间这跟人类开会时最容易记住最后几句话一个道理。所以你的核心禁止规则务必放在系统提示词的最后部分而不是埋在角色设定或中间段落里。我实测过把“禁止编造数据”从提示词中段移到末尾违规率会有肉眼可见的下降。第二检查指令与示例是否一致。如果系统提示词里写了“不要使用 emoji”但示例输出里又带着 emoji模型会优先模仿示例。示例的引导力远强于抽象指令。所有你在示例中展示的内容都会被模型当成“默认正确”的行为。所以想禁止什么示例里就一定不要出现什么。第三检查是否存在“软指令”与“硬指令”冲突。比如角色定义说“你是一个热情的朋友”输出协议里又要求“回复必须严谨客观”模型会用哪个大概率是角色定义里的倾向因为角色定义是一种人格化的强提示。这类冲突不排查的话你就是把提示词改一百遍输出也不会稳定。5.3 会话内存爆与执行中止的处置Agent 跑久了上下文越来越长这是必然的事。你在热词里看到的“Agent execution terminated due to error”多半就来自这类问题要么是上下文超出模型窗口要么是工具返回结果在解析时格式不合法导致整个执行链路崩掉。内存问题的处置思路很简单别硬撑。在编排阶段就设计好上下文压缩策略。比如设定当上下文使用量达到窗口的 60% 时自动触发“总结与压缩”指令让模型把对话历史压缩成要点摘要保留任务目标、关键参数、已确认信息丢掉中间过程。压缩后继续跑Agent 的表现会好很多。有些生态里已经内置了这种机制但你自己手动设置会更可控。执行中止问题我见过的绝大多数源头是“输出解析失败”。比如你要求模型输出 JSON但模型某个瞬间多输出了一个说明性的前缀解析器直接报错退出。这种问题要在代码层做两道保险第一解析 JSON 时用容错解析器遇到前缀/后缀的额外文本先剥离再解析第二在系统提示词里明确“禁止在 JSON 前后输出任何解释文字”并给一个反例提示。两件事一起做中止率能显著降低。会话内存爆的技术背后还牵涉到一个关键点Agent 该记住什么是设计出来的不是自然发生的。你把记忆协议写清楚模型才知道哪些历史信息需要保留、哪些可以丢弃。否则它事无巨细地存着大概率既是浪费又害了自己。最后再分享一个小技巧我这个系列写到这里有件事想专门拎出来说。提示词模板管理和 Agent 提示词编排看着是两个方向但真正把它们串起来的是一个统一的思维习惯把提示词当成会持续迭代的代码来看待。我印象最深的一次踩坑是在一个写作 Agent 项目里我把系统提示词里的语气描述从“专业可信”改成了“自然流畅”。单个词的变化结果输出风格发生了巨变——语气变得过于口语化甚至开始用“嘿嘿”这种词。因为没有做回归测试这个问题在全部 Agent 实例上线后才暴露回滚花了大半天。从那天以后我给自己立了一条规矩动任何一条系统提示词先跑一遍存量测试集再决定要不要上线。这个习惯帮我避免了大大小小几十次事故。提示词编排就像往一架天平上放砝码动任何一边都要重新把整架天平校一遍。你之前学会的写法是“磨刀”从这一篇开始你要学的是怎么握住整把刀——把刀柄和刀身都管好才算真正会用了。
