基于ADOPT框架的复杂Agent链路提示词优化实践

以真实多Agent投顾系统为案例，解读华为泊松实验室ADOPT论文方法论与工程落地

---

引言：当"写好提示词"不再是单人对话

过去两年，“提示词工程”（Prompt Engineering）的讨论大多围绕单轮对话展开——如何写一个清晰的system prompt、如何给few-shot示例、如何用CoT让模型逐步推理。这些方法论在ChatBot场景下足够用了。

但当你面对的是一个多Agent协作系统——4个专业Agent并行分析，1个合成层做冲突消解，输出经过内容过滤、合规注入、画像适配三层后处理——你会发现，"写好提示词"这件事的复杂度是指数级上升的。

更关键的是：在多步LLM流水线中，一个步骤的prompt改动会通过跨步骤依赖关系级联影响所有下游步骤。单独优化某一个节点的prompt，可能导致整体效果反而下降——这就是提示词优化的"牵一发动全身"困境。

2025年12月，华为泊松实验室发布了 ADOPT（Adaptive Dependency-Guided Joint Prompt Optimization for Multi-Step LLM Pipelines） 论文，首次将这个问题形式化并给出了系统性的解决方案。本文将以一个真实的券商智能投顾Agent平台为工程案例，结合ADOPT论文的核心方法论，系统讲解在复杂链路中如何体系化地优化提示词。

---

一、先理解问题：多步流水线中提示词优化的四重困境

在一个单轮对话中，你只需关心"输入→输出"这一个环节。但在一个多Agent系统中，提示词分布在至少6类节点上：

用户请求
  → [意图识别prompt] → [Agent-A system prompt] → [Agent-A tool-use prompt]
  → [Agent-B system prompt] → [Agent-B tool-use prompt]
  → [合成层prompt] → [个性化包装prompt] → [输出审核prompt]

这带来了四个维度的挑战：

困境1：无步骤级监督信号（No Step-Level Supervision）

在投顾Agent系统中，我们只能评估最终报告的质量——比如客户点击了"有用"还是"无用"，投顾审核通过还是驳回。但我们无法直接知道：

• 是股票诊断Agent的分析出了错？
• 还是合成层在整合时曲解了诊断结论？
• 还是Polish层在个性化包装时写错了数字？

只有端到端的输出标签，没有中间步骤的标注。 这是多步流水线优化的核心困难——信用分配（Credit Assignment）问题。

困境2：跨步骤依赖的级联效应（Inter-Step Dependency Cascade）

在本项目中，我们曾遇到过一个真实案例：优化了股票诊断Agent的prompt，让它更详细地分析财务数据，结果合成层的输出质量反而下降了。原因是诊断Agent增加了大量财务细节后，合成层被海量信息淹没，抓不住重点。

改进某一步≠整体提升。 步骤之间的依赖关系使得局部优化可能对全局产生反效果。

困境3：LLM驱动的反向传播存在信号衰减与偏差

现有方法（DSPy、TextGrad等）使用LLM自身来推理"错误是怎么传播的"——让一个LLM检查最终输出，然后"猜测"每个中间步骤哪里出了问题。这在ADOPT论文中被定义为LLM-based back-propagation，存在三个致命缺陷：

• 解释偏差（Interpretation Bias）：LLM在解释"为什么会出错"时会带入自身的先验判断，可能将正确的中间步骤误判为错误
• 信号衰减（Signal Decay）：通过多层LLM反向传递的文本反馈，每一步都损失信息精度，传到上游步骤时信号已经严重失真
• 不稳定性（Instability）：同一输入多次运行可能得到不同的梯度信号，优化过程难以收敛

困境4：资源分配的盲目性

目前大多数做法是对所有步骤的prompt均等投入优化资源。但在本项目5级流水线中：意图识别仅需简单分类（对prompt不敏感），而合成层的prompt质量对最终效果有决定性影响。均等投入意味着大量优化预算浪费在低影响力步骤上。

---

二、ADOPT论文核心方法论

华为泊松实验室的ADOPT（Zhao et al., 2025）针对上述困境提出了三个核心创新。以下先讲解方法论本身，再在第三部分结合本项目展示工程实践。

