企业官网建设流程全解析

简介：面向政务信息化、数字化从业者的 DeepSeek 政务智能体提效完整方案，聚焦自然语言处理与大数据分析在业务场景中的应用。内容从项目背景与目标切入，梳理高频业务场景与痛点优先级，并给出智能问答、自动化审批、数据智能分析等场景设计；技术层面涵盖系统架构、模块化划分、DeepSeek API 集成、数据安全与隐私保护，以及自然语言理解、业务逻辑处理和多轮对话管理等智能体功能设计，并深入涉及敏感信息脱敏、访问权限控制、数据标注规范与模型微调等落地细节。全文共265页，压缩包为1个docx文档，大小约1.99MB，目录结构完整，从数据准备、开发实施到测试验证均有序展开，适合政务项目团队、方案架构师及AI产品经理用于方案借鉴、需求梳理或技术论证。目前已有66人学习下载，对正在规划政务系统智能化升级的读者具有直接参考价值。

1. 政务系统接入DeepSeek构建智能体，先解决的不是模型问题

政务信息化走到今天，通用大模型的能力边界已经很清楚：直接聊天的价值有限，真正能提效的是围绕业务动作构建的智能体。DeepSeek 在政务场景被反复提及，靠的是中文理解与长文本能力贴合公文任务、API 兼容主流生态、模型权重开放可私有化部署这三点。这篇博文不逐页复述 265 页方案文档，而是把「接入 DeepSeek → 编排智能体 → 落地政务场景」链路里被问得最多的选型、参数与坑讲透。适合售前架构师、政务项目后端工程师与集成运维同学，照着章节推进，半天内能跑通最小可用智能体。

2. 接入层搭建：DeepSeek API 调用与私有化部署的双轨方案

政务系统的接入方式和互联网应用不太一样，数据边界直接决定技术选型。下面按「先 API 验证、再评估私有化」的常见节奏展开，代码可以直接抄。

2.1 为什么政务项目先走 API 再评估私有化

政务系统接入大模型的常规节奏，是先拿 API 跑通业务验证，再根据数据敏感度和并发要求决定是否私有化。API 方式的优势是三天内能出可演示的原型，模型迭代由服务方负责，不需要自建推理集群；私有化的优势是数据不出本域，适合处理内部流转材料，但推理资源、模型运维和版本升级的成本都要自己承担。

我在政务项目中一般这样划分：纯公开的办事指南问答、政策检索，优先用 API；涉及内部流转材料、非公开数据的场景，从一开始就按私有化设计。两者的上层代码可以共用同一套 OpenAI 兼容接口，切换成本主要在 base_url 和密钥配置上，这也是 DeepSeek 接入成本低的原因。

2.2 DeepSeek API 的最小调用代码（OpenAI 兼容协议）

DeepSeek 的 API 与 OpenAI 协议兼容，Python 侧用 openai SDK 就能调通。下面是最小可用的调用示例：

import os from openai import OpenAI client = OpenAI( api_key=os.environ["DEEPSEEK_API_KEY"], base_url="https://api.deepseek.com" ) resp = client.chat.completions.create( model="deepseek-chat", messages=[ {"role": "system", "content": "你是政务办事指南助手，回答必须基于已知材料，不编造政策条目。"}, {"role": "user", "content": "提交机动车注销登记申请，需要携带哪些证件？"} ], temperature=0.3, max_tokens=1024, stream=False ) print(resp.choices[0].message.content)

这段代码的要点有三个。api_key 从环境变量读取，不硬编码在仓库里，政务项目要过代码审计，密钥落库是直接扣分的隐患。base_url 指向 DeepSeek 官方接口，业务系统里建议把它放到配置中心，后续切换私有化服务时只改这一处。temperature 在政务场景压到 0.3 以下，答复偏确定性；做公文起草希望措辞略有变化时，可以放宽到 0.5 附近。

2.3 政务场景下必调的四个请求参数

这里要特别提醒 max_tokens 的边界。它限制的是生成长度，不是对话长度；当多轮会话累积到接近模型上下文上限时，接口会提示「达到对话长度上限，请开启新对话」之类的信息，这是上下文管理问题，需要在应用层做历史消息裁剪，第 4 章会给出具体做法。

2.4 私有化部署的框架选型与显存估算

决定私有化后，常见做法是用 vLLM 或 Ollama 起推理服务。Ollama 适合单机快速验证和小流量场景，一条命令拉模型并暴露 OpenAI 兼容接口；vLLM 适合正式环境，连续批处理的吞吐优势对并发敏感的多智能体场景更友好。

# Ollama 方式：拉取蒸馏版模型并启动服务 ollama pull deepseek-r1:7b ollama serve # 验证服务可用性 curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "deepseek-r1:7b", "messages": [{"role": "user", "content": "你好"}], "stream": false}'

显存估算按「参数量 × 量化位数 / 8」粗算再上浮 20%。7B 模型用 INT8 量化约 7GB 显存，INT4 约 4GB；671B 满血版即便切片部署也不是普通机房能承受的，政务项目更务实的路径是选 7B 或 32B 的蒸馏版本，先跑通流程再评估是否需要更大模型。需要说明的是，蒸馏版在复杂推理上明显弱于满血版，涉及多步推断的任务要提前用评估集验证。

