当整个AI行业都在争夺模型与算力时，Anthropic却选择了一条截然不同的路径。其开发者平台负责人揭秘了Claude生态的底层逻辑：开放基础设施控制权，深耕模型路由与token分工策略。从三层架构设计到MCP协议开放，这家公司正在重新定义AI时代的平台护城河。

如果你问我，一家掌握着AI模型的公司，最想把什么攥在自己手里，我猜大多数人会说是模型本身，是算力，是数据中心。但Anthropic给出的答案完全不一样。

他们最不想做的，恰恰是把所有东西都自己包圆。

这是Anthropic平台团队的两位负责人，Katelyn Lesse和Angela Jiang，在Sequoia Capital的一次访谈里聊到的。她们两个人管着的东西，可能是整个AI行业里最重要的一块基础设施，就是Anthropic对外开放的开发者平台，也是公司自己内部产品跑在上面的那套系统。听完这场访谈，我脑子里冒出来一个念头，这两个人对生态这个词的理解，跟大部分公司完全不一样。

两个北极星，两套逻辑

内部和外部，这是Katelyn一上来就点出的两条线。

对内，团队的目标很简单，就是给公司内部想做产品的人尽可能多的杠杆，让他们能又快又稳地把想法做出来。速度，是内部这条线上最看重的东西。

对外，目标听起来更宽泛一点，就是让任何一个开发者都能用Claude去实现他们想做的东西。听着像一句空话，但落地下来，其实是要贴着每一个具体行业去做事。她提到团队花了大量时间和亚马逊云科技、谷歌云这些云厂商深度整合，原因就是想尽可能贴近开发者真正做生意的地方。

我自己听到这里，想到的是一个很朴素的道理。以前做定制化软件，成本高到大部分公司根本负担不起。现在有了AI，这个门槛理论上被打掉了。所以Anthropic想做的，不是替你把产品做完，而是把做产品这件事的门槛降到人人都能跨过去。这个定位，其实比卖模型这件事本身要野心大得多。

三层蛋糕，知识，执行，协调

Angela用了一个很形象的说法，把整个平台想象成一块三层蛋糕。

最底下一层是知识层，说白了就是模型知道怎么用自己。messages API是最早的形态，后来慢慢加上了tools也就是工具调用、skills也就是技能包，还有memory也就是记忆。这一层解决的问题很基础，Claude知道该怎么回答一个问题，该怎么调用一个工具。

往上一层是执行层。知道怎么做是一回事，真的把活干出来是另一回事。Katelyn说，一年前她刚加入Anthropic的时候，整个平台基本上就是一个messages API，是个无状态的接口。但客户反反复复在解决同一类问题，团队自己内部也在反复解决同一类问题，那就是怎么支撑一个能长时间运行、甚至没有人在旁边盯着的agent。沙盒怎么起怎么关，会话记录怎么存好方便随时恢复，这些看着枯燥的基础设施活，慢慢被打包成了现在的Claude Managed Agents，也就是Claude托管代理。

最上面一层是协调层，这也是整场访谈里我觉得最有意思的部分，放到下一段单独说。

我自己的理解是，这个三层模型其实映射的是人做事的三个阶段，先懂，再干，最后是安排谁干什么、什么时候干。大部分公司做AI产品，还停留在第一层，顶多摸到第二层。真正难的，恰恰是最上面这层，而这恰恰是Anthropic现在花最多精力的地方。

协调层，一个token也有自己的工作

Angela提到一个词，叫strategies也就是策略，她管它叫meta harness，可以理解成元框架。

这个概念听着抽象，但拆开讲很好懂。以前我们默认一个token，也就是一个词元，不管它出现在对话的哪个位置，干的都是同一件事，就是预测下一个词。但Angela说的是，token其实是可以被分配不同工作的。有的token负责建议，有的负责真正执行，还有的负责反思过去做过的事，把经验写进记忆里，让下一次的agent能表现得更好。

再往下拆，还可以有更细的分工。比如让一个更聪明的大模型去做建议，再让一个更便宜的小模型去执行建议里的具体步骤。或者先执行，再单独用一轮去检查执行的结果对不对，不对就重来。

