动态图解：用 Manus 重建 Manus

Manus 联合创始人、首席产品官张涛发布了一篇长文：《用 Manus 重建 Manus：什么变了，什么出了问题，以及我们现在如何工作》。讲的不是某个新功能，而是一家做 Agent 的公司，自己默认跟 Agent 一起干活以后，工程、产品、市场三个团队各变成了什么样，又有哪些地方没跑通。

故事从九月下旬开始。那是 Manus 2.0 的最后冲刺，张涛在 Slack 上给一位工程师发了几条功能需求和缺陷报告。后来他去看进展：工程师屏幕上开着一排 Agent 会话，有的在 Manus 里，有的在 Codex 里。他点开其中一个。

提示词就是他发的那条 Slack 消息：

需求原样进了 Agent。

一年前，工程师会先读消息、弄懂意思，再动手写代码。现在是 Agent 读请求、找到相关代码、提出修改方案。工程师做三件事：指挥任务、检查结果、对最终产物负责。

大多数时候，请求在跑，不在等他。在 Manus，一名工程师同时推进 10 到 20 个请求已是常态。

同一个人，一年前和现在手上的活：

请求在跑，不在等人。

张涛说他为团队适应得这么快感到自豪，也感到不安：这个节奏对吗？还有什么没注意到？

Manus 给自己定了两条规矩：用自己的产品干真实的活；一直去找 AI 失灵的地方。这篇长文就是按这两条写的，覆盖工程、产品、市场三个团队，也写了行不通的地方。张涛自己的定位是：一份还在进行中的实验报告，不是在给「AI 原生组织」下定义。

先看结论

文章开头先摆了六条目前学到的东西：

• 没有折中之道：把 AI 加到旧的工作方式上，有时只会多出噪音。闭环真正形成，事情才会变。
• Agent 需要全局视野：更好的上下文，比更好的提示词收益更大。
• 信任来自测试和上下文，不只来自模型质量。
• 自主性需要终点线：成功可被验证，Agent 才能独立跑；其他地方，人来定。
• 瓶颈会转移：工程变快以后，决定做什么成了约束。
• 人的角色没被削弱，而是更聚焦在高影响力的事情上。

六条放在一起，大概是这样一条线：

六条，都还在实验里。

后面每一节，基本对应其中一条。

没有折中

2026 年之前，Manus 和大多数公司做的事一样：把 AI 加到已有的工作方式上。客服用 AI 摘要标记问题，工程师用编程助手，机器人在频道里发分析。

每一块单看都有用，但块和块之间没连起来。

在闭环形成之前，他们只是在用老办法干活，只不过多了很多 AI 在互相说话：

没接成环，只是多了 AI 在互相说话。

团队常回到一句话：软件工程是随时间累积的编程。写代码容易衡量；让一个复杂产品健康地跑上好几年，不容易衡量。AI 写的代码占比高，可能是真进展，也可能是在堆以后要有人清理的垃圾。

所以他们在意的考验更难：Manus 是一款上线超过一年的复杂产品，换了工作方式以后，它能不能持续改进而不崩，同时每个人都做得更多？

张涛给的答案是：到目前为止，能。

把全局交给 Agent

和大多数科技公司一样，Manus 时间丢得最多的地方是交接。前端和后端工程师各自解读一个需求，就接口达成一致，再花好几天修不匹配的地方。两个人很少会以同样的方式理解同一个需求。

如果 AI 能跨技术栈写代码，能不能让一个人端到端负责一个需求？障碍是上下文：代码散在不同仓库里，没有哪个 Agent 能一次看到整个系统。

回答始于一次内部实验——想看看在尽量少的人工输入、几乎不手写代码的情况下，AI 能把一个产品做到什么程度。实验里形成的方法，后来长成了内部工具 Manus-mono，简称 Mono。

Mono 不合并代码仓库。它是一个统一入口，加一份写给 Agent 的手册：每个仓库做什么、怎么协作、团队怎么干活。Agent 按需去拉。另外还维护一个架构决策记录库，每个 Agent 会话一开始拿到的就不只是代码，还有过往决策背后的理由。

不管谁在跟 Agent 协作，这个 Agent 都带着之前所有人的上下文：

不合并仓库，给 Agent 一张全图。

