# Ads Agent 深度拆解 & 尽调问题清单

> 基于 `seekee` 案例的 Google Ads 投流 AI Agent 系统分析
> 整理给 Emma · 2026-05-31

---

# 上篇：产品与系统深度拆解

## 一、什么是"投流"？（小白入门）

想象你在街上开了一家店。店开好了，没人进来，怎么办？

你**买广告**。在街口立一块牌子，路人看到，有人就进来了。

**投流**就是把这块牌子搬到互联网上——在 Google、Facebook、TikTok 上买广告位，用户刷手机时看到你的广告，点进去，下载你的 App。

### seekee 具体在干嘛？

seekee 是一个西语/葡语市场的流媒体 App（类似 Netflix），里面有很多韩剧（K-drama）配了西语字幕。他们去 Google Ads 投广告，让拉美用户看到后下载这个 App。

**怎么投的？**

1. seekee 做广告素材——可能是一段韩剧精彩片段（视频），也可能是一句文案配张图（图片/TEXT）
2. 上传到 Google Ads，告诉 Google "帮我投放"
3. Google 把素材推给用户——用户在 YouTube 看视频、在某个 App 里看到插屏广告
4. 用户点广告 → 跳转 App Store / Google Play → 下载 → 成为用户

**钱怎么算？**

seekee 告诉 Google："每次有人下载我的 App，我最多愿意花 $0.08（CPA = Cost Per Action，单次下载成本）"。Google 按这个预算自动竞价、展示。

> **一句话**：seekee 每个月花 $200-300 万美元给 Google，换来几百万人下载 App。

---

## 二、投手每天在干啥？

seekee 有一个角色叫**投手**（Media Buyer）。他的工作核心：**怎么让 $200 万美元花得更值。**

### 他要管的东西

- **几千条素材**：韩剧片段、葡语字幕版、西语配音版、不同的前 3 秒……每条都是一个独立素材
- **两个 Google Ads 账号**：483-522-0990（主账号，花大部分钱）和 985-025-6295（备用）
- **几十个 Campaign（广告系列）**：每个 campaign 是一组素材的集合，有自己的预算

### 他要盯的变化

| 指标 | 含义 | 例子 |
|---|---|---|
| **CTR（点击率）** | 100 个人看到，几个点了？ | 素材初始 CTR 48%，3 天后跌到 7% |
| **CPA（单次下载成本）** | 花多少钱换一个人下载？ | 正常 $0.08，某素材飙到 $0.20 |
| **消耗（Spend）** | 每天在烧多少钱？ | 某素材一周烧了 $305 基本没转化 |

### 投手靠直觉做的判断

- "这条素材跑了 3 天，CTR 从 48% 掉到 7%，得换了"
- "这几条文字素材 CPA 都比正常高出一倍多，暂停吧"
- "这个 campaign 上周花 $2 万多，这周才几块钱？出事了"

---

## 三、核心痛点

### 1. 人不够用——几千条素材同时跑

一个投手能同时盯几十条素材。但 seekee 同时跑的可能上千条。绝大多数素材发生了什么，投手根本看不到。

比如素材 `#342965287864`——一条文字素材跑了 49 天，CTR 跌了 51.9%，每周还在烧 $305。投手可能压根不知道这条素材存在。

> 一条 $300 看起来不多，100 条这样的素材一周就浪费 $3 万。

### 2. 信号发现不及时

素材 CTR 下滑是渐变过程——今天跌 10%，明天跌 20%，后天跌 40%。人的注意力有限，可能跌了 60% 才反应过来，中间的几天都在烧无效的钱。

### 3. 经验全在脑子里，换人就废了

一个投手干了半年，摸索出："seekee 的韩剧 romcom 类素材在拉美 CTR 高但转化差""KOL 类素材 CPA 偏高正常不用急""TEXT 素材一般 3-5 天就该换"……

这些经验无法沉淀——投手离职，经验跟着走。新投手从零开始。

---

## 四、Ads Agent 怎么解决？（网站完整架构）

这是一套 **AI 驱动的投流盯盘系统 + 自我进化引擎**，分 7 层：