这个思路让我想通了一件事。这两年大家都在争论，agent到底应不应该无脑地把最贵的模型一路跑到底。Anthropic给的答案其实是，别在模型大小上纠结了，先想清楚每一个token该干什么活。这跟企业管理里说的分工协作，其实是一回事，只不过管理的对象从人变成了token。我觉得这才是真正意义上把智能当成一种可以被设计、被编排的资源来用，而不是简单地把它当成一个越大越好的黑箱。

生态还是围墙花园

主持人直接问了这个问题，开放生态，还是围墙花园。

Katelyn的回答很干脆，她说团队对基础设施这件事完全不恋战。跑在谁的服务器上，存在谁的数据库里，这些都不重要。他们上线了self-hosted sandboxes，也就是自托管沙盒，直接跟Modal、Vercel、Cloudflare还有亚马逊的microVMs这些合作伙伴打通，你可以把这些东西插到你自己的基础设施里。他们还上线了MCP tunnels，让你可以直接连到防火墙后面自己的MCP服务器。真正重要的，是agent架构本身够不够稳，够不够能撑规模。

Angela补了一句让我印象很深的话，她把这一整套战略比作电这个东西。电之所以是一项彻底改变世界的技术，不是因为哪一家公司把电攥得死死的，而是因为所有人都能接进去用，而且有统一的标准和插口。没有一家公司能靠自己把电这件事做完，必须靠整个生态一起。

她们把skills和MCP直接开放给整个行业，connectors也就是连接器，也是建在MCP协议上面的。团队现在还在琢磨一个更高层的标准，就是安全。Katelyn的原话是，没有哪家公司真的希望自己的技术被拿去干坏事，网络安全就是个典型例子，大家都想保护好自己的系统不被恶意利用。所以在安全这件事上，行业内互相合作，大家的利益其实是一致的。

我自己听到这段，第一反应是有点意外。一家掌握核心模型能力的公司，主动把基础设施的控制权让出去，这在传统软件行业里是反直觉的。传统逻辑是，你越往下游延伸控制，护城河就越深。但Anthropic的逻辑反过来了，他们赌的是，只有让别人也能自由地在这套体系上盖房子，这套体系本身才会越滚越大。电网只有联到千家万户才有价值，锁在一家公司手里，顶多算个发电站。

唯独不放的一件事，模型路由

不过，不恋战不等于什么都不管。

有一件事团队态度很坚决，就是model routing也就是模型路由。Angela说得很明确，她们相信harness和agentic layer也就是智能体层，应该跟具体的模型家族深度绑定，调校到位。曾经有一段时间，行业里流行的想法是，先搭好一个通用的harness，底下随便换模型，靠一个路由器决定该用哪个模型。Angela说她们看到Vercel这样的公司走的是另一条路，把整个harness和agent绑定在一个模型家族上面，这个思路她们更认同。所以Anthropic选择的位置是，把Claude这一个模型家族内部的调度做到最优，而不是去做一个跨模型家族的万能路由器。

我觉得这个取舍背后的逻辑挺清楚的。开放的是接口和标准，收紧的是最核心的那部分体验，就是Claude到底好不好用。这跟很多开源项目的打法有点像，底层协议开放，核心产品体验自己攥着。开放到什么程度，收紧到什么程度，这条线怎么画，可能才是所有平台型公司真正的护城河所在。

怎么决定做哪些垂直产品

聊到具体做哪些产品，Angela给了两个判断维度。

第一个维度，是要不断去试探新的form factor，也就是产品形态。她们提到Claude Design这个例子，团队做的一个决定是，尽量把设计这件事完全交给Claude去做，而不是走传统的所见即所得的设计系统路线，单纯靠代码生成来解决设计问题。这类实验很多时候压根不会真正上线，团队内部试个两周觉得不行就换下一个，但它验证的是一种新的做事方式到底行不行得通。

