企业官网建设流程全解析

1. 从"上下文塞不下"聊起：长文本处理到底难在哪

先抛个场景。某次我做一个信息提取类的Agent，输入是一份八十多页的行业研报PDF，要求Agent从中提取关键结论并生成结构化摘要。第一版方案很天真：把PDF整个读进来，拼成一段超长文本，一股脑塞进提示词。结果显而易见——直接触发了模型的上下文上限，程序报错；后来硬着头皮截断，只保留前两万字，结论倒是出来了，但丢掉了后半部分里一个非常重要的风险提示。这个项目让我彻底意识到：Agent场景下的长文本处理，从来不是"把文本喂进去"这么简单，它是一个从输入、拆解、调度到汇总的系统工程。

聊长文本处理，首先要承认一个大背景：大语言模型的上下文窗口虽然在快速变长，从最早的几千token，到现在的几十万甚至上百万token，看起来数字很漂亮，但实际用起来远没有想象中美好。窗口越大，推理成本越高，响应速度越慢，而且模型对中间部分的注意力会出现明显衰减。圈内有个经典的"lost in the middle"现象，就是说当文本很长时，模型往往只对开头和结尾的内容记得牢，中间的关键信息很容易被忽略。这意味着什么呢？哪怕你的上下文窗口有几十万token，把整个文档一股脑放进去，也不能保证模型真的"读懂了"每一处细节。

那有人可能会说，既然有长上下文模型，直接全量放入不就行了？我在小规模实验里试过这种方案，几十页的合同文本直接放入，模型确实能生成完整的摘要，但追问某个中间章节的具体金额时，模型给出的数字和原文对不上。这就是注意力衰减在作怪。事实上，长文本处理的关键不在于"能不能塞下"，而在于"如何让模型把注意力放在最该放的地方"。

这篇文章主要想聊的是Agent场景下的实操经验。所谓Agent场景，和普通的单轮问答不同，它往往涉及多步骤任务：读取外部文档、调用工具、与多个模型交互、根据中间结果动态调整策略。在这种场景下，长文本处理不是一次性的"全文阅读"，而是贯穿整个任务生命周期的问题。你需要考虑：如何对文本进行分块和索引？如何在多轮调用之间维护有效状态？如何处理超过单次窗口上限的超长输入？如何降低成本和延迟？我会围绕这些具体问题，结合自己的实践心得，给出一些可以落地的方法。

如果你正在做RAG类的Agent，或者需要让Agent理解长文档、分析多份材料、生成长篇报告，这篇文章应该对你的胃口。里面有踩坑记录，也有对比测试的结果，不一定适合所有场景，但大概率能给你省下一些试错的时间。

2. 先想清楚你的"长文本"长在哪：场景划分与方案选型

先说句大实话：任何不谈场景的架构设计都是耍流氓。长文本处理的第一步，不是急着写代码，而是先想清楚你的Agent到底要面对什么样的长文本。

2.1 三种典型的长文本形态

我把实际工作中遇到的长文本场景粗略分成三类，每一类的处理策略差别很大。

第一类是单篇超长文档。比如一本技术手册、一份完整的年报、一整本书。这种场景的特点是文本体量大、整体性强、前后文存在依赖关系。处理这种文本，核心矛盾在于"一次的窗口放不下"以及"信息分散在全文各处"。对这种场景，我一般倾向于先做结构解析，再配合检索或分治策略。

第二类是多文档聚合。比如让Agent对比分析五份不同的方案文档，或者从几十封邮件中提取待办事项。这种场景的难点不在于单文档的长度，而在于跨文档的关系建模：哪些文档提到了同一件事？哪些内容互相矛盾？哪些信息分散在不同来源、需要合并才能得出完整结论？这种场景对Agent的规划能力要求更高，它需要在多个"中等大小"的文本块之间跳转、对照、汇总。

第三类是流式或迭代增长的长内容。比如日志分析、实时爬取网页内容增量更新、用户与Agent的多轮历史对话。这种场景的特点是文本边界模糊、总量不可控、时效性很重要。你没法一次性"读完"，因为内容还在不断产生。面对这种文本，关键不在于处理存量，而在于用合理的方式消化增量，避免上下文无限制膨胀。

2.2 方案选型：全量放入、分片处理、还是检索增强

