Agent 原生的系统会议

当 agent 能够帮助研究者快速实现一个想法、完成一组实验、根据结果修改方案时，研究社区有机会以更快的速度积累知识。一场聚焦于某类系统问题的学术会议，可以借此吸引新的参与者，把原本停留在讨论中的想法做成原型，让不同方案按照统一的评判标准接受检验。

Agent 能让研究者尝试更多想法，也更快地验证结果，帮助一个领域更快发展。研究是否有价值，取决于提出了什么问题、怎样验证结论，以及最终留下了什么认识。不过，agent 也让研究者更容易完成一篇论文。论文产出加快了，审稿人能投入的时间和精力却很难同步增加。如果毕业、招聘和晋升仍高度依赖顶会发表记录，新增的研究能力就可能同时带来更多有价值的发现与更大的审稿压力。

学术会议需要同时面对这两种变化。本文中，我尝试讨论一种面向计算机系统研究、由研究者与 agent 共同参与的新会议形态，称为“agent 原生的系统会议”。

系统会议为什么存在

一场系统会议背后，是一群围绕共同问题聚集起来的研究者和实践者。有人关心操作系统的抽象与实现，有人关心网络中的资源分配和故障，有人关心大规模服务如何可靠运行。彼此的方案可能相互竞争，判断也会有分歧，但他们愿意花时间理解对方的工作，因为这些工作回应了自己在意的问题。

会议让社区成员有机会定期见面，交流研究进展。研究者在这里介绍新的系统设计，分享测量发现和部署经验。同行检验证据、讨论设计取舍，找出尚未解决的问题，再把这些问题带回各自的研究中。OSDI 的会议定位¹明确强调学术界与产业界围绕系统软件设计、实现及其影响展开交流。

这些活动让社区逐渐积累起共享的知识：某个抽象为什么有效，性能提升需要付出什么代价，什么条件下结论会失效，哪些问题值得下一批研究者继续投入。会议通过选稿和议程安排，影响社区关注哪些工作、讨论哪些问题。年轻研究者也能从这些讨论中学习如何提出问题、评价证据和回应质疑。

毕业、招聘和晋升看重会议录用结果，是因为会议长期积累的声誉，让录用具有了“同行认可”的意义。要维持这种认可，会议就需要持续分享有价值的研究、组织有内容的讨论，并促成新的合作。

在我看来，会议规模扩大后，更需要说清楚自己关注哪些问题：目标系统面对哪些约束，现有方法留下了什么缺口，什么进展值得这个社区花时间理解。把共同关心的问题说清楚，能帮助新成员加入讨论，也方便不同方向的研究者相互理解。同时，会议也应鼓励研究者探索新的问题，并根据新的发现重新审视以往的判断。

CFP（Call for Papers，征稿启事）是会议向投稿人介绍研究议题和征稿范围的主要途径。它应当让作者快速判断：会议关注哪些问题，期待怎样的系统贡献，自己的工作为什么适合在这里讨论。如果 CFP 只罗列宽泛的领域名称，等到拒稿时才解释隐含的偏好，作者就很难据此选择研究课题和投稿会议，会议也要承担许多本可避免的评审工作。

因此，CFP 应写清核心议题、范围边界、接受的贡献类型，以及不同 track（征稿方向）的证据要求，必要时用例子解释容易混淆的情形。其中，要区分投稿必须满足的要求和会议特别鼓励的研究方向。对于跨领域研究或新问题，作者需要解释自己的工作与会议关注的系统问题有什么关系，会议也应据此判断工作是否符合征稿范围，不能只看关键词是否匹配。筛选论文的标准应提前写进 CFP，让作者在投稿前就能了解。

同行评审要判断什么

同行评审要根据会议关注的问题和公开的标准，评价每一篇投稿。审稿人应具备相关专长、没有利益冲突，并根据本次提交的论文和证据，说明支持录用、修改或拒稿的理由。SOSP 的公开评审标准²包括新颖性、重要性、相关性、清晰度与正确性。审稿人既要判断贡献的价值，也要检查技术论证是否成立。

