实习日志 / 中文 / 实习 Journal / Journal 2：项目说明与阶段进展

Journal 2：项目说明与阶段进展

背景与原始目标

首次报案（First Notice of Loss，FNOL）指客户在事故、盗窃或灾害之后第一次向保险公司报告损失，保险公司据此建立理赔记录。这是客户在经历不愉快的事件后与保险公司的第一次接触，后续处理能否顺利展开，很大程度上取决于这一步。

Scenario 8 设定了一家名为 Northwind 的保险公司，每年处理八万多件车辆、房屋和家庭财物理赔。按照题目的设定，Northwind 的报案主要通过两个渠道完成：电话报案由客服人员接听，能理解客户的自然描述，也能处理各种例外情况。但每通电话平均需要 18 分钟，人力成本高，业务量增长时只能相应增加人手；网页表单随时可用，收集到的信息也比较规整。但表单冗长，问题不会随事故情况调整，放弃率达到 30%。两个渠道都不会系统地收集照片和文件，因此常常需要事后补件。按照题目的设定，40% 的报案至少需要一次追加联系，从首次报案到创建理赔平均需要 2.5 天，严重程度和欺诈风险的判断要等到报案后 24 到 48 小时才由人工完成。

在真实的市场里也能看到同类问题。新西兰金融市场管理局（FMA）在 2025 年发布的理赔调查中发现，在受调查的保险公司中，只有 43% 会在理赔确认中告诉客户将通过什么方式获得进度更新；报告还建议保险公司把向客户提出的信息请求合并起来 [1]。

题目期望的产出是一个 agent：它能从客户的第一句描述开始，一直引导到理赔创建，并完成 10 个测试场景（5 个车辆、3 个房屋、2 个财物）。它需要做到以下几件事：

支持多轮对话和澄清；
接收照片和 PDF；
依据匿名化的保单文件核对保障范围和免赔额；
对案件的严重程度分级，并标记欺诈信号；
调用工具在模拟的理赔系统中创建理赔，需要时预约评估师；
结束时告诉客户理赔编号和预计时间。

衡量标准有四项：至少 80% 的场景无需追加联系；严重程度分级由理赔人员盲评；测试集中的欺诈标记不能有误报；客户在 5 分钟内、10 个问题以内完成报案。

以用户为中心的调研告诉了我们什么

在设计最初的原型时，团队同步开展了以用户为中心的调研，这部分工作主要由队友完成。调研使用了四类来源。

第一类是在线问卷。问卷面向新西兰的保险客户和潜在理赔人，通过 Google Forms 匿名填写，大约需要 3 到 5 分钟，参与者在知情同意后作答，没有报酬。有效样本为 155 份，其中约七成的人从未理赔过。部分题目只面向有理赔经历的人，也有人跳过个别题目，因此各题的有效人数不同，下文的百分比都按该题实际作答的人数计算。

第二类是一次非正式的行业访谈。受访者是一位保险业审计从业者，访谈以文字形式进行，由一位队友记录，并事先征得了受访者同意。

第三类是一次小范围的网站观察：五位来自其他项目组的参与者当面尝试在一家新西兰保险公司的公开网站上走一遍理赔流程。

第四类是公开资料，包括 FMA 的调查报告、新西兰保险与金融服务调解机构公布的案例，以及几家保险公司公开的报案指引。网上的客户评价只作为个别经历的例子，不用来推断问题出现的频率。

这些来源共同指向一个核心发现：除了表单太长，客户在理赔中遇到的困难集中表现为一连串的"不知道"。客户不知道事故后第一步该做什么，不知道要收集哪些证据，不知道自己提供的信息够不够，不知道接下来会发生什么、由谁负责下一步。有 AI 参与时，他们还不知道 AI 是否理解了自己，也不知道情况变复杂时会不会有人接手。

