企业官网建设流程全解析

做AI Agent落地的人，这两年一定会遇到同一个瓶颈：demo跑得飞快，一旦进生产环境就被流程、权限、合规砸得晕头转向。保险理赔更是重灾区：单证杂、规则多、金额敏感、审计严格，稍有不慎就是投诉和赔付差错。AI Agent Harness Engineering，简单说就是给Agent套上一层工程底座，让它在一个受控、可回溯、可干预的框架内干活。我们团队在一个车险理赔流程优化项目里，用这套思路把"资料齐全性预审"这个环节的人力投入砍掉了约七成，准确率稳定在95%以上。这篇文章就把我们踩过的坑、拆过的模块、沉淀出来的落地方法一次讲透，适合正在做Agent生产落地的工程师、产品经理，以及准备用AI改造传统理赔流程的决策者。

1. 先搞懂：Agent Harness Engineering到底在解决什么问题

1.1 保险理赔流程的本质与Agent化改造的难点

保险理赔本质上是一个"信息收集—判断—授权—执行"的审批链。从客户报案开始，到查勘、定损、单证审核、理算、核赔，再到最后的结案支付，每一个环节都在做两件事：整理信息、做决策。这不就是大模型最擅长的事吗？确实，我一开始也是这么想的。但真正动手做之后才发现，理赔流程不是一个"一问一答"的对话，而是一个有状态、有约束、有责任边界的业务流程。

难点在于三个地方。第一，信息形态极度非结构化，用户上传的照片可能是歪的、模糊的、反光的，发票上的金额可能被水印遮挡，维修清单的项目名称五花八门。第二，决策必须符合规则和条款，比如"无证驾驶是否免赔""用药目录外费用是否自付"，这些判断不是开放式的，而是有明确答案的。第三，所有操作都要留下痕迹，理赔人员不仅要给结论，还要能解释为什么。这些要求叠加在一起，如果只把大模型当作一个"聪明的聊天机器人"丢给用户，结果一定是灾难。

所以我们需要一个中间层，专门处理"模型与业务系统之间的连接和约束"。这就是Agent Harness Engineering的由来。

1.2 Harness层、模型层与应用层的边界

很多团队的误区是，Agent优化就是换更好的模型、写更长的Prompt。真正进过生产环境的人都知道，模型能力只占整个系统行为的一小部分，更关键的是中间那一层"工程胶水"。我习惯把整个系统拆成三层来看：

• 模型层：负责根据输入生成文本、动作序列或结论，比如判断"这份材料缺什么"、生成"给用户的补材料通知书"。
• Harness层：负责决定模型能看到什么、能调用什么工具、在什么条件下不能做什么、如何解析和校验模型输出，以及把每次决策记录下来。
• 应用层：面向理赔员或用户的前台，比如任务工作台、消息队列、审批界面、数据报表。

在这三层里，最容易被低估的就是Harness层。它像汽车的悬挂和转向系统：发动机再好，没有合理的传动和限速机制，跑上路也是失控的。保险理赔流程优化最大的杠杆恰恰在这里，因为你可以不动原有的核心业务系统，只需在Agent和业务系统之间加一层"受控的调度者"，就能大幅改变系统的整体表现。

1.3 为什么理赔流程优化的关键在于Harness层

理赔场景是"强规则"和"弱规则"共存的典型：比如"单证是否齐全"是强规则，上传三张照片，缺一张身份证照片，这就是确定的缺失；而"这张发票照片是否真实""维修工时费是否合理"则属于弱规则，往往需要结合经验判断。如果只用传统规则引擎，处理弱规则时特别"蠢"，只能做简单的包含匹配，遇到模糊表述就失效；如果只用纯模型，处理强规则时又特别"飘"，会出现漏项、误判、规则冲突。

