NanoClaw 登陆 Slack：一条消息即可创建可寻址、持久化 AI 同事团队

在 Slack 中添加 AI 代理对许多企业而言颇具吸引力——但正如 VentureBeat 自身亲身体验所证实的那样，现实往往远比初看之下更为复杂且笨拙。

现在 NanoCo公司（即热门开源、面向企业、自主式 AI 代理框架 NanoClaw 的背后开发方）希望让这一过程变得与在 Slack 中输入一条消息一样简单。更进一步地说：该公司新推出的 NanoClaw Slack 集成允许人类用户仅通过一条 Slack 提示，即可启动一支由多个代理组成的完整团队，每个代理均具备专属技能、工作流，甚至自定义头像。 NanoClaw （这是 OpenClaw 的一种沙盒化程度更高、低代码版本） NanoClaw Slack 集成 让人类用户仅通过一条 Slack 提示，即可启动一支由多个代理组成的完整团队，每个代理均具备专属技能、工作流，甚至自定义头像。

NanoCo 首席执行官兼联合创始人加夫里埃尔·科恩（Gavriel Cohen）在独家接受 VentureBeat 采访时指出：“在未来 12 到 18 个月内，团队中的每个人都会成为代理的管理者。”

此外，NanoClaw 代理可在频道及共享的 Slack Canvases 中协同工作，甚至可在 Slack 之外的其他平台（如 Telegram 或 WhatsApp）上收发消息，使其人类同事能像呼叫彼此一样，在不同消息平台上直接向它们发送消息。

科恩补充道：“我认为，这是代理首次以原生方式真正落地 Slack。”他解释称：“过去，你不得不采用各种奇怪的方式，试图让多个不同代理在后台共用同一个机器人；而现在，每个代理在 Slack 中都拥有独立身份——专属头像、专属面孔、专属名称。你可以 @ 它们，它们之间也可以相互 @。”

对企业团队而言，更具实质意义的是持久性与隔离性。NanoClaw 并未将新增的工作者呈现为执行完单个任务后即消失的隐形子代理。每个代理均可被赋予独立角色、记忆上下文、指令与权限，从而构建出更接近小型数字部门的结构，而非一个仅靠冗长提示驱动的单一聊天机器人。

与今年 1 月发布的原始开源版本 NanoClaw（发布于 2026 年 1 月）一样，开发者与企业可进一步自主选择任意底层大语言模型（LLM）来驱动其 NanoClaw 代理，从而针对性能、成本或其他因素组合进行优化。

从单个 NanoClaw Slack 代理到一整支专业化团队

对于新安装，NanoClaw 当前的设置流程始于克隆项目并运行其 nanoclaw.sh 安装程序，该程序将引导用户完成依赖项配置、凭据获取、代理容器构建以及首个消息通道配对。NanoClaw 官网称，该安装程序可将用户“从一台全新机器引导至一个可收发消息的已命名代理”，Slack 是受支持的通道之一。

科恩向 VentureBeat 描述了专用于 Slack 的流程，称其相较传统 Slack 机器人构建方式实现了显著简化。他指出，此前用户需自行导航 Slack 的管理与开发者界面，创建应用、收集密钥、API 密钥与令牌，再将这些凭据手动移入机器人实际运行的位置。

借助此次新集成，NanoClaw 设置流程则提供“连接 Slack”选项。用户为代理命名、完成身份验证、选择 NanoClaw 的“添加至 Slack”选项，并经历 Slack 的安装与授权流程。一旦获得授权，首个代理即可出现在 Slack 中，并开始与用户通信。

关键区别在于，此次初始授权本质上是一次性的团队空间连接。Slack 应用市场列表显示，用户“仅需连接一次团队空间”，此后 NanoClaw 即可为每个新增代理单独配置 Slack 机器人，包括专属名称、自动生成的头像与身份。

