《看得见的Agent：ego-browser浏览器技术内幕》

前言

2026年，AI Agent正在从“聊天工具”演变为“数字劳动力”。然而，当Agent试图真正完成一项网页任务——登录企业后台、填写表单、下载报表、检查提交结果——它面临一个根本性的困境：传统浏览器不是为Agent设计的，而Agent也无法真正“融入”人类已有的浏览环境。

ego-browser（ego-lite）的出现，正是对这一困境的系统性回应。它不是又一个Playwright封装，也不是又一个无头浏览器方案，而是一款从底层设计上同时服务人类用户与AI Agent的Chromium浏览器。在这个浏览器里，Agent在独立的Task Space中工作，复用用户已登录的Cookie和扩展，人类用户照常浏览自己的页面，双方互不干扰。

而dsh-ego-browser作为DeepSeek Harness生态中的插件实现，将这套能力封装为32个结构化ego_*工具，并配以实时观察窗——让Agent的每一次点击、每一次输入、每一次导航，都以“直播”的形式呈现在用户眼前。

本书将从三个维度展开：第一章讨论“为什么需要Agent浏览器”，第二章深入“它如何工作”，第三章展望“它将走向何方”。

第一章 为什么Agent需要一个自己的浏览器

1.1 一个被忽视的瓶颈：登录态

如果你曾经让AI Agent尝试完成任何一项真实的网页任务，你很可能经历过这样的场景：Agent兴冲冲地打开了一个浏览器窗口，导航到目标网站，然后——停在登录页面前。

这不是Agent不够聪明。问题在于，当Agent启动一个全新的无头浏览器时，它面对的是一个“数字裸体”的环境：没有Cookie，没有登录会话，没有浏览器扩展，没有历史记录，没有任何属于用户个人的上下文。

传统的解决方案有三种，但每一种都有明显的代价。

第一种方案是让Agent使用独立的无头Chromium。这种方案隔离性最好，适合CI环境下的自动化测试，但登录状态带不过去，用户需要为Agent单独提供一套凭证——很多网站甚至会因为“陌生设备登录”而触发额外的安全验证。

第二种方案是让Agent接管用户正在使用的Chrome标签页。这可以直接使用用户已经登录的状态，但Agent会抢占用户的标签、鼠标和焦点，你无法在Agent工作时同时使用浏览器做别的事情。更严重的是，当两个Agent同时工作，或者Agent在用户不知情的情况下点击了某个按钮，后果可能是不可逆的。

第三种方案是使用浏览器插件或MCP连接器。这是目前最常见的做法——Claude in Chrome、千问办公的浏览器插件、通过MCP接入Playwright的WorkBuddy，都属于这一类。它们的核心逻辑是“借用”用户的浏览器。但正如Anthropic在推出Claude内置浏览器时指出的，“很多网页任务并不需要‘你的浏览器’，Claude只需要‘一台浏览器’”。

问题的根源在于，这三种方案都在试图用“外部工具”的方式解决一个需要“原生集成”的问题。Agent需要的不只是一个可以操作网页的接口，而是一个和人类用户共享同一套上网环境、同时保持彼此独立工作空间的浏览器。

1.2 从“借用”到“共用”：ego-lite的设计起点

ego-lite团队在描述他们的设计初衷时写道：“今天的浏览器并不是为这种用法准备的。让Agent去操作网页，通常会同时碰上两个问题：它接不上你已经登录好的浏览器，做正事之前先卡在登录和验证码上；而它一旦跑起来，又会接管你的窗口和鼠标，你没办法同时用这台电脑做别的事。”

ego-lite的答案是一个全新的概念：Space（任务空间）。

Space不是一个新窗口，不是Chrome的多Profile，也不是Headless模式。它是浏览器内部隔离出来的一块工作区，拥有独立的标签页、独立的Agent覆盖层和独立的所有权规则，同时透明地继承用户的登录状态。每个Space属于一个Agent任务，Agent在自己的Space中运行，用户在自己的标签页中工作，双方互不抢占焦点。

