Memory Intelligence Agent

Paper: arXiv:2604.04503 Code: ECNU-SII/MIA Code reference: main @ e442be26 (2026-05-26)

1. Motivation (研究动机)

现有 Deep Research Agent (DRA) 已经能把 LLM/LMM 推理、搜索工具、网页或图像检索结合起来，但它们的“记忆”通常仍停留在检索相似轨迹的层面：把历史 CoT / tool trace 存下来，在新问题到来时塞回上下文。这个范式有三个具体瓶颈。第一，记忆只会增长，不会真正进化；越多轨迹被累积，越容易出现冗余、冲突或低质量案例。第二，长上下文检索会持续增加 storage 和 retrieval cost，尤其在多模态、多轮搜索中，每条轨迹都包含问题、图片 caption、工具调用、网页观察和中间推理。第三，单纯 RAG 式记忆难以让 agent 内化策略：Planner 不一定学会“为什么这条历史轨迹成功”，Executor 也不一定学会遵循计划或在失败时触发 re-plan。

Figure 1 解读：这组柱状图把 MIA 的研究动机压缩成四个对比：它不仅能给 frontier LLM/LMM 的 ReAct 式搜索带来增益，也能让 Qwen2.5-VL-7B 级别的小 Executor 在多数据集上接近或超过更大模型，并且在统一 Executor 下优于 RAG、Mem0、A-Mem、ReasoningBank、ExpeL、Memento 等 memory-based search agent。图中的核心信号不是“多一个检索模块”，而是记忆被转化成 Planner 参数和 Memory Manager 的正负范式后，agent 的搜索策略会随经验增长而变化。

本文要解决的目标是：让 DRA 在复杂 multi-hop、open-domain、multimodal question answering 中，既能显式利用高质量历史轨迹，又能把历史经验内化到可持续更新的 Planner 中，从而降低纯上下文记忆的负担，并提升长期推理能力。这个问题值得研究，因为一旦 memory 不再只是被动检索，而能在 test time 继续形成 parametric memory，DRA 就有机会从一次次真实搜索中自我改进，而不是每次都从静态 prompt 和静态模型开始。

Figure 2 解读：这个 case 展示了 MIA 处理复杂多跳问题时的完整链路：先基于输入检索相似记忆，再由 Planner 产出可执行搜索计划，Executor 按计划调用工具、观察环境、回答或触发反思，最后把过程压缩回 Memory Manager。它说明本文关注的不是单次 answer accuracy，而是“搜索过程本身”如何被记住、筛选、复用和训练。

2. Idea (核心思想)

MIA 的核心洞察是：agent memory 应该同时存在于 context 和 parameters 两个层面。成功/失败轨迹可以作为 non-parametric memory 被检索出来做 in-context contrastive learning；同一批轨迹也可以通过 GRPO 更新 Planner，使历史经验变成 parametric memory，而不是永远占用上下文窗口。

关键创新可以概括为 Manager-Planner-Executor 三元架构：Memory Manager 管理压缩后的正负历史范式；Planner 根据当前问题和记忆生成搜索 plan，并在反馈后决定是否 re-plan；Executor 负责具体工具调用和环境交互。训练上，MIA 先用两阶段 alternating RL 对齐 Planner 与 Executor，再在 TTL 阶段冻结 Executor、持续更新 Planner，并同步更新显式 memory buffer。

与 RAG / Mem0 / A-Mem 这类主要依赖“检索历史文本”的方法相比，MIA 的根本区别在于它建立了双向转换回路：non-parametric memory 通过 Planner training 被压缩进参数，新的 parametric policy 又在 exploration 中产生新轨迹回写 Memory Manager。与只做 ReAct 或 planner-only 的 agent 相比，MIA 额外训练 Executor 的 plan-following / re-plan 接口，并用正负范式约束 Planner 的检索和反思。

3. Method (方法)

3.1 Overall framework：Manager-Planner-Executor

