Claude Tag 深度拆解：Slack 里的共享 AI，正在长成组织级 Agent 运行时

如果把 Claude Tag 只理解为 Slack 机器人，会错过它最重要的产品变化。它把频道变成了一个可授权、可记忆、可持续运行的 Agent 空间：团队共享同一个执行者，任务在 Anthropic 托管的线程级沙箱中异步完成，外部凭证由 Agent Proxy 在边界注入，结果回到公开线程并留下可追溯记录。Claude Tag 官方文档 已经把这些机制写得相当具体。

这套设计具备了组织级 Agent 运行时的雏形。它仍然留下一个比模型能力更难的问题：当一个共享 Agent 同时拥有组织记忆、主动权和工具权限时，谁来定义它该做什么、该听谁、又该在什么时候闭嘴？

先给结论：Claude Tag 真正发布了什么

Anthropic 在 2026 年 6 月 23 日推出 Claude Tag，首发于 Slack，面向 Claude Team 和 Enterprise 客户开放 beta。频道成员只要 @Claude 就能交付任务；Claude 会拆解步骤、调用已连接的工具和数据源，在完成后把产出放回线程。它也可以执行定时任务、监听频道或仓库事件，并在无人点名时主动跟进。Anthropic 的发布公告 称，内部版本已经生成产品团队 65% 的代码；这是厂商自报的使用数据，不能直接等同于外部团队可复现的效率。

发布页强调的是“Slack 里的 AI 队友”，系统设计透露出更大的野心：

1. 把 Agent 从个人软件变成团队共享资源。
2. 把聊天频道变成权限、记忆与任务的容器。
3. 给 Agent 一套独立于人的服务身份。
4. 让任务脱离一次对话，持续几个小时、几天或按事件反复运行。
5. 把执行过程、成本和责任放进组织可审计的控制面。

普通聊天机器人主要完成“输入一段话，返回一段话”。Claude Tag 接收的是一个问题或责任，例如“调查这次延迟，找到根因并开一个修复 PR”。交付物可以是消息、图表、文件、持续更新的页面或代码分支。官方的工作原理文档 明确说明，Claude Tag 与 Claude Code on the web 使用同一套托管执行引擎，产出因此能够从答案延伸到可运行的工作成果。

技术拆解：一条 Slack 线程怎样变成执行会话

Claude Tag 的架构可以拆成五层：

Slack 频道 / 线程
        │  @Claude、回复、定时任务、频道监听、仓库事件
        ▼
会话与上下文层
        │  当前线程 + 频道历史 + 工作区搜索 + 频道/工作区记忆
        ▼
线程级临时沙箱
        │  规划、读写文件、运行代码、生成文档、克隆仓库
        ▼
Agent Proxy 与权限边界
        │  域名规则 + 路径/方法限制 + 边界注入服务凭证
        ▼
企业系统
        GitHub / 数据仓库 / 监控 / 工单 / 任意 HTTP API
        │
        └──────── 结果、PR、日志、审计记录回到 Slack 线程

1. 线程是执行单元

每一条 Slack 线程都会启动一个独立沙箱。两条线程即使在同一频道，也拥有不同的运行环境。沙箱空闲后会被释放；有人继续回复时，系统重新构建沙箱，线程上下文、频道记忆以及已经推送到外部系统的成果继续存在，沙箱里尚未发布的临时文件则会消失。会话生命周期文档 把流程分成启动会话、创建沙箱、执行循环、交付结果和释放沙箱五步。

这个选择很工程化。临时计算环境降低了跨任务污染和长期驻留风险，也迫使 Agent 把重要中间成果写到可持久化的位置。代价是长任务需要主动建立检查点：分支、草稿、附件或外部状态。如果团队把“Agent 还记得”误解成“工作目录永远在”，恢复任务时就会丢掉没有落盘的中间产物。

2. 频道成了新的安全主体

频道内的 Claude 使用管理员为该频道配置的连接与服务账号。谁发起任务并不会改变工具权限；同一频道的所有成员共享同一组能力。Claude Tag 概览 甚至直接写明：能访问什么取决于你在哪个频道，而非你是谁。

这是一项大胆的产品取舍。它让团队无需逐人配置，加入频道即可协作，也把安全治理从传统的“用户—角色—资源”改写成：

成员资格 → 频道 → Access Bundle → Agent 服务身份 → 可执行动作

