风险

法律、条款与责任

• 站点使用条款。 政府网站和航空公司、活动平台通常禁止未经授权的自动化访问，或要求仅由本人操作。本次没有把 thaievisa.go.th 与 tm47.immigration.go.th 的完整条款逐条引用下来（实现前必须再读一遍当时的 Terms）。产品定位应是「在用户本人电脑上、由用户发起并盯着的辅助填写」，而不是无人值守的机器人。对外文案不要写「全自动申报」。
• 申请人是责任主体。 伦敦大使馆写明自动填充也要本人核对，提交后不能改，错误可能导致拒签且费用不退（说明）。产品必须在提交闸门上重复这一点：Agent24 不对获批、拒签、逾期罚款负责。建议在首次使用时用明白的中文和英文让用户确认。
• 不要代办。 一旦收取「包过」费用或替用户保管护照原件，性质就变成移民服务，可能触及当地牌照。路径上已建议远离这条（见商业模式）。
• 验证码与反自动化。 把政府站点的验证码送去商业打码，既可能违反该站点条款，也把页面图像送给第三方。MVP 禁止这样做。
• 个人数据保护。 若功能以后提供给在泰国的用户，需要对照泰国《个人数据保护法》（PDPA）评估：本机单用户、数据不离开设备、不向开发者回传护照，风险显著低于云端代办。但这不等于「无需任何告知」。隐私说明要写清：数据存在哪里、有没有遥测、日志里有没有值。本次不是法律意见，上线前应请有资质的人看一遍。
• 电脑使用代理的通用风险。 OpenAI 和 Anthropic 都把提示注入（页面里隐藏指令，诱使智能体泄露数据或乱操作）写成真实风险（ChatGPT agent 帮助中心、Claude in Chrome 公告）。FormVault 的缓解是：固定站点走配方而不是自由模型；模型看不到值；提交必须人批；允许的域名写死。通用智能体阶段要把提示注入当成一等风险，而不是事后补丁。

政府站点变更

• 选择器、步骤、时间窗口都可能在没有预告的情况下改变。这是配方产品的主要维护成本，也是以后若收费时可以解释的成本。
• 缓解：配方版本化；每一步有成功判定；失败时停下来给人，而不是乱点；用本机回归脚本对着「保存下来的页面快照」跑（不要高频打真实政府站）；可选的「修复模式」必须再经人确认才写回配方。
• 官方口径本身就会不一致（TM.47 的 15 天与「不少于 7 天」）。代码里把窗口规则做成可配置，并显示出处，不要写死一条。

安全

• 保险箱加密保护的是磁盘丢失和普通备份泄露，挡不住已经在用户机器上、与 Agent24 同权限的恶意软件。要把这个限制写进说明。Agent24 进程外模块目前与内核同 UID（架构基线，2026-11-12）。
• 主密钥在操作系统钥匙串，不进 Git，不进云同步，不进模型日志。
• 审计日志掩码。分享调试包前自动红action。
• 附件和下载的回执可能含住址和护照号，默认进加密档案，而不是桌面明文 PDF。
• 不要为了「方便登录」去实现从云端邮箱抓取密码或 OTP，除非有明确的最小权限设计和用户开关。

产品与技术风险

• 本地 8B 级模型可能不够做复杂的未知站点规划。这是把通用智能体放到 P1 以后的原因：MVP 不依赖它。
• 政府站点反爬可能对 Playwright 新配置文件不友好。优先走用户自己的 Chrome。
• Agent24 主循环的 10 轮、30 秒超时不够跑完整张 e-Visa。必须在模块内做状态机，一次工具调用覆盖多步，只在闸门处返回。
• 姓名转写、地址英文拼写、日期格式（日/月/年还是年-月-日）是实际出错点，要比「模型聪不聪明」更早写测试。

衡量指标

在没有大量用户之前，用下面这些就够了。数字应来自本机运行记录（用户 voluntarily 打开统计），不要默认回传。