这些代理持续运行于客户自有基础设施之上，并通过 Socket Mode 连接 Slack。NanoCo 表示，其自身不存储代理的 Slack 令牌；根据应用市场列表，这些令牌保留在用户本地设备上。

Slack 的标准管理控制措施仍围绕该系统部署。组织可对其 NanoClaw 集成应用常规的应用审批策略；而 NanoClaw 的应用市场列表则指出，该应用的主页标签页会显示团队空间内已配置的所有代理，并允许用户撤销单个代理或完全断开团队空间连接。

其结果并非 NanoClaw 底层基础设施的一键式替代方案，而是在该基础设施与 Slack 之间建立的一次性桥梁：用户依然拥有并运营代理运行时环境，但一旦该桥梁获得授权，代理本身即可自主创建并协调更多原生 Slack 同事，无需每次均返回手动应用配置流程。

科恩表示，在后台，主代理配备了一种模型上下文协议（MCP）工具，可用于创建新代理并定义其指令、人格、技能与工具；另一工具则可将其置入共享房间。这些代理已预装适配 Slack Canvas 的能力，并可与 Slack 频道内的每位人类用户及彼此通信。

交互本身刻意设计得极为简洁。科恩表示，用户无需每次需要新角色时都打开独立的代理构建器，而是可直接告知已有代理自己所需同事或团队的具体类型。

“你在 Slack 中的代理可以这样回应：‘为我创建另一个处理代码审查的代理；再创建另一个审阅贡献者文章的代理；再组建一支从不同视角审阅贡献者文章的代理团队。’随后你的代理便会创建新代理，它们会直接弹出在侧边栏并向你发送消息。”

这意味着开发者可请求一名产品经理、一名架构师、一名实施代理、一名代码审查代理及一名测试代理，然后为各代理分配不同工具集，并令它们彼此交接工作。科恩举例称，例如测试代理可访问测试环境，而审查代理则具备专用于代码审查的技能，产品代理则负责监控用户反馈。

科恩认为，这种劳动分工远不止于表面化的角色扮演。“为不同任务分别赋予特定技能、指令与工具，具有切实优势，”他指出，“我可以拥有一个代码审查代理、一个代码测试代理、一个代码编写代理，并让它们形成闭环协作。”他补充道，若实施代理遇到模糊之处，它可直接 @ 产品代理或架构代理寻求澄清，而非强迫一个通用型模型在同一上下文中承担全部职责与工具。

代理与人类共同在共享的 Slack Canvas 上协作

一张提供的演示截图展示了该模式在营销领域的应用：一名名为 Nano 的主代理创建了 Atlas（负责战略）、Sage（负责内容）、Echo（负责社交）、Scout（负责外联）及 Compass（负责 SEO 与数据分析）。这些代理在同一条 Slack 对话中自我介绍并开始协调工作，其中 Atlas 特别注明已将一项任务添加至 Canvas，以防该任务被遗漏。

用户无需在一开始就指定每个细节。科恩表示，有人可以向主代理（lead agent）提供精确的审核流程、优先事项和所需工具，也可以根据该代理现有的上下文和记忆，将更多配置工作交由代理自行完成。

该设计还试图避免一种常见的多代理失效模式：机器人 endlessly 相互触发。NanoCo 表示，各代理仅在被明确标记（tagged）时才作出回应；而用户在 Canvas 中针对某项工作所留下的评论，则可被路由回负责该项工作的代理。

该模型还可扩展至超越单人创建的任务专用机器人团队。科恩描述了一种工作场所场景：每位员工各自拥有持久化代理（persistent agents），这些代理可在人类定义的策略下彼此通信。

他说：“每个人拥有自己的代理意味着，我可以在 Slack 中拥有我的代理，而你拥有你的代理；你的代理可以向我的代理提问。也许我当天不在办公室，你的代理可以 ping 我的代理，询问我的可用性；我则可以设定一些策略，规定我的代理是否能直接回答，还是必须由我本人批准。”

