Anthropic's Katelyn Lesse & Angela Jiang: Building an Ecosystem, not a Walled Garden

在这之上的最后一层抽象，很可能就是 coordination layer（协调层）。所以你有 knowledge（知识），有 execution（执行），还有 coordination（协调）。而在 coordination layer，我们开始思考一些可以称为 strategies（策略）的东西，本质上它几乎像是一个 meta harness（元级编排框架）。真正底层的 harness 是为 execution 设计的。但再上一层关注的是：如果 token 并不是真正可互换的，你需要给它们分配不同的职责，比如这个 token 负责 advising（提供建议），而那个 token 负责 executing（执行），那你就会想开始组合出这类彼此配合的、经过编排的 strategies，它们应该位于所有这些东西之上，因为归根结底，还是需要执行，而执行本身仍然需要知道该做什么。

所以理论上，一切都应该像梯子一样层层衔接起来。所以我想，如果你去看我们的 road map（路线图），并稍微往前推演一下，看看你会预期我们往哪里走，那么你会看到：就我们会发布的这些抽象而言，我们会越来越多地从 knowledge execution layer，进一步从 execution layer，走向某种 coordination layer。

Caitlin 和 Angela，非常感谢你们今天加入我们。Lauren 和我都特别高兴你们能来。你们负责构建 Anthropix platform，因此你们实际上是在打造——在我看来——全球最重要的 developer platform（开发者平台）之一，甚至可能就是最重要的那个。我们今天非常期待采访你们，进一步了解接下来会发生什么。所以也许先从一个基础问题开始：你们能否先给我们一些背景，说明一下 Anthropic Platform 是什么，以及你们在 Anthropic 内部处于怎样的位置？

好的，Platform 一方面是我们对外的 APIs（应用程序编程接口），也就是开发者在想构建应用和系统、并接入 Cloud 智能时所依赖的 developer platform；另一方面在内部，我们也运行自己的产品基础设施，基本上，我们也是内部 app 所构建其上的那一层。太棒了。那你们团队的 north star（北极星目标）是什么？

这是个很好的问题。因为我们同时面向内部和外部，所以实际上我们有点像是有两个 North Stars，这听起来大概会让人觉得：什么？你们肯定只能有一个 North Star 吧。

是不同的 planetary system（行星系统）。

对，没错。它们是彼此独立的 solar systems（太阳系），所以没问题。不过在内部这一侧，我们真正想提供的，是尽可能多的 leverage（杠杆效应），让内部团队能够交付真正带有 AGI 理念的产品。我们希望他们能快速推进，并且拥有一个可靠、优秀的平台来作为构建基础。但我认为其中关于速度的那一点，对我们来说是非常有意为之的，我们在内部真的、真的非常在意这一点。

对外部来说，我们面临的是一组复杂得多的事情，但其中一个真正的 true north（核心北极星目标）是：基本上要让任何 builder（构建者）都能获得相应的工具，从而能够与 Claude 协同，去构建他们想构建的任何东西。所以这句话说得有点宽泛，但它最终会落到一个结果上：业务在哪里，我们就要在哪里。我们非常在意让自己的平台尽可能、尽可能贴近那些业务。这也是为什么我们花了很多时间和 hyperscalers（超大规模云服务商）合作，并与它们进行非常紧密、非常直接的集成，比如 AWS、Google 等等。而我们最终也会因此创建出很多 primitives（基础构件）。

我们希望人们能够表达出他们认为自己的产品应该是什么样。我们希望他们几乎能以自己的方式做出类似 custom software（定制软件）的东西。你知道，在这个有 AI 的新世界里，过去在经济上大概不可能实现的那最后一公里定制软件，现在从理论上说应该是非常、非常可实现的。我们想把所有工具和所有能力都提供给他们，让他们去做到这一点。所以有时，这会以 primitives、API 以及更高阶 abstractions（抽象）的形式出现。

有时，这也会以 standards（标准）的形式出现。比如说，skills 和 MCP，这些东西对 Claude 变得有用来说就是必需的。我们也可以把它们提供给整个 ecosystem（生态系统），与所有人合作，帮助你创建这些东西，并从 Cloud 中获得最佳效果。所以我会说，对外而言，我们确实是围绕着一件事来定位自己的：帮助你具备构建能力。但在内部，虽然这种定位仍然存在，它可能会更具体地偏向速度，偏向能够非常快速地推进。

