Control-Data Flow Separation: Multi-Agent LLM 中稳定的 Prompt 优化

TL;DR 在多智能体 LLM 中，将执行关键的结构化控制流与可优化的自然语言数据流分离，杜绝 prompt 优化破坏路由/格式等协议，实现 100% 协议有效且任务表现持续提升。

问题

问题背景

当前 Multi-Agent LLM 系统 依赖 prompt 同时完成两类功能：生成任务内容（如推理、写作）和传递执行协议（如消息路由、输出格式、终止信号）。自动 prompt 优化通常只针对内容质量，却无意识地改变了控制面，导致整个 agent pipeline 失效。

现有方法局限

• 传统 prompt optimization（如 TextGrad、DSPy 等）将 prompt 整体作为优化对象，未区分两种角色的不同表示；一旦优化器修改了格式说明、路由关键词或停止条件，底层代码依赖的协议即被破坏。
• 约束生成 或 typed output 方法试图用 schema 固定输出结构，但要么过度限制语言灵活性，要么需要大量手工维护，且未系统解决 prompt 优化带来的协议漂移。
• 现有 agent 框架（如 AutoGen、LangGraph）通常把协议硬编码在代码中，但优化时只调整提示文本，两者容易脱节。

为什么这个问题难/重要

协议正确性直接影响多智能体系统能否运行，而内容优化可能以非线性方式漂移到控制面；论文实证 naive TextGrad 在迭代中反复出现格式丢失、字段重命名等 collapse 现象。业界大量采用 LLM-as-judge 和自动 prompt 工程，但缺少稳定优化手段，导致生产环境要么牺牲性能要么承受系统崩溃风险。

行业类比

这类似于在软件工程中重构模块时修改了接口签名却没有同步更新调用方——LLM 的 prompt 同时充当了“实现”和“API 契约”，优化必须像类型系统一样保护控制流不被意外破坏。

核心洞察

• - 将多智能体系统中的执行关键协议（消息路由、输出格式、终止信号）从可优化的自然语言内容中分离，控制流用 typed, validated program objects 表示，数据流保持语言可优化。这区别于将整个 prompt 作为单一文本优化的 baseline，后者无法区分协议与内容，任何针对内容的编辑都可能破坏底层代码依赖的控制接口。
• - 通过 schema 和执行层校验，优化过程始终维持 100% protocol validity，且不影响任务表现提升。这与 TextGrad 等直接对文本 prompt 做梯度优化的方法形成对比，后者会产生 prompt drift 并逐渐侵蚀控制表面，导致代理管道在迭代后期崩溃，而本框架从结构上根除这类失败模式。

方法

该方法的输入是一个多智能体 LLM 系统，其中每个 agent 的提示同时扮演两种角色：生成任务相关内容，以及定义执行关键协议（如消息路由、输出格式、终止信号）。传统提示优化（如 TextGrad）会直接编辑这些提示，容易在改进内容时无意破坏协议，导致管线崩溃。

CDSep 的核心思路是将这两种角色分离为不同的表示：

1. 协议结构化为类型化对象：将消息路由、JSON 字段、终止标志等执行关键控制信息，从自然语言提示中抽出，表示为经过模式校验的 typed program objects（如 Pydantic 模型）。这些对象由代码持有，执行引擎只读取这些已校验的结构，不依赖提示文本。
2. 任务内容保留为数据流：agent 之间的自然语言通信内容（数据流）继续由提示生成，成为优化器唯一可以修改的部分。
3. 优化仅作用于数据流：提示优化器在迭代过程中只调整数据流的语言表述，而协议对象保持不变，因此不会出现“提示漂移”到控制面的情况。
4. 开发者接口：提供显式的 schema 声明 API，开发者定义控制类型和验证规则；执行前自动校验，确保协议有效性。

输出是保持 100% 最终协议有效性的同时，任务性能持续提升的多智能体系统。