这使该概念更趋近于组织级委托（organizational delegation）：部分代理按职能专业化，而另一些代理则实质上代表个体员工及其所积累的上下文。科恩表示，这些代理可配备浏览器与互联网访问权限、记忆能力、编码能力及其他工具；新创建的代理则自带对 Canvas 工作、代理间通信以及生成更多代理的内置支持。

Slack 正为更多第三方代理敞开大门。

底层的 Slack 变革范围比 NanoClaw 更广。

今年4月， 作为 Salesforce 旗下产品，Slack 宣布可在消息平台中直接添加外部 AI 代理， 最初点名提及 Vercel 和 Lovable，并称这些集成将于五月底上线。

Slack 表示，其部署机制可自动完成 OAuth 授权、清单（manifest）配置及环境搭建，从而使外部构建的代理无需专为 Slack 重建即可接入工作区。

Salesforce 最近发布的 Slack Code 页面 目前已将 NanoClaw 与 Lovable、Hyperagent、Superhuman、n8n、Vercel、ChatGPT、LangChain、Runlayer 和 Skydive 并列，并指出“添加到 Slack”（Add to Slack）功能可通过几次点击，将来自这些平台的代理以其自身身份引入 Slack。

Slack 已充斥着各类 AI 助理。例如，OpenAI 允许将 ChatGPT 工作区代理部署至 Slack 频道，使其能够回答问题、通过已连接系统执行任务并输出文件。Slack 同样支持 Claude 和自定义 Agentforce 代理。因此，NanoClaw 的差异化之处并非简单地实现“Slack 中的 AI”，而是让一个已在运行的代理能够在对话内部即时创建额外的、可独立寻址的协作代理。NanoCo 将此称为 Slack 首创；这一特定市场首发主张属于该公司。

Slack 产品管理总监乔什·米拉斯（Josh Milas）在随附公告中表示：“‘添加到 Slack’意味着一条消息即可启动一支完整的 NanoClaw 代理团队，与 Slack 中的人员并肩协作。”

NanoClaw 与 Slack 中的 Claude Tag、ChatGPT 代理及 Agentforce 的区别何在

NanoClaw 并非唯一试图将 AI 从侧边栏聊天机器人转变为类似持久化 Slack 同事的公司。

Anthropic 公司的 Claude Tag或为最接近的概念对照——该功能自六月起开始向 Claude Team 和 Enterprise 客户以测试版形式推出。

管理员可授予 @Claude 对选定频道、工具、数据源及代码库的访问权限；频道内所有人均可通过标记（tagging）方式向其委派任务。Claude 能记住其所处频道中的相关信息，可异步工作数小时乃至数天；当管理员启用其“环境感知”（ambient）行为后，它还能主动标记信息或重启未解决的工作，而无需等待新的提示。

Anthropic 表示，不同 Claude 身份亦可限定于不同用例，例如销售用途的 Claude 不会与其工程用途的 Claude 共享记忆或工具。

差异在于 这些数字同事的配置与组织方式。Claude Tag 的文档化工作流由管理员主导：管理员将 Claude 与 Slack 配对，决定每个 Claude 身份可访问的频道、工具及信息，设定支出限额，再将这些身份开放给员工使用。

在特定频道内，Anthropic 描述的是“一个与所有人互动的 Claude”。其公开文档并未描述终端用户要求该 Claude 按需即时创建多个具有独立命名的 Slack 机器人的场景。NanoClaw 的模型几乎与此相反。

NanoClaw 表示，在组织首次将其 NanoClaw 安装接入 Slack 后，现有代理本身即可通过对话式请求来配置额外代理，每个新工作人员均获得其 专属 Slack 机器人身份、名称、生成头像及令牌 ，并在客户自有基础设施上运行。

OpenAI 的 ChatGPT 工作区代理（ChatGPT Workspace Agents） 则占据该光谱上的另一端点。

商业版、教育版及企业版客户可在 ChatGPT 中构建可复用的代理，为其设定指令、模型、文件、应用、自定义 MCP 连接及排程，随后将这些代理附加至 Slack 频道。

