实习日志 / 实习 Journal 1 & 2(合并提交)

实习 Journal 1 & 2(合并提交)

项目:Scenario 08 — Northwind FNOL Agent,CS778 AWS Challenge 作者:Leif (Zhixuan Wei) 覆盖阶段:Milestone 1(用户调研与 Prototype)、Milestone 2(MVP 至今)

1. 项目与工作环境

Northwind 是本场景中的虚构保险公司,每年处理超过八万件车辆、房屋和财物理赔。按 Scenario 8 的简报,它现有的首次报案(FNOL)流程需要 15 到 25 分钟,四成报案至少需要一次追加联系,从首次报案到 claim 创建平均要 2.5 天。它目前依赖两个渠道,各有代价:电话客服听得懂自然语言、处理得了例外情况,但人力成本高,难以扩张;网页表单结构化、随时可用,但冗长僵硬,问题不会随事故情况调整,而刚出过事故的人没有多少耐心对付一张长表单。两个渠道都缺少系统性的照片和文件收集。

Scenario 8 要求我们做一个能从客户第一句描述一直引导到 claim 创建的理赔 Agent。我们把它理解为一个协调问题:生成一句得体的回复并不难,难的是把一段不完整、可能跳跃的讲述变成可靠的 claim 记录,判断现在还缺什么、什么可以先推进,以及在需要专业判断时把案件连同完整上下文交给人。由此形成我们的产品主张:让客户自然地讲发生了什么,系统承担背后的保险结构、证据追踪和流程推进,并持续负责把 claim 带到下一个安全步骤。主张落实为两个核心能力:一是自适应的报案过程,问题的多少和深浅随事故与客户的情况变化;二是一份客户、Agent 和员工共同工作于其上的 claim 记录,交接时上下文完整保留,客户不必向接手的员工把事情再讲一遍。

我们是五个学生组成的团队,在这个 in-house 实习项目里以两周为一个迭代周期,通过 GitHub 仓库和 Kanban 项目板协作。我在项目中的职责是:Agent 本体的行为设计与模型接入,claimant 端界面与员工 Workbench 的设计和重构,迭代计划与 Kanban 板的管理,以及贯穿整个开发过程的仓库治理与 CI 体系的建设和迁移。

2. Milestone 1:用户调研、用户痛点与用户旅程

调研,与我们的顺序错误

合理的路径本应从用户需求出发,我们却直接开始了产品设计:界面、流程、API。第一次Sprint过后,我们开始意识到了找出用户旅程中真实的关切和痛点的重要性,而不是想当然地闭门造车。用户调研由团队在设计已经开始之后并行完成。

调研给了我们扎实的东西。我们回收了 155 份有效问卷,做了行业访谈和用户观察,分析了公开的客户投诉和行业资料,把用户归纳为三类:第一次报案的人、追求效率的人、处境紧急或案情复杂的人。核心发现是:问题不只是表单长。用户在理赔中失去信心和掌控感,来自一串"不知道":事故后第一步该做什么,需要收集什么证据,保险公司拿到的信息够了没有,接下来会发生什么,下一步该谁负责;用了 AI 之后还要加上两条:它到底有没有听懂我,情况变严重时人工会不会接手。在有过理赔经历的受访者里,约三分之一表示当时不清楚需要提供哪些信息;被问到最看重什么时,将近一半的人选了"要求清晰"和"材料上传简单"。大家要的是一个有引导、透明、连续、随时能找到人的过程。这些发现直接支撑了我们的两个核心能力:按情况提问;让进度、责任方和下一步始终可见,交接时带上完整上下文。

调研过程也暴露了我们的盲点。它是探索性的:个别题目的作答人数很少,空白答案只能算缺失,结论足以支撑优先级判断,不足以当作人群统计;员工一侧的证据主要来自公开流程资料和一次有限的行业访谈,仍需要真正的理赔员工来验证。我们在后来的设计里保留了这些保留意见,没有把探索性结论当成定论用。

我的部分:把结论变成可验证的旅程

调研主要由队友完成;我在这个阶段做的是"转译",把调研结论变成可验证的开发计划。我把产品目标拆成十六条功能需求和十二个验收场景,每个场景都描述一段可以观察的完整经历:客户描述一起追尾,系统生成一份 claim 草稿,每条事实都记着出处;客户提到有人受伤,正常的信息收集立即停下,案件转给人;客户一周后回来,能从上次停下的地方继续。团队定的完成标准是:每条演示路径都必须真实改变系统状态,不接受静态演示。

