加载中...
最近，Manus 团队成员 Ivan Leo 在个人博客中发布了一篇题为 Three Lessons I’ve Learned at Manus 的文章，对自己在 Manus 工作期间的经历进行了系统回顾。
Manus 是一款面向真实生产环境的 AI Agent 产品。在极短时间内，这个团队完成了从早期产品形态到大规模商业化的跨越。根据作者在文中的描述，Manus 在 不到 8 个月的时间里实现了超过 1 亿美元的 ARR，这在当前 AI 应用层中属于极端少见的增长曲线。
Ivan Leo 本人并非外部观察者，而是一线工程成员。他加入 Manus 的时间 ，但在这段高度压缩的时间里，已经深度参与了多个关键功能的设计、实现与落地，包括用户触达功能、支付系统集成以及 API 与内部连接器相关的维护工作。
欢迎关注 DataLearner 官方微信，获得最新 AI 技术推送
这篇文章并不讨论模型参数、训练方法或算法创新，而是从 工程执行、产品交付方式以及个人在高速系统中的角色变化 出发，总结了三条在现实环境中反复被验证的经验。正因为这些经验产生于一个「真实用户、真实收入、真实压力」的环境，它们才具备被单独拿出来分析的价值。
在传统软件工程体系中，“代码正确 ≈ 系统可用”并不是一种天真的假设，而是建立在一套成熟、长期有效的方法论之上。
产品经理通过 PRD 明确定义用户是谁、如何使用系统、允许和不允许的行为边界；工程师围绕这些确定性假设实现功能，并通过接口契约、单元测试和集成测试来验证正确性。在 UI 和流程的强约束下，用户行为高度可预测，系统是否可用，往往可以在上线前被证明。
这套机制在过去二十多年里持续奏效，其核心价值在于：把不确定性尽可能压缩在设计和测试阶段。
但在 Agent 产品中，这个前提开始瓦解。
首先，Agent 的主要交互方式是自然语言。用户输入不再是被严格约束的字段，而是开放文本；prompt 本身成为系统行为的一部分。真实使用路径不再是有限集合，而是一个不断被用户探索和扩展的空间。PRD 无法穷举这些路径，只能给出非常粗粒度的预期。
Manus 中 Mail Manus 功能的问题并不来自代码或接口错误，而是来自用户如何理解并使用这个 Agent。文档、示例和演示方式直接影响用户如何构造 prompt，也在无形中定义了系统的“可理解行为空间”。在这种情况下，文档不再是附属物，而是系统行为的一部分。
其次，测试环境无法覆盖模型决策的不确定性。支付能力在接口层面完全可用，并不意味着 Agent 已经理解了真实支付场景的语义差异。只有在真实生产环境、真实资金流转、不可逆操作的约束下，模型是否会做出错误但看似合理的决策，才会暴露出来。
在 Agent 系统中，很多“不可用”并不是 bug，而是系统在真实约束下的自然表现。这也是为什么工程责任不可避免地从“代码是否正确”，前移到了“系统在真实世界中是否可靠”。这一经验背后隐含的判断是：
在 AI 产品中，工程责任不能在代码层结束，而必须延伸到用户是否真正完成了任务。
传统软件工程高度重视前期规划，这同样不是偶然。在需求相对稳定、行为路径可枚举的系统中，充分的设计和评审可以显著降低返工成本。清晰的流程图、状态机和接口定义，能够让团队在实现阶段高效协作，避免无谓试错。
但 Agent 产品面对的，是另一类不确定性。Manus 的一个典型实践是：与其在文档中反复讨论 Agent 应该如何响应，不如尽快做出一个可交互的原型，让真实使用暴露问题。Ivan 加入团队后的第一个任务，就是构建一个通过邮件触发 Agent 的 Demo。这个 Demo 并不完美，但它足够真实，能够立刻进入用户使用路径。
在 Agent 系统中，许多关键问题无法通过设计阶段发现：
这里 Ivan 的一个实际例子是文件上传功能。早期版本的文件上传的功能设计非常传统：
从工程和流程角度看，这并不是错误；从规划角度看，它符合设计。但是这个功能设计有一个前提假设：用户愿意等待一个“完整结果”。但一旦进入真实使用，很多用户会在等待过程中直接放弃操作。在对话式 Agent 的语境下，这种无反馈的等待7秒让系统“看起来像是坏掉了”。然而，这些问题只有在系统被真实使用时才会显现。原型的价值，并不在于“验证设计是否正确”，而在于 尽早暴露哪些假设是错误的。解决方式并不是简单的性能优化，而是对整个交互与推理流程的重构。Manus 重新设计了文件上传后的体验，让系统在第一时间给出可感知反馈；同时，把文件处理变成了能力发现的入口——当用户上传幻灯片、视频或网站时，Agent 会基于内容类型主动给出具体建议。最终的结果不是“更快”，而是“感觉即时”，用户也更愿意继续探索这个能力。
在高度依赖模型行为的系统中，可运行原型本身就是最重要的信息来源。过度规划并不会降低不确定性，反而会推迟问题暴露的时间点。
在传统软件团队中，清晰的角色边界是一种优势。
工程师对模块和代码负责，产品经理对需求和用户体验负责，运维或平台团队对系统稳定性负责。只要系统行为高度可预测、模块边界相对稳定，这种分工不仅高效，而且是大规模协作的前提。大多数问题都可以被明确归因到某个模块或角色，再通过既有流程解决。
但在 Agent 产品中，这套分工开始失效。
原因并不在于组织设计不合理，而在于 系统问题的形态发生了变化。在以大模型为核心的系统里，失败往往不是单点错误，而是模型决策、工具调用、上下文管理和用户输入共同作用的结果。很多问题并不会表现为“接口报错”或“服务异常”，而是以一种更模糊的形式出现：系统给出了一个看似合理、但实际上不可用的结果。
Ivan 在 Manus 的经历正是这种变化的缩影。
在 API 发布之后，他在实际使用过程中发现了一个连接器相关的问题。这个问题并不在他的原始职责范围内，也不是一个会在常规测试中被轻易捕捉到的显性 bug。它更多体现在系统行为层面：在某些组合条件下，Agent 的行为偏离了预期。
在传统团队结构下，这类问题往往会被来回转交——它既不像纯粹的模型问题，也不像明确的业务逻辑错误，很难第一时间判断“该由谁来修”。但在 Manus 的节奏下，等待职责确认本身就意味着问题会持续影响真实用户。
于是 Ivan 选择在周末直接修复了这个问题。
这次修复的意义，并不在于“他多做了一点事”，而在于它揭示了一种新的现实：在 Agent 系统中，责任往往会落到最先看清问题本质的人身上，而不是最初被分配职责的人身上。 随着对这个模块理解的加深，他开始持续参与相关演进，并逐渐成为这一部分系统的主要维护者之一。
为了在陌生系统中快速推进，他并没有简单地抛出“我不知道怎么做”的问题，而是先观察系统中已经存在的实现模式，再提出更具体的问题——例如在某个场景下，是否应当沿用既有结构。这种提问方式的前提，是把自己放在“系统整体”的位置上，而不是局限于某个模块或角色。
从更宏观的角度看，这种角色边界的模糊并不是偶然现象，而是 Agent 产品的结构性结果。当系统行为高度依赖模型决策和组件组合时，问题的“责任归属”往往在事前是不可判定的。唯一可行的策略，是让责任向最理解系统整体行为的人前移。
在 Manus 这样的高速团队中，个人影响力不再主要由岗位描述决定，而是由一个人是否能够 持续减少系统的不确定性 决定。这不是对个人的道德要求，而是复杂 Agent 系统在真实环境中运行时，对组织提出的客观约束。
从表面看，这三条经验并不新颖，但它们在 AI Agent 系统中被反复放大：
在这种背景下，对结果负责、通过原型获取真实反馈、主动跨越角色边界，不再是个人风格问题，而是构建可用 AI 系统的基本条件。
也正因为如此，这篇来自 Manus 一线工程实践的总结，才具有超出个人经验分享的参考价值。
原文来源：Ivan Leo，《Three Lessons I’ve Learned at Manus》 https://ivanleo.com/blog/three-lessons-manus
