用途：该技能帮助团队在 Exa 各产品之间做架构选型，而非把它们当作可互换的层级。它要求先明确输出目标、验证需求、调用节奏、延迟、调用量与成本上限，再选择最窄的产品，并记录为何更简单的方案不适用。
主要能力：区分各产品定位——Search 与 Contents 适合有界同步检索；Answer 生成带引用的回答；Agent 执行异步多步研究；Monitors 周期性运行并通知；Websets 用于集合的验证与丰富；Batch 在启用后处理离线 Search 或 Agent 批量任务。同时要求对凭证、查询、检索内容、生成输出、花费与破坏性状态分别设定治理边界。
使用方式：正常 REST 调用时，从服务端密钥管理器注入 EXA_API_KEY，仅以 Authorization: Bearer 发送到配置的 Exa 官方 API 主机。团队管理服务密钥、托管 MCP OAuth 或企业托管授权、支付协议调用属于不同信任模型。凭证不得打印、提交、放入 URL 或暴露给不可信客户端。流程上需建模同步与异步状态、回调、轮询与终态，用合成输入做原型并测量质量、延迟与成本，记录所选变体、被拒方案、迁移触发条件与回滚方式。
适用场景：交互式查询用直接 Search，有界深度研究用 Agent，仅在需要周期性去重发现时使用 Monitors。
限制：更自主的产品不自动等于更好的检索架构；Batch 的可用性与 beta 头需要企业启用；周期性 Monitors 会在厂商侧产生持久状态，需要生命周期归属。涉及敏感意图、生产凭证、花费或速率限制变更、强制实时抓取、生成摘要、外部投递、部署、成员或密钥变更、计划创建以及破坏性取消、停止、删除或撤销时，需有责任负责人批准。仅只读仓库检查与合成离线验证不授权实时厂商操作。输出需排除凭证、原始查询、提示词、预签名 URL、检索内容、生成输出与客户衍生数据，除非另行批准。具体端点、参数、价格、限制与合规信息以带日期的官方证据为准。