保险理赔的第一报案(FNOL,First Notice of Loss)是整个理赔链条的起点,也是最耗人力的环节之一。报案员需要一边听客户描述事故,一边在多个门户系统中录入信息、查询保单、校验字段——手眼并用,重复劳动密集。AWS 最近展示了一种新思路:用 Strands Agents SDK 做领域推理,用 Amazon Bedrock AgentCore Browser Tool 做实时门户交互,两者组合实现"免手操"的 FNOL 录入。核心不是取代人的判断,而是把反复切屏、填表的体力活交给 Agent。
FNOL 的痛点在哪
传统 FNOL 流程大致是这样的:
- 客户来电或在线提交事故信息(时间、地点、损失描述等)。
- 报案员理解客户陈述,提取关键字段。
- 报案员打开内部理赔门户,逐字段填入表单,中途可能还要切换到保单系统查询保障范围。
- 提交表单,等待系统返回报案号。
步骤 2 需要专业判断,步骤 3 是纯体力活。一个熟练报案员处理一单平均 8–15 分钟,其中超过一半时间在操作界面。高峰时段(自然灾害后集中报案),排队时间直接拉长。
关键洞察:推理和操作是两种不同能力。推理需要领域知识(这算不算碰撞险?是否需要豁免?),操作需要精确的界面交互(点哪个按钮、填哪个字段)。把它们拆开,分别交给擅长的东西,是这次方案的出发点。
Strands Agents:负责"想"
Strands Agents SDK 是 AWS 推出的轻量级 Agent 框架,核心设计理念是"以工具为中心"——Agent 的行为由它能调用的工具决定,而不是靠硬编码流程。
在 FNOL 场景中,Strands Agent 扮演的是"报案推理引擎":
- 从客户原始陈述中提取结构化字段(事故时间、地点、涉及车辆、损失类型)。
- 根据保单条款判断险种适用性。
- 决定需要录入哪些门户字段、哪些需要人工复核。
Agent 不直接操作浏览器,它输出的是一份"操作指令清单"——告诉 Browser Tool 该去哪个页面、填什么值、点什么按钮。
Bedrock AgentCore Browser Tool:负责"做"
Amazon Bedrock AgentCore Browser Tool 是一个托管式浏览器工具,能让 Agent 以自然语言指令驱动真实 Web 门户的操作。它不是模拟 API 调用,而是真的在浏览器里点击、输入、导航——对那些没有开放 API 的内部系统尤其关键。
在 FNOL 流程中,Browser Tool 接收 Agent 的指令,执行:
- 打开理赔门户登录页,完成认证。
- 导航到"新建报案"表单。
- 按指令逐字段填入提取的结构化数据。
- 提交表单,抓取返回的报案号。
整个过程报案员不需要碰键盘,只需在 Agent 请求复核时做判断性确认。
实践:搭建一个最小 FNOL Agent
下面用一个可运行的 Python 示例展示如何组合 Strands Agent 与 Browser Tool。假设你已有 AWS 账户,且在 Bedrock 中启用了对应模型。
安装依赖
pip install strands-agents boto3
Agent 定义与运行
import json
from strands import Agent, tool
# --------------------------------------------------
# 1. 定义领域推理工具:从客户陈述提取结构化字段
# --------------------------------------------------
@tool(
name="extract_fnol_fields",
description="从客户事故陈述中提取 FNOL 所需的结构化字段"
)
def extract_fnol_fields(customer_statement: str) -> dict:
"""
实际生产中这里会调用 LLM 做提取;
示例中用硬编码模拟返回结构,方便你直接运行测试。
"""
# 模拟提取结果——替换为 Bedrock 模型调用即可
extracted = {
"incident_date": "2025-06-18",
"incident_location": "上海市浦东新区世纪大道100号",
"loss_type": "collision",
"vehicle_make": "Toyota",
"vehicle_model": "Camry",
"vehicle_year": "2023",
"policy_number": "POL-2023-88412",
"claimant_name": "张伟",
"contact_phone": "138-0000-1234",
"requires_human_review": False # Agent 判断是否需要人工复核
}
return extracted
# --------------------------------------------------
# 2. 定义浏览器操作工具:调用 Bedrock AgentCore Browser Tool
# --------------------------------------------------
@tool(
name="browser_submit_fnol",
description="通过浏览器工具在理赔门户中提交 FNOL 表单"
)
def browser_submit_fnol(fields: dict) -> dict:
"""
生产环境中调用 Bedrock AgentCore Browser Tool 的 API;
示例中用 boto3 模拟请求结构,展示调用模式。
"""
import boto3
client = boto3.client("bedrock-agentcore", region_name="us-east-1")
# 构造浏览器操作指令序列
browser_instructions = [
{"action": "navigate", "url": "https://claims-portal.example.com/new-claim"},
{"action": "fill", "selector": "#policy_number", "value": fields["policy_number"]},
{"action": "fill", "selector": "#claimant_name", "value": fields["claimant_name"]},
{"action": "fill", "selector": "#incident_date", "value": fields["incident_date"]},
{"action": "fill", "selector": "#loss_type", "value": fields["loss_type"]},
{"action": "fill", "selector": "#location", "value": fields["incident_location"]},
{"action": "click", "selector": "#submit_btn"},
{"action": "extract", "selector": "#claim_id_label"}
]
# 调用 Browser Tool 执行操作序列
response = client.invoke_browser_tool(
browserToolId="fnol-claims-portal", # 预注册的浏览器工具标识
instructions=json.dumps(browser_instructions),
sessionId="fnol-session-001"
)
# 返回门户响应(含报案号等)
result = json.loads(response["executionResult"])
return result
# --------------------------------------------------
# 3. 组装 Agent
# --------------------------------------------------
fnol_agent = Agent(
model="us.anthropic.claude-3-5-sonnet-20241022-v2:0",
tools=[extract_fnol_fields, browser_submit_fnol],
system_prompt=(
"你是保险理赔 FNOL 报案助手。"
"工作流程:"
"1. 收到客户事故陈述后,调用 extract_fnol_fields 提取结构化字段。"
"2. 如果 requires_human_review 为 True,先向用户请求确认再继续。"
"3. 确认无误后,调用 browser_submit_fnol 在门户中提交表单。"
"4. 向用户报告报案号和下一步指引。"
"始终保持专业、简洁,不编造保单条款。"
)
)
# --------------------------------------------------
# 4. 运行
# --------------------------------------------------
if __name__ == "__main__":
customer_input = (
"我今天早上8点在浦东世纪大道100号出了碰撞事故,"
"我的车是2023款丰田凯美瑞,保单号POL-2023-88412,"
"我叫张伟,电话138-0000-1234。"
)
result = fnol_agent(customer_input)
print(result)
运行前需要修改的地方:
extract_fnol_fields中的硬编码返回值应替换为实际的 LLM 提取逻辑(在 Strands 框架下,Agent 自身模型就能做提取,你也可以把提取逻辑直接交给模型而不单独定义工具)。browser_submit_fnol中的门户 URL、CSS selector、browserToolId需替换为你实际环境的值。- 确保 AWS 凭证已配置(
aws configure或环境变量)。 - Bedrock AgentCore Browser Tool 需在 AWS 控制台预先注册目标门户站点。
为什么不直接用 API?
很多团队的第一反应是:为什么不给理赔门户开个 REST API,让 Agent 直接调?
现实是,大量保险公司的核心系统还在用老旧门户,短期不可能全部 API 化。Browser Tool 的价值就在于不依赖目标系统提供 API——它操作的是真实界面,跟人操作一模一样,只是更快、更稳定。这让 Agent 能立刻接入现有系统,而不是等 IT 团队排期做接口开发。
当然,如果门户已有 API,直接调 API 更可靠。Browser Tool 是"没有 API 时的最佳退路",不是首选。
人工判断的位置
这个方案最值得注意的设计是 requires_human_review 标记。Agent 在提取字段后自行判断是否需要人工介入——比如损失类型模糊、保单条款存在争议、陈述与保单信息不一致等情况。只有这些场景才会暂停流程,请报案员确认。
这意味着:
- 80%以上的标准报案可以全自动走完,报案员只需最终确认报案号。
- 边缘案例不会被强行自动化,而是被标记出来交给人判断。
- 人的角色从"全程操作员"变成"关键决策者"——工作量下降,判断质量不降。
上线前的检查清单
| 检查项 | 说明 |
|---|---|
| 门户认证方式 | Browser Tool 需能完成登录(SSO / MFA 场景需额外配置) |
| 字段映射准确性 | Agent 提取的字段名必须与门户表单 selector 一一对应,建议用配置文件维护映射表 |
| 异常恢复策略 | 门户页面结构变更、网络中断时 Agent 应有重试/回退逻辑,不能静默失败 |
| 合规与审计 | 每次自动提交应记录完整操作日志,满足监管追溯要求 |
| 人工复核阈值 | requires_human_review 的触发条件需与业务团队共同定义,不能纯靠模型自判 |
| 测试环境先行 | 先在非生产门户上跑通全流程,确认字段填写无误后再切生产 |
适合什么团队先试
- 已有 Bedrock 使用经验的保险或金融团队,上手最快。
- FNOL 量大且门户操作重复度高的场景(车险、财产险报案高峰)。
- 内部系统短期内无法 API 化,但急需提效的业务线。
不适合的场景:报案涉及复杂多方责任判定、需要大量非结构化证据采集(照片、视频审核)的情况——这些环节的推理深度超出了当前 Agent 工具链的舒适区,强行自动化反而增加风险。
Strands Agents + Browser Tool 的组合,本质上是把"懂业务"和"会操作"解耦后分别强化。推理交给 Agent,操作交给浏览器工具,人在关键节点把关。这不是远期愿景,是现在就能搭起来跑的架构。