最近经常有人问我“用 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 是帮工，你可以用它的速度推进，但别放弃自己的判断权。
