跨国深谈← 返回←Anthropic 平台负责人：Claude 平台的「三层蛋糕」与给 token 分工的「策略」

Anthropic 平台负责人：Claude 平台的「三层蛋糕」与给 token 分工的「策略」

关联

公司 Anthropic · Claude

概念 Messages API · Claude Managed Agents · Claude Tag · 策略 · 智能体 · harness · 上下文工程 · 提示词缓存 · 技能 · 记忆 · 评估 · MCP

这一集聊的是 Anthropic 的平台团队——既是对外的开发者 API(大家构建应用时接入 Claude 智能的那一层)，也是对内支撑 Anthropic 自家产品的基础设施。两位主角 Caitlin 和 Angela 负责这套平台，主持人称它是「世界上最重要的开发者平台之一」。

团队有两个北极星：对内给自家团队最大杠杆、让他们快速发布产品；对外是「业务在哪里，我们就在哪里」——深度集成 AWS、Google 等云厂商，让任何构建者都能用 Claude 做定制软件。Angela 的一句话点出了背景判断：定制软件的「最后一公里」以前在经济上不可能，现在理论上应该非常容易实现 。

最有信息量的一个钩子是：在他们看来，token 并不是完全可互换的——你可以让这个 token 执行任务、让那个 token 提供建议、让另一个「做梦」(探索)，围绕这个思路组合出的东西，他们叫「策略」(strategies)。这是全集反复出现的核心概念。

平台是一个三层蛋糕

一年多前，平台基本只有一个 Messages API——无状态、一问一答 。随着模型越来越擅长长时间运行、处理更多上下文，他们发现客户和自己都在反复解决同样的问题，于是开始把基础能力打包成更高阶的抽象。Angela 给出的框架是这个「蛋糕」有三层 :

• 知识层：懂得怎么用 Claude——Messages API 的具体参数形状(体现模型设计：怎么思考、怎么尊重参数、怎么做工具调用)、标准化的工具、以及 skills 和 memory(把不同时点可注入的上下文标准化)。
• 执行层：让 Claude 真正干活——编辑多个系统里的文件、输出结果，这需要基础设施：有治理和安全的沙箱(隔离运行环境)、可恢复的会话存储、prompt 缓存、上下文窗口管理。这一层的具象产品是 Claude Managed Agents:一个通用但高性能的 harness(工具套件)，托管了这些枯燥但关键的细节。
• 协调层：就是上面说的「策略」——一个「元 harness」,给不同 token 分配不同工作(建议、执行、做梦、评分)，编排组合。这是路线图的方向：抽象会越来越多地从知识层走向执行层、再走向协调层。

不执着于「跑在我的基础设施上」

一个可能反直觉的开放姿态：对执行层，他们并不坚持你必须用他们的沙箱和存储。他们推出了自托管沙箱，并与 Modal、Vercel、Cloudflare 甚至 Amazon 的新微型虚拟机合作，让这些都能即插即用；还推出 MCP tunnels,让你能穿透防火墙调用自己内网的 MCP 服务器 。

重要的是「如何把智能体组合起来的架构」这件事上他们有强烈观点，底层跑在谁的机器上不重要。生态上他们还推动标准(skills、MCP),甚至在安全互操作上做标准制定——比如联合防范网络攻击和欺诈。Angela 的类比：AI 像电，之所以是变革性技术，是因为它能接入一切、人人可访问，而这靠的是标准和生态，不是任何一家能独自做到的。

选垂直赛道的两个框架

第一个是「展示新的形态因子」：产品不一定冲着最大市场去，而是展示「还有这种做法」。例子是 Claude Design——不搞传统的所见即所得设计系统集成，而是纯粹让 Claude 生成代码来做设计，早期实验发现它真能做到 。

很多这类内部项目「酷两周就换下一个」，甚至从不发布。第二个框架才是正经看 TAM(总可用市场)，且他们偏好 token 密集的领域——判断标准是：一轮结束后，你是「做完了就走」，还是「太爽了，我要做更多」？

编程显然是后者，所以他们也在金融、法律这类有迭代流动的领域做垂直化(如 Claude for Financial Services),同时提供从 Messages API 到 Managed Agents 到插件的不同接入深度。Claude Tag 则是把企业内部智能体平台(如 Shopify、Square 都自建的那种)打包成一个现成产品。

Claude Tag 不是「一个 Slack 机器人」

发布时有很多「不过是个 Slack 机器人」的嘲讽。Angela 的回应：在 Slack 里 @ 它只是接口，不是重点；重点是引擎盖下的上下文工程和架构，好让「Tag 就是能直接用」。

它的体验目标是「像一个同事」：你入职，它进入你的频道，主动、弄清楚了什么有用、帮你把事办成——问它怎么提交报销单就行，不用再到处找人。他们形容这是一个组织级别的 harness(org-level harness)。

【背景】「org-level harness」(组织级别的 harness)这一说法借自 Andrej Karpathy(前特斯拉 AI 总监、OpenAI 创始成员)对智能体的评论。

harness 到底该做什么：删掉引导，让它跑更久

关于最佳实践，Caitlin 很直白：prompt 缓存——去做，能省很多钱；保持上下文窗口干净(清掉旧工具调用、用程序化方式调用工具)；然后是 evals(评测)。但她认为这些底层细节「没那么多汁可榨」，有趣的创新在更高一层：同一个 token,可以花在执行上，也可以花在反思过去的会话并把经验写进记忆、向更大的模型请教以指导小模型、或者执行后由评分器打分决定重试。

Angela 补充了底层逻辑：两年前 harness 是脚手架，要砌两面墙逼模型走直线；现在模型非常「可引导」，引导直接写进 prompt 就行——如果你的 harness 是为引导设计的，那部分可以删掉。harness 该做的是允许模型跑得更久，比如走完 B 再走 C、F、Z 再回来汇报 。

那有没有通用 harness?他们的观点是没有——但通用的部分(prompt 缓存这类)不必自己持有；真正值得自己掌控的是模型与你的执行之间的验证逻辑，在法律、金融这种出错有后果的领域，微调这最后一点会带来巨大差异，甚至决定用户最终用谁的产品 。

至于上下文，她认为有点被过度炒作了：任何 harness 都能处理很多上下文，有独家数据当然有优势，但那不算 harness 层面的护城河 。他们想达到的终点是：你直接告诉智能体「这是我要的结果，这是我要花的预算」，预备、开始 。

从最先进的用户身上学到的

最有意思的创新发生在「上下文与连接层」：有客户在不同模型和平台上各自构建了最擅长的智能体，然后在一个智能体之上暴露 MCP server,让另一个智能体能调用它上面的工具——跨平台协作，跑通了；有医疗公司在跟连 API 都没有的老系统打交道，用 computer use(让模型操作电脑界面)做自动化；还有客户为整个后台办公搭建了自创的上下文流水线。另外，使用量的行业趋势在变：编程之外，制造业正在兴起——他们有产品经理专门飞到底特律去了解客户。

从 token 狂飙到 token 理性化

对于「token maxing 之后是 token rationalization」的说法，他们认为这是自然周期，但关键警告是：不要停止 AI 使用——那是错误的举动 。很多公司的 AI 支出是通过影子 IT 爆发的，员工就是想用，不知不觉半个组织都装上了 Claude Code。

正确的做法不是设一刀切的上限，而是构建按任务复杂度路由的架构：难题路由到大模型，简单任务路由到便宜模型。路由只会在 Claude 模型家族内部做——他们有一个强信念：harness 和智能体层应该针对你用的模型家族来调校，行业也正从「换个模型插进同一个 harness」往上走一层、改为插整个绑定模型家族的智能体(如 Vercel 的做法)。Caitlin 用在 Stripe 时的类比：当年他们盯着 AWS 账单，发现配置不当的后台任务狂烧 CPU,就设护栏找到它、客气地请工程师关掉——AI 成本治理也会走到这一步，但要从侧面看「同样成果能不能用更聪明的策略、更低成本达成」，而不是把创新掐死。

接下来：把「策略」做成产品

未来两个月他们在构建「让你能组合策略」的能力。Angela 给了一个具体例子：做一个 bug 猎捕智能体，通常只有两个杠杆——换更大的模型、或让它跑更久；但实验发现还有第三个杠杆，回报大得多：best-of-n(并行跑多个、取最好的结果)。

说说容易、论文很多，但真正建成并投入生产非常难，要自建一堆自定义 harness——「我们看到这就是 alpha 所在，而且它很难」,所以他们的哲学是：回报大且难的东西，就把它做简单给你用。一年前谈的「智能体蜂群」其实就是策略的一种。同时他们也在补「基本门槛」：企业级安全合规控制、平台更模块化(想单独用记忆就用记忆)、以及给周末开发者更开放、更可折腾的体验。

本集带走

• 用「三层蛋糕」定位你该建什么：知识(skills、memory、API 参数)→ 执行(harness + 沙箱、会话存储等托管基础设施)→ 协调(策略)。普通企业不必自己爬山，直接用高阶打包产品；AI 原生初创才需要从原语玩起。
• 底层细节别过度打磨：prompt 缓存、清理上下文窗口、写 evals 就是最主要的最佳实践，这层能榨的价值有限；值得自己掌控的是验证逻辑(尤其法律、金融)和 token 预算分配策略。
• 删掉引导型脚手架：模型已经足够可引导，只让 harness 做「允许它跑更久」的事，把精力放到元层——反思写记忆、大小模型协作、执行后评分重试、best-of-n。
• 控制成本的正确姿势：不要一刀切封顶(那会扼杀创新)，按任务复杂度路由到大小模型，事后审视「同样成果有无更省的路径」。
• 接口会不断换，上下文工程才是护城河：Claude Tag 表明，智能体会直接长在 Slack、WhatsApp 这些人类协作形态里，比拼的是引擎盖下的架构。

但下一层是关于，好，如果 token 并不是真正可互换的，你需要给它们分配不同的工作，比如这个 token 负责建议、那个负责执行，这个在「做梦」、那个在执行，诸如此类，你会想开始组合这些协同配合的编排式策略
But the next one is about, okay, if tokens aren’t really fungible and you need to give them different jobs, like maybe this token is advising versus this token is executing, this token is dreaming versus this token is executing, so on and so forth, you want to start composing these kind of orchestrated strategies that go together
—— 嘉宾 · [11:34]

我们实际上并不执着于说，你应该在我们的基础设施上运行这些东西。
We actually aren’t precious about, you should run these things on our infrastructure.
—— 嘉宾 · [16:11]

所以对这一年的 AI 开发来说很棒的东西，很可能对下一年的 AI 开发来说就不那么棒了。
So what might be awesome for one year’s worth of AI development will probably not be awesome for the next year’s worth.
—— 嘉宾 · [17:28]

而且我觉得我们想要达到的境地是，你可以直接告诉一个智能体：这是我想要的结果，这是我想要花的预算，预备、各就各位、开始。
And I think where we want to get to is a point where you can literally just tell an agent, here’s the outcome I want and here’s the budget that I want to spend, like ready, set, go.
—— 嘉宾 · [33:41]