随着网络系统研究复杂度的提升，研究结果复现通常需要研究人员依据论文描述重新实现完整系统。然而，网络领域开源实现比例较低，且系统形态高度异构，涉及算法逻辑、协议流程、实验配置以及不同编程语言与运行环境，例如 Python、C++、Go 以及 P4 等。这使得手工复现不仅成本高、周期长，也容易因实现细节缺失而产生结果偏差。
厦门大学信息学院向乔教授、宋庆禹副教授团队联合上海交通大学、北京邮电大学、亿联网络与清华大学，提出面向网络研究复现的多智能体框架 RepLLM。它能够从论文内容出发，自动完成信息解析、系统架构设计、代码生成以及审计修复。在七项代表性网络系统复现任务中，RepLLM 生成的代码全部实现可运行并成功加载真实数据集；经过有限人工校准后，完整复现通常可在约两小时内完成。论文的第一作者是厦门大学一年级硕士研究生蒋怡宁。
论文将发表于计算机网络领域顶级会议 ACM SIGCOMM 2026。ACM SIGCOMM（Special Interest Group on Data Communication）是计算机网络领域的旗舰学术会议（CCF A）。第40届SIGCOMM会议将于2026年8月17日-21日在美国丹佛召开。
- 论文标题：RepLLM: Toward Automatically Reproducing Network Research Results
- 会议网站：https://conferences.sigcomm.org/sigcomm/2026/accepted/
- 论文预览版：https://arxiv.org/abs/2509.21074
背景
网络论文读懂了，代码却跑不起来？
在计算机网络研究中，复现一篇论文，往往比读懂它困难得多。
论文通常只呈现系统架构、核心算法和实验结果，却难以完整容纳模块接口、数据格式、环境配置、脚本组织以及大量工程细节。研究者即使理解了论文，也可能需要花费数周乃至更长时间，才能重新实现一套可运行系统。
更现实的问题是：许多论文并没有公开完整代码。
通过统计 2016—2025 年 SIGCOMM 和 NSDI 论文的开源情况，结果显示，过去十年只有约 38% 的论文提供了作者公开的实现。与此同时，一篇网络系统论文平均需要复现 2.29 个已有系统作为对比，科研成本极高。
代码缺失、架构异构、环境复杂、跨模块依赖密集 —— 这些因素共同构成了网络研究复现的高门槛。
大模型虽然已经表现出强大的代码生成能力，但简单地把整篇论文交给一个模型，再要求它 “一次生成全部代码”，效果并不理想：长论文容易造成关键信息遗漏，多文件代码容易产生接口冲突，而能够成功运行的代码，也未必真正实现了论文中的算法。
怎么破？
RepLLM 给出的答案是：不要让一个大模型包办全部工作，而是组织一支分工明确、共享上下文、能够执行和修复代码的 “AI 复现团队”。
RepLLM：
从论文直达可执行系统
RepLLM 是一套面向网络系统论文的端到端多智能体复现框架。
用户提供论文和相关数据后，系统会依次完成四个阶段：
- 内容解析：从论文中提取章节、图表、公式、算法及其相互引用关系；
- 架构设计：将论文描述转化为模块、接口、执行顺序和环境依赖；
- 代码生成：依据结构化算法逻辑和数据契约，分步骤生成代码；
- 审计与修复：通过静态检查和沙箱执行发现问题，并自动生成补丁。
最终得到的不只是零散的代码片段，而是一套包含入口脚本、模块实现、配置文件、运行环境和实验流程的系统级代码仓库。
四个 AI 智能体，
组成一支 “论文复现团队”
RepLLM 的核心，是四类专业智能体的协同工作。
1. 内容解析智能体：先把论文真正读懂
内容解析智能体不会简单地把 PDF 转成一段长文本，而是构建结构化的论文知识树。
章节、图表、公式和算法均拥有独立标识，并通过引用关系连接起来。当后续模块需要实现某个功能时，系统可以递归获取与该功能有关的论文内容，降低长上下文中的信息丢失问题。
2. 架构设计智能体：先设计，再写代码
架构设计智能体将论文中的高层描述转化为系统蓝图，包括模块划分、执行步骤、输入输出接口、数据结构、数值约束和环境依赖。
这一步解决了大模型生成多文件项目时常见的接口漂移、重复定义和循环依赖问题。
3. 代码生成智能体：用结构化推理连接论文与程序
RepLLM 引入结构化思维链 SCoT，将论文中的自然语言算法转换为带有输入输出类型、条件分支、循环逻辑和数据依赖的中间表示，再据此生成具体代码。
它相当于在 “论文描述” 和 “程序实现” 之间增加了一层可检查的工程契约：既保留算法逻辑，又不提前绑定某一种编程语言的具体语法。
4. 审计与修复智能体：让代码真正跑起来
RepLLM 将生成的系统放入隔离沙箱中运行，并采用两层修复机制：
- 静态审计负责检查语法、接口、依赖以及论文与代码之间的语义偏差；
- 动态修复根据运行日志处理端口冲突、缺少依赖、数据格式错误和编排失败等问题。
二者形成 “生成 — 检查 — 运行 — 修复” 的闭环，使系统从 “看起来像代码” 进一步走向 “能够执行实验”。
图一：RepLLM系统架构
共享记忆：
让多个智能体始终面对同一个系统
多智能体系统最容易出现的问题，是不同智能体拥有不同版本的上下文。
RepLLM 为此设计了显式共享记忆：论文内容被组织在论文空间中，系统架构、接口定义、代码状态和修复记录则保存在系统空间中。所有智能体按统一规则读取最新状态，不需要反复传递完整对话历史。
实验中的消融结果显示，移除共享记忆后，系统可能生成一个 “运行成功” 的空壳程序，却没有真正实现论文算法；移除接口记忆，则容易出现后续模块偏离前期接口约定的情况。
这也揭示了一个重要事实：评价智能体不能只看 Token 数量和程序是否退出，更要检查系统是否真正覆盖了论文描述的功能。
七篇代表性论文，
全部实现可运行和数据加载
研究团队选择了七项具有代表性的网络研究进行测试，包括：
- 流量工程系统 NCFlow；
- DNS 配置验证系统 GRooT；
- 集合协调算法 Rateless IBLT；
- 配置挖掘系统 SelfStarter；
- 概率网络验证系统 NetDice；
- 学习加速流量工程系统 Teal；
- 可编程数据平面系统 NetChain。
这些系统覆盖流量工程、DNS 验证、编码理论、网络配置挖掘、概率验证和在网计算等不同方向，原始实现涉及 Python、C++、Go 和 P4，并依赖 Gurobi、CUDA、Mininet、BMv2 等不同工具与运行环境。
实验结果显示，RepLLM 在七项任务上生成的代码均能够运行，并成功加载论文对应的数据集。
相比之下，单次大模型API调用代码生成方法在 Rateless IBLT、Teal 和 NetChain 等任务上无法运行；在 NetDice 等任务中也无法正确接入真实数据。部分通用代码智能体（例如Claude Code）虽然能够生成可执行程序，却容易将真实系统简化为模拟器，绕过论文所依赖的数据平面或实验环境。
尤其是在复杂的 NetChain 复现中，系统必须让 P4 数据平面、Python 控制平面、客户端和编排脚本协同工作。RepLLM是所有评测方法中最接近于端到端完美复现原文的一种，并在人工校准后成功于 BMv2 测试环境中完成数据包交互。
从论文到结果，
最快 82 分钟
代码能运行，并不代表实验结果已经与原论文一致。
为此，团队进一步允许研究者对自动生成的代码进行少量人工校准。七项任务的自动生成阶段耗时 38 至 84 分钟，人工修复耗时 23 至 93 分钟，总复现时间为 82 至 138 分钟。
换言之，过去可能需要数周完成的网络系统复现，如今有望在约两小时内获得可运行、可调试并接近原论文结果的实现。
经过校准后：
- NCFlow 在主要数据集上获得了与官方实现近乎一致的总吞吐；
- NetDice 通过全部 11 项测试；
- GRooT 完整复现了参考测试中的违规检测结果；
- Teal 完整执行了 FlowGNN、COMA 和 ADMM 流程；
- SelfStarter 完整复现了预期的 ACL 模板与异常检测结果；
- Rateless IBLT 完整实现了真实协议路径的端到端验证；
- NetChain 在 p4c/BMv2 环境下复现了 P4 数据平面与控制平面的协同运行，核心功能逻辑与原实现的保持一致，同时复现代码兼容 Python3。
实验结果表明，借助 RepLLM 可以在约两小时内复现原始基准中约 95% 的结果，同时减少不必要的上下文传递和 Token 消耗。
助力学术效率提升
RepLLM 的意义并不只是节省写代码的时间。
它尝试打通一条更完整的科研自动化链路：
论文理解 → 系统设计 → 代码实现 → 环境构建 → 运行验证 → 结果复现
对于研究者而言，RepLLM 可以帮助快速建立基线系统、验证论文想法并降低跨方向复现成本；对于论文作者和评审者，它也有望成为检查论文可复现性、生成实验制品和发现描述缺失的辅助工具。RepLLM后续将开源，共同推进网络系统研究成果的高效复现与开放共享。
当然，RepLLM 仍然存在能力边界。需要修改内核或驱动、依赖专用硬件和大规模集群，或者必须在 Kubernetes、LLVM 等大型既有项目上打补丁的工作，目前仍难以在轻量沙箱中完整验证。未来，RepLLM 将逐步完善相关功能。
RepLLM 的探索表明，围绕具体科研任务构建专用 Agent，可以将大模型能力更深入地融入学术研究流程。
科研 Agent 的价值不只在于自动生成代码，更在于理解科研任务、组织专业知识并贯通研究流程。它可以协助研究者完成文献解析、系统搭建、环境配置、代码调试和结果验证等耗时工作，降低重复性工程投入，让科研人员将更多精力用于问题发现、方法设计和理论创新。
未来，科研 Agent 还可以进一步服务于文献调研、论文复现、网络系统设计、实验执行、数据分析和科研写作等环节，形成覆盖网络研究全流程的智能化工具链。
