每日论文速递 · Agent & LLM

I have enough data now. I've found 7 highly relevant papers from the last month. Let me compile the report.

📄 每日论文速递 · Agent & LLM

日期：2026-05-18

---

1. Orchard: An Open-Source Agentic Modeling Framework

🔗 https://arxiv.org/abs/2605.15040

💡 一句话：微软开源的 Agent 训练框架，核心是一个轻量级环境服务层（Orchard Env），统一了 sandbox 生命周期管理。Orchard-SWE 基于 Qwen3-30B 在 SWE-bench Verified 上做到 67.5%（SFT+RL），开源同规模模型 SOTA。还覆盖了 GUI agent 和个人助手场景。

🎯 关联：极高。这个框架的设计理念——用统一的环境抽象层来复用 agent 训练数据和 pipeline——跟你在 InternOS 里做的 Agent 平台架构高度对齐。它的 "harness-agnostic environment layer" 思路值得直接参考。credit-assignment SFT（从失败轨迹的有效片段学习）这个训练技巧也很有启发。

---

2. FORGE: Self-Evolving Agent Memory With No Weight Updates via Population Broadcast

🔗 https://arxiv.org/abs/2605.16233

💡 一句话：不更新权重，纯靠 prompt 注入自然语言记忆来让 Agent 自我进化。核心机制是"群体广播"——在多个 agent 实例之间传播最优实例的记忆（规则/示例），比 Reflexion 提升 29-72%。

🎯 关联：高。Agent memory 设计是你 InternOS 里的核心问题。FORGE 的做法很实用——不需要微调，纯靠自然语言记忆的 population-level 传播来提升性能。这个"毕业"机制（性能收敛的实例冻结以节省算力）对多 agent 编排的资源管理也有参考价值。

---

3. Response-Conditioned Parallel-to-Sequential Orchestration for Multi-Agent Systems (Nexa)

🔗 https://arxiv.org/abs/2605.15573

💡 一句话：提出了一种混合编排范式——先并行执行所有 agent，然后用一个轻量 transformer 策略网络预测出一张稀疏 DAG 通信图，决定哪些 agent 需要顺序精炼。图为空就纯并行，不空就做一轮顺序传播。

🎯 关联：高。这直接就是多 agent 调度编排的问题。你之前在 InternOS 里讨论过跨 agent 调度，Nexa 的"按需从并行切到顺序"的思路比固定拓扑灵活得多。而且这个通信策略跨 agent 数量、任务、底层模型都能迁移，工程上很实际。

---

4. Context, Reasoning, and Hierarchy: A Cost-Performance Study of Compound LLM Agent Design

🔗 https://arxiv.org/abs/2605.16205

💡 一句话：在 POMDP 环境下系统比较了 agent 设计的三个维度：上下文表示、推理策略、层级分解。核心结论——程序化状态抽象（而非原始观测）每 token 回报最高；层级分解 + 不加 deliberation 工具效果最好；deliberation 工具在层级系统中会产生"审议级联"反而拖后腿。

🎯 关联：高。"投资基础设施和干净的任务分解，而不是更深的单 agent 推理"这个设计原则，对 InternOS 的 agent 架构设计非常有指导意义。简单说：context engineering > deliberation engineering。

---

5. More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding

🔗 https://arxiv.org/abs/2605.05716

💡 一句话：对 agent scaffolding 的 5 个组件（规划、工具、记忆、自省、检索）做了全因子实验（32 种组合），发现"全都加上"不是最优——单工具 agent 比全功能版高 32%。最优组件数量跟任务和模型规模相关，贪心选择不可靠。

🎯 关联：极高。这篇直接挑战了"agent 组件越多越好"的默认假设。你设计 Agent 平台时，这个证据很重要——不应该让用户默认启用所有组件，而应该提供 task-specific 的组件选择机制。56.3% 的子模块化违反说明组件间交互是非线性的。

---

6. SWE-Edit: Rethinking Code Editing for Efficient SWE-Agent

🔗 https://arxiv.org/abs/2604.26102

💡 一句话：把代码编辑从 agent 主循环中拆出来，分成 Viewer（提取相关代码）和 Editor（执行修改）两个子 agent，让主 agent 专注推理。用 GRPO 训练 Qwen3-8B 自适应选择编辑模式，在 SWE-bench Verified 上提升 2.1% 同时降低 17.9% 推理成本。

🎯 关联：中高。子 agent 分工的设计模式（inspection vs execution 的上下文隔离）对你做 Agent 平台的工具编排有直接参考价值。"context coupling problem"这个问题在复杂 agent 系统里非常普遍。

---

7. QueST: Query-Conditioned Test-Time Self-Training for Large Language Models

🔗 https://arxiv.org/abs/2605.13369

💡 一句话：在推理时根据输入 query 自动生成结构相关的问题-答案对，用这些做 test-time 微调，然后再回答原始问题。不需要外部数据，在数学和科学推理 benchmark 上一致超越其他 test-time 优化方法。

🎯 关联：中。这是一个 test-time compute 的新范式——不是简单的多次采样，而是真的在推理时调参。如果你未来在 Agent 平台里要做"agent 自适应"的能力，这个方向值得关注。核心 insight：query 本身编码了足够的信号来构建自训练数据。

---

今日总结：今天的重点是 agent 组件设计和编排。论文 #4 和 #5 共同指向一个结论——agent 系统不是组件堆得越多越好，context engineering 和干净的任务分解比深度推理更有效。#1 Orchard 框架对你做 Agent 平台的技术选型有直接参考价值，值得细读。