上个月，Anthropic 的 Claude Code 设计负责人 Meaghan 发现了一件怪事。
她 Slack 设计评审频道里常驻的那个 Tag——一个以团队成员身份住在群里的 AI 同事——在长期参与设计评审之后，慢慢学会了她的提问角度：这个设计是为谁做的？想传达什么？跟我们的设计系统对得上吗？
再后来，Tag 不再等她下指令。它会直接在同事的设计草稿上迭代出一个更好的版本，有时还会主动找到相关同事，替她发起讨论：「嘿，Meaghan 之前是这么想的，这里有个原型你可以点点看，感受一下她的思路。」
这个故事出自最近一篇关于 Claude Tag 的深度研究（作者 Celia）。我读到的时候，第一反应不是「AI 好强」，而是一阵轻微的寒意： 这个 AI 已经悄悄学会了一个人的品味，并开始代表她在组织里行事。
多数人对 Claude Tag 的理解还停留在「Slack 里装了个聊天机器人」——@它，它回复。它今年 6 月以 beta 形式上线，8 月初 Anthropic 干脆把 Slack 里的 Claude 应用改名为 Claude Tag。从外面看，像是一个顺手发布的小功能。
但 Meaghan 的故事里真正发生的事情是： 组织认知，第一次变得像代码一样可以 fork、可以 merge。
一、先回答一个几乎没人问过的问题：周报和会议为什么存在？
标准答案是「信息同步」。但这个答案经不起推敲——如果目标只是同步信息，一块公告板就够了，为什么要让人开会轮流发言、写周报逐条汇报？
更深的答案是： 人类很会分工，但很难合并大脑。
每个人脑子里都装着一块不同的认知碎片：你知道客户上次说了什么，我知道这个架构为什么这么设计，他知道数据里藏着什么趋势。要一起干成一件事，这些碎片必须先合并成一份共同的理解，否则每个人都在用自己的碎片猜别人的碎片。
于是我们发明了一系列「合并协议」：
- 会议：同步合并。所有人花同一小时，轮流朗读自己的碎片，带宽约等于一个人的语速；
- 周报 / 日报：异步合并。把一周的认知压缩成几百字，上传给上级，等下次被读取；
- 文档 / 交接材料：持久化合并。把认知冻结成文件，代价是冻结的瞬间它就开始过期。
这三种协议有一个共同的缺陷： 慢、低带宽、有损。
有多有损？可以粗略算一下。下面这个模型把三种协议的开销和损耗量化出来（数字是示意量级，你可以换成自己团队的）：
from dataclasses import dataclass
@dataclass
class MergeProtocol:
"""一种人类认知合并协议。"""
name: str
hours_per_week: float # 全员每周投入的小时数
fragments: int # 一周产生的认知碎片数（示意）
loss_rate: float # 合并过程中的损耗率
def effective(p: MergeProtocol) -> float:
"""实际被合并进共同认知的碎片数。"""
return p.fragments * (1 - p.loss_rate)
protocols = [
MergeProtocol("会议（同步合并）", 8.0, 500, 0.6),
MergeProtocol("周报（异步合并）", 1.5, 300, 0.8),
MergeProtocol("文档（持久化合并）", 2.0, 400, 0.5),
]
for p in protocols:
kept = effective(p)
print(f"{p.name}：每周 {p.hours_per_week} 小时，"
f"合并率 {kept / p.fragments:.0%}，实际合并 {kept:.0f} 个碎片")
# generated by hugo AI
典型的输出大概是这样：三种协议加起来每周烧掉十几个人小时，却只有一小半的认知碎片真正进入了共同理解——而剩下那一多半，往往恰好是最值钱的部分。
会上说出来的，是你想到的一小部分；周报里写下的，是你做过的一小部分；文档里留下的，是你理解的一小部分。最值钱的那部分——当时为什么这么定、走过哪些弯路、哪个方案被否掉时大家脸上的表情——在每一次合并里都悄悄丢失了。
那篇研究里有一句话，我认为值得所有管理者抄下来：
会议、文档和周报，本质上都是人类为了合并集体认知发明的工具，只是它们速度慢、带宽低，而且会损失大量隐性知识。
二、Git 二十年前解决了代码的合并，组织等到现在
软件行业其实早就遇到过同样的问题：很多人改同一份东西，怎么保证大家的改动能合并而不打架？
答案是 Git。它没有试图合并程序员的头脑，它只合并「代码变更」——但这就足够改变协作范式：上千个素未谋面的人，可以常年共同维护同一个代码仓库。
把两种协作方式放在一起看：
| 代码协作（Git） | 组织协作（传统） | 认知协作（AI Coworker） | |
|---|---|---|---|
| 合并对象 | 代码变更 | 人的认知碎片 | 上下文 + 记忆 + 判断痕迹 |
| 合并方式 | pull request + review | 会议 + 周报 | 共享记忆层 + agent 并行 |
| 带宽 | 高（完整 diff 可查） | 低（语言压缩，大量有损） | 高（原始上下文） |
| fork 成本 | 几乎为零 | 极高（重新培养一个人） | 几乎为零（复制一个实例） |
Claude Tag 这类产品做的事情，就是把 Git 范式搬进组织认知。
它的三层记忆——当前任务的 thread 上下文、频道长期沉淀的 channel 记忆、全公司共享的 workspace 记忆——本质上就是一个 带分支权限的仓库：每个频道像一间彼此隔离的办公室，agent 只能看到自己所属房间里的东西，获得授权才能走出去。那篇研究里引述 Anthropic 内部员工的说法：Tag 正在变成一个「全知全能的共享大脑」。
传统组织：认知靠人串行合并
A 的认知 ──周报──> 主管 ──会议──> B 的认知
（压缩成 500 字） （轮流发言 1 小时）
AI Coworker：认知直接跑在共享记忆层上
人 A ─┐ ┌─> 人 B
人 C ─┼─> 共享上下文层 ────────┼─> 人 D
工作痕迹┘ （原始上下文 + 三层记忆）└─> Agent × N（可 fork）
人类同一时间只能进行一场对话，而 Tag 可以同时进行几千场，且全部跑在同一个记忆层上。于是出现了一个此前组织里不可能存在的角色：它整合所有的产品决策、工程决策和运营决策，把分散的线索串起来，主动提示每个人可能的盲区。
Meaghan 的 Tag 之所以能「代表她」，不是因为它模仿了她的语气，而是因为它一直在读她所有的设计评审记录—— 它 merge 了她。
在 你的下一个下属，不需要工位 里，我写过数字员工「上岗」需要的东西：岗位、权限、验收标准。Tag 是这个判断的第一个成熟产品形态——它有岗位（频道里的角色），有权限（频道级隔离），有记忆（三层仓库）。
三、是什么让 merge 成立，又是什么还卡着它
Tag 不是第一个做这件事的产品。Devin 做过，年初爆火过的 OpenClaw 做过，今年 2 月发布的 Viktor 也做过——10 周做到 1500 万美元年化收入、2000 多家付费组织，增速堪比当年的 Lovable 和 Manus（这些数据我在外部报道中核实过）。
但它们都没有大规模铺开。按那篇研究的梳理，真正让 merge 成立的工程前提有三件事：
第一，任务时长决定产品形态。 模型只能自主工作几分钟时，合适的产品是 Chat；能推进约一小时的任务时，local coding agent 成立；能稳定工作数小时之后，async coworker 才成立。产品形态不是产品经理选出来的，是模型自主时长这个变量算出来的。据文中引述的 METR 评测口径，最新的前沿模型已经能完成约等于人类专家连续工作 16 小时的任务，再叠加自我排期能力——先做完现在能做的，再把下一步安排到下周三——单次执行就能串成持续几个月的长程任务。
第二，记忆的最终答案是最朴素的文件系统。 Anthropic 试过很多记忆方案，最后发现最好用的就是给模型一块可以长期读写的空间，放手让它自己维护。而高低阶模型的差距，文中说得很直白：在于「蒸馏」能力——高阶模型不只记录具体事件，而是会思考这段经验以后还能泛化到哪里。
第三，情商。 Tag 被专门训练过分寸感：什么时候该主动帮忙，什么时候该退居幕后。这决定了它是「同事」还是「噪音」。
但也要诚实地说，这个范式还没有成熟，两个卡点都很硬：
- 成本：一家 20 人的公司放开用 Tag，一个月可能烧掉几万美金。贵的工程根源是 cache 命中率低——多人协作天然异步，半天前一个人发起的任务，另一个人回来继续时 cache 早已失效；每个人的权限和上下文不同，cache 结构无法复用；再挂上上百个 connector，工具描述本身就在烧 context window。这是我认为全文最值钱的一个工程洞察。
- 权限：Tag 要发挥价值，就必须拿到公司的大量上下文和系统权限，但目前没有任何方案能给出企业级的安全承诺。99% 的可靠度不够，剩下那 1% 才决定产品能不能进企业。有用户的评论一针见血：「Claude Tag 就像把整个公司交给 Anthropic，然后再从他们手里租回来。」
所以更准确的说法是： 组织认知的 fork 和 merge，刚刚被证明可行，还没有被证明便宜和安全。
四、这对你意味着什么
在 AI 的竞争变了：未来是上下文的竞争 里，我说过模型之争已经不是决定性战场；在 要 AI-native，我最想让大家停掉的不是手工劳动 里，我说过要把信息流动的介质从人换成 Agent。这一篇是它们的下一层：介质换掉之后，组织的认知第一次可以合并了。三个角色各有各的动作：
个人：留下可合并的资产。 你的认知不会自动 merge 进组织，只有你写下来的部分会被 merge。决策记录、机器可读的上下文，不是写给主管看的汇报材料，而是你向组织仓库提交的 pull request。半年后有人问「当时为什么这么定」，能不能挖出答案，取决于你今天提交的质量。
Leader：公开频道不是文化口号，是基建。 那篇研究里有个细节：为了让 Tag 拿到完整的原始上下文，Anthropic 在刻意营造高度公开的文化——尽量把工作放在公开频道，减少私聊。因为私聊就是 merge 层读不到的数据。你组织的公开程度，直接决定了你的 agent 有多聪明。
组织：上下文层要留在自己手里。 Tag 的两个卡点——成本和权限——恰恰是企业组织系统的主场：权限图谱、组织架构、审批链，本来就握在企业手里。模型和 agent 会越来越可替换，但认知仓库只有一个，它应该属于企业自己，而不是租回来的。
五、写在最后
如果组织认知真的可以 fork 和 merge，那人类还剩下什么必须亲自做的？
我的答案还是那两个词： 判断，和担责。Agent 可以合并所有人的认知，但它不能为合并的结果负责。总得有人看着 merge 之后的版本说：这个方向对，出了问题算我的。
这正是管理者在 AI-native 组织里的新岗位：不再做信息的汇聚点，而是做合并结果的验收人。
这个系列从上下文的竞争（#337），写到信息介质的换代（#338），再写到认知的合并（这一篇）。下一篇想写那个最现实的问题：协作型 agent 这么贵，什么时候能用得起——cache 命中率这道题，解法可能不在模型侧。
你在组织里见过哪些「认知无法合并」的场景？欢迎留言聊聊。