具体来看，问卷中有理赔经历的人里，约三分之一（35.4%）表示当时不清楚需要提供哪些信息，60.4% 在提交后不清楚理赔进展到了哪一步。在最看重的方面，71.7% 的人选择了进度和下一步可见，48.3% 选择了材料要求清晰、上传简单。四成以上的受访者担心 AI 误解事故，或者替人做了本该由人把关的决定。访谈从员工一侧印证了同样的问题：客户常常不清楚哪些材料需要自己去取、哪些事情由保险公司负责，员工要花大量时间反复解释。网站观察中，五位参与者都被"保单号"这类术语卡住，并且都表示想放弃。

这些结论也有明显的局限。问卷是探索性的，样本不大，个别题目的作答人数很少，结论可以帮助判断优先级，但不能当作人群统计来用。员工一侧的证据主要来自公开的流程资料和一次访谈，仍需要真正的理赔员工来验证。我们在后来的设计里一直保留着这些限定。

在这个阶段，我的工作是把调研结论转成可以验证的开发计划。我把产品目标拆成十六条功能需求和十二个验收场景，每个场景描述一段可以观察到的完整经历。举几个例子：

客户描述一起追尾事故后，系统生成一份理赔草稿，草稿里的每条事实都注明出自客户的哪句话；
客户提到有人受伤时，系统停止常规提问，立即把案件交给人工处理；
警方报告通常要过一段时间才能出具，客户一周后拿到报告回来，可以接着上次的进度继续，不用从头再讲一遍。

团队为这些场景定下的完成标准是：每条演示路径都要真实改变系统里记录的状态，只展示界面的演示不算完成。

我们的目标

在调研和竞标分析的基础上，我们把产品主张定为：建立一个可信的理赔协同入口，让客户用自己的话讲述发生了什么，由系统承担背后的专业整理和流程推进，并持续负责把理赔带到下一个安全的步骤。这里的"可信"指的是：每一条重要事实及其来源、每一次权限判断、每一次状态变化和人工决定，都可以被核实。用一句更直白的话说：客户只需要讲发生了什么，不应该成为自己理赔流程的项目经理。

这个主张落实为两个关键能力。

第一个是可信、自适应的理赔入口。agent 根据事故和客户的情况，决定问多少、问多深，把客户的自然描述整理成有来源、可以继续处理的理赔记录，只在必要时请客户确认关键事实，并在需要时带着完整的上下文转给人工。这个入口同时服务于员工：员工拿到的是带有来源、不确定性和待办事项的结构化上下文，可以追问、修正、拒绝或者推翻 agent 的建议。

第二个是基于统一理赔记录的协同层。客户、agent、员工，以及评估师、维修商、警方文件提供方等外部参与方，都在同一份理赔记录上工作，交接时上下文不会丢失，客户也不必向每个接手的人重复说明。

具体来说，我们希望系统做到：

agent 只问推进下一步真正需要的问题，已经确认的信息不重复询问；
每条事实都记录来源和确认状态，客户可以查看和纠正；
某份材料暂时缺失时，只挂起依赖它的步骤，其他可以安全推进的部分照常推进；
客户隔几天再回来时，可以从上次停下的地方继续；
出现伤亡或危险信号，或者客户明确要求人工时，立即转交，并附带完整的上下文；
保障范围、责任认定、欺诈判断和赔付这些影响重大的决定，始终留给人来做。

验收方面，为了测出题目规定的四项指标，并在 10 个场景之外充分验证系统，团队设计了相应体量的测试：在最终版本上完成不少于 100 次完整的报案流程测试，按车辆、房屋、财物 5∶3∶2 的比例分配，并另外请不了解系统内部的人做真实的盲测。

实现目标的方向，以及我做的调研与文献综述

要实现上述目标，需要同时考虑几个方向：

agent 怎样理解客户、做出决策并与系统协作；
客户端和员工端的界面与体验；
数据、保单知识和历史理赔的检索；
员工的工作流程与交接；
外部服务与材料；
部署与集成。

团队按这些方向分工，我主要负责 agent 的行为与编排，以及客户端的体验。下面按目标说明我为这些部分做的调研，以及从文献中得到的依据。

