Ein Verne修改

2026-11-02 14:00:00

今年 2 月份我把 [[Nowledge Mem]] 装到 MacBook 上，想解决的是一个很常见的问题：我希望在 [[Perplexity]] 网页上查过的资料，直接在 Claude Code 中可以记住。但没想到大半年过去，它已经变成了我每天都在用的软件，而且是那种「不在后台跑着就会觉得别扭」的存在。我在 Claude Code、[[Codex]]、[[OpenClaw]] 里开的每一个会话，开头都会先从它这里拿一份简报；网页上和 AI 聊过的东西会自动同步进去；我做过的决定、踩过的坑、服务器的配置，都沉淀成一条条可以被任何 Agent 检索的记忆。说它是我所有 Agent 的记忆和大脑，一点都不夸张。

之前我录过一期视频演示安装和浏览器插件的用法。这篇文章会先简单介绍它是什么，再重点聊聊长期使用之后，它到底在我的工作流里扮演什么角色，有哪些地方让我离不开，又有哪些坑值得提前知道。

视频介绍：YouTube

为什么需要一个跨工具的记忆层

我现在同时在用的 AI 工具其实挺多的。写代码主要是 Claude Code 和 Codex，查资料习惯用 Perplexity 和 [[Gemini]]，偶尔打开 [[ChatGPT]]，自己的服务器上还跑着 OpenClaw 处理一些自动化任务。每个工具单独看都很好用，问题在于它们彼此之间完全不认识。我在 Codex 里刚和它确认过某个项目的部署方式，切到 Claude Code 它一无所知；在 Perplexity 里花半小时调研清楚的东西，到了终端里又得重新贴一遍链接。大模型本身是无状态的，每开一个新会话就是一个新的陌生人，而作为用户，我积累下来的项目偏好、踩过的坑、做过的取舍，如果每次都丢掉，是很大的浪费。

市面上解决这个问题的方案大致有三类。第一类是工具自带的记忆，比如 ChatGPT 的 Memory、Claude Code 的 CLAUDE.md、OpenClaw 自己的记忆系统，它们只在自己的生态里生效，换个工具就失效了。第二类是针对单个工具的插件，比如我之前介绍过的 claude-mem：让 AI 编程助手拥有持久记忆，做得很深但只服务 Claude Code。第三类就是 Nowledge Mem 这样的独立记忆层，它不依附于任何一个 Agent，而是通过插件、[[MCP]]、命令行和浏览器扩展，让所有工具读写同一份数据。对于我这种会频繁在不同工具之间切换的人来说，只有第三类才真正解决问题。

Nowledge Mem 是什么

Nowledge Mem 是一款隐私优先、用知识图谱增强的 AI 上下文管理器。它把各种 AI 工具里的对话、笔记和文件沉淀成可以复用的记忆，再用知识图谱把这些记忆连起来。这个定义有点拗口，拆开来看主要是这么几点：数据默认存在本地，提炼和索引用的模型也可以跑在本机，不用担心隐私问题；ChatGPT、Claude、Cursor、Gemini 等不同工具里产生的对话，可以集中保存到同一个私有记忆库；它会自动识别记忆中的实体、概念和关系，用图算法找出它们之间的关联，而不是像传统笔记软件那样只把文档罗列出来；最后，通过插件和 MCP，它能成为各种 Agent 共用的「外挂硬盘」。打个比方，它相当于给你所有的 AI 助手配了一个共用的海马体，让它们都能记住你的偏好、项目背景和随手冒出来的想法。并且随着越来越深度的使用，会发现 Nowledge Mem 会越来越懂你。

把内容存进去的方式也很多。网页上的 AI 对话可以通过浏览器扩展同步；本地 Claude Code、Codex 的历史会话可以扫描后一键导入；Markdown、PDF 这类文件可以直接拖进去，它会从里面提炼记忆；在对话中让 Agent 执行保存命令，或者用 nmem 命令行写脚本，也都可以把内容写进去。桌面应用提供 macOS、Windows 和 Linux 版本。

它在我的工作流里到底做了什么

先放一组数据，这是我写这篇文章时用 nmem stats 看到的：970 条记忆、3640 条对话线程、接近 4000 个实体、58 个知识社区。第一条记忆的时间是 2026 年 2 月 19 日，到现在刚好 8 个多月。这些记忆里，有 291 条是后台的 Knowledge Agent 自动从对话里提炼的，228 条来自 OpenClaw，211 条是各种编程 Agent 在工作过程中主动保存的，176 条是我或 Agent 通过 nmem 命令行手动写入的。

每次我在 Claude Code 里开一个新会话，Nowledge Mem 的插件会在 SessionStart 阶段注入一份 Context Bundle，里面有我的身份信息、当前的 Space，以及一份 Working Memory。Working Memory 是它每天自动生成的工作简报，会列出我最近在关注的事情、悬而未决的问题和下一步。比如今天早上的简报里，它提醒我前几天在对比 [[PowerContext]] 和 Nowledge Mem 之后，说过想把 PowerContext 部署到 Homelab 上长期使用，但这件事还停留在计划阶段，域名用哪个、选 Basic 还是 Full 记忆模式都还没定。这种「我自己都快忘了，但它记得，而且知道哪些事情还没收尾」的感觉，是我觉得它最有价值的地方。

除了开场简报，插件还会在每次提交 prompt 时提醒 Agent：如果任务涉及延续之前的工作、回顾历史决定或者跨工具的上下文，先去记忆库里搜一下再下结论。Agent 会调用 nmem m search 搜索记忆，或者用 nmem t search 去翻历史对话。会话结束或者上下文被压缩之前，插件会把整段对话保存成一条 thread，之后后台的 Knowledge Agent 会从里面提炼出值得长期保存的记忆。整个过程我基本不需要操心，照常提问、写代码就行。

网页端则靠 Nowledge Mem Exchange 浏览器扩展。我在 Perplexity、Gemini、ChatGPT 上的提问和回答会被自动同步到本地，这也是为什么我的对话线程里，Perplexity 的数量反而最多。在最近的 1000 条对话里，Perplexity 有 498 条，Claude Code 有 426 条，Codex 40 条。以前我在 Perplexity 上做的调研，查完就散落在它的历史记录里，现在这些内容会进入同一个知识库，之后 Claude Code 写代码或者写文章需要背景资料时，可以直接检索到。

让我离不开的几个特性

记忆是结构化的

Nowledge Mem 保存的不是一堆原始聊天记录，而是经过提炼、带类型的记忆单元。一条记忆会被标记为事实、决策、偏好、操作步骤或者经验教训，并且关联到具体的实体。这个区别在长期使用之后非常明显。我有一条偏好记忆写的是「所有项目的 PR 和 commit message 里都不要加 AI 署名」，不管我在哪个工具、哪个项目里工作，Agent 都会在 Context Bundle 里看到它。还有一条记忆记录了我把 Nowledge Mem 通过 Cloudflare Tunnel 映射出去之后，远程模式下哪些接口会返回 403、管理命令要怎么在本地执行。这类细节如果只存在于某次对话里，下一次遇到同样问题时几乎不可能翻到；变成结构化记忆之后，Agent 一搜就能拿到。

混合检索加知识图谱

搜索是记忆系统的生命线。Nowledge Mem 的检索同时用了 BM25 关键词匹配和向量语义搜索，所以不管我是用精确的命令名去搜，还是用一句模糊的描述去搜，基本都能找到想要的东西。在这之上它还会把记忆里的实体抽出来建知识图谱，再自动聚类成社区。我现在的 58 个社区里，最大的是 OpenClaw 的记忆系统和向量检索，有 138 条相关记忆，其他还有我自己的几个项目、日本高股息投资组合、东京车站调研等等。翻看这些社区的时候，我才意识到自己这半年的注意力到底花在了哪里，这算是一个意外的收获。

图谱也不只是后台的数据结构，应用里有一个可视化的图谱浏览界面。主界面左边是类似聊天的交互区，右边是知识图谱，点击图谱上的某个节点，左边就会列出相关的记忆和对话。这种顺着关联往下翻的浏览方式，经常能帮我发现两件事之间原本没注意到的联系，比如两个看起来不相关的项目，其实依赖了同一个后来被废弃的接口。

本地优先，同时能远程访问

数据默认存在本地，提炼记忆用的模型也可以跑在本地，这一点从一开始就是我选择它的原因。我的代码、服务器配置、投资想法都在里面，不太愿意交给一个纯云端的服务。但我也不只有一台电脑，其他设备上的 Agent 和命令行同样需要访问这份记忆。它的 Access Anywhere 功能解决了这个问题：在设置里打开之后会生成一个 API Key，我再用 [[Cloudflare Tunnel]] 把 MacBook 上的 14242 端口映射到自己的域名，其他设备的 nmem 命令行、浏览器扩展和 MCP 客户端填上地址和 Key 就能连上。数据依然只有一份，放在我自己的机器上。

覆盖几乎所有我在用的工具

官方目前提供了 Claude Code、Codex 的插件，OpenClaw 的记忆插件，浏览器扩展，以及通用的 MCP Server 和 nmem 命令行，再加上一份可以直接丢给 Agent 阅读的 Skill 说明文档。通过 MCP 接入的 Agent 可以搜索记忆和历史对话、保存当前工作的检查点，也可以在不同工具之间交接任务进度，比如在 Claude Desktop 里直接说「帮我查一下上次关于重构数据库的讨论」，它就会去调用 Nowledge Mem 的搜索接口。我在视频里说它支持 20 多种工具，大部分主流 Agent 都能接入。对我来说最关键的是 Claude Code 和 Codex 用的是同一套 hook 机制，OpenClaw 则直接把 Nowledge Mem 设置成了自己的记忆插槽，三个 Agent 共用一个大脑，任何一个保存的东西，另外两个下次都能用上。

安装与配置

安装本身不复杂。去官网下载桌面应用，macOS 上需要按提示授予辅助功能权限，否则全局搜索栏 Global Launcher 没法正常呼出。打开之后先到设置里把本地模型下载好，这个模型用来做记忆提炼和向量化。然后在 Preference 里安装命令行工具，安装完成后在终端执行：

nmem status

看到 status ok 就说明本地服务正常。接下来按照官网文档为不同的 Agent 安装插件。以 Claude Code 为例，官网会给出一行安装命令，复制到 Claude Code 里执行即可，装好之后新开会话能看到 Loading Nowledge Mem context... 的提示，说明 hook 已经生效。Codex 也是类似的方式，通过 marketplace 安装插件。

浏览器扩展需要多一步配置。打开扩展的设置，填入 Mem API URL 和 API Key，这两个值都可以在桌面应用的 Access Anywhere 页面找到。只在本机使用的话，地址填 http://localhost:14242 就行；如果要让局域网里的其他设备访问，需要打开对应的开关。测试连接成功后保存，再把常用的网页 AI 工具勾选上，之后每次在这些网站上聊天，内容就会自动同步。如果同时勾选了自动提炼，它还会把对话进一步整理成记忆。

如果要像我一样从外网访问，可以用 Cloudflare Tunnel 把本地端口映射出去，然后在其他设备上配置客户端：

nmem config client set url https://mem.example.com
nmem config client set api-key <your-api-key>
nmem status

MCP 客户端的地址是 https://mem.example.com/mcp/，注意末尾的斜杠不能省，请求时带上 Authorization: Bearer <key>。

关于价格，我录视频的时候它还在内测阶段，可以申请 Alpha 邀请，或者花 9.99 美元购买 Pro 授权，可以在 3 台设备上启用。现在官网的方案已经调整为免费的本地版（自己提供模型 API Key）加付费的 Plus 订阅，另外还有正在公测的 Nowledge Cloud 和内测中的团队版，具体价格建议以官网为准。

长期使用的一些经验和坑

善用 Global Launcher

除了让 Agent 自己去查，我自己也经常需要翻记忆。在 macOS 上按快捷键（默认是 Cmd+Shift+K，可以在设置里改）就能呼出全局搜索栏，不用切换窗口就能找到之前的代码片段、命令或者笔记，复制出来直接粘到编辑器或终端里。手不离键盘，比打开应用再搜索快很多。

远程模式的访问限制

通过反向代理访问的时候，Nowledge Mem 会进入 remote mode，这时根路径 / 会直接返回 403，提示该接口在远程模式下不开放，网页界面要访问 /app 才能打开。更容易踩坑的是，nmem key、nmem config access 这类管理命令在远程模式下也是 403。所以如果要轮换 API Key 或者改访问配置，得回到运行应用的那台机器上，用 NMEM_API_URL=http://127.0.0.1:14242 指定本地地址执行。如果你在远程设备上看到 403，先别急着怀疑 Key 填错了，很可能只是这个接口在远程模式下本来就不开放。

主动召回意味着可能漏掉

Nowledge Mem 的召回方式是开场注入一份简报，其余靠 Agent 自己判断什么时候去搜。这样做省 token，不会每条 prompt 都塞一大段可能不相关的上下文，但代价是如果 Agent 没意识到需要查，就会漏掉。我的经验是在 CLAUDE.md 或者 AGENTS.md 里写清楚哪些场景必须先查记忆，比如继续之前的任务、涉及服务器配置、需要引用过去的决定。平时和 Agent 对话时，我也会直接说「先去 Nowledge Mem 里搜一下上次的方案」。如果你想要每条 prompt 都自动注入上下文，可以看看我之前写的 用 PowerContext 给多个 Coding Agent 做任务交接，两者的思路正好相反。

不是什么都值得记

记忆库不是越大越好。如果把所有对话都提炼成记忆，检索结果里很容易混进大量一次性的问答，真正有用的东西反而被淹没。所以我给 Agent 定了一个双轨规则：对话线程照常自动保存，作为原始素材；但只有长期有效的偏好、决策、计划和踩坑经验，才主动写成记忆。写的时候尽量带上时间、具体的命令和结论，而不是一句笼统的「已经配置好了」。这样半年之后回头看，每条记忆都还能看懂、还有用。

记忆也会过时和冲突

服务器换了、配置改了、计划变了，旧的记忆就会和新情况冲突。Nowledge Mem 的后台会把新证据合并到旧结论里，用新记忆替代被推翻的旧记忆，并保留版本历史；Working Memory 也会在发现两条信息对不上时直接标注出来，而不是随便挑一个当结论。这一点我很喜欢，但它并不能完全替代人工。nmem status 有时会提示有待审核的条目，建议隔一段时间用 nmem feed inbox 看一下，把明显过时的内容处理掉。知识图谱也一样，偶尔手动合并一下重复的实体节点、修正错误的关联，图谱质量会高很多。我把这当成打理数字花园，花不了多少时间，但能让后面的检索准很多。