Mono 是一步步长出来的，每一步都在解决上一步暴露出的瓶颈：

1. 看清整个系统：补上任何单个仓库都装不下的业务上下文，用 Git worktrees 并行干活。
2. 本地验证：以前推到测试环境要 5 到 10 分钟；现在整个 Manus 技术栈能在一台笔记本上跑，检查只要几秒。
3. 调试生产环境问题：在受限权限下，Mono 能读诊断生产 bug 需要的日志、配置和错误报告。
4. 端到端执行发布：以前容易卡住的发布环节交给 Mono，审批仍由人来做。
5. 端到端测试：验证成了瓶颈以后，Mono 开始用测试账户，在浏览器和移动端模拟器里跑真实用户流程。

五级台阶，一级一级往上：

每一步，补上一步露出的短板。

（原文这里配了一段介绍 Mono 如何运作、如何演进的视频，由一位同事用 Manus 制作。）

常有人问 Mono 是不是代码 wiki。文档只是一部分；其余是代码周围的一切：怎么测、怎么发、决定了什么、为什么这样定，还有 Agent 能碰什么、不能碰什么。

Mono 也成了一个大家一起往里加东西、越用越好的共享知识库。有个例子：运维工程师烦透了总被叫去帮忙发布，就把发布流程写进了 Mono。现在任何人都能执行发布，Agent 也能，但审批仍归有发布权限的人。

一个人解决了自己的烦恼，整个公司快了一点：

人人能发布，审批仍归有权限的人。

团队现在默认一个人就能在每个平台上交付一个需求。移动端团队一直是 七个人，在两个产品之间维护 四款应用，还跟网页端保持同步节奏。

Mono 在公司里扩散，没有自上而下的强推。张涛觉得这更多是文化：探索 AI 的边界本来就是他们存在的理由之一，组织又是扁平的。工具能走多远，取决于组织允许它走多远。

闭环：从 bug 报告到验证过的修复

Mono 让任何人都能碰产品的任何部分，这是一半。另一半，是让 Agent 自己发现问题。

在大多数互联网公司，用户的 bug 报告要先过客服、产品、分流，才到得了能修它的工程师手上。

在 Manus，现在是一个内部 Agent 先调查报告，把问题追溯到引起它的那次改动，然后在 Slack 发帖，@ 负责这次改动的工程师。工程师判断是不是自己该修的，再交给自己的 Agent。另一个独立的 Agent 跑相关测试和流程，检查修复。

三个 Agent，三种角色：分流、执行、验证。中间的人做判断。

一条 bug 报告走完的路：

三个 Agent，中间是人。

越来越多的工程工作现在是这样开头的：Agent 把问题交到人手上。

这个闭环有明确的边界。读用户报告的 Agent 不能改代码，只能调查、反馈。改动来自工程师自己的 Agent，而且要工程师先拍板。任何东西在拥有发布权限的人审批之前，都不会上线。

怎么信 Agent 写的代码

很长一段时间里，合进主分支的每一次改动，都要两位高级工程师之一签字。团队对 AI 的信任还不够跳过这一步。Agent 写的代码越来越多，这个审查环节成了瓶颈。

单论写代码，模型已经相当强。他们发现差距落在两点：

第一，人知道怎么测自己的活。第二，人参与了上下游的讨论，知道对业务来说什么才叫「对」。

正确的代码，不等于正确的产品：

正确的代码 ≠ 正确的产品。

于是从两头补：

• 让 Agent 加入讨论：每位工程师的 Agent 都驻在它被拉进去的 Slack 讨论串里，跟着上下文走。等有人最后说一句「开工」，Agent 已经知道团队定了什么、为什么。
• 让 Agent 做端到端测试：和后端团队一起，让 Agent 每次改动后都能在 Manus 里跑真实流程和回归测试。测试覆盖率涨，信任跟着涨。

现在每一次改动都要过这道验证，再过一个跑着当前最强模型的代码审查机器人；支付这类敏感区域还有额外规则。

机器人替掉的是排队，不是人的决定：

机器人替掉排队，不替决定。

Agent 可以提 pull request，但没有人的明确批准，合不进主分支。做什么、谁能发布，仍由人定。

自主要有终点线