提示：私有化服务切换 base_url 后，检查上下文长度配置是否与 API 版一致，很多「接入后变笨」的案例其实是上下文窗口被框架默认值限小了。

2.5 接入侧的网关与密钥管理

接入侧我会加一层统一网关，把模型调用、限流、计量和审计日志收敛到一个入口。政务系统对调用记录的要求严格，谁的请求、调了哪个模型、生成了什么内容，都要能回查。密钥管理不放进代码仓库，用环境变量或专门的密钥服务注入；每个智能体用独立 Key，便于按业务线核算成本和对账。

3. 智能体编排：从单次问答到工具调用的完整链路

接入层解决的是「模型能对话」，编排层解决的是「模型会干活」。普通问答和智能体之间的差距，就在下面这几节讲的规划、工具调用和知识召回上。

3.1 智能体和普通问答的本质差异

普通问答是「请求 → 生成」的一次性动作；智能体则是在生成之外多了规划、调用、观察、再生成的循环。用政务场景对比：直接问「补办身份证要什么材料」是问答；「根据用户描述判断补办情形，检索对应办事指南，把材料清单整理成可打印的告知单」就是智能体行为，它需要工具调用、分支判断和结果重组。

智能体的搭建框架要包含四件事：模型、系统提示词、工具集、多轮循环的执行器。政务项目里工具集通常先接三类：检索类（政策库、办事指南）、查询类（业务系统接口）、写操作类（生成文档、提交工单）。写操作工具要格外谨慎，必须先人工确认再执行。

3.2 用 Function Calling 让 DeepSeek 调用检索工具

Function Calling 是智能体最核心的交互协议。模型本身不执行代码，它根据用户问题输出结构化的工具调用请求，由应用侧真正执行，再把结果回填给模型继续生成。要让 DeepSeek 正确选工具，工具描述的清晰度比参数个数更重要。

tools = [{ "type": "function", "function": { "name": "retrieve_policy", "description": "检索政策文件与办事指南，返回与用户问题相关的条款片段", "parameters": { "type": "object", "properties": { "query": {"type": "string", "description": "检索关键词，尽量使用用户原话中的业务词"}, "top_k": {"type": "integer", "description": "返回片段数量，范围1-5"} }, "required": ["query"] } } }] # 第一次请求：让模型判断是否需要检索 resp = client.chat.completions.create( model="deepseek-chat", messages=[{"role": "user", "content": "我家老人的社保卡丢了，怎么补？"}], tools=tools, tool_choice="auto" ) msg = resp.choices[0].message if msg.tool_calls: # 应用侧执行检索，把结果追加进消息后再次请求 for call in msg.tool_calls: result = search_policy(call.function.arguments) messages.append({ "role": "tool", "tool_call_id": call.id, "content": result }) final = client.chat.completions.create( model="deepseek-chat", messages=messages, tools=tools ) print(final.choices[0].message.content)

这段循环是智能体最小骨架。messages 里必须保留原始用户消息、模型的 tool_calls 以及对应的 tool 结果，三者靠 tool_call_id 关联；漏掉任何一环，模型就无法理解检索结果来自哪里。search_policy 是应用侧自己写的检索函数，可以是向量库查询，也可以是业务系统接口，模型不关心实现，只认函数名和参数。tool_choice 设为 auto，让模型自行判断是否需要检索；某个场景必须强制走检索时，可以显式把 tool_choice 指定为对应函数名。

3.3 编排平台选型：代码自建、Dify 与 Coze

不自己写编排代码的话，Dify 和 Coze（扣子）是目前团队用得最多的两类平台。Dify 支持私有化部署，工作流可视化，适合政务内网场景；Coze 上手快、插件生态全，云上托管的属性让它更适合对数据出域没有限制的场景。选型的判断依据不是功能多少，而是数据边界在哪。

我在项目中给的建议是：原型期用 Coze 验证交互，确认业务价值后再用 Dify 或代码自建固化，避免原型平台与生产平台的割裂。无论选哪种，智能体的评估标准不变：意图识别准确率、工具调用正确率、最终答复可用率。

3.4 政务知识库的切分、向量化与召回

RAG 是政务智能体必做的一环。政策文件动辄上千行，直接灌进模型不现实，正确做法是先把文档切成片段，向量化后存入检索库，回答时先召回相关片段再让模型生成。切分策略直接影响召回质量：按固定字数切会切断条款语义，推荐按章节标题和条款边界切，片段 400 到 800 字，相邻片段留 10% 重叠。

def split_by_section(text, chunk_size=600, overlap=60): """按段落聚合切分，尽量不切断句号结尾的完整语句。""" chunks, current = [], "" for line in text.splitlines(): if len(current) + len(line) > chunk_size and current: chunks.append(current) current = current[-overlap:] + line # 与上一块保持重叠 else: current += line if current: chunks.append(current) return chunks

