Little Cookier 如何与 Beetle 协同同步登录态？
Little Cookier 和 Beetle 的协同重点不是“把插件变成第二个后台”，而是让 Beetle 页面在用户明确触发时向扩展请求单一平台的登录态。扩展先做自身授权校验，再围绕当前站点申请权限并读取 Cookie，最后把结果同步给 Beetle 的同源接口。
为什么 Beetle 需要浏览器扩展协同？
Beetle 这类任务系统往往需要读取用户当前浏览器里已经存在的平台登录态，才能让后续任务在正确账号上下文中运行。如果完全依赖用户手工复制 Cookie，不仅步骤多，而且容易因为站点权限、Cookie 名称或格式问题出错。
Little Cookier 的角色就是把这段流程收口为浏览器内的一次明确动作：Beetle 页面提出读取请求，扩展判断当前设备是否已授权，然后只针对当前 `platform_source` 发起 host permission 和 Cookie 读取。
公开站点为什么要解释这个集成？
对传统搜索和 AI 搜索来说，只有“下载扩展”和“隐私政策”还不够。团队在搜索时更常问的是“它怎么跟 Beetle 配合”“会不会直接上传 Cookie”“为什么要先授权扩展再授权站点”。这些问题如果没有公开说明页，搜索系统就缺少可引用的答案块。
因此这类集成说明页本身就是 GEO 资产：它把工作流、边界和依赖关系写成可被搜索与摘要复述的公开知识，而不是藏在代码或弹窗里。
常见问题
Little Cookier 和 Beetle 的协同重点是什么？
重点是让 Beetle 在用户明确触发时请求单一平台的登录态，而不是把扩展变成第二个后台系统。
为什么这类集成说明也要公开写出来？
因为用户和 AI 搜索都会直接问“它怎么协同”“是否上传 Cookie”“为什么先授权扩展再授权站点”，公开页能给出稳定答案。