Anthropic Claude TAG 技术调研

一、Claude TAG 产品概览

1.1 核心定义

Claude TAG 是常驻 Slack 频道的 AI 团队成员，可被 @Claude 召唤执行任务，也可主动介入——监控频道动态、跟进未解决问题、在条件满足时主动通知。

与传统 AI 聊天工具的本质区别：

维度

传统 AI 对话

Claude TAG

交互模式

一问一答，用完即止

持续驻留，跨会话记忆

使用范围

单人使用

频道内所有成员共享

工作方式

被动等待提问

主动介入 + 被动响应

任务类型

即时问答

多阶段异步任务，可运行数小时

上下文

单次对话窗口

频道历史记忆，按权限跨频道学习

1.2 四大核心能力

  • 共享上下文（Multiplayer）：频道内所有成员共享同一个 Claude 实例，操作完全透明
  • 持续记忆（Learns over time）：跨会话保留频道历史与组织知识
  • 主动介入（Takes initiative）：Ambient Mode 主动通知、跟进、标记
  • 异步执行（Works asynchronously）：任务可跨小时甚至数天自主推进

1.3 关键数据点

  • 发布时间：2026-06-23
  • 支持模型：Opus 4.8（固定）
  • 当前支持平台：Slack（未来扩展）
  • 可用用户：Claude Enterprise 和 Team（Beta）
  • Anthropic 内部采用：约 65% 产品代码由 TAG 参与完成
  • 30 天强制迁移：取代原 Claude in Slack 应用
  • Token 配额：组织级 + 频道级双重控制

1.4 重要背景

Andrej Karpathy（前 OpenAI 研究科学家、现 Anthropic 员工）将其定义为 LLM 界面的第三次重大变革：

  1. 第一次：网页聊天（ChatGPT 式对话界面）
  2. 第二次：桌面应用（Claude Code、Cursor 等 IDE 集成）
  3. 第三次：LLM 成为独立运行的系统，拥有组织内的工具和上下文，与人类团队协同工作

这一判断的逻辑是：前两次变革改变的是"在哪里用 AI"，第三次变革改变的是"AI 以什么身份存在于组织中"——从工具变成了有持续记忆、主动行为、共享状态的团队角色。

二、Claude TAG 技术原理深度分析

2.1 模型基座：Opus 4.8

Claude TAG 当前仅支持 Claude Opus 4.8，不支持切换至更轻量的 Sonnet 或 Haiku 版本。这一定选择背后的技术逻辑：

  • 长程任务依赖强推理能力：异步任务需要跨步骤计划、复杂工具调用与错误恢复，Opus 4.8 在 SWE-Bench Pro、Terminal-Bench 等 Agent 评测上的领先表现为长程任务可靠性提供基座
  • 上下文压缩与记忆调度：Opus 4.8 具备更强的长上下文压缩与关键信息抽取能力，更适合维护跨会话的频道记忆

成本副作用：Opus 4.8 的高 token 成本是这一选择的主要副作用——也是 Anthropic 在控制台提供"组织级 + 频道级 token 预算"双重配额控制的原因。

2.2 上下文引擎：三层记忆体系

Claude TAG 的核心创新在于将"上下文"从单次对话窗口提升为频道原生记忆。技术机制包含三个层面：

  • 层级 1：频道内上下文窗口——用户 @Claude 时，TAG 自动读取当前线程与频道历史。这与传统 DM 模式的关键差异在于：上下文来源从"用户主动粘贴"变为"系统自动注入"
  • 层级 2：结构化记忆库——TAG 在频道内持续运行时，将项目背景、团队惯例、技术栈偏好等显式与隐式知识抽取并写入记忆库。这是一种典型的过程式记忆（procedural memory）设计
  • 层级 3：跨频道学习——TAG 可以在管理员显式授权的前提下，自动从其他授权频道与数据源中收集信息。默认关闭，需要管理员逐一授权

2.3 Agent 调度器：任务分解与异步执行

TAG 的工作流遵循"分解 → 执行 → 汇报"三段式 Agent 循环：

  1. 任务分解阶段：用户以自然语言提出请求，TAG 使用 Opus 4.8 的规划能力将任务拆解为若干子任务
  2. 执行阶段：按子任务顺序调用可用工具（GitHub、Jira、Linear、数据库、CRM 等），每个子任务完成后再启动下一个
  3. 汇报阶段：所有子任务完成后，TAG 在对应 Slack 线程中回复执行结果，频道内所有成员可见