Harness层能把两者拧在一起：强规则用代码或校验函数判断，弱规则交给模型生成候选结论，再通过校验函数回查。举个例子，核赔之前需要校验"被保险人身份证号是否与保单一致"，这个校验不需要模型参与，直接两个字段比对就行。但"客户提供的维修单是否与事故照片中的损伤部位对应"，则需要模型先做视觉理解，再输出对应的部位列表，最后由规则引擎检查这个列表是否落在本次事故的赔偿范围内。

这种"模型判断+规则校验"的混合模式，只在Harness层才能干净地实现。模型层负责"发散"，Harness层负责"收敛"，应用层负责"呈现"。三者的职责一旦混淆，系统一定会出各种莫名其妙的问题。

2. 理赔流程中Agent Harness的架构与核心模块拆解

2.1 全流程梳理：从报案、查勘、定损到理算结案

在动手设计Harness之前，我们先把车险理赔的主流程完整梳理了一遍，确认每个环节的信息输入、决策输出和风险等级。简化后的流程大体是这样：

1. 报案登记：用户提供保单号、事故描述，可能上传现场照片、驾驶证、行驶证、银行卡。
2. 查勘调度：系统分派查勘员到现场或者使用远程视频查勘，收集事故全貌。
3. 定损：依据维修报价单、配件价格库、工时标准、拖车费等，确定损失金额。
4. 单证审核：检查理赔资料是否齐全、有效，比如三者车维修发票、交警责任认定书等。
5. 理算：根据保险条款、免赔额、赔偿比例，计算最终赔付金额。
6. 核赔：由人工作出最终审批，然后支付。

每个环节的信息源、权限范围、错误容忍度都不一样。报案环节错误容忍度相对高，即使信息缺失，后面还能补；但理算环节金额错了就会直接产生真金白银的损失。一个合格的Harness应该为每个环节配置独立的"Agent工作台"，而不是把所有环节塞进同一个大模型Agent里。

2.2 Harness层的四大核心模块

我们最终沉淀出来的Harness层，包含四个核心模块，缺一不可。

第一个是工具网关（Tool Gateway）。模型不能直接访问数据库、不能直连支付接口，所有动作都要通过网关。网关负责做入参校验、权限校验、频率限制、结果脱敏。比如"查询保单信息"这个工具，声明了只读，就不能在工具内部做任何修改操作；"生成定损草稿"这个工具，只能写工作台草稿，不能直接提交到最终定损表。这样做的好处是，即使模型在对话中突然变异，试图调用一个"删除案件"的工具，网关也会在入口处把它拦下来。

第二个是状态机和流程编排。理赔是一个典型的有状态流程。同一个案件，在"查勘中"和"待核赔"两个状态下，Agent可用的工具完全不同。我们用状态机把每个案件当前所处的阶段记录下来，Harness层根据状态决定开放哪些工具、关闭哪些工具。例如，案件还在"报案登记"阶段时，就不允许Agent调用"修改理算金额"接口。这个设计看似简单，却避免了无数"Agent越权操作"的问题。

第三个是上下文管理（Context Management）。理赔案件通常涉及长文本、多图片、历史记录，一个案件从报案到结案的完整材料可能超过几万字和上百张图片，全部塞进模型上下文既不可能也不经济。Harness层的作用是动态地从业务库或向量库抽取与当前任务相关的片段，然后拼接成一个精简的上下文包。比如在做单证审核时，只需要保单概要、材料清单、已收集材料的OCR文本，而不需要之前的全部对话历史。

第四个是安全护栏（Guardrails）。除了权限，护栏还负责输出校验和人工确认机制。模型生成一段结论后，Harness会先校验格式、检查数字一致性、识别敏感信息，再决定是否放行。如果发现模型的计算结果和工具返回的数据不一致，直接拒绝输出并转人工。某些高风险动作，比如"核减赔款超过一定金额""驳回用户申请"，必须设置强制的人工确认点，即使Agent已经完成所有推理，也不能自动执行。

2.3 流程编排引擎如何把"自由发挥"收敛成"边界内的智能"

