从提示语优化到反馈循环：DSPy、GEPA和Claude Code

多年来，对于弱性能的LLM输出，默认的解决方法很简单：调整提示词后重新尝试。而在代理系统中，往往问题并不出在提示词本身。

想象一个只有在配置更改后才会出现的生产环境故障。将其交给两种不同的AI系统处理。第一种系统会给出堆栈跟踪信息以及措辞严谨的指令，随后返回修复补丁；而第二种系统则能打开代码仓库，阅读项目规则，重现故障，修改代码，运行测试，找出问题所在，然后再重新尝试。

在这两种情况下模型都很重要。第二种系统所具备而第一种所没有的，是一个可运行的反馈循环。

一旦有了这样的循环结构，提示词的表达就只是众多可调参数之一。你还可以调整任务的分解方式、需要检索的内容、可用的工具、示例、验证规则、重试规则、执行时的沙箱环境，以及决定工作是否正确的评估机制。

从斯坦福大学在DSPy、MIPRO、STORM和GEPA方面的研究，到Anthropic在Claude Code和模型上下文协议上的实际应用，其核心思路是一致的。这些并非同一套架构，但共同的理念是：人工智能工程正从单纯优化提示词，转向构建能够执行任务、衡量结果并持续改进模型相关程序的系统。

提示词现已成为其中一个参数

一次性使用的应用几乎没有任何控制选项：

Task → Prompt → Model → Result

对于那些结构简单的任务来说没问题。但一旦任务需要多个阶段、外部信息、实际的副作用、检查功能，或者需要在执行过程中纠正错误决策，系统就会变得脆弱。

为实际生产环境设计的系统则更像是这样：

 Task
  ↓
Program / Planner
  ↓
Context + Retrieval
  ↓
Tools + Environment
  ↓
Execution Trace
  ↓
Evaluator
  ↓
Retry, Repair, or Optimize
  ↓
Result

目前，糟糕的结果可能由多种原因造成。模型可能不够强大，检索过程可能调用了错误的上下文，规划器可能对任务的拆分不合理，某个工具可能返回了过时的数据，验证器可能忽略了无效的答案，又或者指令本身确实需要修正。

因此，提示工程并不会消失，它只是更广泛的调试与优化工作中的一个环节而已。

DSPy：让程序更加明确

DSPy的第一个重要理念是不再将语言模型流程视为一堆需要手动调整的提示字符串。最初的论文将语言模型应用建模为声明式模块的计算图，并加入了一个编译器，用于根据特定指标优化这些模块。当前的文档表述得更直白：定义结构化的签名和模块，提供示例与评分函数，然后编译程序，而无需手动调整每个提示。

一个简单的DSPy程序如下所示：

import dspy

class Diagnose(dspy.Signature):
    """Identify the most likely root cause from an issue and repository evidence."""
    issue: str = dspy.InputField()
    evidence: str = dspy.InputField()
    diagnosis: str = dspy.OutputField()

program = dspy.ChainOfThought(Diagnose)

optimizer = dspy.GEPA(
    metric=score_diagnosis,
    auto="medium",
)

optimized = optimizer.compile(
    program,
    trainset=historical_incidents,
)

语法并非关键所在。重要的是，原本在一个提示词中混杂在一起的四项内容现在分开了：任务需要生成什么、如何执行任务、哪些示例作为指导，以及如何评估成功标准。

这改变了工程师的工作方式。不必把整个迭代预算都花在争论“简洁”是否应改为“回答前仔细思考”上，而是可以提出更好的问题：哪些行为需要改进，又该如何衡量？

如果没有有意义的评估指标，自动优化只会让系统在错误的目标上变得更好。

MIPRO：调整多个阶段其实是一个搜索问题

当程序包含多个模块时，情况会变得更加复杂。以一个包含诊断、补丁生成和审核的错误修复流程为例，最终测试仍然失败。是哪个模块导致了问题？应该修改哪条指令？那些少量示例是否具有误导性？更完善的诊断步骤会不会反而降低补丁生成的效率？

这实际上是一个任务分配问题，也是MIPRO要解决的核心问题。MIPRO的相关论文并非仅仅着眼于对单个提示语的修改，而是同时调整每个模块中的书面指令与少量示例，结合能够同时考虑程序和数据的指令建议、针对小数据集的评估结果，以及一种用于引导搜索朝向更有希望的组合的替代模型。