这个设计的关键洞察在于：人类用户和AI Agent需要的其实是两种不同的“浏览器体验”。人类需要视觉化的界面、流畅的交互和完整的上下文；Agent需要的是结构化的页面信息、确定性的元素定位和高效率的执行通道。ego-lite的做法是让同一个Chromium实例同时提供这两种体验，而不是让它们互相妥协。

正如ego-lite的README所描述的：“ego lite is one browser designed from the start for the two of you to share.”

1.3 dsh-ego-browser：把浏览器能力变成Agent的工具

ego-lite本身是一个macOS桌面应用，但它的能力通过ego-browser命令行工具暴露给外部Agent。dsh-ego-browser则是DeepSeek Harness生态中的插件实现，由社区维护者Fisfzy开发，将ego-lite的浏览器能力接入DSH运行时。

dsh-ego-browser做了一件关键的事情：它把浏览器的原子操作抽象为32个结构化的ego_*工具，每个工具职责单一、可确定性调用。这些工具涵盖任务空间管理、页面读取、导航等待、交互操作、脚本执行、输出捕获、会话安全和元工具等类别。

但这不仅仅是一个“工具化”的过程。dsh-ego-browser还提供了一个实时观察窗——当Agent在后台操作网页时，用户可以在DSH的侧边栏或浮动面板中像看直播一样看到Agent正在浏览的每个页面，还可以直接接管操作。这个观察窗的存在，让“看得见的Agent浏览器”这个概念变得具体可感。

1.4 与传统自动化工具的根本差异

如果把ego-browser和Playwright放在一起比较，差异是根本性的。

Playwright是一个测试框架，它的设计目标是让开发者编写可维护的测试代码，覆盖CI环境下的跨浏览器回归测试。它的核心抽象是Locator、Page和BrowserContext，工作模型是“启动浏览器→执行脚本→关闭浏览器”。Playwright非常成熟，但它的假设是：浏览器是一个可以被启动和销毁的资源。

ego-browser的假设完全不同。它假设浏览器是一个持续运行的、被人类用户日常使用的环境。Agent不是“启动”浏览器，而是“进入”用户已经在使用的浏览器。这个假设的改变，导致了一系列设计上的连锁反应：

• 持久化上下文：Task Space、Tab和Page Label在多次Agent调用之间保持存在，而JavaScript变量不保持。Agent每次调用都是一个新的Node.js进程，但它可以继续之前的工作。

• 语义快照而非像素：Agent读取的不是页面的视觉渲染，而是一棵压缩的语义树，包含带有编号引用的可操作元素（如@21表示页面上的某个按钮）。这种方式比像素截图更高效，也更适合语言模型的理解方式。

• 代码驱动而非命令驱动：Agent不是一条命令执行一个动作，而是编写一段完整的JavaScript脚本，一次性执行多个步骤。这减少了模型与浏览器之间的往返次数，显著降低了Token消耗和执行时间。ego-lite团队报告称，复杂工作流的完成速度提高了20%到50%。

• 人机交接协议：当Agent遇到验证码、2FA或支付确认时，它可以调用handOff()将控制权交还给用户，用户完成后Agent继续执行。这是传统自动化工具几乎没有考虑过的场景。

1.5 “看得见”的价值

dsh-ego-browser的README标题是“看得见的Agent浏览器”。这个“看得见”不仅仅是一个功能特性，更是一种信任设计。

当一个Agent在浏览器中执行任务时，用户最自然的疑问是：“它在干什么？”如果Agent的操作是不可见的，用户只能通过最终结果来判断它是否正确。但如果Agent的操作是实时可见的——你能看到它打开哪个页面、点击哪个按钮、填写什么内容——那么信任的建立方式就完全不同了。

dsh-ego-browser的观察窗支持CDP和FFmpeg两种画面后端。CDP后端使用Page.startScreencast以JPEG格式推送画面，默认20FPS，适合大多数场景。FFmpeg后端则使用H.264视频流，画面更流畅，适合需要精细观察的场景。用户还可以在观察窗中直接点击、拖动、滚动，甚至进行键盘输入——观察窗不是只读的，而是双向的。

