跟“聪明人”做“糊涂账”：MoA^2I架构实验追剧系列，二阶段完成了

二阶段工作量属实不小，不过我们要先回顾下最初的理想：

图片

这次AI实验就是在尝试实现这个架构概念图，有了自然语言编程的最大好处就是自己的梦自己圆，自己挖的坑自己跳。

一阶段的工作完成了一个实验性的简单业务系统，有了服务化的传统业务系统，就可以尝试智能化改造了。这个图中其实有几个东西是跟智能化体系是高度相关的，人工智能当然不必说，智能体构件、MCP服务（也就是那个外部生态构件），以及标准化业务构件与他们的关系，简单地说，作为一个服务化架构，这些东西要能够“混排”在一个系统里，这也许不是什么难事儿，但是能说出来跟能做出来还是不一样的。

二阶段的工作的第一步就是构建mcp服务器、mcp服务和ollama集成，这个工作并不难，在Cursor放开月使用次数限制后，这个工作很快也就完成了，mcp服务也搞了一些，主要用在了“AI智能分析”模块中：

这个分析是mcp服务方式调用ollama集成的本地模型完成的，客户名字都是AI在编写数据系统时编造的，如有雷同，纯属巧合。

结合本地模型，做了个AI助手，助手也可以调用MCP服务，至少AI是这么说的，应该也是这么做的，毕竟没有另外写功能：

这一阶段工作结束后，就进入了真正的智能体开发阶段：

单纯做一个跑起来的智能体并不难，智能体控制台里边就可以使用这些智能体：

在运行记录模块，可以到一些运行信息：

让智能体协作也还好，通过AI编程在后端可以解决智能体的集成问题，有个工作流引擎也就可以，最开始做了一个五智能体协作的，但是笔者还是希望能够更像一个智能体平台，所以做了编排功能：

还不够美观，但是可以用用。

智能体协作就像高级RPA，从开始的分析、决策、采购、销售、库存管理五个有分工协作的智能体，延伸到了收款、付款七个，并在收付款上联动银行账户管理，这时需要注意业务规则，尽管这只是实验系统，决策要控制销售不能大过库存，销售订单和明细要一致，按照订单收款，按照明细出库，收款要增加银行余额，采购则相反。所以，智能体协作设计不好会带来数据不一致的问题，要反复检查，比较费事。也正是因为这个发现了系统中的一些数据问题，然后通过AI进行了大量的数据修正，AI还挺适合干这个活儿的。

编好的智能体放在运营中心中进行日常执行：

以下是智能体的架构和智能体对传统服务的调用：

关于七个智能体的协作，也有一张架构图：

应该说出了零代码部分，别的已经集成了，AI助手可以调用MCP，智能体可以调用传统服务，传统服务还有自己的入口，都集成在一个系统中，一个首页下：

二阶段是个比较重要的阶段，这个架构证明题结束之后，谈谈感想吧：

一、AI编程工具进步太快了，肉眼可见，每月感觉都不一样；

二、智能体是一个很好的运营效率加速器，比RPA适用范围更广，也具有更强的扩展性，但同时对企业内部流程、数据质量要求也更高；

三、智能体其实可以分成分析、执行两大类型，笔者的系统中还有决策这个第三类，这是无意中分离出来的，其实分析、执行就够，而且如果业务不复杂的话，执行智能体也不需要挂大模型，分析、决策上挂就可以，笔者也是这么做的；

四、考虑到业务稳定性、可预测性，智能体调用传统服务还是很稳妥的方式，至少直到AI完全可靠之前，毕竟现在超级大佬又在讲“即时系统”了；

五、一般业务的智能体带入主要还是用大模型的分析能力，但是这个分析需要提示词的加强，也就是上下文增强，当然，这个靠AI去写比较好，人来完善就行；

六、AI开发如果是笔者这种纯自然语言编程，就需要控制好测试，否则很花时间，如果是技术人员使用，效率自然会更高；

七、AI系统设计，应该首重数据设计，先设计好数据、库表，数据决定后端，后端决定前端，这个逻辑比较理想；

八、AI设计容易发散，而且“手快”，所以开发者有时需要“眼疾”，否则会在不经意间出问题，当然，另一种方式是，如果在享受“摸鱼式”开发，那么，轮到人做决定时，最好回看下起前边的过程；

九、AI真是“聪明人”了，经常会要“简化”、“直接”、“捷径”，如果你一不小心放过他了，嗯，那就后果自负了。

好了，笔者后边工作很忙了，近期没时间再往下了，其实从实验角度看，这也已经够用了，所以，休息一阵子，冷静冷静。总体来讲，传统的设计方式依然有效，AI开发要重在讨论，而且要非常关注数据，这也可以算是对传统设计理念的回归，数据本来就很重要啊！业务架构中最重要的也是数据实体模型，数据实体模型推导业务组件模型，这是个很重要却又很缺失的设计环节，AI开发换了一种模式重回经典。