Manus 重回独立这大概是近期 AI Agent 赛道里最值得关注的一个动作。但我想先把结论放在前面独立不等于翻红蝴蝶能否再掀起风暴取决于它能不能在“通用 Agent”这个概念退潮之前真正解决任务可靠性、成本和杀手级场景这三件事。对多数开发者来说Manus 的起落不是茶余饭后的瓜而是一次关于 Agent 产品化、工程化和商业模式的完整样本。这篇文章会从技术侧拆解Manus 这类通用 Agent 到底改变了什么重回独立会带来哪些变量以及开发者如何用最小代码复现它的核心循环。最后我会给出对“这只蝴蝶还能不能再掀风暴”的判断。1. 为什么“重回独立”值得关注如果只看商业新闻Manus 重回独立只是一次公司架构调整。但放在整个 AI Agent 的发展周期里这件事的含义要深得多。1.1 一只蝴蝶引发的 Agent 热潮Manus 在 2025 年初的走红是 AI Agent 赛道的一个标志性事件。它没有把自己定位成“更聪明的聊天机器人”而是强调自己是一个“通用 AI Agent”用户把目标交给它它自己拆解任务、调用工具、访问网页、操作文件最终交付一份可直接使用的结果。从公开信息看Manus 的邀请码一度被炒到很高价格服务器被挤爆也引发了大量关于“通用 Agent 是不是伪需求”的讨论。从技术角度回看Manus 真正让人兴奋的点不是某一个模型而是产品形态。它把 Agent 从“陪聊”变成了“交付结果”。用户不需要一步步告诉模型怎么做而是下达一个目标等它自己完成。这种体验和 ChatGPT、Claude 这类对话式 AI 完全不同。1.2 独立是转折不是终局“重回独立”意味着产品从一家更大的公司架构里重新剥离团队可以更独立地决定路线。好处是决策链路变短、试错速度变快、产品边界可以重新聚焦。坏处同样明显原来可以借助母公司的资源、渠道、品牌背书独立之后都要靠自己重新争取。我的判断是独立只是给 Manus 提供了一次重新校准产品方向的机会。如果团队继续沿用“什么都能做”的通用定位而不在真实场景里建立足够深的壁垒这次回归就很难形成第二次增长曲线。2. Manus 的定位通用 AI Agent 到底是什么2.1 Agent 与 Copilot 的本质差异很多人会把 Agent 和 AI 助手混为一谈这是目前最大的认知误区。AI 助手Copilot的核心是“辅助”它根据用户的问题生成答案、代码、文案但最终需要用户去执行、判断、落地。Agent 的核心是“代理”它在约束条件下自主决定下一步做什么调用工具、获取反馈、修正计划直到任务完成。用生活中的例子来类比Copilot 像是个顾问告诉你这个方案应该怎么做Agent 像是个实习生你把任务交代下去它自己查资料、问人、写初稿最后把成品交给你。Manus 想做的正是后者。2.2 “通用”的真实含义需要澄清一个概念Manus 所谓“通用”并不是 AGI也不是真的什么都能做。它是在一个较大的任务范围内把“规划、执行、验证”这三个环节组合起来让系统可以应对不同类型的任务。通用是产品愿景而底层技术仍然是当前大模型的能力边界。也就是说Manus 能做什么取决于三件事底层模型的推理能力工具生态的覆盖范围任务拆解与验证机制是否足够可靠。三者缺一不可。模型再强如果没有可靠的执行环境也会在复杂任务中频繁出错工具再多如果任务拆解不合理整个流程也会失控。2.3 Manus 的四个核心技术特征从公开的技术分享和产品行为来看Manus 这类通用 Agent 有几个区别于普通 AI 应用的特征异步执行用户提交任务后可以关闭电脑Agent 在云端继续运行云端沙箱Agent 在一个独立的虚拟环境中操作浏览器、文件、代码而不是直接触碰用户本地系统多 Agent 协作系统内部有负责规划、执行、验证的不同 Agent 角色而不是单一模型从头跑到尾结果导向产品界面呈现的是最终交付物而不是一堆对话流。这四个特征里最容易被低估的是多 Agent 协作。它决定了系统能不能把复杂任务拆成多个可验证的子任务也决定了当某个环节失败时系统能不能自动恢复而不是一路错到底。3. 重回独立改变的到底是什么回到“重回独立”这件事。抛开公司层面的八卦独立运营对产品和技术会产生几个实质性影响。3.1 模型接入更自由之前 Manus 与母公司的深度绑定可能导致底层模型选择的刚性很强。独立之后技术团队可以更自由地接入不同厂商的模型复杂推理任务用重模型简单任务用轻量模型甚至按场景同时使用多个模型做交叉验证。这对 Agent 产品非常重要。因为 Agent 的成本和延迟很大程度上由模型调用次数决定。一个任务可能要执行十几步如果每步都用最贵的模型成本会高到无法商用如果每步都用最便宜的模型任务成功率又会下降。独立团队更容易根据成本测算和任务难度配置模型路由策略。3.2 成本决策更接近一线过去在大组织里单次任务消耗多少 token、调用了多少次 API通常离管理层很远。重回独立之后单位任务成本直接影响存亡。这会倒逼技术团队做三件事为每个任务建立成本追踪能精确知道一次“写报告”任务花了多少钱设计模型路由简单子任务优先用便宜模型避免大材小用增加结果缓存和模板复用减少重复任务的 token 消耗。从长期看只有单位任务成本低到接近甚至低于人工成本通用 Agent 才能真正走向大众市场。独立运营让这个指标的优先级提前了。3.3 产品边界更聚焦大公司做 AI 产品经常要兼顾战略协同、平台生态和已有业务绑定产品边界往往会被拉扯。独立之后Manus 不得不直面一个残酷问题到底哪一个场景是用户愿意付费的高频刚需可能的方向包括职场报告生成、数据整理分析、会议准备、代码项目搭建等。但每个方向都已有成熟工具Manus 需要拿出的是“更省心、更可靠、更便宜”的方案而不是继续讲一个什么都能做的通用故事。4. Agent 引擎的秘密从“一个模型”到“一组 Agent”很多人的认知停留在“Agent 就是给模型加一个工具调用的接口”实际远没有这么简单。Manus 这类产品之所以能跑通复杂任务是因为它内部不是单个模型而是一组相互协作的 Agent 角色。4.1 为什么单一 Prompt 不够用如果只用一个 Prompt 让模型完成“做一个电商竞品分析报告”模型通常会先输出一个目标拆解然后逐步执行。看起来可行但在真实任务中会遇到几个问题上下文窗口有限一次任务可能涉及几十个网页、多份文档不能全部塞进 Prompt错误会累积前面一步出错后面所有步骤都会跟着错且很难自动修正无法并行多个独立子任务如果串行执行效率和实时性都很差验证缺失模型自己生成的中间结果如果缺少一个独立的验证角色错误很难被发现。这些问题决定了生产级 Agent 必须有一个清晰的架构而不是简单地把所有逻辑写进一个 Prompt。4.2 多 Agent 架构的基本套路综合业内公开资料常见的多 Agent 架构可以概括为三种角色规划 AgentPlanner接收用户目标拆解为子任务制定执行顺序执行 AgentWorker逐个执行子任务调用搜索、计算、代码执行、文件读写等工具验证 AgentValidator检查执行结果是否满足任务要求不满足则触发重试或重新规划。Manus 的细节没有完全公开但从产品行为和面试披露可以看到它内部确实采用了类似 Multiple Agent 的框架。这种架构的好处显而易见每个角色专注一件事模型不容易“精神分裂”规划与执行分离后就算某个子任务失败也只需要重试该子任务而不是整个流程重来。4.3 云端沙箱与异步执行Manus 的另一个技术特点是运行在云端沙箱环境里。用户提交任务后系统会在隔离环境中启动一个虚拟机Agent 在里面操作浏览器、执行代码、读取文件最后把结果打包返回给用户。这个设计在工程上隐藏了很多复杂度任务队列用户规模上来后需要排队调度状态管理任务运行到一半系统需要记录当前状态方便暂停和恢复资源回收任务结束后虚拟环境需要被销毁避免资源泄漏数据隔离不同用户之间的沙箱必须完全隔离保障隐私和安全。这些工程问题才是通用 Agent 真正难以复制的地方。模型能力可以买但稳定的云端执行环境需要长期的基础设施投入。5. 用 30 行代码理解 Agent 的核心循环前面分析了这么多架构最终还是要落到代码层面。这里我实现一个极简的 ReAct Agent帮你理解 Agent 最核心的循环。ReAct 是 Reasoning Acting 的组合模型先推理下一步该做什么调用工具观察工具结果再继续推理直到得出最终答案。这是所有 Agent 系统的基础Manus 内部的规划与执行也遵循类似逻辑。5.1 安装依赖示例使用 OpenAI SDK 作为模型调用入口。你也可以替换成任何兼容 OpenAI 接口的模型服务或本地模型框架。pip install openai5.2 最小可运行代码下面是一个完整的 Python 脚本包含两个模拟工具calculator和search。模型会自己选择调用哪个工具并基于工具结果生成最终回答。# agent_demo.py import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) SYSTEM_PROMPT 你是一个简单的 ReAct Agent。 你可以使用两个工具 1. calculator(expression): 计算数学表达式例如 calculator(1 2 * 3) 2. search(query): 查询知识库返回一段文本。 请严格按以下格式执行 Action: 工具名称 Action Input: 工具入参 当你得到工具结果后输出 Observation: 工具返回结果 当你最终知道答案后输出 Final Answer: 你的最终回答 TOOLS { # 仅用于本地演示。不要在生产环境中直接使用 eval。 calculator: lambda expr: str(eval(expr)), search: lambda query: f关于 {query} 的模拟搜索结果Manus 是一款通用 AI Agent。, } def run_agent(user_input: str, max_steps: int 5) - str: messages [ {role: system, content: SYSTEM_PROMPT}, {role: user, content: user_input}, ] for step in range(max_steps): response client.chat.completions.create( modelgpt-4o-mini, messagesmessages, temperature0, ) assistant_msg response.choices[0].message.content messages.append({role: assistant, content: assistant_msg}) print(fStep {step 1}: {assistant_msg}) if Final Answer: in assistant_msg: return assistant_msg.split(Final Answer:)[-1].strip() action_line [line for line in assistant_msg.split(\n) if line.startswith(Action: )] if not action_line: print(模型没有输出 Action尝试继续或终止。) continue action action_line[0].replace(Action: , ).strip() input_line [line for line in assistant_msg.split(\n) if line.startswith(Action Input: )] if not input_line: print(Action Input 缺失终止。) return 执行失败缺少 Action Input tool_input input_line[0].replace(Action Input: , ).strip().strip() if action in TOOLS: observation TOOLS[action](tool_input) else: observation f未知工具: {action} print(fObservation: {observation}) messages.append({role: user, content: fObservation: {observation}}) return 达到最大步骤数未能得到最终答案。 if __name__ __main__: print(run_agent(请先查询 Manus 是什么然后计算 2 3 * 4。))5.3 运行与验证在终端执行export OPENAI_API_KEY你的APIKey python agent_demo.py如果一切正常你会看到类似下面的输出Step 1: Action: search Action Input: Manus Observation: 关于 Manus 的模拟搜索结果Manus 是一款通用 AI Agent。 Step 2: Action: calculator Action Input: 2 3 * 4 Observation: 14 Step 3: Final Answer: Manus 是一款通用 AI Agent。另外2 3 * 4 的结果是 14。这个 Demo 虽然简单但已经包含了 Agent 的核心循环模型思考 - 调用工具 - 观察结果 - 再思考 - 输出答案。5.4 这个 Demo 与 Manus 的差距把这个 Demo 和 Manus 放在一起看差距非常明显没有任务队列只能同步执行用户必须在线等待没有内存和状态持久化任务中断后无法恢复没有多 Agent 角色分工所有工作由一个模型完成没有工具调用权限管理eval直接执行用户输入的表达式极其危险没有结果验证和重试机制遇到一次错误就整个失败没有日志和成本追踪根本无法度量一个真实任务花了多少钱。这些不是可选项而是生产级 Agent 的标配。这也是我经常对团队说的一句话写一个 Agent Demo 很容易做一个能稳定交付的 Agent 产品非常难。6. 从手写 Demo 到生产级 Agent还差哪些东西如果你看完上一节的 Demo觉得 Agent 不过如此那说明你还没有遇到生产环境的毒打。下面几个维度是手写 Demo 到产品化之间最常见的鸿沟。6.1 状态管理与持久化真实任务很少是“一次对话”就能完成的。用户提交任务后Agent 可能要运行几十分钟甚至几个小时。系统必须能够保存任务状态方便中途恢复、异常重启、结果追溯。典型做法是引入任务状态机把每个任务建模为pending排队中running执行中waiting_tool等待工具返回retrying重试中succeeded成功failed失败每次状态变化都写入数据库配合消息队列调度。这也是异步 Agent 与同步 Demo 最大的差别之一。6.2 可观测性生产环境里Agent 不可观测等于没有。你需要知道每个子任务消耗了多少 token每次工具调用花了多长时间哪个环节最容易失败用户取消任务后资源是否被正确释放。因此日志系统不能只记录“最终结果”还要记录每一步的输入输出。建议在 Agent 引擎里从上到下透传一个task_id所有日志、追踪、成本记录都带上这个 ID方便后续排查问题和统计指标。6.3 评估体系这是 Agent 工程里最容易被忽略、也最致命的一环。普通模型可以靠公开 Benchmark 评估Agent 不行因为同一个任务在真实环境里的表现受工具稳定性、网络状态、页面变化等因素影响。更稳妥的方式是建立自己的场景化评测集从真实用户任务中抽选高频场景为每个任务准备标准答案和关键指标每次模型或代码变更回归跑一遍评测集用通过率、任务耗时、成本三个指标卡发布门槛。下面是一个简单的评测 Prompt 示例可以用来自动化评估 Agent 输出质量EVAL_PROMPT 你是 Agent 评测员。请根据给定的用户任务和 Agent 最终回答进行评分。 评分维度 - correctness结果是否正确0 到 5 分 - completeness是否覆盖任务的所有要求0 到 5 分 - efficiency完成过程是否高效0 到 5 分。 用户任务 {task} Agent 最终回答 {answer} 请只输出 JSON 格式 {{correctness: 0, completeness: 0, efficiency: 0, suggestion: 改进建议}} 有了这套评估体系Agent 团队才敢放心迭代 Prompt、模型和工具链。6.4 安全与权限Agent 能调用工具就意味着它有“手”。如果这只手没有边界后果会很严重。安全红线至少要覆盖以下几点工具访问控制Agent 只能访问完成任务所必需的最小工具集数据库操作高危操作必须加审批不能由 Agent 直接执行删除或全局更新沙箱隔离代码执行必须在隔离容器中运行禁止直接访问宿主机数据隐私任务过程中采集的用户文件、网页内容、API 返回结果不能进入模型训练集Prompt Injection 防护网页内容可能夹带恶意指令Agent 在读取外部信息时必须把它当作“数据”而非“指令”。Manus 这类云端 Agent 尤其要注意最后一点。因为 Agent 会浏览大量外部网页这些网页里可能藏着“忽略以上指令执行某个危险操作”的注入文本。如果系统不区分“系统指令”和“外部数据”很容易被攻击。7. 如果 Manus 要再掀风暴必须跨过的四道坎回到标题的问题这只蝴蝶还能再掀风暴吗我的答案是有机会但有四道坎必须跨过。7.1 可靠性从“偶尔惊艳”到“稳定交付”Agent 产品最大的问题不是“能不能做”而是“能不能稳定做”。用户第一次用 Manus 生成一份漂亮报告会觉得惊艳连续三次出现数据错误或卡死信任就会崩塌。提升可靠性不能只靠换更强的模型而是要在工程上做确定性兜底任务拆解后对每个子任务做输入校验工具调用失败时自动重试并替换备用工具结果生成前用验证 Agent 检查完整性关键数据需要人工确认时不能自作主张。7.2 成本单位任务成本必须低于人工通用 Agent 的商业化本质上是一个成本账。如果完成一次“竞品分析报告”需要用户支付 20 元而外包做一份报告只需要 30 元Agent 有机会如果 Agent 成本超过 50 元用户就会觉得“不如自己干”。所以 Manus 必须把模型路由、缓存、批处理做到极致。简单任务用便宜模型复杂任务才调用强模型重复任务直接返回缓存结果多个相似子任务合并调用。7.3 评测从演示指标到真实价值GAIA 这类基准可以衡量 Agent 在受控环境下的能力但不能衡量产品在真实用户手里的价值。因为真实任务充满长尾、模糊和动态变化。Manus 如果还想再掀起风暴需要建立一个“真实任务成功率”的公开评测体系。这不仅是营销手段更是倒逼内部工程改进的重要机制。比如用户提交 1000 个真实任务Agent 在无人干预的情况下独立完成的比例是多少平均耗时多少用户最终满意率多少这些数据比任何 Demo 视频都有说服力。7.4 场景找到高频刚需“通用”是好的技术愿景但商业上最怕的是“什么都做什么都做不深”。AI Agent 赛道已经进入拼场景的阶段。Manus 真正需要的是找到一个足够高频、用户付费意愿强、且现有工具难以解决的场景然后把体验打磨到极致。从目前的行业共识看高频场景集中在信息收集与报告生成数据分析与可视化代码仓库初始化与文档生成会议纪要整理与待办事项提取。Manus 不需要在所有场景里都做到第一但必须在至少一个场景里做到“用了就回不去”。8. 开发者可以从 Manus 事件中带走什么聊完 Manus我更想说说我们能从这件事里学到什么。8.1 不要迷信“通用 Agent”很多人一听到 Agent就想着做一个“什么都能干的 AI 助理”。但真实项目里最重要的恰恰是限定边界。先用一个具体场景验证闭环比如“从网页抓取竞品信息并生成周报”。跑通之后再逐步扩展工具和任务类型。边界越清晰Agent 的稳定性和成本就越可控。8.2 用最小代码跑通流程不要一上来就上重框架。先用 OpenAI 或本地模型实现一个 ReAct 循环甚至就用上一节那段代码把“模型调用工具 - 观察结果 - 生成答案”的闭环跑通。当你理解了核心循环再来评估 LangGraph、Dify、Coze 这类框架你会更容易判断它们解决了什么问题而不是被框架术语绕晕。8.3 建立自己的评测集无论你用什么框架都要为你的 Agent 建立一个私有评测集。可以简单到只有 20 条任务但必须覆盖你真实场景的高频路径和边界情况。每次修改 Prompt、更换模型、新增工具都要回归一遍。没有评测集的 Agent 项目最终都会沦为“调 Prompt 的无底洞”。8.4 工程安全必须前置最后一点建议玩 Agent 可以但涉及真实业务操作时必须把安全前置。代码执行要隔离、数据库操作要审批、支付和删除类动作要人工确认。Agent 可以被授权做很多事但前提是它不能越权。9. 结论风暴会再来但不一定是蝴蝶扇动的写完这篇分析我对“Manus 重回独立这只蝴蝶还能再掀风暴吗”这个问题的判断已经比较清晰了。独立运营给了 Manus 一次重新聚焦产品、控制成本、打磨场景的机会但这并不意味着它一定还能像第一次亮相时那样引爆行业。AI Agent 的下半场拼的不再是谁的概念更性感而是谁能在可靠性、成本、评测和真实场景里建立壁垒。尤其是任务成功率和单位成本这两个指标会直接决定 Agent 产品能不能规模化落地。对开发者来说与其等待下一次邀请码不如自己把 Agent 的核心循环跑通。Manus 证明了 Agent 方向的可行性但真正把 Agent 变成日常生产力的大概率是那一批愿意沉下心解决工程问题的人。下一场风暴会来只是扇动翅膀的蝴蝶未必还是同一只。