很多人第一次听我说要做“消防管理智能化”项目时第一反应都是“接一个大语言模型把火警信息丢进去让它生成报告不就行了”。真实干过之后才知道这种想法离“智能救援系统”还差得非常远。我在参与一个某城市救援信息平台的智能化改造时核心任务正是用 Agentic AI智能体式 AI配合提示工程把一套零散的应急能力拼成一个能辅助指挥员做判断的“智能救援系统”。今天这篇文章我就以提示工程架构师的视角把这个项目里的拆解思路、提示词写法、踩坑记录和调优过程完整梳理一遍。如果你也在做应急、消防、安防或者任何对可靠性和时效性要求极高的 AI 应用这篇内容应该能给你不少直接可用的参考。1. 为什么传统大模型问答撑不起“智能救援系统”1.1 消防指挥中心的真实痛点信息爆炸与决策窗口有一次我们做需求调研我坐在某指挥中心的大屏旁边眼睁睁看着一条真实警情从接入到派单的全过程。电话进来的前两分钟调度员需要在三四个系统之间来回切换接警登记、地图定位、水源预案、附近队伍状态、历史警情记录。每个系统都有自己的查询框和操作流程调度员嘴上还要和报警人确认信息手里的鼠标根本停不下来。那一瞬间我意识到真正的痛点不是缺信息而是信息以碎片的形式在多个终端之间跳跃决策窗口又短人的处理带宽完全不够用。传统的对话式大模型在这个场景里能干什么它能回答“某地的预案文本是什么”如果你把预案喂给它它也能总结一段话。但这都是被动的需要人先问它才答。可指挥员连提问的时间都没有更别说让模型去主动查水源、看风向、调档案。消防管理智能化的核心需求是把“人围着系统转”变成“系统围着事件转”在事件发生时主动组织信息、给出可操作的提示而不是守在一个对话框里等人来问。1.2 Agentic AI 的差异化价值Agentic AI 和传统对话模型最大的区别就是它不再是一个“回答问题”的东西而是一个“感知—规划—行动—观察”的闭环。你可以想象一个智能体完成任务时的样子它先接收一段火警文本自己判断要不要调用地图服务查询结果回来后继续推理下一步该查什么最后把所有结果整合成一份结构清晰的警情摘要。整个过程不需要人逐条指示。我习惯用一个生活类比来解释这种差异传统大模型像一个在路边被人拉住问路的路人你说一句它答一句Agentic AI 更像你雇来的一个助理你说“有个化工园区起火了”它会自己打车、联系园区值班室、查风速、调出应急预案然后在你下车前把情况汇报完。消防场景尤其吃这套因为指挥员要的不是“标准答案”而是一个能代替他先跑一遍信息流程的“前置脑”。所以引入 Agentic AI 的真正价值不是把某个问答接口替换掉而是把“事件数据到辅助决策”这条链路自动化。它不是替代指挥员的判断而是把判断之前所有脏活累活先干完。1.3 提示工程架构师为什么是关键角色有了 Agentic AI 的骨架接下来的问题就是这个助理到底怎么说话、怎么干活模型基础能力再强如果没有人把它“派到正确的岗位上”它依然会迷失。提示工程架构师在智能体系统里等同于给每一个智能体写“任职说明书和工作手册”的人。举个例子同样是“查一下消防水源”你可以让它直接搜索数据库也可以让它先判断当前火灾类型再决定查哪种水源数据。这两种做法的可靠性差别非常远。提示工程架构师的职责就是把这种决策逻辑落到提示词里明确告诉模型什么情况下用什么工具、什么信息没有证据不要猜、输出格式必须是怎样。在一个救援级系统里提示词不再只是“写得顺不顺”的问题而是“能不能在高压、低延时、信息残缺的极端条件下稳定不翻车”的问题。2. “救援系统”智能体的顶层设计从值班终端到调度大脑2.1 先定边界哪些环节可以智能体化哪些必须保留人工动手写任何提示词之前我们团队花了一半时间做边界梳理。这个步骤如果跳过后续一定会在某个深夜被现实毒打。我们列了两张清单一张叫“可以智能体化”一张叫“绝不能碰”。可以智能体化的包括警情要素抽取、预案匹配、资源分布查询、报告初稿生成、信息推送绝不能碰的包括自动确认出警指令、远程控制设备、向报警人承诺到场时间、自动判定火情等级。这里面的逻辑是智能体可以做“读、查、整理、建议”但凡是涉及对外承诺、行动授权和物理控制的操作必须走人工确认。这不是保守而是明确的权责边界。一旦系统给出错误建议责任最终要由人来承担那么关键决策就必须留给人。提示词里我会让模型在处理这类事项时直接返回固定话术“该事项需人工确认已转入值班员工作台。”2.2 多智能体群组的拆解思路系统里我们没有做“一个超大智能体包打天下”而是拆成了几个专职智能体再配一个主控智能体负责调度。分工大概是这样的智能体主要职责依赖数据警情感知 Agent从报警文本中抽取时间、地点、燃烧物、被困人数等结构化字段接警系统、OCR 结果知识检索 Agent匹配应急预案、历史案例、危化品性质预案库、案例库资源调度 Agent查询附近消防站、水源、可调车辆和人员状态位置服务、值班系统报告生成 Agent汇总以上信息生成结构化警情摘要和行动建议所有上游输出主控 Agent 不干具体活它的任务是根据事件类型决定调用哪些智能体、以什么顺序调用。比如“危化品泄漏”和“居民楼火灾”这两类事件资源调度 Agent 的关注点完全不一样前者要查风向和防护装备后者要查疏散通道和登高车辆。这种编排逻辑如果写进一个大而全的提示词里模型很容易顾此失彼拆开之后每个智能体提示词都能写得非常专注效果也稳定得多。2.3 提示工程在智能体系统里的位置有了智能体拆分提示工程架构师就不是只写一段漂亮的“角色设定词”而是要为每个智能体、每个工具调用、每次跨智能体通信设计对应的提示词。你可以理解成智能体是部门提示词是部门的工作制度。制度写得含糊部门就互相甩锅制度写得事无巨细部门又丧失灵活性。好的提示词是用来框定行为边界和操作路径而不是限制模型的天花板。在技术落地时我们通常把提示词分成三层第一层是系统级提示词挂在主控智能体上负责全局策略第二层是任务级提示词挂在各个专职智能体上负责具体流程第三层是工具级提示词嵌在每次调用数据库或接口时负责把自然语言翻译成规范查询。三层各司其职后续做版本迭代和回归评估时也容易定位问题。3. 提示工程架构师写系统提示词的具体姿势3.1 系统提示词的三段式结构先给大家看一段我们实际在用的主控智能体系统提示词片段已脱敏处理。这算是我认为比较稳妥的写法结构你是某城市救援信息平台的调度总控智能体。你的核心职责是在收到警情信息后 有条理地调度下属智能体完成信息收集并输出结构化行动摘要。 工作流程固定为 1. 抽取并确认核心警情要素地点、类型、规模、报警人描述。 2. 根据事件类型判断需要调用的智能体列表。 3. 依次调用智能体并将关键结果缓存在工作记忆中。 4. 汇总所有结果生成《警情信息摘要》和《行动建议清单》。 必须遵守的规则 - 只能输出事实型信息所有结论必须注明证据来源。 - 如果某个字段无数据必须输出“未知”禁止推测。 - 涉及出警指令、控制设备、对报警人承诺等操作一律输出固定话术 “该事项需人工确认已转入值班员工作台”。 - 输出格式严格遵循 JSON Schema不得增加额外字段。这个提示词里最关键的其实是最后两条规则。没有它们模型在压力下会自己脑补信息也会在某个瞬间突然“自作主张”这是救援场景绝对无法接受的。系统提示词不是写给模型看的“人设故事”而是约束行为的“安全红线”。越短的规则越容易被模型执行所以不要写“请务必仔细不要出错”而要明确“禁止推测”这种机器可理解的要求。3.2 任务拆解与思维链引导主控智能体的提示词定了框架专职智能体还需要更细的动作指引。以警情感知 Agent 为例它面对的输入可能是这样一句报警原文“北边那个化工厂好像着火了几个罐子在烧人还没跑出来。”这句话包含大量信息缺失还夹杂着口语和模糊表述。我们给感知 Agent 的提示词里会要求它先做三步思考第一步提取所有显式实体比如地点、对象、状态第二步识别缺失字段用“待确认”标记第三步根据常识补全查询关键词但不把补全结果当作事实。这就是一种引导模型走“思维链”的写法。注意这里不是让它自由发挥而是给它一条固定的推理路线防止它直接跳到最后结论。比如对于“北边那个化工厂”我们要求感知 Agent 输出“据报警人描述为某化工厂具体名称待定位确认”同时把“化工厂”“罐体燃烧”作为检索关键词交给知识检索 Agent 去查危化品数据库。这样既保留了报警人的原始说法又把可查询的实体严格限定在系统可以验证的范围里。3.3 工具调用提示与参数清洗智能体要真去执行查询提示词设计上和纯对话写作完全不同。我们让模型输出的不是普通句子而是一个结构化的工具调用意图由平台层去执行。提示词里会给出一个具体的 JSON 调用约定{ intent: query_resource, parameters: { resource_type: hydrant, location: 北港化工园区, radius_m: 3000, limit: 10 } }为了让模型稳定地生成这个结构我们在提示词里提供了 3 个正例和 1 个反例明确告诉它“不要输出自然语言描述不要套用不存在的地图服务”。这个细节非常有效模型对格式的稳定性比对语义的稳定性要强太多你给它看两个好例子它基本就能跟着格式走。参数清洗也很重要模型把“北边那个化工厂”直接扔给位置服务会查不到所以提示词里会让感知 Agent 先做一次“地点标准化”把口语位置换算成坐标或者正式园区名再交给工具。这条链路看起来多了一步但换来的是下游查询结果质的提升。我刚开始做的时候图省事让模型直接把原始文本拼进检索接口结果 80% 的查询都因为地址不规范而失败。后来补上“地点标准化”这个环节成功率才上来。3.4 动态检索与上下文拼接策略消防预案和危化品数据会定期更新而预训练模型只记得训练时的旧知识。我们的做法是不指望模型背数据而是利用检索增强生成RAG把最新数据实时拼进上下文。在提示工程层面这意味着要给检索 Agent 写一套“如何构造检索词”的规则。具体来说知识检索 Agent 的提示词里会注明收到感知 Agent 传过来的实体后先拆成“事件类型、物质名称、地理位置”三个检索维度每个维度单独查一次如果查不到完整匹配再降级为关键词前缀匹配。这样可以避免模型拿着“化工园区着火”这种模糊短语去检索把一堆不相关预案捞上来。检索结果返回后还需要在提示词里规定上下文顺序先放高优先级匹配结果再放其他参考最后放一条“若以上结果均不相符输出未找到匹配预案”的兜底分支。动态检索让系统具备了“时效性”不再吃训练数据的旧红利。我们后来在模拟测试里故意换了新修订的预案版本系统能准确检索到更新后的内容并正确标注了修订日期。4. 仿真推演一场化工园区夜警事件的完整链路复盘4.1 场景搭建与数据准备纸上谈兵没有意义真刀真枪测一把才放心。我们搭了一套离线仿真环境模拟了一场夜间某园区内储罐区火警事件。输入数据包括一段带有嘈杂背景音但能听懂中文的报警录音转写文本一条物联网温度传感器异常记录一张现场监控截图的光学字符识别结果以及一份气象站提供的风速风向数据。给智能体喂数据也有讲究不能一次性全塞进去否则它分不清主次。我们按照事件推进的时间顺序把报警文本设为第一优先输入温度传感器记录和 OCR 结果作为“现场补充信息”延后加入气象数据单独做一次工具调用。这是为了让系统尽可能贴近真实世界里“信息是逐渐到达”的特性而不是像考试一样把所有信息先铺在桌上。4.2 智能体群的实时表现仿真跑起来之后系统的行为大致是这样的报警文本到达感知 Agent 在 1.8 秒内抽取出了“地点未知、疑似储罐火灾、有人员被困”三个核心要素并把“园区名称待确认”标记为待定紧接着主控智能体判断这类事件需要资源调度和知识检索于是并行调用了两个专职智能体。资源调度 Agent 先通过网络位置服务定位到附近三个消防站和两处水源但提示词里的“地点标准化”节点成功把报警文本里的口语化描述换算成了园区坐标所以查询结果精度很高。知识检索 Agent 用“储罐、燃烧物、防护距离”作为关键词匹配到了一份危化品事故处置预案并标注了预案版本号。报告生成 Agent 将所有信息汇总成一个字段齐全的 JSON 摘要包含警情要素、匹配预案、可用资源和建议处置方向。整条链路跑完大概用了 6 秒比我们预想的低调很多。担忧的问题出现在别处摘要虽然结构完整但篇幅过长把很多非关键资源也列了上来反而淹没了最需要关注的“人员被困”和“风向威胁”这两条信息。这其实是指示词里“排序优先级”缺失导致的直接后果。4.3 复盘后的三轮提示词调优针对仿真暴露的问题我们做了三轮调优。第一轮在报告生成 Agent 的提示词里增加“按危险等级排序优先展示人员伤亡、危险物质、风向下风口位置”的规则并强制摘要前 100 字必须包含这三个要素。效果立竿见影第二次跑出来的摘要重点清晰很多。第二轮我们遇到的是信息冲突问题。温度传感器显示某罐体温度升高但 OCR 结果里没有出现明显火光两个信息源在摘要里被并列放置连逻辑关系都没说明。后来我们在报告 Agent 提示词里加了“如果不同来源存在矛盾必须显式输出冲突标注并将此类信息置于人工复核队列”这才让系统学会“不确定就是不确定”的表达方式。第三轮则是多 Agent 通信层面的问题。一开始资源调度 Agent 和知识检索 Agent 各自同时访问了同一份 GIS 服务造成重复查询。我们在主控提示词里加了一条“互斥工具队列”——同一时刻同一服务只允许一个智能体调用其他智能体命中缓存。这个调整直接让系统响应时间再度缩短也更符合真实平台接口的并发限制。经过这三轮调优这套仿真链路才真正达到我们想要的“能看、能用、敢参考”的状态。每次改提示词我们都会把这一整套仿真事件翻来覆去跑五遍确认不会因为微调引入新问题。5. 实战中容易翻车的提示工程细节与稳健性策略5.1 拒识话术与“不许做”清单提示工程里最容易被新手忽略的一块是“明确告诉模型不做什么”。救援环境下宁可系统少做一件事也不能做错一件事。我们建立了一张“不许做”清单不能确认火警等级、不能建议关闭阀门、不能代替指挥员签发调度指令。清单会直接以规则形式写进系统提示词并要求模型在触达边界时输出一段固定话术。一开始我觉得这样做很蠢像是对模型能力的浪费。但测试中真的发生过模型在回答里附带了“建议立即启动区域断电”这种超出职责范围的指令如果被值班员当成系统建议执行后果不堪设想。加了“不许做”清单之后类似行为被明显压制因为模型对显式禁令的遵从度远高于对隐含边界的理解。5.2 冲突信息处理与幻觉控制幻觉是任何落地系统绕不开的坎尤其在信息残缺的火警场景里模型很容易“脑补”出充满细节但根本不存在的现场情况。我们控制幻觉主要做两件事第一在提示词级别要求每个结论带证据锚点没有证据就输出“未知”第二在流程级别要求所有关键数据都必须经过工具调用验证不允许模型凭通用知识回答。具体到提示词写法我们会在感知 Agent 里加上“如果报警人未提及被困人数必须输出 unknown禁止使用“可能有多人”这类推测性表述”。这看似严苛但对后续资源调度十分重要指挥员宁可看到“未知”然后立刻安排侦察也不能看到一个虚假的“现场已无被困人员”而放松警惕。5.3 超时降级与多 Agent 通信卫生救援系统对延时的忍耐度极低。我们在联调时发现如果某个外部数据接口响应超过 5 秒智能体会一直“干等”导致整条链路卡住。后来在提示词和平台逻辑两侧都加了降级策略平台侧设置超时上限超时后自动返回“服务暂不可用”智能体侧在提示词里规定如果遇到工具超时直接标记该字段为“获取失败”继续执行其他任务而不是反复重试。多 Agent 之间通信还需要注意“上下文污染”。不同智能体关注的焦点不同如果把上一个 Agent 的全部原始输出都传给下一个后面的模型会被大量无关信息干扰。我们的做法是定义严格的消息接口上一级只传递结构化的字段结果摘要限制在固定长度内原始文本只保留在数据库中按需调取。这个“通信卫生”原则让整体系统的稳定性提升了一个档次。5.4 提示词版本管理与回归评估提示词和代码一样属于需要持续维护的资产。我们每改一条规则都像发版一样记录变更原因并且用一批历史警情数据做回归。批次里包含各类典型情况高层住宅火灾、危化品泄漏、野外杂草起火、false alarm误报警每条数据都人工标注了期望的输出关键点。评估指标上我们主要盯四个要素抽取准确率、工具调用正确率、报告可用率和人工复核触发率。调优的目标不是追求某一个指标无限高而是让整体表现“偏保守但稳定”。比如有一次为了提升调用正确率我放宽了工具选择规则结果是调用率上去了误报也增多整体反而倒退。后来收敛到“准确优先、必要时用人工兜底”的策略效果最稳定。我最后再分享一个小技巧在提示词版本更新的提交信息里把仿真测试的结果一并写上去。这样下次排查问题时你能顺着版本历史快速定位是哪条提示词改动导致了行为偏移。在救援这种复杂系统里可追溯性有时比代码逻辑本身还重要。 
长河君 · 2026/10/23 4:51:59 · 阅读 1.2k Agentic AI与提示工程：打造智能救援系统的实战拆解
很多人第一次听我说要做“消防管理智能化”项目时第一反应都是“接一个大语言模型把火警信息丢进去让它生成报告不就行了”。真实干过之后才知道这种想法离“智能救援系统”还差得非常远。我在参与一个某城市救援信息平台的智能化改造时核心任务正是用 Agentic AI智能体式 AI配合提示工程把一套零散的应急能力拼成一个能辅助指挥员做判断的“智能救援系统”。今天这篇文章我就以提示工程架构师的视角把这个项目里的拆解思路、提示词写法、踩坑记录和调优过程完整梳理一遍。如果你也在做应急、消防、安防或者任何对可靠性和时效性要求极高的 AI 应用这篇内容应该能给你不少直接可用的参考。1. 为什么传统大模型问答撑不起“智能救援系统”1.1 消防指挥中心的真实痛点信息爆炸与决策窗口有一次我们做需求调研我坐在某指挥中心的大屏旁边眼睁睁看着一条真实警情从接入到派单的全过程。电话进来的前两分钟调度员需要在三四个系统之间来回切换接警登记、地图定位、水源预案、附近队伍状态、历史警情记录。每个系统都有自己的查询框和操作流程调度员嘴上还要和报警人确认信息手里的鼠标根本停不下来。那一瞬间我意识到真正的痛点不是缺信息而是信息以碎片的形式在多个终端之间跳跃决策窗口又短人的处理带宽完全不够用。传统的对话式大模型在这个场景里能干什么它能回答“某地的预案文本是什么”如果你把预案喂给它它也能总结一段话。但这都是被动的需要人先问它才答。可指挥员连提问的时间都没有更别说让模型去主动查水源、看风向、调档案。消防管理智能化的核心需求是把“人围着系统转”变成“系统围着事件转”在事件发生时主动组织信息、给出可操作的提示而不是守在一个对话框里等人来问。1.2 Agentic AI 的差异化价值Agentic AI 和传统对话模型最大的区别就是它不再是一个“回答问题”的东西而是一个“感知—规划—行动—观察”的闭环。你可以想象一个智能体完成任务时的样子它先接收一段火警文本自己判断要不要调用地图服务查询结果回来后继续推理下一步该查什么最后把所有结果整合成一份结构清晰的警情摘要。整个过程不需要人逐条指示。我习惯用一个生活类比来解释这种差异传统大模型像一个在路边被人拉住问路的路人你说一句它答一句Agentic AI 更像你雇来的一个助理你说“有个化工园区起火了”它会自己打车、联系园区值班室、查风速、调出应急预案然后在你下车前把情况汇报完。消防场景尤其吃这套因为指挥员要的不是“标准答案”而是一个能代替他先跑一遍信息流程的“前置脑”。所以引入 Agentic AI 的真正价值不是把某个问答接口替换掉而是把“事件数据到辅助决策”这条链路自动化。它不是替代指挥员的判断而是把判断之前所有脏活累活先干完。1.3 提示工程架构师为什么是关键角色有了 Agentic AI 的骨架接下来的问题就是这个助理到底怎么说话、怎么干活模型基础能力再强如果没有人把它“派到正确的岗位上”它依然会迷失。提示工程架构师在智能体系统里等同于给每一个智能体写“任职说明书和工作手册”的人。举个例子同样是“查一下消防水源”你可以让它直接搜索数据库也可以让它先判断当前火灾类型再决定查哪种水源数据。这两种做法的可靠性差别非常远。提示工程架构师的职责就是把这种决策逻辑落到提示词里明确告诉模型什么情况下用什么工具、什么信息没有证据不要猜、输出格式必须是怎样。在一个救援级系统里提示词不再只是“写得顺不顺”的问题而是“能不能在高压、低延时、信息残缺的极端条件下稳定不翻车”的问题。2. “救援系统”智能体的顶层设计从值班终端到调度大脑2.1 先定边界哪些环节可以智能体化哪些必须保留人工动手写任何提示词之前我们团队花了一半时间做边界梳理。这个步骤如果跳过后续一定会在某个深夜被现实毒打。我们列了两张清单一张叫“可以智能体化”一张叫“绝不能碰”。可以智能体化的包括警情要素抽取、预案匹配、资源分布查询、报告初稿生成、信息推送绝不能碰的包括自动确认出警指令、远程控制设备、向报警人承诺到场时间、自动判定火情等级。这里面的逻辑是智能体可以做“读、查、整理、建议”但凡是涉及对外承诺、行动授权和物理控制的操作必须走人工确认。这不是保守而是明确的权责边界。一旦系统给出错误建议责任最终要由人来承担那么关键决策就必须留给人。提示词里我会让模型在处理这类事项时直接返回固定话术“该事项需人工确认已转入值班员工作台。”2.2 多智能体群组的拆解思路系统里我们没有做“一个超大智能体包打天下”而是拆成了几个专职智能体再配一个主控智能体负责调度。分工大概是这样的智能体主要职责依赖数据警情感知 Agent从报警文本中抽取时间、地点、燃烧物、被困人数等结构化字段接警系统、OCR 结果知识检索 Agent匹配应急预案、历史案例、危化品性质预案库、案例库资源调度 Agent查询附近消防站、水源、可调车辆和人员状态位置服务、值班系统报告生成 Agent汇总以上信息生成结构化警情摘要和行动建议所有上游输出主控 Agent 不干具体活它的任务是根据事件类型决定调用哪些智能体、以什么顺序调用。比如“危化品泄漏”和“居民楼火灾”这两类事件资源调度 Agent 的关注点完全不一样前者要查风向和防护装备后者要查疏散通道和登高车辆。这种编排逻辑如果写进一个大而全的提示词里模型很容易顾此失彼拆开之后每个智能体提示词都能写得非常专注效果也稳定得多。2.3 提示工程在智能体系统里的位置有了智能体拆分提示工程架构师就不是只写一段漂亮的“角色设定词”而是要为每个智能体、每个工具调用、每次跨智能体通信设计对应的提示词。你可以理解成智能体是部门提示词是部门的工作制度。制度写得含糊部门就互相甩锅制度写得事无巨细部门又丧失灵活性。好的提示词是用来框定行为边界和操作路径而不是限制模型的天花板。在技术落地时我们通常把提示词分成三层第一层是系统级提示词挂在主控智能体上负责全局策略第二层是任务级提示词挂在各个专职智能体上负责具体流程第三层是工具级提示词嵌在每次调用数据库或接口时负责把自然语言翻译成规范查询。三层各司其职后续做版本迭代和回归评估时也容易定位问题。3. 提示工程架构师写系统提示词的具体姿势3.1 系统提示词的三段式结构先给大家看一段我们实际在用的主控智能体系统提示词片段已脱敏处理。这算是我认为比较稳妥的写法结构你是某城市救援信息平台的调度总控智能体。你的核心职责是在收到警情信息后 有条理地调度下属智能体完成信息收集并输出结构化行动摘要。 工作流程固定为 1. 抽取并确认核心警情要素地点、类型、规模、报警人描述。 2. 根据事件类型判断需要调用的智能体列表。 3. 依次调用智能体并将关键结果缓存在工作记忆中。 4. 汇总所有结果生成《警情信息摘要》和《行动建议清单》。 必须遵守的规则 - 只能输出事实型信息所有结论必须注明证据来源。 - 如果某个字段无数据必须输出“未知”禁止推测。 - 涉及出警指令、控制设备、对报警人承诺等操作一律输出固定话术 “该事项需人工确认已转入值班员工作台”。 - 输出格式严格遵循 JSON Schema不得增加额外字段。这个提示词里最关键的其实是最后两条规则。没有它们模型在压力下会自己脑补信息也会在某个瞬间突然“自作主张”这是救援场景绝对无法接受的。系统提示词不是写给模型看的“人设故事”而是约束行为的“安全红线”。越短的规则越容易被模型执行所以不要写“请务必仔细不要出错”而要明确“禁止推测”这种机器可理解的要求。3.2 任务拆解与思维链引导主控智能体的提示词定了框架专职智能体还需要更细的动作指引。以警情感知 Agent 为例它面对的输入可能是这样一句报警原文“北边那个化工厂好像着火了几个罐子在烧人还没跑出来。”这句话包含大量信息缺失还夹杂着口语和模糊表述。我们给感知 Agent 的提示词里会要求它先做三步思考第一步提取所有显式实体比如地点、对象、状态第二步识别缺失字段用“待确认”标记第三步根据常识补全查询关键词但不把补全结果当作事实。这就是一种引导模型走“思维链”的写法。注意这里不是让它自由发挥而是给它一条固定的推理路线防止它直接跳到最后结论。比如对于“北边那个化工厂”我们要求感知 Agent 输出“据报警人描述为某化工厂具体名称待定位确认”同时把“化工厂”“罐体燃烧”作为检索关键词交给知识检索 Agent 去查危化品数据库。这样既保留了报警人的原始说法又把可查询的实体严格限定在系统可以验证的范围里。3.3 工具调用提示与参数清洗智能体要真去执行查询提示词设计上和纯对话写作完全不同。我们让模型输出的不是普通句子而是一个结构化的工具调用意图由平台层去执行。提示词里会给出一个具体的 JSON 调用约定{ intent: query_resource, parameters: { resource_type: hydrant, location: 北港化工园区, radius_m: 3000, limit: 10 } }为了让模型稳定地生成这个结构我们在提示词里提供了 3 个正例和 1 个反例明确告诉它“不要输出自然语言描述不要套用不存在的地图服务”。这个细节非常有效模型对格式的稳定性比对语义的稳定性要强太多你给它看两个好例子它基本就能跟着格式走。参数清洗也很重要模型把“北边那个化工厂”直接扔给位置服务会查不到所以提示词里会让感知 Agent 先做一次“地点标准化”把口语位置换算成坐标或者正式园区名再交给工具。这条链路看起来多了一步但换来的是下游查询结果质的提升。我刚开始做的时候图省事让模型直接把原始文本拼进检索接口结果 80% 的查询都因为地址不规范而失败。后来补上“地点标准化”这个环节成功率才上来。3.4 动态检索与上下文拼接策略消防预案和危化品数据会定期更新而预训练模型只记得训练时的旧知识。我们的做法是不指望模型背数据而是利用检索增强生成RAG把最新数据实时拼进上下文。在提示工程层面这意味着要给检索 Agent 写一套“如何构造检索词”的规则。具体来说知识检索 Agent 的提示词里会注明收到感知 Agent 传过来的实体后先拆成“事件类型、物质名称、地理位置”三个检索维度每个维度单独查一次如果查不到完整匹配再降级为关键词前缀匹配。这样可以避免模型拿着“化工园区着火”这种模糊短语去检索把一堆不相关预案捞上来。检索结果返回后还需要在提示词里规定上下文顺序先放高优先级匹配结果再放其他参考最后放一条“若以上结果均不相符输出未找到匹配预案”的兜底分支。动态检索让系统具备了“时效性”不再吃训练数据的旧红利。我们后来在模拟测试里故意换了新修订的预案版本系统能准确检索到更新后的内容并正确标注了修订日期。4. 仿真推演一场化工园区夜警事件的完整链路复盘4.1 场景搭建与数据准备纸上谈兵没有意义真刀真枪测一把才放心。我们搭了一套离线仿真环境模拟了一场夜间某园区内储罐区火警事件。输入数据包括一段带有嘈杂背景音但能听懂中文的报警录音转写文本一条物联网温度传感器异常记录一张现场监控截图的光学字符识别结果以及一份气象站提供的风速风向数据。给智能体喂数据也有讲究不能一次性全塞进去否则它分不清主次。我们按照事件推进的时间顺序把报警文本设为第一优先输入温度传感器记录和 OCR 结果作为“现场补充信息”延后加入气象数据单独做一次工具调用。这是为了让系统尽可能贴近真实世界里“信息是逐渐到达”的特性而不是像考试一样把所有信息先铺在桌上。4.2 智能体群的实时表现仿真跑起来之后系统的行为大致是这样的报警文本到达感知 Agent 在 1.8 秒内抽取出了“地点未知、疑似储罐火灾、有人员被困”三个核心要素并把“园区名称待确认”标记为待定紧接着主控智能体判断这类事件需要资源调度和知识检索于是并行调用了两个专职智能体。资源调度 Agent 先通过网络位置服务定位到附近三个消防站和两处水源但提示词里的“地点标准化”节点成功把报警文本里的口语化描述换算成了园区坐标所以查询结果精度很高。知识检索 Agent 用“储罐、燃烧物、防护距离”作为关键词匹配到了一份危化品事故处置预案并标注了预案版本号。报告生成 Agent 将所有信息汇总成一个字段齐全的 JSON 摘要包含警情要素、匹配预案、可用资源和建议处置方向。整条链路跑完大概用了 6 秒比我们预想的低调很多。担忧的问题出现在别处摘要虽然结构完整但篇幅过长把很多非关键资源也列了上来反而淹没了最需要关注的“人员被困”和“风向威胁”这两条信息。这其实是指示词里“排序优先级”缺失导致的直接后果。4.3 复盘后的三轮提示词调优针对仿真暴露的问题我们做了三轮调优。第一轮在报告生成 Agent 的提示词里增加“按危险等级排序优先展示人员伤亡、危险物质、风向下风口位置”的规则并强制摘要前 100 字必须包含这三个要素。效果立竿见影第二次跑出来的摘要重点清晰很多。第二轮我们遇到的是信息冲突问题。温度传感器显示某罐体温度升高但 OCR 结果里没有出现明显火光两个信息源在摘要里被并列放置连逻辑关系都没说明。后来我们在报告 Agent 提示词里加了“如果不同来源存在矛盾必须显式输出冲突标注并将此类信息置于人工复核队列”这才让系统学会“不确定就是不确定”的表达方式。第三轮则是多 Agent 通信层面的问题。一开始资源调度 Agent 和知识检索 Agent 各自同时访问了同一份 GIS 服务造成重复查询。我们在主控提示词里加了一条“互斥工具队列”——同一时刻同一服务只允许一个智能体调用其他智能体命中缓存。这个调整直接让系统响应时间再度缩短也更符合真实平台接口的并发限制。经过这三轮调优这套仿真链路才真正达到我们想要的“能看、能用、敢参考”的状态。每次改提示词我们都会把这一整套仿真事件翻来覆去跑五遍确认不会因为微调引入新问题。5. 实战中容易翻车的提示工程细节与稳健性策略5.1 拒识话术与“不许做”清单提示工程里最容易被新手忽略的一块是“明确告诉模型不做什么”。救援环境下宁可系统少做一件事也不能做错一件事。我们建立了一张“不许做”清单不能确认火警等级、不能建议关闭阀门、不能代替指挥员签发调度指令。清单会直接以规则形式写进系统提示词并要求模型在触达边界时输出一段固定话术。一开始我觉得这样做很蠢像是对模型能力的浪费。但测试中真的发生过模型在回答里附带了“建议立即启动区域断电”这种超出职责范围的指令如果被值班员当成系统建议执行后果不堪设想。加了“不许做”清单之后类似行为被明显压制因为模型对显式禁令的遵从度远高于对隐含边界的理解。5.2 冲突信息处理与幻觉控制幻觉是任何落地系统绕不开的坎尤其在信息残缺的火警场景里模型很容易“脑补”出充满细节但根本不存在的现场情况。我们控制幻觉主要做两件事第一在提示词级别要求每个结论带证据锚点没有证据就输出“未知”第二在流程级别要求所有关键数据都必须经过工具调用验证不允许模型凭通用知识回答。具体到提示词写法我们会在感知 Agent 里加上“如果报警人未提及被困人数必须输出 unknown禁止使用“可能有多人”这类推测性表述”。这看似严苛但对后续资源调度十分重要指挥员宁可看到“未知”然后立刻安排侦察也不能看到一个虚假的“现场已无被困人员”而放松警惕。5.3 超时降级与多 Agent 通信卫生救援系统对延时的忍耐度极低。我们在联调时发现如果某个外部数据接口响应超过 5 秒智能体会一直“干等”导致整条链路卡住。后来在提示词和平台逻辑两侧都加了降级策略平台侧设置超时上限超时后自动返回“服务暂不可用”智能体侧在提示词里规定如果遇到工具超时直接标记该字段为“获取失败”继续执行其他任务而不是反复重试。多 Agent 之间通信还需要注意“上下文污染”。不同智能体关注的焦点不同如果把上一个 Agent 的全部原始输出都传给下一个后面的模型会被大量无关信息干扰。我们的做法是定义严格的消息接口上一级只传递结构化的字段结果摘要限制在固定长度内原始文本只保留在数据库中按需调取。这个“通信卫生”原则让整体系统的稳定性提升了一个档次。5.4 提示词版本管理与回归评估提示词和代码一样属于需要持续维护的资产。我们每改一条规则都像发版一样记录变更原因并且用一批历史警情数据做回归。批次里包含各类典型情况高层住宅火灾、危化品泄漏、野外杂草起火、false alarm误报警每条数据都人工标注了期望的输出关键点。评估指标上我们主要盯四个要素抽取准确率、工具调用正确率、报告可用率和人工复核触发率。调优的目标不是追求某一个指标无限高而是让整体表现“偏保守但稳定”。比如有一次为了提升调用正确率我放宽了工具选择规则结果是调用率上去了误报也增多整体反而倒退。后来收敛到“准确优先、必要时用人工兜底”的策略效果最稳定。我最后再分享一个小技巧在提示词版本更新的提交信息里把仿真测试的结果一并写上去。这样下次排查问题时你能顺着版本历史快速定位是哪条提示词改动导致了行为偏移。在救援这种复杂系统里可追溯性有时比代码逻辑本身还重要。