研究智能体是什么，以及它不是什么。

这个类别的用法十分宽泛。"AI 研究"可以指任何事情，从"对单个 PDF 做摘要"到"花 30 分钟调查一片竞争格局并生成一份带引用来源的 4000 字报告"。这些需要截然不同的架构。本章讨论的是难度更高的那一端：开放式问题、自主多步探索、跨多来源的综合，以及需要经得起推敲的输出。

以下四个属性共同定义了这种形态，使研究智能体有别于 Build、Ship 以及 Specialize 前几章所涵盖的类别。

属性 1：开放式问题与发散式搜索

对话智能体回答一个问题。代码智能体将项目收敛到目标状态。研究智能体则做一件不同的事：它探索。"半导体出口政策有什么动态？"这个问题并没有单一的正确答案可以收敛到。智能体必须自行决定调查哪些方面、从哪些来源取材、在每条线索上深入到什么程度，以及何时停止。对同一问题进行的不同合理运行，可能会呈现不同（但各自有价值）的答案。

这在设计上就是发散式搜索。代码智能体的成功是二值的（测试通过/失败），而研究智能体的成功则处于一个连续的质量空间。代码智能体在工作过程中应当不断缩小范围，而研究智能体在工作过程中往往不断扩展——它发现问题牵涉到最初未曾考虑的角度，沿着早期发现中浮现的线索追踪下去。

这种形态带来了深远影响。智能体无法拥有封闭式的"完成"定义。停止条件成为一个设计问题（见步骤 4）。质量必须用统计方式而非机械方式衡量。智能体的计划必须能够随着学习的深入而修订。

属性 2：须注明来源的输出

研究智能体的输出不只是文本——而是每一项实质性声明都可追溯到来源的文本。研究报告的读者想知道每个事实来自哪里，以便进行核实、深入挖掘或权衡可信度。一个生成了文笔优美的文章却不附来源的研究智能体，其价值低于一个文章不那么精雕细琢却附有来源的智能体。

这一要求改变了智能体运作的一切。在内部，它必须追踪每条声明来自哪个来源，在综合步骤中不遗失这一信息，并在最终输出中保留归因。实践中研究智能体大多数的失败，都发生在这里——智能体做了不错的研究，却在撰写报告时丢失了来源归因；或者将引用捏造到实际上从其他地方获取的声明上；最糟糕的是，完全编造了来源。

引用规范是研究智能体版本的第 4.1 章验证循环。它是将"听起来合理的文本"转化为"人类可以核查的声明"的结构性承诺。步骤 3 将具体介绍如何实现。

属性 3：宽泛的工具面和高频的工具调用（tool use）

对话智能体可能只有 3 个工具。代码智能体有第 4.1 章的 6 个。研究智能体通常有 8–15 个工具，且使用频率极高——Anthropic 的研究系统记录了内嵌于其中的工作量扩展规则："复杂研究问题可能需要 10 个以上的子智能体，每个子智能体发起 10–15 次工具调用"——因此单个用户查询可能在整个系统中涉及数百次工具调用。

这些工具是异构的：网页搜索（通常是多个搜索引擎）、网页抓取、PDF/文档阅读器、用于数据分析的代码执行，有时还包括访问特定数据源的 API（Bloomberg、PubMed、SEC EDGAR），以及越来越多的连接到内部语料库的 MCP 服务器。每个工具都有其自身的故障模式、延迟（latency）特性和成本（cost）。智能体必须做出良好的选择、良好的序列安排，并从所有工具中良好地恢复。

这种广度是研究智能体强大的部分原因，也是它脆弱的部分原因。代码智能体某次工具调用失败，通常会暴露清晰的错误和清晰的下一步。研究智能体某次搜索引擎调用失败，就必须判断：换个搜索引擎？重新表述查询？尝试直接抓取 URL？就此略过？这个决定取决于具体上下文，错误的选择会级联引发更多无效的工具调用。

属性 4：长时运行且成本高昂

宽泛的工具面、高频的工具调用，以及大量累积的上下文窗口（context window）（智能体已读取的每条搜索结果、每个抓取的页面、每段 PDF 摘录）的叠加，使研究智能体成为迄今为止成本最高的智能体类型。Anthropic 公布的数字：在等效听起来的查询上，其研究系统使用的令牌（token）数量约为对话交互的 15 倍。其公开的评估（eval）发现，以 Opus 为主导、Sonnet 为子智能体的多智能体（multi-agent）设置，比单智能体 Opus 的表现高出 90.2%——但这个成本乘数是进入的代价。