数据只有一份，记得备份

本地优先的另一面是数据只在一台机器上。我刚开始用的时候，它既不支持多设备同步，也没有云备份，设备一坏记忆就可能全丢，导入导出功能当时也还在开发中。现在情况好了一些，多设备可以通过 Access Anywhere 共享同一份记忆，但真正的数据库依然只在我的 MacBook 里。命令行提供了 nmem export 和 nmem import，目前还标注为实验性功能，建议定期导出一份放到别的地方。如果不想自己维护，可以关注一下官方的 Nowledge Cloud，它可以把同一套服务放到云端运行，迁入迁出据说都是一键操作，我还没有实际迁移过。

最后

用了大半年，Nowledge Mem 给我最大的改变是，我不再需要充当不同 AI 工具之间的「人肉上下文搬运工」。以前每开一个新会话，我都得花几分钟交代背景；现在 Agent 一上来就知道我是谁、最近在忙什么、有哪些事情还没收尾，而且这份认知在 Claude Code、Codex、OpenClaw 和网页 AI 之间是共享的。工具越多，这个记忆层的价值就越大。

它当然还有可以改进的地方，比如主动召回偶尔会漏、远程模式的一些限制需要摸索、数据备份还不够省心。但在我试过的各种 AI 记忆方案里，它是唯一一个真正做到跨工具、本地优先、又能长期稳定使用的。如果你也同时在用好几个 AI Agent，经常觉得每次都在重复自我介绍，很建议试一下。安装和浏览器插件的配置过程我在视频里有完整演示，有问题也欢迎留言交流。

2026-10-29 13:00:00

前两天整理了一篇 AI 浏览器自动化方案怎么选，把 Playwright、MCP、Agent 专用浏览器、WebMCP 这些路线梳理了一遍。在那篇文章里我提到，「内置 Agent 的 AI 浏览器」这一类里我最看好的是 Aside，原因是它的密码管理器设计得很用心，但篇幅有限没有展开。今天就单独写一篇，聊聊这个浏览器到底能做什么、和 [[Comet]]、[[Dia Browser]] 有什么不一样，以及我现在是怎么用它的。如果你看完想试试，可以用我的邀请链接 注册，注册后会额外获得 100 Credits。

Aside 是什么

Aside 是一款基于 [[Chromium]] 的 AI 浏览器，官方口号是 “Anything you do in browser, Aside can do for you”。背后的公司 Aside Computer Inc. 是 Y Combinator 2025 年秋季批次（YC F25）的项目，团队只有 8 个人左右，三位联合创始人都来自韩国的移动归因公司 Airbridge。有意思的是，他们最早做的是给 B2B 销售用的实时通话助手，后来才转向浏览器。产品在 2026 年 6 月下旬正式发布，9 月推出 Windows 版，10 月的版本内核已经升级到 Chromium 154，并支持 Windows ARM64，迭代速度非常快，几乎每周都有新版本。

Aside 在自己的宣言里有一个判断我很认同：AI 的操作系统其实已经存在了，就是浏览器。工资、银行、报税、设计、项目管理，现在绝大多数工作都发生在网页应用里，「现代软件大多只是一个标签页」。既然工作都在浏览器里，那承载工作的浏览器理所当然应该能帮你把活干完。这个思路和很多 Agent 产品不太一样，后者通常要你一个个接第三方集成，或者在云端开一个干干净净、没有任何登录态的浏览器，Agent 每做一步都要问你要账号、要背景、要授权。

Aside 的做法是把 Agent 直接放到浏览器里，复用你已有的 Cookie、登录状态和浏览历史。用官方的话说，就是把你的账号当作工具，把浏览历史当作记忆。你能在浏览器里登录的网站，理论上 Agent 都能替你操作，不需要任何额外配置。

和其他 AI 浏览器有什么不同

过去一年我陆续用过 Dia 和 Comet，再往前还写过 Arc 的初体验。Dia 更像是把 AI 对话做进了浏览器，擅长围绕当前页面聊天和辅助写作；Comet 以 Perplexity 的 AI 搜索为核心，问答体验很好，但长流程的自主任务一直不是它的强项。OpenAI 的 [[ChatGPT Atlas]] 更是在 2026 年 8 月就停止了服务，能力并回了 ChatGPT 桌面应用。

Aside 的重心明显不在「聊天」，而在「任务」。一个任务可以跨多个网站，持续几分钟甚至几个小时，中途可以暂停等你输入、请求审批，然后继续。官方给的示例几乎全是那种「登录之后才能做」的杂事：从 Rippling 下载工资单、收集各个平台的账单发票、从合同里提取日期、把仪表盘上的内容整理成待办。这些恰好是传统 RPA 脚本写起来麻烦、而通用聊天机器人又碰不到的工作。

另外还有一个非常值得一提的是 Aside 专门为 Agent 设计了一款密码管理器 — Aside Vault，Agent 可以利用认证但又不会暴露密码，另外 Aside 可以直接阅读的 Markdown 记忆，还给开发者准备了 CLI 和 [[MCP]] 服务。

Aside Vault 让 Agent 能登录但看不到密码

让 AI 替你操作已登录的网站，最大的心理障碍其实是安全：我愿意让它帮我下载发票，但我不愿意把密码交给一个大模型。Aside Vault 的思路是把「登录这个动作」和「知道密码」拆开。任务走到登录页时，Aside 先检查目标 URL 是否匹配、访问策略是否允许，满足条件就由浏览器直接把凭据自动填进网页，整个过程模型拿不到明文密码。

围绕这个核心，Vault 还做了一整套配套机制。解锁可以用 macOS 的 Touch ID 或 Windows Hello，加密依赖 Secure Enclave 这类硬件能力。Agent 的访问策略分为 Always allow、While unlocked、Never 三档，导入的条目还可以单独覆盖全局策略，比如银行账号直接设成 Never。无痕会话里 Agent 完全不能使用密码库。每一次凭据使用都会记录审计日志，支付、发帖、发消息这类敏感操作会停下来等你确认。遇到 MFA、验证码或身份验证，Aside 也不会去尝试绕过，而是交给人来完成。

我之前的整理文章中对比过，着是目前为止我能看到的最用心的安全设计，尽可能隔离 Agent 和密码，Aside Vault 是我看到的最棒的使用设计。

本地记忆和 Routines

Aside 会根据浏览历史、聊天和任务记录生成记忆，这样每次交代任务时不用重复解释背景。和很多产品把记忆藏在云端黑盒里不同，Aside 的记忆就是本地的一堆 Markdown 文件，又继承了 OpenClaw 的精髓。在 Mac 上，位于 ~/.aside/u/0/memory/ 目录下，根目录有 MEMORY.md（通用的操作规则）、USER.md（用户画像和偏好）和一个 TAXONOMY.md。这个 TAXONOMY 文件很有意思，它定义了记忆的分类和归档规则：语义记忆按「当前状态加历史」的结构存放，情景记忆按日期追加写入 episodic/ 目录，根目录的两个文件则由它们提炼而来，并且要求足够小，方便每次加载进提示词。任务结束后，一个叫 Dreaming 的后台过程会负责整理和更新这些文件。

这种透明度我很喜欢，用 [[Obsidian]] 打开就能看到 AI 记住了你什么，不放心还可以在设置里关掉记忆，或者给情景记忆设置 30 天、90 天的保留期。需要说明的是，我刚装上不久，目前这几个文件里还只有模板，没有积累出什么内容，记忆的实际效果还需要用一段时间再评价。

Routines 则是定时任务，比如「每天早上 9 点生成一份简报」「每周一检查某个后台的数据」。它可以手动创建，Aside 也会扫描你的重复性工作，主动给出 Routine 草稿让你确认。免费版最多 3 个活跃的 Routine，Pro 不限数量。

给编程 Agent 用的浏览器

作为一个整天使用 [[Claude Code]] 的人，Aside 可以直接被 Agent 使用。它附带一个 CLI，安装后可以直接添加 CLI，也可以通过如下的方式安装：

curl -fsSL https://releases.aside.com/install.sh | bash

装好之后可以直接在终端里给 Aside 的 Agent 派任务：

aside "Open localhost:3000 and run a smoke test"
aside --account u1 "Check unread Slack notifications"
aside session steer <id> "Switch to Google Flights"

如果需要精确控制页面、截图或读取 DOM，可以用 aside repl 运行 [[Playwright]] 风格的 JavaScript。更方便的是 aside skills install，它会把一个 aside-browser Skill 装进 Claude Code、[[Codex]]、Cursor、OpenCode 这些编程工具里。我现在的 Claude Code 里就有这个 Skill，它的内容很克制，只是让 Agent 先执行 aside guide 去读取最新的使用说明，CLI 升级后说明也会跟着更新，不会出现 Skill 文档过时的问题。如果你更习惯 MCP，配置一行就能接入：

{"mcpServers":{"aside":{"command":"aside","args":["mcp"]}}}

除了浏览器操作，CLI 还内置了一批站点 Skill，执行 aside skills list 能看到 Gmail、Google Docs、Google Sheets、Notion、Slack、LinkedIn、YouTube 等，部分读取操作甚至不需要打开浏览器标签页。另外 aside memory search 可以让外部 Agent 直接检索 Aside 的记忆，不用再反复问你背景。这样一来，Aside 就不只是一个浏览器，而是一个「带着你的登录态和个人上下文」的浏览器后端，任何编程 Agent 都可以调用它，思路上和我之前介绍的 [[Ego Lite]] 有点接近，只是 Aside 自己也带了一个能独立干活的 Agent。

模型和价格

Aside 支持三种模型来源。第一种是订阅附带的 Aside 自有模型，按 Credits 计费；第二种是用 OAuth 登录你已有的 [[ChatGPT]] Plus/Pro、[[Claude]] Pro/Max 或 [[GitHub Copilot]] 订阅；第三种是填入 Anthropic、OpenAI、[[OpenRouter]]、xAI 等服务商的 API Key。后两种方式的费用由对应服务商计算，不消耗 Aside 的 Credits，所以如果你已经有 ChatGPT 或 Claude 的订阅，免费版基本就够日常使用了。

按年付费可以打 8 折。通过 我的邀请链接 注册会额外获得 100 Credits，对于先试水的用户来说，加上每月 500 的免费额度，足够跑一批真实任务看看效果了。

关于性能，Aside 宣称在 Online-Mind2Web、BU-Bench-V1、Odysseys 三个浏览器 Agent 基准上排名第一，Online-Mind2Web 上的成绩是 99.0%（300 个任务完成 297 个），并且把测试结果公开在了 GitHub 上。不过这些都是自测自评，评分也由大模型自动判定，主要成绩还是用 gpt-5.5 跑出来的，参考一下就好，最可靠的办法还是拿自己的任务去试。

使用建议和需要注意的地方

首次启动时，Aside 会让你从现有浏览器导入历史、Cookie 和书签。我的建议是不要一股脑全部导入，尤其不要把主力浏览器的 Profile 原样搬过去。Aside 支持多 Profile，可以单独建一个工作用的 Profile，只导入任务真正需要的那几个网站，银行和主邮箱这种高价值账号暂时不要放进去，或者在 Vault 里把它们的 Agent 访问策略设成 Never。

任务权限也值得时间设置一下。Aside 的任务有 Read only、Guard、Full access 三档，Guard 是默认值，只能在批准的文件夹里工作，访问其他目录前会询问。新任务我建议先用只读跑一遍，确认 Agent 理解对了再放开。写任务描述时尽量说清楚「哪个网站、哪个账号、要什么结果、放到哪里、哪些事不要做」。尽量避免模糊的指令。

还有几个使用注意事项。首先，「本地优先」指的是数据存储，模型推理依然调用云端大模型，任务所需的页面内容还是会作为上下文发给模型服务商，切记敏感的内容一定做安全保护。其次，Aside 产品很新，不免偶尔有 BUG，尤其是有人反馈过和 [[1Password]] 的集成会出问题，Vault 在保存新生成的密码时也不够稳定。最后，目前不支持 Linux 和移动端，macOS 需要 15.0 以上。至于让 Agent 带着真实登录态长时间自主运行，本身就存在提示注入和误操作的风险，涉及付款、对外发消息的操作一定要保留人工确认这一步。

最后

在我看来，Aside 是 2026 年这一波 AI 浏览器里思路最清晰的一个。它没有满足于在侧边栏放一个聊天框，而是认真回答了「如何让 Agent 安全地使用你的登录态」这个问题：Vault 把登录和密码拆开，记忆以 Markdown 的形式留在本地，权限和审批机制层层叠加，再加上 CLI 和 MCP，让它既能给普通用户当日常浏览器，又能给 Claude Code 这样的编程 Agent 当浏览器后端。

我目前的用法是把它当作编程 Agent 的「手」，让 Claude Code 通过 aside-browser Skill 去处理那些需要登录的网页步骤，获取网页内容，日常浏览还没有完全切过去。Aside 还很年轻，稳定性和基准测试的可信度都需要时间验证。如果你也经常在浏览器里做重复、需要登录的杂事，或者想给自己的 Agent 找一个带登录态的浏览器，不妨试试。

相关链接

• Aside 官网
• Aside 在 MyAltBox 上的介绍
• Aside 的替代品
• CLI、MCP 与 REPL 文档
• Aside 宣言
• 基准测试仓库 at-inc/aside-benchmarks

2026-10-28 13:00:00

最近我一直在研究「让 AI 用浏览器」这件事。起因是看到 Nowledge 写了一个 browse-now Skill，可以直接让 Claude 控制浏览器，紧接着又偶然发现了 [[Ego Lite]] 这款专门为 Agent 设计的浏览器。顺着这条线，我把 Aside、BrowserOS、Deta Surf 这几款 AI 浏览器挨个调研了一遍，越看越发现它们的侧重点和实现方式差别很大：有人在做测试框架，有人在做浏览器插件，有人从 Chromium 内核开始为 Agent 改造浏览器，还有人在推动新的 Web 标准。它们看起来都在「让 AI 操作网页」，解决的却根本不是同一个问题。

这篇文章是我这一轮调研的阶段性总结。截至 2026 年 10 月，让 AI 操作浏览器的方案大致可以分成十条路线：传统脚本、CDP 加 MCP 或 CLI、浏览器插件、Agent 专用浏览器、内置 Agent 的 AI 浏览器、自主 Agent 框架、云端浏览器、数据采集、Computer Use 和 WebMCP。文章会先逐条介绍每条路线里的典型方案，再用三个问题把它们放在一起比较，最后分享我的判断和选型建议。

结论

如果你没时间看完全文，可以先看这几条：

