51CTO-acedar-Manus的核心理念和源码深度剖析

Manus 这个名字你可能已经听过很多次：一堆演示视频、几张流程图、几句「通用 agent」的口号。但真到要改它、调它、或者拿它的思路做自己的东西时，问题就来了——它到底怎么把一次用户请求拆成若干步骤？工具调用失败之后重试还是换策略？多个 agent 之间是并行、串行还是互相打分？这些问题靠看演示视频是答不上来的，只能去读执行链路。

这份资料面向的就是卡在这个位置的人：用过 agent 产品，也写过一些 function calling 的代码，但没系统跟过一个完整框架从入口到落地的路径。

先确认你缺的是哪一块

Manus 类的框架，难点通常不在模型本身，而在模型之外的那层调度。可以自查几个问题：

• 一次任务进来，是先规划再执行，还是边想边做？中间状态存在哪里？
• 工具（浏览器、代码执行、文件读写）是怎么注册给模型的？schema 长什么样，返回结果怎么回灌进上下文？
• 单个 agent 循环什么时候终止？靠模型自己说「完成」，还是外部有判定条件？
• 多 agent 协作时，谁负责拆任务、谁负责汇总，分歧怎么收敛？

只要其中有两三个答不利索，说明你看的还停留在接口层，没进到执行层。这份资料的价值就在这一段。

内容大致覆盖的三条线

一、核心理念：为什么这么设计

官方示例是理解设计意图的捷径。同一个任务，看它怎么被描述、怎么被拆、中间产物以什么形式流转，比直接读代码更快建立直觉。重点不是记流程，而是想清楚每一步「为什么必须存在」——比如为什么要有独立的规划环节，为什么执行结果要先落盘再进上下文。想通了，你自己设计时的取舍就有依据。

二、执行逻辑：从入口到产出

这是最需要动手跟的部分。建议边看边标记三类位置：状态定义、循环控制、错误处理。状态定义决定了框架能记住什么；循环控制决定了它什么时候停、会不会绕圈；错误处理最容易被忽略，却最能看出工程成熟度——工具超时怎么办、返回格式不符合预期怎么办、上下文超长怎么截断。源码剖析里这些细节往往比架构图更有用。

三、多 agent 机制

多 agent 不等于多开几个模型。真正要弄清楚的是分工方式与通信方式：任务是预先静态切分，还是运行时动态派发；agent 之间传递的是原始上下文还是压缩后的结论；出现冲突时有没有仲裁环节。这部分看懂之后，你对「多 agent 到底解决什么问题、又在哪儿引入新问题」会有自己的判断，而不是跟着宣传走。

建议的跟课方式

• 不要一口气刷完。按「理念—执行—多 agent」分段，每段结束自己画一张流程草图，再对照源码修正。
• 挑一个你熟悉的小任务（比如抓取页面并整理成表格），跟着框架跑一遍，记录每个环节的输入输出。
• 看到工具注册部分，试着加一个自己的工具，验证是否真的理解了接口约束。
• 多 agent 部分先别急着动手，先把调度关系讲清楚再改代码，否则容易越改越乱。

看完应该能回答的问题

• Manus 的主循环一次迭代包含哪几个阶段，各阶段的产出分别是什么？
• 工具调用的结果以什么形式进入模型上下文，为什么要做这层转换？
• 任务终止的判定条件是什么，异常路径下如何避免死循环？
• 多 agent 场景里，任务分配与结果汇总分别由谁承担？
• 如果要给这套框架换一个模型或加一类工具，改动会落在哪些模块？

能顺畅答出这几题，说明你已经从「会用」走到了「能改」。这也正是这份资料真正想帮你跨过去的那道坎：不是多认一个框架的名字，而是拿到一套可以复用到自己项目里的执行思路。