The Secrets of Claude's Platform From the Team Who Built It

一年后的这个平台，你觉得会发展到什么程度？

我们想要尝试一些方向，让 Claude 实际上能够非常擅长理解它自己。它会判断你应该用什么 model（模型），会判断如何启动所有 sub agents（子 agent）。你不用再花那么多心思去想有哪些架构，因为 Claude 实际上已经足够理解自己，能够在运行过程中即时重写自己。

在那样的世界里，如果 Claude 能够即时调整，你的 agents（agent）也会即时变成它们为帮助你完成目标所需要成为的样子，那么这个平台就必须进行非常严肃的大规模扩展。

我真正想问的是：我们离 Club making a billion dollars 还有多近？Angela，Caitlin，欢迎来到节目。

谢谢邀请。对，谢谢。

对于不了解情况的人来说，你们两位都在 Anthropic 负责平台相关工作。所以，Angela，你是 Claude platform 的产品负责人；Caitlin，你是 Claude platform 的工程负责人。我真的很兴奋能和你们聊，因为，首先，你们最近推出了很多东西。你们最近上线了 Claude Managed Agents，也一直在为它发布新功能。

而我觉得，这恰好处在一个特别有意思的时间点，让我开始思考：对于一家 model company（模型公司）来说，AI 里的 platform（平台）到底是什么。因为在 GPT-3 时代，平台就是一个 completion endpoint（补全端点）：你基本上就是发一个 prompt（提示词），然后得到一个 response（响应）。再往后，它变成了带有 tool calling（工具调用）、再加上一些 chat sessions（聊天会话）之类功能的 completion endpoint。再到现在，有了 Claude Managed Agents，你本质上得到的是一个运行在计算机上的 Claude，带有 memory（记忆）以及所有这些其他能力。

所以我其实是想——我很希望你们能帮我梳理一下这条演进轨迹，以及在 AI 里构建一个平台到底意味着什么。

对，我觉得，怎么说呢，你的概括非常准确。我觉得，随着很多这类技术从最初的 LM 逐步演进，把它封装到 API 之后其实是很有意思的一步。很多人当时都会觉得，哇，我可以用它做点什么了；在那个时候我觉得这已经很酷了。现在我们回头看，可能会觉得，哦，那其实还挺基础的。

然后，你知道，我觉得我们越来越多地走向了一个稍微更 stateful（有状态）的世界，因为你会希望持久化这类 session state（会话状态），从而确保模型的表现越来越好。我觉得这其实大概就是贯穿始终的一条主线。随着我们不断改进 Claude，让它持续变得更强、也更 autonomous（自主），我们会发现自己基本上需要把平台演进成更高阶的 abstraction（抽象）。但这么做的目的，其实都是为了帮助你从这个系统里拿到最好的结果。我觉得在最开始的时候，大家都非常 exploratory（探索性）。就像是，谁也不知道人们会用这些 LLMs 构建出什么，所以你会希望尽可能把各种可能性都开放出来、让它们可用。

然后，随着这些 use case（用例）开始逐渐收敛，人们开始用它做产品，现在也开始用它来构建 agent。越来越多的事情都变成了：客户来问我们，怎样才能把 Claude 的能力发挥到最好？我该如何设置我的 tools？我该如何运行这个 loop？以及诸如此类的问题。

有些人确实非常非常爱做实验，他们在边界地带探索，这很好。然后还有一大批其他人进来时会想，我其实希望这里面很多东西都是 out of the box（开箱即用）的。为了确保 Claude 基本上能够产出最好的结果，我们发现自己会不断把这个平台做得越来越丰富、越来越丰富、越来越丰富。而这其中包含的，既有 state（状态），也有你开始看到我们加入的那些 tools，还包括很多这类东西里近似 cloud components（云组件）的部分。但这一切追求的其实还是同一个使命：就是让事情真的尽可能简单。

我觉得，可能从更往前看的状态来说，就这类事情的平台哲学而言，一个平台最终会做的，大概就是：它提供一组 primitives（基础原语）和 infrastructure（基础设施），让你能够以尽可能快的速度、尽可能少的工作量，拿到你想要的结果。我觉得，至少在当前这个阶段，这通常会呈现出某种特定的 form factor（形态）。对，不过，是这样。

那你会如何描述今天这些 primitives 是什么？或者也可以直接这么问：Cloud Managed Agents 里的 primitives 是什么？

