千川几百户自动投放系统方案：总账户 API + LLM 分析（附不走 API 的浏览器自动化版）

如果你手里是巨量千川的总账户（管家 / 纵横组织账户），一次授权就能看到名下所有下级户——几百户的量级，靠人眼一个个盯盘、调价、关停，是绝对扛不住的。

这篇讲怎么搭一套「自动拉数 → LLM 分析出策略（不只是死规则）→ 人审 / 自动执行 → 跨户看板」的系统，让几百户的监控和调优能规模化、可解释、不黑盒乱烧钱。

文章同时覆盖两条技术路线：

A 路 · 官方 API 版——规模化首选、合规、可自动执行。
B 路 · 纯浏览器自动化版——免对公认证、快起，但有明显天花板。

文末给「谁适合走哪条」的取舍建议。

调研来源：巨量引擎商业开放平台官方文档、巨量学、CSDN / 知乎实操贴、第三方工具官网、学术论文（RTBAgent / DARA）、IAB Agentic RTB Framework。凡标 【需核实】 = 官方未公开或随政策变动，落地前要找官方 / 服务商确认。

一句话结论

把几百户的「盯盘 + 调优」做成一条流水线：

官方 API 把数据规模化拉回来 → 用「便宜模型批量筛 + 贵模型深析」两级 LLM 把人眼盯不过来的几百户压缩成「少数几个真需要动手的户 + 每户带理由的建议」→ 人审为主、小范围自动为辅地执行 → 全程留审计可回滚。

核心不是「让 AI 替你花钱」，而是「让 AI 替你看盘、替你写诊断报告、替你拟好动作，钱怎么动由边界和人把关」。这条边界（哪些自动、哪些必须人点头）是整套系统的安全阀。

一、整体架构

1.1 分层总览

┌─────────────────────────────────────────────────────────────┐
│  L5  看板 & 告警层                                            │
│      跨户大盘 / 异常红榜 / 决策待办 / 飞书·企业微信推送 / 复盘 │
├─────────────────────────────────────────────────────────────┤
│  L4  执行层（安全阀在这）                                     │
│      策略 → [人审队列 | 自动执行]（按边界分流）               │
│      → 调 API 落地 → 审计台账 → 可回滚                        │
├─────────────────────────────────────────────────────────────┤
│  L3  LLM 分析/决策层  ★重点★                                 │
│      两级模型：便宜模型批量初筛 → 贵模型深度诊断              │
│      输出：结构化策略 JSON（每户/每计划 action+参数+理由+置信+风险）│
├─────────────────────────────────────────────────────────────┤
│  L2  特征 & 异常预筛层（省钱关键）                            │
│      指标计算（ROI/成本/消耗趋势/同环比）+ 规则预筛           │
│      把"正常户"挡掉，只把"待决策户"送进 LLM                   │
├─────────────────────────────────────────────────────────────┤
│  L1  数据层                                                   │
│      定时拉报表（账户/计划/创意/素材/直播间）→ 限流队列 → 落库│
├─────────────────────────────────────────────────────────────┤
│  L0  接入/授权层                                              │
│      管家账户 OAuth 一次授权 → 子账户列表同步 → token 管理    │
└─────────────────────────────────────────────────────────────┘

1.2 数据怎么流（一个轮询周期）

L0 用管家账户的 token，拉「管家账户下广告主列表」，拿到几百个子户 ID（增量同步，新户自动纳管）。
L1 调度器按错峰节奏，对每个子户拉计划级 / 账户级报表，经令牌桶限速、队列削峰后落库（时序表 + 关系表）。
L2 对每户算衍生指标（ROI、转化成本、消耗速度、同比环比、素材衰退），用规则预筛把「平稳达标」的户过滤掉——这一步把几百户压到「真正异常 / 边缘的几十户」。
L3 只对这几十户喂数据给 LLM：先便宜模型批量分诊（紧急 / 观察 / 正常），再对「紧急 + 边缘」户用贵模型深析，产出结构化策略（每户该调价 / 关停 / 追投，带理由 + 置信度 + 预估影响 + 风险）。
L4 策略按「边界规则」分流：在自动区间内的（如小幅降预算、关停明确亏损素材）走自动执行；越界的（大额调价、整户停投）进人审队列等人点头。执行即写审计台账，支持回滚。
L5 一切沉淀进跨户看板 + 告警：异常红榜推到飞书 / 企业微信，一眼看清「哪些户在烧钱、系统替我做了啥、哪些等我拍板」。