你们是如何决定哪些东西进入 platform（平台）、哪些会 externalize（对外开放），以及哪些不会，从而决定哪些产品应该可用的？

对。我的意思是，我们通常会尽量坚持一种能够在各个方面保持一致的 philosophy（理念）。这实际上也是我们同时做 internal 和 external 的原因之一。还有很多其他的平台型业务和模式，会把这两者明确分开。对我们来说，我们会有意识地尽量让它们保持对等。

因此，我们会尽可能坚持这样一种 philosophy：对于任何 builder（构建者），无论内部还是外部，尽管我们的内部 builder 可能会有一些略微不同的需求——就像任何用户都会有略微不同的需求一样——我们都希望所有人可用的是同一套 primitives。这里面一个也许更 overarching 的 thesis（核心判断）是，我们看到这些模型的能力一直在增长，而且这种增长近乎指数级。要找出一种能够长期成立的 form factor（产品形态）其实非常难。我想两年前，我们都还在说，一切都是 chat。现在大家都在说，忘掉 chat 吧。

现在一切都像是在讲 agents。而且之后还会有另一种 form factor、再另一种 form factor。我们设想这会是一个持续演化的过程。所以，对我们来说，能够让所有人——也包括我们自己——适应这一点的最好方式，实际上是构建一个非常强健的平台，给人们那些工具，让他们自己去弄清楚这些 form factors 到底是什么。我也完全不认为，我们会觉得自己是唯一有能力找出这种 form factor 的人，绝对不是。

事实上，我们越能推动这件事的 democratization（民主化、普及化），越能帮助人们、允许人们去做实验，我就越认为，这些 form factors 其实会自然而然地从市场中浮现出来。

对，而且我觉得在我们团队内部，也有过一些时刻：我们甚至只是在尝试用另一种更高阶的方式来重新 packaging 我们的 primitives，我们会想，好，很棒，我们已经用自己做出来并推向世界的这个产品，解决了某一类非常具体的问题，因此我们也可以自己先 dog food（内部试用）它；但我们绝不想掉进这样一个陷阱：过度围绕内部用户的问题及其解决方式来优化，因为正如 Angela 所说，内部用户有非常具体的需求，外部用户也有非常具体的需求，所以如果你过度偏向其中任何一边，就会掉进陷阱。因此很多时候，我们会在内部 dog food 某个东西的同时，也向外部客户开放某种 early access（抢先体验），这样我们就能获得一系列不同的反馈，再把这些东西带回平台中。

我很想聊聊你刚才提到的那些更高层级的 abstraction（抽象）。我想最底层基本上就是对 Clive、Opus 之类 token 的原始访问。你是怎么理解其上那一层层 abstraction 的“层级蛋糕”的？

对，如果往回看，大概一年前我加入 Anthropic 时，这个平台基本上就只是 messages API。就是一个 messages API。我们推出过像 MCP 这样的标准，当然也围绕我们的 SDK、docs、console 之类提供了 developer tooling（开发者工具），但在很大程度上，它当时还是一个 stateless API（无状态 API）。有意思的是，呼应 Angela 关于 form factor 会随时间演化的观点，我们发现很多客户在反复解决同样的问题，而这些也正是我们自己在反复解决的问题：随着 model 越来越擅长长时间运行，并且能在同一时间处理更多 context（上下文），你会想构建能够在一种长时间运行的环境中成功工作的 agent，甚至是在 remote context（远程环境）中运行、且不一定有人类 in the loop（参与闭环）的 agent。

所以我们发现，可以把自己的 primitives（基础构件）拼接起来，搭建起那些我们内部也在反复搭建、用于支撑自家产品的基础设施，并进一步形成一些更高阶的 abstraction，让你开箱即用地完成更多 agentic work（agent 式工作）。我们替你解决的问题之一是，infrastructure（基础设施）本身往往很难处理。比如，怎么生成 sandbox（沙箱），让它具备合适的 governance（治理）和 security（安全性），并且在需要时启动、在不需要时关闭？又比如，怎么处理 transcript sessions 的存储，以便你中断一个 session 后，之后还能恢复并接着运行？所以，基础设施是我们希望能更多开箱即用提供的一个重点，而今天我们确实也提供了更多这类能力。第二件事则是 harnesses（运行封装）和 harness engineering。