为了让 agent 可靠地推进理赔：成熟系统的做法

为了弄清一个真正能处理理赔的 agent 应该由哪些部分组成，我先调研了业界的做法，包括主流的对话式客服平台、保险行业的垂直产品，以及支撑长流程的基础设施。厂商材料的可信程度差别很大，所以我把来源分成四个等级：官方技术文档、能读到代码的公开实现、看不到内部实现的产品说明，以及我自己的推导。厂商对效果的宣称，一律只按产品说明对待。

调研得到的结论可以归纳为以下几点：

成熟的平台把对话状态和业务流程放在模型之外显式管理，例如用页面和参数表示会话进行到哪一步，用单独定义的流程承载业务逻辑 [2], [3]；
理赔的事实和状态应当由应用掌握，模型负责理解、整理和提出建议；
系统需要确定的流程，但客户可以跳着说、随时纠正或者中途暂停；
一轮对话往往同时包含回应客户、记录事实、查询资料和安排下一步；
转交人工是一项正常能力，交接质量取决于转交理由、优先级和上下文是否完整；
检索到的保单内容是判断的依据，本身不授权任何动作；
评估 agent 要看它处理过程中的每一步。

为了让 agent 可控：内部的编排、工具调用与约束

两篇综述为理解 agent 的构成提供了框架。Wang 等人把基于大语言模型的自主 agent 归纳为角色设定、记忆、规划和行动几个模块 [4]；Xi 等人从"大脑、感知、行动"三个部分讨论 agent 的构成 [5]。两者都说明，一个可用的 agent 大部分工程量在模型之外。

在工具调用方面，ReAct 让模型交替产生推理步骤和具体行动，借助外部信息减少凭空编造 [6]；Toolformer 表明模型可以学会在需要时调用计算器、搜索等外部工具 [7]。我们的 agent 也通过有明确边界的工具查询保单、读取理赔记录。不过，这两项研究讨论的是模型能否调用工具，在受监管的业务里还要回答它是否被允许这样做。

τ-bench 正好针对这一点。它在零售、航空等客服领域测试 agent 同时面对用户、工具和领域政策时的表现，发现即使是较强的模型，任务成功率也不到一半，而且多次运行的结果并不一致 [8]。这对我们意味着两件事：保险业务要求的遵守不能只寄托在提示词上；评估时要看完整的交互过程，以及多次运行结果是否一致。

关于提示词的局限，Zamfirescu-Pereira 等人发现，非 AI 专家设计提示词时往往凭感觉试错，基于提示词的交互很脆弱 [9]。LMQL 把提示词当作程序来写，在模型输出上加入约束和控制流程 [10]。AI Chains 把复杂任务拆成若干步骤串联起来，在用户研究中同时提高了结果质量、透明度和可控性 [11]。受这些研究启发，我把行为约束从提示词里拿了出来：系统允许出现的字段、动作和工具各写成一份有限的清单，每类输出分别校验；一轮对话拆成"模型提出建议、系统批准、实际执行"三个可以分别记录的环节。

结构化输出也有代价。Tam 等人发现，严格的输出格式限制会降低模型的推理表现 [12]。因此，我让系统必须校验的部分保持窄而稳定，其余部分留给模型自然表达。

在上下文方面，Liu 等人发现，当相关信息位于长上下文的中间时，模型的表现明显下降 [13]。所以 agent 每一轮只装载当前需要的内容，包括当前理赔的快照、尚未解决的问题和最近几轮对话；完整的记录保存在外部，需要时再取。

在安全方面，Greshake 等人展示了攻击者可以把指令藏进应用会检索到的数据里，从而影响模型的行为 [14]；NeMo Guardrails 则提供了在模型之外定义对话约束的方法 [15]。我们据此把保单文档和客户上传的材料一律当作数据处理，不当作指令；伤亡、危险这类安全信号，在调用模型之前由系统先行检查。

