笔者长期从事政府网站的建设、运营，在这个AI满天飞的年代，也不可避免要接触AI在政府网站的应用。2025年年初的时候，天真的以为，平台有政策文件、有办事指南、还有常见问答以及一手的政务公开数据，就可以让大语言模型展现出强大的语言理解和交互能力。然而，真正到了落地环节的时候，一个尴尬的现实逐渐浮现：我们无法给到模型有效的知识，模型的总结随着问题的角度不同也可以一本正经的给出不同的答案。

错误的情形层出不穷，例如将"夫妻双方合计提取额度不得超过审定额度"简化成了"每人都能全额提取"；因为匹配关联度高，将已失效的 2021 年版文稿作为现行依据；因为要控制输出的合规定，又导致很多简单的问题无法给出答案。

这些问题的根源，不在于模型参数不够大，而在于数据治理匮乏，更在于未对政策进行系统性的拆解、结构化、治理和更新，从而导致再先进的 AI 也只是一本"会说话的过期手册"。当然最明显的感叹就是为何政务大模型与商业大模型的实际差距会这么大。

经过一年多的洗礼，本文从政策数据治理的视角出发，探讨政务 AI 如何从单业务智能体的深耕细作，走向多智能体协同的规模化应用，并最终实现从技术搭建到业务价值的闭环。

一、单智能体：先在一个业务域里"扎下根"

面对政务领域部门林立、规则异构的现实，最务实的策略不是做一个"全知全会"的超级 AI，而是先选一个高频业务域，建一个懂行的单智能体。以住房公积金为例，这个领域规则相对清晰、咨询量大、社会关注度高，是验证政务 AI 可行性的理想切口。

（一）构建政策可计算资产知识库

单智能体的核心竞争力，在于其知识库的深度，构建结构化数据库、向量语义库、知识图谱三层架构，分别对应政策中的"确定性事实""解释性语义"和"关系性推理"。

（1）结构化数据库——存放"硬事实"

政策中大量内容是可以精确查询的：什么情形可以提取公积金？需要满足哪些条件？有什么限制？这些不适合用向量模糊匹配，而应拆解为结构化的知识单元。

以《深圳市住房公积金管理办法》第二十七条为例，"支付房租"这一提取情形可入库为：

但需要特别指出的是：仅有政策原文是远远不够的。 政府规章（如《深圳市住房公积金管理办法》）通常是原则性、授权性表述，它规定"什么情形可以办""由谁审批"，却不会告诉你"需要带几张身份证复印件""网上办理要填几个步骤""额度具体怎么算"。

真正可落地的结构化知识，必须将政策原文与办事指南、实施细则、操作规程等下位文件进行关联融合。例如，第二十七条虽然列举了"支付房租"这一提取情形，但具体的申请材料（身份证、公积金联名卡、租房合同或无房证明）、办理时限（3个工作日内）、办理渠道（网上/窗口/APP）以及额度计算公式，都来源于《深圳市住房公积金提取管理规定》及对应的办事指南。

在结构化库中，这种关联应该显式化。一个完整的知识单元不仅包含法条依据，还应标注其对应的实施细则和办事指南，确保 AI 在回答"能不能办"的同时，也能准确回答"怎么办""带什么材料""多久办好"。这一点完美的诠释了政策与服务的融合互通。在过往的经历中，理解政策与服务的融合互通是停留在关联层面的，在进行网站的建设运营过程中，还和设计师多次宣贯政策是办事的依据、政策指引办事的理念。现在想来，这样的理念其实更应该应用于AI知识体系的建立过程。

当用户问"租房提取有限额吗"，系统直接命中结构化库，零幻觉返回限制条件。涉及数值的问题（如缴存基数上下限）更应关联参数表，确保返回的是当前年度生效的数值，而非文本中过期的数字。

综合以上，我们得到了如下的基于公积金智能体的结构化数据入库表：

（2）向量语义库——存放"解释性内容"

对于政策原文、办事指南、窗口话术等富含语义的文本，须采用 RAG 向量检索。但分块策略必须"结构感知"：以"条"为最小单元，长条按"款"切分，每个 chunk 头部强制注入 [文件]|[章节]|[事项]|[条款] 的上下文前缀。

然而，不同政策文稿的规范差异极大，不能简单用一套正则表达式"一刀切"。 政府规章可能严格遵循"章—节—条—款—项"的层级；部门规范性文件可能只有"一、二、三"的条目；而通知、公告类文件甚至可能完全没有编号，仅靠段落和加粗标题区分。如果切分策略与文稿规范不匹配，很容易把一条完整的政策切成碎片，或把两条无关的政策硬凑在一起。

切分时的关键原则：

1. 先识别文稿类型：通过文件标题、发文机关、正文前 500 字的结构特征（如出现"第一章""第一条""一、"等关键词）自动分类。

2. 再匹配切分模板：为每种文稿类型配置专用的解析器（正则规则 + NLP 语义边界识别）。

