7月7日，Anthropic 应用 AI 团队研发人员 Lamis Mukta接受AI Native Dev 播客访谈。本次对话双方围绕Anthropic 最新发布的团队协作型 AI Agent 产品 Claude Tag展开，此外还探讨了Claude Code 在企业内外部的落地实践、AI Agent 自主运行时长的指数级增长趋势，以及“睡眠整理”（Dreaming）记忆优化机制等话题。
Lamis Mukta解释了Claude Tag 与在 Slack 中 @Claude的本质区别：Claude Tag 具备极强的主动性，可以长时间执行工作流并在任务完成时主动反馈结果，而非等待被提问才回应；同时它拥有跨频道的记忆和上下文管理能力，能够理解整个团队的工作全貌，打破了单次会话和独立交互的限制。她指出，Claude Tag 能够自行理解需要进行代码开发，自主启动沙盒运行代码、进行代码验证，并在拉取请求准备就绪时通知相关人员，这体现了比以往更强的端到端主动性。同时透露，Claude Tag 发布前，Anthropic 内部 65% 的产品工程拉取请求已由其自动提交。
关于 Claude Code 与 Claude Tag 的工作模式差异，Lamis Mukta 指出，Claude Code 是偏向单人独立模式的会话式工具，而 Claude Tag 从一开始就是多人协作、公开透明的；她表示，Claude Tag 的异步性远强于 Claude Code，指令下达后可能数小时后带着完整构建好的功能主动回来找人，这代表了工作方式的根本改变。
在企业级场景的挑战，Lamis Mukta 指出，单人体验绝佳的功能未必能直接扩展到企业级场景，因此团队为 Claude Tag 设计了基于频道的精细权限体系；她表示，Claude Tag 引入了“AI Agent 身份”这一设计理念，使其拥有独立于个人的专属密钥和权限，以团队而非个人名义行事，从而让审计工作变得容易得多。
此外，Lamis Mukta 介绍了“睡眠整理”（Dreaming）机制，即由另一个 AI Agent 定期审查记忆库和会话轨迹，找出缺失、误导性或可优化重组的信息，并提供附带证据的修改建议供人工批准；她认为，这一机制开启了 AI Agent 持续学习的路径。
01
Claude Tag是什么，如何使用
请先介绍一下你自己、你在Anthropic 的角色以及你的日常工作；随后请谈谈最近发布的 Claude Tag，它到底是什么，你们又是如何使用它的？
Lamis Mukta：我是Lamis，是 Anthropic 的一名研发人员，目前就职于应用 AI 团队。这个团队在产品、研究和商业化推广之间发挥着纽带作用。我们的工作既包括直接对接客户，我个人通常更倾向于与初创企业和创始人合作，也包括与产品和研究部门合作推进内部项目。
Claude Tag 是你积极主动的协作伙伴，目前它直接集成在你的 Slack 工作区中。它的特别之处在于，它不仅包含了你在 Claude Code 中习惯的所有连接器、工具和上下文，还具备了更高程度的主动性和持久性，可以长时间独立推进工作任务。它能够同时与你和你的团队成员进行协同配合。
在Slack 里标记 Claude 和你们的 Claude Tag 到底有什么区别？
Lamis Mukta：
（关于与Slack 内 @Claude 的区别）表面上看这两者非常相似，但实际上底层的复杂机制让它们有了显著的差异。首先，Claude Tag 具备极强的主动性。它可以长时间执行工作流，并在任务完成时主动反馈结果。这真正发挥了目前 AI Agent 长时间执行自主任务的能力。
其次，通常你需要通过提问来触发 AI Agent，然后 Slack 里的 Claude 才会回复。但 Claude Tag 有时会主动找你，提醒你有事项需要处理。此外它拥有跨频道的记忆和上下文管理能力，能够理解整个团队的工作全貌。因为它同时在与你所有的团队成员沟通，这种理解是随着时间推移不断积累的。Claude Tag 打破了单次会话和独立交互的限制。
团队通常的协作流程是先在Slack 里讨论一个需求或 Bug，关联 Linear 提工单，再召唤 Claude 实现，最后由其提交 PR 并提示审查。就此提出问题：这里发生了历史记录层面的变化，Claude Tag 是否不仅了解 Slack 内的历史互动，还知道得更多？这是否是你提到的第一点区别？
Lamis Mukta：关于上下文这一点，我们为Claude Tag 设计了一套完整的权限系统，你可以完全控制它并进行定制。它基本上是基于频道级别进行权限隔离的。如果某个频道专门用来讨论功能需求，它就会积累大量关于历史需求和处理流程的上下文，进而端到端地跟进这些流程。所以只要配置得当，它能掌握大量的历史背景。它还具备搜索其他公开频道的能力。比如你们有一个客服频道，里面包含更多 Bug 源头的上下文，只要授予了相应权限，Claude Tag 就能访问并将信息呈现给你，而你原本可能根本看不到这些信息。这正是因为它的上下文窗口或记忆范围大得多。
在Linear 的工单处理完后，你们会去 Claude Code 里去实现代码吗？
Lamis Mukta：这是我们内部通常的使用方式。
整个端到端工作流可以完全在Slack 一个消息线程里完成：假设收到一条反馈，Claude Tag 可以率先捕捉到反馈，并自动标记它认为应该参与处理的人。
Lamis Mukta：作为其工作流和技能的一部分，它随后会自动在Linear 中创建工单，只要通过提示词设定并在执行中不断学习，就能实现这一点。最后一点也是最核心的区别，你不再需要打开 Claude Code 去要求它执行任务。它能自行理解接下来需要进行代码开发，因此可以自己启动沙盒，在获得权限的情况下于代码库里运行代码，等到拉取请求准备就绪时再通知你。它还能进行代码验证，确保实现的功能满足最初提交的工单需求。总体而言，这体现了更强的端到端主动性。如果你希望它自动运行整个流程，或者希望在执行代码前设置一个人工审批节点，然后再跟踪合并请求、提醒相关人员进行代码审查等，它在这些方面要主动得多，而且它拥有足够的上下文和记忆来胜任这项工作。
这是否意味着团队不再需要被工单流程束缚？
Lamis Mukta：这实际上取决于各个团队希望在工作流的哪个环节对AI Agent 进行干预。你可以清晰地设定权限边界，比如明确它绝对不能做什么，或者在某些特定领域必须询问人工意见。我们观察到，因为 Claude Tag 能够随着时间建立起记忆库，它会对工作流的模式产生敏锐的直觉并自动进行调整。
关于新工作流的区别再补充一点，如果你使用 Claude Tag 来实现这些，你会发现它促成跨部门协同的能力非常强大。例如当一个客服工单生成时，你可能需要标记负责该客户的主管，让他们了解进展。当 Tag 带着方案反馈给你时，你可以拉入工程师或产品经理对产品实现进行评估，并在之后需要代码审查和部署上线时再让工程师介入。我们看到的是这种多人协作的能力，这是以前仅仅依靠 Claude Code 或 Cowork 很难实现的。正是在这里，我们看到了效果在呈指数级放大。
02
从 Claude Code 到 Claude Tag：单人模式向多人协同的迁移
假设听众都是AI Agent 开发者，当工作流从 IDE 或独立会话逐渐转移并更多停留在 Slack 聊天环境时，这种工作流发生了怎样的改变？就工作流本身、聊天界面带来的体验差异，谈谈你的看法。
Lamis Mukta：先从我们在内部看到的实际影响说起，自从内部启用Claude Tag 以来，我们的产品工程团队有 65% 的拉取请求是由它创建的。作为 Claude Code 的早期采用者，这就是我们目前达到的规模，现在它通常成为了我们启动这些工作流的首选入口。就工作流而言，聊天界面肯定带来了不同的体验。
它带来的转变是，使用 Claude Code 开发时，整个体验非常偏向单人独立模式。你通常要在本地运行代码，进入 Claude Code 实例，开启一个个独立的会话。在会话中你陈述目标，管理上下文，然后运行结果或循环。
但有了 Claude Tag，界限开始变得模糊。我们不再局限于会话和单人模式。当你用 Claude Tag 启动 AI Agent 编程流程时，你会发现它从一开始就是多人协作的。Tag 可以主动向流程中需要参与的人征求意见。作为开发者，我不再需要亲自去找产品或销售人员沟通，我可以让这一切直接融入核心的 Tag 工作流中。最终所有这些工作都具有公开透明的属性，这意味着相关人员从一开始就能清楚看到工作流的进展。他们确切知道工程师正在提供什么样的产品规格，并且可以随时补充背景信息，或者他们的 Claude Tag 也会把相关信息推送给他们。这种全新的协作性质是非常与众不同的。
另一方面，它的异步性远强于 Claude Code。如果你希望密切监控 AI Agent 的每一个操作回合，了解它的确切操作、需要的跟进事项以及进度更新，那么 Claude Code 会非常出色。但在 Claude Tag 这里，我们更多看到的是长期运行的异步任务模式，这实际上充分发挥了近期模型迭代解锁的强大能力。当你给 Claude Tag 发送指令后，它可能在几个小时后带着完整构建好的功能回来找你。你可以放心地把任务交给 AI Agent，它会在完成后主动通知你，这和 Claude Code 的体验截然不同。虽然它是受到我们在 Claude Code 中发布的一些功能的启发，但这确实代表了工作方式的根本改变。
03
Slack 会成为更靠近日常工作的入口
从终端IDE 到聊天环境的迁移意味着人类对 AI 决策可靠性的信任在不断提升，Slack 和聊天环境真的会成为新的 IDE 吗？
Lamis Mukta：我不认为两者是完全相互替代的关系，它们各有其定位和用途。但我非常认同你提到的趋势，即因为种种原因，我们的行为模式以及我们与AI Agent 的交互方式正在发生转变。首先正如你提到的信任问题，大语言模型的能力正变得越来越强。我们正处于 AI Agent 持续运行能力呈指数级增长的曲线上。METR 图表清晰地显示，AI Agent 能够自主运行的时间大约每四个月就会翻一番。纯粹从能力角度来看，正是由于实际能力的飞跃，我们才敢于给予这些 AI Agent 更多的信任。
这种自主执行时长每四个月翻一番，究竟是模型本身能力的提升，还是也包含了人类干预因素？
Lamis Mukta：METR 开展了这项研究，涵盖了多个不同的领域和时间跨度。AI Agent 能够成功完成特定时长任务的能力是衡量其水平的一个指标。虽然这并不完美，我们还有其他评测集和基准测试来衡量模型能力，但它是一个通用且广泛的指标，真实反映了与这些模型交互时的直观感受。它们能够执行任务的时间越长，通常意味着在处理更复杂的工作。它们能够执行多步骤任务，在不同阶段验证自身的工作成果，最终成功交付任务。这是我们观察到的一个大趋势。
仔细观察就会发现这非常惊人，每当你认为这种指数级增长无法持续时，它却总能打破常规。这种现象已经持续了近十年的时间。讨论模型能力时，运行时间显然是一个方面。但随着时间推移，我们发现许多以前需要在 Harness 中处理的行为，现在正在被嵌入到模型内部。具体而言，现在的模型在验证自身工作方面表现得越来越好。从直觉上讲，它们在汇报任务完成前会自我检查，而且当它们拥有验证自身工作的工具时，无论是通过前端测试、运行测试还是创建自身的评估，它们在这些方面的表现也变得越来越出色。关于信任问题，我认为这两者相辅相成。赋予模型验证自身工作的工具，它们就能更好地自主完成这项工作。
当今开发领域的另一个趋势是，开发者或工程师的行为正在发生转变，更多地取决于能否在特定场景下清晰地定义成功的标准。这不仅适用于编程，几乎适用于所有领域。你是否对理想的结果有清晰的认知？如果有，把它交给模型，它可以循环执行，或者让另一个 AI Agent 审查其工作，直到审查者认为任务已圆满完成。我认为主要有两点，在 AI Agent 和模型端，它们变得越来越强大，越来越擅长执行这些任务，而在人类端，我们的行为正在向能否清晰定义好结果转变。
补充一点，在过去一年实战深度使用这些工具后，我们已经非常清楚它们在哪些场景下能发挥巨大价值。它们在哪些环节需要更多的监督，我们可以调整自身行为和输入，使人类与工具的协作更加完美。最后，关于你提到的 Slack 是否将成为新的大本营或新的集成开发环境，我认为它提供了一个平台，让 AI Agent 能够更靠近你日常工作的地方。它让你可以在任何地方随时召唤它们。当需要更多上下文或想要委派任务时，只需将 AI Agent 拉入对话即可。有时是编写代码，有时是构建某个功能或仪表盘，有时仅仅是问这个缩写是什么意思，或者你能告诉我上周发生了什么吗。这赋予了极大的灵活性，你无需在与 AI Agent 协作和与团队协作之间频繁切换上下文，一切都变得更加整合。
04
Claude Code 外部行业采用的成熟度
从纯粹的AI Agent 编程和开发角度看,你认为目前行业在使用 Claude Code 方面处于什么成熟度阶段?人们目前主要是如何使用 Claude Code 的?
Lamis Mukta：我们看到了各种形式和规模的应用。在个人层面，人们能够更快、更高质量地完成独立的任务。当将这种应用扩展到团队和整个组织时，我们看到了一些相当惊人的成果。例如像Stripe 这样的组织，他们完成了整个代码库的重写，这原本需要几周甚至几个月的时间，而现在只需几天或几个小时。当真正大规模部署这些工具并让每个人都参与进来时，就能达到这样的规模效应。那些过去因为资源短缺而被搁置数月或数年的宏大项目，现在终于变得可行了。这使得人们能够将精力集中在产品和工程工作的其他方面。
我们经常能看到这种情况。其他团队仅用一个月左右的时间就交付了数百万行代码。我认为当每个人都全身心投入时，就能看到这种规模的开发速度。另一方面，你开始看到更多的团队在追求这类极具挑战的创新项目，如果没有 AI，他们原本没有时间、资源或能力去做。在产品方面，我们看到的一个现象是，团队基本上能够对某些想法进行多种原型设计，通过 AI Agent 工具或在内部进行大量测试，然后全力投入到效果最好的那一个项目中。因此在产品开发方式上，有了更多的实验空间，也带来了更多的勇气和胆识。
像Claude 这样的工具大大降低了快速构建的成本，这让"自建还是采购"的问题变得极为有趣。在这个快速变化的 AI 编程领域，人类是否已经成了适应速度最慢的一环？人们还能跟上交付的节奏吗？
Lamis Mukta：最近我在几个欧洲城市进行了一次巡回交流，与一些创始人社区进行了探讨。我喜欢问在场所有人一个问题，谁有错失恐惧症，觉得自己日常工作和生活中对AI 的使用还不够。结果往往是全场举手。Anthropic 的员工也是如此，我们都举起了手。谁能跟得上这种发展速度呢？连 Karpathy 都这么说过类似的话。从根本上讲，事物发展的规模和速度已经超出了单个人的认知和跟进能力。这甚至已经超过了一份全职工作的工作量。有时我甚至会发现一些我不知道我们已经具备的功能。
我们刚才讨论了很多关于这些技术发展的速度和步伐。但还有一个层面，那就是这一切在多大程度上转化为对产品开发者或构建者产生的实际影响。你如何将这种指数级增长转化为为客户提供的价值以及对内部流程的影响。这是一个更难回答也是更难解决的问题。我们可以拥有所有这些原始智能，但我们有将其转化为实际价值的基础设施吗？
这涵盖了很多方面。它包括 Harness，如何管理上下文和记忆，如何管理工具，以及如何让这些 AI Agent 获取它们需要的所有资源。此外还涉及安全性，即如何进行权限管理。在设计 Claude Tag 时，我们对这个特定问题进行了深入思考。然后是其他所有基础设施，比如将如何托管和部署这些模型，本质上将如何处理所有的推理请求。尽管发生了很多耀眼且惊人的创新，但这些基础设施和安全问题才是每个人都应该高度关注的焦点。我们一直致力于开发工具来帮助人们真正获取这种价值，因为在纸面上它就在那里，大家都能看到。但要确保人们能真正感受到这种价值，这需要付出更多的艰苦努力。
05
Claude Code 的诞生与产品化之路
回到Anthropic 内部开发软件的起点，Boris 在地下室里开发出了 Claude Code，能跟我们分享一下那个故事吗？
Lamis Mukta：这很大程度上是Boris 业余时间做的一个副业项目。在 Anthropic 有一种非常强烈的实验文化。大家总是喜欢构建自己的工具并进行各种尝试，这也是 Boris 正在做的事。一开始当他在 Slack 上分享这个项目时大概只收到了六个回复。这再次证明数据并不总是完美的，我们没有一套绝对完美的流程来判断什么才是好产品。但有几个人看到了这个项目觉得非常兴奋并继续参与开发。在很短的时间内，它在公司内部获得了惊人的采用率，大约一半的员工每周都在使用它。
还有一点很重要，我认为这也是在该领域开发产品的关键原则，当模型能力有了进一步提升，使得 AI Agent
能够真正实现长时间执行编程任务时，该产品的采用率迎来了真正的爆发。早期版本的自主性感觉要弱得多，更像是分块返回代码，而在后期，它真正开始能够访问各类工具，高效处理整个代码库，掌控大量上下文并保持目标导向。我们经常对开发者强调，要为模型未来的能力构建产品，而不是为今天的能力构建，因为这些技术发展得太快了。
当Anthropic 意识到 Claude Code 的巨大价值并希望将其分享给更广泛的受众时，情况是怎样的？
Lamis Mukta：我认为这又回到了那个现象，即当时团队中一半的人每周都在使用Claude Code，对于一个新产品来说这非常疯狂。这种内部产品市场契合度让我们意识到，是时候更广泛地发布这款产品了。Claude Tag 也是同样的发展路径。发布之前，我们 65% 的代码拉取请求都是由 Claude Tag 提交的。当一款产品能够如此深入地契合目前所看到的模型能力，并且现阶段已经成为日常的主力工具时，发布它就是水到渠成的事。
这里面一个明显的趋势是，最初所有工程师都依赖 Claude Code 来快速交付大量代码。随后我们发现 Anthropic 的所有团队都开始全面使用 Claude Code。有一个典型的例子，营销团队的一名成员，一天的开始是去谷歌搜索什么是终端以及如何使用它。然而到一天结束时，他已经自动化了一个原本需要 30 分钟的工作流，现在只需 30 秒就能完成。他们能够在极短的时间内制作出广告素材。我认为大家都见证了这些工具的强大威力，并能创造性地找到将其应用到非编程领域工作流中的方法。
也许在非编程领域，验证和上下文的问题更难解决。你没有整洁的文件系统、用于版本控制的 GitHub 以及进行单元测试的能力等完善的基础设施，必须更具创造力。但这就是我们前进的方向。我们能够设定结果和成功标准，或者定义一份好文档或一份好简报的标准是什么。人们正在改变创建、生成以及存储数据的方式，以便 AI Agent 能够更容易地访问这些信息。在 Anthropic 有一种非常强大的文化，就是在 Slack 的公共频道公开工作。我们刻意这样做，因为这意味着 AI Agent 可以用任何人都不可能具备的全局视野将所有信息连接起来。
有时候我在公开频道与 Claude Tag 交流的程度，几乎达到了用它处理所有工作的地步，除非涉及高度机密的内容，否则都在公共频道进行。有时公司里我不认识的人会给我发消息，说看到我在做某个项目，他们很想使用，询问是否可以共享，或者能否在这个方向上合作。我认为只有依靠目前拥有的这类工具，才能在如此规模的组织上建立起这种连接。
06
Claude Tag 引入了独立于个人的"AI Agent 身份"
在早期围绕Claude Tag 和 Claude Code 有如此深厚的内部试用文化时,产品方向在多大程度上是由你们的内部反馈和测试驱动的？
Lamis Mukta：这一点非常重要。这方面有几点需要考虑，因为在AI Agent 时代的产品开发中，有些功能表面上看起来是个绝妙的主意，并且作为单人体验感觉非常棒。但当真正考虑如何将这些体验扩展到企业级应用时，面临的问题形态截然不同。在与 Claude Tag 的交互方面，我们很早就知道它非常高效。同时我们也清楚，在 Anthropic 团队内部非常乐于共享信息。当然我们也有非常严格的安全防护机制，比如界定对某个团队来说什么是绝对机密的信息。但我们在 Slack 工作区等平台已经设置好了一切，在权限管理方面有非常完善的机制。
这意味着，在这些确信安全可信的信息共享空间内，人们可以非常开放，这也正是 AI Agent 能够表现得如此出色的原因。设计 Claude Tag 时的一个原则是，精心设计如何对每个频道进行权限分配。每个频道和工作区都有各自的权限范围，包括可以访问哪些工具、对不同服务和连接器拥有什么 API 密钥，以及允许访问哪些其他频道。一方面我们希望分享能让团队更好地与 AI Agent 协作的文化实践，比如公开工作，但另一方面，必须确保产品内置了安全防护机制，以便用户能够以真正可扩展至企业级的方式合理实现这种工作模式。我们认为这种做法非常有效。
为了让这项工作更高效，我们采取的另一项措施是提出了 AI Agent 身份这一概念。Claude Tag 与使用 Claude Code 或 Cowork 的极大区别在于，当使用 Code 或 Cowork 时，它们会继承你个人的权限，这意味着它们会使用我的 API 密钥或权限系统进行操作，并由我授予访问权。而在使用 Claude Tag 时，我们实际上赋予了该 AI Agent 独立的权限和专属密钥，使其能够自主执行任务。它不再代表个人，而是代表团队运作。这也让审计工作变得容易得多。它不是以你的身份，而是以自己的身份在执行任务。这是为实现这种多人协作模式，我们需要做出的另一项关键架构调整。
补充一点，必定会有各团队共同参与并提供产品级反馈的情况，我们会确保它真正适用于各种用例和不同类型的用户。但与此同时，我们认为大部分工作都投入到了确保它能真正满足企业级规模的需求，并让大家切实从中获得价值。
07
Anthropic 踩过的坑
从采用角度或从与AI Agent 编程协同工作的方式来看,在使用 Claude Code 甚至 Claude Tag 的过程中,Anthropic 最大的经验教训有哪些？
Lamis Mukta：我们有几个方面的教训，部分在开发端，部分在行为表现端。在开发方面，我之前说过，我们始终应为模型未来的发展方向构建应用，而不是局限于它目前的能力。我们在Claude Code 方面经常思考的一件事是，每当推出新模型时，都会探讨这些模型本身在某些维度上如何变得更强大。这意味着我们需要非常定期地重新审视这些 Harness 应该是什么样。我们很乐意随着时间的推移从 Harness 中删减内容，使其变得更简单，更轻量，直接让模型去承担繁重的核心工作。渐渐地，我们看到 Harness 实际上变得更精简了，因为在某些能力上我们可以更加信任模型，只需保留能为其提供所需工具和基础设施的配置即可。新模型并不意味着要盲目堆砌更多的提示词和更复杂的架构。有时候，大道至简。
另一件事是回顾我之前关于 Dreaming 的演讲。特别是与初创公司合作时，很多人专门向我询问关于记忆与上下文基础设施的问题。这并没有一个放之四海而皆准的解决方案。人们想出了极具创意的方法来构建记忆数据库或记忆结构。我们在 Managed Agents API 中的解决方案是一个非常简单的记忆文件系统，它仅仅依靠 AI Agent 读写记忆的能力。我在那场演讲中提到过，我们过去尝试了很多不同方案，比如索引记忆存储或专门用来读写记忆的复杂工具。
随着时间推移，我们发现这带来了一系列问题。有时候，我们对 AI Agent 应该如何与记忆交互预设了太多限制，其实最好别去干预，特别是当它们具备管理能力时。它们非常擅长直接使用文件系统以及原生的 bash 和 grep 工具。我们学到的一点是，实际上可以直接移除一些抽象层，甚至放下对记忆结构设定的固有偏好。渐渐地，我们意识到构建索引并不总是通用的最佳实践，一个简单的文件系统反而更好。显然，必须通过不断尝试来获取这些经验。所有这些都是非常开放的研发领域，未来肯定会发现更多的最佳实践。这只是我们在尝试并简化工作流过程中的几个例子。
当模型或AI Agent 升级时，是应该重新运行评估确认配置是否仍然有效，还是应该减少提供的上下文以避免臃肿？这是否要求对环境进行持续评估，判断需要改变的是上下文、提示词，还是 Harness 本身？
Lamis Mukta：当我们测试新模型时，特别是在应用AI 方面，因为我们与客户合作非常密切。在早期测试阶段，我们非常关注模型的哪些行为变化需要调整提示词，以及由于模型变强，现在哪些方面可以稍微放手。我们总是会发布关于使用新模型最佳实践的指南，并协助客户完成迁移。在模型发布前后，总会提供大量有用资源，确保大家顺畅过渡。
08
Anthropic团队内部的用例
刚才提到了营销团队的用例，Anthropic 是如何在传统工程领域之外使用 Claude Code 和 Claude Tag 的？
Lamis Mukta：方式太多了。可以说整个公司都依托Claude 运行。另一个有趣的数据是，在过去一年里，全公司各团队放心交由 Claude 处理的工作量翻了一番，对 Claude 的依赖程度从 30% 上升到了 60%。营销团队的用例非常有趣，他们建立了一个用于广告和文案生成的流水线。我们大量的事件响应基础设施在某种程度上也依赖 Claude 来对事件进行优先级排序并拉入合适人员，在力所能及的范围内，它还能开始诊断代码问题。
所有这些不同的解决方案都依赖于 AI Agent 稍微不同的配置。例如，在销售团队中，我们有周报机制，Claude 会汇总每个人当周的工作，并提供数据统计和仪表盘更新，让大家做好开会准备。这样就没人需要辛苦做幻灯片了。这是基于日程表运行的任务，能节省大量时间。此外还有更具响应性的场景，比如事件响应，Claude 知道何时介入，也知道该表现出多强的主动性。我们看到了各种各样的应用。例如，开发产品时，会有一些接口让我能将反馈输入到原型中，然后 Claude Code 就会在后台处理。每个人都在打造属于自己的工具。
构思 Tag 的开发时融入了许多这方面的思考，它的初衷就是让所有团队都能轻易上手。比如主动性是可以灵活调节的。你可以设置让 Claude 仅在被标记时回应，或者让它建立时间表来执行任务，又或者当它认为有相关上下文需要分享时，主动加入讨论。我们从以往产品中学到的是，如何设定时间表以及掌握介入时机。因为最糟糕的体验就是有一个总是带着冗长上下文回应每句话的机器人。我们将这种主动性视为一个渐变范围，并在实践中不断微调，以判断什么是合适的，何时介入，何时保持沉默，以及何时按程序设定执行任务。这也是作为团队可以引导的方向。如果 Claude 做出了不符合偏好的行为，你只需告诉它，它就会更新记忆，在未来更贴近你的预期。
09
让 AI Agent 参与生产事故的诊断与修复
假如可观测性数据直接传输到Slack，Claude Tag 察觉异常后主动提交事件报告、修改代码并推送的场景，Anthropic 内部是否也是这样操作的？
Lamis Mukta：事件响应AI Agent 肯定是我们认为极其行之有效的模式。作为曾经需要值班的工程师，我深知凌晨三点听到 PagerDuty 报警电话的恐惧感。这是一个非常有趣的场景，体现了几个关键设计原则。首先，为了让 AI Agent 胜任这项工作，你需要赋予它访问各种数据源的权限，比如数据仓库，日志，指标，甚至代码仓库，这样它们才能开始诊断问题。这是此类 AI Agent 极佳的起步套件。但另一个融入我们托管 AI Agent 产品设计理念的重要考量是，你希望在人类与 AI 系统的交互中将门控关卡设置在哪里？这完全取决于团队决定。
我们理解，大规模部署这些应用需要经历建立信任的过程。也许刚开始，你只是让 Claude 试一试，同时保留传统流程，仅仅验证它是否达到了预期的成功标准。随着时间推移，你会变得更加自信，将越来越多工作委托给它。也许它最开始只是诊断修复方案并转交给工程团队，只有在认为问题极其严重时才唤醒工程师，再进一步，它可能会提交一个草稿 PR，直到放开你想要的任何其他权限关卡。在这个过程中，你确实能看到这减少了工程团队的负担，并帮你更快解决故障，这是我们在内部真切感受到的。团队只需认真思考，希望 Claude 在哪些环节向你们申请批准。我们可以提供最佳实践的建议，但这显然需要建立在高度信任的基础之上。
比起总说"我睡觉时 AI 在工作"的，现在感觉即将打破信任障碍，变成"我睡觉时 AI 在修复生产环境问题"，并认为从宕机成本角度看，让 AI Agent 诊断定位根本原因比人类更快更准确，这会是一个有趣的平衡点。
Lamis Mukta：不管怎么说，我宁愿被这样一个电话叫醒，出现了一个故障，这是修复它的PR，这是我验证过修复有效的测试，这是此次故障的影响范围。比起只对我说请你来看看这个故障好吗，我更愿意醒来看到前者。
Lamis Mukta：即使保留了人工审核关卡，这两种情况下的信息交接也截然不同。我非常乐意在凌晨三点批准那个PR。
10
Dreaming:让 AI Agent 具备持续学习能力的记忆优化机制
你在伦敦AI Native DevCon 大会上分享了一个名为 Dreaming 的概念，能给大家简单介绍一下 Dreaming 是什么吗？
Lamis Mukta：Dreaming 是我们在托管 AI Agent 服务上提供的一项研究预览功能。对于不熟悉 Claude 托管 AI Agent 的人来说，这款产品本质上能让你在生产环境中更迅速地构建和部署 AI Agent。我们在 Anthropic 承担了繁杂的工作，从管理 AI Agent 的 Harness 到部分基础设施和可观测性等。通过这款产品，我们实际上是将一段时间内构建 AI Agent 积累的经验教训，转化为具体的原语，如 AI Agent，环境和会话，让你能够快速组合并极速部署这些 AI Agent。这就是托管 AI Agent 产品的核心。
既然上下文在 AI Agent 开发中如此重要，那么缺少记忆功能是不完整的。记忆功能使 AI Agent 在学习时能够读写不同的记忆库。这里的权限控制极其严格。极其重要且庞大的组织级别上下文只能被读取，而 AI Agent 的暂存区允许它们存放与当前工作相关的上下文，这对提升它们的工作效率至关重要。人们经常问，构建这些记忆系统的最佳实践是什么。如果系统长时间运行，内部积攒陈旧信息的风险就会增加。部分内容可能已经过时或缺失，甚至记录得非常混乱等。
我们设计并引入了睡眠整理这一概念，它的运作方式顾名思义。你可以按照自己喜欢的频率运行这些睡眠整理任务，输入部分记忆库数据以及托管 AI Agent 的部分会话记录。这些记录实际上就是 AI Agent
执行各项任务的轨迹。你把这些信息交给另一个 AI Agent，让它去审查这些记录和记忆，寻找其中的偏差。它可能会发现缺失了某些信息，如果 AI Agent 掌握这些上下文，表现会更好，反之也可能发现其中有一些拖累性能的误导性信息。或者它只是找到了一种新的信息重组方式，使得 AI Agent 更容易检索和调用信息。
这个过程非常全面。它会为你提供修改建议的假设，并附上含有相关证据的会话记录，然后由你决定实施哪些更改。我认为这里的关键在于它开启了持续学习之路。这种理念意味着，你今天运行了 AI Agent，明天就能基于优化点再次运行，并真切看到它们能力的提升。借助睡眠整理功能，你可以很大程度上将这些工作托管出去，让整个过程自动化运行，只需批准你认为合理的修改即可。这让我们非常兴奋。我们看到许多客户在运行此类流程后，他们部署的 AI Agent 性能得到了显著提升。
11
配置 Claude Tag 的第一步可以从每日简报做起
对于那些试图在组织内部引入托管工作流,并进一步推广 AI Agent 开发的听众,你会给出什么建议？根据你的经验,有哪些日常实践能够真正帮助大家迈入下一阶段？
Lamis Mukta：考虑到今天听众的背景可能很广泛，我非常鼓励大家去配置并体验一下Claude Tag。你只需要让你们的 Slack 管理员开启该功能并进行一些基础配置即可。这花不了多少时间。为了让大家对我用它做的事情有个直观的感受，我设置的第一个功能是每日简报。得益于 Tag 能够访问的连接器和上下文，它能告诉我过去24小时内发生的事情，尤其是在与跨国团队合作时，比如我在美国旧金山的团队做了什么。它会直接把所有信息整理好发给我，这样我一觉醒来就不必面对满屏的邮件和 Slack 消息了。我只需阅读一份精炼的简报，了解哪些事情需要我关注。它也掌握我当前工作流的上下文，所以它能提醒我，你正在处理这件事情，比如准备这次演讲，在开始之前也许你想先复习一下这些文档等。每日简报真的非常棒。
我设置的另一个功能是，它知道哪些频道对我很重要，并会实时提醒我任何需要关注的紧急事务。只要它发现任何认为与我相关的内容就会立刻通知我。这太好用了，因为一家公司在公开频道沟通固然很好，但也意味着 Slack 上会有海量信息，我根本看不过来。在团队层面我们也有一些应用，Tag 会制作涵盖各类事务的周报。在应用 AI 团队中，我们会收到一份周报，汇总团队本周学到或看到的各种新事物。这非常棒，它鼓励大家持续分享上下文，并真正在整个组织内普及这些知识。这些就是很好的实践切入点。
我相信你会很快领略到它的强大能力。还有一个进阶玩法，你可以让 Tag 为你编写一些自定义软件，并将其部署到 Claude Code 制品中。然后你可以把它当作个人仪表盘，或者分享给团队说，这是一个用来追踪某个工作流的小工具。这些都是很好的尝试起点。
Lamis Mukta：我个人非常喜欢的一个用法是，让这些AI Agent 告诉你这周你哪里做得好。这是件很美好的事情，毕竟有时你根本没时间去自我反思。你可以对它说，告诉我这周我取得的三个小成就，再给我几个关于如何优化的反馈等。在 AI 的世界里，一切都发展得太快了，能停下脚步反思一下当下的状况感觉真的很好。我还会把我刚做完的年度总结发给它。我会输入我的年度反馈，以及我觉得管理层对我的期望等内容。它就能根据我的实际工作给我反馈，我是否正在采取下一步的改进措施，我做的是否符合团队对我的期望。这些其实非常有价值，既能确保你在做自己想做的事，同时也能满足其他人的需求。我现在唯一需要的就是一个能替我打工的 AI Agent，然后我就可以完全放手去享受阳光了。
