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

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

在产品上线半年后，Moxt 的联合创始人明喆进行了一次复盘，梳理了他们把 Agent 真正放进团队日常工作后，对「人和 Agent 怎么协作」这件事的理解是怎么一步步变清楚的。这其中的不少认知，可能早已是共识，但真正落地的时候，手感还是很不一样的。也正因此，这个第一手的实践，很值得一看。

文章来自 Moxt 团队投稿，Founder Park 进行了部分内容编辑。⬆️关注 Founder Park，最及时最干货的创业分享 我们将通过「AI 产品市集」、内容报道、社群分发等方式，帮你触达早期用户、获得真实反馈，以及建立关键连接。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 不是设计出来的，是在真实工作里一层层改出来的。

每一层认知都是上一层的解法不够用之后，被迫看到的下一个问题。内容中包含的图片若涉及版权问题，请及时与我们联系删除