信任是有边界的。这一点，他们是吃了亏才明白的。

曾经有段时间，大家都对完全自主的 Agent 循环很兴奋，于是试了一次：一个 Agent 从内部反馈渠道收集反馈，每条反馈都启动一个项目。一位同事让它跑了一整个周末。

看一看：

周一早上，200 多个项目等他拍板。

为什么不让 Agent 把这些决定也做了？因为自主循环只有在系统能检查目标是否达成时才有效。测试过或不过；页面能加载或不能。大多数现实工作没有这种检查，要靠人判断：做完没有，值不值得做。

那个周末留下两条教训。第一，人做决定的速度，跟不上一个不受约束的循环产生决定的速度。第二，没人决定某件事该不该做，就没人为结果负责。

能不能放手，看有没有终点线：

能验证的放手，不能验证的人来定。

前面那个 bug 修复闭环之所以能跑，是因为测试定义了成功。产品决策没有测试可依，所以 Manus 的每一次产品变更，仍然从一个人决定「值不值得做」开始。

瓶颈挪到了产品

传统产品流程交接多，每交接一次，优先级就偏一点。编码 Agent 让工程师变快以后，冒出一个新问题：没有足够的产品经理来写好需求。

工程第一次不再是瓶颈。

Manus 先试了两条路。一是请几位工程师当「建造者」（builder），从探索到发布全权负责一个问题，但同时有技术判断和产品判断的人寥寥无几。二是让 PM 改代码，也停住了：交接还在，没有工程师的直觉，PM 能改文案和交互，改不了底层逻辑。

瓶颈怎么一路挪过去：

工程一快，卡点挪到「做什么」。

Mono 把这两个问题都解了，因为它自带规则：

• 任何涉及模型调用或成本的改动，写代码之前要先拿到负责人签字。
• 每一次改动都过和工程师改动一样的审查与测试。
• Mono 能用测试账户走完注册和支付流程，并把每一步记下来，PM 就能准确指出出问题的那一刻。

实际是什么样？一位负责语音转文字的 PM，让 Manus 对 10 多个模型做了基准测试，然后选定一个。她通过 Mono 拉下前端代码，在设计系统里做了 demo，让 Manus 把每个用户场景渲染成图片给她审。她把 demo 转成视频。方案清楚到她自己就把功能做了出来，包括 Web 和桌面端界面。

过程里有三个决定是人做的：她选了模型；产品和设计团队审了演示；一位有发布权限的工程师审了代码。

一位 PM 从选模型到上线：

一年前，这一切不可能。

他们把这种转变叫作从「人在环中」（human in the loop）到「人在环上」（human on the loop）。以前 AI 完成任务的 70–80%，人补剩下的；现在人定规则，监督多个 Agent，在关键节点检查方法和结果，必要时介入，并对结果负责。

两种站位的差别：

从补尾巴，到定规则、看节点。

有些 PM 现在交的不是书面规格或原型图，而是一段短视频。几分钟里讲清使用场景、每个界面、每次点击做什么、边缘情况怎么处理、底层怎么转。设计、工程和 QA 更快对「完成」的定义达成一致，PM 只用讲一次。（原文这里附了一段语音输入功能的产品需求视频。）

如今约 一半 的 PM 独立上线功能，每位 PM 都提交过代码。设计师也开始动手了。一位 PM 写了 Manus 2.0 里 Manus Studio 界面的大部分代码，另一位写了视频编辑器。背后是有人花了好几个月，突破自己原来的岗位边界。张涛说这是最让他自豪的地方。

但这不等于每个人都得变成开发者。公司里谁都能构建产品，就可能有人上线本不该存在的东西。产品团队常问一句：「如果这件事只花一秒钟、零成本，你会上线吗？」有时答案是不会。

所以仍然需要模块负责人，决定做什么、不做什么、用户最终看到什么；也需要有人维护 Mono 这样的基础设施。构建变容易了，决定构建什么就更重要。

市场部的 AI 队友

一次营销合作，要走脚本审查、定价、合同、审批、付款、上线、效果复盘。这些步骤散在邮件、合同工具、审批系统、电子表格和广告平台里。以前很大一部分时间花在这些系统之间搬信息，留给需要判断力的创意工作的时间很少。

