跨国深谈← 返回←给代码智能体装上搜索：EXA 的实战方法

给代码智能体装上搜索：EXA 的实战方法

关联

人物 Jakub Hojsan

公司 Exa · Exa Agent

概念 智能体 · 网页搜索 · 知识截止日期 · 代码审查 · 语义搜索 · 高亮蒸馏

这一集聊的是一件很具体的事：怎么给写代码和评审代码的 AI 智能体装上好用的网络搜索。演讲者是 EXA 的前置部署工程师 Jacob Hoisan——他的工作就是帮客户把 EXA 的搜索接进自己的智能体。

EXA 做的不是 Google 式的「10 条蓝色链接」，而是一个语义搜索引擎：你传一个查询，它返回上下文丰富的高亮片段，直接喂给 LLM 用。按他的说法，湾区大部分 coding agent 公司(包括 Cursor、Cognition、Warp、CodeRabbit)的网页搜索都是 EXA 在背后驱动的。

核心问题：模型有「知识截止日期」

所有大语言模型都有知识截止日期——模型训练数据截止的那个时间点，之后发生的事它一概不知道。Jacob 给出的量级是：从知识截止到模型发布，通常要落后大约六个月。这六个月里，真实仓库上的重要变更日志、新推的 PR,模型既无法用来创建新仓库，也根本没法评审。

他举了个真实例子：一个几个月前的向量存储 PR,落在模型截止日期之后的盲区里。人类怎么评审？

会去 Stack Overflow 上问「这个叫 inertia check 的随机变量是不是被删了？为什么我的代码编译不过？」——把报错贴上去，通常能拿到答案，然后提 PR 解决。

而一个没有网络搜索的 LLM 看这个 diff,会觉得「改动一致，像是一次清理」，看起来没问题。但实际上，删掉这个参数的原因是需要为一次依赖版本升级做重构。用网络搜索，智能体才能查看仓库本身、变更日志里的破坏性变更，然后深入解释这次迁移该怎么改。

光加工具不够：一个两步问题

这里有本集最反直觉的一点：仅仅把搜索工具接到智能体上，是不起作用的。Jacob 举的例子是 Claude Code——它原生就有网络搜索工具，但当你对它说「我想用 Sonnet 4.6 或 4.7」,模型会直接回答「这个版本不存在」，根本不去搜索。也就是说，即使工具有了访问权限，模型不知道自己该用它。

所以必须走两步：一是指示智能体何时使用搜索(因为它通常不会自己触发)，二是实际执行搜索。落地做法是给模型一套明确的规则。比如给代码评审智能体写：当遇到一个升级依赖或版本的 diff 时，去查看上游源码验证这是否属实，然后把评审建立在你查到的内容之上。

高亮蒸馏：只喂模型需要的 500 个字符

EXA 返回的不是整个网页。它有一个解释步骤，把整个页面蒸馏成 LLM 回答这个问题真正需要的内容。Jacob 的原话：你不再给模型喂 100,000 个字符，而是只喂 500 个字符。

这个高亮抽取完全是计算性的，运行时直接抽取特定行，不经过 LLM,零裁剪、零额外延迟。同一个网站，问他的生平简介会返回「热爱摄影、骑摩托车」那些内容，问他的电话号码则返回完全不同的一组信息——按查询动态决定抽取什么。放到代码场景：一个仓库可能有海量代码，但你既不想把全部代码喂进模型，也不想再调一个模型去综合它。

为什么不直接用模型厂商自带的搜索

Jacob 给了四条理由：

• 透明性：用 OpenAI 或 Anthropic 的内置网页搜索是个黑盒——调 API、综合信息、可能耗时长达 10 秒，最后你拿到一部分来源、却拿不到内容。用 EXA 能拿到完整追踪：确切的查询、确切的来源、传给模型的高亮，可以直接接进遥测系统，出问题时能排查。
• 省 token 的高亮：如上所述，页面蒸馏成模型确切需要的内容。
• 成本：模型提供商的成本高到让你注意不到搜索账单，但在足够大的工作负载下，EXA 的定价比原生搜索划算得多，多数情况下质量也更好。
• 不被绑定在一家模型商上：用第三方搜索有一层标准化——GLM 出来就用 GLM,Anthropic、OpenAI 出新模型就用新模型，始终是同一个固定 API、同一组灵活参数，不用适配每家的搜索实现。

质疑环节：数十亿文档怎么排序

有观众问：互联网上数十亿文档的重排序和组织是怎么做的？Jacob 的回答：多阶段流程——查询转成查询嵌入，中间叠加关键词过滤与语义搜索，搜索过程中采用多轮重排序，丢弃不相关结果。索引是高度精选的：文档数量不如 Google 多，但他敢打赌，在这数百亿文档的索引里，文档质量非常高。

产品延伸：编码只是开始

Jacob 说编码只是起点——这也正是他加入 EXA 的原因之一，当时就有大批人想把 EXA 当作获取编码文档的搜索 API。在编码之外，他们推出了新产品 Exa Agent:面向不想自己编排搜索、但需要好的搜索体验的场景，与多家数据提供商合作，从 SimilarWeb(网页分析)、Particle(播客情报)、Crunchbase(私募市场)等来源呈现高亮信息，正在为最大的金融公司和对冲基金提供支持。

现场他还演示了一个查询：找出所有提到过这场大会的人——结果里出现了他认识的、给他发过邮件的演讲者。接入方式上，通过 MCP 就能调用，基本覆盖所有支持 MCP 的提供商。

本集带走

• 给智能体加搜索是两步，不是一步：接入工具只是第一步，必须再给模型写明确的触发规则(例如「遇到依赖升级的 diff 就查上游变更日志验证」)，否则模型会自信地告诉你「这个版本不存在」而不去搜。
• 别整页喂模型：知识截止之后约六个月的真实仓库变更，模型天生看不见；搜索后要做页面蒸馏，把 10 万字符压到几百字符再喂给 LLM,省 token 也省注意力。
• 评审代码时，diff 看起来对不等于真的对：一个「像清理」的参数删除，背后可能是依赖升级带来的破坏性变更，只有查上游源码才能解释清楚。
• 自建搜索工具时保留完整追踪：确切的查询、来源、传给模型的高亮都落进遥测，出问题才能排查——这是厂商内置黑盒搜索给不了的。

代码编写智能体其实并不需要你在搜索 Google 时看到的那 10 条蓝色链接。
Coding agents don’t really need these 10 blue links that you see when you search Google.
—— Jakub Hojsan · [00:29]

这样你就不再给模型喂 100,000 个字符了，你实际上只给它喂 500 个字符来回答这个问题。
So you’re not feeding the model 100,000 characters anymore. You’re feeding it quite literally only 500 characters to answer the question.
—— Jakub Hojsan · [03:09]

仅仅给你的智能体加一个搜索工具是不够的。
Now, adding a search tool to your agent is not enough.
—— Jakub Hojsan · [03:20]

通过为你提供互联网上几乎任何页面的内容，我们给搜索调用增加的额外延迟为零。
We add zero extra latency to our search call by providing you the contents of pretty much any page on the internet.
—— Jakub Hojsan · [06:26]

我们的索引是高度精选的，所以我们的文档数量没有 Google 那么多，但我敢打赌，在我们数百亿文档的索引里，我们有质量非常高的文档。
Our index is highly curated, so we don’t have as many documents as Google, but I bet you that we have very high-quality documents in our tens of billions of documents index.
—— Jakub Hojsan · [10:54]