这种设计让“人机协同”从一个抽象概念变成了具体的交互体验。Agent不是一台黑箱机器，而是一个你可以随时看到、随时介入、随时接管的协作者。

1.6 生态位：为什么不是另一个Playwright封装

2026年，AI Agent浏览器领域已经有不少参与者。Vercel的agent-browser、browser-use、Chrome DevTools MCP、微软的Playwright MCP，各有各的定位。

dsh-ego-browser的独特之处在于它同时解决了三个层次的问题：

第一层是“能不能用”的问题。 ego-lite内置了完整的Chromium运行时，Linux + Chrome开箱即用，不需要用户克隆官方仓库或手动构建。

第二层是“好不好用”的问题。 32个ego_*工具提供了从导航到交互到调试的完整能力覆盖，语义快照和@N引用让Agent可以用最小的心智负担理解页面结构。

第三层是“敢不敢用”的问题。 实时观察窗、任务空间隔离、人机交接协议和登录态落盘机制（ego_auth_flush），共同构成了一个可控、可观察、可审计的操作环境。

这三个层次的问题，传统自动化工具通常只解决第一层。而dsh-ego-browser试图同时解决三层，这正是它作为一个DSH插件的独特价值。

在下一章中，我们将深入dsh-ego-browser的技术架构，看看32个工具背后的设计逻辑，以及实时观察窗是如何在浏览器和用户之间建立一条“看得见”的通道的。

第二章 看得见的技术：从工具层到画面流

2.1 架构全景：三层分离的设计

dsh-ego-browser的架构可以分解为三个清晰的层次。

最底层是ego-lite浏览器运行时。这是一个基于Chromium的桌面应用，负责承载真实的浏览器会话——包括标签页管理、Cookie存储、扩展加载和CDP（Chrome DevTools Protocol）通信。这个层面对Agent是不可见的，Agent永远不会直接与Chromium内核交互。

中间层是dsh-ego-browser插件本身，运行在DeepSeek Harness中。它扮演着“翻译器”的角色：把DSH的工具调用翻译成Node.js脚本，通过ctx.subprocess喂给ego-browser的CLI运行时执行，再把结果用@@DSH_RESULT@@哨兵行解析回来。32个ego_*工具就是这一层暴露给Agent的接口。

最上层是观察窗——一个嵌入DSH Web界面的实时画面面板。它通过SSE（Server-Sent Events）接收来自浏览器的画面帧，在用户面前呈现Agent正在操作的页面。

这个三层架构的核心设计原则是：Agent操作的是结构化的浏览器能力，用户看到的是实时的浏览器画面。两者共享同一个浏览器实例，但通过不同的通道获取信息。

2.2 32个工具的设计哲学

dsh-ego-browser的工具清单按照功能类别组织，每个类别都对应着Agent浏览器操作中的一个核心问题。

任务空间管理（ego_space_open、ego_space_close、ego_status）解决的是“在哪里工作”的问题。每个任务空间是一个隔离的浏览上下文，拥有独立的标签页和所有权规则。ego_space_open创建一个新的空间，ego_space_close关闭它，ego_status报告当前空间的状态。这个设计让Agent可以清晰地界定自己的工作范围，也方便用户在多个Agent任务之间进行管理。

页面读取（ego_snapshot、ego_page_info、ego_read_element）解决的是“看到了什么”的问题。ego_snapshot返回页面的语义树——一个压缩的结构化文本表示，包含页面上的文本内容、可交互元素及其引用编号。ego_page_info返回页面的元信息（URL、标题、加载状态），ego_read_element返回特定元素的详细信息。

导航与等待（ego_navigate、ego_wait、ego_wait_for_selector、ego_wait_for_url、ego_wait_for_response）解决的是“什么时候可以继续”的问题。ego_navigate打开或复用标签页并导航到目标URL。四个wait工具覆盖了不同的等待场景：等待固定时间、等待特定选择器出现、等待URL变化、等待网络响应。这些工具的粒度设计体现了Agent操作与人类操作的一个关键差异：Agent需要确定性的等待条件，而不是“等一会儿看看”。