大家会投入很多思考和精力在这些问题上：我该如何做 prompt caching（提示缓存）？如何管理我的 context window（上下文窗口）？以及我到底该怎样从 model 中榨出更多 intelligence（智能），又该如何控制成本，等等。所以我们某种程度上把自己的 primitives 进一步打包，使之更贴合我们自己反复在解决的这些问题，从而为用户开箱即用地提供更多这类能力。这样一来，无论他们是在内部为自己构建系统，还是在开发产品，都可以更专注于他们真正想解决的问题；如果他们想把其中一部分问题外包给我们，也可以这么做，这基本上就是我们的 ethos（理念）。

你们的客户通常是在你们提供的这堆工具里自行挑选组合吗，还是说——我换个问法——他们有多经常会直接选择 managed agents 这类方案？也就是“你们全都替我搞定”的那种。

这取决于用户群体。比如我会说，真正 AI native 的 startups，那些在非常底层不断 tinkering（动手折腾）和 experimenting（实验）的人，通常只会选择 primitives。至于其他人，尤其是更传统的 enterprise（企业）场景，或者一些 startup 的目标与理念本身并不是去优化某种 hill climbing 式的局部提升，而更像是把一系列 workflows（工作流）串联起来，并为用户提供独特价值——对这些人来说，这类事情本来就不是他们的 core competency（核心能力），也不是他们想投入时间和资源去聚焦的地方，所以他们会更多选择这种更高阶的打包式方案。

过去几个月里，你们在不同层级都发布了哪些 primitives 的例子？我们已经看到其中一些了，很想听你展开讲讲。

对。我想，也许可以这样来理解 Caitlin 刚才提到的一些 constructs（构件）：这个说法有点过度简化了，但基本上，这个“层级蛋糕”大致可以分成三层。最底层有点像是 knowledge（知识）。所以在这一层，很多时候它是关于 model 的知识，是关于 model 所需要的东西的知识，也可以说，就是知道如何真正用 Claude 做成一件事的能力。我大概会这么表述。因此，在这一层，我们投入越来越多时间打磨的 primitives，其实反而是一些更偏过去就存在的东西。

因为我们仍然在持续演进它们，但它们往往已经更成熟一些。比如说，我们在 messages API 上加入了非常具体的形态和参数。这更像是在明确展示 Claude 的设计，也就是 Claude 这个 model（模型）本身的实际设计：它如何思考、如何遵守某些参数、如何进行 tool calls（工具调用），以及所有这些不同的部分。然后我们开始标准化 tools，接着又开始标准化那些你可以在不同时间点注入的 context（上下文）片段，具体来说就是 skills 和 memory。所以这些就是在过去大概一年多时间里，我们推出的那类 knowledge layer（知识层）抽象。

我们实际上已经开始投入越来越多时间的下一层 abstraction（抽象），是这样一种情况：当你已经“知道”一些东西之后，接下来你就需要去执行。所以在 execution layer（执行层），那一层抽象就是 Caitlin 刚才提到的那部分：我们在做这些更高阶的东西，但这里所谓“更高阶”到底加在什么之上？本质上就是因为你现在是在让 Claude 去执行工作，而不只是知道某件事。对吧？

我可以给它一个问题，让它给我一个答案。你也可以把很多这类东西串起来。但如果你现在需要它去执行，比如真正做事、给我产出、在很多不同系统里编辑文件，这就会复杂得多，也需要基础设施来承接。所以这一层基本上可以说是一套 low level harness（底层控制框架）加上 managed infrastructure（托管基础设施）这样的抽象。今天，我们在这一层的高层产品叫做 Cloud Managed Agents。

这是其中一部分，但我们开始把越来越多的组件包进这里面。我觉得在它之上还会有一层。我们已经有一些迹象，并且已经开始朝那个方向构建，但在这之上的最后一层 abstraction 很可能就是 coordination layer（协调层）。所以你先有 knowledge，然后有 execution，再然后有 coordination。而在 coordination layer，我们已经开始以一些并不那么显眼的方式，把其中一些能力暴露出来。

