企业官网建设流程全解析

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

"Autonomous"（自主）经常被当作一个二值属性来用——某个工具要么是自主的、要么不是。实际上，自主性是一条光谱：产品本身没有"自主"这回事，只有"你的具体任务落在哪一级自主性上"。本文以开源仓库 invisible_playwright_mcp 为观察样本，拆解四级自治阶梯（建议、监督、受限无人值守、开放式无人值守），说明为什么第三级到第四级之间是失望最集中的地带，并给出判断你的任务该落在哪一级的实用测试方法。读完你会知道：什么情况下值得让一个浏览器代理无人值守地跑下去，什么情况下它只是另一种形式的账单；以及 invisible_playwright_mcp 的界面、工具注解、超时上限和密钥隔离等实现细节，分别对应自主性阶梯上的哪一级。

自主性是一条光谱，不是一项特性

"自主浏览器代理"的定义本身很简单：一个程序自行决定下一步的浏览器动作，以朝向某个目标。但它有多少决策是在没有你的情况下做出的，这就是本文要讲的频谱。

几乎每个产品都自称"自主"，而真实的差别在于任务边界。对于一个具体的任务，任何产品都落在四个等级之一上：

第一级：建议（suggested）。代理提出动作，你逐个批准。慢，但这是唯一一个"犯错不会让你付出任何代价"的设置——每一步都在你的眼皮底下、在你的控制之下发生。

第二级：监督（supervised）。代理自己运行，你在旁边看，随时可以叫停。这是大多数实际工作真正发生的等级，也是大多数人应该开始的等级。

第三级：无人值守、有界（unattended, bounded）。代理在你不在场时运行，任务有明确终点状态，配了预算和超时。没人看着，但它跑不远——因为边界是预先划死的。

第四级：无人值守、开放式（unattended, open-ended）。"盯着这几个网站，有什么有趣的事情就告诉我。"没有定义好的终点。这才是"自主"这个词暗示的东西，也是下面列出的失败模式不再只是假设、而是必然发生的等级。

所以有用的提问从来不是"这个工具是不是自主的"，而是"我的任务属于哪一级"。对大多数任务而言，诚实的答案往往是第二级或第三级。

从 invisible_playwright_mcp 的源码结构看，这个判断也体现在产品设计上：它的官方界面uvx invisible-playwright-mcp ui是一个"左边聊天、右边实时浏览器画面"的本地 Web 应用（见 cli.py 与 routes.py 中的路由表），从 0.3.0 起就刻意不做无头模式——它是给"看着它干活的人"用的聊天窗口，而不是给 cron 用的后台任务。这正是第二级"监督"的产品化形态：代理运行，人看着，人可以按停止。

第二级以上，什么东西会坏掉

1. 没人知道何时停止

没有终点状态的任务不会结束。没人管的话，代理会一直浏览下去，也一直计费下去。回合预算（turn budget）和墙钟超时（wall-clock timeout）在第三级不是可选项，而是让第三级区别于一场事故的东西。

这一点在 invisible_playwright_mcp 的代理循环实现里可以得到精确印证。查看 agent.py 中的Conversation.run，当前源码明确写着"没有回合上限"（No turn ceiling）：曾经有一个max_turns=25的上限，实际效果是把"进行得很顺利的长任务"在最后一步前掐掉——一个你已经看着它工作了二十五步的任务，在可能就要回答的前一步被丢弃，而每一步都已经付过费。一个数字无法区分"卡住的循环"和"只是比较长的任务"，猜错了就搭上整个运行。

那这个循环现在靠什么停下来？两个机制，都在代理之外：

• 界面停止按钮。routes.py中的/chat/stop路由对应界面的停止按钮，工作期间发送按钮变成停止按钮；取消落在下一个工具调用处（asyncio.to_thread是取消点）。它针对的是"这一次具体的运行"做的判断，而不是预先选好的常量——它甚至能在第三回合就停掉一个运行。
• 单次回复的 token 上限。Conversation.MAX_TOKENS = 8192，设定在客户端而不是交给提供商默认值：一次回合是"一句推理加一个工具调用"，不是一篇论文，只有最后一回合才需要空间。这是单回合的软边界，不是整个运行的边界。

