Cognitive Kernel-Pro: A Framework for Deep Research Agents and Agent Foundation Models Training

Paper: arXiv:2508.00414 Code: Tencent/CognitiveKernel-Pro Code reference: main @ 827eea52 (2026-04-29)

1. Motivation（研究动机）

Cognitive Kernel-Pro 解决的问题不是单一网页问答或单一工具调用，而是“深度研究 agent”在开放环境中如何同时具备网页交互、文件处理、代码执行、长链路推理和可训练性。论文的出发点很明确：当前强 agent 系统要么闭源，要么依赖 Jina Reader、FireCrawl、Chunkr、Whisper、付费浏览/文件解析服务等专有工具，导致研究者很难复现系统级效果，也很难把 agent 轨迹转化为可公开训练的 Agent Foundation Model 数据。作者希望把两件事合在一起做：第一，给出一个尽量开源、尽量免费、模块清晰的 deep research agent 框架；第二，围绕这个框架整理 query、trajectory、verifiable answer，并探索 SFT、RL、test-time reflection/voting 等训练和推理扩展策略。

这篇论文的关键背景是 GAIA 等 benchmark 已经把 agent 从“会搜索”推到“跨网页、文件、表格、图像和推理”综合能力评测。GAIA 任务通常要求多步搜索、信息聚合、文件下载与阅读、数值计算、答案格式控制；如果一个开源 agent 只能做网页搜索，或者只支持 PDF fetching 但没有通用 file agent，就很容易在真实任务里断链。论文因此强调“工具不是越多越好”，而是要把工具能力纳入同一套可训练的认知内核：主 agent 负责任务分解、子任务委派、信息聚合、代码生成和工具调用；Web/File 子 agent 负责各自资源域内的观察与动作；同一个 agent foundation model 驱动主 agent 与子 agent，从而使训练轨迹具有统一格式。

另一个动机是训练数据本身。很多 deep research 数据只给最终问答，缺少可验证的中间过程；也有一些数据来自真实网页或文件，但答案不稳定、互联网上可直接检索、或者过程不唯一，难以作为 SFT/RL 样本。作者把数据构造拆成四类域：web、file、code/general reasoning，并强调 query 必须依托可验证来源、需要跨来源综合、答案稳定且简短、不能只是网页原文拷贝。这个标准直接服务于后续训练：SFT 需要高质量轨迹，RL 需要确定、可验证、可打分的 reward；如果 query 本身歧义大或答案随时间变化，训练信号会变成噪声。

论文还把“模型能力”和“系统能力”分开看。CK-Pro-8B 是基于 Qwen3-8B 的 fine-tuned agent foundation model，但完整 Cognitive Kernel-Pro framework 也可以用 Claude-3.7-sonnet 或 GPT-4.1 作为 backbone。这个设置说明作者不是只追求一个 8B 模型在单一 benchmark 上刷分，而是想证明：即便使用较小开源模型，只要 agent 框架、数据构造和推理时反思/投票设计得当，也能接近或超过 WebDancer/WebSailor 这类开源 7B agent；而在使用 Claude-3.7 作为 backbone 时，框架本身也能在不依赖专有付费工具的条件下和更强闭源/半闭源 agent 系统竞争。

本文最值得关注的矛盾是“开放可复现”与“高性能 deep research”之间的张力。开放 agent 系统如果完全不用专有工具，文件解析、网页渲染、图像理解、搜索质量都会受限；但如果大量借助付费工具，模型训练和系统复现又不可控。Cognitive Kernel-Pro 的折中是：Google Search API 被视为搜索任务中几乎不可避免的基础搜索接口，其他能力尽量用开源实现替代；网页交互用 Playwright，文件处理用内部 file agent，代码动作统一成 Python 函数调用，模型训练数据也围绕可验证来源构造。这个取向使论文更像一篇 agent 系统 + agent model training recipe 的技术报告，而不是单纯的模型论文。

Figure 2 解读：这张 roadmap 把 Tencent AI Lab 之前的 Cognitive Kernel、WebVoyager 等工作汇总为三个方向：agent framework development、agent data construction、agent foundation model training。黄色块对应本文新增贡献：把多模块 agent 框架、可验证训练数据、SFT/RL 与推理时 scaling 组合成一个完整 pipeline。它也提示读者不要把 CK-Pro 只理解成一个 GitHub agent runtime；论文真正想表达的是从系统执行到数据再到模型训练的闭环。

2. Idea（核心思想）

核心思想可以概括为：把 deep research agent 设计成一个“可执行 Python 动作空间上的分层多模块系统”，再用同一套系统产生可监督、可验证、可强化学习的轨迹。主 agent 不直接把所有网页、文件、代码细节塞进一次 LLM 推理，而是在一个状态增强的循环里维护 completed_list、todo_list、experience、information 等状态，由 planner 更新计划，由 action generator 生成 Python 代码。这个代码可以直接作为 code agent 执行，也可以调用 web_agent(...)、file_agent(...)、ask_llm(...)、search(...)、stop(...) 等函数。这样，agent 的“动作”不是自然语言标签，而是可执行的函数调用；观察结果通过 print 返回，进入下一轮上下文。