但我们开始思考一种叫 strategies（策略）的东西，基本上它几乎像是一个 meta harness（元控制框架）。真正底层的 harness 是为 execution 设计的。但下一层要解决的是：如果 token 并不是真正可互换的，而且你需要给它们分配不同的工作，比如这个 token 负责 advising（建议）而不是 executing（执行），这个 token 负责 dreaming（发散/构想）而另一个 token 负责 executing，诸如此类。你就会想开始把这类经过编排的 strategies 组合起来，而它们应该建立在前面所有这些东西之上，因为归根结底，你仍然需要执行，而执行者也仍然需要知道该做什么。

所以理论上，一切都应该像梯子一样层层衔接起来。所以我想，如果你去看我们的 roadmap，并且稍微往前推演一下、预期我们会往哪里走，那么你会看到我们会越来越多地从 knowledge layer 走向 execution layer，再从 execution layer 走向 coordination layer，就我们会推出的这些 abstractions 而言。

放出来。

一句非常酷的引言。

你觉得

这一切会整合成一个更广泛的 ecosystem（生态系统）吗，而不只是你们正在构建的那些东西？你们如何帮助支持那些在其之上构建产品的人，又如何帮助他们把这些组成部分的价值最大化？

会的。我觉得这对我们来说是最重要的事情之一。我们真的很想找到一种方式，尽可能支持更多人去做这件事。不过我们也还在学习，毕竟这个行业的很多方面都还在演变。

我们已经看到很多不同的组件被搭起来、又被撤掉。我觉得对 Caitlin 和我来说，关键点一直在于：至少在 base layer（基础层）上，确保我们尽可能全面地提供各种 primitives（基础能力）。所以，比如 knowledge（知识）、execution（执行）、coordination（协调）这类能力，我们都希望开放给所有人，这样大家就可以在其之上进行组合和创造。这是从一种纯 builder（构建者）的视角来看。然后还有另一个视角，就是人们该如何与你们对接、接入我们。

对吧？我们自己也在构建 first party products（第一方产品）。我们也创建了一些可以与我们原生嵌入的方式，比如 connectors（连接器），它们是基于 MCP spec 构建的。我们也在尽量对这类东西保持更开放的态度。同时，我们也开始摸索，哪些具体的模块和组件才是合适的。

但我们真正想做到的是：让一家公司能够基于这些能力被创建和构建出来，他们可以打造自己想要的任何产品；如果需要，也可以构建 agents（智能体）。而这些 agents 和产品本身，也可以成为能够接入其他 agents 的东西。其中一些 agents 可能是 cloud agents（云端智能体），另一些 agents 可能是别人的 agents。

但我们希望能够在整体上实现这种 transactability（可交易性 / 可交互协作能力）。而我认为，要让这一切最终成立，其中有一部分就在于 standard setting（标准制定）。一方面是传统意义上的标准制定，也就是系统如何实现 interoperability（互操作性）。这也是你已经能在 skills 和 MCP 这类东西上看到的方向。不过，它们依然还是处在 builder layer（构建者层）。

我觉得在更高一层上，还有一部分与 interoperability 和 standard setting 有关，那就是：我们该如何共同对待 safety（安全）？我们和很多这类公司都谈过，这里先不谈理念分歧，单从现实层面来说，没有人真的希望自己的服务上运行的技术去做负面的事情。所以我觉得 cyber（网络安全）就是一个很好的例子。你会想保护自己的系统，不受 negative actors 或 bad actors（恶意行为者）的影响。因此，这类标准制定的重点就在于：我们怎样才能找到方式，与越来越多的人合作，一起说——对，我们都希望确保 critical infrastructure（关键基础设施）是安全可靠的。

我们都希望防止 fraud（欺诈）或任何这类事情发生。以及，我们怎样才能更好地与这些成员中的每一方合作？我觉得，在最后这一层上，我们某种程度上仍然处在持续演进之中。我也认为，我们现在仍然非常努力地在寻找办法，让自己做得更好，并与行业其他参与者协作，把更多人带进来、与他们配合推进。但这些都属于更高阶的 primitives（基础构件）或模块，我们希望它们能够到位，这样大家才能与各方合作，最终解决这个问题。

