大模型应用实战百科
提示词工程 · 工作流 · 智能体

什么是提示词工程

从最基本的概念出发，理解提示词工程到底是什么。

定义

提示词工程（Prompt Engineering）是一门关注提示词（Prompt）开发和优化的学科，旨在帮助用户将大语言模型（LLM, Large Language Model）应用于各类场景。它不仅仅是"写一个问题"，而是一套与 AI 高效沟通的工程方法论。

根据 Prompt Engineering Guide（promptingguide.ai）的定义，提示词工程涵盖：

• 与大语言模型交互和研发的各种技能与技术
• 提升 LLM 处理复杂任务（如问答、算术推理）的能力
• 提高大语言模型的安全性
• 借助外部工具和专业知识增强 LLM 能力

提示词的英文术语

在学习过程中你会频繁遇到以下英文术语，这里先做个对照：

为什么需要学习提示词工程

理解学习的动机，才能建立持续学习的动力。

四大核心理由

1. 释放 AI 的全部能力

DeepLearning.AI 课程中，吴恩达（Andrew Ng）用一个生动的比喻说明：LLM 就像一个"非常聪明但需要明确指令的新同事"。你给它的指令越清晰，它交付的结果越好。同一个模型，不同的提示词可以产生从"无法使用"到"惊艳专业"的天壤之别。

帮我写个产品介绍

你是一位资深产品文案。
请为一款"智能降噪耳机"写
一段 200 字的产品介绍，
目标用户是 25-35 岁都市白领，
语气专业但亲切，突出降噪和
续航两个卖点。

2. 降低成本与提升效率

好的提示词能减少试错次数，降低 Token 消耗（即 API 调用成本）。Learn Prompting 的课程强调，系统化的提示技巧可以让你第一次就得到高质量输出，而不是反复修改、反复调用。

3. 提高输出的可靠性与一致性

在生产环境中，你需要 AI 的输出稳定、可预测、可复现。提示词工程提供了一系列结构化方法（如格式约束、Few-shot 示例、思维链等），让模型输出从"偶尔好"变成"持续好"。

4. 一项通用技能

提示词工程的原理是跨平台通用的。无论你使用 GPT、Claude、Gemini 还是开源模型，核心方法论一致。OpenAI 指南和 Anthropic 指南虽然各有侧重，但底层原则高度相通——学会了这些通用方法，你可以快速适应任何新模型。

核心学习资源概览

本指南融合的核心学习资源各有侧重，了解它们的特点有助于你选择适合自己的补充学习路径。除以下五大主资源外，还整合了 OpenAI Cookbook 和 Microsoft Azure OpenAI 学习路径。

LLM 是如何工作的

理解模型的工作原理，才能理解为什么某些提示技巧有效。

大语言模型的训练过程

Learn Prompting 课程指出，理解 LLM 的工作原理是写好提示词的基础。大语言模型的诞生通常经历三个阶段：

① 预训练（Pre-training）

模型通过阅读海量互联网文本，学习语言的统计规律和世界知识。这个阶段模型学会了"续写文本"——即根据前面的内容，预测下一个最可能出现的词。但此时的模型还不会"对话"。

② 指令微调（Supervised Fine-Tuning, SFT）

用大量"指令-回答"的示例数据训练模型，让它学会按照人类指令行事，而不是单纯续写文本。

③ 人类反馈强化学习（RLHF）

让人类对模型的多个回答进行排序打分，用这些偏好数据训练一个"奖励模型"，再通过强化学习优化模型，使其输出更符合人类期望（更有用、更诚实、更安全）。

核心机制：下一个 Token 预测

无论经过怎样的训练，LLM 的底层机制始终是基于概率预测下一个 Token（词元）。它不是在"搜索答案"，而是在"生成最可能的下一个词"。

为什么模型会"一本正经地胡说八道"

因为模型是在"生成最可能的下一个词"，当它不确定答案时，它会生成看起来合理但实际错误的内容——这就是所谓的幻觉（Hallucination）。提示词工程的重要目标之一，就是通过清晰的指令和准确的上下文来减少幻觉。

关键概念：Token 与上下文

掌握 Token 和上下文窗口这两个核心概念，是理解提示词工程的前提。

Token（词元）

# 英文 "Hello world" = 2 个 Token
# 中文 "你好世界" ≈ 4-6 个 Token（取决于分词器）
# 1 个英文单词 ≈ 1-2 个 Token
# 1 个中文字 ≈ 1-2 个 Token

上下文窗口（Context Window）

模型参数设置详解

Prompt Engineering Guide 的 LLM Settings 章节详细介绍了通过 API 调整模型行为的关键参数。理解这些参数能帮助你获得更稳定、更符合预期的输出。以下是 6 个核心参数的完整说明：

提示词的四大要素

一个好的提示词通常包含四个组成部分，理解它们是构建有效提示的基础。

Prompt Engineering Guide 指出，一个完整的提示词通常由以下四个要素构成（并非每次都需要全部，但理解它们有助于系统构建提示）：

完整示例

# 【指令】
请将以下用户评论分类为"正面"、"负面"或"中性"。

# 【上下文】
我们正在分析一款智能手表的用户反馈，
分类结果将用于产品改进决策。

# 【输入数据】
评论内容："手表外观不错，但电池只能撑一天，
而且心率监测经常断连，体验不太好。"

# 【输出格式】
请以 JSON 格式输出，包含字段：
- sentiment: 分类结果
- reason: 一句话理由

进阶：Azure OpenAI 的五组件模型

Microsoft Azure OpenAI 的 提示工程技术指南提供了一个更精细的提示组件拆分模型，将提示分为 5 个组件（按使用频率从高到低排列，均为可选但至少需要一个）：

两大核心原则

DeepLearning.AI 课程提出的两大原则，是所有提示词工程技巧的根基。

吴恩达在 DeepLearning.AI 课程中提出了编写有效提示词的两大核心原则，这两条原则贯穿了几乎所有提示技术，是入门提示词工程最重要的认知。

原则一：编写清晰具体的指令

技巧 1：使用分隔符标识输入

用分隔符清晰区分指令与输入数据，避免模型混淆——这是 OpenAI 官方指南的首要建议。分隔符的作用是在提示词中创建明确的"边界"，让模型清楚知道哪部分是指令、哪部分是需要处理的数据、哪部分是参考信息。

以下是 5 种常用分隔符的详细对比，帮助你根据场景选择最合适的方案：

请总结以下用 <article> 标签包裹的文本：

<article>
人工智能（AI）是计算机科学的一个分支，
致力于创造能够模拟人类智能行为的系统...
</article>

请用 3 句话概括核心内容。

请总结以下用三重引号包裹的文本：

"""
人工智能（AI）是计算机科学的一个分支，
致力于创造能够模拟人类智能行为的系统...
"""

请用 3 句话概括核心内容。

中文大模型的分隔符最佳实践

以上分隔符原则在国际模型（GPT、Claude）上验证成熟。对于国产中文大模型，各厂商基于自身训练特点也给出了官方建议，以下汇总 DeepSeek、豆包（字节跳动）等模型的分隔符使用规范，帮助你针对不同模型优化提示词。

# DeepSeek 官方推荐的文件分析提示词模板
# 使用 [file content begin/end] 标记文件内容

