商机长期不动，最稳的自动发现方式是“确定性规则生成候选，Agent 跨系统复核原因，人确认处置，系统回读终态”。不要让模型凭感觉判断谁不作为，也不要把超过若干天没更新等同于商机已经失控。适合已有阶段、负责人和跟进记录的 CRM；如果漏斗字段本身没有统一口径，应先治理数据。
先把“长期不动”拆成可执行规则
商机阶段不同，正常节奏也不同。初次接洽可能看最近跟进，方案阶段要看客户承诺的下一步，合同阶段则要看审批、用印或采购流程。规则引擎应输出 ruleId、商机 ID、证据时间、当前负责人和命中原因，Agent 负责解释与补充证据，不能改变候选的确定性基础。
| 候选规则 | 必须补看的事实 | 可能结论 | 默认承接角色 |
|---|---|---|---|
| 超过阶段阈值无有效动作 | 最近跟进、下次行动日期、客户回复 | 真停滞或待观察 | 销售本人 |
| 高赢率但长期未推进 | 赢率依据、报价、决策链和客户承诺 | 预测失真或需主管介入 | 销售主管 |
| 合同阶段无 CRM 更新 | 审批、用印、订单状态 | 外部流程在推进或 CRM 漏回写 | 商务/销售 |
| 负责人无效或为空 | 当前组织与客户归属 | 需重新分配 | CRM 管理员 |
| 客户或商机疑似重复 | 客户编码、统一标识、联系人与历史单据 | 转数据治理 | 数据管理员 |
规则只负责说“这里值得看一眼”，不负责给人定性。命中规则不等于销售没有做事，更不应直接在群里点名。提醒可以先一对一送达；只有超期未处理或影响预测时，才按既定机制升级。
Agent 要跨系统完成四类复核
第一类是 CRM 事实：商机阶段、最近有效跟进、下一步日期、负责人和赢率依据。第二类是 流程事实：报价、合同或审批是否已经在其他系统流转。第三类是 交易事实：是否已有有效订单、回款或项目状态与漏斗冲突。第四类是 组织与主数据事实：负责人是否仍有效、客户是否重复、关联对象是否属于同一主体。
这些事实有冲突时，不要静默覆盖。Agent 应把来源、时间和差异并列展示，交给销售、主管或数据管理员确认。涉及金额、商机终态、负责人流转等动作，继续沿用业务系统原有权限和审批。
如果想先理解销售 Agent 应该接管哪些杂活，可读销售 AI 助手指南；若 CRM、审批和订单各自为政，可先补系统集成的基本分工。
处置结果必须结构化写回
停滞哨兵至少要支持几种不同终态：确认继续推进、条件暂未变化、已有流程在推进、需要重新分配、转数据修复、明确关闭。每个结果都应写明证据、责任人、下一步日期，以及关联的商机、审批、订单或数据修复任务。
“已提醒销售”不是终态，“销售回复收到”也不是。真正闭环要由独立作业重新查询：商机是否有了新的有效动作；等待中的审批是否仍在流转；重新分配是否写进客户当前负责人；重复对象是否进入治理队列；已关闭商机是否保留关闭原因。没有达到验收谓词的任务，应继续处于待处理或异常状态。
怎样设规则才不会每天制造噪音
第一，阈值要按阶段配置，不用一个“多少天未跟进”扫全漏斗。第二，优先读取明确的下一步日期；销售与客户约定了复查时间，就不应在日期前重复提醒。第三，同一商机、同一规则只保留一个活跃处置项，证据更新时更新原任务，不重复创建。第四，保存规则版本，阈值调整后能解释为什么昨天没命中、今天命中了。
还要把提醒和升级分开。首次命中先交给当前负责人核实；负责人确认已有流程在推进，就关联对应审批或订单并进入观察；超过处置时限仍无结果，再升级主管。数据重复、负责人无效等问题直接走治理队列，不混进销售业绩评价。
主管每轮应抽查几类样本：真停滞、被跨系统证据排除、数据缺失、规则误报和处置后复开。误报原因要回到字段或规则修复，不能简单把阈值拉长。哨兵的目标是更早发现可行动的异常，而不是让日报看起来很忙。
若某条规则长期只产生无法行动的候选，就应暂停并复盘证据条件；如果关键证据始终取不到，则把缺口列为系统改造项，不让销售反复替系统补洞。
上线时先跑只读队列
第一阶段只生成候选和证据包，不自动改商机。让销售主管抽查误报来自阈值、漏字段还是跨系统证据缺失，再调整规则版本。验收重点看候选可解释率、误报分类、结果回写覆盖、超期未处置和独立回读一致性，而不是追求命中越多越好。
成熟后再逐步开放低风险写回，例如补充已核实的下一步；商机关闭、金额修改和负责人变更仍保留人审。项目级验收可对照AI Agent 项目验收清单，完整路线见AI Agent 落地路线图。销售团队也可以从销售岗位解决方案查看相邻场景。
