谁是真正 AI 原生的团队协作空间？

文 丨 阑夕

过去一个月里，飞书开源了 lark-cli，11 个业务域、200 多条命令行指令，全部拆给 AI Agent调用。很快，钉钉跟进，发布了自己的 CLI 工具 dws。

两个中国最大的办公平台，在同一周做了同一件事：把自己的全部能力拆成命令行，交给Agent去操作。

这个动作的含义比它表面看起来要大。它意味着飞书和钉钉都承认了一个前提——Agent 不应该通过人类的界面来工作，它需要自己的操作通道。

但开放接口只是第一步。真正的问题在更底下。

AI 产品在过去三年经历了三次身份切换。

两年前 AI 还是聊天机器人，你问它答，聊完即走，什么都不留下。Copilot 算一个进步，AI 嵌进了现有工具里帮你写草稿、做总结，但主语始终是你。

变化是最近一年的事。Claude Code 让用户坐在终端前面看 Agent 干活，它接管整个代码仓库，自己读代码、自己跑测试、自己提交修改，人只管审批。OpenClaw 把 Agent 能调用的工具从几种变成几百种，一个开放的插件生态，接进去就能用。Hermes Agent 再往前一步，还能自主进化。

主语变了。人不再是那个主要操作者，一切都是 vibe coding、vide design、vide marketing。

这就逼出了一个问题：Agent 在哪里工作？

现在的情况是，Agent被塞进了为人类设计的工具里。它通过Slack、企微发消息，在Notion里编辑文档，在飞书里拉数据。各家也在补救，开CLI，Notion 上了 Custom Agents，都想让 Agent 绕过人的界面直接干活。

调用的问题确实缓解了，但还是很难解决根本问题。一个 Agent 处理完一份客户记录，另一个 Agent 不会知道这件事发生了。它们之间没有信息通道。要串起来，得靠人写自动化脚本，或者干脆靠人转达。CLI 给了 Agent 一双手，但没给它们一间共用的办公室。

还有一层更基础的问题：格式。传统工具默认人是操作者，文件格式是 .docx 和 .xlsx，适合人阅读和修改。但它们本质上是压缩包，里面是一堆 XML 文件。要读取内容，Agent 得先解压，再解析复杂的 XML 结构，才能提取内容。Markdown、CSV、HTML 不一样，打开就是文本，Agent 直接读写。LLM 本身就是吃这些纯文本格式训练出来的，对 Agent 来说这才是母语。

在一栋为人盖的楼里给 Agent 腾房间，能凑合住。现有软件的所有预设都建立在人类是操作者这个假设上。但Agent原生的软件假设Agent是操作者，人类是监督者。

这是地基的问题。

今年初有人总结了一条判断标准：「用户在 UI 上能做到的任何事，Agent 都应该能通过工具做到。」把这句话当尺子量一遍现有协作工具，很少有及格的。

Agent Native 需要的是，文件格式从 .docx 换成 Markdown、CSV、HTML 这些 Agent 直接读写的纯文本，Agent 之间有共享的上下文而不是各自锁在对话窗口里，新能力写一段 prompt 就上线。

Moxt 是我目前见过的，少有的认真按这套假设来设计的协作产品。

我大概试了试，确实有些不同的体验。先给AI投喂了十几篇自己的文章，想看看所谓的Skill蒸馏是什么效果。结果收到一份几千字的解构报告，从选题偏好到句式习惯逐帧分析，结尾还附了一份复刻指南。

把人变成Skill，本质上是把经验的上下文做标准化封装。这件事不新鲜，企业知识库多年前就在做。区别是Moxt把这个封装放进了一个Agent能直接调用的环境里，而不是放进一个人类需要手动检索的文档库。

但让我真正意外的不是Skill。

我在Moxt里搭了四个AI Teammates——销售助理、数据分析师、内容策划、售后客服——让它们在同一个团队空间里工作。

这些都不算稀奇。有意思的是下完任务之后发生的事。

销售助理消化完客户的会议记录并生成摘要后，数据分析师基于这份更新，自动在系统里补全了客户画像。期间我没@任何人，没发消息，没开会，两个AI Teammate自己串起来了一条信息链。

往下推，客户画像更新后同步至售后，完整链路分析出客户痛点，成为内容策划的新素材。我看到的结果是，察觉到客户的不满后，内容策划已经在筹划针对性的传播选题了。

还有一个细节。我对售后客服下达了一个关于客户称呼的纠错，没给任何额外指令，它把这个修正同步给了所有AI Teammates。一次提醒，全员纠正。

这些事情分开看，每一件都不复杂。但加在一起，你看到的是一个Agent团队在协作。信息在Agent之间自动流动，上下文在团队层面共享，没有人在中间当传话筒。

这就是Agent Native架构长出来的东西。没人专门设计了一个「自动同步」功能。当底层假设变成「Agent是工位上的主角」，这些能力自己就冒出来了。飞书做不到，根子在架构：它假设Agent是辅助角色，信息流动的起点和终点都是人。

当然不是没有问题。单轮对话200K的上下文容量对重度用户来说不太够用，叠加上Skills的装载，上下文空间被进一步压缩，我不得不开新对话处理后续任务。这个限制不算致命，但体感上是个实在的卡点。

在做客十字路口那期播客里，Moxt联合创始人昊然说试用了两周产品后，感到「头皮发麻」。

除了产品身上久违的新意之外，起码目前而言，AI带来的创业潮还没有呈现出后移动互联网时期「如果大厂也做，你怎么办」的绝望处境，更何况办公协作领域本就存在海量的长尾需求，不太能出现赢家通吃的局面。

创业者和年轻人的兴奋是可以理解的。至少，他的判断里有一个前提确实有可能成立：Agent时代的协作工具，很难在现有工具上加AI长出来。它需要从头盖。

这个判断放在一年前可能显得冒进。但看看过去六个月，整个行业都在往同一个方向跑：面向 Agent 生态开发，而不是面向人做工具。

当Agent 能力越来越强，它需要自己的工作空间和协作方式。这是架构代际的切换。

Moxt 最初的灵感，起源于团队内部不想再来回互传Markdown文件了。每一个技术周期里总有这样的公司，起点小到像随兴而起，走着走着就认真了。