2.1 核心架构总览

                          ┌──────────────────────┐
   Training Data ──────→  │   Pipeline Execution  │
   (input, label)         │   (全步骤执行，保留   │
                          │    完整execution trace) │
                          └──────────┬───────────┘
                                     │
                          ┌──────────▼───────────┐
                          │  Dependency Analysis  │
                          │  E1: 结构角色分析      │
                          │  E2: 数据驱动依赖分析  │
                          │  (建立步骤间的功能依赖图) │
                          └──────────┬───────────┘
                                     │
                          ┌──────────▼───────────┐
                          │  Textual Gradient     │
                          │  Estimation           │
                          │  E3/E4: 全局文本梯度   │
                          │  E5: 局部文本梯度分解  │
                          │  (类比解析微分)        │
                          └──────────┬───────────┘
                                     │
                    ┌────────────────┼────────────────┐
                    │                │                │
              ┌─────▼─────┐  ┌──────▼──────┐  ┌─────▼─────┐
              │ Step 1    │  │ Step 2      │  │ Step 3    │
              │ Prompt    │  │ Prompt      │  │ Prompt    │
              │ Update    │  │ Update      │  │ Update    │
              │ (解耦更新) │  │ (解耦更新)   │  │ (解耦更新) │
              └───────────┘  └─────────────┘  └───────────┘
                                     │
                          ┌──────────▼───────────┐
                          │  Shapley Resource     │
                          │  Allocation           │
                          │  (高影响力步骤多分配   │
                          │   优化预算)            │
                          └──────────────────────┘

2.2 创新一：依赖感知的文本梯度估计（Dependency-Aware Textual Gradient Estimation）

这是ADOPT最核心的贡献。它的目标是在不依赖LLM反向推理的前提下，为每个中间步骤生成可操作的文本梯度信号。

Step 1：执行轨迹记录

首先，在训练集上运行整个流水线，保留每一步的完整执行轨迹（Execution Trace），包括：

• 该步骤的输入（来自上游步骤的输出）
• 该步骤的输出
• 该步骤使用的prompt版本
• 该步骤的中间推理过程（如CoT）

然后，根据最终输出与标签的匹配程度，将轨迹分为"好案例"和"坏案例"两组。

Step 2：结构与数据双通道依赖分析

ADOPT通过两个独立的优化器（Optimizer）建立步骤间的依赖关系：

• 结构角色分析（E₁）：从流水线的工作流代码和prompt结构中，推断每个步骤的设计意图——这一步骤在整体链路中承担什么角色。例如在投顾系统中，风险扫描Agent的角色是"安全阀"而非"分析主力"。

• 数据驱动依赖分析（E₂）：对于每个步骤，对比"好案例"和"坏案例"中该步骤的输出差异，量化该步骤输出变化与最终结果变化之间的相关性。这相当于在离散的文本空间中模拟了可微系统中的偏导数计算。

Step 3：全局文本梯度 → 局部文本梯度

• 全局文本梯度（E₃, E₄）：对于每个失败案例，首先计算"文本损失" L——用自然语言描述期望输出与实际输出之间的差距。然后生成全局文本梯度 g^global = ∇^text_Output L，这是一段自然语言描述，指明最终输出应该如何修正。

• 局部文本梯度（E₅）：基于步骤依赖模型和该步骤的I/O对，将全局梯度分解为各步骤的局部文本梯度 g^local_i = ∇^text_pi L。这个局部梯度明确指出了每个步骤的prompt应该如何修改才能减少端到端的损失。

关键洞察：这个过程的数学本质是在非可微的离散提示词空间中，通过经验观测到的I/O依赖关系来模拟解析微分。它不依赖LLM去"猜测"错误来源，而是基于实际执行轨迹中的数据相关性来推导。这从根本上避免了LLM反向传播中的解释偏差和信号衰减问题。

2.3 创新二：信号估计与提示词更新的解耦架构

ADOPT的第二个核心设计是将梯度估计与提示词更新明确分离：

传统端到端优化：
  梯度估计 + Prompt更新 → 紧耦合，难以调试，无法复用

ADOPT解耦架构：
  阶段1: 文本梯度估计 → 输出: 每个步骤的 g_local_i
  阶段2: Prompt更新 → 输入: g_local_i + 旧prompt → 输出: 新prompt

为什么解耦很重要？