3. 保留上下文前缀：无论哪种文稿类型，切分后的每个 chunk 都必须携带"文件来源 + 所在章节/标题 + 条款编号"的元数据，确保 AI 能准确溯源。

4. 表格和清单不切碎：办事指南中的材料清单、流程步骤表等，应整体保留为一个 chunk，避免"材料 A 在块 1，材料 B 在块 2"导致 AI 漏答。

例如第十六条关于缴存基数的 chunk：

【来源】《深圳市住房公积金管理办法》| 第三章 缴存 | 第十六条

【主题】缴存基数

住房公积金缴存基数是职工本人上一年度月平均工资。新参加工作的职工从参加工作的第二个月开始缴存住房公积金……

这种带"出身标签"的 chunk，能让模型在生成答案时自然标注引用来源，满足政务领域可追溯、可解释的要求。

（3）知识图谱——支撑"跨条款推理"

向量检索擅长"找到相关文本"，但不擅长"判断条款间的关系"。当用户问"我租房提取了公积金，还能贷款买房吗"时，需要同时关联第二十七条（提取情形）和第三十条（贷款条件），并判断两者是否存在冲突。

知识图谱将政策中的实体（事项、情形、条件、限制、主体）及其关系进行建模：

(支付房租)-[属于]->(公积金提取情形)

(支付房租)-[限制]->(合计提取额度≤审定额度)

(购买住房)-[需要满足]->(职工及其配偶均无未结清公积金贷款)

通过图谱查询，系统可以明确告知用户：租房提取不影响贷款资格，但配偶如有未结清公积金贷款，则不能再申请。这种跨条款的精确推理，是单纯 RAG 难以实现的。

以计算贷款额度为例：

这个贷款问题涉及到的计划维护相对复杂，如果仅仅是RAG检索，可能检索到如下信息：

虽然信息的关联度较高，但仍然无法回答这个问题，所以大模型还是无法进行计算：

知识图谱的构建是一个极其庞大的范畴，可以当作一个知识范畴来学习构建，如何构建、如何查询，使其不但能作为AI可应用的图谱关联，也可应用于提升网站信息粘度，知识所限，以后再表。

（二）构建“法条语言”与“百姓口语”的翻译层

结构化数据库、向量语义库、知识图谱存放的是"供给侧"的政策文本，但用户提问使用的是"需求侧"的口语化表达。这两者之间存在巨大的语义鸿沟，而业务常见问答对（FAQ）正是弥合这一鸿沟的关键桥梁。

在公积金领域，法条表述往往严谨但晦涩，而用户的提问却五花八门：

• 法条写"非本市户籍职工不在本市继续就业"，用户问的是"我辞职回老家了，公积金能取出来吗？"

• 法条写"出资更新、改造本市老旧小区具有所有权的住房"，用户问的是"我家老房子加装电梯，能提公积金吗？"

• 法条写"职工及其配偶均未发生住房公积金贷款或者已经全部还清住房公积金贷款"，用户问的是"我之前贷过公积金但还清了，现在买房还能再贷吗？"

如果知识库里只有原始法条，向量检索很容易因为语义差异而漏配；如果只有 FAQ，又可能因为缺乏法条依据而答错。因此，FAQ 的治理必须遵循"一问一答一锚定"原则：每个标准问答对都必须明确关联到具体的政策条款，形成"口语化问题 → 标准答案 → 法条依据"的三段式结构。这一逻辑正好契合了构建“政策问答平台”的初衷，将政策、问答有机的融合，实现更有效的AI知识体系，其作用体现在三个层面：

第一，提升检索召回率。 将 FAQ 的"扩展问"向量化后存入语义库，相当于在用户口语和政策法条之间铺设了多条"语义高速公路"。当用户用"不干了钱能拿出来吗"提问时，系统先命中 FAQ 的扩展问，再沿着锚定关系找到第二十七条，而不是直接在法条中盲目匹配"不干了"三个字。

第二，校准大模型生成风格。 政务 AI 的答案既要准确，也要通俗易懂。纯法条 chunk 喂给大模型，生成的答案可能过于生硬；而 FAQ 中的标准答案经过业务专家打磨，已经实现了"政策准确性"与"表达通俗性"的平衡。大模型可以参考 FAQ 的表述风格，把"非本市户籍职工不在本市继续就业"转化为"如果您是外地户口且已经离开深圳工作"。

第三，持续发现知识盲区。 FAQ 不是静态资产，而应从12345 热线、站网业务问答知识、AI 对话日志中持续挖掘。如果大量用户都在问一个知识库里没有覆盖的问题（如"灵活就业人员怎么交公积金"），说明要么政策解读存在盲区，要么办事指南不够清晰。这类信号应反向驱动知识库的补全——在深圳公积金条例中，第四十七条恰恰规定了"灵活就业人员可以缴存、提取和使用住房公积金"，如果 FAQ 挖掘发现该问题高频出现，就应及时补充对应的问答对和实施细则。

