OpenMuse 为什么火？可接管浏览器的 AI Agent 架构实战

前言

从“聊天框”到“能接管你的浏览器”，AI Agent 终于有了“手”。

前阵子有朋友反馈，他们正在做一个自动化调研系统。需求本身不复杂：每天定时抓取几个竞品网站的价格和功能更新，汇总成报告。

试过的方案都不太满意。用 Python 写爬虫，网站一改版就挂，维护成本很高；用大模型 API 加工具调用，虽然能理解页面内容，但模型“看不到”真实浏览器——它只能根据你喂给它的文本做判断，页面里的动态内容、登录态、复杂交互，全都摸不着。

他们需要的不是一个能“理解”网页的 AI，而是一个能“操作”浏览器的 AI。这个需求，正好命中了 OpenMuse 最核心的设计。

OpenMuse 是 CopilotKit 团队在 2026 年 9 月开源的一款个人 AI Agent，MIT 协议。上线不到一个月，GitHub 上已经有 4.2K Star。它的定位很清晰：一个有浏览器、有终端、有文件系统、能持续工作的个人智能体。

下面就把 OpenMuse 为什么越来越多人用，从头拆解一遍。

一、OpenMuse 到底是什么？

有人可能会问：“这不就是又一个 AI Agent 框架吗？跟 AutoGen、CrewAI 有什么区别？”

区别很大。AutoGen 和 CrewAI 解决的是“多 Agent 怎么协作”的问题——你定义角色，让它们在一个群聊里讨论，通过对话达成共识。而 OpenMuse 解决的是另一个问题：一个 Agent 怎么真正“动手”完成任务。

它给你的是一个完整的执行环境：一个持久的浏览器（Playwright Chromium）、一个隔离的 Linux 终端、一个文件系统。Agent 在这个环境里干活，你可以随时看到它在做什么，也可以在它卡住的时候直接接管它的浏览器。

用一句话说：OpenMuse 不是“对话框架”，而是“Agent 的工位”。它给 Agent 配了电脑、浏览器和文件柜，让 Agent 能像人一样坐在工位上干活。

二、一张图看懂 OpenMuse 的架构

OpenMuse 的架构有一个很明确的取舍：执行环境是独立的、隔离的，但你可以随时“接管”。

浏览器运行在独立的 Playwright worker 里，有持久化的 profile——cookies、登录态、历史记录全部保留。Agent 用这个浏览器访问网站，你可以在任何时候点击 “Take control”，打开同一个实时浏览器会话，手动完成验证码或登录，然后把控制权交还给 Agent。

三、为什么“能接管”这件事很重要？

这是 OpenMuse 和其他 Agent 工具最本质的区别。

大多数 Agent 工具的工作方式是“盲执行”。你给它一个任务，它在后台跑，中间发生了什么你不知道；跑完告诉你结果，跑挂了报个错，你只能等。

OpenMuse 的工作方式是“可见、可介入、可接管”。它的浏览器 worker 是一个有持久化 profile 的 Chromium 实例。Agent 操作它的时候，每一步都有截图和操作记录，你可以看到它在点哪个按钮、填哪个表单、读哪个页面。

更重要的是，当 Agent 卡住时——比如遇到验证码、双因素认证，或者需要人工判断的复杂页面——你可以直接接管。 “Take control” 打开的就是 Agent 正在使用的那个实时浏览器会话。你完成操作，把控制权交还，Agent 继续从当前状态往下走。不需要重启任务，不需要重新登录，不需要从头再来。

这个设计的价值在于：它承认了“有些事情 Agent 做不了”这个现实，并给出了一个优雅的解法。

3.1 Agent 执行与人工接管流程

流程解读：

• 任务创建：用户通过 API 或界面创建任务，任务引擎负责调度。
• Agent 执行：Agent 在浏览器 Worker 中操作，每一步都有截图和记录。
• 卡住检测：当 Agent 遇到无法处理的页面（验证码、双因素认证、复杂交互）时，标记“需要人工介入”。
• 人工接管：用户收到通知，点击 “Take control”，打开的是 Agent 正在使用的同一个实时浏览器会话。
• 交还控制：人工完成操作后，点击“交还控制权”，Agent 从当前状态继续执行。
• 任务完成：Agent 继续抓取数据、生成报告、返回结果。