对。Cloud Managed Agents 是构建在我们同一套 primitives 之上的；如果你愿意，本来也可以直接基于它们来开发，比如 messages API。而在 messages API 里面，我们围绕 API 又做了很多我想可以称作 innovations（创新）的东西。比如，如果你真的只想做最基础的事，你当然可以只是让 tokens（词元）进出；但你也可以使用我们的一些 built-in tools（内置工具）。你可以用 code execution（代码执行）之类的功能，拉起一个 sandbox（沙箱）并执行工作。

你还可以使用，比如说，web search（网页搜索）以及各种不同的这类能力。所以我觉得，我们是把其中那些我们认为最强大的能力提炼出来，整合进一个 harness（执行框架）和一套 infrastructure 里；而这套东西，就是我们认为能从 Claude 身上拿到最佳结果的方式。

所以我现在坐在这里，有一种我一直称之为“时间通缩”的感觉。也就是说，相比之下，在未来我的时间会变得更有价值，而不是相反——不管相反该怎么说——不是说未来我的时间会变得更不值钱。原因在于，我们现在非常……比如说，就我们内部而言，我们正在构建一个 agent（智能体）。我们在做一些 agent 产品，也就是那种先在内部替我们完成特定任务、之后希望也能给客户使用的 agent。为了做到这一点，我们现在就是，比如你知道的，我们有几台 Mac minis，在上面让 Claude 在循环里运行。

对吧？其中很多东西就是一个大概一千行的 Python 文件之类的。而且这其中很多内容，和你们正在做的 Claude managed agents 很像。所以对我来说——我觉得对很多基于 Cloud 或者 Cloud 平台、生态来构建的人来说也是这样——至少我自己会有这种感觉：也许我们应该干脆等你们把它做出来，但我又不知道边界到底在哪里。

所以，我确实有点想知道，如果我想构建一个 agent，怎样做才是最佳路径，才能和你们正在做的方向保持一致？

对，我觉得你知道，这一部分的平台业务，其实和其他任何形式的平台业务都多少有些类似：确实会有像你这样的客户在构建东西，而你会想，我是不是应该直接自己做，因为我眼下确实有这个即时需求；但与此同时，你也不太想把这些工作重复做一遍，因为本来你其实可能直接就能免费从这个平台里拿到。对。

而且基础设施真的很糟。确实。对。像启动服务器这种事真是烦透了。我真不敢相信你们一直都在做这个。

那就是

很大的一部分。大家都会说，哇，这真不错。不过我也确实想说，我们后来之所以会去做 Cloud Managed Agents，部分原因就是 Anthropic 自己已经经历了足够多轮这样的迭代：我们构建过一些产品，它们本质上就是可以在 cloud（云端）自主运行的 agents。我们已经把那套基础设施搭起来、让它能够良好运作，这样的事情做过足够多次了，所以连我们自己都觉得，好，别再只是为自己重复造这个了。我们要一次性把它按真正可行的方式做好，既基于我们学到的一切，也为了所有正在做这件事的人。

比如，你也许可以把你现在跑的那些东西放在几台 Mac minis 上运行，对吧？对很多人来说，那可能就够用了。但我认为，如果你是在把 agents 集成进自己的产品里，并且你运行的东西是真正有规模的，那么基础设施这件事就会变得越来越有挑战，想把它做对也会越来越难。

那真的很有意思。

对。然后也许为了回答你问题的另一部分，我觉得这里有两层理念。其一有点体现在我们设计 managed agents 的方式上，也就是我们会尽量把它做得足够模块化。比如说，在某些部分上我们会比较有明确倾向，因为我们觉得那些部分就应该，你知道，非常紧密地和 Claude model 结合在一起。但与此同时，很多时候，比如我们希望 Claude 能非常明确地去使用 file systems（文件系统）。

这算是一个非常特定、很 Claude 风格的——

你是说以某种特定方式使用，还是只是泛指 file systems？

只是 file systems 本身。我们也真的很想强调 skills。我知道很多人都喜欢 skills，但这确实是我们在核心上非常有明确倾向的一点。所以我们对这类 primitives（基础原语）会比较坚持。比如，用 file systems，用 skills。

它们其实都非常基础。但与此同时，我们仍然会看到有人在尝试别的方法来做这些事。我们想做的是，帮助你在开始构建时就尽量站在一个更好的起点上。所以这是一部分，也就是那些更“有明确倾向”的部分。不过，对于我们这整套产品中的每一个 endpoint 或 API，我们也会尽量在某些方面把它们开放一些。