```
Google Ads API
     │
     ▼
┌──────────────┐
│ ① Ingest     │  从 Google Ads API 拉素材级数据 → asset_daily 表 125,134 行
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ ② Rule       │  6 种信号检测规则，每 6 小时跑一次
│    Engine    │
└──────┬───────┘
       │ 近 7 天产出 1,024 条原始信号
       ▼
┌──────────────┐
│ ③ Gate       │  降噪：去重 / cooldown / 自动消化 → 34%~64% 落地率
└──────┬───────┘
       │ 当前 139 条待处理 issue
       ▼
┌──────────────┐
│ ④ Inbox      │  投手看到 issue：摘要 + 建议 + 严重度
│   + 看板      │
└──────┬───────┘
       │ 投手给反馈
       ▼
┌──────────────┐
│ ⑤ Feedback   │  5 种反馈按钮 → 采纳 / 误报 / 暂不处理
│    Loop       │
└──────┬───────┘
       │ reward signal
       ▼
┌──────────────┐
│ ⑥ Self-Evolve│  memory.md + product.md + skill.md 持续更新
│   (本周加)     │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│ ⑦ Proactive  │  未来：Agent 自动执行（暂停素材、调整预算）
│    Agent      │
└──────────────┘
```

### ① Data Ingestion（数据拉取层）

`ingest-google-ads` 从 Google Ads API 拉素材粒度数据，落到本地 DB：

- asset_daily 表：每个素材每天的数据（展示量、点击量、花费、转化数）
- 计算指标：CTR、CPA
- 素材属性：类型（视频/图片/TEXT）、投放天数、状态（正常/被拒/源文件失效）

> 截图显示目前已累积 **125,134 行**数据，但 ingest 当前挂了（"❌ ingest-google-ads failed，上次拉取 1 天前"）。

### ② Signal Detection（信号检测层 / Rule Engine）

Rule Engine 每 6 小时跑一次（`run-checkup` 定时任务），覆盖 6 种信号：

| 信号类型 | 检测逻辑 | 近 7 天产出 |
|---|---|---|
| **高 CPA** | 7 日 CPA 超出同类素材中位数 N%（阈值分层：INFO/WARN/CRITICAL） | 882 |
| **approval_limited** | Google 限制了投放范围 | 59 |
| **拒登/限投** | 素材因色情/SYMBOLS 等政策被 Google 拒登 | 34 |
| **素材疲劳** | CTR 对比投放初期大幅下降（如 CTR 跌 75%，已投 49 天） | 25 |
| **素材不可用** | 视频源失效，触发 PROHIBITED 违规 | 21 |
| **系列疲软** | Campaign 级别花费环比暴跌（如从 $22K 跌到 $1.82） | 3 |

> 高 CPA 占绝对主导（86%），base CPA 约 $0.08-0.10，说明是低客单价 App 安装类广告。

### ③ Gate（降噪层）

不是所有 signal 都变成 issue。Gate 做的事：

- **抑制重复**：同一素材同一类问题短期内不重复报
- **cooldown**：刚处理过的冷却期内不再弹
- **自动关闭**：素材已被 PAUSED、指标自愈（resolve 事件）→ 自动标记消化

| 信号类型 | 产出 | 落到 issue | 落地率 |
|---|---|---|---|
| 高 CPA | 882 | 288 | 33% |
| 素材疲劳 | 25 | 16 | 64% |
| 拒登/限投 | 34 | 8 | 24% |

近 7 天系统自动消化了 176 条 issue。

### ④ Inbox + 看板（人机交互层）

投手看到的每条 Issue 包含：

| 字段 | 例子 |
|---|---|
| 严重度 | CRITICAL / WARN / INFO |
| 类型 | 素材疲劳 / 高 CPA / 拒登 |
| 资源 | 账号 → 系列 → 素材 |
| 摘要 | "TEXT素材投放 49 天，CTR 跌 51.9%，本周仍消耗 $305.6" |
| 建议 | "建议暂停" / "建议降级观察" |

看板总览：**139 条待处理**，15 条 Critical，119 条 Warn，5 条 Info。

### ⑤ Feedback Loop（反馈闭环——Reward 收集点）

投手对每条 issue 给反馈，共 5 种：

| 反馈 | 含义 | 累计 |
|---|---|---|
| ✅ 采纳了 | 信号正确，建议靠谱，照做了 | 13 |
| 👍 信号对·建议不行 | 问题存在，建议不靠谱 | 1 |
| 🤷 信号对·暂不处理 | 问题存在，主动选择不管 | 22 |
| ❌ 信号不该报 | 误报，噪音 | 4 |
| 🗑 这类信号没用 | 整个信号类型无价值 | 0 |

> 这 5 个按钮就是机器学习里的 **reward signal**——投手每次点一个按钮，就是在给 Agent 打标签。

