企业官网建设流程全解析

1. 定损这件事，为什么值得认真做一套Agent Harness

保险理赔里最磨人的环节，不是用户提交材料那一下，而是“定损”本身。拿车险来说，一台车撞了，现场拍几张照片传上来，后端到底怎么判断“这伤修要多少钱”“这伤是不是旧伤”“这个位置撞成这样合不合理”，全压在定损员身上。定损员一天处理几十单，每单都要对着照片反复看、翻历史记录、查配件价格，效率上不去，差错也难免。

我做保险科技这块也有几年了，团队前前后后试过不少方案，从最开始的规则引擎，到后来引入视觉模型做图片分类，再到最近这半年，我们把重心转向了“Agent”架构。确切地说，是把定损流程拆成一组可编排、可观测、可单独验证的自动化任务，再用一个统一的 Harness 把它们串起来跑。

这篇文章就是想把这套自动化定损 Harness 的设计思路、核心模块、实操过程和一些踩坑记录完整写出来。它不是一篇理论综述，而是我们项目里真实落地过的东西。适合谁看？如果你在保险、汽车后市场、检修平台这类行业做技术方案，或者你正在用大模型、视觉模型做业务自动化，这篇文章应该能帮你少走不少弯路。

为什么值得认真做？因为定损的“自动化”和一般的内容审核自动化不一样。定损结果直接对应赔付金额，金额错了就是真金白银的损失。你不可能像跑一个情感分析模型那样，大概齐就行。所以这套 Harness 从设计第一天，就把“结果可追溯”“决策可解释”“流程可插拔”三件事当成硬指标。

2. 整体设计思路：先想清楚Agent要拆成几层

2.1 核心需求解析：定损链路里到底有哪些活

先把定损员的工作流拆开看。一台车报案，传上来的是现场照片、行驶证、保单这类材料。定损员要做的事，我归纳成五步：

第一步，识别车辆基本信息，车型、年款、颜色，这些决定了配件价格的基准。 第二步，识别损伤部位，是前保险杠还是左前翼子板，判断需要单独拆解还是整体更换。 第三步，判断损伤程度，剐蹭、变形、破裂、功能受损，这直接影响维修工艺和工时费。 第四步，比对该车的理赔历史，排除重复索赔、旧伤伪装新伤的可能。 第五步，根据配件价格库和工时标准，生成一个定损金额区间。

这五步听起来很清晰，但真正跑起来，每一步都有自己的坑。比如第一步，车型识别，照片角度千奇百怪，光线差一点，模型识别就偏了。第二步和第三步经常纠结在一起，同一个部位，损伤严重程度不同，维修方案完全不同。

所以我们在设计 Harness 的时候，没有走“一个大模型把所有事干了”的路线，而是采用了多层任务的架构。做 Agent 系统的人都懂一个道理：单个 Agent 的能力边界再强，也架不住业务链路长、状态分支多。把任务拆成粒度更小的 Agent，每一层只专心做一件事，出现问题的时候，定位问题的成本也会低很多。

2.2 Harness本身的定位：不是Agent，而是Agent的底盘

把上面说的五步做成五个独立的 Agent 之后，我们立刻发现一个尴尬的情况：每个 Agent 单拎出来效果都不错，一放到真实链路里就乱套。有的是数据格式对不上，有的是一步出错后面全错，有的是某个 Agent 跑挂了整个流程就卡死。

这就需要有一套东西，把各个 Agent 像零件一样装起来，统一管理它们的输入输出、调度顺序、异常处理和结果汇总。我们管这套东西叫 Harness，你可以把它理解成 Agent 的操作系统和底盘。

具体来说，Harness 要做几件事：

• 编排：定义每个 Agent 的执行顺序和依赖关系。比如损伤程度判断必须在损伤部位识别之后做，车型识别可以和损伤识别并行跑。
• 数据传递：统一 Agent 之间的数据格式。我们这个项目里用的是 JSON Schema 约束的中间结构，每个 Agent 的输入输出都严格对齐，避免“一个 Agent 输出的是 A 格式，下一个 Agent 期望的是 B 格式”这种低级但致命的错误。
• 状态管理：记录每一步的执行状态、耗时、返回结果，方便后续回放和审计。
• 兜底策略：某个 Agent 置信度过低的时候，不是硬着头皮继续，而是启动人工介入流程。
• 可观测性：每一步的执行日志、模型调用、参数详情全量记录，这是后面做问题排查和模型迭代的基础。