1. 将多步联合优化降维为单步优化：有了每步骤独立的局部文本梯度后，多prompt联合优化问题被化简为一系列互不依赖的单prompt优化步骤。任何现成的单prompt优化器（APE、APO、PromptAgent等）都可以直接复用。

2. 可插拔的优化策略：不同步骤可以选择不同的更新策略。合成层需要深度优化，可以用重量级的PromptAgent；意图识别只需微调措辞，用轻量级的APE即可。

3. 可审计与可调试：梯度估计的质量和prompt更新的质量可以独立评估。如果优化效果不好，你可以明确知道是"梯度估计不准确"还是"更新策略不佳"——这在紧耦合架构中是无法区分的。

2.4 创新三：基于Shapley值的自适应资源分配

ADOPT的第三个创新解决了"给哪个步骤分配多少优化预算"的问题。

Shapley值机制：对于一个有n个步骤的流水线，每个步骤i对整体性能的边际贡献通过Shapley值来估计：

ϕi=∑S⊆N∖{i}∣S∣!(n−∣S∣−1)!n![v(S∪{i})−v(S)]\phi_i = \sum_{S \subseteq N \setminus \{i\}} \frac{|S|!(n-|S|-1)!}{n!} [v(S \cup \{i\}) - v(S)]ϕi​=S⊆N∖{i}∑​n!∣S∣!(n−∣S∣−1)!​[v(S∪{i})−v(S)]

其中 v(S) 是仅优化步骤集合S时的流水线性能。

实际应用：Shapley值高的步骤（对整体性能影响大的步骤）获得更多的LLM调用配额和迭代轮次，Shapley值低的步骤则被分配更少的资源。ADOPT论文的实验表明，这种自适应分配在相同总预算下，比均匀分配策略获得了显著更好的优化效果。

在投顾Agent项目中，经验上合成层和风险扫描Agent的Shapley值最高——前者主导了信息整合质量，后者的一票否决权直接影响结论方向。意图识别和格式化步骤的Shapley值最低——它们的prompt变化对最终报告质量影响微乎其微。

---

三、ADOPT方法论在投顾Agent项目中的工程实践

以下将ADOPT的三个创新分别映射到券商智能投顾Agent平台的具体工程实践中，展示理论如何落地。

3.1 依赖感知梯度估计的工程实现

场景：优化4 Agent并行会诊 + 合成层的整体提示词质量。

工程映射：

在本项目中，我们构建了一套执行轨迹记录系统。每次A级客户触发4 Agent会诊时，系统自动记录：

ExecutionTrace {
  step_1_portfolio: {
    input_prompt_hash: "v2.3.1",
    output: { conclusion: "...", confidence: 0.82, key_findings: [...] }
  },
  step_2_diagnosis: { ... },
  step_3_stock_pick: { ... },
  step_4_risk_scan: { ... },
  step_5_synthesis: {
    input: [step_1.output, step_2.output, step_3.output, step_4.output],
    output: { executive_summary: "...", action_items: [...] }
  },
  final_label: "review_approved" | "review_rejected"  // 投顾审核结果作为标签
}

好/坏案例分区：以"投顾审核通过率"和"客户满意度评分"作为最终标签。通过的案例进入"好案例"池，被驳回的案例进入"坏案例"池。

依赖分析：对照两组案例中各Agent的输出特征发现——在坏案例（被驳回）中，87%的案例存在"风险扫描Agent结论被合成层稀释"的现象。即风险Agent给出了高风险预警，但合成层将其放在了报告末尾的次要位置，导致投顾驳回。这一发现直接驱动了合成层prompt中"风险优先原则"的制定。

这正是ADOPT E₂优化器的思路——不是让LLM去猜测"合成层哪里做错了"，而是通过实际执行数据的对比分析，客观地发现"风险信息被稀释"这一模式，然后针对性地修改合成层prompt。

对应ADOPT论文的理论解释：

局部文本梯度 g_local_synthesis 的生成逻辑是：

“合成层当前输出的问题是：风险预警信息在优先级排序中被错误地置于次要位置。修正方向：在prompt中增加显式的风险优先规则，使高风险预警在任何情况下都被置于报告最前。”

这个梯度不来自LLM的"我觉得合成层哪里有问题"，而是来自对多组执行轨迹的数据驱动对比分析——好案例中风险信息排第一，坏案例中风险信息排最后，两者之间的差异就构成了梯度信号。

