EP144｜揭秘 Claude Tag 背后的产品哲学：是“主动型队友”，而非工具

校订版逐字稿｜音频时长：01:03:31｜生成日期：2026-08-11

校订说明

• 本稿依据用户提供的中文音频逐段转写，并用原节目页面的英文转录、章节和 Anthropic 官方产品页核对专有名词。
• 已校正 Claude Tag、Claude Code、Lamis Mukta、Simon Maple、Guy Podjarny、Tessl、METR、Linear、Pull Request、Managed Agents、Dreaming 等名称。
• 保留口语重复和原音频中的宣传段落，不把总结或二次观点混入原话；只统一了标点并修正明确的识别错误。
• 说话人时间点根据英文原节目与中文翻译音轨分段对齐，个别快速接话处可能存在数秒偏差；如用于正式引用，请回听相应时间点。

说话人

• 中文节目主播：Jerry（《西经东译》）
• 原节目主持人：Simon Maple（片尾同时提及 Guy Podjarny）
• 嘉宾：Lamis Mukta，Anthropic Member of Technical Staff，Applied AI 团队

逐字稿

00:00:00｜中文导语与节目引语

[00:00:00] 中文节目主播 Jerry：

大家好，欢迎收听《西经东译》。如果你和我一样厌倦了在同质化的AI二手信息中打转，渴望第一时间了解彼岸的优质内容，但又苦于语言的壁垒，那么这个播客就是为你准备的。我是主播杰瑞，一位深耕AI领域的产品经理，很荣幸能为你搭建这座跨越语言的桥梁，带你零距离追踪全球一手的顶尖播客。欢迎关注同名公众号，获取更多内容。想象一下，你的AI助手不再只是被动的等待指令，而是像一个真正的队友那样主动出击。他能主动发现问题，提醒你需要关注的事项，甚至独立完成从创建工单到提交代码的完整工作流。

[00:00:53] 中文节目主播 Jerry：

这听起来是不是有点科幻，但这正是Anthropic正在用Claude Tag实现的未来，他们的内部数据简直令人震惊，产品团队高达 65% 的 Pull Request 现在都由Claude Tag主动开启，这已经不是简单的辅助工具了，它正在成为开发流程的核心协调者。正如我们的嘉宾Lamis Mukta所说，Claude Tag的设计初衷就是成为你的Proactive Teammate，主动型队友。那么，这种拥有长期记忆和跨渠道情境感知能力的AI代理，究竟是如何改变我们与代码的互动方式的？

[00:01:30] 中文节目主播 Jerry：

让我们深入探讨这场正在发生的变革。

[00:01:37] 嘉宾 Lamis Mukta（节目引语）：

Claude Tag是你的主动型队友。Claude Tag真正的特别之处在于，它拥有你在使用Claude Code时所熟悉的所有连接器、工具和上下文，但它增加了一种全新的主动性。以及更强的持久力。能够长时间地跟进并完成一项工作。自从我们内部开始使用Claude Tag以来，我们产品团队里有65%的PR都是由Claude Tag开启的。我觉得，在某种程度上，这款产品真正体现了我们今天所看到的模型能力的发展方向，而且它现在已经成为了我们日常工作中绝对的主力。

[00:02:18] 节目旁白：

AI原生开发者是一档面向开发者和工程负责人的播客，聚焦于AI和智能体编程的最前沿。每周，我和你的主持人Guy Podjarny，还有我Simon Maple，都会与AI领域最激动人心的声音进行对话，共同探讨当今开发者面临的重大问题。这里是AI原生开发者，我们刚刚结束了在伦敦举办的为期两天的AI开发者大会，活动非常精彩。而更棒的是，今年11月，我们将在纽约市再次举办。没错，11月3日和4日，我们将重返这座不夜城，带来更多精彩的会议，极具吸引力的实战工作坊，以及更多丰富内容。

[00:03:05] 节目旁白：

当然，还有你们所期待的社交、派对和美食美酒，这些都是AI开发者大会的标配。我们相信我们拥有业内最棒的会场交流氛围。这与我们邀请到的顶级演讲嘉宾，形成了完美的互补。本次大会将同时以线下和线上直播的形式进行，所有主舞台的主题演讲和分享都可以在线观看。现在就报名吧，限时抢购价仅需100美元的超级盲鸟票，我们真的非常期待能再次回到纽约，希望能在那儿见到大家。

00:03:43｜认识 Lamis Mukta：Anthropic 应用 AI 团队

[00:03:43] 节目旁白：

大家好，欢迎收听新一期的AI原生开发者。今天，我非常荣幸地请到了来自Anthropic的技术专家Lamis Mukta，欢迎做客我们的播客。你好，Simon，今天能来这里，我真的非常高兴。

[00:03:58] 主持人 Simon Maple：

太好了，我们今天会深入聊聊智能体编程这个话题，探讨Anthropic内部是如何使用Claude进行智能体开发的。当然，还要热烈祝贺你们最近刚刚发布了Claude Tag，我们马上就会详细聊到它。不过，Lamis Mukta，在那之前，能先简单介绍一下你自己以及你在Anthropic的角色和主要工作吗？

[00:04:24] 嘉宾 Lamis Mukta：

当然可以，我是 Anthropic 的一名技术专家，隶属于我们的应用AI团队。这个团队的角色很特别，它介于产品研发和市场推广之间。我们的工作内容也很多元，一方面会直接和客户合作，我个人主要是和初创公司以及创始人打交道。

[00:04:41] 主持人 Simon Maple：

另一方面，我们也会和公司的产品及研究部门一起，参与一些内部项目的开发。太棒了，我们今天确实有很多内容要聊，那我们就从那个最激动人心的消息开始吧。就在不久前，Claude Tag正式发布了，你们内部肯定已经用了好几个星期了。

00:04:54｜Claude Tag 是什么：从被动响应到主动协作

[00:05:00] 嘉宾 Lamis Mukta：

给我们介绍一下Claude Tag吧，它到底是什么，你们是怎么使用它的。Claude Tag可以理解为你一个主动性很强的队友，它就在你的工作流里，目前是在Slack中。它的特别之处在于，它具备了所有你在使用Claude Code时习惯的连接器、工具和上下文。但它又增加了一层额外的主动性和持久性，能够长时间地跟进并完成一项工作。而且就像我们说的，它还能同时与你和你的队友协作。这太棒了，其实在我们团队内部也一直重度使用Claude Code，而且我们有一种用法，听起来跟你说的有点像。

[00:05:38] 主持人 Simon Maple：

所以我很想知道它和我们现在用法具体有什么不同。我们是在Slack里集成了Claude，所以经常会直接@Claude来帮我们做一些事情。这个功能已经用了有一段时间了。那么，在Slack里直接@Claude和使用Claude Tag，这两者之间到底有什么区别呢？你问的这个问题特别好，因为从表面上看，这两者确实很像。但真正有趣的区别其实都藏在底层。首先，Claude Tag的主动性非常强，它能自己去执行一项任务，而且是长时间地执行，直到任务完成后再回来通知你。

[00:06:16] 嘉宾 Lamis Mukta：

所以它真正利用了现在AI 智能体能够长时间处理任务的这种能力，这是第一个区别。第二个区别是，通常情况下，你需要通过提问来触发智能体，然后Slack里的Claude才会给你回复。但Claude Tag呢，它有时候会主动来找你，提醒你某件事需要你关注。所以，这再次体现了它的主动性。此外，它还拥有记忆和上下文能力。这个能力可以跨越不同的频道，从而理解整个团队的工作内容。因为它同时与你所有的队友进行交流，这种上下文信息是会随着时间不断积累的。所以，这就不再是那种一次性的孤立的互动了。

[00:06:53] 嘉宾 Lamis Mukta：

Claude Tag能够突破单次会话和个人用户的限制。哇，这太酷了。所以，它几乎可以主动发起对话了。它完全可以做到。我们通常是这么用的，在Slack里直接调用，或者说@Claude。我不该说Tag，就是@Claude这个用法。我们的流程通常是，大家先在Slack里讨论一个需求，一个新功能，或者可能是一个bug。然后我们可能会@Linear，说需要为这个创建一个工单。紧接着，我们就会直接@Claude，说，麻烦你把这个实现一下。然后，它会很快回复说，好的，我会利用当前这个对话的上下文。当然，它也了解整个代码库。

