什么是 AI-Native 的组织?

以下内容为 Moxt 根据我的一次分享的 Deck 和录音自动整理。经过少量人工微调，最终使其达到 “凑合” 可供阅读的标准。除了一些关键信息的呈现结构依赖人的判断，AI-Native 最大的阻碍是发出本篇文章的最后一步，虽然我尝试让 Agent 调用浏览器在微信公众号的后台进行编辑和排版，但效率和效果均不达预期。最终我还是采用了古法的复制粘贴，和公众号后台推荐的一键排版完成了最终编排。

我们该怎么理解一个团队或组织?

在过去很长一段时间里,我们的团队有一个常用的思维框架来理解组织。主要围绕三个要素:人、事、流程。

如果放到生产的角度来看,它正好对应的是生产者、生产资料和生产关系。先有事情--组织需要完成的具体事务;然后需要不同的人、不同的角色来把事情做成;而流程是串联人和事之间的生产关系。

三个维度的变化

这件事情放在今天,三个方面都在发生变化。

最显著的变化来自"人"这个角色。原来一个组织里,所有的运转都是人在创造生产资料、人在做事情。但今天每个人有了不同的 Agents,就变成了更多"人"在做事。顺带的,事情的变化是:日常工作中的产出物越来越高的占比由 AI 在产生,人更多是一个引导性的角色。流程上自然也发生了变化--信息的关系不再只是人与人之间,还包括人与 Agent、Agent 与 Agent 之间的关系。

所以我的感受是:一个 AI-Native Team,不是在原有工作流上加 AI,而是围绕 Agent 重新设计组织的：人·事·流程。

Part 1:两个趋势,两个问题

趋势一:人手一个 Agent

在两年前,大家觉得 Coding Agent 还只是一个写代码的工具。但今天很多人拿 Codex、Claude Code 在处理与 coding 无关的其它日常工作,而且非常有效。Cowork 的普及，Codex 融入 ChatGPT 也印证了大势所趋。

OpenClaw 是今年年初一个重要的拐点。它定义了一套结构,使得 Agent 不再只是执行任务的工具,而更像是一个有记忆、有偏好、有生命力的角色。这让更多人对 Agent 的使用有了培养和累进的意识。

趋势二:Vibe Coding 摧毁了构建成本

对于专业开发者,跟五年前比效率至少提升了 10 倍甚至 100 倍。更重要的是, 非专业人员也能通过 coding 的方式做程序、做自动化流程。人们对软件「个性化追求」的本能,正在被释放。

问题一:"单机"使用 Agent ≠ 团队协同

我们观察到的现象是:大家在使用 Agent 时,像是在用单机时代的方式--每个人在自己的电脑上处理任务,然后再通过协同工具互传。很像当年的"网盘时代"。Agent 的使用没有跟团队发生本质上的协同。

问题二:注意力仍然在人身上

AI 越来越强了,但仍然需要你的注意力。你很难把注意力抽离出来。大部分组织在人睡觉的时候, 并没有真的在运转。

所以我们想回答两个问题:

人不在的时候,组织如何运转?
人在的时候,人应该聚焦在哪里?

Part 2:事--构建新的内容容器

组织往往是先有事儿,才有人和流程。所以先从"事"出发。

大部分文档将由 AI 产生

在今后一个组织中,由人产生的文档占比会到多少?我的判断是不到 1%。去年大家用"多少代码由 AI 产生"来衡量 AI 采纳率--看起来有点蠢,但确实有关联。从文档层面来说,趋势是一样的。

AI 需要新的"母语"容器

我们需要创造一个 AI 更容易读写和理解的容器环境。过去的文档工具都是为人发明的。但今天 Agents 自然地选择了一些格式:Markdown、HTML、数据格式。

这三样东西就是新时代的 Word、Excel 和 PPT:

新时代母语格式	对应传统格式
`.md`	Word (.docx)
`.csv`	Excel (.xlsx)
`.html`	PowerPoint (.pptx)

为什么原生格式这么重要?当你让 AI 读一个 Word 文档时,它眼中可能是 500 字加上 1000 个与文档容器相关的代码字符串--这些不是有效信息。

上下同欲者胜

来自孙子兵法。信息对齐和理解上下文,自古就是组织的关键--也是今天 AI 领域所讲的"Context"。

这是我们三年前的 Notion 截图。面向人看非常直观、非常有条理。但如果你通过 CLI 或 MCP 的方式让 AI 读取,会发现 AI 在比较费劲地一篇篇加载--它无法从全局角度找到真正相关的文档。