[file name]: 季度销售报告.pdf
[file content begin]
2026年Q1总营收1.2亿元，同比增长23%。
华东区占比45%，华北区占比30%，华南区占比25%。
明星产品A系列营收增长45%，贡献增量营收的60%。
[file content end]

请根据以上文件内容回答问题。
如果文件中没有相关信息，请直接说"根据提供的资料无法回答"。

问题：哪个区域增长最快？明星产品的贡献率是多少？

# 豆包推荐的 ### 三段式分隔符结构
# 适用于需要分步执行的复杂任务

###指令###
你需要完成以下三个任务：
1. 总结下面的文章，不超过200字
2. 提取文章中的三个核心要点
3. 基于文章内容，提出两个值得探讨的问题

###文章###
"""
[这里粘贴文章内容]
"""

###输出格式###
请按照以下格式返回结果：
总结：[你的总结内容]
核心要点：
1. [要点一]
2. [要点二]
3. [要点三]
延伸思考：
1. [问题一]
2. [问题二]

技巧 2：要求结构化输出

请从以下文本中提取关键信息，
以 JSON 格式输出，包含以下键：
- 产品名称
- 价格
- 评价数量

文本："iPhone 16 Pro 售价 7999 元，
已有 12500 条用户评价。"

技巧 3：提供条件判断和步骤

请按以下步骤处理用户消息：

1. 首先判断消息是否包含投诉内容
2. 如果包含投诉，提取投诉的具体问题
3. 如果不包含投诉，直接回复"非投诉消息"
4. 对于投诉消息，生成一条安抚性回复

用户消息："你们的产品质量太差了！
用了三天就坏了，要求退款！"

原则二：给模型充足的推理时间

判断这个学生的解答是否正确：

一个问题：一台发电机...
学生的解答：...

直接告诉我对不对。

判断这个学生的解答是否正确。

请按以下步骤：
1. 先自己重新解答这个问题
2. 然后将你的解答与学生的解答对比
3. 最后判断学生的解答是否正确

问题：...
学生解答：...

结构化提示设计

OpenAI 和 Anthropic 各自提出的结构化框架，帮助你系统性地组织提示词。

OpenAI 的推荐结构

OpenAI 官方指南推荐使用 Markdown 和 XML 标签来格式化提示，并按以下顺序组织内容：

OpenAI 结构化示例

# Identity

You are a coding assistant that helps enforce
the use of snake case variables in JavaScript code.

# Instructions

* When defining variables, use snake case names
  (e.g. my_variable) instead of camel case.
* Declare variables using the older "var" keyword.
* Do not give responses with Markdown formatting.

# Examples

<user_query>
How do I declare a string variable for a first name?
</user_query>

<assistant_response>
var first_name = "Anna";
</assistant_response>

Anthropic 的 XML 标签结构化

Anthropic（Claude）强烈推荐使用XML 标签来结构化提示，认为这能帮助模型"无歧义地解析复杂提示"：

<instructions>
你是一位专业的法律文档分析助手。
请阅读以下合同条款，提取其中的
违约责任条款，并以列表形式输出。
</instructions>

<documents>
  <document index="1">
    <source>合同A.pdf</source>
    <document_content>
    第十条 乙方如未按时交付货物...
    </document_content>
  </document>
</documents>

<question>
请列出所有违约责任条款。</question>

零样本提示 Zero-shot

入门通用 最基础的提示方式。

# 直接给指令，不给示例 — 翻译任务
请将以下中文翻译为英文，保持商务正式语气：

"感谢您提供的详细方案，我们将在内部评估后尽快回复。"

# 模型输出：
# Thank you for the detailed proposal.
# We will review it internally and reply as soon as possible.

对比：模糊指令 vs Zero-shot 清晰指令

帮我看看这段话是什么意思：
"这家餐厅服务态度很好，
就是上菜太慢了，等了40分钟。"

将以下文本分类为"正面"、"负面"或"中性"，只输出分类结果，不输出其他内容：

"这家餐厅服务态度很好，就是上菜太慢了，等了40分钟。"

少样本提示 Few-shot

入门通用 通过示例引导模型理解任务模式。

# 通过示例教模型将"描述"翻译为"一句话评论"

# 示例 1
输入：画面精美，剧情紧凑
输出：这部电影的视觉效果令人惊艳，节奏把控也十分到位。

# 示例 2
输入：演员表演自然，配乐动听
输出：演员的表演真实动人，配乐更是锦上添花。

# 示例 3
输入：打斗场面震撼，但结尾仓促
输出：动作戏确实过瘾，可惜结尾收得太急，留有遗憾。

# 实际任务
输入：台词幽默，节奏轻快
输出：

Few-shot 最佳实践（综合 OpenAI + Anthropic）

对比：Zero-shot vs Few-shot（同一任务）

将以下产品描述转换为一句营销文案：

"无线蓝牙耳机，续航 30 小时，主动降噪。"

将产品描述转换为一句营销文案。

示例：
描述：机械键盘，青轴，RGB 背光
文案：指尖跳动的节奏感，每一次敲击都是享受

描述：保温杯，316 不锈钢，24 小时保温
文案：从清晨到深夜，温度始终如初

描述：无线蓝牙耳机，续航 30 小时，主动降噪
文案：

角色设定 Role Prompting

入门通用 为模型设定角色身份，聚焦其行为和语气。

解释一下什么是机器学习。

你是一位擅长用通俗语言解释技术
概念的科普作家，面向没有技术
背景的普通读者。

请用 200 字以内解释"机器学习"，
使用生活中的类比，避免专业术语。

上下文工程 Context Engineering

进阶通用 管理提供给模型的信息，是提示词工程的核心能力。

上下文工程的三个层次

Prompt Engineering Guide 的新增章节"上下文工程指南"将上下文管理分为三个层次：

上下文工程的最佳实践

1. 相关性优先

不要把所有信息都塞给模型。OpenAI 指南强调：只提供与任务相关的信息。无关信息会分散模型注意力，降低输出质量。

2. 结构化组织

用 XML 标签或 Markdown 标题组织上下文。Anthropic 建议多文档场景使用嵌套标签：

<documents>
  <document index="1">
    <source>report_q3.pdf</source>
    <document_content>...</document_content>
  </document>
  <document index="2">
    <source>report_q4.pdf</source>
    <document_content>...</document_content>
  </document>
</documents>

请对比 Q3 和 Q4 的营收增长趋势。

3. 引用提取

Anthropic 提供了一个高级技巧：对于长文档任务，要求模型先引用文档相关部分，再执行任务：

在回答之前，请先从文档中提取并引用
与问题相关的段落，放在 <relevant_quotes>
标签中，然后基于引用内容回答。

这样可以减少幻觉，提高答案的可追溯性。

对比：无上下文 vs 有上下文

我们公司最新的退货政策是什么？

<policy>
退货政策（2026年修订版）：
1. 购买后 7 天内可无理由退货
2. 食品和定制商品不支持退货
3. 退货商品需保持原包装完好
</policy>

请根据以上政策文档回答用户问题。
如果文档中没有相关信息，请说"根据现有政策无法回答"。

用户问题：我买了一台手机，用了5天能退吗？