我们一开始也很纠结：既然用了Agent，是不是应该让它自由规划整个流程？后来发现，在理赔场景里，完全自由规划等于让一个能力很强但没有责任感的实习生自己决定怎么处理客户投诉，结果一定失控。

所以我们的最终方案是：把流程定义成一张有向图，节点是业务动作，边是条件分支。Agent不是一个从零开始自主决策的"大脑"，而是作为流程引擎里的一个"智能算子"，在一个节点内部发挥理解、判断、生成能力。比如在"材料审核"节点中，Agent只能做三件事：提取材料关键字段、比对材料清单识别缺失项、生成补材料通知书。它不能跳到"核减金额"，也不能跨节点去调用支付接口。

这样做的好处是双重的。一方面，流程的合规性、可预测性被结构保证了；另一方面，Agent的灵活性在节点范围内完全保留，语言表达的多样性、模糊信息的处理能力都得到了发挥。用一句我们内部常说的话，"给Agent划一块边界清晰的责任田，它在田里怎么折腾都行，但不能跑到别人的田里去。"

3. 实操指南：搭建一个理赔优化的Agent Harness

3.1 确定场景边界：先啃低风险、高重复的子流程

在项目启动时，我们犯过一个冒进错误：想直接做全自动理算Agent，把所有规则都放进去，结果成本高、准确率也不理想。后来调整策略，选择"理赔资料齐全性预审"作为第一个落地场景。这个环节有三大优点：低风险（最多是让用户补充材料，不会造成资金损失）、高频重复（每天大量的报案材料需要核对）、规则可明确定义（材料清单是固定的）。

建议所有想做Agent落地的团队都从这种"边界清晰、后果可控"的子流程入手。把一个单点流程吃透，形成一套可复用的Harness模板，再横向扩展到其他环节，远比一上来就铺一个多环节的"超级Agent"稳妥。

3.2 工具接口设计与权限模型：让Agent"够得着但碰不了"

工具是所有Agent能力的出口。工具接口设计得好不好，直接决定了系统安不安全、逻辑清不清晰。我们采用了装饰器标注的方式，每个工具函数都声明自己的授权范围：

@tool_gateway(scope="read_only", resource="policy_db") def get_policy(policy_no: str) -> PolicyInfo: """根据保单号查询保单信息，只读，不可以在本函数内执行任何写操作。""" ... @tool_gateway(scope="write_draft", resource="claim_draft") def create_draft_assessment(case_id: str, items: list[dict]) -> str: """生成定损草稿，只能写入草稿表，不能修改正式定损记录。""" ... @tool_gateway(scope="require_manual_confirm", resource="payment") def submit_payment(case_id: str, amount: float) -> str: """提交支付指令，此工具必须有人工确认后才能实际执行。""" ...

Harness层在每次调用前，会检查当前状态机的节点、案件的风险等级、调用者的角色，综合判断是否放行。权限遵循最小化原则：Agent只看得到处理当前任务必要的数据。例如，做单证审核时，返回给模型的保单信息会把被保险人的银行账号遮蔽成尾号；做理算时，才会在内部环境中放开金额相关的字段。

一个容易踩的坑是"工具复用"。同一个"查询客户信息"工具，可能既被单证审核节点使用，又被理算节点使用。不同节点需要的字段范围不一样，所以我们在工具网关层做了"字段级过滤"，而不是简单地把整个数据行发给模型。每个工具可以配置可返回字段的白名单，未白名单的字段一律脱敏或直接不返回。

3.3 上下文窗口与记忆管理：结构化加载而不是全部塞入

理赔Agent最大的上下文压力来自"长期记忆"和"多文件理解"。我们直接在Harness层做了上下文打包器，而不是依赖模型的超长上下文窗口。打包器的输入是所有相关数据，输出是一个结构化的上下文对象，用JSON表示后只包含当前节点需要的部分。

一个典型的"单证审核"上下文包长这样：

