基于LLM智能体模拟同行评审：多智能体系统在学术流程仿真中的应用

1. 项目概述：用AI智能体模拟同行评审的“社会实验”

如果你在学术圈待过，或者参与过顶会论文的投稿，一定对“同行评审”这个环节又爱又恨。它被誉为科学质量的“守门人”，但其过程却像一个黑箱：为什么我的论文被拒了？是研究本身的问题，还是遇到了苛刻的审稿人？审稿人的个人偏好、疲劳程度，甚至与领域主席的互动，到底在多大程度上影响了最终决定？传统上，要研究这些问题，要么依赖难以获取的敏感真实数据，要么只能做小规模的问卷调查，局限性很大。

最近，我在EMNLP 2024上看到一篇挺有意思的口头报告论文《AgentReview》，它提供了一个全新的视角：用大语言模型（LLM）构建的智能体（Agent）来模拟整个同行评审流程。简单说，就是让一堆AI“扮演”论文作者、审稿人和领域主席，在一个可控的虚拟环境里，重复进行成千上万次“投稿-评审-决策”的模拟实验。这听起来有点像一场大型的、可重复的“社会实验”。通过调整不同的实验条件（比如审稿人的严格程度、讨论机制），研究者可以量化那些以往只能定性讨论的因素——比如“审稿人偏见”到底能让论文的接收率产生多大波动。

这个项目的官方实现已经开源，我花了一些时间把它的代码跑通，并深入研究了其框架设计。我发现，它不仅仅是一个研究工具，其模块化的智能体设计、清晰的交互流程，对于想学习多智能体系统（Multi-Agent System）构建、或是想用LLM模拟复杂社会过程的开发者来说，也是一个绝佳的范本。接下来，我将拆解这个项目的核心思路、详细部署步骤，并分享在复现过程中遇到的一些“坑”和解决技巧。

2. 核心思路与框架设计拆解

为什么用AI智能体来模拟同行评审是可行的，甚至是有优势的？这需要从传统研究方法的痛点以及LLM智能体的特性说起。

2.1 传统研究方法的局限与LLM智能体的优势

传统的同行评审研究主要依赖两种数据：一是真实的评审数据，二是通过调查问卷获取的主观数据。前者虽然客观，但属于会议的高度机密，极难获取，且涉及严重的隐私问题。后者则容易受到回忆偏差和社交期望偏差的影响，数据质量不稳定。更重要的是，无论是哪种数据，都难以进行“反事实推断”。比如，我们无法知道如果同一篇论文换一组审稿人，结果会不会不同；也无法量化审稿人在讨论环节被领域主席影响的程度。

LLM智能体模拟恰好能弥补这些缺陷。首先，它完美规避了隐私问题，因为所有角色（论文、审稿人、作者、主席）都是虚拟的，初始论文数据也可以使用公开的、已发表的论文PDF。其次，它提供了完美的控制变量环境。我们可以固定一篇“论文”，只改变审稿人的“性格设定”（如是否苛刻、是否容易从众），然后运行上百次模拟，观察决策结果的变化，从而直接量化该因素的影响力。最后，LLM生成的评审意见和讨论文本是结构化的数据，非常适合进行定量和定性分析。

AgentReview框架的核心洞见在于，它将社会学中的经典理论（如社会影响理论、利他主义疲劳、权威偏见）操作化为一组可调节的智能体参数，从而在模拟中检验这些理论如何影响评审结果。

2.2 AgentReview的五阶段模拟管道

项目的模拟流程设计得非常细致，完全复现了顶会（如ICLR）的完整评审周期。理解这个管道是看懂整个项目的基础。

第一阶段：审稿人独立评估。这是最基础的环节。系统为每篇模拟的论文分配3个审稿人智能体。每个审稿人独立阅读论文PDF，并生成初始评分、评审意见和推荐决策（接受/拒绝）。这里的关键在于，每个审稿人智能体都被赋予了一个“人格”，这个“人格”由系统提示词（System Prompt）来定义，其中包含了其专业领域、评审严格程度（例如，是否倾向于给低分）等潜在变量。