我觉得，如果 Fly 在一天结束时、退一步看所有这些事情，这项技术的变革性实在太强了。某种意义上，它有点像 electricity（电）：在电出现之前，人们只能靠 candle（蜡烛），能做的事情非常有限；但有了电之后，它之所以对我们所有人都是如此具有变革性的技术、如此强大的 utility（基础效用），是因为你真的可以把它接入几乎所有东西。每个人都能够真正使用它。我们也有各种标准，以及插接和完成所需各个环节的方法。

而这不是任何一个人单靠自己就能做到的事情。大家始终都必须与 ecosystem（生态系统）协作、与 partners（合作伙伴）协作，去找到一条前进的路径。

你如何看待构建 open ecosystem（开放生态）而不是 walled garden（封闭花园）的理念？对于哪些产品你认为必须由自己 first party（第一方）来拥有，哪些方面你又完全乐于接入生态中的其他组件，你是怎么思考的？

是的，也许借用一下我们稍早谈到的 Angela 那个 layered cake（分层蛋糕）比喻，你会看到在其中一些部分上——比如 execution（执行）——我们在像 Cloud Managed Agents 这样的东西里所做的事情，而且我认为随着时间推移，你会看到我们努力让它变得更 modular（模块化）一些，我们其实并不执着于“这些东西一定要跑在我们的 infrastructure（基础设施）上”。它不一定非得是我们控制的 sandboxes（沙箱），或者我们控制的 storage layer（存储层）。实际上，比如说，我们推出了 self hosted sandboxes（自托管沙箱），并且与 Modal、Vercel、Cloudflare 以及很多其他伙伴合作，甚至包括 Amazon 的新 micro VMs（微型虚拟机），去提供一种 first class offering（一等支持方案），让你可以接入其中任意一种。我们还推出了 MCP tunnels，这样你就可以调用位于你的 firewall（防火墙）之后的 MCP servers，并能够打通这层连接。所以对于其中一些事情，究竟是跑在我们的 infrastructure 上，还是别人的 infrastructure 上，对我们来说其实并不重要；因为对我们更重要的是，你如何把这些 agents（智能体）组合起来的 architecture（架构）——要让它足够强大、足够可靠、足够可扩展——在这一点上我们有非常明确的看法。你基本上只需要遵循我们提供出来的 interfaces（接口）并把这些东西接进来，而我们认为这通常会运作得非常好。

对，我觉得在这种……

在我们可能会构建产品的那些 verticals（垂直领域）上，我觉得我们大概有两个思考框架。第一个是，我们始终都在试图找出一种 form factor（产品形态），一种不断演进的 form factor。顺便说一句，我们并不认为 form factors 是静态的；它是一个动态的东西。所以，某一种在某一年的 AI 发展阶段里可能非常棒的形态，大概率并不会同样适用于下一年的发展阶段。

而我们就是尽量保持这种心态。我们也会整体上这样告诉 Anthropic 团队：大家总是在想，“这个东西够不够 AGI pilled？”与此同时，我们还有另一种心态：我们做出了某个东西，它能用，也确实很酷，可能在一年里都很好，但也许它并不是接下来那个正确的下一步。

那么，有没有办法再试一次呢？我们也会对平台用户说同样的话。我们只是觉得，这大概就是，你知道，技术本身所附带的一部分。不过，是的。其中一个原则就是，始终不断地去寻找这种新的 form factor（形态）。

所以有时候，我们会在某些领域推出产品，来尝试展示一种新类型的 form factor。这不一定是因为我们觉得它是最大的机会，或者是最重要、最值得追逐的事情，而是有时会想，好吧，这件事一直都很难，人们也一直都用这种方式沟通，或者尝试用这种方式做事。那我们能不能证明，也许其实还有一种稍微不同的方式？而且既然现在 model（模型）能力已经这么先进了，我们能不能用一种稍微不同的方式把它表达出来？

有什么例子吗？

对。你知道，Claude Design 在某种程度上就有点这种意思。我觉得，这取决于你怎么看，你可能会把它看成是我们某种程度上进入 design 这个 vertical（垂直领域）的方式之一。但更多时候，如果你仔细看我们想用那个产品做什么，里面其实做了几个决定。第一个是，你实际上可以尝试把越来越多的事情卸载给 Claude。

