Agency 真正需要 AI 提供的，不是更多内容

我意识到自己在做错东西，是在我脑子里出现一个画面的时候：某个 agency owner 因为“10 秒生成 50 条 LinkedIn post ideas”而兴奋不已。

不是因为内容点子没用。不是的。

而是因为如果你真的在 agency 周围待过一点时间，你就知道，那根本不是这个工作的可怕部分。

真正可怕的是 trust。

是 account manager 在想，这个系统会不会不小心把 Client A 和 Client B 混在一起。

是 strategist 在想，“我能不能安全地把它用在一个竞争账户上？”

是 agency owner 在问一个远比任何 AI homepage 都不性感的问题：

如果这玩意儿把一个客户的 intelligence 泄露进另一个客户的工作里，会发生什么？

这个问题，远比“它能生成多少条 captions？”重要得多。

我觉得 AI 软件市场有很大一部分，仍然误解了 agency，因为它误解了 agency 真正的工作。Agency 的主要痛点不是缺词。他们真正承受的是复杂性：

• 多个 clients
• 多个 brands
• 多种内部角色
• 多层 approvals
• 多种版本的“谁可以看什么”

所以当一个 AI vendor 跑来说：“好消息，现在你们可以更快地产出更多内容了”，我内心的一部分会很想问一句：你真的坐进过 agency workflow 吗？

我做 STRAŦUM 越久，就越清楚：agency 首先需要的根本不是更多内容。

他们需要的是更好的 trust infrastructure。

Agency 的问题不是 volume，而是 risk

如果你曾经负责过真正有 stakes 的 client work，这一点会更容易理解。

当你只服务一个品牌时，事情简单得多。你的笔记就是你的笔记。你的 positioning work 只在一个 lane 里。你犯错照样会痛，但至少是局部的。

Agency 不是这样活的。

Agency 同时 juggling 的是：

• 不同的品牌语气
• 不同的品类
• 不同的审批链
• 不同的成功定义
• 甚至彼此可能直接竞争的 clients

这意味着，错误的成本并不只是“我们写出了一份平庸草稿”。

有时候，成本会是：

• 我们把错误的东西发给了错误的客户
• 我们在错误的 workspace 暴露了错误的 context
• 我们让平台整体显得不安全
• 客户开始怀疑，后台还有没有别的地方也一样草率

而一旦客户开始问起最后那个问题，你就已经进入很昂贵的区域了。

这就是为什么我会对那些几乎完全靠 output examples 来卖 agency AI 的方式保持怀疑。一个生成内容的 demo，只能证明模型能生成内容。可以。但对 agency 来说，更重要的证明其实是 architectural 的。

给我看：

• 数据到底在哪里
• client context 是怎么隔离的
• 谁能访问什么
• approvals 有没有 built in
• 一个客户的工作有没有可能污染另一个客户

这才是 agency 真正关心的产品故事，即便它远没有 launch video 里那么好看。

我觉得我的广告背景让这件事更快地变得明显

也许是因为我来自广告行业，我从一开始就不太相信“content is the bottleneck”这套说法适用于 agency。

别误会，agency 当然会生产内容。很多很多内容。是的，那里面也的确存在效率提升空间。

但 agency 工作之所以难，通常并不是因为缺少第一稿。

真正难的是草稿周围的 operating environment。

谁看过它？ 这是给哪个客户的？ 什么 context 塑造了这个 recommendation？ 它是不是在正确的 brand constraints 下生成的？ 有没有人不小心复用了错误的 assumptions？ 谁有权批准它？

如果你在 in-house，这些问题也许只是一部分重要。

如果你在 agency，这些问题每天都全部重要。

所以我在 STRAŦUM 很早的时候做了一个当时看来有点离谱的决定：我几乎一开始就在做 multi-tenancy。基本上 Day 2。现在回头看，那到底算 disciplined 还是有点疯，要看你愿不愿意善意一点理解我。

当时我只有一个勉强能工作的 agent。那个阶段就做 client isolation，看起来确实像时机过早。

但结果证明它是对的。

因为一旦你真的看清 agency，就会发现它们不是“用户更多一点的 SME”。它们的 operating model 根本就是另一种东西。

我意识到 org_id 根本救不了我的那一天

我的第一版 multi-tenancy，是一种非常典型的乐观 builder 写法。

给所有东西都加上 org_id。 写好 policies。 相信 filters。 然后告诉自己问题解决了。

这种做法在很多软件里都能勉强成立。它也会给你一种很安慰的幻觉：你以为自己解决的是 isolation，实际上你解决的只是 basic scoping。

对 STRAŦUM 来说，这远远不够。

因为 agency 不只有一个 organization layer。他们还有 organization 下面的 clients。而每一个 client 都需要属于自己的 context、outputs、history 和 safety boundaries。

也就是说，我当时是在强行把两种完全不同的数据模型塞进一个 mental shortcut 里：

• SME: 一个 org，一个 business context
• Agency: 一个 org，下面挂着多个 client contexts

这件事你可以先靠 application logic 硬撑一阵子。很多人都是这么做的。但我看得越久，就越意识到我正在搭一个“看起来好像对、结构上却过度信任”的系统。

这是个很糟糕的组合。

最后只能重建。Separate routing。Separate schema logic。在数据库层做更多 guardrails。更明确的 context handling。更少那种“大家记得 everywhere 都 filter 对就好”的侥幸。

