在政务公文场景中落地 RAG + Agent：技术难点与系统化解决方案

一、背景：为什么"政务公文生成"是大模型最难落地的场景之一？

随着大模型能力的提升，越来越多政府部门希望利用 RAG（Retrieval-Augmented Generation）+ Agent 技术，实现命令、决定、批复、请示、通知等公文的智能生成，以提高行政效率、降低人工负担。

但实践中很快会发现：

政务公文生成并不是"写得通顺"这么简单，而是一个"零容错、高规范、强约束"的复杂系统工程。

与通用文本生成相比，政务公文具有以下显著特征：

事实零容错：不能编造政策、条款、依据
法律合规性强：只能引用有效、适用的法规文件
格式高度规范：标题、文号、主送机关、正文、落款均有固定规则
行政逻辑严谨：不同文种背后对应不同的行政权力与程序
责任可追溯：生成内容必须可审计、可解释、可回溯

这意味着：

👉 "简单 RAG + Prompt"的方案在政务场景中几乎必然失败。

二、整体目标：我们真正要构建的是什么系统？

一个可用的政务公文生成系统，本质上需要满足以下目标：

在严格约束下，辅助人类完成"合规、准确、可审计"的公文起草，而不是替代行政决策。

因此，系统设计的核心不是"模型多聪明"，而是：

如何约束模型
如何控制知识来源
如何固化行政规则
如何切分责任边界

三、核心技术难点分析（按风险等级排序）

难点一：RAG 检索"相似"≠"可引用"

在政务场景中，最常见的问题不是"检索不到"，而是：

检索到的文件行政层级不匹配
文件已废止或部分失效
属于"指导性文件"，却被当作直接依据
不同文件被模型混合总结，产生新的、不可溯源的"结论"

根因在于 ：

通用向量检索并不理解行政法体系，也无法识别政策文件的法律效力。

难点二：大模型"合理编造"的致命风险（Hallucination）

在政务场景中，以下行为都是不可接受的：

自动补充"根据××文件精神"
生成不存在的条款号或文件编号
将征求意见稿当作正式文件
对模糊条文进行"合理发挥"

这些在通用应用中看似"智能"的能力，在政务场景中却是灾难级风险。

难点三：不同公文类型背后的行政逻辑差异

公文类型并非只是"写法不同"，而是权力与程序的不同：

公文类型	隐含行政逻辑
请示	是否超出本级权限
批复	是否逐项回应请示事项
通知	是否面向不特定对象
决定	是否涉及权利义务变动
命令	是否具备明确法定授权

如果系统只"会写"，却不"懂行政"，生成内容就可能程序违法。

难点四：Agent 自治推理的不可控性

在多 Agent 架构中，常见风险包括：

Agent 自行选择不合适的知识源
推理过程中引入未经校验的信息
多轮推理后，结论无法回溯
不同 Agent 给出冲突结论

完全自治的 Agent 并不适合政务系统。

难点五：格式正确 ≠ 行文规则正确

即使语言通顺，也可能存在：

发文机关排序错误
文号生成不合规
文种使用不当（如"通知"误用为"决定"）
附件引用不规范

这些问题往往不是语言问题，而是规则问题。

难点六：可审计性与责任归属问题

一旦生成的公文被采用，出现问题：

是模型错误？
是知识库错误？
还是人工审核失误？

如果系统无法回答"这段话依据哪份文件生成"，就无法在政务场景中落地。

四、系统化解决方案：如何正确构建政务 RAG + Agent

1️⃣ 构建"结构化 RAG"，而不是普通向量库

政务知识库必须是结构化政策库，每条文件至少包含：

json 复制代码

{
  "title": "文件标题",
  "doc_type": "通知/决定/批复",
  "issuing_body": "发文机关",
  "admin_level": "国家/省/市/县",
  "effective_date": "生效日期",
  "status": "有效/废止/部分有效",
  "applicable_scope": "适用范围",
  "key_clauses": ["关键条款"],
  "can_be_cited": true
}

检索策略必须是：先过滤，再相似度匹配

行政层级 ≤ 当前机关
文件状态 = 有效
文件类型 ∈ 允许引用清单

2️⃣ 用"证据驱动生成"替代"自由生成"

核心原则只有一句话：

模型不能"编写依据"，只能"使用依据"。

工程实现要点：

所有"根据""依据"必须来自 RAG 返回内容
强制输出"证据---正文映射关系"
无依据时，模型必须明确提示"依据不足"

3️⃣ 不同公文类型，使用不同 Agent 策略

推荐的 Agent 架构如下：

text 复制代码

├─ 意图识别 Agent（确定公文类型）
├─ 合法性校验 Agent（权限与程序）
├─ 依据抽取 Agent
├─ 公文生成 Agent
├─ 合规审校 Agent

每类公文都有不同的校验逻辑，例如：

请示：是否属于上级审批事项
批复：是否逐项回应请示内容

4️⃣ Agent 必须"流程化"，而非"完全自治"

政务场景不适合"黑箱式自治 Agent"，而应采用：

预定义流程
有限决策节点
明确输入 / 输出 / 校验规则

本质是一个可控状态机（Workflow），而不是自由探索。

5️⃣ 模板 + 规则引擎，而不是端到端生成

正确的做法是：

正文结构模板化
可变字段参数化
文号、落款、格式由规则系统生成

例如：

text 复制代码

标题：关于{{事项}}的{{文种}}

正文：
根据{{政策依据}}，经研究，现批复如下：
一、{{事项一}}
二、{{事项二}}

6️⃣ 构建"可审计"的生成结果

系统必须强制输出：

使用了哪些政策文件
每一段正文对应哪条依据
哪些内容需要人工确认

最终原则是：

模型是起草辅助工具，不是行政决策主体。

五、推荐的整体技术架构（简化）

text 复制代码

用户输入
 ↓
事项 / 文种识别
 ↓
权限与合法性校验
 ↓
结构化 RAG 检索
 ↓
证据整理
 ↓
模板化生成
 ↓
合规审校 Agent
 ↓
人工确认与发布

六、结语：政务大模型的关键不在"生成"，而在"约束"

政务公文场景的成功，并不取决于模型参数有多大，而取决于：

你是否理解行政体系
你是否尊重规则与边界
你是否为模型设计了"不能犯错的机制"

真正可落地的政务大模型，永远是"规则优先，模型辅助"。