明确了长文本的类型，接下来就是对症下药、选择处理方案。这里我列一下主流方案的适用条件和取舍依据，方便你对照自己的场景做判断。

全量放入，适用于文本总长在模型窗口容忍范围内的场景。这里"容忍范围"要打一个折，并不是模型声称支持多少，你就放多少。以我常用的一个中等规模模型为例，它宣称支持128K上下文，实际测试下来，超过40K时输出质量就开始出现可感知的下降。所以如果你做一个文档问答Agent，文档长度在几万字以内，直接全量放入其实是简单又可靠的选择——省去了拆分的麻烦，也不用担心上下文被切断导致信息丢失。

分片处理，适用于单篇超长文档，特别是那种必须"逐段精读"的任务，比如从合同中提取所有关键条款。处理方式是把文档切成若干有语义边界的片段，逐片送入模型，再把各片结果汇总。这相当于把一个大任务拆成多个子任务，用计算量换精确度。

检索增强，适用于信息分散、不需要全文精读的场景，比如"这份五百页的文档里有哪些提到某产品的段落"。这时候如果全文塞给模型，又慢又贵，不如先通过检索把相关片段圈出来，再组织成上下文喂给模型。但检索方案有一个老大难问题：召回质量不行，后面一切白搭。检索不精准、漏掉了关键段落，最后生成的答案就会出现事实性错误，而且这种错误非常隐蔽，不好排查。

三类方案不是互斥的，实际Agent项目中经常组合使用。比如先整体扫描文档结构，再对重点章节走检索或分片精读，最终汇总结果。设计时的核心原则是：让模型在"能看到足够信息"和"不至于被无关信息淹没"之间取得平衡。

3. 分块的艺术：如何切文本才不被"拦腰截断"

如果你决定走分片处理或检索增强的路线，第一关就是文本分块。这一步看似简单——不就是按固定长度切吗？——但实际做起来，细节非常多，直接决定下游效果。

3.1 别用固定字符数硬切

最容易犯的错误就是按固定字符数切段，比如每500字切一块。这种切法的致命伤是：你完全无法保证语义的完整性，很可能把一句话拦腰截断，甚至把一个专业术语拆成两半。我见过一个项目，把"深度学习"四个字硬生生切成"深度学"和"习"，结果检索的时候"学习"这个词完全匹配不上，召回质量一塌糊涂。你说冤不冤。

更合理的做法，是优先寻找"语义边界"来切。对于结构化文档，比如Markdown、HTML、LaTeX，直接按标题层级来切是最省事的——每个二级标题下的内容天然就是一块。对于PDF和Word，先抽取结构信息，按章节切。对于纯文本，退而求其次，按段落切，段落太长的再按句子边界补切。

这里分享一个我常用的分块思路：

• 第一步，清洗文本，把多余的换行、空格、页眉页脚去除。
• 第二步，识别结构边界。有标题用标题，有列表用列表项，有表格用表格行。
• 第三步，设置一个目标块大小。比如我希望每块控制在1500~2500字之间。为什么是这个量级？因为既要保证块内语义完整，又要避免单块过大导致后续调用成本过高。
• 第四步，以结构边界为基准切块。如果某一块因为结构边界过大而超过上限，再往下找句子边界切，而不是生硬按字数截断。

3.2 块与块之间的"记忆线"

分块的另一个隐蔽问题，是上下文连续性。比如一个合同条款被分到了第3块和第4块，第4块开头写的是"除上条所述之外的任何情形"，它引用了上一块的内容。如果这两块被独立送入模型，模型根本不知道"上条"说的是什么，理解就会出偏差。

解决办法有两种。一种是分块时保留少量重叠，比如相邻块之间重叠一到两句话。这样做虽然会带来少量冗余，但能显著减少引用断档的情况。另一种是在块首添加上下文摘要，给每块补一段"前文提要"。比如这一块之前的内容涉及什么主题、哪几个关键人物、什么状态字段。这个办法在Agent多跳推理时特别管用，因为模型拿到单块文本时，至少知道前因后果。

我在一个合同审查Agent里实测过这两种方法。不做任何处理直接分块时，模型对"前述条款""如上所述"这类指代表述的理解准确率大约只有六成；加了相邻重叠之后，提升到接近八成；再加了上下文摘要，能稳定在九成以上。当然，摘要方案会增加一点额外开销，但对于追求准确率的业务场景完全值得。