Figure 3 解读：MIA 的推理过程分成三段。Inputs & Retrieval 阶段把问题和图像 caption 映射到 memory space，检索相似的成功/失败 workflow；Research Process 阶段由 Planner 读入 memory context 并生成 plan，Executor 按 plan 调用 text/image search 工具，如果回答不可靠则把交互历史反馈给 Planner 触发 re-plan；Outputs & Storage 阶段把最终 answer、工具轨迹、计划和判断标签压缩成结构化 memory。这个图也体现了本文的关键分工：Memory Manager 不直接回答问题，Planner 不直接搜索网页，Executor 不负责长期记忆。

从直觉上看，MIA 把“经验”拆成两种可互补的形态：显式的 workflow 示例适合在当前上下文中提供可解释参照，隐式的 Planner 参数适合吸收大量相似问题中的策略规律。只保留前者会导致上下文越来越大；只训练后者又会丢掉可审计、可对比的具体案例。因此它同时维护 memory buffer 和 Planner policy，并让二者在训练和 TTL 中不断互相转换。

3.2 Memory Manager：non-parametric memory 的抽取、检索和压缩

Memory Manager 由 memory buffer 和冻结的 LLM 服务组成。论文中的 buffer 按 modality 和 question category 组织，每个 entry $m_{i}$ 存储问题、image caption、judgment label、usage count $u_{i}$ 、success count $s_{i}$ 以及历史 workflow。给定新 query 的问题 $q$ 和 caption $c$ ，先通过 sup-simcse-bert-base-uncased 得到归一化 embedding： $e (x) = Norm (MeanPool (Encoder (x))) .$ 问题和 caption 的相似度分别为： $sim_{i}^{(q)} = cos (e_{q}, e_{q_{i}}), sim_{i}^{(c)} = cos (e_{c}, e_{c_{i}}) .$ 论文把最终检索分数写成 semantic similarity、value reward、frequency reward 的组合： $Score (m_{i}) = λ_{s} Sim_{i} + λ_{v} Val_{i} + λ_{f} Freq_{i},$ 其中论文设定 $λ_{s} = 0.7, λ_{v} = λ_{f} = 0.3$ 。在 released code 中，Memory-Serve/memory_serve.py 的 MemoryProcessor 实际使用 question_weight=0.8、caption_weight=0.2 组合 query/caption cosine similarity，再用 cosine_weight=0.7 与 win_rate_weight=0.3 组合 normalized similarity 和 historical win rate。

论文公式与 released code 实现差异：论文描述了 frequency reward，并称新 memory 的 counts 初始化为 0；main@e442be26 代码中 MemoryBucket.add_entry 默认把 usage_count=1、success_count=1、win_rate=1.0，检索打分只显式组合 normalized cosine similarity 与 win_rate，没有单独的 frequency reward 项。这意味着实际实现更接近“语义相似度 + 历史胜率”的检索，而不是论文公式中的三项打分。

Figure 4 解读：该 prompt 说明 Memory Manager 并不是把原始长轨迹直接塞进 buffer，而是要求 LLM 从交互历史中抽取 image caption、workflow summary、关键工具调用和经验性 plan。这样做的目的有两个：压缩存储成本，并把低层 tool observation 转换成 Planner 可读的策略范式。

Non-parametric memory 的更新流程如下：Planner 对同一问题生成 $G$ 个 candidate plans；Executor 分别执行得到 $G$ 条 trajectories；LLM Judger 按答案正确性把轨迹分成 $T_{s u cc}$ 和 $T_{f ai l}$ 。如果存在成功轨迹，Memory Manager 选择执行路径最短的成功轨迹： $τ_{s u cc}^{*} = ar g min_{τ \in T_{s u cc}} length (τ) .$ 如果存在失败轨迹，则随机采样一条失败轨迹 $τ_{f ai l}^{*} \in T_{f ai l}$ 。前者鼓励高效推理，后者保存错误模式，二者共同形成 positive / negative paradigms。

