用 Manus 重建 Manus：什么变了，什么出了问题，以及我们现在如何工作
作者：张涛，Manus 联合创始人兼首席产品官
九月下旬，在 Manus 2.0 的最后冲刺阶段，我在 Slack 上给一位工程师发了几条功能需求和缺陷报告。后来我去看他进展如何。他的屏幕上开着一排 agent 会话，有的在 Manus 里，有的在 Codex 里。我点进其中一个。提示词就是我在 Slack 上发的消息，一字不差地粘贴进去。
一年前，他会读我的消息，理解我的意思，然后开始写代码。而现在，agent 读取请求，找到相关代码，并提出修改方案。工程师的工作是指挥任务、检查结果并对最终产物负责。大多数时候请求都在运行中，并不需要他等待。如今在我们这里，一名工程师同时推进 10 到 20 个请求已是常态。
我为团队的快速适应感到自豪。但我也感到不安。这个节奏对吗？还有什么是我们没注意到的？
我们在 Manus 构建 agent，所以我们坚持两条原则：用自己的产品做真实工作，并持续寻找 AI 失灵的地方。
我想记录一下当人与 agent 默认并肩工作时，一家公司内部会发生什么。本文涵盖三个团队——工程、产品和市场——并包括那些行不通的地方。这是一份正在进行中的实验报告，而不是对"AI 原生组织"的定义。
我们目前学到的：
•没有折中之道。把 AI 加到旧的工作方式上有时只会增加噪音。只有当闭环真正形成时，事情才会改变。
•Agent 需要全局视野。更好的上下文比更好的提示词给我们带来的收益更大。
•信任来自测试和上下文，而不仅仅来自模型质量。
•自主性需要终点线。只有当成功可被验证时，agent 才能独立运行。在其他所有地方，由人来决定。
•瓶颈会转移。当工程变得更快时，决定该构建什么反而成了约束。
•人的角色并未被削弱，反而更聚焦于高影响力的事情。
1. 没有折中之道
在 2026 年之前，我们和大多数公司做的事一样：把 AI 加到我们已有的工作方式上。这意味着客服用 AI 摘要来标记问题，工程师使用编程助手，机器人在频道里发布分析。每一块单独看都有用，但各块之间彼此并不相连。在闭环真正形成之前，我们只是在用老办法工作，只不过多了许多 AI 在互相说话。
有一句话我们常常回到：软件工程是随时间累积的编程。写代码容易衡量；让一个复杂产品健康地运行多年则不然。AI 写代码的高占比可能意味着真实的进展，也可能意味着在堆积日后要有人清理的垃圾。
我们真正在意的考验更难。Manus 是一款已上线超过一年的复杂产品。它能否在新的工作方式下持续改进而不崩塌，同时每个人都能做得更多？到目前为止，答案是肯定的。
2. 把全局交给 agent
和大多数科技公司一样，我们在交接环节损失的时间最多。前端工程师和后端工程师会各自解读一个需求，就接口达成一致，然后花几天时间修复不匹配的地方。两个人很少会以相同的方式理解同一个需求。
如果 AI 能跨技术栈写代码，是否可以让一个人端到端地负责一个需求？障碍在于上下文。我们的代码分散在不同的仓库中，没有哪个 agent 能一次看到整个系统。
我们对此的回答始于一次内部实验。我们想看看在尽可能少的人工输入和几乎不手写代码的情况下，AI 能把一个产品做到什么程度。我们在这个过程中形成的方法，演变成了如今我们称之为 Manus-mono（或简称 Mono）的内部工具。
Mono 并不合并我们的代码仓库。它是一个统一的入口，加上一份写给 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 的边界本就是我们存在的原因之一，而且我们的组织是扁平的。工具能走多远，取决于组织允许它走多远。
3. 闭环：从用户的 bug 报告到经过验证的修复
Mono 让任何人都能参与产品的任何部分。这只是其中一半。另一半是让 agent 能自主发现问题。
在大多数互联网公司，用户的 bug 报告要先经过客服、产品和分流，才能到达能够修复它的工程师手上。
对我们来说，现在是一个内部 agent 先调查该报告，并把问题追溯到导致它的那次改动。然后它会在 Slack 中发帖，并 @ 负责这次改动的工程师。工程师来决定是否属于自己要修的，然后交给自己的 agent 处理。另一个独立的 agent 会通过运行相关测试和流程来检查修复。
三个 agent，三种角色：一个负责分流，一个负责执行，一个负责验证。中间的人做出判断。我们越来越多的工程工作现在都以这种方式开始——由 agent 把问题交到人手上。
这个闭环有明确的边界。读取用户报告的 agent 不能改动代码。它只能调查并向我们反馈。改动来自工程师自己的 agent，并且需要工程师先做决定。任何内容在未经拥有发布权限的人审批之前，都不会发布上线。
4. 我们如何学会信任 Agent 编写的代码
长期以来，合并到主分支的每一次更改都需要两位高级工程师之一的签字确认。我们对 AI 的信任还不足以跳过这一步。随着 Agent 产出的代码越来越多，这个审查环节成了瓶颈。
就纯粹的编码能力而言，模型已经相当出色。我们意识到差距归结为两点。第一，人知道如何测试自己的工作。第二，人参与了上下游的讨论，所以他们知道对业务而言什么才是"正确"的。正确的代码并不等同于正确的产品。
我们从两方面入手解决：
•让 Agent 加入讨论。现在，每位工程师的 Agent 都会驻留在它被添加的 Slack 讨论串中，跟进上下文。当有人最终说"开工"时，Agent 已经知道团队决定了什么以及为什么。
•让 Agent 进行端到端测试。我们与后端团队合作，赋予 Agent 在每次更改后于 Manus 中运行真实流程和回归测试的能力。随着测试覆盖率的增长，我们的信任也随之增长。
如今，每一次更改都要通过这种验证，并经过运行最强可用模型的代码审查机器人审查，对支付等敏感领域还有额外规则。机器人取代了排队，而不是人的决策。Agent 可以提交 pull request，但未经人的明确批准，无法合并到我们的主分支。什么要构建、谁可以发布，仍由人来决定。
5. 自主性需要一个终点目标
信任是有边界的，我们是通过艰难的教训才明白这一点的。
曾经有一段时间，大家都对完全自主的 Agent 循环感到兴奋，于是我们试了一次。一个 Agent 从我们的内部反馈渠道收集反馈，并为每一条反馈启动一个项目。一位同事让它运行了整个周末。周一早上，有超过 200 个项目在等待他的决策。
为什么不让 Agent 也替我们做这些决定呢？自主循环只有在系统能够检查目标是否达成时才有效。测试通过或失败；页面能加载或不能加载。而大多数现实工作并没有这样的检查。必须由人来判断事情是否完成，以及是否值得去做。
那个周末我们得到了两条教训。第一，人做决策的速度跟不上一个不受约束的循环产生决策的速度。第二，如果没有人决定某件事是否该做，那就没有人为结果负责。第 3 节中的 bug 修复循环之所以奏效，是因为测试定义了成功。产品决策没有测试可依，所以 Manus 的每一次产品变更仍然始于一个人决定是否值得去做。
6. 当工程变得更快时，产品反而成了瓶颈
传统的产品流程有许多交接环节，每一次交接都会让优先级稍稍偏移。随着编码 Agent 让工程师效率更高，一个新问题出现了：没有足够的产品经理来撰写好的需求。工程第一次不再是瓶颈。
在 Manus，我们的第一个解决方案是请几位工程师成为"建造者"，从探索到发布全权负责一个问题。但同时具备技术判断力和产品判断力的人寥寥无几。接着我们让 PM 来改代码，这同样陷入停滞。交接依然存在，而没有工程师的直觉，PM 可以改文案和交互，却改不了底层逻辑。
Mono 解决了这两个问题，因为它自带规则：
•任何涉及模型调用或成本的更改，都需要在编写代码前获得负责人的签字确认。
•每一次更改都要经过与工程师更改相同的审查和测试。
•Mono 可以使用测试账户走完注册和支付流程，并记录每一步，这样 PM 就能准确指出出问题的具体时刻。
下面是实际操作中的样子。一位负责语音转文字的 PM 让 Manus 对 10 多个模型进行了基准测试，然后选定了一个。她通过 Mono 拉取前端代码，在我们的设计系统中构建了一个 demo，并让 Manus 把每个用户场景渲染成图片供她审阅。她把 demo 转成了视频。方案清晰到她自己就把该功能构建了出来，包括 Web 和桌面端 UI。
过程中有人做出了三个决定。她选择了模型。产品和设计团队审查了演示。一位拥有发布权限的工程师审查了代码。一年前，这一切都不可能实现。
我们将这种转变描述为从人在环中（human in the loop）转向人在环上（human on the loop）。过去 AI 完成任务的 70-80%，人来补足剩余部分。现在人来设定规则，监督多个 agent，在关键节点检查方法和结果，必要时介入，并对结果负责。
现在有些 PM 会提交一段简短的视频，而不是书面规格或原型图。几分钟内，视频就能展示使用场景、每个界面、每次点击的作用、边缘情况如何处理，以及底层如何运转。对我们而言，设计、工程和 QA 能更快就"完成"的定义达成一致，PM 只需讲解一次。
（语音输入的产品需求视频）
如今约有一半的 PM 独立上线功能，每位 PM 都提交过代码。设计师也开始动手了。一位 PM 在 Manus 2.0 中编写了 Manus Studio 界面的大部分代码。另一位编写了视频编辑器。这些成果的背后，是有人花了数月时间突破自己原有的岗位边界。这是最让我自豪的地方。
这并不意味着每个人都必须成为开发者。当公司里任何人都能构建产品时，可能会有人上线一些本不该存在的东西。我们的产品团队经常问一个问题："如果这件事只花一秒钟且零成本，你会上线吗？"有时答案是否定的。我们仍然需要模块负责人来决定构建什么、不构建什么以及用户最终看到什么。我们也需要有人来维护像 Mono 这样的基础设施。当构建变得容易时，决定构建什么就更为重要。
7. 营销工作流中的 AI 队友
一次营销合作要经历脚本审查、定价、合同、审批、付款、上线和效果复盘等环节。这些步骤分散在邮件、合同工具、审批系统、电子表格和广告平台中。过去工作中很大一部分时间都花在了在这些系统间搬运信息，留给需要判断力的创意工作的时间很少。
我们从一个小问题入手：合作方内容或广告上线后，我们往往很晚才知道。于是我们让 AI 写了一个脚本来检测内容何时发布。接着我们想要效果数据。然后是过往合作的复盘。再然后整个内部工作流被打通：当合同签署或审批通过时，agent 会更新状态并通知负责下一步的人。
Manus 将这一切构建成了一个内部站点。对人而言，它是仪表板和日历。对 agent 而言，它是一组工具。使用这些工具在我们工作流中运作的 agent，就是我们所说的 AI 队友。它只在团队为其接入的渠道和系统中工作，访问权限仅限于此工作流。
它的工作内容如下：
•它管理自己的队列。许多人同时向它发消息，所以它在一个"前台"会话中与所有人沟通，并把任务分派给并行会话。它会判断某条消息是否与自己相关，然后再决定是中断当前工作还是等待。这些规则是它在开发过程中自行提出的，我们审查后予以保留。
•它从转发的上下文中学习。过去策略调整意味着一场会议和一份书面简报。现在我们的营销负责人会把讨论转发给它，并说一句"学习一下"。
•它会关注长期目标。有一次，Slack 线程中的队友（它也被加入了该线程）记不清某个项目的进展。它在未被 @ 的情况下回复道："B 还在测试中。要不要等 A 的结果出来再看 B？"
•它会与其他团队核实事实。在我们上线 3D 模型绑定后，它向产品团队询问支持哪些内容。它了解到绑定覆盖七个类别，包括鱼类、蛇类和四足动物，因此我们的描述得以保持准确。
现在队友们会让它参与脚本和定价审查，因为它读过我们过往的合作记录。但最终决策仍由人做出。
这个内部站点也能从它的使用者（包括 agent 本身）身上得到改进。当 agent 遇到阻碍时，它会通过反馈接口提交一个请求。该请求会通过 Manus 2.0 中的自动化在 Manus 中创建一项开发任务，由工程师审查变更后再发布。它已经运行了大约一周。我们还需要积累更多案例才能真正依赖它。
那么团队里的人做什么呢？有三件事仍由他们负责。他们做出并承担每一项重要决定。他们处理 agent 未见过的情况，并教它该怎么做或该找谁。当它的分析指向新的角度时，他们会调整它的方向。
8. 减少互相打扰
在所有这些团队中,许多问题不再需要去打扰某个人。
先问 Agent。一位同事在 Mono 上搭建了一个 Slack 机器人,它运行在云端电脑上并在话题串中回复。非工程师用得最多。这个功能是怎么工作的?这个字符串在哪里?这个发布了吗?他们不再需要先去找负责人。
打开会话,而不是询问进度更新。工程师的进展过去都存在他们自己的 AI 聊天里,他们一下线就看不见了。所以我们做了一个内部功能,让项目成员可以看到彼此的会话,并申请加入。工程师可能用 Agent 完成了一个功能的大部分,然后 PM 加入同一个会话来调整间距、样式和文案。在别人的会话中发帖需要对方批准,我们还在完善权限机制。
(示意图:工程师、PM 和设计师如何在一个会话中协作。并非真实的价格调整。)
重点不是让大家彼此交流更少,而是让大家彼此打扰更少。
只决定需要决定的事。我们使用 AI 最多的人保留了一个主会话,专门做一件事:列出需要他决定的事项,并为每一项给出建议。当 Slack 变得繁忙时,他不参与其中,而是问:"我现在需要决定什么?"
我也做类似的事。我每天有超过 20 个待办事项,而且正如我公开分享过的,我有 ADHD。对我来说,最难的部分是开始。现在每个待办都进入一个专属的 Manus Project,它会把每一项变成单独的任务。它能启动的就启动。遇到不确定的,它会问我背景信息,以及该由哪位 PM 负责。然后,利用我授予它的对我自己 Slack、Gmail 和 Notion 的访问权限,它会收集上下文,并把一个完整的请求交给 PM,而不是只给一句话。对我来说,这种变化不仅仅关乎效率。我现在每天花在对从何入手感到焦虑上的时间少多了,这在个人层面意义巨大。
9. 这些花费值得吗?
我们在 AI 上花费很多,并且密切跟踪这些支出。我们不是用它来评判任何人的表现。我们是用它来评判这笔支出本身:它现在是否有回报,或者是否在为未来打基础?
以下是我们认为它为我们带来了什么,以及我们预期成本会如何变化:
•它为我们换来了时间和注意力。随着团队壮大,协作会消耗每个人的注意力。AI 保护了每个人的注意力,让他们能够更充分地掌控自己的工作。而我们还在继续招聘。
•使用最好的模型是我们了解 AI 边界的方式。第 4 节描述的验证和代码审查设置运行在我们能用到的最强模型上。负责开发者生产力的同事称之为我们最具性价比的支出。
•成本应该通过产品降下来。我们现在越来越多的开发工作发生在我们自己的产品 Manus Studio 中,所以我们的使用数据能告诉我们 tokens 浪费在哪里。修复会进入产品本身,因此也应该让 Manus 对用户更高效。我们预期随着模型变得更便宜以及我们消除浪费,今天的成本将大幅下降。这是一个信念,而不是承诺!
10. 哪些还没做好
打扰变少了,但注意力更碎片化了。过去一天处理四五件事的人,现在可能同时推进 20 或 30 件事。每次切换都意味着重新加载上下文。AI 扩展了人们能做的事情,也促使他们做得更多。一位 PM 告诉我,只要有一个任务在跑,她就忍不住要启动另一个 Agent。做更多的事情不是目标。我们把这当作一个需要解决的问题,而不是值得庆祝的节奏。
信息更分散了。我们的产品负责人过去了解每一项变更以及背后的原因。现在他有时会截图一个问题去问 Mono:"这是谁改的?"听起来好笑,但这个问题是真实的。当每个人都被赋权去改变产品时,谁对整体负责?
共享权限需要重新设计。当工作可以被分享和交接,而 Agent 又出现在我们更多的对话中时,我们必须决定什么是开放的,什么需要审批。
我们的解决方案仍然很初级。目前,一个 Agent 监督其他 Agent,只汇报哪些卡住了以及哪些需要人来决策。我们知道这还可以做得更好。
11. 我们接下来要做什么
这些问题指向其他团队可能也会需要的产品工作。我们并没有提前规划这些功能。它们源自我们自己不断遇到的问题。
•把会话作为共享工作区。一个人提出问题，设计师提出方案，工程师构建它，PM 推动它运行，这一切都在同一个地方发生。
•跨设备、跨人员流转的工作。本地机器和云端机器保持连接，这样当有人暂时离开时，工作仍能继续。
•能发现人们未曾考虑过的方案的 Agent。一个在公司系统内运行、拥有合适权限的 Agent，应该能够提出解决方案，而不仅仅是执行指令。
我们会先在自己身上尝试这些，然后再带给用户。
12. 人们现在在做什么
那位同时打开一排 Agent 会话的工程师，不仅仅是一个关于效率的故事。它是组织运作方式的一次变革。过去，公司通过角色和层级来传递信息。一个人能做什么，取决于他能调动多少人和多少资源。现在，我们花一点时间为 AI 提供上下文和工具，然后花更多时间去做判断和决策。越来越多的时候，是 Agent 把问题带到我们面前。但决定如何应对，仍然是我们的工作。
我们开过这样的玩笑：如果 Manus 能做这么多，还来办公室干什么？让 Agent 自己搞定好了。但真正重要的问题，依然需要人来提出、争论和决策。例如，什么才算一个好产品？或者，稍微夸张一点地说：是打造一个有真实收入、持续推动 AI 边界的伟大产品，还是追求利润率？AI 不知道我们想要哪一个。我们知道。文化和信任，来自我们日复一日、在关键时刻一起把事情想清楚的过程。那是每个会话中所有工作所依托的基础。
所以，就目前而言，这是我们的答案。在我们作为 AI 原生组织的实验中，人的角色并没有被削弱。它变得更专注于那些他们能产生最大影响的领域：定义问题、判断质量、决定什么值得做、为结果负责。
这也是为什么我们仍在招聘。人的技能与判断力处于这种工作方式的核心——而这一点在短期内不会改变。
写下这篇文章时，我很好奇一年之后它会是什么样。每家公司都有不同的目标、结构和文化，所以可能没有标准答案，也没有最终形态。但对一家构建 Agent 的公司来说，弄清楚人与 AI 如何协作并不是可选项。它就是工作的一部分。我们会继续探索，也会继续分享我们的所学。
关于数据的说明。本文中的数字来自内部记录。团队规模和 PM 交付数据截至 10 月下旬。部分内容是估算或个人经验，而非严格的度量。
