8.0
热点
AI SCORE
技术实践2026-08-21 13:10
无API遗留Web应用的AI浏览器自动化方案
dev.to · AI#AWS#自动化#遗留系统
Editor brief · 编辑速览
AWS Bedrock AgentCore Browser Tool可让AI Agent操控无接口的旧系统界面，结合Strands Agents实现工作流自动化。
最难自动化的业务流程，往往不是技术上有多少门道，而是被困在那些从设计之初就没打算和任何外部系统对接的软件里。
一个团队可能依赖一个十五年前的内部门户。员工登录、打开几个页面、搜索记录、更新字段、提交表单，每天重复同样的步骤几十遍。这个应用可能对业务至关重要，却完全不暴露任何可用的 API。
传统的解决方案都让人不太舒服：重建整个系统、为它套上一层脆弱的 UI 自动化，或者继续让人力去做那些重复的浏览器操作。
而具备浏览器操控能力的 AI Agent 开辟了另一种可能——它们可以直接 navigating 界面本身，解读页面内容，与表单交互，并在关键操作前停下来等待人工确认。
2026 年 8 月 13 日，AWS 发布了一份参考架构，演示的正是 Amazon Bedrock AgentCore Browser Tool 与 Strands Agents 的组合方案。其中的经验总结比 AWS 本身更有普适性：API 缺失不再意味着业务流程无法自动化，但浏览器自动化需要比普通 API 对接更强的边界控制。
本文就来逐一讲解这些边界。
不要一上来就提这样的需求：
自动化我们的旧门户。
从一个能清楚描述的业务流程开始。例如：
找到客户保单，更新邮寄地址，验证新值是否正确，如果有任何不确定的地方则在最终提交前停下。
这样才给 Agent 一个有边界的任务。
一个简单的任务定义大概长这样：
type BrowserTask = {
goal: string;
startingUrl: string;
expectedSteps: string[];
criticalActions: string[];
requiredEvidence: string[];
};
const task: BrowserTask = {
goal: "Update the customer mailing address",
startingUrl: "https://legacy.example.com/policies",
expectedSteps: [
"Search customer",
"Open policy",
"Edit mailing address",
"Review changes"
],
criticalActions: [
"Submit final change"
],
requiredEvidence: [
"Customer identity",
"Original address",
"Updated address"
]
};
这比直接给 Agent 一个浏览器让它"处理保单变更"要好控制得多。
AI 浏览器 Agent 是在操作一个真实的应用程序。它可能看到客户数据、认证状态、内部记录或敏感表单。
这个浏览器不应该简单地和你的其他应用跑在同一个环境里。
更安全的模式是：
Task starts
↓
Fresh browser session
↓
Task-specific authentication
↓
Agent operates the legacy app
↓
Evidence and result stored
↓
Session ends
AWS AgentCore Browser Tool 使用隔离的托管浏览器会话。AWS 文档还支持将会话录制到 S3 存储桶供后续审查，并使用 IAM execution roles 来控制浏览器环境可以访问哪些 AWS 资源。
不同平台上具体实现会有差异，但原则是一样的：把浏览器执行视为一个独立的运行时，而不是你主应用的无形延伸。
一个实用的浏览器 Agent 反复执行三个工作：
这个循环可以简单表示为：
Observe page
↓
Interpret state
↓
Choose next action
↓
Execute
↓
Observe again
对于传统的自动化脚本，观察步骤可能几乎完全依赖选择器（selector）。
对于 AI 辅助的工作流，页面结构、截图、可见文本和应用状态都可以帮助系统理解当前发生了什么。
AWS 的参考实现使用具备视觉理解能力的基础模型来检查浏览器截图，确定下一步操作，通过 Playwright 执行，然后重复这个循环直到任务完成或需要人工确认。
这种方式对于那些难以通过简洁的 API 契约来建模的旧系统界面尤其有用。
即使模型决定了下一步该做什么，实际的浏览器操作应该保持狭窄且可审查的。
工具层大概会暴露以下操作：
type BrowserAction =
| { type: "navigate"; url: string }
| { type: "click"; target: string }
| { type: "type"; target: string; value: string }
| { type: "select"; target: string; value: string }
| { type: "read"; target: string }
| { type: "screenshot" };
模型从已知操作中选择，而不是获得对环境的无限制控制权。
这样既给工作流提供了更清晰的审计追踪，也让失败的运行更容易理解。
这个边界比浏览器 Agent 有多聪明重要得多。
想象 Agent 成功找到了客户记录，打开了正确的表单，输入了新地址，来到了最终的提交按钮。
在那个时刻，以下两种方式有巨大差别：
Agent clicks Submit
Agent prepares the change
↓
Operator sees the current screen
↓
Operator confirms
↓
Agent submits
AWS 在 2026 年 8 月 13 日的参考实现遵循的是第二种模式。当模型到达关键步骤（如提交表单或确认记录选择）时，它可以暂停并向操作员展示当前的截图，然后继续。
这样在重复步骤上获得了自动化的速度，同时在后果变得不可逆转的边界处保留了人工判断。
一个简单的应用层 guard 大概是：
async function executeAction(
action: BrowserAction,
context: TaskContext
) {
if (context.criticalActions.includes(action.type)) {
const approved = await requestHumanApproval({
action,
screenshot: await browser.captureScreenshot()
});
if (!approved) {
return {
status: "paused",
reason: "Human approval declined"
};
}
}
return browser.execute(action);
}
具体机制会有差异，但架构边界不应该变。
当你唯一知道的信息只是"Agent 说它完成了任务"，浏览器自动化就很难让人信任了。
一个生产级工作流应该留下足够的证据来解释发生了什么：
一个简单的事件大概长这样：
type BrowserAuditEvent = {
taskId: string;
sessionId: string;
timestamp: string;
action: string;
pageUrl: string;
screenshotRef?: string;
humanApproved?: boolean;
};
AWS 的参考实现将会话记录和截图存储在 Amazon S3 中，并使用 CloudWatch 进行审计日志和可观测性。AgentCore Browser 也支持会话录制和回放。
当用户第一次问出"为什么自动化改了这条记录？"时，这些记录就变得非常有价值了。
系统应该能给出比"模型自己决定的"更好的答案。
旧系统往往正因为认证方式别扭而难以自动化：
不要把用户名密码直接塞进 prompts 来解决这些问题。
认证应该由 Agent 周围的基础设施来处理。
AWS AgentCore Browser 支持可以跨会话保留认证状态的浏览器配置文件，AWS 的参考架构也讨论了企业代理配置和内部应用程序的密钥管理。
通用模式是：
Human or identity system authenticates
↓
Browser receives scoped session
↓
Agent uses authenticated browser
↓
Credentials remain outside model context
Agent 需要访问已登录的应用，但不需要知道底层的凭证。
API 通常给你一个相对明确的契约。
Web 界面不是这样的。
按钮会移动，标签会改变，弹窗会出现，字段被重命名，重构会改变页面结构。
这使得浏览器自动化天生更容易受到表现层变化的影响。
因此，一个有用的实现应该检测不确定性，而不是假装每个页面都和预期一模一样。
type PageCheck = {
expectedState: string;
observedState: string;
confidence: number;
};
如果置信度低于你的安全阈值，就停下来。
if (pageCheck.confidence < 0.75) {
return requestHumanReview(pageCheck);
}
目标不是让模型更努力地猜测，而是在 Agent 改变重要内容之前让不确定性变得可见。
虽然浏览器可能是与旧系统交互的唯一方式，但这不意味着每一个业务决策都应该放在浏览器 Agent 内部。
假设一个保单变更只有在以下条件全部满足时才被允许：
如果这些规则是你自己的应用已知的，就在浏览器之外进行校验。
const validation = validatePolicyChange(request);
if (!validation.allowed) {
return {
status: "rejected",
reasons: validation.reasons
};
}
return runBrowserTask(request);
让浏览器 Agent 处理界面交互。
让确定性应用逻辑处理确定性业务规则。
这样减少了模型需要做出的高风险决策数量。
浏览器工作流会失败。
页面超时、会话断开、Agent 失去信心、网络请求没有返回。
如果之前的操作可能已经成功了，盲目重试整个任务是不对的。
要显式追踪状态：
type BrowserTaskState = {
taskId: string;
currentStep: number;
completedSteps: string[];
submitted: boolean;
};
在重复一个步骤之前，先确认它的预期效果是否已经发生。
当浏览器流程包含提交记录、发送消息、更改账户状态或触发下游操作时，这一点尤其重要。
仅仅因为一个应用没有 API，浏览器自动化并不自动成为正确的解决方案。
它是强候选者的场景是：
它变得不那么有吸引力的场景是：
如果 API 存在且适用，就用它。
浏览器 Agent 最有价值的时候，是浏览器本身就是你实际拥有的集成边界。
旧应用不需要在每个周边流程都能改进之前就先内部现代化。
浏览器自动化有时可以在底层系统保持原地的情况下消除重复劳动。
这可以为团队争取时间。
可以在更长期的 API、迁移或替换策略独立推进的同时，减少当前的手工处理。
但这个区隔很重要。
浏览器 Agent 不应该成为永远保留每一个脆弱旧系统的借口。它可以是从业务现有工作流通往最终想要的架构之间的一座桥。
生产级模式可以是这样：
Operator request
↓
Authentication
↓
Task validation
↓
Isolated browser session
↓
Observe page
↓
Model selects browser action
↓
Action executed through Playwright
↓
Critical action?
↙ ↘
No Yes
↓ ↓
Continue Human confirmation
↓
Continue
↓
Result recorded
↓
Session audit stored
这个架构在旧界面混乱的地方给予 Agent 灵活性，同时让关键边界保持可见。
AWS 在 2026 年 8 月 13 日发布了旧版 Web 应用自动化参考架构。
该实现将 Amazon Bedrock AgentCore Browser Tool 与 Strands Agents 以及具备视觉理解能力的基础模型结合使用。Agent 通过 Playwright/CDP 驱动一个托管的 Chromium 会话，存储截图和会话上下文供审查，并可以在关键操作前暂停等待人工确认。
AWS 将该架构定位为依赖浏览器交互而非现代 API 的旧版 Web 应用。
具体技术栈是 AWS 特有的。
但工程模式不是。
API 缺失曾经让很多自动化想法在一开始就感觉被堵死了。
浏览器 Agent 改变了这个限制。
它们让软件可以与人一样通过同一套界面进行交互，同时现代应用的控制层可以包裹在这个交互周围：隔离、可审计性、审批、认证和失败处理。
这不会让旧软件变成现代软件。
但它可以让围绕它的工作流变得少人工得多。