[00:07:40] 嘉宾 Lamis Mukta：

最后，它会给出一个Pull Request，问我们，你看一下这个可以吗？

[00:07:44] 主持人 Simon Maple：

我们检查后会说，没问题，看起来很棒，合并吧。然后，事情就搞定了。所以听下来，这里有几个关键的不同。第一个，显然就是历史记录。听起来，它能知道整个Slack，甚至更广范围内的所有过往互动，对吧？这是你刚才提到的第一点吗？完全正确。关于上下文这一点，我们在Claude Tag里建立了一整套权限系统。而且你可以根据自己的需求，对权限进行精细的控制和调整。但基本上，它的作用域是精确到频道级别的。所以，如果这是一个专门讨论功能需求的频道，它就能掌握大量关于历史功能请求的上下文。

[00:08:27] 主持人 Simon Maple：

比如，通过技能设定，了解处理这些流程的端到端标准做法。如果配置得到，它还能获得搜索其他公共频道的能力。比如说，你可能有一个客户支持频道，里面有关于某个问题来源的更多背景信息。只要获得了权限，Claude Tag就可以访问这些信息，并把它呈现出来。而这些信息可能连你自己都看不到。所以，这是第一点，就是它拥有的上下文窗口或者说记忆范围更广了。我记得你刚才提到，在创建了Linear工单之后，你们会去Claude Code里执行具体的开发任务，对吧？

[00:09:03] 嘉宾 Lamis Mukta：

通常是这个流程吗？是的，没错。所以这里要强调的一点是，有了Claude Tag，你完全可以在 Slack 的一个对话线程里，完成整个端到端的全部工作流程。我们来想象一个场景。在Claude Tag的世界里，一条用户反馈进来了。你可以把它配置成，让Claude Tag首先捕捉到这条反馈，然后根据它设定的技能和工作流，自动 @所有它认为应该参与响应的人。接着，它还可以自动创建Linear工单。因为这是你配置好的工作流程，它通过观察和学习就能掌握。最后，也是我认为最关键的区别在于，

[00:09:39] 嘉宾 Lamis Mukta：

你再也不需要打开Claude Code去手动执行任务了。它可以直接理解下一步就是开始写代码，于是它能自己启动一个沙箱环境，在你的代码仓库里开始工作，然后在Pull Request准备好之后，再来通知你。它甚至还能做一些验证工作，确保代码实现，满足了最初工单里提出的所有需求。所以，我们在这里看到的是一个更彻底的端到端的自动化。如果你希望它能完整地执行，从创建工单到执行代码前征求你的同意，再到推进PR，提醒相关人审核等等一系列操作，它都能主动完成。

[00:10:15] 主持人 Simon Maple：

因为它拥有完成这项工作所需的所有上下文和记忆。

[00:10:18] 嘉宾 Lamis Mukta：

听起来，它更像一个总指挥了。也就是说，以前我可能需要自己去Linear说，为这个建一个工单。但现在，好像只要我把Claude Tag叫进来，它就能在后台帮我把这些事都办妥。我就可以更专注于我想要实现的功能本身，而不是那些繁琐的流程机制。完全正确。说到底，这其实是让每个团队自己去决定他们希望在工作流的哪个节点去引导这个AI助手。你可以非常明确地设定一些关卡，比如，这些操作你绝对没有权限执行，或者，在这些方面，你必须先征求我的意见。而且我们的观察是，因为Claude Tag能够随着时间不断积累记忆，

[00:11:01] 嘉宾 Lamis Mukta：

它会对团队的工作流形成一种非常好的感觉和默契，并且会自我调整。而且，它的行为方式是可以被精确控制和调整的，但本质上，它的作用域是限定在频道级别的。比如说，如果这是一个专门讨论功能需求的频道，那它就拥有大量关于历史功能请求的上下文，并且通过它的技能，它也知道处理这些请求的完整流程是怎样的。所以，只要配置得到，它就能掌握大量的历史信息和上下文。同时，它也能搜索Claude Tag所在的其他公开频道。也许你有一个客户支持频道，那里有更多关于某个问题来源的背景信息，只要给予权限，Claude Tag就能访问这些信息，

[00:11:42] 嘉宾 Lamis Mukta：

并把它呈现出来。这甚至可能超出了你自己的可见范围。所以，这是第一点，就是它拥有的上下文窗口，或者说记忆范围更广了。第二点，你刚才提到在Linear上创建了工单之后，你是不是会去用Claude Code来执行？是的，我们通常的流程就是这样。好，这里我想说明的一点是，你完全可以在Slack的一个对话线程里，完成端到端的整个工作流。我们想象一下这个场景，一条用户反馈进来了，在Claude Tag的世界里，

[00:12:12] 主持人 Simon Maple：

你可以把它配置成这样。首先由Claude Tag捕捉到这条反馈，然后根据它的技能和工作流设置，自动 @ 所有它认为应该参与回应的人。接着，它还可以自动创建一个Linear工单，因为这是你预设好的工作流程，通过不断的提示和学习，它已经掌握了。最后，也是最关键的区别在于，你不再需要打开Claude Code，去命令它执行任务了。它能直接理解下一步的工作，就是开始写代码，所以它会自己启动一个沙箱环境，如果获得了仓库的访问权限，它就会开始在你的代码库里写代码，

[00:12:47] 嘉宾 Lamis Mukta：

等PR准备好了再通知你。它甚至还能验证代码是否符合最初工单里提出的所有要求。所以，我们看到的是一个整体上端到端效率的提升。如果你希望它能帮你跑通，从创建工单到执行代码的整个流程，它完全可以做到。当然，你也可以设置一个人工审核的关卡，让它在执行代码前先征求你的同意，然后它会推动PR的进展，提醒相关人员进行代码审查等等。从这个意义上说，它变得主动多了。并且，它拥有完成这项工作所需的所有上下文和记忆。完全正确。所以说，这其实取决于每个团队自己去决定。他们希望AI 智能体在工作流的哪个节点介入和引导。

[00:13:52] 嘉宾 Lamis Mukta：

你可以设定非常明确的规则，比如，这些操作你绝对没有权限，或者，在这些方面你必须征求我的意见。我们发现，因为Claude Tag能够随着时间的推移，不断积累记忆，它能非常准确地掌握这些工作流程的样子，并且会自我调整。这一点真的很酷。关于这个新工作流，我还想补充最后一个不同之处。就是如果你用Claude Tag来实践，你会发现，它赋能跨职能协作的能力非常强大。举个例子，客户支持工单被创建后，你可能会先标记一下负责这个客户的销售同事，让他们了解情况，做到信息同步。然后，你可以拉上工程师或者产品经理，

[00:14:31] 嘉宾 Lamis Mukta：

让他们对产品实现方案给一些反馈，等方案确定后，再让工程师介入，

[00:14:36] 主持人 Simon Maple：

进行代码审查和后续的整个部署工作。所以，我们看到的是一种多人协作的能力。这在以前单纯使用Claude Code或者其他类似工具时，是很难实现的。我想，这正是我们看到效率成倍增长的地方。这太棒了，肯定有很多听众，现在在Slack环境里，还没有用过Claude或者Claude Tag，所以，

00:14:59｜从单人会话到多人协作式智能体

[00:14:59] 主持人 Simon Maple：

这其实是一个相当大的转变。当我们讨论流程变化时，我们具体是从什么状态，变成了什么状态。假设大家现在都是习惯了那种Agentic开发的模式，那么新的工作方式，也就是更多的生活在Slack这样的聊天环境里，

[00:15:16] 嘉宾 Lamis Mukta：

