分页是一项工具目录规范:为什么智能体在处理列表返回时会耗尽上下文
在你的技术栈中,每一个设计良好的 HTTP API 都会返回分页结果。没有人会把一百万行数据加载进内存并祈祷一切顺利。然而,你的智能体(agent)所调用的工具却会返回整个列表,而智能体也会尽职尽责地阅读它,因为函数签名写的是 list_orders() -> Order[],且智能体不像人类用户那样拥有“滚动并加载更多”的协议。
智能体在原本可以跳过的行上浪费了 Token。拥有 50K 记录的长尾客户遇到了中等规模客户从未见过的上下文窗口失败。工具作者无法从追踪(trace)中判断智能体是需要所有这些行,还是仅仅因为无法请求更少的数据。而且,在你评估套件的某个地方,原本会标记这种退化的回归测试从未运行,因为每个测试固件(test fixture)的记录都少于 100 条。
分页不是一种 UI 交互功能。它是一种负载卸载(load-shedding)原语 —— 而在没有分页的情况下使用工具的智能体,正在重新犯下你们公司的 API 设计师们花了十年时间才学会避免的每一个 SELECT * FROM orders 错误。