第二阶段：作者-审稿人 rebuttal 讨论。模拟作者收到评审意见后，撰写反驳信（rebuttal）来回应审稿人的关切。审稿人阅读反驳信后，可以选择是否更新自己的评分和意见。这个阶段模拟了学术交流中“澄清误解”的过程。

第三阶段：审稿人-领域主席（AC）讨论。领域主席智能体介入，组织审稿人进行讨论。主席可能会总结分歧，或者引导审稿人关注某些关键问题。在这个社交互动中，审稿人智能体可能会因为“社会影响”（其他审稿人的观点）或“权威偏见”（对主席意见的重视）而改变自己的立场。

第四阶段：元评审（Meta-Review）撰写。领域主席综合所有讨论，撰写一份给程序委员会的元评审报告，总结论文的优缺点和争议点。

第五阶段：最终决策。领域主席基于所有信息（初始评审、反驳、讨论、元评审），做出最终的接受或拒绝决定。项目在这里设置了一个关键机制：固定接受率。例如，模拟ICLR 2020-2023时，接受率固定为32%。这意味着主席的决策并非完全自由，而是在一个竞争环境中做出的，他需要在所有论文中排序，选出前32%。这更贴近现实。

整个管道就像一个精密的戏剧脚本，每个智能体按照自己的角色和规则进行交互，而研究者则是背后的导演，通过调整“演员”的设定来观察“剧情”（评审结果）的变化。

3. 环境部署与数据准备实操指南

理论很美好，但要把这个项目跑起来，需要一些具体的操作。以下是基于我实际搭建过程的详细步骤。

3.1 基础环境搭建与依赖安装

项目基于Python，并使用了Gradio构建了一个简易的演示界面。首先从GitHub克隆代码库：

git clone https://github.com/Ahren09/AgentReview.git cd AgentReview

接下来安装依赖。项目提供了requirements.txt文件，但这里有个注意事项：由于依赖库可能有版本冲突，建议先创建一个新的Python虚拟环境（如使用conda或venv）。

# 使用 conda 创建环境（推荐） conda create -n agentreview python=3.10 conda activate agentreview # 使用 venv python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装依赖 pip install -r requirements.txt

安装过程中可能会遇到一些库的版本问题。例如，gradio的版本如果过高，可能与项目代码不兼容。如果运行时报错，可以尝试指定一个稍旧的版本，比如pip install gradio==5.4.0，这与项目标注的SDK版本一致。

3.2 核心数据获取与处理

项目的运行依赖于两大部分数据：真实的论文PDF，以及（可选的）预生成的LLM评审数据。

第一步：下载论文数据包。数据存放在Dropbox。你需要下载名为AgentReview_Paper_Data.zip的文件。由于网络环境差异，直接使用命令行wget或curl可能不稳定。更可靠的方法是使用浏览器下载，或者在有图形界面的服务器上使用axel、aria2等多线程下载工具加速。

下载后，将其解压到项目根目录下的data/文件夹中。这里有一个关键细节：务必确保解压后的目录结构正确。

# 假设zip文件已下载到AgentReview目录下 unzip AgentReview_Paper_Data.zip -d data/ # 检查解压结果 ls data/ # 你应该看到类似这样的结构：iclr2020/, iclr2021/, ... 以及 pdfs/ 文件夹

解压后的data/目录应包含各年份ICLR的评审数据（JSON格式）和一个存放所有论文PDF的pdfs/子目录。论文PDF是后续LLM智能体“阅读”的原材料。

第二步：（可选）下载预生成的评审数据。为了节省时间和API调用成本，作者提供了一个AgentReview_LLM_Reviews.zip文件，里面包含了使用GPT-4等模型预先为论文生成的评审意见、评分等。如果你只是想快速运行分析或演示，而不想从头调用昂贵的API，下载这个文件非常有用。

unzip AgentReview_LLM_Reviews.zip -d outputs/

注意：如果你打算从头运行完整的模拟流程，生成自己的数据，则可以跳过这一步。但请注意，从头运行需要配置LLM API并可能产生可观费用。

