218 lines
8.2 KiB
Markdown
218 lines
8.2 KiB
Markdown
---
|
||
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 |