{ "case_brief": { "case_id": "CLM2025-001234", "stage": "document_review", "risk_level": "medium" }, "policy_summary": { "coverage_type": "商业车险-车辆损失险", "deductible": 0, "insured_name_masked": "张*", "validation_needed": ["driver_license", "id_card", "repair_invoice"] }, "collected_documents": [ {"doc_type": "driver_license", "status": "ocr_done", "ocr_excerpt": "姓名：张**，有效期至2035年"}, {"doc_type": "repair_invoice", "status": "ocr_done", "ocr_excerpt": "金额：12,000元，项目：前后杠喷漆、钣金"} ], "missing_docs": ["id_card_front", "bank_card"], "instructions": [ "如果collected_documents中的信息与policy_summary不一致，标记为需要人工复核。", "根据missing_docs输出补材料通知书，语气要专业、友好。" ] }

这个上下文包的设计有一条铁律：永远不要为了让模型"理解全局"就把一份客户十年的保单历史、所有历史对话全部塞进去。信息越精简，模型越容易聚焦，越不容易产生幻觉。那些需要长期查询的数据，用工具实时获取，而不是存进上下文。

3.4 可观测性与审计：每个决策都要能回溯

保险行业监管和内部审计非常严格，Agent必须做到"每一个结论都有据可查"。我们从第一天起就强制要求Harness层记录完整的决策追踪信息，包括：

• trace_id：每次Agent运行的唯一标识，链路追踪用。
• node_id：当前流程节点。
• model_input：传给模型的实际上下文（自动脱敏后的版本）。
• model_output：模型输出的原始内容。
• parsed_action：从模型输出解析出的结构化动作。
• tool_calls：按时间顺序记录的工具调用参数和返回值摘要。
• guardrail_validations：经过了哪些护栏校验，结果是否通过。

我们用一张审计表存储这些记录，字段设计大概如下：

有了这张表，一旦用户投诉理赔结果不合理，我们可以在十秒内调出该案件的所有Agent决策轨迹，快速定位是模型判断错了、工具数据错了、还是规则配置错了。这个能力，在传统人力理赔体系里是难以实现的。

3.5 一个最小可落地的实现示例

这里给出一个简化但可运行的Harness配置伪代码，用于"资料齐全性预审"节点。我们使用YAML描述流程节点和护栏规则，再配合一个调度引擎执行。

flow: name: claim_document_precheck initial_node: start states: - id: start on_enter: trigger_agent transition: to(done) harness: model_config: provider: local_llama temperature: 0.2 max_tokens: 1024 state_machine: allowed_state_transitions: start: [done] tools_allowed_by_state: start: [get_policy, ocr_extract, check_docs, notify_user] tools: - name: get_policy scope: read_only fields_returned: ["policy_no", "coverage_type", "deductible", "insured_name_masked"] - name: ocr_extract scope: read_only fields_returned: ["doc_type", "ocr_text", "confidence"] - name: check_docs scope: read_only fields_returned: ["missing_docs", "completed_docs"] - name: notify_user scope: write_draft require_manual_confirm: false guardrails: - id: output_json_parse validator: parse_and_validate_json - id: missing_docs_consistency validator: compare_with_tool_output on_failure: retry_once_then_manual observability: enable_trace: true log_model_input: masked

调度引擎的运行逻辑可以概括为：先根据当前状态机确定可用工具列表，然后调用模型生成"下一步动作"，Harness解析这个动作，先检查工具权限，再调用对应工具，然后再让模型根据工具返回值生成最终回复，最后执行护栏校验。如果校验不通过，基于"retry_once_then_manual"策略，给模型一次自我修正的机会，仍然不通过就转人工。

4. 踩坑记录与常见问题排查

4.1 Agent幻觉导致误判金额怎么办