频道由此同时承担沟通空间、协作边界和权限角色。成员变更、公开与私有属性、继承自工作区或组织的连接，都会影响实际权限。管理员若把一个高权限 Access Bundle 挂到公开频道，任何后来加入的人都可能通过 Claude 调用这组权限。安全文档 建议把敏感凭证限制在私有频道，并检查频道从工作区和组织层继承的最终访问摘要。

3. 模型和沙箱拿不到长期凭证

Claude Tag 的外部请求都经过 Agent Proxy。凭证保存在独立的 credential store 中；请求匹配管理员规则后，Proxy 才在网络边界注入凭证。模型与沙箱看不到密钥本身。出站网络默认拒绝，只有匹配凭证规则、域名白名单或环境网络规则的请求才能通过。Agent Identity 文档 还说明，规则可以限制到主机、路径前缀和只读 HTTP 方法。

这比把一个长效 API Key 塞进 Agent 环境变量更接近企业所需的控制面：

• 密钥与推理上下文分离；
• 网络出口与权限策略绑定；
• 外部系统看到的是 Agent 自己的账号；
• 管理员可以单独撤销 Agent，而不影响某个员工；
• 日志能同时回答“谁提出任务”和“哪个 Agent 身份执行了动作”。

NIST 在 2026 年发布的软件与 AI Agent 身份和授权概念文件 也把 Agent 独立身份、最小权限和可验证授权列为需要标准化的新问题。Claude Tag 抢先把这套抽象做成了产品。

4. 记忆按“场所”积累

Claude Tag 的记忆不属于某个员工。公开频道中的有效信息会沉淀为工作区记忆，其他公开频道可以使用；私有频道可以读取工作区记忆，但新写入的内容保存在该私有频道自己的记忆库。官方记忆说明 允许频道成员查询、修正和删除记忆，管理员也能统一审查。

这让口头知识第一次有机会变成持续可用的组织上下文。周一站会提过的决定，周四另一个频道可能无需重新解释。另一面也很尖锐：访问隔离与记忆隔离并不完全相同。 某个公开频道里形成的错误结论、过时规则或带偏见的归纳，可能被别的频道复用；把凭证锁在私有频道，也不等于自动隔离 Claude 在公开空间学到的内容。

组织记忆因此不能只做向量检索。它至少需要来源、时间、适用范围、置信度、责任人、冲突关系和失效策略。否则“越用越懂公司”也可能变成“越用越坚定地重复旧误解”。

5. 主动模式把轮询变成事件驱动

Claude Tag 支持三类 routine：按时间运行、观察频道变化、响应仓库事件。它可以持续整理摘要、追踪审批、监控告警、处理积压，只有遇到需要人判断的事项才回到线程。主动任务文档 显示，routine 与人工触发的任务使用同一套频道权限和执行循环。

主动性让 Agent 从“等人提问的工具”跨到“对未完成状态负责的参与者”。我在《当 Agent 开始主动找你》 里讨论过，这类体验的关键指标会从回答质量转向打扰精度：该出现时出现，不该出现时保持安静。

能力边界：Claude Tag 擅长的并不只是写代码

Anthropic 把 Claude Tag 描述为 Claude Code 的演进，但它的产品边界已经越过工程团队。

共享问题求解

同一个频道里只有一个共享的 Claude。任何成员都能看到过程，也能在任务运行中追加信息、纠正方向或接过别人的线程。官方文档甚至强调，启动者并不拥有独占控制权，频道里的其他人可以直接 steering。多人会话说明 为此提供了一个很具体的交互：一个人发起项目状态整理，另一个人在同一线程要求补充供应商报价，Claude 会把新要求并入正在进行的任务。

共享可见性降低了重复问答，也让提示词、数据来源和修正过程成为团队资产。它同时会暴露组织现实：两位负责人若给出互相冲突的指令，Agent 无法靠更长上下文解决权责不清。

长任务与异步交付

对于复杂任务，Claude 会在原线程更新检查清单，用户可以离开 Slack 去做别的事。结果完成后再通知相关成员。执行可以跨多轮、跨几个小时或按计划持续数天，适合：

• 从故障讨论、监控数据和代码变更中定位根因；
• 将决策线程转换为文档、工单和负责人清单；
• 查询数据仓库并把结果绘制成图表；
• 追踪审批、客户跟进和未关闭事项；
• 监控告警或仓库事件，准备修复分支；
• 定期更新一份长期存在的报告或页面。

这种体验的价值来自等待与工作解耦。模型速度提高固然重要，更大的效率收益是人不必守着对话框看它逐 token 输出。