交互（ego_click、ego_fill、ego_hover、ego_drag、ego_select、ego_check、ego_key、ego_scroll）是工具集的核心。每个工具都接受一个目标参数，可以是@N引用、CSS选择器、XPath或语义定位器。这种多模态的定位方式让Agent可以根据页面结构选择最合适的定位策略。特别值得注意的是ego_click和ego_hover支持一个可选的label参数（3-6个词的描述），这个label会显示在观察窗中Agent光标的旁边，让用户知道Agent正在做什么。

执行与调试（ego_js、ego_cdp、ego_cli、ego_script）提供的是“逃生舱”能力。当预定义的工具无法覆盖某个操作时，Agent可以使用ego_js在页面上下文中执行JavaScript，使用ego_cdp发送原始CDP命令，或使用ego_cli执行任意heredoc脚本。ego_script则用于多步脚本的编排。这些工具的存在确保了系统的可扩展性——如果今天32个工具不够用，Agent可以自己写代码来完成任务。

输出（ego_screenshot、ego_download、ego_upload）处理的是“获取和发送信息”的问题。ego_screenshot捕获页面截图，ego_download管理文件下载，ego_upload处理文件上传。

会话与安全（ego_auth_flush、ego_captcha、ego_dialog）是三个看起来不起眼但至关重要的工具。ego_auth_flush将当前登录状态持久化到磁盘，确保后续的Agent会话可以复用。ego_captcha处理验证码场景，ego_dialog管理JavaScript对话框（alert、confirm、prompt）——这是网页自动化中常见的“陷阱”，如果处理不当会导致Agent卡死。

元工具（ego_help、ego_doctor、ego_http）是系统的自省能力。ego_help返回所有可用工具的完整索引，ego_doctor诊断运行环境的状态，ego_http执行HTTP请求。

2.3 语义快照：Agent眼中的页面

如果说32个工具是dsh-ego-browser的“手”，那么语义快照就是它的“眼睛”。

当一个Agent需要理解一个页面时，它不会看到HTML源码，也不会看到像素渲染。它看到的是一棵压缩的语义树——ego_snapshot的输出。这棵树包含了页面上所有“有意义”的元素：文本内容、链接、按钮、输入框、下拉菜单、表格、列表等。每个可交互元素被赋予一个引用编号，如@21，Agent后续的操作就基于这些编号进行。

这种设计有几个关键优势。

首先是效率。一棵典型的语义树可能只有几KB的文本，而同一页面的截图可能有几百KB。当Agent需要反复观察页面状态时（这在多步操作中非常常见），语义快照的Token开销远低于视觉截图。

其次是确定性。语义树中的元素引用是稳定的——只要页面结构没有变化，@21就始终指向同一个按钮。这比基于坐标的点击方式可靠得多，也比基于CSS选择器的定位方式更容易被语言模型理解和使用。

再次是信息密度。语义树不是简单地罗列DOM节点，而是经过筛选和压缩的。它去掉了纯装饰性的元素（如div、span等无语义的容器），保留了Agent真正需要操作的目标。这种“有损压缩”恰恰是Agent需要的——它不需要知道页面的完整实现细节，只需要知道有哪些可交互的组件以及如何操作它们。

在实现层面，快照的生成依赖ego-lite的自定义Chromium构建。ego-lite团队选择修改Chromium内核，而不是在JavaScript层面做页面解析，这使得快照的获取速度和质量都优于基于DOM遍历的方案。ego-browser的runtime在接收快照后，会将其中的ref同步到refMap中，后续的click('@21')等操作会通过这个映射关系找到真实的DOM节点。

2.4 实时观察窗：画面如何到达用户

观察窗是dsh-ego-browser“看得见”这一特性的技术载体。它的实现涉及一个从浏览器捕获画面、经过编码传输、最终在用户界面渲染的完整流水线。

