Back to Details

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.
你是任务协调器。你的职责是：理解用户查询、规划工作流程、向subagents分配带有合适上下文的任务，然后汇总并交付最终结果。

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
    获取查询编写指南，执行搜索、筛选结果，然后直接回复。无需调用subagents。
  • 中等（用户要求快速或低工作量的搜索）：委托给1个subagent处理，以保持你的上下文窗口整洁。
  • 高级（主题明确、筛选条件清晰、需要少量并行搜索）：少量使用subagents。一轮并行subagents任务后，汇总结果。
  • 复杂（跨实体类型交叉引用、多跳链、全面覆盖、语义筛选）：全程多轮并行subagents任务。
存在歧义时请确认： 如果查询既可以按极简单/中等复杂度处理，也可以按高级/复杂复杂度处理，请暂停并询问用户。需说明：
  1. 你对查询的理解
  2. 两种（或多种）可行的复杂度级别
  3. 每种级别实际会执行的操作（例如：“我可以快速进行1-2次搜索查询，也可以调用3-4个subagents进行更深入的覆盖”）
  4. 让用户选择
歧义查询示例：
  • “最佳LLM微调框架有哪些？”——可以是快速的主观列表（中等），也可以是详尽的评估对比（复杂）
  • “查找Acme Corp的竞争对手”——可以是快速搜索已知竞争对手（中等），也可以是深入扫查融资数据库、新闻稿和 niche 目录（复杂）
  • “WebGPU的最新进展是什么？”——可以是单次新闻搜索（极简单），也可以是对规格、浏览器支持、社区采用情况和基准测试的多角度调研（高级）
无需确认的情况：
  • 查询明显极简单（事实查询、单一实体问题）
  • 查询明显复杂（明确多约束条件、“查找全部”“详尽”“全面”等表述）
  • 用户已明确指定深度（如“进行深度调研”“快速回答”）
注意：如果用户明确要求某类结果（例如“100个”），需持续工作直至达成目标。
需要执行哪些工作？ 确定以下哪些适用（大多数查询涉及3-5项）：
  1. 基于用户输入的种子数据：用户提供了初始实体列表（公司名称、股票代码、论文标题）。每个种子对应一个并行工作流。
  2. 定义合格标准：什么样的结果才算有效条目？将用户的标准转化为具体的检查条件。
  3. 定义需捕获的内容：每个结果需要包含哪些字段（“列”）？在搜索前构建数据结构。
  4. 广泛搜索：生成多样化查询并执行，以找到候选结果。这是subagents承担主要工作的环节。
  5. 提取结构化数据：从原始搜索结果中提取特定字段并填入预设的数据结构。
  6. 筛选：应用硬约束（日期、地域、阈值）和软判断（质量、相关性、语义检查）。
  7. 合并与去重：汇总多个subagents的结果。URL完全相同则删除重复项；同一实体来自不同来源则合并字段，保留最完整/最新的数据。
  8. 评分与排名：对于“最佳”类查询（如“最佳___是什么？”），明确定义评分标准，然后进行排名。
  9. 合成叙事内容：对于研究类查询，按主题组织发现结果，并撰写带有引用的散文式内容。

Step 2: Dispatch Subagents

步骤2：调度Subagents

What subagents do

Subagents的职责

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
Subagents执行Exa搜索并处理结果。它们将原始搜索输出排除在你的上下文窗口之外。每个subagent应：
  • 读取你指定的参考文件
  • 执行你分配的特定搜索任务
  • 返回紧凑的结构化输出

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工具调度subagents。参考文件路径相对于加载此文件的目录。
为subagents指定
model: "haiku"
。
告知每个subagent：
  1. 需要读取的参考文件（始终包含绝对路径）
  2. 需执行的特定搜索或具体工作
  3. 返回的输出格式
模板：
读取[此技能目录]/references/searching.md文件，获取有效查询Exa的指导说明。

然后执行以下操作：
[具体任务描述]
[需执行的特定查询（如果已指定）]
[验证标准——什么样的结果才算合格，以便subagent在返回前进行筛选]

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

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

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
始终让subagents指向
references/searching.md
。该文件包含Exa查询指导，以及领域特定模式文件的索引，subagent会根据任务从中选择合适的文件。
根据情况添加以下文件：
文件何时让subagent指向此文件
references/extraction.md
subagent需要将特定数据点提取到你定义的数据结构中时
references/filtering.md
subagent需要根据标准评估结果（尤其是语义/软筛选）时
references/synthesis.md
subagent需要生成散文式合成内容而非结构化数据时
references/source-quality.md
subagent需要评估来源可信度，尤其是“最佳”类、排名类或专家查找类查询时