其含义是：研究智能体不是免费的，其经济性只有在问题本身值得付出代价时才成立。一次典型的研究运行，单次查询的令牌成本可能在 0.50–3.00 美元之间（相比之下，第 2.2 章中对话轮次的成本是 0.01–0.05 美元）。用户必须愿意等待数分钟而非数秒钟才能得到答案。这些约束是真实存在的，它们决定了研究智能体擅长什么：值得数分钟算力投入的问题，而不是"天气怎么样"。

这些属性所产生的形态

这四个属性共同定义了一个真正独特的类别：

当前产品格局

以 2026 年中期为参照，已发布的研究智能体产品包括：

• Anthropic 的 Research（在 Claude.ai 中）——支持网页 + Google Workspace + 连接器的多智能体研究。自 2025 年中期公开发布，其架构在"How we built our multi-agent research system"工程博客文章中有详细说明。
• OpenAI Deep Research——单智能体（初期）扩展思考研究模式，带浏览工具，面向较长篇幅的综合任务。
• Perplexity Pro Search / Research——以搜索为先的研究，支持多来源聚合。典型运行时间较短，更偏向带引用摘要的形态。
• Google Gemini 中的"Deep Research"——与 OpenAI Deep Research 形态相近。
• 开源框架——GPT Researcher、LangChain 研究智能体、基于 Agent SDK 的自定义实现。

这些产品的趋同令人瞩目：几乎所有产品都采用某种形式的编排者加工作者模式，所有产品都要求引用来源，所有产品都定位于值得数分钟算力投入的问题。步骤 2 中介绍的架构是业界共识设计，并非 Anthropic 的专属特色。

编排者-子智能体架构。

如果你把研究智能体构建为一个拥有众多工具的大型提示词（prompt），你可以让演示跑通，甚至让个别查询也能答得不错。但你得不到的是：在多样化查询规模下的一致性。单智能体设计有特定的弱点，在生产环境中会暴露出来；几乎所有主要研究智能体产品都采用了相同的修复方案：分解为一个主导编排者和一组专业化子智能体。

本步骤解释为什么这种分解能胜出、每个角色的职责，以及证明这一架构合理的成本/质量数学。

单智能体设计的问题

单智能体研究系统中会可靠地出现三种特定的故障模式，在没有分解的情况下很难从工程上绕开：

上下文污染。单智能体在调查一个复杂问题时，会将每条搜索结果、每个抓取的页面、每段 PDF 摘录都累积到一个不断膨胀的上下文窗口中。到第 30 轮时，上下文中充斥着海量大多与当前无关的搜索片段。性能下降——"迷失在中间"问题（第 0.1 章）开始发作，智能体忘记了早期的发现，综合也随之受损，因为相关内容被淹没其中。

串行瓶颈。单智能体必须一次发起一次工具调用，权衡结果，决定下一步，再发起一次调用。即便有并行工具调用（第 0.3 章），结构性决策也是串行的。一次原本可以并行运行 10 条独立调查线索的研究运行，变成了在这些线索上的 10 倍长的顺序遍历。

缺乏角色专业化。单智能体同时扮演：规划者（决定调查什么）、搜索者（拟定查询并阅读结果）、评估者（判断哪些来源可信）和综合者（撰写最终答案）。每个角色都是不同的认知任务，有不同的提示词工程需求。试图用一个提示词优化所有角色，最终在每个角色上都只能产出平庸的提示词。

分解方式

生产研究系统都收敛到这种形态：

主研究员充当规划者和综合者。每个子智能体负责一条调查线索——一个范围有限的特定子问题，配有小型工具集。子智能体返回压缩后的发现（其分析得出的结论，加上支撑这些结论的引用来源），而非原始搜索结果。主研究员用可管理的上下文完成跨线索的综合。

为什么这行得通

这种分解解决了单智能体三种故障模式中的全部三种：

上下文隔离防止污染。每个子智能体拥有专属于其线索的独立上下文窗口。子智能体 #1 收集的搜索结果永远不会进入子智能体 #2 的上下文，主研究员也只看到每个子智能体压缩后的发现。这是关键的架构洞见——子智能体充当上下文隔离过滤器。它们消化原始信息并输出摘要。

并行性是结构性的。子智能体并发运行。如果一个复杂问题有 5 条独立的调查线索，这 5 个子智能体可以同时工作。挂钟时间降至最长单条线索所需时间，而非所有线索的总和。对于线索真正相互独立的研究问题，在不损失质量的情况下可实现 3–5 倍的加速。

角色专业化提升每个步骤的质量。主研究员的提示词可以针对规划和综合进行优化。子智能体的提示词可以针对专注调查进行优化。每个角色都有各自的模型选择——Anthropic 记录的配置是以 Opus 作为主研究员、Sonnet 作为子智能体（其发现：这种组合在内部评估中比单智能体 Opus 的表现高出 90.2%）。主研究员在更强大的模型上完成认知要求更高的工作（规划、判断、综合），子智能体在更便宜的模型上完成可并行化的、范围更窄的工作。

