这个系列写到第七篇，话题切到提示词模板管理和Agent提示词编排。做Agent开发的人基本都有这种体验：单条Prompt写得再顺，一旦Agent角色多起来、工具多起来、流程分支一多，提示词就不再是“一段话”，而是一个需要被认真管理的系统。这篇文章我会从模板管理怎么落地讲起，再讲Agent场景下多个提示词怎么编排，最后附上可以直接抄作业的代码和一串踩坑记录。适合正在做Agent开发、AI工作流，或者准备从Prompt Engineer往Agent方向转的读者。
1. 为什么Prompt模板管理是Agent开发的必修课
1.1 从单条Prompt到Prompt系统的质变
很多人刚开始做Agent时，思维还停留在“写一条特别好的Prompt”上。Prompt Engineer时代确实是这样，你精心打磨一段系统提示词，调温度、调few-shot，效果就能有明显提升。但Agent项目完全不是这么回事。
我做过一个AI客服Agent，你猜里面有多少条Prompt？粗算一下：客服主系统提示词1条、意图识别提示词1条、情绪安抚话术模板3条、订单查询工具说明2条、退货流程引导1条、安全护栏提示词1条、记忆检索时的上下文组装模板1条，这就已经超过10条了。每条还可能有2到3个线上版本。
当Prompt超过一定数量，它就从“文本”变成了“代码”。你会遇到典型的工程问题：版本混乱、改A坏B、变量命名不统一、新同事看不懂某个Prompt为什么这么写、出问题不知道是哪条Prompt导致的。这些问题已经不是“把提示词写得更好”能解决的，必须把提示词当代码来管理。
这个转变是很多Agent项目翻车的分水岭。你去看那些做失败的Agent项目，大概率不是模型能力不够，而是提示词系统乱成一锅粥，模型的行为没法稳定复现，出了问题也没法排查。
1.2 模板管理解决的四个核心痛点
模板管理的意义，说白了就是解决四个问题。
第一，把提示词从代码里解放出来。很多项目一开始把Prompt直接写在Python文件里，用f-string拼接。短期没问题，等Prompt涨到几十条，改一次Prompt就要发一次代码，AI工程师和开发工程师互相等，效率极低。把Prompt抽成独立文件或独立配置，Prompt迭代就不再依赖发版。
第二，让变量和结构分离。Prompt里总有一些会变的部分：用户名、日期、商品信息、历史对话摘要。如果用f-string硬拼，变量一多就乱了。模板引擎可以声明变量、设置默认值、做条件渲染，结构是固定的，内容是可替换的，改起来心里有底。
第三，版本可回溯。模板管理至少要做到“改了什么、什么时候改的、为什么改”可查。这个用git就能解决，后面我会具体讲怎么组织。
第四，支撑评测和AB实验。Prompt模板管理好了，才能在相同输入下对比v1和v2的输出效果。如果你连模板都没法固定，评测结果根本不可信。
这四点没做好，后面做Agent编排就是空中楼阁。所以我的建议是：凡是超过5条Prompt的项目，第一天就该把模板管理建起来，别等乱了再回头补。
2. 提示词模板管理的三个层次与落地设计
2.1 第一层：单模板变量化与命名规范
模板管理的地基，是每条Prompt都先做变量化处理。
什么叫变量化？把一段写死的Prompt里所有可能变化的内容，全部替换成变量占位符。比如“你是客服助手，今天是2026年6月1日”要改成“你是客服助手，今天是{{ current_date }}”。变量化之后，Prompt的可复用性才会出现。
做变量化时最容易踩的坑是变量命名不规范。我见过一个项目里同一个字段叫user_name、username、name三种，渲染时一半没替换成功，模型拿到的就是“我是{{ username }}”，这还算好的，更怕的是渲染器把缺失变量替换成空字符串，模型拿到一段残缺指令还不知道哪来的。
我的做法是定一个命名规范：
- 全小写下划线风格，比如
user_name、order_id。 - 所有日期统一叫
current_date，不要有的地方叫today，有的叫date_now。 - 有默认值的变量在模板声明里写清楚，渲染前先做校验。
- 禁止在变量名里带前缀区别“系统变量”和“业务变量”，因为一旦开始区分，后面就会分家。
模板引擎层面，我会要求渲染失败时“快速失败”。也就是说，模板里声明了变量但渲染时没传值，直接报错，不要静默替换成空串。静默失败是模板管理里最恶心的坑，后面避坑清单里我会再提。
2.2 第二层：多模板目录与角色拆分
单条模板变量化做好后，第二步是设计目录结构。我的习惯是按照“角色/能力”拆分文件，每个Agent子模块维护自己的Prompt文件，放一个独立的prompts目录里，与业务代码隔离。
下面是我在一个实际项目里用过的目录结构，可以直接参考：
prompts/ ├── base/ │ ├── system_default.md # 通用系统提示词 │ ├── security.md # 安全护栏提示词，所有Agent共用 │ └── output_format.md # 通用输出格式约束 ├── agents/ │ ├── planner/ │ │ ├── system.md # 规划器系统提示词 │ │ └── fewshots.md # 规划器few-shot示例 │ ├── sql_generator/ │ │ ├── system.md # SQL生成专用提示词 │ │ └── examples.yaml # 示例对，用yaml存方便复用 │ └── reporter/ │ └── system.md # 结果解读与报告生成提示词 ├── workflows/ │ ├── customer_service/ │ │ ├── main.yaml # 客服流程编排配置 │ │ └── user_context.md # 用户上下文组装模板 │ └── data_analysis/ │ ├── main.yaml # 数据分析流程编排配置 │ └── chart_recommend.md # 图表推荐提示词 └── versions/ └── changelog.md # 模板变更记录这个结构有几个好处：目录即导航，新同事来了看目录就知道这个Agent有哪些模块；每个文件职责单一，不会出现一个几百行的巨型Prompt；通用部分放在base里复用，避免每个Agent各写一套安全提示词然后出现口径不一致。
角色拆分的原则也值得说：不要按聊天轮次拆，要按职责拆。同样是“回答问题”，客服主回复是一个角色，SQL生成是另一个角色，它们不应该混在同一个模板里。混在一起会导致模型在不止一个环节被调用时，行为边界是模糊的。
2.3 第三层：场景化的模板包与版本追踪
第三层是把多个模板组织成“模板包”，按场景复用。你不需要每次写代码时手动拼接十几条Prompt，而是定义一个场景配置，运行时自动加载对应的模板包。
比如客服场景的模板包是：system_default.md+security.md+user_context.md+agents/customer_service/system.md。数据分析场景的模板包则是：system_default.md+security.md+agents/sql_generator/system.md+agents/reporter/system.md。场景不同，加载的模板组合不同，base部分的自由度就体现出来了。
模板包怎么定义？我用的是YAML配置文件加一个加载器，类似这样：
# workflows/customer_service/main.yaml name: customer_service version: 1.4.0 templates: system: ../base/system_default.md security: ../base/security.md context: ./user_context.md main_agent: ../agents/customer_service/system.md variables: max_history_rounds: 10 default_emotion_style: 温和版本追踪方面，我用的就是git加一个changelog文件。每次改Prompt，commit message写清楚“改了什么、为什么改、预期影响”。线上出问题时，能通过模板版本号快速定位到当时使用的Prompt快照。
这里有个细节很多人忽略：模板版本和代码发布要绑定。模板变了，Agent行为就会变，如果代码没发布但模板发布了，线上行为会不一致。我的做法是在部署时把模板打成一个带版本号的快照文件，和代码一起发布。这样代码和Prompt永远是同一时间点的状态，排查问题不会出现“代码是昨天的，Prompt是上周的”这种混乱。
3. Agent提示词编排：让多个Prompt协同工作
3.1 编排的本质：不是拼Prompt，而是设计Agent的工作流
模板管理解决的是“每条Prompt怎么写、怎么存”的问题，编排解决的是“这些Prompt怎么配合、在什么时机用什么Prompt、各自的输入输出怎么衔接”的问题。
很多人理解的编排就是把系统提示词拼得特别长，把所有要求、所有工具说明、所有历史对话、所有角色描述一次性塞进去。这是误区。Agent场景下，上下文窗口是有限的，而且模型对巨长提示词的注意力会分散。你把20条规则写进一个系统提示词，模型往往只记得前几条和后几条，中间的规则形同虚设。
真正的编排，是根据任务的推进阶段，动态组装不同的提示词。举个例子，一个数据分析Agent跑一次完整流程大概是这样的：
- 第一阶段：主控Agent收到用户问题，用主控提示词判断意图，决定是否需要查数据。
- 第二阶段：如果查数据，规划器用规划提示词拆解问题，生成SQL查询子任务。
- 第三阶段：SQL生成模块用SQL专用提示词，结合表结构和示例，生成可执行SQL。
- 第四阶段：执行SQL拿到结果后，报告模块用报告提示词，把数据解读成业务结论。
每个阶段只注入这个阶段需要的Prompt，上下文是精简的，职责是清晰的。这就是编排的价值：让Agent的每一步都有明确的角色、明确的输入、明确的输出约束，而不是把所有事情压给一次大上下文推理。
3.2 一次长Prompt与模块化编排的对比
拿一个具体的场景比较一下就清楚了。假设要做“先查库存，再生成补货建议”的Agent。
不编排的写法是：系统提示词里写“你是库存管理助手，你可以查询库存表，查询后根据库存量和销量生成补货建议，注意如果库存低于安全线要提醒紧急补货……”然后一次性把所有查询结果、历史记录都塞进去，让模型自己输出最终建议。
这种写法的直观问题有三个。第一，如果模型中间忘了调用工具，整个回答就会开始编数据。第二，系统提示词里工具说明多了，模型反而拿不准什么时候该用什么工具。第三，一旦输出格式不对，后续整个链路都崩了。
模块化编排之后，流程变成：
- 意图识别层：判断用户那句话是不是补货相关。
- 工具调用层：用工具提示词（只描述一个工具：查库存表）触发查询。
- 结果汇总层：把查询结果填入报告模板，生成补货建议。
每一层的Prompt都短而专一。模型在工具调用层只做一件事，成功率明显高于让它在超长上下文里同时做三件事。
我列一个对比表，方便大家直观感受：
| 维度 | 单条超长Prompt | 模块化提示词编排 |
|---|---|---|
| 上下文占用 | 高，每次都把所有内容塞进去 | 低，按需注入 |
| 可维护性 | 改一处可能影响全局 | 每个模块独立迭代 |
| 可调试性 | 输出不对难以定位哪条规则导致的 | 按阶段查看日志即可定位 |
| 输出稳定性 | 规则多，输出容易飘 | 每个模块输出约束简单，稳定性高 |
| 复用性 | 整段绑定一个场景 | base部分可复用 |
我接触过的Agent项目里，凡是单条Prompt超过3000字的，基本都会遇到“改一条规则，另一处行为变了”的问题。模块化编排之后，这类问题少了一大半。
3.3 编排的核心原则
总结下来，编排时我会死守四个原则。
第一个，单一职责。每个模板只描述一个角色做一件事，不要在一个模板里既要模型规划、又要它调用工具、还要它生成报告。职责混在一起，模型行为就不可控。
第二个，上下文最小化。每个阶段只注入当前工作需要的上下文，历史记录只保留必要摘要，不要一股脑全塞。这里顺便说一句，很多Agent“越聊越笨”，就是因为上下文无限膨胀，模型注意力被历史噪音稀释了。
第三个，输出格式优先稳定。编排链路里每个模块的输出都会被下一个模块消费，如果上一个模块输出的是Markdown，下一个模块却按JSON解析，必崩。我现在的习惯是：模块间通信统一用JSON，每个模板末尾都写清楚“只输出JSON，不要额外解释”。格式稳定，链路才稳定。
第四个，全程可观测。每个阶段的输入输出都要记录日志，尤其是Prompt模板的版本号、最终渲染后的完整文本、模型输出原文。出了问题，顺着日志从后往前查，就能定位是模板问题、输入问题还是模型问题。
4. 实操：自己写一套轻量模板管理模块
4.1 选用Jinja2的理由
模板引擎的选择上，我推荐Jinja2，主要原因是它在Python生态里最普及、语法能力强、社区成熟、几乎不会有维护风险。
有人问为什么不直接手写Python字符串拼接。字符串拼接的痛点在于条件逻辑和循环逻辑写起来特别痛苦，比如“如果有历史对话就插入，没有就省略”这种逻辑，f-string写起来会非常丑。Jinja2天然支持{% if %}、{% for %}、过滤器、默认值，模板文件可以干净地保持声明式风格。
还有人问为什么不选LangChain内置的PromptTemplate。LangChain的PromptTemplate语法其实就是Jinja2的子集，如果你直接用Jinja2，未来不绑定任何框架，代码更通用。我自己更倾向于轻量自建，尤其是项目早期，不引入重框架，逻辑越透明越好排查。
4.2 PromptManager代码实现
下面是我在实际项目里用的一个精简版PromptManager，核心功能是：加载指定目录的模板、渲染变量、校验必填参数、支持模板片段拼接。代码不长，但实用性很高。
import json from pathlib import Path from jinja2 import Environment, FileSystemLoader, StrictUndefined class PromptManager: def __init__(self, template_dir: str): self.template_dir = Path(template_dir) self.env = Environment( loader=FileSystemLoader(str(self.template_dir)), undefined=StrictUndefined, # 缺失变量直接报错，不静默替换 trim_blocks=True, lstrip_blocks=True ) def render(self, template_name: str, variables: dict) -> str: template = self.env.get_template(template_name) return template.render(**variables) def render_with_base(self, main_template: str, base_templates: list, variables: dict) -> str: """组合多个基础模板和主模板""" parts = [] for base_name in base_templates: parts.append(self.render(base_name, variables)) parts.append(self.render(main_template, variables)) return "\n\n".join(parts) def save_snapshot(self, final_prompt: str, meta: dict, output_dir: str): """保存最终渲染后的Prompt快照，用于排查问题""" path = Path(output_dir) path.mkdir(parents=True, exist_ok=True) snapshot = { "meta": meta, "prompt": final_prompt } snapshot_path = path / f"{meta.get('trace_id', 'prompt')}.json" snapshot_path.write_text( json.dumps(snapshot, ensure_ascii=False, indent=2), encoding="utf-8" ) return str(snapshot_path)代码里有几个细节值得讲。一是StrictUndefined，这个开关是灵魂。它让未传入变量直接抛异常，而不是被替换成空字符串。很多线上问题就是空字符串偷偷替换导致的，开了这个开关可以把问题扼杀在开发期。
二是trim_blocks和lstrip_blocks，这两个参数让模板里的缩进和换行更干净，渲染出来的最终Prompt不会到处都是多余空行。模型对空行其实没什么偏见，但日志排查时你会感激这个设置的。
三是save_snapshot，这是我后来加的功能。每次生成最终Prompt时都存一份完整文本和meta信息，meta里带上trace_id、模板版本号、模型版本、时间戳。线上出问题，直接靠trace_id拉出当时的完整Prompt，不用猜。
4.3 调试模式与最终渲染检查
用了PromptManager之后，开发阶段我会开一个“调试模式”，把每条模板的最终渲染结果完整打印到本地日志里，肉眼检查一遍再调模型。这个习惯帮我抓到了大量低级错误，包括变量没替换、模板语法写错、base模板拼接顺序不对等。
一个很简单但很有效的检查方法是：渲染后的Prompt里搜索“{{”或“}}”，只要有残留，说明有变量没替换成功。虽然StrictUndefined会拦住大部分，但有些时候是在模板片段里写了嵌套变量，渲染完还是残留的，人工检查更稳妥。
调试代码长这样：
manager = PromptManager("prompts") variables = { "user_name": "张三", "current_date": "2026-06-01", "products": ["咖啡", "牛奶"] } final_prompt = manager.render_with_base( main_template="agents/customer_service/system.md", base_templates=["base/system_default.md", "base/security.md"], variables=variables ) print("===== FINAL PROMPT =====") print(final_prompt) print("===== END PROMPT =====")跑一次，看一眼输出格式，确认没有变量残留，再接入Agent主流程。整个开发节奏是“改模板 -> 跑调试 -> 看渲染结果 -> 人工确认 -> 接流程”，比直接在线上Agent里试错稳得多。
5. 实战案例：三阶段数据分析Agent的提示词编排
5.1 整体流程设计
光讲理论不过瘾，我拿一个真实做过的“业务数据分析Agent”来演示编排是怎么落地的。
这个Agent要做的事情：用户用自然语言提问，比如“上个月华东区销售额环比增长了多少”，Agent需要先拆解意图，再生成SQL去查数据库，最后把查询结果转成业务结论。
如果用单条超长Prompt做，基本会变成：系统提示词里塞表结构、塞SQL规范、塞解释范本，模型一步到位。试过就知道，这种做法的SQL生成质量很不稳，经常忘表名、瞎编字段，解释也容易跑偏。
我最后拆成了三个阶段：
- 意图拆解阶段：判断用户问题类型（查数、趋势对比、下钻、异常告警），输出一个结构化的任务描述。
- SQL生成阶段：根据任务描述、表结构、few-shot示例生成SQL，并做基础校验。
- 结论解读阶段：把SQL查询结果翻译成业务语言，附上建议。
每个阶段用独立的Prompt模板，阶段之间通过结构化数据传递，而不是通过自然语言传递。
5.2 三个阶段的模板要点
意图拆解阶段的模板核心是让模型输出一个JSON规范的任务描述，模板里不写任何业务字段，只定义输出格式：
你是一个业务分析意图拆解器。用户会输入一个数据分析问题，你需要判断问题类型并输出一个结构化的JSON。 问题类型包含：trend（趋势）、compare（对比）、breakdown（下钻）、anomaly（异常）、other（其他）。 输出格式要求： - 只输出一个JSON对象，不要输出任何额外文字。 - 字段说明： - intent_type: 字符串，问题类型 - time_range: 字符串，用户提到的时间范围 - target_metric: 字符串，用户要分析的指标 - dimension: 字符串，分析维度，比如地区、产品线 - conditions: 对象，用户提到的过滤条件，键值对形式 示例输入：上个月华东区销售额环比增长多少？ 示例输出：{"intent_type": "compare", "time_range": "上月", "target_metric": "销售额", "dimension": "区域", "conditions": {"区域": "华东区"}}这个模板的巧妙之处在于它不问模型“你是什么角色”，而是直接给任务定义和输出格式。模型不需要产生太多角色想象，行为会更直接。
SQL生成阶段模板是整套里最长的，因为它需要注入表结构信息。但注意，信息注入也是按需的，只在需要的时候把相关表结构渲染进去，其他表一概不给：
根据以下任务描述和表结构，生成一条可以执行的PostgreSQL SQL。 业务表结构： {{ table_schema }} 历史参考示例（只在结构和语义匹配时参考）： {{ few_shots }} 任务描述： {{ task_json }} 约束： 1. 字段名必须来自表结构，禁止编造字段。 2. 涉及日期过滤时，按照 {{ current_date }} 作为当前日期推算。 3. 只输出SQL，不要解释。 4. 如果任务无法用SQL完成，输出一个JSON：{"error": "无法生成SQL"}。结论解读阶段模板则负责把一行行数据转成用户能看懂的话。这里有个小技巧：模板里写死“支持数据，不要编造结论”，因为模型看到一堆数字后容易自由发挥，把它按住很重要。具体我按照完整流程写一下。
三个阶段的Prompt合在一起，正好体现编排的核心思想：每个模板只解决一个问题，输出格式互相衔接，模板之间通过结构化数据传递，而不是通过一段自然语言的总结去接力。
5.3 编排器怎么把它们串起来
编排器没有用任何Agent框架，就是用几行Python代码控制流程。核心逻辑如下：
import json def run_analysis_agent(user_question: str, manager: PromptManager, table_schema: str, few_shots: str): # 阶段一：意图拆解 intent_prompt = manager.render( "agents/planner/system.md", {"user_question": user_question, "current_date": "2026-06-01"} ) intent_output = call_llm(intent_prompt) task_json = parse_json_output(intent_output) # 解析失败就重试或报错 # 阶段二：SQL生成 sql_prompt = manager.render( "agents/sql_generator/system.md", { "table_schema": table_schema, "few_shots": few_shots, "task_json": json.dumps(task_json, ensure_ascii=False), "current_date": "2026-06-01" } ) sql_output = call_llm(sql_prompt) sql_text = extract_sql(sql_output) # 处理模型可能加的代码块 # 阶段三：查询并解读 query_result = execute_sql(sql_text) report_prompt = manager.render( "agents/reporter/system.md", {"user_intent": user_question, "query_result": json.dumps(query_result, ensure_ascii=False)} ) final_report = call_llm(report_prompt) return final_report这段代码没用什么花哨的框架，就是把三个阶段按顺序串起来，中间加了JSON解析和SQL提取两个小模块。这本身就是编排：流程是你定义的，但不是靠人肉拼接提示词，而是靠代码控制每个阶段的输入输出。
实际运行中我还加了一个兜底机制：如果SQL生成失败，会带着错误信息退回意图拆解阶段，让模型重新生成一个更保守的任务描述。这个“反馈循环”是Agent编排里很关键的一环，后面有时间单独写一篇。
编排器的另一个重要职责是日志。每个阶段调用模型前后，都要记录trace信息。我通常会把每个阶段的Prompt摘要、模型输出摘要、耗时都写进日志，这样问题定位可以精确到“是SQL生成阶段崩了，还是SQL执行阶段崩了”，而不是面对一大段上下文瞎猜。
6. 提示词模板与编排的避坑清单
6.1 常见的8个坑
做模板管理和编排久了，踩过的坑能列一长串。我捡8个最常见的讲，基本每条都踩出过生产事故。
第一个坑：变量命名不一致导致渲染静默失败。前文提过，同一个字段在多个模板里叫法不一样，user_name和username混用。开了StrictUndefined之后问题会暴露，但很多老项目没开，线上就会出现Prompt里夹着变量名直接发给模型的情况。解决方案是从项目第一天就统一命名规范，渲染器里开严格模式。
第二个坑：模板越写越长，最终退化成一个巨型Prompt。拆分是反人性的，因为写一个巨型Prompt对开发来说更快，但线上的维护成本会爆炸。我的经验是：单个模板文件超过150行，就一定要拆分。拆不掉就说明这个模块的职责本身就不单一，需要重新设计。
第三个坑：输出格式约束写得模糊。比如只说“输出JSON”，没说字段结构、没说类型、没说要不要换行。模型就会给你配一堆markdown代码块、额外解释文字，下游解析器一崩再崩。约束必须像接口文档一样写清楚，甚至把示例写进模板里。
第四个坑：上下文无限膨胀。把用户全部历史对话、全部工具结果都塞进Prompt，模型注意力被噪音稀释，回答质量肉眼可见地下降。现在我的准则是：只保留当前任务需要的上下文，历史信息做摘要后再注入。
第五个坑：多个子Agent的提示词角色冲突。比如主Agent系统提示词说“你是客服助手”，SQL生成模块又说“你是数据分析师”，模型在上下文里同时看到两个身份，行为就会摇摆。解决方案是保持模块之间身份隔离，每个模块的用户可见性和角色定义只在自己Prompt里出现，不互相混用。
第六个坑：模板版本与代码发布脱节。模板改了但代码没发，或者反过来，线上跑的是旧模板新代码，行为错乱。现在我把Prompt快照打包进部署产物，一个版本号对应一套完整状态，从根上避免这个问题。
第七个坑：模板里写死了业务逻辑。比如把仓库编号、优惠策略直接写进Prompt，业务一改就要改模板发版，还容易外泄。业务逻辑应该通过变量和工具传入，模板只负责描述“怎么用这些信息”。
第八个坑：缺少最终渲染结果日志。这个问题最隐蔽，因为它平时不影响运行，一出问题就要命。没有完整Prompt日志，你只能对着模型输出猜“它是不是没看懂”，实际上可能是上游变量传错了。现在的习惯是每次调用都存快照，重要对话存30天。
6.2 快速自查表
下面是我每次上线Agent前会过一遍的自查表，也分享出来：
| 检查项 | 正常状态 | 危险信号 |
|---|---|---|
| 变量覆盖 | 渲染结果无保留变量 | Prompt里能看到{{ xxx }}残留 |
| 模板拆分粒度 | 单文件不超过150行 | 单文件超过300行，职责不清 |
| 输出格式约束 | 明确到字段级别 | 只写了“输出JSON”或“用列表回答” |
| 上下文大小 | 只注入当前任务所需 | 一次调用塞入全部历史 |
| 版本绑定 | Prompt快照与代码同版本发布 | 线上模板与仓库不一致 |
| 日志完整度 | 每阶段都有trace记录 | 出问题只能靠猜 |
| 模块身份隔离 | 各模块角色不重叠 | 多个模板用同一身份描述 |
这张表我打印出来贴工位了，新项目上线前必过一遍，省了太多事。
7. 框架与自研怎么选
7.1 主流框架里的Prompt编排能力
最后聊一下热词里反复出现的Agent框架。现在主流的Agent框架确实都内置了提示词编排能力，但不同框架的侧重点不太一样。我做过一个粗略对比，写出来供参考。
LangChain系框架的Prompt管理是最成熟的，有专门的MessageTemplate体系，支持从文件加载、变量渲染、输出解析器串联。它的好处是生态大、教程多，坏处是抽象层次多，排查问题时要穿过好几层封装才能看到最终Prompt长什么样。
LlamaIndex更偏向RAG场景，编排上更关注检索上下文与提示词的组装。如果你的Agent核心是知识库问答，LlamaIndex的Prompt模板设计可以直接参考。
一些可视化平台比如Dify、Coze，把提示词编排做成了界面操作，适合快速搭原型，但对复杂工作流和精细管控来说不够灵活，尤其不适合需要深度定制模板逻辑的团队。
代码型Agent框架比如AutoGPT、MetaGPT这种，编排的重心放在任务规划和多Agent协作上。它们内置的Prompts非常值得读，很多设计思路可以直接借鉴。MetaGPT的多人协作提示词设计尤其出色，每个角色的Prompt都遵循严格的输出协议，是很好的学习样本。
吴恩达那套Agent设计模式公开教程里提到过四个核心模式：反射、工具使用、规划、多智能体协作。在我看来，模板管理与编排主要支撑的是“规划”和“多智能体协作”，没有稳定的Prompt基础设施，这两种模式很难落地。
7.2 我的选型建议
我的建议可以浓缩成一句话：项目初期不要直接上重框架，先用文本模板加几行代码把编排跑通，等流程稳定了再看要不要引入框架。
原因很简单。第一，直接上框架会把“Prompt管理”和“Agent流程控制”耦合在一起，出了问题你分不清是模板问题还是框架问题。第二，框架的抽象层级通常比较高，你不太能控制每个阶段Prompt的最终细节，这对初期调试很不利。第三，很多框架会在你的Prompt之外自动注入额外的系统消息，这个行为不透明，很容易让模型行为出乎意料。
自己先把模板管理和编排器写出来，最大的收获是对整个流程有完全掌控。等到项目复杂度明显上升，比如需要多Agent并行、需要记忆持久化、需要复杂的工具调度时，再迁移到框架也来得及。而且因为你已经理清了Prompt和流程的边界，用框架时也能更好地理解哪里该用框架的能力、哪里该保留自己的实现。
现在的趋势是Agent中台、Agent平台这些概念越来越热，但我始终觉得，不管上层怎么变，底层的Prompt质量和管理能力永远是Agent效果的基石。
我个人在实际项目里折腾了几轮之后的体会是：提示词模板和编排这事儿，最难的其实不是技术，而是克制。克制住“一条Prompt搞定一切”的冲动，克制住“先上线再说”的侥幸，克制住“过度设计”的欲望。从简单可用的文本模板开始，把变量、版本、日志这几样基础打牢，再逐步引入场景化模板包和流程编排，这套路是最稳的。最后再分享一个小技巧：每次改完模板，别急着调模型，先看一眼渲染后的纯文本干净不干净，这个习惯帮我拦下了不知道多少次无效试错。