工具调用与真实交付

官方列出的连接范围包含代码库、工单、数据仓库和自定义 HTTP API。Agent 可以读数据，也可以在管理员允许的范围内写入外部系统。GitHub PR 会由 Claude GitHub App 创建，并链接回发起工作的 Slack 线程；审计页面能查看一次性任务、定时任务和通过 Agent Identity 发出的网络请求。Anthropic 帮助中心 还提供组织级与频道级用量上限，达到上限的任务会被拒绝，而非静默运行到一半。

完整闭环决定了它与“总结群聊”的差距。Agent 只有同时具备上下文、行动能力、持久成果和责任记录，才可能接走一段端到端工作。

产品角度：为什么 Slack 入口如此关键

1. 它绕开了企业 AI 的冷启动

很多企业 AI 项目的第一道障碍是“员工要去哪里用”。新门户、新账号、新提示词培训都会增加迁移成本。Claude Tag 进入 Slack 后，分发动作缩短为在已有线程里提到一位新成员。上下文也已经存在：问题描述、截图、争论、负责人和历史决定都在频道中。

Slack 提供的并非一个聊天框，而是一张现成的组织图。频道对应项目与职能，成员关系表达谁在场，线程表达具体问题，历史消息保存过程，提及和通知承担协作协议。Claude Tag 借用了整套社会结构。

2. “多人共用”改变了 Agent 的单位经济

传统 AI 助手按个人席位销售，价值由每个员工是否高频使用决定。Claude Tag 的频道任务按用量计费，管理员可以为组织和单个频道设置预算。计费文档 说明频道工作由组织承担，私聊则走个人 Claude 账号的额度。

共享 Agent 更像一项团队基础设施：少数成员发起任务，整个频道都能消费结果。厂商可以从卖“访问模型的席位”转向卖“完成组织工作的计算量”。对客户来说，成本核算也会从月活人数转向每个已解决工单、每个可用 PR、每次事故定位和每小时人工复核减少了多少。

3. 护城河会从模型转向组织上下文与授权图

模型可以替换，企业积累的连接、权限、频道指令、组织记忆、任务历史和评测标准却很难迁移。Claude Tag 越深入真实工作，越会形成一张动态的授权与知识图：

谁负责什么
谁可以批准什么
哪个频道拥有哪组工具
哪些信息可跨频道复用
哪类任务需要哪个技能
什么结果曾被接受或打回

未来企业 Agent 平台的粘性，很可能来自这张图，而非某一次 benchmark 的领先。真正的竞争对手也就不只包括模型公司，还包括 Slack、Microsoft Teams、飞书、钉钉、身份管理厂商、自动化平台和拥有业务数据的 SaaS。

4. Slack 只是第一块界面

Claude Tag 产品页已经写明 Microsoft Teams 版本正在计划中。官方产品页 把 Slack 描述为当前入口，而非最终边界。只要身份、权限、沙箱和记忆运行在独立控制面上，同一个 Agent 可以出现在群聊、工单、代码评审、CRM、邮件与会议中。

因此，Claude Tag 更像一项“可嵌入任意协作表面的 Agent 服务”。Slack 帮它解决最初的分发和共享上下文，之后的战场是所有工作事件。

用户角度：真正改变的是协作协议

对个人：从提示词作者变成任务委托人

个人需要表达目标、边界、交付物和验收条件，而不是逐步告诉模型点击哪里。优秀的委托会长成一份微型任务合同：

• 目标是什么；
• 可使用哪些信息；
• 哪些动作允许自动完成；
• 什么情况必须回来提问；
• 结果放在哪里；
• 怎样才算完成。

这种能力比“会不会写神奇提示词”更接近管理能力。用户也要学会在进度清单、外部产物和异常节点上检查，而非沉迷观察 Agent 的每一步思考。

对团队：共享过程减少信息差，也增加指令冲突

私聊 AI 的产出常常变成新的信息孤岛：一个人知道自己问过什么，其他人只看到复制过来的结论。Claude Tag 把问题、过程、工具与交付留在团队线程里，任何成员都能继续追问。

但多人 steering 会带来三个新问题：

1. 后加入的指令是否覆盖原目标？
2. 两位成员意见冲突时，谁有最终决定权？
3. Agent 需要执行高风险动作时，频道中的“任何人”都能批准吗？

聊天工具的成员权限通常只回答“能否看到和发言”，无法完整表达“能否修改目标、能否批准部署、能否改变预算”。共享 Agent 最终需要在消息之上增加任务角色：发起人、协作者、审批人、观察者和资源所有者。