主研究员的具体工作

主研究员按顺序完成三件截然不同的事：

# Sketch of the lead researcher's lifecycle

async def run_research(user_query: str):
    # 1. PLAN. Analyze the query and decompose into sub-questions.
    plan = await lead_call(
        model="claude-opus-4-7",
        system=PLANNER_SYSTEM_PROMPT,
        message=user_query,
        # Output: structured plan with sub-questions and tool guidance per
    )
    save_to_memory(plan)   # persist; large research tasks can exceed context

    # 2. DELEGATE. Spawn sub-agents in parallel, one per sub-question.
    findings = await asyncio.gather(*[
        run_subagent(
            sub_question=sq.question,
            tools=sq.allowed_tools,        # narrow per sub-agent
            tool_budget=sq.budget,         # 3-15 calls depending on task
            output_schema=COMPRESSED_FINDING_SCHEMA,
        )
        for sq in plan.sub_questions
    ])

    # 3. SYNTHESIZE. Combine findings into a coherent answer with citations.
    # Lead receives the compressed findings, NOT the raw search results.
    return await lead_call(
        model="claude-opus-4-7",
        system=SYNTHESIZER_SYSTEM_PROMPT,
        message=build_synthesis_input(user_query, plan, findings),
    )

这段草图中有三处细节值得关注，且都有其存在的理由：

内存持久化。长时间的研究任务可能超出模型的上下文窗口。计划在开始时保存到持久化存储；如果主研究员在运行途中需要重新加载，它可以恢复。Anthropic 记录的系统明确使用了这种模式，因为复杂查询常规性地超出 200K 令牌的上下文。

结构化的每子智能体任务规格。每个子智能体的任务不只是"调查这个"，而是"调查这个特定的子问题，使用这些特定的工具，在这个工具调用预算内，并按照这个精确的模式（schema）返回发现"。Anthropic 公布的发现：若没有这种级别的规格，子智能体要么重复彼此的工作，要么留下空白。其引用的例子——一个子智能体调查 2021 年半导体短缺，而另外两个独立调查 2025 年供应链——正是任务委派粗疏时的产物。

嵌入主研究员系统提示词中的工作量扩展规则。主研究员需要知道如何将工作量规模匹配到问题上。Anthropic 记录的规则如下：

• 简单事实核查：1 个子智能体，3–10 次工具调用。
• 直接比较：2–4 个子智能体，每个 10–15 次调用。
• 复杂研究：10 个以上子智能体，各有明确划分的职责。

没有这些规则，智能体要么对简单问题过度投入（浪费成本），要么对复杂问题投入不足（答案质量差）。提示词中的这些规则锚定了主研究员的规划步骤。

子智能体的具体工作

每个子智能体接收一项范围有限的任务，并运行一个有界的调查循环：

async def run_subagent(sub_question: str, tools: list,
                       tool_budget: int, output_schema: dict):
    # Subagent has its own conversation context, isolated from peers
    messages = [{"role": "user", "content": sub_question}]
    calls_made = 0

    while calls_made < tool_budget:
        response = await client.messages.create(
            model="claude-sonnet-4-5",        # cheaper than lead
            system=SUBAGENT_SYSTEM_PROMPT,    # narrow, focused
            tools=tools,                      # narrow, per-task
            messages=messages,
        )
        if response.stop_reason == "end_turn":
            break

        # Tool use; track calls against the budget
        results = await dispatch_tools(response.content)
        calls_made += len(results)
        messages.extend(append_turn(response, results))

    # Final step: produce structured findings (NOT raw chat)
    findings = await client.messages.create(
        model="claude-sonnet-4-5",
        system=COMPRESSION_PROMPT,
        messages=messages + [{"role": "user",
            "content": "Produce structured findings per the schema."}],
        tools=[{"name": "emit_findings", "input_schema": output_schema}],
    )
    return findings.content[0].input

最后输出的结构化数据至关重要。子智能体不返回对话式文本——它们返回一个类型化的对象：声明，以及每条声明来自的来源 URL，加上可信度指标。这正是使引用传播成为可能的原因。主研究员收到的发现已经映射到来源，综合步骤保留这种映射，而不是重新构建它。

成本权衡，如实说明

多智能体研究成本高昂。成本组成，粗略如下：

• 主研究员的规划调用：1 次调用，中等规模上下文，昂贵模型（Opus）
• N 个子智能体 × 每个 M 次工具调用，每个子智能体上下文窗口内的上下文不断增长
• 主研究员的综合调用：1 次调用，来自 N 个压缩发现的大型上下文，昂贵模型

