devgo.cn如果你在广告行业待过，一定知道做一条广告有多繁琐：写文案、配乐、选受众、定投放地域，每一步都要专业团队反复打磨。但 Spotify 的广告平台现在把这些全砍了——广告主只需要用自然语言描述一句“我想给美国科技中心的工程负责人推一条 QCon AI 大会的广告”，剩下的文案、音频、受众定向、合规审查，全部由平台上的 AI Agent 自动完成。这不是什么实验室 demo，而是已经跑在真实生产环境里的系统：自去年上线以来，Spotify 超过 70% 的广告都在使用 AI 工具，累计为 7000 多个广告主生成了约 2 万条创意素材，背后是真金白银的广告预算和真实用户。
这套系统叫 Ads AI，本质是一个多 Agent 平台。所谓多 Agent，就是把一个复杂任务拆给多个各司其职的 AI 程序协作完成，而不是让一个大模型包揽所有事。在 Spotify 的架构里，广告主输入的自然语言会先经过一个 LLM Gateway（大模型网关，负责统一调度和调用底层大模型）提取出结构化意图——比如“受众是技术人群”“地域限定美国”“目标是品牌曝光”。这个意图随后被交给一个基于 Google ADK（Agent Development Kit，谷歌的 Agent 开发框架）Java 版本构建的多 Agent 编排层，里面并行跑着好几个专职 Agent：广告脚本生成 Agent 负责写文案，广告护栏 Agent 负责检查内容是否符合平台政策，受众推荐 Agent 负责圈选投放人群（目前还在试点阶段）。这些 Agent 的输出最终汇聚成两个明确的结果：推荐的受众包和生成好的创意素材。
整个架构最值得借鉴的地方，是 Spotify 在工程组织层面定下的一条硬规矩：一个 Agent，一个代码包，一个负责人。每个 Agent 都被强制封装成独立的 Bazel 包（Bazel 是谷歌开源的构建工具，能精细控制代码依赖关系），包里除了 Agent 本身的逻辑，还捆绑了所有权信息、监控配置、告警规则和依赖管理。这意味着什么？意味着一个团队想改某个 Agent 的提示词，必须先通过 Bazel 的编译期可见性检查——如果这个 Agent 没有被授权引用某个工具或另一个 Agent 的代码，直接编译失败，连运行的机会都没有。这种把权限控制前置到编译期的做法，从根上杜绝了团队之间互相乱调代码的混乱局面。
更巧妙的是，Spotify 把 Agent 的 LLM 配置（比如用哪个模型、温度参数多少）以 front matter 的形式直接存在代码包的头部。这样每个 Agent 的模型选择就跟着代码走，版本管理、代码评审、灰度发布全都复用现有的工程流程，不需要额外搞一套模型配置管理系统。在团队层面，每个团队拥有自己的 Agent 和工具，但所有 Agent 共享同一个运行时上下文和 Google ADK 运行时。平台层统一负责工具的可追踪性、上下文管理和运行循环，而安全和编排逻辑被单独抽出来放在 Agent 之外的独立层——这样能保证所有 Agent 体验一致的护栏和编排策略，不会出现某个 Agent 安全审查严格、另一个却很松的情况。
整个技术栈从下往上分三层：最底层是模型和工具平台，负责 LLM 运行时、插件和可观测性配置；中间是 AI Agent 层，各个 Agent 在这里各司其职；最上层是 gRPC 服务层（gRPC 是谷歌开源的高性能远程调用框架），负责接收客户端请求和管理会话。客户端每次调用都会创建一个与 Agent 的会话，然后请求才进入 Agent 层处理。这套分层设计让 Spotify 能够支撑多个团队并行开发不同的 Agent，同时保证整体架构的一致性和可维护性。
最让我意外的是 Spotify 在演讲中毫不避讳地分享了开发过程中踩过的坑。他们特别强调了一个核心原则：Agent 负责的是“判断”和“推理”——比如理解广告主说“我想给 Z 世代推运动鞋广告”背后的受众意图、从各种信号中生成广告简报、识别敏感话题防止不合规内容生成。但数据本身，他们坚决不让 Agent 直接碰。这种职责划分避免了 Agent 在数据访问上权限过大带来的安全风险，也让数据治理变得清晰可控。对于任何想在生产环境落地多 Agent 系统的团队，这个原则都值得直接抄作业：Agent 做决策，平台管数据，权限在编译期就锁死。
这套思路能直接借鉴的场景其实很广。凡是需要多个 AI 能力协作完成一个完整任务的业务——比如电商的商品描述生成加合规审查、客服系统的意图识别加话术生成加情绪检测、内容平台的自动摘要加敏感信息过滤——都可以参考 Spotify 的这套模式：按职责拆 Agent、每个 Agent 独立成包并绑定所有权、权限控制前置到编译期、安全编排独立于 Agent 之外。最大的坑在于，多 Agent 系统的复杂度会随着 Agent 数量急剧上升，如果没有 Spotify 这种强制的包隔离和所有权机制，很快就会变成一团乱麻。另外，LLM 配置跟着代码走这个细节看似不起眼，实际能省掉大量模型版本管理的头疼事，强烈推荐一试。
内容与图片版权归原作者所有 · 原文: https://www.infoq.com/presentations/spotify-multi-agent-ai-architecture/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global