三、用"路由层"解决规模化难题

当公积金智能体跑通后，自然面临横向扩展的问题：医保、市场监管、人社、税务……每个部门都有自己的政策体系和话语体系。此时，多智能体架构成为必然选择。

（一）分域而治，每个部门一个"专家"

多智能体架构的核心思想是：路由层做减法，业务层做加法。

• 路由层（Intent Router）：轻量级，只负责识别用户意图属于哪个业务域（甚至哪个子域），然后将问题分发给对应的业务智能体。

• 业务智能体：公积金智能体、医保智能体、市场监管智能体等，各自维护自己的知识库、规则引擎和对话状态。

这种架构的好处显而易见：

1. 知识边界清晰：医保智能体看不到公积金的政策，从根本上避免了跨部门语义混淆。

2. 迭代互不干扰：医保局更新门诊共济政策，只需更新医保智能体，不会影响公积金智能体。

3. Prompt 高度聚焦：每个业务智能体只需要扮演"本领域专家"，无需在 Prompt 中写满"如果你是 A 部门……如果你是 B 部门……"的复杂条件。

（二）路由虽小，却决定成败

路由层不需要用大模型做复杂推理。对于明确的业务关键词（如"公积金""医保""营业执照"），用轻量分类模型或规则匹配即可；对于模糊表达（如"我辞职了，钱能取出来吗"），可用小参数模型提取关键实体后再做路由。

路由层必须支持三种模式：

（三）跨域协，汇总层与公共知识层

当多个智能体并行回答后，需要一个汇总层（Synthesizer）将各智能体的答案整合为一份连贯的回复，并明确分区标注：

"关于医保：离职后，非深户职工可以申请医保关系转移接续……
关于公积金：如果您是非本市户籍职工且不在本市继续就业，可以办理公积金提取……"

如果两个智能体的答案存在冲突（比如一个说"必须同时办理"，另一个说"可以分开办理"），汇总层应触发人工复核告警，而不是强行整合出一个可能错误的结论。

此外，建议建立一个跨域公共知识层，统一存放通用术语定义（如"职工""家庭""本市户籍"），避免不同智能体对同一概念的解释出现偏差。

四、知识库要从"静态仓库"变成"活资产"

技术架构再完善，如果缺乏持续的业务治理，知识库三个月就会腐烂。政务政策具有高频更新、溯及力复杂的特点，必须建立一套**"发布即治理"**的闭环机制。

（一）确保知识的准确性和时效性

1、政策发布即入库的 T+0 闭环

在公文流转系统中嵌入知识更新节点。政策文件一经签发，NLP 引擎自动对比新旧版本，标红"新增""修改""废止"的条款，生成《知识更新任务单》。业务专员在 24 小时内审核确认后，一键同步到结构化库、向量库和知识图谱。

2、答案分级的审核机制

不是所有 AI 答案都能直接展示。建议设置三级内容：

·      绿色：结构化库直接命中，100% 确定，直接输出。

·      黄色：向量库语义匹配，涉及数值或条件判断，输出时标注"具体以部门审核为准"并强制附带引用来源。

·      红色：知识库未命中、新旧政策冲突或问题超纲，不输出猜测答案，直接转人工客服。

3、自动化回归测试用例库

为每个业务智能体建立测试用例，每次知识更新后自动跑一遍。例如：

·      "新参加工作什么时候缴存公积金？" → 期望：第二个月开始（第十六条）

·      "深汕合作区能提取公积金吗？" → 期望：可以，参照执行（第四十六条）

4、三人治理小组

由业务知识官（审核政策准确性）、数据运营官（分析用户日志、发现盲区）、技术架构师（维护底座）组成，每月例会复盘 AI 答错案例，持续优化知识库。

（二）版本管理与溯及力处理

政务政策更新时，往往涉及新旧衔接。知识库必须保留历史版本，并标注每个版本的生效时段。当用户问"我 2026 年 3 月离职的，适用新办法还是老办法"时，系统能够根据时间轴定位到正确的政策版本，而不是默认返回最新版。

五、结语

政务AI的实践，确实是一个需要不断优化跃进的万里长征。再强大的大模型，也读不懂一份没有拆解的文本；再聪明的 AI，也回答不了一份没有更新的政策。

从单智能体的深耕细作，到多智能体的协同扩展，从技术上的"结构化库 + 向量库 + 知识图谱"三层架构，到业务上的"发布即入库、分级审核、回归测试、治理小组"四道闸门，政务 AI 的落地没有捷径，只有把政策数据治理这件"脏活累活"做到极致。

未来，决定一个政务网站 AI 服务水平的，不会是它接入了哪个最新的大模型，而会是它的政策知识库拆得多细、治得多勤、更新得多快。只有当机器真正"读懂"政府文件，公众才能用上便捷可触的AI政务服务。