随后我试着实现了第一批旅程,作为一个 good first issue:接上真实接口的引导式报案,报告受伤或危险时的紧急中断和人工支持路径,以及从事实采集、员工交接到客户可见状态回写的完整一条线。其中两个设计决定一直沿用:还没生成的材料(比如要一周才出的警方报告)只挂起它自己,案件里其他可以安全推进的部分照常推进;客户明确要求人工时立即照办。两条都来自调研里的真实抱怨:单件材料拖住整个案子,求助人工时被系统反复挽留。

3. Milestone 2:从 Prototype 到 Validation Prototype

Prototype 证明了这些旅程说得通。但那时的"Agent"是一段固定脚本,缺一套行为准则,也缺少可交给它消化的数据;界面和协作方式同样是临时的。这个阶段我的工作是把支持我们设计思想的原型推向真实:一个由真实模型驱动、且每一步都可核查的 Agent;一套吸收了优秀前端实践、以用户痛点和我们的设计主张为中心设计出来的界面;一套人人可以依赖的协作方式。

3.1 Agent:行为先行,模型最后

写 Agent 文档和代码契约之前,我先调研了成熟系统是怎么做对话式服务的,包括主流对话平台 [1][2][3][4][5]、保险行业的垂直产品 [6][7][8][9][10][11],以及支撑长流程的基础设施 [12][13][14][15][16][17][18][19][20][21][22]。厂商材料的可靠性差别很大,我给每个来源分了级:官方技术文档、公开可读的实现、看不到内部的产品宣称、我自己的推导,并排除了一部分营销性质的宣称。

这些系统在一个问题上高度一致:模型负责理解和表达,应用负责事实、权限和流程。我据此设计了我们自己的行为体系,第一步是把一轮对话里混在一起的东西拆开:用户意图(客户这一轮想解决什么),交互动作(这一轮怎么沟通:回答、澄清、确认还是解释),claim 命令(对 claim 记录的受控修改),工具调用(查保单、登记材料这类有边界的能力),运行时控制(继续、等待、中断、转人工)。旧原型用八个混合动作表达这一切,一个动作既是回复方式又是状态变更,没法分开校验。拆开之后,一轮对话产出的是一份多维的计划:客户的一句话,可以同时得到回应、生成几条带出处的字段更新、触发一次保单查询、再排出下一步,每一类都单独校验、单独留痕。

约束从两处来。一处是注册表:系统允许存在的字段、动作和工具是一份有限清单,各自带校验规则和权限要求,模型只能在清单内提议,清单外的提议直接被拒。另一处是把 claim 的"内容"和"进度"分成两台状态机:内容分支回答这起事故涉及什么(车辆、碰撞、涉及第三方、警方报告未出),可以叠加;生命周期回答案件推进到哪、在等谁,转换由应用控制。动态表单是这两台状态机的投影:客户一句话可以同时填上好几个字段,每个字段带着值、出处和确认状态,纠正时旧值留在历史里;下一个问题按当前动作真正缺什么来选,凑够了就推进,不逐题过表单。

模型接入层单独成一块,理由有两个。一个是成本和可用性:我们不能被单一供应商的价格和故障绑死,评估和替换模型必须是低成本的事。另一个来自这个阶段收到的明确建议:保险数据有隐私要求,真实部署里可能不允许把数据交给云端模型,必须有一个解释得清的 plan B,换成本地部署的模型。所以接入层的设计目标是:行为契约不动,换模型只是换一个 adapter,不同接口和字段结构的差异在 adapter 里消化;每个模型档案登记它验证过的能力,没验证过的用途不许承担。

这些设计到今天已经大部分落进主分支。行为目录写成了带结构校验的正式文档,十五种行为各自登记触发条件、必须产生的结果、禁止产生的结果和失败时的行为;五个命名空间的动作注册表进入后端,每个动作带版本、封闭的输入定义、执行所需的权限和副作用分级。模型接入层支持 OpenAI 兼容的官方、中转和本地端点,每次调用前先核对选定的模型档案:身份、协议、隐私等级、提示词版本、超时和评估状态,不满足就拒绝调用。三种场景的报案路径接通了真实模型,用版本化提示词和严格的结构化输出从客户一句话里提取多条带出处的事实,失败的轮次不写入任何部分状态。刚完成的一步是把三条产品线的字段目录和分支规则做成可执行的后端契约:车辆、房屋、财物是互斥的产品家族,家族只能由已确认的事实选定,模型推测的值停在候选;客户纠正后分支重新计算,退出的分支连同来源进入历史,不静默删除。Agent 经手的每个动作现在还有统一的审计记录格式,谁发起、影响谁、依据什么授权、真实结果如何,包括失败和结果未知,都必须记全;这份契约由代码生成,CI 盯着它和文档不漂移。队友的工作也在这条线上会合:接入层的配置和错误处理补全了,真实模型供应商的校验加固了,保单和历史理赔的查询接进了对话轮次。要如实记录的边界是:仓库默认运行的仍是受控脚本,接真实模型是显式的配置动作;live 路径的配置、传输和供应商校验都有测试,在合成数据下跑通,还没有成为三条产品线演示的默认路径。

