当一个系统里同时存在几个基础模型时最让人头疼的往往不是某个模型能力不行而是你没法确定另一个模型到底在按什么逻辑做事。你可能已经遇到过这类场景一个模型负责规划另一个模型负责执行结果规划模型给出的步骤执行模型认为不符合约束两个模型基于同一个任务目标却在上下文里互相拉扯最后谁也不让步。于是有人会想能不能给它们签一份“合作协议”让它们在出现分歧时选择合作我的判断是真正的突破口可能不是协议本身而是“相似性推理”。最近有一个研究方向把博弈论引入基础模型思路大意是为基础模型之间的理性合作找到一条新路径而这条路径依赖的不是共享参数、不是统一规则而是通过对相似性的推断来识别谁适合合作。这个方向听起来很理论但它恰好回答了一个非常工程化的问题当多个模型无法直接读取对方的参数、意图和价值观时凭什么相信对方会按合作的方式行动有意思的是这个问题一旦被说破你会发现它不只是论文里的抽象建模也直接关系到我们平时做多智能体系统、模型路由、跨团队模型接入时遇到的那些不稳定的协作问题。1. 基础模型协作的真正瓶颈不是能力而是“看不透彼此”1.1 多模型协作已经是真实需求不再只是实验今天把多个基础模型放进同一个工作流里早就不再是新鲜事。常见的有这么几类场景多智能体框架里不同模型扮演规划、执行、审查、总结等角色任务被拆给不同模型完成。模型路由场景中系统根据请求内容把任务分发给不同模型再汇总结果。集成推理场景里多个模型对同一个问题给出答案然后通过投票或加权融合得到最终输出。跨团队协作场景里企业内部不同部门各自维护一个模型服务希望在共享任务上相互调用。这些场景都有一个共同点参与协作的模型彼此之间没有能力“打开对方看看”。你不能直接读取另一个模型的权重不能保证对方和你的系统消息完全一致也不能假设对方默认会优先保证你的关键指标。这就是基础模型协作的第一层瓶颈——不是推理能力不够而是协作所需的信息极其有限。1.2 传统协作控制方式为什么在这里失效在传统的软件工程里多模块协作通常靠三样东西共享状态、统一接口、中心化调度。模块之间通过明确的数据结构交换信息调度器负责指派任务失败时返回错误码。这种方式的前提是每个模块的行为是可预期的接口是稳定的调度者能看见全局。到了多基础模型协作里这套思路开始松动。你也可以设计一个中心化编排系统让所有模型都按统一格式输出再由调度器做决策。这种方案在小型系统里完全可行。但它本质上不是“模型之间在合作”而是“一个中心系统在控制所有模型”。一旦某个模型偏离了系统预设的格式或者输出看起来合规但实际行为不一致中心调度器很难提前察觉。更麻烦的是当你引入的是不同团队、不同厂商提供的模型服务时你只能拿到通过 API 暴露出来的输出拿不到模型内部的任何状态。这就带来一个很有意思的问题多个模型之间怎么在没有中心化完全控制的条件下形成一种“自发但稳定”的合作关系1.3 黑盒条件下的核心困境意图和能力不可直接观测两个基础模型交互时真正能观测到的是什么是输出文本是工具调用序列是延迟是置信度标记是偶尔露出的中间推理步骤。除此之外关于对方模型的内部目标、训练数据分布、价值对齐程度、上下文是否被篡改你几乎一无所知。这种情况下最自然的想法是让模型直接“对话”。你可以给一个模型一段提示词让它主动与另一个模型沟通、确认、谈判。但问题在于基础模型可以通过语言生成各种各样的“表态”它完全可能表面上同意合作实际上并没有按合作意图执行。你没有办法从一两句对话里判断对方是否真的值得信任。这个困境在博弈论里非常经典参与人互相不知道对方的类型和收益结构只能看到对方采取的行为。于是如何从行为中推断对方是否与自己“同频”就成了决定能否合作的关键。1.4 博弈论为什么在这个时候重新变得有用传统博弈论研究理性决策者在相互影响的环境里如何选择策略。它关心的核心问题是在什么条件下理性个体会选择合作而不是背叛纳什均衡、声誉机制、重复博弈、信号传递这些概念本来就是为了处理“有限信息下的互动决策”而发展起来的。基础模型协作正好落在这个问题框架里。每个模型都是一个参与者它可以选择配合系统目标也可以选择只顾自己的局部目标。双方都不知道对方的完整信息只能通过观察对方的行为来调整自己的策略。如果这个互动会重复发生一个聪明的模型就会意识到为了将来还能合作自己需要建立可靠的行为记录同时也需要判断对方是否可靠。这个视角带来的不是某个神奇算法而是一整套分析协作问题的方式。而“相似性推理”正是在这套方式里被推到了前台。2. 相似性推理如何成为“靠谱协作”的切入点2.1 相似性推理从“完全信息”走向“行为线索”我们换个角度理解问题。如果两个人要合作但是彼此没有任何背景了解你凭什么判断对方值得信任大多数时候你会看对方说话的方式、做事的节奏、出现分歧时的反应。如果对方的价值观和做事习惯与你相近你就更愿意先合作一轮试试。基础模型之间的相似性推理思路非常接近。它不要求模型之间共享内部参数也不要求一个权威仲裁者来保证对方可信只需要建立一个共同的行为空间。每个模型把自己的输出、决策过程、工具调用方式映射到这个空间里然后判断另一个模型的行为是否与自己期望的模式相似。如果相似度高就认为对方更可能持有相近的目标可以进入下一步协作如果相似度低就保持距离、降低共享信息的级别甚至拒绝合作。这种机制不依赖“对方一定诚实”的理想假设而是把信任建立在对可观测行为的持续评估上。2.2 行为签名一个模型如何“自证”自己可信在具体的系统设计里每个模型可以维护一个“行为签名”。这个签名不是模型自报的意图而是从它实际行为中提取出来的特征。常见的“行为签名”可以包括同一任务多次执行时输出是否稳定。面对冲突指令时是否优先遵循用户硬约束。输出结构的规范性是否保持统一格式。工具调用序列是否符合任务上下文。对模糊问题的处理方式是主动澄清还是强行猜测。两个模型如果这些行为特征接近那么在同一个任务流里它们更容易对齐预期。因为它们对“任务应该怎么做”的判断标准比较接近不容易反复出现互相推翻的情况。这就像两个代码风格相似的人合作写项目比一个习惯极端重构、另一个习惯最小改动的人协作起来更顺畅。不是说风格不同就不能合作而是在缺乏充分沟通条件时风格相近本身就能降低协调成本。2.3 重复博弈与声誉机制相似性识别带来的是长期理性只看一次相似性还不够。真实系统里模型之间的交互通常不是一锤子买卖。你今天让两个模型协作明天还有新的任务进来。这样一个重复博弈的设定下每个模型的行为就会产生“声誉”效应。如果模型 A 发现自己只要在行为上与模型 B 保持相似、协调就能更高效地完成任务它就有动力继续这样做。反过来如果模型 A 发现了模型 B 的行为偏离了共同基线它可以在后续任务中降低合作级别。这个机制不需要一个裁判来解释“谁对谁错”只需要每个参与者基于相似性推断不断调整合作策略。最终达到的稳定状态可以理解成一种“理性合作”合作不是因为模型天生善良而是因为在一个可重复、可观察、可反馈的环境里合作比背叛带来更高的长期收益。相似性推理的作用就是帮助模型识别出那些“适合合作”的对象避免把精力浪费在完全不可预测的交互上。2.4 为什么不是“道德合作”而是“理性合作”评价这类机制时要特别注意一个容易误读的地方相似性推理解决的不是价值对齐问题而是协调成本问题。它不让模型变得更有道德也不保证模型输出的内容一定正确。它只是在给模型一个更加务实的生存策略选择和自己行为模式相近的对象协作降低不确定性提高长期收益。这个定位很重要。如果你期待它能让所有模型“善良起来”一定会失望。如果你把它理解成一种防御性的协作策略就会发现它天然适合那些不想暴露内部信息、又想提高合作概率的系统。3. 一个可参考的最小落地框架相似性评估驱动的多模型协作理论要落到工程上不能只停留在概念层面。好消息是相似性推理并不需要非常复杂的基建才能试点。你可以用很小的代价搭建一个最小可用的多模型协作实验。3.1 五步流程注册、采样、评估、协议、反馈我从工程实践的角度给出一个最小流程你可以按这个顺序去搭注册行为基线每个参与协作的模型先在一组标准任务上执行一次记录它的行为签名。这组任务要覆盖你业务里的典型输入、典型冲突和典型边界情况。持续采样行为在真实协作过程中记录每个模型在每轮任务中的输出、中间决策和工具调用序列。不要只记录最终结果否则很多协作失败的线索会丢失。计算相似性把新采样的行为特征与基线或其他模型的行为特征做比较得到一个相似度分数。这个分数是后续协议决策的依据。按协议决定合作级别相似度高于阈值允许深度合作、共享更多上下文中等相似度只允许有限协作低相似度不合作或只走隔离通道。反馈更新每一轮协作结束后把结果写入反馈日志更新模型的行为基线或声誉记录。注意这个更新不是改模型参数而是更新系统对模型的动态画像。3.2 相似性度量怎么选三类信号各有使用场景在当前工程条件下最常用的行为信号有三类信号类型说明适合场景主要风险输出嵌入相似度对模型生成的最终文本做向量化计算余弦相似度快速判断输出语义是否接近表达风格不同但语义一致的模型可能被误判决策轨迹相似度比较工具的调用顺序、中间步骤、分支决策复杂任务、多步骤协作需要额外埋点采集成本更高行为一致性统计同一输入多次执行统计输出的稳定性衡量模型行为是否可预测稳定不等于正确可能稳定地偏离目标实际项目里我更建议不要只用单一信号。一种比较稳妥的做法是用输出嵌入相似度做初筛用决策轨迹相似度做二次确认再配合行为一致性统计做长期监控。3.3 阈值和协议参数先保守再放开很多人在搭这一类系统时最容易犯的错是一上来就把相似度阈值设得很低希望让所有模型都能合作。结果就是不稳定的协作关系进入正常流程最后系统行为变得不可控。我更推荐“先保守再放开”的参数策略初始阶段把相似度阈值设得高一点宁可漏掉一些潜在可合作的模型也不要让不可靠模型进入核心链路。用一段观察期积累数据看看相似度分段和协作成功率之间的关系。根据实际表现逐步调整阈值。比如当相似度在 0.75 以上的协作成功率明显高于 0.6 到 0.75 这个区间时阈值就应该放在 0.75 以上。注意不要一上来就把相似度阈值定死也不要只用一次协作结果就更新一个模型的信誉。先跑通小样本再谈调参。3.4 隔离机制低相似度模型如何处理低相似度不一定是模型能力不行更可能是目标函数、提示词偏好、输出风格差异太大。遇到这种情况正确的处理方式不是消灭它而是隔离它。隔离可以分几个层次不共享关键上下文只给最小必要信息。不进入联合决策链路只允许它处理独立子任务。增加人工审核或额外校验环节。如果某个模型频繁出现低相似度又导致任务失败就把它从协作列表里暂时移除。这种隔离机制的核心价值在于它让系统的安全性不依赖于每个模型都是“好合作者”而是让系统有能力识别并管理“不适合合作者”。4. 把这个框架落地时最容易踩的四个坑4.1 把训练数据相似当成了行为相似这是第一个容易误判的地方。两个模型可能在同一批公开语料上做过训练输出的文本风格接近但它们被微调的目标完全不同。一个模型追求全面详细另一个模型追求简洁直接看起来“相似”的输出背后可能是完全不同的行为策略。所以不要只从输出文本的语义相似度下结论。关键是看它们遇到冲突指令、模糊任务和资源受限场景时的反应。行为相似性要建立在“决策反应”上而不是“语言风格”上。4.2 只看单轮输出不看决策路径基础模型的很多任务不是一次生成就结束而是会经历多轮推理、工具调用、结果修正。只看最终答案很容易错过真正的行为差异。举个例子模型 A 和模型 B 可能最终都给出了正确答案但 A 是通过查数据库得到的结果B 是通过自由生成猜出来的结果。从预测结果看两者相似从决策路径看两者完全不同。如果你只计算最终答案的相似度就会把一个不可靠的猜测者当成可靠协作者。因此在条件允许的情况下优先记录中间决策轨迹。哪怕只记录“是否调用了检索工具”“是否主动质疑输入条件”“是否在边界情况下请求澄清”都比单纯记录最终文本有价值得多。4.3 对“理性”的假设过于理想化博弈论模型里通常假设参与者是理性的会追求自身收益最大化。但真实的基础模型不是这样的“理性主体”。它可能受到系统提示词、上下文长度、输出格式限制甚至随机采样温度的影响。同一个模型在不同请求里可能表现出完全不同的偏好。这也是为什么不能直接把论文里的理论结果当成现成工程方案来用。理论价值在于提供分析框架但工程落地时必须考虑模型行为的不稳定性。你要做的是不断采样、观察、修正而不是假设模型会永远理性地选择合作。4.4 把协作失败全部归结为模型内部问题最后这个坑非常隐蔽当多个模型协作出现矛盾你不一定需要归因到模型智能水平。很多矛盾来源于信息不对称。比如模型 A 在规划时看到了完整用户背景但传达给模型 B 时只给了概要模型 B 因为缺少细节给出了一个看起来冲突的判断。这种情况下两个模型本身都没有出大问题问题出在协作流程的上下文传递不完整。在排查协作失败时先检查两边的输入上下文是否一致再检查双方是否看到了同一套约束条件最后再讨论相似度阈值和合作级别。大部分实际故障往往发生在信息传递层而不是模型博弈层。排查顺序通常建议是先看现象再看双方输入的差异接着看行为采样是否完整然后看相似度阈值和协议参数最后再看是否存在模型能力或目标层面的根本冲突。5. 对构建多智能体系统的工程启发5.1 三层视角行为层、协议层、收益层从相似性推理这个方向我们可以提炼出一个更通用的多智能体系统设计视角。一个健壮的协作系统需要同时考虑三个层次行为层每一个模型行为是否可观测、可记录、可比较。这一层决定你能否感知协作危机。协议层模型之间约定交换什么信息、在什么阈值下合作、在什么情况下退出。这一层决定系统如何处理感知到的差异。收益层模型选择合作给它带来的收益是什么选择背叛需要承担什么代价。这一层决定协作是否可持续。很多多智能体系统设计之所以混乱是因为只考虑了协议层希望用一套规则约束所有模型却忽略了行为层没有观测数据、收益层没有惩罚机制。协议写得再漂亮模型也不会理性遵守。5.2 什么时候值得引入相似性推理机制不是所有系统都需要相似性推理。适合引入的信号包括模型来自不同团队或不同厂商无法共享内部参数。系统会长期重复运行存在多轮任务交互。某个模型的行为可能随任务变化而偏移。协作结果不稳定但排查不出单一故障原因。需要一个不依赖中心仲裁者的动态信任机制。如果你的系统完全由自家团队控制、模型可以统一配置、行为高度稳定那么传统的中心化编排模式往往更简单、更高效。没有必要为了引入博弈论而增加复杂度。5.3 什么时候不该用同样重要的是要知道这个方法论不适合什么场景不适合场景原因单模型内部多任务调度不需要用模型间博弈解决问题完全受控的固定管道中心化编排更直接、成本更低对结果有严格正确性要求相似性推理只能改善协作稳定性不能保证正确模型能力不足行为相似但能力不足协作再多也没有意义非重复任务只有一次交互时声誉机制和重复博弈很难起效5.4 一个判断清单如果你的团队正在考虑把多个模型放进同一个协作流程我建议先过一遍这个清单我有没有办法持续记录每个模型的行为特征我是不是只在系统出现矛盾时才去看模型输出我是否知道模型之间看到的上下文是否完全一致我有没有定义“不同模型可以协作到什么程度”的分级协议如果一个模型反复表现异常我有没有自动隔离它的机制如果大多数答案是否定的那么无论用多少理论框架系统的稳定性都会停留在靠运气阶段。6. 下一步从论文概念到工程实践6.1 先复现一个具体问题而不是复现整个理论面对这类偏理论的工作最常见的错误是试图原样复现论文里的完整框架然后立刻接入生产系统。这个想法通常行不通因为论文中的假设、实验条件和工程环境往往差异很大。我更建议先挑一个具体的协作不稳定问题来做尝试。比如两个大模型在交叉审查任务里经常互相否定你先采集一段时间的行为数据看看相似性评估结果能不能提前预测不稳定的协作组合。先有这个“可观测、可复现、可改进”的小循环再考虑要不要扩大成完整博弈框架。6.2 建立观测面是第一步不管最终是否使用相似性推理工程上最重要的一步都是先把观测面建起来。你需要知道每个模型在每次任务里接收了什么输入、生成了什么输出、调用了哪些工具、得到了什么反馈。没有这些数据一切关于“模型是否理性合作”的判断都是空谈。有这些数据你才能理解协作失败到底发生在哪一层。6.3 从双智能体扩展到多智能体验证阶段建议先从两个模型开始。为它们设计一个存在目标冲突的任务场景加入不同水平的相似度阈值观察系统是否会根据相似性评估结果自动调整协作方式。跑通之后再加入第三个模型让其中一个是低相似度模型验证隔离机制能否生效。这个扩展路径很慢但很扎实。多智能体系统里失败往往不是来自单一模型而是来自多个模型之间的组合效应。先理解两两关系再理解三角关系最后才是全网络关系。6.4 保持理论视角但不照搬结论回到文章开头那个问题多个基础模型协作时真正的瓶颈不是能力而是“看不透彼此”。博弈论和相似性推理的价值在于提供了一种在看不透彼此的情况下仍然可以维持理性合作的路径。这个路径没有把“合作”寄托在模型的道德感上也没有假设一个全能的中心调度者而是回到可观测的行为本身用持续的比较、推断和反馈让系统里的每个协作关系都变得可评估、可调整、可退出。对一个长期和模型打交道的人来说这个思路带来的启发可能比具体算法更持久任何时候当你无法控制一个庞大复杂的协作系统时先不要急着设计更复杂的规则而是先让自己拥有足够可靠的观察能力。有了观察才有推断有了推断才有真正的合作。如果你现在正被多模型协作搞得焦头烂额建议从今天开始把每个模型的输入、输出和决策过程完整记录下来。不用先上复杂的博弈框架先把观测面补齐。这一件事做好了后续的稳定性和可控性都会容易得多。