控制流与数据流分离：让多智能体AI系统的自我优化不再崩溃

2023 年底，有团队在做一个论文评审系统的实验。他们让多个 AI 智能体分工合作，一个当"组长"，负责协调三个"审稿人"分头看论文的不同章节，最后汇总意见。为了让这个系统表现更好，他们用了一种流行的自动优化技术，不断根据结果反馈去调整每个智能体的提示词。

结果优化跑到中途，整个系统的输出变成了零。

不是变差了一点，是彻底停摆。这不是那种"模型犯了个小错"的失败，而是整条流水线直接断掉了。要理解这有多反常，你得先知道提示词优化这件事在当时已经被认为是相对成熟的技术：像 APE、OPRO、TextGrad 这些方法，都已经在各种任务上证明能自动把提示词写得比人工调的还好。没人预料到，把这套成熟技术搬到多智能体系统里，会直接把系统搞崩。

这就是这篇论文要解决的问题。

提示词的两副面孔

要搞清楚问题出在哪，得先弄明白多智能体系统里的"提示词"到底在干什么。

在一个多智能体系统里，每个智能体的行为都由一段提示词定义，这段提示词告诉它该做什么、怎么和别人协作。但仔细看会发现，这段提示词其实同时承担了两种完全不同的任务。

一种是生成内容,比如写一段论文点评、总结一段信息、给出一个理由。这些内容是给人看的,或者给其他智能体看的,本质上是自然语言,怎么写都行,只要说清楚意思就行。

另一种是控制执行流程,比如"这条消息该转发给谁""任务完不完成了""该停止了吗"。这些信息不是给人看的,是给背后那段 Python 代码看的。程序会解析智能体输出的这部分内容,然后决定接下来该调用哪个智能体、要不要终止整个流程。

问题就出在这两种东西经常被塞进同一段文字里。

组长智能体可能被要求输出一个 JSON 对象,里面有个 action 字段和一个 target_agent 字段,程序读取这个 JSON,决定该把任务转给哪个"工人"智能体。这段提示词看起来只是在教 AI 怎么写话,但实际上它也是程序和 AI 之间的接口协议。

优化器不知道这个区别。它只看到一段文字,只知道这段文字的目标是让最终结果变好。于是它可能会把说明理由的部分改得更丰富、更清楚,同时不小心也把那个 JSON 格式的说明改没了,或者改得面目全非。程序解析不出预期的字段,路由失败,整个执行链条断裂。

这就好比一份合同里,既写着"请详细说明产品优点",又写着"请在文末签字确认"。如果有人专门帮你把"产品优点"这段话改得更打动人,但没意识到"签字确认"那行字也在同一份文件里,一不小心把签字那行也改没了或者改得含糊不清。文件读起来更精彩了,但没有签字,这份合同在法律上根本不成立。如果不特意把签字栏单独隔离出来标注"这里不能动",任何一次为了提升文案质量的修改都可能误伤合同的法律效力。这正是多智能体提示词优化中发生的事情:内容质量在提升,但执行契约被悄悄破坏了。

作者观察到一个关键点:这两种角色天然有不同的表现形式。执行协议通常是结构化的,由离散的动作、固定的字段构成;而任务内容天然是非结构化的自然语言。既然表现形式不同,消费者也不同,那就不该把它们捆在同一个可编辑的文本字段里。

控制流与数据流分离

论文提出的解决方案叫控制-数据流分离

控制-数据流分离:一种设计思路,把每个智能体的输出拆成两个独立通道,一个是程序读取的结构化控制通道,一个是智能体和优化器读取的自由文本数据通道。

具体来说，每个智能体在每一步产生的输出不再是一整段混杂的文字，而是被拆成两部分:一个控制流对象 c，一个数据流消息 m。

控制流对象是类型严格的程序对象,比如 Python 里的 dataclass 或者 Pydantic 模型。它包含路由目标、终止标志之类的字段，而且这些字段的取值范围通常是提前定义好的封闭集合。程序控制器只读这个对象来做执行决策，绝不会去解析那段自由文本来判断该做什么。

数据流消息就是普通的自然语言，可以是一段点评、一个总结、一句解释。这部分内容会被记录下来，供其他智能体参考，也会被提示词优化器读取用来改进提示词，但它永远不会被程序拿去做路由判断。

