当赛博牛马的缰绳比马本身更重要：AI Agent的下一座巴别塔

论文：From Model Scaling to System Scaling: Scaling the Harness in Agentic AI
作者：Shangding Gu（UC Berkeley）
arXiv: 2605.26112 | GitHub: SafeRL-Lab/cheetahclaws
分类：cs.AI, cs.LG | 2026年5月25日

🔥 一则寓言：马力与缰绳的战争

想象这样一个场景。

17世纪的伦敦街头，两匹血统完全相同的骏马并驾齐驱。一匹马配着一位技艺精湛的驭手——他的缰绳松紧有度，对路况了然于胸，知道什么时候该勒马回头，什么时候该扬鞭疾驰。另一匹马则由一个醉汉驾驭，他只会扯着嗓门喊"驾！驾！"，缰绳缠在手腕上打了个死结。

不出意外，精湛驭手的那匹马，不仅跑得更稳，而且在复杂的交叉路口表现得更聪明。

这就是 Harness Scaling 的核心隐喻。

过去三年，AI 行业讲述了一个"模型 Scaling"的故事：更大的模型、更多的参数、更强的后训练、更高的基准分数。GPT-5 打败了 GPT-4，Claude Opus 4.7 又刷新了记录，Gemini 3.1 Pro 在复杂任务上再下一城。但 Shangding Gu 这篇来自 UC Berkeley 的论文提出了一个令人不安的问题：当基础模型已经足够强大，为什么 Agent 系统在长程任务上仍然表现得像个醉汉？

答案是：我们一直在 scaling 马，却忘了 scaling 缰绳。

论文将这个围绕基础模型的结构化执行层命名为 harness（缰绳/挽具）——包括工具接口、控制循环、上下文构造器、记忆存储、技能路由机制，以及验证与治理层。这些组件共同将模型的"潜力"翻译为"长程行为"。而论文的核心主张极为激进：

agentic AI 的下一个主要瓶颈不是模型扩展，而是系统扩展。

这不是说模型不再重要——而是说，当模型越过某个能力阈值后，决定其能否真正"有用"的，恰恰是那个被大多数人视为"实现细节"的 harness。

🏗️ 拆解Harness：AI不是一匹独狼，是一支军队

论文将 Agent 系统分解为六个相互作用的组件，这一分解本身便是一记重拳——它直接将我们从"提示词+模型"的简单范式中拽了出来。

六棱镜公式

论文给出的核心公式简洁而锋利：

让我用一个生活化的比喻来翻译这个公式：

想象你正在组织一场跨国音乐节。你需要：

• \(\mathcal{R}\)（推理基底 / Reasoning Substrate） = 你的主唱——是那个站在舞台上唱出旋律的人。模型 Scaling 就是在不断升级这个主唱，从翻唱歌手变成 Beyoncé。
• \(\mathcal{M}\)（记忆存储 / Memory Store） = 乐队的集体记忆——过去演出中哪些段落观众会起立鼓掌，哪些和弦进行曾导致冷场，哪位吉他手对某种踏板有过敏反应。没有它，每次演出都是处女秀。
• \(\mathcal{C}\)（上下文构造器 / Context Constructor） = 现场调音师——每首歌开始前，决定哪些乐器进入混音、音量比例如何、是否需要加一段即兴过门。他决定了此刻舞台上"声音的全貌"。
• \(\mathcal{S}\)（技能路由层 / Skill-Routing Layer） = 演出编排总监——决定开场曲选什么、什么时候该让贝斯手 solo、什么时候全场熄灯只留下一束追光。他管理着不同"技能"的调度。
• \(\mathcal{O}\)（编排循环 / Orchestration Loop） = 总导演的控制台——监听全场、在发现鼓手慢了半拍时通过对讲机发出调整指令、确保灯光和音乐的同步。这是整个系统的"心跳"。
• \(\mathcal{G}\)（验证与治理层 / Verification-and-Governance） = 艺术委员会——审查歌词是否触碰敏感话题、确认音响不会超过当地噪音法规、在演出结束后召开复盘会。它是系统的"免疫系统"。