3.2 界面重做:把调研的账还上

这个阶段的后期,我对客户端和员工端做了一次完整E2E检查,结果不好看,而且多数问题能追溯到 Milestone 1 的顺序错误。客户落地页有六个入口,没有主次,三种理赔类型里两种点进去是死路。登录旅程是断的:登录或注册成功后,用户被送进一个孤立的账户页,那里的返回键回到的是入口页,找不到刚才的对话;用户判断不了登录成没成功,也找不到刚开始的 claim。页面元素在互相堆叠,营销区块、材料准备清单、演示控件和聊天挤在同一层。引导表单一屏放了九个字段,违反我们自己"一次只问一个主要问题"的设计主张。页面上挂着一个固定的"第 1 步,共 3 步"进度条,可实际流程装不进三步:经过人工交接、等待材料的案件都放不进去,这个进度条给客户的把握是假的。正文字号低于无障碍下限。员工端是一个十五万字符的单文件 HTML,关键信息藏在鼠标悬停里,键盘用户够不到,演示控件混在正式功能里。这些问题没有哪条能怪到某个人头上,它们是界面决策跑在用户理解前面时攒下的债。

我用两天多完成了从设计到落地的重做,起点是把调研里的 persona 变成一套设计规则,同时为两个前端设计一套共享的视觉语言。调研给出的形象,经行业 mentor 的帮助进一步明确:理赔中的人信任的是一个安静把事办妥的专人,产品应该像一位 private client manager。我据此定下具体选择,每条都有理由。底色用温暖的米白,强调色我看过竞品后选了灰调的绿:保险业把代表信任的蓝和代表安全的绿用滥了,放在一起只剩模板感,辨识度来自克制,所以强调色只出现在有含义的地方,比如一条新确认的事实。待补材料永远不用红色标,一个还没回答的问题算不上警报。层级靠底色深浅建立,页面、侧栏、面板逐级加深,不靠线框和阴影。这些选择没有停留在设计稿里:我把颜色、字号、字重、间距、圆角、边框和状态语义整理成一份两端共用的 token 库,组件样式只能引用 token,不许散落色值,同一个语义只有一个 token。两端共享同一套性格,但各有各的信息密度:客户端正文不小于 16px,优先降低认知负担;员工端可以更紧凑,但负责状态和动作的文字不许缩到难读。

两端也都从单文件页面迁移到组件化结构,状态、路由和样式各有边界,改一个按钮不再牵动另一个页面。路由带状态保护:刷新、后退和直接输入网址都先经过校验,不会渲染出半个页面。还有一条原则贯穿两端:界面上不摆产品没有的能力。文件、语音这些控件,后端没就绪就明确显示不可用及原因;该等待就显示等待,该失败就显示失败,不用静态文案伪装成功。流程状态是唯一事实源,界面只是它的投影。

客户端重做后,对话是唯一的主入口。总的来说，现在的客户端有点像gpt或者Claude的网页版，但是有我们的明确特色：旁边一块"目前我们了解到的"区域列出每条事实的值、出处和状态,本轮新增的会标出来。客户想改哪条,可以直接改,也可以在对话里直接用自然语言要求 Agent 纠正。模型提出的内容要客户确认才生效,并有并发保护,旧页面不会覆盖新事实。登录旅程被拉直:没登录也可以先开始报案,登录成功直接回到对话,匿名开始的 claim 关联到账户,账户页只从 Profile 进。

员工端我按员工的工作顺序重新组织:第一屏回答现在该处理哪个 claim、它卡在哪、下一步是什么;动作区只显示当前状态允许的操作,同一时刻突出一个主动作;证据、历史和完整对话作为参考资料按需展开。欺诈线索只作为附带出处的信号出现,交给专业人员复核,界面上永远没有"欺诈"结论。处理一个 claim 要先显式认领,认领是原子操作,两个人不会同时改一份。员工侧的 Agent 只出建议稿,员工自己编辑并确认后才变成动作,执行时还要再验一次权限。

