用Coze+Claude实现Manus，Agent的难点到底在哪？

2025年，国内AI领域接连迎来两个标志性事件：DeepSeek的发布正式宣告我们迈入L2大门，随后Manus的发布又将行业推向了L2.5时代。从L1到L5的演进路线，源于山姆·奥特曼对AI应用发展的预测，在他看来，这一进程大约十年就能实现。

这条路线本质上属于

的逻辑——基座模型会成为最大受益者，流量最终会高度集中。但实际发展的走向，并没有完全按照这个剧本走。

AI发展史

L4、L5离我们还太远，单看L1到L3的描述也容易觉得抽象，得放进具体的时间线里才能看清全貌：

2022年底ChatGPT（3.5）发布，标志我们进入L1时代。没过多久GPT-4也来了。

站在那个时间节点来看，当时AI应用面临的最大问题其实

，而是——想拿到OpenAI的账号都难如登天。微软云Azure的GPT账号，溢价100%都未必拿得到。模型推理响应速度更是慢到令人发指，一次来回快则20秒，慢则一分钟。所以

那也是

的开端。主流技术路线是先预训练再微调，烧钱烧得厉害。国内走在前面的是百度、智谱、通义千问、讯飞、百川智能等，但彼此之间并没有拉开明显差距，实际水平也不比开源模型LLaMA和Bloom高出多少。

这个阶段，AI应用进入生产环境还不成熟，但前期的研发投入已经很扎实了。尤其在那些不太在乎资费和响应时间的2B场景里，早入局的人已经尝到了甜头。卖铲子的、卖研发工具的，包括用Coze教普通人搭AI应用的、做数据生产和数据标注的公司，都赚了不少。

芯片行业遵循摩尔定律，而AI的火热又让大规模资金疯狂涌入，结果就是每半年模型响应速度翻倍、成本降一半。到去年年底，

1. ChatGPT的响应速度已经很快，基本5秒内能搞定；
2. 智谱的推理能力和响应速度大幅提升，阿里的Qwen模型也进步明显。

当然，国内最具标志性的AI事件还是DeepSeek的发布。无论是它率先暴露的思维链CoT，还是专家模型等创新设计，都让人眼前一亮。这标志着我们正式进入了L2阶段。

到了2025年，模型基础的推理能力、响应速度、资费全部达到了生产环境的水准。业内之所以称2025为国内AI应用元年，底气就在这里。

环境到位了，各种AI应用自然会爆发。紧接着另一个标志性事件就来了：

Manus本身的技术难度或许没有想象中那么高，但它率先提出了一种AI时代应有的智能体产品体验。随后，各浏览器厂商也在往这个方向靠拢，的思路开始扩散。

但Manus类产品在实际使用中问题也不少。基础模型能力是够了，配套的设施却没跟上，导致总让人感觉差那么一口气。

后续红杉AI峰会也同步指出：第一批智能体的机会在垂直领域。果不其然，设计师的智能体、程序员的智能体在今年取得了长足进步。

等产品已经在实际影响我们的工作方式了。

今年Google I/O大会展露了很多智能体趋势，尤其是图像/视频体系Flow + Veo3 + Imagen3的套餐值得关注。近期发布的Nano Banana更是火得不行，文生图的应用近在眼前。

AI如火如荼地发展，但问题也来了：

要回答这个问题，可能得从Agent的基础架构开始分析。

从基础架构看AI机会

Agent框架的技术架构可以拆成三块：

1. 大模型解决规划与调度问题
   ——Manus能爆发的核心原因就是模型能力大幅增强；

2. RAG解决幻觉问题
   ——模型上下文破百万是早晚的事，如何让模型聊得像人、体验好的AI分身这类应用，将在未来两年诞生；

3. 工具链解决多模态问题
   ——包括最近很火的MCP、Computer Use，都算是AI多模态能力的延伸，目的就是解决AI各种“不行”的问题，覆盖听觉、视觉、触觉等。

从基础架构出发，一条能力清单的红线也就划出来了：

_{包括语音、视频、图生文、文生图、视频语音等，接下来会死一大半，一般公司千万不要涉足。}

另一方面，记忆模块目前用的是RAG技术，但这个方向未来应该会有不小的迭代。模型可能会留出合适的接口，方便注入领域知识，

在模型上下文持续增加（超过10w）的情况下，向量库这个技术栈，未来几年大概率会成为历史。

好消息是

，所以不必担心公司最后的数据壁垒被完全打破。OpenAI最近那篇论文《Why Language Models Hallucinate》点明了本质：