在评估方面，Shankar 等人发现，评估大语言模型输出的标准需要由人来校准，而且人的标准会在评阅过程中不断变化 [16]。这提醒我们：自动化检查可以帮助发现问题，判断的标准仍要由人来定。

为了让 agent 服务于人：外部的用户旅程、分工与信任

客户旅程研究把客户经历的一连串接触点作为分析和设计的单位 [17]。我们也以报案旅程为设计单位，从客户说出第一句话开始，一直到员工接手。

在人与 AI 的分工上，Huang 和 Rust 把服务任务分为机械、思考和情感三类，认为在当前阶段，机械性服务主要交给 AI，思考性服务由 AI 与人共同承担，情感性服务主要由人承担 [18]。这与我们的分工相对应：信息的整理和记录交给 agent；保障、责任这类需要专业判断的问题，由 agent 整理依据、员工做决定；客户处在紧急情况或情绪困扰中时，尽快转交给人。

Xiao 等人在约 600 名参与者的实地研究中比较了普通在线问卷和 AI 驱动的对话式问卷，发现对话式问卷带来更高的参与度，开放回答的信息量、相关性、具体程度和清晰程度也更好 [19]。这支持我们用对话代替长表单来收集事故描述。

关于聊天机器人的"人设"，研究给出了两方面的提醒。Adam 等人发现，拟人化的语言线索和先提小请求、再提大请求的方式，能提高用户对聊天机器人请求的配合度 [20]；Crolic 等人则发现，当客户带着愤怒进入对话时，拟人化反而会降低满意度，原因是拟人化抬高了客户的预期 [21]。刚出事故的客户可能焦虑或生气，所以我们的 agent 人设保持克制：语气专业、友好，不刻意扮演真人，把事情办清楚放在首位。

在人机交互设计上，Yang 等人指出，AI 能力的不确定性和输出的复杂性，是人机交互难以设计的两个根源 [22]；Amershi 等人提出了 18 条人机交互设计准则，包括让用户清楚系统能做什么、支持用户高效地纠正错误 [23]。据此，我们在界面上展示 agent 已经记录了什么、每条信息的来源是什么，客户可以直接修改，也可以用自然语言要求纠正；后端还不具备的能力，界面上如实显示为不可用。

最后是信任。研究发现，人们常常过度依赖 AI，而给出解释并不一定能减少这种依赖。Bansal 等人发现，解释反而提高了人接受 AI 建议的概率，无论建议是否正确 [24]；Vasconcelos 等人发现，只有当解释降低了核实 AI 判断的成本时，过度依赖才会减少 [25]；Buçinca 等人设计的"认知强制"方法能减少过度依赖，但用户不太喜欢这种方式 [26]。这些研究影响了员工一侧的设计：员工一侧的 agent 只出建议稿，员工编辑确认后才会执行；欺诈只以附带来源的信号出现，不给出结论；每条事实都附上来源，让员工核实的成本足够低。

这些研究放到理赔场景里的局限

上面的研究大多基于通用任务，或者零售、航空这类客服场景。保险事故后客户的情绪更强，业务要求又涉及保单条款和监管，这些结论需要在我们的场景里重新验证。团队坚持做真实的完整流程测试和盲测，原因也在这里。

其他方向的调研

在前端方面，我读了《Refactoring UI》[27]，逐节判断哪些原则适合我们的产品，并参考业界成熟的产品，把最初简陋的原型改造成两端统一的设计体系。设计的调性来自行业 mentor 分享的一个观察：用户真正信任的，是一位专业、站在自己角度考虑问题的私人客户经理。据此，界面采用温和的米白底色，强调色只用在有含义的地方，待补的材料不用红色标注，客户端正文不小于 16px；颜色、字号、间距等设计要素被整理成两端共用的设计变量。

在响应速度方面，为了控制 agent 的响应时间和调用成本，我还调研了几款主流 AI 编程工具和 agent 框架如何装载上下文 [28]，由此得出一个结论："让模型知道某项内容存在"和"本轮把这项内容的全文发给模型"应当分开处理。