1.3 关键设计原则

LLM 只在「值得想」的地方花算力——L2 预筛是省钱命门，几百户不能每户都喂大模型。
决策与执行解耦——LLM 只产出「建议 JSON」，执行层独立校验边界后才动手。LLM 永远碰不到「直接花钱」的按钮，中间隔着一道边界闸。
一切可解释、可审计、可回滚——每个动作都带「为什么 + 改前值 + 改后值 + 谁批的」，烧错钱能查能退。
顺应「全域推广」大势（见第六节）——重心放监控 / 告警 / 异常关停 / 批量建 / 跨户看板，别死磕逐计划手动微调出价（这块官方 AI 在接管）。

二、管家账户 API：一次授权管所有下级户

2.1 管家账户在巨量体系里是什么

巨量开放平台账户角色分四类（接口里 role / 账户类型字段）：

类型	角色	说明
1	普通广告主	单个投放户
2	纵横组织（管家账户）	批量纳管自己名下一批广告主户
3	一级代理商	代理商体系
4	二级代理商	代理商体系

几百户场景对应的就是 纵横组织 / 管家账户（巨量纵横）。它的价值就是：一次授权，拿到名下所有子户的访问权，不用每个子户单独授权——这正是几百户能规模化的前提。

2.2 一次授权拿到所有子户（核心链路）

建应用：开放平台用对公主体注册，创建「千川应用」，拿 APP_ID + Secret，勾权限点（数据报表 + 广告管理 / 出价预算状态 等），提交审核（约 48 小时）。
管家账户 OAuth 授权：用管家账户登录授权页 → 拿 auth_code（有效期约 10 分钟，过期作废）→ 用 auth_code + APP_ID + Secret 换 access_token + refresh_token。
拉子户列表：用管家 token 调「查询管家账户下广告主列表 / 广告主列表（纵横组织）」接口，一次性拿回名下全部子户 advertiser_id。这是「一次授权管所有户」的关键接口。
以子户身份调接口：后续拉报表 / 调出价预算，带上目标 advertiser_id + 管家 token 即可操作对应子户（在已授权范围内）。

✅ 因为这几百户都在自己的管家账户下，走的是「自有户 + 管家一次授权」，不需要服务商那档 50 万注资资质——只要对公认证建应用即可，门槛低很多。这是「自有户」场景相对「代管他人户」最大的优势。

2.3 Token 管理（几百户也只管 1～少数几个管家 token）

巨大简化点：管家账户模式下，不用管几百个子户 token——主要管「管家账户这一个（或少数几个）token」，靠它操作所有子户。token 数量从「几百」降到「个位数」，运维负担骤降。
refresh_token 有效期约 1 个月，持续运行中大约每天会刷新数次（实测约 5 次 / 天会触发刷新），刷新后旧的立即失效——必须有调度自动续期 + 持久化最新 token，单点丢失会导致整批瘫痪。
token 落库加密存储，刷新逻辑加锁防并发覆盖，失败要告警（这是系统单点，挂了全停）。

2.4 资质门槛

场景	资质要求
管自己 / 自己公司名下的户（管家账户）	对公认证 + 建应用即可，门槛低
帮别人（客户）代管户	基本要服务商 / 代理商资质（独立法人、成立满 1 年、注册资金 50 万 +【需核实最新版】）

一句话：管自有户门槛低，代管他人户才撞资质硬墙。 走系统前先确认自己属于哪一档。

2.5 限流 / 频控应对（几百户最大工程坑）