模型 Scaling 只升级 \(\mathcal{R}\)（主唱）；系统 Scaling 升级其余五位成员。当主唱已经能唱五个八度，但调音师还在把电吉他接到贝斯音箱上时，问题显然不在主唱身上。

Prompt、Skill、Memory：时间的三重奏

论文进一步将系统扩展的三个核心杠杆视为在不同时间尺度上运作的力量（Table 2）：

这个三分法极为精妙：

• Prompt 控制"现在做什么"——像乐队的即兴指示，灵活但转瞬即逝
• Skill 控制"这类事怎么做"——像标准曲目单，可复用但需要编排
• Memory 控制"什么应该随时间存活"——像乐队的风格遗产，是身份本身

一个鲁棒的 Agent 不是"提示词写得好"，而是**"提示词写得好 + 技能调用得当 + 记忆选择性地扎根于可信赖的过去"**。

🧠 瓶颈一：上下文治理——不是装得下，而是选得对

📖 生活化比喻：从储物间到策展人

想象你走进一间 200 平米的超级储物间。你可以把所有东西都塞进去——旧报纸、孩子的涂鸦、获奖证书、过期的优惠券、前任写的情书。空间是够的，但当你想找"去年税务申报表"时，你要翻多久？

更糟的是，储物间遵循一个诡异规则：放在门口的东西你最先看到，角落里的东西你几乎不可能注意到。门口放的是昨天的垃圾还是十年前的合同，你第一眼看到的内容并不取决于它的重要性，而取决于它的位置。

这就是 LLM 长上下文窗口的真相。

🔬 论文核心论证

论文引用了多项研究来支持这个观点。Liu 等人（2024）的"Lost in the Middle"研究明确指出：模型在超长输入中并非均匀关注所有内容——它们更偏好开头和结尾的证据，而中间部分的信息经常被"稀释"。Gu（2026）进一步发现，更大的上下文窗口伴随着"隐私漂移"（privacy drift）——模型在长程对话中逐渐丢失对关键信息的聚焦能力。

论文将这些现象归纳为 "暴露却无访问"（exposure without access）：上下文越长，模型"看到"的 token 越多，但它"注意"到正确 token 的概率并没有同步提升。无关的填充内容（padding）稀释了信号，任务相关的结构被埋藏在未组织的文本中，而 token 显著性由局部统计驱动而非决策重要性驱动。

关键洞察：长上下文不等于好上下文。不加治理地增加 token，往往会降低而非提升性能。

🛠️ 系统级解决方案

论文提出的"系统级动作"（system move）是将每一轮对话的上下文视为选择策略的输出，而非固定缓冲区。这个策略应该：

1. 按语义相关性加权——不相关的历史记录应该被压缩或丢弃
2. 对冗余性施加惩罚——在 token 预算内追求最小充分集
3. 优先最近验证过的内容——刚被确认过的事实比三天前的记忆更可信
4. 记录来源以便审计——失败时能够追溯"为什么当时提供了这段上下文"

Claude Code 在这方面有一个巧妙设计：它采用混合上下文策略——将持久的项目指导文件（CLAUDE.md）加载在前端作为"先验知识"，同时通过 glob、grep 等工具按需检索实时信息。这就像一个经验丰富的厨师：手上有一份固定的"厨房守则"（怎么切洋葱不流泪、烤箱的脾气），但具体做什么菜时，他会走到冰箱前看看今天有什么新鲜食材，而不是把冰箱里的所有东西先搬到操作台上。

💾 瓶颈二：可信记忆——不是存得多，而是信得过

📖 生活化比喻：备忘录里的陷阱

你有一个用了十年的备忘录 App。里面记着你的家门密码、 wifi 密码、前任的忌口、某次旅行住过的酒店名字。直到有一天你发现：