• 没有「最好的那一个」。这些工具解决的问题不一样，有的负责给 AI 出主意，有的负责提供浏览器，有的负责在云端批量跑，很多时候是搭配着用，而不是二选一
• 能不让 AI 看网页，就别让它看。AI 每看一次页面都要花钱、花时间，还可能看错。网站有现成接口就用接口，流程固定就写脚本，只有遇到陌生的页面才让 AI 自己去点
• AI 适合探路，不适合天天跑同一条路。现在的普遍做法是先让 AI 把流程跑通一遍，再把它变成固定的脚本，以后重复执行就不用让 AI 一步步琢磨了
• 争论 MCP 好还是命令行好意义不大。真正影响速度和费用的，是工具每一步塞给 AI 多少页面内容，以及能不能一次做完好几步
• 让 AI 用你已经登录好的账号，最方便也最危险。一封藏着恶意指令的邮件，就可能让 AI 把你的数据发出去。最简单的保护办法是给 AI 单独开一个浏览器 Profile，只登录它需要的网站，付款、发消息之前必须由你确认
• 普通人不会为了 AI 换浏览器。OpenAI 的 Atlas 不到一年就关停了，Google 也选择把 Gemini 直接放进 Chrome。真正在快速增长的，是开发者给自己的 AI 助手配的专用浏览器

为什么大家都在抢浏览器入口

在现实世界里，API 能覆盖的只是很小一部分，即使加上 MCP，Agent 能访问和操作的数据也很有限，大量 SaaS 后台、内部系统、需要登录才能看的页面都没有开放接口，浏览器是 Agent 能接触这些系统的唯一入口。对开发者来说需求更直接，Claude Code 写完的前端页面，总得在真实浏览器里点一点、看一眼控制台，才知道到底对不对。

2026 年这个领域变化非常快，几乎每个月都有重量级的产品发布或者转向。我按时间简单列几个节点，你就能感受到这股热度：

• 1 月，Vercel Labs 开源 [[agent-browser]]，到现在已经有 4.5 万 Star；Google 把 Gemini 做成 Chrome 的常驻侧边栏，并推出基于 Gemini 3 的 auto browse
• 3 月，个人开发者 jackwener 开源 [[OpenCLI]]，把网站封装成命令行工具，现在 3 万多 Star
• 4 月，Cloudflare 把 Browser Rendering 改名为 [[Cloudflare Browser Run]]；Codex 桌面版加入内置浏览器和后台电脑操作；Ego Lite 和 Browser Use 团队的 [[Browser Harness]] 先后开源
• 5 月，OpenAI 推出 Codex for Chrome 扩展，Moonshot 推出 Kimi WebBridge，Chrome 发布 [[WebMCP]] 开发文档，随后在 Chrome 149 开启 Origin Trial
• 6 月，YC F25 的 Aside 发布
• 7 月，OpenAI 发布合并了 Codex 的 ChatGPT 桌面 App 和新的 [[ChatGPT Chrome Extension]]，同时宣布弃用 Atlas，8 月 9 日 Atlas 正式关停
• 8 月，Zenity 在 Black Hat 上演示了针对 Claude in Chrome、Gemini in Chrome、Comet、Atlas 和 Copilot Edge 的零点击劫持
• 9 月，Browser Use 和 TypeSafe 开源 [[Jev Ultrafast]]，6 周拿到 2.4 万 Star
• 10 月，[[Playwright]] 1.64 加入 page.webmcp

一年前大家讨论的还是「给人用的 AI 浏览器」，比如我写过的 AI 浏览器 Comet 初体验 和 Dia 浏览器初体验；到了 2026 年，增长最快的反而是「给 AI 用的浏览器」，主角从人换成了 Agent。大厂在收缩自己的独立浏览器，开源社区却在疯狂地给 Agent 造浏览器。

十条路线逐一看

下面按开头的分类逐条来看。每条路线先列出几个典型方案，让你知道它们大概是做什么的，再聊这条路线的特点和我的看法。其中「内置 Agent 的 AI 浏览器」和「Computer Use」在很多梳理里会被漏掉，但前者是普通用户最先接触到的形态，后者是所有基于网页代码的方案都失效时的最后兜底，所以我也把它们放了进来。

传统脚本：最成熟稳定，也是一切的地基

典型方案：

• [[Playwright]]：微软出品，支持 Chromium、Firefox 和 WebKit，现在还内置了测试 Agent、MCP 和命令行工具
• [[Puppeteer]]：Google 维护的 Node.js 库，主要用来控制 Chrome，Chrome DevTools MCP 的底层就是它
• [[Selenium]]：历史最久的浏览器自动化工具，支持多种编程语言和浏览器，企业测试里用得最多

[[Playwright]]、[[Puppeteer]]、[[Selenium]] 最成熟，控制精准、可测试、可复现。只要业务路径是确定的，脚本的单步操作是毫秒级，运行时不消耗任何 Token，永远比让大模型每走一步想一次更快更便宜。当然「零 Token」只在运行时成立，现在越来越多的脚本本身就是 AI 写的。

更有意思的是，这几个老牌工具都在主动拥抱 Agent。Playwright 从 1.56 开始内置 Planner、Generator、Healer 三个测试 Agent，1.62 把 MCP 和 playwright-cli 直接打包进来，10 月 14 日发布的 1.64 甚至加了 page.webmcp。Puppeteer 在 Firefox 上默认改用 WebDriver BiDi，Google 的 Chrome DevTools MCP 底层用的就是它。Selenium 官方博客在 9 月专门写了一篇文章，承认现在大量 Selenium 代码是编程 Agent 写的，而且总在同样几个地方出错，文档里也新增了配合 AI 编程 Agent 使用的章节。传统脚本不是 AI 的对立面，而是 AI 探索之后的「编译产物」，后面几乎所有 AI 方案的底层都还是它们。

CDP 加 MCP 或 CLI：接入最快，Token 最难控

典型方案：

• [[Chrome DevTools MCP]]：Google Chrome DevTools 团队出品，擅长网络请求、控制台和性能调试
• [[Playwright MCP]] 和 playwright-cli：微软出品，前者给支持 MCP 的 AI 工具用，后者给编程 Agent 用，更省 Token
• [[agent-browser]]：Vercel Labs 用 Rust 写的命令行工具，主打返回给 AI 的页面信息足够精简
• [[Browser Harness]]：Browser Use 团队出品，直接连上你正在用的 Chrome，让 Agent 边干活边给自己写工具函数

这条路线的逻辑是借力打力，把现成浏览器的调试和控制能力包装成 Agent 能调用的接口。[[Chrome DevTools MCP]] 是 Google Chrome DevTools 团队做的，强项是网络、控制台和性能调试，全量大约 60 个工具，也提供只保留 3 个工具的 --slim 模式和 chrome-devtools 命令行。[[Playwright MCP]] 依靠无障碍树快照操作页面，但微软自己又推出了 playwright-cli：给编程 Agent 用的话，CLI 加 Skill 更省 Token，因为它不会把页面数据强行塞进模型上下文。[[agent-browser]] 是 Vercel Labs 用 Rust 写的 CLI 加常驻守护进程，直连 CDP，快照用 @e1 这样的引用标记元素，官方说一次快照只有 200 到 400 个 Token。[[Browser Harness]] 来自 Browser Use 团队，MIT 协议，通过 CDP 连接你正在运行的、已登录的 Chrome，特别之处是让 Agent 在任务中自己编写辅助函数。

关于 Token 消耗，各家都有数字，但都很乱。agent-browser 宣称比 Playwright MCP 少用 93% 的上下文，却没给出原始计数，第三方测出来有 82% 的，也有整个任务只少 37% 的；还有人重测发现 Playwright MCP 和 CLI 单步消耗几乎一样。相对完整的是 Browser Use 在 10 月 14 日做的一次评测：100 个任务，用 Codex 驱动云端浏览器，输入 Token 中位数分别是 Browser Harness 210 万、agent-browser 330 万、Playwright MCP 440 万、Chrome DevTools MCP 670 万，而成功率的差异在统计上并不显著。这是 Browser Use 自家的评测，要打个折扣看，但方向和我的体感一致：能力差不多，差别主要在每一步往上下文里塞了多少东西。我之前写过一篇 给 MCP 工具描述瘦身 减少 AI 上下文消耗的实践，浏览器场景是这个问题最严重的地方。

从 Chrome 144 开始，在 Chrome 里打开远程调试开关、点一下允许，外部工具就能连接你正在用的浏览器，Chrome DevTools MCP 的 --autoConnect 和 Browser Harness 都依赖这个能力。在提供了巨大方便的同时，我们也得注意，因为授权的范围是整个浏览器的 profile，所以特别需要注意安全问题。

浏览器插件：借用你的日常 Chrome

典型方案：

• [[Claude in Chrome]]：Anthropic 官方扩展，Claude Code 也能通过它操作你的 Chrome
• [[ChatGPT Chrome Extension]]：OpenAI 官方扩展，前身是 Codex for Chrome，只给 ChatGPT 和 Codex 自己用
• [[Kimi Browser Extension]]：Moonshot 出品，可以把你的 Chrome 交给 Claude Code、Codex 这类外部 Agent
• [[OpenCLI]]：开源项目，把 170 多个网站封装成命令行工具，复用你已登录的 Chrome
• [[Nanobrowser]]、[[Cebian]]：开源的纯扩展 Agent，填上自己的 API Key 就能用

浏览器插件的思路很聪明：日常 Chrome 早就登录好了各种网站，何必再开一个沙箱重新登录？三家大模型厂商都选了这条路。[[Claude in Chrome]] 从 2025 年 8 月发布预览版，12 月向所有付费计划开放，可以用 claude --chrome 让 Claude Code 通过 Native Messaging 操作你的 Chrome。OpenAI 在 2026 年 5 月推出 Codex for Chrome，7 月合并成新的 ChatGPT Chrome 扩展，同样通过桌面 App 的 Native Messaging 连接，但只给 ChatGPT 和 Codex 自己用。Moonshot 的 [[Kimi Browser Extension]] 原名 Kimi WebBridge，是扩展加本地服务的结构，走 CDP，可以把你的 Chrome 交给 Claude Code、Codex 这些外部 Agent，9 月改名后还加了操作录制，录下来可以存成 Skill 重放。Google 是个例外，它不需要做扩展，Gemini 直接集成在 Chrome 里，后面讲内置 Agent 的浏览器时再单独说。

开源项目里，[[OpenCLI]] 确实值得特别留意。它是扩展加本地 daemon，复用你已登录的 Chrome，已经有 170 多个站点适配器，比如 B 站、知乎、小红书、Twitter、Reddit。每个适配器会声明认证策略（公开、Cookie、拦截网络请求、操作界面、本地），作者写适配器时的推荐顺序是先看网络请求，再看页面初始状态，然后搜索前端 bundle，最后才用拦截器。仓库里还带了专门写适配器、自动修复失效适配器的 Skill。这意味着 Agent 不必每次重新「看」页面，而是直接调用沉淀好的网站能力。需要说明的是，「优先读网络请求」是写适配器的推荐路径，并不是所有命令都这样，界面操作类的命令仍然是在点击和输入。

[[Nanobrowser]] 是纯浏览器扩展，没有本地 Bridge，模型请求由扩展直接发出；10 月 15 日发布的 v0.3.0 已经用单一 Agent 取代了旧的 Planner 和 Navigator，网上很多介绍还停留在旧架构。

同样是纯扩展路线的还有 [[Cebian]]，作者是国内开发者猫头猫（maotoumao），名字就是「侧边」的拼音。它是一个住在浏览器侧边栏里的 Agent，不需要注册账号，也没有后端服务器，填入 OpenAI、Anthropic、Google、DeepSeek 或任何 OpenAI 兼容接口的 API Key 就能用，对话和文件都留在本地浏览器里，只有你发出的消息会直接发给你选的模型服务商。能力上，它可以读取当前页面、把选中的元素或截图作为上下文，也能点击按钮、填写表单、操作标签页；还能把一遍浏览器操作录下来让 Agent 自动重放，适合定期重复的任务。扩展该有的周边也比较齐全：内置 MCP 客户端可以接入外部工具，支持 Skills，跨对话的记忆以本地 Markdown 文件保存，默认关闭。项目 2026 年 4 月开源，AGPL-3.0 协议，支持 Chrome、Edge 和 Firefox，10 月 24 日发布了 v1.8.2。它目前还很小众，更适合自己在侧边栏里用；但如果你想要一个开源、自带 Key、不绑定任何厂商的侧边栏 Agent，它值得一试。

这类插件的短板也很明显：扩展权限很大，Claude in Chrome 的 service worker 空闲后会断连，没有无头模式，不适合高并发和长期无人值守。最重要的一条是，它们操作的是你最核心的那个浏览器 Profile，安全风险最高。

Agent 专用浏览器：从内核开始为 Agent 设计

典型方案：

• [[Ego Lite]]：每个 Agent 有自己独立的空间，在后台并行干活，不和你抢标签页和鼠标
• [[BrowserOS]] neo：完全开源，通过 MCP 接入 Claude Code、Codex、Cursor，每次会话都能回放

这类产品不满足于给 Chrome 套插件，而是直接改 Chromium，做一个面向 Agent 的运行时。Ego Lite 的设计包括：每个 Agent 一个独立的 Space，你在前台浏览，Agent 在后台并行工作，互不抢标签页和鼠标；在浏览器引擎内部生成页面快照，能处理跨域 iframe 和 Shadow DOM；Agent 不是一条条调命令，而是写一段 JavaScript，由 ego-browser nodejs 一次执行多个步骤。常见的「内嵌 Node.js」说法不太准确，实际上是 App 打包了一个 Node 运行时，脚本跑在 Node 里而不是页面里。开源策略上，浏览器本体闭源，harness 和 Skill 用 MIT 协议开源。

[[BrowserOS]] neo 则是 YC S24 团队 Felafax 做的，Chromium 补丁都以 AGPL 开源。它走标准 MCP，本地端点是 127.0.0.1:9200/mcp，能一键写入 Claude Code、Codex、Cursor 等工具的配置；每个 Agent 的标签放进一个彩色标签组，每个会话都录成可回放的 DOM 录像，存在本地。两者的哲学差别很有意思：Ego Lite 希望你和 Agent 共用一个浏览器，neo 明确说自己「不是 Chrome 的替代品」，而是放在 Chrome 旁边的第二个浏览器。