几百户 × 每户多计划 × 每周期轮询 = 请求量巨大，不做限流必被拒。官方限流是两层：① 单开发者对单接口 + ② 该接口所有开发者总量。应对：

令牌桶限速：客户端每秒发 N 个 token，没 token 就排队重试（官方推荐做法）。
队列削峰 + 错峰轮询：避开整点高峰（官方明确点名 12:00、12:30 这种半点别打），几百户分批错峰，不要同一秒齐发。
报表接口优化：用更小的 page_size、加 filter 条件减少返回量、历史大数据走异步任务接口而不是同步轮询。
重试 + 退避：失败指数退避重试，区分「限流（可重试）」vs「授权失效（要重授权）」。
配额自查：具体 QPS 官方按接口不同、未统一公开，建应用后在控制台看自己接口配额【需核实】，按实际配额定轮询频率。

三、数据层：拉什么、多频、怎么存

3.1 拉哪些指标（按层级）

层级	关键指标	用途
账户级	当日消耗、余额、整体 ROI / ROAS、总转化、转化成本	跨户大盘、余额预警、整户异常
计划 / 广告级	消耗、展示、点击、CTR、转化数、转化成本、ROI、出价、预算、投放状态	决策主战场——调价 / 关停 / 追投都在这层
创意 / 素材级	素材消耗、CTR、完播、转化、素材新鲜度 / 衰退	关停低质素材、识别爆款素材
直播间级（直播带货户）	在线人数、GPM、转化、停留	直播投放实时调控
商品级	单品 ROI、动销	选品 / 追投判断

重点抓「钱（消耗 / 预算 / 余额）+ 效（ROI / 转化成本）+ 状态（投放中 / 暂停 / 受限）+ 趋势（同环比 / 衰退）」四类，足够支撑 LLM 决策。

3.2 拉数频率（分级轮询，平衡时效与限流）

高频（5～15 分钟）：在投计划的核心指标（消耗、ROI、转化成本、状态）——用于异常关停 / 防超支这种要快的。
中频（30～60 分钟）：素材级、直播间级。
低频（每日 / 收盘）：账户级汇总、历史报表、复盘数据（走异步接口）。
事件触发：余额低于阈值、消耗突增、ROI 崩盘 → 立即拉一次 + 告警，不等下一轮。

频率受限流硬约束：几百户做不到全部 1 分钟级。务实做法——核心户 / 大消耗户高频，长尾小户低频，把有限的 QPS 配额花在刀刃上。

3.3 存储设计

时序库（指标随时间）：每户 / 每计划的指标按时间点落表，支持趋势、同环比、回看。选型 ClickHouse / TimescaleDB（量大）或 Postgres 时序表（中等量够用）。
关系库（结构 & 台账）：账户-计划-创意-素材层级关系、token 表、调整审计台账、人审队列、策略历史。Postgres。
缓存：Redis 做限流令牌桶、token 缓存、轮询调度状态、热数据。
冷归档：历史明细归对象存储，复盘按需捞。

台账是合规与回滚的命根：每次调整记录 户 / 计划 + 动作 + 改前值 + 改后值 + 触发原因 + LLM 理由 + 谁批准 + 时间戳，一条都不能少。

四、★重点★ LLM 分析层：怎么给「可解释策略」、几百户怎么控成本、怎么防黑盒乱调钱

这是整套系统的灵魂，也是它和「死规则工具」「官方黑盒托管」的差异化所在。拆成四块讲。

4.1 怎么喂数据给 LLM

LLM 不是直接吞原始报表，要先做「结构化 + 上下文打包」。

把一个户喂给 LLM 时，打包成一份它能读懂的「病历」——也就是单户决策包（Decision Packet）：

