先看证据
升级的重点，是让检索投入可分档
Exa Labs 于 2026 年 10 月 19 日发布 Exa 3.0，这是面向 AI agent 的网页搜索 API 升级，新增了低价搜索类型 Exa Lite，并让 Dynamic Highlights 正式可用。Exa 把这次更新描述为检索质量提升，但对工程团队来说，更具体的变化是搜索可以按计算投入分档：Lite 和 Auto 使用同一索引，Auto 则在候选生成、摘要提取和排序上花更多计算。
这使得搜索选择不必只是在“哪家排名最高”之间做判断。对于一个会反复搜索、再把结果交给模型推理的 Agent，检索成本、上下文占用和结果质量会同时影响整条任务链。Exa 3.0试图把其中两项做成可调参数：开发者可以用 Lite 控制单次请求价格，也可以在需要更多检索处理时选 Auto。它提出的是一种预算分层方案，是否适合具体任务仍需实测。
共享索引，计算换来的是边际提升
Exa 公布的任务成本—得分图给出了这套分档的一个具体例子：Lite 每个任务约花 0.045 美元，得分约 79；Auto 每个任务约花 0.065 美元，得分约 80.5。按这张图的口径，Auto 多出的约 0.02 美元换来约 1.5 分提升。它说明高档位并非免费提高质量，而是把更多计算投入检索流程后，得到幅度有限的额外收益。
这组每任务成本不能和 API 的每千次请求标价直接互换。Exa Lite 标价为每千次请求 4 美元，Auto 为 7 美元，报道列出的 Perplexity、Brave 和 Parallel 则是每千次请求 5 美元。任务可能包含多轮搜索，调用量和结果用法也会不同，所以团队应分别记录请求成本与完整 Agent 任务成本。否则，单看一次 API 调用便宜，可能掩盖了多轮搜索或上下文处理带来的总账单。
Highlights把检索从找页面推向组织证据
Dynamic Highlights 改变的是结果如何进入 Agent 的上下文。Exa 称，它不是逐页独立抽取片段，而是在所有搜索结果之间挑选内容，把更多 token 分给更有用的页面，并删除重复信息。Exa 报告称，相比传入完整网页文本，Highlights 可少用 95% 的 token，同时改善答案质量，而且不额外收费。这些是厂商公布的结果，不能直接推定每种查询都能获得相同节省或质量提升。
不过，这个机制瞄准的问题很实际：搜索找到网页，并不等于 Agent 获得了可用证据。完整页面会占据上下文预算，而逐页抽取也可能把相似信息重复带入模型。跨结果分配摘要空间，试图让检索系统承担一部分筛选与去重工作。对构建 Agent 的团队，值得测的不只是答案是否正确，还包括传入了多少文本、证据是否覆盖不同来源，以及节省的上下文成本有没有被额外搜索轮次抵消。
八项领先，数字背后的差距并不均匀
Exa 称 Auto 在八项基准中都排第一，但测试由 Exa 自行运行。比较对象是 Exa 3.0 Auto、Perplexity Web、Brave LLM Context 和 Parallel Advanced，使用同一套 GPT-6 Luna Agent 测试流程，最多进行 25 轮搜索、每轮取 10 条结果，评测时间为 2026 年 10 月。这种统一流程有助于在该设置内比较端点，却不能替代独立机构复测，也不能证明换一个 Agent 或查询集仍会得到相同结果。
具体分差需要和“八项第一”一起读。BrowseComp 为 Exa 91.8%、Perplexity 91.5%，只差 0.3 个百分点；DSQA 为 88.2% 对 87.6%，WideSearch 为 56.1% 对 Brave 的 54.8%。差距较大的项目包括 ATLAS，Exa 为 42.0%、Perplexity 为 37.2%，以及 WebCode，Exa 为 75.5%、Perplexity 为 69.9%。另外，FinSearchComp 为 Exa 68.0%、Parallel 66.0%；Company FindAll 的平均实体数为 15.4 对 14.2，People FindAll 为 7.6 对 6.8。ATLAS 由 Exa 发布，因此尤其需要独立评测来确认它能否代表更广泛的检索能力。
索引扩张与托管边界，决定了适用范围
Exa 表示，3.0 使用自有爬虫和独立索引，而不是包装 Google 或 Bing 的结果。公司称索引跟踪超过 2 万亿个 URL、可服务 1000 亿个网页，并新增商品、本地商家、航班、活动、体育和天气等数据。官方列出的细项包括约 12.7 亿条商品信息和超过 2.11 亿个本地商家。这些规模数字说明 Exa 正把搜索拓展为面向个人助理的资料入口，但规模本身不能说明具体条目的新鲜度、准确性或覆盖盲区。
部署与集成也有明确边界。Exa 目前只提供托管 API，没有自托管选项，embedding 模型的参数规模和架构也未披露。Lite 与 Auto 共享索引，但 Lite 对不支持的参数会返回指出字段的 400 错误，因此从其他搜索类型迁移时，需要核对请求参数和失败处理。更稳妥的做法是用自有查询集，在同一 Agent 流程里分别比较 Lite、Auto 和现有服务，记录准确率、延迟、每任务成本及数据新鲜度，再决定哪些查询值得使用更重的 Auto。若工作负载或数据治理要求托管之外的控制，当前版本的部署方式也可能直接不合适。