所以，有些东西是我们正在往前看的方向。也就是说，也许今天还没提供，但在设计上，我们会尽量让它足够灵活，让大家能够加入不同的部件，因为我们也意识到，这个 API 或这组 APIs 未必能在它最初的构造下解决所有问题，总会有一些部分需要开放出来。然后第二点是，我们对此其实也讲得比较公开：当我们设计很多这类东西时，我们也会发布 blog posts，以及某种 reference implementations（参考实现）。所以如果你至少想从这种构造中获得一些启发——对——但又想基于 messages API 自己做一套，那当然也是可以的。

我觉得这也呼应了你刚才提到的点，这件事现在也正在我们这边出现。再说一次，我们现在有一些 Clouds 跑在一台 Mac Mini 上，配一个 Python 文件；另外还有几个更大、更严肃一些、跑在 cloud infrastructure（云基础设施）上的实现，我们正在思考该怎么处理它们。我想我今天也跟团队提到过，我们今天会聊这个。我觉得他们其中一个问题，或者说一种顾虑，是在考虑把 cloud managed agents 用在这类场景、为我们的客户 spin up agents（启动 agents）时，目前的状态更像是——我们有一个 playground。我们只是有个小环境，有一台 server 或一台 Mac Mini，然后就可以把东西直接 pipe 给 Cloud。

它能做 Cloud Code 能做的任何事。它有文件系统，也有浏览器，基本上各种东西都有。要是我们想把它切换成 GPT 5.5、Gemini 或别的什么，做起来也相当容易。

所以是不是会有这样一种感觉：他们会觉得，如果我们用 Cloud managed agent（云托管 agent），我们就会被套进去，而且就没法灵活地做我们想做的所有事情了。另外大家也会担心，某些功能会先出现在 Cloud Code 本身里，而 Cloud Managed Agent 可能要过一段时间才会有，这样就会让我们没法始终站在前沿——而这恰恰是我们对客户、其实也是对自己做出的承诺。比如说，我们就是很喜欢第一时间去做那些最新的东西。你怎么看这个问题？

对，我觉得从我们内部的工作方式来看，比较好的一点是——这么说吧——我们在运行这个 platform（平台），而多数人通常理解的 platform，是我们对外提供的 APIs（应用程序接口）以及整套 API 服务。但实际上，我们团队其余很大一部分工作，是做 internal platform（内部平台）：也就是说，我们所有的 first party products（第一方产品）也是直接构建在和其他所有人相同的平台之上的。所以这件事很酷的地方在于，我们把很多时间——倒也不是全部

时间，但确实有很

大一部分时间——都花在和内部那些基于这个平台构建产品的团队一起工作，帮助他们实现想做的功能，交流想法，诸如此类。所以我觉得，随着时间推移，你可能会看到这种分化越来越少——比如说，Cloud Managed Agents 里能用什么、coworker、Cloud Code 里能用什么，虽然它们可能都建立在同一套基础设施之上，对吧？我觉得这是理解这个问题的一种方式。对。然后我还觉得，

关于你提到的——或者你团队提到的——这种 model lock-in（模型锁定）担忧，我觉得这是合理的。很多人确实都有这种顾虑。我觉得我们现在正处在一个有点演进的阶段：如果你回头看，哪怕只是几个月前，构建一个非常、非常、非常通用的 harness（封装框架）还是很标准的做法。它超级通用，然后你就可以在这些东西之间热切换不同模型。我觉得对于上一代模型来说，跨不同 labs（实验室/模型提供方）这么做还算行得通。

很多事情当时的发展速度，让我觉得那样做还算是某种程度上合理的。但我觉得现在，到了下一代模型，以及从未来趋势来看，你会从每一家 lab 那里都多少看到这一点：大家都在用略有不同的技术和视角，来推进各自那一类模型的发展。所以理论上，你当然可以去做一个把所有这些都覆盖进去的 superset（超集）。但更多时候，我觉得，当你为你的公司或者客户构建 agents（智能体）时，你最终真正想交付的其实是某种 outcome（结果）。

所以我觉得，这里的抽象层级——也就是你真正要去热切换的对象——会不再是那种非常通用的 harness 加上可热切换的模型；而会变成 harness 和模型高度配对的一体。你仍然需要冗余，也仍然可能想在某些场景里用其他模型，但你大概率会在 agent 这一层来做这件事——也就是 harness 加模型这一层——而不一定是采用另一种架构：先做一个极其、极其通用的 harness，再去热切换底下的所有东西。