3.2 解耦架构的工程实现

场景：将"发现问题"和"修改prompt"分离为两个独立阶段，使优化过程可插拔、可审计。

工程映射：

在本项目中，提示词优化被严格分为两个团队执行：

阶段	执行者	输入	输出	工具
信号估计	AI算法工程师 + 数据分析	执行轨迹 + 好/坏案例对比	每个节点的局部文本梯度（自然语言描述的改进方向）	数据分析脚本 + 人工分析
Prompt更新	AI算法工程师 + 合规部门	局部梯度 + 旧prompt + 合规约束	新版本prompt	PromptAgent / 人工改写

一个具体的解耦优化案例：

阶段1——梯度估计：通过执行轨迹分析发现，股票诊断Agent在"坏案例"中频繁出现两个模式：

1. 诊断结论过于简短（平均仅83字），导致合成层缺少足够的论据进行深度整合
2. 财务数据引用中12%的案例存在数字精度偏差（如"约120亿"替换了精确的"118.5亿"）

生成的局部文本梯度：

“诊断Agent的输出信息密度不足，且存在数字精度损失。改进方向：①约束输出深度，确保每个诊断维度至少包含数据+分析+判断三段式；②强制要求财务数据使用精确值而非约数。”

阶段2——Prompt更新：基于以上梯度，修改诊断Agent的prompt，增加两条规则：

## 新增规则
5. 每个分析维度必须输出：(a)精确数据 → (b)数据含义解读 → (c)对投资的启示
6. 所有财务数字必须保留原始精度，禁止使用"约"、"大约"、"左右"等模糊词

解耦的价值验证：修改上线一周后，诊断Agent平均输出长度从83字提升至215字，数字精度偏差率从12%降至1.3%。合成层的"信息充足度"评分（由LLM评估）从3.1/5提升至4.2/5。两个阶段的负责人可以独立追溯各自的贡献，也可以在出现问题时快速定位是"梯度估计错了"还是"更新写错了"。

3.3 Shapley资源分配的工程实践

场景：在固定优化预算下，将精力集中在高影响力步骤上。

工程映射：

在本项目的5级流水线中，通过对照实验估算了各步骤的Shapley值（使用A级客户30天的运行数据）：

流水线步骤	估算Shapley值	影响力等级	优化资源分配	说明
意图识别	0.03	低	5%	简单的意图分类任务，prompt敏感度低
股票诊断Agent	0.18	中	20%	诊断质量直接影响下游合成，但非决定性的
持仓分析Agent	0.16	中	15%	同上
AI选股Agent	0.12	中	10%	推荐质量重要但客户容忍度较高
风险扫描Agent	0.22	高	25%	一票否决权使其成为质量关键节点
合成层（Research Manager）	0.24	高	20%	信息整合的最终质量决定性因素
个性化包装	0.05	低	5%	仅影响可读性，不影响分析正确性

资源分配策略的工程收益：

在总优化预算为200人时的条件下，按Shapley值分配（高影响力75%，中影响力45%，低影响力10%）相比均匀分配，最终报告的"投顾审核通过率"提升了8.3个百分点。原因很直观：合成层和风险扫描Agent的prompt质量改进拥有最大的全局杠杆效应。

---

四、ADOPT vs. 其他提示词优化方法：深度对比

本章将ADOPT与当前主流的四种提示词自动优化方法进行系统对比，并说明各自的适用场景。

4.1 对比总览

维度	ADOPT	DSPy MIPROv2	TextGrad	GEPA	Trace
机构	华为泊松实验室	Stanford NLP	Stanford Zou Lab	UC Berkeley + Stanford + MIT	-
发表时间	2025.12	2024-2025	2025 (Nature)	2025.07	2024
核心机制	依赖感知文本梯度估计 + 解耦更新	贝叶斯优化 (TPE)	LLM反向传播文本梯度	遗传搜索 + 反思进化	LLM驱动的trace级优化
梯度来源	执行轨迹数据驱动（非LLM）	不需要梯度（黑盒搜索）	LLM生成文本梯度	不需要梯度（遗传变异）	LLM分析execution trace
多步信用分配	结构+数据双通道依赖分析	黑盒优化（不显式分配）	LLM反向推理分配	遗传选择隐式分配	Trace级反馈
算力成本	中（需多轮执行记录）	高（需大量候选评估）	中（每次反向传播需LLM调用）	低-中（仅需正向评估）	中
可解释性	高（局部梯度可见）	低（贝叶斯黑盒）	中（梯度为自然语言）	中（可通过反思trace查看）	高（trace级可视化）
对流水线结构的假设	支持循环+动态控制流	主要针对DAG结构	通用计算图	无结构假设	通用

