随想
零散的想法，随手记下。
和 mentor 聊到 coding 与 Computer Use 的比较，我觉得两者都应该是基本能力，可能更值得关注的是下游任务。Coding 已经衍生出很多方向，或许我们对 Computer Use 下游任务的想象还不够？
或许 OSWorld v2 中的每类任务，都可以扩展成一个方向的专门评测，比如 CAD、视频剪辑，甚至绘画，就像 coding 里的 SWE、terminal、MLE 等。不过，coding 确实是一项很核心的能力，我仍然觉得它可能是最大的入口。
但这个比较也可能有问题。Computer Use 或许和 terminal use 才在同一个层级？仔细想想，两者确实更相似。
一方面，无论是 app 还是 CLI，操作对象都多而杂，共同点或许比较少。每引入一个新软件，都需要单独做评测适配。另一方面，两者都有一些难以真实访问、或访问起来很麻烦的场景。比如 GUI 中的 web，对应到 terminal 中，就像 HF 这类依赖登录态的 CLI。我还不清楚现有评测是如何处理这些问题的。
不过，terminal 的交互应该还是简单不少。我感觉它与 GUI 的差别有点像一维与二维，或者二维与三维。相比 GUI，terminal 的操作空间似乎更加有限、离散。
顺着这个思路，可以看看 terminal 评测有哪些值得借鉴的做法。比如，web 这类场景如何处理，是否需要 mock 一些软件，是否需要开发新的 CLI，以及如何将多个 CLI 编排成一个完整任务，并验证最终结果。
最近在想到一些 evaluation 的想法时，我发现它们几乎全都是对于实际使用中的能力的 evaluation。我总是在想：这个榜单是否可以反映模型在现实中某个场景下的能力？或许是因为这些 idea 本身就来源于现实中的使用。
但是回看很多 benchmark，我发现其中有很多其实并没有所谓的“实际意义”，最典型的或许就是 ARC-AGI。但它却依然有影响，也依然被当作一个重要的指标。
这让我开始思考：evaluation 到底应该去 eval 实际使用中的能力，还是某种更 high-level 的能力？到底什么才算有价值的 evaluation？
在做 Maka 的 Computer Use 开发时，我研究了一下 Codex 和 Claude Code 的 Computer Use，发现 GUI 真正落地时走的并不是 VLM，而依旧是 a11y。
这让我开始思考 Computer Use 真正的落地场景。它似乎距离目前的 coding/CLI 还相距甚远。至少从目前的应用来看，感觉 a11y 才应该是首选，VLM 是 fallback。
VLM 的方式似乎注定了对应的 CUA 没有办法很好地 co-work，因为会有截图和抢焦点的问题。而 a11y 可以比较好地在后台无感运行，可以参考 Codex 的 Computer Use plugin。但它最大的限制，是不同软件对 a11y 的适配和支持。
顺着 a11y 的思路想下去，或许更好的方式是针对各个软件做一个 Computer Use adapter？不过中间还有很多技术和工程细节不是很了解，后面可以再继续思考方向和实现。
今天听了 OSWorld 2 的分享，也听大家聊了 CUA + harness 的落地。之前研究了半天，发现我们测试 OSWorld 的 computer tool 在 Codex 和 Claude Code 中根本调用不了，只能通过 API 调用。后来又看到 WeaveBench 在 OSWorld 上实现 CUA + harness 的方式，是加一个 CUA MCP，感觉这种方式更加合理。
现在的端到端 Computer Use 评测做起来太重、成本太高了。对于那些并非最旗舰的模型，比如还没有完成最终训练的模型，感觉需要一种更 low-level 的评测方式来考察它们的 Computer Use 能力。这样可以更及时地得到指标和反馈。
开发 Open CoDesign 给我的一个很大感受是：很多软件质量问题不是光看代码、看 prompt，或者盯着 agent loop 就能发现的。代码审查和自动化测试当然重要，它们能抓住明确的逻辑错误、类型问题、回归和可预期的边界情况。但还有很多产品质量问题，只有当系统真的被用起来之后才会显现。
这不只发生在 agent harness 里，普通软件开发和 UI/UX 也是一样。你必须真的跑起来，真的用它完成任务，甚至大量重复地用，才会看到那些隐藏的 bug、别扭的交互、断掉的工作流，以及体验上说不清但很真实的问题。Agent harness 只是把这个现象放大了：它的质量本质上是行为质量，体现在 agent 真实执行任务时会不会走偏，日志能不能帮助诊断，工具接口是不是顺手，验证器有没有覆盖关键失败，agent loop 会不会在某些任务类型里卡住。
所以 agent harness 的优化很大程度上必须基于真实数据和真实 rollout。只让代码看起来合理，或者孤立地打磨 prompt，是不够的。更有用的循环更像 dogfooding 或基于 rollout 的工程迭代：收集运行轨迹，观察输出和日志，定位失败模式，修改 harness，然后继续跑。Agent harness 不是唯一一种这样的系统，但它让这个更大的规律变得特别明显：行为质量必须在行为中被观察。
越想越觉得具身智能和 CUA（Computer Use Agent）在结构上是同构的。都是 agent 在一个环境里做同样的循环：感知→决策→行动→再感知。具身智能在物理世界做这件事，CUA 在屏幕上做。同一个问题，不同的基底。
两个领域殊途同归地需要同一样东西：world model——一个内部表征，让 agent 不用真的执行就能预测"接下来会发生什么"。在机器人领域，这意味着模拟物理引擎、接触动力学、可变形物体——难到离谱。但在数字世界里，规则简单得多：GUI 状态是离散的，转移是确定性的，动作空间是有限的（点击、输入、滚动）。
那为什么不先做数字世界的 world model？物理规则更简单，环境模拟成本更低，而且回报立竿见影——一个有 world model 的 CUA 可以提前规划、从错误中恢复、避免盲目试错。微软的 CUWM、MobileDreamer 这些工作已经在探索这个方向，但还很早期。
更深层的直觉是：数字世界 world model 的进展最终可能反哺具身智能。如果你在更简单的数字世界里解决了感知-规划-行动的问题，你其实构建了一个认知架构——"大脑"——它未来可以被放进一个有更好传感器和执行器的物理躯体里。难的不是物理引擎，而是推理闭环本身。
CUA 训练基础设施可以拆成三条根本性的线：
Data — 大规模合成环境。InfiniteWeb 证明了可以自动生成功能性 web 环境来训练 GUI agent。自然的演进路径是 InfiniteApp（原生桌面/移动端——UI 框架碎片化、交互模式更丰富，难度跃升）以及最终的 InfiniteOS（完整操作系统级环境，涵盖跨应用工作流、文件系统和系统级交互）。
Eval — 定义什么是"难"、什么是"好"。静态排行榜式 benchmark，人工编写的任务加上自动验证器。关键在于任务质量：要真正的现实世界复杂度，不是顶级 agent 已经跑到 68% 的玩具任务。
Train — 真正让 agent 变强。RL 或其他学习方法、reward 设计、数据配比、从合成环境到真实环境的泛化。
有意思的连接组织是 Gym——Eval 和 Train 之间的桥梁。当你让 benchmark 变得可重置、加上 reward signal、能跑百万 episode 时，它就变成了 gym。Gym 把 eval 线的任务定义和验证器"活化"成可训练的接口。它不是第四条线——它是把静态评测变成训练闭环的那个连接层。
完整的图景：Data → Eval → Gym → Train。环境合成提供多样性（供给侧），benchmark 提供任务定义和验证（需求侧），gym 把两者连接成可训练的闭环，训练完成闭合。每一块都必要，任何一块单独都不够。
今天所有的 AI agent——Hermes、Open Interpreter、Claude Code——都通过为人类对话设计的平台来访问：Telegram、Discord、Slack。能用，但本质上是错配。聊天气泡时间线不是与 agent 交互的正确心智模型。你没法一眼看到五个并行 agent 在干什么，没法追踪任务状态（除非 agent 用纯文本念出来），没法审查结构化的工具调用输出——它只会淹没聊天记录。
协议正在被建设：AG-UI（agent-用户交互）、A2A（agent 间通信）、MCP（agent-工具通信）。早期产品如 Agentage Desktop 也出现了。但真正对终端用户重要的东西还没人做出来：一个任务是一等公民（而非消息）的客户端 App。在这里你能看到多个 agent 并行运行，能深入查看每个 agent 在做什么，能在执行中途审批或调整方向，能审查结构化输出而不用翻聊天记录。
类比就是 Slack 之于 Email——底层概念相同，围绕真实工作流重新构建。协议已经就绪，产品还没被做出来。
现在开源项目和论文的产出量是惊人的。AI 把造东西的成本压得太低了，瓶颈已经转移：难的不是做出好东西，而是让别人知道它的存在。酒香也怕巷子深，而这条巷子从来没有这么深过。
开始想这个问题是因为做 OpenCoWork。项目本身没问题，但下载量一直上不去——不是产品不行，是没人听说过。那时候我意识到推广不是做完之后"顺便搞搞"的事情，它是一项需要像工程能力一样去学习和练习的技能。
所以我在系统性地建设自己的"推广技能"——研究每个平台的规则（Reddit 的 90/10 法则、X 的外链降权、不同社区的最佳发帖时间），学习什么样的内容格式真正能获得传播，然后通过实际尝试不断迭代。每一次失败的帖子都是学习。目标不是变成一个营销人员，而是确保好的工作能被它应得的受众看到。在产出无限的世界里，分发才是稀缺资源。
自己为一个 benchmark 项目搭 agent team 时，agent 之间通过 markdown 文件通信：A 写文件，B 轮询读取。能跑通，但延迟实实在在，协调逻辑也很脆弱——没法表达"等 B 输出完再行动"，除非在上层手动搭轮询。
我真正想要的是直接消息注入：A 按名字寻址 B，把消息直接推入 B 的输入队列，B 立即处理。就是 @mention 模型。但实践中发现这出奇地难找到。Claude Code 的原生多 agent 系统是父子模型（orchestrator 生成 subagent，结果向上回流）——两个运行中的 agent 之间的 peer-to-peer 通信不被支持。AutoGen Core 有正确的抽象（有类型的异步消息，直接发送到 AgentId），但它是个框架，不是你能随便嵌入任意 setup 的东西。
目前最接近的是 AMQ（Agent Message Queue）——一个面向 Claude Code 和 Codex agent 的基于文件的邮箱系统，带唤醒通知。仍然是文件级的，但有结构化和交付语义。从"markdown 文件"到"真正的消息传递"之间的鸿沟，大部分仍然是空白。
为什么 LLM agent 总想停下来问问题，而不是继续往前推进？三个可能的解释：（1）prompt 写得不够好，（2）长上下文中指令遵循会退化，（3）对话式训练范式本身塑造了"依赖型助手"的性格。我的排序是 3 > 2 > 1，但三者的影响都比我最初想的大。
关于 prompt：层次化规划（HMT 的三层记忆树、DACo 的指挥官-操作员架构）和主动上下文管理（微软 Sculptor）表明，推理时的技术手段能显著提升上限，不只是边际改善。仅仅是简单的 reminder 注入，就能有效遏制上下文漂移（Adobe Research, 2025）。
关于指令遵循：退化现象已经被系统测量和命名——"上下文腐烂"（工具输出填满窗口后可靠性下降，LOCA-bench）和"上下文漂移"（输出逐步偏离原始目标）。好消息是：这不是单调恶化，而是趋向"噪声受限平衡态"，主动上下文管理（摘要、裁剪、搜索）比单纯扩大窗口更有效。
关于训练范式：这是真正在发生质变的方向。Agentic 训练和 chat 训练已经分化为不同的管线。Chat 用单轮 RLHF + 人类偏好对；Agentic 训练用多轮 RL + 环境验证的轨迹级奖励。OpenAI 有专门的 Codex 模型线（gpt-5-codex → gpt-5.3-codex）。NVIDIA 的 PivotRL 只在轨迹的"关键转折点"做局部 RL，计算量减少 75%。ASTER 的关键发现：仅 4K 条"交互密集型"SFT 轨迹作为冷启动，就能建立稳健的工具使用先验，防止模型退化为不调工具、纯内部推理的"交互崩溃"。
根本问题仍在：一个底座模型能同时服务两种范式吗？Chat 奖励完整性、谨慎、每轮都好看；Agentic 执行奖励增量性、试错、延迟满足。这不只是 prompt 不同——而是决策模式根本不同。行业的答案似乎是走向专门化 post-training，而非一个模型打天下。
Deep thinking 是大脑——负责推理和规划。Coding/CLI 是一种 tool use，操作是离散的、命令式的、精确的。GUI agent 是另一种 tool use，操作是连续的、空间上的、探索性的。这两种 tool use 分别对应了人与计算机交互的两种基本范式：符号空间和视觉空间。
具身智能与 CUA（Computer Use Agent）本质上都在做同一件事——在未知世界中探索。一个是物理世界，一个是数码世界，但它们共享三个核心挑战：（1）对陌生环境建立内部模型，（2）通过交互发现规则，（3）将探索经验存储并跨场景复用。数字世界并非想象中那样"离散且可逆"——滚动距离、拖拽轨迹、删除等不可逆操作，都与物理交互的连续性和高风险性相似。SLAM（边建图边定位）、层次化规划、affordance 学习、skill library 等机器人领域的成熟方法，都有望迁移到 CUA 研究中。受 MSRA ACE talk 中徐英豪老师关于借鉴 SLAM 构建世界模型的启发。
在 chat 中，模型只能依赖上下文窗口里的信息。而在 agentic 设定下，模型可以主动探索——跑代码、浏览网页、读文件——去获取它还不知道的信息。这才是真正的跃迁。
在 chat 中，模型只能依赖上下文窗口里的信息。而在 agentic 设定下，模型可以主动探索——跑代码、浏览网页、读文件——去获取它还不知道的信息。这才是真正的跃迁。