要用 Sakana Fugu 对照两个已登录的网站，可从本机 Agent 使用 fugu 路由，并让它运行 Tabbit CLI。提供稳定记录 ID，要求 Agent 在两个获准访问的网站中查找对应记录，再输出包含双方来源链接的对照表。两个网站都保持只读，任何差异都留在具名草稿中，交给人处理。
一位 Reddit 用户在早期讨论中说，自己在编程任务里试用后更偏好标准 Fugu，而不是表现不稳定、速度更慢且费用更高的 Ultra。这是个人体验，不是基准结论；但它说明了一个实际选择：先用基础路由处理边界清楚的查找，再评估结果是否够用。查看原始讨论。
要点
Sakana 基础 API 模型为
fugu，与带版本号的 Ultra 端点不同。模型端点不会携带网站登录态。本机客户端必须在已有登录的浏览器配置中运行 Tabbit CLI。
用工单、订单或案例编号等稳定 ID 匹配，不要在有唯一编号时只用姓名检索。
要求只读对账表，每个系统都附一个来源链接，并明确标出“待复核”。
人工检查双方记录并批准前，不要让 Agent 更新任何系统。
确认 Fugu 路由和本地浏览器路径
| 检查项 | 确认内容 | 安全的下一步 |
|---|---|---|
| 模型路由 | 客户端或服务商提供 Sakana fugu | 先发一条无敏感内容的短请求，确认所选路由 |
| Tabbit 妙招 | 本机客户端已加载 Tabbit 妙招说明 | 使用客户端文档中的技能菜单；Pi 的入口是 /skill:tabbit |
| 浏览器配置 | 两个网站均已登录到目标账号 | 委派读取前亲自打开两个网站确认 |
| 记录键 | 两个系统都能查到同一个稳定 ID | 若匹配不唯一，立即停止并请人确认 |
Sakana 的官方 API 文档将 fugu 定位为日常使用路由，并说明 API 接入。它会在支持的模型池中路由；模型可用性和本地浏览器访问是两项独立检查。开始前确认服务商账号实际提供 fugu。 Models.dev Sakana 目录可辅助发现，但应以客户端当前模型列表为准。
当本机 Agent 支持 Tabbit CLI 时，Tabbit Browser 可以让它访问页面。请阅读Tabbit CLI 指南和连接现有浏览器配置。不要假设 API 自己能读取已登录页面，也不要假设远程 Agent 能访问你的电脑。
用稳定 ID 核对两个系统
选择一个你获准查看的记录。第一次试用最好用测试工单或测试订单，而不是客户记录。只提供稳定 ID 和完成核对所需的字段。要求 Agent 以两边页面的链接和可见信息为依据，不要自行猜测字段的含义。
| 对照字段 | 系统 A | 系统 B | 复核规则 |
|---|---|---|---|
| 稳定记录 ID | 页面显示的 ID 和记录链接 | 页面显示的 ID 和记录链接 | ID 不同或出现多个匹配时停止 |
| 状态 | 页面可见的状态原文 | 页面可见的状态原文 | 保留原文，差异标记出来 |
| 更新时间 | 页面时间，以及可见时的时区 | 页面时间，以及可见时的时区 | 不要抹掉时区差异 |
| 金额或数量 | 页面数值和单位 | 页面数值和单位 | 只比较含义相同的字段 |
不要把两个相似姓名当成记录匹配的证据。如果系统不显示某个字段，就记录“页面不可见”并附上链接。首个浏览器任务清单说明如何缩小第一项任务的范围；该清单也解释了为什么应先使用只读权限。
开两个任务标签页，保留登录态
打开两个网站前，用已安装的启动器运行 tabbit-cli diagnose，确认本地控制器正在运行。这只检查 CLI 是否可连接；模型选择、技能发现和网站登录仍需分别核对。
使用一个已在两个网站登录的 Tabbit 配置。Agent 应为每个网站打开独立任务标签页，用户可继续使用原来的标签页。读取字段前，先核对每个任务标签页中的网站和记录 ID。
打开准备使用的 Tabbit 配置，亲自确认两个登录仍有效。
启动支持 Fugu 的本机客户端，确认所选模型为
fugu。从客户端的技能菜单加载 Tabbit 妙招。Pi 使用
/skill:tabbit，有些客户端使用/skills菜单。让 Tabbit CLI 为系统 A 打开独立任务标签页，核对账号和精确 ID。
在系统 B 重复这一步。若网站要求登录或显示了意外页面，先停下并由你处理。
让 Agent 起草对照表。第一轮不要授予写入操作权限。
本机夹具测试中，受保护页面在建立短期测试会话前返回 401；第二个具名任务复用会话后，成功读取测试页面。这只证明本地测试环境中的会话复用，没有调用 Fugu、登录真实客户网站或验证外部模型集成。选择浏览器控制方式时，可读MCP 与 CLI 对比和Codex Tabbit 设置。
要求生成对账草稿，不要更新记录
有用的结果是一张能逐项核对的简表。草稿名称应与来源记录区分开。
使用 Sakana Fugu 模型 fugu，对照我指定的两个获准网站中的记录 ID TEST-4821。从本机 Agent 调用 Tabbit CLI，每个网站打开一个独立任务标签页。只读取该 ID 对应的记录。创建名为“Fugu 记录对账”的草稿，字段包括：字段名、系统 A 的值和 URL、系统 B 的值和 URL、匹配状态、复核备注。保留页面显示的原始文字和时间。如果 ID 不存在、重复或不同，停止并标为“待复核”。不要编辑、提交、批准或发送任何内容。下一步前先展示草稿给我。TEST-4821 是示例夹具 ID，不是真实记录。请替换成你有权检查的编号。预期草稿应包含两条记录的直接链接、准确字段值和清楚的差异标记。让 Fugu 再检查一次表格可以辅助复核，但业务负责人仍应打开两个目标页面后再决定如何处理差异。
一篇早期独立体验文章在比较 Fugu API 和 Ultra 时，分别记录了提示词、Token 用量和延迟。这类记录能帮助判断模型选择是否适合任务，但不能证明它能准确处理你的记录。查看第一手 API 体验。
如何判断基础 Fugu 是否够用
对于边界清楚的记录对照，如果 fugu 可用，且页面信息易读，可以先从它开始。它可能会通过变化中的模型池路由，因此不同运行结果取决于当时服务和任务上下文。若任务需要原版 Ultra，或你自己的试用表明更深推理有用，再选择固定版本。不要把模型差异与浏览器登录能力混为一谈。
当两个记录页都需要登录，且本机浏览器已经登录时，Tabbit 才能帮上忙。公开网页可能只需要搜索工具；私有记录则需要本地浏览器路线来提供页面上下文，差异结论仍由人决定。先选一条测试记录，产出可复核的草稿。
Tabbit CLI 指南 · 访问现有浏览器 · 首个浏览器任务 · MCP 或 CLI · 网页搜索或浏览器控制 · Agent 浏览器基础 · Codex 设置 · Playwright MCP 设置
常见问题
标准 Sakana Fugu 的模型 ID 是什么？
Sakana API 使用 fugu 作为基础路由。它会在支持的模型池中路由任务，因此开始前要确认客户端和服务商确实提供该入口。
Fugu 能对照两个已登录的网站吗？
Fugu 本身不提供浏览器登录态。请使用能调用 Fugu、并能在已登录配置中运行 Tabbit CLI 的本机 Agent 客户端。
为什么要用稳定记录 ID 匹配？
不同系统中的名称和日期可能不同。共同 ID 能提供准确的检索键，也更容易复核差异。
应该让 Agent 更新任一系统吗？
不应该。先用只读权限生成带双方记录链接的对账草稿，再由人检查差异并决定是否更新。
能否用远程 Agent 完成这个流程？
只有客户端支持连接本机 Tabbit 浏览器时才可以。否则应在拥有登录配置的电脑上运行 Agent。