大致内容如下：

Bootstrap useful demonstrations
          ↓
Propose task-grounded instructions
          ↓
Search instruction + demo combinations
          ↓
Evaluate the whole program

在使用 Llama-3-8B 时，优化器在七个多阶段程序中的五个上超越了基准水平，最佳情况下在所测量的准确率指标上提升了高达 13%。

这一成果相较于“自动提示语优于人类”的说法要保守得多。更重要的启示在于结构层面：一旦指令和示例成为多阶段程序的参数，改进该程序就变成了对系统的搜索过程，而非单纯对某段文本的编写。

STORM：结构优先于优化

再好的优化器也无法挽救结构糟糕的工作流程。斯坦福大学的 STORM 就是一个很好的例子，因为它关注的是工作流程的布局方式，而非哪种提示语更有效。

让单一模型一次性完成所有研究及长文撰写是一种过于简单的做法；STORM则将准备阶段拆分为独立的步骤。它寻找该主题的不同视角，利用这些视角基于资料提出问题，将收集到的内容整理成大纲，之后才进行写作。

与基于大纲的检索基准相比，该研究显示在内容组织方面有25个百分点的绝对提升，在内容广度方面有10个百分点的提升。STORM项目也明确指出了其局限性：生成的文章尚不可直接发表，通常需要大量修改。

从中得到的启示并非“增加更多智能体”，而是分解任务能让人们分别控制上下文、证据、错误处理及评估等环节。在优化工作流程之前，首先要确保其各个阶段与实际可能出现的问题相匹配。

GEPA：从实际发生的情况中学习

一个分数就能说明某次表现平平，但通常无法解释原因。真正的表现则会留下更为丰富的证据：

input
  ↓
retrieval choice
  ↓
reasoning
  ↓
tool call
  ↓
tool result
  ↓
constraint failure
  ↓
final output

GEPA是“遗传-帕累托”方法的缩写，于2025年7月发表，它利用该信号来处理任务。该方法会采集执行轨迹，用自然语言对其进行分析，提出提示词修改建议，对候选方案进行评分，并维护帕累托前沿，从而避免舍弃互补的策略。

在实际应用中，有一个边界至关重要。GEPA会在你已经观察到的轨迹上进行优化。但这并不意味着允许实时代理在每次用户请求后都自行修改。在任何优化后的候选版本投入使用之前，都应为其生成版本号，用其从未训练过的数据集对其进行评分，将其优化成本控制在固定范围内，并通过针对精心挑选的评估集的专门测试。这才是有效自我改进与失控自我修改之间的界限。

Claude Code：真实环境中的循环

DSPy从程序优化角度来解决这个问题，而Claude Code则从运行时角度入手。在Anthropic的框架中，它是一个存在于你代码仓库中的智能体：它会获取项目自身的指令，修改文件，执行shell命令和测试套件，并根据结果不断进行调整。其高级架构文档中提到了通过子智能体分配任务、在各个步骤之间运行钩子功能，以及通过MCP接入企业内部服务。

这种架构并非“与更聪明的程序员聊天”，而更接近于以下模式：

Repository + Project Rules + Task
              ↓
            Model
       ↙      ↓      ↘
     Read    Edit   Execute
       ↘      ↓      ↙
      Tests / Runtime Evidence
              ↓
         Next Decision

这种运行时的证据会改变模型能够完成的任务。一次失败的测试比“请重新考虑”更能提供反馈；编译错误也比模型自行评估其修复方案更为可靠。是否在合理范围内进行修改可以通过机械方式进行检查，而无需再询问另一个模型该变更的规模是否恰当。

Anthropic的内部效率数据虽有趣，但容易被过度解读。其2026年的分析报告显示，到2026年第二季度，每位工程师每天的代码行数约为早期阶段的八倍，同时该公司也明确指出代码行数并不能真实反映实际效率。这一时期也正是模型与Claude Code都经历重大变革的阶段，因此这些数据并不能说明提升效率完全得益于协调机制。更明确的迹象是，现代编码系统不断将模型输出转化为行动、观察结果，进而推动进一步的决策。