有次我们让Agent读取一张维修发票，它在OCR文本里看到"12000"和"1200"，而实际图片上中间那个零被水印挡住了。模型直接依据上下文猜了一个"1200"，然后当作定损依据。幸好Harness层的"数字一致性校验器"拦住了：它把发票金额字段、OCR置信度、维修清单金额、保单限额四个来源做了交叉比对，发现三个不一致，立即转人工。

这一类问题的解决思路很明确：不要信任模型对关键数字的“解读”，关键数字必须用专用OCR模型或规则解析，模型只做汇总和解释。在Harness层加一道数字校验逻辑，比如把模型输出的金额与工具返回的源字段做严格比对，对不上就拦截。我们还对金额字段做了"二次确认提示"：如果模型输出金额和工具返回值一致，但金额大于设定阈值，仍然要求人工确认。

4.2 用户隐私与数据合规在Harness层怎么处理

理赔数据包含大量的个人敏感信息，这是保险公司最紧张的环节之一。我们踩过几次坑以后，总结出几条必须做的事：

第一，日志脱敏。Prompt日志、模型输出日志、检索日志里都不能出现明文身份证号、银行卡号、家庭住址。我们写了一个脱敏过滤器，在数据写入日志之前，自动把命中的敏感字段替换为掩码。模型输入本身也要进行"按需最小化"，不能为了完整而把不必要的敏感信息传给模型。

第二，本地化部署或私有化中间件。对于客户敏感数据，尽量使用本地部署的模型服务，而不是直接调用公有云大模型。如果必须使用云端API，数据链路要做加密传输，并且不能把完整原始影像件发给模型，而是先在本地完成OCR、字段抽取，只把抽取后的文本片段传到模型。

第三，租户隔离。不同险种、不同业务线的数据权限不能共用同一个Agent上下文。我们在Harness层实现了Resource隔离，每个租户的数据只能被自己授权范围内的工具读取。

4.3 成本与性能：多轮Agent调用如何控制在预算内

最初我们不加节制地让Agent在每个案件上执行20到30轮工具调用，费用很快爆表。后来做了两点优化：

第一，规则引擎前置。很多材料齐全性检查根本不需要模型，"是否缺少身份证"直接用代码判断即可。我们用规则引擎先把那些"一眼就能判断"的案件过滤掉，只有规则覆盖不了的歧义情况才交给Agent。实测下来，大约60%的案件完全不需要调用模型。第二，限制最大工具调用轮次。每个Agent节点最多执行8次工具调用，超了就终止并转人工。这样做既控制了成本，又防止了模型陷入"反复试错"的死循环。

4.4 流程僵化与灵活性的平衡

护栏设置得太严格，系统就退化成传统规则引擎，失去Agent的智能价值；设置得太宽松，又会出现各种难以预料的越权和幻觉。我们的建议是"分级授权"：

这个分级表不是拍脑袋定的，而是和业务方、合规方一起梳理出来的。每个具体业务动作都对应一个风险等级，Harness层会把风险等级作为权限决策的输入。有了这个制度，我们就可以放心地让Agent在低风险区域完全自主，在中风险区域部分自主，在高风险区域只做参谋。

4.5 问题排查速查表

最后分享一个我们内部常用的排查表，希望能帮后来者少走弯路。

我自己在这个项目里最深的体会是：Agent只是发动机，Harness才是整台车。发动机再强劲，没有方向盘、刹车和仪表盘，开上理赔这条路就是灾难。先想清楚哪些错误可以容忍，哪些绝对不能发生，然后把这些边界变成代码里的校验、状态机里的转换、权限表里的条目。宁可多写一百行规则，也不要去赌模型永远不会犯错。与其买一个宣称"全自动理赔"的黑盒，不如自己构建一个能容纳AI能力、能随时插拔模型、能审计每一步的工程底座。这套Harness方法论，不仅适用于保险理赔，凡是"高风险、强流程、严合规"的行业，比如银行信贷审核、医疗预授权、供应链风控，都可以复用。希望大家在Agent落地路上，少踩我们踩过的坑。