128K 还是 200K？企业办公智能体真的需要超长上下文吗？

最近在做企业办公智能体性能测试时，遇到了一个很典型的问题。

原本规划的模型上下文长度是 128K，测试已经按照这个目标开展。后来随着办公场景进一步细化，又提出了新的要求：是不是应该支持到 200K？

从模型能力上看，这个问题似乎很好回答。

模型支持 200K，那就部署 200K；如果硬件资源允许，甚至可以继续往上做。

但真正开始做性能测试以后，我越来越觉得，这个问题其实问反了。

企业真正应该问的不是：模型最多能够支持多长的上下文？

而是：我们的业务场景，到底需要多长的有效上下文？

这两个问题看起来很像，背后却是完全不同的技术路线。

因为从 128K 增加到 200K，并不只是模型启动参数从一个数字改成另外一个数字。它后面还连着显存占用、KV Cache、首 Token 时间、并发能力、吞吐、附件解析方式、RAG 策略，甚至整个办公智能体的产品设计。

所以这篇文章想聊的，不是哪一个数字更先进，而是：对于文档、PPT、问答、数据分析、代码这些常见企业办公任务，我们到底应该怎样理解上下文长度？

一、先把一个概念说清楚：128K 不等于能塞 128K 的文档

很多人第一次看到「128K 上下文」，很容易形成一种直觉：我的模型支持 128K，那么我上传一个 100K Token 的文档，应该就可以直接处理。

实际情况没有这么简单。

一个完整的大模型请求里，通常至少包含下面这些内容：

• System Prompt
• 智能体角色和规则
• 用户当前的问题
• 历史对话
• 附件解析后注入的内容
• RAG 检索出来的知识
• 工具调用结果
• 智能体中间过程
• 最终给模型预留的输出空间

因此：模型上下文窗口 ≠ 用户可使用的附件空间。

可以简单写成：

有效上下文 = 系统提示词 + 历史对话 + 当前输入 + 附件内容 + RAG 内容 + 工具返回 + 输出预留

假设模型支持 128K，也不可能真的把 128K 全部留给一个 Word 或者 PDF。实际工程中还需要预留一定安全空间。

比如为了防止长对话、工具返回或者模型输出导致上下文溢出，128K 模型真正能够稳定用于业务输入的空间，往往需要控制在一个更低的范围。

所以相比宣传页上的「128K」「200K」，我现在更关注另外一个指标：一次真实业务请求最终到底组装出了多少 Token？

这个数字才真正决定性能。

图 1 · 上下文窗口到底被谁占用了：128K 是总预算，不是附件额度

二、附件大小和上下文长度，本来就不是一回事

办公智能体里还有一个特别容易混淆的问题：文件大小。

例如：上传一个 1MB 的 Word 文件，需要多少上下文？

这个问题实际上没有固定答案。因为模型看到的不是这个「1MB」。

一个 1MB 文件可能包含：大量图片、少量正文、表格、XML 结构、字体和样式、批注、嵌入对象。

PDF 还可能是：文本型 PDF、扫描型 PDF、图片型 PDF、图文混排 PDF。

PPT 就更明显。一个几十 MB 的 PPT，真正抽取出来的文本可能并不多；反过来，一个体积并不大的纯文本材料，却可能对应数万甚至更多 Token。

因此：文件 MB 数 → 文本长度 → Token 数量，三者之间并不存在固定换算关系。

真正决定上下文压力的是解析以后最终送给模型的内容。

而且现在大多数企业智能体，也不会简单地把整个文件原封不动塞给大模型。比较典型的链路应该是：

文件上传 → 文档解析 / OCR → 结构化提取 → 文本切片 → 向量化 / 索引 → 问题检索 → 召回相关片段 → 重排序 → 组装 Prompt → 调用大模型

也就是说，一个 1MB 附件最后真正进入大模型的，可能只是一小部分相关内容。

这就是为什么讨论上下文长度之前，必须先搞清楚一个问题：我们的附件，到底是「全文入模」，还是「解析以后按需检索」？

如果这个机制都没有搞清楚，直接讨论 128K 还是 200K，意义其实并不大。