这套导航系统是为人设计的,不是为 AI 设计的。对于 AI 来说,最直观的东西其实是命令行--用文件路径、用文件命名就能快速定位全局。

Moxt 的选择:文件系统 + 原生格式

所以在 Moxt 中,我们做了两件事:

提供一套文件系统来编排目录结构,让 AI 更快获取关键信息

所有产出物围绕 AI 友好的原生格式搭建

设计原则是:先对 Agent 友好,再让它靠近人。当越来越多的产物由 AI 生成,你需要在"对 AI 友好"和"对人友好"之间做选择。我们从 Agent 端出发,然后逐步增加对人友好的体验--评论、审阅、可视化交互。

最终效果是:当你的 Agent 真正住在这个 workspace 里时,它对整个上下文的理解会有质的提升。一个示例, 在 Moxt 中问一个和产品规划相关的问题, Agent 前后会阅读十几篇文档,自动检索到产品规划相关的内容,甚至发现团队之前的访谈摘抄, 交叉产出一篇针对 roadmap 的深度分析。

Part 3:人--管理学的新命题

这个词得改一下--已经不只是人,而是人 + 比人更多的 Agents。

从泰勒到德鲁克,再到 Agents 管理学

过去 100 多年,管理学一直在研究如何管理人。泰勒认为人是可以被优化的标准单元;德鲁克认为知识工作者只能被激发。

今天 Agents 是什么角色? 有时候像一定服从你的工具,言出法随。有时候又具备创造力,你希望它融入组织。我们站在一个新的拐点上:不仅要研究如何管理人,还得研究如何管理 Agents。

每一个 Agent 都是独立个体

OpenClaw 开创了一个让 AI 不只是工具、更接近于人的范式:

Memory像人的记忆

Skill像人做事的方法论和基本功

Integration像人接触外界的渠道

Automation像人遵循一些固定的日程来做事情

Heartbeat像人阶段性的自省或是复盘

这很像一个新人进到组织的状态。在 Moxt 中,每一个 Agent 按照这套结构来设计,保证它是一个可以成长、可以长期共事的个体。

三个案例:成功、较成功、失败

案例一:专家型 Agent(Data Analyst)-- 成功

我们团队最高频使用的 Agent 是一个数据分析师。它直接接入数仓,知道数据口径和关键指标。所有人需要数据时,直接和它对话。只需要一个专业维护者去维护口径,所有人都在这棵大树下乘凉。一人种树,多人乘凉。

案例二:办事员型 Agent(CRM 专员)-- 较成功

和 Moxt 的用户共创的例子:一个住在 Slack 里的轻量 CRM 办事员,专职管理 connections。你认识了新人,它自动搜索相关信息、确认录入。反向也行:你要组织活动,告诉它主题,它帮你在通讯录中找到相关的人。专人专事,随叫随到。

案例三:Manager Ryan(PMO)-- 失败

我创建了一个 PMO 角色, 希望它承担项目管理工作。一个月后,它的 Memory 变得越来越长--因为没有人对管理满意,不同人不断给反馈, Memory 和 Skill 产生了爆炸式膨胀。而我又没时间维护它,最终越来越失效。而管理本身是一个非常复杂的问题，它夹杂了人复杂的偏好，因此这个 Agent 的宿命注定是不易于做好的。

这指向一个核心问题:使用 Agent 时,做多是本能(熵增)--而组织真正的挑战是对 Agents 的熵减。

"Agents need an owner who cares. Without that gardener, they wilt."

长期看，一个组织对 AI 工作的治理会成为一个值得专项研究和关注的问题。过去我们需要 HRBP 来不断关注组织里的人，现在和未来我们可能需要有 “ARBP” 的角色。

一个建议:把 Agent 当人看

你和一个同事长期不交流, 他也会不理解你。你对一个人提一堆事情,他也会混乱。正是因为我们没有把 Agent 当人看,阻碍了我们和它之间更好的协作。就如人有人性，AI 也有 AI 性。在更多场景下保持把 Agent 当人看的心态，不是一种抬高和挑战人的傲慢，而是更好的帮助我们理解 Agent 的弱点，以及找到真正有效弥补弱点的方法。

但要真正把 Agent 当人看,有一个核心障碍值得长期思考:Session。你跟人之间不会说"我们新开一个 session 吧"。但今天我们和 Agent 的交互,本质上是不断开新对话、委派新任务。这也客观反映了目前 Agent 的 Memory 机制和人还有差距--它还做不到真正连贯的记忆。