注意：分块不是越细越好。块越小，后续需要调用的次数就越多，总耗时和成本随之上涨，而且跨块聚合时的信息损耗也更大。你需要找到一个平衡点，我个人的经验是单块内容控制在模型单次有效理解范围的1/3到1/2比较合适。

3.3 表格与非结构化内容的处理

长文本里总有一些让人头疼的内容，表格尤其典型。表格不同于普通段落，它依赖行列结构表达信息，如果按普通文本流式切块，很容易被切成一堆无意义的碎片。比如一个销售数据表，一列是月份、一列是销售额、一列是同比增长率，切碎了之后，模型看到的是"三月 210万 15%"这种孤立片段，很难关联起来。

我的习惯是，遇到表格先用工具转成Markdown表格格式保留结构，再决定是整表作为一块、还是按行拆分并补上表头信息。一般来讲，如果表格行数少于二十行，整表保留；如果表格很大，按行分组切块，每组都携带表头，让模型始终知道每列的含义。类似地，代码块、公式等内容也需要特殊处理，不要简单地混在普通文本里切，否则语义完整性会大打折扣。

4. 超越窗口限制：分治、摘要与分层检索的配合

分块只是解决了"怎么把文本拆开"的问题，真正让Agent优雅处理长文本的，是一套围绕分块构建的调度策略。这一节我讲两个我在实战中反复使用的核心战术：分治法与分层摘要法。

4.1 分治法：先拆解、再批处理、后汇总

分治法的思路很朴素，但很有效。当长文本无法一次性读入时，先把全文拆成多个有语义边界的片段，逐一交给模型理解和抽取，最后把所有片段的抽取结果合并，做一次全局汇总。

以我之前做的研报分析Agent来举例。面对一份完整行业研报，我的处理流程是这样的：

• 第一轮，按章节拆分成若干段，每段连同"这一段要回答的问题清单"一起发给模型，让它输出结构化字段。比如这一段提到了哪些核心数据、主要观点、风险信号、涉及主体。
• 第二轮，把所有段落的结构化结果汇总成一张表，再发给模型做全局总结，提炼出完整的核心观点和前后矛盾之处。

这套流程跑下来，效果比全量放入稳定得多，而且每次单次调用只处理少量文本，上下文噪音低、token消耗可控。代价就是调用次数变多了，需要设计好并行策略，否则总耗时可能不降反升。

并行执行这里有个细节值得说。在无状态依赖的场景下，各分块的抽取任务完全不存在先后顺序，完全可以并发调用，一次性发出多个请求。我实测过，同一个研报拆成10个分块、并发处理再汇总的方案，总耗时大约是全量放入方案的1.2~1.5倍（考虑到全量输入本身的耗时），而准确率提升非常明显，尤其在长文档的中后段信息提取上，几乎是碾压性的优势。但如果你用的是必须串行处理的分块依赖策略，或者API限流比较严格，就要仔细编排调度，防止并发集中在某个窗口。

分治法还有一个容易被忽略的好处：它能定位信息来源。在汇总阶段，可以让模型在每个结论后面顺带标注它是从哪一块得出的，这样一旦后续发现答案有误，可以快速溯源到具体分块，排查成本大大降低。这在企业级应用中尤其重要。

4.2 分层摘要：给Agent配一个"快速阅读模式"

分治法适合精读场景，但有些场景下Agent需要先对全文有个全局把握，再决定下一步读哪里。这时候分层摘要法就派上用场了。

分层摘要的思路是：先逐块生成摘要，再把摘要合并成更高级的摘要，层层向上，最终得到全文浓缩版。这个过程很像读论文的"先读摘要、再读引言、最后读某章节"。Agent拿到全文摘要后，能快速判断：关键信息大概在哪个位置？还需要深入了解哪部分？从而精准定位，避免一次全量阅读。

我在一个多文档对比分析项目中应用过这个思路。Agent需要同时分析六份方案文档，每份二十多页。我的做法是：每份文档生成一页摘要，再把六份摘要合成一份总览，让Agent基于总览列出各方案的差异点和冲突点，再针对具体冲突点回到原文检索。整体下来，时间成本比逐份精读低了一半多，而且结论质量没有明显下降。对信息密度高、需要"快读抓重点"的场景，分层摘要几乎是必选项。

