Manus 的出现，标志着我们进入了 AI 应用的 L2.5 阶段，也让“入口即应用”的产品形态成为可能。但真正落地一个 Agent，难点远不止模型能力——从规划、执行、观察到工具调用，每一个环节都藏着坑。本文通过 Coze + Claude 的实战组合，拆解 Manus 的核心架构，带你看清 Agent 的底层逻辑、技术挑战与未来演进方向。
在2025年，国内有两个标志性事件，第一是DeepSeek的发布，正式标志我们迈入L2大门，而随后的Manus发布，预示着我们进入了L2.5时代：
这里的L1到L5，就是OpenAI的山姆奥特曼对AI应用的发展预测，并且他认为10年左右就会实现：
这条路线属于模型吃掉所有的路线，按照这个逻辑基模会成最大受益者，必定流量全部都集中了，只不过事实上的发展不是那么回事。
上述的L4、L5还太遥远，L1-L3光看描述看不出感觉，需要结合更多信息去阅读：
22年年底ChatGPT（3.5）发布，标志我们进入L1时代，没过多久4.0也发布了。
作为这一时期AI应用经历者，从模型能力上来说，最大问题都不是上下文太短与幻觉问题，而是一票难求，你根本拿不到OpenAI的账号，当时要拿到微软云Azure的GPT账号，需要甚至溢价100%都拿不到！
这里模型推理响应速度也慢到爆，一次来回快的话20秒，慢的话得一分钟，所以整个23年AI没达到可用状态。
当时也是百模大战的开端，主流技术路径，都是先预训练再微调，这一过程非常花钱。国内走在前列的有：百度、智谱、通意千问，讯飞甚至百川智能等，只不过都没拉开身位，他们的实际水平也不比开源模型LLama与Bloom。
在这个阶段，AI应用进入生产环境尚不成熟，但前期进入研发却已经很成熟了，特别在有些2B使用场景不太关注资费和响应时间。所以这个阶段卖铲子、卖研发工具的公司赚了不少钱，包括用Coze教普通人搭建AI应用、各种做数据生产和数据标注的公司。
但整个芯片行业是要遵循摩尔定律的，而由于AI的火热大规模的资金涌入，直接导致了每半年模型的响应速度就翻倍、费用下降一半，所以到去年年底，所有常见模型能力都有了质的飞跃：老大哥ChatGPT响应速度已经很快的，基本可以在5秒左右结束；智谱无论从推理能力还是响应速度也有大幅的提升，包括阿里的Qwen模型也进步明显；
当然，国内最具标志性AI事件还是DeepSeek发布，无论是其首先暴露的思维链CoT，还是专家模型等的创新设计，都足够让人眼前一亮，而这也标志着我们完全进入了L2的阶段。
在25年，无论是模型基础的推理能力，还是响应速度还是资费，全部已经达到生产环境的水准，所以业内才称2025是国内AI应用元年，这个元年是这么来的。
环境OK了各种AI应用自然而然就爆发了，另一个标AI志性事件马上爆发：Manus发布了，Manus这个东西倒不是说他有多难，但他首先提出了一种AI时代应该有的智能体产品体验，事实上接下来各个浏览器厂商也在往这个方向发展了，入口即应用的思维开始扩展。
只不过Manus类产品实际使用起来问题还很多，基本模型能力倒是够了，但配套设施又没有跟上，这就导致了其看起来总是差点意思。
后续，红杉AI峰会也同步指出，第一批智能体的机会在垂直领域，果不其然设计师的智能体、程序员的智能体在今年取得了长足的进步，比如Cursor、Lovart等产品已经实际影响我们的工作方式了。
其次就是今年Google I/O大会，展示了很多智能体趋势，其中尤以图像/视频体系Flow + Veo3 + imagen4套餐值得关注，而近期发布的Nano Banana更是火得不行，文生图的应用近在眼前…
AI如火如荼的发展，但这里问题也就来了，我们这些普通人的机会在哪？我们需要避免的坑点又在哪里？
要回答这个问题，可能得从Agent的基础架构上做判断…
Agent框架的技术框架：
从基础架构出发，这块一个基础能力清单红线也就出来了，比如：多模态相关的东西做不得！
包括，语音相关、视频相关、什么图生文、文生图，视频语音什么的，接下来要死一大半，一般公司千万不要涉足。
另一方面，记忆模块暂时用的是RAG技术，但我这个东西未来应该会有不小迭代，模型可能会留出合适的接口，让我们可以更好的注入领域知识，但这里的数据安全也是不小的问题…
然后在模型上下文持续增加（模型上下文>10w）的情况下，向量库什么的，我认为在接下来几年会成为历史。
好消息是模型幻觉是难以解决的，所以大家不必担心公司最后的数据壁垒，如OpenAI最近的论文《Why Language Models Hallucinate》所述：
幻觉不是神秘缺陷，而是训练/评测激励奖励猜测、惩罚不确定的统计后果。
降低幻觉，要在评测中对自信错误重罚、对合理不确定给部分分，并允许模型在不确定时弃答/求澄清；
RAG可缓解事实性错误，但若激励不改，猜测仍会发生
再看如今常见的智能体，又可以分为两类：通用型智能体、垂直行业智能体。
对通用型智能体来说，其核心是工具生态，生态越繁荣越容易脱颖而出； 而对于垂直行业智能体来说，私有语料、垂直领域插件越多，其使用上越友好。
以Manus类产品为例，他其实是没有什么技术门槛的，国内有很多类似的产品，其实现周期在一个月左右，当然要打磨得好，也要花不少时间的。
这里大家还不要不信，为让大家更清楚Agent架构，我们用傻瓜工具Coze来简单实现下“Manus”，让大家对Agent架构的工作量在哪有个更系统的认识。
在开始实现之前说一下Multi Agent System：
Agent的最佳实践遵循单一职责，所谓多智能体就是：工作由几个Agent就能完成，至于怎么调用，需要大模型去做详细规划调度，而Manus本质上是一个MAS系统。
举个例子：打开Manus，让他给我做个贪吃蛇，很快就完成了：
这里用到的工具有：
所有这操作，都在一台云主机上完成，并且实时回传了运行进展。
其大概架构是这样的（PS：真实场景在规划和记忆一块会复杂巨多，我们这里只做简单猜想）：
下面我们具体展开说明：
规划模块的职责是：识别用户意图，并把任务拆解成若干个可以原子化执行的子任务，并写入Todo.md中。比如：
# 用户问题
帮我做一个贪吃蛇的小游戏
# Todo.md
# 贪吃蛇游戏开发进度
## 第一阶段：设计游戏架构和界面
– [ ] 创建项目目录结构
– [ ] 设计游戏界面布局…
## 第二阶段：实现游戏核心逻辑
– [ ] 实现蛇的移动逻辑
– [ ] 实现食物生成和碰撞检测…
## 第三阶段：测试和优化游戏
– [ ] 本地测试游戏功能
– [ ] 优化游戏性能…
## 第四阶段：部署游戏并交付给用户
– [ ] 部署到公网
– [ ] 向用户交付最终产品
规划结束后，后续的所有执行，都会围绕着清单进行执行。OpenManus关于规划模块的提示词是这样的：
planner_module
– 系统配备规划器模块，用于整体任务规划
– 任务规划将以事件流中的事件形式提供
– 任务计划使用编号的伪代码表示执行步骤
– 每次计划更新都包含当前步骤编号、状态和反思
– 表示执行步骤的伪代码将在整体任务目标发生变化时更新
– 必须完成所有计划步骤，并在完成时达到最终步骤编号
# todo rules
– 根据 Planner 模块中的任务规划，创建 todo.md 文件作为清单
– 任务规划优先于 todo.md，而 todo.md 包含更多详细信息
– 完成每项任务后，立即使用文本替换工具更新 todo.md 中的标记
– 当任务规划发生重大变化时，重建 todo.md
– 必须使用 todo.md 记录和更新信息收集任务的进度
– 所有计划步骤完成后，验证 todo.md 的完成情况并删除跳过的任务
拿到了规划的清单之后，就会进入到一个事件循环当中，不断的执行清单上面的任务，直到所有任务完成：
Think模块会根据当前的执行情况，决定下一步的行动任务，如果任务偏离主目标太多的话，也可以推翻当前任务重新调整任务清单；
Excute模块会按照当前任务调用各种Agent完成具体的任务，每个Agent都配置了各自的技能（比如各种工具）；
Observe模块会评估当前任务的执行情况，更新任务执行的具体情况。
当清单中已经没有待办的任务时，就会跳出循环。
云端主机负责执行具体的任务，提供任务的执行环境，并负责实时上报日志。
云主机上面为了达到ComputerUse的效果，会开放很多的能力，这些能力也就是我们所说的Tools：
任务执行完成后，Report模块会分析执行的过程数据，并生成最终总结数据。也有很多其他模块，这里不展开。
接下来我们做具体的Coze实现：
具体到实现这里，我们会怎么简单怎么来：
Service端跟Client端通过异步通信协议实现连通。具体细节不多展开，不然很多同学看不懂，这里直接给出Coze的实现：
接下来说说重点：
整体功能来说，最重要的还是要设计一下todoList的数据结构，根据OpenManus的提示词，可以设计出类似右边的数据结构：
Coze的话，一个大模型模块就搞定了。
执行模块需要实现的是一套大模型自主调用智能体的流程，Coze的话，直接使用系统提示词实现FunctionCalling调用远程工具即可。大致的流程如下：
通信协议设计如下：
通过这个能力，咱们的系统就具备了自主判断和调用工具的能力。Coze实现如下：
观察模块也是通过一个大模型节点就可以搞定。提示词如下：
# 角色执行效果评估助手
# 任务
1. 根据当前的上下文中的任务状态字段，判断是否存在执行失败和待执行的任务。
2. 不要解释，也不要额外输出其他内容。
3. 保持上下文格式和内容的完整性
4. 上下文中不包括历史记录数据
5. 上下文需要时一个合法的JSON
if (存在执行失败的任务) {
– 面向最终目标，更新任务列表和当前任务。
– 之前已经执行成功的任务保持不变
} elseif (存在待执行的任务) {
– 更新当前任务为下一个待执行的任务。
} else {
– 原样输出上下文}
# 上下文{{context}}
# 历史记录{{histroy}}
# 输出要求
status的值：
所有任务都执行完毕=complete
存在执行失败的任务=retry
存在待执行的任务=next
服务端的话，可以使用Cursor或者Claude Code实现一个简单的Service服务器，核心实现/Excute和/Log这两个接口即可。
其中/Excute接口需要能够调用服务器上的智能体，接收智能体的流日志并写入日志文件。
智能体可以使用任意大模型，如果需要大模型写代码的话最好选择代码模型（Claude系列、Kimi K2等），然后配套各种MCP工具即可。
具体的MCP工具的使用可以直接查看相关文档，这里就不再赘述，后续单开一期讲讲MCP…
到这里基本功能完成，大家可以看到最终效果了：
通过上述案例，可能有两点重要启示：
第一，貌似简单实现一个“Manus”成本并不高，但想要他表现得很好，做好各种意图识别，又是一件很难的事情，初期的关键是丰富的Tools，紧接着是各种领域知识（SOP+数据）的注入；
第二，初期实现依赖Computer Use，后续可能AI Code会是一个巨大的核心，这可能也是很多巨头公司或者基座模型一直在重点关注AI编程的原因；
大家可以看出，上述所谓成本并不高其实是相对的，因为做出来的是个demo，如果你的“Manus”想要真正被用户接受、解决实际的工作问题，那么就复杂了，马上就涉及到了各种深水区：
这也是为什么红杉这么推崇OpenEvidence的原因：
AI应用的竞争已经从技术能力的竞争，转向了产品定义、用户体验打磨、生态整合与垂直行业知识深度的竞争，早期的红利属于在垂直领域做得无比深入的团队。
从Manus之前的实现来说，Computer Use在其中扮演了重要的角色，只不过这可能是无奈之举，因为很多网站并不提供API。
理想情况是让 Agent 调用受控、可测、可审计的函数（MCP），Computer Use 作为兜底能力。
而大家也看到了，我们在做简单实现时并没有使用Computer Use，一来是场景足够单一，二来是就是想验证下AI Code 这种方式（Claude）。
大家可以想象下，当AI编程再强大一点、理解能力更强一点，整个Agent架构可能就闭环了：AI发展的终极趋势自我进化，貌似也不是不可能，说白了也不过是AI自己给自己写工具做调试。
这也是为什么很多巨头都在关注这块，掌控了AI编程能力，就掌控了智能体能力扩展的“开关”。这不再是做一个应用，而是在打造一个能够生长应用的平台。
这符合OpenAI、Google等巨头“模型吃掉一切”的终极路线图，只不过这里面的安全性问题和实现难度较高，还有很长的路要走…
所以，接下来我们对AI应用做规划，要更多的从基础工具实现的视野转向创意与应用的视野。基础工具这块模型厂商不提供，大厂也会补足，比如AI知识库这里，腾讯的IMA、飞书的知识问答系统已经慢慢走向成熟了。
对于小团队来说，当下的最佳策略是避开巨头的锋芒（平台型工具如Coze、AI表格或者多模态类工具），而是选择一条垂直细分赛道，利用现有的Agent开发工具，将自己的行业知识转化为产品力，深耕下去，成为某个小领域的不可或缺。
综上，是个人一些片面认知，希望对各位有用…
本文由人人都是产品经理作者【叶小钗】，微信公众号：【叶小钗】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。