而不是传统的IDE或者其他开发流程中，到底会带来怎样的变化呢？好的，这里有几点可以说。为了让大家有个概念，我先分享一下我们内部使用Claude Tag之后看到的影响。在我们的产品工程团队，现在有整整65%的PR是由Claude Tag发起的。我们当然是Claude Code的早期使用者，但现在Claude Tag已经成为我们启动许多工作流的首选方式。所以，这就是我们目前在工作流程上达到的一个状态。我认为，这种基于聊天的交互界面的确很不一样，它让我们实现了过去很难做到的事情。

[00:15:52] 嘉宾 Lamis Mukta：

当你使用Claude Code进行Agentic开发时，你会感觉这更像是一个单人模式。你通常需要进入 Claude Code 的实例，可能在本地运行代码，然后启动一次次的独立会话。我们有一个会话的概念，你需要在会话里陈述目标，管理上下文，然后运行一些循环，或者达成某些结果。而有了Claude Tag之后，整个过程的边界变得更模糊了。我们开始减少对会话的关注，也不再是那种单人模式。当你用Claude Tag启动这些Agentic编码，或者其他Agentic流程时，你会发现，它从一开始就更倾向于多人协作。比如，

[00:16:28] 嘉宾 Lamis Mukta：

Claude Tag可以主动去征求工作流中可能需要的其他人的意见。所以，作为开发者，我不再需要自己去联系产品同事，或者销售同事。我可以把这个环节直接嵌入到Claude Tag的流程里。而且，最终所有这些工作都可能是在公开的频道里进行的。这意味着，其他同事从一开始就能看到这些工作流的进展。他们能清楚地知道工程师给出的产品规格是怎样的。如果想补充一些额外的上下文，随时都可以加入讨论。甚至他们自己的Claude Tag也会把相关信息推送给他们。所以，这种整体的协作特性是非常与众不同的。比如说，有些事情需要销售同事跟进，

[00:17:07] 嘉宾 Lamis Mukta：

我就可以把这个任务直接嵌入到Claude Tag的工作流里。而且，还有一个关键点是，所有这些工作都可能是在一个公开的环境下进行的。这意味着那些相关人员从一开始就能看到整个工作流的进展。他们能清楚地知道工程师提交的产品规格是什么样的。并且如果需要，随时可以补充额外的信息进来。甚至他们自己的Claude Tag也会把这些信息推送给他们。所以，这就形成了一种全新的协作生态，

[00:17:36] 主持人 Simon Maple：

和以前非常不一样。另一点不同在于，它的异步性比用Claude Code要强得多。可以说，Claude Code非常适合那种你需要全程参与关注智能体每一步进展的场景。你希望它完成每一步都向你汇报，告诉你做了什么，需要哪些后续更新等等。当你想要更精细地驾驭整个过程时，用它就对了。但是对于Claude Tag，我们观察到一种更普遍的模式，那就是处理那些需要长时间运行的一步任务。这其实也得益于近期模型迭代所解锁的一些新能力。所以你会看到这样的情景，你只需要ping 一下 Claude Tag，它可能几个小时后

[00:18:15] 主持人 Simon Maple：

就带着你之前提到的那个已经开发完成的功能回来了。你基本上可以放手让智能体自己去工作，等它完成了再来找你。这一点我觉得和Claude Code的体验是相当不同的。当然，它的灵感也来源于我们在Claude Code里发布过的一些功能，但这确实反映了整个行业正在发生的变化。这真的很有意思。大概一年多前吧，我跟Slack的一位产品副总裁聊天，当时我半开玩笑地问他，Slack是不是正在成为开发者的新一代IDE呢？现在回想起来，这个演变过程真的非常有趣。你看，开发者们当然都非常热爱自己的IDE，那里曾是他们效率最高的地方。

[00:18:59] 主持人 Simon Maple：

然后，情况开始变化了，大家开始用上了像Copilot这样的工具，我们开始把智能助手引入到IDE中。这些助手逐渐演进，变得越来越强大，能够处理多文件，修改，像Cursor这样的工具也应运而生。

[00:19:18] 嘉宾 Lamis Mukta：

但真正的转折点，是当Claude Code进入终端IDE之后，它彻底改变了很多人的工作方式。而现在，我感觉我们正在迎来下一次变革。说实话，这真的非常需要信任。我也很想就信任这个话题，稍微聊几句。想要真正地离开IDE，信任是必不可少的前提。

00:19:39｜信任从哪里来：能力、验证与成功标准

[00:19:41] 嘉宾 Lamis Mukta：

因为一旦我们进入了终端IDE的模式，我们其实会越来越依赖自动化测试和验证结果，而不是亲自去检查代码或者代码审查的结论。当这个模式再次被延伸，进入到Slack这样的聊天环境时，我们离具体的代码实现就又远了一层。我觉得，像Claude Tag这种在Slack内部运行的工具，要是在一年前，大家是根本没法接受的，对吧？但现在，我们对AI能做，对事情的信任度已经大大提高了。我们相信，AI生成和智能体编写的代码是可靠的，所以，我们才敢于在一个离纯代码环境更远的地方，去使用这些智能体。我们现在对AI能够做对事情的信任度高多了，

[00:20:28] 嘉宾 Lamis Mukta：

而且AI生成代码和智能体代码的可靠性，也越来越强。正因为如此，我们才能在一个更为抽象，远离以代码为中心的环境里，去使用这些智能体。所以，slack和聊天工具会是新的集成开发环境，IDE嘛，这是个很棒的问题，我觉得这不像是一对一的替代关系，不同的工具有各自的位置和用途。但我非常认同你提到的那个趋势，就是我们与智能体互动的方式，确实因为很多原因在发生改变。其中一个原因，就和你刚才提到的信任有关，那就是，模型本身正变得越来越强。我们正处在一个指数级增长的趋势上，尤其是关于智能体能运行多长时间，这一点。

[00:21:09] 嘉宾 Lamis Mukta：

METR的图表一直显示，大概每四个月，智能体能够自主运行的时间就会翻一番。我想就这一点深入问一下，

[00:21:17] 主持人 Simon Maple：

你刚才说每四个月，智能体自主工作的时间就会翻一番，这纯粹是指模型和智能体本身的能力在翻倍吗？还是说，这里面也包含了人类与它互动方式的因素？也就是说，

[00:21:32] 嘉宾 Lamis Mukta：

当它在自主工作时，我们是否还能跟它互动？这确实是个很有意思的问题。METR发布的这项研究，涵盖了好几个不同的领域和时间跨度。所谓的智能体能够成功完成特定长度任务的时间，本身就是衡量其能力的一个指标。这个指标当然不完美，我们也会用其他像EVOS这样的基准来衡量模型能力，但它是一个非常宽泛且通用的指标，而且确实非常贴近我们与这些模型互动时的真实感受。所以，当它们能够完成这些任务的时间越长，通常也反映出它们正在处理更复杂的事情。比如，它们能够执行多步骤的任务，能够在不同阶段验证自己的工作成果，然后回过头来，

[00:22:13] 嘉宾 Lamis Mukta：

成功地完成整个任务。这是我们观察到的一个全行业的趋势。说实话，如果你去看那条增长曲线，会觉得相当震撼，因为每当你觉得它不可能再维持那条漂亮的对数直线增长时，它总能做到。这种情况在过去近十年里一直在发生，真的非常有意思。当然，我们谈论模型能力时，运行时间只是一个方面。我们观察到，随着时间的推移，很多以前需要我们通过外部工具来辅助的行为，现在已经内化到模型本身了。具体来说，现在的模型在验证自身工作方面做得好多了。这既体现在一种本能层面，就是说他们在向你报告任务完成之前，会先自己检查一遍。也体现在，当他们拥有工具时，

[00:22:54] 嘉宾 Lamis Mukta：

比如前端测试工具，他们也更善于利用这些工具来验证自己的工作。无论是运行测试，还是创建自己的评估标准，他们在这方面的自主能力也变得越来越强。所以，回到你说的信任问题，我认为这两者是相辅相成的。你给模型提供了验证自己工作的工具，而他们也更善于自己去完成这件事。我觉得，我们今天在开发中看到的另一个模式是，开发者或工程师的行为正在发生转变。越来越关注一个核心问题，你能在你的场景中，多好的定义成功的标准。这不仅仅是针对编码，而是适用于所有事情。你是否对成功的样子有一个非常清晰的概念？如果答案是肯定的，那就把它交给模型。