def retrieve_memory_context(question, image_caption, bucket, top_k_pos=2, top_k_neg=2):
    q_vec = encoder(question).mean_pool().l2_normalize()
    if image_caption.strip():
        c_vec = encoder(image_caption).mean_pool().l2_normalize()
        sim_q = F.cosine_similarity(q_vec[None], bucket.question_embeddings)
        sim_c = F.cosine_similarity(c_vec[None], bucket.caption_embeddings)
        semantic = 0.8 * sim_q + 0.2 * sim_c
    else:
        semantic = F.cosine_similarity(q_vec[None], bucket.question_embeddings)
 
    semantic = (semantic - semantic.min()) / (semantic.max() - semantic.min() + 1e-8)
    win_rate = torch.tensor([m.get("win_rate", 0.0) for m in bucket.memory_data])
    score = 0.7 * semantic.cpu() + 0.3 * win_rate
 
    ranked = torch.argsort(score, descending=True).tolist()
    pos, neg = [], []
    for idx in ranked:
        item = bucket.memory_data[idx]
        if item["judgement"] == "correct" and len(pos) < top_k_pos:
            pos.append((idx, item))
        if item["judgement"] == "incorrect" and len(neg) < top_k_neg:
            neg.append((idx, item))
    return format_positive_negative_examples(pos, neg)

3.3 Planner-Executor 协作与 two-stage alternating RL

MIA 分两阶段训练 Planner 和 Executor。Stage 1 冻结 Planner，把它作为 plan server，训练 Executor 学会解析 plan、按 ReAct 调用工具、在回答错误时接受 re-plan。Stage 2 冻结训练后的 Executor，把它作为环境交互 server，训练 Planner 学会吸收 memory context、生成更可执行的 plan，并根据 Executor feedback 做 reflection。

Executor 的 GRPO 目标是在工具和 Planner 参与的 interleaved trajectory 上计算 token-level policy loss。论文写成： $J_{GRPO}^{M_{E}} (θ) = E [\frac{1}{G} \sum_{i = 1}^{G} \frac{1}{\sum _{t = 1}^{∣ y_{i} ∣} I ( y _{i, t} )} \sum_{t = 1}^{∣ y_{i} ∣} min (r_{i, t} \hat{A}_{i, t}, clip (r_{i, t}, 1 - ϵ, 1 + ϵ) \hat{A}_{i, t}) - β D_{K L} (π_{θ} ∥ π_{re f})],$ 其中 $r_{i, t} = \frac{π _{θ} ( y _{i, t} ∣ x , y _{i, < t} ; S _{e} , M _{P} )}{π _{o l d} ( y _{i, t} ∣ x , y _{i, < t} ; S _{e} , M _{P} )}$ ， $I (y_{i, t}) = 1$ 表示 token 由 policy 生成，若 token 来自工具或 Planner 则 mask 为 0。

Executor reward 是 rule-based composite reward： $r_{M_{E}} (x, y) = 0.7 r_{1} (a_{p re d}, a_{g o l d}) + 0.2 r_{2} (y) + 0.1 r_{3} (y),$ 其中 $r_{1}$ 是 LLM Judger 判定的答案正确性， $r_{2}$ 是标准化 tool call reward， $r_{3}$ 是格式 reward。released code 的 Executor-Train/Train/local_search/mmsearch.py::compute_score 与该公式一致：final_score = 0.7 * accuracy_score + 0.2 * average_tool_score + 0.1 * format_score。

def executor_reward(messages, ground_truth, question):
    answer = extract_answer(messages[-1])
    accuracy_score = float(judge_answer(question, answer, normalize_text(ground_truth)))
 
    tool_segments = re.findall(r"<tool_call>.*?</tool_call>", messages[-1], flags=re.S)
    tool_scores = [is_valid_tool_call(seg) for seg in tool_segments]
    average_tool_score = sum(tool_scores) / max(len(tool_scores), 1)
 
    format_score = float(has_balanced_think_tags(messages[-1]) and has_final_answer(messages[-1]))
    return 0.7 * accuracy_score + 0.2 * average_tool_score + 0.1 * format_score