• 完成率： 从发起到「用户确认提交」或「停在支付前（e-Visa）」的比例。
• 人为干预次数： 每次任务中验证码、OTP、选错字段、手动改值的次数。趋势应下降。
• 核对发现问题数： 闸门上用户改了多少个字段。若经常改同一字段，说明映射有缺陷。
• 准时率（TM.47）： 在官方窗口内完成的比例；逾期次数应趋近于零。这是对用户最有意义的结果指标。
• 配方失效率： 因页面结构变化而中断的次数和日期，用来安排跟版。
• 隐私承诺的技术验证： 自动化测试保证规划提示词里不出现护照号、密码和照片二进制。这是发布门禁，不是可选项。
• 时间： 用户从打开到提交的时长，对比「完全手填」的自我估计。样本少时当作定性证据。

路线图

P0（MVP，建议的第一版）

• 加密保险箱 + 操作系统钥匙串 + 规范字段谱系（含泰国地址）。
• 本机浏览器操作器（优先 Chrome 扩展或 CDP 附着）。
• 提交前核对清单、验证码/OTP 交接、审计日志掩码。
• TM.47 配方：登录、填、预览、人确认后提交、查状态、存回执。
• 调度提醒：按用户记录的到期日，在窗口可能开始时提醒（规则可配置，展示出处）。
• e-Visa 配方：填和上传，停在支付前。
• 全程 LocalOnly。发布门禁：提示词不含敏感值。
• 用维护者自己的真实周期做至少一次「人监督」的 TM.47（遵守条款，本人在场）。

P1

• 配方失败时的修复模式（模型提议、人确认、写回版本）。
• 通用站点的 DOM 规划（仍然盲规划、本地填写），限域名白名单。
• 本机视觉模型兜底（验证码仍由人解，视觉只用来找控件）。
• 可选对接 Bitwarden 或 1Password，密码仍不进模型。
• 更多固定配方：例如下一次由用户指定的高频站点（投诉、活动报名），一条一条加，不搞「任意网站保证成功」。
• 若有稳定使用，试验很窄的「配方年费」包装。

P2

• 加密备份与家庭成员档案（e-Visa 手册允许一个账户为家人申请，仍须每人核对）。
• 跨设备：仅在用户自建隧道和已有 Agent24 远程认证模型下考虑，默认仍然是单机。daemon 目前只绑 127.0.0.1（架构基线）。
• 社区配方市场（必须有签名、域名白名单、责任声明），不是优先项。
• 明确继续不做：云端浏览器、打码服务、签证结果担保、机票自动付款。

建议的下一步（给作者）

1. 先确认自己就是第一个用户。 下一次 TM.47 到期日是哪天、账号是否已有、护照是否即将更换（换护照则不能走网上）。这些决定 P0 的日历。
2. 在还不写自动提交的前提下，手工走一遍两个官方站点，把当前活页的字段和选择器记成配方草稿。 人在场，不当成无人值守脚本。
3. 在 Agent24 里开一个进程外模块仓库（或目录），先实现保险箱和假表单验收，按技术架构里的落地顺序，不要先对政府站点调 Playwright。
4. 请人看一眼条款和 PDPA 告知草稿，再决定对外演示的措辞。
5. 硬件确认： 是否已在本机跑 oMLX 或 Ollama，内存是否达到舒适运行 8B 级 4bit 模型。MVP 在两条固定配方上可以几乎不靠视觉。
6. 决定浏览器形态： 能否接受先做 Chrome 扩展。若作者主要用其他浏览器，P0 的附着方案要跟着改。

还需要向作者确认的问题

• 你下一次 90 天报到的窗口大概在什么时候？是否换过护照或最近无再入境许可出境过？
• 更急的是 TM.47，还是下一次 e-Visa？
• 日常浏览器是 Chrome、Edge、Safari 还是其他？能否接受安装扩展？
• 保险箱要完全自管，还是希望第一版就对接你已有的 1Password 或 Bitwarden？
• 是否已经在这台电脑上稳定运行 Agent24 的本地模型（oMLX 或 Ollama）？
• 对外演示时，你能否接受「助手填写、你按提交」这条不可妥协的产品原则，即使看起来没有竞品那么「全自动」？