第二个维度，是真正商业意义上的考量，团队会看TAM也就是潜在市场规模，还会特别偏向那些token消耗量大的行业。Angela对token消耗大这个词的解释，我觉得特别精准。她说的不是token数量本身，而是一种心理状态，就是你做完一轮之后，回头一看，会不会觉得这事真带劲，还想接着做更多。编程就是这样一个行业，写完一段代码看到它跑起来了，你会忍不住想接着写下一段。但有些服务，做完一轮任务就结束了，用户不会再想往下深挖。除了这两个维度，团队还会锁定一些具体的业务职能去深耕，比如金融、法律这些领域，专门去打磨符合这些行业需求的skills和workflow。

我自己觉得这套打法挺诚实的。很多公司做垂直产品，要么是纯粹拍脑袋觉得这个赛道性感，要么是纯粹跟着钱走。Anthropic把两条腿都摆在台面上讲清楚，一条腿是探索新形态，一条腿是真金白银的生意考量，这两件事不冲突，可以同时干。

Claude Tag，冰山下面才是重点

访谈里提到一个内部产品，叫Claude Tag，本质上是个能在Slack里被@出来干活的agent。

外界一开始的反应挺冷淡的，觉得这不就是个聊天机器人吗，at一下就能回复。但Katelyn说，这个反应恰恰说明大家都搞错了重点。界面确实就是在Slack里at一下这么简单，但这从来不是重点。真正的重点，是底下那一整套context engineering也就是上下文工程和架构设计，让这个at一下的动作背后，agent真的能像一个新同事一样，主动搞清楚你想要什么，然后把事情办成。

她们提到一个说法，来自Andrej Karpathy，说这更像是一个org level harness，也就是组织级框架。你能看到的只是水面上那一点点，水面下堆的全是复杂度，而这部分复杂度，才是真正难啃、也真正有价值的地方。

我自己对这个案例特别有共鸣。这两年做AI产品，很容易陷入一个误区，觉得交互形式才是创新，今天做个新按钮，明天换个新界面。但Claude Tag这个例子说明，真正的护城河可能压根不在界面层。界面这东西，今天是Slack，明天可能是微信群，后天可能是一封邮件，agent会跟着人类协作的场景走，场景变了，界面自然跟着变。真正沉淀下来、带不走的，是底下那套上下文工程的功夫。

harness是怎么一步步变薄的

聊到harness的最佳实践，两个人给的建议其实挺朴素的。做好prompt caching也就是提示词缓存，及时清理上下文窗口里的旧内容，还有一定要写evals也就是评估用例去验证效果。

但更有意思的是Angela讲的一个变化趋势。两年前的harness，很大一部分工作是在给模型搭脚手架，防止它跑偏，相当于在一条路两边各砌一堵墙，逼着模型沿直线走。现在的模型已经足够听话，你在提示词里直接说清楚从A到B，它就真能从A走到B，原来那些用来纠偏的脚手架，现在可以直接删掉。

但删掉纠偏的部分，不代表harness变得不重要了，只是harness的工作重心变了。以前是怎么让模型不跑偏，现在是怎么让模型能撑得住更长时间的连续运行，从A到B，再到C，再到Z，最后再绕回来跟你汇报。这种更长链条的任务编排，靠的就不再是简单的纠偏脚手架，而是前面说的那种策略型的harness。

我自己的理解是，这其实是一种此消彼长的关系。模型越聪明，原本需要人工设计来兜底的那部分工作就越少，但省下来的精力，恰好可以挪去解决更高阶的编排问题。这是个很健康的分工方式，不是说harness这门手艺过时了，而是它一直在往上迁移。

从最顶尖的用户身上，她们看到了什么

两个人还聊到从客户身上学到的东西，我觉得这段特别真实，没有营销腔。

一类客户是那些真正AI原生的公司，他们在上下文的处理上玩出了很多花活，比如把散落在各处的联系人信息主动串联起来，提前拿到各种权限，再喂给一个agent去用。另一类，是那些还在用特别老的系统的公司，比如一些医疗行业的客户，他们对接的系统压根没有API，团队甚至得琢磨怎么用computer use这类手段，靠agent直接模拟人操作电脑界面去打通这些老系统。

