Agent & LLM · 2026年6月21日
每日论文速递 · Agent & LLM
💡 一句话：在 208 个真实企业场景上对比了 DAG Plan-and-Execute 和 ReAct 两种编排范式，并提出一个带优先级推断 + 相关任务关联的 Task Manager，把多智能体系统从离散请求-响应推到持续事件监听。覆盖 Persona（<10 agents）、Department（20–80）、Enterprise（200）三个规模。
信息够了。直接挑选最相关的 7 篇，分布在调度编排、memory、tool 使用、coding agent、benchmark 几个方向。
📄 每日论文速递 · Agent & LLM
日期：2026-06-21
筛选自 arXiv cs.AI / cs.CL / cs.MA 最近一周（6/14–6/19）的新提交，专门挑了对 InternOS 调度系统和 AI Agent 平台架构有直接借鉴价值的。
1. Autonomous Event-Driven Multi-Agent Orchestration for Enterprise AI at Scale（企业级事件驱动多智能体编排）
🔗 https://arxiv.org/abs/2606.20058
💡 一句话：在 208 个真实企业场景上对比了 DAG Plan-and-Execute 和 ReAct 两种编排范式，并提出一个带"优先级推断 + 相关任务关联"的 Task Manager，把多智能体系统从离散请求-响应推到持续事件监听。覆盖 Persona（<10 agents）、Department（20–80）、Enterprise（200）三个规模。
🎯 关联：最强相关。这就是 InternOS 要解决的问题原型——跨部门、多 agent、连续事件流的调度。208 场景的实验数据可以直接拿来对照你"7 Kernel + 跨订单调度"的设计选择，特别是 Task Manager 那块的优先级推断逻辑值得抄一抄思路。
2. Beyond Global Replanning: Hierarchical Recovery for Cross-Device Agent Systems（跨设备 Agent 的分层故障恢复）
🔗 https://arxiv.org/abs/2606.20487
💡 一句话：现有多设备 agent 系统在子任务失败时只会粗粒度地重试/重分配/全局重规划，这篇提出 device-local 策略空间建模，做分层恢复——本地能修就不动全局计划。
🎯 关联：直接对应你之前讨论的"承诺跟踪机制"——一个 agent 答应了的事失败了，怎么处理？这篇给出了一个不是"全推倒重来"的中间层方案。InternOS 如果未来要做容错，这是必读。
3. The Orchestration Gap: Why Process Automation Stalls in Operationally Complex Industries（编排鸿沟：为什么 Agent 自动化在复杂业务领域卡住）
🔗 https://arxiv.org/abs/2606.19790
💡 一句话：作者直接开炮——agent 系统在物流、医疗、建筑这些"工具碎片化 + 多人协作"的行业落地不行，不是模型不够强，是缺少 orchestration 这一层抽象。文章定义了 orchestration runtime 应该长什么样。
🎯 关联：观点文，但很对你胃口。你跟领导汇报 InternOS 价值时，这篇的论点框架可以直接借用：价值不在单个模型调用，而在运行时的多步协调。
4. PACMS: Submodular Context Selection as a Pluggable Engine for LLM Agents（用子模函数做上下文选择的可插拔引擎）
🔗 https://arxiv.org/abs/2606.20047
💡 一句话：Agent 的 context window 同时被 user 对话、persistent memory、工具调用结果三路灌满，超出后就要裁剪。PACMS 用子模优化做了一个可插拔的上下文选择层，独立于 agent 主体。
🎯 关联：InternOS 里 agent 多了以后必然要面对 context 爆炸问题。"可插拔"这个设计原则跟你"不重构、保持 7 Kernel"的哲学一致——这种横切关注点应该是独立组件而不是塞进 kernel。
5. Connect the Dots: Training LLMs for Long-Lifecycle Agents with Cross-Domain Generalization Via RL（训练长生命周期 Agent 跨域泛化）
🔗 https://arxiv.org/abs/2606.20002
💡 一句话：定义了一个 meta-capability —— "Connect the Dots"：agent 在环境里跑很久，要持续探索、从经验里学、自更新上下文。用 RL 训练这个能力，并且跨域可迁移。
🎯 关联：和你之前关心的 "agent 记忆/长期演化" 直接对应。InternOS 里 agent 不是一次性任务，是常驻角色——这篇给的是长生命周期 agent 训练范式，值得作为未来路线图参考。
6. AtomMem: Building Simple and Effective Memory System for LLM Agents via Atomic Facts（基于原子事实的 Agent 记忆系统）
🔗 https://arxiv.org/abs/2606.19847
💡 一句话：现有 memory 系统粗粒度、不稳定，要么表示低效要么更新无约束。AtomMem 把记忆拆成"原子事实"为最小单位，强调 simple & effective。
🎯 关联：你说过"存记忆里就存记忆里"——但 InternOS 多 agent 之间共享记忆迟早要面对一致性问题。原子事实这个粒度选择，是个比 RAG chunk 更可控的方案。可以作为 memory 模块设计时的备选范式。
7. Probe-and-Refine Tuning of Repository Guidance for Coding Agents（探查-精调：给 Coding Agent 的 repo 操作指南）
🔗 https://arxiv.org/abs/2606.20512
💡 一句话：Coding agent 需要"高于代码层"的 repo 知识（哪个文件属于哪个子系统、测试怎么跑、历史上哪些 workflow 出过错），工程师靠 AGENTS.md 提供这些指引——但效果有争议。这篇做了 probe-and-refine 的方法学。
🎯 关联：和你给朋友讨论的 AI sandbox 方案有交集。如果 sandbox 里要跑 coding agent，怎么把"项目隐性知识"喂给它是绕不开的工程问题。这篇给的是方法论，不是产品。
今日观察：这一周编排（orchestration）相关论文密集出现，特别是 #1 和 #3 都在讲"多 agent 真正难的是 runtime 协调而不是单 agent 能力"——这跟你 InternOS 的核心 thesis 完全吻合。建议优先读 #1 的实验设计部分，#3 的论点框架可以直接搬到你下次内部汇报里。