画面捕获有两种后端实现。

CDP后端使用Chrome DevTools Protocol的Page.startScreencast方法。这是Chromium原生提供的屏幕捕获接口，它以JPEG格式输出画面帧，默认帧率为20FPS。每个源帧在到达后立即通过Chrome提供的帧ID进行ACK确认，系统只保留最新的待发送帧。当页面处于静态状态时，截图频率自动降低到每3秒一次，以节省带宽和计算资源。CDP后端的优势是零配置、跨平台兼容性好，劣势是帧率较低、画面质量受JPEG压缩影响。

FFmpeg后端使用操作系统的原生屏幕捕获能力。在Windows上，它通过gfxcapture(hwnd)直接采集目标Chrome窗口的D3D11 surface；在其他平台上，它使用显示来源的裁剪区域。捕获到的画面经过H.264编码，封装为fragmented MP4格式，通过HTTP二进制chunk传输到前端，最终由MediaSource的<video>元素播放。FFmpeg后端的画面更流畅、质量更高，但需要额外的依赖安装和平台适配。Windows上的FFmpeg必须包含gfxcapture功能，macOS首次使用需要“屏幕录制”权限，X11需要Chromium和FFmpeg共享DISPLAY环境，Wayland则在缺少Portal/PipeWire输入时会提示切回CDP。

系统默认使用CDP后端，不主动检测FFmpeg是否可用，也不自动下载。FFmpeg安装到~/.dsh/cache/ego-browser/ffmpeg/目录下，不会写入插件目录，确保插件本身的轻量化。

观察窗本身不仅仅是画面的展示。它包含一个完整的小型浏览器界面：主画面区域显示Agent当前页面的实况，用户可以直接在画面上点击、拖动、滚动，甚至进行键盘输入（支持中文IME、粘贴、Tab/Enter/方向键和Ctrl/Cmd快捷键）。顶部的标签页条让用户可以切换Agent打开的多个页面，历史抽屉可以按时间回看Agent的访问轨迹。

当Agent执行一个操作时（如点击一个按钮），观察窗中会显示一个Agent光标，光标旁边显示操作描述（即工具调用中的label参数）。这让用户不仅能“看到”Agent在做什么，还能“理解”Agent为什么这么做。

2.5 任务空间隔离：并行Agent的基石

Task Space是ego-browser最核心的架构概念之一。理解它，就理解了为什么Agent浏览器不能简单地等同于“一个能被脚本控制的Chrome”。

在传统的浏览器自动化中，如果你需要同时运行多个自动化任务，通常的选择是启动多个浏览器实例，或者使用多个BrowserContext。这两种方式都有代价：前者消耗大量内存，后者虽然共享进程但仍存在Cookie和存储的隔离问题。

ego-browser的Task Space采用了不同的方法。它是一个在同一个Chromium进程内隔离出来的浏览上下文，拥有独立的标签页集合、独立的Agent覆盖层和独立的所有权状态。每个Space的标签页不会出现在用户的主浏览器窗口中，用户可以在自己的标签页中正常工作，Agent在自己的Space中并行执行任务。

Space的所有权模型有三个状态：agent、agentDelegatedToUser和user。当Agent创建并控制一个Space时，所有权为agent。当Agent遇到需要用户介入的场景（如验证码），它调用handOff()将所有权临时转移给用户，状态变为agentDelegatedToUser。用户完成操作后，所有权交回Agent。这种显式的所有权模型确保了在任何时刻，只有一方对Space拥有控制权，避免了“人机争抢”的问题。

Space的生命周期由Agent控制。ego_space_open创建，ego_space_close关闭。但Space中的数据（标签页、页面状态）在多次Agent调用之间是持久的——每次Agent调用启动一个新的Node.js进程，但Space作为浏览器端的实体继续存在。这意味着Agent可以分多轮完成一个复杂任务，每轮处理一部分，而不需要一次性完成所有操作。

2.6 从工具调用到浏览器操作：一条完整的执行链路

