ego-lite双启动路径详解同一份代码如何既当CLI又当SDK【免费下载链接】ego-liteThe fastest browser for AI agents to run browser automation, built for sharing your logged-in browser state with your AI agents, like Codex or Claude Code, without disturbing you. Zero cost, zero config.项目地址: https://gitcode.com/GitHub_Trending/eg/ego-liteego-liteego lite是一款专为 AI 智能体打造的浏览器让你把已有的登录态安全地分享给 Codex、Claude Code 等助手而它自己继续在你的标签页上工作。真正承载浏览器自动化能力的是其中的ego-browser助手运行时——它只有一个入口文件却能同时扮演两种身份既能在终端里当命令行工具CLI又能作为 SDK 被 AI 浏览器直接调用。本文带你拆解这份一份代码、两条启动路径的设计看看它是怎么做到零配置又不互相打架的。项目速览ego-browser 是助手运行时ego-browser并不是一个独立的浏览器而是跑在 ego-lite基于 Chromium内部的Node.js 助手层。浏览器原生暴露一个ego运行时标签页、CDP 通道、页面快照、任务空间而这个包把面向智能体的助手函数打包好、挂上去。整体链路很短ego-browser (Chromium) → globalThis.ego → Playwright 风格 facade → 智能体 heredoc也就是说智能体最终调用的是page、browser、taskSpaces、site、fetch这一组Playwright 风格的 facade背后统一收敛到 CDP。理解了这个前提再看双启动路径就很清晰了两种身份只是谁来执行这组 facade的不同。分岔口isDirectCli()一个判断决定身份真正的分岔只有一处。入口文件 index.ts 以#!/usr/bin/env node开头并在 package.json 里被声明为可执行命令ego-browser。文件末尾只用一个布尔判断决定走哪条路isDirectCli()为真→ 走 CLI 路径执行await runMain()否则→ 走 SDK 路径执行installEgoSdk()。关键在于 isDirectCli() 的实现它比较当前进程入口pathToFileURL(process.argv[1]).href是否等于本模块自身的import.meta.url。被node dist/out/index.js或ego-browser直接拉起时两者相等判为 CLI被浏览器运行时import进来时入口不是本文件判为 SDK。一个判断干净利落地把同一份代码劈成两种用法。CLI 路径读 stdin跑一段 heredoc命令形如ego-browser JS ... JS把脚本从标准输入喂进来。整条路径由 runMain() 驱动做了四件事解析参数--help、--doctor、--reload、--debug-clicks读取 stdinreadAll()把整段 heredoc 读成一个字符串执行execute() 通过 executionContext() 取出全部 helperObject.assign(globalThis, context)注入全局再用AsyncFunction动态构造并await执行收口输出调用flushSink()决定是原样吐出还是在硬停时丢弃。对使用者来说这就是贴一段 JS、拿回结果无需关心连接准备——浏览器连接是自动备好的。SDK 路径把 helper 挂到globalThis上当被浏览器import时走的是 installEgoSdk()。它和 CLI 的差别本质是谁拥有执行环境注入目标可指定默认target globalThis用Object.defineProperty把每个 helper 挂成不可枚举属性避免污染命名空间等待就绪信号异步 helper 被wrapReady()包一层调用前先await readySignal保证浏览器连接就绪后才真正执行接管输出把console.log换成缓冲写并在 installLifecycleFlush() 注册beforeExit / exit在进程退出时统一冲刷暴露运行时把ego.helpers、ego.learnings挂好并对createTab、useTaskSpace等会改变会话的方法做包装wrapCreateTab/wrapInvalidating在关键操作后失效会话缓存。一句话CLI 是我拉起进程跑你的脚本SDK 是你把我 import 进去我把自己装好再交给宿主跑。为何两条路径不会漂移helperContext()是唯一事实来源最容易出 bug 的地方是两条路径各自维护一份 helper 清单、逐渐长岔。ego-browser 用了一个很聪明的约定——同一个来源喂两头executionContext()CLI与 installEgoSdk()SDK都调用同一个 helperContext()该函数统一产出page / browser / taskSpaces / site / fetch / cdp / help这组 facade外加一个help额外从 loadAgentHelpers() 动态加载智能体工作区里的自定义 helper。源码注释也直接点明这是单一事实来源让 CLI 与 SDK 两条路径不可能漂移help也同时存在于两边。想扩展能力只改helperContext()一处即可。输出收口缓冲输出 硬停折叠console.log是智能体唯一读取的通道。output-sink.ts 的设计就是让这个通道在两种路径下都只说有用的话先缓冲、后落盘bufferOutput()不直接写先攒着。因为已经写出去的字节收不回来只有确认本次没有硬停才能安全冲刷硬停折叠用户接管页面时每条浏览器命令都会重复报同一个硬停错误。markHardStop()只记录第一条flushSink() 在结束时丢弃整段缓冲、只输出这一条归属信息避免智能体被同一句提示刷屏升级提示殿后可选的可更新提示以 trailer 形式追加在最后读起来像脚注而非干扰。CLI 路径在脚本跑完后flushSink(stdout, ...)SDK 路径因为宿主不会调用execute()包装就靠installLifecycleFlush()在进程退出时冲刷。同一套收口逻辑两种触发时机。架构红利代码即接口更快更省把能力包装成智能体直接调用的 JS 函数而非调一条命令、看结果、再调一条正是 ego-lite 的核心卖点。官方基准测试显示在四个真实网页任务上ego-browser比同类工具更快且更省 token任务越复杂差距越大——复杂工作流最高快2.5×token 成本大幅降低。这也解释了为什么入口只做分发而把真正的执行细节交给helpers.ts里的 facade智能体擅长写代码那就让它把多步任务一次性写成一段 JS而不是困在反复试错的循环里。关键文件清单去读源码想深入这条链路按这个顺序读最高效入口与分岔index.ts、isDirectCli()、installEgoSdk()CLI 执行runMain()、execute()、executionContext()助手定义helperContext()、loadAgentHelpers()输出收口output-sink.ts浏览器桥接browser-runtime.ts架构说明README.md小结ego-lite 的ego-browser用一个入口文件、一个isDirectCli()判断把同一份代码劈成了两条井水不犯河水的启动路径CLI 负责拉起进程跑 heredocSDK 负责被 import 后自我装配。而两条路径之所以能长期一致是因为它们共用唯一的helperContext()再靠一套先缓冲、后收口的输出逻辑保证智能体只看到干净结果。这种代码即接口的设计既省去了额外配置也为更快的执行和更低的 token 成本打下了基础。【免费下载链接】ego-liteThe fastest browser for AI agents to run browser automation, built for sharing your logged-in browser state with your AI agents, like Codex or Claude Code, without disturbing you. Zero cost, zero config.项目地址: https://gitcode.com/GitHub_Trending/eg/ego-lite创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考