跳转至

Context 不是免费的：解析长文档 agent 的性能天花板与架构优化

Ch01.1086 Context 不是免费的：解析长文档 agent 的性能天花板与架构优化

📊 Level ⭐⭐ | 5.8KB | entities/context-不是免费的解析长文档-agent-的性能天花板与架构优化.md

Context 不是免费的：解析长文档 agent 的性能天花板与架构优化

来源: 高可用架构

发布日期: 2026-03-06

原文链接: https://mp.weixin.qq.com/s/WrQ7LtUPuphZwRYngmyFuw

  • 文章讨论构建真实世界AI智能体时常见问题：处理长文档的JSON解析输出（如坐标、置信度分数）占用整个上下文窗口，导致智能体无法有效工作。

  • 作者提出解决方案：将解析输出分离为纯内容（Markdown格式用于智能体推理）和元数据（存储在文件系统中，按需通过工具查询），并优化提示词以鼓励代理使用搜索工具而非全载文档。

导读： 随着模型上下文窗口不断扩大，我们似乎习惯了“暴力输入”，但 1M Token 的杂乱数据往往不如 200k 的精炼信息。本文深入剖析了构建复杂 Agent（如法律、金融、建筑领域）时的常见性能瓶颈：原始解析输出对模型推理的干扰。通过引入“Markdown 编号块 + 沙盒代码查询”的架构模式，我们不仅能保留精确到 PDF 像素级的引用能力，还能让 Agent 的注意力重新聚焦在逻辑推理上。这是一场关于“信息密度”与“工具调用”的技术进化。

作者 Raunak（@raunakdoesdev）是一位专注开源科学、优雅软件架构与精致界面的独立开发者与创业者。目前正在构建Reducto AI，擅长AI代理、文档解析与复杂工作流优化，曾在Anthropic黑客松获奖，热衷分享真实世界AI工程经验。

我在构建现实世界智能体时看到的最常见问题——以及如何修复它。

最近，我反复从构建各种文档相关智能体的客户那里听到同一个问题。他们通过 API 处理长文档，将生成的 JSON 响应喂给智能体，结果在智能体还没开始干正事之前，整个 上下文窗口（Context Window） 就已经被塞满了。

我在很多场景中都见过这种情况：审查合同的法律 AI 智能体、处理理赔的保险智能体，有时是处理 10-K 表格提取数据的金融智能体。

但问题的本质总是一样的： 原始解析输出包含的信息远超智能体所需，而这些多余的信息正严重损害性能。

一个例子：建筑工作流智能体

最近的一个例子让这个问题变得尤为清晰：一位客户正在构建一个用于建筑项目的“变更单（Change Order）”审查智能体。他们带着一份 100 页的变更单来找我们，这份文档解析后产生了 20 万行 JSON 代码 。

该工作流允许承包商提交变更单，智能体则根据原始合同、进度表和单价表进行交叉比对，并在审查电子表格中标记出不一致之处。由于用户是负责数百万美元索赔的建筑项目经理（PM）， 每一项发现都需要链接回原始 PDF 的精确区域 。

他们利用沙盒环境、电子表格工具和边界框（Bounding Box）引用构建了整个系统。听起来很扎实，对吧？

但智能体在处理长文档时总是卡住。他们的第一直觉是在系统顶层增加一些东西：比如目录、章节摘要，或者想办法给智能体一个可以进一步钻取的压缩视图。

我扫了一眼那 20 万个 token 里到底装了什么，立刻发现了一个更好的解决方案。

问题所在：原始 API 响应并非为智能体输入而设计

Reducto 的解析响应是为了工程灵活性而设计的。每个模块（Block）都有边界框坐标、OCR 置信度分数、类型分类、坐标数据——这是一个对文档丰富且忠实的还原。

这正是你开发文档阅读器或版面分析工具时所需要的。

但这不是你希望放入智能体上下文窗口

→ 原文存档

关联