如果你关注过公共服务类系统的数字化改造会发现一个正在发生的趋势许多医疗预约、税务申报、社会福利申领系统正在从传统的“表单 工作流”模式慢慢变成“对话式问答 AI 自动决策”模式。技术圈把这件事概括为一句话AI 正在“打破”旧有的公共服务系统结构。我不打算从政治或体制角度去讨论这个标题真正值得技术人关注的是工程层面的变化——当一个需要审计、稳定、可回滚的公共系统开始接入大模型和 Agent 之后哪些旧架构假设失效了哪些工程手段必须补上。看到这个标题我的第一反应是AI 对公共服务系统的冲击瓶颈并不在模型能力而在传统软件工程范式跟不上。过去做政务或公共服务系统强调流程固定、权限清晰、操作留痕现在做 AI Agent 系统模型输出有概率性工具调用有不确定性连“用户想问的问题到底是什么意图”都可能需要模型自己判断。两套思路碰撞时最危险的不是算法效果不够好而是边界没有想清楚就匆匆上线。这篇文章从四个层面展开。先讲公共服务系统接入 AI 真正会遇到哪些卡点再讲 AI Agent、RAG 和传统系统之间的关系然后给出一套最小可运行的原型代码覆盖问答服务、权限校验、审计日志和幻觉缓解最后讲清楚验证方法、常见问题和最佳实践。读完你会明白AI 改造公共服务系统这件事难的不是选模型而是怎么用工程手段把“不确定的模型”装进“确定性要求极高的系统”里。1. 公共服务系统接入 AI真正的卡点在哪很多人以为公共服务系统接入 AI 的最大难点是模型能力不足。比如问答不准确、理解不细致、多轮对话容易跑偏。但从实际工程视角看这些属于可以迭代的问题真正让人头疼的是下面四个卡点。第一个卡点是历史数据孤岛。公共服务系统往往由多个时期建设的子系统组成有上世纪遗留的关系型数据库有新上的微服务还有大量Excel、PDF甚至纸质扫描件。AI 问答要给出准确答案必须先做数据盘点、清洗、分级和向量化。这个过程通常要占整个项目 60% 以上的工作量而不是像 demo 里那样给模型接一个知识库就完事。第二个卡点是权限边界与审计要求。公共系统涉及公民隐私和机构数据必须做到“谁在什么条件下能看什么数据”。传统系统的权限模型是写死在接口里的而 AI 问答是一个自然语言入口用户不会每次都告诉你“我是哪个科室、要查哪类数据”。如果检索环节不做权限过滤一个普通市民的提问可能让模型从私有知识库里检索出内部政策依据。这个风险比模型答错别字严重得多。第三个卡点是模型幻觉与决策责任。公共服务场景对准确性的要求远高于普通客服机器人。一个社保问答系统如果给出了错误的申请条件用户可能白跑一趟如果一个辅助审批的 Agent 给出错误建议并被人采纳责任归属就会成为大问题。技术人必须接受一个现实大模型给出的答案只是“候选内容”不是“最终结论”。系统设计上必须留出人审、抽查和纠正路径。第四个卡点是灰度发布与回滚机制。传统系统发版很明确代码上线验证新功能出问题就回滚到上个版本。AI 系统的不确定性在于模型本身是概率输出同一套 Prompt 换一个模型版本回答风格和正确率都会变化。更麻烦的是RAG 里的知识库会持续更新数据变化可能导致同样的问题给出不同答案。没有评估集、没有 A/B 对比、没有快速回滚能力AI 系统一旦上线出了问题很难定位是模型问题、数据问题还是 Prompt 问题。所以公共服务系统 AI 化的本质不是“用大模型替代旧系统”而是把 AI 能力嵌入一个已经存在了几十年的复杂系统。真正被“打破”的是传统软件“输入确定、逻辑确定、输出确定”的确定性假设。2. 核心概念与架构认知在写代码之前有必要把几个关键概念说清楚。因为公共服务类系统的开发者很多人对微服务、事务、权限模型很熟但对 Agent 和 RAG 的认知还停留在“会聊天的机器人”阶段。2.1 AI Agent从“回答一句话”到“完成一个任务”AI Agent 可以理解为具备“任务拆解—工具调用—结果汇总”能力的大模型应用。它不只是生成一段回答还会判断需要调用哪个接口、查哪张表、做哪一步操作。比如用户说“我想申请残疾人护理补贴”Agent 可能要拆成“确认申请资格—列出材料清单—查找就近受理点—生成申请指引”几个步骤每一步都可能调用不同的后端服务。但在公共服务系统里Agent 不能拥有过大的操作权限。它更适合做“信息检索、材料整理、流程引导”而不是直接修改核心业务数据。把 Agent 定位成“有大脑的读多写少网关”会比“让 Agent 自动办事”安全得多。2.2 RAG让模型既能回答问题又能回答准确问题RAG即检索增强生成。核心思路是不直接让大模型凭记忆回答而是先从知识库检索出与用户问题相关的文档片段再把“参考资料 用户问题”一起交给大模型生成答案。这么做有三个好处一是答案可以溯源二是知识可以随时更新三是可以按用户权限控制检索范围从而降低越权风险。公共服务领域的知识库有一个特点政策文本经常更新不同层级的规则存在差异。如果只靠模型微调每次政策变化都要重新训练成本高且不及时。RAG 则可以在知识库文档更新后立刻影响回答结果这也是它在公共系统中更受青睐的原因。2.3 传统公共系统架构与 AI 架构的差异传统公共系统一般是“界面 服务接口 数据库”的固定结构。用户录入表单后端校验合法性数据库执行事务系统把结果写回并记录日志。这套架构成熟、安全、可审计但不适合处理开放式自然语言问题。AI 系统的典型链路是“用户输入 → 意图识别 → 权限校验 → 向量检索 → Prompt 拼装 → 模型生成 → 内容审核 → 结果返回”。这条链路多出了检索、生成、审核三个环节任何一个环节出错都会影响最终答案。维度传统公共服务系统引入 AI 后的系统输入结构化表单自然语言 表单输出固定结果概率性文本数据访问接口写死权限检索阶段动态过滤故障排查日志 堆栈需要追踪检索、Prompt、模型响应安全边界数据库权限检索范围 内容过滤 人审兜底上线方式版本发布模型灰度 Prompt 灰度 知识库灰度把这张表理解透你会发现 AI 公共系统并不是推倒重来而是在传统系统前面加了一层“智能问答与决策辅助层”。传统系统仍然是事实来源和事务中枢AI 层负责理解和生成。这个架构边界一旦明确很多技术选型就清晰了。3. 环境准备与前置条件本文的示例代码以 Python 和 FastAPI 为主适合快速搭建原型。虽然生产环境可能是 Java 技术栈但核心设计和排查思路是通用的。下面列出最小环境要求版本请以实际项目为准这里重点演示工程思路。3.1 基础运行环境操作系统Linux 或 macOSWindows 建议使用 WSL。Python 3.9 及以上版本需要支持list[str]类型写法。FastAPI 和 Uvicorn用于提供 HTTP 接口。PyYAML用于加载 Prompt 模板配置。requests用于调用模型网关接口。向量数据库用于知识库检索。生产环境常用 pgvector、Milvus、Elasticsearch 等原型阶段用内存列表也可以。3.2 目录结构规划public-service-ai/ ├── app/ │ ├── __init__.py │ ├── main.py # FastAPI 入口注册中间件 │ ├── security.py # 权限校验与 Token 验证 │ ├── service.py # 问答主流程检索 拼装 Prompt 调用模型 │ ├── vector.py # 向量检索桩实现 │ └── llm.py # 模型调用桩实现 ├── config/ │ └── prompts.yaml # Prompt 模板配置 ├── requirements.txt └── docker-compose.yml这种分层思路适合公共服务类系统接口层只负责接收请求和返回结果安全层负责校验身份服务层负责编排检索和模型调用各自隔离。后续替换向量库或模型网关不需要改接口层代码。3.3 requirements.txtfastapi uvicorn pyyaml requests原型阶段不要为了炫技引入太多重量级依赖。公共服务系统最大的敌人是依赖冲突和不可复现依赖越少问题越容易排查。4. 核心流程拆解从需求到上线一个公共服务 AI 问答系统通常要走过六步。每一步都可以独立验证避免把所有风险积压到最后。4.1 需求冻结与场景裁剪首先明确系统要回答哪些问题。不要一开始就追求“什么都能问”而是圈定 20 到 50 个高频业务问题比如申请条件、材料清单、办理时限、常见拒件原因。把这些问题的标准答案写成问答对作为后续测试集的基础。没有测试集AI 系统上线后基本无法判断改得好不好。4.2 数据盘点与知识库构建整理与这些高频问题相关的政策文档、办事指南、内部口径。每份文档需要标注来源、生效日期、适用范围。然后按业务域拆分片段写入向量库。这个阶段最容易踩的坑是“把没有脱敏的内部文件直接向量化”会在权限层面埋雷。4.3 权限模型设计在写业务代码之前先定义数据分级。比如“公开政策”“登录用户可见”“内部处理口径”三级。向量检索时必须根据用户身份传入允许访问的数据域而不是让模型自行判断。检索阶段过滤权限要比生成之后再审核更可靠。4.4 Prompt 模板管理Prompt 不要写在业务代码里而是放在独立的配置文件中。这样产品、运营、业务专家可以直接调整模板不需要改代码重新发版。同时给 Prompt 加上版本号方便对比不同版本的效果。4.5 接口与审计所有 AI 问答接口都应该经过统一身份认证并记录完整审计日志。日志至少要包含用户标识、问题内容、检索到的文档来源、Prompt 版本、模型版本、生成结果、响应耗时。这样一旦出现争议可以完整还原“用户问了什么、系统查了什么、模型答了什么”。4.6 灰度发布上线时先开放白名单用户配置比例从 5% 慢慢提升到 100%。每次更新知识库或模型版本先用离线测试集跑一遍准确率再放到线上小流量观察。如果发现问题可以快速关闭 AI 入口回退到传统人工问答通道。5. 最小原型代码实现下面用 FastAPI 实现一个最小可运行的公共服务问答系统。这套代码包含了接口入口、权限校验、审计中间件、检索与生成流程以及 Prompt 模板管理。代码只是工程骨架不依赖具体向量库和模型厂商。5.1 FastAPI 主入口# app/main.py import time import uuid from fastapi import FastAPI, Request, HTTPException, Depends from pydantic import BaseModel from app.security import authorize from app.service import retrieve_and_generate app FastAPI(titlePublic Service QA Agent) class Question(BaseModel): question: str session_id: str class Answer(BaseModel): answer: str sources: list[str] request_id: str app.middleware(http) async def audit_middleware(request: Request, call_next): start time.time() response await call_next(request) elapsed_ms int((time.time() - start) * 1000) # 生产环境应写入独立审计库或消息队列 print({ type: AUDIT_LOG, path: request.url.path, method: request.method, user: request.headers.get(X-User-Id, anonymous), status: response.status_code, elapsed_ms: elapsed_ms, }) return response app.post(/api/v1/ask, response_modelAnswer) def ask(question: Question, user: dict Depends(authorize)): request_id str(uuid.uuid4()) try: answer, sources retrieve_and_generate(question.question, user[user_id]) return Answer(answeranswer, sourcessources, request_idrequest_id) except Exception: raise HTTPException(status_code500, detailservice error)这里的审计中间件是全局的它会记录每一次请求的用户、路径、状态和耗时。生产中应该把这段 JSON 写入独立的审计存储或消息队列不能只打印到控制台。5.2 权限校验与 Token 生成# app/security.py import hashlib import hmac import os from fastapi import Header, HTTPException # 实际项目中应从配置中心读取密钥并接入统一身份认证服务 API_SECRET os.getenv(API_SECRET, change-me) def validate_token(user_id: str, token: str) - bool: expected hmac.new( API_SECRET.encode(utf-8), user_id.encode(utf-8), hashlib.sha256, ).hexdigest() return hmac.compare_digest(expected, token) def authorize( x_user_id: str Header(...), x_user_token: str Header(...), ): if not validate_token(x_user_id, x_user_token): raise HTTPException(status_code401, detailunauthorized) return {user_id: x_user_id}这个示例用 HMAC 模拟 token 校验。真实项目必须使用统一认证平台并加入 token 有效期、刷新机制和用户角色。HMAC 只用于解释“每一个 AI 请求都要校验身份”这个工程原则。5.3 问答服务主流程# app/service.py import os import yaml from app.llm import call_llm from app.vector import vector_search _PROMPT_CACHE None def _load_prompts(): global _PROMPT_CACHE if _PROMPT_CACHE is None: with open(os.path.join(os.path.dirname(__file__), .., config, prompts.yaml), r, encodingutf-8) as f: _PROMPT_CACHE yaml.safe_load(f) return _PROMPT_CACHE def build_prompt(question: str, docs: list[dict]) - str: prompts _load_prompts() template prompts[rag_question][template] context \n---\n.join( f文档{doc[source]}: {doc[content]} for doc in docs ) return template.format(questionquestion, contextcontext) def retrieve_and_generate(question: str, user_id: str): docs vector_search(question, top_k3, allowed_domains_get_domains(user_id)) prompt build_prompt(question, docs) answer call_llm(prompt) sources [doc[source] for doc in docs] return answer, sources def _get_domains(user_id: str) - list[str]: # 真实系统应从权限中心获取用户可访问的数据域 return [policy_public, personal_service]这里有一个容易被忽略的设计_get_domains决定了用户能检索哪些数据域。即使前端隐藏了入口只要接口允许传用户 ID就必须在服务端重新计算权限而不是信任前端传来的角色字段。5.4 向量检索与模型调用桩# app/vector.py def vector_search(query: str, top_k: int, allowed_domains: list[str]) - list[dict]: # 实际项目连接向量数据库构造权限过滤条件后做相似度检索 return [ { source: policy_public_001, content: 根据相关政策申请残疾人护理补贴需要身份证、居住证和残疾证明。 }, { source: policy_public_002, content: 低保家庭申请流程需先在社区服务站提交材料审核周期通常为15个工作日。 }, ] def call_llm(prompt: str) - str: # 实际项目调用统一模型网关网关负责限流、内容安全和模型路由 return ( 根据资料申请残疾人护理补贴目前需要身份证、居住证和残疾证明。 具体材料以当地窗口要求为准。 )这个桩实现的意义是让整个链路先跑通。你可以先不接真实的向量库和模型服务用固定返回验证权限、审计和接口流程然后再替换为真实实现。5.5 Prompt 模板配置# config/prompts.yaml rag_question: template: | 你是一个公共服务问答助手。请严格基于以下资料回答问题。 如果资料中没有相关答案请直接回答“资料库中暂未收录请联系人工窗口咨询”。 不要编造政策条款不要使用资料库之外的信息。 用户问题 {question} 可参考资料 {context} 要求 1. 只能引用资料中的内容。 2. 回答结束后列出引用的资料编号。这份 Prompt 的关键不是“回答得多好”而是“回答错了怎么办”。它明确要求模型在资料不充分时放弃回答并给出兜底话术。公共服务场景里承认不知道比乱编一个答案安全得多。5.6 生成测试 Token 的命令pip install fastapi uvicorn pyyaml requests export API_SECRETchange-me python -c import hmac,hashlib,os; secretos.getenv(API_SECRET,change-me); uiduser_123; print(hmac.new(secret.encode(), uid.encode(), hashlib.sha256).hexdigest()) uvicorn app.main:app --host 0.0.0.0 --port 8080生成 Token 后用下面的 curl 请求验证接口curl -X POST http://localhost:8080/api/v1/ask \ -H Content-Type: application/json \ -H X-User-Id: user_123 \ -H X-User-Token: 上一步生成的token \ -d {question: 残疾人护理补贴的申请条件是什么, session_id: s_001}如果 Token 错误接口会返回 401如果正确会返回带有答案、来源和请求 ID 的 JSON。这里最重要的验证点是当用户身份变化时服务端重新计算数据域并影响检索结果而不是让用户自己决定能看什么。6. 运行结果与效果验证启动服务后先不要急着接真实模型。建议按下面的顺序验证系统是否健康。6.1 权限验证用一个错误的 Token 请求接口预期返回如下{ detail: unauthorized }这一步确认没有 Token 就无法访问 AI 接口。公共系统最怕“接口公开数据裸奔”权限校验是第一道防线。6.2 正常问答验证用正确的 Token 请求预期返回类似{ answer: 根据资料申请残疾人护理补贴目前需要身份证、居住证和残疾证明。具体材料以当地窗口要求为准。, sources: [ policy_public_001 ], request_id: xx-xx-xx }需要确认两点一是答案是否严格来自 source 列表中的文档二是 request_id 是否与审计日志中的请求 ID 对应。这样后续追责才能有据可查。6.3 幻觉回归测试准备一组“知识库中没有答案”的问题比如一个虚构政策名。预期模型回答“资料库中暂未收录请联系人工窗口咨询”而不是编造一个政策条文。如果模型开始自由发挥说明 Prompt 约束失效需要调整模板或增加内容审核。6.4 可观测性验证观察控制台输出的审计日志是否包含完整字段。真实项目还应该接入链路追踪和指标监控重点指标包括检索耗时、模型生成耗时、单次问答总耗时、来源命中率、拒答率。这些指标决定了你能否在用户投诉前发现问题。6.5 失败时先看哪里如果接口 500 报错优先检查四个位置一是权限模块是否异常导致用户身份拿不到二是向量检索是否超时三是模型网关是否限流四是审计日志是否因为写入失败阻塞了主流程。公共服务系统里审计链路故障宁可降级也不要影响业务接口。7. 常见问题与排查思路下面这些问题是公共服务 AI 项目中常见的高频故障按表格整理方便实际操作时快速定位。问题现象可能原因排查方式解决方案用户能看到其他辖区政策检索阶段未按区域过滤查看审计日志中的检索条件在向量检索参数中加入区域权限过滤模型回答中出现编造条款知识库未覆盖该问题Prompt约束不足跑幻觉回归测试集强化拒答指令增加兜底话术同一问题不同用户答案不同且都正确权限不同导致检索范围不同对比两个用户的数据域属正常现象但需在 UI 提示“按您的权限展示”接口响应越来越慢检索或模型调用无超时控制查看监控指标中的分位耗时为检索和模型调用设置独立超时启用缓存更新知识库后答案变差新文档清洗不完整片段拆分不合理对比新旧版本测试集准确率上线前跑回归测试做到可回滚Audit 日志缺失审计写入异常被吞掉检查消息队列或数据库写入失败率引入降级策略确保审计不阻塞主流程模型被诱导输出内部口径方法人审与内容安全检测用红队问题集进行安全测试增加内容安全网关关键场景转为人工审核这些问题的共同点是不能只靠改模型解决。它们发生在数据、权限、流程和运维层必须用工程手段处理。8. 最佳实践与工程建议如果要把这套原型做成生产级公共服务系统下面几条建议值得提前考虑。8.1 数据分级是 AI 权限的第一道锁在知识库构建阶段就完成数据分级比事后补救便宜得多。公开政策、登录用户可见、内部处理口径必须分库或者打上清晰标签。向量检索时把用户的数据域作为硬过滤条件而不是把过滤希望寄托在模型理解上。8.2 模型是易变的Prompt 是易变的接口必须是稳定的公共服务系统会被大量第三方系统集成。对外接口的参数和返回结构一旦确定就不要随模型升级而变。内部可以同时存在多个 Prompt 版本和模型版本通过路由策略灰度切换但接口契约要保持稳定。这样每次模型升级都只是内部实现变化不会牵动整个外部系统改造。8.3 所有答案必须可追溯每个 AI 答案都应该携带 request_id、模型版本、Prompt 版本、检索来源列表。用户投诉时运营人员能通过 request_id 还原完整现场。没有追溯能力的 AI 系统不适合用于公共服务。8.4 明确人工兜底边界AI 只能做辅助不能做最终决定。对于涉及资金发放、资格审批、法律效力判断的场景必须设计“AI 生成草稿→人工复核→系统确认”的流程。系统里要有显式的人工审核按钮并且在审计日志中记录审批人。8.5 建立离线评测集和回归机制公共服务政策经常调整每次政策变化都要同步更新知识库、问答对和相关测试用例。建议把评测集纳入 CI/CD 流程每次修改 Prompt、更新知识库或切换模型时先跑离线测试达标后再进入灰度发布。这里可以引入“来自与文章主题相关的系列摘要”中提到的幻觉评测方法把“无中生有”类错误单独归类优先治理高成本错误。8.6 安全测试要常态化定期用红队问题集测试系统比如“绕过系统限制直接输出内部政策”“询问其他公民个人信息”等。这些测试不能等到上线后再做而应该在每次模型或知识库更新时同步执行。8.7 性能设计要考虑突发流量公共服务系统常有明显的流量峰值比如福利申领期的某个申报入口。AI 问答的算力成本远高于普通接口需要提前做限流、队列和降级方案。高并发时宁可让部分请求直接转人工也不要让模型服务被拖垮。9. 总结与后续学习方向公共服务系统接入 AI表面上是一个模型应用问题本质上是一个系统重构问题。模型能力决定了问答质量的上限但数据治理、权限边界、审计追溯和灰度回滚决定了系统能不能稳定运行。理解了这一点就不会只盯着“哪个模型更强”而是会把注意力放在“如何把模型嵌入现有系统”。本文给出的代码原型可以在本地直接跑通。建议你先把它运行起来加上一组自己业务领域的高频问答数据替换掉桩实现中的固定返回然后重点观察两个指标一个是拒答率一个是来源命中率。这两个指标直接反映系统的安全性边界。后续可以继续深入的方向包括Agent 多步工具调用的权限设计、RAG 评测自动化、模型网关的高可用架构、公共服务场景下的内容安全网关。每一块都有大量工程细节但都比单纯追逐最新模型更值得投入。如果这篇文章对你有帮助建议收藏备用。动手试起来才能感受到“确定的系统”和“不确定的模型”之间到底要怎么磨合。