[00:23:35] 嘉宾 Lamis Mukta：

模型可以自己循环迭代，或者让另一个AI 智能体来审查它的工作。直到审查者认为任务已经完成，所以我认为这是两个方面的事情。一方面，在AI 智能体和模型这边，它们的能力越来越强，越来越擅长做这些事。另一方面，在我们人类这边，我们的行为模式也正在转变，更倾向于去思考，我们能否定义清楚什么才是好的结果。我想最后再补充一点，来完善这个观点。过去一年，我们很多人都在高强度地使用这些工具，这让我们对它们有了一种非常深刻的直觉。我们越来越清楚，这些工具在哪些地方真正有用，在哪些地方又需要多一些监督。这样，

[00:24:19] 嘉宾 Lamis Mukta：

我们就可以相应地调整自己的行为和输入方式，让两者的协作达到最佳效果。所以，最后回到你关于Slack是不是新的IDE的问题。我认为它更像是一个让AI 智能体能更贴近你日常工作流的平台。它允许你在任何地方，任何时候，当你需要更多上下文或者想要委派任务时，随时把AI 智能体拉进来参与。有时候这确实是个编码任务，比如构建这个功能或这个仪表盘。但有时候可能只是问一句，这个缩写词是什么意思？或者你能不能告诉我上周发生了什么之类的小事？所以，我觉得这提供了更大的灵活性。你不再需要在与AI协作和与团队协作之间来回切换上下文，

[00:25:01] 嘉宾 Lamis Mukta：

一切都变得更加整合了。你提到定义什么是好的结果，这一点真的很有意思。我们人类总是希望在最合适的任务上使用最合适的工具。

[00:25:13] 主持人 Simon Maple：

当我们聚焦于代码要定义好的时候，我们当然会去写测试，构建测试用例。而很多时候，我们依赖IDE来完成这些工作。但是，当我们想要协作式的定义什么是好的结果时，我们很自然地会发现自己处在一个聊天环境里，那才是定义需求的最佳场所。所以，在那个阶段引入AI 智能体，给它提供关于什么是好的上下文，就变得至关重要。

00:25:45｜行业采用：更快交付、重写代码库与登月项目

[00:25:45] 主持人 Simon Maple：

让我们稍微把视野放宽一点。我认为，那些高级用户看到像Claude这样的工具，会觉得，这正是我需要的。然后，立刻就想引入使用。比如今天，我们公司办公室里正在举办一场黑客马拉松，现场大概有100到150人。这些人对AI的采纳程度千差万别。有些人，可能刚刚接触。对于刚接触AI 智能体编码的人来说，

[00:26:14] 嘉宾 Lamis Mukta：

也是如此。我很想问问你，从外部来看，Claude Code的普及情况怎么样？我是说，在更广泛的行业里，单纯从AI 智能体编码和开发这个角度看，你觉得整个行业对Claude Code的应用，目前处在一个什么样的成熟阶段？我们稍后会聊到Anthropic内部的使用情况，但从外部来看，大家现在主要是怎么用Claude Code的。好的，我们确实看到了各种各样，形态各异的应用方式。从个人层面来说，最直接的体现就是，能够更快，更高质量地完成单个工作任务。而当我们把这个能力扩展到团队和整个组织时，一些非常惊人的事情就发生了。

[00:26:56] 嘉宾 Lamis Mukta：

比如，我们看到像Stripe这样的公司，他们完成了整个代码库的重写，这种规模的工作过去，可能需要几周甚至几个月，但现在呢，只用了几天甚至几个小时就搞定了。这就是我们所说的，当这些工具被大规模部署，并且每个人都投身于那些宏伟项目时，所能达到的效率级别。要知道，很多项目，你可能总是一拖再拖，拖上几个月甚至几年，就是因为找不到资源，但现在，他们终于变得可行了。这也让大家能把精力集中在产品和工程的其他方面。这种情况我们确实持续在观察，比如，有其他团队在一个月内就交付了上百万行的代码。所以说，当所有人都真正投入进来时，

[00:27:39] 嘉宾 Lamis Mukta：

我们就能看到开发速度达到这样一个量级。另外一点也很明显，就是你开始看到越来越多的团队敢于去挑战那些所谓的登月项目了。要知道，

[00:27:48] 主持人 Simon Maple：

在过去，这些项目因为缺乏时间、资源或者能力，他们根本是想都不敢想的。在产品方面，我们看到有些团队会用AI工具快速构建好几个不同想法的原型，进行内部测试，然后全力投入到那个效果最好的方案上。这样一来，团队就有了更多实验的空间。我想，这可能也意味着在产品开发的方式上，团队会变得更大胆，更有勇气。当然，这就引出了一个非常有意思的问题，那就是，自建还是购买的经典抉择。毕竟，像Claude这样的工具，它让快速开发和构建的成本变得前所未有的低。你可以非常迅速地把一个想法或原型变成一个真正能上线运行的应用。那接下来的问题就是，

[00:28:37] 嘉宾 Lamis Mukta：

团队是否愿意长期维护它。当我们思考这个行业里什么变化最快时，我想知道，在这个过程中，人类是不是适应得最慢的一环。在AI编码领域，面对这种日新月异的变化和交付速度，大家真的能跟得上吗？这是个好问题，我最近刚好在欧洲几个城市做了一圈交流，和一些创业者社群聊了聊。我特别喜欢在现场问大家一个问题，在座的各位，谁会因为感觉自己在日常工作和生活中，AI用的还不够多而感到焦虑？结果每次都是，全场的人都举起了手，就连我们Anthropic的员工自己也全都举手了。说真的，谁能跟得上这个发展速度呢？卡帕西在他那条著名的推文里也说过，

[00:29:24] 主持人 Simon Maple：

他从来没感觉自己像现在这样脱节。说到底，这种发展的规模和速度，已经完全超出了任何一个个体能够跟上的范畴了。我的意思是，现在光是跟上这些进展，就已经超过一份全职工作的工作量了。有时候，我甚至会发现，我们自己产品里有些我根本不知道的功能，因为实在是跟不过来。不过，我觉得我们聊了很多关于技术发展的速度和节奏，

[00:29:49] 嘉宾 Lamis Mukta：

但其实还有另一面，对吧？那就是，这些指数级的进步，到底有多少转化成了实实在在的价值？对于产品开发者或者创造者来说，你交付给客户的价值，以及对内部流程的改进，是否也实现了同步的指数级增长呢？我觉得，这才是那个更难回答的问题，也是一个更难解决的挑战。我们可以拥有所有这些原始的智能，但我们有相应的基础设施，来把这些价值真正的激活和释放出来吗？这背后设计的东西太多了，比如你的整个开发框架，你如何管理上下文和记忆，如何管理工具，如何授予权限，怎么才能让这些智能体在安全的前提下，访问到他们需要的一切？这个权限管理的问题，

[00:30:32] 嘉宾 Lamis Mukta：

就是我们当初在设计Claude Tag时，重点思考的一个核心，然后还有其他所有的事情，比如，整个基础设施，你打算如何托管和部署这些模型，还有，你如何处理所有的推理计算，所以，尽管每天都有很多光鲜亮丽，

[00:30:48] 主持人 Simon Maple：

激动人心的技术突破，但我认为，刚刚提到的那些基础设施问题，才是每个人都应该真正聚焦的核心，我们一直努力开发工具，就是为了帮助人们真正获取到这种价值，因为理论上，价值就在那里，我们都看得到，但要让每个人都真切地感受到它，我觉得还需要付出艰苦的多的努力，说得非常有意思，你刚才提到了记忆，我也很想和你聊聊做梦这个话题，就是你在伦敦AI原生开发者大会上分享的那个，这个我们稍后再谈，在此之前，

00:31:22｜Claude Code 的起源：内部试用与模型能力拐点

[00:31:22] 主持人 Simon Maple：

