我对扣子空间与Manus的产品的思考

软件工程师罗小东，拥有多年架构和平台设计经验，目前专注于平台与新技术的融合研究。

背景

针对于刚出的扣子空间临时整理的笔记，同样，此只针对于AIP多Agent平台的升级阐述，临时笔记，略有口语化。

前期一篇手稿《我对多Agent平台的进一步升级和落地范式》刚出了一版本范式论，如果说Manus是一个引子（还不成熟），但是扣子空间的出现，将多Agent协作的思路做好了定调方向，明确了多Agent协作的未来方向和决心，还有形态体现，在目前看极有可能（只是有可能）是Agent的未来2-4年形态。

概述

所设的加速，就是不用再过于探索性的设计预研，产品形态思考，还有技术预研等，针对于AIP来说，设计部分是最耗时的部分，下面是2年前的整体架构设计：

明显，到现在25年的今天，这个架构在一定的程度上，会有一些落后，以前是单Agent的架构，现在需要调整成多Agent协作的架构。

需要比较明确的行业发展路线做为引导，建设提升以下内容：

• 产品形态：明确产品输入到输出结果交互形态的设计

• 工具包：工具包的抽取或者规范及与大模型的结合（MCP）

• 数据资产：行业Agent或者通用Agent与数据资产与

  
  

技术方案和技术路线也是比较明确，这也是原来的定位，简单而且容易结合本身业务，结合企业级场景，小型而且可以私有。

每个设计师都有自己的看法和思路，我有我思。

明确内容

确定好思路和方向，很快就会提升出可用落地的产品的形态和进行投入场景使用优化。

产品形态

场景需要闭环，任务场景的闭环形态是输入和输出的目标和结果，比如写文档场景，写爱情小说是目标，输出小说则是结果，这个形成闭环，而发布小说，则是另一个场景，由此来进一进的落地一个个场景。

多Agent智能体结合与不同行业Agent结合形态，在进入场景时，针对于不同的场景选择不同的Agent智能体，以解决通用Agent和业务Agent的区别。

场景交互形态以规划、执行、实时输出，结果整合，最终形态为路线，形成场景处理思路，此处确实是参考了Manus的交互设计，以下为两个示例，右边的实时的Agent执行输出。

多Agent数据分析的示例：

多Agent文档审核的示例：

以上为多Agent协作产品形态的体现，此形态后期还有很大的优化空间，路径也比较明确，当前会考虑先落地为主。

工具包结合

工具包是前期做Agent的痛点，也是开发的痛点，通过API调用解决了一部分问题，原来的接口架构也已经处理好了，之前的定位是在数据资产模块提供接口能力，但是始终觉得并不是最优解。

而MCP的出现貌似可以解决这个问题，但是不确定性还有技术框架的成熟等，还需要再等待，是否能成为行业规范，也有一定的观望态度，而目前在多个大厂的推广和使用形态下，明确定了MCP的结合思路，但是要需要服务，而client框架要自定义结合的方式，以解决智能体平台和工具平台分离的问题，还有规范问题，具体MCP的实现只是另一个方式。

工具的结合很快就可以将前期Agent和使用各方工具包的统一形成标准（需要的就是这个标准规范），可以更明确工程关系还有总体设计，也有利于市场推广，预计会在2个月左右完成MCP服务的搭建和适配。

数据资产结合

通过智能体和行业专家型智能体的区分，是否有价值性，在模型能力都差不多的情况下，通用的结果会出现可看而不能可用，

或者说针对于行业业务，或者本身业务来说关联不大，这里主要是结果直接交付型方向。

数据资产与Agent落地的结合如下:

• 通用Agent智能体: 这些是看得到的或者是常用的逻辑思维，比如目前的大模型就具备。

• 业务Agent智能体： 这个是针对于业务性的，大到公司多年数据，小到一张表，或者一张Excel数据。

  
  

当中会包含数据标注，评分，采集，清理，输出，训练等等过程，当前的目标性是给Agent场景，比如报表会有数据分析Agent输出，工作周日报会从工作Agent输出，这些会形成新的交互形态，还有输出形态，形成明确规范（需要的也是这个规范），从而形成工程化和系统化。

总结

以上为学习和研究大模型的应用场景和设计的一些心得思路参考，精力和思路有限，也期望有兴趣的同学可以互相交流。

参考

• Manus

• 扣子空间

• AI小镇