评审还有一项容易被录用结果掩盖的作用：把社区对好研究的理解传递给作者。通过具体的评价和讨论，作者可以知道同行为什么重视某个问题、什么证据足以支持一项主张、哪些设计取舍需要交代。这些反馈能帮助研究者改进眼前的论文，也能引导他们在下一项工作中提出更有价值的问题。无论作者有没有使用 agent，这些要求都应适用。

社区的共识和价值观也会变化。评审应说清判断的依据，让作者在收到决定后能够回应和质疑，并在后续研究或投稿中说明不同看法；新的问题、方法和证据，也可能改变社区原有的看法。好的评审既传递已有经验，也给新的判断留下空间。

对于系统研究，一份有用的评审至少应回答四个问题：

1. 这项工作增加了什么知识？贡献可能来自新的机制、设计原则、测量发现，也可能来自有价值的部署经验。
2. 作者的主张得到了多大程度的支持？基线、资源条件和工作负载是否合适，实验是否覆盖关键约束，局限有没有交代清楚？
3. 这项工作是否适合在这个会议讨论？目标读者、评审专长与相应 track 的要求是否匹配？
4. 哪些问题必须解决，作者应当怎样改进？程序委员会（Program Committee，PC）作出决定的关键依据是什么？

如何衡量一篇论文的质量

要把好质量关，就得说明怎样判断一篇论文的好坏。我认为，会议可以围绕问题、证据和贡献展开评审：先理解作者想解决什么，再看结论是否有证据支持，最后讨论这项工作对社区有什么价值。

Edsger W. Dijkstra 在《The Three Golden Rules for Successful Scientific Research》³中从研究者选题的角度提出三条建议：1）提高自己的质量标准，不要把时间都花在按部就班的问题上，尝试挑战自己的能力边界；2）当社会相关性与科学严谨性不能兼得时，优先保证研究的可靠性；3）如果可以确信能力和资源都不逊于自己的同行正在或即将研究同一问题，就避免在这一问题上重复投入，寻找自己能够作出独特贡献的方向。

这些建议也启发我思考，会议应当如何判断一项研究：它解决的问题是否值得关注？结论是否可靠？与已有研究相比，它带来了什么新的认识？尤其在 agent 可以更快地完成实现、运行实验和撰写论文时，我们需要认真追问这些问题。

审稿人应说清自己的判断，标明依据来自论文的哪些位置、哪些证据，并指出还需要解决的问题。对于未来硬件、新抽象等探索性工作，不应只看它是否已经在生产环境中部署；实验方法也应与研究问题相适应。系统研究有多种贡献形式，评价方法需要与贡献类型相匹配⁴。

例如，一篇提出新调度器的论文，声称能降低在线服务的尾延迟。审稿人应先问：目标工作负载中的延迟问题有多重要，现有调度方法为何不足？接着检查作者是否在可比的资源条件和调优投入下与合适的基线比较，是否覆盖负载变化，并报告吞吐量和资源代价。最后再问：论文解释了延迟改善的原因和失效条件，还是只展示了某组配置下更好的数字？这个例子中的新调度器即使在部分条件下无效，只要论文可靠地解释了它的适用限制及其原因，也可能给社区留下有价值的认识。

系统会议已经采取了哪些措施

在讨论 agent 原生的会议之前，先看与投稿压力、评审人力和 AI 使用有关的现行措施。

这些规则回应投稿和评审中的不同问题。除了评审压力，agent 也为研究社区带来了新的机会。

Auto Research：让社区更快成长

先来看看 agent 给研究社区带来的机会。借助 Auto Research（自动化研究），研究者可以更快地实现想法、搭建实验、定位错误和补充验证，缩短从提出问题到得到初步答案的时间。对一个新兴社区而言，这意味着它有机会更快积累成果，吸引同行参与。

假设一群研究者想围绕低成本推理系统建立社区。他们可以先明确共同关心的条件：延迟目标、内存预算、工作负载和部署环境。参与者借助 agent 实现不同的调度方案，在共同约定的条件下复查基线、寻找反例，再把结果带回来讨论。一次失败的尝试也有价值：它可能告诉大家，某种优化只在特定请求分布下有效，或者节省计算的代价是难以接受的尾延迟。

