让浏览器 Agent 先交来源表。每一行对应一条能判断真假的主张，并写明原网页、具体位置和判定。这样，审阅者可以从报告里的一句话直接回到证据。在下面的公开样例里，两份权威资料对 HTTP 418 用了不同说法。核对日期和文件用途后，差异有了明确解释。
先把问题缩小到可以核对
我们只问两件事：当前 HTTP 状态码登记表如何标记 418，“茶壶”的说法又出现在哪里？2026 年 11 月 6 日，我们用 Tabbit 打开登记表和两份 RFC，由作者逐项复核判定。这是一次有引导的浏览器调研。让 Agent 自主执行时，也可以先给同样的范围，要求它提交未解决的条目，再起草报告。
在任务第一行写明时间、要回答的问题和什么算一手来源。“找出当前登记名称和历史表述”容易复核，“解释 HTTP 418”则容易把登记状态、历史文字和服务器行为混在一起。可以用深度调研案例确定要问的问题，再参照首次任务清单限定站点和动作。先查少量原始页面，遇到证据缺口再补。
从一句主张回到原文
| 待核对的主张 | 一手来源和位置 | 判定 |
|---|---|---|
| C1 当前登记表把 418 标为未使用。 | IANA 的 418 行，链接到 RFC 9110 §15.5.19。 | 支持，范围为 IANA 登记。 |
| C2 早期 RFC 2324 有茶壶的表述。 | 1998 年 4 月的 RFC 2324 §2.3.2。 | 支持，属于信息类 RFC 中的历史文字。 |
| C3 现行规范把 418 命名为“我是茶壶”。 | 2022 年 6 月的 RFC 9110 §15.5.19。 | 反驳。章节标为未使用，正文解释了保留原因。 |
| C4 提供的 RFC 链接可证明另一个服务器行为。 | 故意使用无效的 RFC Editor 链接作对照。 | 未核验。Tabbit 实际读到 HTTP 404。 |
下载来源表 CSV可以看到四行的实际地址、核对结果和无效对照。IANA 登记表引用了 RFC 9110，两者是一条引用链。RFC 2324 回答的是历史用语问题。如果要说明某个服务器会返回 418，需要对那个实现另找证据。
核对时从报告中的一句话出发，打开链接，记录跳转后地址并定位到章节或表格行。摘一小段原文，或写一条保留条件的转述。原文只覆盖“某些实现”时，结论就只能写到这个范围。一句话包含当前状态和历史来源时，拆成两行。浏览器 CLI 教程可以帮助提取页面原文，MCP 与 CLI 的比较说明页面观察如何传给 Agent。
保留失败和分歧
| 判定 | 如何处理 |
|---|---|
| 支持 | 按原文范围引用。 |
| 反驳 | 先修正主张，再写报告。 |
| 部分支持 | 拆开主张，只保留已有证据的部分。 |
| 未核验 | 保留失败记录，等待补证。 |
判定可以分为支持、反驳、部分支持和未核验。404 只能说明那次请求的结果，不能回答主张本身。遇到登录页时，可记录可见的标题，并注明正文没读到。没有其他可靠来源时，把这条从报告结论中移出。涉及已登录页面时，先检查浏览器权限是否覆盖该操作。
如果两份资料不同，先对照日期、定义和适用范围。这里的登记状态和历史文字回答了两个问题。若看完仍有分歧，把两种说法和补证条件一并留在表里。会变化的结论带上核对日期，重用前再打开一手来源。
可以直接给 Agent 这条要求：“先返回来源表。每个主张记录 URL、章节或行号、支持它的原文、核对日期和判定。失败也留一行。只用已支持的条目写结论，并标明推断。”抽查几条成功项，再逐项检查全部未解决条目。想了解执行步骤，可看浏览器自动化和网页调研工作流，也可以用 Tabbit 重做这个公开样例。
一手来源：IANA HTTP 状态码登记表、RFC 9110 §15.5.19、RFC 2324 §2.3.2。
常见问题
网页调研来源表要写哪些字段？
每条主张单独编号，记录原链接、实际落地地址、原文定位、短引文或转述、核对日期和判定依据。
链接能打开，为什么还需要核对原文？
网页可能确实讨论这个主题，但它支持的是另一个时间、范围或结论。看到正文后，要核对它是否支持你写的那句话。
来源打不开怎么办？
保留请求的地址、已知落地地址、核对日期、实际响应和对应主张。找到其他合适来源之前，把这条主张留在未核验状态。
两个来源说法不同怎么办？
先比较日期、适用范围、权威性和定义。两条来源都留在表里，再说明差异能否解释。
每条来源都要贴一段原文吗？
短引文或准确转述加上章节定位即可。写清哪些是来源的内容，哪些是你从中得到的结论。