这真的很有意思。我不知道，像 Cursor 这类产品现在是这么做的吗？比如，他们会为每个 model 单独配一套 harness（运行/调用框架），还是用一个通用的 harness，然后把不同 model 在里面来回热切换？你知道吗？

我也不完全确定。我的直觉是——具体 Cursor 我不清楚——但我们聊过的一些团队，确实也大致形成了类似的看法。主要原因是，他们就是在努力把每个 model 的能力尽可能压榨出来，几乎像是在做 harness engineer（harness 工程）一样，把每一个细微差别都利用起来。然后，你知道，我们自己也有一个例子——严格说不算外部客户，而是我们内部做过很多的一件事。比如说，我们最近就在 managed agents 上反复研究过 memory。

而且我们自己也试了很多不同的 harness。我们试过一个，就是后来真正上线的那个；也试过很多其他版本，用了各种不同的技术。至少对我个人来说，当我看到团队跑出来的 eval suite（评测套件）结果时，这些 harness 的表现差异非常大。所以我觉得，哪怕只看这种例子，也足以说明：如果把合适的部件用对的方式拼起来，光靠 harness engineering（harness 工程）本身，你就能实现非常大幅度的 hill climb（爬坡式优化）。

我觉得，如果把这个思路推广到所有 model 组合、所有不同 lab、各种不同 provider 上，这种构造方式里面其实有非常多 alpha（超额收益/优势）可挖。所以如果不只是我们自己，其他人也在尝试这种程度的“绑单元”式做法，我一点也不会惊讶。

很有意思的一点是，这里面存在一种 path dependence（路径依赖）：你一开始会对 request 和 response 怎么做、tool call（工具调用）怎么做、或者要不要让 model 使用 file system（文件系统）之类的问题做出某种选择。对。然后这些选择就会在某种程度上改变——

——所有这些不同 model 的发展轨迹。而且当时看起来，也许只是个很小的决定，几乎像个脚注一样。对。但最后它会变得非常重要。

你觉得这最终会不会影响 model 的 generalizability（泛化能力）？就是说，到某个阶段，它们会不会被锁进一些自己擅长的“赛道”里，比如 Claude 很擅长 file system，而 OpenAI 的 GPT 又擅长别的东西。那样的话，如果它被锁定在一种特定的做事方式里，这会怎样进一步影响 model 的“个性”和行为模式？

我确实觉得，这种情况实际上会在某种程度上把 model 锁住。所以，我们最终会当作“正确路径”和“正确 primitives（原语）”的那些东西，必须经过非常谨慎的思考。因此我觉得，在某些时期，某些其他 model 会变得特别特别擅长 reasoning（推理），然后它们又几乎会在这种推理层面上过度优化。与此同时，也还有另一种视角会问：好，没错，我们希望它在 computer（计算机操作）方面也非常强。

比如，也许 computer 这一部分才是有意思的部分。所以如果你把一些 primitives（原语）想透，我们可能会做对，也可能会做错，但至少我们会经历这样一个思考过程，而这大概率至少会把我们引向某一条路径。我觉得很难说到底哪个方向本身最终会被证明是对的，但我确实认为，最后会走成什么样，很大程度上取决于 path dependency（路径依赖）。所以，认真思考你到底选择纳入什么，或者让 model（模型）原生具备什么，是非常重要的。

那有没有哪些 path dependency（路径依赖）是你们后来不得不回退、纠正的？

很可能有。我没法就 Anthropic 这个层面说太多，我来这里才几个月，但我可以想象这种情况肯定发生过。我的意思是，我们做过实验——包括在其他 labs（实验室）也是一样——我们需要关注的那类 primitives（原语）一直都在变化。你确实会碰到某种局部最优点，然后重新思考：好吧。

也许我们应该采用一种更通用的方法。

对，很有意思。我想稍微退一步，问你一个也许我一开始就该问的问题：Cloud Managed Agents 到底是给谁用的？对吧？我今天早些时候自己搭了一个。

我们这边已经有人在 Every 内部把它用于 production（生产环境）了，而我今天也刚做了一个。我非常喜欢你们那种 getting started chat（入门聊天）体验，还有你们提供的一些示例。这让我感觉，即使我不是技术人员，我可能也会想用它来搭一个 agent（智能体）。它也许还是有一点复杂，但我实际做的事情是——说这个有点抱歉——我是在 Codex 的 app browser 里完成的。所以是 Codex 在驱动整个 managed agent（托管式智能体）的设置过程，而它很快就帮我把一个 Slack bot 跑起来了。