这个设计恰恰论证了原文的结论：内部回合上限会在错误的时间切掉正确的运行，而真正能兜住"跑偏"的停止条件必须写在任务里、由外部机制强制执行。对第三级无人值守而言，预算和超时只能来自任务描述和调度器那一边，不能指望代理自己数。

2. 错误静默累积

在第二级，你看到错误的点击，当场叫停。无人值守时，错误的点击会成为下一个决策所基于的状态——到第二十步，代理已经信心十足地跑到了一个毫不相干的地方。缓解办法是在步骤之间检查页面是否还是预期的那种页面，不是就停。

invisible_playwright_mcp 给这个问题的证据是：每个工具调用都有天花板，但天花板约束不了整个运行。查看 actions.py：

关键事实有两点。第一，这 15 秒不是"等一次然后失败"——点击会反复重新解析元素、反复检查它是否可操作，直到成功或预算耗尽。该模块注释记录了两组实测：一个在 iframe 内、选择器够不到的元素，"not actionable in 15s after 275 attempts"；一个被报告为可见却点不到的 skip-to-content 链接，同一 15 秒内 208 次尝试。也就是说一次失败调用内部已经重试了数百次。

第二，整个运行没有上限。一个任务可以朝错误方向做一百次成功调用，循环里没有任何东西会拦它：每次调用都快、都成功，任何天花板都永远碰不到。这正是为什么上面的每调用数字只是调试工具而不是安全机制——你真正需要的边界要写进任务里，因为逐调用的超时约束不了一个"正稳步朝错误方向前进"的运行。

3. 权限成为风险

无人值守的代理如果带着已登录会话，就能用你的凭证行事；而页面可以在你下发指令的同一个通道向代理下达指令——这就是提示注入（prompt injection）。"无人值守"加"已登录"这个组合，恰好把提示注入从"一个错误答案"升级成"一个动作"。相关讨论见 让代理登录网站 与 该不该让代理登录账号。

invisible_playwright_mcp 在源码层面对待这个问题的态度，可以从两个地方看到：

• 密钥隔离。runner.py 的职责是"浏览器服务器如何启动、子进程被允许知道什么"。child_env从引擎启动的环境中移除 OpenRouter 模型密钥——按变量名、也按值（防止OPENAI_API_KEY里藏着同一个 OpenRouter key），而且启动后forget_key还会把活进程环境里被.env重新读回来的密钥再剥掉一次。原因写得很直白："让秘密不出现在进程里，最便宜的办法就是根本不把它交出去。"浏览器驱动进程没有模型密钥的用场，无论谁启动它。
• 只读/破坏性注解。server.py 的_says给每个工具声明readOnlyHint和destructiveHint：任何会输入、点击、导航或关闭浏览器的工具都被标为 destructive，客户端据此在无人值守时确认动作；而读类工具标为 read-only，客户端可以放心地自动跑。注释里还记录了一个教训：曾经有五个工具声称 read-only 却走的是"唤醒漏斗"，会真的拉起一个 Firefox——"一个能生出浏览器的工具已经改变了环境，客户端信任它去无人值守运行"正是这类风险的具体形态。

三问测试：你的任务属于第四级吗

如果任务属于第四级（无人值守、开放式），必须能回答三个问题。任何一个答案是"否"，它就属于更低一级。