随着这些尝试积累，后来者不必每次从零开始：他们能找到可运行的基线、未解决的问题和前人的实验记录。Agent 帮助他们更快动手，会议让他们找到关心同一问题的同行。

这样的社区需要明确自己的研究方向。组织者可以与参与者共同整理尚未解决的问题、工作负载和实验条件，记录仍有争议的结论，并在 CFP 和专题讨论中说明研究重点。

一个会议是否有生命力，不能只看投稿数量，还要看有没有新研究者留下来，前一届提出的问题是否得到了更好的回答，已有成果有没有被使用、复查和修正。

研究加速之后，评审面临什么压力

Agent 帮助研究者更快完成论文，也降低了修改和再次投稿的成本。如果毕业、招聘或晋升依赖顶会论文数量，新增能力就可能转化为更多投稿。

更直接的问题是，研究者可能未经理解和核查，就把 agent 生成的论证、代码或实验结果复制进论文。例如，一段看似完整的实验分析，可能没有回答目标场景真正关心的问题；一张图即使来自实际运行，也可能使用了不合适的基线。这里需要防范的是缺少判断和验证的行为，不能把使用 agent 本身视为问题。人工完成的研究同样需要接受这些检验。

这里有“百万漕工衣食所系”的制度惯性：论文发表关系着毕业、就业和资源分配，评价方式很难随着研究工具的变化立即调整。会议即使扩充评审能力，新增容量也可能被更多投稿填满；评审人力能否跟上，还要看研究者有多大的发表需求，以及多投一篇论文能给他们带来多少好处。

守住质量，延续社区的研究品味

以论文质量为准，而不是中稿率

提交和修改论文越来越容易，同行检查其价值与证据仍需要时间。更多尝试可能带来新的发现，也可能产生未经充分判断和验证的论文；在这样的情况下，会议更需要严格把关论文质量。

当投稿量因为研究工具进步而增加时，会议可能面临维持既有中稿率的压力。我认为，中稿率应是评审的结果，不能成为决定录用数量的目标。不能为了把比例维持在某个数字，就降低要求、接收本未达到标准的论文。

严格控制质量，需要回到会议公开的标准：问题是否值得社区关注，贡献是否清楚，证据是否支持结论，关键的设计取舍和局限是否得到解释。Agent 可以帮助作者完成实现和实验，但表达完整、图表齐全并不能代替这些判断。

如果会议长期为了维持某个中稿率而放宽标准，录用所代表的同行认可就会逐渐失去含义。作者得到的信号可能从“解决值得研究的问题”变成“生产足够多、看起来完整的论文”；久而久之，会议的研究品味（research taste）和社区对其评审的信任都可能受到侵蚀。

由谁代表社区作出判断

投稿增加后，一些会议尝试从作者中扩充审稿人。前面提到的 SoCC 候补审稿人制度¹¹是一种做法；机器学习领域的 ICLR¹²、ICML¹³ 也有互惠评审安排，各自的资格、负荷和豁免条件不同。

我不建议系统会议依靠候补审稿人制度应对投稿压力。增加审稿人，也意味着由更多人代表社区评价研究、向作者传递标准。审稿经验有多少、博士毕业多久、具有什么学位或职位，都不足以说明一个人是否理解并愿意维护这个社区的研究品味。

一个会议的研究品味体现在它如何看待问题的重要性、设计的洞见、实验的说服力和结论的适用边界。熟悉领域的同行通过选稿、讨论和反馈，逐渐形成并修正这些标准；具体分歧也会促使大家重新审视自己的判断。如果只是为了处理更多论文而不断增加审稿人，就可能在新成员尚未充分理解社区标准时，让他们代表会议作出判断。