这两个产品让我确信一件事：隔离、可观测性、快照质量这几件事，靠插件很难做好，必须在浏览器层面原生支持。Ego Lite 自测的 Real-World Bench（31 个任务）里，它平均 398 秒、成功率 93.5%、每任务 1.64 美元，Browser Harness 是 615 秒和 77.4%。这同样是自测数据，但说明在同一个 Agent、同一个模型下，换一个浏览器工具层，效率差距可以非常大。

内置 Agent 的 AI 浏览器：独立产品在退潮，Chrome 亲自下场

典型方案：

• [[Aside]]：YC 孵化，能直接在你已登录的网站里干活，还有一个专为 Agent 设计的密码管理器
• [[Comet]]：Perplexity 出品，以 AI 搜索为核心
• [[Dia Browser]]：Arc 浏览器团队出品，偏向围绕网页对话和辅助写作
• BrowserOS：开源浏览器，除了给外部 Agent 用的 neo，本身也内置了 Agent
• [[Gemini in Chrome]]：Google 直接集成在 Chrome 里，不用换浏览器
• ChatGPT Atlas：OpenAI 出品，已于 2026 年 8 月关停

这是普通用户最先接触到的形态：浏览器自带一个 Agent，你在侧边栏或地址栏里下指令。Aside、[[Comet]]、[[Dia Browser]]、BrowserOS 都属于这一类。最值得一提的是 Aside 的 Aside Vault，它把「Agent 能登录」和「Agent 能看到密码」拆开了：凭据直接自动填进网页，模型拿不到明文，还有按任务的访问策略和审计日志，这是我在这一轮调研中见到的最用心的安全设计。Aside 还宣称在 Online-Mind2Web 上拿到了 99.0% 的成绩，不过是自测自评。它同时提供 CLI 和 MCP，也能给 Claude Code 当浏览器后端，详细介绍可以看我单独写的 Aside AI 浏览器介绍。

还有一个特殊的成员是 Google 的 [[Gemini in Chrome]]。Google 不需要说服任何人换浏览器，它直接把 Gemini 集成进了 Chrome 本身。2026 年 1 月 28 日，Gemini 从原来的浮动窗口变成常驻右侧的侧边栏，同时推出基于 Gemini 3 的 auto browse，可以替你滚动、点击、输入，完成多日期比价、填写表单、收集报税文件这类多步骤的杂事。获得你的授权后，它能调用 Google 密码管理器处理需要登录的任务，还能连接 Gmail、日历、地图、Google Flights 这些 Google 自家应用；遇到购买、发帖这类操作，它会停下来让你确认，或者让你自己完成最后一步。目前 auto browse 只在美国以预览形式向 Google AI Pro 和 Ultra 订阅用户开放，5 月宣布登陆 Android 版 Chrome，I/O 2026 上又宣布要和 Gemini Spark 打通。它和浏览器插件最大的区别是不需要安装任何东西，Agent 就是浏览器本身的一部分。

但独立的 AI 浏览器这条路正在退潮。ChatGPT Atlas 从 2025 年 10 月 21 日发布到 2026 年 8 月 9 日关停，只活了 292 天，始终只有 macOS 版本，它的能力被拆进了 ChatGPT 桌面 App 的内置浏览器和 Chrome 扩展里。我的理解是，让用户为了 AI 换掉日常浏览器的成本太高了。OpenAI 退回到「扩展加桌面 App」，Google 则把 Agent 直接塞进了用户最多的浏览器，两家走的路不同，结论却一样：Agent 应该去用户已经在的地方，而不是让用户为它搬家。

顺带一提 Deta Surf，它是这一组里的反例：内置了浏览器，但 AI 只读不动手，把网页、PDF、YouTube 收进本地资料库，生成带引用的笔记，更像一个本地版的 [[NotebookLM]]。它提醒我，不是所有「AI 加浏览器」的需求都应该用 Agent 来解决。

自主 Agent 框架：从全自主走向混合

典型方案：

• [[browser-use]]：最有名的开源自主 Agent 框架，给它一个目标，AI 自己一步步探索完成
• [[Stagehand]]：Browserbase 出品，已知的步骤写代码，不确定的部分交给 AI
• [[Skyvern]]：面向企业流程，靠看截图理解页面
• [[Jev Ultrafast]]：Browser Use 和 TypeSafe 的实验项目，把 AI 能做的操作压缩到 8 种，追求极致速度

[[browser-use]] 是端到端自主探索的代表，适应性强，但在复杂长链路任务里 Token 开销大、结果有波动。[[Stagehand]] 是 Browserbase 做的混合框架，已知步骤写代码，未知节点交给 act、extract、observe 这几个 AI 原语。它在 2025 年的 v3 就去掉了内置的 Playwright 依赖，改为直接走 CDP；2026 年 8 月 10 日发布的 v4 又重写了一次，不再需要任何外部驱动，把 CDP 调度放进浏览器扩展里，只支持 Chromium；agent() 被移除；缓存改成在 Browserbase 云端进行，用本地浏览器时没有缓存。[[Skyvern]] 偏企业级流程，用多模态模型看带标注的截图，拆成 Actor、Planner、Validator 三个角色，Skyvern 2.0 在 WebVoyager 上的成绩是 85.85%，协议是 AGPL-3.0。

[[Jev Ultrafast]] 是 Browser Use 和 TypeSafe 在 9 月开源的实验项目，把每个页面变成一张编号的元素表，只允许 8 种操作（点击、输入、选择、上下滚动、等待、完成、受阻），一次请求同时选操作和目标。README 里的例子是在 Google Flights 上查苏黎世到伦敦的航班，用时 7.1 秒，浏览器协议调用从 1092 次降到 101 次。代价是不支持 Shadow DOM、iframe、Canvas、文件上传和弹出新标签，而且依赖 TypeSafe 的专有决策模型 [[Jev]] 和 API Key。

这类框架最值得关注的是方向上的变化。Stagehand 删掉了 agent()，Skyvern 把成功的运行转成 Playwright 脚本缓存起来，下次直接重放、坏了再让 AI 重新生成，官方称能快 3 到 5 倍、便宜最多 70%。就连 Browser Use 自己，也在全自主框架之外又押了两个注：让编程 Agent 自己写辅助函数的 Browser Harness，以及极致压缩动作空间的 Jev Ultrafast。这些框架都在远离「每一步都让大模型想一想」。

云端浏览器：规模化之后的真问题

典型方案：

• [[Browserbase]]：全托管的云端浏览器服务，起步最早，功能也最完整
• [[Steel]]：开源，可以用 Docker 自己部署
• [[Cloudflare Browser Run]]：Cloudflare 出品，按小时计费，几家里价格最低

当任务从一台电脑走向服务器批量运行，问题就变成了并发调度、资源隔离、会话持久化、代理轮换、反爬和故障恢复。[[Browserbase]] 是全托管的代表，2025 年 6 月完成 4000 万美元 B 轮，估值 3 亿美元，开发者套餐每月 20 美元，包含 25 个并发浏览器和 100 小时，Contexts 可以持久化 Cookie 和本地存储，还有 Live View 和会话回放。[[Steel]] 用 Apache-2.0 开源，一条 docker run 就能自托管，云服务大约每浏览器小时 0.10 美元。Cloudflare Browser Run 在 4 月改名时加了公开的 CDP 端点、Live View、人工接管和录像，付费计划含每月 10 小时，超出后每小时 0.09 美元，是这几家里最便宜的。

不少介绍说 Cloudflare Browser Run「兼容 Stagehand」，这一点要打个问号：Cloudflare 文档里的示例还是 v2 风格，而 Stagehand 从 v3 开始不再基于 Playwright，在 Workers 里运行新版本的兼容问题还有 issue 在跟踪，从 Workers 外部通过 CDP 连接问题不大。另一个现实问题是数据中心 IP，X、LinkedIn 这类网站会直接把你当机器人拦下，需要登录态的个人任务放在云端很痛苦。Cloudflare 的 /crawl 是一个用 Web Bot Auth 签名的 Agent，遵守 robots.txt，不绕过机器人防护，我觉得这代表了另一种未来：网站不再和 Agent 斗智斗勇，而是识别它、给它放行或限流。

数据采集：能抓就别点

典型方案：

• [[Crawl4AI]]：开源爬虫，能把网页转成干净的 Markdown，可以自己部署
• [[Firecrawl]]：托管的网页抓取 API，也有开源版本
• [[Jina Reader]]：在网址前面加一个前缀，就能拿到这个页面的 Markdown 版本

如果目标只是把公开网页变成干净的 Markdown 或 JSON，完全没必要让 Agent 模拟点击。[[Crawl4AI]] 现在有 8.6 万 Star，Apache-2.0 协议，提供去噪后的 Fit Markdown、不调用 LLM 的 CSS/XPath 抽取、LLM 抽取和自适应爬取，Docker 服务自带 MCP。[[Firecrawl]] 是托管 API 路线（开源部分为 AGPL），我之前写过 FireCrawl 强大的数据爬虫工具。单页阅读的话 [[Jina Reader]] 最省事。我自己在 Claude Code 里做调研，读资料基本都走这类工具，只有遇到强交互或者需要登录的页面，才会动用浏览器 Agent。

Computer Use：最通用也最昂贵的兜底

典型方案：

• Claude computer use：Anthropic 在 2024 年 10 月推出
• Gemini Computer Use：Google 在 2025 年 10 月发布预览
• Codex 后台电脑操作：OpenAI 在 2026 年 4 月加入 Codex 桌面版

这条路线不看 DOM，直接看屏幕截图，用坐标点击和键盘输入。Anthropic 在 2024 年 10 月推出 computer use，Google 在 2025 年 10 月发布 Gemini 2.5 Computer Use 预览，OpenAI 在 2026 年 4 月给 Codex 桌面版加入了后台电脑操作，可以用自己的光标操作 Mac 上的应用。它的优势是通用，Canvas 页面、桌面应用、远程桌面都能处理；劣势是每一步都要传截图，慢且贵。2026 年 6 月发布的 OSWorld 2.0 把任务换成跨网站和桌面应用的长流程之后，论文发布时最好的模型也只能完整完成约两成任务。我把它当作 DOM 方案失效时的最后一层兜底，而不是首选。

WebMCP：让网站自己开口

这条路线目前只有一个方案，就是 Google 和微软正在推动的 Web 标准 [[WebMCP]]，Chrome 和 Edge 已经开始试验。

[[WebMCP]] 是我最看好的长期方向。它让网站通过标准接口直接把能力注册成工具，Agent 不用再去猜按钮在哪：

await document.modelContext.registerTool({
  name: "add-todo",
  description: "Add a new item to the user's active todo list",
  inputSchema: {
    type: "object",
    properties: { text: { type: "string" } },
    required: ["text"]
  },
  async execute({ text }) {
    await addTodoItemToCollection(text);
    return { content: [{ type: "text", text: `Added: ${text}` }] };
  }
});

但它的成熟度需要说准确。它目前是 W3C Web 机器学习社区组的草案，还不是正式标准，编辑来自 Google 和微软；Chrome 149 和 Edge 150 以 Origin Trial 形式提供；入口 API 已经从 navigator.modelContext 改成了 document.modelContext，表单上的声明式写法在 10 月 8 日被移出了规格正文；Firefox 和 Safari 还没有任何承诺。Playwright 1.64 和 Cloudflare Browser Run 已经开始支持它。它还有一个天然的鸡生蛋问题：愿意被 Agent 使用的网站会接入，不愿意的网站（恰恰是反爬最严的那些）永远不会。所以在可预见的未来，WebMCP 会和 DOM 操作长期共存。

用三个问题给这些方案归类

看完这十条路线，你可能已经发现，路线之间的边界其实没那么清楚，真到选型时经常对不上号：Ego Lite 和 Claude in Chrome 都能用你的登录态，算不算一类？Browserbase 和 Stagehand 总是一起出现，又该归到哪边？问题在于，这些工具并不是在抢同一个位置，而是各自只负责「让 AI 用浏览器」这件事里的一部分。所以我换了个角度，拿下面三个问题去问每一个方案：

• 谁在指挥浏览器？可能是提前写好的脚本，运行时根本没有 AI 参与；可能是浏览器里自带的 AI，比如 Aside、Comet；也可能是你电脑上的 Claude Code、Codex 这类 AI 助手，浏览器只负责听命令
• 用的是哪个浏览器？可能是你平时上网用的 Chrome，里面登录着你所有的账号；可能是本机上一个专门给 AI 用的浏览器；可能是一个什么都没登录的空白浏览器；也可能是远程服务器上的浏览器
• AI 怎么看网页、怎么动手？可能是照着写好的代码找按钮；可能是读一份浏览器整理好的「页面元素清单」，再按编号点击；可能是像人一样看截图、按坐标点鼠标；也可能是网站直接把功能开放出来，AI 调用就行

用这三个问题把十条路线过一遍，就得到了下面这张表：

回头再看上面那两个例子就清楚了。Ego Lite 和 Claude in Chrome 都能用你已经登录好的账号，区别在于前者是一个专门给 AI 用的浏览器，后者直接用你平时上网的那个 Chrome。Browserbase 和 Stagehand 则根本不是同一种东西：Stagehand 负责让 AI 判断下一步该点哪里，Browserbase 负责提供一台远程服务器上的浏览器，一个出脑子，一个出场地，所以它们经常搭配在一起用。同样，Playwright 既可以是你手写的测试脚本，也可以是 Playwright MCP 背后真正干活的那部分。很多方案并不互斥，而是可以叠在一起用。想明白这一点，选型时就不会再纠结「哪个最好」，而是分别想清楚：谁来指挥、用哪个浏览器、让 AI 用什么方式看网页。

我的几个判断

看懂网页这件事，正在从 AI 身上转移出去

把这些路线排成一排，我发现它们最本质的区别是：看懂网页这个活，到底由谁来干。最左边是 Computer Use，AI 像人一样盯着截图，自己判断按钮在哪、该点哪个坐标，所有的理解工作都压在 AI 身上；往右一步，浏览器先把页面整理成一份元素清单，AI 只要读文字、按编号点击；再往右是 Ego Lite、agent-browser 这样的工具，清单更精简，AI 还能一次写好几步操作批量执行；然后是 OpenCLI 的站点适配器，直接调用网站自己的数据接口，AI 几乎不用看页面；最右边是 WebMCP，网站主动把「搜索」「下单」这类功能交到 AI 手里。

越往右，花的钱越少、速度越快、结果越稳定，但能支持的网站也越少。所以我的选型原则很简单：在能用的方案里，尽量选最靠右的那个，左边的方案只在右边都用不了时兜底。

探索交给 AI，执行交给代码