他们从一个小问题下手：合作方内容或广告上线了，团队往往很晚才知道。于是让 AI 写了个脚本，检测内容什么时候发布。接着想要效果数据。然后是过往合作的复盘。再然后，整条内部工作流打通了：合同一签、审批一过，Agent 就更新状态，通知负责下一步的人。

从一个脚本，长成一整条线：

从一个小问题长出来。

Manus 把这一切做成了一个内部站点。对人来说，它是仪表板和日历；对 Agent 来说，它是一组工具。在这条工作流里用这些工具干活的 Agent，就是他们说的 AI 队友。它只在团队给它接的渠道和系统里工作，权限只限这条工作流。

它管自己的队列。很多人同时给它发消息，它就在一个「前台」会话里跟所有人沟通，把任务分派到并行会话里。它先判断一条消息跟自己有没有关系，再决定是打断手上的活还是等一等。这些规则是它在开发过程中自己提出来的，团队审过以后留下了。

一个前台，背后几条并行的活：

前台接话，后台并行。

它从转发的上下文里学。以前策略一调整，就要开会、写书面简报；现在营销负责人把讨论转给它，说一句「学习一下」。

它盯着长期目标。有一次，它也在的一个 Slack 线程里，队友们记不清某个项目进展到哪了。没人 @ 它，它回了一句：

看一看：

没人 @，它记得 A 和 B。

它还会找别的团队核实事实。3D 模型绑定上线以后，它去问产品团队支持哪些内容，得知绑定覆盖 七个类别，包括鱼类、蛇类和四足动物，市场的描述因此保持准确。

现在队友们会拉它参与脚本和定价审查，因为它读过过往的合作记录。最终决定仍由人做。

这个内部站点还能从使用者身上改进，包括 Agent 自己。Agent 遇到阻碍，就通过反馈接口提一个请求；请求经 Manus 2.0 的自动化（Automations）在 Manus 里建成一项开发任务；工程师审过改动再发布。

站点被它的用户一点点修：

用的人来修，但才跑了一周。

这个机制才运行了 大约一周。张涛说得很直接：还要攒更多案例，才能真正依赖它。

那团队里的人做什么？三件事仍归他们：做出并承担每一个重要决定；处理 Agent 没见过的情况，并教它怎么做、该找谁；当它的分析指向新角度时，给它调方向。

少打扰

在这几个团队里，很多问题不再需要去打扰某个人。文章给了三种做法。

先问 Agent。 一位同事在 Mono 上搭了个 Slack 机器人，跑在云端电脑上，在话题串里回复。用得最多的是非工程师：这个功能怎么工作的？这个字符串在哪？这个发了没有？不用先去找负责人。

打开会话，而不是问进度。 工程师的进展以前存在他们自己的 AI 聊天里，人一下线就看不到。于是团队做了一个内部功能，项目成员能看到彼此的会话并申请加入。工程师可能用 Agent 做完一个功能的大部分，PM 再进同一个会话调间距、样式和文案。在别人的会话里发帖要对方批准，权限机制还在完善。

只决定需要决定的事。 公司里用 AI 最多的人留着一个主会话，只干一件事：列出要他决定的事项，每项附一条建议。Slack 一忙起来，他不进去，只问：「我现在需要决定什么？」

三种少打扰的办法：

不是少交流，是少打扰。

重点不是让大家彼此交流更少，而是彼此打扰更少。（原文配了一张工程师、PM 和设计师在同一会话里协作的示意图，并注明那不是真实的价格调整。）

张涛自己也这么干。他每天有 20 多个待办，而且——他也对外讲过——他有 ADHD。对他来说最难的是开始。

现在每个待办都进一个专属的 Manus Project，它把每一项变成单独的任务，能启动的就启动；拿不准的，回头问他背景，以及该归哪位 PM。然后它用他授权的 Slack、Gmail 和 Notion 访问权限收集上下文，交给 PM 一个完整的请求，而不是一句话。

一条待办，变成一份完整的请求：

难的是开始，它先替他起步。

他说这种变化不只是效率：每天为「从哪下手」焦虑的时间少多了，这在个人层面意义很大。

这笔钱值不值

Manus 在 AI 上花得很多，也盯得很紧。花销数据不拿来评判任何人的表现，只拿来评判这笔钱本身：它现在有没有回报，或者是不是在为以后打基础。

