商业 AI Agents 组 组长、产品&工程负责人
广告收入诊断 Agent（Rollie）
掉量诊断跨十余个看板、耗时 1—2 天且靠专家；把专家流程和分层业务知识做成 Agent，配评测与经验回收闭环，完整诊断约 50 秒，周诊断任务峰值 2,028 组。
一次完整掉量诊断：人工跨十余个看板 → Agent 出报告
Q3 周诊断任务 322 组→峰值
省下的人力：每周近 1,000 小时（评奖口径，预估）
止损与增收：每组 case 约 0.5 万元（评奖口径，预估）
选场景：两条漏斗互为因果，规则穷举不了，正是 AI 该接手的地方
一条广告展示之前，系统要从全部在投广告里层层召回、排序，选出一条；展示之后，用户点不点、下不下载、激不激活，又反过来决定它下一次能不能竞得。某个客户收入下降时，原因可能在任何一环，也可能卡在两条漏斗之间，所以排查要跨十余个看板，而且离不开专家。
AI 切入的三个条件，广告诊断逐项命中
规则难穷举
变量多、互相牵动，规则只能覆盖固定路径；阈值写死（例如波动不到 15% 就不往下查），会漏掉当天真正出问题的变量。
依赖专家
要懂上百个过滤器、几十个维度的口径，新人很难独立判断；团队两年来靠 case 周会已沉淀出骨干排查思路，适合交给 Agent 推广。
结果可交互、可验证
用户能追问、补条件、看依据，诊断在对话里收敛；毫秒级的竞价决策不容 AI 多想，就不适合。
更早的两次尝试划清了边界：一项“先生图再贴字”的素材功能，上线前半个月被能直接写中文的生图模型取代；RAG 问答助手把业务知识切成碎片，答简单问题够用，遇到牵一发动全身的问题就召回不全。所以长处只能沉在业务知识和业务特有的工具上，通用能力交给模型自己迭代。
漏斗环节为示意，不代表实际量级。
值多少：完整诊断从 1—2 天压到约 50 秒，省下的是人力，止住的是收入
过去运营排查一次掉量，要跨十余个看板手工查数、汇总、交叉分析：复杂的 case 写完一份完整诊断报告要 1—2 天，简单的也要几个小时。Agent 接手以后，完整诊断约 50 秒出结论。掉量多晚一天止住，就多损失一天收入，所以快本身就是钱。
每周省近 1,000 小时，约等于 20 个人
平均每组 case 约 0.5 万元 × 1,000 组
每周诊断任务：规则式诊断时期约 25 组，Q3 峰值 2,028 组
Q3 每周看板查询，由 Agent 代替人去点
展开详情这两笔钱是怎么算的评奖申报时的口径，都是预估，列出每一步假设+
每周省近 1,000 小时 ≈ 20 人 ≈ 100 万元/月
每个 case 排查 1 小时—1 天，按最低的 1 小时算
每周约 1,000 组 → 省近 1,000 小时
÷（每天 10 小时 × 5 个工作日）≈ 20 人
× 每人 5 万元/月 ≈ 100 万元/月
每组约 0.5 万元，1,000 组 ≈ 500 万元/周
case 里能发现问题，或找到产品优化点
诊断压到分钟级，掉量更早止住，直接缩小损失
平均每组止损或增收约 0.5 万元
× 每周 1,000 组 ≈ 500 万元/周
口径：本人参评时的申报口径，均为预估；1,000 组取 Q2 每周诊断任务的量级（峰值近 1,000 组/周），Q3 峰值已到 2,028 组。人力按最保守的 1 小时/case 计。
时间口径：1—2 天是人工写完一份完整掉量诊断报告；约 50 秒是 Agent 从接到问题到输出结构化报告，含多轮工具调用、推理和报告生成。
三天三版定架构：重心从“造底座”转向“沉业务能力”
2026 年春节后，本人先一个人试：2 月 25—27 日三天重构三版，每一版撞到边界才换方向；随后两周迭代 10 版，MVP 由本人借助 AI 编程亲手写成。
规则式查数
把“人看看板”变成程序自动取数，异常阈值写进规则，稳、快、可解释。边界：阈值要提前写死，变量一多就僵。
自建 ReAct 循环
大模型当诊断大脑：观察 → 思考 → 调工具 → 看结果，再进下一轮；约 50 秒走完过去要几小时的排查，根因正确。边界：一要多轮追问、记忆和上下文管理，底座就越做越重。
薄 Harness，厚 Skill，厚 Code
推理、上下文和工具加载交给通用 Agent 平台；业务方法做成 Skill，错不起的硬逻辑写成代码。
拍板后的三层分工
业务能力做成插件，不绑定哪一个 Harness，也不绑定谁的工作流。3 月 12 日先接进离业务最近的飞书大群，让业务方当天就看到效果；用的人多了，单机飞书机器人只撑得住约 6 个并发，Q2 改成把 Skill 包分发到每个人自己的 Agent 里运行，七成以上查数工具上云、可热更新。有人诊断完发飞书报告，有人生成网页分享，各取所需。
Q1 内完成 V1—V8：规则引擎（V1—V4，10+ 个原子查数工具）→ 自建 ReAct 循环（V5—V6）→ 可插拔的 Skill 工具包（V7—V8，工具返回结果时附带下一步提示，解决深轮次“迷路”）。Harness 指 Claude Code、Codex 这类让模型能读写文件、调用工具的 Agent 外壳。
一次诊断怎么跑：先下钻锁定“掉的是谁”，再顺着漏斗查到底
两阶段诊断是 Skill 的主流程。只顺着漏斗直查，定位不到根因：得先按维度把下降收窄到具体的广告和广告位组合，再对它沿全链路逐环排查。沿途还有五个“界面”引导 Agent 按预期执行，相当于给 Agent 做的菜单和提示。
沿途教 Agent 做事的五个界面
悬停或点按一条原则，看哪些界面体现了它
Skill 知识文档友好 · 最小必要
Skill.md 写主流程，references 放分层的背景、字段和方法。
命令行工具的 --help友好
直接写给 Agent 看：字段去哪查、参数怎么拼、下一步调哪个工具。模型在预训练里见过海量命令行用法，这是它最熟的界面。
服务端校验友好
请求先过一道拦截，把校验结果写回提示，引导 Agent 自己改正。
报错指引友好
底层平台报错时，不只回错误码，还告诉 Agent 下一步查什么、可以怎么改。
运行时提示最小必要
按进度给任务引导、防止原地打转、建议收尾，例如查到精排时提示可以考虑收尾。
第六个界面：工具本身。查数工具不只是“能调通”，还要当一层中间层，把晦涩的底层接口翻译成 Agent 好用的样子
原来的底层接口：为人和网页设计
中间层之后：按业务组织、按需加载
展开详情接进了哪些数据：12 张标准看板 + 4 类非标查询，覆盖漏斗每一环标准看板走统一查询入口，非标查询走拆分后的 4 个工具+
标准看板（沿漏斗从上到下）
- 媒体请求量与质量：上游流量入口是否正常
- 广告下发链路：是否被拉黑、是否受预算或控制评分压制
- 引擎全链路过滤：哪个业务过滤节点过滤了广告
- RTA 链路：请求量、通过率、超时、缓存命中
- 召回链路：按流量、应用、广告维度下钻召回过滤原因
- 粗排、精排：各阶段过滤漏斗与打分
- 出价策略：策略层的拦截原因和调价行为
- 外部 DSP 竞价：填充 → 参竞 → 竞胜 → 下发
- 广告效果总览：曝光、点击、收入、转化，按广告 / 计划 / 广告位 / 媒体 / 行业下钻
- 搜索词粒度：补上效果数据最细只到广告位的缺口
- 预算分析：预算花费进度、达限状态
非标查询（拆成 4 个工具）
- 广告信息详情：投放状态、出价类型、预算、定向、转化目标
- 广告主操作记录：手动操作与系统状态流转
- 内部配置：平台侧策略配置，如拉黑、出价调整、流量控制
- 内部操作记录：运营对配置的修改历史
为什么要这样拆
场景覆盖从 80% 到 100%、看板接入从 50% 到 100%，新增搜索词、外部 DSP、召回、RTA、策略配置、预算分析等 8 个看板。查询越多，越要靠“一种查法 + 按需调用”守住 Agent 的注意力。
长会话被压缩时，通用摘要曾把一个客户逐小时均匀下降的数据，记成某几个小时骤降 100%，Agent 因此误判为客户设了时间定向。解法是借 Agent 平台的生命周期钩子：压缩前把数据范围、业务逻辑、已知发现、下一步核查四类事实存成账本，压缩后再读回，不让通用摘要改写业务事实。
规模：Q1 交付时有 10+ 个查数工具、100+ 条诊断规则（9 大类）、35 个维度 × 69 个指标；Q2 核心数据 100% 接入（12 张标准看板 + 4 类非标查询），新增外部 DSP、搜索位、联盟流量三个主题，覆盖大盘约 71% 的收入。
知识怎么组织：先按“用户常用 × 收入重要”分两层，主题变多后再按业务拆成四层
广告数据看板有三百多个维度和指标，全部塞进上下文，既贵又容易让模型分心、编造。统计用户的真实查询后发现，一小部分维度和指标就承接了绝大多数查询，于是只把这部分先展开，其余只留一个“找得到”的入口，模型需要时再打开。
广告数据看板的维度和指标，词典文件 70 多 KB；全量喂给模型，注意力被冲散，成本也降不下来
10% 的维度和指标承接了 88% 的查询：按“用户使用频次”和“收入贡献”两把尺子挑进第一层
token 用量：低频知识不再默认挤占上下文，用户体验不缺，查询照样完整
第二步（2026 年 6 月）：主题从 1 个扩到 4 个，单份文档越写越长，改成四层，各自按需加载、多人并行建设
展开详情为什么这样分：两次分层各解决什么问题第一次省 token、护注意力；第二次解决知识建设和阅读的双重瓶颈+
按价值分两层，渐进披露
两条尺子：用户在看板上的真实使用频次（和用户交朋友），以及对收入的重要度（结果导向）。高频、高价值的先展开，低频的只留一个“找得到”的入口。思路接近 LLM wiki，不引入 RAG 带来的复杂性和语义割裂。结果：token 省 88%。
按业务主题拆成四层
新增外部 DSP、搜索位、联盟流量三个主题（合计约占大盘 71% 的收入）后遇到两个瓶颈：建设效率（知识更新受限于团队带宽，业务方没法参与）和阅读效率（Skill 文档越长，上下文越占、token 越贵、注意力越散）。拆层后，业务知识可以由懂业务的人按主题写，工具说明书跟着看板走，互不牵连。
只有用户会直接发起的场景，才独立成 Skill
例如日常查大盘收入，就单独做成查数 Skill；诊断里用到的子流程留在诊断 Skill 内部按需加载。
思路接近 LLM wiki：用按价值分层的结构化知识，代替把知识切成碎片的 RAG。
快、准、活：上线之后，靠评测、无感升级和经验回收持续进化
Agent 交付出去只是第一步。每次改版要能确认没改坏（准），新版本要无感地送到每个人手上（快），一线用户调教出的经验既要留得住，又要能回流进官方版本（活）。
新版首周升级覆盖率
过去要手动下载、替换文件，80% 的用户来问怎么升级。现在开会话时先问服务端有没有新版，后台拉包、校验、替换，用户无感，一天一更也不打扰人。
一版评测的耗时
过去人工评测占团队 80% 的时间，只测最强模型、每题跑一次。现在交给三个 Agent：A 从回归用例、新功能和线上真实掉量里收用例，黄金答案由 AI 起草、人来校准；B 用高、中、低三档模型各跑 3 次，每次隔离；C 按结果分加过程分打分，业务正确排第一，其次才看 token 和耗时。
第一轮经验回收
6 份有效反馈提炼出 10 条优化建议，其中 5 条提纯为方法论、规则和工具策略，进了下一版。
展开详情评测怎么做：四个阶段、三个 Agent，承认 AI 有波动，再量它稳不稳用例从哪来、怎么跑才公平、怎么打分+
原来的评测为什么不科学
只用最强模型
不经济，也验证不了中低档模型能不能跑稳
每题只跑一次
大模型输出有随机性，一次不该定结果
在一个会话里连着问
上下文不隔离，每次不是独立、公平的结果
没有度量体系
凭感觉判断答得好不好，“跑几条看看，没问题就发”
新的四个阶段
- 从产品能力出发：每次都要测的回归用例库；扫代码提交和新功能说明，生成新功能用例
- 从线上业务出发：去看板扫当下真实的掉量案例；自动捞用户最近几天在查的问题
- 黄金答案：AI 起草、写成飞书提案，再由懂业务的人校准，把握不准的去问用户（约 80% 凭经验判断、20% 来自用户）
- 模型稳定性：高、中、低三档模型同时跑，看 Skill 在哪一档能跑稳
- 多轮稳定性：同一用例在同一模型和 Harness 下重复 3 次
- 上下文无污染：每次都开独立的子 Agent，互相隔离
- 业务正确性排第一：把一个用例拆成几步断言，按价值加权，数据是否准确的权重远高于报告写得丰不丰富
- 结果分 + 过程分：结果对了，也要看过程里有没有严重误判
- 其次才看 token 成本和耗时
一次评测示例：执行阶段共跑 45 次、每次独立隔离；三档模型平均得分约 95 分，其中一次满分运行 7/7 断言通过、约 8.3 分钟。评测 Agent 群的架构由我主导设计；团队里一位运营背景的同学两个多月后独立开发出三个 Agent（扫用例、执行、打分）和完整的评测报告网页。
活：官方知识与个人经验分两条轨道存，升级不会冲突覆盖
分开存
官方 Skill 随版本自动更新；个人 Learnings 放在独立目录，升级碰不到。提示词里也明确要求 Agent 不改官方 Skill。
一起读
每次开工两轨都加载，冲突时个人经验优先，因为它首先是这个人的助理。用户纠正 Agent 时，它会自动记进自己的笔记。
民主收集，集中提纯
Learnings 随会话自动上传（5 月初起，此前要手动交）；AI 先聚类去重、挑出高价值问题，专家提纯成方法论、规则或工具策略，评测通过后再发版分发。
展开详情第一轮经验回收，提纯进下一版的 5 条来自一线用户的 6 份有效反馈，先由 AI 聚类成 10 条建议，再挑出 5 条+
- 先收窄时间窗口：不直接查全天，先看全天趋势，聚焦真正下降的时段
- 对比时换排序方式，让注意力落在核心数据上：查上涨按今天的收入排序，查下降按对比日的收入排序
- 时间参数统一用北京时区，避免口径对不上
- 单纯查数不强制走完整条过滤链路，不是掉量问题就不必按诊断流程走到底
- 出价相关的价格变化时，拆到原子指标：目标转化成本、预估转化率、调价系数各自怎么变
一个个人经验的例子：某小语种金融客户，金融行业只看站内收入、不看外部 DSP 收入，用户教过一次，Agent 之后就按这个口径选主指标。
结果：Q3 每周诊断任务
Rollica 上线前 4 周，每周诊断任务在 287—369 组之间；上线后默认装好官方 Rollie Skill、定时盯盘门槛变低、各方 Agent 走统一的查数入口，任务随之放量。峰值周自动盯盘 1,499 组，占比从 Q3 初的 49% 升到 74%。整套方法也复用到面向客户的小米广告投放 Agent AdmiClaw：同样是薄 Harness 加厚 Skill、带校验的查数工具、分层知识和评测，按优化师视角重设指标与数据范围。
口径：每周人工触发与定时盯盘的诊断任务合计，统计到 2026-09-16。Q3 用户 106 人，行业运营渗透 100%、销售运营 80%，35 份问卷满意度 85.2%。
问题
Problem- 运营排查掉量要跨十余个看板手工查数，竞价与用户行为两条漏斗互为因果，完整诊断需 1—2 天、依赖专家，排查越慢，收入波动越久
- 旧规则式诊断只定位、不给结论
打法
Approach- 选场景看三条：规则难穷举、依赖专家、结果可验证
- 薄 Harness、厚 Skill：推理交给通用底座，流程与知识做成可插拔 Skill、分发到各人 Agent，鉴权、查数由代码兜底
- 推广靠飞书业务群首发、双周用户交流会
方案
Solution- 主流程走两阶段诊断：先按维度下钻锁定掉量主体，再查该广告全链路漏斗
- 核心数据 100% 接入，查数 CLI 带服务端校验与报错指引
- Skill 静默升级，官方知识与个人 Learnings 双轨、升级不会冲突覆盖，经验回收提炼后进下一版
攻坚
Hard parts- ①300+ 维度指标挤占上下文、诱发幻觉→按使用频次 × 收入贡献分层按需披露，token 省 88%
- ②人工评测一版要一周、只测最强模型→评测用例的收集、执行、评分交给三个 Agent，高中低三档模型各跑 3 次，结果与过程加权打分，缩到 2—3 小时
- ③长会话压缩把逐小时数据记错、误判根因→压缩前存事实账本、压缩后回注
结果
Results- 完整诊断从人工 1—2 天缩到约 50 秒
- 按评奖口径（预估）每周省近 1,000 小时人力，约 100 万元/月，止损与增收约 500 万元/周
- 新版首周升级覆盖率 30%→100%，一版评测 1 周→2—3 小时
- Q3 周诊断任务 322 组→峰值 2,028 组（规则式诊断时期约 25 组），看板查询 4.15 万次/周由 Agent 代人去点
- 用户 106 人，行业运营渗透 100%、销售运营 80%，问卷满意度 85.2%
- 整套方法复用到面向客户的 AdmiClaw