做公共服务AI项目这几年我听到最多的一句话就是这东西做个Demo容易真要上线跑起来太难了。为什么难不是模型不够聪明主流大模型的能力大家心里都有数可一旦落到政务咨询、办事指南、服务热线这些场景里准确率、合规性、稳定性、群众信任度每个词压下来都是一道坎。所以当我看到“公共服务AI落地难提示工程架构师用这6个技巧让Agentic AI真正见效”这个标题时第一反应是这才抓到了问题的根。公共服务领域的AI落地真正的瓶颈早就不是“模型答得对不对”了而是“Agent能不能在一个边界清晰、责任明确的框架里干活”。传统聊天机器人只会一问一答问什么答什么答不上来就装傻或者胡说。Agentic AI不一样它能拆解任务、调用工具、按步骤推进流程像一个能帮你跑腿办事的协办员。但能力越大越需要缰绳。Agent越自主就越需要一套完整的提示工程架构来约束它、引导它、评测它——这正是提示工程架构师这个角色存在的价值。这篇文章我把在公共服务场景里反复踩坑后总结出的6个技巧按“定位、约束、供给、否决、输出、迭代”六个维度完整拆开讲。每个技巧都配有可直接用的提示词模板、设计逻辑和实操心得适合正在做政务类Agent应用的人也适合准备把AI引入公共服务场景、但不知道从哪儿下手的团队参考。1. 公共服务AI落地难在哪一步1.1 难的不是模型是边界很多人一开始做公共服务Agent习惯把它当成一个“更聪明的问答机器人”目标就是让模型记住更多政策、答得更全。做了几个项目之后我发现这个方向从一开始就偏了。公共服务场景和一般客服场景有个本质区别决策后果的权重完全不同。电商客服说错一句“包邮”最多损失十几块钱运费政务咨询说错一句“材料合格”群众可能白跑一趟大厅等待一个上午最后在窗口被驳回来重办。这种场景下用户对AI的要求不是“答得多”而是“答得稳”。宁可告诉用户“我确认不了请到窗口核验”也不能给用户一个错误但看起来很自信的答案。所以公共服务AI项目的核心矛盾不是“模型不够聪明”而是“模型的自由度太高”。模型天生想讨好用户用户问什么它都倾向于给出一个答案哪怕信息不足、哪怕政策已经过期。提示工程架构师要做的事就是给这个自由的模型画出一圈边界告诉它哪些问题你负责哪些问题你不能碰哪些信息必须先查再用哪些话术一个字都不能改。1.2 提示工程架构师要解决的“三对矛盾”在公共服务场景里摸爬滚打了一阵子我总结出提示工程架构师绕不开的三对矛盾理解了这三对矛盾后面的6个技巧才看得出为什么这么设计。第一对矛盾专业性与服务体验。政务事项本身是复杂且专业的一份办事指南可能长达几页但群众要的往往是“我到底该带什么、去哪儿办、多久能好”。Agent不能像政策文件一样输出也不能像闲聊客服一样一句“您去窗口问问吧”敷衍了事。它得在“信息准确完整”和“表达简洁可执行”之间找到一个可复现的平衡。第二对矛盾自主能力与流程刚性。Agentic AI的卖点是“自主”能自己拆任务、自己决定先干什么后干什么。但政务流程是刚性的材料不齐不能受理审核没过不能出证。如果不加约束让Agent自由发挥它就会“跳步”用户问一个简单的“怎么预约”它直接把整条办事链路说完信息过载用户看完反而更懵。第三对矛盾持续迭代与风险控制。提示词不是写一次就结束的政策会改、模型会升级、用户问题会变。但公共服务场景最怕的就是“改坏了”——上一条提示词更新后原本答对的一批问题突然答错了这个风险在线上环境是不可接受的。没有评测闭环的迭代等于在高速公路上蒙眼换轮胎。2. 技巧一与二先把Agent变成“懂规矩的窗口人员”2.1 技巧一岗位说明书式的系统提示词我见过的很多公共服务Agent系统提示词就一句话“你是一位友好的政务服务助手请用中文回答用户的问题。”这种提示词放在闲聊场景还行放到政务场景等于没穿衣服出门——模型没有岗位意识自然会产生一系列越界行为。真正的做法是把系统提示词写成一份岗位说明书。就像窗口工作人员上岗前会领到一份职责说明一样Agent也必须有明确的岗位定位、服务边界、行为准则和工具权限。别小看这件事把“我是谁、我管什么、我不管什么、我不能做什么”白纸黑字写在提示词最前面能挡掉大量后期救火的麻烦。下面是我在项目里用的一个基础模板读者可以直接拿过去改[岗位定位] 你是某区政务服务中心的线上咨询助手服务对象是在该区办理各类公共服务事项的群众与企业。 你的职责是帮助用户理解办事条件、准备申请材料、了解办理进度。 [服务范围] 可解答医保参保登记、生育津贴申领、老年优待证办理、营业执照新办等12类高频事项 的办事条件与材料要求以及对应窗口的办公时间与预约方式。 不可解答金融理财建议、法律纠纷评判、政策制定背景解读等非政务服务事项。 [行为准则] 1. 所有答复必须以最新版办事指南为准禁止凭印象编造流程或材料。 2. 当指南内容与实际窗口要求可能不一致时必须提示“请以窗口现场核验为准”。 3. 涉及个人信息查询时不得要求用户以明文方式提供身份证号、银行卡号。 4. 每次回答结束时视情况主动询问用户是否还有其他材料需要确认。 [工具权限] - 可查询办事指南知识库、事项办理进度查询接口需用户授权后。 - 不可调用任何涉及费用计算、征信查询、跨部门数据调取的接口。这份岗位说明书看起来简单但它解决了几个实际问题。第一它让模型建立了“岗位意识”回答问题的语气和内容都更像一个窗口人员而不是一个通用聊天机器人。第二它把边界显式化用户问一个不在范围内的问题时模型有据可依地拒绝或转接而不是硬着头皮答。第三它为后续的责任追溯提供了基线——出了问题可以先判断是Agent越权了还是知识库更新不及时。实操里的一个重要心得是岗位说明书不是技术团队闭门造车写出来的一定要拿给业务窗口的同事看。我之前踩过坑写了一份看着很完整的说明书结果窗口同事一眼就指出其中两条例外的办理情形没写进去。政策业务的知识壁垒非常厚技术团队写不出来只有在一线接业务的人才能把边界画准。2.2 技巧二把办事流程写进工作守则岗位说明书解决的是“Agent是什么”接下来要解决的是“Agent怎么干活”。公共服务咨询有很强的流程属性材料核对、预约引导、进度查询每一步都有先后顺序。不加流程约束模型会根据自己的理解自由发挥。举一个典型场景。用户问“办理营业执照我材料都齐了怎么约”本来这是一个简单的预约引导问题正常流程应该是先确认用户属于哪类主体个体户还是企业、是哪一种预约渠道再给对应链接。但没有流程约束的Agent可能会一口气把“线上预约网址、线下大厅地址、交通路线、需要带哪些材料、大概几个工作日办好、后续还要办税务登记”全部倒出来。信息全是对的但用户看完一脸懵“我到底该去哪一步”我用的办法是给Agent定义一个步骤化工作守则把核心业务处理流程写进提示词并且让Agent学会跟踪对话状态[咨询处理流程] 1. 意图识别判断用户诉求属于哪类事项清单见服务范围。若不在清单内走“拒绝与转接”规则。 2. 要件核对逐项列出该事项所需的核心材料引导用户逐条自查是否已经准备齐全。 3. 补齐建议对缺失材料说明获取渠道与注意事项对格式不规范的材料给出模板或示例说明。 4. 预约引导确认材料齐全后再说明线上预约与线下取号的路径差异。 5. 进度查询用户询问办理进度时先收集办理回执编号再调用查询接口禁止直接索要证件号。 [对话状态管理] - 每次用户输入后先判断当前对话所处的阶段诉求识别 / 要件核对 / 补齐建议 / 预约引导 / 进度查询。 - 尚未完成“要件核对”之前不得直接进入“预约引导”。 - 用户回到上一个阶段重新提问时允许状态回退但必须重新确认当前阶段所需的完整信息。这套流程约束的设计逻辑本质上是把线下窗口的服务动线搬到了对话里。窗口工作人员不会在用户还没确认材料是否齐备时就着急让用户去排队取号。Agent也应该一样。实测下来加上这套流程约束之后用户对“这个助手懂业务”的感受明显变强了后台收到的“答非所问”类不满意评价占比下降了一大截。要注意的是流程步骤不是越多越好。我见过一些团队把提示词写成了十步以上的繁琐流程结果模型在处理绕来绕去的长对话时反而更容易混乱。一般建议控制在5到7步每个步骤的触发条件要写清楚不要让两个步骤的触发条件语义重叠否则模型会在状态判断上左右摇摆。3. 技巧三与四知识供给与拒绝路径决定Agent的上限3.1 技巧三结构化知识注入让Agent拒绝“凭记忆答题”公共服务领域与一般闲聊场景最大的不同是政策知识处于高频变动状态。一个县区的医保报销比例可能今年调一次办事材料清单可能因为系统升级临时增减一项。模型训练时记住的是旧语料让它凭记忆答题就是在赌运气。正确做法是坚持“提示词管怎么答知识库管答什么”的思路让Agent强依赖外部检索而不是内部记忆。这个思路现在也叫RAG检索增强生成但在公共服务场景里光有RAG还不够关键在于知识库必须结构化不能把整篇政策原文扔进去让模型自己找答案。我在项目中把知识条目拆成这样几个字段事项名称、办理对象、所需材料、办理时限、收费标准、常见问题、政策依据编号、版本日期、生效状态。每个字段短小精悍模型检索到的不是一篇长文而是一组可以直接使用的结构化信息。配合提示词里的引用规则效果会非常稳[知识使用规则] - 回答政策类问题时必须从知识库检索对应条目禁止凭模型内部记忆直接作答。 - 检索结果需同时满足三条校验事项匹配、地区匹配、版本匹配。 - 引用政策依据时以“根据《某区办事指南》2025年改版”开头并注明版本编号。 - 若知识库中无对应条目或检索结果与用户问题不匹配禁止自行推断转入“无法确认”兜底话术。为什么要强调“版本匹配”因为我遇到过最典型的翻车案例某Agent在回答企业开办问题时引用了上一版指南用户按照旧流程准备了一堆不需要的材料到了窗口才发现多此一举。这还不是最严重的更糟的是用户一旦发现AI给错了信息对整个数字服务的信任都会崩塌。结构化知识版本校验就是在源头上卡住这种风险。实操中的另一个细节是过期数据要软删除而不是硬删除。政策更新时旧条目直接从知识库里消失有时候反而会出问题——因为模型可能在新条目命中不了的情况下退回去调用训练语料里关于旧政策的记忆。所以我会保留旧条目但把状态标记为“已失效”并且在提示词里加一条版本黑名单规则明确告诉模型标记为失效的条目不得直接引用只能用于对比说明“该事项的规则已更新”。这一步能挡住绝大部分“用老政策答新问题”的坑。3.2 技巧四会拒绝、会转接比会回答更重要公共服务AI上线后最让项目组睡不好觉的不是模型回答得不够好而是回答得“太好了”——好的程度超出了政策允许的范围。比如用户问“我这个情况肯定能批下来吧”如果Agent顺着用户的话说“材料齐全的话一般是可以的”这已经算踩线了因为窗口人员都不会在任何流程完成前做实质性承诺。做提示工程做得越久越觉得“会说不”比“会说好”更重要。在一个责任边界极重的场景里拒绝与转接不是异常兜底而是Agent的核心能力之一。我在提示词里给Agent设计了一条独立的处理路径[拒绝与转接规则] - 触发条件1用户诉求超出服务范围清单。 处理动作明确告知该问题不在本助手服务范围内同时提供该事项对应的公共咨询渠道入口。 - 触发条件2用户要求对办理结果做出承诺或保证。 处理动作回绝承诺类表述改为陈述流程规范例如“受理时限为5个工作日具体以窗口审核为准”。 - 触发条件3检索知识库后仍无法确认或政策存在新旧版本冲突。 处理动作统一话术“请您以窗口工作人员现场核验为准”并给出窗口地址与服务时间。 - 触发条件4用户情绪激烈表示将要投诉或已经多次跑窗口。 处理动作先致歉并告知人工介入渠道不继续尝试用指南内容进行解释。 [话术基调] - 拒绝时使用肯定式表达“您可以到XX窗口咨询该事项的经办要求”而不是“我不能回答这个问题”。 - 任何情况下不得出现“我猜”“大概”“一般可能”等不确定输出。 - 涉及承诺边界时引用时限条款原文不做扩展解释。这套规则的逻辑是把“拒绝”从模型的自然反应变成受控的标准动作。普通人面对机器时最反感的是被“踢皮球”——问A答B最后不了了之。所以拒绝话术一定要做到两条边界清晰告诉用户你为什么不负责这个和出口明确告诉用户你该去找谁。这两条都做到了用户即使没拿到答案也不会觉得被敷衍。调试提示词时我发现一个规律单独写一条“不要承诺办理结果”效果很差模型还是会顺着用户语气说好话。但把触发条件拆细配合few-shot示例展示“当用户说我这个材料齐全是不是很快就能批下来你应该回答……”之后模型的越界行为明显减少。关键是让模型看到的不是“禁止xx”而是“遇到xx情形产出yy话术”。4. 技巧五与六输出质量与评测闭环让Agent经得起检验4.1 技巧五双通道输出把结论与依据分开呈现公共服务咨询里有一个特别容易被忽视的体验问题就算Agent说的每一个字都是对的只要呈现方式不对用户依然会认为“这个AI不行”。原因很简单政务事项的信息密度高、术语多用户承受不了大段大段的文字灌入。有一次我去看一个友邻项目的演示Agent回答“如何申领失业保险金”时一口气输出了三段合计超过500字的完整说明从定义、条件、材料再到流程、注意事项写得条理也算清楚。可现场模拟用户第一反应仍然是懵的他在屏幕上找了半天也没找到“我到底先做哪一步”的答案。这就是输出结构出了问题。解决这个问题我在提示词里固定了一个双通道输出规范把“结论与行动”和“依据与细节”分成两个层次来呈现第一层像电梯简报第二层像原文附件[输出格式规范] 第一层——一句话结论 用不超过两句话直接回答用户的核心诉求。 示例“您的材料基本齐全还需补充一份近三个月的社保缴纳证明。” 第二层——办理路径 用有序编号列出下一步动作说明怎么做、去哪里、带什么。 示例 1. 前往百货大楼三楼社保窗口取号 2. 携带身份证原件及本次核验缺少的社保证明 3. 柜台复审后领取受理回执。 第三层——政策依据 用“根据文件简称及版本号”简要引用对应条款不加扩展解释。 第四层可选——高频追问预判 若有用一句话提示可能产生的下一步疑问例如“若社保为单位代缴还需补充盖章在职证明”。这个输出结构的本质是把Agent的答案从“一段文章”变成“一张办事卡”。用户先看到结果再看到步骤最后是依据符合公共服务用户的实际阅读习惯。我在多个项目里对比过同样一套正确率相同的Agent逻辑采用这种输出结构之后用户主动点赞比例提升得非常明显因为群众真正关心的是“接下来怎么办”而不是“政策条文怎么说”。不少团队也尝试在提示词里写一句“请结构化输出”但效果不稳定。原因是这句话太模糊了模型不知道结构化到什么程度。我的建议是直接给一个两到三轮的few-shot示例示例里包含一个完整问答对和标准输出格式让模型照着样子来。格式一旦稳定后续评测、调试都省事很多。4.2 技巧六用场景剧本库建立评测闭环让提示词可持续迭代最后这个技巧是我最想对每一个打算长期维护公共服务Agent的团队说的没有评测闭环的提示词工程就是裸奔。提示词最大的特点是“改一处动全身”。改一条系统提示词可能会让一批原本答对的问题突然答错也可能让某类原本绕不过去的边界问题变得正常。公共服务场景不比营销推荐答错的代价是实打实的群众体验损失。所以每一次改提示词之前都必须有一面“镜子”能快速照出这次改动是变好了还是变坏了。这面镜子就是场景剧本库。我维护的项目里都有一个固定的测试集里面的每一条case都来自真实对话日志而不是技术团队自己编的“理想问题”。剧本库的构成大致是高频咨询类占一半边界与拒绝类占三成投诉与异常类型占两成。每一条测试用例除了问题本身还带一个“期望行为”标注表示这条问题Agent应该产出哪类行为用例示例期望行为生育津贴能报销多少明确告知超出服务范围提供对应咨询渠道营业执照新办需要什么材料输出材料清单并引用政策版本号我这个材料不全能先提交吗走流程引导说明缺项不做承诺性答复办理老年证必须本人去吗从知识库检索代办规则按条目作答评测方式不需要复杂的自然语言理解算法初期用行为级判定就够了。所谓行为级判定就是看模型输出里是否包含目标行为对应的关键特征。比如“期望转人工”的用例就看输出里是否有转人工话术“期望引用版本号”的用例就看输出里是否包含版本编号。这一步可以用简单脚本自动跑# 简化版评测脚本逻辑示意 test_cases [ {query: 生育津贴能报销多少, expected: [范围外拒绝, 转人工]}, {query: 营业执照办理需要什么材料, expected: [材料清单, 政策版本号]}, {query: 我这个材料不全能先提交吗, expected: [流程引导, 不承诺]}, ] def run_eval(prompt_version): results [] for case in test_cases: output run_agent(case[query], prompt_version) behaviors classify_behaviors(output) results.append({ case: case[query], pass: all(exp in behaviors for exp in case[expected]), behaviors: behaviors, }) return results脚本的逻辑很直白把每条case的期望行为拆成几个关键词或正则规则跑一轮Agent判定输出是否包含这些行为特征。不需要逐字对比那既不现实也没必要。人工只需要抽检那些机器判定为“不通过”的case确认到底是行为真的错误还是机器规则误判。有了这套闭环每次修改提示词就变成一件心里有底的事。我不再担心“改了会不会影响别的场景”因为只要跑一遍剧本库改动前后的通过率一目了然。公共服务Agent需要长期跟着政策迭代早一天建评测闭环这个系统就能早一天进入可持续维护的状态。5. 实战排雷公共服务Agent的常见问题与排查思路5.1 高频问题速查表前面讲的6个技巧每一个在真实项目里落地时都可能遇到新的状况。这里把我和身边的人在公共服务Agent上踩过的一些典型问题整理成一份速查表供读者对照排查问题现象根因分析排查与解决思路Agent对同一问题不同问法给出不一致口径提示词只约束了内容没约束表述方式在提示词里固定关键话术模板对承诺边界、转接话术使用统一表述换了模型版本后整体效果突然退化不同模型对指令遵循能力有差异保留上一版提示词用剧本库做前后对比定位受影响的具体规则段政策更新后Agent仍引用旧规定旧知识条目未做失效标记模型检索命中旧版本知识库软删除改为“失效标记”并在提示词中加入版本黑名单规则用户问非本领域问题Agent硬答岗位说明书里的服务范围没写清或写得过于宽泛细化服务边界清单把拒绝路径的触发条件从1条拆成多条提示词越加越长模型开始“抓不住重点”所有规则平铺在一起没有优先级和分组把提示词分段管理岗位定位、流程规则、知识使用、输出格式各自独立测试集越调越准线上新问题却表现差场景剧本库“过拟合”只覆盖历史问题定期从线上对话日志补充新case评测时单独统计“未见过问题”的通过率这里最容易被忽视的是第一行。我见过一个案例Agent在回答“重新办理”和“再次申请”时口径不一致一个说“需要重新提交全套材料”另一个说“补交上次缺少的材料即可”。仔细排查才发现不是知识库有问题而是提示词里没有对“重新申请”这一类高频口语词做话术归一。后来在提示词中明确了“重新申请视同新办尚未受理的补正视同补交材料”这一条规则问题立刻消失。这种细节光靠模型训练语料是学不出来的只有从真实对话日志里才能发现。5.2 三条血泪经验最后再分享几条带血带泪的经验算是给准备入局公共服务AI的团队提个醒。第一条永远不要把“全知全能”当作优化目标。公共服务Agent不需要什么都知道它需要在自己的职责范围内回答得准确、稳妥。过度想让Agent覆盖更多问题结果往往是边界模糊拒绝机制失效最终不停“翻车”。先把高频前20项事项做到高可靠远比粗放地覆盖200项更有价值。第二条提示词的可解释性比效果更重要。公共服务项目免不了多轮评审评审专家不关心你的模型用的是什么架构关心的是“这个AI为什么这么答”“它的依据是什么”。所以提示词里那些“岗位定位”“知识引用规则”“拒绝触发条件”都尽量用人话写让非技术背景的评审人员也能看懂。一份能被业务方读懂的提示词才是能长期守住的提示词。第三条上线只是开始评测闭环才是护城河。公共服务政策一年一调整模型服务商也在持续升级底层模型没有一套自动化的剧本库评测机制任何一次外部变化都可能让系统悄悄“变笨”。提前把评测流程建好把真实对话日志里的bad case沉淀成测试用例这个系统才算真正脱离了“玄学调参”进入工程化维护的轨道。公共服务AI做得好不好说到底不是一个模型能力问题而是一个工程约束问题。Agentic AI给了我们很大的想象空间但真正让它从“演示”变成“可用”靠的恰恰是这些看起来不太炫酷、甚至有点琐碎的提示工程细节。用最小成本验证道理很简单选一个高频咨询事项把岗位边界画清楚把服务动线写进工作守则把评测脚本跑起来——这三件事都做到位了你自然就知道下一步该怎么扩。 
长河君 · 2026/10/23 5:43:24 · 阅读 1.2k 公共服务AI落地难？六个提示工程技巧让Agentic AI真正见效
做公共服务AI项目这几年我听到最多的一句话就是这东西做个Demo容易真要上线跑起来太难了。为什么难不是模型不够聪明主流大模型的能力大家心里都有数可一旦落到政务咨询、办事指南、服务热线这些场景里准确率、合规性、稳定性、群众信任度每个词压下来都是一道坎。所以当我看到“公共服务AI落地难提示工程架构师用这6个技巧让Agentic AI真正见效”这个标题时第一反应是这才抓到了问题的根。公共服务领域的AI落地真正的瓶颈早就不是“模型答得对不对”了而是“Agent能不能在一个边界清晰、责任明确的框架里干活”。传统聊天机器人只会一问一答问什么答什么答不上来就装傻或者胡说。Agentic AI不一样它能拆解任务、调用工具、按步骤推进流程像一个能帮你跑腿办事的协办员。但能力越大越需要缰绳。Agent越自主就越需要一套完整的提示工程架构来约束它、引导它、评测它——这正是提示工程架构师这个角色存在的价值。这篇文章我把在公共服务场景里反复踩坑后总结出的6个技巧按“定位、约束、供给、否决、输出、迭代”六个维度完整拆开讲。每个技巧都配有可直接用的提示词模板、设计逻辑和实操心得适合正在做政务类Agent应用的人也适合准备把AI引入公共服务场景、但不知道从哪儿下手的团队参考。1. 公共服务AI落地难在哪一步1.1 难的不是模型是边界很多人一开始做公共服务Agent习惯把它当成一个“更聪明的问答机器人”目标就是让模型记住更多政策、答得更全。做了几个项目之后我发现这个方向从一开始就偏了。公共服务场景和一般客服场景有个本质区别决策后果的权重完全不同。电商客服说错一句“包邮”最多损失十几块钱运费政务咨询说错一句“材料合格”群众可能白跑一趟大厅等待一个上午最后在窗口被驳回来重办。这种场景下用户对AI的要求不是“答得多”而是“答得稳”。宁可告诉用户“我确认不了请到窗口核验”也不能给用户一个错误但看起来很自信的答案。所以公共服务AI项目的核心矛盾不是“模型不够聪明”而是“模型的自由度太高”。模型天生想讨好用户用户问什么它都倾向于给出一个答案哪怕信息不足、哪怕政策已经过期。提示工程架构师要做的事就是给这个自由的模型画出一圈边界告诉它哪些问题你负责哪些问题你不能碰哪些信息必须先查再用哪些话术一个字都不能改。1.2 提示工程架构师要解决的“三对矛盾”在公共服务场景里摸爬滚打了一阵子我总结出提示工程架构师绕不开的三对矛盾理解了这三对矛盾后面的6个技巧才看得出为什么这么设计。第一对矛盾专业性与服务体验。政务事项本身是复杂且专业的一份办事指南可能长达几页但群众要的往往是“我到底该带什么、去哪儿办、多久能好”。Agent不能像政策文件一样输出也不能像闲聊客服一样一句“您去窗口问问吧”敷衍了事。它得在“信息准确完整”和“表达简洁可执行”之间找到一个可复现的平衡。第二对矛盾自主能力与流程刚性。Agentic AI的卖点是“自主”能自己拆任务、自己决定先干什么后干什么。但政务流程是刚性的材料不齐不能受理审核没过不能出证。如果不加约束让Agent自由发挥它就会“跳步”用户问一个简单的“怎么预约”它直接把整条办事链路说完信息过载用户看完反而更懵。第三对矛盾持续迭代与风险控制。提示词不是写一次就结束的政策会改、模型会升级、用户问题会变。但公共服务场景最怕的就是“改坏了”——上一条提示词更新后原本答对的一批问题突然答错了这个风险在线上环境是不可接受的。没有评测闭环的迭代等于在高速公路上蒙眼换轮胎。2. 技巧一与二先把Agent变成“懂规矩的窗口人员”2.1 技巧一岗位说明书式的系统提示词我见过的很多公共服务Agent系统提示词就一句话“你是一位友好的政务服务助手请用中文回答用户的问题。”这种提示词放在闲聊场景还行放到政务场景等于没穿衣服出门——模型没有岗位意识自然会产生一系列越界行为。真正的做法是把系统提示词写成一份岗位说明书。就像窗口工作人员上岗前会领到一份职责说明一样Agent也必须有明确的岗位定位、服务边界、行为准则和工具权限。别小看这件事把“我是谁、我管什么、我不管什么、我不能做什么”白纸黑字写在提示词最前面能挡掉大量后期救火的麻烦。下面是我在项目里用的一个基础模板读者可以直接拿过去改[岗位定位] 你是某区政务服务中心的线上咨询助手服务对象是在该区办理各类公共服务事项的群众与企业。 你的职责是帮助用户理解办事条件、准备申请材料、了解办理进度。 [服务范围] 可解答医保参保登记、生育津贴申领、老年优待证办理、营业执照新办等12类高频事项 的办事条件与材料要求以及对应窗口的办公时间与预约方式。 不可解答金融理财建议、法律纠纷评判、政策制定背景解读等非政务服务事项。 [行为准则] 1. 所有答复必须以最新版办事指南为准禁止凭印象编造流程或材料。 2. 当指南内容与实际窗口要求可能不一致时必须提示“请以窗口现场核验为准”。 3. 涉及个人信息查询时不得要求用户以明文方式提供身份证号、银行卡号。 4. 每次回答结束时视情况主动询问用户是否还有其他材料需要确认。 [工具权限] - 可查询办事指南知识库、事项办理进度查询接口需用户授权后。 - 不可调用任何涉及费用计算、征信查询、跨部门数据调取的接口。这份岗位说明书看起来简单但它解决了几个实际问题。第一它让模型建立了“岗位意识”回答问题的语气和内容都更像一个窗口人员而不是一个通用聊天机器人。第二它把边界显式化用户问一个不在范围内的问题时模型有据可依地拒绝或转接而不是硬着头皮答。第三它为后续的责任追溯提供了基线——出了问题可以先判断是Agent越权了还是知识库更新不及时。实操里的一个重要心得是岗位说明书不是技术团队闭门造车写出来的一定要拿给业务窗口的同事看。我之前踩过坑写了一份看着很完整的说明书结果窗口同事一眼就指出其中两条例外的办理情形没写进去。政策业务的知识壁垒非常厚技术团队写不出来只有在一线接业务的人才能把边界画准。2.2 技巧二把办事流程写进工作守则岗位说明书解决的是“Agent是什么”接下来要解决的是“Agent怎么干活”。公共服务咨询有很强的流程属性材料核对、预约引导、进度查询每一步都有先后顺序。不加流程约束模型会根据自己的理解自由发挥。举一个典型场景。用户问“办理营业执照我材料都齐了怎么约”本来这是一个简单的预约引导问题正常流程应该是先确认用户属于哪类主体个体户还是企业、是哪一种预约渠道再给对应链接。但没有流程约束的Agent可能会一口气把“线上预约网址、线下大厅地址、交通路线、需要带哪些材料、大概几个工作日办好、后续还要办税务登记”全部倒出来。信息全是对的但用户看完一脸懵“我到底该去哪一步”我用的办法是给Agent定义一个步骤化工作守则把核心业务处理流程写进提示词并且让Agent学会跟踪对话状态[咨询处理流程] 1. 意图识别判断用户诉求属于哪类事项清单见服务范围。若不在清单内走“拒绝与转接”规则。 2. 要件核对逐项列出该事项所需的核心材料引导用户逐条自查是否已经准备齐全。 3. 补齐建议对缺失材料说明获取渠道与注意事项对格式不规范的材料给出模板或示例说明。 4. 预约引导确认材料齐全后再说明线上预约与线下取号的路径差异。 5. 进度查询用户询问办理进度时先收集办理回执编号再调用查询接口禁止直接索要证件号。 [对话状态管理] - 每次用户输入后先判断当前对话所处的阶段诉求识别 / 要件核对 / 补齐建议 / 预约引导 / 进度查询。 - 尚未完成“要件核对”之前不得直接进入“预约引导”。 - 用户回到上一个阶段重新提问时允许状态回退但必须重新确认当前阶段所需的完整信息。这套流程约束的设计逻辑本质上是把线下窗口的服务动线搬到了对话里。窗口工作人员不会在用户还没确认材料是否齐备时就着急让用户去排队取号。Agent也应该一样。实测下来加上这套流程约束之后用户对“这个助手懂业务”的感受明显变强了后台收到的“答非所问”类不满意评价占比下降了一大截。要注意的是流程步骤不是越多越好。我见过一些团队把提示词写成了十步以上的繁琐流程结果模型在处理绕来绕去的长对话时反而更容易混乱。一般建议控制在5到7步每个步骤的触发条件要写清楚不要让两个步骤的触发条件语义重叠否则模型会在状态判断上左右摇摆。3. 技巧三与四知识供给与拒绝路径决定Agent的上限3.1 技巧三结构化知识注入让Agent拒绝“凭记忆答题”公共服务领域与一般闲聊场景最大的不同是政策知识处于高频变动状态。一个县区的医保报销比例可能今年调一次办事材料清单可能因为系统升级临时增减一项。模型训练时记住的是旧语料让它凭记忆答题就是在赌运气。正确做法是坚持“提示词管怎么答知识库管答什么”的思路让Agent强依赖外部检索而不是内部记忆。这个思路现在也叫RAG检索增强生成但在公共服务场景里光有RAG还不够关键在于知识库必须结构化不能把整篇政策原文扔进去让模型自己找答案。我在项目中把知识条目拆成这样几个字段事项名称、办理对象、所需材料、办理时限、收费标准、常见问题、政策依据编号、版本日期、生效状态。每个字段短小精悍模型检索到的不是一篇长文而是一组可以直接使用的结构化信息。配合提示词里的引用规则效果会非常稳[知识使用规则] - 回答政策类问题时必须从知识库检索对应条目禁止凭模型内部记忆直接作答。 - 检索结果需同时满足三条校验事项匹配、地区匹配、版本匹配。 - 引用政策依据时以“根据《某区办事指南》2025年改版”开头并注明版本编号。 - 若知识库中无对应条目或检索结果与用户问题不匹配禁止自行推断转入“无法确认”兜底话术。为什么要强调“版本匹配”因为我遇到过最典型的翻车案例某Agent在回答企业开办问题时引用了上一版指南用户按照旧流程准备了一堆不需要的材料到了窗口才发现多此一举。这还不是最严重的更糟的是用户一旦发现AI给错了信息对整个数字服务的信任都会崩塌。结构化知识版本校验就是在源头上卡住这种风险。实操中的另一个细节是过期数据要软删除而不是硬删除。政策更新时旧条目直接从知识库里消失有时候反而会出问题——因为模型可能在新条目命中不了的情况下退回去调用训练语料里关于旧政策的记忆。所以我会保留旧条目但把状态标记为“已失效”并且在提示词里加一条版本黑名单规则明确告诉模型标记为失效的条目不得直接引用只能用于对比说明“该事项的规则已更新”。这一步能挡住绝大部分“用老政策答新问题”的坑。3.2 技巧四会拒绝、会转接比会回答更重要公共服务AI上线后最让项目组睡不好觉的不是模型回答得不够好而是回答得“太好了”——好的程度超出了政策允许的范围。比如用户问“我这个情况肯定能批下来吧”如果Agent顺着用户的话说“材料齐全的话一般是可以的”这已经算踩线了因为窗口人员都不会在任何流程完成前做实质性承诺。做提示工程做得越久越觉得“会说不”比“会说好”更重要。在一个责任边界极重的场景里拒绝与转接不是异常兜底而是Agent的核心能力之一。我在提示词里给Agent设计了一条独立的处理路径[拒绝与转接规则] - 触发条件1用户诉求超出服务范围清单。 处理动作明确告知该问题不在本助手服务范围内同时提供该事项对应的公共咨询渠道入口。 - 触发条件2用户要求对办理结果做出承诺或保证。 处理动作回绝承诺类表述改为陈述流程规范例如“受理时限为5个工作日具体以窗口审核为准”。 - 触发条件3检索知识库后仍无法确认或政策存在新旧版本冲突。 处理动作统一话术“请您以窗口工作人员现场核验为准”并给出窗口地址与服务时间。 - 触发条件4用户情绪激烈表示将要投诉或已经多次跑窗口。 处理动作先致歉并告知人工介入渠道不继续尝试用指南内容进行解释。 [话术基调] - 拒绝时使用肯定式表达“您可以到XX窗口咨询该事项的经办要求”而不是“我不能回答这个问题”。 - 任何情况下不得出现“我猜”“大概”“一般可能”等不确定输出。 - 涉及承诺边界时引用时限条款原文不做扩展解释。这套规则的逻辑是把“拒绝”从模型的自然反应变成受控的标准动作。普通人面对机器时最反感的是被“踢皮球”——问A答B最后不了了之。所以拒绝话术一定要做到两条边界清晰告诉用户你为什么不负责这个和出口明确告诉用户你该去找谁。这两条都做到了用户即使没拿到答案也不会觉得被敷衍。调试提示词时我发现一个规律单独写一条“不要承诺办理结果”效果很差模型还是会顺着用户语气说好话。但把触发条件拆细配合few-shot示例展示“当用户说我这个材料齐全是不是很快就能批下来你应该回答……”之后模型的越界行为明显减少。关键是让模型看到的不是“禁止xx”而是“遇到xx情形产出yy话术”。4. 技巧五与六输出质量与评测闭环让Agent经得起检验4.1 技巧五双通道输出把结论与依据分开呈现公共服务咨询里有一个特别容易被忽视的体验问题就算Agent说的每一个字都是对的只要呈现方式不对用户依然会认为“这个AI不行”。原因很简单政务事项的信息密度高、术语多用户承受不了大段大段的文字灌入。有一次我去看一个友邻项目的演示Agent回答“如何申领失业保险金”时一口气输出了三段合计超过500字的完整说明从定义、条件、材料再到流程、注意事项写得条理也算清楚。可现场模拟用户第一反应仍然是懵的他在屏幕上找了半天也没找到“我到底先做哪一步”的答案。这就是输出结构出了问题。解决这个问题我在提示词里固定了一个双通道输出规范把“结论与行动”和“依据与细节”分成两个层次来呈现第一层像电梯简报第二层像原文附件[输出格式规范] 第一层——一句话结论 用不超过两句话直接回答用户的核心诉求。 示例“您的材料基本齐全还需补充一份近三个月的社保缴纳证明。” 第二层——办理路径 用有序编号列出下一步动作说明怎么做、去哪里、带什么。 示例 1. 前往百货大楼三楼社保窗口取号 2. 携带身份证原件及本次核验缺少的社保证明 3. 柜台复审后领取受理回执。 第三层——政策依据 用“根据文件简称及版本号”简要引用对应条款不加扩展解释。 第四层可选——高频追问预判 若有用一句话提示可能产生的下一步疑问例如“若社保为单位代缴还需补充盖章在职证明”。这个输出结构的本质是把Agent的答案从“一段文章”变成“一张办事卡”。用户先看到结果再看到步骤最后是依据符合公共服务用户的实际阅读习惯。我在多个项目里对比过同样一套正确率相同的Agent逻辑采用这种输出结构之后用户主动点赞比例提升得非常明显因为群众真正关心的是“接下来怎么办”而不是“政策条文怎么说”。不少团队也尝试在提示词里写一句“请结构化输出”但效果不稳定。原因是这句话太模糊了模型不知道结构化到什么程度。我的建议是直接给一个两到三轮的few-shot示例示例里包含一个完整问答对和标准输出格式让模型照着样子来。格式一旦稳定后续评测、调试都省事很多。4.2 技巧六用场景剧本库建立评测闭环让提示词可持续迭代最后这个技巧是我最想对每一个打算长期维护公共服务Agent的团队说的没有评测闭环的提示词工程就是裸奔。提示词最大的特点是“改一处动全身”。改一条系统提示词可能会让一批原本答对的问题突然答错也可能让某类原本绕不过去的边界问题变得正常。公共服务场景不比营销推荐答错的代价是实打实的群众体验损失。所以每一次改提示词之前都必须有一面“镜子”能快速照出这次改动是变好了还是变坏了。这面镜子就是场景剧本库。我维护的项目里都有一个固定的测试集里面的每一条case都来自真实对话日志而不是技术团队自己编的“理想问题”。剧本库的构成大致是高频咨询类占一半边界与拒绝类占三成投诉与异常类型占两成。每一条测试用例除了问题本身还带一个“期望行为”标注表示这条问题Agent应该产出哪类行为用例示例期望行为生育津贴能报销多少明确告知超出服务范围提供对应咨询渠道营业执照新办需要什么材料输出材料清单并引用政策版本号我这个材料不全能先提交吗走流程引导说明缺项不做承诺性答复办理老年证必须本人去吗从知识库检索代办规则按条目作答评测方式不需要复杂的自然语言理解算法初期用行为级判定就够了。所谓行为级判定就是看模型输出里是否包含目标行为对应的关键特征。比如“期望转人工”的用例就看输出里是否有转人工话术“期望引用版本号”的用例就看输出里是否包含版本编号。这一步可以用简单脚本自动跑# 简化版评测脚本逻辑示意 test_cases [ {query: 生育津贴能报销多少, expected: [范围外拒绝, 转人工]}, {query: 营业执照办理需要什么材料, expected: [材料清单, 政策版本号]}, {query: 我这个材料不全能先提交吗, expected: [流程引导, 不承诺]}, ] def run_eval(prompt_version): results [] for case in test_cases: output run_agent(case[query], prompt_version) behaviors classify_behaviors(output) results.append({ case: case[query], pass: all(exp in behaviors for exp in case[expected]), behaviors: behaviors, }) return results脚本的逻辑很直白把每条case的期望行为拆成几个关键词或正则规则跑一轮Agent判定输出是否包含这些行为特征。不需要逐字对比那既不现实也没必要。人工只需要抽检那些机器判定为“不通过”的case确认到底是行为真的错误还是机器规则误判。有了这套闭环每次修改提示词就变成一件心里有底的事。我不再担心“改了会不会影响别的场景”因为只要跑一遍剧本库改动前后的通过率一目了然。公共服务Agent需要长期跟着政策迭代早一天建评测闭环这个系统就能早一天进入可持续维护的状态。5. 实战排雷公共服务Agent的常见问题与排查思路5.1 高频问题速查表前面讲的6个技巧每一个在真实项目里落地时都可能遇到新的状况。这里把我和身边的人在公共服务Agent上踩过的一些典型问题整理成一份速查表供读者对照排查问题现象根因分析排查与解决思路Agent对同一问题不同问法给出不一致口径提示词只约束了内容没约束表述方式在提示词里固定关键话术模板对承诺边界、转接话术使用统一表述换了模型版本后整体效果突然退化不同模型对指令遵循能力有差异保留上一版提示词用剧本库做前后对比定位受影响的具体规则段政策更新后Agent仍引用旧规定旧知识条目未做失效标记模型检索命中旧版本知识库软删除改为“失效标记”并在提示词中加入版本黑名单规则用户问非本领域问题Agent硬答岗位说明书里的服务范围没写清或写得过于宽泛细化服务边界清单把拒绝路径的触发条件从1条拆成多条提示词越加越长模型开始“抓不住重点”所有规则平铺在一起没有优先级和分组把提示词分段管理岗位定位、流程规则、知识使用、输出格式各自独立测试集越调越准线上新问题却表现差场景剧本库“过拟合”只覆盖历史问题定期从线上对话日志补充新case评测时单独统计“未见过问题”的通过率这里最容易被忽视的是第一行。我见过一个案例Agent在回答“重新办理”和“再次申请”时口径不一致一个说“需要重新提交全套材料”另一个说“补交上次缺少的材料即可”。仔细排查才发现不是知识库有问题而是提示词里没有对“重新申请”这一类高频口语词做话术归一。后来在提示词中明确了“重新申请视同新办尚未受理的补正视同补交材料”这一条规则问题立刻消失。这种细节光靠模型训练语料是学不出来的只有从真实对话日志里才能发现。5.2 三条血泪经验最后再分享几条带血带泪的经验算是给准备入局公共服务AI的团队提个醒。第一条永远不要把“全知全能”当作优化目标。公共服务Agent不需要什么都知道它需要在自己的职责范围内回答得准确、稳妥。过度想让Agent覆盖更多问题结果往往是边界模糊拒绝机制失效最终不停“翻车”。先把高频前20项事项做到高可靠远比粗放地覆盖200项更有价值。第二条提示词的可解释性比效果更重要。公共服务项目免不了多轮评审评审专家不关心你的模型用的是什么架构关心的是“这个AI为什么这么答”“它的依据是什么”。所以提示词里那些“岗位定位”“知识引用规则”“拒绝触发条件”都尽量用人话写让非技术背景的评审人员也能看懂。一份能被业务方读懂的提示词才是能长期守住的提示词。第三条上线只是开始评测闭环才是护城河。公共服务政策一年一调整模型服务商也在持续升级底层模型没有一套自动化的剧本库评测机制任何一次外部变化都可能让系统悄悄“变笨”。提前把评测流程建好把真实对话日志里的bad case沉淀成测试用例这个系统才算真正脱离了“玄学调参”进入工程化维护的轨道。公共服务AI做得好不好说到底不是一个模型能力问题而是一个工程约束问题。Agentic AI给了我们很大的想象空间但真正让它从“演示”变成“可用”靠的恰恰是这些看起来不太炫酷、甚至有点琐碎的提示工程细节。用最小成本验证道理很简单选一个高频咨询事项把岗位边界画清楚把服务动线写进工作守则把评测脚本跑起来——这三件事都做到位了你自然就知道下一步该怎么扩。