企业官网建设流程全解析

简介：这份PDF深度聚焦DeepSeek智能体平台在保险承保理赔全流程中的落地集成，适合保险科技产品经理、AI架构师及数字化转型团队参考。文档共868页、51个大章节，支持目录跳转与书签大纲快速定位，全文文字、图表与代码均保持完整可读。包内仅1个PDF文件，压缩包约20.02MB，浏览学习人数为109人。方案从业务痛点拆解、系统对接规范到数据资产梳理层层展开，涵盖结构化数据解析（含JSON/XML代码）、OCR识别、语义检索、客户身份核验智能体、自动核保规则引擎与AI决策融合等关键环节；同时针对投保材料完整性校验、风险等级预测、产品条款智能解读与复杂保单人工核保辅助提供可实现的技术路径，并配有模型选型、权重计算与部署优化细节。章节导航设计合理，便于按需查阅，可直接支撑技术方案预研与落地参考。

1. 保险承保理赔改造：为什么DeepSeek和智能体平台成了方案主力

一份868页的保险智能化改造方案，落到系统上，核心结构其实特别简单：DeepSeek负责读单据、抽字段、做判断，智能体平台负责调工具、串流程、跑人工审批。真正卡住团队的不是模型能力，而是承保理赔这些环节的断点到底在哪、模型和规则引擎怎么分工、改了之后人工怎么接得住。这篇笔记按我做项目的顺序来写：先拆流程，再选平台接模型，然后落到承保和理赔的具体实现，最后把那些让项目翻车的坑点一遍。适合保险科技团队和大模型流程改造的工程师参考。

2. 承保理赔全流程拆解：自动化集成到底该从哪些断点下手

我接这种改造，第一件事不是选模型，而是把流程画出来。承保和理赔两条链路，人工动作密集的地方就是断点。断点找得准，后面的接入才有价值；断点找不准，模型接得再顺也只是一堆摆设。

2.1 承保链路：录单、核保、出单的三类断点

承保端的断点集中在三个位置。第一是录单，客户提交的投保资料以图片和PDF为主，身份证、银行卡、健康告知、财务报表混在一起。现有OCR模板能识别固定版式，遇到排版乱、手写批注多的单证就废了。第二是核保，人工核保员一天要读几十份体检报告，规则引擎只能判断年龄、职业、保额这些硬字段，对“甲状腺结节伴钙化”这种描述性风险无能为力。第三是出单，产品配置和核心系统的费率表对不上时，需要人工核对报价单，这里也是投诉高发区。

这三个断点的共同特征是：大量时间花在“读”和“搬运”上，真正的专业判断只占一小部分。用智能体改造时，我一般把“读”交给OCR和DeepSeek，“搬运”交给平台里的HTTP工具，“判断”由规则引擎先过滤、模型补充、人工终审。

2.2 理赔链路：报案、查勘、定损、理算的断点分布

理赔链路更长。报案环节，坐席要边听电话边打字，转写内容里时间、地点、三者信息经常缺漏。查勘环节，查勘员拍摄的现场照片和填写的事故报告需要人工比对车辆损失部位和保单责任。定损环节，4S店报价单里的维修项目要和配件编码对齐，是否属于保险责任范围要靠人判断。理算环节，医疗账单要按医保目录剔除自费项目，涉及多个责任方的还要拆分比例。

我见过一家公司在这条链路上配了40多个人专门录入和核对，依然每月产生近千条差错。差错主要来自“同一份单据不同人理解不一致”。自动化的价值不是把人去掉，而是把理解不一致的部分标准化：让模型抽取，让规则校验，让人工只处理模型标记为低置信度的案件。

2.3 核心判断：规则引擎能做的别让模型做，模型只补三块短板

这里要给团队立一个原则：凡是能用规则确定性表达的，一律不进模型。保费计算有公式，免赔额有参数表，责任期有日期校验，这些用规则引擎跑最快，出错还能追溯。大模型只做三件事：