Planner 的训练目标与 Executor 类似，但条件变为 retrieved memory context $m$ 和 trained Executor $M_{E}$ ： $J_{GRPO}^{M_{P}} (θ) = E [\frac{1}{G} \sum_{i = 1}^{G} \frac{1}{\sum _{t = 1}^{∣ y_{i} ∣} I ( y _{i, t} )} \sum_{t = 1}^{∣ y_{i} ∣} min (r_{i, t} \hat{A}_{i, t}, clip (r_{i, t}, 1 - ϵ, 1 + ϵ) \hat{A}_{i, t}) - β D_{K L} (π_{θ} ∥ π_{re f})] .$ Planner reward 同时看初答、终答、是否应该反思和格式： $r_{M_{P}} (x, y) = 0.7 r_{1} (a_{p re d}^{2}, a_{g o l d}) + 0.2 r_{1} (a_{p re d}^{1}, a_{g o l d}) + 0.05 r_{2} (y, a_{g o l d}) + 0.05 r_{3} (y) .$ Planner-Train/mem-plan/local_search/mmsearch.py::compute_score 的实现也体现了这个设计：它从 messages[1] 解析 first answer，从 messages[5] 解析 re-plan 后 final answer；若 first answer 已正确且 Planner 选择 no re-plan，或 first answer 错误且选择 yes re-plan，则 decision_score=1.0；最终按 final accuracy、first accuracy、decision/reflection、format 加权。

def planner_reward(messages, ground_truth, question):
    first_answer = extract_answer(messages[1])
    final_answer = extract_answer(messages[5]) if len(messages) == 6 else first_answer
    do_replan = extract_after_think(messages[2]).lower()
 
    first_ok = judge_answer(question, first_answer, normalize_text(ground_truth))
    final_ok = judge_answer(question, final_answer, normalize_text(ground_truth))
    decision_ok = (first_ok and do_replan == "no") or ((not first_ok) and do_replan == "yes")
    format_ok = do_replan in {"yes", "no"} and all_balanced_think_tags(messages)
 
    return 0.7 * float(final_ok) + 0.2 * float(first_ok) + 0.05 * float(decision_ok) + 0.05 * float(format_ok)

3.4 Test-Time Learning：同步更新 parametric / non-parametric memory

Figure 5 解读：TTL 阶段冻结 Executor，只让 Planner 继续学习。一次 exploration 会生成多个 plan rollouts；inference pipeline 由 Router 根据 Meta Plan Memory 选择最优 plan/trajectory 作为对用户的最终输出，避免把 label 泄漏进推理；training pipeline 则在获得环境反馈后为所有 rollouts 计算 reward 和 advantage，同时更新 Planner 参数并把正负 workflow 写回 Memory Manager。图中的关键点是 inference 和 training 共享探索结果，但最终回答的选择不能直接使用 gold label。

TTL 的在线自进化流程是：exploration $\to$ environmental feedback acquisition $\to$ non-parametric memory extraction $\to$ parametric memory update。对于每个 rollout $i$ ，计算 reward $R_{i}$ 后按组内标准化得到： $\hat{A}_{i} = \frac{R _{i} - μ _{R}}{σ _{R} + ϵ}, R = {R_{1}, \dots, R_{G}} .$ 然后用 GRPO 更新 Planner；同时 Memory Manager 抽取成功最短路径和失败样本作为显式正负范式。released code 中，TTRL-streaming/run_streaming_ttrl_server.sh 配置 actor_rollout_ref.rollout.n=4、data.train_batch_size=32、Planner learning rate 1e-6、trainer.n_gpus_per_node=4，对应“在线小批量探索 + 只更新 Planner”的设定。

def ttl_update(planner, frozen_executor, memory_manager, batch):
    rollouts = []
    for sample in batch:
        memory = memory_manager.retrieve(sample.question, sample.image_caption)
        for _ in range(4):
            plan = planner.generate_plan(sample.question, memory)
            trajectory = frozen_executor.execute(sample.question, sample.image, plan)
            reward = judge_or_environment_reward(trajectory, sample)
            rollouts.append((sample, plan, trajectory, reward))
 
    rewards = torch.tensor([r for *_, r in rollouts])
    advantages = (rewards - rewards.mean()) / (rewards.std() + 1e-8)
    grpo_update(planner, rollouts, advantages, lr=1e-6)
    memory_manager.store_shortest_success_and_random_failure(rollouts)

3.5 Unsupervised self-evolution：Reviewer-Area Chair judge