对于一次包含 10 个子智能体、每个子智能体 12 次工具调用加上主研究员两次调用的"复杂研究"运行，令牌使用总量约在 50 万至 200 万之间。以子智能体使用 Sonnet 定价、主研究员使用 Opus 定价计算，每次运行的成本在 2–5 美元之间。提示词缓存（第 2.2 章）有所帮助，但并不能从根本上改变数量级。

这正是为什么这一架构专门留给真正困难的问题。对于简单的查询，单智能体甚至单次调用的路径更便宜、也完全够用。编排者-子智能体架构是当边际质量值得边际成本时的正确答案——而你的工作量扩展规则需要捕捉哪些问题属于哪种情况。

真正重要的工具，以及引用规范。

研究智能体可以使用许多工具。构建时的诱惑是把所有可能有用的东西都接入——多个搜索引擎、每个数据 API、代码执行、图像生成，应有尽有。不要这样做。工具面是一种成本：每增加一个工具，都会让智能体做出决策时更慢、更容易走错路，评估成本也更高。规范做法是：发布能完成任务的最小工具集。

本步骤涵盖值得保留的工具及每种工具的使用模式，以及使输出可信的引用基础设施。

覆盖大多数研究智能体工作的五种工具

以下是在生产中涌现出来的工具集，按使用频率大致排序：

注意这个列表没有包含的内容。没有图像生成。没有文件写入。没有邮件/通信工具。研究智能体是只读的——它们调查和综合，但不在世界中采取行动。这是一种刻意的设计规范：限制行动空间使智能体安全性大幅提升（无数据泄露路径，无不可逆的错误），也使评估更加严格。

为什么 web_search 和 web_fetch 通常分开

将这两者合并为一个工具（"搜索并自动抓取最佳结果"）的诱惑是有的。不要这样做。分开是有两个原因的：

智能体应当自行选择读哪些结果。搜索返回 10 个带摘要的候选结果。智能体阅读这些摘要，找出最有价值的 2–3 个实际抓取。抓取全部 10 个会浪费 7 倍的令牌，并用低相关内容污染上下文。将搜索与抓取分开，把这个选择权交到智能体手中。

工具描述可以分别优化。搜索工具的描述教会智能体如何拟定良好的查询（关键词，而非自然语言；3–6 个词；在必要时加入时间标记）。抓取工具的描述教会智能体何时应抓取（摘要不够；需要原始来源）、何时不必抓取（摘要已能回答问题）。这是两种不同的技能，有不同的提示词工程方法。

边读边压缩模式

研究智能体设计中杠杆率最高的模式之一：一读到信息就立即压缩，而不是等到综合时再压缩。

朴素设计：每个子智能体抓取来源，将其完整文本累积到上下文中，最后为主研究员做摘要。三个问题：(1) 跨多个来源的上下文膨胀；(2) 主研究员收到的摘要是子智能体在上下文已被污染的轮次结束时被迫撰写的；(3) 归因混乱，因为到综合时，特定声明与特定来源 URL 之间的联系已经弱化。

更好的设计：每当子智能体读取某个来源时，立即提取相关声明及支撑每条声明的 URL，并丢弃（或移出上下文）原始文本。子智能体的工作上下文包含一个不断增长的（声明，来源 URL）对列表，而非原始文档。

# Inside a subagent — the compress-as-you-read pattern

# Step 1: search to find candidates
search_results = await web_search("semiconductor export controls 2025")

# Step 2: pick most promising 2-3 URLs
chosen_urls = pick_best(search_results, n=3)

# Step 3: fetch and IMMEDIATELY extract claims
claims = []
for url in chosen_urls:
    text = await web_fetch(url)
    extracted = await extract_claims(   # a separate model call
        text=text,
        source_url=url,
        sub_question=current_sub_question,
    )
    # extracted is a list of {claim, source_url, confidence, quote}
    claims.extend(extracted)
    # text is discarded; only the structured claims live on

# Step 4: the subagent's "memory" is the growing claims list
#         not the raw fetched documents

这种模式有三个优点：(1) 子智能体的上下文保持紧凑，智能体可以在上下文压力积聚之前阅读更多来源；(2) 声明到 URL 的映射在提取时即已建立，此时两者都是新鲜的，而不是在综合阶段重新构建；(3) 提取步骤本身是一个聚焦的、可评估的子任务——你可以独立衡量"提取器是否能从给定来源中准确生成声明？"，而无需将其与"综合者是否能写出一份好报告？"混为一谈。

引用规范：结构性承诺