会议需要邀请新的同行加入，补充不同方向的专长。SIGCOMM 的社区介绍¹⁴和 SIGPLAN 的 PC 主席指南¹⁵都提到，选任时需要考虑程序委员会的组成和评审能力。会议可以开放自荐和同行推荐，结合候选人的代表性工作或评审经历，了解他们如何判断问题的价值、理解证据并给出建设性反馈；也应为年轻研究者、产业界和新方向的专家提供参与机会，避免只依赖熟人推荐。

新成员进入后，可以先独立完成初评，再与有经验的同行讨论判断依据：为什么某个问题重要，哪些证据支持了结论，分歧又来自哪里。资深成员需要解释自己的理由，也要认真回应新成员的质疑。这样的交流既传递社区的经验，也让原有标准接受检验；“志同道合”意味着愿意围绕共同问题交流，而不必对每项研究有相同看法。

让 agent 参与研究与评审

随着研究方式的变化，我尝试设计一套涵盖投稿、评审和版本管理的会议流程：尽早判断投稿与 CFP 是否匹配，保留各次提交的论文版本，帮助审稿人找到相关证据，减少重复阅读，让专家把时间用在需要深入判断的问题上。

下图概括本文设想的研究与发表流程：蓝色表示研究者和同行的判断或行动，绿色表示 agent 辅助，灰色表示流程阶段。

让研究结论经得起核查

要避免作者直接使用自己尚未理解的结果，会议可以先在 CFP 和评审标准中写清对作者的要求：作者应说明研究问题为什么值得关注、关键设计选择基于什么理由，以及主要结论由哪些实验或其他证据支持。评审应指出具体缺口，让作者知道需要补充什么，也让社区的判断标准通过反馈传递出去。

我认为，会议不应要求每篇投稿都提供复现环境。系统研究可能依赖特定硬件、生产环境或难以公开的工作负载，为每项工作准备这样的环境并不现实。Artifact evaluation（研究产物评估）可以由作者自愿参加；例如，SOSP 2026 的 artifact evaluation²就是可选的。

审稿人应当结合问题的重要性、评测方法是否合理、对比是否公平、证据能否支持主张等方面判断工作；对于存疑之处，应指出具体问题，供作者在收到决定后补充证据或修正结论。有条件的作者也可以自愿分享代码、数据或复现材料，供社区进一步检验和使用。

这些要求针对研究内容和作者责任，对使用与不使用 agent 的工作一视同仁。工具可以生成代码、运行实验、整理结果，甚至帮助发现错误，但它不能对论文中的纰漏或幻觉负责。虚构的引用、错误的实验分析或缺乏证据的结论，即使来自 agent，责任仍由署名研究者承担；各作者按其贡献承担相应责任，作者团队也应保证提交内容经过核查。发现错误后，作者需要解释并修正，不能把责任推给工具。

借助 agent 初筛，尽早反馈投稿是否符合 CFP

CFP 写清楚之后，会议还需要尽快向作者反馈：论文是否符合征稿范围，问题和贡献是否值得进入全文评审？我建议会议从投稿完成起，在 1—2 周内向作者返回初筛结论和具体理由。

两页摘要如果能独立讲清研究内容，就可以让审稿人初步判断：工作是否符合会议关心的议题，问题是否值得研究，核心贡献是否值得进一步评审。摘要需要讲清研究动机、已有方法的不足、核心想法和初步结果，让同行理解作者试图解决什么问题。ATC 2026 的两页摘要指南¹⁶即提供了这样的写作参考。

初筛的判断应有明确理由。通过初筛后，审稿人仍需阅读全文，核查设计、实验和结论；对跨领域或容易被误解的新方向，也应安排熟悉相关问题的同行复核。ASPLOS 2027 的 rapid review⁶ 提供了一个参考：审稿人阅读正文前两页，判断这项工作是否推进了会议关注的核心研究方向，以及程序委员会是否有足够的专长来评审；如果程序委员会缺少足够专长，会尽早退回投稿。

要在投稿量较大、审稿人时间有限的情况下尽快完成初筛，我认为这套流程必须引入 agent 辅助。Agent 根据本届公开的 CFP、两页摘要或会议规定的其他初筛材料，梳理研究问题与贡献，给出“符合范围”“可能不符”或“需要澄清”的初步判断，并列出对应的 CFP 条目、论文中的具体位置和理由。

