做保险理赔Agent项目的团队越来越多但真正让我觉得值得拿出来分享的不是某个Agent本身而是后面那套自动化定损的Harness。这个词国内用得还不多用大白话说它就是给Agent搭建的“试车跑道和仪表盘”没有它模型跑得好不好只能凭感觉有了它每一次推理过程、每一个工具调用、每一个错误决策都能被记录、回放、量化。这篇文章就围绕保险理赔Agent和自动化定损Harness的搭建思路展开重点讲清楚这套系统解决什么问题、核心模块怎么拆、踩过哪些坑以及从零跑通一个可评测闭环的关键经验。1. 为什么需要一套定损Harness而不是只做Agent1.1 理赔定损场景的真实痛点先还原一下业务现场。理赔员每天处理案件时车上拍的是一堆角度混乱的照片报案描述写着“我车被蹭了一下”“倒车撞到柱子”这类口语化内容。传统做法是人为比对照片、查配件库和工时标准再结合经验估算维修费用。这个过程慢、容易漏也给后续核赔带来大量沟通成本。引入Agent的目的是让模型自动完成信息抽取、图片证据分析、配件查询、费用估算和建议生成。但这里有一个很容易被忽略的事实保险理赔是强规则、强证据、强解释的领域它不像写文案或画图那样“差不多就行”。如果Agent给出的定损建议没有依据、引用不准、甚至把左侧车门照片当成右侧来估价业务方根本不敢用。所以真正的瓶颈不是模型能力而是怎么证明模型每一次输出都可靠、可复现、可追溯。Harness就是为解决这个问题而存在的。它不是一个业务系统而是开发和测试Agent的工程基础设施。它包含场景生成、流程编排、工具调用记录、结果评估和回归对比让Agent在受控环境下反复验证而不是直接放到生产环境里赌运气。1.2 Harness在工程上的定位与价值我习惯把Harness理解成“流水线上的检测台”。汽车组装完要过检具芯片焊好要过测试座Agent跑完也要过一套评估装置。这套评估装置的职责有三层第一约束Agent的行为边界比如规定输出JSON结构、规定工具调用顺序第二记录完整过程从收到案件到最终报告之间每一句话、每一个中间结果都留痕第三提供量化反馈让开发者能说出“这次改动让定价误差下降了多少”“哪类场景失败率上升了”。我们团队内部曾走过一段弯路最初的方案只有Agent没有Harness开发时用几个固定例子肉眼判断效果改完Prompt觉得“看起来合理”就上线。结果到了用户反馈阶段同一个案件在不同时间跑出的结果不一致又没有过程日志根本定位不了是哪一步出了问题。后来把Harness补上第一周就把一个隐藏了很久的图片理解bug找了出来。也是从那时起我确定了一个原则没有回放和评估能力的Agent项目不应该进入生产环节。1.3 影响范围不止定损还覆盖反欺诈与客服从影响范围看这套Harness天然具备扩展性。定损流程里清洗好的证据链可以复用给反欺诈模型做风险提示Agent沉淀的高质量问答对也能喂给理赔客服机器人。它本身的价值是长在数据、工具、评估这套底座上的所以后续每加一个Agent都只是往Harness上挂一个新的任务模板而已。2. 自动化定损Harness的整体架构与技术选型2.1 五层结构拆解一个可用的Harness我建议按五层来组织分工清晰、边界明确。第一层是任务编排层负责定义一次定损任务从开始到结束的步骤状态机第二层是Agent执行层承载推理链、结构化输出和工具调用第三层是工具能力层把OCR、车辆图片理解、配件库查询、工时费标准等外部能力封装成统一接口第四层是数据层管理案件场景库、图片样本库、报告模板和评估指标第五层是评估观测层负责trace记录、结果评分、基线对比和回归报告。用一张简化的运行流程来理解案件数据进入编排层编排层启动Agent执行层Agent按计划调用工具层接口所有输入输出实时写入评估观测层最后评估观测层给出量化报告。这个结构最大的好处是每一层都可以单独替换。模型换了、OCR服务商换了、场景库更新了都不影响其它层的工作。2.2 LLM选型与调用方式定损Agent的核心是LLM这里我不建议一上来就绑定某一家模型。我们的做法是分两档复杂度低的场景用开源中尺寸模型本地部署控制成本和时延复杂场景如多车事故、需要跨多份文档交叉核实的用云端商用大模型。两档模型由Harness的配置中心统一管理按场景标签自动路由。选型时我总结了三条经验。第一定损领域对知识密度要求高模型要认识常见车型、配件名称和维修工艺词纯对话能力强但行业词汇弱的模型跑起来很吃力。第二对结构化输出要求严格模型必须稳定输出JSON不能今天给数组明天给对象。第三对引用准确性要求高每一句“根据图片可见”都要能对应到具体证据这也决定了Harness里必须单独有一层做引用校验。调用方式上我们统一走函数调用function calling模式而不是让Agent自由发挥。每调用一次工具就记录一次结构化参数和返回值。这看起来多了一步却让后续排查时能精确知道Agent在什么证据上做了什么样的判断。2.3 Agent基类抽象要点代码层面我先把Agent执行过程抽象成统一的基类保证每个Agent都具备步骤控制、trace上报和结果校验能力。下面是一个简化示例实际项目中可以基于它扩展成更完整的框架。from typing import Dict, Any, List, Optional from dataclasses import dataclass, field dataclass class StepResult: step_name: str inputs: Dict[str, Any] outputs: Dict[str, Any] tool_calls: List[Dict[str, Any]] cost_ms: float class BaseAgent: 所有定损Agent的基类负责统一的流程控制与追踪。 def __init__(self, config: Dict[str, Any]): self.config config self.trace [] self.context: Dict[str, Any] {} def run(self, case: Dict[str, Any]) - Dict[str, Any]: # 子类实现具体步骤基类负责包裹process入口 return self.process(case) async def process(self, case: Dict[str, Any]) - Dict[str, Any]: raise NotImplementedError def record_step(self, step_name: str, inputs: Dict, outputs: Dict, tool_calls: List, cost_ms: float): self.trace.append(StepResult(step_name, inputs, outputs, tool_calls, cost_ms)) def get_trace(self) - List[StepResult]: return self.trace这段代码的作用是约束每一层实现都必须将步骤输入输出落盘。很多团队写Agent时很随性过程信息散落在日志里出问题根本对不齐。基类一旦定下来后续每一个Agent都必须遵循同一套trace协议评估层才能用统一逻辑分析。3. 定损Agent内部设计与实操要点3.1 工作流节点编排定损Agent和普通问答Agent有一个重要区别它必须有固定的工作流节点。我们的核心流程分为五步。第一步是任务理解从报案文本中抽取事故类型、车辆信息、损失部位、天气路况、是否有人伤等关键字段第二步是证据收集调用图片理解工具分析照片判断损伤部位和程度同时检查图片是否完整第三步是工具核实根据车型和部位查询配件编号、工时项目和价格标准第四步是生成建议综合前面所有信息输出损坏清单、维修方案和预估费用区间第五步是争议点说明主动列出当前证据不足或存在歧义的地方比如“无法判断划痕是否涉及钣金需要现场复核”。每一步之间不是简单的串联而是会做条件跳转。比如图片证据中识别出安全气囊弹出就走复杂事故分支需要额外查询维修级别和第三方核价规则。这种编排能力最好放在独立的状态机里而不是靠Prompt硬约束因为Prompt的稳定性远不如代码逻辑。3.2 可解释性设计理赔员要的是依据不是正确答案保险场景里模型就算给出正确答案如果说不清依据业务方依然会拒收。所以我们做了一个比较关键的机制每一句输出都绑定证据引用。具体实现是要求Agent在生成结论时使用类似Markdown引用的格式把证据编号写在句子末尾之后再通过解析器校验这些编号是否真实存在于已收集的证据列表中。这里我把Prompt里常用的规则总结成一段人话“只能引用工具返回结果和图片分析结果禁止引用你自己的常识如果没有证据就明确说证据不足而不是猜一个答案。”加上这条约束之前模型经常在照片模糊时脑补损伤加上之后误判率明显下降。可视化推理这块让理赔员能看到“引用了什么图片”“查了哪个配件”“为什么给出这个区间”信任度自然就上来了。3.3 工具层设计统一、幂等、可降级工具层很关键但它也是最容易做得混乱的一块。我建议所有外部能力都封装成统一接口入参出参都是JSON内部实现自己处理HTTP、超时、重试和鉴权。每个工具要保证幂等性同一个参数重复调用不产生副作用否则Agent做了多轮自我修正就会重复扣费或重复生成记录。OCR和图片理解是定损场景最高频的两个工具。OCR负责识别车牌、行驶证、发票等信息识别结果一定要带坐标和置信度车辆图片理解则要判断损伤部位、损伤类型、面积和严重程度。这里有一个实操上的取舍早期我们单独做目标检测模型识别划痕后面发现大模型的图文理解能力已经能覆盖大部分场景就直接换成VLM接口用小模型做预处理VLM做综合判断成本可控还少维护一路模型。工具调用必须要设计降级策略如果VLM超时就用OCR结果加规则判断至少保证主流程不直接中断。3.4 Prompt模板设计与示例定损Agent的Prompt不适合写太长太长的系统提示反而会稀释关键指令。我通常控制在800到1200字以内核心内容包含角色定义、约束规则、输出格式和少量典型示例。示例不要超过3个否则模型会学着示例的措辞写报告而不是按数据结构产出。下面是一段简化版Prompt结构实际项目中可以基于它扩展。你是一名保险车辆定损初级分析员。你的任务是根据案件描述和工具返回结果输出结构化定损建议。 约束1. 只使用输入中出现的证据2. 禁止编造配件编码或工时费3. 不确定时在争议点字段说明4. 输出必须符合给定JSON格式。 工具返回 - OCR结果... - 图片分析结果... - 配件库查询结果... 输出格式 { damage_items: [ {part: , action: , est_price: 0, evidence_ids: []} ], total_range: [0, 0], disputes: [] }模板准备好之后最重要的动作是把同一套场景分别在多个模型上跑对比输出稳定性。实测下来闭源商用模型一般比小参数开源模型稳定很多但如果场景比较规矩开源小模型加上严格的后处理校验也能用。4. 场景库与评估体系Harness的灵魂4.1 场景生成器从单一样例到覆盖矩阵Harness不能只测那几个手工设计的例子。每个例子都带有开发者的主观倾向容易把系统调成“只会做这套题”。所以我们做了一个场景生成器它会基于模板、车辆配置表、事故类型表和随机化规则组合生成大量测试用例。比如一个基础模板是“某车型某部位损伤报案描述模糊天气条件雨”生成器会随机组合出20个不同的变形场景。变形过程中会故意加入容易混淆的因素比如左右侧照片反装、报案金额和图片损伤不符、维修方案包含替换与修复两种选择等用来测试模型的抗干扰能力。每个场景都包含五个要素车辆档案信息、报案文本、图片列表、工具mock返回、期望动作。期望动作不是简单的答案而是“用户期望看到的关键字段集合”。例如某场景的期望是“识别出后保险杠破损、建议更换、证据引用包含图片编号和配件查询结果、定价区间落在某范围内”。4.2 评估指标体系我把评估体系拆成四个维度每个维度给具体权重最后算总分。结构合法性占20分检查输出是否满足JSON Schema、关键字段是否齐全业务完整性占30分检查信息抽取结果是否与场景预期一致定价准确度占30分考察定损区间与基准区间的重合率和误差证据充分性占20分计算结论句子中有多少比例携带了有效证据引用。这四个维度可以同时兼顾“格式正确”和“业务正确”。有些模型格式很标准但定价全靠胡编证据引用覆盖率还不到20%这种模型在总分上一样会不及格。Harness会把每个场景的评分明细存下来评分历史趋势也保留方便观察每次修改到底是变好了还是变差了。4.3 完整trace结构与回放机制回放能力是Harness和普通日志系统最大差别。普通日志只记录“输入输出”trace则记录每一个步骤的前后关系、工具调用的入参出参、模型的中间推理想法、消耗的token数和耗时。为了做到这一点我们给每个Agent实例分配唯一request_id所有子步骤都会带上这个ID写入trace中心。{ request_id: case-0042-run-001, case_id: case-0042, steps: [ { step_name: extract_info, inputs: {report_text: 倒车撞到柱子右后保险杠划伤}, outputs: {vehicle_type: sedan, damage_parts: [rear_bumper], weather: day}, tool_calls: [], cost_ms: 812 }, { step_name: analyze_images, inputs: {images: [img_01.jpg, img_02.jpg]}, outputs: {detected_damages: [{part: rear_bumper, type: scratch}]}, tool_calls: [vlm_image_analyze], cost_ms: 2300 } ] }拿到这份trace之后工程师可以看到Agent在哪个环节用的时间最长、哪次工具调用返回了空数据、哪一步输出的字段明显不符合常理。排错效率比裸看日志至少高一倍。我们还会用它做“差分对比”同一个案件跑新版和旧版模型并排对比trace找出行为差异。4.4 回归测试与多模型对比定损Agent会频繁经历prompt小改、模型升级、工具服务升级。如果没有回归测试每次改动都像在开盲盒。我们的做法是每次改动都跑一遍固定回归集回归集包含约200个场景从轻度划痕到多车事故都有覆盖。跑完后自动生成对比报告列出每个维度的得分变化。多模型对比也是靠Harness实现的。我们在接入新模型时让同一批场景在两个模型上各跑一遍得到A/B对比表。表格里能看到新模型在定价准确度上可能高了2分但业务完整性却掉了5分原因是它经常把“无法判断”写成“无损伤”。这类问题不通过量化对比很难发现。5. 从零搭一套最小Harness并跑通评测5.1 环境准备与项目结构假设你已经有一个可用的LLM接口本地还需要准备三样东西Python 3.10以上环境、一个文件型缓存数据库用来存场景和评估结果、一个可运行的OCR或图片理解服务开发期可用mock接口代替。项目结构我习惯这么组织。auto_estimate_harness/ ├── app/ │ ├── agents/ │ │ ├── base_agent.py │ │ └── damage_estimate_agent.py │ ├── tools/ │ │ ├── ocr_client.py │ │ └── vlm_client.py │ ├── evaluator/ │ │ ├── metrics.py │ │ └── trace_parser.py │ └── scenarios/ │ ├── generator.py │ └── registry.py ├── configs/ │ ├── llm_config.yaml │ └── tools.yaml ├── outputs/ │ └── traces/ └── run_evaluation.py这个结构把Agent、工具、评估器、场景库四个核心模块拆开后续加新Agent时不需要动评估器。开发期建议把外部工具全部改成mock等主流程跑通再接真实服务这样能排除很多网络和鉴权干扰。5.2 关键参数选择与解释跑评测之前有几个参数必须先想清楚。模型temperature我固定设成0.2定损场景要的是稳定可复现不允许模型偶尔蹦出创造性连词。token上限根据报告长度设为1500到2500之间太长容易截断损坏JSON结构。并发请求数调成3到5一方面避免超时重试堆积另一方面减轻外部工具压力。对工具调用我设置了单次工具超时5秒、最多重试2次的兜底策略。这里有个操作细节mock工具要故意加入一部分失败场景比如图片服务偶尔返回502用来检验Agent在工具异常时的降级表现。如果Agent一遇到工具失败就死机Harness会把这类场景标红排到修复优先级的最高层。5.3 执行一次完整评测并看懂输出下面用一个精简版命令示意如何启动评测。实际使用时可能需要增加一轮采样次数比如每个场景跑3次取平均避免LLM随机性干扰结果。python run_evaluation.py --scenario-file configs/demo_scenarios.json --output-dir outputs/run_20250101 --sample-times 3运行结束后在output目录下会生成一份汇总表。假设我们跑了30个场景汇总结果可能是这样的。指标平均值说明结构合法性得分18/20有两个场景输出残缺业务完整性得分26/30关键字段大部分正确定价准确度得分24/30配件编码误差大证据充分性得分14/20部分结论缺少引用平均耗时7.8秒包含两次图片分析看到分数后下一步就是打开trace逐条排查。定价准确度丢分严重的场景通常能定位到某个配件查询工具返回了空数据模型只能自己猜价格。这种问题不该只改prompt而是要去修工具层的数据覆盖度。5.4 一个真实的失败案例复盘有一次我们在某合资B级轿车“右侧后门受损”的场景里发现模型把损伤部位识别成了左侧车门导致后续所有配件查询和定价都错了方向。排查trace后发现图片分析工具给VLM发送的是未旋转的原图VLM基于画面方向做了错误判断。修复方案不是在prompt里补一句“注意方向”而是在图片预处理阶段统一转为EXIF方向标准并在工具返回结果里增加一个“image_orientation”字段。这个问题一旦定位到修复只花了半小时。如果没有trace这种问题大概率会归咎于“大模型不行”。这个例子很说明问题Harness的价值在于把“玄学”变成工程问题。模型随机性存在但大多数错误其实是工具链路和数据链路的问题只是之前缺少证据去证明。6. 高频问题与排查技巧实录6.1 模型幻觉与证据不足的拦截策略定损Agent最常见的幻觉是“编造配件编码”和“脑补损伤程度”。我们在评估层加了一道“证据校验器”把所有结论中出现的实体抽取出来与工具返回结果和图片描述做匹配不匹配的直接标红。同时要求模型在证据不充分时强制输出“证据不足”后续接人工复核流程。实测跑下来这一招让定价误差超过30%的高风险样本减少了一大半。6.2 输出结构不稳定的兜底手段LLM偶尔会把JSON字段名改掉或者多嵌套一层数组。我们用两层方案兜底第一层在prompt里给JSON Schema示例第二层在解析时用“宽容解析器”尝试自动纠正常见错误比如字段名相似替换和缺失字段补默认值。如果解析失败再重试一次还是不成功就判定无效输出进入人工复核队列。不要为了追求解析完全自动而反复重试那样会大幅提高延迟得不偿失。6.3 工具超时与限流处理定损过程中要多次调用图片理解服务很容易触发外部API限流。我建议在工具层做本地熔断连续失败5次后5分钟内不再调用该工具Agent改为走降级逻辑。熔断一定要记录到trace中不然排查时看到输出异常却不知外部服务已经不可用会很头疼。6.4 提示词注入的边界控制理赔报案文本来自用户里面可能藏指令。我们采用两条防线一是在进入Agent前做系统指令与用户内容的隔离把报案文本仅作为数据字段传给模型而不是拼接进指令区二是在评估层加“注入检测器”如果模型输出内容里带有明显非业务指令痕迹直接拦截。保险行业对安全要求高这条防线绝对不能省。6.5 常见问题排查速查表问题常见原因快速排查方法定价偏差大配件库返回空或图片误判查看工具调用的返回值输出JSON解析失败字段被模型改写跑宽容解析器定位错误行重复调用工具未设置幂等或DAG环检查编排层visited集合低置信度却给出方案提示词缺少强制“证据不足”选项检查输出disputes字段局部改好全局变差prompt对某类场景过拟合对比回归集分段得分常见问题基本逃不出这张表的范围。遇到新问题时我的习惯是先看trace和指标报告再改代码而不是直接动prompt。凭感觉调prompt是最耗时的排查方式而且大概率会引入新的回归问题。最后分享一点实际操作中的体会这套Harness做成型之后我最大的感受是Agent项目能不能落地拼的不是模型跑出几句漂亮话而是拼工程系统是否经得起回归、回放和量化。调试过程中最上瘾的时刻是看到一次评分从60分涨到85分打开trace发现改对了那个关键节点。如果你准备做一个保险理赔或类似强规则领域的Agent我建议先把Harness搭起来再写业务逻辑哪怕它第一版只有100行代码也一定能让后续工作少走很多弯路。下一步我计划把场景库扩到覆盖更多低频复杂事故再叠加一层反欺诈特征让同一套评估底座发挥更大的作用。