Add Milky note: [Milky] 为您整理《讲透《Agentic design patterns》系列（1/21）：别再用长提示词了，10
This commit is contained in:
Zane
@@ -0,0 +1,206 @@
|
||||
# Prompt Chaining（提示词链）模式实战指南
|
||||
|
||||
## 核心概念：什么是 Prompt Chaining
|
||||
|
||||
**Prompt Chaining（提示词链）** 的本质是**将大任务拆解为串行步骤（Pipeline）**，上一步的产出直接作为下一步的输入。
|
||||
|
||||
**工厂装配线类比**：想象一个工厂的生产流程——拧螺丝的工位完成后，半成品直接滑向喷漆工位，再流向质检工位。而不是让一个工人同时负责拧螺丝、喷漆和质检。提示词链遵循同样的逻辑：每个步骤专注于单一职责，通过标准化接口传递中间产物。
|
||||
|
||||
## 为什么单 Prompt 搞不定复杂任务
|
||||
|
||||
当试图用单个超长 Prompt 解决复杂任务时，模型会出现**五类典型失效模式**：
|
||||
|
||||
1. **上下文稀释（Context Dilution）**：过长的指令导致模型注意力分散，忽略关键约束条件
|
||||
2. **逻辑纠缠（Logic Entanglement）**：多步骤推理相互干扰，前一步的错误在后续被放大
|
||||
3. **输出格式不稳定**：同时要求模型完成分析、推理、格式化输出，导致结构混乱
|
||||
4. **调试困难**：无法定位问题出现在哪个推理环节
|
||||
5. **Token 效率低下**：重复处理相同的上下文背景信息
|
||||
|
||||
## 7 个高频应用场景与流水线设计
|
||||
|
||||
### 场景 1：文档生成流水线
|
||||
**步骤拆解**：
|
||||
1. **大纲生成**：根据主题生成结构化大纲（Markdown 格式）
|
||||
2. **内容填充**：针对每个章节标题生成详细内容
|
||||
3. **风格润色**：统一语气、优化表达、检查一致性
|
||||
4. **格式校验**：验证最终输出是否符合模板要求
|
||||
|
||||
### 场景 2：代码审查与修复
|
||||
**步骤拆解**：
|
||||
1. **静态分析**：识别潜在 Bug、安全漏洞、性能瓶颈（输出问题清单 JSON）
|
||||
2. **修复建议**：针对每个问题生成具体修复代码
|
||||
3. **代码重构**：优化可读性和可维护性
|
||||
4. **测试生成**：为修复后的代码生成单元测试用例
|
||||
|
||||
### 场景 3：数据分析报告
|
||||
**步骤拆解**：
|
||||
1. **数据理解**：分析原始数据结构，识别字段类型和分布（输出数据画像）
|
||||
2. **洞察发现**：基于数据画像执行统计分析，发现趋势和异常
|
||||
3. **可视化建议**：生成图表配置代码（Matplotlib/Plotly）
|
||||
4. **报告撰写**：将数据洞察转化为业务语言，生成 executive summary
|
||||
|
||||
### 场景 4：客服对话处理
|
||||
**步骤拆解**：
|
||||
1. **意图识别**：分类用户问题类型（退款/技术支持/账户问题）
|
||||
2. **信息抽取**：从对话历史中提取关键实体（订单号、产品型号）
|
||||
3. **方案生成**：基于知识库生成解决方案草稿
|
||||
4. **语气校准**：根据用户情绪调整回复的礼貌程度和详细程度
|
||||
|
||||
### 场景 5：法律合同审查
|
||||
**步骤拆解**：
|
||||
1. **条款提取**：识别关键条款（违约责任、保密协议、争议解决）
|
||||
2. **风险标记**：对照法规库标记高风险条款（输出风险评级）
|
||||
3. **条款对比**：与标准模板对比，指出缺失或不合理条款
|
||||
4. **修订建议**：生成具体的条款修改建议书
|
||||
|
||||
### 场景 6：学术论文辅助
|
||||
**步骤拆解**：
|
||||
1. **文献摘要**：将多篇论文摘要压缩为核心观点矩阵
|
||||
2. **研究缺口识别**：分析现有研究的空白点
|
||||
3. **方法论设计**：针对研究问题设计实验方案
|
||||
4. **引用格式化**：将参考文献转换为指定格式（APA/MLA）
|
||||
|
||||
### 场景 7：多语言内容本地化
|
||||
**步骤拆解**：
|
||||
1. **初译**：直译源语言内容
|
||||
2. **文化适配**：识别文化特定梗、俚语，进行本地化转换
|
||||
3. **术语一致性检查**：确保专业术语在全文中统一
|
||||
4. **本地合规审查**：检查内容是否符合目标地区的法规要求
|
||||
|
||||
## 代码实战：LangChain LCEL 实现两步链
|
||||
|
||||
使用 **LangChain Expression Language (LCEL)** 可以简洁地实现 Prompt Chaining：
|
||||
|
||||
```python
|
||||
from langchain_openai import ChatOpenAI
|
||||
from langchain_core.prompts import ChatPromptTemplate
|
||||
from langchain_core.output_parsers import StrOutputParser
|
||||
|
||||
# 初始化模型
|
||||
llm = ChatOpenAI(model="gpt-4", temperature=0)
|
||||
|
||||
# 第一步：生成大纲
|
||||
outline_prompt = ChatPromptTemplate.from_template(
|
||||
"为以下主题生成详细的文章大纲，使用Markdown格式：\n主题：{topic}"
|
||||
)
|
||||
outline_chain = outline_prompt | llm | StrOutputParser()
|
||||
|
||||
# 第二步：基于大纲生成内容
|
||||
content_prompt = ChatPromptTemplate.from_template(
|
||||
"基于以下大纲撰写详细内容，要求专业且易懂：\n大纲：{outline}"
|
||||
)
|
||||
content_chain = content_prompt | llm | StrOutputParser()
|
||||
|
||||
# 组合链：使用 pipe 操作符串联
|
||||
full_chain = {"outline": outline_chain} | content_chain
|
||||
|
||||
# 执行
|
||||
result = full_chain.invoke({"topic": "Prompt Chaining 设计模式"})
|
||||
print(result)
|
||||
```
|
||||
|
||||
**关键语法解析**：
|
||||
- `|` 操作符：将上游组件的输出作为下游组件的输入
|
||||
- `{"outline": outline_chain}`：显式映射，将第一步的输出命名为 `outline` 传递给第二步
|
||||
- 隐式传递：如果下游 Prompt 的变量名与上游输出匹配，可自动映射
|
||||
|
||||
### 多步链与状态管理
|
||||
|
||||
对于需要保留上下文的复杂流程：
|
||||
|
||||
```python
|
||||
from langchain_core.runnables import RunnablePassthrough
|
||||
|
||||
# 三步链示例：提取 → 分析 → 总结
|
||||
extract_chain = (
|
||||
ChatPromptTemplate.from_template("从文本中提取关键数据点：{text}")
|
||||
| llm
|
||||
| StrOutputParser()
|
||||
)
|
||||
|
||||
analyze_chain = (
|
||||
ChatPromptTemplate.from_template("分析以下数据点并提供洞察：{data}")
|
||||
| llm
|
||||
| StrOutputParser()
|
||||
)
|
||||
|
||||
# 保留原始文本的同时传递中间结果
|
||||
combined_chain = (
|
||||
{
|
||||
"data": extract_chain,
|
||||
"original_text": RunnablePassthrough() # 透传原始输入
|
||||
}
|
||||
| analyze_chain
|
||||
)
|
||||
```
|
||||
|
||||
## 上下文工程与避坑指南
|
||||
|
||||
### 什么时候必须用链（Prompt Chaining）
|
||||
|
||||
| 场景特征 | 单 Prompt 风险 | 链式处理优势 |
|
||||
|---------|--------------|------------|
|
||||
| 多模态处理 | 格式混乱 | 每步专注一种输出格式 |
|
||||
| 需要外部工具调用 | 逻辑嵌套复杂 | 中间步骤可插入 API 调用 |
|
||||
| 质量门控要求 | 无法中途拦截 | 每步后可添加 validation |
|
||||
| 长文本生成（>2k tokens） | 遗忘早期约束 | 分步引用前文摘要 |
|
||||
|
||||
### 什么时候不该用链
|
||||
|
||||
1. **简单问答**：单轮即可完成的任务，拆分反而增加延迟和成本
|
||||
2. **强依赖全局上下文**：如代码全局重构，需要同时看到所有模块
|
||||
3. **实时性要求极高**：链式调用增加多次 API 往返时间（RTT）
|
||||
|
||||
### 步骤间数据传递格式规范
|
||||
|
||||
**推荐格式（防止 Pipeline 崩溃）**：
|
||||
|
||||
1. **结构化中间态**：使用 JSON/YAML 而非自然语言传递数据
|
||||
```json
|
||||
{
|
||||
"step1_output": {
|
||||
"entities": ["Apple Inc.", "iPhone 15"],
|
||||
"sentiment": "positive",
|
||||
"confidence": 0.92
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. **Schema 校验**：在步骤间添加 Pydantic 模型验证
|
||||
```python
|
||||
from pydantic import BaseModel, ValidationError
|
||||
|
||||
class EntityExtraction(BaseModel):
|
||||
entities: list[str]
|
||||
confidence: float
|
||||
|
||||
# 在链中添加验证节点
|
||||
def validate_output(text: str) -> dict:
|
||||
try:
|
||||
return EntityExtraction.parse_raw(text).dict()
|
||||
except ValidationError:
|
||||
return {"error": "格式不符，要求重新生成"}
|
||||
```
|
||||
|
||||
3. **容错设计**：为上一步骤添加失败回退（Fallback）
|
||||
```python
|
||||
robust_chain = step1.with_fallbacks([fallback_prompt]) | step2
|
||||
```
|
||||
|
||||
4. **上下文窗口管理**：
|
||||
- 避免传递完整历史，只传递**摘要（Summary）**或**关键状态（State）**
|
||||
- 使用 `Map-Reduce` 模式处理超长文本，而非线性串联
|
||||
|
||||
### 调试技巧
|
||||
|
||||
- **中间状态检查**：使用 `RunnableLambda` 打印中间结果
|
||||
```python
|
||||
from langchain_core.runnables import RunnableLambda
|
||||
|
||||
debug_chain = step1 | RunnableLambda(lambda x: print(f"中间结果: {x}") or x) | step2
|
||||
```
|
||||
- **Token 消耗监控**：分别计算每个子步骤的 Token 数，识别成本瓶颈
|
||||
|
||||
---
|
||||
|
||||
**设计原则总结**：Prompt Chaining 的核心价值在于**通过任务分解降低单步复杂度（Complexity Decomposition）**，使每个子模型只需处理简化后的认知负载，从而提升整体系统的可靠性（Reliability）和可维护性（Maintainability）。
|
||||
218
InBox/milky_milky_2635.md
Normal file
218
InBox/milky_milky_2635.md
Normal file
@@ -0,0 +1,218 @@
|
||||
---
|
||||
title: "[Milky] 为您整理《讲透《Agentic design patterns》系列（1/21）：别再用长提示词了，10分钟学会prompt链模式》笔记 | BV1YGVY6nE4n"
|
||||
source: "milky@4ueo.com"
|
||||
date: 2026-06-10 12:18
|
||||
tags: [milky, bilibili, notes]
|
||||
email_id: 2635
|
||||
---
|
||||
|
||||
Milky 为您整理了《讲透《Agentic design patterns》系列（1/21）：别再用长提示词了，10分钟学会prompt链模式》 | BV1YGVY6nE4n 笔记。
|
||||
|
||||
Prompt Chaining（提示词链）模式实战指南
|
||||
|
||||
核心概念：什么是 Prompt Chaining
|
||||
|
||||
Prompt Chaining（提示词链） 的本质是将大任务拆解为串行步骤（Pipeline），上一步的产出直接作为下一步的输入。
|
||||
|
||||
工厂装配线类比：想象一个工厂的生产流程——拧螺丝的工位完成后，半成品直接滑向喷漆工位，再流向质检工位。而不是让一个工人同时负责拧螺丝、喷漆和质检。提示词链遵循同样的逻辑：每个步骤专注于单一职责，通过标准化接口传递中间产物。
|
||||
|
||||
为什么单 Prompt 搞不定复杂任务
|
||||
|
||||
当试图用单个超长 Prompt 解决复杂任务时，模型会出现五类典型失效模式：
|
||||
|
||||
上下文稀释（Context Dilution）：过长的指令导致模型注意力分散，忽略关键约束条件
|
||||
逻辑纠缠（Logic Entanglement）：多步骤推理相互干扰，前一步的错误在后续被放大
|
||||
输出格式不稳定：同时要求模型完成分析、推理、格式化输出，导致结构混乱
|
||||
调试困难：无法定位问题出现在哪个推理环节
|
||||
Token 效率低下：重复处理相同的上下文背景信息
|
||||
|
||||
7 个高频应用场景与流水线设计
|
||||
|
||||
场景 1：文档生成流水线
|
||||
步骤拆解：
|
||||
大纲生成：根据主题生成结构化大纲（Markdown 格式）
|
||||
内容填充：针对每个章节标题生成详细内容
|
||||
风格润色：统一语气、优化表达、检查一致性
|
||||
格式校验：验证最终输出是否符合模板要求
|
||||
|
||||
场景 2：代码审查与修复
|
||||
步骤拆解：
|
||||
静态分析：识别潜在 Bug、安全漏洞、性能瓶颈（输出问题清单 JSON）
|
||||
修复建议：针对每个问题生成具体修复代码
|
||||
代码重构：优化可读性和可维护性
|
||||
测试生成：为修复后的代码生成单元测试用例
|
||||
|
||||
场景 3：数据分析报告
|
||||
步骤拆解：
|
||||
数据理解：分析原始数据结构，识别字段类型和分布（输出数据画像）
|
||||
洞察发现：基于数据画像执行统计分析，发现趋势和异常
|
||||
可视化建议：生成图表配置代码（Matplotlib/Plotly）
|
||||
报告撰写：将数据洞察转化为业务语言，生成 executive summary
|
||||
|
||||
场景 4：客服对话处理
|
||||
步骤拆解：
|
||||
意图识别：分类用户问题类型（退款/技术支持/账户问题）
|
||||
信息抽取：从对话历史中提取关键实体（订单号、产品型号）
|
||||
方案生成：基于知识库生成解决方案草稿
|
||||
语气校准：根据用户情绪调整回复的礼貌程度和详细程度
|
||||
|
||||
场景 5：法律合同审查
|
||||
步骤拆解：
|
||||
条款提取：识别关键条款（违约责任、保密协议、争议解决）
|
||||
风险标记：对照法规库标记高风险条款（输出风险评级）
|
||||
条款对比：与标准模板对比，指出缺失或不合理条款
|
||||
修订建议：生成具体的条款修改建议书
|
||||
|
||||
场景 6：学术论文辅助
|
||||
步骤拆解：
|
||||
文献摘要：将多篇论文摘要压缩为核心观点矩阵
|
||||
研究缺口识别：分析现有研究的空白点
|
||||
方法论设计：针对研究问题设计实验方案
|
||||
引用格式化：将参考文献转换为指定格式（APA/MLA）
|
||||
|
||||
场景 7：多语言内容本地化
|
||||
步骤拆解：
|
||||
初译：直译源语言内容
|
||||
文化适配：识别文化特定梗、俚语，进行本地化转换
|
||||
术语一致性检查：确保专业术语在全文中统一
|
||||
本地合规审查：检查内容是否符合目标地区的法规要求
|
||||
|
||||
代码实战：LangChain LCEL 实现两步链
|
||||
|
||||
使用 LangChain Expression Language (LCEL) 可以简洁地实现 Prompt Chaining：
|
||||
|
||||
`python
|
||||
from langchain_openai import ChatOpenAI
|
||||
from langchain_core.prompts import ChatPromptTemplate
|
||||
from langchaincore.outputparsers import StrOutputParser
|
||||
|
||||
初始化模型
|
||||
llm = ChatOpenAI(model="gpt-4", temperature=0)
|
||||
|
||||
第一步：生成大纲
|
||||
outlineprompt = ChatPromptTemplate.fromtemplate(
|
||||
"为以下主题生成详细的文章大纲，使用Markdown格式：\n主题：{topic}"
|
||||
)
|
||||
outlinechain = outlineprompt | llm | StrOutputParser()
|
||||
|
||||
第二步：基于大纲生成内容
|
||||
contentprompt = ChatPromptTemplate.fromtemplate(
|
||||
"基于以下大纲撰写详细内容，要求专业且易懂：\n大纲：{outline}"
|
||||
)
|
||||
contentchain = contentprompt | llm | StrOutputParser()
|
||||
|
||||
组合链：使用 pipe 操作符串联
|
||||
fullchain = {"outline": outlinechain} | content_chain
|
||||
|
||||
执行
|
||||
result = full_chain.invoke({"topic": "Prompt Chaining 设计模式"})
|
||||
print(result)
|
||||
`
|
||||
|
||||
关键语法解析：
|
||||
| 操作符：将上游组件的输出作为下游组件的输入
|
||||
{"outline": outline_chain}：显式映射，将第一步的输出命名为 outline 传递给第二步
|
||||
隐式传递：如果下游 Prompt 的变量名与上游输出匹配，可自动映射
|
||||
|
||||
多步链与状态管理
|
||||
|
||||
对于需要保留上下文的复杂流程：
|
||||
|
||||
`python
|
||||
from langchain_core.runnables import RunnablePassthrough
|
||||
|
||||
三步链示例：提取 → 分析 → 总结
|
||||
extract_chain = (
|
||||
ChatPromptTemplate.from_template("从文本中提取关键数据点：{text}")
|
||||
| llm
|
||||
| StrOutputParser()
|
||||
)
|
||||
|
||||
analyze_chain = (
|
||||
ChatPromptTemplate.from_template("分析以下数据点并提供洞察：{data}")
|
||||
| llm
|
||||
| StrOutputParser()
|
||||
)
|
||||
|
||||
保留原始文本的同时传递中间结果
|
||||
combined_chain = (
|
||||
{
|
||||
"data": extract_chain,
|
||||
"original_text": RunnablePassthrough() # 透传原始输入
|
||||
}
|
||||
| analyze_chain
|
||||
)
|
||||
`
|
||||
|
||||
上下文工程与避坑指南
|
||||
|
||||
什么时候必须用链（Prompt Chaining）
|
||||
|
||||
| 场景特征 | 单 Prompt 风险 | 链式处理优势 |
|
||||
|---------|--------------|------------|
|
||||
| 多模态处理 | 格式混乱 | 每步专注一种输出格式 |
|
||||
| 需要外部工具调用 | 逻辑嵌套复杂 | 中间步骤可插入 API 调用 |
|
||||
| 质量门控要求 | 无法中途拦截 | 每步后可添加 validation |
|
||||
| 长文本生成（>2k tokens） | 遗忘早期约束 | 分步引用前文摘要 |
|
||||
|
||||
什么时候不该用链
|
||||
|
||||
简单问答：单轮即可完成的任务，拆分反而增加延迟和成本
|
||||
强依赖全局上下文：如代码全局重构，需要同时看到所有模块
|
||||
实时性要求极高：链式调用增加多次 API 往返时间（RTT）
|
||||
|
||||
步骤间数据传递格式规范
|
||||
|
||||
推荐格式（防止 Pipeline 崩溃）：
|
||||
|
||||
结构化中间态：使用 JSON/YAML 而非自然语言传递数据
|
||||
`json
|
||||
{
|
||||
"step1_output": {
|
||||
"entities": ["Apple Inc.", "iPhone 15"],
|
||||
"sentiment": "positive",
|
||||
"confidence": 0.92
|
||||
}
|
||||
}
|
||||
`
|
||||
|
||||
Schema 校验：在步骤间添加 Pydantic 模型验证
|
||||
`python
|
||||
from pydantic import BaseModel, ValidationError
|
||||
|
||||
class EntityExtraction(BaseModel):
|
||||
entities: list[str]
|
||||
confidence: float
|
||||
|
||||
# 在链中添加验证节点
|
||||
def validate_output(text: str) -> dict:
|
||||
try:
|
||||
return EntityExtraction.parse_raw(text).dict()
|
||||
except ValidationError:
|
||||
return {"error": "格式不符，要求重新生成"}
|
||||
`
|
||||
|
||||
容错设计：为上一步骤添加失败回退（Fallback）
|
||||
`python
|
||||
robustchain = step1.withfallbacks([fallback_prompt]) | step2
|
||||
`
|
||||
|
||||
上下文窗口管理：
|
||||
- 避免传递完整历史，只传递摘要（Summary）或关键状态（State）
|
||||
- 使用 Map-Reduce 模式处理超长文本，而非线性串联
|
||||
|
||||
调试技巧
|
||||
|
||||
中间状态检查：使用 RunnableLambda 打印中间结果
|
||||
`python
|
||||
from langchain_core.runnables import RunnableLambda
|
||||
|
||||
debug_chain = step1 | RunnableLambda(lambda x: print(f"中间结果: {x}") or x) | step2
|
||||
`
|
||||
Token 消耗监控：分别计算每个子步骤的 Token 数，识别成本瓶颈
|
||||
|
||||
|
||||
设计原则总结：Prompt Chaining 的核心价值在于通过任务分解降低单步复杂度（Complexity Decomposition），使每个子模型只需处理简化后的认知负载，从而提升整体系统的可靠性（Reliability）和可维护性（Maintainability）。
|
||||
|
||||
──────────────────────────────
|
||||
Generated by MilkyAi@Bilibili: https://space.bilibili.com/3461574540921489
|
||||
Reference in New Issue
Block a user