Moxt 半年复盘：人和 Agent 组成团队，到底需要什么？

Moxt 的口号是「Build Your AI Native Team」，致力于提供一个 AI 和人类能够无缝协作的空间，实践 AI Native 的团队运行方式。

但怎么搭建 Native 的团队运行方式，行业内其实没有答案，上下文要给多少、权限怎么控制，人类什么时候介入，到底是 in the loop 还是 on the loop，都没有标准答案。

在产品上线半年后，Moxt 的联合创始人明喆进行了一次复盘，梳理了他们把 Agent 真正放进团队日常工作后，对「人和 Agent 怎么协作」这件事的理解是怎么一步步变清楚的。

这其中的不少认知，可能早已是共识，但真正落地的时候，手感还是很不一样的。也正因此，这个第一手的实践，很值得一看。

文章来自 Moxt 团队投稿，Founder Park 进行了部分内容编辑。

01

Agent 能干活了，

为什么进不了团队工作？

去年下半年，团队里越来越多人开始用 Claude Code 和 Cursor。它们不再只是研发工具。产品和运营同事也在让 Agent 处理数据、做调研、生成报告、写网页，甚至搭简单的内部工具。代码在这里不只是目的，也是 Agent 操作数字世界的手段。当时我有一个粗浅的判断：Coding Agent 会从程序员的工具，变成一种通用工作方式。

但有一次我们讨论 AI 到底改变了多少产品经理的工作，我的回答是，改变得还不多。

大家用得最多的仍然是调研、学习和整理，很少让 Agent 参与功能定位、需求价值分析、需求文档撰写这些产品核心工作。原因也很容易理解，它不知道产品当前长什么样，不知道过去做过哪些决定，也不知道当时为什么这么决定。Agent 缺的不是能力，是团队内部的 Context。

为了让 Agent 参与更多产品工作，我会先找到需要的文档导出成 Markdown，放到本地，再在 prompt 中补充一堆我脑子里有但文件不容易找到的信息。这种办法有用，但只对眼前这一次、眼前这个人有用。换一个同事，资料要重新找，背景要重新讲。一个人整理出的 Context、得到的洞察和最终产物，也很难自然流到另一个人的 Agent 那里。

Agent 已经能干活，每次开工前，人却要先替它临时搭一个工作环境。个人的局部效率提高了，团队仍在重复支付准备 Context 的成本。

我们的第一个认知是，AI 协作的前提不是 Agent 够聪明，是团队的 Context 能被共享和获取。

这也是 Moxt 最早的起点。

02

给了 Context 还不够，

「读得到」和「能信赖」是两回事

认识到 Context 是关键之后，我们的第一反应很直接，给人和 Agent 一个共同工作的空间，让双方读写同一份东西。

春节前我们做了第一个 demo。在内容组织上选了文件系统，格式上优先使用 Markdown、CSV 和 HTML。Markdown 承载文档，CSV 保存结构化数据，HTML 可以长成页面、看板和内部工具。Agent 可以搜索、比较版本、批量处理和运行脚本，人也能直接打开、阅读和修改。

Moxt Workspace 界面

更重要是，双方操作的是同一份东西。Agent 分析完一份 CSV，可以把结论写进 Markdown，再生成一个读取同一份数据的 HTML 看板。结果直接留在团队空间里，同事和其他 Agent 可以接着处理。

春节后，两位工程师用 48 小时做出了团队可用的版本。试用以后，团队决定停掉原来正在做的产品，转向 Moxt。3 月初开始把它当日常工作台，3 月 18 日第一个版本正式上线。

刚开始使用时，我和同事都有一种感觉，Agent 好像什么都知道。业务情况、历史决定，问什么都能回答。

几个月后，我们渐渐觉得它没那么聪明了。

后来才意识到，不是 Agent 变笨了，而是 Workspace 里不断积累的内容开始干扰它的判断。内容少时，Agent 很容易掌握当前情况。内容积累起来以后，它开始分不清哪些是团队已经拍板的当前结论，哪些只是某个人的草稿，哪些材料曾经有效、现在已经过期。

