周一下午，你把三份销售表格丢给 Agent，说：合并、算环比、做一页汇报用的 PPT。
这个任务不需要什么推理天才。模型完全知道环比怎么算，也知道一页好的汇报应该长什么样。但它会卡在一个非常朴素的地方：它到底能碰到什么。
如果它只能写代码，它会给你一段脚本，你自己跑、自己检查、自己发现第三份表里的日期格式不一样。
如果它能开浏览器，它可能会打开某个在线表格，一格一格地填，然后在第 14 步点错了一个下拉框。
如果它直接改文档对象模型，它会往单元格里写值，写完整片区域，再读回来验证一遍，然后把差异摆到你面前让你确认。
如果它只能看截图、移动鼠标，它很可能在第 7 步点偏了，然后非常自信地告诉你「已完成」。
同一个任务，同一级别的模型，这四条路径的成功率、成本、可审计性差了一到两个数量级。今天想聊的就是这几条路径本身，也就是 Agent 的操作层。
一、先说一个信号：Agent 不再被当作「一次请求」
今天 GitHub 趋势榜被 agent harness 包场，google/ax 一天涨了 1543 star。这个项目值得仔细看，因为它讲的不是 agent 怎么写，而是 agent 在哪里活。
AX 的定位是分布式 harness 运行时，背后有一个很实在的观察：agentic 负载本质上是突发型的。一个 Agent 可能密集计算一分钟，然后等人类审批，一等就是几个小时甚至几天。如果它是一个有状态的 actor，那你在这段空闲里一直在为它付钱。规模一大，这件事在成本上就不成立了。
而 Kubernetes 是为无状态微服务和可预测批处理设计的，它的抽象里没有「把有状态的沙箱 actor 挂起、之后再恢复」这件事。
所以 AX 的核心原语全是围绕这个缺口设计的：
- 事件日志：每一步输入、输出、状态变化都落盘，会话可以在任意时刻重新水合（rehydrate）。挂了能续，重启能接着跑。
- 单写者架构：在分布式工作流里，多个组件可能同时想改同一个会话状态。让一个控制器负责写，是避免状态腐坏最省事的办法。
- 快照与轨迹分支：可以在任意检查点把一条执行轨迹分叉出去，用来试不同路径、做评估，而且不丢上下文。
- 亚秒级恢复：挂起不是销毁，恢复时没有冷启动延迟，几十个任务复用同一个宿主 worker。
它在 Kubernetes 之上还定义了几个声明式原语：Task 管生命周期和资源约束，Workspace 管执行前的环境装配（挂 git 仓库、配 MCP、装 skill 包），Gateway 管沙箱的出站网络白名单和凭证注入，Model 收敛所有模型提供方参数。Google 同时开源的 Agent Substrate 走得更远，它的控制面是为「数亿次亚秒级工具调用」设计的，因为标准 K8s 控制面撑不住这个数量级的抖动。
这里的信息量不在于某个 API 设计，而在于：当大厂开始认真做这件事，说明生产环境的痛点已经从「模型答不好」变成了「跑得起来、挂了能恢复、出事能查证」。
但运行时只解决了「Agent 在哪跑」。真正决定它能干成什么活的，是下一层。
二、界面才是战场：三条路线正在分叉
路线 A：把界面变成原生运行时
Excel 这类软件一直有个尴尬：它很好用，但它的「好用」是给人眼和人手准备的。Agent 面对它，要么去模拟人点鼠标，要么去啃文件格式。
Univer 给出的是第三种答案。它的定位直接写在标题里：The Office Harness for AI Agents。它的做法不是让 Agent 学会操作 Excel，而是把表格、文档、幻灯片、画布、关系表、PDF 收进同一套运行时，一个 .univer 文件里可以同时装 Sheet、Doc、Slide、Base、Board 多种 Unit，公式和嵌入内容能跨 Unit 互相引用。一份文档引用了某个表格，表格改了，引用自动跟着变。
对 Agent 来说，这个变化是根本性的：文件从「要渲染出来的东西」变成了「结构化、可验证的数据对象」。Agent 改的是单元格的值、公式的引用、图表的绑定关系，而不是屏幕上的第几行第几列。它有一个 headless 的 Node.js 运行时，同一套逻辑能在服务端跑，不需要 UI。
更值得注意的是它的复核模型。每次写入发生在隔离的 worktree 里，人在对话里实时看着，然后选择 merge 还是 discard。多个 Agent 可以同时在同一个文件上干活，各自在自己的 worktree 里，最后由人审查合并。再配上 Git 风格的版本历史。
这就顺带把两个老大难问题一起解决了：Agent 不会静默覆盖你的当前版本，而且所有改动是结构化 diff，可以直接 code review。
结构化还有一个隐性红利。Univer 的演示文稿生成里有一个 lint 环节，专门检查文字超出页面、内容溢出、元素重叠。这种事在像素世界里只能靠人眼看，在结构化世界里它是几条规则。当你把操作对象从像素换成数据模型，验证的成本从「人审」变成了「断言」。
dsh-univer-office 这个 DeepSeek Harness 插件的流程很能说明问题：Agent 建文件、建 worktree、改一个 Unit、读回来验证、提交待审。你批准之后再让它导出 .xlsx 或 .pptx。整条链路里没有一次鼠标点击。
路线 B：在别人的网页上加一层中间层
但现实中大部分软件你改不了。真正的工作发生在别人的网页上：后台系统、SaaS 面板、内部工单。于是有了第二条路线。
这一路有两个代表，思路正好相反。
browser-use 是默认自主的：每一步把页面拍成一个带索引的元素树，交给模型决定动作，执行，再循环，直到任务完成或者撞到 max_steps。一句 Agent(task="...") 背后可能藏了十几个决策。它的强项是开放式任务，你没法预先枚举步骤的那种。
Stagehand 是控制优先的：它给你四个原语，让你自己写控制流。
act()执行一个动作，一次模型调用extract()按 schema 把页面上的数据抽成结构化的东西observe()把一句指令解析成具体动作，但先不执行。这一步是关键，解析结果可以缓存，之后重放不再调用模型agent().execute()真的需要自主时才用
Browserbase 自己给出的迁移指南里，把这个思想画成了一条确定性刻度，从高到底五级：全自主的 agent()、按步用 AI、observe 后缓存重放的 act、开启 self-heal 和缓存的稳定重放、以及纯导航的 page.goto。他们的建议很直白：健康的写法是混合，导航用 goto，重复的骨架用缓存动作，会变的部分用 act / extract，只把真正开放式的那一段留给 agent()。
为什么值得这么较真？看一组实测数据。有一个公开的对比基准，用同一个模型（gemini-3-flash-preview）在 9 个真实任务上各跑 5 次：
- token 量级：其中一个框架比 browser-use 少用 3.13 倍到 56.93 倍的 token，比 Stagehand 少用 1.42 倍到 13.33 倍
- 简单抽取任务：browser-use 中位数 43,838 token，对比工具 770 token，差了接近 57 倍
- 登录加登出：browser-use 114,796 token，对比工具 2,884 token，差了接近 40 倍
- 速度：browser-use 在 9 个任务里有 8 个是最慢的，常常慢 2 到 9 倍
这份基准的作者是他自己那个工具的作者，所以绝对数字要打折看。但需要谨慎的还不止立场：Stagehand 的旧模式在「登录加登出」这个任务上 5 次全挂，原因是它对 a 标签的 click 事件处理方式，换成 hybrid 模式能过，但 token 又涨到对比工具的 37 倍。browser-use 反而是 45 次全过。
即便打掉立场因素，数量级的差距在多个独立对比里都能看到。另一份三方对比给出的每任务区间是：Stagehand 1000 到 3000 token，Playwright MCP 1500 到 5000，browser-use 5000 到 15000。
我想强调的不是谁更好，而是结论本身：同一个模型、同一个页面，你把「模型决策权」放在哪一层，成本和稳定性就变一个量级。在这个赛道上，确定性不是质量属性，是成本属性。 而「全自主」这个默认值，在演示里很好看，在生产里很贵。
路线 C：看屏幕，移鼠标
有些软件你既改不了，也没有 API，连 DOM 都没有，比如桌面端的专业软件。只剩最后一条路：截图、找元素、点坐标。
这一路的数字非常难看。我列几个 2026 年的公开基准。
WindowsWorld 用 181 个任务覆盖 17 个桌面应用，其中 78% 天然跨应用（要从一个应用取信息，到另一个应用里产生结果）。结论是：所有 computer-use Agent 在跨应用任务上成功率都低于 21%。最好的配置（Gemini-3-flash 的 hybrid 模式）最终成功率 20.44%，但它的中间进度分有 50.32%。中间 30 个百分点的落差说明一件事：Agent 在「游荡」，子目标一个个完成，但汇总不成结局。规划链一拉长，成功率从 L1 的 35.90% 掉到 L3 的 16.67%。
DeskCraft 用 538 个长时序创作与工程任务评测了 18 个 Agent。最强模型标准任务 33.8%，带人在环交互的任务 27.6%。把尝试次数加多，pass@6 能涨到 45.6%，但 pass 的严格版本会掉，说明这是「间歇性成功」，而不是稳定解决。
WorldGUI 测的是非默认初始状态：软件已经被配置过、步骤已经被打过乱、界面和默认不一样。最强组合只有 45.8%，人类专家 85.3%。同一个任务，只把默认状态换成扰动状态，某个模型的成绩就从 50.0% 掉到 19.1%。
OSWorld 2.0 面向长时序专业工作流，任务的人类中位完成时间约 1.6 小时，每个 Agent 平均约 318 次工具调用。最好配置的二值完成率 20.6%，部分分 54.8%。
还有一个 25% 特别扎眼：面对「这个任务根本不可行」的测试，最好的模型只有 25% 能识别出来并停下。幻觉成功是结构性的，不是偶发的。
问题出在哪？Desktop-Delta Bench 给出了一个很有诊断价值的视角。在桌面环境里，推理、远端输入、应用渲染、截图捕获是异步的。你看到的那一帧可能是延迟的、被遮挡的、瞬时的，甚至根本属于另一个工作流。一旦过期或者错配的观测进入上下文，它就会污染后续推理。
为了测这个能力，他们设计了两类任务：三帧时间排序（带一个从别的轨迹里剪来的干扰帧），以及从动作前后两帧反推动作本身。结果最好的模型在排序任务上的精确匹配只有 65% 上下；反推动作类型比定位动作更难，点击的 F1 能到 0.96，拖拽只有 0.76。
还有一份工作叫 BLIND-ACT，它发现 Agent 会在矛盾、不可行的条件下继续执行，而不是停下来。
这一路还有一个少被讨论的坑：评测本身不可靠。有一篇论文审计了五个主流基准里 150 条被判失败的轨迹，发现 15.3% 的 FAIL 判断是错的：其中 10.7% 是评测器的假阴性，4.7% 是坏任务（比如某个 OSWorld 任务在官方发布的镜像上根本不可能完成，某个基准的开放网络任务碰到搜索引擎失效和验证码墙）。也就是说，你在排行榜上看到的数字里，有一部分是测量噪声。
把这些放一起，路线 C 的根本问题不是模型不够聪明，而是观测量和真实状态之间存在延迟与失配。你在用一串截图去推断一个有副作用、有隐藏状态的状态机，中间还隔着渲染、窗口焦点和异步 IO。在这条路上，「错觉是常态」不是修辞。
三、所以工程上应该怎么排序
把三条路线摆在一起，选择顺序其实相当清楚。
- 能用 API 就别碰界面。 这句话已经讲了十年，但今天依然是最省钱的建议。
- 必须操作文件时，先找原生运行时。 这个软件有没有 SDK、插件、headless 模式？表格和文档有 Univer 这类运行时，也有各个语言的文档库；设计工具有开放 API。核心判断标准是：Agent 改的是数据模型，还是屏幕上的一格？
- 只有在别人的网页上时，才用浏览器中间层，并且把确定性当成一等约束。 导航用
goto，重复骨架用observe后缓存重放，会变的部分用act/extract，agent()只留给真正开放式的一段。写之前先问一句：这一步真的需要模型决策吗？ - 桌面 GUI 是最后手段，而且要假设它会失败。 必须配人工审批卡点、可回滚的隔离环境、完整的操作留痕。把「它能自己跑完」当默认预期，是这条路上最容易犯的错。
再补一条容易被忽略的：你选择哪条路，等于选择了你的审计成本。 路线 A 的改动是结构化 diff，能进 code review，能写断言。路线 B 的产物是动作序列，需要 trace 才能复盘。路线 C 的产物是像素流，只能靠录像。这三者的运维代价，在任何真实项目里都不会比 token 账单便宜。
四、写在最后
今天趋势榜的一句话总结是：模型退居幕后，harness 成为兵家必争之地。我想把这个判断往前推一步。
harness 的竞争里，真正决定成败的可能不是编排逻辑写得多漂亮，而是它给 Agent 接上了什么样的手。同样的模型，接在文档对象模型上、接在 DOM 上、接在像素上，是三种完全不同的生物。
三条路线的分叉已经很清楚：把文件变成可验证的数据结构，把网页拆成确定性与非确定性两层，把像素操作留在最后一格当作兜底。
模型会继续变强，这没什么悬念。但模型变强不会自动修复两个物理约束：一个是观测与真实状态之间的延迟，另一个是界面在别人手里。所以接下来一年值得盯的，可能不是下一个模型的跑分，而是谁能先把某个专业工作流的操作层做对。那个位置一旦被占住，模型换谁都得从它这里过。
参考来源
- google/ax ：Google 开源的分布式 agent 运行时（README 与架构图）
- Agent Executor, Google’s distributed Agent Runtime ：Google Cloud Blog 官方说明，含 Agent Substrate
- Google Open-Sources AX, a Kubernetes Style Orchestrator ：InfoQ 对 AX 四个声明式原语与亚秒级恢复的报道
- Univer 与 dream-num/univer ：Office Harness 的运行时设计与 AI skills
- dsh-univer-office ：DeepSeek Harness 的 Office 插件与 worktree 复核流程
- browser-use to Stagehand 迁移指南 ：Browserbase 官方 skills 仓库里的确定性刻度表
- browser-agent-benchmark ：同模型下三个浏览器自动化框架的 token、时延与成功率对比
- Browser Use vs Stagehand vs Playwright MCP (2026) ：三方对比与每任务 token 区间
- WindowsWorld (arXiv 2604.27776) ：跨应用桌面 GUI Agent 基准，181 任务 / 17 应用
- DeskCraft (arXiv 2606.03103) ：长时序专业工作流与人在环协作基准，538 任务
- WorldGUI (arXiv 2502.08047) ：非默认初始状态下的桌面 GUI 自动化基准
- Desktop-Delta Bench (arXiv 2607.26041) ：桌面 GUI 状态转移理解与观测污染诊断
- OSWorld 2.0 相关讨论 ：长时序 computer-use 任务的评测可靠性审计，15.3% 的失败判定有误