从聊天机器人到团队代理：Theo 解读 Karpathy 的 Claude Tag 观点

Andrej Karpathy 描述了语言模型界面的第三种范式：继网站和桌面应用之后，拥有组织工具与上下文的持久异步代理与团队一起工作。他讨论的例子是 Anthropic 在 Slack 中推出的 Claude Tag。尽管我不太愿意称赞 Anthropic 或 Slack，我认为背后的想法值得研究。

录制时，我说 Claude Tag 面向团队和企业套餐提供，并担心它相对于个人订阅的成本。可用性、套餐细节和价格都可能变化。我最感兴趣的是这种交互模式，而不是说每个团队都需要这个特定产品。

Anthropic 描述的 Claude 可以加入选定的 Slack 频道，并连接用户选择的工具、数据和代码库。频道成员可以提及它、委派工作，并在共享对话上继续协作。公告称它会保留相关频道上下文并规划未来任务；具体能访问什么取决于授予的权限。

我的团队一直在为 Discord 工作流构建不同代理，处理内容、赞助和规划等事务。我们创建隔离环境，放入每个代理所需的工具与上下文，但每次部署都需要配置。Claude Tag 看起来将其中部分隔离工作封装成了面向团队的产品。

Anthropic 表示，其内部版 Claude Tag 创建了产品团队 65% 的代码。这是公司自行报告的数字；视频没有解释测量方式，也不能证明其他团队会有相同结果。我认为有价值的是，频道让多人共享代理工作，并从别人停下的地方继续。

我们已经在拉取请求机器人中看到一些协作式代理行为，例如队友让机器人提出修改。但我觉得 GitHub 作为快速交流场所既慢又不可靠。与队友和代理在同一个频道交谈，对我来说更自然；这是一种偏好，不是受控比较。

Anthropic 表示，Claude 会积累所在频道的上下文，获得授权后也可以从其他频道和数据源学习；公告称它不会转述私人频道内容。权限和隐私的具体行为取决于实际配置。不同团队需要不同上下文，频道可以成为一个有用的边界。

我经常为全局配置与项目配置之间的空白感到困扰：一个任务需要几个 skill 和连接器，另一个不需要，第三个又需要额外指令。人员、团队、项目和单个任务之间的正确边界还没有定论，但频道与团队现有的组织方式比较契合。

如果上下文与频道关联，即使两个团队使用同一个仓库或跨越多个服务，它们也可以获得不同体验。这是我感兴趣的组织方式：代理的相关背景可以跟随团队，而不只取决于仓库结构。

公告还描述了可选的主动更新、异步任务、定时任务和私信。我能想象主动跟进在混乱的频道里有用，但我对它的兴趣不如上下文边界。这些是发布公告中的产品描述，不是我亲自测试的结果。

我的 Hermes 代理运行在专门的 Discord 服务器里，因为我喜欢用线程隔离任务。在之前的 OpenClaw 配置中，我主要用一个对话把 YouTube 和 SoundCloud 链接归档到 NAS。当不相关工作和定时任务共用一个线程时，上下文会被裁剪或打断，我得手动提醒代理哪些历史细节重要。

我提到 OpenClaw 后来加入了 Discord 线程支持，这能解决我描述的配置中的部分问题。对我而言，关键区别是多个任务可以有各自的历史，而不是让每个定时结果都插进另一段对话。

一个 Hermes 任务每天上午 11 点查看 ProgrammerHumor，选择五条帖子并生成可在手机上查看的页面。它有自己的线程。我先要求试运行，之后又让代理把输出改为嵌入图片的 HTML 页面，供我决定是否分享。

这种隔离使定时工作不会干扰其他对话。我的团队希望为赞助、内容规划和代码使用不同代理与能力，但目前我得自己设置独立环境和边界。我认为，提供这些基本能力的产品可以让更多人使用这种工作流。

我的保留意见是模型选择。使用 Hermes 时，我可以在 GLM、OpenAI 和 Claude 模型之间切换，虽然访问和计费方式不同。按我的经验，同一代理配置从 GPT-5.4 换到 5.5 后表现更好。我不希望这种交互模式依赖某一家实验室或模型系列。

我看到的取舍是：自建方案需要自己配置隔离、skill 和上下文，但可以切换模型；Claude Tag 则承诺提供更集成的体验，却绑定 Claude。例如，我有时让 Codex 请 Claude 参与 API 设计或提供第二意见；不能假定这个产品也有同样的灵活性。

Karpathy 将这一想法称为组织级代理运行框架。我认同这个方向：共享上下文、工具和异步工作可能符合真实团队的运作方式。我期待其他服务商构建类似体验，愿意自行配置代理的人也可以用 Hermes 或 OpenClaw 等工具探索其中一些想法。