问题一：你能用一句话写出停止条件吗？写不出，代理也写不出，它就不会停。关于怎么写，给 AI 浏览器代理一个停止条件 给出了四种停止条件的完整分类——产物（artifact，外部可检查的命名结果）、状态（页面说出某个信息）、预算（N 页/N 分钟/N 次尝试）、提问（停下来问你）——并且指出：模型能自查前两种（都是它能观察到的），后两种它无法可靠地自我执行，"计数预算的是花预算的人，这是软上限"。正确组合几乎总是产物加预算：完成长什么样，加上你愿意花多少去找出答案。该文还强调一个常被省略的配套部分：逃生舱口——当停止条件无法满足时记录"不可用，原因是……"的指令，否则"拿到价格就停"这种任务在价格真的不存在的那一刻就变成无界任务。

问题二：如果它做错四十次，代价是什么？钱、账号被封、或者一串发生在真实网站上的真实动作。如果答案比"浪费了 token"更糟，就留在第二级，或者把账号拿走。

问题三：脚本能完成吗？如果步骤每次一样，脚本更快、更便宜、确定性更强，而且不会跑偏。Playwright MCP 与 CLI 的分界 讨论了这个拆分，用浏览器 MCP 服务器做网页抓取 则把它应用到大体量场景——那里的答案几乎总是脚本。抓取那篇文档的三阶段模式是这个问题最完整的答案：第一阶段用模型（找出列表、分页、字段和详情页形态，报告它用的选择器，大约二十回合，替代 devtools 里的半小时）；第二阶段不用模型（把选择器写成普通代码跑一万页，确定、快、免费、可测试）；第三阶段只在失败时回到模型（脚本返回空字段就是页面变了的信号，重新打开会话问页面现在长什么样）。代价的底数是可测的：该文档记录这个服务器的 16 个工具定义每回合要重发 3,141 token（8,040 字符描述加参数 schema，2026-09-13 计得），每页乘以回合数，第二阶段就不再是风格偏好而是必需。模型只有在下一步事先不可知、且走错一步很便宜时才值回票价。

真正想要第四级的任务是：下一步无法预先知道并且走错一步很便宜。这个集合比营销暗示的要窄得多。认清自己在线的哪一边，比任何工具选择都值钱。

工具实际能给你什么

大多数代理库和 MCP 服务器默认是第二级，允许你搭出第三级：browser-use、Skyvern、Stagehand，以及包括 invisible_playwright_mcp 在内的 MCP 服务器，都是这样。第三级是你自己加上预算、超时和状态检查的地方——这个工作在它们每一个里面都是你的活，不是工具的出厂配置。

invisible_playwright_mcp 的几个实现细节可以帮你看清"工具给了什么、没给什么"：

• 每调用超时是工具给的。上面的 45 s / 15 s 表格来自 actions.py 的goto、click、fill、select_option调用。它是调试工具：一次调用花满 15 秒，通常意味着元素在 iframe 里、被遮罩盖住、根本没渲染、选择器写错，或者是个"报告可见却点不到"的元素；导航花满 45 秒，通常是站点没完成你要求它等待的东西。但它不是安全机制——how-long-before-the-agent-gives-up那篇文档的结论和本页一致：一个运行没有上限，你要的硬边界得自己写进任务。
• 成本数字帮你在第二、三级之间做预算。how-long-an-ai-agent-takes-per-step 的实测（2026-09-17，针对127.0.0.1的真实页面）：browser_type约每秒固定成本 1 秒加每字符约 270 ms——12 字符中位 3.93 秒、43 字符 12.63 秒；browser_open一次性约 4.82 秒；读取类动作（text/HTML/snapshot/evaluate）都是一到两个百分之一秒，基本免费。这引出两条规划规则：预算任务要数输入的字符数，而不是字段数；以及多看一眼几乎免费——看的行为不贵，贵的是结果进模型上下文之后占的 token。
• 无头与调度的缺口是设计出来的。run-ai-agent-on-a-schedule 明确：这个界面从 0.3.0 起只有ui一个子命令，一个只在 Ctrl-C 或 kill 信号下停止的常驻服务器，没有--once、没有 run-and-exit。要无人值守跑，只有两条路：一是走已经接好 MCP 的助手 CLI 的非交互模式（每条 crontab 行仍在花模型 token，因为模型仍在做决策）；二是用 invisible_playwright 库写固定步骤、完全不经过模型（seed固定浏览器身份让周期性检查看起来像同一个回访者，profile_dir跨运行保留 cookie 和登录，没有密钥、没有模型、没有账单）。决策规则一句话：每一步都做同一件事的任务，为它每次付模型费买不到任何东西；只有每次运行都需要新判断时，模型才挣到它的位置。至于无人值守时代理卡住了怎么办——调度那篇文档的建议是把失败弄"响"：非零退出码、重定向到带日期的日志文件、指向你本来就会看的地方，而不是发明一个没人打开的新检查点。
• 没人看守时的拦截风险是分开算的。why-does-my-ai-agent-get-blocked 给出四层独立模型：浏览器指纹、IP 声誉、请求量、行为节奏。代理框架只能修第一层（invisible_playwright_mcp 的引擎是一个在 C++ 层打过补丁的真实 Firefox，指纹一致、动作走真实指针和键盘），IP 靠你买、量靠你的 prompt 决定、节奏由循环和驱动方式共同产生。无人值守通常意味着更快、更规律——速度和规律性恰恰是被评判的对象，所以无人值守的代理被拦的概率更高，这正是文章里那个问题的答案。

