喜欢就关注我哦～
关于 Liz: 10+ 年算法背景，前腾讯 & top外资，野生全栈，热爱build，技术E人。专注于将前沿算法落地为真实可用的产品，也喜欢把抽象复杂的技术讲得通俗有趣。欢迎留言交流=D
ICLR 2026这几天正在召开，我也集中读了一些agent 方向的论文后，挑出了五篇个人觉得很值得回看的工作。
先说明一下，这几篇论文虽然都入选了 ICLR 2026 Oral，但研究和投稿本身发生在更早阶段，所以其中部分实验设置、对比对象和结果，放到今天看未必还是最新的。 但我还是想推荐它们。因为我挑选这些文章时，会特别看它们有没有延续性。也就是直到今天，是否还有人在继续迭代和优化。这样更容易分辨哪些是阶段性技巧，哪些是真正有延续性的方向。
另外，企业落地场景往往也需要分情况讨论。对于一些逻辑相对简单、预算有限，或现实约束较多的场景，企业真正追求的往往不是最前沿的方案，而是 ROI 更高的方案。在这种情况下，一些相对朴素但已经被验证有效的思路，反而可能是更合适的选择。
这些论文涵盖了不少实际问题，比如如何构建可训练的 agent 系统、如何设计跨平台数据 pipeline，以及如何开展安全评测等。如果你在做 agent 相关的研发，希望这些 insights 会对你有帮助。
In-the-Flow Agentic System Optimization for Effective Planning and Tool Use
Agent 系统能不能在真实多轮执行流里被训练？在此之前，agent 系统的训练始终面临一个根本困境——奖励信号要在整个轨迹走完才能知道成还是败，这个间隔可能长达几十轮，中间没有任何反馈。
AgentFlow 把系统拆成四个专业化模块——planner、executor、verifier、generator，通过共享的 evolving memory 让它们在多轮交互中协调。然后用 Flow-GRPO，在每一轮 planner 做决策时把最终 outcome reward 广播回这一步。这篇文章的新意是把最终 outcome reward 广播回每一步 planner 决策，让长程、稀疏奖励的训练变得 tractable。
技术方法与实验设置
四个模块都用 Qwen2.5-7B-Instruct，只把 planner 设为可训练
系统配了 Base Generator、Python Coder、Google Search、Wikipedia Search、Web Search 等工具
在十个 benchmark 上评估，覆盖 search-intensive、agentic、math、science 四类任务
主要结果与局限
在 7B 规模下，AgentFlow 相比最强 baseline 平均提升：
search +14.9%
agentic +14.0%
math +14.5%
science +4.1%
关于对照组：如果只把 frozen planner 换成 GPT-4o，只提升 5.8 个点；而真正的 in-the-flow RL 能把平均性能推到 55.7——说明瓶颈不只是“planner 不够强”，而是“planner 没在系统回路里被训练”。
局限：它依旧依赖一个手工设计过的多模块结构，且 executor / verifier / generator 仍是固定模块。
对我的启发： 这篇论文打开了“系统级训练信号”的思路——不要只盯着模型本身优化，而是把整个 agent 系统当成优化对象。Flow-GRPO 的广播机制（把最终 outcome reward 传回每一步）是一个可复用的设计模式，可以迁移到其他模块化 agent 系统里。
Agent Data Protocol: Unifying Datasets for Diverse, Effective Fine-tuning of LLM Agents
ADP 解决的是“agent 拿什么训”。公开 agent post-training 之所以进展慢，不是因为完全没有数据，而是因为数据被割裂在不同 schema、不同 action space、不同 harness 里，没人能低成本把它们接起来。
ADP 提出的方案是把异构的 agent 轨迹统一成一套轻量级“interlingua”——用 Pydantic schemas 把动作统一成 API Action、Code Action、Message Action 三类，把观察统一成 Text Observation、Web Observation 两类。
技术方法与实验设置
完成了 13 个既有 agent 训练数据集到 ADP 的转换
转换到三个主流 agent harness: OpenHands、SWE-Agent、AgentLab
据此构建了 ADP Dataset V1
主要结果与局限
基于 ADP 训练的模型，在不同 benchmark / harness 设置下分别达到：
SWE-Bench Verified:40.3%
WebArena:22.9%
AgentBench OS:34.7%
论文版本中的 ADP Dataset V1 已整合超过 130 万条训练轨迹 / instances，并支持在 OpenHands、SWE-Agent、AgentLab 等不同 harness 之间流动。
局限：协议层统一不等于 license 风险消失，下游用户需要自行验证原始数据集的最新授权条款。
对我的启发： 这篇文章在去年 10 月份的时候我就已经关注到他们的工作。ADP 的核心价值不在于“又造了一个数据格式”，而在于它证明了协议层标准化比单点模型更稀缺。如果你在构建 agent 训练 pipeline，最先投入的应该是数据协议层——一旦统一了 schema，后续的模型切换、数据扩展、框架迁移都会变得低成本。13 个数据集 → 1 个协议的思路可以复制到任何多源数据的场景。
RedTeamCUA: Realistic Adversarial Testing of Computer-Use Agents in Hybrid Web-OS Environments
Computer-use agent 的间接 prompt injection 到底应该怎么测？
当 agent 能操作 OS、能读写文件、能通过 web 执行真实操作时，攻击者可以把恶意指令嵌入一个看似无害的网页评论，agent 在浏览时把这些指令当成用户意图的一部分，最后在 OS 层面执行真实破坏。这个跨 web 到 OS 的混合攻击面，在本论文之前缺少足够真实、系统化的评测框架。
RedTeamCUA 构建的 hybrid sandbox 解决了这个评测缺口：底层 OS 用 OSWorld 的 VM，web 侧用 Docker 化的 WebArena / TheAgentCompany replica，再加上可配置的 adversarial injection 和一个关键的 Decoupled Eval 设计——直接把 agent 放到恶意注入点附近，而不是让它从零开始导航，以免“导航能力太差”导致“看起来安全”。
技术方法与实验设置
构建了 RTC-Bench，含 864 个 adversarial examples
由 9 个 benign goals × 24 个 adversarial goals × 4 种实例化方式组成
覆盖 CIA triad 的 confidentiality / integrity / availability 目标
同时报告 ASR（execution-based）和 AR（Attempt Rate）
主要结果与局限
结果如下：
Decoupled Eval 下，frontier CUAs 的攻击成功率最高达到 66.2%
Claude 3.7 Sonnet | CUA:42.9%
“最安全”的 Operator：7.6%
Attempt Rate 有的高达 92.5%——它们不是“完全免疫”，而是“想作恶但没做成功”
在更现实的 end-to-end 评估中，官方来源报告的 ASR 最高约为 50%，其中 Claude 4 Opus | CUA 为 48%。
局限：论文在测试的几类 defense setting 下认为，现有方法都不足以提供充分保护。
对我的启发： RedTeamCUA 给出的最大启示是把“能力不足”从“安全性”里剥离出来的 Decoupled Eval 设计。在做 agent 安全评测时，不要让 agent 因为“找不到注入点”而显得安全——直接把它放到恶意内容附近再测。这个设计思路可以迁移到任何安全相关的评测里：先确认 agent 接触到了风险内容，再评估它的响应。对 CUA 产品团队来说，上线前必须跑一次 hybrid web-OS 的 red team。
ScaleCUA: Scaling Open-Source Computer Use Agents with Cross-Platform Data
ScaleCUA 回答的问题是开源 CUA 社区最现实的问题：没有足够大的跨平台数据，open-source computer-use agent 很难追上闭源系统。
ScaleCUA-Data 覆盖 6 个平台/环境（如 Windows、macOS、Ubuntu/Linux、Android、iOS、Web）和 3 个 GUI-centric task domain，通过闭环流程把自动化采集与人工专家结合，再训练出可跨平台操作的 agent。
技术方法与实验设置
grounding data：自动 pipeline + Claude 3.7 标注 + 人工校验
trajectory data：人工操作采集 + 模型补注释
数据总文件体量约 1.07 TB
模型公开了 3B / 7B / 32B 三档
主要结果与局限
WebArena-Lite-v2：+26.6
ScreenSpot-Pro:+10.7
MMBench-GUI L1-Hard:94.4%
OSWorld-G:60.6%
WebArena-Lite-v2：47.4%
局限：后续工作 CUA-Suite 给出了一个很尖锐的外部批评：ScaleCUA 虽然是当时最大的开放数据集，但仍主要是约 200 万张截图，换算成连续视频不到 20 小时——这说明 screenshot-based scaling 之后，下一步瓶颈会转向 temporal continuity 和 continuous control。
对我的启发： ScaleCUA 证明了数据规模可以把开源 CUA 从 demo 到可用基线，但它同时暴露了“截图路线”的天花板。如果你正在构建 CUA 数据 pipeline，意识到两点：第一，现有 screenshot-based scaling 已经暴露出明显边界；第二，下一步要从静态截图走向连续视频交互。
MemAgent: Reshaping Long-Context LLM with Multi-Conv RL-based Memory Agent
MemAgent 的核心问题意识：长上下文不是简单把窗口越堆越大，而是要把“读、记、忘”变成一个可训练的 policy。
做法是固定长度的 memory panel，按 chunk 读入文档，每轮用 overwrite strategy 更新 memory，再用 multi-conv RL 训练模型学会保留关键信息、丢弃干扰信息。真正的新意在于 memory update 本身被当成 RL 训练对象，这使它和单纯的 sliding window、长 context continued pretraining、甚至大窗口模型区分开来。
技术方法与实验设置
用 Qwen2.5-7B-Instruct 和 14B-Instruct 做 base model
训练时限制在 8K context window（1024 query + 5000 chunk + 1024 memory + 1024 output）
在 32K 文档上训练，在长度从 7K 到 3.5M 的 RULER 任务上测外推能力
主要结果与局限
RL-MemAgent-14B：从 7K 的 83.59 到 3.5M 的 78.12，绝对降幅约 5.47 个点
RL-MemAgent-7B：从 82.03 到 71.09
512K RULER OOD 任务上，14B 平均 95%+
即使模型能在 spec 上支持百万 token 窗口，也不代表它能用那些窗口里的信息解决实际问题——长上下文的下一阶段，不是更长的窗口，而是更会取舍的记忆。
局限：主验证任务仍以 HotpotQA/RULER 类 long-QA 为中心，距离通用长时程 agent memory 还有明显距离。
对我的启发： MemAgent 给出的核心洞察是，memory update 本身可以被训练。这打破了“长上下文就是大窗口”的惯性思维。如果你在处理超长文档、知识库、或长对话系统，别急着扩 context window，先问自己：模型有没有学会记住重要的、忘记干扰的。
References
In-the-Flow Agentic System Optimization for Effective Planning and Tool Use（https://arxiv.org/abs/2510.05592）
Agent Data Protocol: Unifying Datasets for Diverse, Effective Fine-tuning of LLM Agents（https://arxiv.org/abs/2510.24702）
RedTeamCUA: Realistic Adversarial Testing of Computer-Use Agents in Hybrid Web-OS Environments（https://arxiv.org/abs/2505.21936）
ScaleCUA: Scaling Open-Source Computer Use Agents with Cross-Platform Data（https://arxiv.org/abs/2509.15221）
MemAgent: Reshaping Long-Context LLM with Multi-Conv RL-based Memory Agent（https://arxiv.org/abs/2507.02259）