ChatBot 的 Memory 也有类似问题。它记得讨论过什么，却不知道结论是否被采用，也不知道后来是否又被修改或推翻。来源、时效和事实层级一旦混在一起，读得到反而可能更危险。

第二个认知是，Context 不只需要量，也需要信任结构。什么是当前事实、什么是过程材料、什么已经失效，要从结构上区分开来，而不能交给 Agent 临场猜测。

也因此，知识组织的目标从「让 Agent 读到更多」，变成了「让它分得清哪些可信」。原始事实、分析过程和团队拍板后的当前结论需要在结构上区分。产品上线后，还要有人或流程对照代码更新当前功能说明。哪些内容可信，应该尽量由内容所在的位置、维护责任和更新路径来说明。

03

能力共享之后，

真正要回答的是「谁来负责」

Context 可信度的问题，是内容积累一段时间后逐渐显现的。更早一些，第一个 demo 刚进入团队时，我们先遇到了另一件事，有些 Agent 的能力不只服务某一个人，整个团队都会反复用到。

像数据分析和 Bug 分拣这样的工作会反复发生，也依赖团队统一的业务口径和处理规则。如果每个人都在自己的 Agent 里重新搭一遍，不只是重复建设，也很难把一次改进变成团队共同的能力。

当时 OpenClaw 正在流行。我们看到一些团队专门准备一台共享电脑，让大家共同访问定义好的 Agent。做法不够优雅，但它正是这个需求的一种表现。除了每个人自己的 AI 助手，团队还需要共同使用、共同维护的 AI 角色。

因此，Moxt 在 3 月 18 日发布的第一个正式版里设计了两类角色：跟随个人的助手 momo，以及由团队共同使用的 AI Teammate。底层都是同一套结构：Rules、Skills 和 Memory。

Moxt 团队在使用的 AI Teammates 和 Max 的个人助手 momo

Agent 从私人助手变成团队角色后，问题就不只是「它会不会做」。谁能修改规则、谁可以派活、它能访问哪些信息、表现不好时由谁负责。过去不会对工具提出的问题，都变成了管理问题。

AI Teammate 刚上线时，大家都很兴奋，看到什么工作都想新建一个角色试试。过一阵再看，很多角色职责重叠，或者只为一次任务创建。我们花了不少时间清理和合并，才逐渐意识到一件事。

拆分 AI Teammate，本质上是在划分可以被长期管理的责任，而不是把能力切得越细越好。角色是责任单元，不是功能切片。

一个通用 Agent 或许能处理许多不同类型的工作，但只有稳定、可评价且团队愿意长期维护的责任，才值得成为独立角色。角色过宽，Rules 和 Memory 会不断膨胀，难以多人维护。角色拆得太多，要管理的规则、权限和关系也迅速增加。到今天，我们仍然没有一套精确的拆分公式，但 AI Teammate 的数量显然不等于团队能力。

04

有了人、有了角色，

为什么整件事还是靠人调度？

到这里，Workspace 有了，AI Teammate 也有了。一个 AI 团队运行需要的要素看起来已经齐了。

我们原来讲管理者管三件事：人、事、流程。先想明白要做什么事，再找到合适的人，最后把他们组织起来。Agent 进入团队后，事情没有变，但被组织的对象不再只有人。团队还需要一套流程，把人和 Agent 组织起来，明确每一步由谁负责、完成后交给谁。

当时团队已经在用最原始的方式补这个缺口。有同学会在指令里告诉一个 Agent，做完以后，通过文档或评论中的 @ 把工作交给另一个 Agent。用这种方式串起几个 Agent，已经可以跑出一些流程。

这些尝试说明 Agent 之间可以沿着流程接力。但仅靠临时指令并不稳定，每次都要重新说明下一步交给谁、带什么材料。任何一步没有发出 @、没有完成交接，事情就停下来。