户基本盘：行业 / 品类、目标 ROI、日预算、当前余额。
当前关键指标 + 趋势：今天 vs 昨天 vs 7 日均值，环比涨跌。
计划级明细表：Top N 个在投计划的消耗 / ROI / 转化成本 / 出价 / 状态。
素材衰退信号：哪些素材 CTR 在掉、消耗在缩。
历史动作记忆：这户最近做过哪些调整、效果如何（防 LLM 反复横跳乱调）。
约束条件：调价 / 预算的允许幅度、红线（见 4.4）。

格式上用紧凑的 Markdown 表 / JSON，不堆原始字段，只给决策相关的，省 token。再给 LLM「同类户的中位表现」做横向锚，让它判断「这户是真差还是行业普遍差」。

4.2 Prompt 设计：逼出「可解释、可执行」的结构化策略

核心是强制结构化输出 + 强制给理由 + 强制给置信度和风险，杜绝「我觉得调一下」这种含糊。

System prompt 要点（角色 + 纪律）：

你是资深千川投手，目标是在「目标 ROI / 预算约束」下让这户跑得更好。
你只能在给定的「允许动作 + 允许幅度」里出建议，不得越界。
每条建议必须给：动作、具体参数、理由（基于哪个指标 / 趋势）、置信度、预估影响、风险与回滚条件。
拿不准就建议「观察」或「转人审」，不许硬调。宁可不动，不可乱动。

强制输出 JSON Schema（执行层直接消费）：

{
  "advertiser_id": "123",
  "overall_diagnosis": "整户ROI达标但素材A严重衰退拖累，计划#5超成本",
  "urgency": "high | medium | low",
  "actions": [
    {
      "target": "campaign#5",
      "action": "decrease_budget | increase_budget | adjust_bid | pause | enable | pause_material | observe | escalate_to_human",
      "param": {"from": 800, "to": 500, "unit": "元/日"},
      "reason": "转化成本连续3小时高于目标30%，消耗占比过大",
      "evidence_metrics": ["转化成本=45(目标35)", "消耗占比=40%", "ROI=0.8"],
      "confidence": 0.82,
      "expected_effect": "止损，预计日省300元无效消耗",
      "risk": "可能错杀正在起量的计划",
      "rollback_condition": "若关停后整户消耗骤降>50%则恢复"
    }
  ]
}

关键：reason + evidence_metrics 让每个动作都能追溯到数据，这就是「可解释策略」——人审一看就懂「为什么动这户、凭什么」，而不是黑盒甩给你一个调整。这也是对「全域推广黑盒托管」的正面回答：官方托管不告诉你为什么，这套告诉你为什么。

4.3 几百户成本控制：两级模型「便宜筛 + 贵深析」

几百户每户都上贵模型 = token 成本爆炸。用漏斗式分级把贵算力只花在该花的户：

几百户
  │  L2 规则预筛（不花LLM钱）：平稳达标的直接放行
  ▼
 几十户（异常/边缘）
  │  ① 便宜模型批量分诊（如 Haiku 级）：每户一句话判「紧急/观察/正常」
  ▼
 十几户（紧急+边缘）
  │  ② 贵模型深度诊断（如 Opus 级）：出完整结构化策略 + 理由
  ▼
 少数户的高质量可执行策略

第 0 级（不花钱）：L2 规则预筛先砍掉「平稳达标」的大多数户。
第 1 级（便宜模型）：对剩下的几十户做批量粗筛分诊——便宜模型快速判紧急度、挑出真正要深想的。可一次喂多户做 batch。
第 2 级（贵模型）：只对「紧急 + 边缘难判」的十几户上贵模型，出带理由的完整策略。

省钱杠杆：

prompt 缓存：户的静态信息（行业 / 目标 / 约束）和 system prompt 走缓存，每轮只变动态指标。
批处理：粗筛阶段多户合并一次调用。
变化驱动：指标没明显变化的户跳过 LLM（缓存上轮结论）。
按户价值分配：大消耗户值得贵模型，长尾小户便宜模型甚至纯规则即可。

直觉量级：几百户里，每轮真正需要贵模型深析的可能就十几个。成本从「几百 × 贵」降到「十几 × 贵 + 几十 × 便宜」，是一两个数量级的差距。