一是理解非结构化内容，比如体检报告中的异常指标、理赔申请书里手写的出险经过。二是处理开放描述，判断事故经过是否自洽、三者信息是否冲突，这类任务没有标准答案，正好是模型的长处。三是输出结构化字段，把一段口语转成案件要素，把一句话转成下一步动作。

这样做还有个审计上的好处：规则引擎的每一步都能打日志，模型建议也记录原始输入和输出。将来监管问起来，条条可查。

2.4 给断点排序：频次、处理时长、错误率、自动化可行性

断点不能一口气全做。我按四个维度打分：日处理频次、单笔处理时长、历史错误率、自动化可行性。频次高、时长长、错误率高、可行性好的是第一优先级。比如医疗发票校验，每天几千笔，错误率不低，OCR加模型抽取后规则引擎校验金额，可行性很高。而复杂伤残鉴定报告，虽然处理时间长，但样本量少，模型误判成本高，我建议放在二期。

打完分之后列一个改造路线图：第一批只上两三个断点，跑通后再扩。不要一上来就把承保理赔全链路自动化，那个目标太大了，中间任何一环失败都会让整体方案被否定。

3. 智能体平台选型与DeepSeek接入：API、Dify、本地部署怎么选

流程拆完，下一步是搭底座。保险客户通常有两个硬性要求：数据不出域、操作可审计。这两点决定了选型和接入方式。

3.1 为什么我选Dify智能体平台而不是自己写编排

保险业务流程长，需要状态持久化、人工审批节点、全链路日志。如果直接用LangChain自己编，开发一个能抗住生产的agent至少要几个月的排期。Dify智能体平台这类产品把工作流、知识库、工具调用都做成了可视化节点，我可以用“工作流模式”把承保理赔每一步的输入输出固定下来，而不是让模型自由发挥。

选平台我只看三点。第一，工具注册是不是方便，能不能把内部系统的查询接口直接暴露成OpenAI function。第二，有没有人工节点，审核员能不能在Dify界面上确认、修改、退回。第三，日志是不是完整，每步prompt、tool调用、返回值都要能回放。Dify在数据不出域和日志方面做得比较均衡，适合保险这种重审计场景。当然，如果客户已经有成熟的API网关和运维体系，也可以只把Dify当作agent编排层，后端接已有的企业微信和内部OA。

3.2 DeepSeek API调用方式：鉴权、参数和返回结构

DeepSeek的API是OpenAI兼容格式，迁移成本很低。我一般用官方Python SDK，把base_url指到DeepSeek的开放接口就行。

import os from openai import OpenAI client = OpenAI( api_key=os.getenv("DEEPSEEK_API_KEY"), base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是保险理赔助手，只输出JSON。"}, {"role": "user", "content": "从报案记录中抽取事故时间、出险地点、三者车牌号。报案记录：今天下午三点在朝阳路与一辆电瓶车发生剐蹭，对方车牌沪A12345。"} ], temperature=0, response_format={"type": "json_object"} ) content = resp.choices[0].message.content print(content)

逻辑说明：system prompt负责约束行为，user放待处理文本；temperature设0是为了让同样输入得到稳定输出，保险场景最怕模型状态飘；response_format强制返回JSON结构，方便下游直接做字段映射。

参数说明：base_url如果走的是内部网关，要注意模型名映射。有的网关需要把model转换成实际部署的模型名，否则会报model not found。我一般会在网关层统一一个别名，业务代码里永远写deepseek-chat，换模型时不动业务。

3.3 工具调用：让模型能查保单、调费率表、读历史理赔

真正让DeepSeek“动手”的是function calling。下面定义了一个保单查询工具：

tools = [ { "type": "function", "function": { "name": "query_policy", "description": "根据保单号查询投保人和险种信息", "parameters": { "type": "object", "properties": { "policy_no": {"type": "string", "description": "保单号，例如P20240001"} }, "required": ["policy_no"] } } } ] resp = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools, tool_choice="auto" ) msg = resp.choices[0].message if msg.tool_calls: for call in msg.tool_calls: print(call.function.name, call.function.arguments)