每个会议还可以提供一个面向作者的投稿工具，集成到 HotCRP 等投稿系统中。作者上传论文后，agent 自动阅读论文，识别研究问题、方法与贡献，结合本届 CFP 判断可能涉及的方向，尽早提示主题不匹配或需要澄清的地方，并指出相关的 CFP 条目和论文内容。作者不必再手动勾选研究方向；如果 agent 理解有误，作者可以修改表述或补充说明，也可以重新考虑投稿会议。

对论文内容的这些分析，也可以用于匹配审稿人。会议可以要求每位作者维护并关联至少一个可核验的学术档案，例如 ORCID、Google Scholar 或 OpenReview；审稿人也提供相应档案，并说明能够承担的审稿量。Agent 根据论文涉及的问题和方法，结合这些档案中的研究经历与专长，从会议选任的审稿人中推荐并分配合适的同行，同时给出匹配依据。跨领域工作可以匹配来自不同方向的审稿人，不必强行归入作者选择的单一标签。

利益冲突也应由 agent 自动识别，不依赖作者在投稿时逐一手动申报。系统可以结合已关联的学术档案及会议有权使用的资料，检查作者与候选审稿人之间的共同发表、机构任职、师生等关系，再按会议公布的冲突类型和适用期限排除不合适的人选。

完成评审后直接决定，及时反馈

对于通过初筛的论文，我建议取消 rebuttal（作者回复）阶段。审稿人完成全文评审和程序委员会内部讨论后，会议直接作出录用或拒稿决定，并尽快把决定和评审意见发给作者。OSDI 2026⁹ 已取消作者回复；我建议把这种做法与快速反馈结合起来，让作者尽早拿到决定和评审意见。

拒稿意见应让作者知道接下来能做什么。会议应说清主要理由：是问题或贡献没有达到要求、证据不足，还是工作超出征稿范围，或会议缺少合适的审稿人。对于论文内容上的问题，评审还应指出具体位置。作者拿到反馈后，可以补充实验、修改结论或完善论证，再选择合适的会议投稿。

重投之后，会议如何协作

作者收到决定后，可能修改工作并继续向其他会议投稿。如何利用已有评审、减少重复劳动，同时保留每一轮的独立判断，需要会议之间共同考虑。

借助版本差异了解研究进展

对于重新投稿的论文，作者可以提供上一次实际提交的版本和修改说明，解释问题定位、系统设计、实验与结论发生了什么变化。Agent 可以对比论文的不同版本，整理出改动说明，标明对应的章节和图表，并区分文字调整、方法变化、新增证据和结论修正。作者可以纠正说明中的错误，审稿人也能据此核查改动。

重投历史会不会带来评审偏见？

了解重投历史，也可能影响审稿人的判断。审稿人如果先知道一篇论文已被其他会议拒绝，可能带着负面预期阅读，并更容易接受支持拒稿的理由。

Stelmakh 等人在 2020 年开展了一项随机实验¹⁷，让 133 名新手审稿人评阅 19 篇论文。提前收到“曾被类似会议拒稿”信号的一组，十分制总体评分平均低 0.78 分，95％置信区间为下降 0.24 至 1.30 分。

一个值得尝试的做法，是把投稿是否合规的核查，与对论文本身的评价分开。获授权的主席先核查投稿历史，以及不同投稿的评审时间是否重叠。审稿人根据本次提交的论文独立完成初评，再查看必要的改动说明和上一轮尚未解决的问题。OSDI 2027¹、SOSP 2026² 已采用先完成评审、再展示重投说明的做法。

旧评审可以指出值得继续解决的技术问题，作者也需要解释为何没有采纳某条具体意见。对存在争议的论文，可以请未参与上一轮的同行复核。

跨会议共享投稿信息与禁投机制

减少重复劳动，还需要跨会议协作。OSDI、SOSP、ATC、ASPLOS、EuroSys、NSDI、SoCC 等会议可以约定如何共享投稿记录，并限制访问权限。记录包括研究工作及其各个版本的标识、作者、投稿和撤稿时间、决定时间，以及是否仍在评审。只有获授权的主席或核查人员可以访问，查询过程也应留有记录。

