给 AI 论文助手做了两次「大脑手术」：从单打独斗到专家团队
做学术论文 AI 产品快一年了，最近连续完成了两个核心模块的架构升级——论文打磨模块和数据分析模块。分享一下思路。
Part 1：论文打磨模块
在 CoPaper.AI 里，论文初稿生成完成后会进入「论文打磨模式」——你可以通过对话让 AI 改论证、调结构、跑回归、润色文字、回复审稿意见。简单说，从初稿到终稿之间所有的迭代修改，都在这里完成。
之前的问题：一个 AI 干所有活
最早的设计是一个 AI 助手负责所有论文修改任务——改内容、调结构、跑回归、润文字、回审稿意见……二十多个工具全塞给一个 Agent。
结果就是：
- 它经常选错工具（你让它改图表，它去改了段落）
- 每次调用都要处理巨长的上下文
- 想加新功能就更臃肿
升级思路：一个调度中心 + 多个专家代理
借鉴了多代理协作的学术前沿思路，把一个「全能但平庸」的 Agent 拆成了一个调度中心 + 多个专业代理。每个代理只负责一类任务——有的专门改内容，有的专门调结构，有的专门处理实证分析，有的专门润色格式……各司其职。
核心设计理念
1. 上下文隔离
每个专家代理只加载与自己任务相关的信息。处理数据分析的代理不需要看文献综述，处理格式的代理不需要看代码。这样每次 AI 调用的 token 消耗大幅降低。
2. 模型分层
需要深度推理的任务用强模型，模式化任务用轻量模型。不同的任务匹配不同的模型，成本和质量的最优平衡。
3. 专属能力解锁
拆分后每个专家可以拥有自己的专属工具和能力——比如精细化的代码局部编辑、跨章节内容移动等。这些在单体架构下很难实现。
4. 适度修改原则
AI 修改的幅度应与用户请求的范围成正比。用户让你改一个段落，你就只改那个段落，不要顺手把全文都重写了。防止 AI「过度热心」。
效果
- 任务路由准确率明显提升
- 单次调用的上下文大幅减少
- 解锁了一批之前做不到的精细化功能
- 新旧架构可以平滑切换，零风险上线
对论文打磨意味着什么
论文从初稿到最终定稿，中间要经历大量反复修改——审稿人让你补一个稳健性检验，导师觉得第三章论证不够有力，你自己发现摘要和正文的数字对不上……这些修改类型完全不同，但以前全靠一个 Agent「猜」你想干什么。
升级后，打磨体验变了：你说「换一种回归方法」，负责实证的代理直接改代码跑分析、更新图表，不会误碰你刚润色好的文字；你说「适配某某期刊格式」，负责格式的代理只动排版和措辞，不会改你的模型设定。每个代理各司其职，修改精准且可预期。
对于做实证研究的同学来说，论文打磨往往比初稿更耗时间。这次架构升级，就是让 AI 在「改论文」这件事上，从一个手忙脚乱的实习生，变成一个配合默契的专家团队。
Part 2：数据分析模块
在 CoPaper.AI 里，你上传数据后就进入「数据分析模式」——这里的 AI 可以帮你做数据清洗、跑回归、画图表，甚至直接帮你写论文。从一个只能做简单数据清洗的工具，到现在能独立完成「数据 → 分析 → 论文」全流程，这个模块经历了一次脱胎换骨的进化。
进化之路：从「数据清洗工具」到「全能研究搭档」
这个模块的升级不是一步到位的，而是经历了渐进式的进化：
第一阶段：数据清洗工具
最初只是一个简单的数据预处理工具——上传数据、做简单清洗、导出结果。跑完清洗就完了。
第二阶段：实证分析平台
后来意识到，用户上传数据不只是为了「洗数据」，更想直接做实证分析。于是大幅扩展了统计分析能力，支持了多种主流的计量经济学方法和高级建模技术，同时加入了可视化输出和多数据集管理。
这个模块也从「数据清洗工具」正式更名，定位为一个完整的实证分析平台。
第三阶段：论文写作能力
这是最大的一次飞跃——不再只是「跑完模型给你看结果」，而是可以直接帮你把分析结果写成论文。AI 可以根据数据和分析结果自动生成论文大纲，然后分节撰写，分析代码和论文章节自动关联，最终可以导出为标准的文档格式。
整个体验变成了：上传数据 → 探索分析 → 生成大纲 → 逐节写作 → 导出论文，一站式完成。
第四阶段：多代理架构
功能越来越多，工具越来越多——于是遇到了和打磨模块一样的问题：单体 Agent 不堪重负。
同样引入了调度中心 + 多个专业子代理的架构：不同的子代理分别负责数据处理、统计建模、图表可视化、论文写作等任务。每个子代理只接收与自己任务相关的上下文，上下文精简带来了更准确的任务执行和更低的成本。
一个贯穿两个模块的设计原则
适度原则（Proportional Response）
无论是论文打磨还是数据分析，我们都遵循同一条原则：AI 做的事情应该精确匹配用户请求的范围，不多不少。
你让它跑一个描述性统计，它就只输出描述性统计，不会自作主张加上回归分析。你让它改一个段落，它就只改那个段落，不会顺手重写全文。
这条原则看起来简单，但在实际产品中非常关键——很多 AI 产品的痛点不是「做不到」，而是「做太多」，用户反而搞不清楚哪些是自己要的。
总结：做 AI 产品的两点感悟
做了两次架构升级后，最大的感悟：
1. 不是模型越强越好，而是让对的模型做对的事。 多个专注的专家，胜过一个什么都懂但什么都不精的通才。
2. AI 产品的核心体验不是「AI 有多聪明」，而是「AI 有多懂边界」。 教 AI「什么时候该收手」，比教它「怎么做得更多」更重要。
这个思路不只适用于论文场景，任何复杂的 AI Agent 产品，当工具数量增长到一定规模，都值得考虑拆成多代理架构。