图 2 · 一个 1MB 附件到底去了哪里：附件通常不是原样进入上下文

三、真正需要多长上下文，要回到办公任务本身

如果从实际办公任务来看，我觉得不同场景对于上下文的需求差异非常大。

1. 普通问答：很多时候连 32K 都用不到

例如：「帮我写一份会议通知。」「把这段内容改得正式一点。」「解释一下这个制度条款。」「根据知识库回答一个业务问题。」

这类任务真正需要的大模型上下文其实并不长。尤其是知识问答场景。

如果已经有成熟的 RAG 体系，用户问一个具体问题，系统只需要把最相关的几个知识片段找出来交给模型。很多请求最终可能只是几千到几万 Token。

这种情况下，为了一个普通问答场景把所有请求都按照 200K 进行资源规划，并不划算。

2. 文档写作：真正需要的是「持续记住结构」

文档类任务稍微复杂一些。例如：上传几份材料，帮我整理成一篇报告。

这里模型需要同时理解：用户要求、多份参考材料、原文事实、已经生成的内容、文章整体结构、前后文逻辑。

随着文档越来越长，多轮修改越来越多，上下文确实会快速增长。

但这里还有另外一种办法：不一定必须一直保留全部历史。例如可以通过文档结构化存储、分章节生成、历史内容摘要、关键事实抽取、已生成内容按需读取，来降低模型需要长期保存的上下文。

换句话说：长文写作首先是智能体状态管理问题，其次才是上下文长度问题。

如果整个产品完全依赖「把所有历史对话一直塞给模型」，那么即使今天 200K 够用，将来一样可能不够。

3. PPT：看起来文件很大，实际未必最吃上下文

PPT 是一个很有意思的场景。因为 PPT 文件通常包含大量图片、图表、版式、页面元素，而文字很少。

如果任务只是「根据 20 页 PPT 总结主要内容」，文本 Token 可能没有想象中那么夸张。

真正困难的地方反而可能是图片理解、图表识别、页面结构、多模态模型能力。

所以 PPT 场景不能简单理解为：文件越大 → 上下文越长。

这也是为什么办公智能体测试不能只设计「上传多少 MB 文件」，还应该同时记录：解析后 Token 数量。

4. 数据分析：真正吃上下文的往往不是原始数据

再看数据分析。如果用户上传一个几百 MB 的 Excel，让模型直接把完整 Excel 转换成 Token 再处理，显然不是一个合理的方案。

比较成熟的方式应该是：模型负责理解问题，工具负责处理数据。

例如用户说「帮我分析近 12 个月销售额下降的原因」。模型生成分析计划，Python、SQL 或者数据分析工具负责真正计算，最后只把数据结构、关键统计结果、中间分析结果、图表信息返回给模型。

因此数据分析真正消耗上下文的，往往不是原始数据，而是分析过程产生的中间结果。

如果工具链设计得不好，大量 SQL 结果、DataFrame、日志全部返回模型，上下文一样会很快膨胀。所以这里依然不是单纯的模型问题。

5. 代码：长上下文确实有价值，但仍然不应该暴力塞仓库

代码场景可能是我认为长上下文价值比较明显的一类场景。

因为做一次代码修改，模型可能需要同时理解：需求、Repository 结构、多个源码文件、接口关系、配置文件、测试代码、编译错误、上一次修改结果。对于大型项目，几十万 Token 确实很容易出现。

但是现在比较成熟的 Coding Agent 同样不会把整个代码仓库全部塞进 Prompt。它通常会：搜索代码、定位相关文件、查看 Symbol、读取局部代码、修改、执行、根据报错继续定位。

本质还是：检索 + 工具 + 上下文，而不是无限上下文。

图 3 · 五类办公任务的上下文需求：不是所有办公场景都需要 200K

四、那 128K 和 200K 到底差在哪里？

如果完全不考虑资源成本，那当然是：越长越好。问题就在于，企业私有化部署几乎不可能不考虑成本。

长上下文对于推理系统最大的影响之一，就是 KV Cache。简单理解：模型在阅读前面几万、十几万 Token 时，需要把大量中间计算结果保存起来，以便后续 Token 继续使用。上下文越长，需要保存的内容越多。