这一轮调研里，我看到几乎所有方案都在收敛到同一个模式：第一次用 AI 探索，跑通之后沉淀成确定性的东西，以后重复执行。Playwright 的 Generator 和 Healer，Skyvern 的代码缓存，Stagehand 的缓存，OpenCLI 的适配器编写和自动修复，Ego Lite 的站点经验包，Kimi 的操作录制转 Skill，Browser Harness 让 Agent 自己写辅助函数，说的都是同一件事。大模型在这里更像一个编译器，把模糊的意图编译成可以重复运行的脚本，脚本失效了再重新编译一次。这其实和我在 AI Coding Agent 语境下的 Harness Engineering 里聊的思路一致，Agent 的价值不只是自己干活，更在于把经验变成可复用的工具。

MCP 还是 CLI 不是关键

社区里经常争论浏览器工具该做成 MCP 还是 CLI。从上面那些数据看，协议本身不是关键，真正决定效率的是两件事：会不会把整页数据强行塞进上下文，以及能不能一次执行多个步骤。MCP 的优势是通用，任何支持 MCP 的工具填一个地址就能用，所以 BrowserOS neo 选了它；CLI 和代码对编程 Agent 更高效，所以微软在 Playwright MCP 之外又做了 playwright-cli，Ego Lite 干脆让 Agent 写脚本。两种形态会长期共存，选哪个取决于你的 Agent 是不是擅长写代码。

登录态是最值钱也最危险的资产

几乎所有方案的核心卖点都是「复用你的登录态」，这恰恰也是最大的风险。OpenAI 在 2025 年 12 月 22 日加固 Atlas 的文章里直说，提示注入就像网络诈骗和社会工程学一样，「unlikely to ever be fully solved」。Anthropic 公布的数据是，Claude in Chrome 在 123 个测试用例上的攻击成功率从无防护时的 23.6% 降到了 11.2%，支持页面上称 Opus 4.8 当前配置在内部测试中低于 0.08%。但 Zenity 在 2026 年 8 月的 Black Hat 上演示，只是让 Claude in Chrome 总结一封带恶意指令的邮件，就能导出 Gmail 数据、共享 Google Drive、接管 Slack 和 X 账号。他们的观点是，Agent 在一个会话里同时读取多个来源的内容，从根本上破坏了浏览器的同源策略，CTO 的原话是「This is not a bug we can patch away」。

对应的防御思路也很清楚，各家都在做一部分：隔离（Ego Lite 的 Space、neo 的标签组、单独的浏览器），凭据保险箱（Aside Vault），敏感操作人工审批，事后审计和回放（neo 的会话录像），以及网站端的签名 Agent（Web Bot Auth）。我给自己定的规矩是：Agent 永远不碰我主力 Chrome 的 Profile，单独建一个 Profile，只导入任务真正需要的几个网站，银行、主邮箱一律不导；新任务先用只读方式跑；涉及付款、发消息、发帖的操作，必须停在最后一步由我确认。

独立 AI 浏览器在退潮，给 Agent 的浏览器在崛起

Atlas 关停和一堆 Agent 浏览器工具的 Star 增长放在一起看，信号非常明显。普通用户不会为了 AI 换浏览器，就连 Google 也没有另做一个 AI 浏览器，而是把 Gemini 直接放进了 Chrome；但开发者很乐意给自己的 Agent 配一个浏览器：Ego Lite 半年 2 万 Star，agent-browser 9 个月 4.5 万，OpenCLI 7 个月 3 万，Jev Ultrafast 6 周 2.4 万。浏览器的角色正在从「给人用的产品」变成「给 Agent 用的运行时」，这可能是未来一两年这个领域最大的结构性变化。

我会怎么选

结合上面的分析，这是我自己的选型表，每个选择背后的注意事项也写在了最后一列：

我自己的日常组合是这样的：写代码时让 Claude Code 用 agent-browser 或 playwright-cli 去验证本地页面，跑通的流程让它顺手写成 Playwright 测试；需要登录态的个人杂事交给 Ego Lite，用一个只导入了必要网站的 Profile；查资料基本靠 Jina Reader 和 Firecrawl，很少让 Agent 真去点网页。这套组合的思路就是前面说的「尽量往右选」，真正需要 Agent 动手操作浏览器的场景，其实比想象中少得多。

几个容易踩的坑

下面是我自己踩过、或者在调研中反复看到的问题：

• 快照里的元素引用（@e21 这种）在页面变化后会失效，每次操作前重新取快照是最稳的做法
• 不要让 MCP 把整棵无障碍树都返回，agent-browser 的 -i 只看可交互元素、Chrome DevTools MCP 的 --slim 都能大幅减少上下文
• 遇到验证码和二次验证，正确的做法是交给人处理，而不是想办法绕过，这既是工程问题也是合规问题
• BrowserOS、Skyvern、Firecrawl 用的是 AGPL，想嵌进商业产品前先看清楚协议
• 文中几乎所有的性能数字（Ego Lite、Aside、agent-browser、Stagehand、Jev Ultrafast、Browser Use 的评测）都是厂商自测，最可靠的办法永远是拿你自己的真实任务跑一遍

最后

梳理完这一圈，我最大的收获是不再执着于找「最强的 AI 浏览器」。让 AI 用浏览器，其实要分开回答三件事：谁来指挥，用哪个浏览器，AI 用什么方式看网页。每件事都有成熟的工具可选，真正的功夫在于把它们搭配好，以及判断什么时候根本不需要 AI。确定性能解决的就用脚本，网站有接口就走接口，只有真正未知的部分才交给模型，这条原则在 2026 年比任何具体工具都更经得起时间。

展望一下，我觉得接下来一年有几件事值得关注：WebMCP 能不能在几个大型 SaaS 上真正落地；「AI 探索、代码执行」的经验沉淀能不能形成像插件市场一样的共享生态，比如 OpenCLI 的适配器、Ego Lite 的经验包；以及 Agent 专用浏览器会不会像当年的无头浏览器一样，变成每个开发者工具箱里的标配。安全问题短期内不会有银弹，在那之前，给 Agent 一个单独的 Profile 是最便宜也最有效的保护。

2026-10-26 13:00:00

家里的 [[Homelab]] 一直是一台 4 盘位的小主机跑 [[Proxmox VE]]，上面跑着 Ubuntu 虚拟机、一堆 Docker 服务和下载机。平时远程管理全靠 SSH 加 [[Tailscale]]，只要系统还活着基本没什么问题。真正让我不放心的是系统起不来的时候：升级内核后卡在启动界面、改网卡配置时手滑导致网络没起来、BIOS 被重置后不再从正确的硬盘启动，这时候 SSH 连不上，Tailscale 也不会在线，人不在家就只能干等。最近正好赶上一波促销，我入手了 [[GL.iNet]] 的 Comet Pro（型号 GL-RM10）远程 [[IP KVM]]，叠加各种限时优惠之后实际支付 590.76 元，算是把 Homelab 远程管理的最后一块短板补上了。

远程桌面解决不了的问题

我们平时用的 [[AnyDesk]]、[[TeamViewer]]、[[RDP]]、VNC 这类远程桌面工具，本质上都是跑在操作系统里的一个程序，系统没启动、卡死或者网络配置坏了，它们也就跟着失效。服务器厂商的解决办法是在主板上放一颗独立的 BMC 芯片，也就是常说的 [[IPMI]]、iDRAC、iLO，不管操作系统是什么状态都能远程看到画面、按电源键。但我们在家里用的迷你主机、NAS 小主机、旧台式机几乎都没有这个东西。

IP KVM 就是把 BMC 做成了一个外挂的小盒子。它通过 HDMI 采集目标电脑的画面，通过 USB 模拟键盘鼠标，再把这些信号经网络传到浏览器里，于是开机自检、BIOS/UEFI 设置、系统安装界面都能远程看到并操作，和坐在机器前面没什么区别。对 Homelab 来说，这意味着即使宿主机彻底起不来，也能在外面进 BIOS 改启动顺序，或者挂一个 ISO 重装系统。

几年前想要这个能力，基本只有 [[PiKVM]] 一个选择，要么买树莓派加采集模块自己 DIY，要么买 V4 Mini 这样的成品，价格在 275 美元左右。2024 年之后情况变了，[[JetKVM]] 在 Kickstarter 上众筹爆火，Sipeed 推出了 [[NanoKVM]]，GL.iNet 也做了 Comet 系列，消费级 IP KVM 的价格被拉到了 100 美元上下，这也是我开始认真考虑买一台的原因。

为什么选了 Comet Pro

GL.iNet 的 Comet 系列目前有好几款：入门的 Comet（GL-RM1）、带 PoE 的 Comet PoE（GL-RM1PE）、本文的主角 Comet Pro（GL-RM10），以及走 5G 网络的 Comet 5G（GL-RM10RC）。Comet Pro 是其中配置最完整的一款，相比入门款多了双频 Wi-Fi 6、2.22 英寸触摸屏和 HDMI 直通输出，存储从 8GB 提升到 32GB eMMC，处理器也从 Cortex-A7 换成了四核 Cortex-A53 加 1GB 内存。它在 2025 年 8 月上 Kickstarter 众筹，同年 12 月开始发货。

让我下决心的其实是价格。Comet Pro 官方定价 179.99 美元，亚马逊上平时的折扣价也在 145～160 美元，而我这次 590.76 元到手，按现在的汇率折合 80 多美元，不到官方定价的一半，基本和 JetKVM、Comet 入门款是一个价位。同样的钱能拿到 Wi-Fi 6、32GB 存储和 HDMI 直通，就没有太多犹豫的理由了。下面是我购买前整理的几款主流方案对比：

如果按原价买，我大概率会选 JetKVM，毕竟便宜一半而且完全开源。但在价格拉平之后，Comet Pro 的硬件余量明显更大，A53 加 1GB 内存跑 Web 界面和视频编码都更从容，再加上 GL.iNet 做路由器多年，固件更新和售后相对靠谱，所以选它是比较自然的结果。

无线连接到底解决了什么

Comet Pro 最大的卖点是双频 Wi-Fi 6，官方称它是第一款同时支持 2.4GHz 和 5GHz 的桌面 KVM。不过这里要先说清楚它的边界：Wi-Fi 只是替代了 KVM 到路由器的那根网线，KVM 到被控电脑的 HDMI 线和 USB 线还是少不了，所以它不是「无线控制电脑」，而是「KVM 本身可以无线联网」。理解了这一点再看它的价值，主要体现在机器所在的位置没有网口，或者交换机口已经插满的场景，Comet Pro 可以直接放在机器旁边，不用为它再拉一根线。

配置过程也因此简单了不少。设备通电后在触摸屏上直接选择 Wi-Fi、输入密码，屏幕上就会显示分配到的 IP，用浏览器打开这个地址就能开始初始化，全程不需要先插网线或者去路由器后台找设备。远程画面用的是 H.264 硬件编码，局域网内官方标称延迟 30～60ms，网络一般的时候也可以从 4K@30 切到 1080p@60，这点码率对 Wi-Fi 6 来说绰绰有余。

不过有一个容易被忽略的坑：KVM 自己也要依赖网络才能被访问到。如果你的软路由（比如 OpenWrt、iKuai）是跑在 PVE 的虚拟机里，那么 PVE 宿主机挂掉的同时家里的网络也一起断了，KVM 不管是有线还是无线都连不上，形成一个循环依赖。这种情况下要么让 KVM 连到一台独立的主路由上，要么接受「宿主机挂了只能等回家」的现实。

板载存储与虚拟媒体

32GB eMMC 是我比较看重的另一点。IP KVM 的虚拟媒体功能可以把上传的 ISO 挂载成一个 U 盘给被控电脑，远程重装系统就靠它。Proxmox VE 的安装镜像只有一两 GB，Windows 11 镜像也就 5～7GB，32GB 的空间足够同时放好几个常用镜像，需要的时候直接挂载，不用每次重新上传。入门款 Comet 只有 8GB，放一个 Windows 镜像就去掉了一大半。

除了装系统，这块存储也可以当成一个临时的文件中转站。比如被控机器网络坏了，需要把一个修好的网卡驱动或者配置文件送进去，就可以先传到 KVM 上，再以 U 盘的形式挂给目标机器，绕过它自己已经瘫痪的网络。

触摸屏、直通与软件生态

HDMI 直通（Loop Out）是我之前没太在意、但仔细想想很实用的功能。被控电脑的画面同时输出给 KVM 和本地显示器，机器旁边有人用的时候完全不受影响，不需要被控电脑额外拿出一个视频输出口。机身上的 2.22 英寸触摸屏不显示被控电脑的画面，主要用来查看 IP、连接 Wi-Fi、开关云服务，还可以设置一个 4 位 PIN 锁住屏幕，防止别人随手改设置。

软件方面，Comet Pro 的固件叫 GLKVM，核心守护进程 KVMD 是 PiKVM 的衍生项目，以 GPL-3.0 协议开源在 GitHub 的 gl-inet/glkvm 仓库里。GL.iNet 在上面套了一层 Vue 写的新界面，原版 PiKVM 的 Web UI 其实也打包在固件里，只是在 nginx 配置中被注释掉了，习惯 PiKVM 界面的话可以手动切回去。远程访问有几种方式可以选：官方的 GLKVM Cloud、开源可自托管的 glkvm-cloud、Apps Center 里内置的 [[Tailscale]]，以及 [[ZeroTier]] 和 [[NetBird]]。我自己一直在用 Tailscale 组网（之前写过一篇 Tailscale 简单使用），所以会直接用内置的 Tailscale，不打算依赖官方云。

部署计划与需要注意的地方

我的计划是把它接到跑 PVE 的宿主机上，作为整台 Homelab 的兜底方案。连接方式本身很简单，包装里电源适配器、两根 HDMI 线、USB-C 线和网线都有，基本不需要额外买线：

1. 用 USB-C 线连接 Comet Pro 和宿主机，负责键鼠模拟和虚拟媒体
2. HDMI 线从宿主机接到 Comet Pro 的 HDMI IN，本地如果还要用显示器就接到 HDMI OUT
3. 在触摸屏上连接 Wi-Fi，浏览器打开显示的 IP，设置管理员密码并开启两步验证
4. 在 Apps Center 里启用 Tailscale，加入自己的 tailnet

购买前翻文档和评测时，整理了几个比较容易踩的坑。第一是供电，Comet Pro 可以从被控电脑的 USB 口取电，但电脑关机或进入睡眠（S3/S4）时 USB 可能断电，KVM 也会跟着掉线，所以最好用单独的电源适配器供电，或者在 BIOS 里打开 USB 待机供电。第二是显示输出，不少电脑只在主显示输出上显示 BIOS 画面，多显示器的机器要把 KVM 接在主输出上；如果被控电脑只有 USB-C 视频输出，还要确认这个口支持 DP Alt Mode。