还有一个细节让我觉得挺有意思，有客户同时在Claude Managed Agents和别的平台上都搭了agent，各自负责擅长的事，然后突然意识到，可以在自己的agent上包一层MCP server，也就是MCP服务器，让另一个agent直接调用这个agent当工具用。团队听完之后的反应是，直接坐下来跟客户一起把这套东西跑通了。

另外一个我没想到的趋势，是制造业开始冒头，团队里已经有人专门飞去底特律，去搞清楚那边的客户到底需要什么。

我自己看完这段最大的感受是，真正的创新往往不是什么惊天动地的新产品形态，而是这种连接层面上的巧劲，把原本各自为战的agent和系统，用最朴素的协议串联起来。这也印证了前面说的，MCP这类开放标准的价值，恰恰体现在这些看似不起眼、但极其具体的连接场景里。

从token maxing到token理性化

主持人提了一个很有意思的说法，说行业刚经历完一段拼命堆token的阶段，现在进入了理性化阶段。Angela说这个说法她很认同。

她给的建议是，千万别因为想省钱就直接叫停AI的使用，这是最亏的做法。很多公司AI花费失控，其实是因为员工自己偷偷用，变成了影子IT，等公司发现的时候，已经有一大半团队私下装了Claude Code。与其一刀切，更好的办法是设计一套策略，根据任务的难度分级路由，难的任务交给更聪明的大模型，简单的任务交给便宜的模型去处理。

Katelyn补充说，这跟她之前在Stripe的经历很像，当年大家对AWS账单也是锱铢必较，发现有员工的后台任务配置错误、疯狂烧CPU，团队会很客气地提醒对方把这个任务关掉，这不是在扼杀创新，而是把不必要的浪费剔除掉。

我自己觉得这个类比特别贴切。真正成熟的公司，不是完全不管成本，也不是因为怕花钱就干脆不让用，而是在鼓励大胆尝试和抠成本细节之间找到一个平衡点。这个平衡点，现在还在被每一家用AI的公司重新摸索。

接下来会发生什么

聊到接下来几个月团队最兴奋的方向，答案还是回到了strategies这个词上。

Angela举了个具体例子，如果你想做一个专门抓bug的agent，过去能调的杠杆基本上只有两个，换个更大的模型，或者让它跑得更久。但其实还有第三个杠杆，常常被大家忽略，就是best-of-n，同时跑好几次，挑一个最好的结果出来。这个方法在论文里早就有人写过，但真要把它做成能稳定跑在生产环境、能让真实用户用起来的东西，难度非常大。而这恰恰是团队认为真正有alpha，也就是超额收益的地方。

聊到agent swarms也就是智能体集群这个概念，Angela说这其实就是众多策略里的一种，拆解到最细，本质上还是同一件事，就是给每一个token分配一份具体的工作。

除了继续往这个方向深挖，团队还提到两类用户画像，需要分别照顾。一类是大型企业，他们需要企业级的安全合规能力，也需要平台足够模块化，方便把各种能力单独拼装进自己现有的系统里。另一类是周末搞副业的独立开发者，这类人需要的是足够开放、足够能被随便折腾的体验。

我自己看到这里，觉得这才是一个成熟平台该有的样子。既要伺候得了最挑剔的大企业客户，也要给周末爱折腾的个人开发者留出空间，这两拨人的需求完全不同，但一个真正想成为基础设施的平台，谁都不能舍弃。

我的一点感想

看完整场访谈，我最大的感触是，Anthropic的平台团队，想清楚了一件很多公司想不清楚的事，就是什么该攥在手里，什么该放出去。

模型能力，他们攥得很紧。基础设施跑在哪、存在哪，他们完全不在乎。标准和协议，他们主动开放给整个行业。这条线画得很清楚，也很聪明。

我自己做产品这些年，见过太多公司反过来操作，把不该管的基础设施管得死死的，却在真正决定产品体验的核心能力上放任自流。Anthropic这套打法给我的启发是，做平台这件事，真正值钱的不是你控制了多少东西，而是你想清楚了控制哪一部分才真正有意义。剩下的，越开放，盘子才能滚得越大。