但分层摘要有一个我不能不提的坑：摘要本身会丢失信息，层级越多，丢失越严重。如果底层摘要质量不达标，上层摘要就是"错上加错"。所以，要么在底层摘要里要求模型保留关键数字、人名、时间等不可压缩信息，要么在高层次比较时始终保留跳回原文的入口。我见过不少项目在摘要环节省事，最后生成的总结出现"幽灵细节"——模型自己脑补出原文完全没有的数字，必须给模型提供回到原文核实的能力，不能让它只依赖摘要做事实性判断。

4.3 检索与分块的搭配：召回质量决定上限

检索增强这块，我补一句实操心得。很多人都把关注点放在向量化和相似度算法上，但实践下来，分块质量对检索效果的影响往往比embedding模型的选择更大。一个语义完整的块，哪怕用简单的BM25算法也能召回到位；反过来，一个语义被切碎的块，即使用的是顶尖向量模型，召回结果也未必理想。本质上，分块和检索是组合拳，你不能指望靠某一环节的"高级"来弥补另一环节的薄弱。

此外，关键词召回在专业领域依然有独特价值。术语、编号、型号这类信息，向量检索经常不如精确匹配靠谱。我现在的项目里，实际用的是"关键词召回 + 向量召回"的双路召回，再合并去重。这样既能利用语义相似性召回同义改写的内容，又能利用精确匹配保证编号类信息不漏。混合召回加上去重排序，再配合重排模型做精排，这样一套流程下来，召回质量才能比较稳定。

5. Agent调用链路上的长文本管理：从上下文预算到状态压缩

分块策略解决的是"一次输入放不下"的问题，但Agent场景往往还有另一个更要命的挑战：多次调用之间，上下文怎么管理？一个Agent执行任务可能需要多轮模型调用，每轮调用都要携带必要的上下文。如果不加管理，上下文只会越滚越大，最终必然爆窗，而且中间还会出现上下文不一致的情况。这一节聊聊我在调用层面的一些经验。

5.1 给上下文做"预算管理"

做Agent如同做项目，预算很重要。我的习惯是给每次Agent运行设定一个上下文预算——总共能使用的token上限，然后按照比例分配给系统提示词、检索到的文档块、对话历史和当前待处理的用户请求。比如一次任务我的总预算是20K token，那么我可能这样分配：系统提示词5K，当前输入2K，工具调用信息3K，剩下的10K用于放检索或分块内容。一旦超出预算，就触发"压缩策略"。

这个预算管理听起来像是人为限制，但它的价值在于：倒逼你在设计阶段就想清楚每一部分信息的必要性。如果你发现自己什么信息都舍不得丢，什么都要塞进上下文，说明你的方案设计可能偷懒了。合理的上下文不是"多多益善"，而是"各行其位"。我见过太多Agent失败的案例，都不是因为模型不够聪明，而是因为上下文里无关信息太多，把关键信息淹没了。预算管理能从根本上迫使你优化信息组织方式。

5.2 状态压缩：高质量Agent的必备能力

Agent执行过程中，会把中间步骤的结果放进"记忆"。这个记忆现在普遍的做法是把历史对话记录全部塞进下一轮请求的上下文里。对话轮次一多，历史就会变得冗长，这时候就需要状态压缩。

最常见的压缩方式是"总结历史"。比如用户和Agent聊了十轮，最终的问题是汇总所有诉求。你可以把前九轮的关键信息压缩成一段摘要，再结合第十轮的请求一起处理。但这里要注意一个度：摘要要保留那些"未来仍然有用"的信息，而不是平均用力。例如用户明确说过"预算不能超过十万"，这个硬性约束必须原样保留，不能模糊化成"预算有限"。在压缩时，对数字、否定词、约束条件要格外小心，这些恰恰是模型压缩时最容易被扭曲的部分。

另一种压缩方式是"结构化抽取"。不是让模型生成自然语言摘要，而是按固定格式输出JSON：{"user_request": "...", "confirmed_params": {...}, "pending_items": [...]}。这种方式最大的优势是结构清晰、后续可以在代码层面做逻辑判断，而不需要模型每轮重新理解一遍上下文。在做复杂的工具调用型Agent时，我几乎清一色用结构化记忆，效果比自然语言摘要稳定得多。

5.3 多跳检索：在每一次调用中选对材料