思维链 Chain-of-Thought (CoT)

进阶通用 引导模型逐步推理，是解决复杂问题的核心技术。

CoT 的效果对比

一个奇数数组 [15, 32, 5, 13, 82, 7, 1]
中所有奇数相加，再加上一个
偶数数组 [4, 8, 12] 的和。
最终结果是多少？

一个奇数数组 [15, 32, 5, 13, 82, 7, 1]
中所有奇数相加，再加上一个
偶数数组 [4, 8, 12] 的和。

让我们一步步思考：
第一步：找出奇数数组中的奇数...
第二步：计算奇数之和...
第三步：计算偶数数组之和...
第四步：相加得到最终结果。

CoT 的三种实现方式

方式 1：Zero-shot CoT

最简单的方式——在提示末尾加上一句触发语：

[你的问题]

# 触发语
让我们一步步思考。
# 或英文：Let's think step by step.

方式 2：Few-shot CoT

在示例中展示推理过程，让模型学习"如何分步思考"：

# 示例 1
Q: 小明有 5 个苹果，给了小红 2 个，
   又买了 3 个，现在有几个？
A: 思考过程：
   1. 小明原有 5 个苹果
   2. 给了小红 2 个：5 - 2 = 3
   3. 又买了 3 个：3 + 3 = 6
   答案：6 个

# 示例 2（类似结构）
...

# 实际问题
Q: 一辆公交车上有 20 人，
   到站下了 8 人，上了 12 人，
   现在车上有多少人？
A:

方式 3：结构化思考标签

Anthropic 推荐使用 <thinking> 和 <answer> 标签分离推理与输出：

请先在 <thinking> 标签中写出你的
推理过程，然后在 <answer> 标签中
给出最终答案。

问题：如果 A > B，B > C，C > D，
那么 A 和 D 谁大？

自我一致性 Self-Consistency

高级通用 通过多次采样取多数投票，提高推理可靠性。

# 同一问题，多次采样
for i in range(5):
    response = model.generate(
        prompt="问题 + Let's think step by step",
        temperature=0.7  # 较高温度增加多样性
    )
    answers.append(extract_answer(response))

# 取出现次数最多的答案
final_answer = most_common(answers)

对比：单次推理 vs 多次推理取多数

问题：一个班有 32 个学生，男生比女生多 4 人，男生有多少人？

让我们一步步思考。
（模型只推理一次，可能算错）

# 同一问题 + CoT，调用 5 次（temperature=0.7）
问题：一个班有 32 个学生，男生比女生多 4 人，男生有多少人？

让我们一步步思考。

# 第 1 次推理 → 答案：18
# 第 2 次推理 → 答案：18
# 第 3 次推理 → 答案：20（错误路径）
# 第 4 次推理 → 答案：18
# 第 5 次推理 → 答案：18

# 多数投票 → 最终答案：18
# 验证：32 - 4 = 28，28 / 2 = 14（女生），14 + 4 = 18（男生）✓

提示链 Prompt Chaining

进阶通用 将复杂任务拆分为多步，逐步完成。

最常见的模式：自我纠正链

Anthropic 指出，提示链最常见的模式是自我纠正（Self-correction）：

实际案例：文章创作流水线

# 步骤 1：生成大纲
请为以下主题生成一份文章大纲：
主题：人工智能在教育中的应用
要求：5 个主要部分，每部分 2-3 个要点

# 步骤 2：根据大纲写初稿
请根据以下大纲撰写一篇 1000 字的文章初稿。
大纲：[步骤 1 的输出]

# 步骤 3：审查并改进
你是一位资深编辑。请审查以下文章，
指出 3 个需要改进的地方，并给出修改建议。
文章：[步骤 2 的输出]

# 步骤 4：根据建议修改
请根据以下审查建议修改文章，
输出最终版本。
原文：[步骤 2 的输出]
建议：[步骤 3 的输出]

对比：单提示 vs 提示链（文章创作）

请为"AI 在教育中的应用"写一篇 1000 字文章，
要求：5 个部分，每部分 2-3 个要点，
语气专业但通俗，结尾要有展望，
同时检查是否有事实错误并修正。

# 步骤1：生成大纲
请为"AI 在教育中的应用"生成文章大纲，
5 个主要部分，每部分 2-3 个要点。

# 步骤2：根据大纲写初稿（将步骤1输出粘贴到此处）
请根据以下大纲撰写 1000 字文章初稿。
大纲：[步骤1的输出]

# 步骤3：审查（将步骤2输出粘贴到此处）
你是资深编辑，请审查文章，
指出 3 个需要改进的地方并给出建议。
文章：[步骤2的输出]

# 步骤4：修改定稿（将步骤2和3输出粘贴到此处）
请根据审查建议修改文章，输出最终版。
原文：[步骤2的输出]
建议：[步骤3的输出]

思维树 Tree of Thoughts (ToT)

高级通用 CoT 的升级版，探索多条推理路径并评估选择。

CoT vs ToT 对比

对比：CoT（线性）vs ToT（树状探索）

问题：用 1、3、4、6 四个数字，通过加减乘除
和括号，得到 24。

让我们一步步思考。
（如果第一步选错方向，后续推理全部浪费）

问题：用 1、3、4、6 四个数字，通过加减乘除
和括号，得到 24。

请按以下步骤思考：

步骤1 - 生成 3 种可能的第一步计算：
  路径A：（写下第一个运算）
  路径B：（写下第二个运算）
  路径C：（写下第三个运算）

步骤2 - 评估每条路径：
  路径A评估：是否有前景？为什么？
  路径B评估：是否有前景？为什么？
  路径C评估：是否有前景？为什么？

步骤3 - 从最有前景的路径继续，直到得出 24。
  如果走不通，回溯到步骤1尝试其他路径。

答案：[最终表达式] = 24

检索增强生成 RAG

高级通用 让模型"查阅资料"再回答，减少幻觉的利器。

RAG 的提示结构

<retrieved_context>
[从知识库检索到的相关文档内容]
</retrieved_context>

请基于以上检索到的上下文回答问题。
如果上下文中没有相关信息，请直接说
"根据现有资料无法回答"，不要编造。

问题：[用户的实际问题]

对比：无 RAG vs 有 RAG

问题：我们公司 2026 年第二季度的
营收增长率是多少？

（模型不了解你的私有数据，
可能编造一个看似合理的数字）

<retrieved_context>
2026 Q2 财报摘要：
总营收 3.2 亿元，同比增长 15.3%。
毛利率 42.1%，较去年同期提升 2.3 个百分点。
海外市场营收占比首次超过 30%。
</retrieved_context>

请基于以上检索到的上下文回答问题。
重要规则：
1. 只使用上下文中的信息回答
2. 如果上下文中没有相关信息，请直接说
   "根据提供的资料无法回答"
3. 不要编造或推测

问题：2026 年第二季度的营收增长率是多少？

ReAct 推理与行动

高级通用 让模型边推理边行动，与外部环境交互。

ReAct 循环

# 问题：2024年诺贝尔文学奖得主写过哪些中文小说？

Thought 1: 我需要先查找 2024 年诺贝尔文学奖得主是谁。
Action 1: Search("2024 诺贝尔文学奖得主")
Observation 1: 2024 年诺贝尔文学奖得主是韩江。