这里的核心机制是所谓的"冻结提示词槽"。

Frozen Prompt Slot(冻结提示词槽):自动生成的一段格式说明文字,被单独锁定在提示词的某个位置,优化器无法读取也无法修改这部分内容。

每个智能体的控制模式对应一个 schema,系统会根据这个 schema 自动生成一段说明文字,告诉 AI 该按什么格式输出控制信息。这段说明文字被放进一个优化器碰不到的槽位里，就像信封里塞了一份不可拆封的密封条款。无论优化器怎么改写提示词的其他部分，这段格式说明永远原封不动地存在。

这就好比银行给你发的账单，账单上有一栏是"应付金额"，这一栏是打印机直接根据数据库生成的，任何人拿到账单都改不了这个数字，哪怕你想在这栏旁边写点批注解释这笔钱是怎么来的也没问题，批注区是自由的，但金额栏是锁死的。如果没有这道锁，账单被随手转发几次修改几次之后，金额栏被谁不小心涂改了，银行系统还得依赖这份纸质单子去转账，那结果可想而知。控制-数据分离要做的，正是把"金额栏"从"批注区"里物理隔离出来。

运行时的验证机制也很关键。程序控制器解析出候选的控制对象之后,会拿这个 schema 去校验。如果校验不通过,系统不会把这个无效对象当有效的用,而是会重试有限次数，实在不行就走一个预设的默认动作或者报出一个可控的失败，而不是让整个程序崩溃或者陷入死循环。

这套设计带来一个可以严格证明的性质,论文把它叫做协议稳定性保证。只要满足三个条件:路由函数只读取合法的类型化控制对象、schema 说明文字被冻结在优化器碰不到的槽位、解析或校验失败时有重试兜底机制，那么无论优化器怎么改写数据流部分的提示词，整个多智能体系统的执行轨迹都不会出现未处理的解析错误、校验错误或路由错误。

需要说清楚的是，这个保证只针对"程序不崩溃"，不保证"AI说的话都对"。控制流稳定和内容质量是两码事，论文把这一点说得很直白：一个协议完全合法的多智能体流水线，依然可能产出质量很差或者事实错误的内容。这个设计解决的是崩溃问题，不是正确性问题。

四个测试场景，一个共同的结论

为了验证这套设计到底管不管用，团队在四个复杂度递增的场景上做了实验。

第一个场景是 BBH，一个包含逻辑推理、物品追踪、因果判断、单词排序四类任务的基准测试，只用单个智能体，输出一个简单答案。第二个场景是论文评审生成，用前面提到的组长带三个工人的架构，需要处理复杂的路由决策。第三个和第四个场景都是保险核保任务，模拟保险公司给投保人评定风险等级的完整业务流程，其中一个用的是团队自己造的合成数据，另一个用的是保险行业合作方提供的、由真实核保专家评过分的合成案例（强调一下，这些数据都是虚构的，不涉及任何真实客户信息）。

对照组里，除了不优化的固定提示词和这篇论文自己的方法之外，还有一个叫朴素 TextGrad 的对照，也就是直接把 TextGrad 这种文本梯度优化技术用在整段提示词上，不做任何隔离。此外还对比了 DSPy 框架下的两种优化策略。

Stability(稳定性):论文中用来衡量多智能体系统运行可靠性的指标,表示一个任务能够顺利跑完、没有出现无法处理的解析或路由错误的比例。

结果相当一致。在论文评审生成这个任务上，朴素 TextGrad 的稳定性直接跌到 0%,意味着优化跑完之后，系统对每一份论文的评审输出全都失败了。前面提到的"系统崩溃为零输出"，指的正是这个数字。而这篇论文提出的方法在同样的任务上稳定性保持在 100%。

在行业验证过的保险核保场景里，朴素方法的稳定性也降到了 56.7%，原因是优化器把用来指定"疾病章节名称"格式的说明文字给改写坏了，导致程序解析不出该查哪个章节手册。而分离方法依然保持 100%。

有意思的是，DSPy 框架下的方法虽然没有出现这种断崖式崩溃，但用的是完全不同的机制来规避问题。比如在论文评审任务里，DSPy 把组长和工人的路由决策压缩成了一次性的前向调用，本身就没有中间路由步骤需要校验；而在核保任务上，DSPy 生成的原始输出有一部分其实并不符合 schema，只是靠后处理硬把它"掰"进最近的合法档位里，这种"事后修补"和这篇论文强调的"从一开始就不让错误发生"是两种不同的思路。