在长文本场景中，很多时候Agent不是一轮就能拿到答案，而是需要"多跳推理"——先从文档里找出相关线索，再基于线索进一步查找。比如用户问："哪些产品线在去年的营收下降超过20%？"Agent可能需要先去财务章节找到各产品线的营收数据，再筛选出降幅大的条目，最后去市场分析章节了解下降原因。这个过程中，每一跳都需要选择合适的文本片段送入上下文。

多跳检索的工程实现并不复杂，难的是材料选择的策略。我的经验是，每一跳之间要保持状态链接：第一跳找到"产品A营收下降25%"，第二跳的检索词就可以带上"产品A 营收下降 原因"。如果每条信息是孤立地检索，Agent就会陷入"每轮都从零开始"的低效状态。这种状态链接的工程化做法，一般是用一个结构化的"临时推理笔记"贯穿整个Agent循环，每执行一步就往笔记里追加结果。最终模型可以从笔记中提取完整的推理链。

提示：长文本场景的Agent还有一个容易踩的坑——模型在推理过程中会出现"路径遗忘"。前一步得出的结论，到下一步就忘了。解决思路就是要保证每一步的结果都以结构化形式持久化保存，而不是依赖对话上下文里碰巧还留着。这也是为什么状态管理在Agent架构里占据了极其重要的位置。

6. 模型选型与成本权衡：算清这笔账再动手

长文本处理从来不只关乎技术可行性，还关乎成本和性能之间的平衡。这里我讲一下模型选型和调用策略上怎么权衡。

6.1 长上下文模型不是万能解

长上下文模型确实能解决一部分问题，尤其是那些"必须看到全文才能判断"的场景。但你需要认清它的代价：

• Token越多，费用越高。有些模型按输入token计费，你塞进去80K token，哪怕只输出几十个字的答案，费用也按80K算。高频使用下，成本是不可忽视的。
• 速度变慢。输入量增大，首字延迟明显增加。用户等待的体感会被严重拖慢，对交互型Agent是致命的。
• 注意力衰减。哪怕窗口够长，中间段落的细节仍然容易被忽略。长上下文模型能"看到"全文，但不代表"重视"全文。

所以在方案设计时，我一直倡导一个理念：把长上下文模型当作"兜底方案"，而不是"默认方案"。能用检索解决，就不全文喂给模型；能分块精读解决，就不一次性全量输入；能用小模型处理简单任务，就不动辄调用大模型。只有那种"信息分散、难以索引、必须全局理解"的少数场景，才值得动用长上下文的大模型。

6.2 模型能力分层与调用策略

在Agent链路中，不同环节对模型能力的要求差别很大。比如分块抽取环节，往往不需要最强的模型，一个中等级别的模型加上清晰的任务指令就能胜任。而最后的全局汇总和复杂推理环节，才需要调用最强模型。这种"大小模型混用"的策略，在保证质量的前提下能省下可观的成本。

我实际维护的一个Agent，把分块抽取阶段的模型从旗舰款换成中端款后，成本下降了约65%，质量几乎无损。而最终汇总阶段保持用旗舰款，因为这一步容错率低、需要深度推理。成本控制的核心思路，不是一味换成便宜模型，而是把"贵模型"用在最需要它的地方。

6.3 缓存与复用：降低长文本处理的重复开销

长文本处理还有一个隐藏的成本来源：重复处理。比如同一份文档被十个用户分别问答，如果每次问答都重新切块、重新抽取、重新生成摘要，那就是十倍的重复开销。合理的做法是引入缓存层，把分块、摘要、结构抽取的结果保存下来，后续直接复用。

对于静态文档，还可以预计算向量和索引，建好即用。我对常用语料库就是这么做的：文档入库时一次性完成清洗、分块、嵌入和摘要生成，所有结果存入数据库。这样每次问答时，Agent只需要走检索和推理环节，省掉了最耗时的预处理阶段。交互体验几乎没有等待时间，成本也大幅下降。

7. 独立评测：不依赖主观感受的Agent长文本优化方法

聊完了各种方案，最后分享一个所有工程实践都绕不开的话题——怎么评测优化效果。长文本场景的优化特别容易陷入"凭感觉"的误区：你调整了分块策略，感觉答案"好像更准了"，但真的准吗？哪里准了？如果没有可量化的评测，所有优化都是盲目的。

7.1 构建一个微型评测集