Thought 2: 韩江是韩国作家，写的是韩语小说。
            但题目问的是中文小说，我需要确认她
            是否有作品被翻译成中文。
Action 2: Search("韩江 中文译本 小说")
Observation 2: 韩江的《素食者》《人类行为》
              等已被翻译成中文出版。

Thought 3: 我现在知道了韩江的中文译本小说。
Action 3: Finish("韩江的中文译本小说包括
            《素食者》《人类行为》等")

对比：纯推理 vs ReAct（推理+行动）

问题：今天北京的空气质量指数是多少？

（模型知识有截止日期，
无法获取实时数据，只能编造或拒绝回答）

问题：今天北京的空气质量指数是多少？

请按 Thought → Action → Observation 循环思考：

Thought 1: 我需要查询今天北京的实时空气质量。
Action 1: Search("北京 今日空气质量指数")
Observation 1: [搜索引擎返回的结果]

Thought 2: 我已获取到实时数据，可以回答了。
Action 2: Finish("今天北京的空气质量指数为 [搜索结果]，
           空气质量等级为 [搜索结果]。")

# 注意：Action 中的 Search() 需要配合函数调用/工具使用功能
# 模型本身无法搜索，需要通过 API 的 function calling 实现

自我批评与自我纠正

高级通用 让模型检查和改进自己的输出。

Learn Prompting 高级课程将这类技术归类为Self-Criticism Prompting（自我批评提示），包含多种具体方法。核心思想是：让模型生成答案后，再让模型审视和改进自己的答案。

四种自我批评技术

实践案例：自我优化

# 步骤 1：生成初始回答
请回答：什么是量子计算？

# 步骤 2：让模型自我批评
请审查你刚才的回答，从以下角度评估：
1. 准确性：有没有事实错误？
2. 清晰度：普通读者能理解吗？
3. 完整性：有没有遗漏重要内容？
请指出需要改进的地方。

# 步骤 3：基于批评改进
请根据你刚才提出的改进建议，
重新写一个更好的回答。

对比：直接回答 vs 自我批评后回答

请解释什么是量子纠缠。

# 步骤1：生成初始回答
请解释什么是量子纠缠，面向普通读者。

# 步骤2：让模型自我批评（将步骤1输出粘贴到此处）
请审查你刚才的回答，从以下角度评估：
1. 准确性：有没有事实错误？
2. 清晰度：普通读者能理解吗？
3. 完整性：有没有遗漏重要内容？
4. 比喻是否恰当？
指出需要改进的地方。
你的回答：[步骤1的输出]

# 步骤3：基于批评改进（将步骤2输出粘贴到此处）
请根据你刚才提出的改进建议，
重新写一个更好的回答。
改进建议：[步骤2的输出]

迭代式提示开发

没有完美的"第一次提示"——迭代是提示词工程的核心工作流。

DeepLearning.AI 课程的"Iterative"章节传达了一个核心理念：好的提示词不是一次写成的，而是迭代出来的。吴恩达将这个过程描述为一个循环：

迭代的实际案例

假设你要让模型总结一篇技术文章的要点：

总结这篇文章。
[文章内容]

请用 3 个要点总结这篇文章，
每个要点不超过 30 字。
[文章内容]

结果太笼统，缺少具体数据。

请用 3 个要点总结这篇文章，
每个要点不超过 30 字，
必须包含文章中的关键数据。
如果文章没有数据，注明"无数据"。
[文章内容]

OpenAI 的生产级建议

OpenAI 指南针对生产环境提出了更系统的迭代管理建议：

• 构建测试套件：建立一组代表性输入和期望输出，每次修改提示后跑一遍
• 版本化管理：将提示存储在代码中，通过代码审查和部署流程管理变更
• 固定模型快照：生产应用固定到特定模型版本（如 gpt-4.1-2025-04-14）以确保一致行为
• 分阶段发布：使用功能标志逐步推送提示变更

五大应用场景

DeepLearning.AI 课程的核心实践——掌握这五大场景，覆盖大部分日常需求。

场景一：文本摘要 Summarizing

你的任务是生成一段简短的摘要。

请将以下用三重引号包裹的产品评论，
总结为一句话，聚焦于"产品质量"方面。

评论："""
我买了这台搅拌机已经三个月了...
"""

场景二：信息推断 Inferring

请从以下评论中推断：
1. 情感倾向（正面/负面/中性）
2. 提到的产品特征列表
3. 是否包含购买建议

以 JSON 格式输出。

评论："这款耳机的降噪效果一流，
戴久了也不夹耳朵，强烈推荐！"

场景三：文本转换 Transforming

请将以下中文翻译为英文，
语气保持正式商务风格，
并纠正可能的语法错误：

原文："我们希望能跟贵司进一步探讨
合作的可能性，期待您的回复。"

场景四：内容扩展 Expanding

你是一位客户服务专员。
请根据以下客户反馈，
写一封回复邮件。

要求：
- 语气：专业、热情、有同理心
- 长度：150-200 字
- 结构：感谢反馈 → 回应问题 → 解决方案 → 表达期待
- 如果是投诉，先道歉再给方案

客户反馈："收到的商品有破损，
客服电话一直打不通。"

场景五：聊天机器人 Chatbot

# 系统提示（设定角色和行为规则）
你是"OrderBot"，一家披萨店的自动
接单机器人。你的职责是：

1. 热情问候顾客
2. 收集订单信息（披萨尺寸、配料、饮料）
3. 确认订单和配送地址
4. 回答关于菜单的问题
5. 始终保持礼貌和专业

如果顾客问了与点餐无关的问题，
委婉地将话题引回订单。

# 对话历史会自动维护
# 每轮将 system + history + new user message 一起发送

安全与伦理

Learn Prompting 课程特别强调的安全意识——负责任地使用提示词工程。

幻觉 Hallucination

请基于以下提供的文档回答问题。

重要规则：
1. 只使用文档中的信息回答
2. 如果文档中没有相关信息，
   请直接说"根据提供的资料无法回答"
3. 不要编造或推测
4. 引用你使用的文档段落

文档：[相关文档]
问题：[用户问题]

偏见 Bias

对抗性提示 Adversarial Prompting

Prompt Engineering Guide 专门设置了"风险和误用"章节，涵盖三类安全风险：

不同模型的差异化提示

OpenAI 和 Anthropic 各自的指南揭示了不同模型需要不同的提示策略。

GPT 模型 vs 推理模型

OpenAI 官方指南明确区分了两类模型的提示策略：

Claude 的独特之处

Anthropic 指南揭示了 Claude 模型的几个特点：

1. 对清晰度的极高要求

Claude 被比作"聪明但缺乏背景的新员工"——你解释得越精确，结果越好。模糊的指令效果会明显变差。

2. 自适应思考

Claude 新一代模型（Claude 3.5+）使用自适应思考，模型自动决定何时推理、推理多少。不需要手动加"Let's think step by step"，模型会自行判断。通过 effort 参数控制思考力度。

3. 预填充技巧

预填充（Prefilling）是指在 assistant 消息中提供部分内容，让模型从该内容开始续写。这在旧版 Claude 中可用于控制输出格式（如强制以 JSON 开头）。新版 Claude 推荐改用 XML 格式指示器控制输出格式。详见 Anthropic Prefilling 指南。

4. 对"think"一词敏感

有趣的是，Anthropic 指出某些 Claude 模型对"think"一词特别敏感。当扩展思考禁用时，建议使用"consider""evaluate""reason through"等替代词。

格式控制技巧

Anthropic 提供了四种有效的格式控制方法：

# 1. 告诉做什么，而非不做什么
# ❌ "Do not use markdown"
# ✅ "Your response should be composed of
#     smoothly flowing prose paragraphs."

# 2. 使用 XML 格式指示器
Write the prose sections in
<smoothly_flowing_prose_paragraphs> tags.

# 3. 匹配提示风格到期望输出
# 提示中少用 markdown，输出中的 markdown 也会减少

# 4. 为特定格式使用详细提示
# 用大段指令精确描述格式要求

图像与视频生成提示词

进阶通用 从文本生成图像和视频的提示词写作方法——多模态 AI 时代的必备技能。

随着 DALL·E、GPT Image、Sora、Midjourney 等模型的发展，图像生成（Text-to-Image）和视频生成（Text-to-Video）已成为提示词工程的重要领域。与文本生成不同，图像和视频提示词需要描述视觉元素而非逻辑推理。本章综合 OpenAI 官方图像生成指南、Sora 视频生成指南和 OpenAI Cookbook 的最佳实践，提炼通用方法论。

一、图像生成提示词技巧

图像提示词的五大要素

对比：模糊描述 vs 精确描述

画一只猫在窗边。

一只橘色虎斑猫蜷缩在木质窗台上，
阳光从左侧窗户洒入形成温暖逆光。
水彩画风格，柔和色调，
特写构图，背景虚化的绿色植物。

[主体描述], [风格], [构图], [光线], [细节/色调]

# 实例：
一只穿着围裙的熊猫厨师在厨房里拉面，
吉卜力动画风格，中景构图，
温暖的室内灯光，蒸汽缭绕，
暖色调，木质厨房背景。

图像生成的进阶技巧

• 多轮迭代：先生成初版，再通过追加指令微调（如"把风格改为写实""去掉背景中的植物"）
• 参考图片：提供参考图让模型学习风格或内容（如"生成一个包含参考图中所有物品的礼篮"）
• 质量等级：草稿迭代用 low 质量（快速），最终成品用 high 质量
• 遮罩编辑：用遮罩指定需要修改的区域，保持其余部分不变
• 文字渲染：如需图中包含文字，在提示词中用引号明确标注（如标签上写着 "Relax & Unwind"）

二、视频生成提示词技巧

视频提示词的五大核心要素

对比：缺少要素 vs 五要素齐全

拍一个关于咖啡的视频。

特写镜头：一杯冒着热气的咖啡放在木桌上，
晨光透过百叶窗洒下，柔和景深。
（Shot Type: Close-up | Subject: 咖啡杯 |
Action: 冒热气 | Setting: 木桌 |
Lighting: 百叶窗晨光）

[镜头类型] of [主体], [动作], [场景], [光线].

# 实例 1（风景）：
广角跟踪镜头：一辆青色跑车行驶在沙漠公路上，
热浪可见，头顶烈日。

# 实例 2（人物）：
特写镜头：一个孩子在草地上放红色风筝，
黄金时刻阳光，镜头缓慢向上摇。

# 实例 3（微距）：
缓慢推轨镜头：穿行于蓝色暮光下的微缩纸城市，
柔和雾气，窗户灯光闪烁亮起。

视频生成的进阶技巧

• 角色引用：使用角色功能时，必须在提示词中逐字提及角色名称，仅传递角色 ID 不足以保持一致性
• 视频扩展：扩展时描述场景如何继续发展（如"镜头升过屋顶，展现日出"），每次最多扩展 20 秒
• 视频编辑：每次编辑仅做一个明确定义的改动（如"将怪物颜色改为橙色"），小步迭代比大改更可靠
• 色调控制：可通过编辑指令调整整体色调（如"将色调转换为青色、沙色和锈色，带暖色背光"）
• 模型选择：快速迭代用 sora-2，高分辨率电影级素材用 sora-2-pro

OpenAI Cookbook 实践指南

OpenAI 官方示例与指南集合，覆盖提示工程、Agent 开发、RAG、函数调用、评估、多模态等 98 篇文章。提炼核心方法论与可直接运行的代码示例。

什么是 OpenAI Cookbook

定位：不是 API 文档，而是"实战经验手册"——每个示例都围绕一个具体场景，给出完整代码、关键参数和避坑指南。

核心理念：评估驱动开发（Eval-driven Development）。先建立评估基准，再写提示/构建 Agent，然后迭代优化。

主题分类速览

按 2026 年 7 月内容整理，覆盖 11 大主题：

一、提示工程最佳实践

Cookbook 中提示工程内容最丰富，核心不是"背诵技巧"，而是"按模型特性写提示"。

1. 不同模型，不同提示策略

2. 评估驱动的提示优化

不要凭感觉改提示。Cookbook 推荐的流程是：

1. 建立可重复的评估集（输入+期望输出+评分标准）
2. 用 baseline 提示跑一遍，得到初始分数
3. 每次只改一个变量，对比分数变化
4. 用 Codex 或优化器自动修复提示

3. 提示迁移与缓存

从旧模型迁移到新模型时，模型行为会变化。Cookbook 建议：

• 用 Prompt Migration Guide 系统迁移
• 用 Prompt Caching 201 降低重复前缀的延迟和成本
• 用 Prompt Personalities 统一品牌风格

二、Agent 开发

Agent 是 Cookbook 当前最活跃的领域，核心框架是 OpenAI Agents SDK。

1. Agent 改进闭环

Cookbook 推荐的 Agent 生产流程：

Traces（追踪） → Evals（评估） → Codex（修复） → 重新部署 → 回到 Traces

Traces 记录 Agent 每一步思考、工具调用和输出；Evals 用量化指标评估效果；Codex 根据失败案例自动修复代码或提示。

2. 记忆与沙箱

可靠 Agent 需要两个基础：

• 长期记忆：跨会话保留关键信息，支持只读/只生成/多轮分组模式。
• 沙箱执行：在隔离环境（Docker、E2B、Daytona 等）中运行 Agent，避免直接操作生产环境。

3. 代码示例：最简文本 Agent

from agents import Agent, Runner

agent = Agent(
    name="Assistant",
    instructions="You are a helpful assistant"
)

result = Runner.run_sync(agent, "Write a haiku about recursion.")
print(result.final_output)

三、RAG 与文件搜索

Cookbook 把 RAG 简化为"让模型能读取外部文档"。

1. 用 File Search 做 PDF RAG

Responses API 内置 File Search 工具，不需要自己搭建向量数据库：

from openai import OpenAI
client = OpenAI()

response = client.responses.create(
    model="gpt-5.5",
    input="这篇论文的核心贡献是什么？",
    tools=[{
        "type": "file_search",
        "vector_store_ids": ["vs_xxx"]
    }]
)

2. 图像理解 + RAG

上传带图文 PDF 或图片，用 File Search + Vision 做跨模态检索。适合发票、说明书、设计稿等场景。

3. 自建 Embeddings 检索

对于需要完全控制的场景，用 text-embedding-3 模型生成向量，存入 Pinecone/Milvus/PostgreSQL 等向量库，再检索注入提示。

四、函数调用与结构化输出

把模型输出变成可编程数据，是落地应用的关键。

1. 结构化输出

response = client.responses.create(
    input=[{"role": "user", "content": "提取订单信息"}],
    model="gpt-5.5",
    text={"format": {"type": "json_object"}}
)

更严格的做法是传 JSON Schema，让模型按 schema 生成字段。

2. 多工具编排

Responses API 可以在一次请求中协调多个工具：Web Search、File Search、自定义函数。模型会自动决定调用哪个工具、传递什么参数。

3. MCP 工具

MCP（Model Context Protocol）让 Agent 连接外部服务（GitHub、Slack、数据库等）。Cookbook 有专门指南讲解 Responses API 的 MCP Tool 用法。

五、评估（Evals）

评估是 Cookbook 反复强调的核心能力，没有评估就没有可靠系统。

1. 为什么需要评估

提示改了之后，"感觉更好"不可靠。必须量化：准确率、召回率、幻觉率、成本、延迟。Cookbook 推荐把评估做成 CI 的一部分。

2. 宏观评估（Macro Evals）

对 Agent 系统来说，单条用例评估不够，需要端到端场景评估：Agent 是否完成了用户目标？是否走了不必要的步骤？是否安全合规？

3. 推荐工具

• OpenAI Evals：官方框架，适合结构化评估
• Promptfoo：社区推荐，适合提示对比和回归测试
• Langfuse：与 Agent 追踪结合，做在线评估

六、多模态：图像、音频、视频

Cookbook 的多模态内容越来越丰富，核心是把"文本提示技巧"扩展到其他模态。

1. 图像生成提示

核心要素：主体、细节、风格、光线、构图、镜头。Cookbook 推荐先写简短提示，再逐步添加细节，而不是一开始写大段。

2. 视觉理解

上传图片或 Base64，让模型回答图片内容。关键技巧：在提示中明确告诉模型要关注什么、按什么格式输出。

3. 语音与实时

Whisper 做转写和翻译，Realtime API 做低延迟语音对话。Cookbook 比较了不同语音转文字方法的优劣。

七、核心代码示例

示例 1：评估驱动提示优化

import json

# 1. 定义评估集
examples = [
    {"input": "...", "expected": "..."},
]

# 2. 定义评分函数
def score(output, expected):
    return output.strip() == expected.strip()

# 3. 循环：改提示 → 跑评估 → 看分数
for prompt_version in prompt_versions:
    total = sum(score(run(prompt_version, ex["input"]), ex["expected"]) for ex in examples)
    print(f"{prompt_version}: {total}/{len(examples)}")

示例 2：带工具调用的 Agent

from agents import Agent, function_tool, Runner

@function_tool
def get_weather(city: str) -> str:
    return f"{city} 今天晴天，25°C"

agent = Agent(
    name="WeatherBot",
    instructions="你是天气助手，需要时调用 get_weather。",
    tools=[get_weather]
)

result = Runner.run_sync(agent, "杭州天气如何？")
print(result.final_output)

学习路径建议

OpenAI 热门开源项目精选

按 GitHub Star 数量排序，精选 5 个 OpenAI 官方最热门的开源项目。每个项目分别标注适合初学者和进阶者的学习点。

1. Whisper — 通用语音识别模型

import whisper

model = whisper.load_model("turbo")
result = model.transcribe("audio.mp3")
print(result["text"])

2. Codex — 终端编程 Agent

# 安装
npm install -g @openai/codex

# 在终端中直接下达任务
codex "重构 utils.py 中的错误处理逻辑"

# 诊断安装状态
codex doctor

3. openai-cookbook — 官方示例与最佳实践

1. GPT-4.1 Prompting Guide
2. Introduction to Structured Outputs
3. Doing RAG on PDFs using File Search
4. Build an Agent Improvement Loop with Traces, Evals, and Codex

4. openai-python — 官方 Python SDK

from openai import OpenAI

client = OpenAI()

response = client.responses.create(
    model="gpt-5.5",
    input="用一句话总结递归。"
)
print(response.output_text)

5. openai-agents-python — 多智能体框架

from agents import Agent, Runner

agent = Agent(
    name="Assistant",
    instructions="You are a helpful assistant"
)

result = Runner.run_sync(agent, "写一首关于递归的俳句。")
print(result.final_output)

学习建议

工作流与智能体实践

高级通用 从提示词技术到系统架构——掌握工作流与智能体的设计模式，构建可生产的 AI 应用。

前面的章节（提示链、ReAct、RAG）教你的是提示词层面的技术。当任务复杂到需要多个步骤协同、多个模型分工、或让模型自主决策时，就需要从"提示词工程"升级到"系统架构设计"。本章整合八大权威知识来源，从概念选型到企业实战，构建完整的"概念→选型→设计→实战→生产化→学习路径"闭环。

零、快速上手：5 分钟搭建第一个工作流

理论先放一边，动手感受一下。以下三条路径从零代码到代码框架，选择适合你的方式立即开始：

🟢 路径 A：用扣子 Coze 搭建文章生成工作流（零代码，5 分钟）

🟡 路径 B：用 Dify 搭建知识库问答（Docker 部署，30 分钟）

🔴 路径 C：用 LangGraph 搭建带条件路由的状态图（Python，需编程基础）

pip install langgraph langchain-openai

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

# 1. 定义状态（所有节点共享的数据结构）
class State(TypedDict):
    messages: Annotated[list, operator.add]

# 2. 定义节点函数（每个节点接收状态、返回状态更新）
def classify(state: State) -> State:
    # 实际项目中这里调用 LLM 做意图分类
    return {"messages": ["已分类"]}

def handle_refund(state: State) -> State:
    return {"messages": ["退款处理完成"]}

def handle_tech(state: State) -> State:
    return {"messages": ["技术支持完成"]}

# 3. 定义路由函数（决定下一步走向哪个节点）
def route(state: State) -> str:
    last = state["messages"][-1].lower()
    if "refund" in last: return "refund"
    if "tech" in last: return "tech"
    return END

# 4. 构建状态图：节点 + 边 + 条件路由
workflow = StateGraph(State)
workflow.add_node("classify", classify)
workflow.add_node("refund", handle_refund)
workflow.add_node("tech", handle_tech)
workflow.set_entry_point("classify")
workflow.add_conditional_edges("classify", route)
workflow.add_edge("refund", END)
workflow.add_edge("tech", END)

# 5. 编译并运行
app = workflow.compile()
result = app.invoke({"messages": ["我要退款"]})
print(result)  # {'messages': ['我要退款', '已分类', '退款处理完成']}

一、核心概念：工作流 vs 智能体 🟢 入门

任务：将用户输入的邮件翻译成英文

# 错误做法：用自主 Agent 处理简单任务
# Agent 自主决策调用翻译工具、检查工具、修正工具...
# 成本高、延迟大、结果不可控

# 正确做法：单次 LLM 调用即可
请将以下邮件翻译成英文，保持商务语气：
[邮件内容]

# 层级1：单次调用（90%的简单任务）
翻译邮件 → 直接调用 LLM

# 层级2：提示链工作流（需要分步的任务）
写文章 → 先生成大纲 → 检查大纲 → 写正文 → 审查

# 层级3：自主 Agent（开放式、不可预测步骤的任务）
"帮我研究竞品的定价策略并生成分析报告"
→ Agent 自主搜索、分析、判断是否需要更多信息

二、平台工具全景图 🟢 入门

工作流与智能体的实现不限于一种方式——从零代码可视化平台到纯代码框架，各有适用场景。以下六大平台/工具覆盖从入门到生产全链路：

三、工作流设计模式 🟡 进阶

Anthropic 从生产级项目中提炼出五种可组合的工作流模式，按复杂度递增排列。以下每种模式均增加适用场景、平台映射和生产注意事项，帮助你不仅理解概念，更能落地实施。

模式 1：提示链（Prompt Chaining）

将任务分解为顺序步骤，每步 LLM 调用处理前一步的输出。可在中间添加程序化检查点（gate）确保流程不跑偏。本指南第 15 章已介绍提示词层面的提示链，这里强调的是系统层面的编排——加入代码逻辑做检查和路由。

# 系统层面提示链示例（伪代码）
# 步骤1：生成大纲
outline = llm("为'{topic}'生成文章大纲，5个部分")

# 检查点（gate）：验证大纲质量
if not has_required_sections(outline):
    outline = llm("补充缺失部分到大纲: {outline}")

# 步骤2：基于大纲写正文
draft = llm("根据大纲写1000字文章: {outline}")

# 步骤3：审查
review = llm("审查文章，指出3个改进点: {draft}")

# 步骤4：修改定稿
    final = llm("根据审查建议修改: {draft} 建议: {review}")

📋 生产注意：检查点阈值需调优（太严导致频繁重试，太松导致质量下降）；设置超时和最大重试次数；缓存中间结果以便故障恢复。

模式 2：路由分发（Routing）

对输入分类，导向专门的后续处理。实现关注点分离——为不同类型输入构建专用提示，避免"一个提示搞定所有"导致的性能下降。

# 路由分发工作流示例（伪代码）
# 步骤1：分类用户输入
category = llm("将用户查询分类为: general/refund/tech/support\n查询: {user_input}")

# 步骤2：根据分类路由到专用处理
if category == "refund":
    result = llm("你是退款专员，处理退款请求: {user_input}")
elif category == "tech":
    result = llm("你是技术支持，诊断技术问题: {user_input}")
elif category == "support":
    # 简单问题用小模型（成本低、速度快）
    result = llm_haiku("回答常见问题: {user_input}")
else:
    result = llm("通用客服回答: {user_input}")

📋 生产注意：设置分类置信度阈值，低于阈值的走兜底路由；为新类别预留扩展入口；简单问题用小模型降低成本。

模式 3：并行化（Parallelization）

多个 LLM 同时处理任务，输出以程序化方式聚合。两种变体：分区（拆分为独立子任务并行）和投票（同一任务运行多次取多数/最优）。

# 并行化工作流示例（伪代码）
# 分区：同时从不同维度审查代码
security_review = llm("从安全角度审查代码: {code}")
performance_review = llm("从性能角度审查代码: {code}")
style_review = llm("从代码风格角度审查: {code}")

# 聚合结果
final_review = merge(security_review, performance_review, style_review)

# 投票变体：同一任务多次运行取多数
answers = [llm("解决数学问题: {problem}") for _ in range(5)]
final_answer = majority_vote(answers)

📋 生产注意：控制并发数避免 API 限流；设置单个子任务超时；投票模式需奇数次调用避免平局。

模式 4：编排者-工作者（Orchestrator-Workers）

一个中央 LLM 动态分解任务，委派给工作者 LLM，再综合结果。与并行化的区别：子任务不是预定义的，而是编排者根据输入动态决定。

# 编排者-工作者工作流示例（伪代码）
# 编排者：分析任务，动态决定需要修改哪些文件
plan = llm_orchestrator("""
任务：为项目添加用户登录功能
当前文件结构：{file_tree}
请决定需要修改哪些文件，以及每个文件的具体改动
""")

# 工作者：并行执行各文件的修改
changes = []
for file_task in plan.tasks:
    change = llm_worker(f"修改文件 {file_task.path}: {file_task.instruction}")
    changes.append(change)

# 编排者：综合所有修改
final_result = llm_orchestrator("综合以下修改: {changes}")

📋 生产注意：子任务错误隔离（一个失败不影响其他）；部分失败时的合并策略；编排者需设定最大子任务数防止失控。

模式 5：评估者-优化者（Evaluator-Optimizer）

一个 LLM 生成响应，另一个 LLM 评估并反馈，循环迭代直到满足标准。类似人类作家反复打磨文档的过程。本指南第 19 章的"自我批评"是此模式的提示词层面实现。

# 评估者-优化者工作流示例（伪代码）
translation = llm("翻译这段文字为英文: {source_text}")

for iteration in range(max_iterations):
    # 评估者：审查翻译质量
    feedback = llm_evaluator("""
    审查翻译质量，从以下角度评估：
    1. 准确性：有无误译
    2. 流畅性：是否符合英文表达习惯
    3. 语气：是否保留了原文语气
    翻译: {translation}
    原文: {source_text}
    如果需要改进，指出具体问题。
    """)

    if feedback.is_satisfied:
        break  # 质量达标，退出循环

    # 优化者：根据反馈改进
    translation = llm("根据反馈改进翻译: {translation}\n反馈: {feedback}")

📋 生产注意：评估标准需量化（如"准确率≥95%"而非"足够好"）；设置最大迭代次数（通常 3-5 次）；记录每轮迭代的改进幅度用于分析收益递减点。

四、智能体设计模式 🟡 进阶

工作流模式解决的是"步骤可预测"的任务，而智能体（Agent）解决的是"步骤不可预测"的开放式任务。以下五种 Agent 设计模式覆盖从简单工具调用到复杂多 Agent 协作的完整谱系：

模式 1：ReAct（推理 + 行动循环）

本指南第 18 章介绍了 ReAct 的提示词层面实现，这里是系统级升级——加入安全护栏、人类检查点和最大迭代限制。Agent 在循环中自主决定下一步行动，调用工具获取环境反馈，直到任务完成或达到限制。

# 自主 Agent 循环示例（伪代码）
# 本指南第18章 ReAct 的系统级实现

max_iterations = 10
task = "研究竞品定价策略并生成分析报告"
context = ""

for i in range(max_iterations):
    # Agent 规划下一步行动
    action = llm(f"""
    任务: {task}
    已知信息: {context}
    可用工具: search(), analyze(), write_report()
    决定下一步行动（Thought + Action）
    """)

    if action.type == "finish":
        break  # Agent 认为任务完成

    # 执行工具调用，获取环境反馈
    observation = execute_tool(action.tool, action.params)

    # 更新上下文（环境反馈）
    context += f"\nAction: {action}\nObservation: {observation}"

    # 检查点：每3步请求人类确认（可选）
    if i > 0 and i % 3 == 0:
        if not human_confirm(f"Agent 计划继续: {action}"):
            break

# 安全护栏：达到最大迭代次数强制终止
if i == max_iterations - 1:
    log("Agent 达到最大迭代次数，强制终止")

模式 2：Function Calling（函数调用）

模型根据用户意图自主决定调用哪个预定义函数，并生成结构化参数。比 ReAct 更精确——函数签名约束了模型的输出格式，减少解析错误。OpenAI Responses API 原生支持。

pip install openai

from openai import OpenAI

client = OpenAI()  # 自动读取 OPENAI_API_KEY 环境变量

# 1. 定义可用函数（工具）
tools = [
    {
        "type": "function",
        "function": {
            "name": "query_order",
            "description": "查询用户订单状态",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string", "description": "订单编号"}
                },
                "required": ["order_id"]
            }
        }
    }
]