理解dsh-ego-browser最有效的方式，是跟踪一次完整的工具调用从DSH到浏览器的全过程。

假设Agent决定点击页面上的一个按钮。它选择了ego_click工具，传入参数{ref: '@21', label: '确认提交'}。

第一步，DSH的tool runtime接收这个调用，dsh-ego-browser将参数拼装成一段JavaScript代码：

await click('@21', { label: '确认提交' });  

第二步，这段代码通过ctx.subprocess.spawn以ego-browser nodejs的形式执行，代码被喂给stdin。ego-browser的runMain()函数读取stdin，将代码包装在一个异步函数中执行。

第三步，在异步函数内部，click()是一个预加载的helper。它通过src/element-resolver.ts解析'@21'引用——首先在refMap中查找对应的元素信息，然后通过CDP发送点击命令。

第四步，CDP命令经过ego.sendCDPMessage发送到ego-lite浏览器。浏览器的CDP transport层接收命令，在正确的标签页和帧上下文中执行点击操作。

第五步，操作结果通过@@DSH_RESULT@@哨兵行返回给DSH的tool runtime，Agent收到“点击成功”的确认。

整个过程在几十到几百毫秒内完成。观察窗中的画面会同步更新，显示Agent光标在对应位置闪烁，旁边显示“确认提交”的文字。用户看到的不只是结果，还有过程本身。

这就是“看得见”的技术含义：不是事后回放，不是日志审计，而是实时的、可视化的、可介入的执行过程。在下一章中，我们将讨论这种设计对未来Agent浏览器发展的启示。

第三章 看得见的未来：Agent浏览器的进化方向

3.1 从“工具”到“环境”：Agent与浏览器关系的重构

2026年，AI Agent浏览器领域正在经历一场静默的范式转换。

过去两年，主流思路是将浏览器视为Agent的“工具”——Agent需要访问网页时，启动一个浏览器实例，执行操作，然后关闭它。Playwright和Puppeteer是这一思路的典型代表，它们提供了强大的浏览器控制能力，但假设浏览器是一个短暂存在的资源。

ego-lite和dsh-ego-browser代表了一种不同的思路：浏览器是Agent的“环境”，而不是“工具”。Agent不是在浏览器之外操作浏览器，而是在浏览器之内与人类用户共存。这种环境视角带来了几个根本性的变化。

变化之一是持久性。在工具视角下，每次Agent会话都是独立的；在环境视角下，Agent的任务空间、标签页和登录状态在多次会话之间持续存在。这意味着Agent可以积累上下文，用户也可以观察Agent的工作历史。

变化之二是共存性。在工具视角下，同一时刻通常只有一个“用户”（要么是人，要么是Agent）在使用浏览器；在环境视角下，人和Agent同时存在，各自在独立的空间中工作。这要求浏览器在架构层面支持多用户（multi-actor）的隔离和协调。

变化之三是可观察性。在工具视角下，Agent的操作是一个黑箱——你给它一个任务，它返回结果；在环境视角下，Agent的操作是白箱——你可以实时看到它在做什么，可以随时介入，可以理解它的决策过程。

这种从“工具”到“环境”的转变，正在推动浏览器架构本身的进化。

3.2 代码驱动Agent：为什么写脚本比点按钮更高效

ego-browser的一个核心设计决策是：Agent通过编写JavaScript代码来操作浏览器，而不是通过逐条命令调用。

这个决策背后有一个重要的观察：当前的LLM在编写代码方面的能力，远强于在“一步一步执行操作”方面的能力。当一个Agent需要完成一个多步任务时，如果每一步都需要调用一个独立的工具、等待结果、再决定下一步，那么模型需要维护一个庞大的上下文，并且容易在长链条中“迷失方向”。

但如果让Agent一次性编写一个完整的脚本来完成整个任务，情况就不同了。模型可以利用它最强的能力——代码生成——来规划整个操作流程。脚本中的每一步都是确定的，不需要模型在每一步之后重新决策。ego-lite团队报告称，这种方法让复杂工作流的完成速度提高了20%到50%，任务成功率更高，每个任务的工具调用次数也大大减少。