Figure 6 解读：无监督设置下没有 gold answer，MIA 用 Reviewer-Area Chair 风格的多代理 judge 替代单一 LLM-as-a-judge。三个 reviewer 分别检查 reasoning & logical consistency、information sourcing & credibility、result validity，Area Chair 再综合 JSON 证据做 meta-decision。这个设计试图减少“hallucinated objectivity”：单个 judge 可能被流畅表达欺骗，而多维审查要求指出证据、错误类型和致命缺陷。

在实现中，论文使用 Qwen3-32B 实例化三个 reviewer 和一个 AC。 $R_{L}$ 检查结论从前提是否可达， $R_{C}$ 检查 retrieved information 的误解和事实幻觉， $R_{V}$ 检查最终响应是否完成任务。这样 MIA 即使没有 ground truth，也能给 Planner TTL 和 Memory Manager 更新提供近似监督信号。

3.6 Code-to-paper mapping

Code reference: main @ e442be26 (2026-05-26) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Memory Manager / memory buffer	`Memory-Serve/memory_serve.py`	`MemoryBucket`, `MemoryProcessor`, `direct_store_memory`, `retrieve_balanced_memories`, `get_memories_context`
Positive/negative memory context for inference	`Memory-Serve/memory_serve.py`	`memory`, `best_plan`, `batch_memory_save`, `update_memory_stats`
Supervised no-TTRL MIA inference	`Inference/MIA-noTTRL/run_multi_react.py`, `Inference/MIA-noTTRL/react_agent.py`	`process_multimodal_item`, ReAct-style tool loop
TTRL agent service	`Serve/MIA-TTRL/agent_serve_ttrl.py`	`plan_route`, `replan_route`, `memory_route`, `MemoryProcessor`
No-ground-truth TTRL service	`Serve/MIA-TTRL/agent_sever_ttrl_nogt.py`	`memory_route`, `save_memory`
Executor GRPO training	`Executor-Train/Train/local_search/run_mmsearch_grpo.sh`, `Executor-Train/Train/local_search/mmsearch.py`	`compute_score`, `CustomRLHFDataset`
Planner GRPO training	`Planner-Train/mem-plan/local_search/run_mmsearch_grpo.sh`, `Planner-Train/mem-plan/local_search/mmsearch.py`	`compute_score`, `CustomRLHFDataset`
Streaming TTL	`TTRL-streaming/run_streaming_ttrl_server.sh`, `TTRL-streaming/streaming_ttrl_server.py`	`train_planner`, streaming GRPO server
Tool interfaces	`Serve/MIA-TTRL/tool_search.py`, `tool_serper.py`, `tool_image.py`	`Search`, `ImageSearch`

4. Experimental Setup (实验设置)

4.1 Datasets and scale

论文同时评估 multimodal 与 text-only DRA。数据规模来自 Appendix Dataset Settings：

Multimodal training: FVQA-train，4,856 image-text examples，来自 MMSearch-R1。
Multimodal evaluation: FVQA-test 1,800；InfoSeek 2,000；LiveVQA 2,384；SimpleVQA 1,013；MMSearch 171；In-house 1 295；In-house 2 505。
Text-only Planner training: MATPO，6,175 examples。
Text-only evaluation: 2Wiki 12,576；HotpotQA 7,405；SimpleQA 4,327；GAIA-Text 103。

4.2 Baselines, tools, and metrics

Baselines 包括 closed-source models：GPT-4o、GPT-5.4、Gemini-2.5-Pro、Gemini-3-Flash、Claude-Sonnet-4.6；open-source Qwen2.5-VL-7B / 32B；search agents：ReAct、MMSearch-R1、DeepMMSearch-R1、WebWatcher、Deepeyes2；memory-based search agents：No Memory、RAG、Mem0、A-Mem、ReasoningBank、ExpeL、Memento。工作流分为 Direct Answer、Search Agent、Memory-based Search Agent。

工具设置：multimodal 的 image-to-image search 使用 Serper；HotpotQA、2WikiMultiHopQA、SimpleQA 的 text-to-text search 使用 wiki25；其他文本搜索使用 Serper。主要指标是 accuracy，即最终答案是否被 LLM Judger / dataset evaluator 判为正确；tool-call analysis 额外统计成功运行中的 tool call frequency。