所以它会有点带着明确倾向，也就是，直接去跟它聊，让它自己真正去尝试搞明白。当然，你仍然可以编辑它，然后做这些操作，但它某种程度上会稍微弱化这种做法，更鼓励的是：就直接和 Claude 交流，让它去弄清楚。第二点是，它其实是在努力表达这样一件事：code（代码）其实是一种解决问题的方式，而很多时候你通常不会想到要用这种方式。因为很多做 generative（生成式）slide decks、designs 之类产品的人，通常会选择这样一条路：他们会有某种 design system（设计系统），然后你去对接这个 design system。

这几乎就是一种传统、经典的 WYSIWYG 风格的设计方式。而在 Claude Design 里，我们想的是，好吧，我们能不能试着纯粹用 code，让 Claude 来生成这些 code？它会不会做得不错？我们在早期做了一些实验后发现，实际上，看起来它还真的有点能做到。

那我们怎么把这一点展示给全世界看呢？所以这算是一个例子。我们还有很多其他内部项目，这些大体都属于“表达 form factor”这一类。我们会先在内部试一试，它会在两周内显得超级酷，然后我们就继续做下一个东西了。

说实话，我们甚至从来不会把那东西正式发布出去。不过，没错，我们在那个方向上确实做了很多产品实验，那基本就是我们的 labs team 在做的事。然后还有第二类，那就是我们确实会看 TAM。毕竟我们是一家公司，我们确实会看 TAM。我们也会关注那些我们认为会发生合理的、agentic（具备 agent 自主性特征的）operations（运营/操作）的领域。

在这些领域里，我们确实更偏向那些更 token heavy 的东西。所谓 token heavy，或者我可能会说 token hungry，意思是，比如你完成一轮交互之后，回头看这一轮的结果，会问自己：我做完了吗，还是说我 actually 很高兴自己做了这件事，还想继续多做一点？我们喜欢那种对这个问题的答案是“我还想继续做”的行业。coding 显然就是我们都知道的一个例子。

coding 的好处在于，它实际带来的效果是：当你完成一轮之后，你会看着结果说，这太棒了，我感觉自己被解锁了。我还要继续做更多，我能构建更多，我能做更多事情。

但也有另外一些服务是这样的：你完成那一轮之后，工作其实就已经结束了，然后你就转去做别的了。你明白我的意思吧？所以我们往往会更进入那些更像是存在某种 iterative flow（迭代式流程）的方向：你会继续一起构建、继续生成更多内容。然后我们最后还会看的一个角度是，某些 business functions（业务职能）会是我们愿意去接触的 buyer（采购方）。

我们希望帮助他们优化 workflow（工作流程），帮助他们在那里创造出更好的产品。我觉得我们在一些 verticalization（垂直化）方向上一直都相当透明。比如我们做过 finance，也做过 legal。我们一直在努力收窄到一些更具体的领域，因为我们觉得，如果拥有正确的 context（上下文）和正确的 tools（工具），再把它们用合适的 form factor（产品形态）组合起来，那对我们来说大概率会是有用且可行的。

而在这些领域中的每一个，我们都在努力稍微展示一下“可能性的艺术”——也就是你可以通过哪些不同方式来实现这些结果。以 finance 为例，这就是个很好的例子。你可以是一家解决 finance 问题的公司，直接基于 Messages API 来构建，拿到一些 token，然后在其上搭建其他所有东西。或者你也可以基于 cloud managed agents（云托管 agent）来构建，这样你一开始就能获得更多开箱即用的能力。

或者你也可以说，我要做一个 plugin，或者说一个 connector，把它放进我们的某个产品里，放进这些 form factors（产品形态）里面。比如我们最近发布 Claude for Financial Services 时，就是在说：好，很棒，我们准备了一整套 skills（技能包）之类的东西，你可以选择在我们的产品里使用，也可以放进别人的产品里使用。我们甚至还发布了 cookbooks（操作指南），告诉你如何使用 Cloud Managed Agents 去完成这些事情。所以我觉得，对我们来说，这整体上都是一种实验：我们把这些不同的组件都提供给大家，然后看看他们会如何拿它们去发挥。