用生活化的类比来说，各个 Agent 是不同工种的师傅，Harness 就是那个项目经理加监理。师傅们只管把自己手上的活干好，至于先叫谁、后叫谁、谁的结果给谁用、谁干砸了怎么补救，都是项目经理说了算。

2.3 方案选型：为什么不用端到端大模型一把梭

做这个方案之前，团队里也吵过一轮。有人提议直接用一个多模态大模型，把现场照片丢进去，让它直接输出定损结果和金额。这思路听上去很性感，业界也确实有不少团队在试，但我们在评估之后，还是选择了更保守的模块化方案。

为什么不直接用端到端大模型？原因有三个。

一是可解释性。定损结果是要承担赔付责任的，如果大模型给了一个金额，但说不清依据是什么，合规和审计那边根本过不去。模块化方案里，每一个判断步骤都有明确的输入、输出和处理逻辑，可以逐层回溯。

二是可维护性。定损规则变化太快了，车型每年更新，配件价格每个季度调，维修工艺也在演化。如果所有知识都揉在一个大模型里，每次规则变化都要重新训练模型，成本极高。模块化方案里，车型识别模型、价格计算模块、维修方案规则库都是独立维护的，改哪块就动哪块。

三是容错性。端到端模型是黑盒，一个地方错了，可能整体结果就错了，而且你很难知道是哪一步出的问题。模块化方案里，每个 Agent 都有置信度评估，哪一步置信度低就单独处理，不会污染后面的链路。

当然，模块化的代价也有，那就是开发量大、接口复杂，需要有人专门维护 Harness 本身。但对我们这个场景来说，这个代价是值得的。

3. 核心细节解析：五个Agent和它们背后的门道

3.1 图像接收与预处理：很多后续问题都出在这一步

定损链路的第一步，是处理用户上传的现场照片。听起来简单，实际上这一步的质量直接决定后面所有 Agent 的表现。

我们收到的照片五花八门。有晚上在路灯下拍的，有逆光拍的，有车辆只有半个车身入镜的，还有分辨率低到放大十倍的边缘全是马赛克的。如果照片质量不达标，后面模型识别再强也白搭。

所以 Harness 里最先跑的，是一个图像预处理模块。它的工作有三块：

• 基础清洗：自动旋转校正方向，调整曝光和对比度，去除部分噪点。
• 质量分级：给每张照片打一个质量分，低于阈值直接标记为“需要补充材料”，同时生成一个建议文案，告诉用户“照片过暗，请在光线充足处重新拍摄”。
• 车辆主体提取：尝试抠出车辆区域，过滤掉无关背景的干扰，方便后续模型聚焦在车身上。

这里有一个很实用的技巧：预处理模块不要只做传统图像处理，可以结合一个轻量级的分割模型，把车辆主体和背景分离。我们用的是语义分割方案，效果比单纯靠边缘检测稳定得多。尤其是在背景复杂的情况下，比如车停在树荫下，树叶的影子打在车身上，传统方法很容易把阴影识别成损伤痕迹。

3.2 车辆识别Agent：车型年款是后面所有判断的基准

第二个 Agent 负责车型识别。这一步的目标是确定车辆的品牌、车系、年款和配置。为什么重要？因为同一个部位的配件，不同年款的车型价格可以差好几倍。举个例子，一款常见家用轿车的前大灯，老款可能几百块，新款带自适应远近光的版本可能两千多。车型认错了，后面金额全偏。

车型识别我们用的是视觉分类模型加逻辑校正的组合方式。视觉模型先根据照片外观给出 Top5 候选结果，然后由一个规则模块根据照片里的细节做二次校验。比如轮毂样式、车身线条特征、前脸格栅形状，这些细节在同一个品牌不同年款之间常常有明确差异。

一个值得注意的细节是：如果照片里能看到行驶证或者车牌信息，我们优先用文字识别结果去交叉验证车型。这种多模态交叉验证，比单纯看照片靠谱得多。

