---
title: "Context不是免费的：长文档Agent性能天花板与架构优化"
created: 2026-05-28
updated: 2026-05-28
type: raw
tags: [document-parsing, context-window, agent-architecture, sandbox, metadata-split, reducto, prompting]
sources:
  - https://mp.weixin.qq.com/s/WrQ7LtUPuphZwRYngmyFuw
review_value: 8
review_confidence: 8
sha256: ee2bd42f5b51cfe273b95c963d5ad8a1c177e1fece0a903fb5a1a769ce275fa8
---

## 背景与问题

作者 Raunak（@raunakdoesdev）构建 Reducto AI，专注文档解析与复杂工作流优化，曾在 Anthropic 黑客松获奖。

核心问题：客户通过 API 处理长文档，将生成的 JSON 响应喂给智能体，结果上下文窗口在智能体还没开始干正事之前就已经被塞满了。

典型场景：
- 法律 AI 智能体审查合同
- 保险智能体处理理赔
- 金融智能体提取 10-K 表格数据

**本质问题**：原始解析输出包含的信息远超智能体所需，多余的信息正严重损害性能。

## 建筑工作流智能体案例

客户构建建筑项目"变更单（Change Order）"审查智能体：
- 100 页变更单解析后产生 **20 万行 JSON**
- 承包商提交变更单，智能体根据原始合同、进度表和单价表交叉比对
- 用户是负责数百万美元索赔的建筑项目经理，**每一项发现都需要链接回原始 PDF 的精确区域**
- 智能体在处理长文档时总是卡住

智能体利用沙盒环境、电子表格工具和边界框（Bounding Box）引用构建了整个系统，但卡住原因不在系统顶层设计，而在于 JSON 本身。

## 原始 API 响应并非为智能体输入而设计

Reducto 的解析响应为工程灵活性设计：每个模块（Block）都有边界框坐标、OCR 置信度分数、类型分类、坐标数据。这正是你开发文档阅读器或版面分析工具时所需要的。

**但这不是你希望放入智能体上下文窗口里的东西。**

当你把原始 JSON 交给智能体时，大部分 token 并不是文档内容，而是像素坐标、置信度浮点数和结构化元数据。智能体正试图在密集的边界框数组中艰难推理合同条款和单价。

**我们为工程师结构化 JSON，而不是为了让智能体直接消耗。大多数结构化 API 响应可能都是如此，不只是我们的。**

这中间有一个很多团队都忽略的预处理步骤。

## 解决方案：Content/Metadata 分离架构

### 核心思想
将解析输出在进入智能体之前拆分为两种表示：**内容（Content）和元数据（Metadata）**。

### 三步后处理（约 20 行代码）
1. 从 API 响应中提取内容（如 `.result.chunks[0].content`）并写入一个 `.md`（Markdown）文件
2. 丢掉坐标、置信度分数和块元数据
3. 剩下的就是一个干净、可读的文档版本

### 难点与解决
**难点**：许多客户需要"块级引用"——当智能体标记某项内容时，产品需要高亮显示原始 PDF 中的精确区域。你不能扔掉边界框，但你也不需要把它们放在上下文窗口里。

**修复方法**：在 Markdown 中为每个块编号。

```
块 0 | 第一节：一般条款
块 1 | 承包商应提供所有人工、材料和设备...
块 2 | 附件 B 中规定的单价应作为所有定价的依据...
块 3 | 1.1 工作范围
块 4 | 本变更单涵盖的工作包括对...的修改
```

完整的解析 JSON（或从中提取的 CSV）存放在智能体的**沙盒文件系统**中。智能体阅读并推理 Markdown 内容。当它发现值得引用的内容时——比如第 47 块中的单价不一致——它会**编写一段简单的 pandas 代码**，从结构化文件中提取对应的边界框。

**元数据永远不会占用上下文窗口。它只在需要时，通过代码按需获取。**

这就是为什么**沙盒化编码智能体**在处理文档工作时如此强大。智能体对待结构化元数据就像开发者一样：将其视为**待查询的数据**，而不是**待阅读的文本**。

原本 20 万 token 的 JSON 变成了：
- 一个用于理解的干净 Markdown 文件
- 一个用于空间查询的结构化文件

设置这一切只需要大约 **20 行的后处理代码**。

## Prompt Pattern 修正

**有害模式**：
> "从头到尾阅读每个附件文档。"

这听起来很合理，你希望智能体严谨周全。但模型非常擅长执行指令，哪怕指令本身并不合理。当你告诉智能体从头到尾阅读每个文档时，它会尝试将每个文件都加载到上下文窗口中。对于一份 100 页的变更单加上证明文件，智能体在做任何有用的工作之前，上下文预算就已经耗尽了。

**正确模式**：
> "利用附件文档回答问题。使用子智能体或工具来有效管理上下文。如果文件很大，请搜索相关章节，而不是加载整个文档。"

区别是巨大的。第一种提示词产生的智能体像是一个在考试前死记硬背教科书的学生；第二种则像是一个研究员，它会搜索（grep）相关章节、阅读特定片段、利用工具提取特定数据。它是在**引导（navigate）文档**，而不是试图背诵文档。

这对工具设计也很重要。如果你的智能体正在填写审查表格，一个能通过关键词或章节标题搜索并返回相关块的工具，远比一个将整个文件甩进对话里的工具更有用。

## 完整流水线

```
文档上传
  ↓
Reducto 解析 API（获取全保真 JSON）
  ↓
预处理（约 20 行代码）
  ├→ 提取块内容 → 带有编号的 .md 文件
  └→ 存储元数据 → 沙盒中的 CSV/JSON 文件
                              （可选）生成章节索引
  ↓
智能体沙盒
  .md 文件 → 智能体阅读并推理
  元数据文件 → 智能体在需要时通过代码查询
  工具：搜索、grep、代码执行、带有引用的单元格写入
  ↓
智能体引用第 47 块 → 编写 pandas 片段 → 提取边界框
  ↓
应用层在原始 PDF 中渲染高亮引用
```

## 核心原则

> "上下文不是免费的。每一个 token 都会影响模型的行为，而那些对任务无用的 token 会积极地挤占掉那些有用的 token。"

**一个包含 90% 坐标元数据的 100 万 token 上下文，效果不如一个拥有干净 Markdown 和优秀工具的 20 万 token 上下文。**

API 返回的所有数据与智能体实际需要的数据之间存在差距。弥合这一差距可以显著提升准确率和性能。

## 其他可行方法（对比）

- 向量搜索分块（Chunking with vector search）
- 层级化摘要（Hierarchical summarization）
- 微调检索（Fine-tuned retrieval）

但对于智能体需要跨文档进行详细交叉引用并产生精确引用的用例，将内容与元数据分离并给智能体提供干净的 Markdown，对我们合作过的团队来说效果非常好。

## 参考阅读

- [别再死磕模型调优了！Cursor和Manus告诉我们: 外壳(Harness)才是真正的护城河]
- [像智能体一样观察：Anthropic 团队谈 Claude Code 工具设计的演进与艺术]
- [我们如何构建安全可扩展的智能体沙箱基础架构]
- [关于软件开发未来的三点思考]

原文：https://x.com/raunakdoesdev/status/2029610657008783407