### ⑥ Self-Evolve（本周要做——核心差异化）

不是微调模型，而是 **training-free** 方式：三个 markdown 文件，Agent 每次分析时自动加载，决策质量随时间提升。

**📄 memory.md（经验积累）**
```
- TEXT 类素材在 seekee 生命周期约 3-5 天，超过 5 天 CTR 普遍下降 40%+
- 葡语/西语市场的 KOL 素材 CPA 通常比中位数高 50-80%，但转化量充足 → 不急报高 CPA
- K-drama romcom 片段 CTR 最高，但转化率不如悬疑/动作类
```

**📄 product.md（产品深层理解）**
```
- seekee 是流媒体内容 App，目标用户：拉美 18-35 岁女性为主
- 用户决定下载前通常看至少 3 次广告 → 耐心，给素材时间
- 周末晚上 7-10 点转化最好 → 分析素材数据时注意时段因素
```

**📄 skill.md（可复用策略模块）**
```
- 素材疲劳检测：CTR 跌超 50% 且已投 30 天以上 → 直接建议暂停（采纳率 92%）
- 高 CPA 判断：高出中位 < 50% → WARN；> 100% → CRITICAL
- 冷启动保护：素材上线头 24h 数据不稳 → Gate 抑制不报
- KOL 素材特殊规则：CPA 高出中位数但转化量 > 同类均值 → 不报警
```

**闭环逻辑**：

```
投手给反馈 → 系统提取模式 → 更新三个 md 文件 →
Agent 下次加载这些文件 → 信号更准、建议更好 →
投手采纳率上升 → 正向循环
```

### ⑦ Proactive Agent（未来）

当某类信号采纳率够高（如素材疲劳 > 90%），Agent 从"建议暂停"升级为**自动暂停**——不等人确认，直接动作，观察数据变化作为 reward。

---

## 五、网站前端结构

```
左侧导航栏：
├── MVP          → 首页仪表盘（Health Monitor）
├── 看板          → Inbox：待处理 139 条 + 趋势 + 严重度分布
├── 信号          → Signal Stream：原始信号流 + Gate 降噪效果
├── 反馈          → Feedback History：所有投手采纳/误报记录
├── 助手          → AI 聊天：投手问"上周高 CPA 预警有哪些"
├── 定时任务       → run-checkup (每 6h) + propose-signal-disable (每天 8am)
├── /api/health   → 健康检查
└── 退出

底部状态栏：
├── DB 已连接 · asset_daily 125,134 rows
├── prd.md · tech.md · flow.md（项目文档入口）
├── Skill 库 — self-evolve 产物存储
├── 信号配置 — Rule 阈值参数调优
└── Measurement — 效果度量面板
```

---

## 六、一条 Issue 的完整生命周期（实例走通）

以素材 `342965287864` 为例：

```
1. Rule Engine 检测到：
   素材 342965287864（TEXT 素材），已投 49 天
   CTR 跌 51.9%，本周仍消耗 $305.6
   → 触发"素材疲劳"CRITICAL 信号

2. Gate 判断：
   该素材近期未被处理过（无 cooldown），未被 PAUSED
   → 落地为 issue，进入 Inbox

3. 投手看到这条 issue：
   摘要："TEXT素材投放 49 天，CTR 跌 51.9%，本周仍消耗 $305.6"
   状态：待处理

4. 投手给反馈：
   ┌──────────────────────────────────────────────────┐
   │ 暂停素材 → 效果回升 → ✅ 采纳了                      │
   │   → self-evolve：疲劳检测阈值有效                     │
   │     "TEXT 素材 49 天必疲劳"写进 memory.md             │
   ├──────────────────────────────────────────────────┤
   │ CTR 跌但转化还行 → 🤷 信号对·暂不处理                  │
   │   → self-evolve：补充 product.md                      │
   │     "某些 TEXT 素材 CTR 跌但转化稳定，别只看 CTR"      │
   ├──────────────────────────────────────────────────┤
   │ 素材其实已手动停 → ❌ 信号不该报 (误报)                 │
   │   → self-evolve：ingest 数据延时要修                    │
   │     "被 PAUSED 的素材应提前过滤" 写进 memory.md        │
   └──────────────────────────────────────────────────┘
```

---

## 七、一句话总结

**投流这件事**：花钱买用户，素材就是货架上的商品，需要不断换更好的。

**投手的困境**：货架太大了（几千商品同时上），眼睛不够用，经验在脑子里没法传。