4.3 Training config from released scripts

训练配置来自 released code 的实际 launch scripts，而不是 ppo_trainer.yaml 默认值：

Executor stage: Executor-Train/Train/local_search/run_mmsearch_grpo.sh 使用 REF_MODEL_PATH=/your_path/model/Qwen2.5-VL-7B-Instruct/Qwen/Qwen2.5-VL-7B-Instruct，data.train_batch_size=128，max_prompt_length=16384，max_response_length=16384，actor_rollout_ref.actor.optim.lr=1e-6，ppo_mini_batch_size=128，ppo_micro_batch_size_per_gpu=4，actor_rollout_ref.rollout.n=8，trainer.n_gpus_per_node=8，nnodes=1，trainer.total_epochs=8。
Planner stage: Planner-Train/mem-plan/local_search/run_mmsearch_grpo.sh 使用 REF_MODEL_PATH=/your_path/model/Qwen3-8B/Qwen/Qwen3-8B，data.train_batch_size=128，max_prompt_length=24576，max_response_length=8192，lr=1e-6，rollout.n=8，trainer.n_gpus_per_node=4，nnodes=1，total_epochs=5。
TTRL streaming: TTRL-streaming/run_streaming_ttrl_server.sh 使用 REF_MODEL_PATH=/your_path/planner，data.train_batch_size=32，max_prompt_length=24576，max_response_length=8192，lr=1e-6，rollout.n=4，temperature=1.0，trainer.n_gpus_per_node=4，nnodes=1。
Memory / judge services: Memory-Serve/deploy.sh 和 Serve/MIA-TTRL/deploy.sh 使用 served model name qwen，gpu-memory-utilization=0.8；Memory Manager embedding path在代码中为 /your_path/bert/sup-simcse-bert-base-uncased。

5. Experimental Results (实验结果)

5.1 Main multimodal and text-only accuracy

Multimodal Table 3 中，MIA 在七个数据集上的结果为：FVQA-test 69.6，InfoSeek 65.5，SimpleVQA 64.9，LiveVQA 43.1，MMSearch 62.6，In-house 1 31.8，In-house 2 37.7。对应的 No Memory baseline 是 61.4 / 56.8 / 63.0 / 33.0 / 55.6 / 15.9 / 26.9；Memento 是 66.3 / 57.3 / 61.9 / 36.7 / 61.4 / 22.7 / 30.7。无监督 MIA 也达到 65.1 / 64.3 / 63.3 / 40.1 / 60.2 / 29.8 / 31.1。

Text-only Table 4 中，MIA 在 SimpleQA / 2Wiki / HotpotQA / GAIA 上达到 47.7 / 71.8 / 63.5 / 31.1，高于 Memento 的 42.4 / 64.2 / 55.2 / 22.3，也高于 Unsupervised MIA 的 46.6 / 71.6 / 61.7 / 30.1。论文据此报告 text-only 平均 accuracy 为 53.5，相比最强替代方法 Memento 平均提升 7.5；在 2Wiki 上提升 7.6，在 GAIA 上提升 8.8。

5.2 Ablation：每个组件的边际贡献

Ablation Table 5/6 显示组件是逐步叠加起作用的。Multimodal 从 Base 61.4 / 56.8 / 63.0 / 33.0 / 55.6 / 15.9 / 26.9 出发，Only Plan 已提高到 64.9 / 58.6 / 62.6 / 35.4 / 56.7 / 21.0 / 31.3；Memory for Planner 进一步变成 67.9 / 60.7 / 61.8 / 36.0 / 59.0 / 17.0 / 34.7；Trained Planner 到 67.6 / 63.8 / 63.8 / 40.1 / 60.8 / 26.1 / 34.5；最终 + TTL 达到 69.6 / 65.5 / 64.9 / 43.1 / 62.6 / 31.8 / 37.7。