4.2 逐一深入对比

ADOPT vs. DSPy MIPROv2

MIPROv2的核心思路：将多步流水线的所有prompt和few-shot示例当作离散超参数，使用Optuna的TPE（Tree-structured Parzen Estimator）贝叶斯优化算法在组合空间中搜索最优配置。

关键差异：

• 信用分配 vs. 黑盒搜索：MIPROv2不对"哪个步骤导致了错误"做显式推理——它将整个程序视为黑盒。如果一个步骤的prompt出了问题，它只能通过"尝试各种组合→看哪个分数高"的方式来间接发现。当流水线步骤增多时，搜索空间呈组合爆炸（5个步骤各10个候选 = 100,000种组合）。ADOPT通过依赖感知的梯度估计直接定位问题步骤，避免了组合搜索。

• 信号效率：MIPROv2的每次试验只产生一个标量分数（好/坏）。ADOPT的一次执行轨迹产生的是每个步骤的结构化文本梯度——信息密度相差一个数量级。这意味着ADOPT可以用更少的评估次数达到相同的优化效果。

• 适用场景分水岭：

  • MIPROv2更适合：步骤数少（≤3）、prompt候选池不大的场景，或者当你不想深入理解流水线内部机制、只想"一键优化"时
  • ADOPT更适合：步骤数多（≥4）、步骤间有复杂依赖关系、需要理解每一步改进方向的可解释场景

一个直观类比：

• MIPROv2 = 蒙着眼睛试100个钥匙，看哪个能开门
• ADOPT = 先仔细研究锁的结构（依赖分析），再针对性地配一把钥匙

ADOPT vs. TextGrad

TextGrad的核心思路：将PyTorch的自动微分理念平移到文本世界。用LLM生成的自然语言批评（critique）作为"文本梯度"，通过计算图反向传播到每一个上游变量。

关键差异：

• 梯度的可靠性：这是ADOPT对TextGrad最根本的改进。TextGrad的文本梯度完全由LLM生成——LLM看到最终输出不好，然后"猜测"每个中间步骤应该怎么改。ADOPT的论文指出这引入了解释偏差：LLM在生成梯度时可能会"脑补"出并不存在的问题，或者遗漏真正的问题。ADOPT的梯度来自执行轨迹的数据驱动对比（好案例 vs 坏案例的真实差异），不依赖LLM的解释能力。

• 信号衰减：TextGrad通过多层LLM反向传播时，每一层都在生成文本→解读文本，信息精度逐步损失。在4步以上的流水线中，传到第一步的梯度可能已经面目全非。ADOPT的局部梯度是直接从全局梯度解析分解的，不经过中间LLM的层层传递，避免了衰减。

• 适用场景分水岭：

  • TextGrad更适合：短流水线（2-3步）、需要快速原型验证的场景；其PyTorch风格API也降低了ML工程师的使用门槛
  • ADOPT更适合：长流水线（≥4步）、对优化质量有较高要求的生成场景；以及对可解释性和审计有要求的合规场景

ADOPT vs. GEPA

GEPA的核心思路：完全放弃梯度概念，采用遗传算法思想——维护一个prompt种群，用LLM对失败案例做"反思"（reflection）来生成变异（mutation），通过Pareto前沿选择保留在任务不同子集上表现最好的候选。

关键差异：

• 有方向 vs. 无方向搜索：GEPA的prompt变异虽然有反思引导，但本质仍是试错搜索——生成多个变异→评估→保留好的。ADOPT则通过依赖分析和梯度分解提供了确定的改进方向，每一步更新都是有理论依据的。

• 效率对比：GEPA论文宣称相比GRPO减少了35倍的rollouts，但这个数字是在"有强反馈信号（如编译器错误、测试用例通过/失败）"的场景下取得的。在投顾Agent这种"输出质量只能靠人工评估"的开放域生成场景中，评估成本才是瓶颈——GEPA的遗传搜索仍需要大量的人工评估或LLM评估来驱动选择。