_{幻觉不是神秘缺陷，而是训练/评测激励奖励猜测、惩罚不确定的统计后果。降低幻觉，要在评测中对自信错误重罚、对合理不确定给部分分，并允许模型在不确定时弃答或求澄清。RAG可缓解事实性错误，但若激励不改，猜测仍会发生。}

再看当下常见的智能体，可以分为两类：

和。

通用型智能体的核心在于工具生态，生态越繁荣，越容易脱颖而出；垂直行业智能体则依赖私有语料和垂直领域插件，积累越深厚，使用体验越友好。

以Manus类产品为例，其实没有什么高不可攀的技术门槛。国内类似的产品不少，实现周期大概在一个月左右，当然要打磨得好，也得花不少时间。

光说可能不够直观，接下来用傻瓜工具Coze来简单实现一个“Manus”，让大家对Agent架构的工作量在哪里有个更系统的认识。

Manus原理简析

在动手之前，先聊聊

：

Agent的最佳实践遵循单一职责原则。所谓多智能体，就是一个任务由几个Agent协作完成，至于怎么调用，需要大模型做详细的规划调度。

照虎画猫

举个例子：打开Manus，让它做个贪吃蛇小游戏，很快就完成了：

这里用到的工具包括：

1. 读写文件的能力；
2. 操作浏览器的能力（搜索网页、模拟点击、键盘事件等）；
3. 代码编写的能力（含纠偏）；
4. 执行系统命令的能力；
5. 代码部署和预览能力；
6. ……

所有这些操作，都在一台云主机上完成，并实时回传运行进展。其

架构如下（说明：真实场景中，规划和记忆部分会复杂得多，这里只做简单猜想）：

一、Planning模块

规划模块的职责是：识别用户意图，把任务拆解成若干可以原子化执行的子任务，并写入Todo.md。比如：

# 用户问题
帮我做一个贪吃蛇的小游戏

# Todo.md
# 贪吃蛇游戏开发进度
## 第一阶段：设计游戏架构和界面
- [ ] 创建项目目录结构
- [ ] 设计游戏界面布局
...
## 第二阶段：实现游戏核心逻辑
- [ ] 实现蛇的移动逻辑
- [ ] 实现食物生成和碰撞检测
...
## 第三阶段：测试和优化游戏
- [ ] 本地测试游戏功能
- [ ] 优化游戏性能
...
## 第四阶段：部署游戏并交付给用户
- [ ] 部署到公网
- [ ] 向用户交付最终产品

规划结束后，后续的所有执行都会围绕清单展开。OpenManus关于规划模块的提示词是这样的：

planner_module
- 系统配备规划器模块，用于整体任务规划
- 任务规划将以事件流中的事件形式提供
- 任务计划使用编号的伪代码表示执行步骤
- 每次计划更新都包含当前步骤编号、状态和反思
- 表示执行步骤的伪代码将在整体任务目标发生变化时更新
- 必须完成所有计划步骤，并在完成时达到最终步骤编号

# todo rules
- 根据 Planner 模块中的任务规划，创建 todo.md 文件作为清单
- 任务规划优先于 todo.md，而 todo.md 包含更多详细信息
- 完成每项任务后，立即使用文本替换工具更新 todo.md 中的标记
- 当任务规划发生重大变化时，重建 todo.md
- 必须使用 todo.md 记录和更新信息收集任务的进度
- 所有计划步骤完成后，验证 todo.md 的完成情况并删除跳过的任务

二、Agent Loop

拿到规划清单后，就进入一个事件循环，不断执行清单上的任务，直到全部完成：

根据当前执行情况，决定下一步行动。如果任务偏离主目标太多，可以推翻当前任务，重新调整清单。

按照当前任务调用各种Agent完成具体工作，每个Agent都配置了各自的技能（如各类工具）。

评估当前任务的执行情况，更新任务进度。

当清单中没有待办任务时，循环终止。

三、Computer Use

云端主机负责执行具体任务，提供执行环境，并实时上报日志。云主机上为了达到Computer Use的效果，会开放大量能力，也就是我们所说的Tools：

四、其他

任务执行完成后，Report模块会分析过程数据，生成最终总结。还有其他模块，这里不展开。接下来直接做Coze实现。

Coze实现“Manus”

实现上能简化就简化：

1. Service端：
   Manus用的是Ubuntu虚拟机，我们直接用Linux云服务器；

2. Client端：
   用Coze搭建，实现规划、思考、执行、观察、汇总等模块。

Service端与Client端通过异步通信协议连通。具体细节不展开，这里直接给出Coze的实现：

接下来说说重点：

一、规划模块

整体功能上，最重要的是设计好todoList的数据结构。参照OpenManus的提示词，可以设计出类似右边的数据结构：