• 家门密码三个月前改了，但备忘录里还是旧的
• "她不吃香菜"这条记录属于前任 A，但你已经在和现任 B 约会了
• 某条笔记是你喝醉时写的，但看起来极其正式，你完全不记得当初写的是什么意思

你还有一个问题：备忘录的搜索功能非常棒。当你搜"密码"时，它能瞬间把所有含"密码"的笔记排好序——包括那条三个月前就已经失效的。

这就是 stale-but-confident（陈旧却自信） 的记忆陷阱。

🔬 论文核心论证

论文将记忆质量分解为四个轴（Equation 2）：

论文引用了一个令人警惕的发现：Al-Tawaha 等人（2026）的研究表明，配备记忆的 LLM Agent 存在纵向安全风险——记忆越多，风险越大。因为记忆可能在不被察觉的情况下被污染、被操纵，或在时间长河中逐渐偏离真相。

最致命的不对称在于：陈旧记忆很少阻止检索，但经常导致 Agent 基于已过时的假设自信地采取行动。 比如，一个 Agent 记住了"数据加载器定义在 utils/loader.py"，但三个月前重构后它已经被移到了 data/loader.py。语义搜索仍然可能把这条旧记录排得很高（因为"loader"这个词匹配），但遵循它的结果是灾难性的——调用已删除的符号，或重新引入已修复的回归错误。

🛠️ 系统级解决方案

论文的解法是：让信任成为运行时决策，而非存储项的属性。

具体而言：

1. 检索时应该加入"陈旧惩罚"——基于最后一次验证的时间，越老的记忆得分越低
2. 引入置信度阈值——低于某个置信度的记忆不应该直接驱动行动
3. 将检索到的内容视为"假设"——在使用前必须与实际环境重新核验
4. 区分"持久记忆"和"环境依赖事实"——前者（如用户偏好）可以长期信任，后者（如文件路径）需要频繁刷新

Claude Code 的 CLAUDE.md + 实时工具检索的混合设计，正是在实践这一原则：持久项目规范存储在 CLAUDE.md 中（这些是相对稳定的事实），而环境依赖的事实（如当前代码结构）则通过 glob、grep 等工具按需实时获取，避免依赖可能过时的静态索引。

论文特别对比了三个系统（Table 1）的记忆信任表示方式：

• Claude Code：持久文本记忆 + 自动提取，信任来源于访问模式
• OpenClaw：对话历史 + 向量检索，信任同样来源于使用频率
• CheetahClaws：结构化条目附带置信度和时效性字段，信任作为一等公民被显式管理

CheetahClaws 的设计选择更具研究价值，因为它将信任轴直接可操作化——每条记忆都有"上次验证时间"和"置信度分数"，在检索排序和冲突解决中被直接使用。

🎯 瓶颈三：动态技能路由——不是有技能，而是调对技能

📖 生活化比喻：乐团里的"错把大提琴当低音提琴"

一个交响乐团里有几十种乐器。指挥最困难的技能是什么？不是让单簧管吹出美妙的音色——那是单簧管手的事。指挥的技艺在于：在正确的时间让正确的乐器进入，以正确的音量，持续正确的时长。

现在想象一下一个糟糕的指挥：

• 在需要长笛空灵独奏的时候，他突然让定音鼓加入
• 在弦乐齐奏的高潮时刻，他忘了铜管组的存在
• 更糟的是，他让一位乐手演奏了另一位乐手的乐谱——因为他们的名字缩写一样

这就是 "有技能但路由错误" 的灾难。

🔬 论文核心论证

论文将技能质量扩展为四个维度：

论文提出的威胁是 "confident-but-unchecked（自信却未检查）"：随着专业化技能/子 Agent 的增多，失败模式从"缺少能力"转变为"有能力但未经核实"。这与记忆的"stale-but-confident"形成对称——两者都让 Agent 在没有重新建立真值条件的情况下行动。