4.4 防「黑盒乱调钱」：六道闸

LLM 会幻觉、会乱建议，绝不能让它直连花钱按钮。六道防线：

动作白名单：LLM 只能从枚举动作里选（调价 / 调预算 / 关停 / 观察 / 转人审），不能发明动作。
幅度硬约束：调价 / 预算单次变动有上限（如单次 ≤20%、日内累计 ≤50%），LLM 越界的建议执行层直接驳回。约束在代码里，不靠 LLM 自觉。
置信度门槛：confidence 低于阈值的建议一律转人审，不自动执行。
金额闸：涉及金额超过 X 元 / 单次预算超 Y 的动作，强制人审（见第五节）。
频率闸 + 反横跳：同一户 / 计划单位时间内调整次数封顶；带「历史动作记忆」防 LLM 把昨天加的今天又减回去来回烧钱。
执行层独立复核：LLM 出的 JSON，执行层用纯代码规则再校验一遍（参数合法、户状态允许、不违红线）才落地——LLM 提议，代码审批。

一句话：LLM 是「军师」不是「司令」。 它分析、它建议、它写理由；动钱的扳机由边界规则和人扣。这样既拿到 LLM 的策略灵活性，又不把钱袋子交给一个会幻觉的黑盒。

五、执行层：人审 vs 自动的边界、审计、回滚

5.1 自动 vs 人审的边界（系统安全阀）

按「风险 × 金额 × 置信度」三维划线：

动作类型	默认走	理由
关停明确亏损的低质素材（ROI≈0、纯烧钱）	✅ 可自动	止损方向、损失有限、可恢复
小幅降预算 / 降出价（≤阈值，止损方向）	✅ 可自动（高置信度）	风险低、防超支
加预算 / 加价（追投方向 = 主动花更多钱）	⚠️ 人审	花钱方向必须谨慎，易被 LLM 乐观误导
大幅调整（超幅度阈值）	⚠️ 人审	影响大
整户 / 整计划停投	⚠️ 人审	影响最大，可能误杀起量户
低置信度 / LLM 主动 escalate	⚠️ 人审	模型自己拿不准

行业共识（IAB、各大平台）也是这条线：LLM 可以加速「分析 / 拟单 / 报告」，但「花钱的扳机」默认要人点头，不交全自动。初期可以把线划得很保守，跑顺了再逐步放宽自动区间。

5.2 人审队列（让审批不累）

LLM 把待审动作**打包成「一条条带理由的待办」**推到看板 + 飞书 / 企业微信：「户 X 计划 #5 建议降预算 800→500，因为转化成本超标 30%，预计日省 300，[批准] / [驳回] / [改参数]」。
支持批量批准同类动作、一键全否、改参数后再批。
高频小动作可设「自动 + 事后通知」，大动作「事前审批」，减轻审批负担。

5.3 审计台账（合规 + 复盘命根）

每个动作落一条不可变记录：时间 / 户 / 计划 / 动作 / 改前值 / 改后值 / 触发指标 / LLM 理由 / 置信度 / 审批人（自动 or 人）/ 执行结果 / API 返回。

用途：出事可追责、效果可复盘、模型可迭代（用「动作 → 后续效果」回流优化 prompt）。

5.4 回滚

快照：每次调整前存「改前值」，一键回滚到改前。
熔断：监测到「调整后指标急剧恶化」（如关停后整户消耗崩、加价后成本飙）自动触发回滚 + 告警。
灰度：自动策略先在「几个测试户」上灰度验证，效果稳了再扩面（呼应第十节分阶段）。
一键全停：紧急情况能一键停掉所有自动执行，全转人工。

六、风控、合规、防封号

6.1 走官方 API = 低风险（A 路天然优势）

用官方 API 改自己（或已授权广告主） 的出价 / 预算 / 开关，这就是开放平台的用途，官方允许、风险低。这是 A 路相对 B 路（浏览器自动化）最大的安全优势。