于是就会产生几个直接影响。

第一，显存占用增加

同样一套硬件：上下文越长，单个请求占用的 KV Cache 越多，那么能够同时容纳的请求数量就可能下降。

对于企业系统而言，这一点非常重要。因为我们真正关心的通常不是「一个用户能不能跑 200K」，而是「几十个、几百个用户同时使用的时候还能不能跑」。

第二，首 Token 时间增加

长上下文请求首先需要经历一个 Prefill 阶段。可以简单理解成：模型先把前面的材料全部「读一遍」。

一个 5K Token 的问题和一个 150K Token 的问题，前置计算量显然不是一个级别。

所以在长上下文场景下，一个非常明显的指标通常就是 TTFT（Time To First Token，首 Token 时间）。

用户最直接的感受就是：点了发送以后，很久没有任何反应。即使后续生成速度很快，体验仍然会比较差。

第三，并发能力下降

这也是办公智能体性能测试里，我目前最关注的地方。

假设一套算力在常规上下文下可以支持较高并发。当大量用户同时使用长文档时：Prefill 计算增加、KV Cache 占用增加、GPU / NPU 资源被长请求占据、后续请求开始排队。

最后可能出现：模型单请求性能没有问题，但系统并发能力迅速下降。

这也是为什么我们在测试里不能只测「200K 请求能不能成功」，还应该测试：200K 条件下到底还能支持多少并发。

图 4 · 上下文越来越长，会发生什么：超长上下文不是免费的

五、所以 RAG 和长上下文并不是二选一

过去做知识问答时，大家经常讨论 RAG。后来模型上下文越来越长，就出现了一种观点：模型都有 128K、200K 甚至更长上下文了，是不是可以不用 RAG 了？

我觉得至少在企业办公场景里，不应该这么理解。

它们解决的问题本来就不完全一样。长上下文解决的是：「模型一次最多能够看多少东西。」 RAG 解决的是：「这一次到底应该让模型看哪些东西。」

一个企业可能有几十万份制度、几百万份文档、大量项目资料、邮件、代码、数据库。不可能因为模型支持 200K，就把所有内容都装进去。

真正合理的方式仍然应该是：RAG 负责缩小范围，长上下文负责容纳更复杂的最终材料。

我反而觉得，模型上下文越来越长以后，对 RAG 提出的要求会更高。

以前可能只召回 5 个 Chunk。未来可能变成：先检索出 50 个候选片段 → 重排序 → 聚合相关章节 → 再交给长上下文模型综合分析。

长上下文提升的不是「取消检索」的能力，而是：检索之后进行复杂综合分析的能力。

图 5 · RAG 与长上下文的关系：不是二选一，而是分工协同

六、200K 有没有意义？当然有

说到这里，并不是要得出「128K 已经足够，没有必要做 200K」的结论。200K 甚至更长上下文，在一些企业场景里确实有明确价值。

多份长文档交叉分析。一次同时比较制度、需求、设计方案、测试报告、历史问题。如果材料之间存在大量跨文档关联，过度切片可能损失整体语义。

超长合同、报告或规范分析。有些材料本身就非常长，用户的问题又可能涉及全文逻辑，而不是某个局部段落。这时长上下文的价值会明显提高。

长周期复杂任务。例如一个智能体连续完成：收集材料 → 分析 → 写报告 → 修改 → 补数据 → 再修改。过程中会形成大量中间状态。如果智能体的 Memory 和状态管理机制还不完善，更大的上下文能够提供更大的缓冲空间。

Coding Agent。大型工程中的跨文件理解，也是长上下文比较典型的受益场景。

所以真正的问题从来不是：200K 有没有用。而是：是不是所有用户、所有请求，都需要按照 200K 来运行。

答案显然不是。

七、我现在更倾向于「分层设计」，而不是押一个数字

如果重新设计企业办公智能体的上下文策略，我现在反而不会纠结：到底统一使用 128K 还是 200K？我更倾向于做成一个分层体系。

常规请求。短问答、写作、知识查询。控制在较短上下文范围内，优先保证响应速度、并发、成本。

中等复杂请求。多轮办公任务、附件问答、复杂报告。允许进入更大的上下文空间。