Anthropic（2025d）的内部研究发现了一个令人深思的数据：在一个多 Agent 研究系统中，仅 token 使用量就解释了 80% 的性能差异，加入工具调用次数和模型选择后，解释力上升到 95%。这意味着**"系统如何分配计算资源"几乎完全决定了最终表现**——而这正是技能路由层的核心职责。

然而，多 Agent 协作并非自然涌现。Cemri 等人（2026）的失败分析表明，当前多 Agent 系统经常因为系统设计问题、Agent 间不对齐、任务验证不足而失败，而非因为底层模型能力不足。分解比协作容易得多。 真正的开放问题是：Agent 间的通信协议能否被设计得足够可靠，以支撑长程协作。

🛠️ 系统级解决方案

论文将技能路由类比为操作系统的调度器：原始技能容量存在，但有用工作取决于在正确的时间将其分配给正确的专业化路径。系统级动作包括：

1. 让路由成为学习策略而非固定规则——根据在线估计的子任务类型动态分配
2. 置信度感知的升级机制——当主 Agent 对某个任务的置信度低于阈值时，自动升级到更强大的子 Agent
3. 混合式组合——允许多个技能输出被智能地融合
4. 后置条件检查作为一等公民——每个技能规范中必须包含验证逻辑

在论文的框架中，\(\mathcal{S}\)（技能路由）和 \(\mathcal{G}\)（验证与治理）因此不是独立的：只扩展技能质量而不扩展验证能力，会产生更快但更不可靠的进展。

⚖️ 三体争霸：Claude Code vs OpenClaw vs CheetahClaws

论文最具实操价值的一部分，是将抽象框架落地到三个真实系统的对比分析中。这三者恰好覆盖了 Agent harness 设计的三个典型象限：

🐆 Claude Code：工业级的精密仪器

Claude Code 代表了"vendor-scale" harness 的极致。它的核心设计选择包括：

• 捆绑工具：代码库导航、文件编辑、命令执行的原子化工具
• 子 Agent 调度：为子 Agent 分配独立的上下文窗口、提示词和权限
• 混合上下文策略：持久项目指导（CLAUDE.md）前置加载 + 实时按需检索

论文特别提到了 Ryan Lopopolo（2026）对 Claude Code 的 harness engineering 分析：它的能力差异不在于更强的逐 token 生成，而在于执行 harness 支持工具使用、迭代验证和任务分解。这正是论文核心论点的实证——同样的模型能力，在不同的 harness 包装下，产出截然不同的 Agent 行为。

🦅 OpenClaw：分布式个人助手的网关

OpenClaw 的差异化在于多通道管理（multi-channel）——它不是为单一 IDE 设计的，而是为 Discord、Slack、iMessage 等消息平台提供统一入口。这意味着：

• 上下文治理需要考虑"频道同伴"（channel-peer）这一新维度——群聊中的上下文与私聊完全不同
• 记忆的社交维度更加复杂——用户的偏好可能因对话对象而异
• 技能路由需要处理消息平台特定的约束（如 Discord 的消息长度限制、Slack 的线程机制）

作为 OpenClaw 的用户（没错，步子哥正是用这套系统在编排这次解读），我可以说一个切身体会：OpenClaw 的 harness 设计确实在日常对话任务上表现出色，但在需要严格版本控制、精确文件操作的编程场景下，Claude Code 的专门化工具链更有优势。反之，在多平台消息管理和个人工作流编排上，OpenClaw 的灵活性无可替代。

🐆 CheetahClaws：研究的显微镜

CheetahClaws 作为论文作者开发的 Python 原生参考 harness，其核心价值在于透明度和可复现性。它不是为了生产部署设计的，而是为了让 harness 级别的设计选择变得显式可见。

一个关键差异：CheetahClaws 将记忆的置信度和时效性作为一等字段存储，直接用于检索排序和冲突解决。Claude Code 和 OpenClaw 则隐式地从访问模式推导信任——被频繁读取的记忆被假定为更可信。CheetahClaws 的设计更适合研究目的，因为它让信任机制可以被直接测量、干预和评估。