对管理者：组织吞吐量上升，复核负担可能转移

Agent 能并行工作后，瓶颈可能从生产转向评审。十名员工各自发起五个任务，管理者面对的不是五十倍产出，而是五十份需要判断是否可用的结果。若没有自动评测、风险分级和异常聚合，团队会获得一支写得很快、却把所有审稿工作留给人的“虚拟队伍”。

我在《如何建立对无人值守 AI Agent 的真实信任》 里给出的护栏、回归评测和人工闸口，在共享 Agent 场景中更重要。完成数量只说明系统忙碌；人均复核分钟数、返工率、事故率和最终采用率，才能说明它是否真正释放了注意力。

五个难题决定 Claude Tag 能走多远

难题一：频道权限可能放大组织配置错误

Claude Tag 使用频道统一权限，团队协作因此非常顺滑。风险也集中在同一点：一个误加成员、过宽的工作区继承或配置错误的服务账号，会扩大所有任务的影响半径。

合理的演进方向是任务级临时授权。Agent 先拥有稳定的只读身份；需要写数据库、合并代码、发外部消息时，再根据发起人、任务、参数和有效期获取一次性能力。服务账号回答“谁在执行”，授权票据回答“这一次为什么可以执行”。

难题二：组织记忆需要可治理的真相机制

现有文档允许用户查看、纠正和删除记忆，这是良好开端。大规模部署还需要：

• 每条记忆都保留来源和时间；
• 事实、偏好、流程和推断使用不同生命周期；
• 新证据与旧结论冲突时显式呈现；
• 重大规则由指定责任人确认；
• 敏感信息有保留期和使用范围；
• 删除源消息后，衍生记忆能够同步处理。

没有这些机制，记忆越强，错误传播也越稳定。企业不会满足于“模型大概记住了”，它们需要知道系统记住了哪句话、为什么相信、谁能改。

难题三：间接提示注入进入组织内部

Claude Tag 会读取 Slack 消息、网页、仓库、工单和数据工具。攻击者不必直接对 Agent 说话；一段藏在 issue、网页、邮件或文档里的恶意指令，也可能混入上下文。OWASP 将这种模式定义为间接提示注入 ，并建议在工具执行边界单独校验动作是否偏离原始任务。

Agent Proxy 的凭证隔离和默认拒绝网络能压低影响半径，却无法证明模型没有被错误内容带偏。企业还需要数据来源分级、动作参数校验、敏感信息流规则、写操作审批和针对真实工具链的对抗评测。安全目标应当是“即使模型被骗，系统仍限制它能做什么”。

难题四：主动性会争夺人类注意力

一个主动 Agent 很有用；十个频道各有一个主动 Agent，就可能制造新的通知洪水。系统需要学习：

• 哪类事件只更新状态；
• 哪类异常进入汇总队列；
• 哪类决定必须立刻打断某个人；
• 谁是当前责任人；
• 多久没有回应才算真正停滞；
• 同一事项被多个 Agent 发现时怎样去重。

主动式产品的核心指标应该包含打扰后的有效行动比例。提醒准确率低于团队容忍度时，用户会像屏蔽普通机器人一样屏蔽 Agent。

难题五：持久记忆与严格数据策略存在结构性冲突

Claude Tag 会保留频道记忆和会话记录，因此目前不适用于启用了 Zero Data Retention 的组织。安全与数据处理文档 明确列出了这一限制。它揭示了一组难以同时最大化的目标：

持续学习  ↔  最小保留
跨频道复用  ↔  严格隔离
主动发现  ↔  最少读取
完整审计  ↔  数据删除

未来产品不会用一个总开关解决这组矛盾，而会提供不同记忆级别：仅线程、仅频道、工作区共享、结构化且经确认、带到期时间、只保存引用不保存内容。记忆将成为权限系统的一部分。

国内有没有类似形态？有，而且路线已经分化

如果判断标准只是“群里能 @ 一个 AI”，国内早已有大量机器人。若把标准提高到共享上下文、主动任务、工具执行、持续记忆、独立身份和审计治理，现有产品呈现出三条不同路线。

最接近产品形态的是 AI 小钉

