# Claude Tag：让 Workflow 从工作现场长出来

最近看到不少人把 Claude Tag 称为“10 倍的 Claude Code”。

如果只是想说它的使用范围远远超过写代码，这个说法很好理解。但如果把它理解成 Claude 的 Agent 能力突然提高了一个数量级，我觉得反而容易错过这个产品最有意思的地方。

Claude Tag 带来的变化并不主要发生在模型上。**它把 Claude 放进了工作本来就在发生的地方。**

这会明显改变我们建设 Workflow 的起点。

## Claude Tag 到底是什么

Claude Tag 是 Anthropic 最近推出的一种 Claude 使用方式，目前主要工作在 Slack 中。

团队成员不需要离开正在讨论的频道，可以直接在 Thread 里 `@Claude`，把正在发生的任务交给它。Claude 能够理解前面的讨论，根据管理员开放的权限访问代码仓库、文档或其他业务工具，然后在独立环境里完成任务，最后把结果送回原来的对话。

这和过去把聊天机器人接进 Slack 有明显区别。普通 Bot 更多是在等人提问，Claude Tag 试图直接参与正在进行的工作。

比如产品团队正在讨论一个 Bug，聊到一半可以让 Claude 去代码仓库里定位问题，修改代码并准备 Pull Request；Support 团队发现某类客户问题反复出现，可以让它结合频道讨论和业务资料进行处理；Operations 团队看到告警，也可以在原来的工作频道里让 Claude 调查相关日志和监控信息。

Anthropic 自己已经把 Claude Tag 用到了代码开发、产品指标分析、Support Ticket 和复杂 Bug 调查中。官方披露，其内部版本已经贡献了产品团队约 65% 的代码。

Claude Tag 也不局限于有人 `@` 它的时候。反复发生的任务可以逐渐变成定时执行，某些频道或监控对象也可以交给 Claude 持续观察。团队在日常使用中补充的背景和纠正，会成为后续工作的上下文。

因此，Claude Tag 看起来很像一个越来越通用的 AI 同事。

但我更关心的是另一层变化：**过去建设 Workflow 时需要额外收集的大量工作信息，现在已经有相当一部分直接出现在 Claude 周围。**

## AI 先进入工作，Workflow 再逐渐显露出来

上一篇文章里，我把目前比较容易跑通的 Agent Workflow 归纳成了 Build、Service 和 Operations。

Coding 属于 Build。Customer Service 和企业内部 IT Service 属于 Service。Security、服务器运维和监控更接近 Operations。

它们能率先使用 Agent，一个重要原因是这些工作经过多年发展，已经形成比较清楚的输入和输出，也有现成的软件工具、评价方法以及反馈机制。LLM 补进来的，主要是过去很难程序化的理解和判断。

可这又带来另一个问题。

知道什么样的 Workflow 容易使用 Agent，并不意味着我们坐在会议室里就能准确找到它。

很多企业做自动化时都会经历类似过程：先访谈，画流程图，设计方案，最后才发现员工平时实际怎么工作，与流程图上的描述相差很远。个人也一样。我们以为自己每天都在做某项重要工作，仔细观察以后，可能会发现大量时间其实花在另外几个重复动作上。

Claude Tag 提供了一条不同的路径。

先让 Claude 进入团队平时工作的 Slack Channel。员工遇到问题时直接把任务交给它，不需要先定义这是不是某种 Agent Workflow。

使用一段时间以后，再回头观察这些委托。

有些请求只发生过一次，不需要继续处理。有些任务却不断重复，而且每次需要的信息差不多，调用的工具差不多，人最后检查结果的方法也差不多。

这时候，一条 Workflow 已经开始露出轮廓。

**与其先想象未来需要什么 Agent，不如先看大家反复把什么工作交给 AI。**

## 从一句 `@Claude` 到一条 Service Workflow

例如一个 Support Channel 最初可能只是有人偶尔说：

> `@Claude，帮我看看昨天还有哪些客户问题没人处理。`

Claude 阅读频道里的讨论，找到相关 Thread，再结合已经开放给它的系统信息整理结果。

连续做过几次以后，团队可能发现，这项工作每次都遵循相似的过程：先找到没有处理的客户请求，判断优先级，补充客户背景，找到负责人，随后关注问题有没有解决。

最开始，这些步骤都由人在 Slack 里临时告诉 Claude。

等模式逐渐清楚以后，每日检查可以改成定时运行，客户信息可以直接从 CRM 获取，紧急程度可以按照已有规则判断，哪些动作由 Claude完成，哪些情况交给人，也可以逐渐明确。

最初的一句 `@Claude`，就这样慢慢演变成一条 Service Workflow。

Operations 里也会出现类似过程。