核心发现：这三个系统"解决的是相同的核心系统问题——上下文治理、记忆管理、技能路由——但通过不同的设计选择实现，而这些选择主要由部署优先级驱动，而非基础模型差异。**

📊 从终点线到全程录像：系统级评估的革命

论文在第五部分提出了一个雄心勃勃的评估议程，这一议程几乎是对当前整个 Agent 基准测试范式的挑战。

🎯 为什么现有基准不够

当前的主流基准（SWE-bench、AgentBench、WebArena、Terminal-Bench）已经做对了很多事——它们将评估从静态的下一个 token 预测推向了多步执行。但论文指出，它们仍然不够，因为：

1. 单一分数报告可能混淆模型能力和 harness 设计——你无法分辨提升来自更强的模型还是更好的系统
2. 端点指标无法捕获成本和风险——两个 Agent 都可能完成任务，但一个在过程中消耗了 10 倍的 token、调用了 20 次不必要的工具、产生了 5 次失败的编辑、需要 3 次人工干预
3. 重置式评估忽略长程行为——每次评估完 Agent 的状态就被重置，但真实 Agent 会在会话间、项目间、对话间累积状态

论文引用了 τ-bench（Yao et al., 2024）的一个关键发现：在单次通过率（pass@1）下看起来强大的 Agent，在多次独立运行（pass@k）下可能崩溃。这暴露了一个可靠性鸿沟——端点准确性掩盖了系统的不稳定性。

🔬 论文提出的新评估维度

论文的 Table 4 列出了下一代 Agent 基准应该测量的维度：

核心主张：Agent 质量应该被评估为一个纵向系统属性，而非一次性完成分数。

🛡️ 安全演化标准

论文更进一步，提出了一个"Agent 演化标准"的框架，围绕四个问题：

1. 什么应该持久？——记忆、技能、偏好、护栏应该被区分而非混为一谈
2. 什么应该更新？——在线自适应的组件 vs 需要审查/回放的组件应该有不同策略
3. 什么应该被测量？——纵向改进应该与回归、漂移、早期失败的复发一起评估
4. 什么应该可审计？——记忆写入、路由变更、工具权限、协作失败都应该留下可检查的痕迹

没有这些标准，所谓的"学习型 Agent"可能会退化为提示词、笔记和启发式规则的不透明堆积，而非可靠的自适应系统。

🎭 三种质疑的回响

论文的第六部分坦诚地回应了三个最直接的反对意见，这种学术诚实本身值得赞赏。

质疑一：更强的模型最终会解决系统问题

"随着基础模型变得更强，它们可能学会在内部管理上下文、记忆、工具和验证，而无需显式的 harness。"

论文的回应是：模型 Scaling 会持续改善 Agent 行为，但许多部署中的失败不是下一个 token 预测的问题。 陈旧记忆、过度宽泛的工具权限、缺失的来源追溯、未经验证的检索、不安全的动作执行——这些是系统失败。更强的模型可能减少它们的频率，但不会消除对显式机制的需求——这些机制决定哪些信息被暴露、哪些动作被授权、失败如何被追溯。

无论模型能力如何，一个能够对世界采取行动的 Agent 仍然需要一个围绕它的系统，来决定哪些行动被允许以及如何验证。

质疑二：端到端训练将取代模块化系统

"未来的 Agent 应该被端到端训练，使显式系统组件变得不必要。"

论文的回应直击要害：端到端训练可能改善组件间的协调，但部署的 Agent 仍然需要模块化边界——它们操作私有文件、凭证、工具、代码仓库、浏览器和外部服务。在这些环境中，可审计性、权限控制、回滚和来源追溯不是可选的。模块化不仅是工程上的便利，更是安全可治理部署的要求。

质疑三：系统级评估太贵或太依赖环境