第三是远程开机。Comet Pro 内置了 [[Wake on LAN]]，但前提是宿主机的 BIOS 和网卡都开启了 WOL，PVE 里也要确认网卡配置没有把它关掉。对完全断电关机的机器，官方提供了 ATX 控制板（接主板的电源和复位针脚）和 Fingerbot（一个物理按开机键的小机械臂），都通过 Comet Pro 的 USB-A 口连接。很多迷你主机主板上根本没有 ATX 针脚可接，这时候 Fingerbot 反而更通用。还有一个更便宜的思路是在 BIOS 里打开「来电自动开机」（Restore on AC Power Loss），再配合一个智能插座断电再上电，也能实现远程开机。

第四也是最重要的一点是安全。IP KVM 等于拿到了这台机器的物理控制权，能进 BIOS、能挂载 ISO、能输入任意按键，一旦被别人登录进来，后果比 SSH 密码泄露严重得多。NanoKVM 之前就因为默认密码、硬编码密钥、未说明的麦克风等问题被反复报道过，虽然后来大部分都修了，但足以说明这类设备出问题的代价。我的原则是绝不把 KVM 的 Web 界面直接暴露到公网，只通过 Tailscale 访问，同时开启两步验证、改掉默认密码，并保持固件更新。

需要接受的妥协

Comet Pro 也不是没有短板。名字叫 Pro 却不支持 PoE，想要一根网线供电只能退回 Comet PoE；4K 只有 30FPS，日常操作没问题，但别指望用它看流畅的 4K 画面；存储也没有 microSD 或 USB 3 扩展，32GB 就是全部。另外它只能控制一台电脑，如果要管理多台机器，要么每台配一个，要么再加一个 KVM 切换器，到这个规模可能就该考虑带 BMC 的服务器主板了。

还有就是 ATX 控制板和 Fingerbot 都要另外购买，如果宿主机完全不支持 WOL，又没有 ATX 针脚，那远程开机这件事还得再多花一点钱。早期评测里也有提到音频和麦克风偶尔需要重启才能恢复，好在 GL.iNet 的固件更新还算频繁，这类问题基本随着版本迭代慢慢被修复了。

最后

像 Proxmox VE 8 升级到 9 这种需要重启宿主机的操作，最怕的就是重启之后机器没回来，而人又不在旁边。有了 Comet Pro 之后，最坏的情况也只是远程进 BIOS 或者挂 ISO 重装，心理负担会小很多，这才是 IP KVM 真正的价值：它平时几乎用不上，但关键时刻能让你不用跑回家。

对我来说，590.76 元的价格让 Comet Pro 从一个「有点贵的高端款」变成了「同价位里配置最完整的选择」，Wi-Fi 6、32GB 存储和 HDMI 直通都是实打实的加分项。如果你的 Homelab 也是没有 IPMI 的迷你主机或者自组装机器，又正好遇到不错的折扣，很值得考虑。等实际用一段时间后，我再写一篇聊聊日常使用的体验，包括 Tailscale 远程访问的延迟、虚拟媒体重装系统的流程，以及原版 PiKVM 界面怎么切回去。

2026-10-19 13:00:00

现在我写代码基本是 [[Codex]] 和 [[Claude Code]] 轮着用。有时候是 Codex 的额度先用完了，有时候是某一步我觉得 Claude Code 更合适，于是一个任务经常要在两个 Agent 之间换手。真正麻烦的不是换工具本身，而是换手的那一刻：新会话对前面发生的事一无所知。之前选了哪个库、哪个旧接口不能动、改了哪些文件、测试跑没跑过，这些信息全都留在上一段对话里。我只能手动复述一遍，或者把一大段聊天记录贴回去，前者容易漏掉关键约束，后者浪费 Token，还会让模型在几千行历史里抓不住重点。说到底，我缺的不是一个更大的上下文窗口，而是一份能在 Agent 之间传递、而且接手方可以核对的「当前状态」。在写这篇文章的时候还出现了另外一个思路就是利用 [[magpie]] 将模型路由给充足额度的账号，这个之后再写文章说。

在 AI 记忆这件事上我已经试过不少方案。claude-mem 为 AI Agent 提供持久化记忆 解决了单个 Agent 跨会话的问题，但记忆绑在 Claude Code 上，换一个 Agent 就用不了了。[[Nowledge Mem]] 我已经用了大半年，它让所有 Agent 共享同一份个人记忆，偏好、基础设施、长期决策都记得很牢，详细体验写在 Nowledge Mem 使用半年体验：让所有 AI Agent 共享同一份记忆。不过它记的是「我是谁、我习惯怎么做」，而不是「这个任务做到了哪一步、下一步该谁来做」。直到看到 [[OceanBase]] 开源的 [[PowerContext]]，我才找到专门补这一块的工具。它把决策、约束和工作进度从对话里剥离出来，存到一个独立的服务里，用 Handoff 的方式交给下一个会话、下一个 Agent，甚至下一个人。

这篇文章会先介绍 PowerContext 的核心概念和安装方法，然后用一个从 Claude Code 交接到 Codex 的完整场景把流程跑一遍，最后分享我用 Docker 把它部署到 Homelab、通过 Cloudflare Tunnel 远程访问的过程，以及中间踩到的 Dashboard 登录 403 的坑。

PowerContext 是什么

PowerContext 是一个开源的 AI Agent 上下文服务（context service），采用 Apache 2.0 协议，是 OceanBase 之前 [[PowerMem]] 项目的全面升级版。项目的 slogan 是「Not only memory but full story」，意思是它不只记住零散的事实，而是把工作中真正值得延续的部分——决策、约束、证据、进度——沉淀成可以检查、带版本的 Artifact，保存在任何单个对话之外。

重读聊天记录在新会话里只能靠手动，换 Agent 更是完全失效；对聊天记录做 RAG 能跨会话，但换了 Agent 一样找不到；Agent 自带的本地记忆文件（比如 CLAUDE.md、AGENTS.md）可以跨会话，但同样绑死在某一个宿主上。PowerContext 把这些信息放在服务端，Codex 和 Claude Code 只要连同一个 Server、同一个 Scope，看到的就是同一份上下文。这也是我认为它最核心的能力：构建跨会话、跨 Agent 的上下文和记忆。

从架构上看，PowerContext 分成三层。最底层是 Core 协议，定义了 Source、Artifact、Trigger 三类契约，方便嵌入到别的应用或者替换组件；中间是内置运行时，提供 Memory、Handoff、Experience、Skill 四类服务以及调度、推理和存储后端；最上层是 Server 和各种接入方式，包括 HTTP API、[[MCP]]、Python 异步客户端、CLI、Dashboard 以及各个 Agent 插件。这几种接口共享同一个 Server 和持久化存储，所以无论从哪个入口写进去的记录，从其他入口都能读出来。存储默认用本地 [[SQLite]]，也可以换成嵌入式的 [[seekdb]]，支持全文检索与向量检索的混合召回。

核心概念

理解 PowerContext 最重要的是先搞清楚 Scope。所有数据都属于某一个 Scope，一个 Scope 就是一套独立的 Source 日志、Memory 生命周期、审核收件箱和 Handoff 历史，结构大致如下：

Scope
├── Source journal    # 证据：提示词、文档、工作契约、任务结果
├── Memory            # atomic-memory/ARTIFACT_ID@REVISION —— 决策、约束、下一步
├── Review Inbox      # 等待审核的 Experience 和 Skill 候选
├── Handoff history   # handoff/ARTIFACT_ID@REVISION —— 跨会话的工作延续
└── Topic Memory      # 后台从符合条件的 Source 中抽取

需要注意的是，Scope ID 只是用来选择数据的，它不代表用户身份，也不授予任何工具权限。换一个工作目录不会自动创建隔离，想让两个 Agent 共享上下文，就让它们使用同一个 Server 和同一个 Scope；想隔离，就显式建一个新的 Scope。

Memory 存放可以复用的决策、约束、事实、状态和下一步。每条记忆都有 active、forgotten、merged、retired 几种状态，「遗忘」一条记忆只是把它移出召回范围，内容和历史仍然保留，可以随时恢复。显式写入 Memory 不需要任何模型，只有从对话 Source 中自动抽取记忆时才需要配置生成模型。这一点继承自 PowerMem 时期的设计思路：PowerMem 就强调智能记忆处理，过滤低质量信息、检测并更新冲突记忆，并模拟艾宾浩斯遗忘曲线按访问频率和重要性调整权重。

Handoff 是我最喜欢的部分。它记录的不是整段对话，而是「当前状态」，按照一个四步闭环运作：

Work Contract → Prepared Handoff → Acknowledgement → Task Outcome

Work Contract 记录被委派任务的目标和完成边界；Handoff 由交出方检查当前分支、改动文件、测试结果、阻塞点和下一步之后生成；接收方拿到之后要先核对证据，再记录一个 Acknowledgement，表明自己接受、需要澄清还是拒绝；任务结束时再记录 Task Outcome，保留最终状态和每一项检查结果，失败或跳过的检查不会被抹掉。这个流程比「把聊天记录复制过去」多了一层可验证性，接手的 Agent 不会盲目相信前任留下的描述。

Experience 和 Skill 则是更进一步的经验沉淀。Experience 记录一个情境、采取的动作、观察到的结果和可复用的教训，Skill 是一套经过审核的操作流程。这两者都要先进入 Review Inbox，审核通过后才会参与召回，模型只能「提议」，不能悄悄把自己的输出提升成规则。Skill 即使审核通过也不会自动安装，必须显式导出某个确切的 Revision，Agent 宿主才能发现它。

所有 Artifact 都按 FAMILY/ARTIFACT_ID@REVISION 寻址，ID 保持稳定，每次修订产生新的 Revision，读取某个确切引用时拿到的永远是当时的快照。召回时，PowerContext 会通过 PreparedContext 从活跃的 Memory 和已审核的 Experience 中挑选内容，再套用一个字节预算，返回 ready 或 empty，不会把所有历史一股脑倒给模型。

安装和启动

PowerContext 需要 Python 3.11 以上、Git 和 [[uv]]，支持 macOS 和 Linux，Windows 目前是实验性支持。1.3.0 版本开始提供了交互式配置向导，推荐的启动方式如下：

uv tool install --force "powercontext[cli,server]==1.3.0"
mkdir -p powercontext-config && cd powercontext-config
powercontext config init --language en --output .env
powercontext config validate --env-file .env
powercontext server run --env-file .env      # 保持这个终端开着

向导会询问存储后端、本地还是远程使用、记忆能力、Dashboard 和要接入的 Agent。存储第一次用直接选 SQLite 就好。记忆能力有两个选项：Basic memory 只支持显式保存和召回，不需要任何模型 API；Full memory 可以自动处理 Source、抽取 Topic Memory 并做语义检索，但需要单独配置生成模型和 Embedding 模型的 API 凭据。这里有个容易踩的坑：你的 Codex 或 Claude Code 订阅并不能当作 Server 的模型凭据，这两套是分开的。

向导会生成 .env 和 .env.next-steps.md 两个文件，里面可能包含凭据，千万不要提交到 Git 仓库。另开一个终端，加载环境变量并检查服务状态：

set -a
. ./.env
set +a
powercontext ready
powercontext capabilities

如果只是想快速体验，也可以不带任何配置直接运行 powercontext server run。此时服务监听 127.0.0.1:8000，在 /mcp 路径提供 Streamable HTTP 的 MCP 接口，自动创建默认 Scope，数据保存在系统用户数据目录下的 SQLite 文件中，可以通过 POWERCONTEXT_HOME 环境变量修改数据位置。Dashboard 默认关闭，在环境文件里设置 POWERCONTEXT_SERVER_DASHBOARD_ENABLED=true 后可以通过 http://127.0.0.1:8000/dashboard/home 查看记忆、Handoff 和版本历史。

接入 Agent

目前 [[Codex]] 的插件是官方维护的，[[Claude Code]]、DeepSeek Harness、Kimi Code、[[OpenCode]]、[[OpenClaw]]、Hermes Agent 等是社区维护，Python 框架方面支持 [[LangChain]]、[[LangGraph]] 和 Pydantic AI。官方特别强调，插件和 Server 要使用同一个版本，混用新旧版本可能导致召回静默失效。

接入 Codex：

powercontext setup codex --ref powercontext-v1.3.0
powercontext doctor codex

接入 Claude Code：

powercontext setup claude-code --ref powercontext-v1.3.0 --server-url "$POWERCONTEXT_CLAUDE_SERVER_URL"
powercontext doctor claude-code

--ref 不要省略，它的默认值是 master，会装上比 Server 新的插件。Codex 的 setup 也是同样的道理。

Claude Code 插件装好后，打开新会话，用 /hooks 确认 SessionStart 和 UserPromptSubmit 两个 Hook 已经生效，再用 /mcp 确认 powercontext 这个 MCP Server 已连接。这两条通路是分开的：Hook 负责在每次提交提示词时调用 POST /v1/context/prepare 召回上下文、同时把提示词作为 Source 证据保存；MCP 则提供显式的 Memory 读写和 Handoff 操作。两者都是 fail open 的设计，Server 挂了或者认证失败，Hook 只是不注入内容，不会阻塞 Claude Code 的正常工作。

使用场景：从 Claude Code 交接到 Codex

下面用一个具体场景把整个流程串起来。假设我在维护一个图床服务，打算给上传接口加上自动转 WebP 的功能。前半段在 Claude Code 里完成接口改造，后半段把补测试和写文档交给 Codex。

让两个 Agent 指向同一个 Scope

这是整个场景能成立的前提。按照 .env.next-steps.md 里给出的请求创建一个 Scope，记下返回的真实 scope_id。注意向导里规划的 codex-... 或 claude-code-... 这类名字只是标题，不是 ID。然后把 Claude Code 和 Codex 都绑定到这个 Scope。Claude Code 这边最简单的做法是在 .env 里写入 POWERCONTEXT_CLAUDE_SCOPE_ID，或者在项目目录下用插件自带的脚本把工作区绑定到这个 Scope：

python3 "${CLAUDE_PLUGIN_ROOT}/scripts/workspace_scope.py" \
  --cwd "$PWD" --bind-scope "SCOPE_ID"

Claude Code 解析 Scope 的优先级依次是：显式设置的 POWERCONTEXT_CLAUDE_SCOPE_ID、会话绑定、工作区绑定、Server 默认 Scope。如果你只是一个人在本机用，两个 Agent 都落到 Server 默认 Scope 也能共享，但我更建议按项目显式建 Scope，避免不同项目的记忆互相污染。