我们刚刚聊了外部社区和整个行业的情况，现在我想把话题转到内部，我想了解一下，Anthropic公司现在是如何自己开发软件的，

[00:31:33] 嘉宾 Lamis Mukta：

另外，我也很想知道，Anthropic在公司内部，具体是怎么使用Claude Code来辅助日常工作的，那么首先，我们不妨回到一切开始的地方，当时Boris是不是就像在自家地下室里捣鼓，然后做出了这个叫Claude Code的东西，给我们讲讲那段故事吧，没错，这完全就是Boris当时在做的一个业余项目，而且我觉得，首先要提的是，Anthropic内部有一种非常浓厚的实验文化，大家总是会自己开发工具，尝试各种新东西，这本身就是Boris当时在做的一个项目，有意思的是什么呢？他刚开始在Slack里分享这个东西的时候，

[00:32:13] 嘉宾 Lamis Mukta：

我记得好像只收到了六个表情回应，这也总是提醒我们，数据本身并不能说明一切，你不可能靠完美的流程来判断一个好产品，到底是什么样的，但当时确实有几个人看到了这个工具，并且非常兴奋，然后就继续投入开发，在很短的时间里，我们看到它在公司内部的采用率高得惊人，差不多一半的员工每周都在用，这里还有一点很重要，我认为这也是在这个领域开发产品时的一个关键原则，那就是一旦模型能力再提升一点点，能够真正支持长时间处理这些编程任务时，

[00:32:45] 主持人 Simon Maple：

我们才看到了这个产品采用率的真正起飞，早期的版本感觉没那么智能，你知道吗，更像是在不断地返回一些代码片段，而到了后期，它真的可以开始接入不同类型的工具，高效地处理整个代码库，并且能持续地专注于目标，所以我们一直跟开发者说的一个重要原则就是，要为模型未来的形态去构建产品，而不是为他们今天的样子，因为就像我们之前聊的，这些技术发展得太快了，这太有意思了，这里面有好几点我都想深入聊一聊，

[00:33:17] 嘉宾 Lamis Mukta：

我们先来谈谈这个内部试用吧，这绝对可以算是Anthropic内部的，一个内部试用的经典成功案例了，对吧，当时有报道说，Claude Code在内部非常受欢迎，然后公司突然意识到，这东西潜力巨大，如果我们的工程师用得这么普遍，获得了这么大的价值，那我们绝对需要把它产品化，能给我们讲讲，Anthropic是在什么时候，意识到这个产品的巨大价值，并决定要跟更广泛的用户分享的吗？好的，我想这还是要回到那个数据上，当时差不多一半的团队成员，每周都在用Claude Code，这对于一个新产品来说，真的挺疯狂的，

[00:34:01] 嘉宾 Lamis Mukta：

正是这种强烈的内部需求让我们意识到，是时候把这个产品更大范围的发布出去了，Claude Tag的故事其实也一样，就像我之前说的，在正式发布前，我们公司整整65%的代码合并请求，都是由Claude Tag提交的，我觉得，当一个产品真正契合了模型当下的能力，并且成为了我们日常工作的核心驱动力时，那个时机就到了，这其中一个很重要的趋势是，Claude Code一开始主要是工程师们在用，靠它来快速交付大量代码，但后来我们发现，Anthropic的所有团队，都在全身心地投入使用Claude Code，有个特别有名的故事，

[00:34:40] 嘉宾 Lamis Mukta：

是市场团队的一个同事，他一天开始的时候，还需要先上网搜什么事终端，该怎么用，结果到了当天结束的时候，他就已经成功地把自己的一项工作流程给自动化了，那个流程原本需要花30分钟，现在呢，只需要30秒，现在只需要30秒，没错，他们真的就在这么短的时间内，制作出了这些广告，所以我的感觉是，现在每个人都看到了这些工具的力量，并且能够创造性地找到方法，把这种能力，应用到自己工作流中，即便是在编程之外的各种不同领域，当然，在这些非编程领域，验证和上下文的问题，

[00:35:16] 主持人 Simon Maple：

可能就更有挑战性了，因为你不像写代码那样，有清晰的文件系统，用GitHub做版本控制，还能进行单元测试，你必须更有创造力才行，但我认为，这正是我们所有人的发展方向，对吧？我们正在学习如何为结果设定目标，为成功的标准建立评估体系，比如一份好的文档，应该是什么样，一份好的简报应该是什么样，人们正在改变他们的行为，改变他们创建，

[00:35:42] 嘉宾 Lamis Mukta：

生成和存储数据的方式，以便AI 智能体能更轻松地访问这些信息，比如，我们在Anthropic内部有一种非常重要的文化，就是尽可能在Slack的公开频道里工作，我们这样做是有意为之的，因为这意味着，我们的AI 智能体能够以一种任何个人都无法企及的视角，将不同信息点连接起来，举个例子，我现在甚至会直接在公开频道里和Claude Tag对话，我所有的工作只要不是特别私密的，我都会在公开频道里进行，这有时会带来一些很有趣的互动，公司里一些我素未谋面的人会给我发消息说，嘿，我看到你在做的那个项目了，我很想用用看，

[00:36:24] 嘉宾 Lamis Mukta：

能分享一下吗？或者我们能在这方面合作吗？所以说，这种大规模连接整个组织的能力，只有通过我们现在拥有的这类工具才能实现。这真的太有意思了，而且我深有同感，因为就连我们公司的法务团队也会用Claude Code来构建应用，添加一些技能，然后把它们发布到我们的技能库里，看到它不仅赋能了工程师群体，还赋能了整个组织，这种感觉真的很奇妙，我们稍后会更深入地探讨这一点。现在我想问一个问题，既然在早期，

00:37:00｜企业级关键：公开协作、智能体身份与权限

[00:37:00] 嘉宾 Lamis Mukta：

公司内部有这么浓厚的内部试用文化，无论是围绕Claude Tag还是Claude Code，那么产品的方向在多大程度上是由内部的反馈和试用驱动的呢？问得非常好，是的，这一点非常重要，但我认为这里有几个层面需要考虑，因为在智能体这个时代做产品开发，很多时候，有些想法表面上看非常棒，单人体验也感觉无懈可击，但当你真正思考如何把它规模化地应用到企业时，你面对的问题就完全是另一个维度了，就拿和Claude Tag的互动来说，我们很早就意识到这个模式非常有效，但我们同样清楚，在Anthropic，

[00:37:42] 嘉宾 Lamis Mukta：

我们对于信息共享的态度是相当开放和慷慨的，当然，这里面有非常严格的护栏，比如哪些信息是严格属于某个团队的隐私，但这些规则我们都已经在Slack，工作区等地方明确设定好了，我们在权限管理方面有非常好的护栏机制，这意味着什么呢？在那些大家明确可以信任，可以分享信息的空间里，人们就能够做到非常开放，而这也正是我们的智能体能够表现出色的原因，所以关于Claude团队版，我们有一个核心的设计原则，那就是我们非常仔细地设计了每个频道的授权方式，每个工作空间和频道都有自己独立的权限范围，这决定了他们能访问哪些工具，

[00:38:23] 嘉宾 Lamis Mukta：

拥有哪些服务的API密钥和连接器，以及可能可以访问哪些其他的频道等等，所以你看，在一个层面上，我们当然希望分享那些让我们能和智能体高效协作的文化实践，

[00:38:36] 主持人 Simon Maple：

比如这种在公共空间工作的模式，但与此同时，我们也要确保产品本身就内置了完善的防护机制，这样企业才能以一种可扩展可落地的方式，真正实现这种高效的协作行为，我们认为这种结合效果非常好，为了让协作更高效，我们做的另一件事是提出了智能体身份这个概念，这是团队版和个人使用的Claude一个非常大的区别，当你个人使用Claude或者其他协作工具时，他们通常是继承你自己的权限，也就是说，他们是使用我的API密钥或者我的权限系统来工作，我授予了他们访问所有这些东西的权限，但在Claude的团队版里，

[00:39:14] 主持人 Simon Maple：

