假设你负责一套已经运行多年的商城、CRM 或企业管理后台。页面能用，员工也熟悉操作流程。现在希望增加一个 AI 助手，让它根据一句话查询订单、补充跟进记录，或者整理一批待处理事项。
一种做法是让 AI 打开浏览器，像员工一样搜索、点击、填表。
另一种做法是把业务动作整理成接口，让 Agent 根据明确的对象和参数发起调用。
于是出现一个很现实的问题：既然 AI 能操作现成页面，为什么还要花时间接 API？
反过来，也有人会问：有了 API 和 MCP，是不是就应该完全放弃浏览器自动化？
这篇文章用同一项业务任务比较两条执行路径。重点是它们分别需要哪些条件、怎样维护，以及出错以后怎样继续。
一、同一条订单跟进任务，可以走两条路
先把目标说具体：
查询指定测试订单的当前状态，确认仍需跟进后，追加一条内部跟进记录。
这里是用于说明架构的假设场景，不是某个客户案例，也不对应一条已经交付的通用接口。所谓“内部”，还需要由业务系统确认：这项动作是否会通知客户、改变订单状态或触发其他流程。
浏览器路径可能是：
进入业务后台
→ 确认当前账号与门店
→ 搜索指定订单
→ 打开订单详情
→ 填写内部跟进记录
→ 提交并重新查看记录
业务接口路径可能是：
取得可信业务身份
→ 按订单标识查询当前状态
→ 调用“追加内部跟进记录”动作
→ 取得记录标识或任务标识
→ 查询最终结果
前一条复用页面交互，后一条依赖明确的业务动作契约。两条路最终都要回到同一事实：正确账号是否对正确订单完成了被允许的修改。
浏览器页面背后通常也会调用服务端接口。这里比较的是 Agent 直接依赖什么：页面交互，还是向集成方提供的业务接口。并不是在讨论系统底层有没有 HTTP 请求。
二、先澄清：MCP 也可以承载浏览器工具
MCP（Model Context Protocol，模型上下文协议）描述工具如何被发现和调用，并不规定工具底层必须是一条业务 API。
Microsoft 的 Playwright MCP 就通过 MCP 提供浏览器自动化能力，允许模型借助结构化的可访问性快照与网页交互。这说明“接了 MCP”和“使用浏览器自动化”可以同时成立。Playwright MCP 官方说明
可以这样区分：
| 维度 | 要回答的问题 | 示例 |
|---|---|---|
| 接入协议 | Agent 怎样发现、描述和调用工具？ | MCP |
| 工具粒度 | Agent 拿到的是页面动作，还是业务动作？ | 点击按钮、填写字段；查询订单、追加跟进记录 |
| 执行方式 | 工具最终怎样操作系统？ | 浏览器交互、业务 API、经过评估的适配器 |
因此，看到一个 MCP Server 时，还要继续看它暴露了什么。click_button 与 append_order_followup 都可以成为工具名，但它们把不同层次的判断交给了 Agent。
MCP 的工具定义可以描述输入与输出结构；规范也提醒，工具注解只有来自可信服务端时才可被信任。结构化描述有助于接入，具体业务权限仍需由实现执行。MCP Tools 规范
三、浏览器自动化适合复用哪些现成条件？
如果团队只有后台使用权，无法修改服务端，也没有适用的开放接口，页面可能就是当前能够获得的执行入口。
尤其是有人在场、次数有限、需要结合页面上下文判断的任务，可以先评估浏览器路径。例如，在一个没有导出接口的旧系统中，按现有权限整理页面上已经可见的信息。
浏览器自动化也不只有“识别截图，再点坐标”一种方式。页面元素、文本、标签和可访问性属性都可以用于定位。Playwright 推荐优先使用面向用户的属性或明确约定，而不是依赖很长的 DOM 层级选择器；Power Automate 也提供基于网页元素的浏览器操作。Playwright Locators · Power Automate 网页自动化
这些能力让现有页面可以被更有结构地操作。不过，项目仍需有人维护页面与自动化之间的约定：
- 同一页面有几个“保存”按钮，怎样确定当前操作对象？
- 当前筛选的是哪家门店、哪个时间范围？
- 登录过期、弹窗出现或表单流程变化时，应该停在哪里？
- 最终结果能否重新打开并核对？
复用现成页面可以减少新增接口的工作，但页面自动化本身仍需要维护。
如果任务只需偶尔执行，且人工介入成本可接受，这种取舍可能合理。是否合理，应由实际任务决定，而不是先给浏览器自动化贴上“临时方案”或“不可靠”的标签。
四、业务 API 值得投入的地方，是稳定的业务动作
如果团队掌握服务端、动作会频繁执行，或者同一能力要被网页助手、工作流和多个 Agent 复用，就值得评估业务接口路径。
一个语义明确的动作可以表达为：
追加订单跟进记录
业务输入：订单标识、跟进内容
可信上下文：当前业务主体及其组织范围
执行约束：订单仍允许跟进，当前主体具有相应权限
结果：新记录标识，或可查询的任务标识
这是一份说明性结构，不是 BailingHub 的真实请求格式。业务主体不能因为模型填了一个员工编号就自动成立；它应来自业务系统信任的授权链路。
这种接口把“操作哪个页面元素”的问题，转化为“执行哪一项业务动作”。只要接口契约保持兼容，页面布局调整就不必同步改变调用流程。
但收益需要接口实现来支撑。一个只接收任意字段、用管理员身份执行、失败后没有查询入口的通用修改接口，仍然会给 Agent 带来很大不确定性。
工程上需要确认的，是接口有没有明确的对象标识、权限检查、状态检查和结果语义。重试安全、幂等与审计也需要具体实现，不能因为用了 API 就自动记为完成。
值得开放给 Agent 的，是团队愿意长期维护的业务动作；接口数量本身不是目标。
五、选型时，把“提交后没有返回”也走一遍
两条路径最容易被演示掩盖的地方，是结果不确定时怎样处理。
仍然使用追加跟进记录的例子。
浏览器点击提交后，页面一直转圈。跟进记录可能已经保存，只是页面没有收到响应。这时重新点击，可能创建第二条记录。
API 请求超时，也可能发生同样的问题：服务端已经提交，调用方却没有取得返回值。换成接口并不会消除这类情况。
处理方式应当由真实执行状态决定：
- 如果有记录标识、任务标识或业务提供的查询凭据，先查询结果。
- 如果业务接口提供了可靠的幂等契约，按同一操作身份处理重试。
- 如果无法确认是否已经发生写入，保留不确定状态并交给人工核对，不自动重复提交。
浏览器“能点击”本身也不是完成证明。以 Playwright 为例，自动等待会检查元素可见、稳定、能够接收事件等交互条件；这些检查并不等于后台业务已经完成。Playwright Auto-waiting
同样，HTTP 200、工具返回成功或一句“已经处理好了”，都需要结合接口契约和业务最终状态解释。
评估一条自动化路径时，要同时观察它如何成功，以及结果不确定时如何停下来、查明状态和恢复。
六、一张表，先判断适合从哪里开始
以下是基于上述条件的工程判断框架，不是对任何工具做出的成功率或性能排名。
| 你的条件 | 可以优先评估的路径 | 决定前需要确认 |
|---|---|---|
| 只有后台使用权，没有适用 API | 浏览器自动化 | 自动化使用范围、登录上下文、对象定位与人工接管 |
| 任务低频，有人在场，强依赖页面上下文 | 浏览器自动化 | 页面结果可核验，交互失败时能够停止 |
| 掌握服务端，动作会被多个入口反复使用 | 业务 API，按需通过 MCP 等方式接入 | 动作语义、可信身份、权限与接口维护责任 |
| 接口只覆盖一部分流程 | 按动作拆分的混合路径 | 每一步由谁执行、怎样传递对象标识、如何防止重复写入 |
| 涉及资金、库存或大范围状态变更 | 先确定业务控制与恢复要求，再选路径 | 审批、限额、业务状态重验、核账和人工处理 |
任务频率不是唯一标准。一次低频操作也可能有很高后果；一个高频只读任务也仍需保护业务数据范围。
因此，不能只按“有没有 API”做决定，还要把动作后果、维护能力和结果可观察性一起放进来。
七、混合路径可以成立，但不要做越权的自动降级
实际系统可以同时使用两种方式。
例如，人通过浏览器完成业务登录与授权，Agent 使用受约束的接口执行动作，最后再打开业务后台核对结果。这里的浏览器登录承担身份建立，和自动点击后台按钮是两件不同的事。
另一个例子是：部分旧模块只有页面入口，团队暂时保留受限的界面操作；已经有明确接口的模块，则使用业务 API。每一段都保留自己的执行与结果证据。
混合方案需要注意一个边界：API 因权限或策略拒绝操作后，不应自动改用权限更大的浏览器会话绕过拒绝。
接口结果不确定时，也不应马上改走页面再提交一次。切换执行路径之前，必须先弄清上一条路径是否已经造成业务变化。
即便是同一个人发起任务，浏览器会话与 API 凭据也可能对应不同的账号、门店或授权范围。对象标识相同，不等于身份和权限已经对齐。
八、第一轮验证，只比较同一条真实任务
准备接入时，可以先写一张简短任务卡：
业务系统：你能够授权使用的测试环境
业务对象：一条专用测试记录
查询目标：确认这条记录的当前状态
写入目标：只改变哪一项内容，会触发哪些后续动作
完成证据：在哪里查询最终结果，怎样对应到本次操作
恢复方式：恢复、撤销、补偿或人工处理由谁负责
再根据系统现有条件选择一条路径试跑。如果两条路径都可用，而且确实需要比较，就使用相同的数据和验收目标。
记录时，优先看几件具体事情：有没有认错对象，是否需要额外人工介入，完成后能否核对业务结果，登录或权限变化后是否停止，以及提交结果不确定时会不会重复写入。
这些事实足以支持第一轮选择。耗时、成本和成功率，也应从真实运行记录中计算，不预先承诺“几分钟接完”或某种方案一定更省钱。
九、BailingHub 和 ACC 在这张图里处于什么位置？
BailingHub 是开源业务动作治理控制面，针对已经接入的业务工具提供能力范围、可信主体、审批、执行与审计治理，最终业务授权仍由原系统完成。其公开路径需要部署者接入工具、配置权限并建立业务授权流程；安装本身不能自动打通任意后台。BailingHub v0.5.1 · Agent Client 接入指南
本文讨论的通用浏览器操作，不应被理解为 BailingHub 已经交付的任意网页点击能力；MCP 适配器也是独立接入项目。
Agent Capability Contract（ACC，Agent 能力契约）则是实现中立的能力治理契约，用于描述能力与执行约束。它不替企业选择浏览器驱动，不替代业务权限系统，也不等同于 BailingHub 产品。ACC 官网
如果你的团队已有可用业务 API，可以选择一条动作，提交“业务系统 + 一条动作 + 脱敏接口”的接入评估；提交 GitHub Issue 需要登录，不要附带账号、密钥、私有地址或客户数据。
如果还在理解工具调用、治理与业务结果怎样连起来，可以从公开 Docker Demo入手。它用于验证示例链路，不是任意后台的现成适配器，也不代表生产接入或外部采用。
对已有业务系统来说，第一步可以很小：选定一个对象、一个动作和一组完成证据。让执行路径服务于这项工作，再用真实结果决定下一步投入。
参考资料与事实边界
- 外部资料核对日期：2026-09-08。浏览器能力与 MCP 说明依据上文链接的官方文档，未使用厂商性能对比或虚构客户数据。
- 订单跟进流程、动作名与任务卡均为架构说明示例，不是已交付 API、维护者实测报告或生产案例。
- BailingHub 产品事实固定引用
v0.5.1；ACC 与独立生态适配器分别处理。本文未将浏览器自动化或任何规划功能登记为 Core 新能力。 - 本文承接 BH-ZH-042 的技术分层选型，聚焦“页面交互与业务接口”的执行路径；不重复上一文的 RAG / OpenAPI / MCP / 工作流总览。