逻辑说明：模型并不真正执行函数，它只返回“应该调用哪个工具、参数是什么”。应用代码收到tool_calls后，去查保单，把结果作为工具消息回传给模型，模型再基于结果生成下一步。这个循环就是agent的核心，也是agent和llm和ai模型之间的区别：LLM只是会说话的模型，agent是能调工具、能记住上下文、能按照流程干活的完整系统，AI模型是大类，agent是其中的一种应用形态。

在Dify智能体平台里，这个循环被封装成了“工具”节点，你只需要把函数名和参数schema填进去，平台会自动处理多轮调用和上下文。但底层仍然遵守OpenAI的tool call协议，所以理解上面的代码仍然很重要。

3.4 本地部署DeepSeek：显存、并发和延迟的取舍

有些保险客户不允许数据出域，要求模型私有化部署在客户机房。常见做法是用vLLM起一个OpenAI兼容服务：

python -m vllm.entrypoints.openai.api_server \ --model /models/deepseek-ai/deepseek-v2-lite \ --served-model-name deepseek-chat \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --host 0.0.0.0 --port 8000

参数说明：--max-model-len控制上下文窗口长度。保险单证经常一页就有几千字，建议至少给8192，否则长报告会被截断。--gpu-memory-utilization设0.9，留一点显存给tokenizer和推理缓存。--served-model-name写deepseek-chat，这样客户端代码和调用公有云时完全一致，后续切回API不用改业务。

本地部署的性能预期要放低。类似规模的模型做单证抽取，单并发延迟通常在2到5秒。如果业务峰值每秒几十个请求，前面要加排队和缓存。缓存尤其关键：同一保单号、同一份OCR文本的重复请求，结果可以直接复用。

3.5 连接企业微信与内部OA：把人工审批变成消息会话

改造方案里一定要有一个人机接口。我们在Dify里配置了企业微信回调，把待人工确认的核保结论以卡片消息推给审核员，审核员在会话里点“同意”或“退回”。这个接口的好处是：现有员工不需要打开新系统，培训成本低；对话记录自动留存，审计可追溯。

实现上就是用一个HTTP Endpoint接收企业微信消息，把消息转成Dify工作流的输入，再把结果通过企业微信应用消息API回传。注意，生产环境要做消息验签，不能随便接收回调。

4. 承保理赔自动化的实现细节：录单、核保、查勘、定损的落地

底座搭好后，开始做真正的业务。我按承保和理赔两个方向分别讲，每段都给可直接复用的代码和参数。

4.1 承保侧：影像件识别加字段抽取，减少人工录入

第一步是OCR。保险单证种类多，身份证、银行卡、体检报告、营业执照都有。我一般根据单证类型先分流到不同的OCR模板，拿到带坐标的文本后，再让DeepSeek做字段抽取。

import json def extract_fields(ocr_text: str) -> dict: prompt = f""" 你是投保单录入助手。从下面OCR文本中抽取字段，返回JSON： 字段包括：姓名、证件号、投保产品、年收入、健康告知说明。 OCR文本： {ocr_text[:3000]} 要求：缺失字段不要猜，填null。 """ resp = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": prompt}], temperature=0, response_format={"type": "json_object"} ) return json.loads(resp.choices[0].message.content)

逻辑说明：OCR文本直接拼在prompt里，模型只负责抽取，不负责发挥。缺失字段强制填null，是为了让下游规则引擎能识别“没抽到”，而不是拿一个编造的字段往下传。字段上限3000字是为了控住token，体检报告通常几页，截断后关键结论一般都在前半部分。

这里有个血泪经验：OCR识别错误，大模型再强也救不回。所以我要求OCR服务返回每个字段的置信度，低于0.9的直接转人工，不能硬进流程。

