你有没有让AI帮你写过一份深度研究报告？
那种几千字、要查资料、要分析、要有理有据的那种。如果你试过，大概率会遇到一个尴尬场面：AI一开始写得挺像样，写到后面开始重复啰嗦，或者你想让它补充一个新发现的信息，它一改就把前面写好的内容改乱了。
这不是AI偷懒，而是一个更深层的结构性问题。美团LongCat团队最近发的一篇技术报告，把这个问题讲透了，还给出了一套解法。这套系统叫LongCat-DeepResearch，在几个权威的深度研究评测集上拿到了不错的成绩，我们今天就来聊聊它到底解决了什么、怎么解决的。
写报告这件事，难在哪
先说一个可能违背你直觉的事实：写一篇开放性的深度研究报告，比回答一个具体问题难得多，难的不是"找不到答案"，而是"你一开始根本不知道要找什么"。
这么说吧，如果你要查"2023年某公司营收是多少"，这是个封闭问题，答案就在那里，找到就行。但如果你要写一篇关于"AI在金融投资中的应用"的综述报告，你在动笔之前，根本无法穷尽所有要涉及的理论、案例和最新进展。你可能写着写着才发现，漏了一个关键的研究团队，或者某个论断需要补充新证据才站得住脚。
这就是研究报告和普通问答的本质区别：证据需求是在写作过程中逐渐暴露出来的，而不是一开始就能列清楚的清单。
那现有的AI系统是怎么处理这个问题的呢？报告里提到，主流路径大概有两种。一种是让AI一边搜索一边推理一边写，走一步看一步；另一种是先搞出一份草稿，然后不断拿这份草稿去指导后续的检索和修改。
这两种做法都会撞上同一堵墙。
**当研究历史越滚越大，或者需要反复重写整篇报告时，会出现三个具体的麻烦。**
第一个麻烦是资源打架。证据、中间推理过程、草稿文字，这些东西全都要塞进AI的"脑子"（也就是它能处理的上下文窗口）里，空间有限，就得压缩。可压缩这个动作本身很危险,你现在觉得不重要而删掉的信息，很可能就是后面写到某一段时突然变得至关重要的证据。
**上下文窗口**：指AI一次能读取和处理的文本长度上限，好比一个人一次能记住的信息量，超出这个量就得取舍。
第二个麻烦更隐蔽,早期形成的一些结论会像磁铁一样吸住后续的思路，让AI后面的搜索都围着这个初步判断转，视野越写越窄。第三个麻烦是效率问题：每次有新证据进来就把整篇报告重写一遍，等于是为了改一句话，把全书都印刷了一遍。
这三个问题合在一起，逼出了LongCat团队的核心追问：**能不能让AI既保持一个共同的研究方向，又不必把所有细节都塞进一个越滚越大的雪球里？**
ResearchSpec：把"报告草稿"换成"报告说明书"
LongCat团队想出的办法，说白了就是四个字：分而治之。但这四个字怎么落地，才是真正见功力的地方。
他们引入了一个叫ResearchSpec的东西。
**ResearchSpec**：可以理解成一份"研究执行说明书"，它不是报告本身，而是对报告需要覆盖哪些内容、每部分要回答什么问题、需要什么证据的一份紧凑清单。
这里的巧思在于，团队没有让AI一上来就动笔写草稿，而是先让多个独立的"规划写手"（Planning Writers）分头去互联网上简单搜索、阅读资料，然后各自提出一份候选的报告结构。这几份草案会被一个叫"规划裁判"的角色汇总合并，再由一个"批评者"角色专门去挑毛病、找遗漏，最后由"修订者"把这些反馈吸收进去，形成最终版的ResearchSpec。
这个过程你可以想象成公司里筹备一个大项目。如果只让一个人闷头做方案，那这个人的知识盲区就是整个项目的盲区，他没想到的角度，永远不会出现在计划里。但如果先让三个不同背景的同事各自琢磨一版方案，再开会碰撞、挑刺、补漏，最后拿出来的方案质量显然会更扎实。如果没有这个"多人分头探索再汇总"的步骤，报告的整体视野很可能一开始就窄了，后面写得再细也救不回来。
ResearchSpec里记录的东西很具体：每个小节要覆盖的范围、需要回答的研究问题、必须提到的实体或案例，还有初步的信息来源线索。每个可以独立执行的小节都有一个唯一编号，比如S1.2，团队管这些执行单元叫"section"。
**section（章节/执行单元）**：报告里可以被单独分配给一个研究员独立完成的最小写作单位，有点像团队项目里"这一块归你负责"的任务包。
值得一提的是，这份说明书在正式分发给各路"研究员"去干活之前，会经过验证器检查,编号有没有重复、父子关系对不对、顺序是否连贯、必填字段是否齐全。有问题就打回去修，实在修不好就回退到之前验证过的版本。这是个挺工程化的细节，但恰恰说明团队把"计划质量"当成了一件不能将就的事,毕竟这份计划一旦定下来，就要在后续阶段被"锁死"，不会再轻易推翻重来。
有意思的是，团队专门做了个实验来验证"计划要不要反复打磨"这件事，值得多说两句。他们设计了四个阶段：W0是只用一个写手的方案，J0是三个写手方案经裁判整合后的版本，R1是再经过一轮"批评-修订"循环的版本，R2是两轮循环后的版本。
结果挺耐人寻味。**从W0到J0，也就是从单人方案到多人整合方案，无论是计划本身覆盖的完整度（从53.76%涨到60.47%），还是最终报告在ResearchRubrics评测上的得分（从81.67涨到85.13），都有明显提升。**
但从J0到R1、R2，也就是继续增加批评修订轮次，计划覆盖度确实还在爬（63.14%到62.48%），可最终报告的得分反而有点起伏，R1的83.24分和R2的84.89分都没超过J0的85.13分。
这说明什么呢？说明"集思广益"这一步是真金白银的收益，但"反复精雕细琢"之后，收益会打折扣，甚至可能不划算。研究团队自己也坦诚地写道，这是"喜忧参半的效果"，没有回避这个不那么漂亮的结果。这种诚实挺难得的，很多技术报告会选择性地展示最好看的那组数据，但这篇报告把矛盾的地方也摆出来了。
每个章节独立开小灶：写作和查证不脱节
计划定好了，接下来就是真正动手研究和写作的阶段。这一步的设计思路也很有意思。
LongCat团队让每一个"研究员"智能体，只拿到三样东西：最初的用户问题、完整的ResearchSpec、还有分配给它的那一个具体章节任务。然后这个研究员就在一个完全独立的上下文环境里，自己去搜索资料、自己去阅读验证，最后自己把这一节内容写出来。
这里的关键设计是,同一个智能体既是这一节的"调查员"，也是这一节的"撰稿人"，中间不需要经过一次"我先总结给别人听，别人再帮我写"的转手。
这个设计解决了什么问题？我们可以拿记者写深度报道来打比方。如果一个记者去实地采访三个月，回来后只交给另一个人一份浓缩的采访提纲，让那个人凭提纲写稿子，那写出来的稿子必然会丢失很多现场的细节和微妙的语气,因为提纲本身就是一次信息损耗。但如果采访者自己动笔写，那些没写进提纲、但采访时记在心里的细节，反而更容易被自然地写进正文里。
如果不这样设计，让研究和写作分成两个角色，会发生什么？报告里专门做了对照实验，叫"一个跑全流程的研究员
万隆优配提示：文章来自网络，不代表本站观点。
