项目交付风险不是到了截止日才突然出现。真正有用的 Agent 应每天跨计划、需求、工时、问题、依赖和客户确认寻找早期信号，并把同一根因聚合成一个有责任人的风险事项。
五类信号比“任务逾期”更早
| 信号 | 典型证据 | 可能影响 |
|---|---|---|
| 范围漂移 | 新需求增加、验收口径变化、频繁返工 | 计划与成本失真 |
| 进度偏离 | 完成比例不变、关键路径落后、里程碑未确认 | 交付日期风险 |
| 投入异常 | 工时集中在返工、关键角色长期无投入 | 资源与质量风险 |
| 依赖未决 | 接口、数据、账号、设备、供应商未到位 | 后续任务无法开始 |
| 决策等待 | 问题无人拍板、客户反馈超期、变更未审批 | 项目持续停滞 |
每条信号都要关联真实项目、任务、需求或问题 ID，不能只从聊天语气推断“项目可能不顺”。
把同一根因合并成一个风险
一个接口账号未提供，可能让十个任务同时变红。如果 Agent 给负责人发十条提醒，只会制造噪音。正确做法是建立一个风险事项，列出根因、受影响任务、最晚处理时间、责任人和解除条件。
新证据到来时更新原风险，而不是每天创建新卡。风险关闭也不能只靠负责人点完成，应重新检查依赖是否到位、受影响任务能否继续。
建议动作不能越过项目治理
Agent 可以建议调整顺序、补齐资料、召开决策会或发起变更，但不能擅自修改客户承诺、合同范围和里程碑。涉及延期、增费、范围删减的动作必须展示证据，由项目负责人和有权人确认。
项目资料齐套的具体方法见制造项目齐套怎么巡检；异常如何形成责任队列见Agent 异常队列怎么设计。
每日巡检输出一张可行动清单
清单按影响和时点排序，每条只保留项目、风险、证据、影响、责任人、截止时间和推荐动作。对于证据不足的信号，标为“待确认”，不要直接升成高风险。
项目负责人处理后，Agent 回读任务、问题、审批或客户确认状态，达到解除条件才关闭。长期无人处理的风险按规则升级，但升级对象也要明确。
验收时看提前发现天数、重复告警压缩率、有责任人比例、按期处置率和实际延期漏报，而不是看每天生成多少条预警。需要把项目系统、工时、需求与沟通证据接起来，可继续了解项目岗位解决方案和定制开发。
风险规则需要按项目类型调整
固定价项目更关注范围漂移和返工，实施项目更关注客户资料、环境与关键用户配合，研发项目更关注技术不确定性和验证结果。不能用同一条“七天无更新”规则判断所有项目；先定义项目类型、阶段和关键路径，再配置相应信号。
规则要保留版本。项目从调研进入开发后，风险阈值和所需证据会变化，但已经产生的历史风险仍按当时规则解释。
沟通信号只能作为线索
会议中多次提出担忧、客户长时间未回复、群里反复追问，可能说明风险，也可能只是沟通习惯。Agent 可以关联这些信号并要求项目经理确认，不能只做情绪分析就把项目判红。最终风险要落到可验证的依赖、决策、进度或质量事实。
变更与风险要互相引用
范围变更通过后，原风险可能解除，但计划、成本和里程碑也要同步更新；若变更未通过，新增工作不能悄悄进入执行。风险卡引用变更单，变更单列出受影响任务，避免两个模块各说各话。
复盘漏报比统计命中更重要
项目结束后抽取实际延期、返工和客户争议，反查系统是否提前出现信号、为何没有告警或为何告警未处理。只统计 Agent 发过多少预警，会鼓励它多报；分析真正发生但没有被发现的风险，才能持续提高价值。