最终输出中的每一项实质性声明都应有可归因的来源。这是不可妥协的。使其实现的机制：

声明和来源在结构上存储在一起。声明永远不是一段文本，而是一个包含声明内容和支撑来源 URL 的对象。子智能体发现的结构化输出模式强制执行这一点：

COMPRESSED_FINDING_SCHEMA = {
    "type": "object",
    "properties": {
        "sub_question": {"type": "string"},
        "summary": {"type": "string",
                     "description": "2-3 sentence overview of findings"},
        "claims": {
            "type": "array",
            "items": {
                "type": "object",
                "properties": {
                    "claim": {"type": "string",
                              "description": "single substantive fact"},
                    "source_url": {"type": "string"},
                    "source_title": {"type": "string"},
                    "confidence": {"type": "string",
                                   "enum": ["high", "medium", "low"]},
                    "quote": {"type": "string",
                              "description": "short verbatim from source"},
                },
                "required": ["claim", "source_url", "confidence"],
            },
        },
        "gaps": {"type": "array",
                  "items": {"type": "string"},
                  "description": "questions raised but not answered"},
    },
}

这一结构在切实地发挥作用：声明是始终包含其来源的类型化对象。数据形态中不存在任何让声明丢失来源的路径。综合步骤接收这些对象，并输出每条声明仍附有引用的最终文本。

综合者的提示词指示保留引用。主研究员的综合提示词明确规定：最终输出中的每一项实质性声明都必须包含内联引用。没有引用的声明要么删除，要么改写以去除实质性内容。多加引用（同一段落中多个句子引用同一来源）是可以的；从实质性声明中删除引用则不被允许。

综合后验证器（可选但有价值）。综合完成后，独立的模型调用检查输出中每一项实质性声明是否都有引用，且该引用确实支持这条声明。这是第 3.3 章的 LLM 作为评判者（LLM-as-judge）方法，专门应用于引用保真度。可以捕捉综合者偏离的情况（从训练数据中添加了一条没有来源支撑的声明，或将引用套在了错误的声明上）。对于高风险输出，将此设为硬性关卡。

"无来源即无声明"规则

最严格的版本，被最严谨的研究智能体产品所采用：如果没有支撑某条声明的来源，该声明就不进入输出。智能体有时会从其训练数据中知道一些事情——但训练数据知识没有审计追踪，将其纳入会破坏引用系统所建立的信任。

规范做法是：要么找到一个来源（明确搜索一个），要么删除该声明。智能体通过系统提示词指令养成这一习惯："不要包含你无法引用的声明。如果某条声明看起来重要但你没有来源，请搜索一个。如果没有来源，则省略该声明并注明这一空白。"

这等同于第 0.1 章的"授权'我不知道'"——智能体获得了明确的许可，甚至是指示，可以省略内容。没有这一点，综合者就会用没有来源的常识性声明来填充内容，侵蚀读者的信任。

来源质量与来源数量

一个微妙之处：更多来源并非总是更好。智能体应当优先选择：

• 一手来源优于二手来源。SEC 文件优于记者对它的摘要。新闻稿优于报道该新闻稿的新闻文章。一手来源保真度更高，经由"传话游戏"引入的错误更少。
• 最新来源优于旧来源（对于当前状态的问题）。2026 年问题需要 2026 年的数据，而不是 2022 年的数据外推。
• 具体来源优于笼统来源。直接针对特定问题的页面，优于仅在路过时提及该话题的综合性文章。
• 权威来源优于聚合器。公司博客优于转载该博客的聚合网站。聚合器会添加容易出错的摘要，且往往自身也丢失了来源引用。

将这些偏好编入每个子智能体的系统提示词，能够显著提升最终输出的可信度。没有这些指令，智能体会默认使用搜索返回的第一批结果——这些结果往往是针对 SEO 优化的，而非针对准确性。

评估、真实标签，以及如何知道何时停止。

第 3.1 章论证了评估是让智能体质量随时间提升的规范。第 3.3 章介绍了 LLM 作为评判者（LLM-as-judge）作为可扩展的评分机制。两者都适用于研究智能体，但研究智能体迫使你直面评估问题中最难的版本：研究输出没有真实标签（ground truth）。没有可以运行的测试。"半导体出口政策有什么动态？"没有规范的正确答案——只有一个连续的质量空间。

本步骤讲述如何仍然对研究智能体的输出进行评分，以及智能体自身如何决定何时停止调查这一相关问题。

研究输出质量的四个维度

"答案好不好？"太模糊，无法衡量。将其分解为各自可以独立评分的维度：

四个维度，各自可独立评分。根据你的产品最看重什么，用权重将它们汇总。通用研究智能体可能对它们平均加权；高风险投资研究智能体可能对准确性和来源质量加倍权重。