他们的账是这么算的：

• 换来时间和注意力。 团队变大，协作会吃掉每个人的注意力。AI 护住了每个人的注意力，让人更完整地掌控自己的工作。而他们还在招人。
• 用最好的模型，是摸清 AI 边界的办法。 前面那套验证和代码审查，跑在能拿到的最强模型上。负责开发者生产力的同事说，这是最有性价比的一笔支出。
• 成本应该通过产品降下来。 越来越多开发工作发生在自家产品 Manus Studio 里，使用数据能告诉他们 tokens 浪费在哪；修复进到产品里，也该让 Manus 对用户更省。他们预期随着模型变便宜、浪费被消掉，今天的成本会大幅下降。

三笔账，一条一条摆出来：

钱换注意力，成本靠产品往下压。

最后那条，张涛特意加了一句：这是一个信念，不是承诺。

还没做好的

打扰少了，注意力更碎了。 以前一天处理四五件事的人，现在可能同时推 20 或 30 件。每切一次，就要重新加载一次上下文。AI 扩大了人能做的事，也推着人做得更多。一位 PM 说，只要有一个任务在跑，她就忍不住再开一个 Agent。

做更多事不是目标。他们把这当成一个要解决的问题，而不是值得庆祝的节奏。

同一个人，从四五件到二三十件：

做得更多，不是目标。

信息更分散了。 产品负责人以前知道每一项改动和背后的原因。现在他有时会截一张图去问 Mono：「这是谁改的？」听着好笑，问题是真的：人人都被赋权改产品的时候，谁对整体负责？

共享权限要重新设计。 工作能被分享、交接，Agent 又出现在越来越多的对话里，就得决定什么开放、什么要审批。

现在的解法还很初级：一个 Agent 监督其他 Agent，只汇报哪些卡住了、哪些需要人来决定。他们知道这还能做得更好。

谁改的、谁能看、谁来盯：

人人能改，谁管整体？

接下来做什么

这些问题指向的产品工作，别的团队大概也会需要。这些功能不是提前规划的，是从他们自己反复撞上的问题里来的：

• 把会话变成共享工作区：一个人提出问题，设计师给方案，工程师构建，PM 让它跑起来，全在同一个地方。
• 跨设备、跨人员流转的工作：本地机器和云端机器保持连接，人暂时走开，活还能接着跑。
• 能发现人没想到的方案的 Agent：在公司系统里、带着合适权限运行的 Agent，应该能提出解法，而不只是执行指令。

三个方向：

先在自己身上试，再带给用户。

人现在做什么

回到开头那位开着一排 Agent 会话的工程师。张涛说，那不只是一个关于效率的故事，而是组织运作方式变了。

过去公司靠角色和层级传递信息，一个人能做什么，取决于他能调动多少人、多少资源。现在是花一点时间给 AI 上下文和工具，花更多时间做判断和决策。越来越多的时候，是 Agent 把问题带到人面前；决定怎么应对，仍然是人的事。

他们开过玩笑：Manus 能干这么多，还来办公室干嘛？让 Agent 自己搞定好了。但真正重要的问题，仍然要人来提出、争论、拍板。比如，什么才算好产品？或者稍微夸张一点：是做一个有真实收入、一直推着 AI 边界走的伟大产品，还是去追利润率？

AI 不知道他们想要哪个。他们知道。

文化和信任，来自日复一日、在关键时刻一起把事情想清楚。那是每个会话里所有工作的地基。

所以，就目前而言，他们的答案是：人的角色没有被削弱，而是更集中到能产生最大影响的地方：

四件事，还在人手里。

这也是 Manus 还在招人的原因：人的技能和判断力在这种工作方式的中心，短期内不会变。

张涛写到最后，说他很好奇一年后这篇文章会是什么样。每家公司的目标、结构和文化不同，可能没有标准答案，也没有最终形态。但对一家做 Agent 的公司来说，弄清楚人和 AI 怎么协作不是可选项，它就是工作的一部分。

原文最后有一条关于数据的说明：文中的数字来自内部记录，团队规模和 PM 交付数据截至 10 月下旬；部分内容是估算或个人经验，不是严格的度量。