目前做到了哪一步

目前为止，系统已经能在车辆、房屋和财物三类场景中完成一次由真实模型驱动的报案：从客户的自然描述开始，agent 从一句话中提取多条事实并注明来源，按需要追问，识别伤亡信号和人工请求并及时转交，在客户同意后发起评估等第三方服务请求，最后在模拟的理赔系统中创建理赔，或者把带有完整上下文的案件交给员工。客户端和员工工作台基于同一份理赔记录工作，员工可以查看来源、缺口和风险信号，并推进下一步。考虑到真实部署中可能有的数据隐私要求，系统可以在云端模型和部署在团队服务器上的本地模型之间切换。

仍未完成的部分也需要说明。目前的测试主要基于合成数据和模拟服务，还没有接入真实的保险公司系统；向 AWS 云环境的迁移由负责后端的队友推进；100 次完整流程测试和真实盲测，将在冻结后的最终版本上进行。

在最近一次阶段性sprint presentation feedback中，业界评委指出系统的理赔流程需要更贴近真实业务。比如在真实的追尾事故中，报案人通常会先记下对方的车牌、驾驶人和保险公司信息；有人受伤时，往往会有警方介入；责任归属不同，免赔额的处理也不同。我们据此重新调研了真实的报案流程和客户经理的提问顺序，把后续工作分为四块：

补充对方信息、目击者、警方报告状态等必要字段；
让 agent 更主动地确认安全情况、追问关键信息，并在转交人工时说明原因；
在保单条款需要专业判断的地方，由 agent 整理依据、提出初步意见，交给员工决定；
把客户的保单和具体的免赔额结构关联起来。

接下来的工作是：冻结功能版本并完成上述测试；基于同一个版本录制演示视频，完成 slides 和 poster；之后在最终展示和报告中总结整个项目。

References

[1] Financial Markets Authority, "Weather events claims insights," Jul. 2025. [Online]. Available: https://www.fma.govt.nz/library/reports-and-papers/weather-events-claims-insights/

[2] Google Cloud, "Dialogflow CX: Pages." [Online]. Available: https://cloud.google.com/dialogflow/cx/docs/concept/page

[3] Rasa, "Flows." [Online]. Available: https://rasa.com/docs/reference/primitives/flows/

[4] L. Wang et al., "A survey on large language model based autonomous agents," Frontiers of Computer Science, vol. 18, no. 6, 2024, doi: 10.1007/s11704-024-40231-1.

[5] Z. Xi et al., "The rise and potential of large language model based agents: A survey," Science China Information Sciences, vol. 68, 2025, doi: 10.1007/s11432-024-4222-0.

[6] S. Yao et al., "ReAct: Synergizing reasoning and acting in language models," in Proc. Int. Conf. Learning Representations (ICLR), 2023.

[7] T. Schick et al., "Toolformer: Language models can teach themselves to use tools," in Advances in Neural Information Processing Systems 36 (NeurIPS), 2023, doi: 10.52202/075280-2997.

[8] S. Yao, N. Shinn, P. Razavi, and K. Narasimhan, "τ-bench: A benchmark for tool-agent-user interaction in real-world domains," in Proc. Int. Conf. Learning Representations (ICLR), 2025.

[9] J. D. Zamfirescu-Pereira, R. Y. Wong, B. Hartmann, and Q. Yang, "Why Johnny can't prompt: How non-AI experts try (and fail) to design LLM prompts," in Proc. CHI Conf. Human Factors in Computing Systems, 2023, doi: 10.1145/3544548.3581388.

[10] L. Beurer-Kellner, M. Fischer, and M. Vechev, "Prompting is programming: A query language for large language models," Proc. ACM on Programming Languages, vol. 7, no. PLDI, 2023, doi: 10.1145/3591300.