这个切分配置的意图是：优先保证每个片段语义完整，overlap 让跨片段的检索词不会因为恰好切在边界而丢失。向量库选择上，单机小规模用 pgvector 足够；数据量到百万级再上 Milvus。政务检索建议加一层重排（rerank），把向量召回的前 20 段重排到前 5 段，答复质量提升明显，代价是一次额外推理开销。

4. 政务场景实战：公文拟稿与办事咨询两个智能体

前面三层是共性能力，这一章落到两个具体智能体上：一个对内提效，一个对外服务。两者对提示词、参数和兜底策略的要求完全不同，分开讲。

4.1 智能体 A：公文拟稿辅助的提示词与参数

公文拟稿是政务办公里提效感知最明显的场景。常见做法是把会议纪要、领导讲话要点喂给智能体，让它先产出通知或请示的初稿，人工再改，初稿能把起草时间压缩一半以上。这类智能体的提示词要把文种、结构、语气约束写死。

你是政务公文写作助手。请按以下要求生成公文初稿： 1. 根据用户提供的素材判断文种：通知、请示、函、批复之一； 2. 结构包含标题、主送机关、正文、落款占位； 3. 正文用「为了…现就…通知如下」句式展开，条目式表述； 4. 语言平实，不使用「确保万无一失」等空话套话； 5. 结尾输出声明：本稿为智能体生成初稿，仅供起草参考，须经正式审核流程。

参数上这类任务用 deepseek-chat 即可，temperature 设 0.5，max_tokens 设 2048。输出里强制要求的免责声明不是形式主义，它把「智能体起草」和「正式发文」的责任边界划清楚了，政务项目上线评审时这一条几乎是必查项。

4.2 智能体 B：办事咨询问答的检索与兜底

办事咨询面向公众，核心是别答错，答错一条政策可能让群众白跑一趟。所以这个智能体的链路是固定的：意图识别 → 检索办事指南 → 生成答复 → 无法置信时转人工。检索结果不够或全部片段得分过低时，强制输出兜底话术。

docs = retrieve_policy(query, top_k=5) # 返回带 text 和 score 的对象列表 if not docs or max(d.score for d in docs) < 0.7: print("抱歉，我暂时无法确认该事项的准确要求，建议拨打 12345 或前往就近的政务服务中心窗口咨询。") else: context = "\n---\n".join(f"材料{i+1}：{d.text}" for i, d in enumerate(docs)) resp = client.chat.completions.create( model="deepseek-chat", messages=[{ "role": "user", "content": f"仅依据以下材料回答，材料中没有的内容回答'材料中未提及'：\n{context}\n问题：{query}" }], temperature=0.2 ) print(resp.choices[0].message.content)

这里两个细节值得抄。召回分数阈值 0.7 不是拍脑袋，它是拿历史问题跑一遍后看「多少该转人工的没转」定出来的，每个项目要自己标定。生成阶段的提示词强调「材料中没有的内容回答材料中未提及」，比单纯说「不要编造」有效得多。多轮对话方面，只保留最近两到三轮消息即可，否则对话一长就容易触发前文说的对话长度上限。

4.3 多智能体的引入时机与拆分方式

场景多了之后会自然遇到一个问题：一个智能体既做公文又做咨询，工具越挂越多，意图判断开始出错。这时再考虑拆分多智能体。常见做法是先加一个意图分发层，按「公文类 / 咨询类 / 通用闲聊」把请求路由到专门智能体，每个专门智能体只维护自己的提示词与工具。

拆分的收益是提示词和工具各自收敛，排错时能快速定位是意图层还是执行层出了问题。但拆分有代价：请求每多跳一层，延迟就增加一次模型调用，链路越深越难排查。我的经验是单智能体挂的工具超过 8 个或意图准确率明显下滑时再拆，不要为了架构好看提前上多智能体。DeepSeek 在意图分发这类轻推理任务上延迟表现足够，真正的瓶颈往往是检索层的外部接口耗时。

5. 提效验收与复盘：三个指标、回归集与高频报错

5.1 上线前先定义三个必看指标

智能体提效方案好不好，不看演示效果，看三个指标：一次解决率，即用户问题不转人工且得到可用答复的比例；人工接管率，即兜底转人工的占比；还有 P95 延迟，政务咨询场景超过 10 秒用户体感就很难接受。这三个指标要在接入阶段就埋点，上线当天和一个月后各对比一次。

5.2 用回归集代替感觉调参

我最常和团队强调的复盘技巧是建回归集：每个业务方向挑 50 条真实历史问题，标注标准答复，每次改提示词、换模型参数或调整切分策略，都拿同一套问题重跑一遍，对比一次解决率变化。回归集不追求大，追求真，真实问题里那些刁钻问法，比测试用例更能暴露「调好一个例子，弄坏一片场景」的问题。

5.3 两个高频报错的应对

「request extension preparation failed」这类请求准备失败，社区里最常见的诱因是单请求上下文过长或并发突增，先把应用层的历史消息裁剪和调用侧限流检查一遍。「达到对话长度上限」则是多轮会话没有清理历史，解决方式是在应用层按 token 数裁剪旧消息，而不是让用户手工重开对话。这两类问题都发生在应用侧，与模型能力无关，排查时先看网关日志，再对着消息体检查。

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