开始时，工程师只是把某个 Alert 丢给 Claude：

> `@Claude，看看这个告警怎么回事。`

Claude 去找相关日志和监控信息，把线索整理出来。

如果每天都有同类问题，团队就会自然想到下一步：能不能让 Claude 主动观察这些告警？哪些信息每次都需要查？哪些问题可以直接判断？哪些操作风险太高，只能交给工程师？

到了这里，重点已经从“Claude 会不会分析告警”，转向“这条工作链怎样稳定运行”。

这正是 Workflow Engineering 开始出现的位置。

## Claude Tag 减少的是前期摸索

过去自己搭 Agent Workflow，一个很麻烦的环节是准备上下文。

团队刚刚讨论过什么，为什么做这个项目，哪份文档最重要，哪个仓库相关，过去发生过什么类似问题，这些信息经常散落在 Slack、文档和各种业务系统里。

换到一个独立 Agent 中工作，首先要把这些背景重新搬过去。

Claude Tag 已经站在 Slack 里。至少团队正在讨论什么、前面做过什么判断、谁纠正过 Claude，这些信息不需要每次重新解释。管理员还可以根据频道需要，把代码仓库或其他业务系统开放给它。

它当然不会因此自动获得企业所有信息。CRM 是否开放、哪些代码仓库能够读取、某个私人频道能不能访问，依然需要组织自己决定。

但起点已经发生了变化。

以前是：

> 先搜集工作信息，再让 AI 开始工作。

现在更像：

> **AI 已经在工作发生的地方，再根据任务逐渐补齐缺少的信息。**

另一个被明显简化的环节，是 Workflow 的发现。

过去要靠访谈和流程分析判断什么适合自动化。Claude Tag 出现以后，团队每天怎样使用 Claude，本身就开始提供线索。

如果几十个人不断要求 Claude 做同一种工作，这比一张流程图更能说明需求存在。

如果一种任务每次都需要大量人工补充背景，说明它距离稳定 Workflow 还有很远。

如果 Claude 每次都能顺利完成，人只做简单检查，那就很适合继续向自动执行推进。

**使用过程本身开始帮助团队发现下一条 Workflow。**

## 高频使用只是起点

这并不意味着，一个任务经常被交给 Claude，就已经完成了 Workflow 建设。

反复委托只能说明这个方向可能有价值。

想长期运行下去，团队迟早要把几个问题弄清楚：这项工作究竟解决什么问题，Claude 可以读取哪些信息，可以使用哪些工具，动作做到哪里需要停下来，怎样判断结果是否合格，以及发生异常以后由谁处理。

这些内容逐渐稳定以后，一条 Workflow 才有了比较可靠的边界。

这里固定下来的也不是传统 RPA 那种一步接一步的脚本。

Claude 每次调查问题时完全可以选择不同资料，调用不同工具，根据当时的信息调整路径。**稳定的是工作的目标、权限和反馈机制，执行过程可以继续保持动态。**

这也是 Agent Workflow 与传统自动化很大的区别。

## 通用的是入口，工作不会因此变得通用

Claude Tag 很容易让人产生另一种想象：既然所有频道都可以 `@Claude`，是不是一个通用 Claude 最后就可以承担所有工作？

从用户角度看，未来可能真的会越来越接近这种体验。

员工不需要知道后台正在运行 Build、Service 还是 Operations。他只知道自己正在 Slack 里工作，需要帮助的时候可以直接叫 Claude。

但建设者看到的会是另一幅图景。

Engineering Channel 后面连接的是代码仓库、测试和开发权限。Support Channel 需要客户资料、业务规则和服务系统。Operations Channel 使用监控、日志和告警，并且会面对完全不同的操作风险。

表面的入口可以完全一样，背后的 Workflow 却需要各自建设。

**Claude Tag 让 Agent 的入口越来越通用，却没有让工作的边界消失。**

这与之前几篇文章里讨论的 Agent 工程化是一致的。

模型可以越来越强，用户和 AI 之间的交互也会越来越简单。但一项工作能不能长期交给 Agent，最终看的依然是输入是否清楚，有没有合适的工具，动作范围怎样控制，结果怎么评价，人工纠正又怎样进入下一轮。

Claude Tag 没有绕开这些问题。

它做得很聪明的一点，是允许我们晚一点解决这些问题。

先让 AI 进入工作现场。

先让人自然地使用它。

先观察哪些委托反复出现，哪些做法产生稳定效果。

然后再把其中少数重要的部分逐渐建设成 Workflow。

所以，与其把 Claude Tag 理解成“10 倍的 Claude Code”，我更愿意把它看作一种非常好的 Workflow 孵化方式。

**它降低的不是 Workflow Engineering 的重要性，而是让我们更容易找到应该从哪里开始。**