再看任务表现本身，这篇论文提出的方法在全部四个场景里都拿到了最高分。BBH 平均准确率 78.3%，超过表现最好的 DSPy 配置（74.3%）；论文评审生成的 Jaccard 指标（一种衡量评审意见和参考答案重合度的指标）达到 44.4%，高于 DSPy 最优的 43.2%；合成保险数据集准确率 50.0%，行业验证数据集上更是达到 36.7%，比保险公司自己提供的人工撰写的专业提示词（31.7%）还要高出 5 个百分点，而这份人工提示词里包含了超过 40 行的专业核保指导语句。

这里有个值得琢磨的细节。表面上看，"限制优化器能改的范围"听起来像是在给系统"上枷锁"，理论上应该会牺牲一些优化空间，换来的应该是稳定性和效果之间的权衡取舍。但实验结果显示恰恰相反：稳定性拉满的同时，效果反而是四个方法里最好的。这说明所谓的"限制"其实并没有真正削弱优化器的能力，它只是把优化器的注意力从"瞎折腾格式"上转移开，逼着它把力气都花在真正提升内容质量这件事上。

拆开来看，到底谁在起作用

论文还做了一组细致的消融实验，专门拆解这套框架里到底哪个组件在起决定性作用。

他们设计了三个可以独立开关的变量：schema 说明文字是否冻结、解析失败时是否允许重试、优化器收到的反馈是不是逐条具体的（而不是一个笼统的总分）。

结果显示，冻结 schema 说明文字这一步是稳定性的关键。在论文评审任务上，仅仅是打开这一项，稳定性就直接从 0% 跳到 100%。这说明系统崩溃的根本原因，就是优化器动了它不该动的那部分文字。

而解析重试机制带来的提升相对有限，属于锦上添花的兜底手段，在保险任务上把最后剩下的百分之一的不稳定episode给收拾干净了。

真正影响任务效果的，其实是逐条反馈这一项。在 schema 已经冻结、重试机制也开启的前提下，把优化器的反馈信号从"一个笼统总分"换成"针对每个样本的具体反馈"，论文评审的 Jaccard 分数从 26.9% 一路跳到 38.0%，保险场景的准确率从 37.8% 跳到 51.1%。

这个发现有点像给学生批改作业。如果只告诉学生"这次考试你考了 60 分"，学生很难知道具体哪里错了、该往哪个方向改进；但如果老师逐题批注"第三题公式用错了，第五题步骤漏了"，学生的进步速度会快得多。优化器也是一样，笼统的总分只能告诉它"还不够好"，具体到每个样本的反馈才能告诉它"哪里不够好、该往哪改"。如果不做这种细粒度反馈，即使协议再稳定，模型也很难真正学到有用的改进方向，这解释了为什么单纯的稳定性保证不足以带来性能提升。

崩溃是怎么一步步发生的

为了搞清楚朴素方法到底是怎么崩的，团队还去翻了优化过程中每一轮的提示词修改记录，做了细致的文本对比。

他们统计了每次优化改动的文字里，有多少行涉及控制相关的关键词，比如 JSON、输出格式、字段名称这类。结果发现，在论文评审任务上，朴素方法改动的文字里有 16.6% 触碰了控制相关的内容，而这篇论文提出的方法只有 4.2%，差了将近四倍。

论文里给出了几个真实的例子。有一次，工人智能体最初的提示词里明确写着"请在第一行输出一个 JSON 对象，包含 status 和 section 两个字段"，还给了具体示例。但经过五轮优化之后，这段格式说明彻底消失了，取而代之的是大段关于"如何写出高质量评审"的指导语句，JSON 格式的痕迹一点没剩。结果就是，这个工人从此每次都直接输出一段自然语言，程序解析不出预期字段，组长永远收不到"工人完成任务"的信号，整个流程卡死。

还有一次，组长智能体原本的提示词里写着"输出格式包含 action 和 target_agent 两个字段"，优化之后 target_agent 这个词从提示词里彻底消失，只剩下 action 作为一个普通英语单词残留在句子里，程序找不到路由目标字段，路由决策直接失败。