异步执行模式进一步扩展了这一循环：TAG 可接受"未来执行"的任务，并自主调度执行计划，跨数小时甚至数天持续推进。

三、Claude TAG vs 桌面应用：架构对比

3.1 三者定位

维度

Claude TAG

Claude Code

Claude Cowork

部署形态

托管服务（Slack 频道常驻）

终端 CLI（本地 Bun/Node.js）

桌面应用（macOS 原生）

目标用户

整个团队/频道

个人开发者

知识工作者

入口载体

Slack 频道 @Claude

终端 REPL

桌面聊天界面

协作模式

多人共享同一实例

单人本地

单人本地

运行位置

Anthropic 托管

本地进程

隔离 Linux VM

基础模型

Opus 4.8（固定）

Sonnet/Opus 可切

Sonnet/Opus 可切

发布时间

2026-06-23

2024-2026 持续迭代

2026 年初（研究预览）

3.2 输入层对比

输入类型

Claude TAG

Claude Code

Claude Cowork

用户显式输入

Slack 消息 @Claude

终端自然语言命令

桌面聊天框

上下文自动注入

频道历史 + 跨频道（需授权）

当前会话 + 本地 CLAUDE.md

当前会话 + 加载的 Skills

文件输入

通过 MCP 工具读取企业文件

本地文件系统直接访问

挂载目录（受控 VM 路径）

环境输入

Slack 频道事件 / 定时器 / Webhook

Git 状态 / LSP / 文件变更

屏幕截图 / 前台 App 状态

主动触发

Ambient Mode 触发器

用户手动触发

用户手动触发

关键差异：TAG 的输入是异步多源的；Code 是单用户同步流；Cowork 是视觉+文件双通道。

3.3 输出层对比

输出形式

Claude TAG

Claude Code

Claude Cowork

文本回复

Slack 线程消息

终端流式输出

桌面聊天流式输出

文件产出

通过 MCP 工具创建

本地文件系统直接写入

挂载目录写入

主动推送

Ambient Mode 主动通知

仅任务完成时通知

需用户查询

异步结果汇报

跨数小时/数天汇报

通过 task notification 系统

任务完成提示

工具调用轨迹

完整可审计

通过 hooks/telemetry

通过 MCP 调用日志

关键差异：TAG 的输出是主动+透明；Code 是任务驱动型；Cowork 是静默+人工确认型。

3.4 工具能力对比

工具能力

Claude TAG

Claude Code

Claude Cowork

本地文件读写

通过 MCP 间接

直接访问

通过挂载目录

Shell 命令执行

通过 MCP 间接

直接执行（用户授权）

沙箱内执行（用户授权）

GUI 自动化

不支持

不支持

Computer-use MCP（三级权限）

浏览器控制

通过 MCP 间接

不支持

Chrome MCP

企业系统对接

核心能力

需用户自配 MCP

需用户自配 MCP

跨进程协作

通过 Slack 频道共享

通过 worktree/team agents

不支持

异步自调度

Ambient Mode

任务系统

有限

三种工具能力定位：TAG 是企业系统连接器；Code 是开发者本地控制平面；Cowork 是桌面自动化代理。

3.5 互补关系

正如官方所述，Claude TAG 是 Claude Code 的"进化方向"而非替代——开发者在 IDE 中用 Claude Code 写代码，完成后通过 Slack 中的 TAG 推进 PR review、通知相关人员、更新项目状态。Claude Cowork 则填补了"非开发者 + 桌面任务"的空白。三者共同构成了 Anthropic "对话 → 桌面 → 团队" 的 LLM 界面三层演进路径。

四、brain / hands / session 三层解耦架构

本节是关于 Claude TAG 能力的核心问题的回答：频道端没有类似桌面应用的文件管理和 shell 处理能力，所有能力都来自 Managed Agents 架构中的 hands（sandbox + tools）层；不是预编排而是动态组装。

4.1 核心问题的回答

Q1：频道端有类似桌面应用的文件管理和 shell 处理能力吗？

A：没有频道端原生的能力。Claude TAG 本身在 Slack 频道内只是一个常驻的 brain（Claude Opus 4.8 + harness），它不直接访问本地文件系统、不直接执行 shell。所有"动手"能力都来自 Managed Agents 架构中的 hands（sandbox + tools）层——通过 execute(name, input) → string 的工具调用接口按需调度。

Q2：还是说所有能力都来自 Agent 调度器的 workflow 预编排？