钉钉在 2026 年 2 月发布 AI 小钉，称其为每个钉钉群里的“主动服务型 Agent”。成员可以在内部群中 @AI小钉 查询聊天记录、管理任务和调整群设置；它还能定时推送信息、生成群日报或周报、识别未完成事项并提醒责任人。钉钉官方介绍 显示，这些能力已经非常接近 Claude Tag 的“群内共享 + 主动跟进”体验，而且钉钉原生掌握任务、审批、组织架构和群管理，闭环可能更贴近中国企业的日常流程。

差距主要落在公开可见的技术控制面。Claude Tag 已经把凭证隔离、出站规则、频道继承、服务身份、审计记录、沙箱生命周期和记忆边界文档化。AI 小钉当前公开页面更偏功能场景。这里不能据此断言钉钉内部没有类似机制，只能说企业采购者暂时难以从公开资料评估其边界是否同样清晰。

Aily 的优势是可构建性与业务权限

飞书 Aily 允许企业创建模型推理、工作流、知识问答和混合调度四类应用。工作流可以由对话、Webhook 或定时任务触发，知识和技能也能通过 API 与飞书事件接入原有业务。Aily 能力文档 说明，它已经覆盖企业 Agent 的编排、RAG、工具调用与自动化。

在权限上，Aily 可以按终端用户角色限制技能，并对数据表设置查看、编辑、新增、删除、字段和记录级权限。角色权限文档 显示，这套授权粒度在结构化业务数据上非常细。它的产品哲学更接近“让企业搭出许多专业智能体”，Claude Tag 则先提供一个统一 Claude，再按频道装配身份、工具、记忆和指令。

DWS 代表更开放的桥接路线

钉钉在 2026 年 7 月发布 DWS（dingtalk-workspace-cli），把群聊、消息、文档、日程、表格、审批和考勤封装为命令，并允许用户把 Claude Code、Codex 等本地 Agent 映射成群机器人。DWS 官方介绍 强调无需自建服务器，几步即可在群内使用本地 AI。

这条路线很适合开发者和希望自选模型的团队：协作平台提供入口与工具协议，Agent 运行时由用户决定。它也会继承本地 Agent 的治理难题——个人电脑是否持续在线、使用谁的账号、如何统一升级、怎样隔离团队数据、谁来保留完整审计。DWS 是一座很短的桥，桥两端的运维责任仍属于企业。

国内真正的机会在哪里

中国企业协作平台拥有三个天然优势：

1. 组织与流程更集中。 通讯录、审批、考勤、任务、文档和表格往往在同一平台。
2. 群聊就是业务现场。 销售、项目、门店、供应链和客户服务大量依赖群协作。
3. 私有化与本地模型需求更强。 企业需要在公有云、专属云、本地执行器与国产模型之间选择。

国内产品很可能不会照搬 Slack + Claude 的组合。更可能出现的形态是：群 Agent 作为默认入口，Aily 或钉钉 AI 助理承担编排，DWS 一类协议连接本地执行器，平台原生身份与审批系统负责高风险授权，企业知识库提供可治理记忆。谁先把这几层合成一套易配置、可审计的系统，谁就更接近真正的组织级 Agent 平台。

未来三阶段：从 @ 一下，到组织自己运转

下面是基于当前架构的预测，不是 Anthropic 已公布的路线图。

第一阶段：常驻群 Agent 成为协作软件标配

时间尺度大约是未来 12 个月。Slack、Teams、飞书和钉钉都会把以下能力做成标准组件：

• 理解长线程与频道历史；
• 自动整理决定、负责人和未完成事项；
• 从对话创建文档、工单、日程和代码任务；
• 运行定时摘要与监听规则；
• 在群里公开进度和交付；
• 由管理员统一连接工具与控制预算。

这一阶段的竞争焦点是覆盖率和默认体验。产品要证明用户无需学习复杂配置，Agent 就能在一个低风险频道里完成第一件真工作。

第二阶段：Agent 身份进入企业 IAM

时间尺度大约是 1 到 3 年。静态服务账号会逐渐被任务级授权补充：

稳定 Agent 身份
    + 发起人身份
    + 任务目标
    + 允许动作与参数范围
    + 预算
    + 到期时间
    + 审批证据
    = 一次可验证的执行权限

企业会建立 Agent 目录：每个 Agent 有负责人、技能、成本中心、数据范围、风险级别、评测记录和撤销开关。身份团队与 AI 平台团队开始共用同一张控制面。审计日志也会从“调用了哪个 API”升级为“这个动作是否仍符合原始任务和批准范围”。

第三阶段：聊天退到异常与决策界面

更长期的形态不会要求人频繁 @Agent。事件会直接触发工作：

