研究 Agent 如何围绕未解决约束持续收敛

原始论文：AREX: Towards a Recursively Self-Improving Agent for Deep Research，arXiv:2607.21461，2026-07-23。
模型与权重：https://huggingface.co/collections/BAAI/arex

先澄清“递归自我改进”

AREX 所说的 Recursive Self-Improvement，不是 Agent 修改自己的模型、代码或 Harness，也不是开放式的无限自我进化。

它实现的是有限轮次的研究循环：

搜索并形成暂定答案
→ 按约束逐项验证
→ 保留已证实部分
→ 标记未解决或冲突部分
→ 生成下一轮定向研究目标
→ Refine、Restart 或结束

因此，更准确的工程定义是：

AREX 是验证驱动的 Research State 迭代器。

这个定义比“多想几轮”更具体，也意味着即使不训练专用模型，仍可以先在 Agent Harness 中复用它的主要机制。

为什么发现与验证不对称

深度研究通常不是寻找一个相关答案，而是寻找一个同时满足多项条件的答案。例如筛选一个技术方案，可能要求：

支持指定协议；
能私有部署；
有官方定价；
最近仍在维护；
证据必须来自一手来源。

从开放搜索空间中直接找到联合满足全部条件的候选很难；当候选已经出现后，逐项判断它是否满足某条条件通常更容易。

论文将其概括为 Discovery–Verification Asymmetry：

发现联合满足所有约束的候选：高成本
验证候选是否满足单项约束：可分解、相对低成本

普通 Research Agent 往往沿着一条不断增长的搜索轨迹前进。早期错误会被继续继承，被否定的候选可能再次出现，已验证的结论也可能在重写时被破坏。

AREX 的关键变化是：验证不再是最后一步，而是下一轮研究的控制信号。

双循环如何工作

Inner Research Loop：产生暂定答案

内层负责当前目标下的搜索与证据组织：

读取当前 Research State
→ 选择优先约束
→ 搜索或访问来源
→ 更新候选与证据
→ 在语义转折点提交 Context Update
→ 输出暂定答案

第一轮目标来自原始问题；之后各轮目标由外层根据未解决约束生成。

Outer Self-improvement Loop：决定下一轮做什么

外层对暂定答案做约束级审计，再执行三路决策：

Accept  ：必要约束均有充分证据，结束
Refine  ：已有有效进展，只补剩余缺口
Restart ：轨迹被错误前提污染，从原问题重启

Refine 不是把原问题再问一遍。它必须保留：

已验证事实与来源；
已否定候选与原因；
仍未解决的约束；
下一轮的具体检索目标。

只有当旧轨迹缺乏可复用证据或方向根本错误时，才选择 Restart。

真正关键的是 Research State

长研究轨迹会积累网页全文、搜索结果、冲突来源、失败查询和过期计划。普通 Context Compaction 往往等到 Token 接近上限才生成摘要，把上下文管理误解为容量问题。

AREX 引入模型主动调用的 update_context Tool。它聚焦在研究转折点提交下一步决策所需的状态：

verified_findings:
  - claim:
    evidence_ids: []

current_candidates: []

rejected_candidates:
  - candidate:
    reason:

unresolved_constraints: []
conflicts: []
next_plan: []

原始网页和 Tool Output 留在 Document Store 或 Trace 中，通过 ID 回查；Active Context 只保存当前判断需要的内容。

Context Update 的证据

论文在 BrowseComp 上分析 Autonomous Context Updating：

80.3% 的任务调用过 update_context；
调用时平均上下文约 25,721 Tokens；
只有 0.01% 的更新发生在 128K 上限附近。

这说明更新主要由语义变化触发，而不是等待上下文耗尽。

最常见触发原因是：

触发原因	占比
修改搜索策略	66.9%
否定候选	13.6%
发现新线索	7.2%
汇总进展	6.4%
验证证据或答案	5.3%

更新后最常保留的是下一步计划、未解决约束、已否定候选和已验证发现。可见高价值状态不是“发生过什么”的完整摘要，而是：

哪些已经成立，哪些已被排除，哪些仍未成立，下一步只该验证什么。

两个组件为什么缺一不可

论文在 BrowseComp 的内部消融结果为：

配置	Accuracy
无 Context Update、无外层循环	59.6
无 Context Update、有外层循环	69.8
有 Context Update、无外层循环	71.4
完整 AREX	82.5

这个结果支持两个相互独立的判断：

结构化 Research State 能减少长轨迹中的信息退化；
外层验证能把剩余不确定性转成新的定向研究。

它仍是论文作者体系内的实验，不等于第三方复现，但说明完整系统的收益并非单纯来自更长的搜索预算。