• 互补而非对立：GEPA的反思机制和ADOPT的梯度估计实际上可以互补。一个可能的方向是：用ADOPT做粗粒度的步骤级优化方向确定，用GEPA做细粒度的prompt措辞搜索。

ADOPT vs. Trace

Trace的核心思路：记录每个步骤的完整执行trace（包括中间推理、工具调用、输出），用LLM分析trace来生成改进建议。

关键差异：

Trace更接近于debugging工具而非系统化优化框架。它告诉你"这一步的输出看起来有问题"，但不会显式建模步骤间的依赖关系，也不提供量化的影响力分配。ADOPT在此基础上增加了依赖建模、梯度分解和资源分配三个层次，使其成为可复现的优化方法论而非一次性诊断工具。

4.3 什么场景下应该选择ADOPT？

基于以上对比，ADOPT在以下场景中具有最显著的优势：

1. 步骤数≥4的长流水线：此时TextGrad的信号衰减和MIPROv2的组合爆炸问题变得不可忽视
2. 步骤间存在非平凡的依赖关系：如投顾Agent中风险扫描的一票否决权、合成层对上游输出的非线性整合
3. 需要可解释的优化过程：金融、医疗、法律等合规场景下，你必须能解释"为什么改了这段prompt"
4. 优化预算有限但要求高：Shapley自适应分配使有限资源集中在高杠杆步骤

4.4 对比总结矩阵

                     信号质量          可解释性        多步信用分配      长链路鲁棒性
ADOPT        ════════════════  ════════════════  ════════════════  ════════════════
DSPy MIPROv2 ═══════          ═══              ══════           ═══════════
TextGrad     ══════════       ════════         ═══════          ═══════
GEPA         ═════════        ════════         ════════         ═══════════════
Trace        ════════         ════════════     ═════            ════════

图例: ═══ 较长表示在该维度表现更强

---

五、从理论到实践：ADOPT视角下的投顾Agent提示词优化全景

将ADOPT的方法论与本项目的工程实践结合，完整的优化链路如下：

                          ┌─────────────────────────────────┐
                          │  Step 0: 执行轨迹全量记录       │
                          │  每次4 Agent会诊 → 完整trace    │
                          │  投顾审核结果 → 标签             │
                          └──────────────┬──────────────────┘
                                         │
                          ┌──────────────▼──────────────────┐
       [ADOPT E1/E2]      │  依赖分析                       │
                          │  E1: 风险Agent = 安全阀角色      │
                          │  E2: 合成层输出质量与最终评分    │
                          │      的相关系数 = 0.74 (最高)    │
                          └──────────────┬──────────────────┘
                                         │
              ┌──────────────────────────┼──────────────────────────┐
              │                          │                          │
    ┌─────────▼─────────┐    ┌──────────▼──────────┐    ┌─────────▼─────────┐
    │  Anchor（锚定）    │    │ Decompose（分解）     │    │Orchestrate（编排） │
    │  三层事实锚定       │    │ 4 Agent正交拆分       │    │ 合成层冲突消解      │
    │  g_local_diag:     │    │ g_local_decomp:      │    │ g_local_synth:     │
    │  "增加精确数值      │    │ "每个子Agent不加      │    │ "风险优先→冲突     │
    │   引用强制约束"     │    │  其他Agent的背景"     │    │  陈述→逻辑串联"    │
    └─────────┬─────────┘    └──────────┬──────────┘    └─────────┬─────────┘
              │                          │                          │
              └──────────────────────────┼──────────────────────────┘
                                         │
                          ┌──────────────▼──────────────────┐
                          │  [ADOPT E5] 各步骤解耦更新        │
                          │  ├─ 诊断Agent prompt v2.3→v2.4   │
                          │  ├─ 合成层prompt v3.1→v3.2       │
                          │  ├─ 风险Agent prompt v1.8→v1.9   │
                          │  └─ ...                          │
                          └──────────────┬──────────────────┘
                                         │
                          ┌──────────────▼──────────────────┐
                          │  [Shapley分配]                   │
                          │  高影响力步骤(风险+合成): 45%预算  │
                          │  中影响力(诊断+持仓+选股): 45%    │
                          │  低影响力(意图+包装): 10%         │
                          └──────────────┬──────────────────┘
                                         │
                          ┌──────────────▼──────────────────┐
                          │  Polish + Track                  │
                          │  分级个性化包装 + 三层评估体系    │
                          │  → 反馈回流至下一轮梯度估计       │
                          └─────────────────────────────────┘

