AWS Agentic Form Filling：Bedrock 情景记忆与语义元素发现的实践

引言：企业级智能体的特殊要求

前七篇文章介绍的工具面向不同的使用场景——个人自动化、云端并发、CLI 加速、反爬对抗、认知编排。但它们有一个共同点：是无状态的。每个任务从零开始，智能体不记得上一次成功填表时使用了什么方法。

在企业级场景中，这远远不够。

以航空公司的值机流程为例。航空公司 A 要求在表单第一页输入预订编号和姓氏，航空公司 B 要求在同一个页面选择航班并验证身份，航空公司 C 把输入框藏在一个需要先点击"开始值机"按钮才能展开的面板后面……

如果 AI 智能体每次遇到这些差异都从零开始推理，效率和可靠性都无法满足生产要求。

AWS Agentic Form Filling 的核心创新就是解决这个问题：情景记忆（Episodic Memory）。它让智能体记住"上次遇到这个航空公司的页面时，我先点击了哪里，然后才看到输入框"，并在下次遇到相同场景时直接复用这些经验。

架构概览

AWS Agentic Form Filling 的架构深度结合了 Amazon Bedrock 的托管 AI 服务与 Playwright 的浏览器自动化能力。

┌────────────────────────────────────────────────────┐
│           AWS Agentic Form Filling 架构              │
│                                                    │
│  ┌──────────────────────────────────────────────┐  │
│  │           Amazon Bedrock AgentCore           │  │
│  │                                              │  │
│  │  ┌────────────────┐  ┌──────────────────┐   │  │
│  │  │ Claude Model   │  │  Episodic Memory │   │  │
│  │  │ (claude-opus)  │  │  (情景记忆存储)   │   │  │
│  │  └────────┬───────┘  └──────────────────┘   │  │
│  │           │                                  │  │
│  │  ┌────────▼──────────────────────────────┐   │  │
│  │  │     ImageFilteringConversationManager │   │  │
│  │  │     (滑动窗口协议，自动排除旧记录)      │   │  │
│  │  └───────────────────────────────────────┘   │  │
│  └──────────────────────────────────────────────┘  │
│                                                    │
│  ┌──────────────────────────────────────────────┐  │
│  │            Playwright Driver                  │  │
│  │                                              │  │
│  │  ┌────────────────┐  ┌──────────────────┐   │  │
│  │  │ aria_snapshot  │  │ Semantic Element │   │  │
│  │  │ (A11y 树)      │  │ Discovery (BERT) │   │  │
│  │  └────────────────┘  └──────────────────┘   │  │
│  └──────────────────────────────────────────────┘  │
│                                                    │
│  ┌──────────────────────────────────────────────┐  │
│  │           目标网站（如航空公司值机页面）       │  │
│  └──────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────┘

核心组件

组件	作用	技术实现
Bedrock AgentCore	智能体编排、记忆管理、工具调用	AWS 托管服务
Claude 模型	核心推理和决策	Amazon Bedrock
Episodic Memory	跨会话经验存储与检索	AgentCore 内置
Playwright	浏览器控制（导航、交互、截图）	开源自动化库
ImageFiltering Manager	上下文窗口管理、Token 优化	自定义滑动窗口
Semantic Discovery	语义化元素定位	Sentence Transformers

情景记忆（Episodic Memory）的设计

情景记忆是 AWS Agentic Form Filling 最具企业价值的设计。它不同于普通的聊天历史存储——它是有结构的、可检索的、经过 PII 过滤的经验数据库。

记忆生命周期

第一轮交互
    │
    ▼
AgentCore 自动捕获当前情节数据：
  - 当前页面 URL / 标题
  - 执行的操作流水（navigation, click, fill）
  - 每个操作的工具效率和返回结果
  - 是否遇到错误及如何解决
    │
PII 过滤层
    │  自动移除：乘客姓名、确认码、支付信息等
    │  保留：导航路径、表单结构特征、错误模式
    ▼
存储到情景记忆数据库
  - 命名空间：航空公司名称
  - 包含：成功导航流程、工具效率、错误解决方案
    │
    ▼
下一轮新会话初始化
    │
AgentCore 自动检索相关记忆
    │  根据当前任务上下文匹配
    │  "我们之前处理过这家航空公司的值机页面"
    ▼
记忆注入到 LLM 提示上下文
    │  "上次这个表单需要先点击'开始值机'按钮才能看到输入框"
    ▼
智能体复用成功策略，避免重复错误

关键设计决策

决策	原因
按命名空间隔离记忆	不同航空公司的表单结构差异巨大，混在一起会混淆推理
自动过滤 PII	合规要求（GDPR、CCPA），防止敏感数据被下一轮会话读取
保留错误解决方案	失败的模式往往比成功路径更有信息价值

语义元素发现（Semantic Element Discovery）

传统的网页元素定位依赖精确匹配——通过 ID、CSS 选择器、XPath 或可访问性标签。但在企业表单中，这些标识符通常是动态生成的或不可靠的。

AWS 的方案是：不匹配文本，匹配语义。

工作原理

Playwright aria_snapshot() 
    │  获取当前页面的可访问性树
    ▼
Sentence Transformers（本地客户端模型）
    │  将 A11y 树分块
    │  每个块转换为高维向量嵌入（Embeddings）
    ▼