在 Claude Code 中沉淀决策

在 Claude Code 会话里讨论方案时，把那些「换个会话就会忘」的约束明确交代下来，并要求它保存为 Memory：

记住这个项目的几个决策：转换使用 sharp 库；原图保留，WebP 作为额外版本生成；
旧的 /api/v0/upload 接口不要改，移动端还在用。把这些保存到 PowerContext Memory。

Claude Code 插件自带的 powercontext-project-context Skill 会调用 remember_memory 把这些决策写成当前 Scope 里的活跃 Memory。之后无论是 Claude Code 的新会话还是 Codex，只要提示词相关，召回时都会带上它们，不需要我再重复一遍。比如 Codex 写文档时，自然就会注明旧的 /api/v0/upload 接口保持不变。如果开启了 Full memory，普通对话也会作为 Source 被后台处理成 Topic Memory，但我的习惯是关键约束还是显式保存，更可控。

在 Claude Code 中提交 Handoff

接口改造完成、准备换人的时候，在 Claude Code 中用一句明确的祈使句触发交接：

Hand off this work with PowerContext. Inspect the current objective, branch, worktree,
changed files, checks, blockers, omissions, and next action.
Commit the completed Handoff and give me its exact Revision.

Claude Code 会检查当前的实际状态，调用 handoff_current_work 生成 Prepared Handoff，并在同一轮里提交，最后返回 Scope 和确切的 Handoff Revision。这里要注意措辞：插件只把明确要求提交的请求当作持久里程碑，如果只说一句「交接当前工作」，生成的只是一个临时载体，不会写成可以跨 Agent 传递的 Revision。如果只想预览不写入，可以说「Preview a PowerContext Handoff and make no writes」。

在这个场景里，我会在交接前让 Claude Code 把「下一步」写得具体一些，比如「为 WebP 转换补单元测试，覆盖透明 PNG 和超大图片两种情况；更新 API 文档，说明新增的 WebP 字段」。Handoff 里的 next_action 越清楚，Codex 接手后越不用猜。

在 Codex 中接手

打开 Codex，在会话里让它主动接手刚才那个 Handoff，把 Claude Code 返回的 Revision 一起给它：

Continue this PowerContext Handoff. Check its evidence against the current repository
and instructions, confirm live state, capabilities, and authorization, then record
whether it is accepted, needs clarification, or is declined.

Codex 会调用 continue_handoff 读取交接内容，把它当作「不可信的历史」去和当前仓库状态核对，比如分支是否一致、改动文件是否还在、Claude Code 声称跑过的测试是否真的通过，然后调用 acknowledge_handoff 记录一个回执。只有证据可读、三项核查都确认后，才能标记为 accepted。这一步我觉得设计得很好，它避免了接手的 Agent 盲信前任的描述，在分支被别人动过的情况下也能及时发现问题。

如果哪天反过来，要把任务从 Codex 交回给 Claude Code，还可以在启动 Claude Code 之前把 Handoff 指定为启动上下文：

export POWERCONTEXT_CLAUDE_BOOTSTRAP_CONTEXT=true
export POWERCONTEXT_CLAUDE_BOOTSTRAP_HANDOFF='{"artifact_id":"HANDOFF_ID","revision":1}'
claude

开启 bootstrap 后，会话启动、恢复、clear、compact 时会注入最多 6 条打了 bootstrap-context 标签的 Memory 以及指定的 Handoff，默认预算 4096 字节，可以在 512 到 8192 字节之间调整。PowerContext 不会自动挑选 Handoff，必须显式指定，这是为了避免误接了别的任务。这组环境变量是 Claude Code 插件提供的，Codex 这边我还是用上面在会话里接手的方式。

记录任务结果

Codex 补完测试和文档之后，让它记录 Task Outcome：

Record the PowerContext Task Outcome. Keep the exact status and check results,
list produced Artifacts and remaining work, and link the accepted exact Handoff receipt.

record_task_outcome 会保存 succeeded、partial、blocked、failed 等状态和每一项检查结果，失败或跳过的测试会原样保留，不会被写成「全部通过」。这条记录本身也是 Source 证据，后续可以支撑新的 Handoff，也可以作为孵化 Experience 的素材。比如 Codex 在补测试时发现 sharp 在某个 Alpine 镜像里需要额外的依赖，就可以沉淀成一条 Experience，审核通过后下次任何 Agent 遇到类似场景都能召回。

整个过程下来，我没有复制过一次聊天记录，Codex 拿到的是一份经过核对的当前状态，而不是几千行对话历史。在 Dashboard 的 Handoff 页面还能看到完整的交接链条，并导出为 Markdown 归档。

用 Docker 部署到 Homelab

在笔记本上跑 powercontext server run 适合体验，但想长期使用就不太方便：笔记本合盖服务就停了，换一台电脑也连不上同一份上下文。我最后把 Server 部署到了家里 [[Proxmox VE]] 上的一台 Ubuntu 虚拟机里，用 [[Docker]] 运行，再通过 [[Cloudflare Tunnel]] 暴露成一个 HTTPS 域名，这样无论在哪台机器上开 Claude Code，连的都是同一个 Server。下文用 context.example.com 代指这个域名。

整体链路如下：

Claude Code / CLI ──HTTPS──> Cloudflare ──> cloudflared
                                               │
                                               └─> 127.0.0.1:18000 ──> 容器 :8000 ──> /data (SQLite)

从源码构建镜像

仓库的 docker/Dockerfile 是一个多阶段构建，基于 python:3.11-slim，以 UID 10001 的非 root 用户运行，数据放在 /data，并且自带一个请求 /health/ready 的健康检查。README 里说发布 Release 时会推送镜像到 Docker Hub，但我写这篇文章时还查不到可用的官方镜像，所以只能自己构建。我的做法是把官方仓库作为 git submodule 放在部署目录的 src/ 下，固定在发布 tag 对应的 commit：

mkdir -p ~/dockerfile/powercontext && cd ~/dockerfile/powercontext
git clone --depth 1 --branch powercontext-v1.4.1 https://github.com/oceanbase/powercontext.git src

如果部署目录本身就是一个 git 仓库，可以用 git submodule add 加进去，升级时只需要切换 tag 再提交新的 submodule 指针，版本记录一目了然。

官方只给了 docker run 的示例，我写了一个 [[Docker Compose]] 文件：

services:
  powercontext:
    build:
      context: ./src
      dockerfile: docker/Dockerfile
      args:
        POWERCONTEXT_VERSION: ${PC_VERSION:-1.4.1}
    image: powercontext-server:${PC_VERSION:-1.4.1}
    container_name: powercontext
    restart: unless-stopped
    ports:
      - "${BIND_HOST:-127.0.0.1}:${PC_PORT:-18000}:8000"
    env_file:
      - path: .env
        required: true
    volumes:
      # 镜像以 10001:10001 运行，目录需同 UID 所有
      - "${PC_DATA_PATH:-./data}:/data"

# 固定子网，让网关 IP 稳定为 172.31.0.1，后面的 FORWARDED_ALLOW_IPS 依赖它
networks:
  default:
    ipam:
      config:
        - subnet: 172.31.0.0/16
          gateway: 172.31.0.1

POWERCONTEXT_VERSION 这个构建参数不能省，Dockerfile 会校验安装出来的包版本是否与它一致。compose 自己用的变量我特意加了 PC_ 前缀，没有沿用 POWERCONTEXT_，免得和 Server 的配置项混在一起。端口只绑定在宿主机的回环地址上，外部访问全部走 Tunnel。我这台机器的 8000 端口已经被别的服务占了，所以换成了 18000。

配置鉴权

Server 要暴露到公网，必须开启鉴权。在部署目录下创建 .env，token 用 openssl rand -hex 32 生成，文件权限设为 600，并加进 .gitignore：

PC_VERSION=1.4.1
PC_PORT=18000
PC_DATA_PATH=~/powercontext-data

POWERCONTEXT_SERVER_ACCESS_MODE=enforced
POWERCONTEXT_SERVER_AUTH_TOKEN=<随机生成的 token>
POWERCONTEXT_SERVER_PUBLIC_URL=https://context.example.com
POWERCONTEXT_SERVER_DASHBOARD_ENABLED=true
POWERCONTEXT_SERVER_MCP_ENABLED=true

FORWARDED_ALLOW_IPS=172.31.0.1

最后一行的作用后面再解释。这里没有配置任何生成模型和 Embedding 模型，也就是 Basic memory 模式，启动日志里会出现一段 Inference capability notice，属于正常提示。

数据目录要先建好，并交给容器里的用户：

sudo mkdir -p ~/powercontext-data
sudo chown 10001:10001 ~/powercontext-data
docker compose up -d --build
curl -s http://127.0.0.1:18000/health/ready

返回的 status 是 ready，access_mode 是 enforced，就说明 Server 正常运行，并且鉴权已经生效。/health/live 和 /health/ready 不需要 token，方便做健康检查，其余的 API、MCP 和 Dashboard 不带 token 都会返回 401。所有持有 token 的人共享同一个管理员身份，没有多用户权限，个人使用够了。

通过 Cloudflare Tunnel 暴露

PowerContext 内置的只有 HTTP，没有 TLS 选项，HTTPS 需要在外面一层终结。我的虚拟机上已经有一个跑着其他服务的 cloudflared，只需要在 ingress 里加一条规则，放在最后的 404 兜底规则前面：

ingress:
  - hostname: context.example.com
    service: http://localhost:18000
  - service: http_status:404

改完先用 cloudflared tunnel ingress validate 校验，再用 cloudflared tunnel ingress rule https://context.example.com/ 确认请求会命中新规则，然后在 Cloudflare DNS 里给这个子域名加一条 CNAME，指向 <tunnel-id>.cfargotunnel.com 并开启代理，最后重启 cloudflared。注意重启会让同一个 Tunnel 上的其他服务中断几秒。

Dashboard 登录 403 的坑

部署好以后，我在浏览器打开 Dashboard，输入 token 后直接得到一个 403，换成故意输错的 token，结果也一样。翻了源码才发现，登录接口在校验 token 之前，会先检查浏览器发来的 Origin 和 Server 看到的请求 scheme 是否一致，不一致就直接拒绝。

问题出在链路中间：Cloudflare 到 cloudflared 这一段是 HTTPS，cloudflared 到容器这一段已经是 HTTP，真实协议只能靠 X-Forwarded-Proto: https 这个头传进去。容器里的 [[uvicorn]] 默认只信任来自 127.0.0.1 的转发头，而对容器来说，请求来自 Docker 网关 172.31.0.1，于是这个头被忽略，scheme 被当成了 http，和浏览器的 https 对不上。

解决方法就是前面 .env 里的 FORWARDED_ALLOW_IPS=172.31.0.1，让 uvicorn 信任 Docker 网关传来的转发头。网关 IP 取决于 compose 网络的子网，所以我在 compose 里把子网固定了下来，避免以后重建网络后 IP 变化，这个修复又悄悄失效。如果你用 [[Nginx]] 或 [[Caddy]] 做反向代理，也会遇到同样的问题，处理思路是一样的。

另外一个小细节是 /mcp 会 307 重定向到 /mcp/。插件生成的地址不带斜杠，问题不大；如果要在其他 MCP 客户端里手动配置，直接写 https://context.example.com/mcp/ 可以少一次跳转。

在 Claude Code 中连接远程 Server

客户端这边，先安装与 Server 相同版本的 CLI：

uv tool install --force "powercontext[cli,server]==1.4.1"

插件的 MCP 配置里，Authorization 头写的是 ${POWERCONTEXT_CLAUDE_AUTHORIZATION:-}，hook 也从同一组环境变量读取 Server 地址和 token。官方不建议把 token 写进插件配置、.mcp.json 或者 URL 里，所以我单独建了一个只有自己可读的文件：

mkdir -p ~/.config/powercontext && chmod 700 ~/.config/powercontext
umask 077
cat > ~/.config/powercontext/client.env <<'EOF'
POWERCONTEXT_CLIENT_SERVER_URL=https://context.example.com
POWERCONTEXT_CLIENT_API_TOKEN=<token>
POWERCONTEXT_CLAUDE_SERVER_URL=https://context.example.com
POWERCONTEXT_CLAUDE_AUTHORIZATION="Bearer <token>"
EOF

再在 ~/.zshrc 里加载它，保证启动 Claude Code 的 shell 里有这些变量：

[ -f ~/.config/powercontext/client.env ] && { set -a; . ~/.config/powercontext/client.env; set +a; }

powercontext ready 返回 Status: ready，就说明客户端和远程 Server 连通了。之后安装插件：

powercontext setup claude-code \
  --ref powercontext-v1.4.1 \
  --server-url https://context.example.com \
  --no-capture-prompts
powercontext doctor claude-code

--no-capture-prompts 的意思是不把每条提示词都存成 Source。在 Basic memory 模式下，Server 不会对这些 Source 做自动抽取，存下来也只是原始记录，所以我先关掉了，以后上了 Full memory 再打开也不迟。

如果想给某个项目单独建 Scope，又不想去找插件的安装目录，可以直接用 CLI 绑定。插件识别工作区的方式，是对 git 根目录的绝对路径取 sha256，按同样的算法算出来就能绑定：

