Prompt Engineering 篇难度 3⏱ 12 分钟概念
01代码生成场景提示（Code Generation Prompts）
通过结构化提示词策略引导 LLM 生成高质量、可运行的代码
代码生成Code Generation提示模板Copilot编程辅助
更新于 2026-03-25code-generation-templates
Agent 应用中引导模型推理、调用工具和协作的三类标准化提示结构
内容摘要
Agent 场景提示模板是一套用于指导大语言模型在智能体（Agent）应用中完成"推理 → 行动 → 观察"循环的标准化提示词结构。它不是一条提示词，而是一类提示词的设计模式——告诉模型"你该怎么思考、什么时候调工具、拿到结果后怎么继续"。
Agent 场景提示模板是一套用于指导大语言模型在智能体（Agent）应用中完成"推理 → 行动 → 观察"循环的标准化提示词结构。它不是一条提示词，而是一类提示词的设计模式——告诉模型"你该怎么思考、什么时候调工具、拿到结果后怎么继续"。
在 Agent 出现之前，LLM 的使用方式主要有两种：一种是直接生成答案，但模型经常编造事实（Hallucination，幻觉）；另一种是直接调用函数，但模型不会解释为什么要调、调完了该做什么。这两种方式都无法应对"既需要推理，又需要与外部工具交互"的复杂任务。Agent 提示模板的核心贡献在于：用结构化的提示词把"思考过程"和"工具调用"串联起来，让模型的每一步决策都有据可查、可追踪、可调试。
目前业界主流的 Agent 提示模板分为三类：ReAct 模板（推理-行动循环）、Tool Use 模板（工具调用规范）、Multi-Agent 模板（多智能体协作协议）。三者不是互斥关系——一个完整的 Agent 应用通常同时使用多种模板。
Agent 提示模板的设计围绕六个核心要素展开：
| 要素 | 作用 | 说明 |
|---|---|---|
| System Prompt（系统提示） | 定义 Agent 的身份、能力边界和行为约束 | 整个提示模板的"宪法"，所有行为都在它划定的范围内发生 |
| Thought（思考） | 展示模型的推理过程 | Agent 的"内心独白"，决定下一步做什么、为什么这么做 |
| Action（行动） | 执行具体操作 | 调用工具、查询数据库或与其他 Agent 通信 |
| Observation（观察） | 接收外部反馈 | 工具返回的结果或其他 Agent 的回复，作为下一轮思考的输入 |
| Tool Definition（工具定义） | 描述可用工具的规格 | 包含工具名称、功能说明、参数类型和调用时机 |
| Collaboration Protocol（协作协议） | 规定多 Agent 间的通信规则 | 定义谁先谁后、信息怎么流转、何时终止 |
System Prompt 是 Agent 提示模板的根基。它不只是"你是一个 AI 助手"这样的角色声明，而是需要明确五个方面：核心任务（做什么）、可用能力（有哪些工具）、行为约束（不能做什么）、输出格式（结果长什么样）、安全护栏（如何拒绝有害请求）。Anthropic 的官方文档指出，Role Prompting（角色提示）是 System Prompt 最有效的用法——给模型一个具体的专家角色，比泛泛的"你是助手"要有效得多。
Thought 是 ReAct 模板的核心环节。一个有效的 Thought 应包含四个部分：任务分析（用户到底想要什么）、信息评估（当前信息够不够）、计划制定（下一步调什么工具）、反思纠正（上一步结果不理想时调整策略）。Thought 的价值不只是提升准确率，更重要的是让整个推理过程可视化，便于开发者调试。
Action 是 Thought 的执行产物，通常表现为工具调用。它必须严格遵循 Tool Definition 中的格式规范，否则工具无法解析。Observation 是工具执行后返回的结果，它会被拼接回 prompt 中作为下一轮 Thought 的输入。实践中，Observation 应做摘要或筛选，避免过长的原始数据消耗太多 Token（令牌，LLM 的计费和上下文计量单位）。
Agent 提示模板的核心机制是 Thought-Action-Observation 循环（简称 TAO 循环）。整个过程如下：
第 1 步：初始化。 用户输入问题，System Prompt 和 Tool Definition 已经预置在上下文中。模型接收到完整的 prompt 后开始第一轮推理。
第 2 步：推理（Thought）。 模型分析用户问题，判断是否需要外部信息。如果当前信息足够，直接输出最终答案；如果不够，规划下一步应该调用什么工具、传什么参数。
第 3 步：行动（Action）。 模型按照 Tool Definition 的格式生成工具调用指令。Agent 框架（如 LangChain、LlamaIndex）解析这个指令并执行实际的工具调用。
第 4 步：观察（Observation）。 工具返回结果，Agent 框架将结果拼接回 prompt 中。
第 5 步：循环或终止。 模型根据 Observation 判断：如果信息足够回答用户问题，输出最终答案并终止循环；如果还需要更多信息，回到第 2 步继续推理。
这套机制之所以有效，原因在于：Thought 让模型"展示工作过程"，减少了跳步导致的错误；Observation 提供了实时反馈，让模型可以自我纠正；而严格的格式约束确保了工具调用的可靠性。
图中的关键流转在于 H → C 的回路：Observation 会被拼接回上下文，触发新一轮 Thought。这个循环可能执行 1 次就结束（简单问题），也可能执行 5-10 次（复杂的多步骤任务）。开发者通常会设置最大循环次数防止无限循环。
下图展示三类模板的关系和各自的侧重点：
ReAct 模板解决"怎么推理"，Tool Use 模板解决"怎么调工具"，Multi-Agent 模板解决"怎么分工协作"。三者经常组合使用——比如一个 Multi-Agent 系统中的每个 Agent 内部都可能采用 ReAct + Tool Use 的结构。
以下伪代码展示 ReAct 模板的核心结构——System Prompt 如何定义 TAO 循环的格式。
# 伪代码：ReAct 模板的核心提示词结构
REACT_SYSTEM_PROMPT = """你是一个能够使用工具解决问题的 AI 助手。
可用工具：
- Search: 搜索网络信息。参数：query（搜索关键词）
- Calculator: 数学计算。参数：expression（数学表达式）
工作流程：
1. Thought：分析当前情况，规划下一步
2. Action：调用合适的工具，格式为 Action: 工具名[参数]
3. Observation：查看工具返回结果
4. 重复以上步骤直到能给出最终答案
示例：
Question: 2024 年中国 GDP 总量是多少万亿美元？
Thought: 这是一个需要最新数据的问题，我需要搜索。
Action: Search[2024年中国GDP总量]
Observation: 根据国家统计局数据，2024年中国GDP约为18.3万亿美元。
Thought: 已获得所需数据，可以回答。
Final Answer: 2024 年中国 GDP 总量约为 18.3 万亿美元。
"""
以下展示 Tool Use 模板的关键部分——JSON Schema 格式的工具定义。
# 伪代码：Tool Use 模板的工具定义结构（以 OpenAI / Anthropic 格式为例）
TOOL_DEFINITION = {
"name": "web_search",
"description": (
"搜索网络上的最新信息。"
"当用户询问时事、新闻或需要实时数据时使用。"
"不要用于回答常识性问题。" # 明确"何时不该用"
),
"input_schema": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "搜索关键词，尽量具体"
}
},
"required": ["query"]
}
}
# OpenAI 官方建议：工具定义要通过"实习生测试"
# ——一个不了解系统背景的人，仅凭这段描述就能正确调用工具
上述代码只展示提示词结构本身，未包含 API 调用逻辑。ReAct 模板的核心是 System Prompt 中的 Thought → Action → Observation 格式约定；Tool Use 模板的核心是 JSON Schema 格式的工具定义。实际运行时，Agent 框架负责解析 Action 并执行工具调用。
| 概念 | 与 Agent 场景提示模板的区别 | 更适合关注的重点 |
|---|---|---|
| Prompt Template（通用提示模板） | 泛指所有结构化提示词模板，Agent 场景模板是其子集 | 关注变量占位和格式统一，不涉及工具调用和循环推理 |
| Function Calling（函数调用） | 是 Tool Use 模板的底层实现机制，不包含推理循环 | 关注 API 层面的工具定义和调用协议，不关心 Thought 过程 |
| Chain-of-Thought（思维链，CoT） | 只关注推理过程的展示，不涉及工具调用和外部交互 | 关注"展示推理步骤"以提升复杂推理准确率 |
| Agent Framework（Agent 框架） | 是运行 Agent 提示模板的软件基础设施，不是提示词本身 | 关注代码实现、工具注册、消息路由等工程问题 |
核心区别：
| 常见误区 | 正确理解 |
|---|---|
| "ReAct、Tool Use、Multi-Agent 是三选一的关系" | 三者是互补的，实际项目中经常组合使用。一个 Multi-Agent 系统中的每个 Agent 内部通常都采用 ReAct + Tool Use 结构。 |
| "工具定义写得越详细越好" | OpenAI 官方建议工具定义要通过"实习生测试"——简洁到一个不了解背景的人也能正确使用。过长的描述反而增加 Token 消耗和理解难度。 |
| "Thought 输出越多，准确率越高" | Thought 的质量比数量更重要。关键是 Action 的准确性和 Observation 的信息质量。冗余的 Thought 只会浪费 Token。 |
| "Multi-Agent 一定比单 Agent 强" | Multi-Agent 引入了协调开销和错误传播风险。只有任务确实需要多种不同专长时，Multi-Agent 才有优势。简单任务用 Multi-Agent 是杀鸡用牛刀。 |
| "提示模板写好一次就不用改了" | 模型版本升级、任务需求变化都可能导致现有模板失效。应该建立提示词版本管理和持续评估机制。 |
参考答案：
Thought 负责推理和规划，Action 负责执行操作（如调用工具），Observation 负责接收外部反馈。如果去掉 Thought，模型会直接从问题跳到工具调用，失去了"先想清楚再动手"的环节。这会导致两个问题：一是工具选择可能不准确（没有分析就盲目调用）；二是推理过程不可见，开发者无法调试模型为什么做出了某个决策。ReAct 论文的实验也证实，去掉 Thought 会导致任务成功率明显下降。
参考答案：
排查方向：(1) 检查工具定义的 description 是否清晰，特别是"何时使用"和"何时不使用"的边界是否明确；(2) 检查 System Prompt 中是否有关于工具选择优先级的指导；(3) 检查是否存在功能重叠的工具导致模型困惑；(4) 查看 Thought 输出中模型对问题的理解是否正确。优化方向：精简工具描述使其通过"实习生测试"；在 System Prompt 中添加工具选择的 Few-Shot 示例；合并功能重叠的工具；考虑是否模型能力不足需要换用更强的模型。OpenAI 的官方建议指出，工具数量在 100 个以内时模型通常能正确选择，但工具越多歧义越大。
参考答案：
System Prompt 设计：定义角色为"电商客服专员"；列出四个工具（订单查询、退货处理、产品知识库搜索、转接人工）；明确行为约束（不承诺未经确认的退款、不透露内部系统信息）；规定输出格式（回复要简洁友好，包含订单号等关键信息）。Tool Definition 设计：每个工具的 description 要说明"什么情况下调用"（如"订单查询"要注明"用户提供了订单号或询问订单状态时调用"），参数类型和必填项要明确。选择 ReAct + Tool Use 而非 Multi-Agent 的理由：客服场景虽然有三类问题，但处理逻辑相对固定，一个 Agent 配合不同工具就够了。Multi-Agent 的协调开销（Agent 间传递信息、编排执行顺序）会增加延迟和复杂度，而客服场景对响应速度要求较高。只有当业务复杂到一个 Agent 的 System Prompt 无法合理描述所有逻辑时（如上百种业务场景），才值得拆分为 Multi-Agent。
优先展示同分类且标签更接近的内容，方便继续串联学习。
通过结构化提示词策略引导 LLM 生成高质量、可运行的代码
用结构化模板帮助 LLM 从原始数据中提取洞察、生成图表描述和分析报告的提示词设计方法
面向写作、翻译、摘要三大文本生成任务的提示词模板设计方法与核心要素