消费级 agentic 浏览器在设计中更接近第二级，因为它们就在你面前运行，见 什么是 agentic 浏览器。

这个列表上没有哪样东西让第四级变得安全。它让第四级变得可能——这是两个完全不同的主张。

常见问题简答

什么是自主浏览器代理？一个自行决定下一步浏览器动作以朝向目标的程序。其中有多少决策在没有你的情况下做出，就是上面那条光谱。

能让它跑一晚上吗？有预算、有超时、有定义好的终点状态、并且没有它可以花掉的凭证——可以。否则你就是在赌博。

自主代理可靠吗？在第二级，有用。在第四级，复合型失败是真实且不可避免的，因为没人能在第三步接住错误。

自主代理和 AI 浏览器是一回事吗？不是。AI 浏览器与 AI 浏览器代理 把两者分开：前者是浏览器本身带着模型能力，后者是模型通过工具驱动浏览器。

无人值守跑会被拦截吗？更可能。无人值守通常意味着更快、更规律，而速率和节奏正是被评判的东西。排查顺序按四层模型来：同一任务同一网络先用手动浏览器试；首个页面加载就被拦（什么都还没做）则嫌疑是指纹或 IP；很多页之后或重试时被拦，去数自己的请求量、读转录里的重试风暴；会话中途、已有页面动作之后被拦，才轮到看节奏。每层之间换一个变量，否则你永远不会知道哪个改动起了作用。

相关阅读：定时运行代理、为浏览器代理编写任务、如何选择 AI 浏览器代理，以及 理解 AI 浏览器代理。

本文依据

本文的论证骨架来自原文档对自主性阶梯的分析；所有实现层面的证据均取自当前仓库的源码与配套文档：

• agent.py：代理循环、无回合上限的设计取舍、MAX_TOKENS = 8192、停止按钮的取消点；
• actions.py：goto/click/fill/select_option的 45 s / 15 s 超时、点击内部重试循环及 275/208 次尝试的实测记录；
• server.py：工具注解readOnlyHint/destructiveHint及其历史教训；
• runner.py：子进程环境的模型密钥剥离；
• cli.py 与 routes.py：ui唯一子命令、/chat/stop停止路由；
• 配套文档：给 AI 浏览器代理一个停止条件、代理放弃前要等多久、AI 浏览器代理每步耗时实测、定时运行 AI 浏览器代理、为什么 AI 代理会被拦截、用浏览器 MCP 服务器做网页抓取。

结论不变，也值得重复：大多数任务属于比宣传低两级的位置。认清这一点，比任何工具选择都值钱——因为认清之后，你会把时间花在写停止条件、划预算、做状态检查上，而不是花在寻找一个"真正自主"的工具上。

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