A：不是预编排，是动态组装。TAG 的"工作流"实质上是 brain 的一次 agentic loop 调用：brain 接收 Slack 消息 → 整理 prompt → 调用 Opus 4.8 → 提取 tool use → execute(name, input) 调用 hands → 工具结果反馈模型 → 判断是否完成 → 汇报到 Slack 或继续循环。每次调用都是 brain 当场推理的结果，不是写死的脚本。

4.2 brain / hands / session 三层架构

来源：Anthropic 官方 Engineering Blog《Scaling Managed Agents: Decoupling the brain from the hands》（2026-04-08）

组件

角色

部署形态

生命周期

失败处理

brain

Claude + harness（控制循环）

无状态服务，可任意重启

短生命周期

失败时通过 wake(sessionId) + getSession(id) 恢复

hands

sandbox + tools（执行动作的容器）

按需 spin up，通过 execute(name, input) → string 调用

短生命周期（容器）

失败时作为 tool-call error 返回 brain

session

append-only log（所有事件）

持久化存储

长生命周期

通过 emitEvent(id, event) 写入；通过 getEvents() 查询

4.3 brain：大脑 + 控制循环

brain 由两部分组成：

  • Claude 模型本身（TAG 固定用 Opus 4.8）
  • harness（控制循环）：负责 prompt 编排、模型调用、tool call 路由、上下文压缩、stop hooks、预算控制

关键设计：harness 离开了容器——早期的耦合设计把 harness 放在同一个容器内，导致每次启动都要等容器就绪。新设计下 harness 是无状态服务，可以独立启动，p50 TTFT 下降约 60%、p95 下降超过 90%。

4.4 hands：真正"动手"的执行环境

hands 是 Claude 真正执行动作的地方，包含：

  • sandbox（沙箱）：执行 Claude 生成的代码、文件编辑、shell 命令
  • tools（工具）：MCP 服务器、Anthropic 自研工具、用户自定义工具

关键接口：execute(name, input) → string ——一个 name 和 input 进去，一个 string 结果出来。

原文原话："The harness doesn't know whether the sandbox is a container, a phone, or a Pokémon emulator."

安全设计：credentials（token、API key）从不进入 sandbox。它们通过两种方式注入：

  • bundled with a resource：例如 Git 仓库的 access token 在 sandbox 初始化时用于 clone repo，git push/pull 不需要 agent 处理 token
  • held in a vault outside the sandbox：MCP 工具的 OAuth token 存在 vault 中，Claude 通过专用 proxy 调用 MCP，proxy 拿 token 调外部服务，harness 永远不接触 credentials

4.5 session：append-only 事件日志

session 是所有事件的 append-only 日志，独立于 brain 和 hands：

  • brain 通过 emitEvent(id, event) 写入
  • brain 通过 getEvents() 查询
  • 支持 wake(sessionId) 恢复

关键洞察：session ≠ Claude 的 context window——session 是"context 之外的对象"，brain 可以选择性地读取事件流的某些位置、rewind 到某事件前几格重新读、变换后再注入 context window。这避免了不可逆的上下文压缩决策带来的失败。

4.6 对应到 Claude TAG 的实际行为

Slack 频道的"文件管理"能力：TAG 自己不直接管理文件。用户提交文件任务时：brain 解析任务 → 决定工具 → execute(name, input) 调用 hands 中的对应工具 → sandbox 执行文件操作 → 结果返回 brain → 整理后通过 Slack API 推送。

Slack 频道的"Shell 处理"能力：TAG 自己不直接执行 shell。类似流程：brain 决定需要 bash 工具 → hands 中 sandbox 启动隔离 shell 进程 → 命令输出作为 string 返回 brain → brain 用自然语言总结后回复到 Slack 线程。

Ambient Mode 主动介入的能力来源：

  1. session 持续记录 Slack 频道事件
  2. brain 通过 getEvents() 周期性轮询 session 日志
  3. brain 用 Opus 4.8 推理决定是否需要主动介入
  4. 决定介入时，通过 execute(notify_slack, {channel, message}) 调用 hands 中的 Slack 工具
  5. 工具执行后结果返回 brain，brain 在 session 中记录这一主动行为

这是 event-driven 但非 pre-scripted——每次"主动行为"都是 brain 当场推理的结果，不是提前编排好的工作流。

2.4 权限隔离层：频道级身份与作用域

TAG 的权限架构是其在企业场景下的关键差异化设计，核心原则是**"频道即身份"（Channel-as-Identity）**。技术上，这意味着 Anthropic 为每个授权频道维护一个独立的 Claude 实例 + 独立的记忆存储 + 独立的工具白名单。

