这是系列文章的第七篇。前几篇讲的是怎么把 AI 用得更顺手比如长文本处理、工具调用、上下文窗口管理这类实操方向。这一次把视角往上抬一抬专门聊两件事提示词模板管理和Agent 提示词编排。这两个词看着高大上实际上所有把 AI 投入到日常工作中的人都绕不开。拿我做过的项目来说一开始写提示词都是现想现写今天写一段“帮我总结文档”明天写一段“帮我把会议纪要整理成待办”每段都从零开始改来改去还会出现前后不一致。用过一段时间之后你会发现真正值得沉淀的其实就那几套结构把结构固定下来把变化的点抽出来做成变量这就是模板管理。而当任务复杂到需要一个智能体拆解、执行、检查、迭代时单一模板已经不够用得考虑怎么把多个提示词按流程串起来这就是编排。这篇内容适合正在做 AI 应用开发的人、想系统化使用 AI 工具的职场人也适合那些已经被“每次都要写一大段提示词”折磨到不耐烦的普通用户。我不打算讲太多抽象理论重点放在怎么设计模板、怎么组织多 Agent 的提示词、怎么写完直接能跑。1. 为什么要管提示词模板从手写 Prompt 到工程化1.1 提示词模板到底解决什么问题提示词模板不是把一段话存起来那么简单。它的本质是把提示词中的“经验”和“场景”分离。先说一个典型场景。我帮一个内容团队搭过一套 AI 工作流几个编辑每天都要让 AI 帮忙写选题、改标题、生成摘要。最早每个人都有自己的写法有人写得详细有人只给一句话。结果呢同一个选题AI 给出的标题风格五花八门有的偏向新闻体有的偏向自媒体风格编辑之间互相吐槽却没有一个人敢说自己写得“对”。后来我把这些零散的提示词收集起来拆成模板统一的结构就出来了固定部分你是谁、你要做什么任务、输出格式是什么变量部分选题名称、目标读者、字数上限、风格偏好编辑们之后的工作方式变成了填表而不是写作。填完表单AI 生成的结果风格基本一致质量下限被兜住了。这个例子说明模板解决的第一件事是一致性。模板解决的第二个问题是效率。你不需要每次从零开始写只需要替换变量就能拿到一段能用的提示词。尤其在使用 Claude、ChatGPT 这类工具时一个写好的模板配合输入变量敲几条内容就能批量完成任务。第三个是可测试性。如果你的提示词每次都不同你根本无法判断修改到底是变好了还是变坏了。模板固定后你可以只动一个变量对比输出差异找到真正影响结果的因素这也是后面要讲的“冒烟测试”的基础。1.2 模板化 vs 直接写死一个边界问题不是所有提示词都该模板化。我见过有些朋友走极端把一段 500 字的提示词整个存成模板里面塞了十几个变量用的时候反而比重新写还费劲。这属于过度抽象。什么时候适合模板化一般满足下面任意一条就可以考虑同一类提示词已经在三个以上不同场景中使用过团队里有多人共同使用同一种 AI 流程提示词长度超过 200 字且高频复用需要保证输出格式稳定或需要后续自动化解析反过来如果只是临时问一个简单问题直接写反而更快。比如你的需求就是“用一句话解释什么是数据库索引”你套模板纯属浪费时间。模板的颗粒度也需要拿捏。我常用的做法是大模板管流程小模板管知识点。一个大模板通常包含完整的角色定义、任务目标、输出规则适合作为一个独立的“技能单元”小模板则更像是零件比如一段专门写“markdown 表格转化规则”的片段可以在多个大模板中按需嵌入。两者互相配合比一把梭用一个巨型模板要灵活得多。1.3 模板之外为什么还要编排模板管的是“一段提示词怎么写得更好”编排管的是“多段提示词怎么协同工作”。这两者不是一回事。举个例子。你要让 AI 帮你写一份市场分析报告。如果只用一个大模板一次完成大概率拿到的是泛泛之谈结构好看数据经不起推敲。于是你把任务拆成多段第一段 Prompt让 AI 列出报告大纲第二段 Prompt让 AI 按大纲逐章撰写内容第三段 Prompt让 AI 对生成的内容做事实性检查第四段 Prompt汇总为最终报告每一段都可以是一个独立的模板但把它们串起来的方式、每段之间的衔接逻辑、上下文怎么传递这就是编排要解决的问题。尤其在 Agent 场景里智能体需要自主判断“下一步做什么”编排的好坏直接决定了它会不会跑偏、会不会一直在原地打转。那篇很火的 Agent 开发文章里提到过一个概念“Agent 不是提示词的堆积而是提示词的结构化协同”。我非常认同。单段提示词的强大是有限的真正让智能体看起来“聪明”的是它能够在多个提示词之间切换、回流和收敛。2. 模板设计的核心细节变量、结构、版本与自测2.1 把提示词拆成“不变底座 可变插槽”写模板的第一步不是打字是拆解。拿到一个任务把提示词里会变化的内容全部挑出来剩下的才是底座。举一个“文档总结模板”的例子。我先给你看一个没拆过的版本你是资深文档分析师请阅读下面的文档内容提取 10 条关键信息并按编号输出。文档标题是《2025 年产品规划》文档作者是李明重点关注市场趋势和竞品分析部分。这段提示词的问题很明显文档标题、作者、关注重点都是写死的换一篇文档就得重写。拆开之后是这样的你是资深文档分析师请阅读下面的文档内容提取 {要点数量} 条关键信息并按编号输出。 文档标题{文档标题} 文档作者{文档作者} 重点关注{关注方向}这样一改底座是固定的“分析师身份 提取规则”变量变成三个插槽。使用时只需要填三个值就能复用。如果一个模板里套路固定但每次使用的数据、侧重点、字数要求不同就该把变量抽出来。我自己的经验是变量数量控制在 3 到 7 个之间最好。少于 3 个说明模板的价值不高多于 7 个填的人会烦模型也容易混淆。不过也不是绝对复杂编排场景中变量会多一些此时建议给变量加上“分组”比如【任务信息】组、【输出规范】组避免一团乱麻。2.2 变量命名与默认值少让模型猜多给人留线索变量命名是个容易被忽视的细节。我在项目里吃过亏最初用中文变量比如{任务对象}、{输出风格}确实直观。后来跟技术人员协作他们更习惯英文或者短横线命名模板里混着{任务对象}和{output_style}一会儿下划线一会儿中文解析逻辑写着写着就乱了。现在我的团队统一采用两种风格供人填写的模板尽量用中文全角变量同时配套英文映射表供程序调用的模板强制用英文加下划线。格式不统一会导致脚本解析失败这个坑后面还会详细说。默认值的价值在于让模板在“不填也能用”和“填了更好用”之间取得平衡。比如你是资深文档分析师请阅读下面的文档内容提取 {要点数量|10} 条关键信息...|10表示默认取 10 条。用户图省事不填模型也会按 10 条来。在鸡汤式的 Prompt 指南里这叫“降低使用门槛”在工程里这叫“提供优雅的降级路径”。变量集中声明也是一条重要原则。不要把一个变量的定义分散在模板的多个位置导致填了这个忘了那个。可以在模板开头用一段“填空说明”注明所有变量含义也可以把这部分放在系统指令之外单独维护。2.3 模板字符串语法选型与转义陷阱写模板代码绕不开的就是字符串语法。最常见的两种是 Python 的 f-string 的{变量}风格和 JavaScript 模板字符串的${变量}风格。还有一类模板引擎如 Jinja2 使用{{ 变量 }}常用于 Dify、n8n 这类工作流平台。选择哪种语法取决于你的使用环境如果只是把提示词粘贴给 ChatGPT、Claude 这样的聊天工具用{变量}足够了最简单。如果你是写代码用 Python 的 f-string 或string.Template会比较顺手。Python 原生模板引擎里$变量风格有一个额外的好处当提示词本身需要包含花括号时用$变量不会冲突。如果使用 Dify、Coze、n8n推荐使用平台内置的{{变量}}语法它会自动处理上下文引用。转义问题很常见。比如你想让模型输出一段 JSONJSON 里的花括号会跟模板变量冲突。在 f-string 里你还得写双花括号{{ }}来表示字面量花括号稍不留神就会出错。更稳妥的做法是模板中尽量不要直接内嵌大片 JSON 示例用“字段说明”代替必须给示例时把示例放到外部文件用变量加载。这样模板可读性更高也不会被转义问题干扰。2.4 版本管理与冒烟测试模板也要有“基线”提示词模板本质上是一份代码。既然是代码就得考虑版本管理。我在本地工作目录里会这样组织prompts/ ├── base/ │ ├── summary_base.md │ ├── rewrite_base.md │ └── report_base.md ├── agents/ │ ├── planner.md │ ├── executor.md │ └── verifier.md └── templates/ ├── weekly_report.md └── product_analysis.md所有的模板文件都纳入 Git 管理。每次修改必须写清楚改动说明改了什么变量、为什么改、影响哪些流程。这听起来很重但在协作项目里它能救你一命。版本管理之外还要给模板设计“冒烟测试”。我借用了一个词叫“词组测试提示词”大意是准备一组长度短、内容固定的测试输入每次改完模板后跑一遍快速看输出是否离谱。比如我有个摘要模板每次改动后都会喂同一段 500 字的测试文本观察模型提取的要点是否还能覆盖关键信息、格式是否符合规范。如果测试都过不了模板大概率有问题更复杂的任务就别指望了。我有一次改动模板时不小心把“输出 5 条要点”误写成“输出 5 段摘要”冒烟测试跑了三条输入全部格式异常第一时间就发现了。如果没有这层测试等实际任务跑起来才发现至少浪费半小时。3. Agent 提示词编排实战从单段 Prompt 到多级协作3.1 把 System Prompt 当“岗位说明书”写进入 Agent 编排之前先要解决一个基础问题每个 Agent 的 System Prompt 该怎么写。我喜欢的写法是——把它当作一份岗位说明书。真实岗位说明书会写清楚五件事岗位职责、任职资格、工作流程、汇报对象、考核指标。Agent 的 System Prompt 也应该这样你是谁角色定位你负责什么职责范围你不能做什么边界约束你怎么做工作流程你交付什么输出格式比如我在一个信息整理项目里写的“资料搜集员”System Prompt你是资料搜集员负责为企业内部团队收集行业信息。 职责范围 - 只负责信息收集、筛选、归纳不负责撰写最终分析报告 - 每次输出必须包含信息来源和时间标注 工作流程 1. 根据用户给出的主题拆解检索词 2. 按检索词逐条收集信息 3. 去重、按可靠程度排序 4. 输出 Markdown 列表格式的结果 边界约束 - 不编造来源不确定的信息明确标注“待核实” - 不扩大收集范围只围绕用户给定的主题为什么要把边界写得这么清楚因为 Agent 编排中最常见的失败就是“越权”——资料搜集员开始写分析建议了分析员开始写执行计划了结果每个环节都在重复贡献最终输出一团糟。岗位说明书式的 System Prompt 就是用来画红线的。3.2 多智能体编排的流转规划器、执行器、验证器怎么写多智能体编排目前业界比较成熟的结构是三段式规划器Planner、执行器Executor、验证器Verifier。规划器的职责是把复杂任务拆成子任务并给出执行顺序。它的提示词重点是“拆解逻辑”核心变量如下你是任务规划器。 用户需求{任务描述} 请按以下步骤输出 1. 把任务拆成不超过 {max_steps} 个子任务 2. 为每个子任务命名并说明它的输入/输出 3. 标注子任务之间的依赖关系 4. 输出 JSON 数组字段包括task_id, task_name, depends_on, expected_output执行器的职责是根据规划结果逐个执行子任务。它的提示词重点是“上下文接收和结果交付”。注意执行器不需要知道完整任务只需要知道自己这一个环节的上下文你是任务执行器。 当前子任务{task_name} 上下文输入{context} 请完成子任务并按以下格式输出结果 - 结果正文不超过 {max_words} 字 - 关键结论列表 - 待核验疑点如果有验证器是很多人会省略、但极其关键的一环。它的职责是检查执行结果是否满足要求如果不满足就触发重新执行。这个验证器的提示词长这样你是质量验证器。以下是执行器生成的子任务结果。 原任务要求{task_requirement} 执行结果{executor_output} 请检查 1. 是否完成原任务中的所有要求 2. 是否有事实性错误 3. 输出格式是否符合规范 4. 给出结论pass / fail 5. 如果 fail请说明具体原因并给出修改建议不超过 {max_suggestions} 条我在实际项目里看到过不少失败案例信息遗漏、格式错乱、答非所问根源都是验证环节缺失。加了验证器之后执行器的错误可以及时被打回整体成功率至少提升两三成。3.3 上下文窗口有限编排时必须处理三件事Agent 编排一定会碰到上下文窗口瓶颈。再大的模型也有 token 上限任务一长上下文塞满了模型就开始“忘事”后面的输出质量直线下降。处理这个问题我总结了三个动作分段、压缩、遗忘。“分段”指的是每个子任务只携带自己需要的上下文不要把整个任务的背景全传给执行器。规划器生成 5 个子任务每个执行器只拿自己的输入片段这样上下文消耗是线性的而不是爆炸式的。“压缩”指的是当历史对话变长时用一轮额外调用把前面的对话摘要成几行概要再继续后续任务。类似给长会话打一个“缩略版”。“遗忘”就比较反直觉了——有些上下文明明有用但太久远留着只会干扰当前判断。比如一个 40 轮的长对话第 3 轮用户说过“格式要简洁”到第 38 轮你还让它遵守意义不大甚至会让模型过度约束自己的输出。这时候就要主动丢弃旧轮次内容只保留关键约束。我在编排模板里会专门放一段“长期约束区”把那些被遗忘的内容重新强调一遍其余的旧消息直接截断。3.4 编排平台与 API 集成Dify 能作为编程工具的 API 吗如果不想从零写编排框架直接用编排平台会省很多事。目前开源社区里用得比较多的有 Dify、Coze、n8n 等。这些平台的共同点是可视化拖拽、支持变量引用、内置工具调用适合快速搭一套 Agent 流程。有一个问题被问得特别多Dify 编排好了之后能不能作为 Continue、Cursor 这类编程工具的 API 来用答案是能但有条件。Continue 这类编程辅助工具支持自定义 API endpoint。你需要把 Dify 的“已发布应用”切换为“API 访问”模式拿到 App ID、API Key 和对应的 endpoint然后在 Continue 的配置中指定 base URL、model 和 headers。需要注意Dify 的 API 返回格式不一定和编程工具要求的标准 OpenAI 格式完全一致通常需要做一层格式转换或者选择平台提供的 OpenAI 兼容接口模式。Dify 编排中的多步骤工作流变量在工具侧调用时未必能暴露出来测试时要确认接口文档里的“输入参数”和“输出字段”。更稳妥的做法是把 Dify 做后端的“业务编排层”编程工具的普通对话调标准接口只有特定任务才调用 Dify 应用。把复杂编排放在后端前端工具的体验反而更清爽。我试过把 Dify 上的报告生成工作流挂到 Continue 里支持“一句话生成周报”这类任务没有问题但要实时调试修改工作流体验不如直接用 Dify 控制台。所以我的建议是如果你需要频繁调整流程先在 Dify 调试好再接入如果只是固定流程复用接入编程工具完全可行。4. 一套可直接套用的文档生成编排模板4.1 场景定义与整体链路理论讲了那么多最后落到一个能直接用的实操示例。我拿“市场调研简报生成”来说这是一个典型的多 Agent 任务包含三个阶段信息搜集、内容撰写、质量审查。整体链路如下用户输入主题和背景规划器根据主题拆出检索方向交给信息搜集 Agent信息搜集 Agent 生成结构化素材撰写 Agent 基于素材写简报审查 Agent 做事实和格式检查不合格则打回修改输出最终简报整套流程我用的是自己的编排脚本配合环境变量和模板文件。你也可以抄下来换成 Dify 里的节点配置。4.2 各环节 Prompt 模板全文规划阶段模板你是项目规划器。用户输入主题如下 {user_topic} 背景说明 {background} 请输出 1. 拆解为 3 个检索子方向 2. 每个方向给出 2 个检索关键词 3. 输出 JSON 格式 { sub_topics: [ {id: 1, name: ..., keywords: [..., ...]} ] } 不要输出额外解释。信息搜集阶段模板你是资料搜集员。请围绕以下关键词进行信息整理 {keywords} 信息范围要求 - 每条信息必须标注来源和可信度 - 同一方向不超过 5 条核心信息 - 有相互矛盾的信息请标注“存疑” 输出格式 方向1 - 信息条目 1来源...可信度高 ...撰写阶段模板你是报告撰写员。基于以下素材撰写简报不要自行补充素材以外的事实。 素材 {material} 简报要求 - 结构背景、核心发现、风险提醒、后续建议 - 字数{max_words} - 语言以“发现式陈述”为主不做方向性断言 - 引用素材中的来源标注 输出格式 ## 背景 ... ## 核心发现 ...审查阶段模板你是质量审查员。请审查以下简报是否满足要求 简报内容 {report} 审查要点 1. 是否准确反映素材结论 2. 是否包含无依据的断言 3. 格式是否符合要求 4. 请给出修改意见输出格式 { evidence: [问题1, 问题2], suggestion: ..., verdict: pass 或 revise }这里有一个细节审查模板要求输出 JSON是为了方便程序判断是否需要打回重写。如果审查结果是 revise直接让撰写 Agent 带上审查建议再写一版即可。4.3 参数校验与异常兜底模板写得再好参数传错一样白搭。我在脚本里加了一层简单的校验校验内容包括必填变量是否存在不符合就返回明确报错而不是默默用空字符串跑变量长度是否超过模型上下文可接受范围比如把一整本书塞进“素材”变量撰写 Agent 直接崩溃输出 JSON 是否为合法 JSON用一次轻量解析去验证解析失败就提示“审查输出格式异常”异常兜底我通常做两级第一级是如果审查环节返回结果无法解析自动重试一次第二级是如果重试仍然失败直接返回“请人工介入”的提示。宁可让流程停下来也不要把有问题的内容当作最终结果输出。这个原则在自动化流程里特别重要。4.4 把编排模板接入编程工具的几种路径如果你想把这套编排用在编程工具里大概有三条路。最直接的一种是把编排逻辑写成一个命令行工具输入主题输出简报文件然后让编程工具调用这个命令。我的做法是写一个简单的 Python 脚本接收参数后调用模型 API把结果写入本地 markdown。编程工具只需要发起一次终端调用即可。第二种是做成 HTTP 服务暴露一个接口编程工具通过请求拿到结果。适合需要多人共用一套编排的场景。第三种就是前面说的 Dify 平台。你只需要把上面这些模板内容填进 Dify 的节点配置中把输出字段绑定好应用本身的调用方随机应变即可。三者没有绝对好坏。追求稳定性选脚本追求复用选服务追求可视化选平台。我自己在不同阶段三种都用过目前项目里以第二种为主力。5. 常见问题与排查技巧实录5.1 模板变量缺失导致系统“跑题”现象模型聊着聊着突然不遵循约束回答内容宽泛甚至开始编造。我排查过几次发现最常见的肇事者是模板变量缺失。比如模板里要求{文档标题}必须在开头出现但脚本传参时漏了这个变量。模型看不到明确的文档标题只能根据上下文猜猜来猜去就跑偏了。排查方法是把传给模型的最终 prompt 原样打印出来人工看一遍变量替换后的文本。打印出来的内容往往一眼就能看出哪里空了哪里的信息不够准确。后来我在脚本里统一加了变量检查所有必填变量缺失都会提前报错连调用都不会发起。习惯上这叫 fail fast能帮你省下大量无效调用。5.2 编排链路太长触发执行中断运行长链路时经常出现模型中途返回错误或直接停止响应。我见过一条消息提示内容类似于“agent execution terminated due to error”。起初以为是网络问题后来发现是链路设计上没考虑上下文长度。当编排链路超过 15 到 20 轮或者单轮上下文超过模型窗口的 70%模型就很容易“迷路”。解决办法有两个方向一是减少轮次把多个简单步骤合并到一轮 Prompt 中一次性完成二是增加“心跳检查”每个子任务完成后立即确认是否需要继续而不是让模型自行判断“我该不该停”。实际项目里我遇到过最夸张的场景是一次调研任务拆了 32 个子步骤跑到第 19 步直接崩掉。后来我把子步骤合并成 8 组每组内部用模板控制输出格式整体链路缩短到 9 轮问题消失。5.3 模板拼接出错导致生成内容“结构损坏”有时候问题不在模型而在模板本身。我见过模板里花括号没闭合、变量名拼错、语法标识符用混等情况轻则模型输出格式错乱重则整个流程无法运行。这种问题和一份坏了打不开的文档很像——表面看是文件坏了本质是模板结构被改坏了。为了避免这个问题我给自己定了几条规则不在生产模板里直接修改花括号包裹的内容修改模板时先把旧版本复制一份改完做冒烟测试再替换变量名全部小写加下划线{任务背景} 这样混合中文英文命名的风格直接禁止。模板的变动记录也要跟着 Git 走不能改完就忘了。5.4 多智能体之间角色冲突编排中最讨厌的一种现象多个 Agent 各写各的输出之间互相矛盾。有一次我搭“双 Agent 辩论式总结系统”一方负责整理正反观点另一方负责结案讨论结果两个智能体都开始输出建议原本的“整理者”忘了自己的身份干起了“决策者”的活。问题的根源是 System Prompt 里虽然有角色定义但实际调用时上下文里塞入了太多无关内容稀释了角色信息的比重。解决办法有三个一是让每个 Agent 单独拿到一条经过强化的角色提醒尤其在大段上下文之前再重复一遍“你就是整理者你不是建议者”二是每个 Agent 的输出入口增加校验节点检查格式是否匹配预设字段三是限制每个 Agent 看到的上下文范围不让它接触到其他角色的完整输出。5.5 排查方法论三段切分法很多朋友遇到问题就从头到尾调一遍效率很低。我的排查思路是“三段切分法”。先把整条编排链路切成三段输入处理段、中间执行段、输出解析段。出现问题后先判断是发生在哪一段。输入处理段排查变量传递、文本清洗中间执行段排查提示词质量、模型参数、上下文长度输出解析段排查格式解析、字段映射、规则校验。判断方法是加日志。每一段都记录输入输出的关键摘要跑完后看日志定位异常点。这个习惯我在项目里坚持了很久到现在仍然觉得它是排查编排问题最有效的手段。不靠感觉靠记录才能不重复踩坑。写在最后回头看我自己的实践提示词模板和 Agent 提示词编排本质上是在“重复利用”和“灵活拆分”之间找平衡。模板给重复任务统一的骨架编排给复杂任务清晰的路径。两者结合AI 工具才真正从“聊天玩具”变成生产力工具。我个人的一个小技巧是在模板里埋“锚点词”。比如每段模板开头都有“以下是输出格式”这样的固定标记后续要接续生成时把这些锚点一起传给下一个 Agent它就知道该按什么规矩往下写。这个细节在聊天式工具里特别有用相当于给模型留了路标。这篇之后我计划再写一篇关于“提示词模板的版本回滚与团队协作”的内容把这些年踩过的模板协同的坑再展开聊。如果你也在做类似的事情欢迎在实践里验证这些方法或者在实际项目中调整成适合自己的版本。毕竟模板和编排本质上是私人化的工具好用比标准更重要。