在此基础上，作者申报重投历史与修改说明，工具辅助比对版本和时间重叠，最后由获授权的人员核实。这可以支持识别一稿多投，也可以帮助判断作者是否遵守事先公布的重投要求。

我建议会议建立明确的禁投机制，并事先公布适用情形、核查程序和处理方式。对于查实的一稿多投，以及违反事先公布的重投规则、没有实质修改也没有合理说明就直接转投的情况，会议可以依据这套机制，对相关责任作者采取禁投措施。作出决定前，应由人工核实违规事实，并确定每位作者的责任。禁投是否适用于其他参与会议，需要会议之间另行约定。拒稿后的顺序转投，特别是原会议因范围或专长不匹配而拒稿时，未修改并不自动构成学术不端。

USENIX 的现行政策¹⁸允许主席为维护投稿诚信与其他会议主席或期刊编辑共享信息，并允许对违规者采取一定期限的禁投等措施。

让会议成为持续研究的起点

Agent 原生的会议，还可以把研究讨论延伸到投稿之前和录用之后。社区可以公开参与者自愿分享的实验材料，持续记录开放问题和复现结果；参与者借助 agent 做新的尝试，把得到的证据带回讨论。会议组织者需要为这些活动提供清楚的参与方式和适当的资源，并明确由谁负责后续维护。

专题 session 可以集中讨论尚未解决的问题：有哪些相互冲突的实验结果，差异来自哪些条件，下一步怎样验证。会议也应给原型演示、失败经验和设计取舍留出讨论时间。年轻研究者应当有机会提出问题、展示初步工作并找到合作对象。还没有写成完整论文的研究，也应有交流机会。

公开研究成果、持续验证和线下交流，不必都按同一个时间表进行。例如 SIGMOD 的录用论文¹⁹先发表于 PACMMOD，再邀请作者到会议报告，已经展示了出版与会议报告分开组织的一种方式。

让研究评价与博士培养跟上变化

会议流程怎么调整，还会受到外部评价方式的影响。如果评价只看顶会论文数量，研究者就会继续把精力放在增加论文数量上。随着 agent 承担更多实现、实验和写作工作，仅凭论文数量，也越来越难看出研究者本人作出了多少贡献。

院系和招聘委员会可以选取几项代表性工作，让研究者说明自己的具体贡献，解释怎样选择问题、作出关键设计、安排并完成验证、处理失败和修正判断。DORA（《旧金山科研评价宣言》）关于依据研究内容、承认多种研究产出的倡议²⁰，可作为参考。

博士培养也可以围绕具体的研究决策来考察学生：为什么选择这个问题，为什么采用这组基线，实验失败说明了什么，换一组资源或工作负载后，哪些结论仍然成立。学生需要能够解释并捍卫自己参与完成的研究，包括 agent 生成的代码和实验。

展望未来

我期待 agent 原生的系统会议能把关心共同问题的研究者聚在一起，让大家借助 agent 更快地实现想法、验证结果，也吸引更多同行参与。

借助 agent，我们可以快速筛选和匹配论文，让作者更快得到反馈；研究者和审稿人仍要对论文和评审负责，认真判断研究问题是否重要、证据是否可靠、贡献是否有价值。

这样一来，我们可以腾出更多时间和精力，研究自己真正关心的重要问题。借助新的工具，也许更多研究者有机会重新审视一些过去较难入门的方向，例如分布式系统中的一致性与容错、操作系统中的隔离与资源管理。现有设计是否已经足够好？技术和应用都在变化，还有哪些问题值得重新研究？期待更多研究者带着这些问题重新出发，为系统领域带来新的认识。

回过头看，会议留下的不只是论文集，还有持续交流的社区，以及后来者可以检验、改进的研究成果。每一届的讨论，都可以成为下一步研究的起点。站在前人的肩膀上，我们才得以看得更远。

参考资料

• 上一篇
  《史蒂夫·乔布斯传》