跳到正文

我想探索如何实现能够在数字世界中自主工作的 Agent:更有效地使用电脑,更独立地完成长程任务,并在工作中不断改进。目前,我最主要的研究切入点是 Hybrid Computer Use,也在通过 Work Agent 的工程和产品实践理解真实用户的需求。

作为这个博客关于研究的开篇,我想先记录截至 2026 年 9 月的研究兴趣、实践带来的思考,以及对未来的一些判断。这里既有正在做的探索,也有尚未实现的目标。我希望之后能回头看看,哪些判断成立,哪些需要修改。

1. 三个相互关联的研究方向

我的兴趣可以分成三个并列、但并不独立的方向:

研究方向核心关注
General Computer Use Agents更加智能、有效地使用电脑,完成不同类型的任务。
Long-Horizon Agents更加自主地完成更长程的任务,减少人持续指导和接手的需要。
Self-Improving Agents利用工作中的信息和经验,改进之后的能力,也加深对用户和环境的了解。

它们分别关注如何行动、如何持续完成任务,以及如何从工作中改进。Harness、Personalization、产品交互和 Evaluation 会贯穿其中。

1.1 General Computer Use:利用数字世界的各种接口

我理解的 Computer Use 是广义地使用电脑,Coding 也是其中的一环。写代码、处理文件、调用 API、使用 CLI 或操作图形界面,都是完成任务的手段。

我近期主要探索 Hybrid Computer Use,希望在同一个 Agent 工作环境中结合这些方式。我的个人偏好是优先利用代码和机器可调用的接口。数字世界已经提供了很多条件,包括 Shell、文件、API、SDK,以及通过 MCP 接入的工具,我希望 Agent 能充分利用它们。

AX(Accessibility,无障碍接口)也是其中很有价值的一类。它依赖应用和系统提供支持,但已经暴露出来的语义信息,在我看来有点像“免费的午餐”。我们可以准备好基础设施,让模型通过文本理解界面并执行操作,减少不必要的视觉推断。

这里需要区分“使用有图形界面的软件”和“采用纯视觉的 GUI 操作”。Agent 要能使用专业软件和网站,并不意味着它必须一直看截图、按坐标点击。AX 同样可以成为观察和操作这些界面的方式。

不过,我的偏好不应该变成模型必须遵守的固定顺序。我更希望把可用的工具和接口提供给模型,让它根据任务选择、组合使用。现在我倾向于把视觉操作看作 fallback,但经过 Hybrid Training,模型可能找到更好的方式,包括在某些情况下更多地选择视觉。

这也是我理解 Bitter Lesson 的一个角度:少用人类预设的偏好限制模型的探索空间。类似地,我把当前一些固定的截图验证步骤看作模型尚不适应混合交互时的补偿;长期来看,我希望模型能自己判断何时需要观察、如何验证,以及任务是否完成。

1.2 Long-Horizon:更自主地完成更长程的任务

Long-Horizon 最基本的目标,是随着任务步骤增多、持续时间变长,Agent 仍然能围绕目标推进工作,直到完成任务。

我认为这既需要模型能力,也需要更好的 Harness。任务管理、上下文压缩和进展保留等机制,要共同支持 Agent 持续工作,让它知道已经做了什么、还需要完成什么,减少人反复提醒、指导和接手。

这也是我希望 Hybrid Computer Use 基于成熟 Harness 来做的原因。真实任务可能交替用到代码、AX、视觉、搜索和其他工具,这些能力需要共享任务进展和上下文,服务于整个任务的完成。工具的丰富程度和持续执行的能力,需要放在一起考虑。

在这个基础上,我还有一个很在意的问题:当用户没有把所有要求写清楚时,Agent 能否准确理解意图,并把长程任务做好?

在实际使用中,我经常遇到两种情况。要么 Agent 不断提问,才能继续推进;要么用户说得不够详细,模型就自己猜,最后做偏了。我希望更智能的 Agent 能主动利用用户的历史行为、过去的交流、偏好,以及当前 workspace 的内容和进展。