我们实际上给了智能体他自己独立的权限和密钥，这样他就能自主地去处理各项工作，他不再是代表某一个独立的个体在工作，

[00:39:22] 嘉宾 Lamis Mukta：

而是代表整个团队在工作，这样一来，审计和追溯也变得容易得多，因为他不是作为你在执行操作，而是作为他自己，所以，这也是我们为了实现这种多人协作模式，所必须做出的一个关键架构调整，总的来说，这个问题的答案是，一方面，各个团队会提供大量产品层面的反馈，我们会确保产品能真正适用于不同类型的用力和用户，但另一方面，我们认为，更多的工作是投入在确保这套系统，能够真正扩展到企业级应用，让大家都能从中获得实实在在的价值，太棒了，接下来我们聊一聊，我知道我们的听众，乃至整个行业，大家提升和进步的方式，不仅是听成功经验，

[00:40:08] 嘉宾 Lamis Mukta：

也包括了解我们曾经在哪里摔过跤，在哪里失败了，然后又如何站起来找到另一条路，我敢肯定，Anthropic也和所有公司一样，肯定在某些方面做过尝试，但最后发现走不太通，所以，我想问，从产品应用或者与AI编程的协作方式来看，你觉得Anthropic学到的最重要的经验是什么，无论是在使用Claude Code，还是在使用Claude团队版的过程中，当然，我觉得这里有几个层面，一部分是开发层面的，另一部分是行为层面的，先说开发层面吧，我之前提到过一点，就是我们应该始终为模型的未来发展方向去构建，

[00:40:51] 嘉宾 Lamis Mukta：

而不是仅仅着眼于他们今天的水平，在Claude Code这边，我们经常思考一个问题，那就是每当我们推出一个新模型时，我们都会讨论这些模型本身是如何变得更强大的，在某些维度上确实如此，这意味着我们会非常规律地重新审视那些辅助系统的设计，并且随着时间的推移，我们很乐意删除其中的一些部分，让它变得更简单，更清亮，从而让模型自己来完成那些繁重的工作，所以你会看到，随着时间推移，像辅助系统这样的东西，实际上会变得越来越小，因为我们可以更信任模型去处理某些能力，我们只需要为它提供必要的工具，使用和基础设施就足够了，这是一点，

[00:41:31] 嘉宾 Lamis Mukta：

所以，新模型的出现并不意味着要堆砌更多的提示词和更复杂的架构，有时候，少即是多，我觉得另一点，可以回顾一下我之前为你们做的那场关于梦想的演讲，特别是在与初创公司合作时，我发现很多人会问我关于内存和上下文基础设施的问题，你知道，这并不是一个一刀切的解决方案，大家确实想出了很多创新的方法来构建他们的内存数据库，或者内存结构，而在我们自己的托管智能体API中，我们采用的方案是一个非常简单的内存文件系统，它完全依赖智能体自己读写内存的能力，我在那次演讲里也提到了，我们过去尝试过很多不同的东西，比如结构化的内存存储，

[00:42:14] 嘉宾 Lamis Mukta：

或者那些对如何读写内存有非常具体规定的工具，但我们后来逐渐认识到，这种方式存在很多问题，有时候，我们对于智能体应该如何与内存交互的看法，有些过于主观了，而实际上，放手让他们自己管理，效果反而更好，特别是当他们的能力越来越强的时候，他们在使用文件系统和原生的Bash，grep这些工具时，表现得非常出色，所以我们学到的一点是，其实可以移除掉一些我们自己家的抽象层，甚至于，

[00:42:45] 主持人 Simon Maple：

我们对于内存结构设计的执念，随着时间推移，我们发现对内存进行索引，并非在所有情况下，都是最佳实践，一个简单的文件系统反而更好，当然，这些东西都需要通过尝试才能学到，所有这些领域都还是非常开放的研究和开发方向，我相信，未来我们还会发现更多的最佳实践，但这几个例子确实说明了，我们是如何通过不断尝试，并最终简化了我们的工作流程，这真的很有意思，我特别好奇的其实是关于，哦，不对，不是上下文那部分，而是智能体模型本身的变化，无论是智能体还是模型的改变，都确实会影响到我们需要为它提供什么，不管是上下文还是内存，

[00:43:30] 主持人 Simon Maple：

才能让它发挥出最佳性能，我觉得最有趣的一点是，我们甚至不需要改变我们的代码或上下文，就需要重新评估一下，看看现有的配置，是否仍然有价值，因为模型的变化，或者智能体的升级，我是不是反而需要提供更少的上下文了呢？因为模型或智能体本身，在没有这些上下文的情况下，已经能做得更好了，如果我继续添加这些东西，会不会只是在无谓地增加上下文的负担？或者我是否需要针对这个新模型，调整我的技能设计？我想我们需要做的，就是对我们的整个环境，进行这样持续性的定期的评估，也就是说，

[00:44:17] 嘉宾 Lamis Mukta：

我到底需要改变什么？是上下文，还是我的提示词？或者因为智能体变了，我得调整我的约束框架？听起来，这在Anthropic内部似乎是家常便饭了。没错，我们在测试这些新模型时，尤其是在应用AI这边，因为我们会和客户紧密合作，所以在早期测试阶段，就会特别留意那些行为上的变化，看看哪些地方需要通过提示词来引导，又有哪些地方因为模型自身能力的提升，我们现在可以放宽心了。所以，我们总会发布一些指导意见，告诉大家使用新模型的最佳实践，并且帮助客户完成迁移。围绕着新模型的发布，我们总会公布很多有用的资源，确保大家都能轻松地过渡过来。

[00:45:03] 嘉宾 Lamis Mukta：

大家好，希望大家喜欢目前为止的节目，

[00:45:07] 主持人 Simon Maple：

我们的团队在幕后付出了很多努力，希望能为大家邀请到最优秀的嘉宾，带来关于智能体开发最有价值的对话，无论是讨论最新的工具，最高效的工作流，还是定义最佳实践，但不知为何，我们发现许多观众还没有订阅我们的频道。如果您喜欢我们的内容，并希望我们能继续为您带来最顶尖的分享，请帮我们一个忙，点击订阅按钮。您的支持真的非常重要，它能让我们不断提升嘉宾的质量，为您打造一个更好的节目。好了，让我们回到正题，我们来聊聊你之前稍微提到过的一个话题，就是市场团队如何创建了一个应用，这非常棒。

[00:45:52] 主持人 Simon Maple：

我觉得Claude的工具确实让这件事变得更容易了，

00:45:55｜走出工程团队：销售、市场与事件响应

[00:45:56] 主持人 Simon Maple：

它赋予了更多人力量，因为你知道，那些非技术背景的同事，或者说工程团队之外的人，通过Slack与一个能写代码的智能体互动，可能会感觉舒服得多。那么，在传统的工程领域之外，Anthropic是如何使用Claude的编程能力的呢？说实话，应用方式真的太多了，我觉得整个公司，每个团队的运作都离不开Claude。另一个有趣的数据是，在过去一年里，我们公司所有团队愿意委托给Claude处理的工作量，整整翻了一番，我们对Claude的依赖程度，

[00:46:31] 嘉宾 Lamis Mukta：

从大约30%上升到了60%，市场团队那个例子就很有趣，他们用Claude搭建了一个文案生成的自动化流程，我们还有很多事件，响应的基础设施也在一定程度上依赖Claude，比如分类问题，通知相关人员，甚至在可能的情况下，他会开始尝试诊断代码问题。所有这些不同的解决方案，都依赖于对智能体稍微不同的配置。再举个例子，在我们的销售团队，销售团队每周都会由Claude生成周报摘要，他会梳理每个人这周的工作，并更新所有统计数据和仪表盘。这样，大家开会前就都准备好了，开会前就准备好了，再也不用有人费劲去做那些PPT了。

[00:47:12] 嘉宾 Lamis Mukta：