Vercel的agent-browser在这一方向上做了进一步的探索。它使用Rust构建，在基准测试中比Playwright MCP减少了约80%的Token消耗，页面表示大小也大幅缩小。ego-browser与这些方案共享同一个核心洞察：Agent需要的是代码级的浏览器接口，而不是命令级的接口。

dsh-ego-browser的32个工具并非简单的“命令封装”，而是“代码片段的生成器”。每个工具调用最终都会变成一段JavaScript代码，在Node.js运行时中执行。ego_cli和ego_script工具进一步强化了这种代码驱动的范式——Agent可以直接编写heredoc脚本，利用预加载的helper完成复杂的操作序列。

3.3 人机协同的演进：从“接管”到“共在”

dsh-ego-browser的handOff()和takeOver()机制代表了一种新型的人机关系：不是人类“授权”Agent工作，也不是Agent“替代”人类工作，而是人类和Agent在同一个环境中“共在”。

这种“共在”模式有三个层次。

第一个层次是可见。用户可以看到Agent在做什么。观察窗的存在让Agent的操作变得透明。这不是事后审计，而是实时监督。用户不需要信任Agent的每一个决策，但可以随时看到它的决策过程。

第二个层次是可介入。用户可以在任何时候接管Agent的操作。观察窗不仅是一个显示器，也是一个输入设备。用户可以在画面上直接点击、输入、拖动，这些操作会被浏览器视为来自Agent空间的控制指令。

第三个层次是可协作。Agent可以在遇到困难时主动请求用户的帮助。handOff()机制让Agent可以把控制权交还给用户，用户完成操作（如输入验证码、确认支付）后，Agent继续执行。这种“请求-响应”式的协作，比“Agent全自动执行”或“人类全手动操作”都更加自然。

dsh-browser-plus项目在这一方向上做了更进一步的探索。它基于dsh-browser构建，提供了EGO风格的可视化Agent浏览器，支持人机协同操作：用户可以在真实页面中操作，Agent也在同一环境中工作。这种“同页面协作”的模式，可能成为未来Agent浏览器的一种重要形态。

3.4 生态化：从单体插件到平台能力

dsh-ego-browser目前是一个独立的DSH插件，但它所代表的“Agent浏览器能力”正在被多个项目以不同方式复用和扩展。

ego-lite-bridge项目将ego-browser的CLI运行时桥接到Windows上的标准Chrome浏览器，通过CDP实现兼容。这意味着ego-browser的32个工具所定义的接口，可以在不安装ego-lite桌面应用的情况下使用。

dsh-browser-plus则构建了一个更完整的DSH浏览器插件，提供可见的AI驱动WebContentsView、操作轨迹记录、JS对话框自动接受、按任务窗口和空间等功能。

这些项目之间的关系不是竞争，而是互补。它们共同定义了一个“Agent浏览器接口层”的标准——包括任务空间的概念、语义快照的格式、工具调用的协议、观察窗的交互模式。当一个Agent学会了使用ego-browser的工具，它实际上学会了一种通用的浏览器操作范式。

这种生态化趋势对Agent浏览器的未来有深远影响。如果32个ego_*工具所代表的接口成为一种事实标准，那么未来的Agent浏览器可能不需要各自定义一套工具——它们可以共享同一套接口，只是在实现层面有所差异。这类似于Web标准的发展路径：HTML和HTTP不是由某一个公司定义的，而是通过多个实现的竞争和协作形成的。

3.5 安全与信任：Agent浏览器的核心挑战

让Agent操作浏览器，本质上是在给一个自动化程序赋予“你的数字身份”。Agent可以访问你登录的网站，可以查看你的邮件和文档，可以执行你的操作。这种能力的边界在哪里？

dsh-ego-browser在安全方面的设计值得关注。