• 告警出现，Agent 调查并准备修复；
• 客户风险升高，Agent 汇总信号并生成行动方案；
• 需求达成共识，Agent 创建任务、更新文档并跟进依赖；
• 数据指标异常，Agent 复核口径、定位变化并通知负责人；
• 审批超时，Agent追踪阻塞点，只把真正需要判断的事项交给人。

聊天界面仍然存在，但主要承载解释、纠偏、审批与异常升级。人的每日入口会更像一个“决策队列”：

需要你批准的 3 件事
需要你判断的 2 个冲突
评测未通过的 4 个结果
预算即将超限的 1 个 Agent
其余 186 个任务已按策略完成

最终形态：组织拥有一层可编程的执行神经系统

当身份、记忆、事件与工具连接起来，Agent 不再只是一个名字。它会形成一层横跨组织的执行网络：

• 感知层读取聊天、会议、工单、指标和代码事件；
• 记忆层保存带来源、时效和权限的组织知识；
• 规划层把目标拆成任务，并选择专业 Agent；
• 执行层在隔离环境中调用工具、生成成果；
• 治理层负责授权、评测、审计、预算与人工闸口；
• 协作层把需要共识的部分交回人类。

这不会让公司“自动驾驶”。更准确的变化是，组织的默认状态从“事情等某个人想起来”变成“系统持续识别未完成状态，人处理价值最高的判断”。

企业现在应该怎样试

Claude Tag 仍处于 beta，最稳妥的做法是把试点当作组织设计实验，而非一次软件安装。

先选对频道

适合首批试点的任务具有四个特征：

• 频道成员稳定；
• 数据敏感度较低；
• 输入已经较完整；
• 结果容易客观核验。

例如内部知识整理、公开资料研究、工单分流、测试失败归类、只读数据汇总。生产发布、外部发信、财务操作、权限变更和删除数据应当留在后续阶段。

用四级自主权递进

测量“减少了多少人类工作”

建议至少记录：

• 首次可用结果的耗时；
• 任务完整完成率；
• 人工复核分钟数；
• 打回与返工比例；
• 主动提醒后的有效行动比例；
• 每个完成结果的推理和工具成本；
• 越权尝试、错误写入和回滚次数；
• 记忆被纠正、过期或删除的频率。

如果完成量增长，人工复核时间同步增长，Agent 只是把工作搬到了评审端。如果主动提醒很多，却很少促成行动，它只是在制造新的通知。如果团队无法解释某个权限从哪里继承，说明试点应先停在只读阶段。

最后的判断

Claude Tag 值得关注，不是因为 Slack 多了一个会回答问题的机器人。它把过去分散在聊天、Agent 框架、云沙箱、IAM、知识库、自动化和审计系统里的能力，压缩成了团队能直接使用的产品。

技术上，线程级沙箱、Agent Proxy、独立服务身份和按场所组织的记忆，给出了共享 Agent 的一套完整骨架。产品上，它借助频道完成分发、上下文冷启动和多人协作。用户层面，它把工作方式从“每个人私下使用 AI”推向“团队公开地委托、观察、纠正和继承 AI 的工作”。

国内已经出现接近的形态，甚至在群任务、审批、组织架构和本地执行器上拥有自己的优势。当前缺口主要是把身份、记忆、执行、主动性与审计做成一套边界清楚的默认系统。

未来最有价值的 Agent 可能没有醒目的聊天主页。它常驻在组织已经工作的地方，听得懂未完成状态，拿得到恰当权限，做完后留下证据，只在真正需要判断时把人叫回来。Claude Tag 是这条路线目前最完整的一次产品化展示，也是一次提前到来的组织实验：当 AI 真的成为共享队友，我们首先要升级的未必是模型，而是公司的授权、记忆与责任结构。

参考资料

• Anthropic：Introducing Claude Tag
• Claude Docs：Work with Claude Tag
• Claude Docs：How Claude Tag works
• Claude Docs：How agent identity works
• Claude Docs：Security and data handling
• Claude Docs：What Claude Tag remembers
• Claude Docs：Set up routines
• Claude Help Center：What is Claude Tag?
• Claude：@Claude 产品页
• NIST：New Concept Paper on Identity and Authority of Software Agents
• OWASP：LLM Prompt Injection Prevention Cheat Sheet
• 钉钉：AI 小钉进驻每一个群组
• 钉钉：DWS 将个人 AI 助手转变为团队智能机器人
• 飞书：Aily 应用场景与能力介绍
• 飞书：Aily 角色权限配置