2026 年 8 月 17 日，browser-use 组织悄悄上线了一个新仓库：macos-harness。两天，480 星。它的定位一句话说完了自己全部的野心：「给 LLM 一台完整的 Mac，让它用最薄的一层 harness 做几乎任何事」。没有框架、没有菜谱、没有护栏--README 的原话是「No framework, no recipes, no rails」。
这条发布时间线微妙得像是故意的：就在 macos-harness 上线的第二天，OpenAI 官宣因 Agent 失控攻击 Hugging Face 事件而暂停两周模型测试、放慢开发节奏（详见本站 OpenAI 减速热点）。一边是全世界最强的 AI 实验室在给 Agent 收缰绳，一边是开源社区在给 Agent 发钥匙。自由度与缰绳的拉扯，正在成为 Agent 时代最主要的工程张力，而 macos-harness 站在了「自由」这一极的最边上。
先说清边界：本文事实基于 browser-use/macos-harness 的 README 与 GitHub API（2026-08-19 实测：480 星 / 33 fork，MIT，Python，创建于 2026-08-17），星数为当日快照，实时会变；项目自述 Experimental，仅支持 macOS；本文非投资建议。
一、项目档案：两天 480 星的「反框架」
| 项目 | 内容 |
|---|---|
| 仓库 | browser-use/macos-harness |
| 定位 | 最简单、最薄的 harness，给 LLM 完全自由操控一台 Mac |
| 星数 / fork | 480 / 33（GitHub API 2026-08-19 实测，创建仅两天） |
| 许可证 / 语言 | MIT / Python |
| 创建时间 | 2026-08-17 |
| 出品方 | browser-use 组织（开源浏览器自动化框架 browser-use 的官方团队） |
| 状态 | Experimental，仅 macOS |
| 安装 | uv + Python 3.12，一段 prompt 交给 Codex / Claude Code 自己装 |
出品方值得单独说一句。browser-use 是目前最知名的开源浏览器自动化框架之一（本站此前写过 browser-use 拆解），它给自己的定位是「给 LLM 一个浏览器」。macos-harness 是同一伙人的下一步棋：从「给 LLM 一个浏览器」到「给 LLM 一台电脑」。README 的结尾只有一句大实话：「Your agent now has a Mac.」
二、设计哲学：六原语，一整台 Mac
macos-harness 最反常识的地方，是它拒绝给模型做任何专用工具。没有 Spotify 工具，没有 Slack 工具，没有 Final Cut 工具。模型拿到的是六个原始原语：
macos-harness <<'PY'
frame = mac.see("Spotify")
mac.key("cmd+k", app="Spotify")
mac.type("Alessia Cara", app="Spotify")
mac.click(640, 420, app="Spotify")
item = mac.ax.at(640, 420, app="Spotify")
mac.script('tell application "Spotify" to play')
print(browser.page_info())
print(list(Path.home().iterdir()))
PY| 原语 | 作用 |
|---|---|
see | 截取目标应用窗口（含后台窗口） |
key | 向指定 app 的进程直接发按键 |
type | 输入文本 |
click | 坐标点击 |
ax | 原生 Apple Accessibility（视觉不够用时读结构） |
script | Apple Events / AppleScript |
同一个常驻 Python 进程里，browser（Browser Harness，经 CDP 驱动你真实登录过的 Chrome）、Path、subprocess 全部直接可用。也就是说：模型的手指（键鼠）、眼睛（截图 + AX）、嘴巴（AppleScript）、腿（shell）都在同一个躯干上。
README 用一张流程图讲清了它的工作方式：agent 想做一件没有现成 helper 的事 -> 看到目标 app，直接用 macOS 原生原语 -> 任务中途用普通 Python 把缺失的逻辑现写出来 -> 任务完成，全程没有新增任何 app 专用工具。
这个设计聪明在哪？过去两年的 Agent 工具生态，走的是「工具爆炸」路线：每接一个应用就包一层 MCP 工具，结果工具清单几百条、模型选不对、维护跟不上。macos-harness 把问题倒过来了--与其给模型造工具，不如给模型一台能自己写工具的电脑。缺什么逻辑，它自己写；写完即用，用完即弃。这是把「工具调用问题」降维成了「代码生成问题」，而后者恰恰是当前模型最强的能力。
三、技术架构：为什么它「看起来像人」
翻开实现，四个 macOS 原生机制的组合拳：
| 机制 | 用途 | 亮点 |
|---|---|---|
| CGWindow | 截屏 | 能截后台应用窗口，不把应用带到前台 |
| CGEvent | 键鼠输入 | 直接向目标 app 的 PID 发事件 |
| AX + Apple Events | 结构化读取 / 自动化 | 视觉识别不够用时兜底 |
| CDP（Browser Harness） | 浏览器 | 驱动真实、已登录的 Chrome |
两个细节值得划线。其一，「截后台窗口不前置」+「键鼠直接发到 PID」意味着 agent 可以并行操作多个应用而不抢占你的前台--harness 还会画一个动画的、可点击穿透的虚拟指针，你的真实光标全程不动。这是「agent 与人共用一台机器」的关键体验设计。其二，浏览器走的是你真实的、带着登录态的 Chrome，而不是一条干净的自动化浏览器--这一点直接对标了 ego-lite 的核心卖点（详见本站 ego-lite 拆解）。
生态位上三兄弟正好各占一格：browser-use 给 agent 一个干净的浏览器（无登录态）、ego-lite 让 agent 共享你真实的浏览器会话、macos-harness 把整台 Mac 连同浏览器、文件系统、终端一起交出去。从左到右，能力半径递增，风险敞口也递增。
四、安装即自治：让 agent 自己装自己
macos-harness 的安装方式是全 README 最「行为艺术」的一段：它不给你装教程，给你一段 prompt，让你粘给 Codex 或 Claude Code：
Install or upgrade macOS Harness from
https://github.com/browser-use/macos-harness with uv using Python 3.12.
Register the skill printed by `macos-harness skill`, then run
`macos-harness doctor`. Explain any missing macOS permissions and ask
before requesting them. Finally, verify the harness by capturing one
already-running app without bringing it to the foreground.翻译一下这段 prompt 的深意：agent 自己装包、自己注册 skill、自己跑 doctor 检查权限、发现缺权限时先解释再申请，最后的验收标准是「截一个正在运行的应用且不把它带到前台」--把本文第三节讲的设计原则变成了安装环节的自检项。整个 onboarding 就是一次人机权限协商的预演。
五、隐私与风险面：钥匙给出去之前，先看清单
macos-harness doctor 会报告实际需要的 macOS 权限，这是给用户看的知情同意书。遥测方面：匿名遥测默认开启，只记录 CLI 命令类别、成败、时长、包版本、OS / 架构、检测到的 agent 客户端；README 明确承诺绝不记录 prompt、应用名、截图、UI 文本、脚本、路径、窗口标题，一条 macos-harness telemetry disable 可关。
但该说的风险必须说透。这个工具的本质是把一台真实电脑的键鼠、屏幕、文件系统、shell 一次性交给模型，而且刻意不设护栏。它不主动激活应用、不动你的光标，这些是体验层的克制，不是安全层的防线。如果你的 agent 在这台 Mac 上跑出了边界，没有任何沙盒会拦住它--这正好是本批主题的另一面：真要把钥匙交出去，先读 Agent 沙盒隔离方案横评，再按 给 Agent 上缰绳部署 SOP 把权限最小化配好。自由度是能力，缰绳是资格；先有缰绳，再谈自由。
给三类人的结论：想体验「agent 用我的电脑」的 Mac 用户，值得一试，装完先跑 doctor 看权限清单；想在生产环境跑自动化任务的人，等它摘掉 Experimental 标签、并且务必包一层沙盒；研究 Agent 交互范式的人，六原语 + 自写工具的思路比工具本身更值得吸收。
常见问题
Q1：macos-harness 和 browser-use 是什么关系，会取代 browser-use 吗？ A1：同门但不互斥。browser-use 是浏览器自动化框架，自己拉一个干净浏览器来驱动；macos-harness 是操作系统层 harness，把整台 Mac（含真实 Chrome、文件、shell）交给模型。前者解决「网页任务」，后者解决「任何任务」，生态位不同，详见本文第三节三兄弟对比。
Q2：「零护栏」是不是很危险，个人能装吗？ A2：能装，但要想清楚再装。它的克制仅限体验层（不前置应用、不动真实光标），安全层没有沙盒、没有审批门。个人玩可以先用一台无敏感数据的机器或独立账户；涉及真实登录态和生产数据时，按本站 给 Agent 上缰绳部署 SOP 做权限最小化。
Q3：为什么说「六原语」比几百个专用工具更聪明？ A3：因为它把「工具调用问题」变成了「代码生成问题」。工具爆炸路线下，每个应用都要包一层 MCP 工具，模型要在几百条工具里选对；六原语路线下，模型缺什么逻辑就用普通 Python 现写，写完即用。而写代码恰恰是当前模型的最强项，等于把杠杆压在了自己的长板上。
Q4：遥测默认开启，会传我的屏幕内容吗？
A4：按 README 承诺不会。遥测只记录 CLI 命令类别、成败、时长、版本、OS / 架构和检测到的 agent 客户端，明确排除 prompt、应用名、截图、UI 文本、脚本、路径、窗口标题。介意的话 macos-harness telemetry disable 一条命令可关。
Q5：只支持 macOS 吗，Windows / Linux 用户有替代品吗？ A5：目前仅 macOS，且自述 Experimental，Windows / Linux 不在 README 的当前承诺里。替代思路是有的：浏览器层可用本站写过的 browser-use / ego-lite 方案，系统层的通用 harness 目前还没有同级开源对标，这个生态位空着本身就是一个信号。
参考来源
- browser-use/macos-harness README（六原语、架构图、安装 prompt、权限与遥测说明）
- GitHub API 实测（2026-08-19）：480 星 / 33 fork / MIT / Python / 创建 2026-08-17
- 本站：browser-use 拆解、ego-lite 拆解、OpenAI 减速热点、Agent 沙盒隔离方案横评
本文基于 README 与 GitHub API 公开数据整理（2026-08-19），星数为当日快照；项目为实验性软件，使用前自行评估风险。