4.2 核保决策：规则引擎先跑硬指标，模型处理描述性风险

核保是强监管、强解释的环节，我不能让模型直接输出“拒绝承保”这种终审结论。实际方案分两层：

第一层规则引擎判断：年龄超限、职业类别为拒保、既往病史命中黑名单，这些直接输出拒绝或转人工，不出现在模型环节。第二层模型判断：体检报告里的描述性内容，比如“甲状腺结节伴钙化，建议随访”，规则引擎无法识别，交给DeepSeek按核保手册映射成标准风险标签。

模型输出的是风险点和建议动作，不是最终承保结论：

{ "findings": ["甲状腺结节TI-RADS 3类", "血压偏高145/95"], "suggested_action": "加费承保", "confidence": "medium", "required_human_review": true }

required_human_review为true的案件直接进人工节点。人工确认后，模型建议才会生成正式核保意见。这样既提效，又保住了解释权。

4.3 理赔侧：报案转写与查勘任务的自动分派

理赔侧第一个高频场景是报案。如果客户打客服电话，坐席的录音先走语音转文字，再用DeepSeek抽取事故要素。

def parse_accident_report(transcript: str): response = client.chat.completions.create( model="deepseek-chat", messages=[{ "role": "user", "content": ( "从报案通话转写中抽取：事故时间、出险地点、三者信息、损失部位。" f"转写内容：{transcript}" ) }], temperature=0, response_format={"type": "json_object"} ) return response.choices[0].message.content

抽取完成后，智能体调用查勘调度工具，根据出险地点给查勘员派单，同时把案件编号写回理赔系统。注意，判断出险时间是否超时报案，是规则引擎该干的事，不要放模型里，确定性逻辑交给规则更可靠。

4.4 查勘与票据校验：三方比对的实现思路

定损之前，查勘报告、维修报价单、保单信息要三方一致。手工看很累，自动化做法分三步：

第一步，保单工具返回保险责任范围，包括险别、保额、免赔额。第二步，维修报价单OCR得到维修项目和金额。第三步，DeepSeek把维修项目与保单责任范围做映射，判断碰撞修复是否属于车损险责任，扩项部分是否属于车主自愿增修。

这里要特别小心金额计算。模型可以判断“碰撞修复属于车损险责任”，但最终赔付金额必须由规则引擎按免赔额、折旧率计算。模型算数不稳，让它算钱等于埋雷。

4.5 人工复核界面：把模型依据和原始凭证并排给审核员

我见过太多项目失败，是因为审核员不知道模型为什么这么判，干脆全盘否定。解决方法是界面同时展示三样东西：抽取字段、决策依据、原始凭证截图。依据必须是可引用的原文片段，比如“甲状腺结节TI-RADS 3类，体检报告第3页”。

在Dify里，这些展示项通过工作流的输出变量配置到审核界面；自研系统则直接调业务API拉取。人工修改后的值回传，作为后续模型的few-shot样例，这个闭环是提升准确率最有效的手段。

5. 避坑与排查：智能体跑保险流程最容易翻车的5个地方

这块都是真金白银换来的经验，按“现象、原因、解决”来写，方便你直接对照排查。

5.1 模型答非所问：问题出在提示词上下文不足

现象：让模型从病历中抽取“既往病史”，模型却把主诉当成病史输出。

原因：prompt里没有定义字段边界和示例，模型不知道主诉和既往史的区别。

解决：在system prompt里给出医学定义和few-shot示例。

[ {"role": "system", "content": "你是病案抽取助手。既往病史指本次就诊前已经存在的疾病，不包括本次主诉。"}, {"role": "user", "content": "病历：患者因胸痛就诊，既往高血压3年。抽取既往病史。"}, {"role": "assistant", "content": "{\"past_history\": \"高血压3年\"}"} ]

改完后错误率明显下降。关键是few-shot要贴近真实样本，不是随便写两条。

5.2 智能体死循环：tool calls need immediate results