这个就是个定时运行的任务，很明显，它给每个人都节省了大量时间。另外还有一些响应更及时的应用，比如处理突发事件。在这种场景下，Claude知道什么时候该介入，也知道该多主动，所以我们能看到各种不同风格的应用。比如我在开发产品的时候，就会设置一些界面，我可以把对原型产品的反馈直接输入进去，然后Claude就会在后台默默地处理这些反馈。所以从这个意义上说，我们每个人都在构建自己的工具，而且我觉得，这些内部实践的经验，很多都融入到了我们对Claude Tag的设计思考中，我们的目标就是让它对所有团队都非常易用。比如说，

[00:47:49] 嘉宾 Lamis Mukta：

主动性这个特质，就是可以随时调节的，你可以把它设置成，只在被提到时才回应，或者让它按照预设的时间表执行任务，甚至是当它认为自己有相关信息可以分享时，就主动加入到对话中去。我们从之前像Claude Code这样的产品，以及我们自己管理的智能体中学到了一点，那就是最让人头疼的，就是那种机器人，不管什么事，都跳出来回复一些不怎么相关的内容。所以，我们把这种主动性看作一个连续的光谱，并且随着时间推移，不断进行精细的调整。这样一来，它就能慢慢知道在什么场合下，介入是合适的，什么时候不该介入，

[00:48:27] 嘉宾 Lamis Mukta：

以及什么时候应该按程序化的时间表来做事。当然，这个主动性程度，团队自己也可以引导。如果Claude做了什么你认为不符合偏好的事，你直接告诉他就行，他会更新自己的记忆，在未来按照你期望的方式来行动。这让我想起了我们之前的一期节目，当时Datadog的CEOOlivier Pomel就提到一个问题，我们人类因为紧急问题凌晨三点被叫醒的日子，到底还能持续多久？我们有多大程度上能信任AI 智能体去处理这些事？比如在一个突发事件中，他自己动手修复，这个修复操作最好是可逆的，然后可能我们早上醒来，

[00:49:07] 主持人 Simon Maple：

才发现半夜发生了点事，然后我们再来判断它的处理方式是否正确。也许我们选择撤销操作，换种方式，但至少我们可以依赖智能体来完成第一步。听你刚才说的，我仿佛看到了一个未来的场景，各种可观测性数据直接汇入slack，然后像Claudtech这样的工具就会盯着这些数据。一旦发现有那么点不对劲，他就会自己判断，我是不是该创建一个突发事件单了。然后你就会看到一个AI 智能体，自己说，好了，我要在这里创建一个事件单。接着，他开始动手进行一些修改，同时记录下他在做什么，最后把变更推送上去。说真的，这种感觉太棒了，我现在就想上手试试，

[00:50:01] 主持人 Simon Maple：

看看这条路走不走得通。你们在Anthropic内部会这样做吗？没错，突发事件响应智能体，这绝对是我们观察到的一个非常有效的模式。作为一个曾经需要轮班待命的工程师，我太懂那种凌晨三点被PagerDuty电话惊醒的恐惧了，那滋味可真不好受。我以前也是个需要轮班待命的工程师，所以我特别懂那种凌晨三点被呼叫器惊醒的恐惧，那滋味真不好受。

[00:50:29] 嘉宾 Lamis Mukta：

不过我觉得你提到的这个场景，恰好体现了几个非常重要的设计原则。首先，要让AI 智能体做好这项工作，你得给它足够好的数据访问权限，这包括你的数据仓库，所有的日志和指标数据，甚至可能还有你的代码库，这样它才能开始诊断问题。我觉得，这是这类智能体的一个非常好的入门套装，但另一点也至关重要。而且，这也直接关系到我们如何设计我们的托管智能体产品。那就是，你希望在人类和智能体交互之间设置哪些关卡，这完全取决于团队自己。我们非常理解，要大规模推广这些东西，这背后需要一个建立信任的过程。比如说，在刚开始的时候，

[00:51:11] 嘉宾 Lamis Mukta：

你可以先让Claude试试手，同时保留传统的处理流程，然后看看它在设定的成功标准下表现得怎么样，有没有达到你的预期。随着时间的推移，你就会更有信心地把越来越多的工作交给它。或许一开始，它只是负责诊断问题，然后把情况同步给工程团队，在它认为问题足够严重时，才唤醒工程师。再往后，它就可以开始起草一个修复问题的PR草案，或者你希望它能触达任何其他权限关卡。所以我觉得这个场景，能让工程团队真切地看到价值所在，它能减轻你的负担，帮你更快地解决故障。这一点我们在内部已经看到了非常好的效果，

[00:51:50] 嘉宾 Lamis Mukta：

你需要做的就是仔细思考在哪些环节需要Claude征求你的批准。这当然是团队自己应该去思考和配置的事情。我们可以根据经验建议哪些做法效果好，但这毕竟是一个需要高度信任的场景。这很有趣，我之前的笔记本电脑上贴着一张贴纸，上面写着AI works while I sleep.AI在我睡觉时工作，现在我感觉我们很快就会突破那道信任的壁垒，实现

[00:52:21] 主持人 Simon Maple：

AI fixes production while I sleep.AI在我睡觉时修复生产环境，我觉得这绝对是正确的方向。无论是在诊断问题，还是在获取修复建议方面，AI 智能体都能更准确，更快速地找到数据。而且从故障造成的损失成本来看，有时候让人类去诊断，找到根源，提出修复方案，成本反而更高。所以我们肯定会看到一个有趣的平衡点出现。观察这个转变的过程，一定会非常精彩。没错，绝对是。而且我觉得，无论如何，我宁愿被这样一种电话叫醒。嘿，我们遇到了一个突发事件，但我认为这个PR可以修复它，这是我运行的测试，

[00:53:08] 主持人 Simon Maple：

验证了方案有效，而且这是预估的影响范围。我绝对更希望被这样的信息叫醒，而不是一个冷冰冰的通知，让我顶着巨大的时间压力去排查问题，完全同意。所以，即便你仍然保留了人工审核这一关，两种情况下说到的信息交接，

[00:53:24] 嘉宾 Lamis Mukta：

体验也是完全不同的。在这两种情况下，我都非常乐意在凌晨三点批准那个PR，绝对的。Lamis Mukta，几周前你在伦敦的NativeDevCon上

[00:53:37] 主持人 Simon Maple：

做了一场非常精彩的分享，而且我们已经宣布了，纽约的NativeDevCon将在2026年11月举行，大家也可以关注一下，你在演讲中提到了一个叫Dreaming，

00:53:48｜Dreaming：让智能体维护和改进自己的记忆

[00:53:51] 主持人 Simon Maple：

做梦的概念，这真的太有意思了，能不能先给我们介绍一下Dreaming到底是什么？

[00:53:58] 嘉宾 Lamis Mukta：

当然，Dreaming是我们Managed Agents，托管智能体，产品中的一个研究预览功能。可能有些听众对Managed Agents不太熟悉，我简单解释一下，这是一款能帮助你更快地在生产环境中，构建和部署智能体的产品。我们基本上承担了从智能体在Anthropic端的底层框架管理，到基础设施和可观测性的一系列繁杂的工作。我们做的其实就是把过去一段时间里，构建智能体的所有经验和教训，全部都沉淀到了这个产品里。我们把这些经验打造成了一些核心的构建模块，比如智能体，环境和会话，

[00:54:33] 嘉宾 Lamis Mukta：

让你能用它们快速地组合出自己想要的智能体，并且非常快地部署上线。这就是Managed Agents产品。当然了，在智能体的开发中，上下文一直是个极其重要的概念，所以一个强大的记忆功能是必不可少的。这个功能允许智能体在学习新东西的时候，向不同的记忆库里读取和写入信息。而且这个记忆系统是分层的，比如有非常重要的组织级别的全局上下文，这部分是只读的，也有像智能体的草稿纸一样的地方，让它们可以随时记录当前工作的上下文。这对于赋能它们的工作来说，效果简直不可思议。就像我之前说的，很多人会问，构建这些记忆系统的最佳实践是什么，

[00:55:14] 嘉宾 Lamis Mukta：