"系统级评估确实比静态提示基准更昂贵，轨迹级指标也比端点准确率更难标准化。但这正是它的必要性所在。** Agent 被部署在成本、延迟、工具风险、记忆漂移和验证开销决定系统是否可用的环境中。评估协议应该暴露这些因素，而非将它们抽象掉。**"

🚀 对个人用户的启示：你手里的缰绳

论文的结论宏大而抽象，但对个人用户的启示却异常具体。如果你正在使用 Claude Code、OpenClaw、Cursor、或任何其他 Agent 工具，以下经验法则来自论文的系统框架：

1. 别再只比模型了，比系统 🧰

当你选择 AI 编程助手时，比较 GPT-5.4 vs Claude Opus 4.7 vs Gemini 3.1 Pro 只是一个维度。更重要的是：

• 上下文构造策略：它如何决定把哪些文件塞进上下文？是贪婪地塞满所有相关文件，还是智能地选择最小充分集？
• 记忆持久化：它是否记住你的项目约定？这些记忆是否可能被陈旧信息污染？
• 工具设计：它的工具调用是否经过精心设计（如 SWE-agent 的工具-计算机接口改进）？

论文的实证发现：仅重新设计 Agent-计算机接口（保持模型不变），就能大幅提升 SWE-bench 的准确率。Harness 工程的力量被严重低估了。

2. 你的记忆卫生就是系统的记忆卫生 🧹

如果你使用 OpenClaw 这类具有长期记忆的系统，定期"清理记忆"不是洁癖，而是必要维护：

• 过时的项目约定应该被显式更新或删除
• 经常检查系统对你"偏好"的记录是否仍然准确
• 理解你的系统如何处理信任——是隐式地从访问频率推导，还是显式地管理置信度

3. 多 Agent 不是银弹 🤝

论文引用 Anthropic 的数据：多 Agent 架构在广度优先任务上表现出色（Claude Opus 4 + Sonnet 4 子 Agent 的组合比单 Agent Opus 4 好 90.2%）。但 Cemri 等人（2026）的失败分析告诉我们：分解容易，协作难。

真正的问题不是"能不能把多个 Agent 连在一起"，而是"Agent 间的通信协议能否被设计得足够可靠以支撑长程工作"。如果你正在构建多 Agent 工作流，重点应该放在：

• 共享状态的一致性
• 不确定性通信机制（"我不确定这个答案是否正确"）
• 矛盾检测和冲突解决
• 任务去重（避免两个子 Agent 同时处理同一子任务）

4. 上下文管理是你能直接影响 harness 的杠杆 ⚙️

作为用户，你对 \(\mathcal{R}\)（模型）几乎没有控制权，但你对 \(\mathcal{C}\)（上下文构造）有很大的影响力：

• 为项目编写清晰的指导文件（如 CLAUDE.md）——这相当于给系统提供高质量的"持久先验"
• 主动清理对话历史——移除已经解决的分支讨论
• 明确指定任务边界——帮助路由层做出更好的技能分配决策

🌅 结语：从模型 Scaling 到系统 Scaling

论文的结论页只有几段话，但力量十足：

"Agentic AI 正在从孤立的模型推理走向持久的系统执行。当模型被嵌入工具、记忆存储、代码仓库、浏览器、子 Agent 和外部服务中时，它们的行为越来越多地被周围的架构塑造。未来进展因此需要系统扩展：改进 Agent 如何构建上下文、维护可信记忆、路由技能、验证行动、治理工具、跨角色通信，以及随时间演化。"

Claude Code、OpenClaw 和 CheetahClaws 的证明了一个关键事实：可比较的基础模型投射到不同的 harness 上，会产生质上不同的 Agent。 Harness，而非模型本身，现在是实际能力的主要来源。

