Claude Tag 这个产品市面上的仿品很多，但我看到的绝大多数的产品仿品仿其型而未有仿其神。这背后是本身绝大多数仿品的团队都是 TO C 创业者出身，导致对于他们来说，并未看出背后的很多设计的原因。而作为一个真的干过 TO B 的产品经理，我觉得大家其实做的都还是 TO C 的产品，由于实在看不过眼（觉得在座的都是垃圾），我决定自己写一篇对于 Claude Tag 的拆解，方便大家参考和使用。
对于 Claude Tag 来说，其神在于：
- 访问按地方配，不按人配。 配置的单位是 scope——整个组织（Default Slack access）、一个 Workspace、一个 Channel——Access Bundle 挂在 scope 上，往下继承；一个 Channel 拿到的是它自己、它的 Workspace、组织三层 Bundle 的并集
- 记忆跟地方走，不跟人走。 Memory 只有两层：Public Channel 里产生的记忆在整个 Workspace 内共享，Private Channel 只读共享层、写自己那一份；
- 用组合来在不同地方配置 Agent。你可以通过组合 Access Bundle， 在不同的位置，给 Agent 组合出各种用法的能力，从而让 Agent 真正解决问题。
如何开通 Claude Tag
花钱就行，50 刀起步；我花了 70 刀；50 刀是用来开 Claude Teams 权限；剩下 20 刀是 Claude Tag 日常消耗的（我觉得对于很多小公司来说，Claude Tag 的一大痛点可能在于成本太高，因为不是按照订阅算的 Token，而是按照真实的消耗算的 Token，那你可能真的得思考，我真的有必要上 Claude Tag 么？以及会考虑选择使用更便宜的 Sonnet 模型作为 Claude Tag 的主模型）。
Claude Tag 怎么使用
比较简单粗暴，当你完成 Claude Tag 连接之后，接下来直接 at Claude 做事就行；过程中可能会涉及到你要去做一些前置授权等。
但需要注意的是，目前 Claude Tag 的所有使用必须放在 Channel 中进行；私聊是无法使用 Claude Tag 的，它只能在 Channel 中使用，你需要把它放在任何一个 Channel 中使用；不过好在是，我测试了，其实你可以在 Private Channel 中使用 Claude Tag。所以你依然可以和他一起工作。只是 Private Channel 会在管理后台看不到 Channel Name
Claude Tag 产品原语
在看 Claude Tag 的细节功能上，我们需要先理解 Claude Tag 的产品原语，以便于我们对齐对于 Claude Tag 的理解，并且让你对于 Claude Tag 的产品理解有一个更加形象的认知，避免快速沉浸到产品的具体功能细节里。同时也更好的帮助理解不同功能的服务层级。
整个 Claude Tag 从产品原语上，你可以定义包括三个大类：Space（任务和行为发生在哪）、Capability（能执行和发生什么样的任务）、Control（如何控制这些任务的发生）。
Space 又可以进一步细分为 Organization、Workspace 和 Channel，后两者可以直接对应到 Slack 的相同概念（Claude Tag 如今还是和 Slack 有较深的绑定），且 Channel 是会话中的最小单元。和 Slack 一一对应可能是源自 Claude 团队自己在用，所以也就没做更多其他品类的兼容。Session 和 Routines 则是会发生在这些 Space 中的具体的会话；Session 是由人类触发的行为，而 Routines 则是由 时间触发的行为。底部的 Environment 则是两个 Session 的运行环境；
Capability 则可以细分为四个子类：Repositories、Domains、Plugin、Credentials ； Repositories 可以提供让 Claude Tag 访问的权限，你可以同时链接多个不同 Github Org 的多个 Repo，从而让 Agent 可以在多个 Repo 中协作。Domains 则给 Claude Tag 了网络访问权限， 通过 Domains 的配置，让 Claude 可以访问到目标的网站，从而获取到必要的信息，从而确保 Agent 的网络行为是可管控的，避免出现信息异常出网的情况。credentials 则提供了不同 SaaS 服务的链接能力，在完成授权后，Agent 会获取到对应的授权，以及一些预制好的 API 请求方式，从而你可以让 Claude Tag 在整个过程中，可以访问到一些外部的 SaaS，从而搞定所有的工作。Plugin 则是一个我们大家相对熟悉的概念，之前在 Claude Code 当中就有，Claude Tag 使用的 Plugin 基本上是一致的；不同的是 Claude Tag 不会执行其中的 Hook，但对于 Skill 和 MCP 都是完全支持的。
在 Capabilities 最下方，还有一个虚线的 Access Bundle；Access Bundle 是一个 Capabilities 的打包合集，其中包含了Repositories、Domains、Plugin、Credentials、Instructions。你可以在某个 Channel 中找到专属的配置，也可以直接添加一个 Access Bundle，来批量管理这些内容；从而，你可以非常快速的将一组预设好的 Access Bundle 给应用到某个特定的 Channel 上。从而快速完成不同 Channel 的配置。这里有一个特殊的是，Instruction 也是可以放在 Access Bundle 当中一起传递的；不过在产品的原语中，我将他放在了 Control 中。所以这里 Access Bundle 横跨了 Capabilities 和 Control。
在 Control 中，则汇聚了各种对于 Agent 的控制能力（aka：让 Agent 更好的做事），这里包括了我们刚刚提到的 Custom Instruction、Memory、Auto mode allow rules、Channel name rules、Channel name rulesd等一系列细节产品功能，这里比较重要的是 Custom Instruction 和 Memory。Custome Instrucion 会出现在 Org、Channel 级别的配置当中，对应的描述会出现在 Agent 的 System Prompt当中，引导 Agent 行为。Memory 则记录了你在和 Agent 之间的交互中产生的信息，支持频道级别的 Memory 和 全局的 Memory ，从而可以实现一些很有意思的用法（比如 Claude Tag 宣发中的一个 Case: 不同用户在不同 Channel 中和 Claude 聊同一件事，Claude Tag 会主动告知另外一个用户所做的决策）。其他我们就不再专门讲述，稍后会按照具体的功能细节时再说。
当你了解了 Claude Tag 的产品原语、定位和他们之间的关系之后，我们就可以来看看他的一些底层设计机制和数据状态了，能帮你更好的理解后续的一些功能设计。
Claude Tag 的一些数据设计
对于整个 Claude Tag 来说，你可以认为数据大概是这个样子的。
- 所有的数据都归属于某个特定的组织；组织下可以拆分多个不同的 Workspace（就像你可以是 Openai + 对应的 FDE 组织）。图的上部
- 每个 Workspace 里可以有一整套独立的 Channel、Memory 等机制；图的中左部。
- 当你进入到每个 Workspace 之后，你会看到 Workspace 内部的 Memory（工作区级别的），然后里面可以有不同的 Channel 来进行日常的沟通和不同工作的分配。比如有的做 A，有的做 B；有的做 C；大家分布在不同的 Channel 里；图的中下部
- 每个 Channel 中有自己的 Channel Memory 、Custom Instruction、Access Bundle、Plugin、Credentials、Repository 等一系列 Agent 运行所需要的信息。用户可以根据自己的需要选择合适的内容。图的中右部。
- Channel 内部，会同时出现多个 Session 或 Routine。且由于存在自定义 Environment 的能力，可能会出现部分运行在 Anthorpic 的 Runtime 里，部分运行在用户自建的 Runtime 里。
上面的这种数据组织方式，很好的满足企业对于数据的管理诉求：
Claude Tag 的一些产品设计细节
围绕这上述的产品原语、产品数据设计；和面向 To B 的产品设计，里面出现了大量很符合 To B 产品直觉的产品设计。
- Claude Tag 是组织买给你的，所以组织、Workspace、Channel 当中，都要能够给你的 Channel 设定不同的 Custom Instruction，从而确保你在使用 Claude Tag 做应该做的事情。正常情况下时按照顺序一层层拼接。
- 一个公司可能会存在不同的部门和分公司；不同的产品团队也可能会使用不同的 Slack Workspace ，从而更好的做好权限管控。因此，要支持一个 Claude Tag 能连接多个 Slack workspace。
- 一个 Agent 想要完整的完成一系列工作，不是简单的 Prompt 、Skill 就能解决，依赖MCP、鉴权、Skill和一定的指引。如果一个 Agent 要被持续复用（比如做客服 Channel 用），那么提供一个打包的 Access Bundle 就是必要的。
- 由于每个 Channel 都不是从 Day 1 就开始思考 Access Bundle，和目前这种 Channel 中除了 Access Bundle 还能单独配置 Credentials（在单独Channels 里叫 Connector ）、Plugin 的能力，我猜测大概率他们是先有 Channel 级别的单独配置，后面共享多了，干脆提供了单独的 Acess Bundle。目前已经出现每个 Channel，很快可能就会去掉 Channel 级别的配置，直接改 Channel 上的默认的 Acess Bundle 就行。
- 在让 Agent 工作时，会涉及到一个 Agent 可能有多种职能，因此允许 Access Bundle 的叠加
- 由于在 Slack 的对话式交互中，进行权限审批是一个复杂和不好判断的事情，因此，设计了 Auto mode allow rules，允许用户根据需要，写一些简单的规则，来让 Agent 自己进行 Auto mode 下的判断。一方面相信 Agent 的能力；另一方面，也给了企业足够的控制权。对于 Claude 还不擅长的业务领域，提供了足够的逃生空间。
- 因为要把 Claude Tag 用在对外客服，因此支持 Claude Tag 被 Guest 访问；但对于不把 Claude Tag 用作客服场景的企业来说，可以直接关掉这个 Feature。
- Claude Tag 似乎改了一次计费逻辑；在上个月我刚开通的时候，是你充值多少用多少；上个月两个任务花了我 $10 ；我赶紧把默认模型改成了 Sonnet 5 ；但今天写这个 Blog 的时候发现，似乎也变成了 Credit 的机制。如果是这样的话， Claude Tag 还蛮香的。
- 如果是将 Claude Tag 用在客服支持等场景，可能会出现某些特定规则的群名，这些群名可能是希望 Claude Tag 加入或者不加入的，所以这里还会有专门的 Channel Name Rule；有白名单有黑名单；白名单会自动加入；黑名单则是绝不加入。对于一些做客服的场景，完全可以把 Channel 名写成 [Channel Support]，然后等 Claude Tag 自己进去做支持。
Claude Tag 的 Memory
Memory 是如此的重要，以至于我认为我一定要专门开一章来写它。如果你要做仿品，只做一件事，那我认为就是做这个 Memory 体系。
Claude Tag 也为其产品设计了 Memory 的机制，
你可以看到，Claude Tag 的 Memory 是以树的形式来组织的：
你会先在 workspace 级别的 Memory 中，看到 每个 Channel 中的 Memory ，但这里其实是各 Memory 的 Channel 的总结，更多是一个 Summary；而不是完整的 Memory；
而 Channel 级别的 Memory，你需要切换到 Channel 的选项中，查看详情。
在实际的使用时，memory.md 会作为索引，加载到 System prompt 中，Agent 根据需要，自己加载别的文件
且系统会根据相关性，通过对 Description 的二次判断，正式判断是否需要加载 Memory 当中的细节，并取 前4K 放在 context 中，方便 Agent 进一步自己去读。
Claude 一个 Channel 中可以有多个 Session （每个 Threads 都是一个新的 Session），Claude Tag会在开始处理任务的时候加载 Memory，因此，如果某个 Threads 写入了 Memory，另外一个 Threads 大概率需要到下一次调用时才能加载到。
在写入 Memory 的时候，Claude Tag 是在本地以文件夹和文件的方式组织 Memory， Agent 在必要的时候，写入相关的 Memory，当然，你也可以自己主动和他说。
Claude 会把 Memory 写入到 Channel 和 Silo 文件夹；这两个文件夹的区别主要在于silo存储的是 workspace 级别的 Memory；而 Channel 存储的是本 Channel 自身的 Memory，这样就可以同时兼顾本 Channel 和全局的 Memory，从而确保 Agent 能及时获得必要的 Memory；同时，因为 Agent 可以同时看到两组 Memory，就可以有所取舍，将 memory 放在合适的位置。
===== 我在沙箱里看到的目录（文档未描述） =====
/tmp/claude/memory
`-- team
|-- channel
| |-- .memory-sync
| |-- .memory-sync-basis
| |-- MEMORY.md
| |-- bestony-language-and-timezone.md
| |-- claude-tag-custom-instructions-layering.md
| |-- claude-tag-primitives-review.md
| `-- report-delivery-format.md
`-- silo
|-- .memory-sync
|-- .memory-sync-basis
`-- channel
|-- C0BQB2J46D6
| |-- MEMORY.md
| `-- report-delivery-format.md
`-- C0BQB5WPQD6
|-- MEMORY.md
`-- bestony-timezone.md
7 directories, 13 files
Code language: Bash (bash)Claude Tag 的审计功能
作为一个 To B 的产品，审计功能是必须的。 Claude Tag 也提供了一些基础的审计能力，分三个大类：Scheduled Work、Memory 和 Network Event。
Scheduled Work 能够查看 Agent 的定时任务；不过也会发现 Agent 在执行任务的时候，也会把一次性任务当成 Scheduled Work 录入，从而导致展示在这里。
memory 则是整个 Org 级别 Memory 的展示，你可以根据需要查看和编辑某些 Memory。
Network Event 则是可以真的查询某个 Agent 对于网络的调用情况（还记得前面配置的 DOMAIN 么？）。
选择要查询的时间范围，就可以查询对应时间范围内的网络请求并分析。
Claude Tag 的 Custom Runtime
作为一个企业级产品，企业肯定会希望能够让运行行为发生在企业可控的网络环境，这样就可以充分利用企业内部的各项资源来完成这个目标。
Claude 支持创建一个 Self Hosted Environments ，来控制 Cloud Session 运行在哪个服务上
可以通过后台的配置，创建一个新的 Self Hosted Environment 来配置自己的 Runner，从而在企业内部使用的时候，就可以直接使用内网的设备来运行任务，执行各项内部基建。
再配合 Access Bundle 中的 Domains 的配置，可以开启对内网服务的访问权限。
辅以 Federated cloud access 链接到内部的 Gateway、授权服务，来实现整个内部的权限管控、安全控制，从而更好的服务企业，让企业更敢于使用 Claude Tag。
Claude Tag 的统计看板
Claude Tag 为用户提供了一个非常简单的统计看板
不过，最核心的 —— 哪个 Channel 最烧钱依然是有的
Access Bundle 的一些细节
- Access Bundle 的 Credentials 除了已经提前集成好的服务，还可以加入自己自定义的 MCP 和 API Server
在使用 API & MCP 接入的时候，可以配置多种不同的授权方式，来满足绝大多数常见的业务场景，确保你能接入绝大多数业务。
Repositories 的的支持需要你将 Claude 的 App 安装到你的 Org 里，才能使用。
如果你有多个 repo ，也可以配置具体要用哪个 repo
我觉得比较好玩，但觉得很合理的设计包括：给用户一个 prompt，发给 github account owner 来做 link
在配置 Plugin 的时候，你可以选择多个 Plugin 放在同一个 Bundle 里，来方便使用和配合。还可以接入组织自己的 Organization，来方便使用组织内部特有的 Skill & MCP。
总结
这篇文章一边写一边截图，花费了将近 3 个小时，希望内容能帮到你，更好的思考 —— Claude Tag 到底给用户提供了什么。绝不是简单的将模型链接到 Slack 上；
背后的功能、实现，对于 TO B 功能的考究，都是很值得学习的。
都看到这了，我猜你肯定想试试看这类产品？那不妨试试我最近参与开发的一个开源项目 —— https://github.com/first-tree-ai/opentag 。我承认，我们还没做到很多这篇文章中提到的 Claude 的功能，但，在路上了，不是么？也欢迎你参考进来一起开发。