# 2. 模型自主决定调用哪个函数
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "我的订单 #12345 到哪了？"}],
    tools=tools
)

# 3. 模型返回 tool_calls（不是直接回答，而是要求调用函数）
tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name)       # "query_order"
print(tool_call.function.arguments)  # '{"order_id": "12345"}'

# 4. 执行函数，将结果返回给模型生成最终回答
def query_order(order_id):
    # 实际项目中这里查询数据库
    return {"status": "已发货", "eta": "明天送达"}

result = query_order("12345")
final = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "user", "content": "我的订单 #12345 到哪了？"},
        response.choices[0].message,
        {"role": "tool", "tool_call_id": tool_call.id, "content": str(result)}
    ]
)
print(final.choices[0].message.content)
# "您的订单 #12345 已发货，预计明天送达。"

模式 3：多 Agent 协作（Handoff 交接）

多个专业 Agent 分工协作，通过 Handoff（交接）机制传递控制权。OpenAI Agents SDK 的核心特性——一个 Agent 可以将任务交接给另一个更专业的 Agent。

# 多 Agent 协作示例（伪代码，基于 OpenAI Agents SDK）
from agents import Agent, Runner

# 定义三个专业 Agent
triage_agent = Agent(
    name="客服分诊",
    instructions="分析用户意图，决定交接给哪个专业 Agent",
    handoffs=["退款专员", "技术支持"]
)