[11] T. Wu, M. Terry, and C. J. Cai, "AI chains: Transparent and controllable human-AI interaction by chaining large language model prompts," in Proc. CHI Conf. Human Factors in Computing Systems, 2022, doi: 10.1145/3491102.3517582.

[12] Z. R. Tam et al., "Let me speak freely? A study on the impact of format restrictions on large language model performance," in Proc. Conf. Empirical Methods in Natural Language Processing: Industry Track, 2024, doi: 10.18653/v1/2024.emnlp-industry.91.

[13] N. F. Liu et al., "Lost in the middle: How language models use long contexts," Transactions of the Association for Computational Linguistics, vol. 12, 2024, doi: 10.1162/tacl_a_00638.

[14] K. Greshake et al., "Not what you've signed up for: Compromising real-world LLM-integrated applications with indirect prompt injection," in Proc. 16th ACM Workshop on Artificial Intelligence and Security, 2023, doi: 10.1145/3605764.3623985.

[15] T. Rebedea et al., "NeMo Guardrails: A toolkit for controllable and safe LLM applications with programmable rails," in Proc. Conf. Empirical Methods in Natural Language Processing: System Demonstrations, 2023, doi: 10.18653/v1/2023.emnlp-demo.40.

[16] S. Shankar et al., "Who validates the validators? Aligning LLM-assisted evaluation of LLM outputs with human preferences," in Proc. ACM Symp. User Interface Software and Technology (UIST), 2024, doi: 10.1145/3654777.3676450.

[17] A. Følstad and K. Kvale, "Customer journeys: A systematic literature review," Journal of Service Theory and Practice, vol. 28, no. 2, 2018, doi: 10.1108/JSTP-11-2014-0261.

[18] M.-H. Huang and R. T. Rust, "Engaged to a robot? The role of AI in service," Journal of Service Research, vol. 24, no. 1, 2021, doi: 10.1177/1094670520902266.

[19] Z. Xiao et al., "Tell me about yourself: Using an AI-powered chatbot to conduct conversational surveys with open-ended questions," ACM Transactions on Computer-Human Interaction, vol. 27, no. 3, 2020, doi: 10.1145/3381804.

[20] M. Adam, M. Wessel, and A. Benlian, "AI-based chatbots in customer service and their effects on user compliance," Electronic Markets, vol. 31, 2021, doi: 10.1007/s12525-020-00414-7.

[21] C. Crolic, F. Thomaz, R. Hadi, and A. T. Stephen, "Blame the bot: Anthropomorphism and anger in customer-chatbot interactions," Journal of Marketing, vol. 86, no. 1, 2022, doi: 10.1177/00222429211045687.

[22] Q. Yang, A. Steinfeld, C. Rosé, and J. Zimmerman, "Re-examining whether, why, and how human-AI interaction is uniquely difficult to design," in Proc. CHI Conf. Human Factors in Computing Systems, 2020, doi: 10.1145/3313831.3376301.

[23] S. Amershi et al., "Guidelines for human-AI interaction," in Proc. CHI Conf. Human Factors in Computing Systems, 2019, doi: 10.1145/3290605.3300233.

[24] G. Bansal et al., "Does the whole exceed its parts? The effect of AI explanations on complementary team performance," in Proc. CHI Conf. Human Factors in Computing Systems, 2021, doi: 10.1145/3411764.3445717.

[25] H. Vasconcelos et al., "Explanations can reduce overreliance on AI systems during decision-making," Proc. ACM on Human-Computer Interaction, vol. 7, no. CSCW1, 2023, doi: 10.1145/3579605.

[26] Z. Buçinca, M. B. Malaya, and K. Z. Gajos, "To trust or to think: Cognitive forcing functions can reduce overreliance on AI in AI-assisted decision-making," Proc. ACM on Human-Computer Interaction, vol. 5, no. CSCW1, 2021, doi: 10.1145/3449287.

[27] A. Wathan and S. Schoger, Refactoring UI. 2018.

[28] Anthropic, "Effective context engineering for AI agents." [Online]. Available: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents