我把 Spotify 这套架构的核心技术细节整理出来了，供正在给团队搭研发 Agent 的架构师参考：
1. 架构三层设计：
- Hooks：唯一具有权威性的层级（PreToolUse hooks），在工具运行前直接拦截拒绝，模型完全无法绕过；
- Scripts：执行层，负责组装请求并唤起廉价模型，把网络管道逻辑与主模型隔离；
- Skills：纯建议层，仅用于平滑指引，就算模型没读也不会导致系统崩溃。
2. 坚决不被代理的三件事（必须全额买单）：
- 修改已有文件：小模型的摘要没有可靠的行号，因此指定 offset 和 limit 的精确读取必须放行给主模型；
- 核心逻辑推理：小模型只能发现表层模式，Spotify 实测中它彻底漏掉了多线程安全 Bug，被旗舰模型几秒抓出；
- 小文件读取：单次代理网络来回耗时 10-30 秒，小文件走代理反而得不偿失。
3. 最省钱的一句系统提示词：
- 给代码生成工蜂下死命令：“只输出纯代码，严禁任何解释，严禁包含 Markdown 格式标记（fences）”；给读取工蜂下死命令：“只给子弹点，严禁问候语，严禁前言”。
这套架构由 Spotify 的 Dimitri Mazmanov 设计，真正实现了高价值思考与低价值搬运的工程解耦。