**Ads Agent 做的事**：自动化拉数据 → 检测异常 → 过滤噪音 → 推给投手 → 收集反馈 → 自我改进。替代人"盯几千条曲线的眼睛"，只把最值得看的推到人面前。同时把人的每一次判断喂回系统，让系统越来越聪明。

**终极目标**：绝大部分投流决策不需要人——系统自己发现素材疲劳就自动换，发现高 CPA 就自动调。人只需定方向，系统自动执行优化。

---

# 下篇：技术尽调问题清单

## 一、Agent 框架与选型

**1. Agent 用的哪个 Harness / 框架？**

是自己写的，还是用开源框架（LangChain / LangGraph / CrewAI / AutoGen / Dify 等）？还是基于别人的产品二次开发（如 Claude Code SDK）？

> 看技术选型的成熟度和团队偏好。

**2. 助手里的 Agent 是自己搭建的，还是用别人的产品？**

截图助手页面显示 "Agent 只读 DB，可以查信号 / 素材 / 趋势 / 案例"。这个 Agent 从零搭建的还是基于某个平台/SDK？底层 LLM 用的什么模型（Claude / GPT / 开源）？为什么选这个？

**3. Agent 的 tool-use 机制怎么设计的？**

"查上周哪些 campaign 触发了高 CPA 预警"——这个问题需要 NL→SQL。是自己写的 prompt 转 SQL，还是用了成熟的 Text-to-SQL 框架（如 Vanna.ai、Dataherald）？

**4. Agent 的上下文管理怎么处理？**

未来要加载 memory.md + product.md + skill.md + 实际数据，上下文会很大。有没有做 RAG / 分段加载 / Prompt Caching？

**5. Agent 的权限边界在哪？**

"Agent 只读 DB"——是特意限制只读还是有写能力但没开放？proactive agent 未来要自动暂停素材，权限模型怎么设计？

---

## 二、数据管线（Ingestion & Pipeline）

**6. ingest-google-ads 为什么挂了？稳定性如何？**

截图显示 `❌ ingest-google-ads failed`，上次拉取 1 天前。是偶发还是经常？有没有 retry + alert 机制？失败后的数据回填策略？

**7. Google Ads API 的 rate limit 怎么处理？**

两个账号、几千条素材的 daily granularity 数据，拉取策略是什么？有没有做增量拉取还是每次全量？如果 API 调超额了怎么降级？

**8. 数据库选型和扩展性？**

asset_daily 目前 125K 行——用什么数据库？日均增量多少？如果客户从 1 个变成 10 个，数据库能撑住吗？

---

## 三、信号检测（Rule Engine）

**9. 6 种信号类型的阈值是怎么定的？**

"高 CPA"判断标准是 "7日 CPA 高出同类中位数 N%"，这个 N% 是谁定的？拍脑袋还是从历史数据分布反推（如按 P95 定 CRITICAL）？

**10. "同类中位数"——"同类"是怎么定义的？**

同素材类型（TEXT vs VIDEO）？同 campaign？同市场（西语 vs 葡语）？粒度不同效果差别很大。截图里 KOL 素材被建议观察——说明可能划了"KOL"作为独立类。

**11. Overlapping Rules 怎么处理？**

一条素材既触发"素材疲劳"又触发"高 CPA"——两个信号合并还是各自报？有没有做 priority / grouping 避免 spamming 投手？

**12. 有没有做回测验证？**

用历史已标注数据（反馈过的 issue）回测 Rule Engine 的准确率/召回率？误报率（当前 533 条里 4 条被标误报）真实吗？

---

## 四、降噪（Gate）

**13. Gate 的抑制逻辑具体实现了哪些规则？**

高 CPA 落地率只有 33%（882 → 288），被吞的 594 条具体是什么规则抑制的？cooldown 窗口多长？重复定义的粒度（素材级还是系列级）？

**14. "自动消化 176 条"——判断标准是否安全？**

自动关闭的条件是什么？如果只是"素材被 PAUSED"就关，投手自己暂停的怎么区分？有没有误消化的风险（把需要人工判断的也自动关了）？

**15. 降噪效果有没有量化评估？**

能不能回答"被抑制的 594 条里，有多少是真正不需要投手看的，有多少是漏报"？

---

## 五、Self-Evolve（本周要做的最核心部分）

**16. memory.md / product.md / skill.md ——具体怎么写入？人工还是自动？**