事实准确性：唯一可以机械化评分的维度

步骤 3 中那个架构属性（声明和来源作为结构化对象存储在一起）最重要的意义，在于它在这里所能实现的：引用保真度可以被程序化检查。

检查方式：对于每条声明及其引用的来源 URL，抓取该来源，并让 LLM 评判者回答"这个来源真的支持这条声明吗？"二值判断：是 / 否 / 部分。一份 95% 以上声明都被忠实引用的研究输出，与一份只有 60% 的输出，是截然不同的——而这种差异对随意的读者而言是不可见的，除非有人来检查。

# Citation-faithfulness check, sketch

async def check_citation_faithfulness(claim: str, source_url: str) -> dict:
    source_text = await web_fetch(source_url)

    response = await judge_client.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=300,
        system="You are a strict fact-checker.",
        messages=[{"role": "user", "content": f"""
Does the following source EXPLICITLY support the claim?
Reply with one of: supported / partial / unsupported / contradicted.
Then give one sentence of reasoning.

Claim: {claim}

Source ({source_url}):
{source_text[:8000]}
"""}],
    )
    return parse_verdict(response)

# Run across every (claim, source) pair in the output
async def grade_research_output(output: dict) -> dict:
    verdicts = await asyncio.gather(*[
        check_citation_faithfulness(c["claim"], c["source_url"])
        for c in output["claims"]
    ])
    supported = sum(1 for v in verdicts if v["verdict"] == "supported")
    return {"faithfulness": supported / len(verdicts), "verdicts": verdicts}

这是第 3.3 章的 LLM-as-judge 方法，应用于一个具体的、范围有限的问题（X 是否支持 Y？），评判者处理此类问题时可靠性很高。在你的评估集（eval suite）上运行它；将 faithfulness 作为顶级指标追踪在你的记分板（第 3.1 章）上；如果它下降，视为回归（regression）。

全面性：按查询类型手工策划检查清单

"智能体是否覆盖了所有重要角度？"更难以机械化衡量，但可以通过努力使其可处理。做法：对你的智能体处理的每种主要查询类型，建立一个小型清单，列出好的答案应当涵盖的主题。金融研究评估可能检查"X 是否值得购买？"的输出是否涵盖了盈利、估值、竞争、关键风险和近期新闻。科学研究评估可能检查方法论、前期工作和局限性。

清单本身由人工构建（需要领域专业知识），存在于你的评估集中，而不在智能体的运行时提示词中。在对输出评分时：LLM 评判者对照输出检查每个清单项（"这份输出是否回答了 X？"），报告逐项覆盖情况，汇总为全面性得分。

这比保真度检查更耗费人力，且清单需要随着查询类型的演进而维护。但这是捕捉以下故障模式的唯一方法：智能体自信地产出了引用忠实的输出，却遗漏了用户真正想知道的核心内容。

停止条件：智能体如何知道何时停止调查？

没有明确停止条件的研究智能体，往往会走向两种故障模式：过早停止（主研究员在 3 次子智能体调用后就综合，而 7 次调用本可产出好得多的答案），或停止太晚（智能体不断深入越来越具体的调查，直到令牌预算耗尽，产出一份内容臃肿、信噪比低的输出）。

生产研究智能体结合使用以下停止信号：

预算限制。对每次运行的工具调用总次数（如 50 次）和令牌总支出设置硬性上限。达到预算时，智能体必须基于已有内容进行综合——不允许发起新的调查。简单，能防止异常运行。风险：上限在本来需要更多调查的问题上提前触发。

边际收益递减检测。主研究员定期反思："鉴于目前的发现，额外的子智能体能否实质性地改善答案？"如果新的搜索不断浮现已经覆盖的相同来源或声明，这是应当停止的信号。智能体对边际价值的自我评估是一种更软但更自适应的信号。

基于覆盖率。如果在规划阶段将问题分解为 N 个子问题，则当所有 N 个子问题都被调查到足够深度时停止——即使预算还有剩余。不要仅仅因为还有余量就继续挖掘。

用户定义。有些产品将深度选择暴露给用户："快速扫描"（5 分钟，1–2 个子智能体，约 0.50 美元）与"深度研究"（30 分钟，10 个以上子智能体，约 5 美元）。用户根据问题对自己的价值选择停止条件。大多数生产研究智能体产品都在向这种 UX 形态收敛。

实践中的混合方案：预算作为硬性上限，覆盖率作为主要信号，边际收益递减作为次要检查，用户定义的深度作为覆盖选项。每种机制都捕捉不同的停止理由；合在一起，它们能规避上述两种故障模式。

专门针对研究智能体的评估套件