用户这次只说了几句话,并不意味着 Agent 对这个人和这件事只能知道这几句话。

我希望它减少那些本可以从已有信息中解决的追问,也减少无依据的猜测,让长程执行真正成为用户可以放心交代的工作方式。

1.3 Self-Improving:让工作经验改善之后的表现

我不希望 Agent 每次工作都从头摸索,重复踩坑,或者反复让我介绍自己和当前环境。我关心的改进包括:

  • 做事能力:从尝试、失败和反馈中学习,改进解决问题的方法。
  • 对用户的了解:理解习惯、偏好和预期,减少重复解释的负担。
  • 对 workspace 的了解:熟悉其中的内容、约定和任务进展。

我会把 Personalization 放在这条主线下。对用户的了解和对工作环境的适应,都可以从持续工作中积累,也都能帮助 Agent 在下一次任务中更准确地理解需求。

我尤其在意上下文和探索历史。Agent 试过什么、为什么失败、得到了什么反馈,这些 Experience 不一定都要成为长期 Memory;即使只在一段时间或当前任务中有用,也能减少绕路。

因此,我的一个基本想法是,尽可能留下数字记录,让后续 Agent 能够读取。只要信息留下来,就有很大的改进和 DIY 空间,具体怎样组织、提取和使用可以继续探索。这也是我很早就从 ChatGPT 网页端转向 Codex 本地端的原因。即使只是日常问题,我也希望交互留下可被后续工作利用的记录。

Skill Optimizer Skill Optimizer GitHub stars 是我在这方面的实践,探索如何利用工作中留下的信息改善后续表现,也更了解用户。后来看到 Hermes,我觉得其中一些思路和自己此前的想法不谋而合。我也在做 Harness Evolution 相关的内部工作和 Demo,尝试利用工作中的信息改进 Harness。

我暂时不把“内化”限定成一种机制。经验可以作为可读取的信息留下来,也可以影响 Memory、Skills、工具和 Harness。是否更新模型参数,并不是我判断有没有改进的唯一标准。

更长期来看,我也对人和 Agent 一起参与新模型开发的全流程感兴趣,希望提升研发质量和效率。当前仍需要人持续审查;随着能力进步,人可能更多地负责提出目标和定义标准,参与程度也可能继续减少。

这三个方向会在使用中互相影响。利用已有信息理解并完成这次任务,与从这次任务中学到东西、改善下一次表现,是不同的问题,但可以在持续工作中联系起来。

2. 工程和产品实践如何影响我的研究

工程和产品实践给了我很多研究上的启发。它们让我接触真实需求,也让我看到一些在研究设置里不那么明显的问题。Computer Use 的研究与实际落地之间的差距,就是最直接的例子。

2.1 从普通人的需求出发

我很早就希望工具能让人“更懒”一些。小时候看妈妈处理表格、自己敲公式,我觉得很繁琐,希望这些事情能用更方便、快捷的方式完成,把人的时间和双手解放出来。

2024 年 10 月,大一刚入学时,我用 Cursor 写了一个“懒人日历” 懒人日历 GitHub stars。班群里的通知经常很冗长,要自己读完、提取时间和事项,再添加到日历里。我尝试让用户输入文本,由模型解析日程信息,确认后添加到日历中。那次经历让我意识到,AI 可能重写很多工具和做事的方式。

后来做 Open Cowork Open Cowork GitHub stars,我进一步思考从 Chat 到 Agentic 的跃迁:AI 可以从回答问题、提供建议,走向调用工具、操作软件和交付结果。

当时 Codex Desktop 还没有推出,我接触到的这类 Agent 入口主要是 Codex CLI 和 Claude Code。它们对熟悉终端的程序员已经很有用,但对普通人并不友好。我希望做一个开源版 Cowork,让不写代码的人也能感受到这种便利。Open Cowork 内置 Skills,并加入 GUI 能力,补上仅靠 CLI 操作覆盖不到的部分。