然后有时我们也会把这些东西整合成产品，本质上就是把所有这些能力打包起来。我觉得 Claw Tag 就是一个很好的例子。我们之前一直看到行业里有人这么做，比如 Shopify 用 River 做了这个，Square，或者说 Block，最近也用 BuilderBot 做了这个。这里面已经有好几个例子了：人们会说，我要在自己公司内部构建一个 agentic platform（agent 化平台），我要尽量给它提供所有正确的 context（上下文），还要让它能从 Slack 或其他你希望它可访问的平台上被使用。而我认为 Claude Tag 很大程度上就是把这些相同的东西打包在一起——任何人其实都可以选择自己去构建一个类似的东西，但这更像是在说：这是我们内部自己的做法；如果你想直接接上就用，那大概就是这个样子。

你觉得大家对 CloudStack 的误解是什么？因为当时有很多议论，说什么“天哪，这不就是个 Slack bot 吗”。那你给我们讲讲，Tag 真正神奇的地方到底是什么。

对，我觉得这是个很好的问题。我也确实认为，这其实多少展示了未来可能会走向哪里。对。我觉得，如果你看过去的产品，大家会说，哦，你其实非常依附于它的 form（形态）或者几乎就是它的 UI（用户界面）。对吧？

比如，它长这样，所以就超级酷。我觉得当你看 tag 的时候，也是这样。对。你和它交互的方式，就是你在 Slack 里直接 tag 它。所以，对，那就是 interface（界面）。但那其实并不是最重要的部分。

重要的是我们在底层做的各种 context engineering（上下文工程）以及 architecture（架构），这样 tag 才能真正“直接可用”。它真的应该感觉就像一个 coworker（同事）。就像一个同事——你知道的——如果你加入一家公司，入职之后，一个同事进入你的频道，然后你可以和它聊天，它会主动行动。它会判断什么是有用的。你可以——而且它就是会帮你把事情做完。

所以如果你从，尤其是非技术受众的角度来想，这就是一个巨大的 unlock（突破口）。你真的只需要建一个频道，然后你 @Claude，有时候甚至都不用 @Claude，然后你就说，嘿，我想做这个、做那个，我搞不清这个，还有我到底该怎么再次提交 expense report（报销单）来着？而传统上，如果你想想怎么解决这个 workflow（工作流），你得四处找信息，得去问你的经理，还得去问带你上手的 buddy，这真的非常非常复杂。而今天，你现在就只需要去和 CloudTag 聊。

而我们做了很多艰难的工作，比如 context engineering、proactivity（主动性），还有很多 harness（编排/控制框架）方面的部分。我觉得 Andre Kaparthi 说得特别好，这就像是一个 org level harness（组织级控制框架）。这里面内嵌了大量复杂性。就像 Kayla 提到的那样，你也可以使用我们的 APIs 去自行构建这些东西。

当然，你自己也可以做很多实验。但这是 Anthropic 对于如何为整个公司打造这种非常棒的、always on（始终在线）的 agent（智能体）的一种 opinionated take（带有明确产品判断的方案）。而我猜其中那个很“未来感”的部分在于，很多复杂性其实就像一座冰山，都是在水面之下的东西。那部分实际上正在变得越来越难，而那也正是更有价值的部分，是我们试图去推进和打通的。

我觉得我们会越来越多地看到这样一种情况：露出水面的那一点点东西，其实只是 interface（界面），而这个界面本身是可以不断切换的。比如今天，Slack 是很多人协作的地方，很多企业在上面协作，很多团队也在上面协作。但有些人是在 WhatsApp 群里协作，或者互发短信，也还有一些人依然通过 email 协作。而这些都可能成为实际的 form factors（交互形态）；你完全可以想象，agents（智能体）就直接进入这些地方，它们几乎是在采用人类一直以来所采用的同样的 form factors。

这几乎像是一种非常——几乎有点无聊的看法，但实际上我觉得它反而是最 forward（前瞻）的，因为你希望 agent，也希望 AI，本质上就像另一个人一样在帮助你。只是它非常聪明，能够理清所有上下文，而且你可以一直让它作为一个非常有帮助的 assistant（助手）陪在你身边。

完全同意。你刚才相当多地谈到了 context，以及 harnesses。所以你们团队对于打造一个卓越 agent 到底需要什么，显然有一套很鲜明、很有主张的观点。我想其中很大一部分，应该都归结到 context engineering 和 harnesses。

完全是。

也许你会分享哪些 best practices（最佳实践）或建议：在 harness 上有哪些地方必须做对，在 context 上又有哪些地方必须做对？