原文：Add a Specialized Deep Research Skill to Agent Harnesses · NVIDIA Technical Blog · 2026-05-20 作者：William Markito Oliveira（NVIDIA 企业 AI Agents 产品负责人）、Isabel Hulseman（产品营销经理）
引言：Harness 不擅长的那件事
过去一年，Claude Code、Codex、OpenCode 这类 agent harness 几乎成了「AI 工程师标配」。它们擅长编排、UI、上下文管理——但凡你让它们做一件真正意义上的「研究」，比如「读完这 47 份合同后告诉我哪几条续约风险最高」「跨产线汇总过去三个月的故障根因」，就会反复撞到同一堵墙。
NVIDIA 在 5 月 20 日发的这篇博客，给出的解法不是「再训一个更聪明的 agent」，而是把整条研究流水线抽出来，做成一个可被任意 harness「委托调用」的 Skill：AI-Q Deep Research Skill。
听上去像又一个集成包，但它实际上隐含了一个反主流的判断：研究质量是独立的工程问题，不应该是编排能力的副产品。本文就沿着这个判断展开，拆它的四阶段流水线、三种认证模式、数据治理反转，以及一个最容易被忽视但极其重要的「frontier 模型开关」。
一、为什么 Harness 亲自做研究会塌房
NVIDIA 把这个问题讲得比较克制——「general-purpose agents can do research, but results may be inconsistent」。但放到任何在企业内部跑过 RAG 或 Agent 的人面前，这种「inconsistent」翻译成中文就是四种具体故障：
多源结果不一致。同一个问题，今天问得到 A 答案，明天问得到 B 答案。原因是 harness 把检索、综合、判定都丢给同一段松散的循环，每一次跑的状态机不一样。
引文链路缺失。你拿到一段结论，但无法回答「这话出自哪份文件的哪一段」。在金融、法务、合规场景里，这条等同于直接不可用。
长周期规划崩坏。十几步以上的研究链路，harness 容易在中途丢掉最初的目标——你以为它在帮你查 Q3 季度数据，它跑着跑着去翻 Q2 了。
敏感数据外泄风险。要让 harness 直接接入企业数据，意味着 harness 进程本身要持有数据 token。一旦这个 harness 是云端托管的，治理团队基本会一票否决。
这四条不是某个 harness 的 bug，而是「让一个为编排设计的通用 agent 顺手做研究」这件事本身的结构性问题。NVIDIA 给的方案是：别让 harness 做。把研究委托给一个专门的后端。
二、AI-Q 到底是什么：一个可移植的「研究后端」
形式上 AI-Q Deep Research Skill 极简——一个目录，两个文件：
SKILL.md：告诉 harness「我是谁、能做什么、怎么调」scripts/aiq.py：辅助脚本，负责把任务提交到 AI-Q 服务器、轮询、拉结果
仓库路径是 .agents/skills/aiq-research/，默认连接 http://localhost:8000，可以用 AIQ_SERVER_URL 覆盖。安装方式就是软链或拷贝到对应 harness 的 skills 目录：
Claude Code: ~/.claude/skills/ 或项目内 .claude/skills/
Codex: harness 配置指向的 skills 目录
OpenCode: ~/.config/opencode/skills/
技术上没什么稀奇，重点是它代表的产品姿态：AI-Q 不与 Claude Code 竞争，也不试图取代 harness 的编排能力。它只解决一件事——当 harness 收到「这个任务需要做研究」的判断后，把整个研究任务作为一个异步 job 扔给 AI-Q，等它出报告。
这是一种典型的「关注点分离」：harness 决定「问什么」，AI-Q 决定「怎么研究」，数据决定「在哪研究」。三方解耦后，每一方都可以独立演进、独立评测、独立扩缩容。
三、四阶段研究流水线：为什么要拆这么细
AI-Q 的核心是一条专门为研究设计的流水线，分四阶段：
① Intent Classifier · 别拿大炮打蚊子
最先跑的是意图分类器，判断这个问题「需要多深」。一句「我们公司的 PTO 政策是几天」根本不需要走 deep research——查一次 Wiki 就够了；而「过去 5 年我们在亚太地区的合规事件有什么共性」必须深挖。
这一步的工程价值在于避免把所有问题都送进最贵的链路。Deep Researcher 用的是 Nemotron 推理模型 + 跨源综合，单次任务可能消耗几分钟和大量 token；让 Intent Classifier 在入口处筛掉 60–80% 的浅查询，是流水线能跑得起的前提。
② Clarifier · 检索前消除歧义
第二阶段是「人机澄清」环节。注意它的位置——在检索开始之前，而不是给完答案让用户挑错。
这是一个很容易被忽视的设计取舍。绝大多数「让用户澄清」的 agent 实现是写完一稿之后请用户改，本质上是把澄清成本推给读完答案的人。AI-Q 反过来：先确认问题边界，再花算力。对 deep research 这种动辄分钟级的任务，把「跑错方向 5 分钟」前置成「问 1 个澄清问题」是值回票价的。
③ Shallow Researcher · 给浅查询留快车道
范围明确、可以几秒返回的查询走这一支。它存在的意义不是性能优化，而是质量隔离——浅查询的失败模式（关键词没命中）和深研究的失败模式（综合判断错）完全不同，混在一条链路里调优会顾此失彼。
④ Deep Researcher · 长周期综合的主战场
这才是 AI-Q 的招牌：跨企业数据源、长周期、多文档综合，Nemotron 推理模型负责规划与综合。输出是带引文的结构化报告，附带每段结论的 source attribution。
这四个阶段「独立调优、独立评测」的工程价值，比阶段本身重要。FreshQA、Deep Research Bench、DeepSearchQA 三个公开基准可以分别针对不同阶段打分；合规收紧时可以单独关掉 Deep 阶段对 frontier model 的路由，而不影响 Shallow 浅查体验。这种「可分别下电」的能力，是端到端黑盒 agent 拿不到的。
四、MCP 三种认证模式：决定治理边界
AI-Q 通过 MCP（Model Context Protocol）function group 接入企业数据源。听起来标准，但到底用谁的身份去查数据，决定了完全不同的治理边界。
模式 A：mcp_client 直连
适合：MCP 服务器本身就不要求用户认证，比如内网开放的搜索、公共文档。
特点是上手最快，但不要在任何含 PII、客户数据的源上用——AI-Q 直接「裸连」MCP，等于把鉴权下推到 MCP 服务器自己。
注意一个生产细节：MCP 推荐用 streamable-http 传输，受保护的 MCP 服务器必须用这个。
模式 B：mcp_client + mcp_service_account
这是生产场景的首选。AI-Q 用一个服务账号去查 MCP，身份是「这个研究服务」而不是「某个用户」。
它的两个隐性好处：长任务不会因为用户 token 过期而中断；审计在 service account 维度聚合，运维团队能拿到清楚的「谁/什么时候/为什么访问了这份数据」。CI、批处理、共享数据集场景几乎只能选它。
模式 C：自定义 AIQ 工具 + get_auth_token()
这是行级权限场景的解法——下游 API 信任 AIQ 用户的 bearer token，每个用户「以自己的身份」查自己的项目数据。
但这里有一个必须知道的当前限制：用户身份在 Dask 异步 worker 中是保留的，但 token 不会在任务中途刷新。NVIDIA 说下个版本会支持，目前你要做的是——如果一个研究任务可能超过 token 有效期，要么换用模式 B，要么把任务拆短。
决策清单（直接抄）
- 实验/原型/无认证数据源 → 模式 A
- 生产/CI/批处理/共享数据 → 模式 B（默认首选）
- 行级权限/「以本人身份查我的数据」→ 模式 C，但注意短任务化
五、数据治理反转：少给权限，结果更扎实
这是整篇文章最容易被忽略、但工程价值最高的部分。
传统思路是：要让 agent 答得准，就得让 agent 看到所有原始数据。AI-Q 反过来：harness 越远离原始数据，反而越能拿到扎实结果。
为什么？因为：
- harness 不持有数据 token → 治理审计大幅简化，云端 harness 也能合规接入企业数据；
- harness 看到的是带引文的结构化报告 → 它没有自己「重新综合」的机会，自然不会产生幻觉式答案；
- AI-Q 在受控环境（本地、企业 K8s、甚至 air-gapped 数据中心）做检索与综合 → 数据从不离开企业边界；
- OpenTelemetry trace 与 source attribution 是默认开启的 → 合规可审计性是流水线原生属性，不是事后补丁。
这套模式对应的部署形态也是「就地展开」：Docker Compose 跑笔记本验证，Helm chart 上 K8s，整张 Blueprint 已经在 Dell AI Factory（Dell-NVIDIA AI-Q 2.0 Reference Architecture）上跑通了金融、公共部门、制造业场景。
工程化的判断是：敏感数据场景不要让 harness 直连任何东西。让 AI-Q 站在数据这一侧，harness 站在用户这一侧，两侧只通过结构化报告通信。
六、模型策略：Frontier 是开关，不是必选
很多人没注意到原文里这段话的分量——AI-Q 采用「混合模型」策略：
- Nemotron 推理模型：负责规划与综合（默认主力）
- Frontier-model router：可配置，处理需要额外能力的任务
- 完全禁用 frontier model：合规严格的场景一键开关
把这三档放到一起读，就能看出 NVIDIA 给合规团队设计的「开关」是真的可拨：
- 默认走自托管的 Nemotron（可作为 NVIDIA NIM 在本地部署），数据全在域内；
- 需要更强能力时启用 frontier router，但这部分流量是 AI-Q 显式路由出去的，可观察、可审计；
- 严合规场景（金融核心、政府、医疗）直接关掉 frontier 路由，整套流水线变成「全自托管」。
这跟主流「agent 必须配上最强 frontier 模型」的叙事是反着的。AI-Q 押注的是：研究质量来自流水线设计（清晰的阶段、好的检索、可靠的综合），而不是来自更大的模型。这给了合规团队一个真正可用的「降级路径」，而不是「不用就废」。
七、给开发者的落地清单
如果你现在就要给手上的 harness 加研究能力，按这几步走：
- 先起服务器：拉 NVIDIA-AI-Blueprints/aiq v2.1.0，Docker Compose 跑本地验证，Helm chart 上 K8s。先决条件：Python 3.10+。
- 接数据源：通过 MCP function group 把现有 Wiki、数仓、CRM 接进来；优先用 service account 模式（模式 B）。
- 装 Skill：把
.agents/skills/aiq-research/拷或软链到你 harness 的 skills 目录。 - 跑评测：用流水线带的评测工具，在自己数据上跑 FreshQA / Deep Research Bench / DeepSearchQA，建立基线。
- 决定 frontier 策略：合规宽松场景留 frontier router 开着，严合规场景直接关掉，全走 Nemotron。
- 观察长任务：如果用模式 C（用户身份），监控有没有任务因 token 过期失败；目前没有中途刷新机制，下一个版本可能会补。
总结：三条带走的判断
回到开头那个反主流的判断：研究质量是独立的工程问题，不应该是编排能力的副产品。
如果你下次给 harness 加研究能力时只能记住三件事，让它们是：
- 委托 ≠ 拥有——harness 别在内部手写检索循环，把研究当成一个独立后端调用；
- 数据治理反转——少给 harness 权限，反而能拿到更扎实的结果，因为 harness 没机会自己「重新综合」；
- Frontier 是开关——别假设一切场景都需要最强模型，给合规团队一个真正可用的降级路径。
AI-Q 不是一个新模型、也不是一个新 harness。它是一个关于「研究该由谁做」的产品判断——把这件事从 harness 的能力清单里拿出来，做成可独立演进、可独立审计、可本地部署的服务。这个判断本身，比它选择的任何技术栈细节都更值得借鉴。
参考资源
- 原文：Add a Specialized Deep Research Skill to Agent Harnesses
- GitHub: NVIDIA-AI-Blueprints/aiq (v2.1.0)
- AI-Q Blueprint 文档：docs.nvidia.com/aiq-blueprint/2.0.0
- Dell-NVIDIA 参考架构：infohub.delltechnologies.com
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
