企业官网建设流程全解析

• 人工智能
• AI Agent
• 浏览器控制
• GUI 自动化
• MCP 服务

AI Agent 读网页是一次随机过程指向确定任务：它很能干，却并不精确，因此输出必须被检查，而检查必须便宜到你真的愿意运行。本文围绕 invisible_playwright_mcp 的真实采集场景，给出按成本排序的五道校验——前三道各只需几秒——并说明为什么“两次运行结果一致”证明不了正确性、什么错误是五道校验全部抓不到的，以及如何在任务提示词里把两道算数类校验直接交给 Agent 自己完成。

为什么“输出需要校验”是这个项目的基本前提

把 Agent 当作一个随机仪器对准一个确定任务，是理解本页一切建议的前提：它读取的是真实网页（browser_read_text拿到的是页面可见文本，见 mcp/server.py），但它对文本的理解、计数与归纳都具有随机性。仓库中的实测案例也印证了这一点——文章：Web research, audited 里，Agent 在 60 本书的目录上统计“超过 40 英镑的价格”与价格带分布，虽然与无模型脚本的确定性答案完全一致，但文章明确写下了边界：干净的价格字符串是容易输入，价格埋在叙述里、分散在变体中、或渲染成图片时，读取就开始漂移。因此校验不是可选项，而是让采集结果可用的必要条件。

五道校验，按成本排序

校验必须便宜到“你确实会去运行它”。前三道加起来只要一分钟，第四道是读数，第五道最贵也最容易被高估。

1. 用页面自己报的数去对行数

大多数列表页会声明自身规模：“1,240 results”“page 3 of 17”“showing 20 of 400”。把你的行数与它比较。

数量偏短是截断或提前停止，而这正是采集类任务最常见的失败。一种成因是读取被截断且当场自报：在长页面上实测，默认文本读取返回了 35,490 字符中的 6,000 字符，并在返回内容的最后一行明确声明了这一点（详见 text, HTML, snapshot or screenshot）。另一种是静默的短计数——通常意味着遍历提前停止，而不是页面内容真的少。

这一校验正是仓库实战文章里反复使用的“目击者”逻辑：在 Extracting a category to CSV 的完整运行中，提示词要求“Tell me how many you got and check it against the count the page itself reports”，类别页头声明32 results，两次提取合计 20 + 12 = 32。文中特别指出“选择器静默匹配不到任何东西，会产生一份看起来已经完成、实则残缺的短文件，页面自己的计数是唯一的见证者”。

2. 检查最后一行，而不是随机一行

抽查中间行是人的本能，却是错误的本能。截断、超时与提前停止都只啃尾部，因此最后一行才是损伤所在，而第一行永远是对的。

打开最后一行的 URL 手动比对。三十秒，却能抓到“中间随机抽五行”永远抓不到的那类失败。

3. 用机械手段检查数据形状

每一行有相同数量的字段；每个数字都能被解析为数字；每个日期都落在合理范围内；没有哪个单元格在应该放数值的地方放了一整句话。

这道校验抓到的是列漂移：第一页产出两列，第四页的标题里出现一个逗号于是产出三列，之后每一行都整体错位。任何会在导入时标记参差不齐行的电子表格工具，都能免费帮你做这件事。

4. 统计空值，并逐一阅读它们

有多少行有原始值却没有归一化值，有多少行的 outcome 不是 “done”。

这个数字决定了数据集是否真的回答了你的问题：40 行里有 2 行尴尬是可注明的瑕疵；15 行则意味着“你正在比较的东西根本不可比较”——这本身是一个发现而不是缺陷，而且只有在 Agent 被允许把单元格留空时，这个发现才可见。允许留空的指令应当写在任务里，其完整方法见 Normalising values across sites——原文明确给出了那句必须写进每个列表任务的话：写出原始字符串并把归一化单元格留空，而不是推断一个值，否则这些尴尬行就会被隐藏在一片好数据之中，既看不见也无法计数。

5. 重跑一个切片，而不是全部

取五行重跑一遍。两次运行不一致，证明其中一次是错的——这本身值得知道。

但一致证明的东西比看上去少得多。同一个模型在同一页面上跑两次，共享同一套盲区：如果它第一次读错了一个标签，第二次通常以同样的方式读错。两次一致只能排除随机抖动，对系统性误读则什么也说明不了。要发现系统性误读，唯一的方法是让人把一行与页面逐项比对——也就是把第 2 道校验从“抽查”升级为“刻意执行”。