烦吗？很烦。

值得吗？也很值得。

不过说实话 — 即使重建之后，几周后我又发现了另一个漏洞：被分配给特定 client 的用户，仍然可以通过另一个 query path 看到其他 client 的数据。架构是变好了，但还不完整。我至今仍无法完全确信它已经滴水不漏。

因为 agency 的 trust，不应该建立在某个开发者晚上 11:30 还记得每一个 if/else branch 的基础上。

AI 会把 trust problem 变得更糟，而不是更好

这就是我觉得整个类别直到现在都说得不够重的一点。

AI 不是 agency workflow 上多加的一层 UI。它改变的是风险结构，因为现在系统不只是储存 context，它还能综合它。

这很强大。

也正因此，边界一旦做差，就完全不可接受。

如果一个 AI 系统拿到了错误的 context，它不只是暴露 raw data。它会 remix 它。它会悄悄让 Client A 的 insights 影响 Client B 的 strategy。它会把 isolation mistakes 变成 polished-looking outputs。说实话，这比明显的 bug 更糟，因为更难被发现。

这也是为什么，当人们开始在多个 accounts 之间随意使用通用 AI 工具时，我会对 agency 环境特别不安。

你也许可以侥幸用一阵子。

然后某一天，有人会觉得那些措辞听起来很眼熟。

或者某个 recommendation 里出现了本来不该出现在那个 workspace 的 competitor framework。

或者客户看到某些东西之后，开始怀疑你们的系统到底有没有 compartmentalized。

而一旦这种怀疑进入关系里，你修复的就不是 content workflow 了。

你是在修 belief。

祝你好运，想靠几条额外 blog captions 把这个问题补回去。

Agency 真正更需要的是什么

如果把所有 AI theater 都剥掉，我觉得 agency 现在更急需的是一些并不 glamorous 的东西：

1. Client-safe 的 context isolation

不是简单的 account switching。

不是简单的 folders。

也不是“we take privacy seriously”这种 copy。

而是真正的分隔 — 在数据库层面，不是在应用层面。我说的是独立的 schema 或独立的 routing，而不是一张共享表加一个 client_id 列，然后祈祷每个 query 都能正确过滤。

2. Role-aware 的权限

不同的人，需要不同层级的 access：

• strategist
• account manager
• approver
• client stakeholder
• admin

如果没有这个，工具在 demo 里会显得“很 collaborative”，到了现实里只会变成 chaos。

3. Approval workflows

Agency 不是那种把想法直接往外扔的 solo creator。这里有 drafts、comments、reviews、approvals、revisions，还有 politics。很多 politics :P

如果 AI 系统不尊重这些，它就是不尊重 agency work。

4. 在正确边界内共享 memory

这一点非常重要。

在某个具体 client context 内，系统当然应该随着时间变得更聪明。这才是 AI 真正有用的地方。但这种复利必须发生在正确的 fence 里，而不是无差别地跨越所有工作一起增长。

5. 执行之前的 strategic intelligence

再次强调，我不是 anti-content。我只是反对把 content-first 当成全部故事。

Agency 真正需要帮助理解的是：

• 客户到底该说什么
• 客户到底该强调什么
• 竞争环境里发生了什么
• strategy 的薄弱点在哪里
• 怎么让团队围绕一个 recommendation 对齐

这些东西，比再生成一大堆 generic deliverables 有价值得多。

这也是为什么 STRAŦUM 最后长成了现在这个样子

很多 STRAŦUM 的产品决定，放在这个视角下就会更好理解。

为什么是 progressive learning？

因为 agency 已经在重复 context 上花了太多时间。

为什么是 multi-tenant routing？

因为 client context 不能只是一个“温柔建议”。

为什么有 approvals 和 collaboration？

因为 agency work 不是一个人坐在那里和 bot 聊天。

为什么聚焦 intelligence over execution？

因为 agency 通常不是靠制造更多噪音来获得回报的。它们获得回报，是因为它们能为客户创造 confidence、direction 和更好的 decisions。

这才是我想为他们做的 AI 产品。

不是那个说“看，你们能更快 churn 更多东西了”的产品。

而是那个说“看，你们的战略工作可以变得更安全、更锋利”的产品。

我不是说我把这一切都做对了。我是说这些问题迫使我做出了特定的架构决策，而大多数通用 AI 工具还没有不得不做出这些决策 — 或者还没有选择去做。

有件事，我真希望更多 AI vendors 能坦白承认

Agency buyers 往往同时在评估两个产品：

1. demo 里的产品
2. 这个产品未来可能制造出来的问题

所以，光有漂亮的 AI output，根本不够有说服力。

买家不是只在问：“这个能帮到我们吗？”

他们也在问：“这个以后会伤到我们吗？”

如果第二个问题你回答不好，那么你那些漂亮的生成结果，大多只是装饰。

我不觉得 agency 还需要更多装饰。

我觉得他们需要的是那种可以放心拿到客户面前去用的系统。

这种产品更难做。

但我也觉得，它更诚实。

我就说这些。

我尤其想听听 agency folks 的看法。你看到的 AI tooling，是真的降低了风险，还是只是让团队能生产更多内容，而那些真正的 operational headaches 还原封不动地留在原地？

Cheers, Chandler