Agent24 本地隐私填表助手

技术架构

本地保险箱、字段谱系、站点配方、本地模型、DOM 与视觉、人机闸门，以及落到 Agent24 的推荐结构。

目录 / Agent24 本地隐私填表助手 / 技术架构

设计原则

  1. 值不出机。 护照号、密码、照片二进制只存在本地保险箱，只被本机进程读取。云端模型（如果将来启用）最多看到字段标签、控件角色和红acted 的页面结构。
  2. 规划与填写分开。 规划器输出「在哪个控件填哪一个档案字段」，执行器在本机取值并键入。这就是 Skyvern 和 1Password 已经公开的模式，FormVault 把它做到不上云。
  3. 固定站点用配方，未知站点才用智能体。 配方是带选择器、等待条件和校验的确定性剧本。智能体是配方没有命中或步骤失败时的修复器。
  4. 人掌握不可逆动作。 验证码、OTP、支付、提交，默认闸门。Agent24 已有 ApprovalBroker 和按工具风险等级审批（架构基线，2026-11-12，bc923205），应直接复用，不要另做一套同意 UI。
  5. 浏览器不要进内核。 Agent24 的内核是 Rust daemon，默认工具只有 http_fetch、fs_read、fs_write、shell_exec。浏览器驱动应作为进程外模块或 sidecar，崩溃和站点反爬隔离在外。

推荐的整体结构

flowchart TD
  user[用户: 网址加一句话] --> daemon[Agent24 daemon<br/>LocalOnly 任务画像]
  daemon --> match{URL 是否有配方}
  match -->|有| recipe[站点配方执行器]
  match -->|无| planner[本机规划器<br/>只输出字段映射]
  planner --> recipe
  recipe --> vault[本地保险箱<br/>操作系统钥匙串解包]
  vault --> operator[本机浏览器操作器<br/>CDP 附着或 Playwright]
  operator --> gate{闸门}
  gate -->|验证码 OTP 支付 提交| human[交给用户]
  gate -->|普通填写| operator
  human --> operator
  operator --> audit[审计日志与回执档案]

落到 Agent24 现在的扩展点

根据 2026-11-12 对 bc923205 的架构阅读（见 agent24-evolution 基线，源码在 iDoris-ai/agent24）：

Agent24 已有怎么用在 FormVault不够的地方
ModelRouter 与 LocalOnly：默认 oMLX（Qwen3-8B-4bit）和 Ollama；本地实例只走回环，不读代理环境变量填表 run 一律 LocalOnly。规划用本地 7B/8B 级模型足够给字段分类；视觉用本地 VLM 做兜底默认没有按任务自动升到复杂档。填表应显式指定，不要依赖默认 TaskProfile
ApprovalBroker、工具风险等级、会话级授权form_submit、vault_export、打开新域名为高风险，必须人批。普通 form_type 可按站点白名单授权默认工具超时 30 秒，主循环最多 10 轮、每轮 16 次工具。一整份 e-Visa 必须由配方引擎在一次工具调用里跑多步，而不是每填一个框就占一轮模型
SQLite 存储、审计日志带 prev_hash / hash 链每次填写与提交写审计。回执文件入工作区现有 Store 自己写明「只记账，不建调用方授权」。保险箱的授权要另做，不能只靠多一张表
调度器（cron / at，漏触发只补一次）TM.47 窗口提醒、状态轮询（注意礼貌间隔，不要高频打政府站点）调度触发的 run 也必须 LocalOnly，且不能自动提交
进程外领域 OS、os attach、MCP推荐 FormVault 作为进程外模块：独立进程、自己的库、经 /api/v1/<name>/* 或附着连接与 daemon 对话进程外模块与内核同 UID、无沙箱。这是既有限制，要在文档里写清：保险箱加密是防御磁盘泄露，不是防御本机恶意进程
Electron 桌面壳核对清单、验证码接管、预览比对做在壳里不要把 Playwright 塞进 Electron 渲染进程

技能契约 ADR-040 在该快照里仍是「零代码」。MVP 不要等技能加载器，把配方做成模块内的数据文件即可。

本地保险箱

推荐设计：

不要把保险箱做成 Solid Pod 那种对外授权网络服务。需求是本机单用户。Solid 的启发只在字段谱系和授权语义，不在部署形态。

规范字段谱系

用一份与具体网站无关的个人档案，配方只做「谱系路径 → 表单控件」的映射。建议至少包括：

映射表示例：person.family_name → #familyName，或「无障碍树里 name 为 Family Name 的文本框」。配方版本要跟着站点改动升级。

站点配方与通用智能体

配方（P0 主力） 是 YAML 或 JSON，内容包括：起始 URL 与允许的域、步骤列表（打开、等待、点击、填、上传、截图）、每步的选择器（CSS、角色、标签文本，可写多个备选）、字段映射、文件规格（类型、大小、尺寸）、已知闸门（验证码、OTP）、成功判定（出现「Pending」或回执编号）、失败时的人读说明。配方由维护者针对真实站点书写并回归，不在运行时让模型改写选择器，除非进入修复模式并再次请人确认。

通用智能体（P1） 在未知 URL 上：本机模型读 DOM 和无障碍树（去掉值），输出填表计划；本机执行器取值填写；视觉模型只在 DOM 不够时看截图。截图在发给模型前要做红action：用占位块盖住已填的值。这一步是「盲规划」的具体实现。

Skyvern 选择纯视觉是为了企业门户经常改 class。个人政府站点改版没那么频繁，但改一次就会让配方失败，所以要有「修复模式」：模型提议新选择器，人看一遍再写回配方。

浏览器怎么开

三种做法，按推荐顺序：

  1. Chrome 扩展 + CDP 附着到用户日常浏览器。 优点：已有登录态、真实指纹、政府站点较少直接拦截。缺点：要装扩展，要小心权限。Opera Neon 走的就是「在你已登录的浏览器里做」（2025-09-30）。对个人隐私填表，这是最自然的。
  2. 本机 Playwright 持久配置文件（专用 Chromium）。 工程更干净，可重复，但新配置文件容易被政府站点当成机器人，验证码会更多。适合开发回归，也适合用户不愿意给扩展权限时的备选。
  3. 云端浏览器（Browserbase 等）。 明确排除。护照和密码会进入别人的浏览器会话，和产品原则冲突。

本地模型与硬件

验证码、OTP、上传、提交

审计、红action、盲规划

推荐落地顺序（工程）

  1. 先做保险箱和字段谱系，以及一个「把档案填进本地 HTML 假表单」的验收，不碰政府站点。
  2. 再做浏览器操作器和闸门 UI，用假站点跑通验证码交接与提交审批。
  3. 第三步才写 TM.47 配方，用维护者自己的账号在真实站点上人监督试跑（注意法律与条款，见风险）。
  4. 第四步 e-Visa 配方，停在支付前。
  5. 最后才考虑通用智能体和云端盲规划。