但如果车型识别的置信度不足，比如改装车、贴膜车、或者比较冷门的进口车型，这个 Agent 会主动把任务挂起，不往下传。这时候系统不会自作主张，而是直接提示需要人工确认车型。别小看这一步主动性降级，它避免了把错误的车型基准传染给后面的所有环节。

3.3 损伤部位识别Agent：分类粒度决定了后续工作量

损伤部位是定损的核心要素之一。我们按照保险行业常用的定损口径，把车辆外观分成大约 40 个区域，前保险杠、中网、左前翼子板、引擎盖、左侧车门、车顶、后保险杠等等。每个区域有一套独立的损伤判定规则。

这个 Agent 用的模型是目标检测加细粒度分类的组合。目标检测负责框出损伤区域，分类模型负责判断这个损伤属于哪种类型。损伤类型我们初期定义了六类：剐蹭、凹陷、破裂、变形、脱落、功能受损。

这里我特别想强调一个经验：损伤分类的粒度不要一开始就搞得太细。我们最开始试图把剐蹭分成“轻度划痕”“中度剐蹭”“重度剐蹭露底漆”之类的五级，结果模型准确率怎么都上不去，标注成本倒是翻了倍。后来我们简化成三类：浅层损伤、深层损伤、结构损伤，然后根据损伤面积和位置，在规则层再去推断严重程度。这样一来模型任务简单了，准确率上去了，规则层也能随时调整标准，不用重新训练模型。这是典型的“模型做减法、规则做加法”思路。

3.4 历史比对Agent：防止旧伤搭便车

这个 Agent 相对独立，平时不太起眼，但真出事的时候，它是用来顶住合规压力的关键模块。

漏油、旧伤、维修痕迹，这些在定损里是敏感信息。用户可能去年在这个位置有过一次出险记录，今年又撞了同一个地方，如果没有历史比对，系统可能把旧伤维修费用也算进来。

历史比对 Agent 做的事，是把当前照片中的损伤位置坐标，与该车辆的历史出险记录做一个空间映射。如果当前损伤区域与该车历史报案的区域高度重合，Agent 会把相关历史记录提取出来，附带相似度分数，传递给下一层去做综合判断。

这里的技术难点在于：历史照片和当前照片的拍摄角度通常不同，直接比对像素不现实。我们的做法是先对车辆做关键点对齐，找到引擎盖前端、大灯边缘、车门把手这些稳定的关键点，把两套照片映射到同一坐标系下，再比较损伤区域的重叠程度。这个方法准确率谈不上完美，但已经能帮定损员省掉大量翻历史记录的时间。

3.5 定损金额计算Agent：把专业标准变成可执行逻辑

最后一个 Agent 负责金额计算。它不识别照片，而是接收前面几个 Agent 的输出结果，参考配件价格库和工时标准，生成定损区间。

金额计算分成两块：配件费用和工时费用。

配件费用是基于车型、部位和损伤类型三个维度查表。配件价格库里的数据由专门的采购和核价团队维护，按照市场行情定期更新。查询结果不是单一价格，而是包含原厂件、品牌件、拆车件三个档位的价格区间。

工时费用则来自维修工艺标准库。损伤类型不同，对应的维修工艺就不同，工时数也不同。比如一个保险杠剐蹭，标准工艺是拆装加喷漆，大概 3 到 4 个工时；如果是保险杠破裂，工艺就会复杂一些，涉及焊接修复或更换，工时数可能到 6 到 8。我们把工艺标准做成规则表，直接在规则层查表计算，不用模型来推断。

4. 实操过程：把流程图变成能跑的系统

4.1 Harness的模块设计与数据结构定义

我们在代码层面把 Harness 设计成一个基于事件驱动的流水线框架。每个 Agent 是一个独立的执行单元，通过消息队列通信，而不是直接函数调用。这样设计的好处是：单个 Agent 挂了不会影响整个主进程，也方便以后横向扩展。

先定义中间数据结构。我们用的是 Pydantic 模型，每个 Agent 的输入输出都有明确的类型定义。

class VehicleInfo(BaseModel): brand: str series: str model_year: int trim_level: Optional[str] = None confidence: float class DamageRegion(BaseModel): region_code: str # 部位编码，如 FRONT_BUMPER damage_type: str # 损伤类型，如 SCRATCH / DENT / CRACK area_cm2: float # 损伤面积估算（平方厘米） bounding_box: List[int] # 图像中的位置框 [x1, y1, x2, y2] confidence: float class ClaimReport(BaseModel): vehicle: VehicleInfo damages: List[DamageRegion] repair_plan: List[RepairItem] # 维修方案明细 estimated_cost: CostRange risk_flags: List[str] # 风险标记，如历史重合 status: str

