构建 AgentOS：我为何为保险理赔构建 AWS Lambda
发布: (2026年4月21日 GMT+8 16:42)
2 分钟阅读
原文: Dev.to
Source: Dev.to
问题：15 天的瓶颈
平均而言，财产与意外（P&C）理赔仍需 15 天以上 处理，涉及 10 次以上 手工触点，且给保险公司带来巨额的损失调整费用（LAE）。传统系统是单体结构——集成一个新的 “AI 工具” 通常需要 18 个月 的企业官僚流程。
愿景：AgentOS
我正在构建 AgentOS。它不是 “AI 包装器”。它是一个模块化、原生 AI 编排层——可以把它想象成 理赔专用的 AWS Lambda。与其让一个巨大的大语言模型（LLM）尝试完成所有工作，AgentOS 会部署一支专门的代理舰队：
- Intake Agent – 将杂乱的 FNOL（首次损失通知）数据转换为结构化的 JSON。
- Policy Agent – 在毫秒级别将理赔与复杂的保单文件进行交叉核对。
- Fraud Shield – 一个代理式模式匹配器，在理赔进入付款阶段前标记异常。
目标：70% 直通式处理（STP）
针对低复杂度的理赔（如汽车玻璃），目标是实现 70% 的 STP。
征求技术评议
- 定价模型： 基于使用量的 “按理赔利润分成（Margin‑on‑Claim）” 模型是否优于传统的 SaaS 座位许可模式？
- 状态持久化： 对于需要等待 24 小时 进行人工审批的代理，您会如何处理状态持久化？