refund_agent = Agent(
    name="退款专员",
    instructions="处理退款相关请求，查询订单状态，发起退款流程",
    tools=[query_order, refund_order]
)

tech_agent = Agent(
    name="技术支持",
    instructions="诊断技术问题，提供解决方案或创建工单",
    tools=[search_kb, create_ticket]
)

# 分诊 Agent 根据用户输入自动交接
result = Runner.run(triage_agent, "我的订单 #12345 想退款")
# 分诊 Agent → 交接给 退款 Agent → 退款 Agent 处理并返回结果

模式 4：层级编排（Supervisor）

一个 Supervisor Agent 统一调度多个子 Agent，子 Agent 完成任务后向 Supervisor 汇报。LangGraph 的经典模式——适合企业级客服路由、复杂任务分解。

# Supervisor 层级编排示例（伪代码，基于 LangGraph）
# Supervisor 决定下一步交给哪个子 Agent
def supervisor(state):
    messages = state["messages"]
    decision = llm("根据对话历史，决定下一步交给谁: researcher / coder / reviewer")
    return {"next": decision}

# 子 Agent 各自处理专业任务
def researcher(state):
    result = llm("搜索并整理相关信息: " + state["task"])
    return {"messages": [result]}

def coder(state):
    result = llm("编写代码实现: " + state["task"])
    return {"messages": [result]}

