r/PPC 上有一条帖，向那些真的把 AI 工具接上客户账户写权限的人问了四个问题：它做错了什么、你怎么做治理、它真的省下工时了吗、六十天后你关掉了哪些功能。回答汇到了一个比工具推荐有用得多的东西——一份控制项清单。
这就是那份清单，写成你可以拿去要求任何一家厂商的样子，包括我们。
七项控制
1. 给建议之前先重新读一遍
拿十分钟前加载的数据做计划的 Agent，会自信地对一个已经不存在的状态动手。大家最常报告的失败不是「决策差」，而是自信地用了错输入：API 文档里有那个字段，但在它刚好查的那个接口上返回 undefined，然后被静默当成零。要求：支撑这次改动的读取，必须发生在同一轮里。
2. 写入前给 diff，不是给描述
Agent 的叙述不是证据。「我会把表现差的那几个降出价」是一句话；3 个定向的出价 1.40 → 0.95 是一个 diff。只有后者能被审阅。
3. 爆炸半径上限
最贵的失败很少是「一次改错」，而是「一次改错被施加在四百个对象上」。要求单次调用有硬上限，并且在调用前校验——不是靠叮嘱模型「小心一点」。
4. 人工确认只用在实质性变更上
什么都要确认，结果就是把你训练成什么都直接点过去；两个月后你得到一个不再起审批作用的弹窗。这道闸必须能区分「可逆的编辑」和「动钱」。
5. 分级归宿主，不归工具
如果一个动作的风险等级来自工具自己的描述，那么任何能写描述的人都能给自己降级。一个自称「只是改个小设置」的工具，不应该能靠措辞绕开审批。未知或自定义动作应该默认落到「敏感」，而不是「安全」。
6. 一份能交给客户的审计记录
问题不是「某处有没有日志」，而是「人家要的时候，你能不能拿出一份不可篡改的『谁在什么时间改了什么』」。产品遥测不算。
7. 回滚路径，在需要之前就建好
每个有后果的动作都应该带一把键，能找到并回滚它所属的那一批。出事之后才开始想怎么撤，就是一个糟糕的小时变成一个糟糕的星期的方式。
这些闸都拦不住的那种失败
上面每一项管的都是执行。diff 告诉你改了什么，日志告诉你谁和何时，回滚把它撤掉。但它们都不能把「对的建议」和「错的建议」分开——两者进来时长得一模一样，而错的那个往往论证得更漂亮。
有一个被广泛转发的例子：一位卖家原本 ROAS 健康地做到 3.5–4x，听信模型去重构广告结构，结果亏了钱。最高赞的回复说清了原因：模型不知道你的库存位置、合约约束和账户历史。另一条评论说得更直：它们不知道怎么在两个都对的选项之间做选择。找规律是这些模型真正强的地方，在两个都站得住脚的策略之间做决定不是。
第二种拦不住的是反复横跳：用三天数据抬价，两天后又砍下去，定向永远得不到一个稳定读数。规模化跑这套的人会强制每个定向 5–7 天冷却期，并表示这比换任何模型都管用。
Orkas 目前覆盖到哪里
Orkas 是一个本地优先的多 Agent 桌面应用。它的电商连接器——Shopify、Amazon Seller Central、eBay、Etsy、TikTok Shop、Shopee、WooCommerce、Walmart 等——都走宿主持有的策略层。下面八项已实现，四项没有。我们宁可你在这里知道，而不是在一次错误写入之后。
| 控制项 | 状态 | 实际存在的东西 |
|---|---|---|
| 四档动作风险分级 | ✅ | 每个连接器动作都是 R / W / H / D——读、写、高影响、破坏性 |
| 写入前预览 | ✅ | 写操作带预览确认，不会直接发出 |
| 涉钱变更要重新确认 | ✅ | 高影响动作被标为外部或财务变更，必须重新确认 |
| 爆炸半径上限 | ✅ | 单次调用能碰多少个对象有硬上限，执行前校验 |
| 纯只读连接 | ✅ | 连接器可以被限制在列能力、描述动作和读取 |
| 分级由宿主判定 | ✅ | 风险来自宿主的固定表，按动作的精确身份匹配；工具自述不能括大信任 |
| 未知动作默认从严 | ✅ | 未分类动作按高影响处理；没有可信策略的电商动作直接拒绝，不执行 |
| 产品边界硬屏蔽清单 | ✅ | 一份固定清单，无论授予什么权限都不暴露 |
| 按动词分权（创建 / 编辑 / 暂停 分开） | ❌ | 权限按风险等级分档，不是按动词拆开 |
| 金额级 spend cap 或预算变动上限 | ❌ | 上限是对象数量，不是金额 |
| 回滚路径 | ❌ | 未实现。回滚一批需要手工 |
| 可导出的不可变审计日志 | ❌ | 连接器调用有遥测埋点，但那不是能交给客户的审计记录 |
如果最后四项是你的硬要求——最常见的情形是你在替客户管广告账户，而客户随时可以要审计——那 Orkas 今天不满足，你应该在每一笔写入上都留人。
另一条路：干脆不要写权限
很大一部分工作的重点不是写，是分析。把报表导出来，放进本地工作区，让 Agent 读。不需要开发者应用，不需要排审核队，回路里不出现带写权限的凭证。而且这恰好是在交出任何不可逆的东西之前，最快弄清楚「它对我有没有用」的办法。两个现成例子：把供应商追踪号和订单对账，以及周度店铺复盘的场景页。
为什么这件事难买多于难做
平台 API 通常是免费的，门槛是审批而不是价格。亚马逊自己的 Ads MCP server 要求你有生效中的 Ads API 凭证；Shopify 要求一个与店铺同组织的商家自建应用；TikTok Shop 要求一个通过卖家开发者审核的 Custom App；eBay 要求 Developers Program 的正式环境 keyset 和你自己的签名密钥。对一个单干的卖家来说，这每一项都是一个项目，不是一个表单——这就是为什么那么多人走导出路线，从来没接过任何东西。那是个合理的选择，任何值得用的工具也应该在那个模式下好用。