政务 Agent 面试不考 prompt，考的是能否把模糊需求拆成合规、可办、可追溯的系统。五个考点：事项规划、工具沙箱、三层记忆、自愈闭环、多 Agent 协同。少一个掉一档。
说出"接个大模型"的那一刻，面试就结束了
题目还原：设计一个能在政务服务场景中自主处理办事预约、材料预审、进度查询、政策适配、投诉受理的 AI Agent，并说清完整架构。
"接个大模型 + 几套办事话术模板"------这个答案一出口，基本可以起身了。
真正被考察的关键词是三个：自主办理、全流程便民、合规可控。落到架构上，就是事项规划、材料校验、办事记忆、异常闭环、系统与监管合规五个维度。逐个拆。
一、规划器：先校验能不能办，再谈怎么拆
铁律：不能让大模型直接处理群众请求。
正确做法是引入规划器，分两层：
- 上层总规划器：把群众需求拆成带依赖关系的子任务，生成 DAG 任务依赖图。
- 下层规则校验节点：每个子任务过一遍政务服务事项库，不通过的直接拦。
举个例子。群众说"我要办居住证续签，顺便查下社保缴费证明怎么开"，规划器先做人脸身份核验，再拆成五步：
- 核验身份与居住证续签准入条件
- 匹配续签所需材料清单，预审已上传的电子材料
- 预约线下办理号，或确认全程网办通道
- 匹配社保缴费证明的办理流程、材料与办理渠道
- 汇总办事指引与预约结果，推送给群众
链条的实际流转如下。注意校验节点在拆解之后、执行之前。
最容易加分的点是事项统一校验机制 ：所有办事规则统一对接官方政务服务事项库，先判断"这事能不能办、是否符合属地与身份要求"，再进执行环节。它的价值是从源头堵死大模型幻觉------不是等它答错再纠正，而是让它根本没机会输出未经校验的结论。
规划器的输出不是自由文本，是结构化 DAG。长这样：
json
{
"session_id": "s_20250610_0001",
"identity_verified": true,
"dag": [
{"id": "t1", "tool": "identity_verify", "depends_on": [], "risk": "low"},
{"id": "t2", "tool": "residence_renew_check", "depends_on": ["t1"], "risk": "low"},
{"id": "t3", "tool": "appointment_book", "depends_on": ["t2"], "risk": "high", "need_human_confirm": true},
{"id": "t4", "tool": "social_security_guide", "depends_on": [], "risk": "low"},
{"id": "t5", "tool": "summary_push", "depends_on": ["t3", "t4"], "risk": "low"}
]
}注意 t3 上挂的 need_human_confirm，下一个得分点展开。
二、工具沙箱：白名单之外，它什么都调不动
大模型碰不了政府核心业务系统，所以必须定义标准化白名单工具接口。
| 工具 | 作用 | 风险等级 | 是否需要人工复核 |
|---|---|---|---|
| 预约办理工具 | 生成线下号源或确认网办通道 | 高 | 是 |
| 材料识别工具 | 预审电子材料完整性 | 低 | 否 |
| 进度查询工具 | 查询办件流转状态 | 低 | 否 |
| 政策匹配工具 | 匹配可办事项与适配政策 | 低 | 否 |
| 投诉登记工具 | 生成投诉工单 | 中 | 视工单类型 |
约束模型输出的三道闸门：防注入 + 参数强校验 + 数据脱敏沙箱。缺一不可。
- 敏感个人信息先脱敏，再进模型上下文；
- 模型输出只能指向白名单内的工具；
- 涉及数据全线的操作，一律先过沙箱校验再执行。
高危操作必须插人工复核节点。 典型高危动作就两个：提交正式办事申请、修改个人政务档案。这类操作让大模型自由输出指令，等于把数据泄露和违规办理打包送上。
三、三层记忆：拉开差距的是长期那一层
Agent 不能失忆，否则群众每次办事都要从"我是谁、要办什么"讲起。
| 记忆层级 | 存什么 | 存储介质 |
|---|---|---|
| 短期会话记忆 | 当前对话上下文、已执行步骤、临时确认信息 | 会话缓存 |
| 中期办事记忆 | 历史办件记录、预约信息、办理进度、投诉处理轨迹 | 关系型数据库 |
| 长期行为记忆 | 办事偏好、常用事项、历史诉求、特殊人群标签 | 向量数据库做检索 |
长期记忆才见真章。群众是老年群体，之前办过养老资格认证，长期记忆里就挂着"特殊服务"标签，Agent 可以主动提供帮办代办通道、大字版指引、语音播报------不用群众自己开口提。
记忆设计直接决定政务服务的温度和精准度。 面试官问这一层，实际是在验证你有没有真正上线过政务级 Agent。
四、自愈闭环：失败路径比成功路径更能说明问题
执行完就结束？不行。用 ReAct 模式做全流程闭环：思考 → 行动 → 观察 → 反思 → 再规划。
一条真实的失败路径：材料预审工具返回"缺少居住地址证明材料"。这时 Agent 不能直接告诉群众办理失败，要自动触发备选流程：
- 先查是否存在可自动核验的电子证照；
- 不行，就告知材料补充渠道与线上上传方式；
- 仍无法补齐，引导就近线下窗口走容缺受理。
自愈策略要成体系，不能一条条硬编码：
| 异常类型 | 自愈动作 |
|---|---|
| 材料缺失 | 匹配电子证照，争取免提交 |
| 流程不符 | 自动修正办事路径 |
| 政策不符 | 自动匹配相近可办事项 |
| 合规风险 | 立即拦截并转人工兜底 |
这张表考的是你对系统鲁棒性和政府服务连续性的理解深度。
五、多 Agent：单 Agent 扛不住多少事项，面试官心里有数
"办事事项那么多、属地政策那么杂，单 Agent 扛得住吗？"------这句追问大概率会来。
这时候要能答出多 Agent 协同架构：一个管控 Agent 负责全局调度与合规总控，下面挂多个领域专家 Agent------事项咨询、材料预审、预约办理、投诉处置。它们之间通过黑板模式共享全局上下文，通过消息队列异步通信。
管控 Agent 接到请求后，把材料预审子任务派给材料 Agent、预约子任务派给办理 Agent，最终汇总结果统一回复。听到这里，面试官会判断你不只懂单 Agent，还懂分布式智能体的架构设计和政府业务域划分。
还有两个点，老练工程师一定会提：
- 模型路由策略：简单的进度查询类任务走轻量小模型降本，复杂的材料预审、政策适配类任务上大模型保准确率。
- 全链路监管与数据安全：所有对话与操作全程留痕、可追溯审计，严格遵循政务数据安全与个人信息保护法规，敏感数据全程加密存储与传输，重要操作执行二次确认。每个 Agent 的决策、工具调用、执行耗时都要有完整日志与监控埋点------线上出问题定位不了、监管追不了责，那就别谈落地。
追问链
Q：大模型给出错误办事指引怎么办？ 规划器层的事项统一校验先拦住，工具沙箱再拦一层，合规风险直接转人工。
Q：办事事项和属地政策太多，规则怎么维护？ 规则统一对接官方政务服务事项库，做配置化而不是写死在 prompt 里。
Q：记忆里存了敏感信息怎么处理？ 敏感字段先脱敏再入库，向量检索层只保留标签和行为特征，不保留原始证件信息。
一句话收束
大模型是大脑，Agent 是守规矩的办事手。 只会调 API，只有大脑没有政务边界，这道题就等于没答。能把政务级落地的细节讲清楚，才是真正能扛民生服务的人。
写在最后
这五个得分点里，我个人觉得最容易在真实项目里翻车的是第三点------三层记忆。政务场景的记忆既要"记得住"群众的办事偏好，又要"留不住"任何不该留的敏感信息，中间的边界全靠自己划。
你们团队在做 Agent 长期记忆时，是怎么平衡个性化体验和合规脱敏的？拆两个库还是同库分表加字段级加密？评论区聊聊。
有用的话点个赞。