当时判断
01流量掉了不等于被限流。先确认是不是真异常，再决定符合预期、值得放大、需要干预还是证据不足。
项目档案 08AI 判断工作流2026.07个人产品探索 · 独立 Demo 可运行
流量诊断 Agent：先查清楚，再决定怎么处理
判断内容或账号是不是真有问题，再给出下一步
我的判断
流量掉了不等于被限流。Agent 要先确认是不是真异常，再判断该关闭、加投、进优化池，还是马上拉 Oncall。
Traffic DiagnosisAgent WorkflowHypothesis CompetitionEvidence RoutingHuman in the LoopCross-team Handoff
决策记录
这次判断，怎么站住。
这不是项目总结，而是我愿意被追问的四个点：当时怎么判断、没有选什么、证据从哪来，以及什么情况会让我改判断。
没选什么
02没有把六个模拟 Case 包装成 90% 准确率，也没有宣称 LoRA、SFT、GRPO 或生产 Oncall 已完成。
证据来源
03用爆款退热、内容加投、单条掉量、推荐下降、账号多条内容一起掉和两个看板对不上六个模拟 Case，验证关闭、加投、P2、P1、P0 和数据校验。
什么会推翻
04如果换一组全新原因后，判断和下一步不能稳定成立，或真实团队接不住这些结论，就不能进入 V2 模型训练。
流量诊断 Agent
先别急着说限流，把问题查清楚再处理。
运营或产品把掉量 Case 交进来，Agent 先判断是不是真异常，再决定关闭、加投、进优化池，还是拉 Oncall。
查看现有 Lab六个常见的线上问题
每个 Case 都从运营真的会问的一句话开始，再检查 Agent 有没有找对证据、给对动作。
业务问题
前几天还在涨，现在开始回落，是正常退热还是哪里出了问题？
最后只做四个决定
不堆原因标签，直接回答：要不要处理、谁来接、下一步做什么。
这是正常变化，解释清楚后关闭
先小步加投，边投边看效果
按 P0、P1、P2 交给对应的人处理
先别下结论，把数据和证据补齐
这套 Agent 怎么自己迭代
不是先说模型变强了。每次判断都有答案可以核对；错了就留下 Bad Case，下一轮先练最常错的部分。
- 01收到问题
把“是不是限流了”整理成可以复现的内容或账号 Case。
- 02Agent 先查
调用数据和工具，先确认是不是真的有异常。
- 03对照答案
用案例预设的真实原因，检查结论和处理动作对不对。
- 04看这次错在哪
把结论、证据、动作和表达分开评分。
- 05留下 Bad Case
记下失败和缺失的证据，方便后面集中补。
- 06安排下一轮
优先练最常错、影响最大的问题。
Opening Judgment
开场判断
这件事本质上是什么
这不是一个填完指标就吐原因的流量计算器。它先帮业务确认掉量是不是真有问题，再决定加投还是处理。
最容易被误判的地方
内容或账号掉量时，线上经常混着内容表现、平台异常和数据口径问题。先猜原因，很容易把问题交错团队。
我的判断
我把产品重心从解释原因改成给出下一步：Agent 先收证据、判断优先级，再把 P0 交给 Demo Oncall，P1/P2 交进对应优化池。
AI 迁移方式
Agent 不只给结论，还要把下一步交出去
Demo 用六个 Case 检查结论、动作和接手人，并把失败留进 Bad Case 档案。当前已经能核对结果、生成样本，但还没有完成模型训练。
NODE 01
收集内容与账号案例
NODE 02
验证结论和处理动作
NODE 03
用失败决定下一轮案例