真的特别酷。所以你在设计这些东西、设计 cloud managed agents（云端托管式智能体）的时候，会怎么思考它到底是给谁用的？

对，所以这点很有意思，因为我觉得你说得对，尤其是那个 quick start（快速开始）体验。我们其实非常坚定地想把它发布出来，但并不只是为了让非技术人员也能去构建 agents（智能体）；更准确地说，是想让任何人——不管是否技术背景——都能够理解这些 primitives（原语）到底是什么。

下面说说它能做什么，以及这些部分是如何组合在一起的。

没错。比如，你知道，它也有一部分是偏教育性质的。但我觉得，当我们思考它是给谁用的时候，我们会想到几类不同的人。一类是我们看到公司内部有人在构建 automation（自动化），或者搭建非常强大的 platform（平台）或 system（系统）。比如我们见过有人说，我想要一个完整的、端到端的 software development platform。

对吧？像 ManageEngine 就是这类需求的一个完美解决方案。或者说，我想把这边一个小流程自动化，比如 legal（法务）需要审核我的 marketing copy（营销文案）。对吧？类似这样的事情。

所以你不应该每次做这些的时候，都还得重新实现 memory（记忆）之类的东西。没错。所有那些东西。

每次做这种事的时候都不该如此。对吧。你可以非常快地开始，也可以很快让某个东西跑起来。另一个我们当前最关注的用户群体，是那些把这些能力构建进自己产品、并提供给客户的人。所以这是另一类用户：确实，你仍然会想要大量 customization（定制），你也仍然想做出一个对你的产品来说非常强大的东西，但我们依然非常、非常相信，不把 engineering resources（工程资源）花在 infrastructure（基础设施）以及各种零碎的 harness engineering（支撑工程）调优这类事情上，是更合理的。

我们为什么不能像一个月前那样聊上一次？那样你本来可以省下很多时间。

我们还是得

多聊聊。

不过我确实有点好奇。好吧。所以也许 infrastructure（基础设施）就是其中一类问题。但当你看到人们搭建 agent（智能体）时，你觉得他们认为什么才是难点，而最后真正的难点又是什么？这两者是同一件事吗？

问得好。我——我也许，这个说法我不知道，可能有点 spicy（有争议）。我不太确定，但我觉得——我觉得人们会认为 harness engineering（封装/调度框架工程）这部分才是难点。嗯哼。所以实际上，比如说，之前我们发布了 Aegion SDK，我想你们现在在 Mac mini 上用的就是这个。

对很多人来说，他们会觉得，好的，太棒了。我就不用去做 harness engineering（封装/调度框架工程）这部分了，不用自己处理 prompt caching，也不用去尽量扩大我的 context window（上下文窗口），以及诸如此类的事情。

我觉得我们其实只是直接在 bat 里用 Claude，比如 Claude dash p 这个命令。

哦，哇。对。好吧。

它——它挺不错的。

对。

对。

很酷。不错。好。很酷。不过不管怎样，你们这么做还是因为这样就不用自己去搭建 harness（封装/调度框架）了。

对吧？但我确实觉得，我们在很多客户身上看到的是：好，现在我想把那个东西真正投入 production（生产环境）并把它扩展起来，结果所有人都会撞上一堵基础设施墙。就像每个人都会遇到同样的问题：哦天哪，我要么得让一台 server（服务器）一直运行，要么就得用那种会 spin up 和 spin down（拉起和关闭）的方案；我还得存 transcript（对话转录）数据，还得有安全的 sandboxing（沙箱隔离），以及诸如此类的一堆事情。所以你知道，如果你启动了一个堵住的 code session，或者你在 sandbox 里启动了 agent SDK，而那就是你正在运行的东西，但你的 sandbox 断连然后挂掉之类的，那你的整个 agent 也就跟着死掉了，对吧？所以我觉得，尤其是基础设施这一块，是大多数人最后都会撞上的那堵墙；但他们原本更以为，真正更难的部分会是 harness engineering（编排/驱动工程），以及如何把 model（模型）的能力尽可能榨出来。

对，我完全同意。我刚才正想说，我们现在接触到太多人了，他们已经到了这样一个阶段：原型做得非常快，他们也特别兴奋，而且看起来它确实能做成那件事。但与此同时，也有一类人真的在更用力地往前推，他们会说：好，我确实想做 hill climb（爬坡式优化），我真的想去打磨最难的部分。