语义相似度搜索
    │  搜索目标："提交按钮"
    │  发现："Proceed to Next Step"（语义相似度 0.91）
    │         "Continue"（语义相似度 0.87）
    │         "Submit"（语义相似度 0.85）
    ▼
即使按钮文本是 "Proceed to Next Step"，
也能通过语义接近度可靠识别

这种设计彻底摆脱了对精确 CSS 选择器的依赖。即使页面的 HTML 结构完全改变、class 名全部重写，只要按钮的语义不变，智能体就能找到它。

与精确匹配的对比

定位方式	示例	面对改版的鲁棒性
CSS 选择器	`#submit-btn`	极差（class 或 ID 改变即失效）
XPath	`//form/div[3]/button`	差（DOM 结构变化即失效）
可访问性标签	`button "Submit"`	中（文本改变即失效）
语义向量	`similar_to("提交按钮")`	高（语义不变即可）

上下文窗口管理：ImageFilteringConversationManager

使用 LLM 驱动的智能体面临一个两难问题：截图提供了丰富的视觉上下文，但每次截图都要消耗大量 Token。

AWS 的方案是一个滑动窗口协议：

对话开始时：
  [系统提示][记忆注入][初始截图]
 
随着对话进行：
  [系统提示][记忆注入][截图 #1][操作 #1][截图 #2][操作 #2]...
 
Token 接近限制时：
  [系统提示][记忆注入][旧截图被移除: 替换为文本占位符]
  [截图 #5][操作 #5]...
 
关键策略：
  - 旧截图被动态剔除
  - 用占位符文本标记"这里有一张被过滤的截图"
  - 保留最近的操作记录和截图
  - 情景记忆不受影响（持久化存储）

这种管理方式确保了：

上下文窗口始终在模型限制范围内
最近的视觉信息得到保留
历史关键数据通过情景记忆持久化，不依赖活动上下文

部署说明

AWS Agentic Form Filling 的部署涉及多个 AWS 服务：

核心依赖

服务	用途
Amazon Bedrock	托管 Claude 模型
Bedrock AgentCore	智能体编排 + 情景记忆
AWS Lambda / ECS	Playwright 执行环境
Amazon S3	截图和日志存储
IAM	权限管理

部署步骤（简化）

# 1. 克隆项目
git clone <repository-url>
 
# 2. 配置 AWS 凭证
aws configure
 
# 3. 部署 AgentCore
python deploy_agentcore.py \
  --memory-enabled \
  --namespace "airline-checkin"
 
# 4. 配置模型访问
# 在 Bedrock 控制台中启用 Claude 模型访问

实战场景：航空值机

系统提示：为乘客完成航空公司值机
输入：确认码 ABC123，姓氏 SMITH

第一次处理（无记忆）：

1. 打开航空公司值机页面
2. aria_snapshot() 获取页面结构
3. 语义搜索："confirmation code input" → 找到输入框
4. 填入 ABC123
5. 语义搜索："last name input" → 找到输入框
6. 填入 SMITH
7. 语义搜索："check in button" → 找到并点击
8. 检测到 CAPTCHA，需要人工介入
9. 记录记忆：这家航空公司的值机页面有 CAPTCHA

第二次处理（有记忆）：

1. 打开同一航空公司值机页面
2. AgentCore 检索到相关记忆
3. 记忆注入提示："上次处理时发现该页面需要 CAPTCHA 验证"
4. 智能体提前准备 CAPTCHA 处理策略
5. 填入信息 → 跳过已知的步骤
6. 效率对比：第一次 35 秒，第二次 12 秒

企业级方案与开源方案的对比

维度	AWS Agentic Form Filling	Nanobrowser / Browy	agent-browser
部署复杂度	高（多 AWS 服务依赖）	极低（浏览器扩展）	低（CLI 安装）
记忆管理	AgentCore Episodic Memory	无	session save/load
元素定位	语义向量 + A11y 树	DOM 路径	A11y Ref
上下文优化	ImageFiltering 滑动窗口	无	无（A11y 快照天然精简）
规模化	AWS 基础设施弹性伸缩	单用户	单实例
成本	AWS 服务费用 + 模型调用	自有 API Key	自有 API Key
适合	企业生产环境	个人开发者	开发者 / 小团队

局限性

AWS 锁定：深度绑定 Amazon Bedrock 和 AWS 生态
配置复杂：需要理解和配置多个 AWS 服务
延迟较高：AgentCore 编排 + 截图分析 + 向量搜索，端到端延迟高于轻量级方案
成本不确定性：企业级托管服务 + Claude 模型的组合成本需要仔细估算

总结

AWS Agentic Form Filling 代表了一类企业级 AI 浏览器智能体的实现范式——它不追求"最快"或"最便宜"，而是追求"最可靠"和"可学习"。

情景记忆让智能体不再是每次从零开始的无状态工具，而是一个能够积累经验的"数字员工"。语义元素发现消除了对脆弱 CSS 选择器的依赖。滑动窗口上下文管理确保了长时间的复杂任务不会因为 Token 限制而中断。

对于那些需要处理大量、重复、结构相似但细节不同的企业表单的场景（航空公司值机、银行开户、保险理赔），这种架构提供了目前最可靠的工程方案。

下一篇文章将对截至 2026 年中的主流 AI 浏览器智能体框架进行全面的横向对比。