SLICC 浏览器原生智能体
在同一工作区中操作浏览器、终端、文件和已登录应用。
- Star 数
- ★ 32
- 最近更新
- 今天
- License
- Apache-2.0
- 主语言
- TypeScript
- FA 评分
- 77/100 · 表现良好
30 秒速览
- 可在哪里用
- 通用 · 跨平台Claude API
- 开始前需要
- 典型场景
- 经常在浏览器、终端和 Web 应用之间切换的开发者，用一个工作区运行代码、编辑文件并验证页面行为。
- 主要局限
- 项目明确处于活跃原型阶段，目标用户需接受功能偶尔损坏或不稳定。
- 源码审查
- 77/100 · 表现良好
这个 Agent 能做什么，适合哪些场景？
SLICC（Self-Licking Ice Cream Cone）是一款运行于浏览器内部、同时能控制浏览器的实用型智能体。它把虚拟文件系统、类 Unix shell、Playwright 浏览器自动化、实时界面和多智能体委派整合到一个工作区，可处理开发、网页操作及已登录应用中的任务。用户可以通过托管网页、macOS 应用、Node.js CLI、Chrome 扩展或无头 follower CLI 接入；同一核心还覆盖 Electron、iOS follower、GitHub Actions 和云端运行方式。主智能体称为 Cone，可把任务分给拥有独立沙箱、shell 和上下文的 Scoop，并汇总其结果。该项目目前被标记为活跃开发中的原型：macOS 应用是当前最方便的入口，Windows 与 Linux 尚无原生图形界面。
用户向 Cone 提交任务后，SLICC 可读取和修改工作区或已挂载文件，执行 bash、git、node、python、grep 和 playwright 等命令，并检查页面、控制标签页、截图及操作当前浏览器中已认证的应用。它能连接其他浏览器窗口，把 Electron 应用加入同一个 Tray，也能通过 @ai-ecoverse/cherry 将 follower 嵌入第三方页面。Cone 可创建隔离的 Scoop 并行执行子任务；结果、错误卡片、文件链接、图片以及可交互的临时界面会返回聊天工作区。mount --source 可把 S3、Cloudflare R2、MinIO、da.live 或 AEM Source Bus 内容挂入 VFS，serve --bridge 和 serve --ttl 30d 分别提供可驱动的实时预览和限期持久快照。会话压缩前会把完整记录保存到 /sessions，可选的 Memory v2 gelatiere 还会分析已归档会话并提出技能或工作流建议。
- 经常在浏览器、终端和 Web 应用之间切换的开发者，用一个工作区运行代码、编辑文件并验证页面行为。
- 需要重复操作已登录后台的运营人员，利用现有浏览器会话执行页面检查、截图和标签页自动化。
- 需要拆分大型任务的技术用户，让 Cone 将研究、修改或验证工作并行委派给隔离的 Scoop。
- 需要远程接入工作会话的用户，通过第二个浏览器、iPhone/iPad follower 或 Go
sliccCLI 查看并控制同一个 Tray。 - 维护 CI 工作流的团队，在 GitHub Actions runner 上启动 leader，挂载仓库、提交提示并取回生成文件。
- 需要统一访问本地与远程内容的用户，把主机目录、S3/R2/MinIO 或 Adobe 内容源挂载到同一个虚拟文件系统。
如何安装或部署这个 Agent？
最快的本地方式需要 Node.js 22 或更高版本以及 Google Chrome：运行 npx sliccy，然后在首次启动的设置窗口中配置 LLM 提供商。长期使用可执行 npm install -g sliccy，再运行 slicc。从源码开发可运行 git clone https://github.com/ai-ecoverse/slicc.git、cd slicc、npm install、npm run dev；开发服务器使用 Vite HMR，并在 http://localhost:5710 打开工作区。macOS 用户也可从项目 Releases 下载 .dmg。无头 follower 可通过 npx sliccy --install-cli 安装；原生 Windows 的安装脚本为 irm https://www.sliccy.ai/install-cli.ps1 | iex。
如何使用这个 Agent？
运行 npx sliccy 后，在首次设置中选择并配置支持的模型提供商，然后在打开的工作区聊天框中描述任务。智能体可直接使用 shell、文件和当前浏览器；需要主机目录时，应挂载到空路径，例如 npx slicc --mount=~/Projects/foo:/mnt/foo，卸载时运行 umount /mnt/foo。若要连接第二个浏览器，在头像菜单中选择“Enable multi-browser sync”，复制同步 URL，再在第二个浏览器的账户对话框中选择“Connect to another browser”。要将 Electron 应用加入工作流，可运行 npm run dev:electron -- /Applications/Slack.app。远程对象存储配置好服务器端凭据后，可使用类似 mount --source s3://my-bucket --profile r2 /mnt/r2 的命令挂载。
这个 Agent 有哪些优点和局限？
- 智能体循环、VFS、shell、界面和工具主要在浏览器端运行，并能直接操作承载自身的浏览器。
- 同一核心覆盖托管网页、CLI、Chrome 扩展、Electron、macOS/iOS follower、GitHub Actions 和云端场景。
- Cone/Scoop 架构提供带独立沙箱和上下文的并行委派，而不是把所有工作塞进单一对话。
- 具备实际文件与命令工具，并支持本地目录及 S3、R2、MinIO、da.live、AEM 等远程内容源。
- 秘密值不会直接暴露给智能体，而是按获准域名注入网络请求。
- 项目明确处于活跃原型阶段，目标用户需接受功能偶尔损坏或不稳定。
- 本地 CLI 要求 Node.js 22+ 和 Chrome；Windows 与 Linux 目前没有原生图形界面。
- 使用前必须自备并配置模型提供商额度或令牌，部分列出的提供商仅属于未经充分验证的 YMMV 范围。
- Chrome 扩展只是加载托管 leader 页面的薄 CDP 桥，并非完全独立、内置界面的扩展。
serve --bridge明确接受跨子域 Cookie 风险；带Domain=.sliccy.now的 Cookie 可被不同预览读取。
这个 Agent 与同类方案有什么区别？
项目将自身定位为 OpenClaw 的浏览器原生替代方向，并提到 NanoClaw 与 Pi 是重要灵感来源；Pi 被描述为每个 SLICC 实例的核心基础。相较这些项目，SLICC 强调智能体运行在浏览器中并控制同一个浏览器，同时把 shell、VFS、多浏览器 Tray、Electron 接入和多 Scoop 委派组合在统一工作区。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|
| SLICC 浏览器原生智能体 当前 | 77 · 表现良好 | ★ 32 | 今天 | TypeScript | Claude API |
| Rakazo AI 队友 | 63 · 存在缺口 | ★ 2.9k | 今天 | TypeScript | — |
| Octop 自托管 AI 助手 | 67 · 存在缺口 | ★ 4.8k | 今天 | Python | Codex · Claude Code · OpenAI API |
| Orbital 项目 Agent | 65 · 存在缺口 | ★ 290 | 4 天前 | Python | Codex · Claude Code · OpenAI API · Claude API |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
README、测试和工作流展示了能力开关、范围受限的文件系统、用户批准、显式挂载、预览撤销、同步链接重置以及最小化的 GitHub 权限；凭据被描述为服务器端保存且不交给代理，第三方 Actions 也固定到提交。扣分原因是产品仍可控制已认证浏览器、执行近似真实的 shell、自动重挂主机目录并发布持久预览；部分安全保证仅由文档陈述，未提供 secrets 文档或实现代码，且并非所有外部动作都有统一确认或回滚机制。来源由仓库、包元数据和 Apache 版权声明标示，但发布者身份未经企业注册验证，也没有更细的贡献者归属证据。
README、package.json 和测试共同呈现了较一致的产品形态、固定版本依赖、Node 要求、构建/检查脚本以及对不支持操作和并发冲突的明确错误处理。失败可持久显示，压缩失败会保留原会话，因此 failure_messages 证据充分。扣分在于未提供锁文件、CI 结果或依赖可用性证明，且 README 的“Node 22+”比 package.json 的 >=22.18.0 更宽泛；托管服务、模型提供商和多种平台组件也构成未静态验证的可用性依赖。
目标用户、浏览器/终端/认证应用/开发工作等场景说明非常具体，macOS、iOS、CLI、扩展、Electron、云端和无头环境的适配路径也很丰富。能力可通过 Cherry capabilities、features、挂载与显式 opt-in 控制，并有不支持方法测试。扣分是默认 Cherry 功能全部开启，代理触发和动作审批规则没有形成统一、可审计的策略；Windows/Linux UI 缺失、原型状态以及部分实验功能也限制了边界完整性。
README 具有清晰的信息层级、多个安装路径、大量任务示例和平台说明；LICENSE 是完整 Apache-2.0，包版本为 6.184.1，SECURITY.md 给出了私密报告渠道和支持范围。扣分是 SLICC、slicc、sliccy 以及 sliccy.com/sliccy.ai 并存，可能造成命名和入口混淆；未提供 changelog 或该修订的发布映射，已知限制虽有披露但没有集中清单，维护责任主要落到组织账户和“we”，缺少经验证的负责人或服务承诺。
文件预览、差异查看、会话恢复、浏览器控制、挂载、并行代理和可驱动预览等输出直接可操作，且相对于普通聊天代理提供了明显的跨浏览器、shell 和多运行时增量价值。扣分是整体架构、托管服务、模型调用和跨平台组件较复杂，README 未量化模型费用、资源消耗、延迟或操作风险，因此成本收益只能评为充分但不完整。
主要声明能对应到 README 的具体行为描述、package.json 的脚本与版本，以及 Cherry 测试中的能力拒绝、错误和特性协商；许可证和安全维护路径也由独立文件相互支持。扣分是大量产品能力只有 README 陈述，所给测试仅覆盖 Cherry 的有限表面，未提供实现、发布记录或独立材料来交叉印证多数安全与功能声明；营销性表述与事实说明虽通常可区分，但并未系统标注推断、保证和实验性状态。
- 这是低置信度的静态审查；未运行代码、测试、安装脚本、浏览器扩展或托管服务。
- 该代理可操作已登录的浏览器、执行 shell 并读写显式或自动挂载的目录；应使用最小权限的浏览器配置、专用账户和窄范围挂载。
- `curl | sh`、PowerShell `iex`、托管 leader、持久预览和跨浏览器同步扩大了供应链与数据暴露面；部署前应固定版本并单独审查安装器、域名边界和撤销行为。
- README 明示 `*.sliccy.now` 的跨子域 Domain cookie 风险；不要在该域范围放置可跨预览读取的敏感 Cookie。
- 凭据隔离、提示注入信任模型和域作用域主要依赖未随本材料提供的 docs/secrets.md 与实现，不能视为已验证。
常见问题
使用 SLICC 是否需要付费账户？
它会获得哪些本地权限？
支持 Windows 和 Linux 吗？
模型提供商失败或额度耗尽时会怎样？
凭据会暴露给智能体吗？
~/.slicc/secrets.env 或扩展的 chrome.storage.local 中。