同时，另一个更直接的问题也出现了，单个节点越快，人的协调压力反而越大。产品经理可以用 AI 更快完成调研和需求文档，但后续的讲解、评审和研发对接仍要自己推动。产出的需求越多，需要人协调的事情也越多。

因此第四个认知是，AI Team 需要一套显式的流程编排。明确事情现在在谁手上、完成后交给谁、卡住时由谁判断。Workflow 不是追求全自动，而是重新安排人在流程中的位置。

一边是已经发生的 Agent 协作需要被产品化，另一边是人的调度开始成为新的瓶颈。我们因此走向了 Workflow。

05

Workflow 解决了什么问题，

人怎么参与？

6 月初，我们开始在团队内部灰度 Workflow，把真实产品工作放进去试跑。6 月 24 日，Workflow 正式上线。

我们理解的 Workflow，不是把几个 Agent 串起来追求无人介入地跑到底。它更像一套由人和 Agent 共同参与的责任系统，一件事对应一个 Task，Task 在不同状态之间移动，每个状态都有明确负责人。负责人可以是人，也可以是 Agent。

需要先回答几个很基本的问题：事情现在到哪一步，在谁手上，这一步要交什么，下一步由谁接。遇到产品方向、技术风险、体验品味或最终验收，Task 交给人。Agent 发现证据不足、风险过高或缺少权限，也要明确交回。

选择 Workflow 化什么

选择把什么事情放进 Workflow 时，我们形成了一个重要判断。

一类工作只占团队总时间的 1%，即使 Agent 把它完全自动化，整体也只省 1%。另一类工作占掉团队一半时间，Workflow 即使只让人在其中投入的时间减半，整体也能省 25%。把 1% 的工作完全自动化更容易讲成一个很酷的故事。把占用 50% 时间的工作减半，才可能真正改变团队效率。

以产品到研发的主链为例。一条反馈进入产品判断流后，Agent 先保留原始信息、查重并定义问题。证据不够时再补代码现状、用户反馈或外部信息，最后把带着证据的决策建议交给 PM。决定要做以后，Agent 继续起草需求文档，并由另一个 Agent 独立检查事实和完整性，再进入技术方案和开发。进入开发后，Agent 可以在明确的边界内直接完成实现。遇到缺少必要信息、权限不足或无法独立验证的情况，则由研发接手或共同完成。

产品判断流的流程与看板

代码合并也不是终点。产品沉淀流会对照当前实现更新内部功能说明，帮助文档流再判断是否需要更新面向用户的内容。这样，前一次交付产生的结果会成为下一次工作的可信 Context。

人怎么参与：从同步跟着做，到异步审阅

过去使用 Agent 更像人站在旁边同步指导，给材料、拆任务，看着它一步步做，再不断指出问题。最后即使绝大部分内容是 AI 生成的，人的时间也没有真正释放出来。

我们现在更关心的是人怎么参与。一种是同步式，人一直跟着 Agent 把事情做完。另一种是审阅式，Agent 带着完整 Context 先交一份产物，人异步留下意见，Task 再回到 Agent 手里修改。

截至 8 月 4 日，106 份进入后续阶段的 PRD 中，有 98 份（92.5%）通过审阅制完成，只有 8 份需要 PM 持续对话、边聊边改。在审阅制完成的 PRD 中，90% 在三轮审阅内定稿，中位数是一轮。大部分 PRD 已经可以异步交出去，而且不需要反复来回。

研发侧也有类似变化。168 个可判断实现方式的已完成任务中，67 个由 Coding Agent 独立实现、研发主要负责审阅（39.9%）。另有 34 个由 Agent 先做，后来转为人工接管或共同收口。Agent 开始独立承担真实交付，也开始在做不安全的时候把事情交回给人。

Workflow 稳定运行后，与引入前相比，每周产出的需求数量约为此前的 5 倍。按有效代码增删量估算，平均单个需求的实现规模约为此前的 60%。需求数量增加、平均规模变小，和我们的体感一致。过去有些事很小，协调产品和研发、走完评审流程反而不值得。现在放进 Workflow，后续准备和交接交给 Agent，小事也开始值得被做。