MCP用于连接工具，而非进行协调

MCP常常与智能体、工具使用及协调功能混为一谈，仿佛它们是同一回事。其实并非如此。MCP架构是一种客户端-服务器规范：AI应用连接到服务器，了解这些服务器提供了哪些工具、资源及提示词，然后以统一的方式调用它们。主机负责协调各个客户端，并承担权限管理、上下文管理、安全策略以及如何接入大语言模型等职责。

因此，MCP只是更大系统架构中的一层而已：

Model                  capability envelope
Program / graph         task decomposition
Context / state         what the model can see
Tools / MCP             what the system can access or do
Runtime / harness       where actions execute
Evaluator               what counts as success
Optimizer               how the program improves
Observability           why a run succeeded or failed

没有哪个框架能够涵盖所有内容，这正是从系统角度思考能带来好处的原因。

优化错误修复流程，而非提示词

从最初的问题入手。不要只用一条指令要求“找到问题并修复它”，而应明确说明工作流程：

  Issue + Repository
        ↓
    Diagnosis
        ↓
      Patch
        ↓
Tests + Lint + Runtime Checks
        ↓
    Diff Review
        ↓
  Accept or Revise

每个阶段都会产生相应的证据：运行时日志记录了哪些文件被读取、执行了哪些命令、哪些补丁应用失败、测试结果以及最终的差异对比。

确定性检查用于验证那些可以通过机械方式证明的内容：所需的测试均通过、代码检查无问题、未触碰被禁止的文件，且补丁仍在允许的范围内。对于真正涉及语义层面的问题，比如该诊断结果是否能解释可能的根本原因，则由模型来判断。

随着时间推移，过去的案例会成为评估集。MIPRO可以搜索诊断和修复模块中的指令与示例。GEPA则可以利用失败的运行路径以及评估者的反馈来提出更好的程序代码。不过优化工作应在发布边界之后进行：

Production traces
      ↓
Curated evaluation set
      ↓
Offline optimizer
      ↓
Candidate program
      ↓
Held-out validation
      ↓
Controlled promotion

这就是研究与生产最终交汇的地方。代理运行时负责生成操作并记录轨迹，评估器则将这些轨迹转化为证据，优化器会提出更好的程序方案，而部署流程则决定是否可以安全地发布该程序。

这对人工智能工程师意味着什么

提示词并未变得无关紧要，只是有了更多可以发挥作用的环节。当工作流表现不佳时，不要首先下意识地检查提示词的措辞，而应先找出出问题的环节：

• 基础模型是否能够处理这项任务？
• 检索过程是否找到了正确的上下文？
• 任务是否在合理的边界上被拆分？
• 工具返回的证据是否值得信赖？
• 程序的执行过程是否处于隔离状态且可被观察？
• 评估器是否衡量了你真正关心的行为表现？
• 优化器是在提升实际应用的质量，还是在仅仅适配开发环境的数据？

从整个系统角度审视，就能发现那些被炒作往往忽视的权衡。将一个性能较差的模型封装在图中，并不会让它变成前沿模型。糟糕的评估指标会引导模型产生错误的行为。工具越多，出错的可能性就越大，安全风险也越高。每次优化都会消耗代币和评估时间。最糟糕的是，一个能够自行修改却没有任何版本历史记录且没有未经修改的测试用例的智能体，虽然表面上看起来更独立，但实际上会变得越来越不可靠。

因此，关键并非模型不再重要。模型质量决定了其能力的上限，而系统设计则决定了这些能力中有多少能转化为可靠的结果。

这就是斯坦福研究与Anthropic工具之间的真正联系。借助DSPy，程序不再隐藏在提示词字符串中。MIPRO允许你在不同阶段搜索指令和示例。STORM则提醒我们工作流的架构才是首要考虑的。GEPA通过分析完整的执行轨迹来寻找改进点。Claude Code将模型置于可用的工程框架中，而MCP则规范了模型与外部功能之间的接口。不同层级的项目，都在朝着同一个方向发展。

下次人工智能系统出现故障时，不应只考虑“接下来该尝试什么提示词？”这个问题，而应先弄清楚系统的哪部分出了问题，以及哪些证据能够帮助你修复它。