优质的文档能为一款AI智能体节省多少成本和时间？事实证明，节省幅度非常大。

我们构建了一项自定义技能，教Claude如何更高效地解析PDF，然后利用真实的使用轨迹找出它在哪些地方浪费了时间和金钱（反复读取同一份文件、对页面进行不必要的“截图”等）。

经过几轮基于观察结果的修复后，与让Claude按默认方式读取PDF相比，结果如下： → 每个问题的成本降低37% → 答案质量全面提升 → 不必要的步骤更少

重要启示：查看智能体在追踪记录中实际留下的内容，并据此修复瓶颈。

完整案例研究 https://llamaindex.ai/blog/building-a-better-liteparse-skill-with-evals?utm_medium=socials&utm_source=twitter&utm_campaign=2026–… 基准测试代码 https://github.com/run-llama/benchmark-claude-pdfs…

为Claude智能体构建更快、更便宜的PDF解析技能：LiteParse案例研究

来源：https://www.llamaindex.ai/blog/building-a-better-liteparse-skill-with-evals?utm_medium=socials&utm_source=twitter&utm_campaign=2026– 在本篇博文中，我们将介绍如何通过评估智能体对文档解析技能的使用、分析追踪记录以及不断迭代，将我们的LiteParse文档解析技能改进为更便宜、更快、质量更高的辅助工具。

准备工作