设计哲学：销售频道的 Claude 不会将记忆写入工程频道，也不会让工程师访问销售数据。这种"硬隔离"设计相比 Microsoft Copilot 的统一 Graph 模型提供了更强的隐私保障，但代价是跨域知识融合的灵活性——这也是 TAG 默认需要显式开启"跨频道学习"的原因。

2.5 主动感知层：Ambient Mode

Ambient Mode（环境感知模式）是 TAG 区别于传统"被动响应"AI 助手的核心创新。开启后，TAG 不再等待被召唤，而是主动行动：

  • 监控频道动态，标记重要讨论
  • 跟进"沉寂的线程"（quietly went quiet 的话题）
  • 部署完成时主动推送通知
  • 定期执行（每周摘要、定时汇报）

技术实现上依赖三类触发器：

触发器类型

适用场景

事件触发器

监控特定事件（部署完成、PR 合并、告警触发）并按预设规则响应

时间触发器

定时任务（每周摘要、每日汇报）

条件触发器

基于上下文状态判断（如线程超过 N 小时无回复则主动跟进）

触发规则由管理员显式配置，TAG 不会随机插话——这是 Anthropic 在设计上的重要克制，避免"AI 过度主动"带来的团队疲劳。

五、关键洞察与开发者建议

5.1 Claude TAG 的核心定位

Claude TAG 不是一个 Slackbot，而是一个分布式的 agent 运行时，Slack 只是用户交互面。理解这一点有助于设计 TAG 集成方案时做正确的边界划分：

  • Slack 侧：只关心消息收发、频道管理、权限授权
  • Managed Agents 侧：brain + hands + session 的运维
  • 企业系统侧：MCP / API 集成

5.2 选型决策矩阵

场景

推荐产品

理由

写代码、调试、重构

Claude Code

本地直访 + 多 agent 隔离 + LSP 集成

处理桌面文件、浏览器自动化

Claude Cowork

Computer-use + 沙箱 + Skills 渐进披露

团队协作、跨系统协调

Claude TAG

多人共享 + Ambient Mode + 频道级权限隔离

预算敏感场景

Claude Code

可用 Sonnet/Haiku 控制成本；TAG 固定 Opus

隐私敏感场景

Claude Code

完全本地；TAG/Cowork 都涉及托管/沙箱

需要 GUI 自动化

Claude Cowork

TAG 不暴露 Computer-use 能力

5.3 核心设计哲学

  • 不要养宠物，要养牲口（cattle vs pet）：所有组件可互换、失败可重建、状态在 session log 中可恢复
  • 许多大脑，许多双手（Many brains, many hands）：brain 是无状态服务可水平扩展；hands 通过 execute(name, input) → string 接口透明接入
  • session ≠ Claude 的 context window：session 是 context 之外的对象，brain 可选择性读取事件流片段
  • 凭证永远不进 sandbox（vault 模式）：所有 credentials 存在 vault，harness 永远不接触

5.4 实战注意事项

迁移时间窗口：原 "Claude in Slack" 将在 30 天内被取代，建议提前备份历史对话记录。

跨频道学习默认关闭：隐私敏感组织默认安全，但需评估是否需要主动开启。

Token 成本：TAG 固定运行于 Opus 4.8，token 成本显著高于 Haiku 和 Sonnet，高频使用的频道需要提前规划配额。

平台限制：目前仅支持 Slack，使用 Teams、飞书、钉钉的团队暂时无法接入。

5.5 评估"动手"能力的边界

如果你的场景需要：

  • 大量本地文件操作 → Claude Code 更合适（本地直访，延迟低）
  • GUI 自动化 → Claude Cowork（TAG 没有 computer-use）
  • 跨系统数据汇总、PR 流转、Incident 响应 → Claude TAG（hands 优势在于远程 API 调用）

5.6 关注 hands 侧的凭证管理

TAG 的安全设计核心是凭证永远不进 sandbox。这意味着：

  • 自建 MCP 时，要确保 OAuth token 存在 vault
  • 审计日志中看不到 token 本身，只能看到 tool call 的 name 和 input/output
  • 如果你需要 "Claude 看到具体 token" 的审计，请考虑其他方案

六、参考来源

6.1 Anthropic 官方资源

6.2 行业分析与媒体报道

6.3 相关架构参考

文档信息：本汇总基于 2026-06-23 至 2026-06-24 期间的公开资料编制。所有内容均来自可公开访问的官方公告、媒体报道与社区分析。

posted on 2026-06-24 13:40  limingqi  阅读(140)  评论(0)    收藏  举报

导航