最近经常有人问我“用 agent 来写论文到底靠不靠谱”。我的答案是这样把论文拆开、分角色、分步骤交给 agent 来做靠谱想让一个 agent 从头到尾自动生成一篇完整论文基本不靠谱。这个区别很关键搞清楚了你的效率能提高不少搞不明白你会被一堆看起来很唬人、实际上没法用的内容坑得很惨。这篇文章想跟你聊的就是“怎么用 agent 把写论文这件事做成一条流水线”。我会从设计思路开始讲到角色拆解、工作流配置、具体的 prompt 模板、文献引用处理最后把那些踩过的坑和排查方法也整理出来。适合正在写课程论文、开题报告、文献综述或者给公司写技术方案的人参考。前提是你自己得清楚研究问题是什么agent 不是帮你思考的它是帮你执行那些重复、机械、耗时间的环节的。1. 换个思路agent 不是替你把论文写完是在拆流水线1.1 为什么直接对话式生成论文不行很多人的第一反应是打开一个对话窗口输入“帮我写一篇关于某某方向的论文”然后等结果。我试过也看过不少人这么干最终得到的要么是一篇四平八稳、但没有任何实质贡献的空话集要么是一篇结构混乱、前后观点互相打架的“缝合怪”。原因很简单论文是一个需要分阶段验证、纠错、迭代的长文本工程不是一次生成任务。如果你把“写论文”这个大问题直接丢给对话模型它会基于统计概率给你拼一段最像论文的文本。这段文本缺少几个关键东西没有真实文献支撑引用全是编的。没有明确的研究问题和假设所以论证没有主线。没有结构上的自我校验章节之间经常脱节。它无法记住前面写过什么更谈不上迭代修改。所以我现在的判断是agent 的价值不是替代你写而是帮你把“写论文”变成“多角色协作的项目”。让不同 agent 分别负责检索、归纳、提纲、起草、复核最后你只要做决策和判断这个流程才走得通。1.2 agent 编排和普通对话式 AI 写作的差别打个比方。普通人用 AI 写作就相当于你雇了一个实习生对他说“你去把这篇论文写出来”实习生一脸懵最后给你交一堆废话。而用 agent 编排就相当于你自己当项目经理把任务拆成“查资料整理文献”“列提纲”“写第一段”“检查引用是不是真实”“统一专业术语”这些岗位每个岗位配一个实习生而且每个人只做自己最擅长的事产出还可以在流水线上被下一道工序拿去用。这种思路下每个 agent 不需要有很强的大局观它只需要在一个非常具体的任务上有不错的输出。比如“文献检索 agent”只需要找到文献关键词、摘要、核心结论“综述起草 agent”只需要把检索 agent 提供的文献笔记变成段落。你作为总指挥随时可以叫停、修改、重新发回去。这么做还有个好处过程可控。每个环节都有中间产物出了问题你知道是哪个环节错了而不是面对一整篇莫名其妙的内容无从下手。1.3 这套思路适合谁、不适合谁我见过最受益的人有两类。一类是刚开始接触科研的学生还没建立文献阅读习惯agent 可以帮助他们在短时间内整理出研究脉络但前提是用来做辅助不是直接当写手另一类是写技术报告、项目总结、产品方案的人他们不缺业务认知缺的是把零散信息组织成结构清晰文档的效率。不适合用 agent 的人也比较清楚完全不懂自己在研究什么、只想拿一篇“看起来像论文”的东西交差的人。这跟学术诚信直接相关。用 agent 做结构化整理和做最终内容的生成者之间界线很微妙。我的原则是agent 永远可以帮你写初稿但最后的观点、实验、数据、结论必须是你自己确认过的。2. 把论文拆成多个“角色”agent 编排的核心逻辑2.1 按研究流程拆角色而不是按章节拆结构安排上很多人喜欢问“我用一个 agent 写绪论另一个写综述这样行不行”。我试过效果很差。因为论文章节之间是层层依赖的你都没确定研究问题绪论凭什么写得出来就算写出来也是空的。我更愿意按研究流程拆而不是按章节拆。一套比较稳的分工是这样的课题拆解 agent把宽泛的方向拆成可操作的研究问题。文献调研 agent批量获取候选文献输出结构化文献卡片。综述整合 agent把文献卡片按主题合并找出研究空白。大纲规划 agent基于研究问题、文献综述和草稿方向生成章节级大纲。分节初稿 agent按大纲一节一节地写不承担全局规划任务。审稿 agent检查文本的逻辑一致性、术语统一性、论证完整性。每个角色负责一个独立的子任务角色与角色之间靠文件传递信息而不是在同一段对话里不断“聊下去”。这样你能随时把某个环节的输出单独拿出来看发现问题也可以精准地返工。2.2 单 agent 长会话和多 agent 协作怎么选并不是所有论文写作都必须做成多 agent。如果你的任务比较小比如一封汇报邮件、一个小型项目报告那用一个 agent 多轮对话就够了。但论文的长度和复杂度决定了单 agent 多轮对话会出现严重的上下文问题到了第 20 轮前面第 3 轮你强调过的关键术语模型已经忘得差不多了。多 agent 的价值在于把上下文封装到文件里一个 agent 只关注它需要关注的那一小块内容。但它的代价也很直接配置复杂、token 消耗增加、流程调试成本高而且可能过度设计。我的建议是阶梯式选择第一阶段先用“单 agent 多轮状态记录”你在外部记录研究问题、术语表、大纲每一轮对话时都把这些状态重新喂给它。这种方式已经能撑住百分之七八十的论文写作场景。等到你真正常态化写比较长的论文或报告再上多 agent给每个任务单独写 prompt 和校验逻辑。2.3 中间产物要结构化这是整个编排的支点这是我在实际项目里收获最大的一条经验agent 之间交换的信息最好不要是自然语言段落而要是结构化的数据。比如文献调研 agent 的输出应该是一个个字段清晰的条目而不是一段串在一起的文字。我常用的中间产物格式是 JSON 和 Markdown。文献卡片用 JSON 存因为后续可以用脚本检索、去重、排序大纲和初稿用 Markdown 存因为方便在编辑器里审阅和加批注。举个课题拆解 agent 的输出模板它输出的不是一个笼统的题目而是这样的结构{ research_question: 面向多源异构数据的智能家居用户行为预测方法, scope: 关注数据来源、特征处理、预测模型的适用性, variables: { input: 传感器数据、日志、用户标签, output: 行为类别或行为的时序序列 }, possible_methods: [transformer, 迁移学习, 图神经网络], risks: [数据标签质量不高, 模型泛化能力难以验证] }生成这种结构化输出之后下一步的文献调研 agent 才能知道该搜哪些关键词、应该重点看哪几个方向。如果课题拆解阶段输出的是一整段文绉绉的话后面所有环节都会被带偏。3. 实操配置一条可复用的论文写作 Agent 流程3.1 底座模型与 API 的选择思路选底座模型是很多人的第一个困惑。我的建议不是追最强性能的模型而是考虑三件事上下文长度、结构化输出能力、以及你在某个场景下的数据敏感度。理论上上下文长度越宽越好。但实际用下来2 万 token 以上的模型才勉强够支撑你在一轮对话里给它一篇论文的完整章节而 8K 上下文的模型就只能做分块处理。所以如果你要跑长文本流程尽量选择上下文更长的商用模型接口或者本地部署支持长上下文的大模型。至于本地部署还是调用 API这是个很现实的问题。调用 API 省事但你需要考虑数据上传之后的保密问题尤其是公司项目或未公开研究的数据本地部署自由度最高但对 GPU 和显存要求很高而且推理速度慢。我的做法是一般性文献综述和提纲规划用在线接口内部有保密要求的技术文档则走本地部署的开源模型速度慢一点但安全。模型参数方面论文写作不是艺术创作不需要太高的随机性。我通常把 temperature 设在 0.2 到 0.4 之间top_p 保持在 0.9 左右。太高的随机性会让论文出现一些你自己都想不到的奇怪论点太低又会显得机械重复几乎直接抄模板。3.2 工作流状态设计与参数设置设计工作流状态听起来有点工程化但做起来并不复杂。我一般用一个项目目录目录里放这样几个文件question.md研究问题和假设的最终版literature_cards.json文献卡片集合review_notes.md综述草稿outline.md当前的大纲fact_table.md全局事实表维护术语定义、关键数字、统一说法draft/按章节存放的初稿文件每个 agent 工作时读取自己需要的文件输出结果覆盖或追加到对应文件。人工参与的节点是每个环节执行完你先看一遍输出确认没问题再放行到下一步。为什么不直接在 agent 对话里存状态因为在对话里存状态是隐性的模型很容易在几十轮之后忘掉但文件是显性的哪怕换一个模型来跑只要文件还在流程就能接得下去。这个方法帮我解决了很多中间流程断裂的问题。3.3 Prompt 模板与上下文管理Prompt 是 agent 工作流里最容易被人高估又最容易被忽视的东西。很多教程说“一个咒语让 AI 帮你写论文”我看过之后只能说完全不靠谱。真实可复用的 prompt 通常很长而且需要包含清晰的任务描述、输入材料、输出格式、禁忌清单。我常用的一个初稿 prompt 结构是这样的你是论文初稿起草助手。你要根据给定的研究问题、全局事实表和章节要求写出当前章节的初稿。 研究问题 {research_question} 全局事实表仅允许使用这些术语和定义 {fact_table} 当前章节要求 {section_requirement} 输出要求 1. 章节篇幅约 1500 字分小节展开。 2. 所有专业术语必须与全局事实表一致。 3. 不要输出参考文献列表引用处用{{citation:key}}标记。 4. 禁止使用空泛的套话比如“随着科技的发展”“总而言之”这类表达。 5. 如果某个论据你无法确定直接写“待核实”不要编造。这里的重点有两个一是只传输当前章节需要的上下文不要把整本论文的笔记全部塞给模型二是用{{citation:key}}这类占位标记把引用问题单独剥离出来后面用脚本统一处理。这样能大幅减少 agent 编造文献的情况。上下文管理上我遵循“最小够用”原则。每个 prompt 只带四样东西研究问题、全局事实表、当前任务的输入材料、当前的任务说明。如果把历史章节全文也带进去很快会撞到上下文上限而且模型会被无关信息干扰。3.4 让 agent 引用真实文献的方法和局限论文写作绕不开文献而 agent 恰恰在文献引用上最容易翻车。大模型会一本正经地生成看起来完全真实的引用信息包括作者、期刊、年份但实际检索却根本不存在。这个问题如果靠人工核查来解决成本又太高。我目前感觉最靠谱的方案是先检索、后生成。也就是让文献调研 agent 先从外部数据库或本地 PDF 集合里提取真实存在的研究条目保存成文献卡片。综述或初稿 agent 在写作时只能从文献卡片里选取条目进行引用。这样就从源头切断了编造的可能性。操作上我会先把需要重点参考的 PDF 用工具解析出文本按论文题目、摘要、方法、结论、关键词保存。文献调研 agent 负责从这些文本里提炼条目然后我自己快速扫一眼把明显不是重点的删掉。等到写作的时候prompt 里明确写着“只允许引用文献卡片中的文献”并且要求它输出{{citation:key}}标记。这套流程不能保证 100% 无误但已经可以保证“你标注的每条文献至少真实存在于你提供的材料中”。至于引用格式、页码、卷号这类细粒度信息我会在最后人工校对阶段花时间补齐。没有 agent 能代替这一步。4. 核心环节落地从题目到初稿的完整示例4.1 选题与问题定义我拿一个虚拟的模拟项目来完整走一遍流程。假设我要写一篇关于“面向多源异构数据的智能家居用户行为预测方法”的论文如果直接把这句话丢给初稿 agent它会写出一篇足够空洞的水文。所以第一步是用课题拆解 agent 把它变成一个可控的研究问题。我给的输入是请把研究方向“面向多源异构数据的智能家居用户行为预测”拆解为具体研究问题。 需要输出 - 一个主研究问题 - 三个子问题 - 输入变量和输出变量 - 建议采用的方法 - 可能存在的风险得到的结果类似前面 JSON 模板里展示的内容。我随后人工修改了一版把主研究问题定位成“如何融合传感器高频数据与用户日志提升行为预测精度”并明确了输入是温度、光照、门窗传感器、使用日志输出是待预测的行为类别比如“离开房间”“睡眠”“娱乐”等。这一步做完后面所有环节才真正有的放矢。4.2 文献调研与综述生成文献调研阶段我会把之前收集好的 PDF 批量喂给文献调研 agent让它逐篇输出结构化卡片包括研究问题、方法、数据集、核心结论、局限。这个阶段不要求它写完整综述只需要把信息提取到位。随后我人工筛选掉那些与当前研究问题关系不大的文献再把保留的卡片交给综述整合 agent。整合 agent 的任务是识别文献之间的主题分组和研究空白而不是把每篇文献单独罗列。这个区分很重要因为综述的价值在于建立逻辑关系而不在于凑字数。最终综述部分会输出两到三个主题小节每个主题下有若干篇文献相互印证或对比。4.3 大纲生成与迭代有了研究问题和综述大纲就顺理成章了。我会把question.md和review_notes.md的内容放进 prompt请求大纲规划 agent 生成章节级大纲每一章还要附带“这一章要论证什么”“预计篇幅多少”。第一次生成的大纲通常不是最终版所以迭代是核心。比如大纲里第三章节只写了一句话“数据预处理方法”这明显不够。我会在旁边批注“本章需要补充多源数据对齐、缺失值处理、时间窗口划分三个子节”然后把批注和原大纲一起回传给 agent让它重新生成。这一步最需要耐心因为大纲定稿之前草稿写得越多返工越麻烦。4.4 分节初稿生成与一致性维护大纲确定之后开始逐节生成初稿。这里最忌讳一次让 agent 写完整篇论文。我一节一节生成每节生成完之后先通读一遍并把所有新的、需要全局保持一致的信息写进fact_table.md。实际例子里第四章第一节写到“传感器数据按 30 秒窗口切片”这个参数我会同时更新全局事实表记下“窗口大小: 30s”。等到第四章第三节要写关于特征提取的内容时prompt 中的事实表已经包含了这个参数agent 就不会写出自相矛盾的 60 秒窗口。等全部分节初稿完成后我会把整篇草稿拼接一起让审稿 agent 做一次“一致性扫描”。我会特地要求它只看下面几个维度术语定义是否统一、事实表里的数据是否在全文一致、每个章节是否回答了对应大纲的问题、有没有重复表达。这类检查用人工做同样能做但 agent 可以在十几分钟内扫完长文本效率确实高。5. 哪些地方最容易翻车问题排查速查表5.1 高发问题和排查路径下面这个表格来自我反复折腾的记录保留了最常见的几个问题和对应的处理方向。现象可能原因排查方向解决建议引用文献真实存在但细节对不上初稿 agent 只记住了文献标题细节被“脑补”检查文献卡片是否包含摘要、方法、结论强制初稿 agent 只输出 citation key不输出格式化引用前后章节术语不一致缺少全局事实表检查两节生成时间点之间是否更新了 fact_table每个 agent 运行前都重新读取事实表并把它放进 prompt整段都是“假大空”套话温度过高prompt 里没有禁止表达检查该章节生成的 temperature 设置降到 0.2 以下并在 prompt 里禁用典型套话生成到一半上下文丢失单次喂入的信息超过模型能记住的范围观察模型是否开始重复前面内容拆成更细分块每次只喂当前章节需要的上下文文献综述变成文献流水账综述 agent 缺少整合逻辑检查 prompt 是否要求按主题分组增加“对比、归纳、找空白”的任务指令生成内容专业术语严重错误没有导入领域资料只靠模型内部知识检查输入材料确认没有领域背景文件在写作前先让文献 agent 整理专业术语表并加入事实表5.2 处理幻觉和编造内容的具体办法幻觉问题在论文写作里不能靠“提示词警告”完全解决但可以减少。我在初稿 prompt 里专门加了一条硬约束“如果你没有把握宁可在该处写‘待核实’也不要编造一个看似合理的陈述。”实际执行下来它确实让模型更倾向于留出缺口而不是硬填内容。另一个办法是给 agent 限制材料来源。所有观点、方法、数据都要求它标注来源 key而这个 key 必须能在文献卡片列表里找到。如果一个观点在文献卡片里找不到来源分节初稿 agent 就不应该出现它。这是我现在最依赖的防幻觉机制。因为它不是靠模型自觉而是靠流程设计。5.3 避免上下文爆炸和流程僵化上下文爆炸是 agent 工作流里最常见的工程问题。我刚开始时为了让初稿 agent 保持全局观试图把前面所有章节都作为上下文传给它结果没多久就触发了上下文限制。后来改用“局部上下文 事实表”的方案每个章节只传当前材料和事实表效果明显更好。流程僵化则是另一个极端。当你把工作流设计得很严密时模型会变得很死板遇到稍微特殊一点的材料就不知道怎么处理。我的应对办法是在 prompt 末尾加一句“如果输入材料缺失请明确说明你缺少什么不要假设。”这让 agent 在不适合硬干的时候会主动求助而不是硬编。6. 一点个人经验用 agent 来写论文这件事我现在的体会是它最大的价值不是帮你省掉思考而是帮你省掉大量重复操作并且让“写论文”这个过程从一件模糊的、令人恐惧的大任务变成一连串可知的、可检查的、可修改的小任务。我现在已经形成了固定习惯每次启动新论文或重型报告时先花一到两天准备问题定义和文献卡片然后用 agent 快速生成一份带缺口标注的初稿再花同样多的时间去核实、补充和重写。整个流程的核心不是“让 AI 一次写得好”而是“让 AI 产出能被人工快速修正的东西”。最后分享一个小技巧不要只在某个对话窗口里做这件事把所有中间产物都落成文件用版本管理工具记录每次修改。这样一旦某次改动跑偏你可以随时回到上一个可用版本。我踩过太多次“改着改着把原本还行的地方改坏了”的坑版本管理是唯一能救回来的工具。论文也好技术方案也好最终是要署你的名字、为你的判断负责的。所以任何时候agent 是帮工你可以用它的速度推进但别放弃自己的判断权。