6.2 发送 / 内容侧红线

不碰非官方自动化、不绕签名、不模拟登录（这些是 B 路的风险，A 路不沾）。
调整动作受幅度 / 频率闸约束，避免「异常高频操作」被平台风控盯上（即便走 API，畸高频率也可能触发风控【需核实】）。

6.3 数据安全

几百户数据 = 敏感商业数据，本地 / 私有部署，加密存储 token 与报表，权限最小化，操作留痕。机密级别等同核心业务数据，不外泄。

6.4 ⚠️ 最大政策风向（必须先搞清楚）

2025 年千川「推商品-标准推广」（手动精细投）已于 5 月 22 日起停止，强制切「全域推广」——平台在把投放推成「AI 黑盒智能托管 + 全域自动出价」，手动逐计划微调出价 / 预算的空间在收窄。
对本系统的含义：纯「几百户手动规则化精调出价」的价值会被官方 AI 部分取代。自动化重心应放在：
- ✅ 跨户监控 + 异常告警 + 异常关停（防烧钱，这个官方托管替代不了你的「跨户统一视角」）。
- ✅ 批量建计划 / 批量上新品 / 素材管理。
- ✅ 跨户大盘看板（「一眼看所有户」）。
- ✅ LLM 做**「全域推广跑得好不好」的诊断和目标 ROI 调参建议**，而不是替代它逐计划出价。

一句话：别和官方 AI 抢「逐计划出价」，去做它做不到的「跨几百户的统一监控、诊断、止损、批量、看板」。

七、纯浏览器自动化方案（不走 API）—— 免认证快起的路

有些团队没有对公资质、或者不想等审核，想「不走 API」。这条路用 Playwright / RPA 驱动千川网页后台，像真人一样点页面来批量监控 + 调整。能快速起步、免对公认证审核，但有明确天花板。如实讲。

7.1 怎么搭

驱动：Playwright（比 Selenium 稳、自带等待、多浏览器）。脚本打开千川 web 后台，定位页面元素（计划列表、出价框、预算框、开关按钮），程序化点击 / 填值 / 读数。
批量监控：脚本轮流登录各户后台 → 抓页面上的报表数字（或抓页面背后的 XHR 接口返回）→ 落本地库 → 比规则 → 标异常。
自动调：定位到目标计划，模拟人操作改出价 / 预算 / 点暂停，弹窗确认。
读数取巧：很多时候不用「肉眼解析 DOM」，可以直接抓网页自身发出的 XHR 数据接口返回的 JSON（页面已登录态，签名由浏览器自己生成），比硬解析表格稳——但这本质是「借网页的壳调它的私有接口」，仍属灰色。

7.2 几百户的登录态 / 多账号怎么管

storage_state 持久化：每个户登录一次，把 cookie / 登录态用 storage_state() 存成文件，下次直接加载复用，跳过重复登录（速度提升 5-10 倍，也少触发验证码 / 风控）。
BrowserContext 隔离：用独立 BrowserContext 给每个户隔离登录态，互不串。
登录态会过期：cookie 会失效，要有「检测失效 → 重新登录（可能撞验证码 / 扫码）」的重授权流程——几百个账号的登录态维护本身就是个大工程，且没有管家账户那种「一次授权管所有」的便利，每个户都要单独维护。
并发：浏览器实例重、吃内存 / CPU，几百户做不到高并发，得连接池 + 错峰串行，慢。

7.3 ⚠️ 几百户场景的真实限制（如实写，别美化）

维度	真实情况
速度	浏览器渲染 + 逐页点击，比 API 慢一两个数量级。几百户全跑一遍可能要很久，做不到分钟级实时。
稳定性	千川后台页面经常改版，一改版选择器全失效、脚本批量崩，维护成本高、三天两头修。
风控 / 封号风险	⚠️ 这是最大的雷。模拟登录 + 高频自动化操作 + 一套设备 / IP 操控大量账号，是平台风控重点打击对象，封号高危。单账号操作频率建议 <1 次 / 秒，几百户高频自动化极易被判异常。
验证码 / 扫码	登录态失效后重登可能撞验证码 / 扫码，自动化会被卡住，要人工介入。
合规	非官方授权的自动化操作，不在平台允许范围，出事平台不认、且可能违反用户协议。
资源	几百个浏览器上下文吃硬件，要么慢、要么堆机器。
能力边界	能做的仅限「网页后台有的操作」；批量能力远不如 API 的批量接口。