这个流程的关键在于“同一个会话”。人工接管时打开的不是一个新浏览器实例，而是 Agent 正在操作的那个。登录态、cookie、页面状态全部保留。人工只是替 Agent 完成了它做不了的那一步，然后 Agent 接着干。

四、代码实战

4.1 环境准备

OpenMuse 需要 Node.js 24 LTS 和 pnpm 11.19.0。

# 克隆仓库
git clone https://github.com/CopilotKit/OpenMuse.git openmuse
cd openmuse

# 安装依赖
pnpm install --frozen-lockfile

# 复制环境配置
cp .env.example .env

4.2 启动演示模式（零配置）

OpenMuse 内置了演示模式，不需要 API Key、不需要 Google 账号、不需要 Docker，就能看到完整的界面和交互流程：

pnpm dev

Web 客户端默认运行在 8081 端口。打开浏览器访问，你会看到完整的聊天界面、任务面板、文件管理器和浏览器控制台，全部使用虚构的示例数据。

这个设计很务实——你可以先花 10 分钟把界面摸熟，确认它解决的是不是你真正的问题，再决定要不要投入时间配置真实环境。

4.3 配置真实模型

在 .env 文件中设置：

AGENT_BACKEND=model
MODEL=openai/gpt-5-mini
OPENAI_API_KEY=sk-...

或者使用 Anthropic 和 Google：

MODEL=anthropic/claude-sonnet-4.6
ANTHROPIC_API_KEY=sk-ant-...

MODEL=google/gemini-3-flash
GOOGLE_API_KEY=...

4.4 启用浏览器 worker

浏览器 worker 需要 Playwright 和 Chromium：

# 安装 Playwright 浏览器
pnpm --dir apps/worker exec playwright install chromium

# 在 .env 中配置 worker 地址
BROWSER_WORKER_URL=http://127.0.0.1:8790
# 至少 32 个字符的随机字符串
WORKER_TOKEN=replace_with_a_random_string_at_least_32_chars

4.5 在 Java 项目中使用

可能有人会问：“OpenMuse 是 TypeScript 写的，Java 项目怎么用？”

OpenMuse 暴露了完整的 REST + WebSocket API，Java 项目可以通过 HTTP 直接调用。

Java 侧调用示例（使用 Java 11+ 的 HttpClient）：

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;

public class OpenMuseClient {

    private static final String BASE_URL = "http://localhost:3000";
    private static final String ACCESS_KEY = "your-openmuse-access-key";

    // 创建任务
    public static String createTask(String description) throws Exception {
        String json = """
            {
                "description": "%s",
                "mode": "live"
            }
            """.formatted(description);

        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(BASE_URL + "/api/tasks"))
            .header("Authorization", "Bearer " + ACCESS_KEY)
            .header("Content-Type", "application/json")
            .POST(HttpRequest.BodyPublishers.ofString(json))
            .build();

        HttpClient client = HttpClient.newHttpClient();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        return response.body();
    }

    // 查询任务状态
    public static String getTaskStatus(String taskId) throws Exception {
        HttpRequest request = HttpRequest.newBuilder()
            .uri(URI.create(BASE_URL + "/api/tasks/" + taskId))
            .header("Authorization", "Bearer " + ACCESS_KEY)
            .GET()
            .build();

        HttpClient client = HttpClient.newHttpClient();
        HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
        return response.body();
    }
}

在 Spring Boot 项目中的典型集成：

@RestController
@RequestMapping("/api/research")
public class ResearchController {

    @Autowired
    private OpenMuseClient openMuseClient;

    @PostMapping("/competitor-price")
    public ResearchResult startPriceCheck(@RequestBody ResearchRequest request) {
        // 调用 OpenMuse 启动浏览器任务
        String taskId = openMuseClient.createTask(
            "访问 " + request.getCompetitorUrl() +
            "，抓取当前价格和功能列表，保存到 competitor_analysis.md"
        );

        // 轮询或通过 WebSocket 等待结果
        return ResearchResult.builder()
                .taskId(taskId)
                .status("STARTED")
                .build();
    }
}

