dsh-store-account-manager
面向 DeepSeek Harness 的本地优先平台账户和持久化浏览器会话管理器
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:sycamorestr/dsh-store-account-manager#e9ae518e1686edc0efb4f35a83dc970b5f9b518bStore Account Manager 以 dsh-store-account-manager 发布，当前版本为 0.3.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
一个面向 DeepSeek Harness（DSH）的本地优先平台账号与浏览器会话管理插件。
它把“平台账号”与“浏览器数据目录”作为两个独立概念管理：账号保存平台名称、后台地址和业务上下文；浏览器数据目录保存 Chromium 的 Cookie、Local Storage、IndexedDB 等登录状态。多个平台账号既可以使用相互隔离的目录，也可以按需共享同一个目录。
当前版本：
0.3.0
Agent 要进入电商后台、内容平台、客服系统、广告平台或企业 SaaS 时，常见方案有几个现实问题：
本项目专注解决账号、浏览器数据目录和登录会话生命周期问题，不承担通用网页自动化。
Default 用户，不再引入额外的浏览器用户/Profile 层级。目录与账号分别归档：
UI 会分别显示活动账号引用数和归档账号引用数。删除归档目录时，所有仍引用它的归档账号记录会在同一次确认操作中永久移除，避免留下失效引用。
删除提供两种模式：
browserDataRoot/<directory-id> 下创建的目录。物理删除必须同时满足：目录已归档、浏览器离线、没有活动账号引用、路径严格位于默认根目录、目录不是符号链接或联接、所有权标记与目录记录完全匹配，并由用户输入完整目录名称确认。旧版 profiles/ 目录和用户自定义目录永远只能取消登记，插件不会递归删除其本机文件。
独立目录适合：
共享目录适合：
共享目录意味着共享全部浏览器状态，不只是某一个平台的 Cookie。关闭这个目录对应的浏览器时，该目录下所有账号页面都会一起关闭。
Chromium 原本会把普通持久 Cookie 保存到浏览器数据目录，但部分登录状态使用“会话 Cookie”，默认可能随着浏览器会话结束而清除。
插件在托管浏览器在线时执行以下流程：
Storage.setCookies 为可处理的会话 Cookie 设置本地到期时间。浏览器启动后的前 60 秒每 2 秒同步一次，之后每 15 秒同步一次；人工标记已登录、关闭浏览器和登录检测也会触发同步。
开发期间对 Chrome 和 Edge 做了控制变量测试：
| 启动方式 | 实测结果 |
|---|---|
| 不启用远程调试 | 账号密码登录成功 |
--remote-debugging-port=0 | 登录验证持续失败 |
| 固定的非零远程调试端口 | 登录成功 |
在本次环境中，port=0 会使 Chromium 暴露 AutomationControlled 特征，而固定非零端口没有触发同样结果。因此插件采用：
--remote-debugging-address=127.0.0.1
--remote-debugging-port=<运行时分配的固定非零端口>
--user-data-dir=<浏览器数据目录>
同时遵循以下限制：
127.0.0.1。--enable-automation。--remote-debugging-port=0。这是针对当前 Chrome、Edge 与目标平台的实测结论，不代表所有平台风控都采用相同判断。启用 CDP 仍可能被某些站点识别。
固定端口启动时 Chromium 不会提供可依赖的 DevToolsActivePort 文件，因此插件维护独立的 browser-runtime.json，记录“数据目录 -> PID、端口、实例 ID”的对应关系。DSH 重启后会验证 PID 和 CDP 健康状态，只恢复仍然有效的记录，并清理陈旧记录。
每个账号都可以随时执行“检测登录状态”。检测流程严格限制为：
登录检测不会读取页面正文、生成 DOM 快照、点击控件、输入账号密码或处理验证码。
检测结果包括：
valid：受保护后台地址成功打开，未落到登录地址；invalid：最终地址是配置的登录地址或明显的登录路径；unknown：通用 URL 规则无法证明是否已登录；error：浏览器启动、页面加载或 CDP 通信失败；unchecked：尚未检测。对于登录页和后台页使用完全相同 URL、单页应用内部切换状态或不发生 URL 跳转的平台，检测可能返回 unknown。
账号行只保留一个“检测登录状态”入口。检测完成后显示结果弹窗：valid 自动标记有效，invalid 自动标记失效，只有 unknown 或 error 才显示“人工标记为已登录”。人工确认会清除旧的自动失败展示，并记录来源和时间；它只表示用户完成了人工核验，不代表插件从平台服务端取得了有效性证明。
内置定时保活默认关闭。
账号可以独立设置：
1 到 720 小时；0 到 240 分钟；调度器每分钟检查到期任务。共享同一个浏览器数据目录的到期账号会被分为一组，在同一个浏览器进程中依次检测，减少重复启动成本。
每次运行会访问账号配置的后台地址、观察登录重定向并同步 Cookie。失败任务使用指数退避，最大放大到正常间隔的 8 倍。
定时访问可以让平台有机会刷新 Cookie 或服务端会话，但是否刷新、刷新多久完全取决于平台。插件不会伪造业务操作，也不保证会话一定被延长。
当前版本只在账号管理器内部串行化同一目录的启动、检测、Cookie 同步和关闭操作，没有实现跨插件的“前台任务租约”。如果另一个插件正在操作同一浏览器，内置保活仍可能打开或关闭临时标签页而影响任务。计划由 Agent 定时任务负责保活时，建议保持内置保活关闭，让 Agent 在没有业务任务时调用 platform_account_check_login；不要同时启用两套调度。
插件只向 Agent 注册四个会话管理工具：
| 工具 | 作用 |
|---|---|
platform_account_list | 按平台名称和账号名称列出账号、登录检测、保活和浏览器状态 |
platform_account_open | 在托管浏览器中打开配置的后台或登录地址 |
platform_account_check_login | 使用临时标签页检测登录状态 |
platform_browser_close | 同步 Cookie 后关闭整个浏览器数据目录对应的浏览器 |
platform_browser_close 会经过 DSH 工具批准流程，因为共享目录下可能有多个账号受到影响。
工具输出不包含：
Agent 先使用 platformName + name 识别目标账号，再把返回的 id 传给其他工具。目录名称、目录 ID 和目录地址都不参与 Agent 的账号识别。
这个插件不提供通用页面自动化，因此没有以下能力：
需要操作页面的插件应作为独立插件开发，通过内部会话服务连接已打开的受信任浏览器，而不是把页面操作重新塞回账号管理器。
插件在 Cordis 上提供 ctx.platformSessions，供本机受信任插件使用：
interface PlatformSessionService {
list(): Promise<PlatformAccount[]>
open(accountId: string): Promise<PlatformStatus>
close(accountId: string): Promise<void>
checkLogin(accountId: string): Promise<LoginCheckResult>
connection(accountId: string): Promise<TrustedBrowserConnection>
}
connection() 返回环回地址上的内部 CDP endpoint。它不会通过本地 HTTP API 或 Agent 工具公开。未来的浏览器操作插件应注入 platformSessions 服务，并继续自行定义操作范围、批准规则和审计策略。
flowchart LR
UI[平台管理 UI] --> API[Loopback HTTP API]
AGENT[DSH Agent] --> TOOLS[4 个会话管理工具]
AUTOMATION[受信任浏览器插件] --> SERVICE[platformSessions 服务]
API --> REPO[AccountRepository]
API --> BROWSER[BrowserManager]
TOOLS --> REPO
TOOLS --> BROWSER
SERVICE --> REPO
SERVICE --> BROWSER
TIMER[KeepAliveScheduler] --> REPO
TIMER --> BROWSER
REPO --> META[accounts.json]
BROWSER --> RUNTIME[browser-runtime.json]
BROWSER --> CHROMIUM[Chrome / Edge]
CHROMIUM --> PROFILE[浏览器数据目录]
| 文件 | 职责 |
|---|---|
src/index.ts | 插件配置、依赖注入和生命周期装配 |
src/shared.ts | 账号、目录、状态和保活共享类型 |
src/store.ts | v3 数据模型、迁移、目录生命周期、安全删除、校验和原子写入 |
src/browser.ts | 浏览器启动、运行时登记、Cookie 同步和登录检测 |
src/maintenance.ts | 定时保活、共享目录分组和失败退避 |
src/api.ts | 仅限本机 UI 的 HTTP API 与目录选择器 |
src/tools.ts | Agent 可见的最小工具集 |
src/service.ts | 供受信任插件使用的内部会话服务 |
src/client/ | DSH 设置页中的“平台管理”界面 |
本项目遵循 DSH 的 Cordis 插件模型：通过 inject 声明依赖，通过 ctx.effect()、ctx.interval() 和 Service 生命周期注册可撤销资源。参考 DeepSeek Harness 插件开发文档 与 DSH 架构说明。
默认数据目录：
%DSH_HOME%/store-account-manager/
未设置 DSH_HOME 时，通常为：
~/.dsh/store-account-manager/
目录内容：
store-account-manager/
├── accounts.json # v3 元数据，不保存密码和 Cookie 值
├── accounts.v1.backup.json # 首次从 v1 迁移时创建
├── accounts.v2.backup.json # 首次从 v2 迁移时创建，内容与原文件完全一致
├── browser-runtime.json # 当前浏览器 PID 与环回 CDP 端口
├── profiles/ # v1 账号原有目录，迁移后仍原地使用
└── browser-data/ # 默认新建目录根路径
└── <directory-id>/
├── .dsh-browser-data.json
└── Default/ # Chromium 自己维护的数据
账号元数据与浏览器状态分离：
PlatformAccount 必须指向一个 BrowserDataDirectory；plugin-created、custom 或 legacy 来源；accounts.json；Origin 的请求只接受 localhost、127.0.0.1 或 ::1。X-Content-Type-Options: nosniff。环回 CDP 仍然是一项高权限本机能力。同一操作系统用户下的恶意进程可能尝试探测本机端口，因此应确保电脑账户、插件来源和本地进程可信。
>= 22.19git clone https://github.com/sycamorestr/dsh-store-account-manager.git
cd dsh-store-account-manager
pnpm install
pnpm build
dsh plugin --profile web add link:$PWD
dsh web --no-open
然后打开：
http://127.0.0.1:3080/
进入 DSH 设置，选择“平台管理”。
链接安装后，源码更新需要重新执行 pnpm build 并重启 DSH。DSH Profile 通过 bundle 的 cordis.patch.yml 挂载插件；官方说明见 Profiles 与 bundles。
| 配置项 | 默认值 | 说明 |
|---|---|---|
dataDir | ~/.dsh/store-account-manager | 元数据、运行时登记和 v1 旧目录根路径 |
browserDataRoot | <dataDir>/browser-data | 自动创建浏览器数据目录的默认根路径 |
cookieRetentionDays | 365 | 会话 Cookie 转为持久 Cookie 时使用的本地期限，范围 1-3650 天 |
chromePath | 自动检测 | Chrome 可执行文件绝对路径 |
edgePath | 自动检测 | Edge 可执行文件绝对路径 |
可以在 Web Profile 的 cordis.patch.yml 中覆盖完整配置：
- id: store-account-manager
config:
dataDir: 'D:\DSH\platform-manager'
browserDataRoot: 'E:\BrowserData'
cookieRetentionDays: 365
chromePath: 'C:\Program Files\Google\Chrome\Application\chrome.exe'
edgePath: 'C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe'
DSH 的配置 patch 会整体替换目标行的 config，修改时应保留需要的全部字段。
如果检测到 accounts.json 的版本是 1：
accounts.v1.backup.json；profiles/<account-id>；legacy，不授予插件物理删除权限；accounts.json。迁移不会把旧浏览器资料搬到新的 browser-data/。旧登录状态能否继续使用，仍由原目录内容和平台服务端有效期决定。
首次由 0.2.x 升级到 0.3.0 时：
accounts.v2.backup.json；profiles/<account-id> 推断为 legacy；browserDataRoot/<directory-id> 的目录推断为 plugin-created；custom；automatic，没有自动有效结论的 ready 状态标记为 manual；共享后，这些账号使用同一个浏览器进程和全部站点数据。不要用它承载需要互相隔离的同平台账号。
有两种方式：
browserDataRoot，让后续自动创建目录都进入指定磁盘；--remote-debugging-port=0。--enable-automation。Chromium 不允许多个浏览器进程同时安全写入同一个用户数据目录。关闭手动打开的同目录浏览器，再由插件重新打开。
unknown检查后台地址与登录地址是否准确。部分单页应用不通过 URL 表达登录状态，通用检测无法可靠判断；这类平台可在结果弹窗中人工确认，并把更精确的适配规则放在未来的平台专用插件中。
browser-runtime.json 只恢复 PID 和 CDP 端点都仍健康的浏览器。如果浏览器已经退出、PID 变化或端口不可访问，旧记录会被清除；再次点击“打开平台”即可重新建立运行时。
pnpm typecheck
pnpm test
pnpm build
当前测试覆盖：
构建输出：
lib/index.js：Node 端插件；lib/index.js.map：服务端 source map；lib/client.js：DSH Web 客户端模块。DevToolsActivePort。MIT