7.4 适合谁

✅ 没有对公资质 / 不想等审核 / 户数不多（十几到几十户）/ 先验证想法——B 路能快速起步看效果。
❌ 几百户规模化、要稳定要快要合规——B 路撑不住，迟早撞墙（慢 + 易崩 + 封号风险）。

八、API 版 vs 浏览器自动化版 · 对比表

维度	A 路 · 官方 API 版	B 路 · 浏览器自动化版
合规 / 风险	✅ 官方允许、低风险	⚠️ 灰色、封号高危
起步门槛	要对公认证 + 建应用 + 审核（约 48h）	✅ 免认证、马上能起
速度	✅ 快、可分钟级	❌ 慢一两个数量级
稳定性	✅ 接口稳定、版本化	❌ 页面改版即崩、常修
几百户规模化	✅ 管家一次授权管所有户、token 少	❌ 每户单独维护登录态、撑不住
批量能力	✅ 官方批量接口强	❌ 仅限网页能点的
限流	有 QPS 限流，要令牌桶（可控）	受风控频率限制（更死）
维护成本	中（接口变更跟进）	高（页面一改全崩 + 撞验证码）
验证码困扰	✅ 无	❌ 重登易撞、卡人工
数据完整度	✅ 官方多维报表全	仅网页可见的
适合规模	几十～几百＋户	十几～几十户

九、谁适合走哪条（取舍建议）

几百户、自己名下、管家账户、要规模化 → 坚定走 A 路（API 版）。

「自有户 + 管家账户」的场景，不需要服务商资质，门槛低，又有「一次授权管所有户 + token 数量少 + 合规 + 快 + 稳」的全部优势。几百户规模 B 路根本撑不住。这是没有悬念的选择。

户数不多、没资质、想先快速验证 → 可先走 B 路起步，但要知道天花板。

十几到几十户、先看效果，B 路免认证快起能用。但要如实认清：慢、页面改版易崩、封号有风险，一旦上量 / 要稳，必须迁回 A 路。

折中：B 路里只抓数据看板（监控告警）相对安全，自动改出价 / 关停这种「写操作」风险最高——可以「B 路只读监控 + 人工手动调」过渡，避开高频自动写操作的封号雷。

若是「帮客户代管」几百户 → 无论 A / B 都要面对资质问题，A 路需服务商资质（50 万注资那档），这是绕不过去的硬门槛，得先想清商业模式值不值。

一句话：自有户走 API，稳准快、合规、管家一授到底；没资质可以先拿浏览器自动化趟十几户看效果，但别拿它扛几百户，会崩会封。

十、技术栈 + 工作量估算

10.1 技术栈建议

层	选型
接入 / SDK	官方 SDK（`oceanengine/ad_open_sdk_go` / `_java`）或社区 `bububa/oceanengine`（含千川 UpdateBid / UpdateBudget / UpdateStatus + 报表，可直接抄）；无官方 Python SDK 则 HTTP 直调
后端	Python（FastAPI，配合 LLM 生态顺手）或 Go（并发拉数性能好）。建议 Python 为主（LLM 编排、prompt 工程方便）
调度	APScheduler / Celery / Temporal（分级轮询 + 错峰 + 重试）
限流	Redis 令牌桶
时序存储	ClickHouse / TimescaleDB（量大）或 Postgres 时序表（中等）
关系 / 台账	Postgres
缓存	Redis
LLM	两级：便宜模型（Haiku 级批量筛）+ 贵模型（Opus 级深析）；统一走结构化输出 + prompt 缓存
看板	Web 前端（React）或先用飞书多维表格 + 仪表盘快速起
告警	飞书机器人 / 企业微信
浏览器自动化（B 路）	Playwright（Python）+ storage_state 登录态持久化 + BrowserContext 隔离
部署	私有 / 本地部署（数据安全），Docker 化