这两个例子说明了同一件事：文本梯度这种优化信号本身分不清"这段话是在讲道理"还是"这段话是在定协议"，它对两者一视同仁地进行改写，一旦协议部分被无意间抹掉，后果就是整条流水线的停摆。

这套方法在不同 AI 模型家族上表现如何

一个自然的疑问是，这套设计是不是只对某一家的模型管用。团队专门在 OpenAI、Anthropic（也就是 Claude 系列模型的开发商）和 Google 三个不同厂商的模型上重复了论文评审这个实验。

结果三个厂商的模型上，这篇论文提出的方法全都保持 100% 的稳定性，而朴素方法在三个厂商上无一例外都是 0%。这说明协议崩溃这个问题不是某个特定模型的性格缺陷，而是这类优化技术本身的结构性风险，跟具体用哪家的大模型没关系。

写在后面

看完这篇论文，我最先想到的是一个很朴素的比喻，但一开始没往这个方向想：这不就是软件工程里"接口和实现分离"的老思路吗？读到论文里明确写着"控制-数据分离遵循的是既有的软件工程原则，而不是发明了一套新的类型系统或分离理论"，我才反应过来，这篇论文的贡献不在于提出了一个多新颖的理论，而在于把一个软件工程里几十年的常识，用一种恰到好处的方式嫁接到了 AI 提示词优化这个新场景里，并且把它做成了可以被强制执行的程序接口，而不是一句"请注意格式"的君子协定。

论文里有个细节我觉得特别值得单独说一说：他们统计了控制相关词汇被误改的比例，发现即使是他们自己的方法，也不是 0%，还有 4.2% 的"意外触碰"。这说明就算你把控制部分单独隔离出来，只要优化器还能看到相关的上下文信息（比如智能体之间互相引用的历史对话），语言层面上的"污染"依然会有微量渗透，只是不会真正影响到那个被锁死的执行接口。这提醒我，工程上的"完全隔离"往往是相对的，真正起作用的不是杜绝一切接触，而是确保关键判断点不依赖那些可能被污染的信号。

还有一点让我意外：这篇论文用的四个测试场景里，风险最高的两个，也就是论文评审生成和保险核保，恰恰是路由逻辑最复杂的两个。而相对简单的单智能体推理任务和线性流程的合成保险数据，朴素方法反而没有崩溃得那么彻底。这说明协议崩溃的风险和系统的"路由复杂度"成正比，越是需要智能体之间动态决定"接下来该找谁"的系统，越容易在提示词优化过程中被悄悄破坏。这对现在越来越流行的、动态编排的多智能体架构是个警示：架构越灵活，越需要在灵活的地方之外，把不该灵活的地方钉死。

这套思路会不会推广到更复杂的场景，比如智能体数量动态变化、角色实时创建的系统？论文自己也承认这是还没做的事情。控制模式目前还是提前写死的，如果哪天智能体可以在运行时自己商量着造出一个新角色，这个新角色的控制协议又该怎么定义、怎么锁定？这个问题留在那里，没有答案，但足够让人琢磨一阵子。

Q&A

Q1：控制-数据流分离是什么？

A：这是一种让多智能体AI系统提示词优化更安全的设计方法，把每个智能体的输出拆成结构化的控制通道和自由文本的数据通道，程序只读取经过验证的控制通道来做路由和终止决策，优化器只能修改数据通道的内容，无法碰触控制通道的格式规则。

Q2：为什么普通的提示词优化会让多智能体系统崩溃？

A：因为提示词里同时混杂着"给AI讲道理的内容"和"给程序解析用的格式协议"，优化器分不清两者的区别，改进内容表达时容易连带破坏格式说明，导致程序解析失败、路由错误甚至整个系统停摆，论文实验显示这种崩溃在论文评审生成等复杂路由场景下稳定性会跌到0%。

Q3：这套方法实际效果如何，会不会牺牲优化空间换稳定性？

A：实验显示不会。在BBH推理、论文评审生成、合成及行业验证保险核保四个场景中，该方法在保持100%协议稳定性的同时，任务表现也全部优于对照方法，比如保险核保准确率达到36.7%，比人工撰写的专业提示词还高出5个百分点。