powercontext scope create --title "my-project" --summary "图床服务"
cd ~/projects/my-project
WS=$(python3 -c 'import hashlib,os,pathlib,subprocess
r=subprocess.run(["git","rev-parse","--show-toplevel"],capture_output=True,text=True).stdout.strip() or os.getcwd()
print(hashlib.sha256(os.fsencode(pathlib.Path(r).resolve())).hexdigest())')
powercontext scope binding set "scp_xxx" --integration claude-code --kind workspace --external-id "$WS"

scp_xxx 换成 scope create 返回的真实 ID。

升级和备份

升级时切换 submodule 的 tag，修改 .env 里的 PC_VERSION，然后重新构建：

git -C src fetch --depth 1 origin tag powercontext-vX.Y.Z
git -C src checkout powercontext-vX.Y.Z
docker compose up -d --build

Server 升级之后，客户端的 CLI 和 Claude Code 插件要跟着升到同一个版本，否则召回可能静默失效。所有数据都在 ~/powercontext-data 这一个目录里，备份 SQLite 文件前先停掉容器，避免拷到写了一半的数据：

docker compose stop
sudo tar czf powercontext-data-$(date +%F).tar.gz -C ~ powercontext-data
docker compose start

也可以用 powercontext archive 导出可移植的逻辑备份。

使用建议

用了一段时间，有几点体会可以分享。第一是先从 Basic memory 开始，不配置任何模型，只用显式保存和 Handoff，就已经能解决跨 Agent 交接的大部分痛点，等确实需要自动抽取再上 Full memory。第二是不要把密钥、Token 等敏感信息写进 Memory、Work Contract 或 Handoff，这些内容会在召回时注入到其他 Agent 的上下文里。第三是服务部署在远程机器上时，务必启用 POWERCONTEXT_SERVER_ACCESS_MODE=enforced 和 Token 认证，并走 HTTPS，客户端默认只允许回环地址上的明文 HTTP。第四是升级时 Server、插件、客户端要一起升级，1.3.0 对已有数据库还需要做离线的 Atomic Memory 迁移，升级前记得备份数据库。

另外，powercontext doctor codex 和 doctor claude-code 只检查安装和连接状态，并不能证明记忆真的在工作。比较靠谱的验证方法是：在一个会话里说一个具体决策，确认它在 Dashboard 中作为 Source 出现，然后开一个新会话（最好换一个 Agent），问它刚才的决策是什么，看能否带引用地答出来。

和 Nowledge Mem 怎么搭配

如果已经在用 Nowledge Mem，还有必要再装一个 PowerContext 吗？我的看法是两者的职责重叠不多，不用二选一。Nowledge Mem 围绕的是「人」，沉淀的是偏好、服务器配置、过去做过的决定这类跨项目通用的东西，网页上和 AI 的对话也能通过浏览器扩展同步进去；PowerContext 围绕的是「项目」，用 Scope 隔离不同项目，用 Handoff 解决换会话、换 Agent 之后接着干的问题。召回方式也正好相反：PowerContext 在每条提示词提交前通过 Hook 自动注入上下文，不容易漏，但每次都多一次请求，注入的内容也不一定相关；Nowledge Mem 只在会话开始时注入一份简报，其余交给 Agent 自己判断什么时候去搜，省 Token，代价是 Agent 没想到要查的时候就会漏掉。关于 Nowledge Mem 的完整使用体验，可以看 Nowledge Mem 使用半年体验：让所有 AI Agent 共享同一份记忆。

所以我的做法是让 Nowledge Mem 继续做个人长期记忆，PowerContext 只在少数长期项目里绑定 Scope，用来做交接。同时开启要注意一点：两个插件都会在 Claude Code 的 Hook 里注入内容，上下文会变重，也可能出现重复。建议先在一个项目里小范围试，观察一段时间，看 PowerContext 召回的内容是否有用、和 Nowledge Mem 的简报重复了多少，再决定要不要扩大范围。

最后

PowerContext 解决的问题很朴素：工作很少由开始它的那个会话完成。它的价值不在于又多了一个记忆数据库，而在于把「决策、约束、当前状态、下一步」这些真正贵的上下文从对话里剥离出来，变成带版本、可审核、可追溯的 Artifact，并且通过 Scope 让不同的 Agent 共享同一份。Handoff 的四步闭环和 Experience、Skill 的审核机制，体现的是一种克制的设计：模型可以提议，但不能悄悄替你做决定。

对我这种在多个 Coding Agent 之间来回切换的人来说，这比在每个 Agent 里各维护一份记忆文件要省心得多。目前项目迭代很快，Windows 支持还是实验性的，部分 Agent 集成也是社区维护，生产环境使用前最好先跑一遍官方的 Jupyter 教程。

2026-10-19 13:00:00

最近整理我自己部署的服务，发现进入了一个比较难维护的状态，常常没有办法快速找到我想要访问的内容，家里有两台 PVE，上面运行着多个 VM，还有几台 VPS 上单独部署了 aaPanel，跑着网站，Appwrite，Chatwoot，Gitea，Umami, Nezha 等等服务，还有一个 Rancher 管理的 K8s 集群，上面也运行着十几个实际工作的网站，之前我都是在 Obsidian 中用一个笔记，记录着服务网址，部署在哪台机器，有没有备份，但是这个笔记越来越大，维护起来也越来越费劲，要查询某个服务的时候，手边没有 Obsidian 也非常不方便，虽然有一些地址记录在了 Chrome 里面，但是也常常域名，端口分不清，体验很差。

所以，我想起了 2021 年时我写过的一篇文章 又一个简单漂亮的静态个人导航站 Homer，当时觉得维护一个 YAML 生成的导航页就够用了。但是这次再梳理，我又搜索了一下，发现了一个比 Homer 更好用的个人导航站 Homepage。

Homepage 是什么

Homepage 是一个开源的自托管应用面板（application dashboard），基于 [[Next.js]] 编写，使用 GPL-3.0 协议。它最早是 Ben Phelps 的个人项目（仓库地址是 benphelps/homepage，我 2023 年的笔记里收藏的还是这个地址），后来迁移到了 gethomepage 组织下，由社区共同维护。截至目前，项目在 GitHub 上有大约 33200 个 Star。

它和 Homer 一样用 YAML 文件配置，但定位完全不一样。Homer 是纯静态的 HTML 和 JS，本质上是一个好看的书签页；Homepage 有自己的 Node.js 后端，可以替你去请求各个服务的 API，把 [[Proxmox VE]] 的 CPU 占用、[[Uptime Kuma]] 的在线状态、[[qBittorrent]] 的下载速度、[[Jellyfin]] 正在播放的内容直接显示在卡片上。官方说法是支持 100 多个服务集成，界面支持 40 多种语言，镜像同时提供 AMD64 和 ARM64 版本，树莓派上也能跑。

核心功能

服务卡片和服务组件

Homepage 的主体是 services.yaml 里定义的服务分组。每个服务至少有名字、图标和链接，可以再挂一个 widget 显示实时数据。比如下面这样，PVE 卡片会显示节点的 CPU 和内存，Uptime Kuma 卡片会显示在线和离线的监控项数量：

- 基础设施:
    - PVE:
        icon: proxmox.png
        href: https://192.168.2.100:8006
        description: ser8 主机
        widget:
          type: proxmox
          url: https://192.168.2.100:8006
          username: "{{HOMEPAGE_VAR_PVE_TOKEN_ID}}"
          password: "{{HOMEPAGE_VAR_PVE_TOKEN_SECRET}}"
    - Uptime Kuma:
        icon: uptime-kuma.png
        href: https://kuma.einverne.info
        widget:
          type: uptimekuma
          url: https://kuma.einverne.info
          slug: default

如果某个服务没有现成的 widget，也可以只加一个 siteMonitor 或 ping 字段，Homepage 会定期探测这个地址，在卡片右上角显示响应时间和在线状态。对我来说这一项就已经很有用了，几十个服务里哪个挂了一眼就能看到。

信息组件和书签

页面顶部可以放一排信息组件，在 widgets.yaml 里配置，包括搜索框、时间日期、天气、主机资源（CPU、内存、磁盘、网络）、Kubernetes 集群资源等。bookmarks.yaml 用来放不需要监控的普通链接，比如 GitHub、Cloudflare 后台这类外部网站。服务和书签分开放，页面看起来很清楚。

Docker 和 Kubernetes 自动发现

如果服务都跑在 [[Docker]] 里，可以不写 services.yaml，直接在容器上加 homepage. 开头的 label，Homepage 读取 Docker socket 后会自动把它加到对应分组里：

labels:
  - homepage.group=Media
  - homepage.name=Jellyfin
  - homepage.icon=jellyfin.png
  - homepage.href=https://jellyfin.example.com
  - homepage.description=媒体服务器

[[Kubernetes]] 的做法类似，在 Ingress 上加 gethomepage.dev/enabled: "true" 等注解，Homepage 会自动发现服务，除了标准 Ingress，还支持 [[Traefik]] 的 IngressRoute 和 Gateway API。这样服务的导航信息和部署配置写在一起，删掉一个服务，导航页上的卡片也会跟着消失，不会出现我那张 Markdown 表格那样越积越旧的问题。

API 代理和密钥保护

这是 Homepage 和 Homer 在架构上最关键的区别。Homepage 里所有对后端服务的 API 请求都由它自己的服务端代理，浏览器只拿到最终结果，API Key 和密码不会出现在前端。配置文件里的敏感信息还可以用 {{HOMEPAGE_VAR_XXX}} 引用环境变量，或者用 {{HOMEPAGE_FILE_XXX}} 从文件里读取，配合 Docker secrets 用，YAML 文件本身就可以放心提交到 Git 仓库。

部署

官方推荐用 Docker Compose 部署，最简单的配置如下：

services:
  homepage:
    image: ghcr.io/gethomepage/homepage:latest
    container_name: homepage
    ports:
      - 3000:3000
    volumes:
      - ./config:/app/config
      - /var/run/docker.sock:/var/run/docker.sock:ro # 可选，Docker 集成才需要
    environment:
      HOMEPAGE_ALLOWED_HOSTS: home.example.com
      HOMEPAGE_VAR_PVE_TOKEN_ID: root@pam!homepage
      HOMEPAGE_VAR_PVE_TOKEN_SECRET: xxxxxxxx
    restart: unless-stopped

第一次启动后，config 目录里会自动生成 services.yaml、widgets.yaml、bookmarks.yaml、settings.yaml、docker.yaml 等示例文件。修改服务和组件配置后刷新页面就能生效，不需要重启容器；settings.yaml 例外，改完要点一下页面右下角的刷新图标，让 Homepage 重新生成静态页面。

这里有个坑必须提一下：从 v1.0 开始，HOMEPAGE_ALLOWED_HOSTS 是必填项。除了 localhost:3000 和 127.0.0.1:3000，只要你用其他域名或 IP 访问，就必须把它加到这个列表里，多个值用逗号分隔且不能有空格，非 80 和 443 端口还要带上端口号。很多人升级后打开页面报错，原因就在这里。如果遇到 host validation 的报错，看一下容器日志，日志里会打印出实际收到的 Host，把它原样填进去就行。虽然可以设置成 * 关闭检查，但官方不推荐。

另一个要注意的是 Docker socket。直接把 /var/run/docker.sock 挂进容器等于把整台机器的 Docker 控制权交给它，哪怕加了 :ro 也一样。更稳妥的做法是在前面加一个 docker-socket-proxy，只开放查看容器的只读接口，Homepage 再通过 docker.yaml 连接这个代理。

安全和访问控制

Homepage 2.0 加入了一个可选的登录功能，可以用简单密码，也可以接 OIDC（比如 [[authentik]]、Keycloak、Pocket ID）。开启方式是设置 HOMEPAGE_AUTH_ENABLED=true，同时提供至少 32 位的 HOMEPAGE_AUTH_SECRET 和 HOMEPAGE_EXTERNAL_URL。只用密码登录的话再加一个 HOMEPAGE_AUTH_PASSWORD，配置了 HOMEPAGE_OIDC_ISSUER 等变量后则会改用 OIDC 登录。

不过这个登录只是一个「登录了还是没登录」的开关，官方文档也写得很明白，它不做密码尝试的频率限制，公网部署时仍然需要在反向代理层做认证、TLS 和限流。我的做法是干脆不暴露到公网：Homepage 跑在家里的服务器上，只通过 [[Tailscale]] 访问。导航页上有大量内网地址和服务信息，放到公网上实在没有必要冒这个风险。

和 Homer 的对比

Homer 也还在维护，GitHub 上有大约 11700 个 Star。它的定位没有变，README 里第一句话就是「A dead simple static HOMepage for your servER」。下面这张表是我把两者放在一起对比的结果：

最值得展开说的是数据获取方式。Homer 的 Smart Card 其实也支持不少服务，包括 Proxmox、Uptime Kuma、Gitea、Home Assistant、Nextcloud 等 50 多种，但因为它没有后端，所有请求都是浏览器直接发出去的。这带来两个问题。第一是 CORS，Homer 官方文档写得很直白，Smart Card 受跨域限制，要么把所有服务放在同一个域名下，要么去给每个服务加 CORS 头，要么额外部署一个代理，比如 Home Assistant 就需要把 Homer 的地址加进 cors_allowed_origins 才能用。第二是密钥泄露，Homer 的文档原话是 config.yml 会通过 /assets/config.yml 直接暴露出去，里面的 API Key 任何能访问这个页面的人都能看到。所以在 Homer 里用 Smart Card，前提是整个页面必须放在认证后面。

Homepage 走服务端代理，这两个问题都不存在了。代价就是多了一个常驻进程，也多了一个需要关注安全更新的组件。对于只想要一个漂亮书签页的人来说，Homer 仍然是更轻的选择，它的 release 包解压后用 python -m http.server 就能跑起来，扔到 [[Cloudflare Pages]] 这类静态托管上也完全没问题。

我的使用建议

如果你的服务只有十来个，并且不在意状态显示，Homer 足够了，配置文件一个人维护起来没有任何负担。如果服务多、分散在多台机器上，或者你希望打开页面就能看到服务健康状况，Homepage 明显更合适。

在服务分散在多台 VPS 上的场景下，我不推荐依赖 Docker label 自动发现。每台机器都需要暴露 Docker socket 给 Homepage，即使加上 socket proxy 也是额外的攻击面。我的做法是手写 services.yaml，放到 Git 仓库里管理，在 description 里写上服务部署在哪台机器、有没有备份，这样 Homepage 就同时承担了服务清单的角色，取代了我那张过时的 Markdown 表格。只有同一台机器上的容器我才用 label 自动发现。

状态监控方面，我没有给每个服务都配 siteMonitor，而是让 Uptime Kuma 统一负责探测和告警，Homepage 只挂一个 Uptime Kuma widget 显示总体状态，再给几个核心服务加上专属 widget。这样职责分得比较清楚：Uptime Kuma 管告警，Homepage 管导航和概览，不会两边重复探测。

图标方面，Homepage 可以直接使用 Dashboard Icons 图标库，icon 字段写 proxmox.png、jellyfin.png 这样的名字就行，也可以用 mdi-、si-、sh- 前缀分别引用 Material Design Icons、Simple Icons 和 selfh.st 图标。这比 Homer 时代自己下载 PNG 放进 assets 目录省事很多。需要注意的是这些图标是浏览器从远程 CDN 加载的，完全离线的内网环境要把图标下载下来挂载到 /app/public/icons，再用 /icons/xxx.png 引用。

最后

从 Homer 到 Homepage，变化的其实是我自己的需求。以前我只需要一个能把链接整理好的页面。到了 2026 年，我更需要的是一个能告诉我「现在一切正常吗」的地方。Homepage 的服务端代理、自动发现和丰富的 widget 正好补上了这一块。

Homepage 当然也不是终点。它不负责告警，也不会替你管理容器，这些交给 Uptime Kuma、[[Portainer]] 或者 Rancher 这样的专门工具更合适。把导航、监控和容器管理分开，每个工具只做好自己的那件事。