研究智能体的评估套件（eval suite）长什么样？与第 3.1 章的示例有两点不同：查询多样性更重要，而逐查询评分成本更高。

覆盖多样的查询形态。简单的事实核查查询、中等难度的比较查询、难度高的开放式探索查询、边缘情况（大量付费墙内容的话题、有争议的话题、近期事件）。大约 30–50 条查询，手工选取以覆盖问题空间。每条查询配有自己的理想答案标准（全面性检查清单，以及预期来源质量模式）。

降低运行频率。评估集中的每条查询需要 1–5 美元的运行成本。50 条查询的评估每次运行需要 50–250 美元。相比之下，第 3.1 章的评估套件每次完整运行可能只需 1–5 美元。你无法为每次 PR 都运行——安排每周运行一次，或者每次 PR 运行一个快速子集（10 条查询，10–50 美元），完整套件按发布节奏运行。

不要期望严格的可复现性。网页内容每天都在变化。同一条查询昨天和今天运行可能会找到不同的来源。你的评估评分机制需要处理这一点——不要对比固定的预期 URL；对比预期的属性（保真度比率、预期主题的覆盖率、来源质量分布）。采样噪声（noise floor）是真实存在的；多次运行取平均，比对确定性智能体更重要。

一个开放式研究查询，在系统中全程追踪。

为了让步骤 2–4 的所有内容具体可感，这里通过一个示例查询进行全程追踪——正是这类查询催生了多智能体形态。不是玩具场景，而是一家初创公司的销售代表在与新客户会面前可能会提出的那种问题。

查询内容

"我们下周二要与 Acme Corp 的平台工程负责人会面。他们当前的技术栈是什么，最近发布了什么，以及他们可能在关注哪些举措？"

注意这个查询的形态：定义宽泛、多方面、需要跨多来源综合、没有固定的正确答案。用户想要 5–10 分钟的阅读准备材料，而不是一个对话式回答。

主研究员的规划步骤

══ Lead (Opus): planning ══════════════════════════════════════════
[reasoning] This is a comprehensive briefing request. The user needs
context across three rough threads: (1) Acme's current tech stack, (2)
their recent shipped work, (3) likely current focus areas. Each can be
investigated independently. Complex-research tier per scaling rules.

[plan emitted]
{
  "sub_questions": [
    {
      "question": "What is Acme Corp's current technical stack?
                   Languages, frameworks, infrastructure, cloud provider.",
      "tools": ["web_search", "web_fetch"],
      "budget": 12,
      "expected_sources": ["engineering blog", "job postings",
                          "github org", "talks/conferences"]
    },
    {
      "question": "What has Acme Corp's engineering shipped in the last
                   6 months? Notable launches, open-source projects.",
      "tools": ["web_search", "web_fetch"],
      "budget": 10,
      "expected_sources": ["engineering blog", "press", "github releases"]
    },
    {
      "question": "What is Acme Corp's platform team likely focused on
                   now? Hiring patterns, conference talks, public roadmap.",
      "tools": ["web_search", "web_fetch", "read_document"],
      "budget": 12,
      "expected_sources": ["job postings", "conference schedules",
                          "team blog", "leadership talks"]
    }
  ],
  "synthesis_focus": "Briefing for sales meeting — emphasize concrete,
                     verifiable claims over speculation."
}
[plan persisted to memory key: research_run_8c1e]

子智能体 #1 运行

══ Subagent 1 (Sonnet): "What is Acme Corp's current tech stack?" ══
[budget: 12 tool calls]