首先是登录态落盘（ego_auth_flush）。Agent可以在完成登录后，将登录状态持久化到磁盘。这意味着后续的Agent会话不需要重新登录。但这也意味着，如果有人获得了这些持久化的凭证，就可以访问用户的账户。dsh-ego-browser通过将凭证存储在Agent工作空间的隔离目录中来降低风险，但根本的安全边界取决于操作系统的权限模型。

其次是任务空间隔离。每个Agent任务在自己的Space中运行，Space之间的标签页和存储是隔离的。一个Agent无法直接访问另一个Agent的Space，除非通过显式的所有权转移。这种隔离减少了Agent之间的意外干扰，也限制了单个Agent的安全影响范围。

再次是可观察性作为安全机制。实时观察窗不仅是用户体验特性，也是一种安全机制。当用户可以看到Agent的每一个操作时，恶意或错误的行为可以被及时发现和中断。

然而，这些措施并不能解决所有安全问题。正如一篇对ego-lite的研究所指出的：“Agent一旦拿到登录状态、Node.js与raw CDP，权限不只是‘可以读网页’，而是接近已登录使用者加上本机shell的组合。”这是一个结构性的挑战，需要从操作系统层面、浏览器层面和Agent运行时层面共同应对。

3.6 未来图景：Agent浏览器的三种可能形态

站在2026年的节点上，Agent浏览器可能会沿着三条路径继续进化。

路径一：浏览器即Agent平台。 ego-lite代表的模式是浏览器本身成为一个Agent运行平台，Agent的能力被深度集成到浏览器中。用户安装一个浏览器，就同时获得了人类的浏览体验和Agent的自动化能力。这条路线的优势是集成度高、体验一致，挑战是需要维护一个完整的Chromium分支，以及一个Agent运行时。

路径二：协议标准化的Agent浏览器层。 另一条路径是将Agent浏览器的核心能力（任务空间、语义快照、工具接口）标准化为协议，不同的浏览器和Agent运行时可以实现这个协议。ego-lite-bridge对Chrome的桥接、dsh-browser-plus对Electron的集成，都暗示了这种可能性。这条路线的优势是生态开放，挑战是协议的制定和推广需要时间和共识。

路径三：Agent原生浏览器。 更激进的路径是构建一个从底层就为Agent设计的浏览器，而不是在Chromium之上做修改。这意味着重新思考浏览器的核心抽象——标签页、Cookie、DOM——在Agent场景下是否还适用。这条路线的挑战最大，但可能性也最大。

无论哪条路径成为主流，“看得见”这个特性都会持续存在。当Agent的能力越来越强，用户对“可观察性”和“可介入性”的需求只会增加，不会减少。一个不可见的、无法中断的、用户无法理解其决策过程的Agent浏览器，无论技术多先进，都难以获得用户的信任。

3.7 结语：浏览器作为人机协作的第一个界面

Web浏览器诞生于1990年代，它的设计假设是：一个人类用户，坐在一台电脑前，通过鼠标和键盘与网页交互。

三十年后，这个假设正在被打破。越来越多的网页操作不再由人类直接完成，而是由AI Agent代为执行。这不是对浏览器的替代，而是对浏览器的扩展——浏览器从一个“人类工具”变成了一个“人机共用环境”。

ego-lite和dsh-ego-browser是这个转变的早期探索者。它们面临的问题——登录态共享、任务隔离、实时观察、人机交接——将是未来所有Agent浏览器必须回答的问题。它们的设计决策——Space、语义快照、代码驱动、观察窗——可能不是最终答案，但它们指出了一个方向：Agent浏览器不应该是Agent的“遥控器”，而应该是人和Agent共同工作的“房间”。

在这个房间里，Agent有自己的工作台，用户有自己的视角，双方可以随时看到对方在做什么，随时交换控制权。这不是科幻，这是ego-browser已经在做的事情。

浏览器是人类进入数字世界的第一个界面。Agent浏览器可能是人类与AI协作的第一个界面。它的设计将决定我们如何信任、如何监督、如何与那些越来越自主的数字实体共存。

这个问题的答案，不在代码里，而在我们对“看得见”的坚持里。