# 状态图编排：Supervisor → 子 Agent → 回到 Supervisor
graph = StateGraph()
graph.add_node("supervisor", supervisor)
graph.add_node("researcher", researcher)
graph.add_node("coder", coder)
graph.add_conditional_edges("supervisor", route_to_sub_agent)
graph.add_edge("researcher", "supervisor")  # 完成后回到 Supervisor
graph.add_edge("coder", "supervisor")

模式 5：记忆增强

为 Agent 添加短期记忆（当前对话上下文）和长期记忆（跨会话的用户偏好、历史交互），实现个性化服务。LangMem 和 Dify Memory 提供现成实现。

# 记忆增强 Agent 示例（伪代码）
# 短期记忆：当前对话上下文（自动管理）
short_term = ConversationBuffer(max_tokens=4000)

# 长期记忆：用户偏好和历史（持久化存储）
long_term = MemoryStore(backend="vector_db")

# 每次对话前检索相关长期记忆
def agent_with_memory(user_input, user_id):
    # 检索与当前输入相关的历史记忆
    relevant_memories = long_term.search(
        query=user_input,
        filter={"user_id": user_id},
        top_k=3
    )

    # 将短期记忆 + 长期记忆 + 用户输入组合
    context = f"""
    用户偏好: {relevant_memories}
    对话历史: {short_term.get_history()}
    当前输入: {user_input}
    """

    response = llm(context)

    # 提取值得记住的信息存入长期记忆
    if has_new_preference(user_input, response):
        long_term.add(user_id, extract_preference(response))

    short_term.add(user_input, response)
    return response