在Coze里，一个大模型模块就搞定了。

二、执行模块

执行模块需要实现一套大模型自主调用智能体的流程。在Coze里，直接用系统提示词实现Function Calling调用远程工具即可。大致流程如下：

通信协议设计如下：

通过这个能力，系统就具备了自主判断和调用工具的能力。Coze实现如下：

三、观察模块

观察模块同样通过一个大模型节点搞定。提示词如下：

# 角色
执行效果评估助手
# 任务
1. 根据当前的上下文中的任务状态字段，判断是否存在执行失败和待执行的任务。
2. 不要解释，也不要额外输出其他内容。
3. 保持上下文格式和内容的完整性
4. 上下文中不包括历史记录数据
5. 上下文需要时一个合法的JSON
if (存在执行失败的任务) {
- 面向最终目标，更新任务列表和当前任务。
- 之前已经执行成功的任务保持不变
} elseif (存在待执行的任务) {
- 更新当前任务为下一个待执行的任务。
} else {
- 原样输出上下文
}
# 上下文
{{context}}
# 历史记录
{{histroy}}
# 输出要求
status的值：
所有任务都执行完毕=complete
存在执行失败的任务=retry
存在待执行的任务=next

四、服务端设计

服务端可以用Cursor或

实现一个简单的Service服务器，核心实现/Execute和/Log两个接口即可。

其中/Execute接口需要能调用服务器上的智能体，接收智能体的流日志并写入日志文件。智能体可以使用任意大模型，如果需要写代码，最好选择代码模型（Claude系列、Kimi K2等），再配套各种MCP工具即可。

MCP工具的具体使用可以直接查看相关文档，这里不再展开。

到这里基本功能就完成了，可以看到最终效果：

结语

通过上述案例，可以得出两个重要启示：

1. 第一，

   简单实现一个“Manus”成本并不高
   ，但想要它表现得好，做好各种意图识别，又是另一件极难的事。初期的关键是丰富的Tools，接着是各种领域知识（SOP+数据）的注入；
2. 第二，初期实现依赖Computer Use，后续AI Code可能成为巨大的核心。很多巨头公司和基座模型一直在

   重点关注AI编程
   ，原因就在这里。

Manus类产品很难

所谓

其实是相对的，因为做出来的只是个demo。如果你的“Manus”想要真正被用户接受、解决实际工作问题，那就复杂了，会马上涉及各种深水区：

1. 精准的意图识别：
   用户的需求千奇百怪，智能体必须理解“言外之意”，这是用户体验的第一道门槛。需要极其

   精细的提示工程
   和大量对话数据调优；

2. 强大的工具生态：
   智能体的能力边界由它能调用的工具决定。一个“Manus”能否真正解决问题，取决于它能否高效使用各种服务——订票、查邮件、控智能家居、分析数据等。自建工具链成本高昂，与第三方服务的集成能力至关重要；

3. 深厚的领域知识：
   在垂直领域，通用知识远远不够。需要将行业的SOP、私有数据库、专家经验注入智能体。这部分工作是“脏活累活”，没有捷径，但正是构建护城河的关键。

这也是红杉如此推崇OpenEvidence的原因：AI应用的竞争已经从技术能力的竞争，转向产品定义、用户体验打磨、生态整合与垂直行业知识深度的竞争。

AI Code是未来

从Manus此前的实现来看，Computer Use在其中扮演了重要角色，但这可能是

——因为很多网站并不提供API。理想情况是让Agent调用受控、可测、可审计的函数（MCP），Computer Use作为兜底能力。

在简单实现中并没有使用Computer Use，一来场景足够单一，二来也是为了验证AI Code这条路（Claude）是否走得通。

可以想象一下，当AI编程再强大一点、理解能力再强一点，整个Agent架构可能就闭环了：

这也是为什么很多巨头都在关注这个方向——掌控了AI编程能力，就掌控了智能体能力扩展的“开关”。这不再只是做一个应用，而是在打造一个能够生长应用的平台。这符合OpenAI、Google等巨头“模型吃掉一切”的终极路线图，只不过

，还有很长的路要走。

所以，接下来对AI应用做规划时，视野需要从基础工具的实现转向创意与应用。基础工具层面，模型厂商不提供，大厂也会补足。比如AI知识库这块，腾讯的IMA、飞书的知识问答系统已经慢慢走向成熟。

对小团队来说，当下的最佳策略是避开巨头锋芒——不做平台型工具（如Coze、AI表格、多模态类工具），而是选择一条垂直细分赛道，利用现有的Agent开发工具，将行业知识转化为产品力，深耕下去，成为某个小领域的

。