10.2 分阶段落地（只读监控 → 小范围自动 → 全量）—— 这是降风险的核心节奏

阶段 0 · 趟路（1～2 周）

建应用、对公认证、管家账户 OAuth 跑通、拉到子户列表、跑通报表接口和限流。
产出：能稳定拉回几百户数据。首次趟路的未知坑（配额 / 授权 / 接口）在这阶段摸清。

阶段 1 · 只读监控看板（2～3 周）

L1 数据层 + L2 指标 / 异常预筛 + L5 看板 / 告警。先不碰任何自动写操作。
产出：跨户大盘 + 异常红榜 + 飞书 / 企业微信告警。光是「能一眼看所有户」就已经回本。 这阶段零风险。

阶段 2 · LLM 诊断（只建议不执行）（2～3 周）

接 L3 两级 LLM，出「带理由的策略建议」，只推人审队列、不自动执行。
产出：每天收到「哪些户要动、为什么、建议怎么动」，人工照着点。这阶段验证 LLM 策略质量、调 prompt、攒「建议 → 效果」数据。

阶段 3 · 小范围自动（边界最保守）（2～3 周）

只对几个测试户 + 最安全的动作（关停明确亏损素材、小幅止损降预算）开自动执行，全程审计 + 可回滚 + 熔断。
产出：验证自动执行链路安全，灰度观察效果。

阶段 4 · 逐步放宽 / 全量（持续）

效果稳了，逐步扩户、逐步放宽自动区间（但「花钱方向」长期保留人审）。持续用审计数据迭代 prompt 和边界。

10.3 工作量粗估【需核实，按实际团队调整】

阶段	人力（1～2 名后端 + 会调 prompt 的）	周期
0 趟路	1 人	1～2 周
1 只读看板	1～2 人	2～3 周
2 LLM 诊断	1～2 人	2～3 周
3 小范围自动	1～2 人	2～3 周
4 放宽 / 全量	持续维护 1 人	长期

MVP（阶段 0+1，能看盘能告警）≈ 1 个月、1～2 人就能用上。
完整带 LLM 自动调（到阶段 3）≈ 2.5～3 个月。
后续是接口变更跟进 + prompt 迭代的持续维护（建议留 1 人 part-time）。

务实建议：先把阶段 0+1+2 做出来（只读监控 + LLM 出建议人工执行），这部分零执行风险、价值最大、最快回本；自动执行（阶段 3+）等策略质量在阶段 2 被验证够稳了再开，且边界从最保守开始。别一上来就追求全自动——那是黑盒乱烧钱的根源。

附 · 关键事实速查（落地前要核实的）

【需核实】 服务商资质最新门槛（注册资金 / 成立年限）——走自有管家不涉及，但若代管他人户要确认。
【需核实】 各接口具体 QPS 配额——建应用后控制台看自己的。
【需核实】 第三方工具价位（千管家 / 创量 / 大爆单按户数阶梯收费，要问销售）——若想「先买现成跑通再自建」可对比。
【需核实】 全域推广最新政策细节（投放模式还在变，落地前看官方最新公告）。
【需核实】 千川 web 后台是否对自动化有明确风控声明（B 路封号风险量级）。

来源：巨量千川 M-API 实操（CSDN）、巨量千川授权流程（集简云）、千川多账户管理（巨量学）、自定义报表-数据报表（开放平台）、获取 Access Token-OAuth2.0（开放平台）、RTBAgent: LLM-based RTB Agent（arXiv）、DARA: LLM Budget Allocation（arXiv）、The ad industry won’t hand LLMs the keys（ppc.land）、Playwright 登录态持久化（CSDN）。