现象：DeepSeek已经返回工具调用，但编排平台没有立刻把工具结果回传，模型反复重试，最终报错“messages tool calls need immediate results”。

原因：OpenAI兼容协议要求工具调用后，下一条消息必须是工具结果，中间不能夹额外的用户输入或系统提示。平台实现不严谨时就会出现这个错误。

解决：升级到新版Dify，或检查自定义编排中是否在tool_calls之后继续加了prompt组装。通用做法是：一旦检测到assistant消息带tool_calls，就立刻执行对应工具，把所有工具结果以role为tool的消息追加到列表里，再请求模型生成下一轮。

5.3 结构化输出崩溃：JSON解析失败和字段缺失

现象：模型偶尔输出“好的，我为您分析如下”开头，导致json.loads直接抛异常。

原因：虽然指定了response_format，但经过平台网关或本地模型时该参数可能不生效。

解决：双重保险。一是解析前剥掉markdown围栏，二是做JSON schema校验，失败则重试一次。

import json, re def safe_json_parse(text: str): text = re.sub(r"^```json|```$", "", text.strip()) try: return json.loads(text) except json.JSONDecodeError: start, end = text.find("{"), text.rfind("}") return json.loads(text[start:end + 1])

逻辑说明：先处理markdown围栏，再截取第一个左花括号到最后一个右花括号之间的内容作为JSON。重试时temperature设成0，避免同样的随机性再次翻车。对缺失字段，在schema validation里强制设置required列表，缺失就判为抽取失败走人工，而不是拿空值往下传。

5.4 并发一高就超时：本地部署与API的取舍

现象：白天业务高峰，本地DeepSeek服务大量超时，健康告知抽取任务堆积。

原因：显存和GPU数量不足以支撑并发。本地单模型同时只能处理有限请求，每个请求又占住上下文窗口。

解决：把服务拆成“本地模型做敏感数据抽取，API模型做非敏感推理”两路。或者用vLLM做动态batching。我一般还会加一层Redis缓存，同一个保单号、同一段OCR文本的抽取结果，5分钟内直接命中缓存。先拦截重复请求，再谈并发。

5.5 人工不信任AI结论：黑匣子式输出不可持续

现象：审核员一个月后不再看模型建议，全部退回人工，自动化率接近零。

原因：界面只显示结论，不给依据，审核员无法判断对错，所以选择不信任。

解决：把模型的决策依据结构化输出。每条结论后面跟evidence字段，内容是原文片段引用。界面展示时把证据和原文位置同时给出来。这一步做不好，前四步做得再好也白搭。

6. 落地验证与进阶技巧：从试点到全量推广可以这样走

验证方法我用“历史案件回放”。拿过去半年的脱敏案件，让智能体在离线环境下跑一遍，比较AI抽取结果与人工录入结果：抽取字段的精确率和召回率、核保建议与最终承保结论的一致率、理赔审核通过率。注意，回放测试只测准确率，不测时效；时效要单独做压测，用录制好的请求打到部署环境，观察P95延迟和错误率。

灰度发布我建议按险种分批，不要按流量比例。先拿一个标准车险产品试两周，收集人工修改记录，统计“模型初判直接通过”的占比。这个占比低于50%说明模型能力还不够，不要急着扩量。占比超过70%后，再逐步扩大到健康险和意外险。

进阶技巧是让人工修改回流。人工审核界面每发生一次修改，就产生一条校正样本。把这些样本定期整理成few-shot和评测集，模型效果会越用越准。我在第一个试点项目里犯过一个错误：一开始追求全自动，结果审核员不配合，录入数据质量也差。后来改成“AI预审 + 人工终审”，自动化率看起来没那么高，但整体处理时效反而提升了一倍。这个教训我到现在都在用。

回放测试和灰度发布做到位后，这套DeepSeek加智能体平台的组合，替换掉的是重复录入和低级核对，而不是核保和理赔的岗位。希望帮到你。

本文还有配套的精品资源，点击获取