这是最核心的问题：
- 如果是**投手手动写** → 那叫文档管理，不叫 self-evolve
- 如果是**从 feedback 数据自动提取模式并更新** → 那才是真正的自进化

自动提取怎么判断"足够多条 feedback 形成一个可靠模式"？

**17. 三个文件的格式和结构是谁设计的？**

是 prompt engineering 层面的设计（给 LLM 读的自然语言），还是结构化配置文件（给程序解析）？有没有 schema 约束？版本怎么管理（回滚怎么办）？

**18. 从 feedback 到调整阈值——有没有做 A/B 或离线验证？**

比如连续 3 条误报反馈 → 自动把某类素材的 CPA 阈值从 +100% 调成 +120%。调完之后怎么知道调对了？有没有用历史数据回测？

> 能答得上这个问题，说明真正在做 feedback-driven parameter optimization。

**19. training-free vs model evolving 的边界在哪？**

哪些靠改 md 文件，哪些需要微调模型？什么条件触发从 training-free 升级到 model evolving？微调的数据（成对的 prompt-completion）怎么构造？

**20. 之前在别的项目里做过类似的 training-free evolving 吗？**

PRD 说"其他部分都收敛了，本周把 self-evolve 加入进去"——说明还没做。团队有没有在别的项目里验证过这套方案？

---

## 六、定时任务 & Proactive Agent

**21. 定时任务的调度是怎么实现的？**

截图里看到 node-cron + 容器重启后从 DB 恢复。是单机 cron 还是分布式？有没有 lock 机制防重跑（多副本同时启动）？

**22. Proactive Agent 的自动操作权限和兜底？**

未来 Agent 自动暂停素材，安全边界：哪些操作需要人工确认？确认超时了怎么兜底？误操作了怎么回滚？

**23. propose-signal-disable（每天 8am）的具体逻辑？**

"信号禁用提案"是 Agent 基于反馈数据自动提议"关闭某些没用的信号类型"，还是投手手动配置？

---

## 七、多租户 & Self-Host

**24. 多租户隔离怎么做的？**

seekee 和 PRD 里提到的"B2B 外贸客户"用的是同一套系统吗？DB 层面是同一库不同 schema，还是独立实例？权限隔离怎么做？

**25. Self-host 部署方案是什么？**

"外贸客户要求 self-host，这种我们会把 model evolving 也加入进去"。Self-host 的完整技术栈（Docker Compose / K8s / 裸机）？谁来维护和升级？

**26. 不同客户的信号规则是共享的还是独立的？**

比如 seekee 的经验（"KOL 素材 CPA 高是正常的"）会不会被错误地迁移到外贸客户？跨租户的 knowledge transfer 怎么做的？

---

## 八、团队 & 工程能力

**27. 这个项目投入了多少人？做了多久？创始人的技术背景？**

MVP 做成这样（有 UI、有 DB、有 Rule Engine、有 Gate、有 Feedback Loop、有 Agent），是几个人、多长时间做的？主力是工程师出身还是产品/运营出身？

> 判断工程资源是否能匹配 PRD 里画的技术蓝图。

**28. 测试覆盖怎么样？**

Rule Engine 的 6 种信号检测有没有单元测试？Gate 降噪逻辑有没有用历史数据做回归测试？从 22 条"信号对·暂不处理"到 4 条"信号不该报"，误报率和漏报率有没有被追踪？

**29. 代码是开源的还是闭源的？**

如果闭源，有 open-core 计划吗？Infra 层面用了哪些开源组件？

---

## 优先必问的 7 个问题

如果时间有限，这 7 个问题最能判断技术水平：

| # | 问题 | 为什么重要 |
|---|---|---|
| 1 | Agent 用哪个 Harness？自己搭还是用开源/别人的产品？ | 判断技术自主性 |
| 2 | Self-evolve 的三个 md 文件怎么从 feedback 数据自动更新？ | 最核心差异化 |
| 3 | Rule 阈值怎么定的，有没有从数据反推？ | 看分析能力 |
| 4 | 高 CPA 落地率只有 33%，被抑制的信号具体怎么被抑制的？ | 看工程功力 |
| 5 | Agent NL→SQL 是自己写的还是套框架？什么模型？ | 看 LLM 理解深度 |
| 6 | 从 feedback 到调阈值有没有做回测验证？ | 看方法论严谨度 |
| 7 | 团队几个人做了多久？创始人技术背景？ | 看资源匹配度 |

---

*文档完*