我的做法是：每次做长文本Agent，先花些时间构建一个微型评测集。找3~5份有代表性的长文档，每份准备5~10个问题，问题的答案从原文中人工确认，做成标准答案集。问题类型要覆盖几类：事实抽取类（"第三季度营收是多少"）、推理类（"哪些因素导致收入下降"）、对比类（"两份合同在付款条件上的差异"）、立场判断类（"作者对某技术整体是乐观还是悲观"）。

评测集不用很大，但要有代表性。它的价值在于：每次改动策略后，都能在固定数据集上跑一遍，客观对比新旧方案的结果。没有评测集的优化，就像在迷雾里开车，方向对不对全凭感觉。

7.2 可量化的指标

长文本评测的量化指标，我一般看这几项：

• 准确率。模型给出的答案与标准答案一致的比例。对事实抽取类问题，这个指标最直接。
• 可追溯性。模型能否指出答案出自原文哪个位置。不能追溯到原文的答案，在企业场景中是不可交付的。
• 漏报率。对于"提取所有关键条款"这类任务，模型遗漏了多少要点的比例。这个指标尤其重要，因为遗漏比答错更隐蔽，也更危险。
• 开销与延迟。单位任务的token消耗和总耗时，这直接关系到能不能规模化上线。

我见过一个团队，在没评测的情况下把分块大小从500字改成2000字，主观感受"还行"，上了评测集才发现事实抽取准确率掉了十几个百分点。反过来，原本认为效果"一般"的检索方案，在评测集上跑完发现其实完全够用，省下了大量不必要的精读调用。这就是评测的价值——它能打破你的直觉，告诉你真相在哪。

8. 一次真实的优化实录：某合同审查Agent的长文本改造

理论聊再多，不如一个真实的案例来得直观。最后我分享一个做过的合同审查Agent优化过程，整个过程有对比数据，算是把前面讲的方法串起来。

8.1 初始状态

这个Agent的输入是各种长短不一的合同文档，短的几页，长的上百页，任务是从中提取付款条款、违约责任、保密义务等关键信息并输出审查建议。第一版实现是全量塞入，遇到长合同就截断，只保留前两万字。上线后问题很明显：超过三十页的合同，审查建议普遍缺项，尤其是靠后的章节，保密义务相关条款经常被漏掉。

8.2 改造过程

我把这个Agent做了三轮改造。

第一轮改成简单分块：按固定字数每3000字切一块，每块独立提取要点，再汇总。结果：漏报率下降了一些，但出现了新的问题——条款断章取义，模型把"付款条件"总结得牛头不对马嘴，因为关键条款被切成了两半。

第二轮改成语义分块：基于合同的章节结构切块，保留条款标题，相邻块保留重叠。这一次，事实抽取的准确率提升明显，从大约七成直接跳到八成五，漏报率也降到更低。但新的问题是：长合同分块数量多，整体耗时变长，而且最后的汇总阶段，模型把各块的要点拼接得有点生硬，"只见树木不见森林"。

第三轮加入分层摘要 + 预算管理。先对每个章节做摘要，再用摘要做全局总结，同时给每次调用设定上下文预算上限。最终效果：事实抽取的准确率稳定在九成左右，漏报率降到个位数，时间成本虽然比全量截断方案高一些，但完全在可接受范围内。更重要的是，审查建议的逻辑连贯性好了很多，不再是一堆要点碎片的堆砌。

8.3 案例复盘

这个案例里最值得复盘的点，不是什么精妙的算法，而是一个朴素的道理：长文本Agent的优化是分层的，每一步解决一个层面的问题。分块解决信息完整性问题，摘要解决全局理解问题，预算管理解决效率与成本问题。跳过任何一层，整体效果都上不去。另外，评测贯穿了整个改造过程，三轮改造每一次的对比数据都是靠评测集跑出来的，而不是"我感觉变好了"。

如果你现在正被Agent长文本问题困扰，我建议先从搭建评测集开始，再审视你的分块策略、上下文管理方式和调用链路。这个过程未必能让你一步到位，但至少能让你每一步都走得有方向。

回到我开头说的那个研报提取项目，现在的处理流程已经完全变了：先切块、并发抽取、结构化汇总、标注来源。处理同样的PDF，结果质量稳定，且端到端的耗时反而比当初全量塞入的方案更低。这大概也是长文本处理最理想的状态——不靠蛮力，靠巧劲。