给 Agent 配工具就够了？从 PDF 解析看轨迹驱动的工程进化

起因：为什么给 Agent 配工具还不够？ 最近 LlamaIndex 团队分享了一个极具代表性的工程案例：如何通过系统化评估优化 Claude Agent 调用 LiteParse 解析 PDF 的 Skill。很多人以为，给大模型接个外部解析库，任务就算完成了。但现实是，Agent 用起来往往像个缺乏经验的实习生——明明有现成工具，却反复调用同一份文件、无脑对数字版报告开启 OCR、甚至把高分辨率页面截图全塞进上下文。这不仅导致延迟飙升、Token 账单爆炸，还经常引发上下文窗口溢出。这件事之所以现在值得深入聊，是因为它精准戳中了当前 Agent 落地的核心痛点：工具链的堆砌早已不是门槛，教 Agent 有纪律地使用工具才是决定工程成败的分水岭。

拆解：从反模式到精准调优 团队没有盲目调参，而是通过跑基准测试和收集 JSONL 交互轨迹，像法医一样解剖了 Agent 的行为。他们揪出了几个典型的烧钱反模式：单次任务中对同一 PDF 调用解析命令高达 9 次；默认开启 OCR 导致纯文本文件处理时间翻倍；滥用 grep 一次性向对话注入两三万字符的原始数据。解决思路非常务实：基于轨迹做外科手术式的 Skill 指令优化。比如，在指令中强制加入解析前检查文件元数据、禁止重复解析已缓存内容、限制单次工具输出字符上限。经过几轮迭代，解析速度大幅提升，Token 消耗和幻觉率也显著下降。值得注意的是，由于 PDF 解析是强 I/O 操作，直接走 CLI 封装成 Skill 比强行适配不支持文件上传的 MCP 协议更符合实际架构需求。

趋势洞察：Agent 工程正在进入轨迹驱动时代 这揭示了一个更深层的行业趋势：AI Agent 的开发范式正在从直觉式提示词工程转向数据驱动的轨迹优化。过去我们靠经验写 System Prompt，现在必须依赖可观测性和自动化 Evals 闭环。Skill 不再是一个静态的 Markdown 说明书，而是一个需要持续压测、监控坏味道并快速迭代的策略层。Markdown 正在成为 Agent 的操作手册，但真正决定它能否跑起来的，是背后的评估流水线。行业正在学会用数据代替直觉来管理 Agent 行为。

实用价值：开发者该怎么抄作业？ 如果你正在构建处理长文档或复杂工作流的 Agent，别再把精力全耗在微调模型上。第一步，务必把 Agent 的完整交互轨迹结构化存储；第二步，定期用脚本扫描最贵的几次调用，定位重复劳动和上下文污染；第三步，在工具调用逻辑中预埋强约束规则。这套方法论能直接帮你把云账单砍掉一大截，同时提升系统稳定性。

反常识：最强的瓶颈往往不是模型，而是工具滥用 我们总以为 Agent 表现不佳是因为底层模型不够聪明，但实际排查发现，大部分性能损耗源于 Agent 缺乏成本意识和状态管理。给 Agent 加上评估护栏和使用纪律，往往比盲目升级到下一代旗舰模型带来的 ROI 更高。未来的 Agent 竞争，拼的将不再是纯粹的推理智力，而是系统级的工程纪律与成本管控。

原文地址: Building a Better LiteParse Skill with Evals