构建者需为每个代理分配唯一的 Slack 句柄（handle），并可配置其仅在被提及（@mention）时响应，或自动响应频道中相关消息。

但构建过程仍主要通过 ChatGPT 的代理构建器（agent builder）完成：OpenAI 的设置文档指示用户先创建代理，再将 Slack 添加为频道。在底层，Slack 句柄依赖于 ChatGPT Agents 应用所管理的 Slack 用户组，而非 NanoClaw 模型中每个已配置代理本身即为一个独立 Slack 机器人的做法。

Salesforce 的 Agentforce 同样允许组织创建多个专业化代理，员工可在 Slack 中通过私信（DM）或 @提及方式调用它们；该方案 arguably 提供了本组中最常规的企业级管理模式。

企业可在 Agentforce Builder 中构建代理，通常从面向 Slack 的特定模板入手（如客户洞察、员工帮助或入职培训等岗位），并可添加子代理（subagents）及操作（actions），使其具备信息检索、创建 Canvas 或执行其他工作的能力。

一旦在 Salesforce 中完成配置并激活，管理员即可将这些代理引入 Slack 供员工使用。这对已将身份、数据及工作流集中于 Salesforce 的组织而言极具威力，但再次将 代理创建置于部署之前 ，而非将创建行为本身设为现有 Slack 代理可在对话过程中执行的操作。

这一区别有助于厘清NanoClaw在日益拥挤的市场中实际新增的价值。Slack自身现已为开发者提供Agent Kit，并为基于外部平台构建的代理（agents）制定部署标准，自动化处理OAuth、清单（manifests）和环境配置等环节。Claude Tag、ChatGPT Workspace Agents与Agentforce均表明：在Slack内部部署持久化、专业化的AI同事，本身已不再具有新颖性。

NanoClaw更具非常规性的押注在于递归式供应（recursive provisioning）：Slack不再仅是员工调用代理的场所，更成为现有代理可自主组装额外命名代理、为其分配角色，并将它们聚合至某一频道以组成工作团队的场所。

不同路径各有利弊。Claude Tag附带Anthropic托管的模型及集中式管理控制功能，包括频道级权限、审计日志与令牌消耗限额；同时提供主动式“环境感知”（ambient）行为——而NanoClaw提供的资料并未以同等方式宣称具备该能力。

ChatGPT Workspace Agents提供托管式代理构建器、定时任务、应用连接，以及组织层级的发布与访问控制。Agentforce则将代理紧密绑定于Salesforce权限、企业数据及预定义业务操作。

NanoClaw则强调 自托管、开源可修改性及独立的代理身份，从而将更多控制权——以及更多运维责任——转移至运行该系统的组织。

其结果并非对上述系统构成直接替代，而是针对同一新兴问题给出的不同解答：企业究竟希望采用少量经中央配置的AI助手，还是构建一种环境，使员工及现有代理能随新工作任务不断涌现而持续创建专业化数字同事？

NanoClaw的发展历程

NanoClaw起步之处远非企业协作市场。创始人科恩（Cohen）曾任职于Wix，于2026年1月31日以MIT许可证发布NanoClaw，初衷是打造一款刻意精简、专注安全的OpenClaw替代方案。

项目最初的定位是：一个可访问消息、文件与工具的个人代理，应运行于操作系统隔离的容器内，而非直接运行于宿主机；且编排层须足够精简，以便开发者或安全团队充分理解——初始核心代码约500行TypeScript，设计重心在于容器隔离与极简单进程架构。

此后，该项目稳步转向企业基础设施领域。今年3月， NanoClaw与Docker达成合作 ，在Docker沙箱内运行代理，并为可能安装软件包、修改文件及启动进程的工作负载启用更强的MicroVM支持型隔离机制。

4月，NanoClaw 2.0版本集成Vercel的Chat SDK与OneCLI的凭证网关，使组织能够围绕敏感操作制定策略，并在向受保护请求注入凭证前强制要求人工审批。