与同类方法（如 DSPy 将控制指令嵌入提示中一起优化）的差异在于：CDSep 强制引入类型化边界，把控制流与数据流在表示层面分离，从根本上避免了协议漂移，而不是依赖正则约束或事后修复。

实验

实验设计

论文在三个任务上验证：BBH 单智能体逻辑推理、MARG review 多智能体协作文献综述生成、保险核保工作流（含合成与行业验证两个版本）。评估指标包括任务性能与协议有效性（protocol validity），基线为 naive prompt optimization（如 TextGrad）。

关键发现

在所有任务中，控制-数据流分离框架实现 100% 最终协议有效性，而 naive 基线出现协议漂移，导致路由、格式、终止信号等执行关键协议失效，最终 pipeline 崩溃。同时，任务性能持续提升，说明分离架构并未牺牲优化能力。方法将执行协议固化为类型化、验证过的程序对象，优化器仅作用于非结构化语言数据流，从根上避免 prompt 编辑破坏协议。

与基线对比的解读

与直接在文本 prompt 上做梯度优化不同，该方法将控制面与数据面分离，类似网络架构中的数据平面与控制平面解耦。naive 方法初期能提升任务表现，但多次迭代后 prompt 漂移到控制表面，系统稳定性不可保障。本文框架提供了协议稳定性保证，更适合生产级多智能体系统。局限在于固定 schema 需预先设计，可能限制协议的自适应演化。

行业影响

落地场景

多智能体 LLM 系统正被用于企业自动化流程，如 保险理赔、电商客服、内容审核等。这些系统常需通过 prompt 优化来提升任务质量，但传统优化会破坏控制协议。该框架可嵌入此类工作流，确保优化时消息路由、输出格式、终止信号等协议不漂移。

商业价值

• 降低故障率：优化导致的 pipeline 崩溃是生产环境主要风险，本方法实现 100% 协议有效性，避免线上事故和人工修复成本。
• 提升迭代效率：持续优化内容生成而不影响控制逻辑，加速多 agent 系统上线后的改进周期。
• 改善用户体验：更稳定的系统减少用户遭遇错误或卡死的概率，支撑高质量服务。

与现有产品/工作流的接口

可作为类型化配置层集成到主流 agent 框架（如 LangGraph、AutoGen、DSPy）。开发者将控制协议定义为带 schema 的 program objects，优化器仅作用于数据流 prompt，无需改动现有框架核心。类似 DSPy 声明式编程，但更显式地分离控制与数据。

具体 use case

1. 保险理赔多智能体流程：风险提取、评级、文档生成等 agent 协作，用 prompt 优化评级模型时，分离的控制 schema 确保输出 JSON 字段和路由策略不被改动，系统保持可用同时提高理赔报告质量。
2. 电商智能客服多 agent 系统：意图识别、工具调用、回复生成多个 agent，自动优化回复 prompt 时，确保工具调用参数和意图分类协议稳定，减少错误路由。

局限

• 论文自身承认 **稳定性 ≠ 正确性**，并依赖 LLM judge 评估任务性能，主观偏置难以避免；实验仅覆盖 BBH 逻辑推理、MARG 评审生成和保险评级三个任务，跨领域泛化能力未被充分验证。固定 schema 的设计也可能限制复杂或动态变化的控制流表达，对需要实时调整路由或输出格式的场景支持不足。
• 与 TextGrad、DSPy 等代表性 prompt optimization 框架的对比范围较窄，只比较了有限基线和任务，缺少对更多多智能体架构（如嵌套、异步通信）的验证。代码虽已发布，但 GitHub 星数仅 1，社区采用和第三方审查尚不充分，实际部署的可靠性仍有待观察。
• 固定 schema 虽然保证了协议有效性，但要求开发者预先定义所有控制协议，增加了初始设计成本；对于探索式 prompt 优化中可能出现的合法协议变更（如新增字段、调整终止条件）缺乏适应性。论文未探讨与结构化输出（如 constrained decoding）或类型系统的深度集成，可能错失进一步提升鲁棒性的机会。