第五章:大文档不是塞进上下文窗口就完了

并购尽调的数据室打开那天，小唐数了数，四百七十三份文档。

合同、章程、股东协议、融资文件、知识产权许可、雇佣协议、诉讼材料——加起来超过一万页。她的任务是找出所有与"控制权变更"相关的条款，确认触发条件、通知义务、违约后果和兜底责任。林薇给她两周。

小唐的第一反应是：把文档打包塞进 Agent。"现在模型上下文窗口越来越大，"她对陈默说，"这些文档是不是能直接塞进去？"

陈默没说话，让她先试试。

Agent 确实给出了输出。一份看起来相当全面的报告，分门别类列出了控制权变更条款，还做了风险评级。小唐花了半天时间通读，觉得基本可用，就发给了陈默复核。

陈默用了三个小时。前两个小时，他在核对 Agent 的引用和结论，一切正常。第三个小时，他打开了一份主合同对应的补充协议——那份只有四页的文档，躺在数据室的一个子文件夹里，文件名是"补充协议（二）- 修订版"。

补充协议第二条写着："尽管主合同第 12.3 条另有规定，如发生控制权变更，受让方须在变更完成后 30 日内，就知识产权许可的延续性向许可方提供书面担保。"

Agent 的报告里完全没有提到这条。

为什么漏了？小唐回去查日志，发现 Agent 的处理记录里确实没有那份补充协议。它读取了主合同，读取了大部分附属协议，但那份补充协议因为文件名里的"修订版"三个字，被系统归到了另一个批次，没有进入本次分析的上下文。

上下文窗口没有爆，但检索漏了。

那天晚上，林薇没有开会，只是把报告打印出来，在漏掉的那一页上折了一个角，放在会议室桌上。

"这不是小唐的错，"她说，"也不是 Agent 故意偷懒。是我们把大文档任务想得太简单了。"

陈默接话："我们以为大文档就是'塞进去'的问题。但尽调不是阅读理解，是在正确的时间找到正确的材料，并确认它们之间的关系。"

他们复盘了整个过程，发现了三个被忽视的环节：

第一，文档之间的关系比文档本身更重要。 补充协议之所以关键，不是因为它长，而是因为它修改了主合同。如果系统只是把文档切成碎片塞给模型，而不记录"这份补充协议对应哪份主合同、修改了哪一条"，模型就不可能知道这条条款的存在。

第二，元数据就是法律意义。 一份合同的签署日期、适用法律、修订历史、关联文档、交易主体、金额门槛——这些往往比条款本身更能说明问题。Agent 需要知道"这份协议是 2023 年签的，但 2024 年出了补充协议"，否则它会用旧版条款做判断。

林薇决定不再让 Agent"吃"整份文档库。

她要求技术团队构建一个专门的知识管理层。不是简单地把文档丢给模型，而是先对文档进行治理：按事项（matter）、文档类型、条款、日期、主体、风险标签和关联关系建立索引。文档被切分成逻辑片段，每个片段保留上下文——它属于哪份合同、前后条款是什么、有没有被其他协议修改过。

当律师发起一个任务时，系统不是把整个文档库塞给模型，而是根据任务动态取用相关片段和元数据。像一位经验丰富的尽调助理，在正确的时间把正确的材料放到律师桌上，并附上一份清单："今天用了这些，还有这些我觉得相关但不确定，您看要不要加进来。"

陈默给这个系统提了一个具体需求：显示"本次使用了哪些文档和章节"。他要求在 Agent 输出界面的最上方，固定展示一个"材料清单"模块，列出所有被检索和引用的文档，并标注每份文档的使用比例。如果某份关键文档没有被使用，律师一眼就能发现。

真正的测试在一个月后到来。

另一项尽调，数据室三百多份文档。Agent 生成报告后，陈默习惯性地先点开"材料清单"。他发现一份关联交易协议的使用比例是 0%——系统检索到了它，但没有把它纳入分析。陈默手动把它加入任务，重新运行。十分钟后，Agent 补充了一段分析：该关联交易协议里有一条"优先购买权"条款，与主合同的控制权变更条款存在潜在冲突。

人发现了检索盲区，系统补上了分析。

林薇后来把这个案例写进了内部手册。她没有说"我们的知识管理系统召回率达到了多少"，而是说："大文档任务的底线不是'模型读得快'，而是'关键文档没漏'。漏一份，结论就可能是错的。"

三个月后，团队形成了一条规矩：

任何超过五十页或超过五份文档的法律任务，Agent 必须输出"材料清单"，律师必须核对清单完整性，然后才看结论。

这个流程没有让尽调变快。事实上，核对材料清单增加了额外步骤。但林薇觉得这是对的。

大文档不是模型的敌人，是产品架构的试金石。一个只能在三页文档上表现良好的 Agent，对法务工作没有实际价值。真正的挑战在于：当信息量超过任何单一工具的承载极限时，系统还能不能保证不漏、不乱、可追溯。

换句话说，大文档 Agent 的关键不是读得多，而是别漏掉该读的。