Claude Tag 这两周挺火。Anthropic 让 Claude 以团队成员身份常驻 Slack，有自己的身份，能看懂频道里的上下文，自己发现问题自己推进。Karpathy 管这个叫 LLM UI/UX 的第三次跃迁，Chat 到 Coding Agent 到 AI Coworker。
我写过一篇《OpenSpec + Superpowers + Harness，然后我们加了工程师》，讲的就是个人 AI 加速遇到团队瓶颈会发生什么。Claude Tag 就是一种方案，和我想的不太一样的另一种方案。
一个人用 Claude Code 用得再好，也不是终点。真正卡住生产率的，是一群人怎么一起用。现在的现实是，个人产出确实提上来了，但整个团队的交付时间、整体生产率，还没有看到质的飞跃。这个缺口，才是 Coding Agent 接下来真正要填的。
Channel 成员制，还是流程规范制
Claude Tag 解决这个问题的思路，是把 Agent 直接塞进协作频道，让它变成频道里的一个成员。谁在频道里讨论什么，它都知道，需要它的时候直接 @它，它可以接手别人已经开始的任务。
我自己的做法不一样。OpenSpec + Superpowers 这套东西，做的不是把 Agent 变成一个成员，是定义一套流程，让 Agent 来规范地执行这个流程，需求怎么写、怎么拆任务、怎么验收，都有明确的步骤。我把整个流程扩展到了团队协作的范围，怎么用 source management、怎么整合到 CI/CD、怎么做 evaluation、怎么定义 quality gate。
一个是让 Agent 融入团队原本的协作方式，一个是让 Agent 服从一套AI Native的流程。两种路子各有优劣。Channel 成员制的好处是门槛低，团队不用改变工作习惯，Claude 自己适应大家。流程规范制的好处是可控，每一步都有明确的产出物和验收标准，不靠 Agent 自己判断现在该做什么。
代价也是有的。Channel 成员制要处理的是一堆没有标准答案的协作细节，流程规范制要处理的是团队愿不愿意改变习惯去适应 AI Native 的开发流程。
协作真正难在哪，七个问题
Claude Tag 的相关资料我认真读了，我还是有些疑问。
Local 开发和 Channel 协作怎么协调
一个团队里，有人在本地用 Claude Code 写代码，Tag 同时也在频道里帮别人查 bug、准备修复 PR。这两拨工作，怎么不冲突？
原文里有个案例，有人在 Slack 反馈了个 Bug，Tag 自己去查 Datadog、Linear、GitHub，确认是真 Bug 之后直接准备一个修复 PR。查了官方文档，这不是个例，Tag 走的就是和 Claude Code 一样的分支、PR 机制。用的是自己的身份，Claude GitHub App，不是借用某个员工的账号。这个身份设计解决了用谁的权限提交的问题。
但人类是不是可以同时在 Local 开发同一块代码，官方文档也没细讲，没有专门的冲突协议。我自己的判断是，允许，但要靠阶段产出物对齐，不是靠禁止 Local 开发。
多人多 Thread，会不会乱成一锅粥
一个频道里，可能同时有好几个功能在推进，形成好几个小 group，各自跟 Tag 对话。这些 thread 之间会不会互相干扰？
原文给了框架。Tag 的记忆分三层，Thread context 管当前任务，是隔离的，Channel memory 管这个频道长期的规则和决策，是共享的。查了官方文档，这个隔离比我想的更彻底，同一个频道里的两个 thread，是两个完全独立的 session，各自跑在独立的 sandbox 里，运行时不共享状态。记忆层管的是加载哪些上下文，session 层管的是运行时怎么隔离，是两件事，合在一起才是完整答案。
我认可这个设计，但不知道规模变大了会怎么样。频道里同时挂十个 thread 和挂两个 thread，结果可能完全不一样，官方也没给出并发数上限。协作场景下 cache 命中率本来就低，thread 一多，这个问题大概率会被放大。
Context 会不会爆炸
聊得越多，攒的东西越多，什么时候该清空？
Claude Tag 自己的答案更直接。官方原话，它的记忆是一份整理过的笔记，不是完整的对话记录。积累方式有三种，用户明确要求记住的、它自己判断该保存的事实、按需回读历史 Session（不支持全文搜索）。不是自动抽象成经验，是靠筛选决定留什么。
这个答案比我预想的更保守，谁来决定笔记里留什么、删什么。这个筛选标准现在完全是模型自己判断，没有人工审核环节，出了偏差不容易发现。
我自己的判断，Channel 管协调，Local 管执行
协作频道负责阶段产出物的交接和确认，具体怎么写、怎么改，还是回到本地用 Claude Code 做。频道不是开发现场，是交接现场。
原文没有明说这个架构，但查完官方文档发现这条判断是对的，而且官方说得比我更直接。文档原话，团队工作用 Claude Tag，个人工作用 Cowork 或 Claude Code，两条路径分得很清楚，不是我自己脑补的分层。
Claude Code 定位是单人工具，需要人类先把 Context 整理好再喂给它。Claude Tag 天然泡在团队 Context 里，补的正是 Code 没有的那一层。两个工具本来就不是互斥的，分层用刚好对上各自的强项。
共享 Context 放哪，我猜的和 Anthropic 做的不一样
我原本觉得，团队共享的 context 应该放 GitHub，天然带版本历史，谁改了什么一目了然。
Anthropic 自己的选择不是这个。他们说尝试了很多记忆方案，最后发现最好用的是最朴素的文件系统，给模型一块能长期读写的空间，让它自己维护。不是版本化的仓库，是一块活的存储。
两种方案的取舍很清楚。GitHub 换来的是可追溯、可回滚，代价是每次读写都要走一遍版本控制的流程。朴素文件系统换来的是灵活和低摩擦，代价是没有天然的历史记录，出问题不好倒查。
版本控制、发布、回滚
Agent 自己产出的东西，要不要走发布流程？出了问题能不能回滚到它改之前的状态？
两篇资料都没碰这条，查官方文档才补上。代码这块没有专门给 Tag 做的回滚系统，走的是标准 PR，出问题靠 git history 倒回去，跟人写的代码一个流程。记忆这块可以让 Tag 自己改或者忘掉一条记录，但这是记忆管理，不是源码版本控制，两码事。
代码这块答案是现成的，不用重新发明。真正没答案的是记忆，一条记忆被改错或者被忘掉，没有历史版本可查，这个缺口原文也没提。
CLAUDE.md 该有几层
现在的 CLAUDE.md，是每个项目自己的宪法，定义这个项目的编码规范、架构原则、工具怎么用。这套东西是给单个项目、单个 repo 准备的。
到了团队协作场景，这一层不够用了。协作频道本身也需要规则，谁来提任务、什么时候该让 Tag 自己处理、什么时候要等人确认、跨项目共用的规范放哪，这些不属于任何一个具体项目，属于协作这件事本身。
我倾向于两层。项目层 CLAUDE.md 还是管具体项目怎么写代码，跟现在一样。协作层需要单独一份文件，管的是这个团队、这个频道怎么跟 Agent 一起工作，谁的任务谁认领、什么情况该升级给人、多个项目共用的规范放这里，不重复写进每个项目自己的 CLAUDE.md 里。
查完官方文档发现没有这样一份文件。官方文档甚至主动劝退，长 playbook 不建议塞进记忆里，该放进一个 Tag 能读的 repo，不要在记忆里反复重述。治理靠的是管理员配置的 Access bundles，按范围划分工具、仓库、指令权限，加上 channel memory 里沉淀的规则，没有一份统一的协作宪法。
这跟 Claude Code 的 CLAUDE.md 惯例是断开的，一个项目一份宪法这套习惯，到了团队协作这一层直接没有对应物。我觉得目前是真实的空白，需要增强。
AI驱动的团队协作现在还没标准答案
Claude Tag 给的答案是让 Agent 融入团队原有的协作方式，我给的答案是让 Agent 服从一套新定义的流程。哪条路先跑通，现在说不好。
但七个问题背后，还有一个更根本的变化在发生。AI 让每个人都能单干，一个人也能把一件事从头做到尾，不用等别人配合。这本来是好事，代价是协作的门槛反而变高了。以前意见不合，要么磨合要么僵持，现在多了第三条最省事的路，各自拉一个 AI 干，不用对齐。摩擦没有消失，只是从协作前挪到了协作后，等分支要合并的时候才爆发，代价更大。
Channel 成员制和流程规范制，都没有正面回答这个问题。谁在分歧发生时有权拍板方向，谁的判断优先于谁，各自单干出来的分支合并前要不要过一道审核，这些是角色问题，不是身份权限问题。Claude Tag 的 Access bundles 管的是谁能碰哪些工具、哪些仓库，不是谁听谁的。这一层现在完全没有产品化的答案。
我自己的判断是，Channel 里必须有显式的 lead 角色，不是靠资历或者嗓门大自然形成，是要写进协作层的规则里。分歧升级找 lead，分支合并 lead 过一遍，这两条卡住了，协作才不会散成一堆各自为战的超级个体。
但下一阶段的 Harness Engineering，要解决的已经不是 Agent 能不能干活，是一群 Agent 加一群人，怎么一起干活。这才是真正可以提高生产率的地方。
参考资料
- Introducing Claude Tag --- Anthropic 官方发布公告
- Claude Tag 产品页
- Work with Claude Tag（官方文档）
- How Claude Tag works（架构机制） --- thread/session/sandbox 隔离机制来源
- What Claude Tag remembers（记忆机制） --- 笔记式记忆的三种积累方式来源
- Set up Claude Tag（管理员配置） --- 访问要求、Access bundles 来源
- What is Claude Tag?（帮助中心）
- OpenSpec + Superpowers + Harness，然后我们加了工程师 --- 本文引用的自己的既有实践