因为当系统运行时间长了，确实会开始面临一些风险。比如里面会有一些过时的信息，有些东西已经不准确了，有些信息又缺失了，或者记录得非常混乱等等。所以，我们就设计并推出了Dreaming这个概念。它的工作方式，我觉得和它的名字听起来也挺像的。基本上，你可以按照任何你想要的频率，来运行这些Dreaming任务。在运行时，你会输入一部分记忆库的数据，以及一些来自Managed Agents的会话记录。这些会话记录，其实就是你的智能体过去执行各项任务时，留下的完整痕迹。然后，你把所有这些东西都交给另一个智能体。

[00:55:54] 嘉宾 Lamis Mukta：

它就会去审查这些记录和记忆，寻找其中任何不一致的地方。比如，它可能会发现某些信息缺失了。如果当初智能体有这些上下文，任务会完成得更好。反过来，它也可能发现记忆里有些误导性的信息，导致了性能下降。或者，它只是找到了一种全新的方式来组织这些信息，让其他智能体将来更容易搜索和调用。而且，整个过程非常详尽。它会给你提出关于应该做什么改变的假设，附上它认为可以作为证据的会话链接，然后你基本上就可以决定要实施哪些变更了。我觉得，这里真正重要的一点是，这真的为持续学习开辟了道路。就像你说的，这意味着你的智能体可以今天运行一次，

[00:56:39] 嘉宾 Lamis Mukta：

然后根据可优化的点进行调整，到了第二天，你就能看到它实实在在的进步了。有了Dreaming这个功能，你就可以在很大程度上把整个优化过程自动化。最后只需要审核并批准那些你认为相关的变更就行了。所以，这是我们非常兴奋的一个方向。我们已经看到，很多客户在采用了类似流程之后，他们部署的智能体性能都获得了非常显著的提升。太棒了，对于想了解更多的听众朋友们，你的那场演讲其实已经上线了，我们会把链接发给大家，这样你们就可以看到类似完整的分享内容了。

[00:57:13] 主持人 Simon Maple：

是的，我想补充一点，那天能到现场我真的非常开心。就像我们之前聊到的，大家对各种新功能都有种错失恐惧症，所以，能有机会深入聊聊那些大家平时可能接触不多的，

[00:57:27] 嘉宾 Lamis Mukta：

相对复杂一些的功能，我觉得特别好。希望听众们会喜欢这些内容。那场分享大家反响特别好，反馈都非常棒，所以真的非常感谢你。

00:57:38｜落地建议：每日简报、紧急提醒与复盘

[00:57:38] 嘉宾 Lamis Mukta：

我们的时间差不多了，不过在结束之前，我们希望能给听众一些可以实践的建议。

[00:57:44] 主持人 Simon Maple：

根据你的经验，对于那些想要在公司里进一步推广，托管，工作流，或者智能体开发的团队，你有什么日常实践的建议吗？有哪些方法可以极大的帮助他们迈向下一个阶段？当然，考虑到我们的听众可能背景很多样，我真的非常鼓励大家去把Claude设置起来试一试。你只需要让你的Slack管理员启用它，再做一些配置，整个过程花不了太多时间。我可以给你分享一下我个人是怎么用它的。我做的第一件事，就是设置了一个每日简报，因为它能连接各种数据源，所以它可以告诉我过去24小时发生了什么。

[00:58:24] 嘉宾 Lamis Mukta：

特别是我们有国际团队，比如旧金山团队的工作进展，它都能立刻呈现给我。这样一来，我早上醒来就不用面对堆积如山的邮件和信息了，而是能直接看到一份精心整理好的，告诉我哪些事情需要我关注的简报。同时，它也了解我正在进行的工作流，所以它会提醒我，比如，你正在准备一个演讲，最好先看一下这份文档之类的。所以，每日简报这个功能非常棒。另外，我还设置了另一个功能，它知道哪些沟通渠道对我最重要，一旦有任何需要我立即关注的紧急事项，它就会实时提醒我，只要它发现任何与我相关的信息，就会马上告诉我。这个功能太有用了，

[00:59:05] 嘉宾 Lamis Mukta：

因为虽然公司内部公开透明的工作方式很好，但也意味着Slack上的信息量非常庞大，我根本不可能全都跟得上。还有一些团队层面的应用，我们会让Claude生成关于各种事物的周报，比如在应用AI团队，我们每周都会有一份报告，总结团队成员这周学到了什么，观察到了什么新东西。这周的周报就特别好，它鼓励大家持续分享信息，真正地在整个组织内扩展知识。所以，从最佳实践的角度来看，这很酷。我认为这些都是很好的起点，你很快就能感受到这个工具的能力边界在哪里。对了，你还可以做一个最终的炫技，就是让Claude Tag给你构建一些定制软件，

[00:59:46] 嘉宾 Lamis Mukta：

然后它能直接部署为 Claude Code Artifact，之后你就可以把它分享出去，哪怕只是作为一个个人仪表盘，或者你也可以分享给团队说，嘿，这个工具可以用来追踪我们某个工作流，所以，这些都是不错的上手方式。太棒了，你说的这个时机正好，因为就在这周，我创建了一个应用，我一直很喜欢像搞定GTD这类工作流方法，但其中一个最大的痛点，就是回顾和检视。所以，我做的这个应用跟你的想法非常相似，它会浏览我的Slack，邮件和代办事项列表，而且，它还会查看我所有的会议笔记，从中提取出一堆代办事项，然后提醒我说，

[01:00:29] 主持人 Simon Maple：

嘿，这些事情你可能需要注意一下，或者应该加到你的日历里。它现在就像我的一个电子助理，跟你说，这真的极大地释放了我的生产力。所以，我完全同意你说的，无论是每日检视，每周复盘，还是每月回顾。从生产力的角度来看，这绝对是颠覆性的改变。没错，你一定要试试用Claude Tag来做。我发现有些功能我个人特别喜欢，比如让这些智能体告诉你，你这周哪些事情做得特别好。说实话，这真的是个很棒的功能，因为平时我们根本没时间反思这些事。你可以直接问他，告诉我这周我取得的三个胜利，或者给我一些关于可以优化之处的思考。你知道，

[01:01:14] 主持人 Simon Maple：

在人工智能这个世界里，一切都发生得太快了，能有片刻时间来反思一下现状，真的很好。我最近也在做类似的事情，我刚刚做完年度评估，所以我把我的年度反馈也输了进去。

[01:01:28] 嘉宾 Lamis Mukta：

同时，我也把我管理团队对我的期望之类的东西，也放了进去。然后，他会根据我正在做的事情给我反馈，告诉我，你有没有在自我提升上迈出下一步？你做的事情是不是团队需要的？这类反馈真的非常有价值，因为它能确保你既在做自己想做的事，同时也能满足他人的需求。这么说吧，我现在就差一个能帮我完成所有工作的智能体了，然后我就可以彻底解放，去享受生活了。这次交流真的太棒了，时间过得飞快，这真是一场精彩绝伦的讨论，我非常非常感谢你。不仅仅是因为你在AI Native DEV上的分享，那个分享反响特别好，

[01:02:19] 嘉宾 Lamis Mukta：

更因为这次对话本身也同样精彩和引人入胜。我真的非常感谢你的到来，也谢谢你分享了这么多关于Anthropic，内部是如何使用Claude Tag和Claude Code的见解，以及你们学到的经验，

[01:02:36] 主持人 Simon Maple：

这真的是一次很棒的交流。非常感谢你，Simon，我也聊得非常开心，也非常感谢你的邀请。太精彩了，真的非常非常感谢你，我相信我们的听众也一定非常喜欢这次的讨论。欢迎大家收听下一期节目，再见。AI Native DEV节目由Tessl为您带来，

[01:02:56] 嘉宾 Lamis Mukta：

Tessl是一个面向技能和上下文的包管理器。

[01:03:00] 主持人 Simon Maple：

本期节目的主持人是Guy Podjarny和我Simon Maple，我们的制作人是Tom Dowler。AI Native DEV不仅仅是一个播客，它更是一个社区。我们每个月都会在伦敦市中心的Tessl办公室举办线下交流会。请访问tessl.io/community了解更多详情，期待在那里见到你。