本文的新意不在于提出某个单独工具，而在于把系统设计、数据构造和训练目标对齐：系统里主 agent/子 agent 的 action-observation trace 正好可以变成 SFT 轨迹；query 生成时保留中间结果和 hint，又能提高 trajectory sampling 成功率；RL 时把长轨迹拆成 subgoal 并对 subgoal-level 与 final-task reward 分别归一化，缓解长链路 deep research 中 reward 稀疏和 reward collapse 的问题。换句话说，Cognitive Kernel-Pro 的“kernel”不是一个静态模块，而是一个能产生、过滤、训练、反思和投票的 agent 循环。

直观上，CK-Pro 试图解决三个 failure mode。第一，单层 agent 在复杂任务中容易把计划、网页搜索、文件阅读、计算和最终答案混在一起，导致工具调用难以约束；分层主/子 agent 把网页和文件操作封装成专业函数，降低主 agent 的局部复杂度。第二，SFT 数据如果只含最终答案，会让模型学不到如何调用工具；作者用 gpt-4.1 在 CK-Pro framework 内采样 trajectories，并用 rejection sampling 筛掉错误轨迹。第三，RL 对 deep research 特别难，因为最终答案 reward 延迟太长；Subgoal-GRPO 在 subgoal phase 内比较局部成败，再和 final reward 组合，给模型更密集的 credit assignment。

这也解释了为什么论文强调 reflection 和 voting。Reflection 不是简单让模型“再想一遍”，而是把轨迹整理为 action-observation 格式，用 DeepVerifier 的五类 rubric 检查：finding sources、reasoning、problem understanding and decomposition、action execution、trajectory efficiency。如果某个维度出现问题，agent 带着结构化反馈重试。Voting 则让同一任务多次运行，汇总多个 trajectory，再选择最符合 rubric 的结果。它们都属于 inference-time scaling：不改训练参数，而是用额外推理成本提高鲁棒性。

Figure 3 解读：左侧是所有 agent 继承同一个 base class 的抽象，核心状态包括已完成事项、待办事项、经验和信息；action generator 输出 Python code，代码既可以调用子 agent 函数，也可以执行普通 Python 逻辑。右侧列出 main/web/file agent 的函数层级，并把 reflection module 接到任务完成检查之后。图中最重要的设计点是“统一动作接口”：Web/File 不是外置黑盒，而是主 agent 可调用的 Python 函数，因此轨迹能统一记录并用于训练。

3. Method（方法）

3.1 系统框架：两层多模块 agent

Cognitive Kernel-Pro 的运行时由 main agent 和若干 sub-agent 组成。Main agent 负责全局任务分解、子任务委派、信息聚合、工具调用和代码生成；sub-agent 负责局部资源域内的操作，例如 Web Agent 在浏览器中点击、输入、滚动和保存文件，File Agent 阅读 PDF、表格和图片。论文和代码都显示，主 agent 与子 agent 继承同一类 multi-step agent 抽象：输入是 task string，输出是 response string，中间动作是 Python code execution。

开源代码中的 ck_pro/agents/agent.py 定义 MultiStepAgent，其主要流程是：run() 创建/复用 session，循环调用 step()，直到达到正常结束、最大步数或最大时间；step() 先生成 plan，再生成 action；_parse_output() 从模型输出中抽取 Thought: 与 Code:，并用 CodeExecutor.extract_code() 解析代码块；step_action() 用 CodeExecutor 执行模型生成的 Python 代码，并把所有注册函数放进 executor 的 global vars。关键实现是 python_executor.add_global_vars(**self.ACTIVE_FUNCTIONS) 与 python_executor.run(action_res["code"], catch_exception=True, timeout=...)，这与论文“all actions are Python functions and executed directly”的描述一致。