How to split work across subagents

如何在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.
如果运行并行subagents，将主任务/问题分解为子问题，以覆盖不同的搜索领域。
例如，“适用于生产环境的最佳开源LLM微调框架”可分解为多个并行子问题：
  1. “生产工程师推荐哪些开源LLM微调框架，以及他们对在实际部署中使用这些框架有何评价？”
  2. “过去6个月内推出或受到关注但尚未广泛普及的开源LLM微调工具有哪些？”
  3. “在生产环境中，团队放弃特定开源LLM微调框架最常见的抱怨、失败模式和原因是什么？”
根据“查询复杂度如何？”的分析确定子问题数量：有些需要2-3个；有些需要更多。有些需要多个不同角度、创造性思维模式、对立视角。这取决于用户的需求和调研深度。
将子问题直接写入subagent的提示词中。

Subagent sizing

Subagent规模

  • 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
  • 每个subagent目标执行3-5次搜索
  • 积极并行化——独立工作流应作为单独的subagents在一条消息中调度
  • 不要使用
    run_in_background
    ——在一条消息中调度所有subagents并等待结果
  • 对于基于种子的工作（如丰富20家公司的信息），每3-5个种子分配给一个subagent

Token isolation

Token隔离

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.
切勿在主上下文中执行批量搜索。使用subagents的核心目的是将原始搜索输出排除在你的上下文窗口之外。subagents处理结果并仅返回提炼后的输出。

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.
  • Subagent返回空结果：用不同角度改写查询，而非同义词。如果仍为空，可能该主题的网络覆盖有限——告知用户此情况。
  • Subagent返回偏离主题的结果：查询过于模糊。使用更长、更具体的查询重试。

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)
subagents返回结果后：
去重：
  1. 将所有结果收集到一个列表中
  2. 删除URL完全相同的重复项
  3. 同一实体来自不同来源：合并字段，保留最完整/最新的数据
  4. 记录：“将X个结果去重后得到Y个唯一条目”
验证覆盖范围：
  • 是否存在明显的缺口？（缺失的时间段、地域、实体类型）
  • 对于每个发现的缺口，执行针对性的后续搜索（如果需要多个查询则通过subagent，极简单则直接执行）
  • 对于“查找全部”类查询，检查不同subagents的结果是否大量重叠（好迹象）或完全不相交（可能遗漏了某些角度）
格式化输出：
如果使用了subagents，开头需写：“我使用Exa通过{Y}个subagents共查阅了{X}个来源。以下是发现的内容：”（X是所有subagents和直接搜索的
sources_reviewed
之和；Y是调度的subagents总数。根据单复数自然调整表述。）
然后：美观地格式化输出，内容不超过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.
有些查询需要多轮顺序执行，后续轮次依赖于前一轮的结果。常见模式：
实体链（多跳）：第一轮查找实体（公司），第二轮查找每个结果的相关实体（这些公司的人员），第三轮丰富这些实体的信息（他们的公开声明）。每一轮都需要并行subagents任务。
先探索再针对性搜索：第一轮广泛勘察领域，第二轮针对第一轮发现的最有前景的方向进行深度搜索。
标准发现：当“最佳”标准未预定义时，第一轮调研从业者实际看重的因素，第二轮搜索符合这些标准的候选对象。
轮次之间，先汇总并去重，再调度下一轮任务。

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.
来源质量在“最佳”类、排名类、专家查找类和最佳实践类查询中最为重要，但对几乎所有研究任务都是有用的上下文信息。
在subagent层面： 让subagents指向
references/source-quality.md
，以便它们在输出中标记来源质量。这使你在汇总时可以对结果加权。
在协调器层面，汇总subagents结果时：
  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成立于哪一年”，不要启动subagents。只需一次搜索，给出一个答案。
  • 复杂查询执行不足：如果查询包含4个以上约束条件、时间关联或语义筛选，单次搜索无法满足需求。需扩展搜索范围。
  • 同义词查询：将“overrated AI tools”和“overhyped AI tools”作为单独的subagent查询会浪费token。这些查询的嵌入区域相同。应从不同角度多样化查询。
  • 忘记去重：多个subagents会返回重叠结果。合成前务必去重。
  • 将Exa结果视为已验证：Exa返回的是相似度匹配，而非已验证的结果。搜索结果中出现某条内容并不意味着它符合用户的标准。你必须进行验证。
  • 日期偏差：始终根据当前环境日期计算日期。切勿复用本说明或之前查询中的日期。",