可复用的 Harness 设计

Constraint Ledger：先定义完成条件

研究开始前，将自然语言需求拆成显式约束：

constraints:
  - id: c1
    statement: 必须来自官方一手来源
    required: true
    status: unresolved
    evidence_ids: []

  - id: c2
    statement: 最近七天发布
    required: true
    status: unresolved
    evidence_ids: []

状态至少包括：

unresolved
supported
contradicted
not_verifiable
stale

如果完成条件不显式，外层循环就无法判断应该 Accept、Refine 还是 Restart。

Evidence Store：证据与答案分离

evidence:
  id: e17
  source_url:
  source_type: official
  published_at:
  retrieved_at:
  supports: [c1, c2]
  source_authority: high
  temporal_validity: current
  conflicts_with: []

同一证据可以支持多个约束，同一约束也可以由多个独立来源支持。答案只是 Evidence Store 和 Constraint Ledger 的当前视图，不是唯一事实源。

Structured Finish：让暂定答案可以被审计

内层不能只返回自然语言结论，应输出结构化结果：

answer:
claim_evidence_map:
constraint_status:
unresolved_constraints:
confidence_components:

Confidence 不应只依赖模型自报分数。更可靠的组合包括：

Constraint Coverage
× Evidence Support
× Source Authority
× Temporal Validity
× Cross-source Consistency

Targeted Refine：只处理剩余缺口

if all_required_constraints_supported():
    return ACCEPT

if reusable_evidence_exists():
    return REFINE(build_objective(unresolved_constraints))

return RESTART(original_query)

下一轮输入应是剩余约束和必要证据，而不是完整历史加一句“继续改进”。

如何用于技术周报和岗位雷达

这类任务天然包含可验证约束。

技术信号

最近七天
一手来源
与 Agent 工程直接相关
包含可复用的工程意义
不与前几期重复

岗位信号

当前仍可申请
Senior / Staff / Principal 等高阶级别
JD 明确涉及 Agent Runtime、MCP 或 AI Coding
使用官方招聘页
地点和工作模式可核验

第一轮负责广泛发现候选；外层逐项验证日期、来源、开放状态和技术相关性；第二轮只补缺少官方来源、时间不清楚或技术含义不足的条目。

这样可以避免每轮重新全网搜索，也能防止已经排除的低质量候选反复进入报告。

应该如何评测

指标	说明
Constraint Coverage	必要约束获得证据支持的比例
Evidence Precision	引用是否真正支持对应结论
Source Authority	一手和权威来源占比
Rejected Candidate Recurrence	已否定候选再次出现的频率
Duplicate Search Rate	重复查询和重复访问比例
Targeted Refinement Ratio	增量搜索是否围绕未解决约束
Unsupported Claim Rate	无证据结论比例
Cost per Verified Constraint	每项已验证约束的平均成本

这些指标比报告长度、搜索次数或 Agent 自报信心更接近真实研究质量。

训练部分提供的额外启示

AREX 还使用 Agentic Mid-training 和长程 RL 训练模型。最值得借鉴的是 Key-step Supervision：长轨迹中真正决定成败的是少数步骤，例如获得决定性证据、否定错误候选、改变搜索方向或提交 Context Update。

论文用等预算随机步骤替换关键步骤回放后，BrowseComp 从 82.5 降到 74.1；用标准 GRPO 替换 Step-aware RL 后降到 79.4。

工程含义不是所有团队都应该训练模型，而是：Agent Eval 和经验沉淀应优先标记 First Decisive Evidence、First Bad Step 与 Strategy Change，而不是只保存整个长轨迹的最终成败。

适用边界

AREX 适合多约束且证据可验证的任务，例如文献研究、技术选型、供应商比较、岗位筛选和尽职调查。

不适合直接套用的情况包括：

完成条件无法明确的开放创作；
外部证据不可获取或不可验证；
简单事实问答；
对时延极度敏感的实时交互。

论文仍是预印本，最多 300 个内层 Turn 和 5 次外层循环的设置成本不低；训练还依赖合成任务和强 Teacher Trajectory。生产实现应先设置研究预算、停止条件和外部置信度校准。

工程结论

AREX 最值得复用的是四项机制：

把任务拆成可验证的约束，而不是只维护一个模糊目标；
把已验证证据、未解决约束和已否定候选保存为 Research State；
让下一轮研究由剩余不确定性驱动，避免无方向延长搜索；
区分 Refine 与 Restart：有效轨迹增量修复，被污染的轨迹彻底重启。

高质量 Research Agent 的核心不是搜索得更多，而是每轮结束后更准确地知道哪些已经成立、哪些仍未成立，以及下一步只应验证什么。