在竞争激烈的保险行业，卓越的客户服务是赢得客户忠诚度的关键。Alan保险一直坚信这一点。正如他们之前分享的，Alan利用 AI 助理实现了客户联络的自动化，并且在保证客户满意度不降低的前提下，极大地提升了效率。今天，我们将深入探讨Alan保险更为复杂和先进的 AI Agent： 理赔代理(Claim Agent)。这个智能代理的初步版本已经能够完全自动化处理大约30%的理赔相关的支持请求。这篇文章将深入剖析该 Agent 的工作原理，分享实际应用案例，并揭示Alan保险在构建过程中的经验与教训。本文将围绕大模型、ReAct Agent、tool calling、智能客服等关键词展开。
1. 为什么需要 Agentic Approach：理赔业务的复杂性
Alan保险的 AI 驱动的客户支持之旅始于专注特定领域的专家 Agent：负责保险范围问题的 Coverage Agent 和处理更广泛 FAQ 问题的 Generic Agent。这些 Agent 在处理简单、明确的问题时表现出色，因为所需的信息可以被提前预测并包含在系统提示(System Prompt)中。然而，随着自动化范围的扩大，Alan 保险遇到了一个重大的挑战：理赔支持——帮助会员理解他们的报销情况、跟踪理赔状态以及解决医疗费用问题。
理赔是客户支持中最复杂的领域之一，占所有工单的20%。典型的理赔问题包括：“为什么我的整骨疗法疗程只报销了一部分？” 与通常可以通过静态保险范围表回答的覆盖范围问题不同，理赔需要动态调查：
- 跨不同日期和受益人的多个护理事件
- 各种保险文件及其处理状态
- 涉及不同健康保障的复杂报销计算
- 会员特定的政策详情和消费追踪
传统的构建全面系统提示的方法很快就遇到了瓶颈。包含所有潜在的理赔相关信息会创建包含大量不相关数据的上下文，从而减慢响应速度并降低答案质量。人类理赔专员在处理理赔时，不会试图预先预测所有可能的信息。相反，他们首先理解会员的问题，推理出需要哪些额外信息，然后从后端系统检索这些特定的细节，并重复这个有针对性的方法，直到他们有足够的信息来准确回答问题。
观察到这种自然的工作流程后，Alan保险受到启发，构建了他们迄今为止最先进的 Agent——一个能够动态检索每个特定场景所需信息的 Agent。这为 大模型 在理赔业务中的应用奠定了基础。
2. Claim Agent：ReAct Agent 的强大力量
与之前静态的 Agent 不同， Claim Agent 实现了 ReAct (Reason + Act) 范例——一个强大的框架，使 AI Agent 能够迭代地收集信息并做出决策。ReAct Agent是一种将推理（Reasoning）和行动（Acting）相结合的架构，使得AI Agent能够更好地理解用户需求，并与环境进行交互以完成任务。
Claim Agent 从一个精简的系统提示开始，其中包含：
- 剧本 (Playbook)：一系列通用的理赔知识和解决方案策略
- 会员属性 (Member attributes)：上下文信息，如当前的护理事件或文件详情
- 工具描述 (Tool descriptions)：可用的后端函数，包含使用示例和使用条件
ReAct 循环在实践中是这样运作的：
- 思考 (Think)： 大模型 分析会员的问题和可用的上下文，以确定是否需要更多信息。
- 行动 (Act)：如果需要额外数据， Agent 调用后端 工具 以获取相关信息。
- 观察 (Observe)： 工具 结果被返回并反馈到 大模型 的上下文中。
- 重复 (Repeat)：循环继续，直到 Agent 有足够的信息来提供全面的答案。
这种方法避免了将不必要的数据“强行塞入”提示中，同时保持了在需要时访问相关信息的能力。在“行动 (Act)”步骤中， Claim Agent 能够利用特定的后端 工具（这些 工具 是确定性的，并非基于 大模型 的）：
get_care_event_details(care_event_id)：获取护理事件信息（例如，报销金额、状态）get_document_details(document_id)：获取保险文件详情（例如，文件类型、处理状态）get_health_guarantee_details(health_guarantee_title)：获取健康保障条件和剩余额度list_care_events(date, name, care_type)：按日期或其他条件搜索护理事件
这种方法的强大之处在于， 工具 仅在需要时才会被调用。 Alan保险的数据显示， Tool calling 大约发生在 20% 的对话中，从而保持了系统的效率，同时维持了全面的覆盖范围。这使得AI能够在特定的场景下，针对性地进行数据获取和分析，极大地提高了工作效率。
3. 实际案例：Claim Agent 的能力与局限性
为了更好地理解它的工作原理，我们来研究三个实际案例，这些案例展示了 Agent 的能力和局限性。
案例 1：福利消费查询
在这个例子中，一位会员问：“我还有多少次替代医学疗程剩余？”
Agent 按以下方式处理问题：
- 循环 1
- 思考 (Think)：“会员询问福利消费情况。我需要检查他们的健康保障详情。”
- 行动 (Act)：调用
get_health_guarantee_details(“psychology”) - 观察 (Observe)： 工具 返回健康保障详情和剩余额度
- 循环 2
- 思考 (Think)：“我现在有足够的信息来回答。我将退出循环”
- 最终答案（在 ReAct 循环之外）
- “您已经使用了 5 次心理咨询疗程中的 4 次。今年还剩余 1 次疗程。”
“思考 (Think)”，“行动 (Act)” 和 “观察 (Observe)” 步骤通过单个 大模型 调用完成。在这个例子中，总共进行了 3 次 大模型 调用。
案例 2：从模糊问题中找到正确的护理事件
在这个例子中，一位会员询问了他们的报销情况，然后询问了他们的一个受益人（“我女儿的呢？”）。
Agent 按以下方式处理问题。
- 循环 1
- 思考 (Think)：“会员询问特定受益人的报销情况，但我不知道他们指的是哪个护理事件。”
- 行动 (Act)：调用
list_care_events(beneficiary=<受益人姓名>) - 观察 (Observe)：返回多个受益人的不同日期的护理事件
- 循环 2
- 思考 (Think)：“结果太多了。我需要更具体的信息。”
- 回复会员：“我看到了<受益人姓名>的几个护理事件。您能说明一下日期吗？”
然后会员回复：“是上周二。”
- 循环 1
- 思考 (Think)：“我需要查找 2025-06-17 日<受益人姓名>的护理事件。”
- 行动 (Act)：调用
list_care_events(beneficiary=<受益人姓名>, date=”2025–06–17") - 观察 (Observe)：找到单个护理事件
- 循环 2
- 思考 (Think)：“现在我将检查这个护理事件的详情。”
- 行动 (Act)：调用
get_care_event_details(care_event_id=<护理事件 ID>) - 观察 (Observe)： 工具 返回护理事件详情
- 循环 3
- 思考 (Think)：“我现在有足够的信息来回答。”
- 最终答案：“您女儿的护理事件于 2025-06-17 报销。”
这个例子展示了 Agent 通过澄清问题来处理模糊查询的能力。
案例 3：当 Tool calling 出错时
Alan保险偶尔会遇到 Agent 提供不正确参数的错误。一个例子是 Agent 调用 get_care_event_details 时使用了 care_event_id_missing_in_the_system_prompt 这个 ID，这个 ID 根本无效！
Alan保险的错误处理策略是将描述性错误消息作为字符串而不是异常返回，从而使 大模型 能够从错误中学习并自我纠正。然而， Tool calling 并非 100% 可靠，必须始终为错误做好准备。当 Agent 在多次尝试后仍无法检索到必要的信息时，它会优雅地升级到人工 Agent，而不是提供潜在的不正确答案，从而确保会员始终获得准确的支持。
4. 构建 Claim Agent 的经验教训
构建 Claim Agent 使Alan保险获得了关于 Agentic AI 系统的宝贵经验，这些经验远远超出了他们之前使用静态提示的经验。以下是 Alan保险分享的一些关键见解。
- 设计万无一失的工具接口。正如我们所见， 大模型 会犯错误，因此Alan保险需要设计能够应对这些错误的健壮的 工具 接口：
- 简化工具接口：删除冗余参数。如果 工具 主要一起使用，则将它们合并为单个 工具。
- 明确指定参数：在 工具 描述中提供明确的格式要求和示例（例如，UUID 格式，YYYY-MM-DD 日期格式）。
- 实施强大的错误处理：确保 工具 返回清晰的错误消息而不是异常，从而使 Agent 能够从错误中学习并自我纠正。
- 限制循环次数：严格限制 ReAct 循环的次数，以避免无限循环。
- 不要犹豫，在系统提示中进行规定。有时，仅提供 工具 不足以让 Agent 正确使用它们。Alan保险遇到了一些情况，尽管在 工具 描述中做了努力，但 Agent 仍然不会调用任何 工具。在这种情况下，有必要在系统提示中添加明确的指令，即使这引入了Alan保险希望避免的重复。
- Alan保险还实施了一个关键的反思步骤。在 Agent 完成其 Tool calling 后，Alan保险会提示它“回顾并反思会员真正想要什么”，然后再生成最终答案。这有助于 Agent 区分直接回答会员的问题和仅仅呈现从 Tool calling 收集的信息。
其他关键见解包括：
- 系统提示与 Tool calling：Alan保险需要在系统提示中包含的信息量与 Tool calling 的频率之间取得平衡。Alan保险遵循以下经验法则：如果信息需要在 80% 以上的时间内使用，则将其包含在系统提示中。
- 模型选择：Alan保险观察到，来自 2024 年 8月之后的 大模型 在遵循 工具 规范和参数格式方面明显优于 2024 年之前的模型。特别是，来自2024年5月和8月的 GPT-4o 在选择正确的参数方面经常遇到困难。随着 大模型 提供商优化其模型以供代理使用，Alan保险应该始终在实施 Tool calling 时寻找最新的模型。
- 隐私问题：在执行 工具（在本例中为只读）之前，Alan保险需要验证用户是否有权访问数据。 工具 输出进入 大模型 提示，这意味着数据可能会暴露给用户。如果用户无权访问数据，Alan保险根本不应该调用该 工具。
这些见解与 Chip Huyen 最近出版的 AI Engineering 一书（特别是第 6 章第 2 节）中的内容有很多共鸣。Alan保险向任何对构建 AI Agent 感兴趣的人推荐它。
5. 智能客服的未来：不断演进的 Agentic AI
从静态提示到动态的、 Tool calling 的 Agent 的演变，标志着Alan保险处理 AI 驱动的客户支持方式发生了根本性的变革。 Claim Agent 像人类 Agent 一样调查、收集证据并提供全面的解决方案，但速度更快。 大模型 在其中发挥了关键作用。
但这仅仅是个开始。 Alan保险的下一步包括：
- 添加更多工具：Alan保险将向 Claim Agent 添加更多 工具，以处理日益复杂的案例。
- 探索高级 Agentic 架构：Alan保险从 ReAct 开始，ReAct 是最简单的 Agentic 架构之一。Alan保险将探索更高级的模式，例如 supervisor 模式。
- 加强测试和评估：Alan保险的内部测试和评估框架尚不支持 Tool calling。为了实现这一点，Alan保险需要提供一种模拟 Tool calling 的方法，因为测试和评估是针对从过去数据中提取的静态数据集进行的。
总而言之，Alan保险的 理赔代理(Claim Agent) 项目利用 大模型 和 ReAct Agent 架构，实现了理赔流程的自动化和效率提升。通过智能的 Tool calling 和持续的优化，Alan保险在 智能客服 领域取得了显著的进展。 未来，随着技术的不断发展，我们可以期待更多创新性的解决方案，为客户提供更加便捷和高效的保险服务。