代码结构里有一个很关键的设计决策：所有 Agent 都注册成插件。Harness 只有一个简单的调度核心，不包含任何业务逻辑。每接入一个新的 Agent，只需要实现一个接口，然后在配置里注册调用顺序。这样可以很方便地针对不同业务场景组装不同的流程。比如，对两车事故的定损流程和三车追尾的流程，可以复用大部分 Agent，只是编排顺序不同。

4.2 调度编排：并行跑还是串行跑，这里面有讲究

调度编排是实现 Harness 的核心环节。按照依赖关系，我们的流程图可以简化为：

图像预处理完成后，车辆识别和损伤识别可以并行启动，因为它们互不依赖。两者都完成后，损伤结果进入历史比对，历史比对完成后，结合车型信息进入金额计算。

这里有个实际的性能优化细节：图片预处理和车型识别是计算密集型的，我们把它们放在 GPU 节点上跑；历史比对主要是检索和空间计算，放在 CPU 节点上跑；金额计算就是纯规则查表，轻量得很。调度器要做好三类节点的任务分配。

如果并行跑，单案的处理耗时能从串行的 15 秒压到 8 秒左右。听着好像不多，但接的是日均几千单的量，这个差距就直接体现在服务器成本和用户体验上。

4.3 降级策略和人工介入：这是最容易被忽略的部分

一套自动化系统，最有价值的不是它在理想情况下的表现，而是它在极端情况下的兜底能力。所以 Harness 里的降级策略和人工介入流程，是我们要花心力最多的部分。

我们的设计是：每个 Agent 输出结果时，除了业务数据，必须附带一个置信度字段。置信度低于阈值的节点，不会直接进入下一环节，而是触发人工介入队列。

人工介入队列会展示一张定损工作台卡片，卡片上聚合了该案的全部中间结果、置信度低的环节和原因、相关图片和规则书依据。定损员只需要核对少数关键项，不需要从头到尾看材料。这样既保住了自动化带来的效率，又没有牺牲准确率。

这里补充一个经验：千万不要让某个 Agent 在没有置信度信息的情况下默默输出一个“差不多”的结果。我们在早期版本里犯过这个错误。某个车型识别模型对冷门车型的识别经常出错，但置信度一直没有很好的校准，导致几个定损案在车型错认的情况下直接算出了金额。后来我们在车型识别 Agent 后面加了一个强制校验环节，凡是最优候选和第二候选的置信度差距小于 15% 的，一律人工确认。

4.4 关键参数和调优记录

在实际调优过程中，有几个参数值得分享：

模型置信度阈值方面，我们把车辆识别的主判阈值定在 0.85，低于这个值就触发人工确认。损伤检测模型的任务是召回率优先，阈值定在 0.30，宁可多框几个疑似区域，也不漏掉真实损伤。漏检的代价远比误检高，因为漏检直接导致赔付金额偏低，事后用户投诉补定损，流程成本更高。

历史重合判定方面，我们设定重合面积比超过 65% 时必查历史，低于 35% 时直接放行，中间区间再结合其他信息判断。这个 65% 的阈值不是拍脑袋定的，是我们抽样验证了 200 条历史重案记录的分布后定的。如果想直接抄作业，建议你用自己的历史数据重新画一下分布再定，不同渠道的数据分布差距还是挺大的。

5. 踩坑记录：这些问题都是真实跑出来的

5.1 图像方向问题没有被预处理完全解决

我们以为是预处理模块必做的自动方向校正，在实际运行中还是出现了漏网之鱼。某一天突然有批量案件的损伤检测结果特别差，后来定位发现，是那一批照片全部是竖屏拍摄，但 EXIF 信息里的旋转角度被某些安卓机器的系统相册提前“修正”了，导致预处理模块读到的方向已经不是原始方向。

解决方案：预处理模块不直接信任 EXIF 信息，而是先用一个轻量分类模型判断图像方向，再做方向校正。这个模型准确率要求不高，98% 就够用了，反正只要方向对了就行。