3.3 LLM API密钥配置与关键设置

项目的智能体核心驱动是LLM API，目前主要支持OpenAI官方API和Azure OpenAI API。

对于OpenAI API用户：你需要一个有效的OpenAI API密钥。将其设置为环境变量。强烈建议不要将密钥硬编码在脚本中。

# Linux/Mac export OPENAI_API_KEY='你的-sk-开头的密钥' # Windows (PowerShell) $env:OPENAI_API_KEY='你的-sk-开头的密钥'

对于Azure OpenAI用户：由于国内网络环境或企业合规要求，使用Azure端点可能更稳定。配置稍复杂一些：

export AZURE_ENDPOINT='https://你的资源名.openai.azure.com/' export AZURE_DEPLOYMENT='你的部署名称' # 例如 gpt-4 export AZURE_OPENAI_KEY='你的Azure OpenAI密钥'

重要心得：在agentreview/目录下的源码中，模型调用逻辑主要写在backend.py或类似的LLM客户端文件中。如果你使用的模型部署名称与代码中默认的gpt-4不同，你可能需要找到相应的代码位置，将模型名称参数修改为你的Azure部署名。例如，搜索client.chat.completions.create(model=...这样的语句并进行修改。

关于内容过滤的坑：论文和评审过程中难免会出现一些专业术语或批判性语句，这可能会触发LLM API（特别是Azure）的内容安全过滤策略，导致调用失败并返回内容违规错误。作者在README中也提到了这一点。如果遇到content_filter错误，你需要到Azure OpenAI Studio中，对你使用的部署模型的“内容过滤”策略进行调整，通常可以适当放宽限制，或者在提示词中明确要求模型以学术讨论的严谨态度进行回应。

4. 运行模拟与自定义实验配置

环境准备好之后，就可以启动模拟了。项目提供了一个主要的运行脚本。

4.1 启动完整模拟流程

项目根目录下有一个run.sh脚本。你需要先编辑这个文件，确保里面设置的环境变量（尤其是API密钥和端点）是正确的。编辑完成后，运行：

bash run.sh

这个脚本会启动整个五阶段的模拟管道。请务必确保当前工作目录是AgentReview/项目根目录，因为代码中的很多路径是相对路径。

运行过程会在终端输出日志，显示当前正在处理哪篇论文、哪个阶段。整个过程可能非常耗时，且消耗大量API Token，具体取决于你配置的论文数量、使用的模型以及实验设置的复杂度。

4.2 使用Jupyter Notebook进行交互式演示

如果你只是想快速体验一下框架的运作，或者进行小规模的测试，更推荐使用项目提供的Jupyter Notebook演示。

jupyter notebook notebooks/demo.ipynb

这个demo.ipynb笔记本通常会包含一个更轻量化的示例，比如使用一两篇论文，运行一个简化的评审流程，并可视化结果。这是理解和调试代码的绝佳起点。你可以逐单元格运行，观察每个阶段智能体之间传递的消息和生成的内容。

4.3 深度定制：设计你自己的实验场景

AgentReview最强大的地方在于其可配置性。所有的实验设置都在agentreview/experiment_config.py这个文件中。作者已经预定义了几个设置，如BASELINE（基线）、benign_Rx1（假设审稿人更友善）等。

每个setting是一个字典或配置对象，它定义了各种参数：

• 审稿人生成参数：如生成评审意见时使用的提示词模板、温度系数（控制创造性/随机性）。
• 讨论参数：如反驳轮数、讨论中是否强制要求审稿人达成一致。
• 决策参数：如使用的固定接受率。
• 智能体“人格”参数：这是最有趣的部分。你可以定义一类审稿人具有“权威偏见”，即他们在与AC讨论时，会更容易改变自己的评分以靠近AC暗示的方向。

如果你想研究“如果所有审稿人都非常疲劳，评审质量会下降多少？”，你可以创建一个新的设置：

# 在 experiment_config.py 中模仿现有格式添加 fatigued_reviewer_setting = { “name”: “fatigued”, “reviewer_config”: { “prompt_template”: “...”, # 在提示词中加入“你现在很疲惫，已经评审了太多论文...”的语句 “strictness_bias”: -0.5, # 假设存在一个严格度偏置参数，负值表示更宽松（因疲劳而放水） “fatigue_level”: “high” # 自定义一个疲劳度参数 }, “discussion_rounds”: 1 # 疲劳的审稿人可能不愿意多轮讨论 } # 然后将这个设置添加到 all_settings 字典中 all_settings = { “BASELINE”: baseline_setting, “benign_Rx1”: benign_Rx1_setting, “fatigued”: fatigued_reviewer_setting, # 加入你的新设置 # ... 其他设置 }

之后，你可以在运行脚本或自定义的主程序中，指定使用fatigued这个设置来运行模拟，并将结果与BASELINE设置的结果进行对比，从而量化“审稿人疲劳”对决策的影响。

5. 核心代码模块解析与二次开发要点

要真正掌握这个项目，或者基于它做自己的研究，需要深入其代码架构。它的设计清晰体现了多智能体系统的典型模式。

5.1 智能体（Agent）类的抽象

在agentreview/agents/目录下，你会找到author.py,reviewer.py,ac.py等文件。每个文件定义了一个智能体类。这些类通常继承自一个基础的Agent类（可能来自引用的chatarena框架）。

以Reviewer类为例，其核心方法可能包括：

• generate_initial_review(paper_content): 接收论文文本，调用LLM生成初始评审。
• read_rebuttal(rebuttal_text): 处理作者的反驳信。
• update_review_after_discussion(discussion_history): 根据讨论历史更新自己的评审意见。

每个智能体的行为由其“系统提示词”和“记忆”所驱动。系统提示词定义了角色的身份、任务和行为准则（如“你是一位严谨的机器学习领域审稿人”）。记忆则存储了当前的对话历史和上下文。

5.2 环境（Environment）与交互流程

agentreview/environment/或主目录下的simulation.py这类文件，定义了整个模拟的“舞台”。它负责：

1. 初始化：加载论文数据、实例化智能体（作者、审稿人、AC）。
2. 推进流程：按顺序执行五个阶段。在每个阶段，它调用相应智能体的方法，并将一个智能体的输出作为输入传递给下一个智能体。
3. 记录日志：保存所有交互的中间结果（评审意见、评分、决策等），用于后续分析。

这个环境类是连接所有智能体、驱动故事发展的“引擎”。如果你想修改流程，例如增加一轮“作者修改后重投”的阶段，就需要在这里修改状态转移的逻辑。

5.3 结果分析与可视化

模拟运行结束后，所有数据会保存在outputs/目录下（如果你使用了预生成数据，也会在这里）。数据格式可能是JSON或CSV，记录了每篇论文、每个审稿人在每个阶段的输出。

项目可能提供了简单的分析脚本，但更深入的分析需要你自己进行。你可以：

• 计算不同实验设置下的平均接受率变化。
• 分析评审意见的情感倾向（正面/负面词汇比例）与最终决策的关系。
• 追踪某位审稿人在讨论前后的评分变化，以验证“社会影响”的存在。

你可以使用Pandas进行数据处理，使用Matplotlib或Seaborn进行绘图，来直观展示你的研究发现。

6. 常见问题排查与实战经验分享

在复现和实验过程中，我遇到了不少问题，这里总结一下，希望能帮你避坑。

6.1 依赖安装与版本冲突问题

问题：安装requirements.txt时，某些库（如numpy,pandas,torch）可能因版本过高或过低而与其他科学计算库冲突。解决：首先尝试在全新的虚拟环境中安装。如果仍有冲突，可以逐一安装核心库，并尝试使用稍旧的、兼容性广的版本。例如：

pip install numpy==1.23.5 pandas==1.5.3 transformers==4.36.2

然后根据运行时的具体报错信息，调整其他库的版本。

6.2 API调用失败与网络超时

问题：运行过程中频繁出现APIConnectionError,Timeout或RateLimitError。解决：

1. 确认密钥与端点：首先双重检查你的OPENAI_API_KEY或Azure环境变量是否设置正确，是否有拼写错误。
2. 网络代理：如果你在国内，直接调用OpenAI官方API可能需要配置网络代理。可以在代码中全局设置，或者使用openai库的proxy参数。注意，这里仅讨论技术上的代理配置，不涉及任何具体工具或服务。一种常见的方法是在代码初始化客户端时指定：

import openai openai.proxy = "http://你的代理地址:端口" # 示例，具体配置需根据你的开发环境

对于Azure用户，通常走的是微软的全球网络，稳定性会好很多。 3.速率限制：免费或低等级的API密钥有每分钟/每天的调用次数限制。如果模拟论文数量多，很容易触发。解决方案是增加重试逻辑和指数退避策略。你可以在调用LLM的代码部分添加tenacity库来实现自动重试。 4.内容过滤：如前所述，如果返回错误信息提及content_filter，你需要去对应的AI服务平台（OpenAI Moderation Dashboard 或 Azure Content Filter）调整设置。

6.3 数据路径错误与文件缺失

问题：运行时报错FileNotFoundError: [Errno 2] No such file or directory: 'data/iclr2020/...'。解决：

1. 确保你已经正确下载并解压了AgentReview_Paper_Data.zip到项目根目录下的data/文件夹。
2. 检查解压后的目录结构是否与代码中读取的路径一致。有时zip文件内部可能多一层文件夹。你可以用tree data/命令查看结构。
3. 确保你在项目根目录（AgentReview/）下运行所有命令和脚本。

6.4 模拟结果与论文声称的数值不符

问题：你运行了基线实验，但计算出来的“审稿人偏见导致37.1%决策变化”这个数字对不上。解决：

1. 随机性：LLM生成具有随机性（即使温度设为0，也可能有微小波动）。确保你运行了足够多次的模拟（如论文中可能进行了数百次），然后取统计平均值。单次运行的结果波动会很大。
2. 模型差异：论文中使用的是特定版本的GPT-4（如gpt-4-0613）。如果你使用的是不同版本（如gpt-4-turbo）或完全不同的模型（如Claude、GLM），结果必然不同。复现研究时，应尽量使用原文指定的模型版本。
3. 提示词微调：智能体的行为极度依赖系统提示词。检查experiment_config.py中基线设置的提示词是否与论文附录中给出的完全一致。一个词的差异都可能导致智能体行为漂移。
4. 随机种子：检查代码中是否设置了随机种子（random.seed,np.random.seed），以确保实验的可重复性。如果没有，每次运行的结果都会不同。

6.5 自定义实验设计的建议

如果你想基于此框架开展自己的研究，以下几点经验可能有用：

从小规模开始：不要一开始就模拟几百篇论文。选择2-3篇论文，1-2个实验设置，先跑通整个流程，验证你的自定义配置是否按预期工作。

详细记录与版本控制：对experiment_config.py的任何修改，都要做好注释和版本记录。每次实验运行，最好将当时的配置文件、代码版本（git commit hash）和结果数据打包保存。科学实验的可重复性至关重要。

成本控制：LLM API调用成本不菲。在正式大规模运行前，用最小的配置（如用GPT-3.5-Turbo代替GPT-4，减少论文数量）估算一下总token消耗和成本。Azure OpenAI的定价页面有详细计算器。

分析日志：项目运行时生成的详细日志是你的宝贵财富。不要只盯着最终结果，多看看中间阶段审稿人生成的文本，这能帮你定性判断智能体的行为是否符合你的设计初衷，比如“疲劳的审稿人”生成的评语是否真的更简短、更敷衍。

这个项目打开了一扇新的大门，让我们能够以计算实验的方式，去探索那些原本深藏在人类社交与决策黑箱中的复杂过程。尽管基于LLM的模拟仍有其局限性（比如智能体可能无法完全复现人类审稿人深层的专业知识和动机），但它无疑是一个强大的、可控制的、可规模化的研究工具。无论是用于学术研究，还是作为学习多智能体系统构建的案例，AgentReview都提供了极高的价值。