这次重做怎么定案,和重做本身一样花了心思。它触及好几个人的工作范围,我写了一份汇总文档,合并之前六份设计草稿,写明冲突时以什么为准,每条结论都标了状态:已确认、当前事实、待讨论。过程中产生了十三个我一个人无法独自拍板的决定,包括最终视觉调性和布局密度,我整理成议题交给团队讨论。重做文档里同时写明:前端不发明后端字段,需要新字段,先向后端负责人提交书面提案。

3.3 治理:教会一个团队(和它手里的工具)协作

这条工作线从第一周持续到现在。起因是一个观察:队友们大多没在专业运作的仓库里工作过,分支保护、有内容的代码评审、写清楚"怎样算完成"的任务单,这些实践对大家是新的。我的做法是让仓库自己示范:把协作规则和模板搭好,再配上自动化,任务卡随开发进度自动流转,谁都不需要把整个项目装在脑子里才能干活。后来我们很荣幸地得知,我们是十三个组里唯一实现了仓库任务与 Kanban 看板自动同步的组。

规则写下来,并不等于规则成立。转折点是我看到一份改动在检查全部失败的情况下被通过并合并,主分支坏了,又用一份新改动去修。我从这件事得出的教训很具体:提醒对人有效但因人而异,对拿着不完整上下文干活的 AI 工具则几乎无效,而队友们都在用这类工具。于是我把规则做成可执行的:一份人和工具都会读到的权威规则文档,一道推送前的本地检查,以及服务端谁也绕不开的合并门槛;后来又把门槛前移到创建阶段,一份说不清要解决什么问题的任务单,在任何人为它花时间之前就会被标出来。

然后,基础设施出了一次任何规则都没预料到的事故。我把检查做得很全面,加上那套看板同步,消耗了十三个组共用配额的 90%。一个下午配额烧干,管理员随即在整个组织停用了 CI 服务。这个问题从头到尾由我处理:当晚试了两家云厂商的免费虚拟机,一台都开不起来,只好连夜把等不起的两样东西,合并检查和看板同步,重建在免费的 serverless 平台上,其间调试了一个只在真实事件下出现、本地复现不了的运行时错误;第二天我向新的 CI 平台提交组织访问申请,并给仓库管理员发邮件说明情况,审批通过后完成迁移。这件事技术上教会我在压力下重建关键链路,并用真实流量验证;沟通上教会我,涉及别人审批的事要第一时间开口,不能让仓库停摆等我试遍所有技术方案。

事故之后,我重新想了一遍:什么样的检查值得一个团队信任。我的答案有四条,后来都做进了仓库。检查的证据必须真实:远端没跑,就要求本地真实跑出结果,谁也不能声称一份不存在的通过记录。失败必须可解释:查不出原因的红灯,只会教人学会忽略红灯。检查不能绑死在单一平台上:这次事故证明平台说停就停,所以合并要求挂在平台中立的状态上,换平台不用改规则。检查的开销要和改动匹配:我把整条检查链改成按影响面运行,只改文档的提交不再跑完整后端检查,普通改动只检查受影响的部分和它的直接使用方,主分支仍然全量。曾经烧掉全组织配额的那套检查,现在按需花力气。

3.4 计划与看板

整个时期的计划和看板由我管理,方式随着暴露出的问题改过几次。最初把目标拆成天粒度的任务,不固定角色,结果每个人每天散在六八个碎片上,任务之间还相互阻塞。之后改成每人稳定负责一条技术栈,产品路径跨栈并行,栈与栈之间靠接口约定衔接,没准备好的依赖先用测试数据顶上。再往后发现纵向切面各自推进,合不出用户可见的完整结果,验收也不明确,于是改成以任务为目标:一张任务对应一个可以完整验收的功能,而每项能力配一份状态清单,标注已验证、部分可用、未开放还是依赖测试数据。"做完了"从一句话变成有等级的陈述,演示不能再悄悄踩在一个大家都忘了的测试替身上。

4. 职业成长与反思

先懂业务,再做设计。 我把保险当成了背景板:第一周我参与设计了一个我们没人真正了解其理赔流程的产品,后来补的调研,包括现行报案流程、字段要求和已有的欺诈控制,实际上是本该先做的功课。后来那次界面检查像一张账单,每条问题背后都是一处界面替用户做了想当然的假设。我带走的习惯是:设计任何界面之前,先能说出每个元素回应的是哪条经过调研证实的事实。