我们使用pdfQA-Benchmark (https://huggingface.co/datasets/pdfqa/pdfQA-Benchmark)ClimateFinanceBench 数据集来评估Claude回答企业可持续发展/ESG报告相关问题的能力，下载了30个PDF文件及其附带的问答对。

然后，我们运行一个Claude Agent（通过claude-agent-sdk）来处理15个(PDF, question) 对。每次运行都会生成一个结构化的JSON答案和一份完整的JSONL交互追踪记录。

每个Claude Agent都能访问标准工具，仅限于项目范围之内，并根据评估配置有条件地允许调用某项技能。

我们比较了几种配置：

• raw — Claude使用内置的Read工具直接读取PDF
• liteparse — 技能的初始版本，封装了本地lit (https://github.com/run-llama/liteparse) CLI (https://github.com/run-llama/liteparse) 用于快速、无模型的PDF解析。
• liteparse-targeted — 更具指令性的变体。我们试图让Claude更频繁地注意到/使用LiteParse。
• effective-liteparse — 基于评估追踪记录分析，为减少延迟而优化的LiteParse使用技能。

本文介绍的是最后一个版本是如何诞生的。

为什么需要技能？

LiteParse既可以作为命令行应用程序使用，也可以作为Rust、Python和JavaScript/TypeScript的库使用。由于文档解析本质上是I/O密集型的，并且需要直接访问文件或原始字节，因此LiteParse并不适合集成到MCP服务器中——MCP服务器不支持文件上传，需要base64编码的字符串或其他变通方法（详见这篇其他博文 (https://www.llamaindex.ai/blog/llamaparse-mcp-the-tooling-layer-for-your-document-agents)）。

因此，技能是最实际的集成模式。通过将使用说明打包成Markdown文件并注入到智能体的上下文中，我们使智能体能够使用LiteParse CLI直接替换Claude内置的PDF阅读器或其他替代解析工具（如PyMuPDF和pdftotext）。使用CLI还可以轻松地将LiteParse与标准Unix工具（如grep和sed）组合使用，让智能体无需额外工具即可过滤、搜索和转换解析后的输出。

然而，让工具可用只是挑战的一部分。技能指令必须精心设计并评估，以确保智能体不仅在适当的时候调用LiteParse，而且能高效地使用它。与通用解析方法相比，精心设计的技能可以帮助智能体更快地处理文档，降低token和计算成本，并提高提取准确性。

寻找反模式

在前两轮评估之后，我们收集了第一批指标（延迟、轮次、成本、工具调用……），并分析了第一批技能版本的JSONL追踪记录，发现了一组反复出现的、代价高昂的错误：

• 反复解析同一个PDF —— 在最糟糕的追踪记录中，lit parse 对单个文档运行了9次，每次搜索都执行一次。每次调用都会重新提取整个PDF。
• 对原生数字PDF启用OCR —— 大多数ESG报告都有真实的文本层；运行OCR纯粹是浪费时间。
• 将高DPI页面截图读入上下文 —— 一张页面PNG图片消耗了约14万字符的上下文，而且智能体经常渲染同一页面两次（默认 + 高分辨率）。
• 无限制的散弹式grep —— 大量的关键词替代项，向对话中倾倒15–25k字符。

尽管存在这些反模式，LiteParse方法仍显示出巨大的潜力。由于解析是通过CLI在外部进行的，因此不受Claude原生文档阅读器限制（目前最多接受32 MB和600页的PDF）。实际上，这赋予了LiteParse几乎无限制的解析能力，主要受限于可用系统资源。

这就是为什么我们决定创建effective-liteparse技能，将修复方案编码为硬性规则：解析一次到临时文件，然后搜索文件；对原生数字PDF使用--no-ocr；截图仅作为最后手段，一次一页，适度DPI；保持结果精简。

除了强化的规则外，我们注意到Claude Agent经常在解析后的内容中执行多次紧凑的迭代，使用grep、sed和Read来查找完成评估任务所需的正确上下文。从这个意义上说，我们扩展了技能的表面，包含了一个小型、独立的Python脚本，该脚本并发读取、分块、索引并基于提供的查询执行BM25后检索。我们在技能中包含了指令，要求使用此脚本来搜索更模糊的关键词，默认使用词汇搜索进行模式/子串搜索。

解析，但不要跑偏

在首次修复后，分析追踪记录时出现了一个新信号：effective-liteparse 比原始的Claude Code更便宜，但速度更慢，原因是轮次数量（turns），而不是解析本身。解析后调用最多的工具是grep和sed，它们以串行循环的方式使用：grep → 查看 → 优化grep → 用sed查看窗口（单独轮次） → 再次grep，每次轮次都是一次完整的API往返。

讽刺的是，我们之前自己制定的两条规则让情况变得更糟：“先定位，再用sed读取窗口” 将每次查找分割为两次轮次，并且 “不要散弹式搜索” 促使模型进行许多微小的串行grep。因此，我们将指导原则改为最小化往返次数：

1. 在同一命令中获取上下文 —— grep -n -i -C4 "term" 在一次轮次中返回匹配项及其上下文窗口，无需后续的sed。
2. 将独立的查找批量处理到一个命令中 —— 使用带标签的for循环一次探测多个事实，而不是每次轮次执行一个grep。
3. 设置硬性搜索预算 —— 在≤3个命令内解决；两次grep不成功后，退回到BM25排序器一次，而不是永远尝试关键词变体。

追踪记录证实了采纳情况：在解析后的工具组合中出现了新的for循环批量模式，平均轮次下降了约15%（13.1 → 11.1）。

数据结果

我们使用LLM作为评判小组（Gemini和GPT，各自对答案及其背后的推理进行评分）对答案进行评分，并通过追踪分析衡量效率，使用匹配的15个问题子集。

质量（LLM作为评判，平均分，越高越好）：

效率（追踪指标）：

Token使用量：

该技能每个问题便宜37%，并且在所有评判指标上得分更高。它在完整任务上仍然慢几秒钟，但轮次持续时间更快，支持更多迭代。

关于Token使用量的说明

乍一看，effective-liteparse 变体在token上看起来更贵：每次运行平均处理约384k输入token，而原始基线约为302k。但这个总数具有误导性，因为它将按不同方式计费的输入类别混在了一起。一旦按计费类别分解输入，情况就反转了：liteparse 中额外的容量主要是缓存读取（按优惠价0.50/MTok计费的token），而昂贵的部分——写入缓存的新内容（6.25/MTok）——比基线低约3倍（29.6k vs 86.7k token）。原始方法每次读取都会重新缓存大型PDF图像页面，而liteparse 在本地解析文档并返回紧凑的文本，因此代价高昂的缓存写入大幅减少，即使便宜的缓存读取增加了。净效果是，尽管liteparse 总体上触及更多token，但其运行成本降低了约40%（平均$0.45 vs $0.75）。

成本使用已发布的Claude Opus 4.7费率（$5基础输入 / $6.25 5分钟缓存写入 / $10 1小时缓存写入 / $0.50缓存读取 / $25输出，每MTok）。报告的成本是运行时的total_cost_usd；与按类别计算的总成本之间的微小差异来自于一个次要的Haiku调用，顶级使用记录未包含该调用。

经验教训

• 追踪记录是真相的源泉。 这里的每一项改进都来自阅读智能体实际做了什么。
• 技能指导会产生二阶效应。 “先定位再读取”和“不要散弹式搜索”听起来谨慎，但实际上增加了往返次数。要优化总轮次，而不是每个命令的简洁性。
• 将框架与技能分离。 最大的成本数字是框架产物，而非技能属性。在归因之前要仔细测量。
• 更便宜和更好在这里并非取舍关系。 规范的本地解析在成本和答案质量上都优于原始PDF摄入。

你可以在以下地址找到完整的基准测试并进行复现：https://github.com/run-llama/benchmark-claude-pdfs