企业官网建设流程全解析

提示词工程这个系列写到第七篇，前六篇聊的都是单轮问答里的基本功：怎么写清楚、怎么结构化、怎么做 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，系统提示词基本是“Ctrl+C/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条不再出现emoji，3条仍出现，需要进一步在第一批示例中放反例

版本管理还有一个好处：当模型升级后模板“突然变差”，你能快速定位到底是哪一段改动导致的。否则你就会陷入“所有东西都变了，不知道哪里出了问题”的迷雾。

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 行为异常，本质上都是提示词编排的规则不够清晰，或规则之间有冲突。排查顺序永远是：先看提示词，再看数据/上下文，最后才看模型。

5.2 模型“不听指令”的排查思路

“我都写了禁止了，它还是那样做”，这是新手最常遇到的困惑。我分享一套排查思路。

第一，检查指令位置。大模型对上下文不同位置的注意力分布并不均匀，系统性偏差决定了末尾指令的执行优先级往往高于中间，这跟人类开会时最容易记住最后几句话一个道理。所以你的核心禁止规则，务必放在系统提示词的最后部分，而不是埋在角色设定或中间段落里。我实测过，把“禁止编造数据”从提示词中段移到末尾，违规率会有肉眼可见的下降。

第二，检查指令与示例是否一致。如果系统提示词里写了“不要使用 emoji”，但示例输出里又带着 emoji，模型会优先模仿示例。示例的引导力远强于抽象指令。所有你在示例中展示的内容，都会被模型当成“默认正确”的行为。所以想禁止什么，示例里就一定不要出现什么。

第三，检查是否存在“软指令”与“硬指令”冲突。比如角色定义说“你是一个热情的朋友”，输出协议里又要求“回复必须严谨客观”，模型会用哪个？大概率是角色定义里的倾向，因为角色定义是一种人格化的强提示。这类冲突不排查的话，你就是把提示词改一百遍，输出也不会稳定。

5.3 会话内存爆与执行中止的处置

Agent 跑久了，上下文越来越长，这是必然的事。你在热词里看到的“Agent execution terminated due to error”，多半就来自这类问题：要么是上下文超出模型窗口，要么是工具返回结果在解析时格式不合法导致整个执行链路崩掉。

内存问题的处置思路很简单：别硬撑。在编排阶段就设计好上下文压缩策略。比如设定当上下文使用量达到窗口的 60% 时，自动触发“总结与压缩”指令：让模型把对话历史压缩成要点摘要，保留任务目标、关键参数、已确认信息，丢掉中间过程。压缩后继续跑，Agent 的表现会好很多。有些生态里已经内置了这种机制，但你自己手动设置会更可控。

执行中止问题，我见过的绝大多数源头是“输出解析失败”。比如你要求模型输出 JSON，但模型某个瞬间多输出了一个说明性的前缀，解析器直接报错退出。这种问题要在代码层做两道保险：第一，解析 JSON 时用容错解析器，遇到前缀/后缀的额外文本先剥离再解析；第二，在系统提示词里明确“禁止在 JSON 前后输出任何解释文字”，并给一个反例提示。两件事一起做，中止率能显著降低。

会话内存爆的技术背后，还牵涉到一个关键点：Agent 该记住什么是设计出来的，不是自然发生的。你把记忆协议写清楚，模型才知道哪些历史信息需要保留、哪些可以丢弃。否则它事无巨细地存着，大概率既是浪费又害了自己。

最后再分享一个小技巧

我这个系列写到这里，有件事想专门拎出来说。提示词模板管理和 Agent 提示词编排，看着是两个方向，但真正把它们串起来的是一个统一的思维习惯：把提示词当成会持续迭代的代码来看待。

我印象最深的一次踩坑，是在一个写作 Agent 项目里，我把系统提示词里的语气描述从“专业可信”改成了“自然流畅”。单个词的变化，结果输出风格发生了巨变——语气变得过于口语化，甚至开始用“嘿嘿”这种词。因为没有做回归测试，这个问题在全部 Agent 实例上线后才暴露，回滚花了大半天。

从那天以后我给自己立了一条规矩：动任何一条系统提示词，先跑一遍存量测试集，再决定要不要上线。这个习惯帮我避免了大大小小几十次事故。提示词编排就像往一架天平上放砝码，动任何一边，都要重新把整架天平校一遍。你之前学会的写法是“磨刀”，从这一篇开始，你要学的是怎么握住整把刀——把刀柄和刀身都管好，才算真正会用了。