Text-only ablation 更清晰：Base 为 40.7 / 61.2 / 51.0 / 11.7；Only Memory 甚至略降到 37.7 / 61.3 / 50.3 / 12.6，说明“只塞记忆”不稳定；Only Plan 提升到 42.1 / 62.8 / 54.9 / 18.5；+ Reflect 到 43.9 / 66.6 / 57.6 / 26.2；Trained Planner 到 44.6 / 69.1 / 59.3 / 28.2；+ TTL 最终到 47.7 / 71.8 / 63.5 / 31.1。论文总结为：相对初始 baseline，MIA multimodal 平均 accuracy +8.94，text-only 平均 accuracy +12.38；TTL 本身贡献约 +3.23 multimodal 和 +2.64 text-only。

Figure 7 解读：训练曲线显示 Executor reward 上升更直接，Planner reward 上升更慢且波动更大。原因是 Executor 的动作与最终答案、tool call、格式 reward 更直接相关；Planner 只通过 Executor 的执行结果间接获得反馈。右侧 TTL response length 的变化说明 Planner 在不同数据集上会逐渐适配任务风格，例如 2Wiki 变短、LiveVQA 保持多模态搜索所需的较长回答。

5.3 Closed-source Executors and tool-call behavior

Figure 8 解读：当 Executor 换成闭源模型、只能训练 Planner 时，MIA 仍能提高 LiveVQA 和 HotpotQA。论文报告 GPT-5.4 提升最大：LiveVQA +8.9，HotpotQA +6.4；Gemini-3-Flash 分别 +3.1 / +2.6；Claude-Sonnet-4.6 分别 +1.8 / +1.7。这说明 MIA 的 memory-to-planner 机制不依赖改动 Executor 参数，对强闭源模型也能通过计划质量和记忆检索改善搜索表现。

Figure 9 解读：tool call distribution 显示成功样本不一定总是调用最多工具，而是需要合适的工具调用频率。MIA 的计划和记忆帮助 Executor 更集中地调用搜索工具，减少盲目探索；失败灰点提示过少或过多工具调用都可能对应任务未完成、检索偏移或 re-plan 不及时。

5.4 Unsupervised self-evolution and limitations

无监督 Table 7 显示 MIA 在没有 gold label 的 self-evolution 下仍能逐 epoch 提升。Base 在 FVQA-test / LiveVQA / 2Wiki / HotpotQA 上是 61.4 / 33.0 / 61.2 / 51.0；Plan and Reflect (no memory) 为 59.6 / 36.5 / 64.2 / 56.4；Unsupervised Memory for Planner 为 57.6 / 28.5 / 66.9 / 56.4；Unsupervised MIA epoch-1 到 65.1 / 40.1 / 71.6 / 61.7，epoch-2 到 66.4 / 41.4 / 73.4 / 63.1，epoch-3 到 67.1 / 41.8 / 74.7 / 63.2。

论文的主要结论是：MIA 的收益来自 memory evolution，而不是更复杂的外部工具；同一套 Manager-Planner-Executor 机制在多模态和文本搜索中都有效。限制方面，论文仍依赖强 LLM/LMM 服务来做 Memory Manager、Router、Reviewer/AC 和 Executor，训练与 TTL 需要多服务部署；部分 in-house 数据不可复现；released code 中一些路径是 /your_path/... 占位，需要用户自行配置模型、数据和服务 URL。作者在结论中也指出，未来计划把 MIA 扩展到更复杂、更动态的环境。

Paper Notes

探索

Memory Intelligence Agent

Memory Intelligence Agent

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：Manager-Planner-Executor

3.2 Memory Manager：non-parametric memory 的抽取、检索和压缩

3.3 Planner-Executor 协作与 two-stage alternating RL

3.4 Test-Time Learning：同步更新 parametric / non-parametric memory

3.5 Unsupervised self-evolution：Reviewer-Area Chair judge

3.6 Code-to-paper mapping

4. Experimental Setup (实验设置)

4.1 Datasets and scale

4.2 Baselines, tools, and metrics

4.3 Training config from released scripts

5. Experimental Results (实验结果)

5.1 Main multimodal and text-only accuracy

5.2 Ablation：每个组件的边际贡献

5.3 Closed-source Executors and tool-call behavior

5.4 Unsupervised self-evolution and limitations

目录