1. 为什么“公关与传播经理”值得被孵化成一个 Agent突发舆情这件事做过公关的人都知道真正决定走向的往往不是后面几天的长文回应而是事发后最初那十几分钟。信息还没核实清楚内部还没对齐口径外部已经在截图、转发、追问。传统做法是拉群、打电话、翻聊天记录、找当事人确认一圈下来半小时过去了第一波舆论高峰已经过去你才刚写完第一句话。“公关与传播经理”这个 Agent 要解决的就是把这套流程压缩到黄金 15 分钟里。它的核心任务不是替人写一篇漂亮的公关稿而是完成三件事事实溯源、影响面判断、回应声明初稿。这三件事在 Grix 里可以被拆成可编排的节点让 Agent 按固定链路跑而不是每次靠人临场发挥。我在实际搭这个 Agent 之前先想清楚了一个问题为什么是“孵化”而不是“开发”因为公关场景的规则是活的。今天某个词是敏感词明天可能就脱敏了今天某个平台的传播规律下个月可能就变了。如果把它写死成一套硬编码逻辑维护成本会高到没人愿意用。Grix 的孵化思路更像是给 Agent 一个可迭代的骨架让它能随着实际案例不断调整判断规则和话术模板。这个 Agent 适合谁用一是中小团队里没有专职公关、但需要有人兜底对外口径的运营或市场同学二是大团队里想给公关同事减负、把重复性溯源工作自动化的技术同学三是对 Agent 编排感兴趣、想找一个真实业务场景练手的开发者。它不要求你懂复杂的模型训练但要求你理解公关的基本判断逻辑否则孵化出来的 Agent 只会说正确的废话。2. 拆解“黄金 15 分钟”里到底要跑哪些判断2.1 事实溯源不是找“真相”而是找“可引用的事实”很多人对事实溯源有个误解以为是要查清事情的全部真相。在舆情场景里15 分钟内你不可能查清全部真相你要做的是找到可以被引用、可以被验证、可以被写进声明里的事实。比如一条截图说“某产品导致用户数据泄露”你要找的不是“到底有没有泄露”而是“这条截图的原始出处是什么”“截图里提到的功能是否真实存在”“官方此前有没有相关说明”。我在 Grix 里给这个 Agent 设计的第一组节点就是围绕“可引用事实”来的。输入是一段舆情描述或一张截图 OCR 后的文本输出是一组带来源标记的事实条目。每条事实必须包含三个字段事实内容、来源类型、可信度标记。来源类型分官方公告、内部系统记录、公开报道、用户反馈四类可信度标记分已核实、待核实、无法核实三档。这里有个实操细节不要指望 Agent 一次就能把所有事实找全。我的做法是让它在第一轮只输出“已知事实”和“关键未知项”把未知项列成待办清单由人决定哪些必须马上查、哪些可以暂缓。这样做的原因是15 分钟里人的注意力是稀缺资源Agent 的价值是帮你把“不知道什么”也列清楚而不是假装什么都知道。2.2 影响面判断的关键是“传播势能”而不是“传播量”影响面判断最容易踩的坑是只看转发量、评论量这些绝对值。一条 100 转发的截图如果转发者里有几个关键节点它的传播势能可能比 1000 转发还大。我在孵化这个 Agent 时把影响面判断拆成了三个维度传播节点质量、情绪烈度、议题延展性。传播节点质量看的是首发者和关键转发者的身份特征比如是否是行业内有影响力的人、是否是媒体账号、是否是竞品相关方。情绪烈度看的是文本里的情绪词密度和极端表达比例。议题延展性看的是这个话题有没有可能从单一事件延展到品牌、行业、政策等更大范围。这三个维度在 Grix 里可以用不同的判断节点来实现。传播节点质量可以用规则加模型判断情绪烈度可以用关键词加语义分析议题延展性则需要结合历史案例库做类比。我实测下来三个维度里最容易出偏差的是议题延展性因为模型很容易把不相关的话题强行关联。解决办法是给这个节点加一个“延展理由”字段要求 Agent 必须写出为什么认为这个话题会延展人再快速扫一眼就能判断是否合理。2.3 回应声明的“三段式”结构为什么在 15 分钟里最稳回应声明在 15 分钟里不可能写得面面俱到但必须结构完整。我试过好几种结构最后发现最稳的是三段式确认事实、表明态度、给出行动。第一段只写已经核实的事实不猜测、不解释第二段表明对事件本身的重视和对相关方的关切第三段给出接下来要做的具体动作比如“已启动内部核查”“将在 X 小时内同步进展”。这个结构的好处是它不依赖你对事件全貌的了解只依赖你对已知事实的掌握。即使后面发现事实有出入第一段的“已核实事实”部分也可以修正而态度和行动部分通常不需要大改。我在 Grix 里把这个结构做成了一个模板节点Agent 只需要把前面溯源到的事实和影响面判断结果填进去就能生成初稿。注意三段式里最忌讳的是第一段写“经查该事件系不实信息”。在 15 分钟内你很难完成完整的核查这种表述一旦被推翻二次舆情的杀伤力比第一次还大。我的经验是第一段只写“我们注意到有关于 X 的讨论目前正在核实中”把“不实”这种定性留到有确凿证据之后。3. 在 Grix 里把判断逻辑落成可编排的节点3.1 输入层舆情原文、截图 OCR、内部上下文三路并行Grix 的编排能力体现在它可以把不同来源的输入并行处理。我在这个 Agent 里设了三路输入第一路是舆情原文直接粘贴或从监控系统推送第二路是截图 OCR 文本用于处理那些只有图片没有文字的情况第三路是内部上下文比如产品当前状态、近期已知问题、客服反馈摘要。这三路输入的处理方式不同。舆情原文和 OCR 文本走同一套事实提取节点内部上下文走单独的匹配节点。匹配节点的作用是把舆情里提到的问题和内部已知问题做关联如果匹配上了就直接把内部记录作为“已核实事实”输出如果没匹配上就标记为“待核实”。这里有个容易忽略的点内部上下文的格式要统一。我一开始让团队随便贴聊天记录结果 Agent 提取出来的信息乱七八糟。后来改成固定格式每条内部信息必须包含“时间、来源、内容、状态”四个字段Agent 的匹配准确率明显提升。这个格式不需要很复杂用简单的表格或 JSON 都行关键是字段要固定。3.2 事实提取节点用“问题清单”驱动而不是“答案清单”事实提取节点是整个 Agent 的核心。我试过两种设计思路一种是让模型直接输出“发生了什么”另一种是让模型输出“我们需要知道什么”。第一种思路的问题是模型很容易编造细节第二种思路虽然看起来绕但更可靠。具体做法是事实提取节点先根据舆情原文生成一组问题比如“截图里的功能是否真实存在”“该功能的上线时间是什么”“此前是否有类似反馈”。然后每个问题走一个独立的查询节点去内部知识库或公开信息里找答案。找到答案的标记为已核实找不到的标记为待核实。这种“问题清单”驱动的设计好处是每一步都可追溯。如果最后声明里写错了一个事实你可以顺着问题清单查到是哪一步出了问题。而且问题清单本身也可以作为内部沟通的材料让相关同事知道需要确认哪些点而不是笼统地说“赶紧查一下”。3.3 影响面判断节点规则打底模型修正影响面判断节点我采用的是规则加模型的混合方案。规则部分负责硬性判断比如“是否涉及监管敏感词”“是否涉及人身安全”“是否涉及未成年人”这些一旦命中就直接拉高优先级。模型部分负责软性判断比如情绪烈度、议题延展性。规则打底的原因是有些红线是不能靠模型概率来判断的。模型可能会因为训练数据的偏差把某些严重问题判断为低优先级。规则部分虽然简单但胜在稳定。模型修正的原因是规则覆盖不了所有情况尤其是那些没有明显关键词但实际很严重的问题。我在 Grix 里把这两部分做成串联节点先过规则规则命中就直接输出高优先级并附带命中原因规则没命中的再过模型模型输出三个维度的评分和理由。这样既保证了红线不被漏掉又保留了灵活性。3.4 声明生成节点模板加变量而不是自由生成声明生成节点我坚持用模板加变量的方式而不是让模型自由生成。原因是自由生成的声明虽然读起来流畅但很容易在细节上出错比如把“正在核实”写成“已经确认”把“部分用户”写成“所有用户”。在舆情场景里这种细节错误是致命的。模板加变量的做法是先定好三段式的骨架然后把需要填的变量列出来比如“事件描述”“已核实事实”“待核实事项”“行动措施”“同步时间”。Agent 的任务是从前面节点的输出里提取这些变量填进模板。如果某个变量缺失就标记为“待补充”而不是让模型自己编。这个做法还有一个好处就是模板可以版本化管理。每次舆情结束后团队可以复盘模板哪里写得好、哪里需要改下次直接更新模板。这样 Agent 的能力是随着使用不断积累的而不是每次从零开始。4. 孵化过程中踩过的坑和对应的解法4.1 坑一Agent 把“待核实”当成“已核实”输出这是我在早期测试里遇到的最严重的问题。Agent 在事实提取节点找不到答案时会倾向于用模型已有的知识去补全然后标记为已核实。结果就是声明里出现了未经确认的细节差点造成二次舆情。解法是在事实提取节点后面加一个“核实状态校验”节点。这个节点的逻辑很简单任何标记为“已核实”的事实必须附带来源链接或内部记录编号没有来源的强制降级为“待核实”。这个校验节点不需要模型用规则就能实现但效果非常明显。提示这个校验节点最好做成独立的、可复用的组件。因为不只是事实提取影响面判断和声明生成里也可能出现类似问题独立组件可以到处挂。4.2 坑二影响面判断被“情绪词”带偏情绪烈度这个维度很容易被情绪词带偏。比如一条舆情里出现了大量感叹号和极端词汇但实际传播范围很小情绪烈度评分却很高导致优先级被误判。解法是给情绪烈度加一个“传播基数”的修正系数。具体做法是情绪烈度评分先算出来然后乘以一个基于传播基数的系数。传播基数小的时候系数小于 1把情绪烈度拉低传播基数大的时候系数大于 1把情绪烈度拉高。这个系数不需要很精确用分段函数就行比如传播量小于 100 时系数 0.5100 到 1000 时系数 1大于 1000 时系数 1.5。4.3 坑三声明模板在不同场景下不够用我一开始只做了一个通用模板结果发现不同场景需要的声明结构不一样。比如产品故障类舆情需要强调“修复进展”而服务态度类舆情需要强调“内部整改”。通用模板虽然能填但读起来很别扭。解法是做模板库而不是单一模板。模板库按场景分类每个场景一个模板Agent 根据影响面判断节点的输出自动选择模板。如果判断不出来就默认用通用模板并标记“建议人工选择模板”。模板库的维护成本不高但效果提升很明显。4.4 坑四Agent 跑完一圈超过了 15 分钟这是最现实的问题。理想情况下 Agent 应该在几分钟内跑完但实际测试时因为要调用多个模型和查询多个数据源跑完一圈经常要十几分钟。如果再加上人工确认的时间15 分钟根本不够。解法是分阶段输出而不是等全部跑完再输出。我把 Agent 的输出拆成三个阶段第一阶段只输出“已知事实”和“关键未知项”大概 3 分钟内完成第二阶段输出影响面判断和模板选择大概 5 分钟内完成第三阶段输出声明初稿大概 5 分钟内完成。每个阶段完成后立即推送给负责人负责人可以在等待下一阶段的同时开始人工核实。这样整体感知时间就压缩到了 15 分钟以内。5. 让 Agent 越用越准的几个迭代习惯5.1 每次舆情结束后做一次“节点复盘”Agent 跑完一次舆情不要只看最终声明写得好不好要顺着节点一个个复盘。事实提取节点有没有漏掉关键问题影响面判断节点有没有误判优先级声明生成节点有没有填错变量每次复盘只需要花十几分钟但积累下来Agent 的判断规则会越来越贴合实际业务。我自己的做法是建一个复盘表格每次舆情后填一行记录哪个节点出了问题、问题是什么、怎么改。改完之后在 Grix 里更新对应节点的配置下次跑的时候就能验证效果。这个习惯坚持了几个月之后Agent 的首次输出可用率从不到 30% 提升到了 70% 以上。5.2 把“人工修改”变成“模板更新”每次人工修改声明初稿都是一次模板优化的机会。如果某类修改反复出现比如总是要把“所有用户”改成“部分用户”那就说明模板里的变量定义有问题应该把“用户范围”做成一个必填变量而不是让模型自己判断。我在 Grix 里给声明生成节点加了一个“修改记录”功能每次人工修改后修改前后的文本都会被记录下来。定期看这些记录就能发现模板的系统性问题。这个功能实现起来不复杂但价值很高因为它把人的经验直接转化成了 Agent 的规则。5.3 用历史案例做回归测试Agent 的规则改多了之后很容易出现“改好一个、改坏一个”的情况。解法是建一个历史案例库每次改完规则拿历史案例跑一遍回归测试看看之前能正确处理的情况有没有被改坏。历史案例库不需要很大十几个典型案例就够。每个案例包含舆情原文、当时的正确判断、当时的声明终稿。回归测试的时候对比 Agent 的新输出和当时的正确判断就能快速发现回归问题。这个习惯在 Agent 规则越来越多之后尤其重要因为人脑很难记住所有规则之间的相互影响。6. 关于这个 Agent 后续还能怎么扩展这个 Agent 目前聚焦在“黄金 15 分钟”的响应阶段但舆情处理其实还有后续阶段比如持续监测、二次回应、复盘归档。这些阶段也可以做成独立的 Agent和当前的响应 Agent 串联起来形成一个完整的舆情处理链路。另一个扩展方向是把这个 Agent 的能力复用到其他需要快速事实溯源和声明生成的场景比如客服投诉升级、合作伙伴纠纷、内部沟通事件。这些场景的判断逻辑和舆情有相似之处但侧重点不同需要调整节点配置和模板库。我在 Grix 里试过把响应 Agent 的骨架复用到客服场景大概改了两三个节点就能跑起来效果比从零搭快很多。最后分享一个我在孵化过程中体会最深的一点Agent 的价值不在于它一次能跑多完美而在于它能把人的判断过程显性化。每次 Agent 跑完你都能看到它是怎么一步步得出结论的哪些地方它不确定哪些地方它可能出错。这种透明性本身就是一种能力它让人和 Agent 之间的协作变得有据可依而不是黑箱对黑箱。