如果你最近在看 AI Agent 相关的资料大概率会被一个问题卡住单个 Agent 能干活已经不稀奇了Agent 和 Agent 之间到底是怎么配合的我一开始也看得一头雾水直到拿“学术评审”这个场景完整做了一次实验才把多 Agent 互动的门道摸透。这篇笔记不聊概念就聊我这次搭建的完整思考、交互模型设计、状态机编排以及实际跑起来之后踩过的一堆坑。我为什么选“学术评审”当样板因为这个场景像是给多 Agent 协作量身定做的有明确的分工、有轮次、有状态流转、有评审标准、还有最终决策。说白了它天然就是一个“多角色、多轮次、强约束”的智力协作流程。这套东西想明白了不只是学术圈能用任何“多人评审、会签、审批”类的业务都能套用。这篇笔记适合正在研究多 Agent 架构、准备做 Agent 编排或者想把自己业务流程 Agent 化的朋友参考。1. 为什么拿“学术评审”当 AI Agent 互动的样板1.1 学术评审本身就是一张多 Agent 协作网络先别急着写代码先把场景看清楚。一篇论文从投稿到录用中间至少要有作者、编辑、多个审稿人、决策者这几类角色参与。这里的每一步都不是那种“问一句答一句”的简单对话编辑要判断稿件主题是否匹配然后分发给合适的审稿人审稿人各自独立阅读给出意见、评分和推荐结论编辑汇总多方意见后要么直接决策要么返修要么退稿返修后的稿子还会再回到部分审稿人手里复核。这种流程有一个很关键的属性每两个 Agent 之间并不需要直接聊长篇自然语言它们各自掌握一段上下文输出一个结构化结论然后被下一个环节消费。这和现在很多 demo 里“两个 Agent 疯狂对话直到达成共识”的玩法完全不同。我当时先画了一张角色关系图才意识到学术评审本质上就是一个 事件驱动 状态机 的系统。你不需要让 AI 自由发挥你需要的是把人类评审流程里的协作规则翻译成 Agent 之间的交互契约。1.2 人肉评审的痛点正好是 Agent 化的机会点人肉评审几乎没有哪个环节是顺畅的。审稿人难约、周期长、意见主观、偶尔还有人情稿和偏见。这些问题长期存在但都不是“某个人不够努力”而是流程本身的结构性问题。如果要拿 AI Agent 来改善就不能只做一个“帮你改论文的机器人”那是单 Agent 的单点替代。真正有价值的是把整条协作链路重构一遍稿子提交后让一个 Agent 做格式与完整性初筛几个专业审稿 Agent 并行评估一个合规 Agent 做伦理与利益冲突检查最后再由一个决策 Agent 汇总出建议。每一步的结果都是结构化数据谁都能审计谁都能回滚。这套思路对工程师来说很有参考价值因为你不是在做学术工具你是在用 Agent 重写一条“多人协作流程”。做市场活动审批、合同会签、代码评审换一下领域词架构几乎一模一样。2. AI Agent 之间到底怎么“对话”主流互动模式拆解2.1 四种互动模式先建立坐标系我在实验里发现多 Agent 协作的交互方式归纳下来就是四种其他的基本都是这四种的组合直接消息传递Agent A 明确把结果发给 Agent BA 知道 B 存在B 也知道消息来自 A。就像两个同事私下对接高效但耦合度高。共享黑板所有 Agent 往一个公共空间里写信息需要的人自己来读。就像团队共用一个云盘文档谁更新了状态其他人打开就能看到。集中调度一个调度者把任务派给多个执行者执行者把结果交回给调度者。就像项目经理分活收活大家不直接互相沟通都通过项目经理中转。发布订阅Agent 往某个主题里发消息其他 Agent 按需订阅。就像部门群里发了公告关心的人自己进来认领不关心的人不受打扰。这四种模式没有孰优孰劣只有合适不合适。直接消息适合固定链路黑板适合状态共享集中调度适合流程控制发布订阅适合一对多广播。真实系统里几乎不会只用一种混着用才是常态。2.2 学术评审场景里怎么选互动模式我在设计评审流程时对不同环节做了不同选择外审阶段用的是“并行裁决”模式三名审稿 Agent 在同一轮并行工作各自独立读稿、独立给意见。它们相互之间不做任何通信只把评审结论写进共享存储这就是典型的共享黑板模式。这么做的原因很简单避免审稿人之间的立场污染。编辑汇总阶段则回到集中调度。主编 Agent 是唯一的总控它决定各个阶段的推进接收所有结果并触发下一轮状态。这个调度者的存在非常关键没有它整个流程会陷入无序对话。作者反馈那一段我用的是直接消息作者 Agent 的修改说明只发给需要复核的审稿 Agent而不是广播给所有人。这能有效减少无关 Agent 的上下文干扰。讲到这里我想多说一句很多多 Agent 项目跑飞掉根源不是模型不行而是交互模式选错了。两个 Agent 一对一无边界聊天看起来热闹实际上既没有收敛条件也没有责任边界。学术评审这个场景教给我的最重要一课就是给 Agent 划定交互边界比给 Agent 更强的模型更管用。3. 一套可落地的学术评审 Agent 编排方案3.1 五个角色明确职责边界我最终设计的方案里一共五个角色每个角色只做一件事Agent 角色核心职责输入输出主编 Agent流程总控决定状态流转投稿事件、各阶段结果评审决策、返修指令初筛 Agent格式、完整性、主题匹配检查论文全文、投稿元数据是否进入外审专业审稿 Agent并行多个从不同角度评估学术质量匿名化稿件、评审标准评分、意见、推荐结论合规 Agent检查伦理、利益冲突、数据合规稿件全文、作者声明合规风险标记决策 Agent汇总多方意见生成决策建议所有结构化评审意见建议接收/返修/退稿这里有个重点专业审稿 Agent 不是只配一个而是并行跑三个。每个 Agent 的角色视角不同比如一个偏方法论一个偏实验结果一个偏创新性。它们在生成意见之前互相看不到对方在写什么这样才能保住评审的独立性。我在实验里把这三个审稿 Agent 做成并发执行实测下来吞吐量很可观。这也是多 Agent 系统相对单 Agent 很实在的一个优势多个 Agent 并行跑瓶颈不再是单次推理时长而是你为它们准备的那张“共享黑板”能不能扛住高并发写入。3.2 状态机让流程有约束而不是让 Agent 自由发挥学术评审最忌讳的就是流程失控。我用一个显式的状态机来控制整体流转每个状态对应一个明确阶段当前状态触发事件下一个状态已提交稿件通过格式初筛外审中已提交稿件未通过格式初筛退稿外审中所有审稿意见回收完毕合规审查合规审查合规检查通过决策汇总决策汇总决策 Agent 给出“小修”返修中返修中作者提交修改稿复核中复核中审稿人确认修改到位已接收状态机的存在让 Agent 之间没有“商量”的空间该流转就流转该停就停。这套设计的核心价值在于可回滚、可审计。任何时刻你都能看到一篇稿子处于哪个阶段已经过了几轮谁在哪个环节卡住了。实际跑系统时这种确定性非常宝贵。我给这个状态机加了一个硬性防死循环机制任何一篇稿子最多只能经历两轮返修超过轮次直接走退稿。没有这个规则模型很容易在一次又一次“修改—复核—再修改”里无限绕圈而且还每轮都信心满满地告诉你“这次有实质提升”。3.3 消息路由Agent 之间传结构化数据不传长篇大论评审过程中 Agent 之间要交换意见我经受的最实用的设计是一律传结构化 JSON不传自由文本。比如专业审稿 Agent 的输出长这样review_result { paper_id: PAPER-2024-001, reviewer_id: reviewer_methodology_01, recommendation: major_revision, score: 62, summary: 方法论设计整体清晰但对比实验规模不足。, major_concerns: [ baseline 对比缺少 2023 年后的 SOTA 方法, 消融实验只做了 3 组样本量不足以支撑结论 ], minor_concerns: [公式 7 的符号定义与上节不一致], confidence: 0.78 }为什么这么做两个原因。第一决策 Agent 解析结构化字段要比解析整段自然语言稳定得多也不会把审稿人的客套话误读成学术态度第二限制 Agent 的输出格式本身就能降低幻觉强制它把“主要问题”和“次要问题”分开列它编造的难度会显著增加。消息路由上我用的是主题订阅加共享存储的混搭方式。审稿 Agent 把结果写入共享存储并发布一条“评审完成”事件主编 Agent 订阅这个事件等三个结果都齐了再做下一轮决策。顺带一提这种做法天然支持并发您可以对比单 Agent 串行评审和三个 Agent 并行评审的耗时外审时间几乎能压缩 50% 以上。4. 多 Agent 系统里那些让我反复踩的坑4.1 坑一Agent 之间“客套式认同”意见失去独立性第一次跑通流程时我加了一个由三个审稿 Agent 和一个主编组成的简化版流程。结果让我大跌眼镜三个审稿 Agent 的评分非常接近而且连“次要问题”的描述都表现出明显的趋同。问题出在我把所有 Agent 的上下文串在了一条链路里第三个审稿 Agent 能看到前一个审稿 Agent 的意见它自然就顺着写了。这就是典型的上下文污染。你要保住独立性就得在审稿阶段做信息隔离。我后来把共享存储改成按 reviewer_id 分块隔离每个审稿 Agent 只读稿件评审准则完全看不到其他人的意见。改完之后三个 Agent 的分数分布一下子就正常了偶尔还会出现“一票反对两票同意”的合理分歧。4.2 坑二返修循环死锁Agent 互相拉扯停不下来第二个坑出现在返修复核环节。作者 Agent 修改了稿件审稿 Agent 复核后认为改动不到位又提出新问题作者 Agent 再次修改审稿 Agent 基于新一轮上下文又提出第三批问题。这个循环一直到我把状态机的返修轮次上限触发才算强制终止。这个问题的根子在于我让审稿 Agent 在每次复核时都能自由提出“新问题”。但从流程设计角度看复核阶段的职责是验证“上一轮提出的问题是否解决”不是“再新增一堆此前没提过的要求”。我后来在审稿 Agent 的复核 prompt 里加了一行硬约束“本轮只评估上一轮 major/minor concerns 的解决情况不得提出未在前期评审中出现过的新问题”。这之后死循环基本消失。4.3 坑三上下文无限膨胀Agent 越审越“健忘”多轮评审最大的隐形杀手是上下文长度。我在实验里跑到第二轮返修时发现专业审稿 Agent 已经快记不住“第一轮意见”和“当前版本”之间的对应关系了它开始出现一种奇怪的症状拿第一轮的旧意见去评估第三轮的修改稿。后来我吸取教训不再把完整评审历史整本丢给 Agent而是维护一张评审摘要表每轮结束只把“上一轮的意见清单本轮修改说明修改稿关键片段”注入上下文。这段三件套足够它做出判断同时也保住每轮评估的焦点。上下文精简之后审稿 Agent 的判断稳定性和响应速度都有明显提升。4.4 坑四主编 Agent 吞掉少数派意见第四个坑更隐蔽。我发现决策 Agent 存在一种“多数派偏好”——当两个审稿 Agent 建议接收、一个建议退稿时主编 Agent 几乎总是一边倒地采纳多数意见甚至会在最终意见里把自己的置信度调得很高。时间一长少数派的反对意见事实上被系统抹掉了。这在学术评审里是很危险的。我加了一个“少数派保护”机制只要三个审稿结果里存在一票反对或者两个审稿 Agent 的推荐结论冲突决策 Agent 就不能直接给最终结论必须将案例转给人工复议队列。这套规则让系统的激进决策率大幅下降代价就是多了一些人工介入但流程的稳健性明显好很多。5. 常见问题速查与我的排障经验5.1 一套可以直接抄的问题速查表把这段实验时间里遇到的问题整理成一张表方便后续再搭类似系统时快速定位症状可能原因排查思路落地解法多个 Agent 给出几乎一致的意见上下文污染审稿人互相看见意见检查共享存储的读写权限按 reviewer_id 隔离上下文审稿 Agent 反复提新旧混杂的问题复核阶段不限制新问题检查复核 prompt强制只评估上一轮 concernsAgent 记不住第一轮的意见多轮历史全部堆积在上下文里观察 token 消耗用摘要表截断历史返修循环无法结束状态机缺少轮次上限检查状态流转配置加入返修轮次硬上限多数派意见压制少数派决策 Agent 倾向迎合多数审计决策置信度分歧时强制人工复议审稿意见编造原文没有的数据输出约束太弱检查审稿 Agent 输出格式强制结构化输出引用原文片段某个 Agent 长时间无响应并发超时导致整体流程挂起检查调度器逻辑设置超时和重试机制5.2 我的排障顺序和独门技巧排查这类系统问题我的习惯是从“确定性问题”往“模型问题”查。第一步永远先看状态机走没走对是哪个环节卡住了第二步查消息路由有没有丢事件、有没有超时重试第三步才轮到怀疑模型去看那一步的 prompt 和上下文。按这个顺序来能少走很多弯路。最后分享一个我花了不少代价才学到的技巧给审稿 Agent 的评审准则里一定要有锚点数值而不是模糊形容词。最开始我写的是“高质量论文可考虑接收”结果不同 Agent 对“高质量”的理解偏差大得离谱。后来我把评审准则改成“方法对比实验不少于 5 组 baseline”“结论部分必须有消融数据支撑”这类可判定的条款审稿结果的可信度一下子高了很多。Agent 不怕规矩多怕的是规矩含糊。这套学术评审 Agent 的互动设计做完之后我最大的体会是多 Agent 系统的瓶颈往往不在“智能”而在“流程设计”。你把角色边界划清楚、把交互模式选对、把状态流转控制住剩下的大模型部分反而不是最难的了。现在我在做其他协作型 Agent 系统时都会先把这张角色表和状态机画出来再考虑往里填什么样的模型和能力。你也可以试试先拿一个自己熟悉的业务流程走一遍这套方法大概率会发现原来 Agent 之间协作真正值钱的是规则不是对话。