五、企业实战场景 🔴 高级

以下四个场景来源于各平台官方文档和公开案例，覆盖客服、知识库、文档处理和合规审查四大企业高频需求。每个场景包含业务背景、架构设计和关键生产指标。

场景 1：智能客服系统

📋 生产指标：首次解决率（FCR）> 60%、转人工率 < 20%、平均响应时间 < 3 秒、用户满意度 > 85%。推荐平台：快速验证用 Coze，企业部署用 Dify（支持人工审核节点），需审计用 LangGraph。

场景 2：知识库检索智能体

📋 生产指标：回答准确率 > 90%、检索召回率 > 85%、合规通过率 100%、平均检索时间 < 2 秒。推荐平台：Dify（知识库 + Agent 节点 + 人工审核），LangGraph（条件边硬护栏 + Checkpointer 审计）。

场景 3：文档处理流水线

📋 生产指标：字段完整率 > 95%、处理效率提升 5-10 倍、人工审核通过率 > 90%。推荐平台：Dify（Workflow + 人工介入节点 + 可观测性），Coze（工作流 + 插件）。

场景 4：合规审查 Agent

📋 生产指标：合规率 100%、审计追踪完整性 100%、审查效率提升 3-5 倍。推荐平台：LangGraph（状态图 + 条件边 + Checkpointer 全链路审计），Dify（条件分支 + 人工审核）。

六、生产化工程要点 🔴 高级

从"能跑的 Demo"到"可靠的生产系统"，需要关注以下六大工程要点。这些要点决定了 AI 应用能否真正在企业环境中稳定运行：

七、工作流与智能体学习路线 📚 参考

从零开始掌握工作流与智能体，建议按以下 4 周进阶路径学习，每周一个平台，逐步深入：

八、权威资源汇总 📚 参考

九、ACI：智能体-计算机接口设计 📚 参考

Anthropic 提出的核心观点：像重视人机交互（HCI）一样重视 Agent 与计算机之间的接口（ACI）设计。工具定义的质量比提示词优化更重要——他们在构建 SWE-bench Agent 时，花在工具优化上的时间比提示词还多。

术语表

学习中遇到的专业术语速查。

速查表与学习路径

快速参考与下一步学习建议。

提示词工程速查表

推荐学习路径

权威学习资源链接