五道校验全部抓不到的东西

正确抽取了错误的对象。比如 Agent 在全部 40 个站点上把“订阅价”而不是“一次性价格”准确读了出来。此时上面每道校验都通过：数量正确、形状正确、数值可解析、重跑一致。

只有人把一页与一行放在一起看，才能发现这类错误。值得在采集开始时做一次，而不是结束时：先单独跑第一行、与页面比对，再发布整个列表——这与 one form submission per spreadsheet row 是同一个纪律。它也是仓库中“Web research, audited”一文结论的另一种表述：一个小样本上通过的审计，是你赢得信任更大样本的资格；而不匹配的审计，是让你花沙箱运行的成本而不是错误决策的成本去发现问题。

把校验构建进任务本身

五道校验中有两道可以是 Agent 自己的工作，而且恰好是它最可靠的两道——因为它们是算术而不是判断：

完成后，说明你写入了多少行、页面声明的总数是多少、你留空了多少行以及为什么。如果这两个数字不一致，先说出这一点。

这只需要一句话，却把“这是你的文件”变成“这是带声明覆盖范围的文件”。剩下三道必须由人来做，因为它们需要与 Agent 看不到的东西比对。

与日志和去重的关系

这五道校验的输入来自 Agent 运行的日志。仓库 wiki 的 what an agent run should log 给出了八字段清单：UTC 时间戳、最终 URL（重定向之后而非你请求的那个）、原始值、归一化值、读取还是推断、出口国家、身份种子、以及 outcome——其中 outcome 至少需要done、not found、blocked、error、needs a person五类取值，因为 “not found” 是答案而 “error” 是没有答案，二者需要不同的响应。只有当这八字段被如实记录，第 1、2、4 道校验才有东西可读。另外，行数只有在去重之后才有意义，所以计数校验应放在 deduplicating what an AI agent collects 之后。

关于截断警告，一个源码级的细节

第 1 道校验背后有一个重要的实现细节：截断必须可见。在 mcp/actions.py 的read_text实现中，源码注释明确记录了这段历史：这个截断曾经是静默的，而静默截断是灾难性的——“调用者读到一句中断的散文，却无法把它与真正到此为止的页面区分开，于是自然的下一个动作（依据返回内容作答）就是依据碎片作答，却以为那是全部”。现在的实现是：DEFAULT_MAX_CHARS = 6000（见 actions.py），超限时返回txt[:max_chars]并追加一行可见声明[cut after 6000 of 35490 characters. Raise max_chars, or narrow the selector to the part you need.]。这就是 what-should-the-agent-read 中引用的原文。因此，当读取结果偏短时，先分清是“页面本来就短”还是“读取被截断且已声明”——一个短答案来自长页面，不是页面变短了。

短问答速查

怎么检查 AI Agent 的抽取结果？用页面声明的总数对数量、打开最后一行、机械检查形状、统计空值、重跑一个切片。

为什么是最后一行而不是随机一行？因为截断和提前停止只啃尾部。第一行永远是对的。

两次一致能证明正确吗？不能。它只能排除随机抖动。系统性误读会一模一样地重复，所以一致性不构成反对它的证据。

这些校验漏掉什么？每一行都正确读取了错误的元素。只有手工把一行与页面比对才能发现。

Agent 能检查自己的工作吗？算数部分可以：行数对页面声明总数、留空计数。把两者都写进任务提示词即可。

延伸阅读

• what an agent run should log：本页校验所读取的日志字段清单
• deduplicating what an AI agent collects：行数只有在去重后才有意义
• Normalising values across sites：“原始值 vs 归一化值”两列规则，以及第 4 道校验依赖的留空指令
• text, HTML, snapshot or screenshot：第 1 道校验引用的截断实测数据
• Web research, audited：仓库内一次“Agent 计数 vs 无模型脚本计数”的完整对照审计，含可复现的提示词与 ground_truth.py
• Extracting a category to CSV：一次完整采集运行，页头32 results与 20 + 12 行提取的对账是第 1 道校验的现场示范

第 1 到第 3 道校验加起来只需一分钟。第 5 道是大家最先想到的，也是证明力最弱的一道。

• 人工智能
• AI Agent
• 浏览器控制
• GUI 自动化
• MCP 服务