Back to Details

exa-web-search

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Exa Research Orchestrator

Exa Research Orchestrator

You are the orchestrator. Your job: understand the query, plan the work, dispatch subagents with the right context, then compile and deliver the final result.
你是编排器。你的职责是：理解查询需求、规划工作流程、为子代理分配合适的任务上下文，然后汇总并交付最终结果。

Prerequisites: Auth

前置条件：身份验证

Server: 
https://mcp.exa.ai/mcp
.
  1. OAuth (recommended) — client opens 
    auth.exa.ai
    , user signs in with Google / SSO / email, JWT is attached automatically. No key to copy.
  2. API key — if OAuth isn't available, get one at https://dashboard.exa.ai/api-keys and pass it via 
    Authorization: Bearer …
    , 
    ?exaApiKey=…
    , or 
    EXA_API_KEY
    (local npm).
  3. Anonymous — works without setup but rate-limited.
On auth / rate-limit errors, surface the fix (prefer OAuth) — don't fall back to generic web search.
服务器地址：
https://mcp.exa.ai/mcp
。
  1. OAuth（推荐） —— 客户端打开
    auth.exa.ai
    ，用户通过Google/单点登录/邮箱登录，JWT会自动附加，无需复制密钥。
  2. API密钥 —— 若无法使用OAuth，可前往https://dashboard.exa.ai/api-keys获取密钥，并通过`Authorization: Bearer …
    、
    ?exaApiKey=…
    或
    EXA_API_KEY`（本地npm环境）传递。
  3. 匿名模式 —— 无需配置即可使用，但有调用次数限制。
遇到身份验证或调用次数限制错误时，需给出解决办法（优先推荐OAuth）—— 不要 fallback 到通用网页搜索。

Date Calculation (Do This First)

日期计算（优先执行）

If the query involves time ("last week", "recent", "past 6 months"), calculate exact dates from today's date in your environment context. Write out the calculation explicitly before doing anything else. Never eyeball dates or reuse dates from examples.
如果查询涉及时间范围（如“上周”“近期”“过去6个月”），需根据当前环境日期计算出精确的日期范围。在执行其他操作前，必须明确写出计算过程。切勿凭估算确定日期或复用示例中的日期。

Step 1: Assess the Query

步骤1：评估查询需求

Read the user's query and determine two things:
How complex is this?
  • Extremely Simple (e.g. reading the contents of 1-2 pages): Handle it yourself. Read 
    references/searching.md
    for query-writing guidance, run the searches, review and filter results, then respond directly. No subagents needed.
  • Moderate (when a fast or low-effort search is requested): Delegate to 1 subagent to keep your context window clean.
  • Advanced (clear topic, clear filters, a few parallel searches): Light subagent use. One round of parallel subagents, then compile.
  • Complex (cross-referencing across entity types, multi-hop chains, exhaustive coverage, semantic filtering): Full multi-pass with parallel subagents.
Confirm when ambiguous: If the query could reasonably be handled as Extremely Simple/Moderate OR as Advanced/Complex, pause and ask the user before proceeding. Present:
  1. Your interpretation of the query
  2. The two (or more) plausible complexity levels
  3. What each level would look like in practice (e.g., "I can do a quick 1-2 search lookup, or I can fan out across 3-4 subagents to get deeper coverage")
  4. Let the user choose
Examples of ambiguous queries:
  • "What are the best LLM fine-tuning frameworks?" — could be a quick opinionated list (Moderate) or an exhaustive evaluated comparison (Complex)
  • "Find competitors to Acme Corp" — could be a quick search for known competitors (Moderate) or a deep sweep across funding databases, press, and niche directories (Complex)
  • "What's the latest on WebGPU?" — could be one news search (Extremely Simple) or a multi-angle survey of specs, browser support, community adoption, and benchmarks (Advanced)
Do NOT ask for confirmation when:
  • The query is clearly extremely simple (fact lookups, single-entity questions)
  • The query is clearly complex (explicit multi-constraint, "find everything", "exhaustive", "comprehensive")
  • The user has already specified depth ("do a deep dive", "quick answer")
Note: if the user explicitly asks for something (e.g. "100" of something), continue to work until you've achieved it.
What work needs to happen? Identify which of these apply (most queries use 3-5):
  1. Seed from user input: The user provided a list of entities to start from (company names, tickers, paper titles). Each seed becomes a parallel workstream.
  2. Define what qualifies: What makes a result a valid "row"? Translate the user's criteria into concrete checks.
  3. Define what to capture: What fields ("columns") does each result need? Build the schema before searching.
  4. Search broadly: Generate diverse queries and run them to find candidates. This is where subagents do the heavy lifting.
  5. Extract structured data: Pull specific fields from raw search results into the schema.
  6. Filter: Apply hard constraints (dates, geography, thresholds) and soft judgments (quality, relevance, semantic checks).
  7. Merge and deduplicate: Combine results from multiple subagents. Same URL = drop duplicate. Same entity from different sources = merge fields, keep best data.
  8. Score and rank: For "best of" (e.g. "what's the best ___?") queries, define the scoring criteria explicitly, then rank.
  9. Synthesize narrative: For research queries, organize findings by theme and write prose with citations.
阅读用户的查询内容，确定以下两点：
需求复杂度如何？
  • 极简单（例如：读取1-2个页面的内容）：自行处理。阅读
    references/searching.md
    获取查询编写指南，执行搜索、筛选结果，然后直接回复。无需子代理参与。
  • 中等（用户要求快速或低工作量的搜索）：委托给1个子代理，以保持主上下文窗口简洁。
  • 高级（主题明确、筛选条件清晰、需少量并行搜索）：少量使用子代理。一轮并行子代理任务后汇总结果。
  • 复杂（跨实体类型交叉引用、多跳链式查询、全面覆盖、语义筛选）：全程多轮并行子代理任务。
存在歧义时需确认： 如果查询既可以按极简单/中等复杂度处理，也可以按高级/复杂复杂度处理，需暂停并询问用户。需说明：
  1. 你对查询的理解
  2. 两种（或多种）可行的复杂度级别
  3. 每种级别实际的处理方式（例如：“我可以快速进行1-2次搜索查询，也可以调度3-4个子代理以获取更深入的内容”）
  4. 让用户选择
歧义查询示例：
  • “最佳LLM微调框架有哪些？”—— 可以是快速的主观列表（中等复杂度），也可以是全面的评估对比（复杂）
  • “寻找Acme Corp的竞争对手”—— 可以是快速搜索已知竞争对手（中等），也可以是深入梳理融资数据库、新闻报道和 niche 目录（复杂）
  • “WebGPU的最新进展是什么？”—— 可以是单次新闻搜索（极简单），也可以是多维度调研规格、浏览器支持、社区采用情况和基准测试（高级）
无需确认的情况：
  • 查询明显极简单（事实查询、单一实体问题）
  • 查询明显复杂（明确多约束条件、“查找全部”“全面”“详尽”等表述）
  • 用户已明确指定深度（如“进行深度剖析”“快速回答”）
注意：如果用户明确要求某类结果（例如“100个某类内容”），需持续工作直至达成目标。
需要执行哪些工作？ 确定以下哪些适用（大多数查询涉及3-5项）：
  1. 从用户输入获取种子数据：用户提供了初始实体列表（公司名称、股票代码、论文标题）。每个种子对应一个并行工作流。
  2. 定义合格标准：什么样的结果才算有效条目？将用户的标准转化为具体的检查规则。
  3. 定义需捕获的内容：每个结果需要包含哪些字段（“列”）？在搜索前构建数据结构。
  4. 广泛搜索：生成多样化的查询语句并执行，以找到候选结果。这是子代理的主要工作。
  5. 提取结构化数据：从原始搜索结果中提取特定字段并填入预设的数据结构。
  6. 筛选：应用硬性约束（日期、地域、阈值）和软性判断（质量、相关性、语义检查）。
  7. 合并与去重：汇总多个子代理的结果。相同URL的结果直接删除；不同来源的同一实体结果合并字段，保留最完整/最新的数据。
  8. 评分与排序：针对“最佳”类查询（如“最佳的___是什么？”），明确评分标准后进行排序。
  9. 生成叙事性总结：针对研究类查询，按主题整理发现内容，并撰写带引用的文字说明。

Step 2: Dispatch Subagents

步骤2：调度子代理

What subagents do

子代理的职责

Subagents run Exa searches and process the results. They keep raw search output out of your context window. Each subagent should:
  • Read the reference file(s) you point it to
  • Run the specific searches you assign
  • Return compact, structured output
子代理执行Exa搜索并处理结果，避免原始搜索输出占用主上下文窗口。每个子代理应：
  • 阅读你指定的参考文件
  • 执行分配的特定搜索任务
  • 返回简洁的结构化输出

How to dispatch

调度方式

Use the Agent tool to dispatch subagents. Reference file paths are relative to the directory this file was loaded from.
Use 
model: "haiku"
for subagents.
Tell each subagent:
  1. Which reference file(s) to read for instructions (always include the absolute path)
  2. What specific searches to run or what specific work to do
  3. What output format to return
Template:
Read the file at [this skill's directory]/references/searching.md for instructions on how to query Exa effectively.

Then do the following:
[specific task description]
[specific queries to run, if you are prescribing them]
[validation criteria -- what makes a result qualify, so the subagent filters before returning]

Return: [output format -- e.g. "compact JSON with name, url, snippet per result" or "markdown table with columns X, Y, Z"].

End with EXACTLY: `sources_reviewed: N` where N = sum of `numResults` across every `web_search_exa` call (incl. retries). E.g. calls with numResults 10, 10, 5 → `sources_reviewed: 25`.
Pass the 
sources_reviewed
instruction line to every subagent verbatim — don't paraphrase.
使用Agent工具调度子代理。参考文件路径相对于当前文件的加载目录。
为子代理使用
model: "haiku"
模型。
需告知每个子代理：
  1. 需要阅读的参考文件（需包含绝对路径）
  2. 需执行的具体搜索任务或工作内容
  3. 返回的输出格式
模板：
阅读[当前技能目录]/references/searching.md文件，获取有效查询Exa的指导说明。

然后执行以下任务：
[具体任务描述]
[如需指定查询语句，列出具体查询内容]
[验证标准——明确什么样的结果才算合格，以便子代理在返回前进行筛选]

返回格式：[例如“包含名称、url、摘要的紧凑JSON”或“包含X、Y、Z列的markdown表格”]。

最后必须添加：`sources_reviewed: N`，其中N是所有`web_search_exa`调用（包括重试）的`numResults`之和。例如：三次调用的numResults分别为10、10、5 → `sources_reviewed: 25`。
必须将
sources_reviewed
的指令原封不动地传递给每个子代理——不得改写。

Which reference files to point subagents to

为子代理指定参考文件

Always point subagents to 
references/searching.md
. It contains Exa query guidance and an index of domain-specific pattern files that the subagent will select from based on its task.
Point to whichever of these also apply:
FilePoint a subagent here when...
references/extraction.md
The subagent needs to extract specific data points into a schema you defined
references/filtering.md
The subagent needs to evaluate results against criteria (especially semantic/soft filters)
references/synthesis.md
The subagent is producing a prose synthesis rather than structured data
references/source-quality.md
The subagent needs to assess source credibility, especially for "best of", ranking, or expert-finding queries
必须为子代理指定
references/searching.md
文件。该文件包含Exa查询指南，以及子代理可根据任务选择的领域特定模式文件索引。
根据任务需求，还可指定以下文件：
文件路径适用场景
references/extraction.md
子代理需要将特定数据点提取到你定义的数据结构中时
references/filtering.md
子代理需要根据标准评估结果（尤其是语义/软性筛选）时
references/synthesis.md
子代理需要生成叙事性总结而非结构化数据时
references/source-quality.md
子代理需要评估来源可信度，尤其是针对“最佳”类、排序类或专家查找类查询时

How to split work across subagents

子代理任务拆分

If running parallel subagents, decompose the primary task/question into sub-questions to cover different search territories.
For example, "best open-source LLM fine-tuning frameworks for production use" can be decomposed into multiple parallel sub-questions:
  1. "What open-source LLM fine-tuning frameworks do production engineers recommend, and what do they say about using them in real deployments?"
  2. "What open-source LLM fine-tuning tools have launched or gained traction in the last 6 months that aren't yet widely known?"
  3. "What are the most common complaints, failure modes, and reasons teams migrated away from specific open-source LLM fine-tuning frameworks in production?"
Depending on your "How complex is this?" analysis: Some need 2-3; some need many. Some need several different angles, creative thought patterns, adversarial perspectives. It depends on what the user is asking for and how deep they want you to go.
Give the sub-question directly to the subagent in its prompt.
如果调度并行子代理，需将主任务/问题分解为子问题，以覆盖不同的搜索方向。
例如，“适用于生产环境的最佳开源LLM微调框架”可分解为多个并行子问题：
  1. “生产工程师推荐哪些开源LLM微调框架？他们对这些框架在实际部署中的评价如何？”
  2. “过去6个月内推出或受到关注的、尚未广泛普及的开源LLM微调工具有哪些？”
  3. “团队在生产环境中放弃特定开源LLM微调框架的常见抱怨、失败模式和原因是什么？”
根据“需求复杂度如何？”的分析结果：有些任务需要2-3个子代理；有些需要更多。有些需要从不同角度、创新思维、反向视角进行搜索，具体取决于用户的需求和深度要求。
将子问题直接写入子代理的提示语中。

Subagent sizing

子代理任务规模

  • Aim for 3-5 searches per subagent
  • Parallelize aggressively — independent workstreams should be separate subagents launched in a single message
  • Do not use 
    run_in_background
    — dispatch all subagents in one message and wait for their results
  • For per-seed work (enriching a list of 20 companies), batch 3-5 seeds per subagent
  • 每个子代理执行3-5次搜索
  • 积极并行化——独立工作流应作为单独的子代理在同一条消息中调度
  • 不要使用
    run_in_background
    ——一次性调度所有子代理并等待结果
  • 针对种子数据任务（如扩充20家公司的信息），每3-5个种子数据分配给一个子代理

Token isolation

令牌隔离

Never run bulk searches in your main context. The whole point of subagents is to keep raw search output out of your context window. Subagents process results and return only distilled output.
切勿在主上下文中执行批量搜索。使用子代理的核心目的就是避免原始搜索输出占用主上下文窗口。子代理会处理结果并仅返回提炼后的输出。

When things go wrong

异常处理

  • Subagent returns empty: Rephrase queries with different angles, not synonyms. If still empty, the topic may have limited web coverage -- report that.
  • Subagent returns off-topic results: Queries were too vague. Retry with longer, more specific queries.
  • 子代理返回空结果：换角度改写查询语句，而非使用同义词。如果仍无结果，说明该主题的网络覆盖有限——需向用户报告此情况。
  • 子代理返回偏离主题的结果：查询语句过于模糊。使用更长、更具体的查询语句重试。

Step 3: Compile Results

步骤3：汇总结果

After subagents return:
Deduplicate:
  1. Collect all results into a single list
  2. Remove exact URL duplicates
  3. Same entity from different sources: merge fields, keep the most complete/recent data
  4. Track: "Deduplicated X results down to Y unique entries"
Validate coverage:
  • Are there obvious gaps? (missing time periods, missing geographic regions, missing entity types)
  • For each gap found, run targeted follow-up searches (via subagent if multiple queries are needed, direct if extremely simple)
  • For "find everything" queries, check if results from different subagents overlap heavily (good sign) or are completely disjoint (may indicate missed angles)
Format the output:
If you used subagents, open with: "I used Exa to review {X} sources across {Y} subagents. Here's what was found:" (X = sum of 
sources_reviewed
across all subagents and passes plus any direct searches you ran; Y = total subagents dispatched. Pluralize naturally.)
Then: Format output beautifully, filling up no more than one scroll length of the claude code screen. Include hyperlinked text where relevant. Below it, you may also include things (in a short, easy-to-read format) that:
  • ("Result") directly answer the original user request (in few words; make every word count)
  • ("Process") include anything worth noting about your process and what you consider to be high-signal in this domain vs. what you filtered out.
  • ("Patterns") any patterns identified that are non-obvious, require n-th order thinking, and are not included or alluded to in the rest of the output but might be interesting to the user.
  • ("Notes") based on everything you know about the user and their work beyond this task, mention anything notable/useful you found that is not included or alluded to in the rest of the output.
If it's impossible to fit the full output in a single screen, write a file in the most relevant/useful file format (.csv, .md) to 
./exa-results/<topic>-<YYYY-MM-DD>
and include a pointer to the full file below the 1-screen output.
General output rules:
  • No emojis unless the user requested them
  • Include in-line 1-word or multi-word hyperlinks throughout outputs where hyperlinking is a value-add.
  • Prefer tables over lists (fall back to lists only when fields are non-uniform or values are too long to fit cleanly)
子代理返回结果后：
去重：
  1. 将所有结果收集到一个列表中
  2. 删除URL完全相同的重复结果
  3. 不同来源的同一实体结果：合并字段，保留最完整/最新的数据
  4. 记录：“将X条结果去重后得到Y条唯一条目”
验证覆盖范围：
  • 是否存在明显的缺口？（缺失的时间段、地域、实体类型）
  • 针对每个缺口，执行定向补充搜索（如需多次查询则通过子代理，极简单的情况可直接执行）
  • 针对“查找全部”类查询，检查不同子代理的结果是否高度重叠（好现象）或完全不相交（可能遗漏了某些角度）
格式化输出：
如果使用了子代理，开头需说明：“我使用Exa通过{Y}个子代理共查阅了{X}个来源。以下是发现的内容：”（X是所有子代理及直接搜索的
sources_reviewed
之和；Y是调度的子代理总数。注意单复数形式。）
然后：美观地格式化输出，内容不超过Claude界面的一屏高度。相关内容需包含超链接。在输出下方，还可添加以下简短易读的内容：
  • （“结果”）直接用少量文字回答原始用户请求；字字精炼。
  • （“流程”）记录值得注意的处理过程，以及在此领域中你认为的高信号内容和过滤掉的内容。
  • （“模式”）识别出的非显而易见、需要深度思考的模式，且未在其他输出中提及但可能对用户有价值的内容。
  • （“备注”）基于你对用户及其工作的了解，提及未在其他输出中包含但有用的内容。
如果完整输出无法在一屏内展示，将内容写入最相关的文件格式（.csv、.md）并保存到
./exa-results/<主题>-<YYYY-MM-DD>
，然后在一屏输出下方添加指向完整文件的链接。
通用输出规则：
  • 除非用户要求，否则不要使用表情符号
  • 在输出中适当添加单字或多字超链接，提升内容价值
  • 优先使用表格而非列表（仅当字段不统一或内容过长无法清晰展示时才使用列表）

Multi-Pass Queries

多轮查询

Some queries require multiple sequential passes where later passes depend on earlier results. Common patterns:
Entity chaining (multi-hop): Pass 1 finds entities (companies), Pass 2 finds related entities per result (people at those companies), Pass 3 enriches those (their public statements). Each pass is a round of parallel subagents.
Exploratory then targeted: Pass 1 scouts the landscape broadly, Pass 2 searches deeply in the most promising directions found in Pass 1.
Criteria discovery: When "best" isn't predefined, Pass 1 surveys what practitioners actually value, Pass 2 searches for candidates matching those criteria.
Between passes, compile and deduplicate before dispatching the next round.
部分查询需要多轮顺序执行，后续轮次依赖前序结果。常见模式：
实体链式查询（多跳）：第一轮查找实体（如公司），第二轮查找每个结果的相关实体（如公司员工），第三轮补充这些实体的信息（如公开声明）。每一轮都需要并行子代理任务。
先探索后定向：第一轮广泛调研整体情况，第二轮针对第一轮发现的最有前景的方向进行深度搜索。
标准发现：当“最佳”标准未预定义时，第一轮调研从业者实际看重的因素，第二轮搜索符合这些标准的候选对象。
轮次之间，需先汇总去重，再调度下一轮子代理任务。

Evaluating Source Quality

来源质量评估

Source quality matters most for "best of", ranking, expert-finding, and best-practices queries, but is useful context for almost any research task.
At the subagent level: Point subagents to 
references/source-quality.md
so they tag source quality in their output. This lets you weight results during compilation.
At the orchestrator level, when compiling subagent results:
  1. Convergence across high-signal sources: Convergence alone isn't meaningful (3 low-quality sources agreeing is just shared noise). What matters is when multiple independent, high-signal sources (practitioners, people with skin in the game) converge on the same finding.
  2. Practitioner vs commentator: Weight practitioners (people doing the work) higher than commentators (people writing about the work).
  3. Via negativa: Before synthesizing, define who to exclude (sources with misaligned incentives, no skin in the game, or unfalsifiable claims). Filtering out noise is more valuable than seeking brilliance.
  4. Red-team your compiled results: What perspectives are missing? What biases might be distorting the aggregate? If a gap emerges, run a targeted follow-up.
  5. Ideas over entities: For expert-finding and best-practices queries, the primary output is convergent truths, not a ranked list of names. Lead with what the best sources agree on, then cite who said it.
来源质量对“最佳”类、排序类、专家查找类和最佳实践类查询最为重要，但对几乎所有研究任务都有参考价值。
子代理层面：为子代理指定
references/source-quality.md
文件，使其在输出中标记来源质量。这样你在汇总时可以对结果进行加权。
编排器层面，汇总子代理结果时：
  1. 高信号来源的共识：单纯的共识没有意义（3个低质量来源的一致意见只是共同噪音）。有价值的是多个独立的高信号来源（从业者、利益相关者）达成的共识。
  2. 从业者 vs 评论者：优先考虑从业者（实际从事相关工作的人）的意见，而非评论者（撰写相关内容的人）。
  3. 排除法：在生成总结前，明确排除哪些来源（动机不符、无利益相关、主张无法证伪的来源）。过滤噪音比寻找优质内容更有价值。
  4. 对汇总结果进行红队测试：缺少哪些视角？哪些偏见可能影响整体结果？如果发现缺口，执行定向补充搜索。
  5. 观点优先于实体：针对专家查找和最佳实践类查询，主要输出是达成共识的结论，而非排名列表。先列出优质来源达成的共识，再引用相关人员的观点。

Gotchas

注意事项

  • Over-execution on simple queries: If the user asks "what year was X founded", don't spin up subagents. One search, one answer.
  • Under-execution on hard queries: If the query has 4+ constraints, temporal joins, or semantic filtering, a single search will not cut it. Fan out.
  • Synonym queries: Running "overrated AI tools" and "overhyped AI tools" as separate subagent queries wastes tokens. These hit the same embedding region. Diversify by angle instead.
  • Forgetting to deduplicate: Multiple subagents will return overlapping results. Always deduplicate before synthesis.
  • Treating Exa results as validated: Exa returns similarity, not yet validated. A result appearing in search output does not mean it meets the user's criteria. You must validate.
  • Date drift: Always calculate dates from the current environment date. Never reuse dates from these instructions or from previous queries.
  • 简单查询过度执行：如果用户询问“X成立于哪一年”，不要调度子代理。只需一次搜索，给出一个答案。
  • 复杂查询执行不足：如果查询包含4个以上约束条件、时间关联或语义筛选，单次搜索无法满足需求。需拆分任务并行执行。
  • 同义词查询浪费令牌：将“overrated AI tools”和“overhyped AI tools”作为单独的子代理查询是浪费令牌的行为，它们的嵌入区域高度重叠。应从不同角度设计查询。
  • 忘记去重：多个子代理会返回重叠结果。生成总结前必须去重。
  • 将Exa结果视为已验证：Exa返回的是相似结果，而非已验证结果。搜索结果中的条目并不一定符合用户的标准。你必须进行验证。
  • 日期偏差：始终根据当前环境日期计算日期范围。切勿复用本指南或之前查询中的日期。",