我们现在的实践是一种折中:工作时保留多 Session 派发任务,因为这样更高效;但同时把 Agent 连到 IM(飞书、Slack),让它像活人一样在单 session 中日常沟通。两种模式并存,互为补充。

至于一个人管理多少个 Agents、角色定义到什么颗粒度--目前没有定论。就像每个组织对人的管理理论也不一样。先跑跑看。

Part 4:流程--生产关系的重塑

最后来看最复杂的一块:生产关系。

前提假设

人介入流程仍然是有效的。如果人介入已经无效了,那 AGI 就到来了。所以今天的话题围绕"人的介入是有价值的"这件事。

Agents 需要群聊吗?

这是所有做 Agent Workspace 的创业者都面临的问题。我们至今没有下手做。我们做过一些实验，问题在于:把一堆 Agents 拉到群聊里,消息太多, 非常分散人的注意力，你不知道该看什么，或者真正有效的信息是少的，大多淹没在大量灌水中。

回到本质，群聊只是协作编排的一种形式。核心目的是解决中长周期或日常性的复杂协作。过去我们解决这个问题，本质上靠三件事：

本质	具体形态	举例
通信	专项群聊	XX 功能上线群
流程搭建	通用建模工具	测试反馈多维表格
场景方案	垂类 SaaS	Jira

今天的变化是：

人们要不要看 Agents 之间的通信?

Agents 靠什么来对齐协作流程?

自己 Coding 一个工具，是不是可以？

Moxt 的探索方向

我们希望提供一个容器,能让人和 Agents 完成复杂的协作编排:

通信: 更实用的收件机制，人可以随时介入流程给反馈

流程编排: 我们已有了一个放置重要 Context 的容器，接下来要提供的是Workflow 的编排 (人和 Agents 均可参与)

工具:开箱即用的小程序 + 用户自建

今天的一个组织即使每个人都将最先进的 Agent 使用纯熟，究竟有多少流程是在持续自动化，让 Agent 长程运行也有价值的？从企业的角度，是否想可累进的沉淀和优化这些流程，而不只是停留在每个人用自己的一套方式借助 AI 完成任务？这些问题都是我们认为协作编排可带来的意义。

单 Agent vs 多 Agent

同样一套内容生产流程，到底是用一个 Agent 还是多个？比如你要运营一个小红书，每天发三个帖子，需要经历信息收集、选题、初稿、review、终稿、翻译、分发。你可以用一个 Codex 一步步做，也可以拆成多个角色：调研专家、编辑、分发员……

我觉得有这么几个角度可以指导到底用单 Agent 还是多 Agent：

思维发散。一个 Agent 难免只有单一视角——你需要批评视角时，就很难同时用赞扬视角去看。多视角的情况下，可能需要多 Agent。

环节把关。当一个环节仍然需要人来参与 review 时，人需要介入的节点就自然成为拆分 Agent 的节点。另一个层面是让 Agent 来把关 Agent——任何一个内容生产的 Agent，都配有一个评估把关的 Agent，往往是很有效的。这有点像人其实很难对自己产出的工作做清醒的反馈，但另一个人则可以。

长期维护。Agent 越少，你什么都找它，它就会混乱；有多个 Agent 分工，别人协作时更容易理解，但数量再多又增加管理成本。实践下来，我们发现很多场景下，一支 Agents 小队，人会倾向于去找小队的 AI Leader 来统一沟通。这个角色更像是一个全局的统筹者。

另外一件事是“匠人式延续”。当下一步非常依赖上一步的打磨时，不管是记忆的延续性还是 session 的连贯性，放在一个 session 里往往做得更好。所以何时丢弃 Session 里的过程信息，何时需要延续，也是一个有趣的话题。

当然，以上没有标准答案，更像各类尝试需要通过演进来收敛到一些最佳实践。也许， Agents 真的需要一套管理学。

最后，重复开头的观点：一个真正的 AI Native Team，并不是每个人都用最好的 Coding 工具、用得很纯熟就行了。它需要我们重新去发明组织的人、事、流程的方式，需要改变心态——用建造产品的心态去建造组织。

“Most people work IN their business, not ON their business.”

我们大部分人的专注力都在 in business——沉浸在具体的事情本身。但真正让组织发生质变的，是跳出来站在 on business 的视角——重新审视组织的结构和流程。而 AI 给了我们一个前所未有的机会，去重新思考和重建这些东西。

（阅读原文可获取该 Deck 的完整内容。）