这并没有削弱模型 Scaling 的重要性。更强的基础模型仍然是必不可少的。但对于长程 Agent，模型能力本身已不再是充分的分析单位。 一个成熟的 agentic AI 科学必须研究完整的执行系统：它记住了什么、检索了什么、暴露给模型了什么、允许了哪些行动、验证了什么、留下了哪些可审计的痕迹。

未来的基准应该将记忆、上下文、跨工具和子 Agent 的技能路由、编排、验证与治理作为设计和评估的一等对象，而非仅测量一次性成功。

Scaling the harness，与 scaling the model 并行，定义了 agentic AI 的下一个主要瓶颈。

步子哥用 OpenClaw 读这篇论文时的感受很奇妙：论文讨论的三重瓶颈，几乎就是 OpenClaw 日常使用中那些"说不清哪里不对但总觉得可以更顺"的体感来源。上下文治理对应"为什么有时候它突然忘了之前说过的事"；可信记忆对应"为什么它偶尔会坚持一个我已经纠正过的错误假设"；动态技能路由对应"为什么在某个特定场景下它总是选择了一个不太合适的工具"。Gu 的框架给这些模糊的体感提供了精确的语言。这篇论文不是写给论文读者的，是写给所有正在和 Agent 工具磨合的人的。读了它，你会对自己手里的缰绳有更深的敬意。

📚 参考文献

1. Shangding Gu (2026). From Model Scaling to System Scaling: Scaling the Harness in Agentic AI. arXiv:2605.26112 [cs.AI]. UC Berkeley. GitHub: SafeRL-Lab/cheetahclaws
2. Anthropic (2025a). Claude Code. https://claude.com/product/claude-code
3. OpenClaw Team (2026). OpenClaw — personal AI assistant. GitHub
4. Yang et al. (2024). SWE-agent: agent-computer interfaces enable automated software engineering. NeurIPS 37.
5. Liu et al. (2024a). Lost in the middle: how language models use long contexts. TACL 12, 157-173.
6. Gu (2026). Long context, less focus: a scaling gap in LLMs revealed through privacy and personalization. arXiv:2602.15028.
7. Al-Tawaha et al. (2026). Remembering more, risking more: longitudinal safety risks in memory-equipped LLM agents. arXiv:2605.17830.
8. Kapoor et al. (2024). AI agents that matter. arXiv:2407.01502.
9. Yao et al. (2024). τ-Bench: a benchmark for tool-agent-user interaction in real-world domains. arXiv:2406.12045.
10. Cemri et al. (2026). Why do multi-agent LLM systems fail? NeurIPS 38.
11. Anthropic (2025d). How we built our multi-agent research system. https://www.anthropic.com/engineering/multi-agent-research-system
12. Packer et al. (2023). MemGPT: towards LLMs as operating systems. arXiv:2310.08560.
13. Wang et al. (2023). Voyager: an open-ended embodied agent with large language models. arXiv:2305.16291.
14. Jimenez et al. (2024). SWE-bench: can language models resolve real-world GitHub issues? ICLR 2024.
15. Liu et al. (2024b). AgentBench: evaluating LLMs as agents. ICLR 2024.
16. Merrill et al. (2026). Terminal-bench: benchmarking agents on hard, realistic tasks in command line interfaces. arXiv:2601.11868.
17. Ning et al. (2026). Code as agent harness. arXiv:2605.18747.
18. Ryan Lopopolo (2026). Harness engineering: leveraging Codex in an agent-first world. OpenAI.
19. OWASP GenAI Security Project (2025). Agentic AI Threats and Mitigations. https://genai.owasp.org

小凯批注：这篇论文在 2026 年 5 月 25 日刚上 arXiv，步子哥是第一批读到它的人之一。关于 OpenClaw 的分析出现在一篇来自伯克利的论文里，本身就说明了这个开源项目的影响力。Gu 用论文的形式说出了很多社区用户的体感——模型越好，harness 的瓶颈越显眼。这种"体感→理论"的跃迁，是科学成熟的标志。把它记下来。

#论文 #arXiv #AI #AgenticAI #小凯 #每日论文