但一旦你真的有了那个东西，把它 productionize（工程化并上线到生产环境）简直就是噩梦，尤其是那种更有意思的、长时间运行的 async（异步）agent：你希望它们能更远程一点、更自主一点。而且大家基本都会撞上那堵墙。这也是我们为什么会构建现在这套东西的一个重要灵感来源。

我觉得，agent 的一种形态示例就是 OpenClaw。尤其是，它在我们内部带来的东西是：你有一个在 Slack 里始终在线的 agent，它有自己的个性，也有自己会去处理、会逐渐负责的那一部分世界。你们觉得，这会不会是一种可能的未来——比如，一个 one-click（一键式）agent，直接活在我的 Slack 里；没错，我可以去配置它内部的各种东西，但我其实不需要真正去操心所有那些技术基础设施方面的事？因为我觉得你们已经有了这方面的雏形，但从当前这种 managed agent（托管式 agent）到一个始终在线、存在于我 Slack 里、还需要我去设置和定制的东西，中间还是有不少步骤。所以这算不算是 platform（平台）职责范围内的事，还是说它已经太偏 product（产品）方向了？

不，这绝对是我们非常想做的事情。我觉得，我们一开始把很多精力放在基础设施这一块，主要是因为我们确实在这里看到了很多这样的痛点。但对，怎么说呢，我不想把它直接称为最终形态，不过在它更成熟、更高级的形态里，我们其实确实想做到：让你可以非常非常轻松地部署这些 agents。我们已经朝这个方向做了一些比较轻量的尝试。

比如说，我们把 vaults 也纳入了 primitives（基础构件）之一，算是一种……

所以 vaults 存的是你的那些 key（密钥）之类的东西？比如你的 OAuth keys？

Credentials（凭证）。

凭证。对。算是先从解决一些更底层的部分开始。但一旦你能以一种更安全的方式，把这类更偏 agent identity（agent 身份）这一类的 primitives（基础构件）封装起来，而且可以非常容易地处理它，并且它还能和整个系统配合工作，那么我觉得，很自然我们就会走到这样一个阶段：也许你只需要一键完成 Slack integration（集成），或者甚至你只要直接告诉 Claude，比如说，加上 Slack，然后它就会把所有事情全部处理好。接着不知不觉间，你那个小 bot（机器人）就已经会在 Slack 上 ping 你了。

我很喜欢。我已经等不及那样的世界到来了。agent 最好的内部 use case（使用场景）是什么？因为我觉得现在有一个很大的问题正在发生：好吧，没错，大家都在用 Codex 或者 Cloud Code，但现在我们又有了这些运行在 cloud（云端）里的 agents。现在公司里的每个人，感觉上都可以拥有自己的 agent。

有团队级的 agents。也有公司范围的 agents。所以你观察到的模式是什么？就是说，当人们做出真正有用的内部 agents 时，他们通常会做什么，这些 agents 看起来又是什么样的？

对。我会说，这和——而且我们其实已经在一些更偏 AI pilled、AGI pilled 的公司里看到过几个这样的例子——比如 Stripe 做了 Minions，他们也经常谈这个，把它当作工程师可以使用的一种端到端开发平台。我觉得 Ramp 也做了类似的东西，而我们自己也做过类似的事情。对吧？挺有意思的。

对。我们在内部构建过这类平台，基本上就是——你知道——我有一些正在运行的 agents，我可以从 Slack 或者别的地方和它们交流。对吧？而到了某个阶段，那实际上就变成了托管型 managed agents（受管 agents）之上的一个相当薄的薄层。你并不需要做很多事情就能实现

这也是我在想的。比如我看了 Minions，或者 Ramp 在做的那些东西，我当时就在想，为什么？你懂吧？所以，做一个那种任何公司员工都能使用的、比较薄的一层 coding agent（编码 agent），它真的有用吗？或者说，为什么不直接在 Slack 里安装 Clot app？

对。我会说，这样的平台和我们内部做过的一些东西之间的区别在于，你可能会想做很多定制化，尤其是在 agent 实际运行、并且能够验证自己改动的 development environment（开发环境）上，对吧？以及诸如此类的事情。

比如说，这就是我们的 CICD 是怎么运作的。

对，完全没错。所以，你知道，我觉得对非常非常多的人来说，Cloud Code 是一个很棒的工具，对吧？而且你可以用 Cloud Code 运行 Cloud Agents，这确实非常好。

但我觉得，如果你想做更偏端到端的开发，对吧，而且你可能还想把更多自定义的东西内建进去，那你就可以从 managed agents 这样的东西开始，在它上面再搭一层，最后做出一个可能更接近那种端到端体验的东西。