在 Open CoDesign Open CoDesign GitHub stars 中,我又以网页和设计为主要交付物,探索以设计为中心的 Harness 和产品交互。后来看到 Codex Desktop 的 Canvas,我开始觉得,这些能力可以融入更广义的 Cowork 产品,未必需要单独成为一种产品。

这些探索让我持续关注三个问题:普通人希望 Agent 做什么,他们怎样提出需求和了解进展,以及怎样使用最终结果。我不希望只沉浸在程序员和 Coding 的世界里,默认所有人都有相同的需求。

2.2 为什么 Work Agent 需要更广义的 Computer Use

在我看来,编程环境的一大优势是工具和生态比较完善。很多开发工作可以通过 CLI、代码和文件操作完成,再通过 MCP 等方式接入其他工具,Agent 就有了相对完整的工作路径。

更广泛的工作场景则涉及各种专业软件和网站,其中不少没有方便、完整的机器接口。Agent 如果只会处理接口友好的部分,遇到这些软件就让人接手,很难真正承担整个任务。

因此,更通用、更少依赖人类干预的 Work Agent,需要使用这些图形界面的能力。这里可以用 AX,也可以用视觉或其他可用接口。我希望保留代码和机器接口的优势,同时覆盖那些对 Agent 不够友好的软件和网站。

2.3 落地过程中看到的差距

在 Maka Maka GitHub stars 中,我主要参与自动化能力和 Computer Use 的一些实现。开发时研究了 Codex、Qwen Code、Kimi Code 的相关实现,并参考 Codex 继续优化,尝试更好的人机交互方式。

我接触的许多 Computer Use 研究设置以纯 GUI 为中心,而按我研究 Codex 实现时的观察,产品很重视 AX。它的价值不只是不抢光标,我也看到了 Token 效率和执行准确性方面的优势。同时,在 Maka 的实践中,速度、兼容性和操作失误仍是问题,模型似乎还没有充分适应这种方式,接口质量也依赖上游支持。

另一个差距是执行环境。与成熟 Coding Agent 相比,我接触的不少研究实现更接近一个观察、决策、执行的循环。真正要接入 MCP、Skills 和其他能力,支持持续工作,往往还需要重新适配。

这些经历推动我把 Hybrid Computer Use 与成熟 Harness 放在一起考虑。我希望训练、评测和实际使用能共享更多执行基础,也希望研究问题能来自真实的开发和使用,而不仅仅来自已有的实验设置。

3. Evaluation 带来的反思

3.1 像一个真正的 Coworker 一样工作

我在 MSRA 参与过一项 Evaluation 工作。Agent 面对一个真实的工作区和一条简短的 instruction,需要结合工作区内容和各种消息中的线索,理解真实意图,包括指令没有直接说出的意思,再像一个 digital worker 或 coworker 一样工作。

这是一项长程任务,也需要混合的 Computer Use,涉及 GUI、CLI 和搜索等工作。理解需求、寻找信息和持续执行,在这里是连在一起的。

这个场景集中体现了我对电脑操作和长程执行的关注,也让我进一步思考:这些工作中获得的理解和经验,怎样保留下来,改善之后的表现?后一个问题是自我改进的方向,不能仅凭 Agent 读取了工作区信息,就认为它已经从经验中学习。

3.2 专业任务需要专业经验

这项工作给我的一个教训是,做专业或垂直领域的 Evaluation,需要真正做过这类工作的人参与。即使学习了相关知识、流程和材料,没有实际做过,也很难想到工作中的各种细节。

知道一个职业大致做什么,与能构造真实任务、判断结果是否可用,之间仍有距离。这让我更重视领域实践者在任务设计和评判中的作用。

3.3 我想继续探索日常使用的评测

如果后续继续做 Work Agent 的 Evaluation,我更想从普通人的视角出发,看看 Agent 在不依赖特定职业专长、但足够真实的任务和环境里,能否表现得足够好。从班群通知中整理日程,就是我自己遇到过的一类需求。

