企业官网建设流程全解析

做保险理赔Agent项目的团队越来越多，但真正让我觉得值得拿出来分享的，不是某个Agent本身，而是后面那套自动化定损的Harness。这个词国内用得还不多，用大白话说，它就是给Agent搭建的“试车跑道和仪表盘”：没有它，模型跑得好不好只能凭感觉；有了它，每一次推理过程、每一个工具调用、每一个错误决策都能被记录、回放、量化。这篇文章就围绕保险理赔Agent和自动化定损Harness的搭建思路展开，重点讲清楚这套系统解决什么问题、核心模块怎么拆、踩过哪些坑，以及从零跑通一个可评测闭环的关键经验。

1. 为什么需要一套定损Harness而不是只做Agent

1.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个场景，汇总结果可能是这样的。

看到分数后，下一步就是打开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 常见问题排查速查表

常见问题基本逃不出这张表的范围。遇到新问题时，我的习惯是先看trace和指标报告，再改代码，而不是直接动prompt。凭感觉调prompt是最耗时的排查方式，而且大概率会引入新的回归问题。

最后分享一点实际操作中的体会

这套Harness做成型之后，我最大的感受是：Agent项目能不能落地，拼的不是模型跑出几句漂亮话，而是拼工程系统是否经得起回归、回放和量化。调试过程中最上瘾的时刻，是看到一次评分从60分涨到85分，打开trace发现改对了那个关键节点。如果你准备做一个保险理赔或类似强规则领域的Agent，我建议先把Harness搭起来再写业务逻辑，哪怕它第一版只有100行代码，也一定能让后续工作少走很多弯路。下一步我计划把场景库扩到覆盖更多低频复杂事故，再叠加一层反欺诈特征，让同一套评估底座发挥更大的作用。