Back to Details

exa-search

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Exa Research Orchestrator

Exa研究编排器

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 / 单点登录(SSO) / 邮箱登录，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. 定义需捕获的字段：每个结果需要包含哪些字段（“列”）？在搜索前先构建数据 schema。
  4. 广泛搜索：生成多样化查询并执行，以找到候选结果。这是子代理的核心工作。
  5. 提取结构化数据：从原始搜索结果中提取特定字段并填入schema。
  6. 筛选：应用硬约束（日期、地域、阈值）和软判断（质量、相关性、语义校验）。
  7. 合并与去重：汇总多个子代理的结果。相同URL的结果直接删除；同一实体来自不同来源的结果，合并字段并保留最完整/最新的数据。
  8. 评分与排序：对于“最佳”类查询（例如“最好的___是什么？”），明确定义评分标准，然后进行排序。
  9. 生成叙事性总结：对于研究类查询，按主题整理发现内容，并撰写带引用的 prose 文本。

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. 返回结果的格式
模板：
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`.
必须将
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
子代理需要将特定数据点提取到你定义的schema中
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/<topic>-<YYYY-MM-DD>
，并在一屏输出下方包含指向完整文件的链接。
通用输出规则：
  • 除非用户要求，否则不要使用表情符号
  • 在输出中所有适合添加超链接的位置，插入单字或多字的嵌入式超链接。
  • 优先使用表格而非列表（仅当字段不统一或内容过长无法清晰展示时，才 fallback 到列表）

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返回的是相似性结果，而非已验证内容。搜索结果中的条目并不一定符合用户的标准。你必须进行验证。
  • 日期偏差：始终根据当前环境日期计算时间范围。切勿复用本指南或之前查询中的日期。",