我感觉这类日常场景值得更多关注,但现有评测覆盖到了哪里、还有哪些需求被忽略,需要进一步了解。我也会想,它们是不是因为单次任务的生产力价值不那么显眼,而较少成为重点?但这些可能恰恰是大家经常处理的事情,也可能最直接地影响日常使用体验。

我对各种 Evaluation 的方式和呈现形式都感兴趣。既想了解具体能力的上限,也想知道用户实际能感受到多少能力、能省下多少精力。真实使用中的问题,会继续影响我想做怎样的评测。

4. 我对未来落地形态的判断

4.1 共用电脑是当前的重要约束

近期,人和 Agent 可能仍然主要共用一台设备,沿用类似 Vibe Coding 的交互方式。在这种形态下,Agent 的操作是否可观测、是否干扰人正常使用电脑,是很直接的产品问题。

Open Cowork 中纯 GUI 操作可能抢光标的体验,让我对这个问题感受很深。因此,我很重视更少干扰人的执行方式,也能理解为什么工程和产品会优先考虑后台操作。

不过,“是否在后台运行”与“使用什么接口”是两个维度。AX 是我关注的一种观察和执行方式,后台执行则是交互上的要求。我不希望把今天共用设备的约束,变成未来所有 Computer Use 研究的固定前提。

4.2 如果 Workspace 逐渐上云

我愿意下注的一种未来是,更多人的 workspace 会迁移到云端,或者文件、登录态和工作环境可以同步、共享。Agent 可以拥有自己的云端电脑或独立工作环境,接受任务、持续执行,再向用户交付结果。

在这种形态下,人和 Agent 不再争用同一个桌面或光标,多个 Agent 也更容易并行工作。至少,“不要打扰人操作当前电脑”这项约束会明显减弱,操作方式的选择就可以更多地围绕任务效果、效率和可靠性展开。交互仍然重要,但光标争用不再是最突出的矛盾。

这也是为什么本地优先对我来说只是当前使用条件下的选择。今天本地有用户的文件、登录态和应用,因此方便;我真正看重的是 Agent 能接触到完成任务所需的信息和工具,工作记录也能被后续使用。

这是一种我看好的可能性,还不是确定的演进路线。我也在考虑更 Agent-Native 的系统或运行环境,开放更多适合 Agent 的接口,更好地支持协作和并行,具体形态仍然保持开放。

4.3 Hybrid 是面向这个未来的选择

如果往这个方向看,我就不希望探索被固定在两端:一端是我接触的一些研究中的纯视觉 GUI Agent,另一端是我在工程中关注的、以 CUA Driver 一类思路为代表的后台无感、AX 优先路线。这不是对所有研究和产品的分类,而是我目前看到的两种侧重。

我选择 Hybrid,不只是为了在今天的两种侧重之间找到折中,也是因为它更适合我看好的未来。

独立运行环境减弱了人机争用设备的限制,我们就更应该为 Agent 提供丰富的工具和接口,让它凭借自身能力选择如何观察、如何行动。

代码、CLI、AX、视觉和其他工具都可以发挥作用。我不想事先规定最终应该收敛到哪一种,也不认为每个任务都必须混合使用多种方式。重要的是模型有选择的空间,并能通过训练和实践更好地利用这些选择。

这也把我目前的工作和长期目标联系起来:今天建设 Hybrid 工具与 Harness,既解决落地中遇到的问题,也为更智能的模型、更独立的运行环境留下空间。

5. 接下来

我目前最主要的研究切入点仍然是 Hybrid Computer Use。Long-Horizon 和 Self-Improvement 是与它并列、相互促进的兴趣,Work Agent 的开发和 Evaluation 则让我不断看到新的需求和问题。

这篇文章先作为一个起点。我希望之后继续记录具体的工作、尝试和判断变化,让研究、工程与产品之间的相互影响有迹可循。最终想走向的,仍然是能够更自主地承担真实任务、又能从工作中不断改进的 Agent,让更多人少花时间在繁琐的事情上。