---

六、三个反直觉的提示词设计洞察

基于本项目从0到1的实践，分享三个在ADOPT框架指导下"踩出来的"经验：

洞察1：好的prompt不是"给模型更多信息"，而是"给模型更明确的边界"

初版股票诊断prompt写了2000多字的system instruction，涵盖各种分析框架和技术细节。结果模型出现"分析过度"——关键结论被海量文字淹没。

优化后的版本砍掉了70%的"你应该怎么想"的指导，增加了大量"你不能做什么"的硬约束。模型的输出质量不降反升。因为边界比方向更重要——方向给得再多，模型还是会自由发挥；边界设得够清晰，模型在边界内的表现往往超出预期。

这与ADOPT的核心理念一致：好的局部文本梯度不是"你应该多想一些"，而是"你在以下方面不应该越界"。

洞察2：合成层的prompt不应该被告知所有细节

最初合成层prompt包含了每个子Agent的完整分析逻辑说明。结果合成层倾向于"沿袭"子Agent的推理方式而非"独立审视"。

最终版本将合成层prompt精简为仅包含"输入是什么、规则是什么、输出是什么"。合成层只基于结果做判断——这恰恰是一个Research Manager应该做的。

这在ADOPT框架中对应一个重要的架构原则：依赖分析的目的不是让下游"理解"上游，而是让下游在正确的位置施加正确的约束。

洞察3：最容易被忽视的是"拒绝回答"的设计

大多数提示词工程关注"怎么答得更好"，但金融合规场景下，"不回答"和"怎么拒绝得体面"同样重要。本项目为拒答场景设计了6类模板、5种伪装识别策略、3级检测管道，投入的精力和"优化回答质量"几乎一样多。

对应ADOPT方法论，这属于为"不做"的行为定义明确的成功标准——不是所有的局部梯度都指向"做得更多"，有些梯度指向"知道什么时候该停下"。

---

七、总结与展望

ADOPT论文（Zhao et al., 2025）解决的本质问题是：多步LLM流水线中的提示词优化，不能靠LLM"猜测"错误来源，而应该通过执行轨迹的数据驱动依赖分析来生成可解释的梯度信号。

它将传统可微系统中的三个核心概念——偏导数（依赖分析）、梯度分解（全局→局部）、资源分配（Shapley值）——巧妙平移到了非可微的提示词空间。这不仅是工程方法论的进步，更是对"如何体系化地设计AI系统"这一根本问题的方法论贡献。

对于正在构建多Agent系统的开发者，ADOPT提供的不是一套新工具，而是一种新的思维方式：

• 不要问"这个prompt写得好不好"，而要问"这个步骤对上一步的什么信息敏感、对下一步的什么输出负责"
• 不要凭直觉判断"哪个步骤最重要"，而要用Shapley值量化每个步骤的边际贡献
• 不要把"优化prompt"当作一次性的创作行为，而要将其视为一个有梯度信号、有反馈回路的持续迭代过程

与其他方法的协同前景

值得注意的是，ADOPT的解耦架构使其天然具备与现有方法互补的潜力：

协同方向	说明
ADOPT + MIPROv2	ADOPT做粗粒度的步骤级优化方向确定，MIPROv2在约束的搜索空间内做细粒度的prompt+few-shot组合搜索
ADOPT + GEPA	ADOPT的梯度估计为GEPA的反思变异提供更准确的"变异方向"，减少无效变异
ADOPT + TextGrad	用ADOPT的依赖分析为TextGrad的反向传播提供结构化的传播路径，减少信号衰减

这些方向目前尚未在学术界被充分探索，是值得关注的研究前沿。

---

参考论文：Zhao, M., Zhang, X., Zhang, S., Li, D., & Shi, R. (2025). ADOPT: Adaptive Dependency-Guided Joint Prompt Optimization for Multi-Step LLM Pipelines. arXiv:2512.24933. Huawei Poisson Lab.

作者注：本文案例基于真实项目架构抽象，具体业务数据已做脱敏处理。对比分析部分基于各方法公开发表的论文与文档，如有疏漏欢迎指正。