把 AI Agent 从一个“单兵作战”的工具变成一个“集团协作”的系统是我最近一直在琢磨的方向。正好手头在做一套学术评审的模拟流程借这个机会把 AI Agent 之间的互动方式彻底梳理了一遍。这篇笔记会用“AI Agent 参与学术评审”这个具体场景把多 Agent 系统的设计思路、互动模式、落地实现和踩坑经验完整讲清楚。不管你是刚接触 Agent 开发还是已经用 LangChain、LangGraph 这类框架写过几个 Demo这篇文章里的内容都能直接拿去做参考。1. 为什么选“学术评审”当作多 Agent 互动的沙盒1.1 学术评审天然是一个多角色协作流程学术评审这件事本身就是个典型的多角色、多阶段、有明确输入输出的协作流程。一篇论文投出去编辑先看格式和主题是否匹配然后送给两个到三个审稿人审稿人各自从创新性、实验设计、写作质量等维度提意见最后编辑综合所有意见给出结论接收、大修、小修还是拒稿。整个链条环环相扣角色之间有明确分工信息流转有清晰方向。这就非常适合用来模拟 AI Agent 互动。因为每个角色都可以被建模成一个独立的 Agent作者 Agent 负责生成论文摘要和回复意见审稿人 Agent 负责阅读、质疑和打分编辑 Agent 负责汇总、裁决和生成最终决定。这些 Agent 之间的交流方式本质上是“传递信息 做出决策 反馈结果”和真实世界的学术评审流程高度一致。如果我只用一个独立的 Agent 去“生成一条学术评审意见”那本质上只是一个高级一点的提示词模板谈不上 Agent 互动。但当我拆成三个、四个甚至更多角色让它们各自维护自己的上下文、各自调用工具、按顺序或按条件触发下一步系统的复杂度就会立刻上来前一个 Agent 的输出会直接影响后一个 Agent 的决策路径这才是真正的多智能体协作。1.2 从单 Agent 到多 Agent互动的本质变了单个 Agent 的逻辑非常简单接收用户输入 → 调用模型推理 → 可能调用工具 → 输出结果。你不需要考虑“谁来触发”“信息怎么共享”“如果某个环节失败了怎么办”。多 Agent 系统完全不是一回事。第一个变化是状态管理。多个 Agent 之间需要共享一份公共状态比如论文全文、审稿意见列表、编辑裁决标记。第二个变化是流程控制。不再是一条直线走到底而是有分支、有回环比如编辑看了两个审稿人的意见后如果意见冲突可能要触发第三位审稿人。第三个变化是角色权限。作者 Agent 能不能直接修改论文审稿人 Agent 能不能看到其他审稿人的意见这些都要在设计时明确。所以做学术评审这个场景表面上是写几个不同的提示词实际上是在设计一个小型分布式协作系统。我甚至觉得啃下这个场景之后再去应对什么智能客服流转、工单自动分派、多部门审批自动化几乎就是同一套方法论换个壳。2. AI Agent 之间的四种主要互动模式2.1 串行传递式前一个 Agent 的输出是后一个 Agent 的输入这是最简单也最直觉的互动方式。Agent A 完成自己的任务把结果丢给 Agent BAgent B 处理完再丢给 Agent C。整个系统像一条流水线没有回头路。放在学术评审里串行模式长这样作者 Agent 生成论文 → 审稿人 Agent 评审 → 编辑 Agent 汇总决策。每个环节只需要关心上游给自己的输入不需要关心下游如何消费自己的输出。优点非常明显流程清晰、调试容易、每一步都能单独检查。缺点也很明显没有反馈回路。如果审稿人 Agent 发现论文格式有问题串行模式下它只能把这个意见传给编辑 Agent不能直接让作者 Agent 重新修改。在某些简单场景下这样够了但要实现更接近现实的学术评审就得引入更灵活的互动方式。2.2 中心编排式一个主控 Agent 调度所有子 Agent中心编排模式是实际项目里最常用的一种。一个 Orchestrator编排者Agent 负责拆解任务、派发给多个 Worker执行者Agent、收集结果、再进行下一步决策。放在学术评审场景里编辑 Agent 就是一个天然的主控角色。它负责拆解评审维度这一个 Worker 专门看实验设计那一个 Worker 专门看创新性等所有 Worker 返回意见后主控角色再做汇总。中心编排式的核心优势是控制力强。主控 Agent 可以决定什么时候并行调用多个 Worker可以根据部分返回结果随时调整后续流程。但它也有代价主控 Agent 的提示词和逻辑最容易变成系统瓶颈一旦编排指令不明确下面的 Worker 就会各说各话。这也是为什么调研了 Agent 中台之后我发现大部分商业化产品的底层编排逻辑都收敛到这种模式的原因——好理解好兜底。2.3 双向对话式两个 Agent 角色反复博弈双向对话式互动指的是两个 Agent 之间不是一次性的输入输出而是多轮往返的讨论。学术评审里最典型的就是作者 Agent 和审稿人 Agent 之间的 rebuttal回复意见环节。作者 Agent 先提交一版回复指出审稿人误解了某部分内容审稿人 Agent 检查回复要么接受解释要么继续质疑作者 Agent 再针对新的质疑补充说明。经过三五轮之后双方才达成一个“审稿人与作者达成一致”的状态。这种互动方式对上下文管理的要求最高。因为每一轮都要把历史对话记录全部带上Token 消耗会随着轮数线性增长。在 LangChain 里可以用messages列表来维护讨论记录在 LangGraph 里则可以把整个讨论历史存入共享的 state 字段让它自动传递。坦白说这种模式做 Demo 很酷真正放到生产环境却要注意控制轮数。我一般会设置一个最大轮数比如 4 轮超过之后强制让编辑 Agent 介入裁决防止两个模型无限拉扯。2.4 分层监督式每个子流程都有自己的小主管分层监督式可以理解为中心编排模式的升级版。不是一个大主管直接管所有执行者而是先有几个中层主管每个中层主管再带一组子 Agent。在学术评审里这个结构非常自然主编 Agent 不直接面对每位审稿人而是先分给领域编辑 Agent领域编辑再把任务派给具体的审稿人 Agent。审稿人之间互不知晓只向自己的领域编辑汇报。优点在于职责隔离和信息封装。主编不需要关注论文的技术细节只需要看到各领域编辑提交的汇总意见。缺点是流程变长、延迟变高如果每一层都是大语言模型的推理调用整个评审链路跑下来可能要消耗好几倍的 Token 和延迟。下表把这四种模式的关键差异做了一个直观对比互动模式信息流转方向适合场景主要弱点在学术评审中的典型对应串行传递式单向流水线流程固定、无需回溯无法反馈修正作者 → 审稿人 → 编辑中心编排式主控调度、星型分发并行任务、动态决策主控容易成为瓶颈编辑分配多位审稿人双向对话式两两多轮往返讨论、博弈、协商Token 消耗大、可能死循环作者回复审稿人质疑分层监督式多层树状汇报规模大、职责分明链路长、延迟高主编 → 领域编辑 → 审稿人我做实际项目时的经验是不要只选一种模式死磕到底。学术评审系统最理想的状态是混合模式比如主流程用中心编排遇到意见冲突时临时切换到双向对话最后逐层汇总时用树状结构。3. 核心细节解析学术评审 Agent 系统怎么设计3.1 角色定义与提示词设计每个 Agent 本质上就是一个“角色 目标 边界”的提示词组合。学术评审系统里我通常会这样定义角色作者 Agent目标是“向审稿人清晰解释论文的创新性和必要性”边界是“不能修改论文正文只能生成回复意见”。审稿人 Agent目标是“从创新、实验、写作三个维度严格审查论文”边界是“只负责提出质疑和得分不决定论文是否接收”。编辑 Agent目标是“综合所有意见给出最终决策”边界是“必须在三个选项中选择一个接收、修改、拒稿”。提示词设计时最关键的是明确输出格式。我踩过不少坑最后基本都会用结构化的输出约束。比如审稿人 Agent 的提示词里直接写死要求system_prompt 你是《AI Agents 前沿》期刊的审稿人。 你的任务是对给定的论文进行严格评审。 输出内容必须严格使用如下 JSON 结构 { summary: 论文内容概括100字以内, scores: {innovation: 1-5, experiment: 1-5, writing: 1-5}, questions: [质疑点1, 质疑点2, 质疑点3], verdict: major_revision / minor_revision / reject } 结构化的好处有两个一是后续 Agent 解析输出非常方便不用从散文里抽取关键信息二是模型为了输出合规 JSON会不自觉地规整自己的推理内容准确性反而更高。3.2 公共状态与上下文流转多 Agent 系统设计里最容易翻车的地方就是状态管理。学术评审这个场景涉及的信息维度很多论文本身、各审稿人的打分、编辑的决策、讨论记录、最终意见。如果这些信息散落在各个 Agent 的内部上下文里后续根本没法统一控制。我参考了 LangGraph 里 StateGraph 的做法定义了一个统一的评审状态对象from typing import Annotated, TypedDict import operator class ReviewState(TypedDict): paper: str # 论文全文 author_response: str # 作者对审稿意见的回复 reviews: Annotated[list, operator.add] # 各审稿人返回意见的聚合列表 discussion: Annotated[list, operator.add] # 作者与审稿人的多轮对话记录 final_decision: str # 最终录用决策这里有两个很妙的设计点。第一reviews和discussion用operator.add作为归并函数LangGraph 会把不同节点返回的新条目自动追加到列表里不需要我手动维护整个历史。第二paper和final_decision是普通字段后写覆盖先写适合存放全局唯一的快照信息。上下文流转的原则是每个 Agent 只取自己需要的字段不要一股脑把所有历史对话都塞进去。编辑 Agent 不需要看作者和审稿人全部五轮讨论的原始内容只需要看最终结论。所以我在给编辑 Agent 组装输入时会做一个字段裁剪大幅降低 Token 消耗。3.3 工具调用让 Agent 不只会“说”还会“做”学术评审如果只是让模型读文本、生成意见那和前几年的大语言模型强提示词工程没什么区别。真正的 Agent 化在于它能不能主动调用工具去影响环境。我在原型的第二版里给审稿人 Agent 接了两类工具。第一类是检索工具比如通过论文标题去搜索相关的已有工作辅助判断该论文的创新性是否足够。用 LangChain 的Tool接口封装from langchain.tools import Tool def search_related_works(title: str) - str: # 这里可以是真实调用学术搜索 API # 也可以是模拟返回几条相关论文标题 return f与 {title} 相关的工作检索结果 search_tool Tool( namesearch_related_works, description当需要判断论文创新度时调用输入为论文标题, funcsearch_related_works, )第二类工具是约束检查器检查论文的格式要求、字数限制、图表是否齐全。这些看起来很基础但正是让 Agent “不是光聊”的关键。给 Agent 绑定工具时的注意事项是工具描述要写得非常直白最好说明“什么时候该调用、什么时候不该调用”。模型是根据描述来决定是否触发工具的描述含糊会导致工具被滥用或完全不被调用。3.4 与 FastAPI 集成怎么扛并发顺着搜索热词里大家关心的问题——“AI Agent 怎么扛并发”我多聊几句。多 Agent 流程一旦跑起来每一步都是真实的后端请求如果直接同步执行一个用户发起的一篇论文评审可能占住一个工作线程几十秒基本没法用。我的方案是两层解耦。第一层是FastAPI 层只做入口和状态登记接到评审请求后立即生成一个review_id把任务丢进 Celery / Redis Queue立刻返回“评审进行中”。第二层是Worker 进程里跑完整的 LangGraph 流程评审结束后把结果写回数据库。前端通过轮询review_id获取结果。FastAPI 端口只需要一个轻量化接口from fastapi import FastAPI, BackgroundTasks from pydantic import BaseModel app FastAPI() class ReviewRequest(BaseModel): paper_title: str paper_content: str app.post(/review) async def start_review(req: ReviewRequest, background_tasks: BackgroundTasks): review_id generate_id() background_tasks.add_task(run_review_pipeline, review_id, req.paper_content) return {review_id: review_id, status: processing}BackgroundTasks在轻量场景够用了如果要更稳健的队列重试和任务优先级就上 Celery。并发瓶颈通常不在 FastAPI 本身而在大语言模型 API 的限流限制。应对的办法就是给每个 Agent 的调用加信号量或令牌桶限速再配合指数退避重试。4. 实操过程从 0 到 1 搭建“三 Agent 学术评审”原型4.1 环境准备与依赖安装整个原型用 Python 3.11 开发核心依赖是langchain、langgraph、fastapi、uvicorn大模型接口先接一个通用的 OpenAI 兼容接口。第一步直接安装pip install langchain langgraph fastapi uvicorn[standard] openai建立一个项目目录和文件结构agent-review/ ├── main.py # FastAPI 入口 ├── state.py # 评审状态定义 ├── agents.py # 作者、审稿人、编辑 Agent 的定义 ├── graph.py # LangGraph 图结构编排 └── run.py # 本地直接调用的脚本入口4.2 顶层图结构设计在 LangGraph 中一个多 Agent 评审系统的核心图结构如下。整个流程分成四个关键节点author_agent生成论文摘要、reviewer_agent评审并生成意见、author_rebuttal生成回复、editor_agent汇总决策。from langgraph.graph import StateGraph, END def build_graph(): workflow StateGraph(ReviewState) workflow.add_node(author_agent, author_agent) workflow.add_node(reviewer_agent, reviewer_agent) workflow.add_node(author_rebuttal, author_rebuttal) workflow.add_node(editor_agent, editor_agent) workflow.set_entry_point(author_agent) workflow.add_edge(author_agent, reviewer_agent) workflow.add_edge(reviewer_agent, author_rebuttal) workflow.add_edge(author_rebuttal, editor_agent) workflow.add_edge(editor_agent, END) return workflow.compile()在 LangGraph 中节点就是普通的函数接收整个 state 作为输入返回一个 dict 作为写入 state 的增量所有字段变更都会自动合并。如果一个节点要提前终止可以添加条件边比如审稿人 Agent 给出reject时跳过 author_rebuttal 直接到 editor_agent。4.3 各个 Agent 节点的核心逻辑首先看 author_agent。它负责把论文内容和标题整理成一个标准摘要并生成一个“作者自证”的亮点说明def author_agent(state: ReviewState) - dict: paper state[paper] prompt f 你是论文作者。请基于论文内容 1. 用150字以内概括论文核心贡献 2. 说明该工作的独特之处 返回格式summary概括/summaryhighlights独特之处/highlights 论文内容 {paper} response call_llm(prompt) return {author_response: response}reviewer_agent 是核心节点它会读取论文内容和作者摘要按审稿人提示词输出结构化意见然后用自己的意见去触发一个工具调用检查相关参考文献是否存在。author_rebuttal 的逻辑很有意思。如果reviews中存在 “reject” 之外的质疑它会逐条回应。这里的实现略去了复杂的提问描述但实践中建议保留完整的质疑列表。最后是 editor_agent。它会收到所有审稿意见和作者回复输出最终决策并把决策字符串写入state[final_decision]。4.4 一个可运行的完整调用链正常情况下四个节点串行执行就能输出一份模拟学术报告。下面是运行图的参考代码def run_pipeline(paper_content: str): graph build_graph() config {recursion_limit: 20} init_state {paper: paper_content, reviews: [], discussion: []} result graph.invoke(init_state, config) print(最终决策, result[final_decision]) return result if __name__ __main__: sample_paper 本文提出一种基于多Agent协作的自动化论文评审框架... run_pipeline(sample_paper)体验过整体链路之后我的建议是先跑通串行全流程再迭代增加回环和并行节点。直接一步到位上复杂图结构调试时很容易分不清是哪一步出了问题。就像我最初二版加入了对话回环结果每次都因为上下文太长超时把回环拆出来单独调试后才恢复正常。4.5 Aware 处理并发的几个实践参数如果你想在自己的服务里扛住真正的并发请求几个关键参数值得记录。对于大模型 API 的调用每秒钟最多发多少个请求可以算出一个阀值如果并发超过这个阀值就需要排队而不是简单地放行。另一个重要参数是超时时间。一个评审流程里单次大模型调用我一般设 60 秒超时整个图设 300 秒总超时超过就降级为“评审超时请稍后重试”。并发上来以后还要注意日志里必须带上review_id否则多个任务同时跑排查问题完全无从下手。每个节点开始和结束都打一行日志记录当前 state 中的关键字段长度。5. 常见问题与排查技巧实录5.1 提示词脆弱性与角色漂移多 Agent 系统最常见的问题就是“角色漂移”。审稿人 Agent 写着写着突然开始替编辑做决定或者作者 Agent 回复意见时反过来批评审稿人水平太差。这是因为模型的角色约束不够强。我的解决办法有两个。一是在系统提示词里反复强调边界用类似“你是审稿人只有编辑能做出最终接收决定”“你无权修改论文正文”这样的命令式语句二是在每个节点的返回结构上做校验比如审稿人 Agent 的返回里如果没有包含scores字段就强制要求模型重新生成一次。实测下来这边界的校验比提示词有效得多。5.2 上下文爆炸与 Token 管理学术评审场景特别容易积累长对话尤其是作者回复审稿人意见这种多轮场景。每一轮都要带上之前的全部讨论五轮下来一个节点就可能消耗上万 Token。我试过几种办法最终沉淀下来两招。第一是裁剪给编辑 Agent 的输入只保留审稿意见的最终汇总不保留原始讨论记录。第二是压缩每轮讨论结束之后增加一个专门的 summarize Agent把该轮的关键结论压缩成三条以内。这两种方式配合使用之后整个流程的 Token 消耗至少降了百分之四十。5.3 模型幻觉与“像模像样的假评审”大语言模型非常擅长生成看着头头是道、实际没有依据的批评。学术评审场景里这个问题尤其致命。审稿人可能提出“本文没有与 XX 方法对比”但实际上论文里专门有一节做过这种对比。针对这台幻觉问题实操中我会给 reviewer_agent 接一个verify_statement工具它会把每一条质疑意见先对照原文检索一遍看论文中是否真的存在相关内容。如果存在则自动修改质疑意见为“建议加强对比分析”之类更准确的表述。效果非常直观评审意见的质量明显变好。5.4 死循环与超时兜底对话式 Agent 互动最容易踩的坑就是死循环。作者 Agent 和审稿人 Agent 理论上可以不间断地争论下去。哪怕我设置了最大轮数为 4仍然可能因为某个节点的重试逻辑写得不严谨出现无限循环。经验是三重兜底。第一在循环条件的出口加硬编码计数第二在图配置里设置recursion_limit第三在异步任务层加总超时超过总超时直接杀掉任务。运行手册里永远要写一句话多 Agent 流程必须有超时兜底不然线上事故就是一瞬间的事。5.5 排查问题的一线心得排查多 Agent 系统的问题最有效的工具不是单步 DeBugger而是完整的中间过程日志。我会给每个 Agent 加一个debugTrue开关开启后把每个节点接收到的输入和输出的完整文本都落到日志文件里。排查时只看状态转换就能发现是哪一步数据格式出错、哪一步上下文被污染。还有一个实操心得不要相信缓存也命中了就跳过调试。LangChain 自带InMemoryCache和 SQLite 缓存调试阶段长期开着缓存会导致你改了提示词但跑出来的还是旧结果排查思路直接跑偏。开发环境建议彻底关掉响应缓存。6. 从“评审”到“中台”多 Agent 系统的通用化6.1 学术评审框架复用到其他业务场景做完这个学术评审系统之后我发现很多流程本质上都可以抽象成“具备不同专业背景的角色在一个公共状态下协作决策”的框架。比如工单流转一线客服 Agent、技术专家 Agent、审批主管 Agent比如内容审核内容生成 Agent、初审 Agent、终审 Agent。学术评审只是这个通用框架的一个具体实例。如果想把这个框架产品化最简单的做法是定义一套“角色配置 图模板 状态 Schema”的组合做成一个 Agent 中台。每一个新场景进来只需要配置新的角色提示词、新的状态字段、新的流程模板不用从头写一遍编排代码。6.2 一个未来的扩展方向评审结果的可解释性学术评审相比普通自动化任务有一个特别值得关注的需求是可解释性。编辑 Agent 给出拒稿决的时候读者不仅要知道结果还要知道依据是什么。我在系统里增加了一个结构把编辑决策关联到具体审稿意见的 ID 上这样输出结果时能做到“决策可溯源”。这个思路同样适用于其他 Agent 协作场景尤其是金融风控、医疗辅助这类高合规要求的领域。当多个 Agent 协作完成一个高风险决策时系统必须能回答“为什么在这个环节做了这个决定”的问题。做多 Agent 系统这么久我最大的体会是技术本身不难难的是对“协作边界”的把握。每个 Agent 都太容易越界太容易自信所以主控者的任务不只是调度还得不断校准它们的边界。学术评审这个场景给了我很完整的锻炼。如果你也想上手体验多 Agent 系统我强烈建议从模仿一套真实的角色协作流程开始别一上来就追求复杂算法先把角色、状态和流程这三件事吃透后面无论是做产品还是深入架构都会顺畅很多。