从零到一：使用Coze与Claude实现ManusAgent的挑战与解决方案
在2025年，国内人工智能领域有两个里程碑式的事件。首先是DeepSeek的发布，这标志着我们正式迈入了L2级别智能体的大门；随后Manus的亮相，则预示着行业开始进入L2.5时代。
这里提到的L1到L5分级，源于OpenAI的山姆·奥特曼对人工智能应用发展路径的预测。他认为，从L1到L5的演进大约会在十年内完成。
这条技术路线本质上是“模型吞噬一切”的路线。按照这个逻辑，基础模型提供商将成为最大的受益者，所有流量都将向其集中。然而，实际的发展轨迹却并非完全如此。
AI发展史：从L1到L2.5的演进之路
上述的L4和L5阶段尚属遥远，仅看L1到L3的文字描述也难以产生直观感受，需要结合更多背景信息来理解。
2022年底，ChatGPT（基于GPT-3.5）的发布标志着我们进入L1时代，不久之后GPT-4也相继问世。
作为这一时期的亲历者，从模型能力的角度来看，当时最大的问题并非上下文长度不足或存在幻觉，而是资源“一票难求”。普通用户很难获得OpenAI的API访问权限，即便是通过微软Azure云服务获取GPT账号，也常常需要付出高达100%的溢价，且往往有价无市。
同时，模型的推理响应速度也极其缓慢。一次完整的交互，快则需20秒，慢则要等待一分钟。因此，整个2023年，人工智能应用实际上并未达到真正可投入生产使用的状态。
那也是“百模大战”的开端。主流的技术路径普遍采用“预训练+微调”的模式，这个过程耗费巨大。国内走在前列的厂商包括百度、智谱AI、通义千问、讯飞以及百川智能等，但它们彼此之间并未拉开显著差距，其实际能力与开源的LLaMA、Bloom等模型相比也优势不大。
在这个阶段，尽管AI应用大规模进入生产环境尚不成熟，但前期研发环境已经相当完善。特别是在一些对企业级客户而言，费用和响应时间并非首要考量的场景中。因此，那些提供基础设施、研发工具的公司获利颇丰，例如教导普通人使用Coze搭建AI应用的培训服务商，以及各类从事数据生产和数据标注的公司。
然而，芯片行业遵循摩尔定律。由于人工智能热潮吸引了大规模资本涌入，直接导致了模型响应速度大约每半年翻倍、使用成本每半年减半的加速发展态势。因此，到去年年底，所有主流模型的能力都实现了质的飞跃：
- 业界标杆ChatGPT的响应速度已经变得非常快，基本可以在5秒内完成交互；
- 智谱AI在推理能力和响应速度上均有大幅提升，阿里的Qwen模型也取得了显著进步。
当然，国内最具标志性的人工智能事件当属DeepSeek的发布。无论是其率先展示的思维链（CoT）技术，还是专家模型等创新设计，都足以让人眼前一亮。这也标志着我们完全进入了L2阶段。
进入2025年，无论是模型的基础推理能力、响应速度还是使用成本，都已达到能够支撑生产应用的水平。因此，业界才将2025年称为“国内AI应用元年”，这个说法正是基于这样的背景。
基础环境就绪后，各类AI应用自然如雨后春笋般涌现。另一个标志性事件随即爆发：Manus发布了。Manus产品的意义不在于其技术难度有多高，而在于它率先提出并实践了一种符合AI时代的智能体产品交互范式。事实上，随后各大浏览器厂商也开始朝这个方向演进，“入口即应用”的思维方式开始普及。
只不过，Manus这类产品在实际使用中仍存在诸多问题。虽然基础模型能力已经足够，但配套的基础设施和工具链尚未完全跟上，这导致其用户体验总感觉“差那么一点意思”。
随后，红杉资本的人工智能峰会也指出，第一批智能体的机会在于垂直领域。果不其然，面向设计师的智能体、面向程序员的智能体在今年取得了长足进步。例如Cursor、Lovart等产品已经切实地改变了部分人群的工作方式。
其次，今年的Google I/O大会展示了众多智能体发展趋势，其中尤其值得关注的是图像/视频生成体系的“Flow + Veo3 + Imagen 4”组合。近期发布的Nano Banana更是火爆异常，文本生成图像的应用似乎近在眼前。
人工智能正在如火如荼地发展，但随之而来的问题是：我们普通人的机会在哪里？我们又需要避免哪些潜在的陷阱？
要回答这个问题，或许需要从智能体的基础架构层面进行审视和判断。
从基础架构视角审视AI领域的机遇
智能体框架的核心技术架构主要包含以下几个方面：
- 大模型负责解决规划与调度问题。Manus能够爆发的核心原因正是模型能力的显著增强。
- RAG（检索增强生成）技术用于缓解幻觉问题。就当前模型发展趋势而言，上下文窗口突破百万级别是迟早的事。如何让模型对话更像真人，以及体验良好的AI数字分身类应用，预计将在未来两年内诞生。
- 工具链旨在解决多模态交互问题。最近颇受关注的MCP（模型上下文协议）、Computer Use等，本质上都是AI多模态能力的延伸，目的是解决AI在各种感官交互（如听觉、视觉、触觉）上的局限性。
从基础架构出发，一条关于基础能力的“红线”也随之清晰：例如，切勿轻易涉足多模态相关领域！
包括语音识别与合成、视频生成、文生图、图生文、视频语音处理等方向，接下来将迎来大规模的行业洗牌，普通公司最好不要轻易涉足。
另一方面，当前的记忆模块主要依赖RAG技术，但未来这一部分可能会有不小的迭代。模型可能会预留更合适的接口，以便我们更高效地注入领域知识。然而，这其中涉及的数据安全问题也不容小觑。
此外，在模型上下文窗口持续扩大（例如超过10万token）的趋势下，传统的向量数据库等技术，可能在未来几年内逐渐退出历史舞台。
一个好消息是，模型的幻觉问题是难以从根本上彻底解决的，因此企业不必过分担心数据壁垒最终会完全消失。正如OpenAI近期发表的论文《Why Language Models Hallucinate》所指出的：
幻觉并非神秘的缺陷，而是训练与评估过程中，奖励“猜测”行为、惩罚“不确定”表达的统计性后果。 降低幻觉，需要在评估中对过于自信的错误答案施加重罚，对合理的不确定性给予部分分数，并允许模型在不确定时选择“弃答”或“请求澄清”。 RAG可以缓解事实性错误，但若底层激励机制不改变，猜测行为仍会发生。
再看如今常见的智能体，大致可以分为两类：通用型智能体和垂直行业智能体。
对于通用型智能体而言，其核心在于工具生态，生态越繁荣，产品越容易脱颖而出。而对于垂直行业智能体来说，私有的领域语料库、垂直领域的专用插件越多，其在实际使用中的友好度和有效性就越高。
以Manus类产品为例，其本身并没有过高的技术壁垒。国内已有不少类似产品，其基本功能的实现周期大约在一个月左右。当然，如果要打磨到体验出色，仍需投入大量时间。
为了让读者更清晰地理解智能体架构，我们接下来将利用Coze这一工具，尝试简单实现一个“类Manus”系统，以便大家对智能体架构的核心工作量分布有一个更系统的认识。
Manus核心原理简要分析
在开始动手实现之前，有必要了解一下 Multi-Agent System（多智能体系统） 的概念。
智能体的最佳实践遵循“单一职责”原则。所谓的多智能体系统，就是指一项工作由多个职责分明的智能体协同完成。至于如何调用这些智能体，则需要大模型进行详细的规划和调度。而Manus在本质上，就是一个多智能体系统。
实例解析：一个贪吃蛇游戏的诞生
举个例子：打开Manus，让它“帮我做一个贪吃蛇游戏”，它很快就能完成任务。
在这个过程中，它可能调用了以下工具能力：
- 文件读写能力；
- 浏览器操作能力（包括网页搜索、模拟点击、键盘事件等）；
- 代码编写与纠错能力；
- 系统命令执行能力；
- 代码部署与预览能力；
- ……
所有这些操作都在一台云主机上完成，并且实时回传了运行进展。其简化版的架构猜想如下（注：真实场景中，规划与记忆模块会复杂得多，此处仅做原理性示意）：
下面我们将对这个架构进行具体展开说明：
一、规划模块
规划模块的核心职责是：识别用户的真实意图，并将宏观任务拆解为一系列可原子化执行的子任务，并写入 Todo.md 这样的清单文件中。例如：
# 用户问题
帮我做一个贪吃蛇的小游戏
# Todo.md
# 贪吃蛇游戏开发进度
## 第一阶段：设计游戏架构和界面
- [ ] 创建项目目录结构
- [ ] 设计游戏界面布局
...
## 第二阶段：实现游戏核心逻辑
- [ ] 实现蛇的移动逻辑
- [ ] 实现食物生成和碰撞检测
...
## 第三阶段：测试和优化游戏
- [ ] 本地测试游戏功能
- [ ] 优化游戏性能
...
## 第四阶段：部署游戏并交付给用户
- [ ] 部署到公网
- [ ] 向用户交付最终产品
规划结束后，后续的所有执行步骤都将围绕这份任务清单展开。参考OpenManus项目，其规划模块的提示词大致设计如下：
planner_module
- 系统配备规划器模块，用于整体任务规划
- 任务规划将以事件流中的事件形式提供
- 任务计划使用编号的伪代码表示执行步骤
- 每次计划更新都包含当前步骤编号、状态和反思
- 表示执行步骤的伪代码将在整体任务目标发生变化时更新
- 必须完成所有计划步骤，并在完成时达到最终步骤编号
# todo rules
- 根据 Planner 模块中的任务规划，创建 todo.md 文件作为清单
- 任务规划优先于 todo.md，而 todo.md 包含更多详细信息
- 完成每项任务后，立即使用文本替换工具更新 todo.md 中的标记
- 当任务规划发生重大变化时，重建 todo.md
- 必须使用 todo.md 记录和更新信息收集任务的进度
- 所有计划步骤完成后，验证 todo.md 的完成情况并删除跳过的任务
二、智能体循环
获得规划清单后，系统会进入一个事件循环，持续执行清单上的任务，直至所有任务完成。
- 思考模块会根据当前的执行进展和上下文，决定下一步要执行的具体任务。如果发现任务执行严重偏离了主目标，它甚至有权推翻当前任务，重新调整任务清单。
- 执行模块会按照当前任务的指示，调用具备相应技能的智能体（每个智能体都配置了不同的工具集）来完成具体操作。
- 观察模块负责评估当前任务的执行结果，并更新任务状态。
当清单中所有待办任务均标记为完成后，系统便会跳出这个循环。
三、计算机使用能力
云端主机负责提供任务执行的具体环境，并执行各类操作指令，同时负责实时上报执行日志。
为了实现“Computer Use”的效果，云主机会开放大量底层能力，这些能力就是我们所说的“工具”。
四、其他模块
任务执行完毕后，报告模块会分析整个执行过程的数据，并生成最终总结。系统中还可能包含许多其他辅助模块，此处不再展开。接下来，我们将进入具体的Coze实现环节。
使用Coze实现“类Manus”系统
在具体实现上，我们将遵循极简原则：
- 服务端： Manus使用的是Ubuntu虚拟机，我们直接用Linux云服务器即可。
- 客户端： 使用Coze平台进行搭建，实现规划、思考、执行、观察、汇总等几个核心模块。
服务端与客户端之间通过异步通信协议进行连接。为避免过于复杂，这里不展开通信细节，直接展示Coze中的实现概览：
接下来阐述几个关键模块的实现重点：
一、规划模块
从整体功能来看，最重要的设计之一是 todoList 的数据结构。参考OpenManus的提示词，可以设计出类似下图的右侧数据结构：
在Coze中，使用一个大模型模块即可实现此规划功能。
二、执行模块
执行模块需要实现一套大模型自主调用智能体工具的流程。在Coze中，可以直接通过系统提示词，利用Function Calling机制来调用远程工具。大致流程如下：
通信协议可以设计如下：
通过这个设计，我们的系统便具备了自主判断需求并调用相应工具的能力。在Coze中的实现如下图所示：
三、观察模块
观察模块同样可以通过一个大模型节点来实现。其提示词可设计如下：
# 角色
执行效果评估助手
# 任务
1. 根据当前的上下文中的任务状态字段，判断是否存在执行失败和待执行的任务。
2. 不要解释，也不要额外输出其他内容。
3. 保持上下文格式和内容的完整性
4. 上下文中不包括历史记录数据
5. 上下文需要时一个合法的JSON
if (存在执行失败的任务) {
- 面向最终目标，更新任务列表和当前任务。
- 之前已经执行成功的任务保持不变
} elseif (存在待执行的任务) {
- 更新当前任务为下一个待执行的任务。
} else {
- 原样输出上下文
}
# 上下文
{{context}}
# 历史记录
{{histroy}}
# 输出要求
status的值：
所有任务都执行完毕=complete
存在执行失败的任务=retry
存在待执行的任务=next
四、服务端设计
服务端可以使用Cursor或者 Claude Code 来实现一个简单的服务端程序，核心是完成 /Excute 和 /Log 这两个接口。
其中，/Excute 接口需要能够调用服务器上的智能体，接收智能体返回的流式日志，并将其写入日志文件。
智能体本身可以选择任意大模型，但如果任务涉及代码编写，最好选择在代码能力上表现突出的模型（如Claude系列、Kimi K2等），并为其配备各种MCP工具。
具体的MCP工具使用方法可以参考相关文档，此处不再赘述，后续或许可以单独探讨MCP的话题。
至此，一个具备基本功能的“类Manus”系统便搭建完成。
结论与启示
通过上述的构建案例，我们或许可以得到两点重要的启示：
- 第一，一个“类Manus”系统的基础实现成本看似不高，但若想让它表现出色，做好各种复杂场景下的意图识别，却是一件极具挑战性的事情。初期的关键是构建丰富的工具生态，紧接着便是注入大量的领域知识（包括标准作业流程SOP和专有数据）。
- 第二，早期的实现高度依赖“Computer Use”能力，但未来“AI编程”可能会成为更核心的驱动力。这也解释了为何许多巨头公司或基础模型提供商一直在重点关注AI编程领域。
Manus类产品面临的深层挑战
大家可以看出，上述所谓“成本不高”是相对而言的，因为构建出的只是一个演示原型。如果你的“Manus”想要真正被用户接纳、并解决实际工作问题，那么复杂性将急剧上升，立刻就会触及各种“深水区”：
- 精准的意图识别：用户的需求往往是模糊、多变且充满言外之意的。智能体必须能够准确理解用户的潜台词，这是提升用户体验的第一道门槛。这需要极其精细的提示工程和海量的对话数据来进行持续调优。
- 强大的工具生态：智能体的能力边界完全取决于其能调用的工具。一个“Manus”能否真正解决问题，取决于它能否无缝、高效地使用各种外部服务（如预订票务、查询邮件、控制智能家居、分析数据等）。自建全套工具链成本极高，因此，与第三方服务的集成能力变得至关重要。
- 深厚的领域知识：在垂直行业应用中，通用知识远远不够。需要将行业的SOP、私有的数据库、专家的经验诀窍（Know-how）深度注入到智能体中。这部分工作是实打实的“脏活累活”，没有捷径可走，但正是构建产品护城河和竞争优势的关键所在。
这也是为什么像红杉这样的顶尖投资机构如此推崇在垂直领域深挖的原因。
AI应用的竞争重点，已逐渐从单纯的技术能力比拼，转向产品定义、用户体验打磨、生态整合与垂直行业知识深度的综合竞争。早期的市场红利，将属于那些在特定垂直领域做得无比深入、构建了坚实壁垒的团队。
AI编程：通向未来的关键路径
从Manus之前的实现方式来看，“Computer Use”在其中扮演了重要角色，但这可能是一种无奈之举，因为许多网站和系统并未提供标准的API接口。
理想的情况是让智能体主要调用受控、可测试、可审计的函数（如通过MCP协议），而将“Computer Use”仅作为最后的兜底能力。
值得注意的是，在我们刚才的简单实现中，并没有使用“Computer Use”。一方面是因为演示场景足够单一，另一方面也是想尝试验证“AI编程”这条路径（例如利用Claude的代码能力）的可行性。
大家可以想象一下，当AI编程的能力再强大一些、对复杂需求的理解再深入一些，整个智能体的架构就可能形成完美的闭环：人工智能发展的终极趋势——自我进化，似乎也并非天方夜谭，说白了也不过是AI为自己编写新的工具并调试优化。
这也是为什么众多科技巨头都在密切关注这一领域。谁掌控了强大的AI编程能力，谁就掌控了智能体能力无限扩展的“总开关”。这不再是简单地做一个应用，而是在打造一个能够自主生长、持续进化的应用生态平台。
这符合OpenAI、Google等巨头所描绘的“模型吞噬一切”的终极路线图。只不过，这条道路上的安全性挑战和工程实现难度极高，我们仍有很长的路要走。
因此，接下来我们在规划AI应用时，需要更多地从基础工具实现的视角，转向创意发掘与应用场景落地的视野。在基础工具层面，即使模型厂商不直接提供，也会有大型科技公司（如腾讯的IMA、飞书的知识问答系统）来补足生态。
对于中小型团队或个人开发者而言，当下的最佳策略或许是避开与巨头的正面竞争（例如平台型工具如Coze、AI表格或多模态工具），转而选择一条垂直细分赛道。利用现有的智能体开发工具，将自身独有的行业知识和经验转化为产品竞争力，并在此领域持续深耕，努力成为某个细分场景中不可或缺的解决方案提供者。
以上，是一些个人的观察与思考，希望能为各位带来一些启发。