→ web_search "Acme Corp engineering blog 2025"
   8 results; top: acme.com/blog (acme's own blog, primary)

→ web_fetch "https://acme.com/blog/posts/scaling-our-microservices-2025"
   [reads ~3500 tokens of content about their move from monolith to
    microservices, mentions Go, Kafka, Kubernetes, PostgreSQL, AWS]

→ extract_claims (internal subagent step)
   → 5 claims extracted with verbatim quotes and source_url

→ web_search "Acme Corp site:github.com"
   Their GitHub org. Several open-source projects.

→ web_fetch "https://github.com/acme-corp"
   [organization page; lists languages and notable repos]

→ extract_claims
   → 3 more claims about languages used in OSS

→ web_search "Acme Corp engineering jobs platform"
   LinkedIn + Greenhouse postings.

→ web_fetch [a senior platform engineer JD]
   [JD lists "experience with Go, Kubernetes, Pulumi, Datadog"]

→ extract_claims
   → 2 claims (with the JD as source); confidence "medium"
     since JDs can be aspirational, not actual

→ web_fetch [a "Staff SRE" JD]
   [similar stack list, plus "experience with eBPF" — new info]

→ extract_claims
   → 1 claim, confidence medium

[stop: enough sources for the sub-question; remaining budget unused]

[compress and emit findings]
{
  "sub_question": "Current technical stack",
  "summary": "Acme uses Go as primary backend language, Kubernetes
              on AWS for orchestration, PostgreSQL and Kafka for data,
              Pulumi for IaC, Datadog for observability. Recently
              migrated from monolith to microservices.",
  "claims": [
    {"claim": "Acme migrated from monolith to microservices in 2024",
     "source_url": "https://acme.com/blog/posts/scaling-our-microservices-2025",
     "confidence": "high",
     "quote": "completed our migration from the monolith in Q3 2024"},
    {"claim": "Primary backend language is Go",
     "source_url": "https://acme.com/blog/posts/scaling-our-microservices-2025",
     "confidence": "high",
     "quote": "...rewrote core services in Go..."},
    ... 9 more ...
  ],
  "gaps": ["Front-end stack not investigated — out of scope",
           "Database scale unknown"]
}

另外两个子智能体同样并行运行——不同的子问题、不同的聚焦调查，每个都输出带有声明和来源的结构化发现。

主研究员的综合

══ Lead (Opus): synthesis ═════════════════════════════════════════
[input: 3 compressed-findings objects, each with summary + claims]
[reasoning] Three subagents returned solid material. Notable signal:
subagent 3 identified that they're hiring heavily for "AI platform"
roles, which suggests their current focus. This connects with the
tech-stack subagent's note that they recently adopted Pulumi (IaC
maturity) and the recent-shipping subagent's note that they shipped
"Acme Workflows" (a new product surface in Sept 2025).

[output drafted with citation discipline]

# Acme Corp — Pre-Meeting Briefing

## Technical stack at a glance

Acme runs primarily on Go services orchestrated by Kubernetes on AWS,
with PostgreSQL and Kafka as data infrastructure [1]. They completed
their migration from a monolith to microservices in Q3 2024 [1], and
have standardized on Pulumi for infrastructure-as-code [2]. Recent
job postings indicate growing depth in eBPF-based observability [3],
suggesting platform maturity beyond standard Kubernetes patterns.

## What they've shipped recently

In the last six months, Acme launched Acme Workflows (Sept 2025) [4],
their first product surface beyond their original SaaS — described in
their announcement as "a new layer for embedded automation" [4]. The
engineering blog highlights two notable infrastructure ships: a custom
deployment system replacing Spinnaker [5] and an internal developer
platform initiative called "Voyager" [6].

## Likely current focus

Three signals converge on AI infrastructure as a top initiative:
- 14 of their 23 active engineering openings are AI-platform-coded
  roles ("ML platform", "AI infrastructure", "agent systems") [7]
- Their CTO gave a talk at QCon SF 2025 titled "Building reliable
  AI-driven products" [8], previewing internal tooling
- The Acme Workflows launch [4] explicitly mentions AI integration
  as a "near-term roadmap item"

This is consistent with broader industry positioning but Acme's
combination of recent microservices maturity + active AI hiring +
public CTO commitment suggests AI platform is genuinely the
priority for the next 6-12 months, not just messaging.

---
Sources:
[1] https://acme.com/blog/posts/scaling-our-microservices-2025
[2] https://github.com/acme-corp/infrastructure
... [8 sources total]

追踪揭示了什么

先读追踪的内容，再读它的形态。有几点值得点名：

主研究员在委派之前先做了规划。第 1 轮不是"派一个子智能体处理全部内容"，而是明确地将问题分解为三条独立线索，并为每条线索分配了工具授权和预算。下游子智能体拥有范围狭窄、可执行的任务授权。

每个子智能体的上下文保持精简。子智能体 1 阅读了 4 个来源，但在任何时刻，其上下文中只包含它正在构建的声明列表和当前来源——而非所有四个来源的全文。边读边压缩。

引用在结构上传播。最终输出中的每条声明都可追溯到特定的来源 URL。主研究员从不需要"记住"哪个来源支持哪条声明——结构化输出对象全程携带着这种映射。不存在产生幻觉（hallucination）的可能。

综合产出了单条发现所没有的东西。"三个信号汇聚到 AI 基础设施"这一点是综合性洞见——它对三个不同子智能体的发现进行了三角验证。没有一条单独的发现得出了这个结论。这是主研究员所增添的价值，也是为什么综合步骤使用最强大模型的原因。

输出标注了不确定性。职位发布证据的可信度是"中等"，因为招聘描述可能是愿景性的而非实际状态。综合保留了这一点——将 AI 重点表述为"可能"而非"确定"——这种校准赢得了读者的信任。