超长任务。多文档综合分析、大型代码工程、超长材料。才真正启用 128K 甚至 200K。

也就是说：上下文长度本身也应该成为一种可以动态调度的资源。

这和服务器资源池其实很像。不是因为系统里有一台 128 核服务器，就意味着所有任务都必须占用 128 核。模型上下文也是一样。

图 6 · 分层上下文策略：不是统一跑最大上下文，而是让不同任务使用合适的上下文

八、性能测试也应该跟着改变

这次做办公智能体性能测试，让我感受比较深的一点是：以前测试大模型，比较容易关注每秒 Token、首 Token、单请求响应时间、最大并发。但如果开始进入企业办公智能体阶段，仅仅测这些已经不太够了。

因为同样是「40 并发」，实际压力可能完全不同。

40 个用户全部做简单问答，和 40 个用户同时上传长文档进行分析，对于模型来说完全不是一个工作负载。

所以后续我觉得办公智能体性能测试至少应该同时控制三个维度：

• 第一维：并发用户 —— 10、20、40、80……
• 第二维：上下文长度 —— 例如 8K、32K、64K、128K、200K
• 第三维：任务类型 —— 文档、问答、PPT、数据分析、代码……

最终形成的不是一个简单的「最大支持 XX 并发」，而应该是一张场景 × 上下文 × 并发的能力矩阵。例如：

• 普通问答 / 8K / 40 并发
• 文档问答 / 32K / 40 并发
• 长文档 / 64K / 20 并发
• 多文档分析 / 128K / 10 并发
• 超长任务 / 200K / 5 并发

这样最后回答的才是一个真正有业务价值的问题：这套算力到底能支撑多少人在什么场景下使用？

而不是单纯告诉业务：这个模型支持 200K。

图 7 · 办公智能体性能测试三维模型：只看并发数已经不够了

九、128K 还是 200K，我现在会怎么判断？

如果现在让我重新回答开头这个问题，我不会直接选择 128K 或者 200K。我会先问五个问题。

第一，真实业务请求的 Token 分布是多少？不要看模型规格，要看线上或者测试场景实际组装出来的 Prompt。P50 是多少？P95 是多少？最长请求是多少？

第二，超长请求来自哪里？是用户真的上传了长材料、对话历史无限累积、RAG 召回过多、工具返回数据太多，还是智能体 Prompt 本身设计得太重？不同原因，解决办法完全不同。

第三，超过 128K 以后，效果真的明显提升了吗？如果把相关材料通过 RAG 压缩到 80K，回答质量和直接使用 180K 全文差异并不明显，那么未必值得长期支付后者的性能成本。

第四，长上下文对并发能力影响有多大？这必须通过真实测试回答。不能只验证「200K 能够跑通」。

第五，这是不是高频业务？如果只有极少数用户偶尔需要 200K，那么完全可以作为特殊任务处理。没有必要让整个系统都按照 200K 场景进行资源规划。

十、最后：企业 AI 真正需要的不是「最大参数」，而是「合适的资源」

这几年大模型的发展很容易让人形成一种习惯：参数越大越好、上下文越长越好、模型能力越强越好。从模型 Benchmark 的角度，这当然没有问题。

但进入企业真正落地阶段以后，事情会变得完全不同。

我们最终面对的是一套资源约束：算力是有限的、显存是有限的、并发能力是有限的、用户等待时间是有限的、企业预算也是有限的。

所以一个企业办公智能体真正需要解决的问题，不是无限扩大上下文，而是搞清楚：什么任务需要什么模型，什么模型需要多少上下文，多少上下文需要多少算力。

128K 还是 200K，其实只是这个问题里很小的一部分。

真正值得建设的是：任务识别 → 文档解析 → RAG → 上下文管理 → 模型路由 → 算力调度这一整套能力。

如果这一套机制建立起来，未来模型支持 500K、1M 甚至更长上下文，我们可能也不会再纠结：「到底应该配置多少 K？」

系统应该自己判断：这一次任务，到底需要多少。

我觉得这才是企业办公智能体从「能用」走向「真正可规模化使用」的一个重要分界点。