AgentLimb · 02 · 架构：本地 bridge 如何连接 AI 工具和浏览器

AgentLimb 的架构重点不是“让插件能点网页”，而是让 AI 工具、本地服务、Chrome 扩展和用户会话之间有清楚的边界。

本地 bridge 负责接收工具调用、转发浏览器动作、返回可理解的页面状态。这样会话留在本机，AI 工具只拿到完成任务所需的结构化信息。

开发细节补充：这篇记录放在 AgentLimb 的产品日记里，不是为了把一个功能包装成故事，而是把“02 · 架构：本地 bridge 如何连接 AI 工具和浏览器”放回真实项目推进中看。它要同时回答三件事：用户为什么需要这个点，开发时哪些边界必须先定住，以及这个选择会怎样影响上架、推广和后续课程复盘。平台口径是 Chrome / Edge / Brave / Vivaldi 等 Chromium 浏览器 / 标准 MCP / Windows + macOS + Linux / 本地回环，当前公开状态是 Chrome 官方商店 / 开源好物 / 离线直链，所以文案不能脱离真实发布进度。

对应的 docs 线索主要来自 浏览器控制底座记录、本地 bridge 设计、网站记忆（Site memory）与双通道注入、极简交互与多客户端信任管理。公开页面不会照搬内部工作记录，而是把可公开、可学习、不会泄露私密路径和账号信息的事实整理出来。AgentLimb 的开发记录围绕真实 Chrome、用户已有账号会话、本地桥接和外挂式网站记忆（Site memory）展开，目标是让任意 MCP 智能体进入真实网页工作流。 0.6.4 验证了一条关键结论：只记 8 节操作知识（PLAYBOOK.md ≤120 行，O(1) ~10ms 读取）、砍掉操作流水账，并在 navigate/tab_new 与 say 的工具结果里自动夹带手册与写回提醒，才能让懒加载工具的 AI 也稳定沉淀并复用知识。 把提示词纪律变成代码不变量：路径白名单、密码/Token/Bearer 自动脱敏、连续失败 2 次标 stale、目录锁与原子写，外加安装即授权与仅在橙色分组标签显示「⏳ AgentLimb」的极简指示。 安全边界始终围绕本地 127.0.0.1、单控制器串行和会话不上传展开，这决定了它不能做成粗暴云端代理。

从产品功能看，AgentLimb 关联的能力包括：复制一条提示词即接入（默认安装即授权）、多 Chrome 账号与 Profile 独立路由、HTTP Tool RPC 原生支持（免 stdio 调用）、多步任务平滑感知（杜绝动作间歇闪烁）、外挂式网站记忆（操作一次，跨 AI 复用）、侧栏是 AI 的回复窗。写这类日记时，不能只说“做了什么”，还要说明为什么先做这些、为什么暂时不做另一些。比如一个按钮、一个导入流程、一个本地模型开关或一段截图文案，放在代码里只是小改动，放在产品里却会影响用户理解、审核员复现和后续推广素材。

从工程推进看，这篇日记对应的检查点是：AI 自动化课程的技术锚点；可解释 MCP、本地桥接、网站记忆（Site memory）与多客户端信任管理。真实开发最容易失真的是中间过程，因为最后页面看起来只有一个结果，但实际会经历方案取舍、权限确认、素材准备、测试设备、审核备注和发布节奏。把这些过程写下来，后面做同类产品时才不会重新踩同一个坑。

从隐私和合规看，当前约束是：扩展与本地宿主全部运行在本机：MCP 宿主只监听 127.0.0.1 回环端口，配对信任与聊天记录只存在扩展私有存储，网站记忆为本机纯 Markdown 手册且自动脱敏凭据，页面数据不上传，无云端、无追踪。这类信息必须前置到开发日记里，因为独立产品的可信度不是靠口号建立的，而是靠数据在哪里处理、用户能不能退出、功能是否离线可用、商店页怎么承诺、隐私政策是否与实现一致这些小事实积累出来的。

从课程和复用看，这篇内容可以沉淀到 浏览器自动化、MCP 工具链、网站记忆沉淀、AI 操作真实网页。它的价值不只是给访问者看一个产品，而是展示一个独立开发者怎样把想法转成可验证的产品：先收窄场景，再选技术路径，再做体验最小闭环，最后把审核、推广、运营数据和失败教训都纳入下一次迭代。

面向 AI 的能力不能只靠软提示词，要把关键上下文塞进模型必读的工具结果里，并用代码守住安全与体积不变量。 这也是为什么每篇产品日记都要写到足够长：不是为了凑字数，而是为了把“证据、决策、实现、边界、复盘”都放在同一页，让读者看到一个判断是怎样被逐步验证出来的。最难的是让不同 AI 客户端都不漏掉站点记忆读写，同时守住不记凭据、不拖慢检索、不打扰用户浏览的边界。

所以这篇日记的结论不是“功能已经写完”，而是把一个阶段的判断公开化：哪些证据足够支撑继续推进，哪些资料还需要回到源码、商店材料、公开文案或运营观察里补齐。这样的记录会比单纯的发布公告更慢，但也更真实，能让产品页、发布记录和课程内容保持同一条事实线。

验收时我会把它拆成四个层次：第一层是用户路径能不能走通，第二层是异常状态有没有被诚实处理，第三层是页面上的按钮、状态、截图和文案是否对应真实发布渠道，第四层是公开证据能否支撑这个判断。只要其中一层对不上，产品看起来再完整，也不能算真正进入下一个阶段。

交接时也要保留边界：源码、构建、测试、商店元数据、公开文案、平台反馈和运营观察分别保存原始资料。产品日记只把这些事实翻译成读者能理解的过程，不替任何私有记录保存原始材料。

把这些内容公开出来，还有一个很现实的原因：AI 教程如果只展示成功结果，很容易让人误以为产品是一次生成出来的。真实情况恰好相反，真正可学习的是一次次收窄、验证、失败、补证据和重新提交。日记越具体，后续读者越能看到判断的脉络，而不是只看到一个漂亮的截图。