在2025年，国内有两个标志性事件，第一是DeepSeek的发布，正式标志我们迈入L2大门，而随后的Manus发布，预示着我们进入了L2.5时代：
这里的L1到L5，就是OpenAI的山姆奥特曼对AI应用的发展预测，并且他认为10年左右就会实现：
这条路线属于模型吃掉所有的路线，按照这个逻辑基模会成最大受益者，必定流量全部都集中了，只不过事实上的发展不是那么回事。
unsetunsetAI发展史unsetunset
上述的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的基础架构上做判断...
unsetunset从基础架构看AI机会unsetunset
Agent框架的技术框架：
大模型解决规划与调度问题，Manus能爆发的核心原因就是模型能力大幅增强； RAG解决幻觉问题，当前模型的发展趋势来说，模型上下文破百万是早晚的事，如何让模型聊得像人，体验好的AI分身这类应用，将在这两年诞生； 工具链解决多模态问题，包括最近很火的MCP、Computer Use其实都算是AI多模态能力的延伸，要的就是解决AI各种“不行”的问题，这里包括了听觉、视觉、触觉等；
从基础架构出发，这块一个基础能力清单红线也就出来了，比如：多模态相关的东西做不得！
包括，语音相关、视频相关、什么图生文、文生图，视频语音什么的，接下来要死一大半，一般公司千万不要涉足。
另一方面，记忆模块暂时用的是RAG技术，但我这个东西未来应该会有不小迭代，模型可能会留出合适的接口，让我们可以更好的注入领域知识，但这里的数据安全也是不小的问题...
然后在模型上下文持续增加（模型上下文>10w）的情况下，向量库什么的，我认为在接下来几年会成为历史。
好消息是模型幻觉是难以解决的，所以大家不必担心公司最后的数据壁垒，如OpenAI最近的论文《Why Language Models Hallucinate》所述：
幻觉不是神秘缺陷，而是训练/评测激励奖励猜测、惩罚不确定的统计后果。
降低幻觉，要在评测中对自信错误重罚、对合理不确定给部分分，并允许模型在不确定时弃答/求澄清；
RAG可缓解事实性错误，但若激励不改，猜测仍会发生
再看如今常见的智能体，又可以分为两类：通用型智能体、垂直行业智能体。
对通用型智能体来说，其核心是工具生态，生态越繁荣越容易脱颖而出； 而对于垂直行业智能体来说，私有语料、垂直领域插件越多，其使用上越友好。
以Manus类产品为例，他其实是没有什么技术门槛的，国内有很多类似的产品，其实现周期在一个月左右，当然要打磨得好，也要花不少时间的。
这里大家还不要不信，为让大家更清楚Agent架构，我们用傻瓜工具Coze来简单实现下“Manus”，让大家对Agent架构的工作量在哪有个更系统的认识。
unsetunsetManus原理简析unsetunset
在开始实现之前说一下Multi Agent System：
Agent的最佳实践遵循单一职责，所谓多智能体就是：工作由几个Agent就能完成，至于怎么调用，需要大模型去做详细规划调度，而Manus本质上是一个MAS系统。
照虎画猫
举个例子：打开Manus，让他给我做个贪吃蛇，很快就完成了：
这里用到的工具有：
读写文件的能力； 操作浏览器的能力（搜索网页和模拟点击、键盘事件等）； 代码编写的能力（纠偏的能力）； 执行系统命令的能力； 代码部署和预览能力； ...
所有这操作，都在一台云主机上完成，并且实时回传了运行进展。其大概架构是这样的（PS：真实场景在规划和记忆一块会复杂巨多，我们这里只做简单猜想）：
下面我们具体展开说明：
一、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
拿到了规划的清单之后，就会进入到一个事件循环当中，不断的执行清单上面的任务，直到所有任务完成：
Think模块会根据当前的执行情况，决定下一步的行动任务，如果任务偏离主目标太多的话，也可以推翻当前任务重新调整任务清单；
Excute模块会按照当前任务调用各种Agent完成具体的任务，每个Agent都配置了各自的技能（比如各种工具）；
Observe模块会评估当前任务的执行情况，更新任务执行的具体情况。
当清单中已经没有待办的任务时，就会跳出循环。
三、Computer Use
云端主机负责执行具体的任务，提供任务的执行环境，并负责实时上报日志。
云主机上面为了达到ComputerUse的效果，会开放很多的能力，这些能力也就是我们所说的Tools：
四、其他
任务执行完成后，Report模块会分析执行的过程数据，并生成最终总结数据。也有很多其他模块，这里不展开。接下来我们做具体的Coze实现：
unsetunsetCoze实现“Manus”unsetunset
具体到实现这里，我们会怎么简单怎么来：
Service端：Manus用的是Ubuntu的虚拟机，我们直接用Linux的云服务器； Client端： 用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...
到这里基本功能完成，大家可以看到最终效果了：
unsetunset结语unsetunset
通过上述案例，可能有两点重要启示：
第一，貌似简单实现一个“Manus”成本并不高，但想要他表现得很好，做好各种意图识别，又是一件很难的事情，初期的关键是丰富的Tools，紧接着是各种领域知识（SOP+数据）的注入； 第二，初期实现依赖Computer Use，后续可能AI Code会是一个巨大的核心，这可能也是很多巨头公司或者基座模型一直在重点关注AI编程的原因；
Manus类产品很难
大家可以看出，上述所谓成本并不高其实是相对的，因为做出来的是个demo，如果你的“Manus”想要真正被用户接受、解决实际的工作问题，那么就复杂了，马上就涉及到了各种深水区：
精准的意图识别：用户的需求是莫名其妙的。智能体必须理解用户的“言外之意”，这是用户体验的一道槛。需要极其精细的提示工程和大量的对话数据进行调优； 强大的工具生态：智能体的能力边界由其能调用的工具决定。一个“Manus”能否真正解决问题，取决于它能否无高效使用各种服务（如订票、查邮件、控智能家居、分析数据等）。自建工具链成本高昂，因此与第三方服务的集成能力至关重要； 深厚的领域知识：在垂直领域，通用知识远远不够。需要将行业的SOP（标准作业程序）、私有的数据库、专家的经验 注入到智能体中。这部分工作是“脏活累活”，没有捷径，但正是构建护城河的关键；
这也是为什么红杉这么推崇OpenEvidence的原因：
AI应用的竞争已经从技术能力的竞争，转向了产品定义、用户体验打磨、生态整合与垂直行业知识深度的竞争，早期的红利属于在垂直领域做得无比深入的团队。
AI Code 是未来
从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开发工具，将自己的行业知识转化为产品力，深耕下去，成为某个小领域的不可或缺。
综上，是个人一些片面认知，希望对各位有用...