GitHub 协作的真实深度。 项目之前我以为自己会用 Git 和 GitHub,实际上我会的是一个人用。五个人并行才会遇到的问题,都是我在这个项目里第一次撞上。任务归属:一份任务分给了 A,B 悄悄把它做完,带来的是怨气和说不清的作者身份,我们后来规定,剩余工作要转移,必须写一份边界清楚的书面说明。评审链条:五个人同时评审时,任何一次合并都可能让其他所有进行中的评审作废,因为它们指向的版本已经过期,我学会了像排任务依赖一样排合并顺序,并要求评审必须针对当前版本。CI 是共享且有限的资源,配额事故让我明白,检查链的设计同时是预算设计。还有一课来自平台本身的局限:平台只能识别账号,分不清账号背后是人还是工具在操作,所以规则只能约束行为,放弃猜测身份。最后是讨论区的用法,它适合承载那些在任务存在之前就需要先拍板的提案。

好的Agent到底设计了什么。 做完这个阶段,我能说出这件事的工程量在哪里:模型是整个系统里最小的部件。围绕它,我们需要一份不依赖提示词的行为边界;需要把"模型建议、系统批准、实际发生"分成三件事分别记录;需要一份封闭的字段和动作清单,模型不能发明清单外的东西;需要一层供应商中立的接入,模型可以换,产品行为不变;需要区分"可以重试""不能重试""结果未知"的错误处理,凡有副作用的地方都要防重复执行;需要在模型开口之前先跑的安全检查,伤亡这类信号轮不到模型判断;需要把检索出来的文档和客户上传的材料一律当数据,不当指令;需要每条事实的出处和确认状态;需要评估完整的处理过程,光看最后一句回答,会漏掉中间的越权和错误。这些没有一样是模型自带的。压缩成一句:agent 工程是使用模型的流畅,同时不继承它的权威。

与人共事。 治理工作改变了我的沟通方式。早期我直接纠正队友的流程错误,结果是我成了瓶颈,偶尔还成了坏人。后来我让系统去给反馈,一个失败时附带书面理由的检查,能教会同一课,而且不附带一张具体的脸。人和人的讨论留给真正的设计分歧,界面重做时那份议题清单成了我的模板:写清楚要决定什么,诚实列出选项,交给团队。

5. 下一步

接下来的阶段要把 MVP 变成 Validation Prototype。我们要证明两件事:报案过程能根据情况自适应,并且值得客户信任;客户、Agent 和员工工作在同一份 claim 记录上。演示会覆盖三条产品线,运行时的测试替身退役,换成真实服务。我负责 Agent 的行为与提示词、动态表单、客户端界面,以及流程状态机里 Agent 的一侧。Journal 3 和 4 将覆盖这个阶段,并向 final report 收拢。

参考文献

[1] Google Cloud, "Dialogflow CX: Pages," https://cloud.google.com/dialogflow/cx/docs/concept/page [2] Microsoft, "Generative orchestration in Copilot Studio," https://learn.microsoft.com/en-us/microsoft-copilot-studio/advanced-generative-actions [3] Genesys, "About Genesys Agent Copilot," https://help.mypurecloud.com/articles/about-genesys-agent-copilot/ [4] Intercom, "Fin Procedures explained," https://www.intercom.com/help/en/articles/12495167-fin-procedures-explained [5] AWS, "Amazon Connect Cases," https://docs.aws.amazon.com/connect/latest/adminguide/cases.html [6] Hi Marley, "Claims," https://www.himarley.com/claims/ [7] Sprout.ai, https://sprout.ai/ [8] Five Sigma, https://fivesigmalabs.com/ [9] Shift Technology, "Claims solutions," https://www.shift-technology.com/solutions/claims [10] Indemn, https://www.indemn.ai/ [11] AWS Samples, "Serverless EDA insurance claims processing," https://github.com/aws-samples/serverless-eda-insurance-claims-processing [12] Rasa, "Flows," https://rasa.com/docs/reference/primitives/flows/ [13] LangChain, "LangGraph durable execution," https://docs.langchain.com/oss/python/langgraph/durable-execution [14] Temporal, "Workflow execution," https://docs.temporal.io/workflow-execution [15] Open Policy Agent documentation, https://www.openpolicyagent.org/docs/latest/ [16] AWS, "Amazon Bedrock Knowledge Bases: retrieval configuration," https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-config.html [17] AWS, "Amazon Bedrock Guardrails," https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html [18] Microsoft, "Security trimming in Azure AI Search," https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search [19] LiteLLM documentation, https://docs.litellm.ai/docs/ [20] OpenAI, "Structured Outputs," https://developers.openai.com/api/docs/guides/structured-outputs [21] Anthropic, "Building effective agents," https://www.anthropic.com/engineering/building-effective-agents [22] Anthropic, "Effective context engineering for AI agents," https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents