Agents Need a New Kind of Web Search ✍ Akshay🕐 2026-07-17📦 9.7 KB 🟢 已读 𝕏 文章列表 文章探讨了当前 AI Agent 在使用传统网页搜索时面临的“检索税”问题。传统搜索 API 仅返回链接和摘要，迫使 Agent 耗费大量 Token 去抓取和清洗内容。作者通过对比实验指出，使用预先爬取并结构化处理的索引（如 Seltz）能显著降低成本并提升效率，这种返回完整文档而非指针的方式是 Agent 搜索的未来。 AgentWeb SearchLLM成本优化检索增强搜索索引信息检索Seltz # Agents Need a New Kind of Web Search **作者**: Akshay **日期**: 2026-07-16T13:54:50.000Z **来源**: [https://x.com/akshay_pachaar/status/2077753829526056985](https://x.com/akshay_pachaar/status/2077753829526056985) ---  Andrej Karpathy once said LLMs are a bit like a coworker with anterograde amnesia. That’s the condition where you keep your old memories but can’t form new ones.  An LLM lives with that condition in two ways. It doesn’t remember you across conversations, and it never learns anything that happened after its training ended. Memory features exist to patch the first gap. This piece is about the second one, because agents mostly get hired to deal with the present. Markets move, people change roles, prices update, news breaks. Web search is how the model sees any of it, and how well it works ends up deciding how useful the whole agent is. So you bolt a search tool onto your agent and assume it can now read the web. Then you check the first few traces, and the result is disappointing. Nearly all the tokens you paid for went into raw page text the agent had to dig through. Only a thin slice went into answering your question. The reason is what a search call actually returns. A typical search API hands back links and thirty-word snippets, nothing more. So the agent isn’t reading the web, it’s reading a table of contents. Fetching the actual pages becomes its job, which means pulling the HTML, stripping the markup, and digging out the usable text before any real work starts. On a single query you barely notice the overhead. In a task that takes several searches, like a research run or a briefing pipeline, you pay it again on every single one.  The problem isn’t that agents search badly. It’s that each search call returns pointers to content instead of the content itself, and the agent pays to close that gap on every call. We ran the same question through three retrieval setups and counted tokens. The most expensive setup cost roughly 4x the cheapest retrieval option. This piece walks through those numbers and shows what a search response should look like when an agent is the one reading it. It also covers a class of questions that only full documents can answer. Let’s start with where the cost actually comes from. Every loop iteration pays the retrieval tax That repeated fetch-and-clean work has a name. Call it the retrieval tax, the tokens an agent burns preparing content before it can reason about your problem. One looping agent is enough to feel it. A research agent searches, reads what came back, decides what to look up next, and searches again, and every pass pays the tax on top of the last one.  Here’s what that costs on a single question. We picked “What was Y2K?” on purpose, because the model already knows the answer from training. We answered it three ways, straight from memory, through a web search loop, and through an owned index (a search service that crawls and cleans pages ahead of time and stores its own processed copy of the web), counting the total tokens billed each time. Picking a question the model already knows is what keeps the experiment clean. The thinking cost is identical in all three runs, so any tokens above it come purely from the retrieval. - From memory, the whole thing took about 600 tokens. That’s the baseline, the cost of just answering with zero retrieval. - An owned index is a search service that has already crawled and cleaned the pages, so one call returns the full document. Going through one took roughly 6,900 tokens. - A single web search hop cost about 3,750 tokens. But snippets are often too thin to answer from, so the agent refetches and refines, and three hops climbed to roughly 28,700, more than 4x the owned index.  The gap between the loop and the index is the tax made visible. Every hop re-billed the entire growing context window, so by the third pass the agent was mostly paying to carry pages it had already read. The owned index skipped all of that. The full document was already there when the query arrived. What makes that possible is what comes back from the search call itself, so let’s look at that next. # Good retrieval returns documents, not directions The fix isn’t a smarter agent or a better prompt. The fix is what comes back from the search call. - A SERP, the plain list of results a search API returns, hands you URLs and asks the agent to go read the web itself. - A scraper-first tool gets you closer by returning raw HTML or markdown, but the agent still has to clean it before it can use anything. - An owned index does all of that work before the query ever arrives, so what comes back is already readable. Here’s the same lookup across all three. We’ll search for Christoph Molnar, the author of the Interpretable Machine Learning book. SERP The agent got a list of tabs, not an answer. Neural search It found the right person, but as highlight fragments. Getting the full record still needs another call. Owned index One call returns the complete record, and the agent goes straight to reasoning. Seltz is a web index built exactly for this. It crawls the web ahead of time, processes every page into a structured document, and returns finished content through a single API call.  It comes with three scopes, and each one returns a different kind of finished document depending on what your agent needs. - The people scope returns full structured profiles, with every role and its dates, education, websites, and the organizations someone has worked at. - The news scope returns complete article text, date-windowed, so you can pull only what was published in a specific period. - The wiki scope returns clean Wikipedia documents, useful for building context around companies, industries, or topics before going deeper. One caveat is worth knowing before you build on the people scope. It works best at the director and regional-leader layer. For the most senior executives, start with open web search and use Seltz to enrich everyone below them. # Some answers only exist across records Full documents unlock something that goes beyond cutting the retrieval tax. Some questions don’t live in any single search result. The answer only exists once you read across multiple records and find where they intersect. Neither a SERP nor a neural search tool can do this on the first pass. They don’t hold enough of each record to join them, so the work lands back on the agent.  Consider a question a GTM team actually runs. You want every target account that hired someone into a data or AI leadership role in the last quarter. Answering it needs two things together. Full role histories to find who started a new position and when, plus recent news to confirm the timing and surface the trigger event. You query the people scope to find who moved into a relevant role recently, then cross-reference the news scope for the trigger event. What comes out is a ranked list of warm accounts with enough context to write a relevant first outreach line for each one. That answer doesn’t exist anywhere on the web as a page. It only exists once you join the records, and the join only works when you hold the full records to begin with. # Chain discovery and depth, and every iteration gets cheaper Seltz isn’t a replacement for open web search. It’s the right tool for a specific class of questions. Open web search handles discovery well. Finding who currently holds a title, confirming something launched last week, reading a page that went live this morning. Once you know what you’re looking for, Seltz returns the complete record in one hop rather than a headline and a link. Many pipelines use the same search tool for every query regardless of what the question needs. Discovery queries go through the same call as deep-dive lookups, and the loop pays the retrieval tax on both. Chain the two instead and each loop iteration gets the right retrieval shape for what it’s actually trying to do. That’s the core argument here. The cost of an agent loop is set less by the model and more by what each search call hands back, and returning finished documents is how you stop paying for the same pages twice. If you’re building loops that hit these query shapes, you should give Seltz a try. Get started here → Stay tune as I dig more into efficient web search for Agents and share what I learn along the way. Thanks for reading and Seltz for partnering with me on this article. Cheers! :) ## 相关链接 - [Akshay](https://x.com/akshay_pachaar) - [@akshay_pachaar](https://x.com/akshay_pachaar) - [9.9K](https://x.com/akshay_pachaar/status/2077753829526056985/analytics) - [Owned index](https://seltz.ai/) - [Seltz](https://seltz.ai/) - [Chain discovery and depth, and every iteration gets cheaper](https://seltz.ai/) - [Seltz](https://seltz.ai/) - [Get started here →](https://seltz.ai/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:54 PM · Jul 16, 2026](https://x.com/akshay_pachaar/status/2077753829526056985) - [9,978 Views](https://x.com/akshay_pachaar/status/2077753829526056985/analytics) --- *导出时间: 2026/7/17 11:25:30* --- ## 中文翻译 # 智能体需要一种新型的网络搜索 **作者**: Akshay **日期**: 2026-07-16T13:54:50.000Z **来源**: [https://x.com/akshay_pachaar/status/2077753829526056985](https://x.com/akshay_pachaar/status/2077753829526056985) ---  Andrej Karpathy 曾说过，大语言模型（LLM）有点像一位患有顺行性遗忘症的同事。这种病症是指你能保留旧的记忆，但无法形成新的记忆。  LLM 在两个方面处于这种状态。它既无法跨对话记住你，也永远学不到其训练结束之后发生的任何事情。 记忆功能的存在是为了弥补第一个缺陷。本文主要探讨第二个问题，因为智能体被“雇佣”主要是为了应对当下。 市场在变动，人员在换岗，价格在更新，新闻在突发。网络搜索是模型感知这一切的途径，而其运作的好坏最终决定了整个智能体的实用性。 因此，你给智能体安装了一个搜索工具，并假设它现在可以阅读网络内容了。但当你检查最初的几个追踪记录时，结果却令人失望。 你支付的 token 几乎全都变成了智能体必须筛选的原始页面文本。只有极小一部分用于回答你的问题。 原因在于搜索调用实际返回的内容。典型的搜索 API 只返回链接和三十个单词的摘要，仅此而已。 所以，智能体并不是在阅读网络，而是在阅读目录。获取实际页面成了它的工作，这意味着在开始任何实际工作之前，必须提取 HTML、剥离标记并挖掘出可用的文本。 在单次查询中，你几乎注意不到这种开销。但在一个需要多次搜索的任务中，比如研究运行或简报生成流程，你在每一次搜索时都要再次支付这笔开销。  问题不在于智能体搜索得不好，而在于每次搜索调用返回的都是指向内容的指针，而不是内容本身，而智能体必须在每次调用时付费来弥补这一差距。 我们通过三种检索设置运行了同一个问题并统计了 token 数量。最昂贵的设置的成本大约是最便宜的检索选项的 4 倍。 本文将梳理这些数据，并展示当阅读者是智能体时，搜索响应应该是什么样子的。它还涉及了一类只有完整文档才能回答的问题。 让我们先从成本的真正来源开始。 每次循环迭代都要支付检索税 这种重复的获取和清理工作有一个名字。称之为“检索税”吧，即智能体在能够针对你的问题进行推理之前，为了准备内容而消耗的 token。 只要有一个循环运行的智能体，你就能感受到这一点。研究型智能体进行搜索，阅读返回的内容，决定接下来查找什么，然后再次搜索，每一次循环都要在前一次的基础上支付这笔税。  这是一个单次问题的成本。我们特意选择了“什么是 Y2K（千年虫）？”这个问题，因为模型已经从训练中知道了答案。 我们通过三种方式回答了它：直接从记忆中回答、通过网络搜索循环、以及通过自建索引（一种预先抓取并清理页面并存储自己的网络处理副本的搜索服务），并统计每次计费的 token 总量。 选择一个模型已经知道的问题是为了保持实验的纯净性。三种运行的思考成本是相同的，因此超出该成本的任何 token 都纯粹来自检索。 - 从记忆中回答，整个过程大约花了 600 个 token。这是基线，即不进行任何检索仅回答问题的成本。 - 自建索引是一种已经抓取并清理了页面的搜索服务，因此一次调用就能返回完整文档。通过这种方式大约消耗了 6,900 个 token。 - 单次网络搜索跳转大约花费了 3,750 个 token。但摘要往往过于简略，无法据之回答，因此智能体需要重新获取并优化，三次跳转后成本攀升至约 28,700 个 token，是自建索引的 4 倍多。  循环与索引之间的差距就是“检索税”的直观体现。每一次跳转都对整个不断增长的上下文窗口进行重复计费，因此到了第三次，智能体支付的大部分费用都是为了携带它已经读过的页面。 自建索引跳过了所有这些步骤。当查询到达时，完整文档已经准备好了。 能够实现这一点的关键在于搜索调用本身返回的内容，所以接下来让我们看看这一点。 # 良好的检索返回的是文档，而不是指引 解决办法不是更聪明的智能体或更好的提示词。解决办法在于搜索调用返回的内容。 - SERP（搜索引擎结果页），即搜索 API 返回的普通结果列表，只给你 URL 并要求智能体自己去阅读网络。 - 优先抓取的工具通过返回原始 HTML 或 markdown 让你更接近一步，但智能体在使用之前仍然必须对其进行清理。 - 自建索引在查询到达之前就完成了所有这些工作，因此返回的内容已经是可读的。 以下是所有三种方式的相同查找过程。我们将搜索《可解释机器学习》一书的作者 Christoph Molnar。 SERP（搜索引擎结果页） 智能体得到的是标签列表，而不是答案。 神经搜索 它找到了正确的人，但仅以高亮片段的形式。要获取完整记录仍需另一次调用。 自建索引 一次调用返回完整记录，智能体直接进入推理环节。 Seltz 正是为此构建的网络索引。它预先抓取网络，将每个页面处理成结构化文档，并通过一次 API 调用返回完成的内容。  它提供三种范围，每一种根据智能体的需求返回不同类型的完成文档。 - 人员范围返回完整的结构化个人资料，包含每个职位及其日期、教育背景、网站以及相关人员曾工作的组织。 - 新闻范围返回完整的文章文本，可按日期窗口筛选，因此你可以仅提取特定时期发布的内容。 - Wiki 范围返回清理过的 Wikipedia 文档， useful for building context around companies, industries, or topics before going deeper.（注：此处原文未翻译，建议补全：这对于在深入挖掘之前围绕公司、行业或主题构建背景非常有用。） 在基于人员范围进行构建之前，有一点值得注意。它在总监和区域负责人层面效果最好。 对于最高级的高管，请先从开放网络搜索开始，然后使用 Seltz 来充实其下属的信息。 # 有些答案仅存在于跨记录之间 完整文档解锁的不仅仅是降低检索税。 有些问题并不存在于任何单一的搜索结果中。只有当你阅读多个记录并找到它们的交集时，答案才会显现。 无论是 SERP 还是神经搜索工具，都无法在第一轮就做到这一点。它们持有的每个记录的信息量不足以进行连接，因此工作又回到了智能体身上。  考虑一个 GTM（进入市场）团队实际会遇到的问题。你想要找到所有在上个季度招聘了数据或 AI 领导层职位的目标客户。 回答这个问题需要两件事的结合。完整的职位历史记录，以找出谁开始了新职位以及何时开始，加上最近的新闻来确认时间点并引出触发事件。 你查询人员范围以找到最近进入相关职位的人员，然后交叉参考新闻范围以寻找触发事件。 输出的是一个排序后的潜在客户列表，其中包含足够的上下文，以便为每个客户撰写相关的首次触达话术。 这个答案在网络上的任何页面都不存在。只有当你连接这些记录时，它才会存在，而要实现连接，前提是你必须持有完整的记录。 # 链式发现与深度，每次迭代都变得更便宜 Seltz 不是开放网络搜索的替代品。它是针对特定类别问题的正确工具。 开放网络搜索擅长发现。例如查找谁目前拥有某个头衔，确认某事上周是否发布，阅读今天早上上线的页面。 一旦你知道了你要找什么，Seltz 就能在一次跳转中返回完整记录，而不是一个标题和一个链接。 许多流水线对每个查询都使用相同的搜索工具，而不考虑问题实际需要什么。发现类查询和深度查找查询使用相同的调用，循环对两者都要支付检索税。 相反，将两者链接起来，每次循环迭代都能获得与其试图实际执行的操作相匹配的检索形式。 这就是核心论点。智能体循环的成本更多地取决于每次搜索调用的返回内容，而不是模型本身，而返回完成文档是让你停止为同一页面付费两次的方法。 如果你正在构建涉及这些查询模式的循环，你应该试一试 Seltz。 从此处开始 → 请持续关注，我将深入探讨针对智能体的高效网络搜索，并在此过程中分享我的所学。 感谢阅读，也感谢 Seltz 与我合作撰写本文。 干杯！ :) ## 相关链接 - [Akshay](https://x.com/akshay_pachaar) - [@akshay_pachaar](https://x.com/akshay_pachaar) - [9.9K](https://x.com/akshay_pachaar/status/2077753829526056985/analytics) - [Owned index](https://seltz.ai/) - [Seltz](https://seltz.ai/) - [Chain discovery and depth, and every iteration gets cheaper](https://seltz.ai/) - [Seltz](https://seltz.ai/) - [Get started here →](https://seltz.ai/) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [9:54 PM · Jul 16, 2026](https://x.com/akshay_pachaar/status/2077753829526056985) - [9,978 Views](https://x.com/akshay_pachaar/status/2077753829526056985/analytics) --- *导出时间: 2026/7/17 11:25:30*
实 实战踩坑：便宜模型执行、贵模型编排？没这么简单！ 文章通过三个真实案例，验证了“贵模型编排、便宜模型执行”这一省钱策略。作者发现，虽然便宜模型在文本判定等任务上能打平顶尖模型，但在高复杂度代码和开放式视觉任务上存在局限。关键在于控制模型能力代差和任务可验证性，否则返工成本将抵消节省的 token 费用。 技术 › Agent ✍ WquGuru🕐 2026-07-28 LLMAgent模型编排成本优化Claude Code多模型协作工程实践
从 从零构建 LLM 架构：10 个实用经验教训 本文指出构建 AI 产品的核心不在于选择模型，而在于架构设计。作者分享了 10 个实用经验，强调从工作流而非模型入手、重视检索优于微调、将提示工程视为系统工程、关注延迟优化、为智能体设置护栏、妥善处理记忆、建立评估管道以及优化成本。最终，多智能体系统将是未来趋势。 技术 › LLM ✍ Tabassum Parveen🕐 2026-05-20 LLM架构设计RAGAgent工程化最佳实践系统设计Prompt工程成本优化Multi-Agent
L LLM 中的 Prompt Caching 技术详解：以 Claude 为例的高效缓存策略 本文深入探讨了 LLM 中的 Prompt Caching 技术，解释了其背后的 KV Cache 机制及静态/动态上下文分离原理。文章通过 Claude Code 的案例分析，展示了如何通过保持 92% 的缓存命中率来将计算成本降低 81%，并总结了哈希敏感性和工程化落地的关键约束。 技术 › LLM ✍ Avi Chawla🕐 2026-04-20 Prompt CachingLLMAgentClaudeKV Cache成本优化系统架构Transformer
从 从构建 Claude Code 中汲取的经验教训：提示缓存至关重要 文章详细阐述了提示缓存在构建 Claude Code 等 AI 代理中的关键作用。核心经验包括：利用前缀匹配机制规划缓存、通过消息传递更新而非修改系统提示以保持缓存、避免中途切换模型或工具、以及利用“延迟加载”和“缓存安全分叉”等技术优化上下文管理。围绕缓存设计系统架构能显著降低延迟与成本。 技术 › LLM ✍ Thariq🕐 2026-03-22 Claude Code提示缓存Agent成本优化系统架构LLM工程实践前缀匹配延迟加载
C ChatGPT Agent Loop 优化技术解析 本文深入解析了 ChatGPT 如何通过 Harness、API 和 Inference 三层架构优化 Agent 循环，重点介绍了持久化 WebSocket、增量 Token 化、KV 缓存管理和推测解码等技术，以降低成本并提升效率。 技术 › Harness Engineering ✍ Bytebytego🕐 2026-07-30 Agent优化LLM架构ChatGPTOpenAI性能成本控制WebSocketTokenization
B BestBlogs 早报｜实现周期骤缩后，创业者如何重选问题 本期早报探讨了 AI 智能体缩短实现周期后，创业者的机遇与挑战。文章涵盖 Sam Altman 对创业窗口的判断、GPT-5.6 的效率工程实践，以及如何通过 Skill Harness 将模型能力封装为可维护的产品功能。 技术 › Skill ✍ ginobefun🕐 2026-07-30 GPT-5.6Agent创业效率工程ProductHarnessSkillLLMOpenAI
C Claude Opus 5 提示工程大师课 文章详细解读了 Anthropic 发布的 Claude Opus 5 模型及其官方提示指南。核心内容包括“Effort（努力）”设置的使用、从“怎么做”转向“为什么”的提示策略、删除验证指令以降低成本、以及如何控制响应长度和 Agent 叙述行为，旨在帮助用户最大化发挥模型效能。 技术 › LLM ✍ Rahul🕐 2026-07-28 Claude Opus 5提示工程AI技巧AgentLLMAnthropic最佳实践
R Run Your Harness Outside of the Sandbox (Why and How) 本文探讨了2026年以来关于Agent运行位置的争论，指出行业趋势是将Agent运行在沙箱之外。作者详细解释了沙箱内运行的三个主要问题：爆炸半径、信任边界和沙箱的间歇性运行，并提出了将沙箱作为工具暴露的正确架构，最后提供了基于Vercel AI SDK的实现示例和生产环境中的挑战。 技术 › Agent ✍ Nathan Flurry🕐 2026-07-28 Agent沙箱架构设计DevOps后端LLM安全性生产环境Vercel AI SDK状态管理
一 一个暑假，我侄子用两个 Skill 搞明白了 Agent 最难的部分 作者讲述侄子利用暑假开发两个健康类 Agent Skill 的经历。从“养生谣言粉碎机”到“体检行动助手”，解决了大模型幻觉、信息检索权威性及流程设计等难点。文章重点介绍了如何利用豆包搜索 API 的结构化数据与权威过滤功能来增强 Agent 能力，并分享了 Skill 开发优于独立 Agent 的实践经验和建议。 技术 › Agent ✍ 宝玉🕐 2026-07-28 AgentSkill豆包搜索AI开发大模型实战经验信息检索健康类目工作流开源
本 本周顶级 AI 论文精选 文章精选了本周 6 篇顶级 AI 论文，涵盖 Harness Handbook、MSCE 记忆技能框架、PRO-LONG 长程记忆机制、Anthropic 全局工作空间解释性研究、Meta 的 GAMUT 完整性基准测试以及渐进式披露模式。 技术 › LLM ✍ DAIR.AI🕐 2026-07-27 AI论文AgentMemoryInterpretabilityAnthropicMetaLLMResearch
浪 浪费20亿Token之后，我做了一个帮自己定义目标的Skill 作者分享了一个名为Leader.skill的开源工具，旨在解决Agent交互中目标定义模糊的问题。该工具基于“目标七问”方法论，将模糊需求转化为清晰的目标任务书，支持多模型组合（如Claude规划、GPT执行），显著提升长程任务的完成率与Token利用率。 技术 › Skill ✍ 数字生命卡兹克🕐 2026-07-27 AgentGoal Engineering目标定义自动化开源LLM效率工具方法论ClaudeGPT
G Graph Engineering：从 0 到 1 小白完整教程 文章介绍了 Graph Engineering，一种通过流程图协调多个 AI 协作完成复杂任务的方法。它将复杂任务拆解为节点、边和状态，解决了单 Loop 应对复杂任务时的局限性。文章详细解析了 Graph 的核心概念、与 Loop 的关系、四个核心模块及具体实践模板，并提供了新手学习路径。 技术 › Agent ✍ Adrian Punk🕐 2026-07-27 Graph EngineeringAgentLLMAI 协作工作流Loop Engineering教程节点设计状态管理AI 架构