关键点：OpenMuse 的 API 设计是 任务导向 的。你创建一个任务，它负责执行，你查询状态。Java 侧不需要理解浏览器操作的细节，只需要调用 API 即可。

五、OpenMuse vs 传统 Agent 方案

对比维度	OpenMuse	传统 Agent（AutoGen/CrewAI）
执行环境	持久浏览器 + 隔离终端 + 文件系统	无独立执行环境
人工接管	✅ 可接管实时浏览器会话	❌ 只能对话介入
任务持久性	✅ 关闭浏览器后继续执行	❌ 进程结束任务即停
审批机制	✅ 每次外部写入需审批	⚠️ 取决于实现
跨平台	iOS / Android / Web	通常仅 CLI 或 Web

六、优缺点

优点

1. 可接管的浏览器会话：这是 OpenMuse 最独特的能力。Agent 遇到验证码、双因素认证或复杂页面时，你可以直接接管实时浏览器，完成操作后交还给 Agent，不需要重启任务，也不需要重新登录。
2. 持久化任务引擎：任务支持暂停、恢复、取消、重试。长任务不会因为进程重启而丢失进度。
3. 端到端文档工作流：可以摄取邮件附件、处理 PDF 表单、生成已填写的副本和回复草稿，对大量表单场景很实用。
4. 跨平台：iOS、Android、Web 端一套代码，支持在手机上查看和接管 Agent 的工作。
5. MIT 协议开源：可自由使用、修改、商用。
6. 演示模式零门槛：不需要 API Key、不需要 Docker，就能看到完整界面和交互流程。

缺点

1. 项目处于 Alpha 阶段：接口、Agent 和平台 API 仍在快速变化中。
2. 配置较复杂：启用真实模式需要配置模型 Key、CopilotKit Intelligence Key、浏览器 Worker 等，不是一键安装。
3. 浏览器 Worker 资源占用：Playwright Chromium 在浏览时占用约 0.25-0.48GB 内存。
4. 没有多用户认证：设计上是单所有者系统，使用共享访问密钥保护，不适合多租户场景。
5. Java 没有官方 SDK：需要通过 REST API 自行集成。

七、适用场景

场景	推荐程度	理由
自动化网页调研	✅✅✅ 强烈推荐	持久浏览器 + 可接管，适合复杂网站
价格监控/竞品追踪	✅✅✅ 强烈推荐	目标监控功能原生支持
PDF 表单自动化	✅✅✅ 强烈推荐	端到端文档工作流
需要人工介入的自动化	✅✅✅ 强烈推荐	接管浏览器是核心差异化能力
长时间运行的调研任务	✅✅✅ 强烈推荐	持久化任务引擎
多用户 SaaS 场景	❌ 不推荐	单所有者设计，无多租户认证
简单的 API 调用	⚠️ 需评估	杀鸡用牛刀

八、写在最后

回到最初的问题：为什么越来越多人用 OpenMuse？

答案不复杂——因为它让 AI Agent 从“聊天框”里走了出来，真正坐到了“工位”上。

AutoGen 和 CrewAI 解决的是“多个 Agent 怎么讨论”，OpenMuse 解决的是“一个 Agent 怎么真正干活”。它给 Agent 配了浏览器、终端和文件系统，让 Agent 能像人一样操作软件、处理文件、完成任务。

而“接管”这个设计，才是它最聪明的地方。它承认了“有些事情 Agent 做不了”这个现实——验证码、双因素认证、复杂的业务判断。但它没有因此放弃，而是给了你一个优雅的介入方式：Agent 卡住的时候，你接管；你搞定了，交还给它。

这种“人机协作”的模式，比“全自动”或“全手动”都更务实。

当然，OpenMuse 还很年轻：Alpha 阶段、配置复杂、没有多用户认证。但对于自动化网页调研、PDF 表单处理、需要人工介入的长任务这些场景来说，它已经是一个非常值得认真评估的选项。

九、参考资源

• GitHub： https://github.com/CopilotKit/OpenMuse
• 官方文档： https://github.com/CopilotKit/OpenMuse/tree/main/docs
• 本地运行指南： https://github.com/CopilotKit/OpenMuse/blob/main/README.md