至5月，科恩与其兄弟拉泽·科恩（Lazer Cohen） 围绕该项目成立NanoCo公司，并完成1200万美元种子轮融资 ，由Valley Capital Partners领投，Docker、Vercel、monday.com等机构参与。其商业化策略是在保持NanoClaw开源的同时，向企业提供托管式、全组织范围部署服务及“专业助理”基础设施。该公司目前称NanoClaw下载量已逾25万次，GitHub星标数突破3万。

随着NanoClaw进一步深入职场基础设施领域，这一开源架构仍为核心卖点。

科恩表示：“你现在真正能够将一个完全可控的开源代理集成至Slack。你可以更改所有这些配置。此外，你还能fork NanoClaw并彻底重写或修改其行为——例如构建自己的记忆系统、自己的编码框架、代理框架。无论你想做什么，皆可实现。绝对自由。”

代理具备持久性，但基础设施始终由用户掌控

科恩表示，NanoClaw保持自托管模式：组织可在本地机器或自有云虚拟机上运行该系统，代理数据亦存储于该处。

同一代理亦可同时出现在Slack、WhatsApp或Telegram中，且保留相同记忆、工作区与工具，尽管每个消息界面使用独立会话。

NanoClaw可跨这些会话提取近期上下文，使代理得以维持连续性，而无需将全部聊天历史合并为单一数据流。NanoClaw文档同样描述了一种多通道架构：同一代理可维持统一工作区与记忆，同时为各通道维护独立会话。

科恩表示：“这一切均为自托管。你将在自己的计算机或云中虚拟机上运行此系统，相关数据亦存储于你的计算机或[虚拟机]VM上。这可以是运行于Mac Mini上的开源模型，你的数据除流向Mac Mini及Slack外，不会去往任何其他地方。”

跨通道连续性亦旨在使代理更少呈现为Slack专属机器人，而更像一位可通过Slack联络的持久化同事。

科恩表示，同一代理可在Telegram、WhatsApp与Slack中存在，并共享相同的记忆、文件与工具。各对话保持为独立会话，但共享同一工作区与持久化上下文，从而使代理能在不同界面间传递知识。

当组织开始创建大量代理时，该架构的重要性便凸显出来。科恩表示，一个代理默认可查看自身在各通道的会话，但无法查看其他代理的私有会话。NanoClaw当前文档同样描述了代理在各自沙箱中运行、模型提供商可配置的架构，默认采用Claude Code，另可选Codex、OpenCode及本地Ollama模型。

新Slack流程存在一项云依赖。科恩表示，NanoCo运营一项小型服务，负责处理Slack供应请求与头像生成。他强调，该服务不接收用户消息或代理记忆。

持续坚持开源

据科恩称，NanoCo不对该社区版Slack功能收费，并自行承担供应服务与头像生成成本。用户仍需自行承担模型推理与托管费用，因此实际部署的代理团队并非零成本。

NanoCo表示，该集成通过Slack Marketplace提供，须遵守常规工作区应用审批与治理流程。Slack方面指出，工作区所有者与管理员可要求应用在安装前必须获得批准。

科恩将该决策描述为NanoCo更广泛的开源战略的一部分，而非一项独立的变现举措。他说：“我们不会从这一项目中赚取任何收入。这纯粹是为社区服务的。”“我们知道，从长远来看，这将使NanoCo公司整体受益。随着NanoCo的发展及其能力的拓展，这些能力将回馈至开源社区。我认为这就是开源的新模式——我们并不试图将我们为社区带来的每一项价值都进行变现。”

企业能否如此迅速地抵达这一阶段，将更多取决于IT团队能否以同等速度管控智能体的权限、记忆、支出及故障模式，而非取决于智能体创建的难易程度。NanoClaw押注，下一个关键问题在于：当上述障碍被消除后，如何管理随之涌现的数字同事。