5.2 清洗数据的坑：训练集和真实分布不对齐

我们的损伤检测模型最初训练时，用的是定损员在专业摄影棚里拍的定损照片。光线均匀、背景干净、车辆完整。但真实用户上传的照片完全不是这么回事，经常只有局部特写，光线差得一塌糊涂，甚至照片里还有其他车辆乱入。

这给我们的教训是：做业务系统的模型，一定要用真实数据做材料，不能用理想数据自欺欺人。后来我们专门建立了一个“真实照片池”，从历史案件里随机抽一批照片，人工清洗标注后作为训练集的一部分。这个改动让模型上线后的误报率降了接近一半。

5.3 配件价格库的更新滞后

金额计算模块本身很简单，真正麻烦的是维护它背后的价格数据。有一段时间，某热门新能源车型的一个配件价格做了大调整，我们库里还是旧价格，导致一批案件的定损金额偏低。

后来我们专门做了一个价格变更监控，对接供应商的价格公告渠道，一旦发现价格变动，自动生成待确认的更新任务，走人工审批后进入价格库。这个流程谈不上智能，但确实堵住了最大的漏洞。

5.4 Agent之间超时问题的处理

不同 Agent 的处理速度差异很大，尤其是历史比对 Agent，如果数据库查询没走索引，一次可能要跑几十秒。后面链路的 Agent 不能傻等着，要做超时处理和重试策略。

我们给每个 Agent 设了独立的超时时间，超时后不是杀掉整个流程，而是缓存当前状态，启动一个轻量级的保底方案。比如历史比对超时了，就把“历史比对失败”作为风险标记传到下一步，由金额计算 Agent 的规则做保守处理，同时触发人工复核请求。

这个“局部失败、整体降级”的策略，在复杂流水线系统里特别重要。

6. 常见问题速查表：照着排查比重新发明轮子快

7. 最后分享几个我们在实际使用中沉淀下来的体会

关于置信度的校准。模型返回的置信度数值，在实验室看起来很正常，但上线后经常跟真实准确率对不上。建议每个模型上线后，定期收集线上结果，重新做置信度校准。我们经历过最夸张的一次，某模型在测试集上置信度 0.9 以上的样本准确率有 95%，上线一个月后 0.9 以上准确率实际只有 80%。原因其实就是真实数据分布和测试集分布漂移了，校准不是一次性的工作。

关于人工介入的体验设计。自动化系统做久了容易陷入一个误区，觉得人工介入少就是好。但定损这个场景不一样，人工介入不是失败，它本身就是流程设计的一部分。与其让定损员在系统外面用一个 Excel 表做补充记录，不如把人工介入的点设计进系统里，让所有操作都有留痕。我们在 Harness 里专门做了一个“人工调整记录”模块，定损员改了什么、为什么要改、改前的自动结果是什么，全部记录在案，这对后续的模型迭代和合规审计都有价值。

关于规则和模型的边界。在这个项目里，我们最大的原则是：模型负责感知，规则负责决策。感知层面的任务，比如这是哪个部位、什么损伤类型，交给模型；决策层面的任务，比如该不该赔、该修还是该换、工时怎么算，交给规则。规则的维护成本低，调整后立即可生效；模型的迭代周期长，但泛化能力强。各用所长，反而比纯规则或纯模型都更稳。

最后说说后续能怎么扩展。现在的五步链路，只覆盖了外观定损。如果把这个 Harness 的思路往外扩，很自然就能接上内饰检测、底盘检测甚至机械件故障诊断，只要每个环节都有独立的感知 Agent 和对应的规则库，扩展起来就是一个加装新 Agent 的事，不会动到底层框架。也可以把定损结果自动送进理赔审核链路，做全流程的自动化闭环。这个方向我们内部已经在验证了，跑顺之后应该会再写一篇完整分享。

这套 Harness 做下来，我们最大的感受是：自动化不是让机器替代人，而是让机器先做一遍粗活，把人解放出来专心处理那些真正需要经验的判断。定损这件事，对照我自己的经验来看，再怎么自动化，也总会有需要人拍板的灰色地带。好的系统不是消灭灰色地带，而是把灰色地带清晰地标注出来，让人处理起来更顺手。