最近DIfy在Github上的Star已经突破8万了，已经进入开源领域的Top100的项目了。在进入AI时代里，好的开源项目容易得到比之前更多的关注。例如模拟Manus的开源项目OPenManus在几天的时间里就获得了2万个Star，这样的成绩对于传统的项目来讲简直是不可思议。印象中，中国开源界里最出圈的TIdb项目从2017年到现在也才50K的Star，中间的增长经历过了无数社区互动，版本迭代和大型项目的反馈。
目前AI领域落地最快的的还是偏向2C的应用，比如面向个人聊天助手的ChatGPT、Kimi类的产品，还有面向专业开发者的Cursor、Copilot、WindSurf之类的工具，很多产品已经完成商业的闭环。许多来自传统 2B 软件行业的从业者在评价 Dify、Manus 这类软件时，往往认为这类软件虽然非常容易上手，但目前只适合做一些快速的Demo，缺乏一些大型企业所必需的关键功能，诸如审计功能、完善的权限设计、安全保障机制以及组织架构同步功能等。这些功能的缺失，可能导致企业客户在将其应用于生产系统时遭遇阻碍。目前AI Agent的平台，想要发挥大模型大脑的功能，往往还需要很多的RPA和API作为手脚，来指挥传统的应用去干活，例如大模型跟数据库对接，大模型跟爬虫对接，大模型跟业务系统的API对接。最近很火的MCP协议，Manus的Demo，也充分展现了未来大模型作为调度中心的潜力。与此同时，不少传统 2B 软件厂商纷纷将 DeepSeek 及各类 AI 能力融入其原有的应用平台。以 SAP、用友、金蝶等为例，它们均已推出经新一代 AI 升级的平台 ，为企业客户提供更智能、高效的服务与解决方案，推动传统业务流程的智能化变革，助力企业在数字化时代实现更大的发展。那么未来的软件发展路线中，到底是AI作为核心去调度应用，还是传统的应用平台作为核心去整合AI能力呢？当下，企业里的部门级应用成为 AI 快速渗透与发挥效能的前沿阵地。企业内部的部门，作为独立的决策单元，一方面要承接公司战略层面下达的目标与任务，另一方面直接把控着日常业务的运转细节。任何公司层面的业务波动，都会使得部门层面要在资源优先的情况下承接业务的弹性，这样就会使得部门层面的运作机制更灵活。与公司级别的标准化操作流程（SOP）相比，部门级工作在规则设定上更为灵活，存在大量尚未被严格固化的业务流程。这些流程由于经常变动，若投入大量 IT 资源将其转化为系统，成本效益并不高。然而，它们却非常适合利用 AI Agent 进行灵活处理。以部门级周报汇总工作为例，在传统模式下，这一工作完全依赖人工收集、整理与汇总，不仅耗费大量时间和精力，而且极易出现信息遗漏或格式不统一等问题。倘若将其格式统一固定，又会因组织架构的频繁变动而需不断调整。借助 AI Agent，通过设定与组织 OKR 相匹配的特定模板，即可实现周报内容的自动收集、关键信息的精准提取以及格式的规范化整理。在此过程中，AI Agent 无需对公司整体业务流程进行大规模改动，也避免了触动复杂的 ERP、CRM 等核心业务系统。即便部门缺乏专业编程技能与开发工程师，借助开源 AI Agent 工具，只需投入少量预算，就能实现工作流程的创新优化。回顾企业信息化建设的历史进程，过去轻量级 SaaS（软件即服务）在部门级应用中脱颖而出，正是因其契合了部门业务灵活性与高效性的需求。轻量级 SaaS 产品开箱即用的特性，极大地缩短了部署与开发周期，有效避免了因跨部门沟通协调不畅导致的项目推进缓慢问题。然而，如果轻量级 SaaS 仅局限于功能层面，而不涉及市场动态数据和信息，如各类社交媒体平台上的客户反馈、供应链价格的波动、股价及金融产品价格的变化等，这类纯功能性的 SaaS 极有可能被 AI Agent 所取代。
我们不妨大胆做一个简单预测：鉴于当前 AI Agent 展现出的超强学习能力，一旦它对某个产品的设计有所了解，便能迅速借助各类开源组件和 API 服务，如同搭积木一般，快速复刻出相应功能。当大模型把软件模块功能像文字一样向量化后，也许就可以用上下文接龙的方式迅速推测出每一个积木后面应该接什么样的积木。以项目管理中的甘特图功能为例，在众多软件中，这一功能常被列为高级功能并单独收费。但凭借 AI 的强大能力，基于现有的数据，它能够调用对应的甘特图模板，渲染出一个更为精美的甘特图。AI 会将 SaaS 的各项功能拆解为众多细小模块，快速复制这些独立模块，随后重新拼装，形成一套全新的解决方案 。这种推测会得出一个结论，所有的功能性模块最终将会开源或者免费。而AI的能力就像水一样，柔性的连接各个功能模块，给企业里的每一个部门每一个人，提供完全个性化的服务和信息，真正实现用“个性化的语言”来随意组合应用。到了公司级别的应用，往往任何的改动都需要多个部门的共识，而这类共识往往是那些大型组织经过多年磨合出来的最佳实践。改动这些企业级应用里的流程，往往费时费力，而且里面的逻辑因为固化下来后基本不变，也不需要太多的灵活性，AI在这里的功效并不比一个固化的计算器更好。大型应用平台之所以在运行和管理上必须保持高度严谨，是因为任何细微的改动都可能像推倒多米诺骨牌一般，对当前业务产生连锁反应，波及各个部门以及供应链上下游的切身利益。实际上，真正的高昂成本并非来自系统代码的迭代更新，而是为达成各方共识所付出的巨大代价，包括时间成本、沟通成本以及协调成本等 。在这些应用里，也不可避免的会遇到需要用到AI的地方，一种是将AI作为工具使用，例如使用OCR将图片识别成文本，辅助运营团队审核。还有一种是针对经常需要变动的部分，过去希望用低代码、拖拉拽或者规则引擎去解决的问题，现在也可以用大模型而无需编程即可解决。例如，针对不同地区客户的风控规则，若政策频繁变动，利用大模型用简单的Prompt进行初步决策，再交由人工审核，能够高效且灵活地应对变化。但是这些能力，都没有发挥到大模型目前最强的能力，那就规划和深度思考的能力。还有一些平台，会在应用平台中嵌入诸如 Dify 这样的 AI Agent，以增强平台的灵活性，处理某些特定业务。但可以预见，未来 AI Agent 要实现广泛落地，离不开更多开放插件的支持，需要与各式各样的工具和应用建立连接，而不能仅仅局限于自身平台。这就引出了一个关键问题：平台层面的 AI Agent 框架，未来究竟应构建为封闭式体系，还是开放式体系？应用层面的AI Agent框架，是否允许接入第三方的开源框架，应用层面的API是否会对其他的AI开放？这无疑是个两难抉择。若平台对 AI 完全开放，虽然能为 AI Agent 的拓展应用带来便利，但也存在显著风险，AI 可能轻易复制平台功能，对平台自身的独特性和竞争力构成威胁。反之，倘若平台选择不开放，那么在后续编程和架构规划过程中，拥有深度思考能力的AI 很可能不会将该平台的应用功能纳入推荐范畴，致使平台在日益智能化的生态中逐渐边缘化，错失诸多发展机遇 。Anthropic 公司在 2024 年底推出的开放标准MCP协议，即模型上下文协议，很可能会改变AI Agent与应用平台竞争的格局。它就像 AI 世界的 “USB-C 接口”，为 AI 与外部交互提供统一通信方式。采用客户端 - 服务器模式，有资源、工具、提示三种核心能力。能让 AI 突破信息壁垒获取实时上下文，实现 “即插即用”，提高开发效率。目前MCP协议里大部分还是以开源的软件和应用为主，方便AI大模型能够快速调用本地的工具。
不过，MCP 协议目前尚不完善，例如在调用资源需要耗费的资源和性能怎么评估，如何调用SaaS商业软件的接口，以及涉及复杂用户验证体系接口时，各类软件如何为AI准备更友好的接口测试，还缺乏有效的应对方案。但就当下 AI 推理情况而言，往往倾向于优先采用开放程度最高的资源与方式来完成任务 。平台级应用若想在与 AI 的竞争中占据一席之地，就必须全方位提升自身竞争力，在规模化、安全性、合规性、审计功能、规范性、性能优化、高可用性以及抽象能力等方面做到更强更好。未来平台级应用跟AI Agent的PK，其实就是企业级软件的资深产品经理跟AI大模型深度思考能力的PK。如果公司使用多个应用平台，每个应用平台里又有很多不同的AI Agent平台，再加上公司层面的AI Agent平台，这样看起来会不会非常混乱？公司级别的应用，是否有哪些是完全统一的，不可替代的呢？比如企业级的IM（聊天应用）往往是统一的，即使是多元化业务的企业，可能会存在不同的业务单元，每个业务单元都使用自己的ERP/CRM和关键业务系统，但是可能会使用统一的邮件系统和IM系统。若公司层面的 AI Agent 平台与即时通讯工具（IM）深度绑定，引导用户习惯与 IM 中的智能助理互动，由其负责深度分析与规划工作，诸如指导用户如何开展业务、该启用哪个系统、具体操作步骤以及应填写哪些信息等。那么，在此情形下，即便众多应用平台自身也配备 AI Agent，这些 Agent 很可能仅充当系统的代理角色，主要负责与企业级 AI Agent 进行交互。以往是用户与系统直接打交道，如今则转变为个人的 AI Agent 与部门层面的Agent，公司层面的Agent，以及系统的 AI Agent 之间相互协作的模式。
粤ICP备14082021号
免费POC，
零成本试错
