虎鲸AI浏览器团队博客一：把 AI 做成统一入口：虎鲸浏览器的 Dify 与本地助手架构 在虎鲸浏览器中，AI 不是直接写死在客户端里的一个模型，而是一层统一的能力入口。用户在客户端聊天窗口输入问题，Electron 负责收集消息、保存会话，再把请求发送到后端 extension-service 的 /api/ai/chat。后端通过 entry 场景找到 Dify 应用密钥，再由 DifyClient 以 HTTP/1.1 调用 Dify 的流式接口。这样客户端不会接触密钥，未来更换 Dify、模型或中转站时，客户端界面基本不用修改。 Dify 工作流负责文案、生图等专业任务。如果回答包含 [[HUJING_LOCAL]]，后端就返回 handoff 事件，客户端再把任务交给本地 OpenCode 助手执行浏览器操作。云端负责理解和生成，本地负责实际操作，职责清楚，也方便后续扩展更多 AI 能力
当你需要在许多个独立环境里做同样的事——批量打开同一个页面、给一批账号填同样的表单、重复相同的浏览动作——逐个窗口手动操作既慢又容易出错。窗口同步正是为这种"动作一致的批量"而生：选中多个已经打开的环境，指定其中一个作为主控，其余作为跟随，你在主控里的操作会被同步到其他环境里去，省掉大量重复点击。这篇文章用概念的方式讲清楚什么是窗口同步、它适合哪些场景、主从机制该怎么理解，以及它和开放 API 自动化之间的分工，最后谈谈使用边界与几点需要注意的地方，帮你判断手上的任务到底该不该用它。
当需要管理的浏览器环境从几个涨到几十上百个，靠人工一个个新建、配置、开窗就不现实了，重复劳动既慢又容易出错。虎鲸提供带鉴权的本地开放 API，让你能用程序批量创建环境、批量启停、导入导出、按分组管理并查询运行状态，把过去的手工操作变成可复用的脚本。本文面向有一点技术基础的运营和开发，讲清楚开放 API 是什么、能做什么、一条典型的自动化流程怎么走，以及上手前需要准备什么、哪些合规与稳定性问题要提前想到，帮助你判断是否值得把重复工作交给自动化。
当一个团队运营的账号从几十个涨到成百上千个，靠人脑记、靠一个总账号一把密码共享的做法很快就会失控：谁在管哪些号、绑的手机邮箱是什么、昨天是谁登录操作的，全都说不清。这篇文章从协作视角拆解规模化账号管理的四个核心动作——信息集中归档、按项目和平台分组、给成员开子账号并按角色最小授权、让每一步操作可追溯，再说明指纹浏览器的团队能力如何把这套方法落到日常，最后给出合规与安全上的提醒。思路优先于工具，工具是让思路跑得稳的地基。
简体中文
English