ck_pro/ck_main/agent.py 中的 CKAgent 组合了 WebAgent、FileAgent、AskLLMTool、SimpleSearchTool 和 StopTool。它还实现了 step_mrun 的多次执行与聚合：如果 action 代码中包含 web_agent(、file_agent( 或 ask_llm(，且配置允许多次运行，主 agent 会用 multiprocessing pool 运行多个候选结果，再调用模型对候选进行聚合选择。这个机制对应论文里的 voting/inference-time scaling 思路，不过代码仓库暴露的是 runtime 层面的多候选执行与选择，而不是完整 RL 训练代码。

Web Agent 的开源实现位于 ck_pro/ck_web/agent.py。它注册了 click、type、scroll_up、scroll_down、wait、goback、restart、goto、stop、save、screenshot 等函数。screenshot 会切换到多模态模型处理网页图像；默认情况下，agent 主要基于网页 accessibility tree / HTML markdown 观察。File Agent 位于 ck_pro/ck_file/agent.py，暴露 load_file、read_text、read_screenshot、search、stop 等动作，适配 PDF、Excel、CSV、图片等文件。两个 sub-agent 的接口都返回 dict-like 结果，使主 agent 可以把局部处理结果继续纳入全局推理。

代码搜索结论：论文给出的 GitHub 仓库已公开，当前检索到的 commit 为 main@827eea52。仓库主要包含 agent runtime、web/file agent、evaluator、SFT 数据转换和 GAIA scorer；论文第 4 节中 Subgoal-GRPO / verl 训练的完整 RL 代码未在该仓库中直接暴露。因此下面的代码映射以已开源 runtime 为准，RL 伪代码依据论文公式和流程复原，不声称来自 repo 源码。

Paper Concept	Source File	Key Class/Function
Base multi-step agent loop	`ck_pro/agents/agent.py`	`MultiStepAgent.run`, `step`, `_parse_output`, `step_action`
Main agent orchestration	`ck_pro/ck_main/agent.py`	`CKAgent`, `step_action`, `ck_step_action`
Web sub-agent	`ck_pro/ck_web/agent.py`	`WebAgent`, `web_click`, `web_type`, `web_goto`, `_my_save`, `_my_screenshot`
File sub-agent	`ck_pro/ck_file/agent.py`	`FileAgent`, `_my_load_file`, `_my_read_text`, `_my_read_screenshot`, `_my_search`
Built-in tools	`ck_pro/agents/tool.py`	`StopTool`, `AskLLMTool`, `SimpleSearchTool`
Reflection / scoring utilities	`ck_pro/agents/evaluator.py`	`Evaluator.cot_qa_evaluate`, `evaluate_with_answer`, `detect_failure`, `ensemble`
SFT data conversion	`data/convert_sft.py`	trajectory/message conversion utilities

# Pseudocode 1: repo-backed MultiStepAgent loop, simplified from ck_pro/agents/agent.py
class MultiStepAgent:
    def run(self, task, max_steps):
        session = Session(task)
        state = self.init_state(session)
        for step_id in range(max_steps):
            plan_prompt = self.templates["plan"].format(task=task, state=state)
            plan_output = self.model(plan_prompt)
            plan = self._parse_output(plan_output)
            state = self.update_plan_state(state, plan)
 
            action_prompt = self.templates["action"].format(task=task, state=state)
            action_output = self.model(action_prompt)
            action = self._parse_output(action_output)  # Thought + Python Code
 
            executor = CodeExecutor()
            executor.add_global_vars(**self.ACTIVE_FUNCTIONS)
            timeout = self.exec_timeout_with_call if self.calls_subagent(action["code"]) else self.exec_timeout_wo_call
            executor.run(action["code"], catch_exception=True, timeout=timeout)
            observation = executor.get_print_results()
            state["information"].append(observation)
 
            if self.has_final_result():
                break
        return self.finalize(session, state)

# Pseudocode 2: repo-backed CKAgent multi-run aggregation, simplified from ck_pro/ck_main/agent.py
class CKAgent(MultiStepAgent):
    def __init__(self):
        self.web_agent = WebAgent()
        self.file_agent = FileAgent()
        self.tools = [StopTool(self), AskLLMTool(), SimpleSearchTool()]
 
    def step_action(self, action_res, action_input_kwargs):
        needs_multi = any(name in action_res["code"] for name in ["web_agent(", "file_agent(", "ask_llm("])
        if self.step_mrun <= 1 or not needs_multi:
            return super().step_action(action_res, action_input_kwargs)
 
        candidates = parallel_map(
            lambda seed_id: super().step_action(action_res, action_input_kwargs),
            range(self.step_mrun),
        )
        select_prompt = self.templates["aggr"].format(
            current_step=action_res["code"],
            result_list=format_candidates(candidates),
        )
        select_code = self._parse_output(self.model(select_prompt))["code"]
        selected_index = parse_printed_index(select_code)
        return candidates[selected_index]

# Pseudocode 3: repo-backed Web/File delegation pattern
def solve_deep_research_question(question: str):
    state = {"todo_list": [question], "information": [], "experience": []}
    # Main agent delegates volatile browsing to WebAgent.
    web_result = web_agent(
        task="Find authoritative sources and download any relevant files.",
        target_url=None,
    )
    print(web_result)
    state["information"].append(web_result)
 
    # If a PDF/CSV/XLSX/image was saved, main agent delegates content reading to FileAgent.
    if "local_path" in web_result.get("log", ""):
        file_result = file_agent(
            task="Read the downloaded files and extract evidence for the answer.",
            file_path_dict={"./downloaded/file.pdf": "source evidence"},
        )
        print(file_result)
        state["information"].append(file_result)
 
    # Main agent can then execute Python for calculation or formatting.
    answer = aggregate_evidence_and_compute_final_answer(state["information"])
    stop(output=answer, summary="answer grounded in browsed and file evidence")

3.2 Agent Foundation Model 的数据构造与 SFT

论文把 SFT 训练 recipe 建在可验证 agent 轨迹上。训练数据表显示，总体覆盖 Web、File、Reasoning 三大类，其中 Web 部分包括 OpenWebVoyager、Multihop URLQA、AgentWebQA with hint、PersonaHub-Aug、WebWalkerQA；File 部分包括 DocBench 与 TableBench；Reasoning 部分包括 NumiaMath、BAAI/TACO、RiddleSense、LogiCoT。对应 query/step 规模如下：OpenWebVoyager 1,259 queries / 9,098 steps；Multihop URLQA 4,225 / 25,589；

AgentWebQA with hint 2,721 / 32,231；PersonaHub-Aug 1,000 / 2,088；WebWalkerQA 1,904 / 18,116；DocBench 300 / 1,566；TableBench 1,000 / 9,482；NumiaMath 616 / 524；BAAI/TACO 225 / 730；RiddleSense 179 / 165；LogiCoT 1,400 / 1,400。这个表说明 CK-Pro-8B 的训练不是只靠网页搜索轨迹，而是混入了文件、表格、数学、代码/谜题、逻辑推理等多种动作类型。

Query 构造的约束来自 Appendix B：每个 query 必须基于可验证来源，例如 Wikipedia、arXiv、Papers With Code、GitHub 或明确可下载文件；必须要求跨来源 reasoning；最终答案不应在互联网上原文存在；答案要稳定、无歧义、通常是数字或短语；query 本身要自包含，并明确答案格式。这些要求看似偏数据工程，但对 agent 训练很关键：它们让 SFT 轨迹可以被自动或半自动验证，也让 RL reward 不会因为答案漂移而失真。

Trajectory sampling 使用 gpt-4.1 作为 CK-Pro framework 的 backbone 来采样。对于构造好的 query-answer pair，系统先用 agent 生成轨迹，再用 LangChain 的 cot_qa 和 gpt-4.1 进行基于相似度的 rejection sampling。每个 query 最多采样三次，直到成功；hint-based sampling 中，中间结果被放在 <secret>...</secret> 中帮助采样成功，但在实际训练前会从输入输出中移除，避免模型直接看到答案线索。这个设计的取舍是：训练数据收集阶段可以使用“教师提示”提高成功率，但最终 SFT 样本必须恢复为真实任务条件。

Figure 4 解读：这张图展示 URLQA 创建中的 information aggregation：query 不应是单网页检索，而要聚合多个可验证来源后得到稳定答案。它与本文的数据原则一致，即 source-based、cross-source、novel、stable、self-contained。对训练而言，这种构造会迫使 agent 学习“找证据—整理证据—计算/归纳答案”的轨迹，而不是只学习搜索关键词。

3.3 Subgoal-Conditioned GRPO：长链路 RL 的 credit assignment

RL 部分针对 deep research agent 的典型问题：轨迹长、工具多、最终答案 reward 稀疏且延迟。作者首先构造 RL 样本为 <Question, Answer, Reference Solution, Grounded URLs>，并做多阶段过滤。过滤流程包括：检查 reference solution 是否能逻辑地推出 reference answer；让 agent 验证外部来源有效性和推理步骤正确性；对每个候选样本用 CK-Pro SFT checkpoint 进行四次独立 rollout，只保留 rollout 表现出 partial correctness 的 400 个高质量样本；再用这些结果形成 curriculum signal，使训练从高一致性样本开始，逐步转向更复杂、低一致性的任务。

Subgoal recovery 的目标是把长轨迹拆成可评估阶段。论文把主 agent 的每一步定义为： $h_{t} = ⟨ s_{t}, a_{t}, τ_{t}^{sub}, k_{t}, r_{t}, r^{o} ⟩$ 其中 $s_{t}$ 是主 agent state，包含当前观察 $O_{t}$ 和累计 memory/context $m_{t}$ ； $a_{t}$ 是主 agent 动作，包括 reasoning、plan 和可执行 Python code； $τ_{t}^{sub}$ 是该动作诱导的 sub-agent trajectory，即 lower-level agent 的状态—动作序列； $k_{t}$ 是当前 subgoal phase； $r_{t}$ 是该步或 subgoal 的局部 reward； $r^{o}$ 是最终 outcome reward。这个定义把“主 agent 生成一段代码并调用子 agent”显式纳入 RL 状态/动作/轨迹，而不是把整个交互当成一个不可分割 episode。

Subgoal-GRPO 的关键是 decoupled normalization。给定一组 $G$ 条 trajectories，某个 phase $k$ 的 cumulative subgoal reward 记为 $R_{sub}^{(i, k)}$ ，最终任务 reward 记为 $R_{final}^{(i)}$ 。先在同一 subgoal phase 内计算 $μ_{sub, k}$ 和 $σ_{sub, k}$ ，得到： $A_{sub, t}^{(i)} = \frac{R _{sub}^{(i, k_{t})} - μ _{sub, k_{t}}}{σ _{sub, k_{t}} + ϵ}$ 最终任务 reward 则在全组 trajectory 上计算： $A_{final}^{(i)} = \frac{R _{final}^{(i)} - μ _{final}}{σ _{final} + ϵ}$ 二者组合为： $A_{t}^{(i)} = A_{sub, t}^{(i)} + λ A_{final}^{(i)}$ 这里 $λ$ 控制局部 subgoal execution 与全局 task alignment 的权衡。与把所有 reward 先相加再统一归一化相比，这种做法保留了 subgoal-level 信号，避免 final reward 方差过大时吞没局部进展。论文把这称为缓解 reward collapse；直观上，一个 agent 即使最终答案错误，也可能已经正确完成网页检索或文件定位，Subgoal-GRPO 能把这些阶段性进展转化为可学习优势。

# Pseudocode 4: paper-derived Subgoal-GRPO advantage construction
def compute_subgoal_grpo_advantages(trajectories, lambda_final=1.0, eps=1e-6):
    # trajectories: group of rollouts for the same question
    # each rollout has steps h_t with subgoal phase k_t, subgoal rewards, and final reward
    phase_to_rewards = collect_rewards_by_phase(trajectories, reward_name="subgoal")
    final_rewards = torch.tensor([traj.final_reward for traj in trajectories])
    final_adv = (final_rewards - final_rewards.mean()) / (final_rewards.std(unbiased=False) + eps)
 
    for i, traj in enumerate(trajectories):
        for step in traj.steps:
            k = step.subgoal_id
            rewards_k = torch.tensor(phase_to_rewards[k])
            sub_adv = (step.subgoal_reward - rewards_k.mean()) / (rewards_k.std(unbiased=False) + eps)
            step.advantage = sub_adv + lambda_final * final_adv[i]
    return trajectories
 
def grpo_update(policy, old_policy, trajectories, clip_eps, beta_kl):
    loss_terms = []
    for traj in trajectories:
        for step in traj.steps:
            logp = policy.log_prob(step.state, step.action_tokens)
            old_logp = old_policy.log_prob(step.state, step.action_tokens).detach()
            ratio = torch.exp(logp - old_logp)
            clipped = torch.clamp(ratio, 1 - clip_eps, 1 + clip_eps)
            surrogate = torch.minimum(ratio * step.advantage, clipped * step.advantage)
            kl_penalty = beta_kl * kl_to_reference(policy, step.state, step.action_tokens)
            loss_terms.append(-(surrogate - kl_penalty).mean())
    return torch.stack(loss_terms).mean()

3.4 Reflection、Voting 与 verifier

Inference-time scaling 包括 reflection with verification 和 voting。Reflection 会把完整 action trajectory 摘要成 action-observation 格式，再用 DeepVerifier 的 rubric 评价答案与轨迹。五个维度分别是：finding sources，检查是否使用具体且权威的证据；reasoning，检查逻辑一致性和对证据的忠实性；problem understanding and decomposition，检查任务解释和子目标拆解；action execution，检查工具、格式、模态使用是否正确；trajectory efficiency，检查是否能在步数预算内到达有效答案。每个维度分为 excellent、good、needs improvement、poor。如果发现违规，agent 带着 per-rubric score 和 targeted error localization 重试，直到得到满意答案或达到 retry limit。

Voting 则不是简单多数票，而是“多轨迹生成 + rubric-based 选择”。agent 对同一任务多次尝试，汇总所有轨迹，再选出最符合 reflection rubric 的输出。这个策略尤其适合 GAIA 这类开放任务，因为不同 rollout 可能找到不同来源或走不同文件处理路径；单次失败可能来自网页状态、搜索结果、文件解析或最终格式，而多次尝试可以提高至少一条轨迹成功的概率。论文中的结果也显示，CK-Pro-8B pass@3 明显高于 pass@1，说明 inference-time sampling 对小模型 agent 很重要。

4. Experimental Setup（实验设置）

4.1 模型、工具与 benchmark

实验主要围绕 GAIA dev set、GAIA text-only subset 和 xbench-DeepSearch。完整 GAIA dev set 有 $n = 165$ ，text-only subset 有 $n = 103$ ，xbench-DeepSearch 有 $n = 100$ 。框架级比较中，作者把 agent 分成 closed-source、open-source with paid tools、open-source without paid tools，并特别标注 reproduced results。Cognitive Kernel-Pro 的强 backbone 设置使用 Claude-3.7-sonnet；CK-Pro-8B 是基于 Qwen3-8B fine-tuned 的 agent foundation model，部分 multimodal 功能由 GPT-4.1 或 Qwen-2.5-VL-72B 支持。

工具设定上，论文认为 Google Search API 是搜索任务中几乎所有 agent 框架都需要的基础搜索接口，因此在“proprietary tools”比较中排除了 Google Search API；其他专有工具如 Chunkr、FireCrawl、Jina Reader、Whisper、Baidu/Bing API 等会被计入 paid/proprietary tools。CK-Pro 的核心主张是在不使用这些额外专有工具的条件下，用 Playwright、file agent、Python code execution 和统一 tool function interface 支撑 web/file/code/general reasoning。

SFT 轨迹采样的 backbone 是 gpt-4.1，采样时最多重试三次；rejection sampling 使用 cot_qa 与 gpt-4.1。README 中的 trajectory sampling 示例也给出与论文一致的配置：--sampling-mode --evaluation-method llm_score --max_retry_num 3，Web Agent 默认最大步数示例为 25，File Agent 为 20，并通过 MAX_FILE_READ_TOKENS=10000、MAX_FILE_SCREENSHOT=5 控制文件读取。注意这些是仓库 README 的运行示例，不应误读为论文所有实验的固定训练超参。

RL 实验使用 verl 作为核心 RL library，agent runtime 部署在 GPU clusters。由于 web 环境波动，训练中使用 Browserless 做 remote Playwright execution，以提高网页导航稳定性。论文还报告一次 Bing Search firewall policy update 导致 web-agent environment 退化，因此 vanilla RL checkpoint 表现受影响；这点很重要，因为它解释了为什么 RL pass@1 不一定单调优于 SFT，但与 pass@3/verifier 结合后提升明显。

4.2 数据规模与训练 recipe

训练 recipe 的数据统计如下：

Type	Data Name	Data Type	Query	Steps
Web	OpenWebVoyager	Web Browsing	1,259	9,098
Web	Multihop URLQA	Web Information Seeking	4,225	25,589
Web	AgentWebQA (w/ hint)	Web Information Seeking	2,721	32,231
Web	PersonaHub-Aug	No Ground Answer	1,000	2,088
Web	WebWalkerQA	Web Information Seeking	1,904	18,116
File	DocBench	PDF	300	1,566
File	TableBench	CSV/XLSX	1,000	9,482
Reasoning	NumiaMath	Math Reasoning	616	524
Reasoning	BAAI/TACO	Code/Puzzle	225	730
Reasoning	RiddleSense	Riddle/Puzzle	179	165
Reasoning	LogiCoT	Logical Reasoning	1,400	1,400

这个 recipe 的设计偏“覆盖 agent 能力面”而不是单纯堆网页数据。Web 数据负责信息 seeking 与浏览器动作，File 数据负责文档和表格处理，Reasoning 数据补足数学、代码谜题和逻辑推理。PersonaHub-Aug 的特点是没有 ground answer，因此论文通过 cross-validation of trajectory outcomes 和少量人工/系统验证引入 1k synthetic queries；作者也承认对这些 synthetic queries 的 manual validation 和 response annotation 工作量很大，尚未完全纳入。

4.3 评测指标和对比对象

主要指标是 Pass@1 和 Pass@3，并按 GAIA Level 1/2/3 分层报告。Pass@1 反映单次 agent run 的稳定性；Pass@3 更接近允许多次尝试/投票时的上限。对于小模型 agent，Pass@3 特别重要，因为一次轨迹失败可能只是某个工具动作或搜索路径失败，而多次运行能覆盖更多候选。论文还报告 reflection ablation 和 multimodal ablation，用来区分提升来自 reflection model、voting、还是多模态模型差异。

Figure 1 解读：这张总览图把三个结果放在一起：完整 GAIA dev set 上 CK-Pro framework 与 proprietary/free-tool agent 的对比；GAIA text-only subset 上 CK-Pro-8B 与 WebDancer/WebSailor 7B family 的对比；以及 RL 相对 SFT 在 GAIA-text 和 XBench-DeepSearch 上的提升。它是论文结论图，但阅读时要注意不同 panel 的 backbone 和工具设定并不完全相同：Claude-3.7 framework、CK-Pro-8B SFT、Subgoal-GRPO RL 是三个不同层面的结果。

5. Experimental Results（实验结果）

5.1 完整 GAIA dev set：框架级效果

在完整 GAIA dev set ( $n = 165$ ) 上，Cognitive Kernel-Pro 使用 Claude-3.7 且不使用额外 paid tools 时，Pass@1 Avg. 为 57.58，Level 1/2/3 分别为 77.36 / 54.65 / 26.92；Voting 后 Avg. 达到 63.64，Level 1/2/3 为 69.81 / 65.12 / 46.15；Pass@3 达到 70.91，Level 1/2/3 为 83.02 / 68.60 / 53.85。相同区域内，reproduced Smolagents* with Claude-3.7 的 Pass@1 Avg. 为 52.10，Voting 为 53.99，Pass@3 为 63.64。论文据此称 CK-Pro 在相同 backbone/search/API 条件下超过 Smolagents：Pass@1 约高 5 个点，Pass@3 约高 7 个点。

与依赖付费工具的开源框架相比，OWL—Workforce* reproduced with Claude-3.7 and without whisper 的 Avg. 为 60.61，Level 1/2/3 为 73.58 / 62.79 / 26.92；OAgent with Claude-3.7、Jina Reader、Whisper、Baidu/Bing API 的 Avg. 为 66.67，Pass@3 为 73.93。CK-Pro Claude-3.7 Pass@3 的 70.91 接近这些 paid-tool systems，同时避免了 Chunkr/FireCrawl/Jina/Whisper 等额外专有依赖。这支持论文“框架本身有效”的主张，但也说明最高分仍可能来自更强工具栈与闭源系统，例如 Manus 报告 Avg. 73.3。

CK-Pro-8B 在完整 GAIA dev set 的 Pass@1 Avg. 为 32.73，Level 1/2/3 为 43.40 / 32.56 / 11.54；Voting 后 Avg. 为 34.54；Pass@3 为 38.18，Level 1/2/3 为 50.94 / 38.37 / 11.54。论文指出 CK-Pro-8B Pass@3 与 Claude-3.7 state-of-the-art 仍有约 30 个点差距，说明 8B agent foundation model 还有很大提升空间。这个结果不应被解读为 8B 已接近闭源最强 agent，而应理解为在开放模型和免费工具约束下建立了可训练 baseline。

5.2 GAIA text-only subset：8B agent 与 WebDancer/WebSailor 对比

在 GAIA text-only subset ( $n = 103$ ) 上，CK-Pro-8B 的 Avg. 为 43.7，Level 1/2/3 为 56.4 / 42.3 / 8.33。对比 7B 系列，Search-o1 7B 为 17.5，R1-Searcher 7B 为 20.4，WebDancer 7B 为 31.0，WebSailor 7B 为 37.9。因此 CK-Pro-8B 在 text-only GAIA 上超过 WebDancer/WebSailor 7B family，尤其在 Avg. 上比 WebSailor 7B 高 5.8 个点，比 WebDancer 7B 高 12.7 个点。

与更大模型相比，WebDancer 32B 的两组结果为 40.7 和 51.5，WebSailor 32B/72B 为 53.2/55.4，WebThinker-RL 32B 为 48.5。CK-Pro-8B 的 43.7 强于部分 32B baseline（如 WebThinker-Base 44.7 非常接近、Search-o1 32B 28.2、WebDancer 32B 40.7），但仍低于 WebSailor 32B/72B 和 WebDancer 32B 的较强设置。这说明 CK-Pro-8B 的贡献更准确地说是“在 7B/8B 开源 agent model 档位建立强 baseline”，而不是全面超过大模型 agent。

Reflection ablation 显示，w/o Reflection 的 Avg. 为 27.0；用 CK-Pro-8B reflection 后为 28.5；用 Qwen-3-32B reflection 后为 31.5；用 GPT-4.1 reflection 后为 32.7。Level 3 从 7.7 提升到 11.5 只出现在 GPT-4.1 reflection 设置中，说明更强 verifier/reflection model 对困难任务有价值，但整体收益主要体现在 Level 1/2。Multimodal ablation 显示 CK-Pro-8B pass@1 使用 Qwen-2.5-VL-72B 时 Avg. 33.94，使用 GPT-4.1 时 Avg. 32.67；pass@3 分别为 37.56 和 38.12。作者据此认为结果提升不完全来自更强 multimodal model，Qwen-2.5-VL-72B 已能达到接近 GPT-4.1 的多模态支撑效果。

5.3 RL：Subgoal-GRPO、Verifier 与 inference-time scaling

RL 结果表明，单纯 RL checkpoint 受 web 环境波动影响，Pass@1 不一定比 SFT 更好。GAIA-text 上，Cognitive Kernel-Pro SFT Pass@1 Avg. 为 43.68，Level 1/2/3 为 56.40 / 42.30 / 8.33；SFT Pass@3 Avg. 为 47.55，Level 1/2/3 为 61.50 / 44.20 / 16.70。Cognitive Kernel-Pro RL Pass@1 Avg. 只有 36.24，Level 1/2/3 为 50.85 / 30.45 / 13.89；这说明 RL 在不结合 pass@3/verifier 时会受到训练环境和策略漂移影响。

真正的提升来自 Subgoal-GRPO 与 verifier / Pass@3 组合。GAIA-text 上，GRPO pass@3 Avg. 为 49.51，Level 1/2/3 为 58.97 / 48.07 / 25.00；Subgoal-GRPO pass@3 Avg. 为 52.67，Level 1/2/3 为 63.72 / 46.92 / 41.67；Subgoal-GRPO pass@3 + Verifier Avg. 进一步到 54.61，Level 1/2/3 为 68.46 / 47.21 / 41.67。Level 3 的改善尤其明显：从 SFT Pass@1 的 8.33 和 SFT Pass@3 的 16.70，到 Subgoal-GRPO pass@3 的 41.67，说明 finer-grained subgoal credit assignment 对困难多步任务更有帮助。

在 xbench-DeepSearch 上，SFT Pass@1 为 20.00，SFT Pass@3 为 32.00；GRPO + Verifier 为 38.00，Subgoal-GRPO + Verifier 为 45.00；GRPO pass@3 和 Subgoal-GRPO pass@3 都是 56.00，Subgoal-GRPO pass@3 + Verifier 达到 58.00。这个趋势支持论文结论：RL 使 agent 更擅长解决 challenging deep research tasks，而 inference-time scaling 会放大 RL 的收益。但也要注意，xbench 表中 Subgoal-GRPO pass@3 和 GRPO pass@3 同为 56.00，说明 subgoal 分解的优势不是所有指标上都绝对领先，主要体现在 GAIA-text Level 3 和 verifier 组合后的稳健性。

5.4 局限与复现注意事项

第一，论文和代码之间存在范围差异。GitHub 仓库公开了 agent runtime、web/file agent、evaluator、GAIA scorer、SFT 转换等，但没有完整公开 Subgoal-GRPO / verl 训练实现。因此如果读者想复现第 4 节 RL，需要自行实现 reward filtering、subgoal recovery、decoupled advantage normalization 和 GRPO update，不能只依赖当前 Tencent/CognitiveKernel-Pro 仓库。

第二，web-agent RL 对外部环境很敏感。论文脚注说明 Bing Search firewall policy update 造成 baseline performance decline，这不是小问题：deep research agent 的 reward 依赖网页可访问性、搜索结果排序、文件下载稳定性和浏览器执行状态。即使模型和代码固定，运行时间不同也可能影响 trajectory 成败。因此 CK-Pro 的实验结论更适合看作 framework/training recipe 的相对趋势，而不是完全环境无关的静态分数。

第三，CK-Pro-8B 的能力仍显著低于 Claude-3.7 framework 设置。完整 GAIA dev 上 8B Pass@3 为 38.18，而 Claude-3.7 framework Pass@3 为 70.91；这个差距意味着 agent foundation model training 仍处在早期阶段。论文的积极意义在于给出开放训练路线和强 7B/8B baseline，不是宣称小模型已经替代闭源大模型。

第四，工具依赖的边界需要明确。论文把 Google Search API 排除在 proprietary tool 比较之外，认为它可由 DuckDuckGo 等免费 API 替换；但实际复现时，搜索 API 的质量、限流、地区差异会显著影响 GAIA 和 deep research。File Agent 支持 PDF/CSV/XLSX/image，但复杂文档、扫描件 OCR 和表格解析仍可能成为瓶颈。对于需要严格评测的复现，必须记录搜索后端、浏览器服务、文件解析版本和模型 endpoint。

总体来看，Cognitive Kernel-Pro 的主要价值是把 deep research agent 的“系统执行结构”和“agent model training 数据结构”对齐：统一 Python 动作空间让轨迹可记录，source-based query 让训练样本可验证，hint/rejection sampling 提高 SFT 数据收集成功率，Subgoal-GRPO 处理长轨迹 credit assignment，reflection/voting 提升推理时鲁棒性。它不是最完整的 RL 代码 release，但作为开放 deep research agent 的 framework + recipe，提供了可继续扩展的基线。

Paper Notes

探索

Cognitive Kernel-Pro: A Framework for Deep Research Agents and Agent Foundation Models Training

Cognitive Kernel-Pro: A Framework for Deep Research Agents and Agent Foundation Models Training

1. Motivation（研究动机）

2. Idea（核心思想）

3. Method（方法）

3.1 系统框架：两层多模块 agent

3.2 Agent Foundation Model 的数据构造与 SFT

3.3 Subgoal-Conditioned GRPO：长链路 RL 的 credit assignment

3.4 Reflection、Voting 与 verifier

4. Experimental Setup（实验设置）

4.1 模型、工具与 benchmark

4.2 数据规模与训练 recipe

4.3 评测指标和对比对象

5. Experimental Results（实验结果）

5.1 完整 GAIA dev set：框架级效果

5.2 GAIA text-only subset：8B agent 与 WebDancer/WebSailor 对比

5.3 RL：Subgoal-GRPO、Verifier 与 inference-time scaling

5.4 局限与复现注意事项

目录