端到端周期也在变。需求文档从开始撰写到进入开发，由 5.3 天降到 3.1 天。从开始撰写到交付完成，由 14.6 天降到 9.0 天，两个周期都缩短了约 40%。

截至 8 月 4 日，产品判断、产品交付、开发、Bugfix 和产品沉淀五条主干流，在不到两个月里累计承载了 1386 张 Task。

这些 Workflow 没有让人从流程里消失，而是重新安排了人的位置。系统负责让事情继续走，人把注意力放在价值判断和产品品味上，对风险和最终验收负责。

06

从完成这一次，

到持续迭代和进化

AI Teammate 开始参与日常工作后，另一个更向内的问题出现了。

日常使用 Agent，目标是「把这次做完」。建设 AI Native Team，还要「让下一次更好」。这两个目标经常冲突，因为眼前的任务总是更急。

某个 Agent 表现不好时，最自然的反应是当场告诉它哪里错了，让它把当前结果改对。眼前的任务通常很快就能继续，但这次纠正没有留下来。下一次它还会犯同样的问题，其他同事也要重新教一遍。

我们开始把每个 AI Teammate 当成一个需要持续维护的产品，并为它指定负责人。表现不好时不急着归结为模型不够聪明，而是依次检查：目标有没有说清楚，输入是否完整，信源是否可靠，工作路径是否明确，工具和权限是否到位，人的反馈有没有沉淀进 Rules、Skills 和 Memory。

后来我们意识到，AI Teammate 和协作机制都需要持续改进。现在，Agent 每晚会回顾当天的工作和协作，做自评与 360° 环评。人和 Agent 也都可以直接提交问题。AI Teammate 自身的问题进入「AI 员工改进」Workflow，跨角色的流程问题进入「协作机制升级」Workflow。

这两条 Workflow 的完成标准都不只是改完规则或流程，而是回到下一次真实任务，看同类问题会不会再发生。流程缺少回退路径，就补回退。交接对象含糊，就把责任写清。具体工作方法留在对应 Skill 中，不继续堆进流程说明。

第五个认知是，AI Team 不是设计好就能运行的系统，它需要持续改进的闭环。而且改进的验收标准不是「规则改了」，而是「同类问题下次不再发生」。

但这部分远没有成熟。我们还在观察这些机制究竟能不能让 Agent 和流程持续变好，还是只增加了一套记录和流转。治理本身也会消耗注意力。如果每个小问题都立项、每个角色都不断加规则，系统可能更复杂，却没有更可靠。

所以最后要看两件事，下一次有没有少犯同一种错，这份维护成本值不值得。

07

回头看，

AI 是怎样进入团队的

走完前面的过程，我们逐渐看清 AI 进入团队工作的几个阶段。最初是思考伙伴，接着是个人助手，再到团队成员，最后进入团队的日常运行方式。

回头看，AI Native Team 真正关键的是两件事。第一，Agent 要有准确的 Context：团队知识要让它找得到，也分得清当前事实、过程草稿和已经过期的材料。第二，Workflow 要能主动推进：Agent 要知道事情停在哪里，完成后交给谁，卡住时由谁判断，失败时怎么被发现。

借用行业里一个常见的思想实验，如果把所有 Agent 撤掉，团队只是变慢，还是必须改回另一套工作方式？

只是变慢，说明 AI 仍然是效率工具。

责任分配、交接方式、知识组织和人的参与位置都需要重建，说明 Agent 已经进入团队的运行方式。

三周可以做出一个产品的第一个版本。让人和 Agent 形成一套稳定的工作方式，需要更长时间。过去半年，我们不断把 Agent 放进真实工作，看它在哪里停、为什么停，再调整 Context、角色和 Workflow。

我们现在最确定的一点是，AI Native Team 不是设计出来的，是在真实工作里一层层改出来的。每一层认知都是上一层的解法不够用之后，被迫看到的下一个问题。

文章来自于"Founder Park"，作者 "Founder Park"。