AI 应用即智能体：探索从 Composer 到 Manus 下的范式演进

简单来说：

AI 应用即智能体是将多个 AI 功能模块（智能体）整合起来，通过服务化的方式（如 API）提供给 AI，使其能够智能体能够相关交互一样， 利用其它 Agent 的能力来完成各种复杂的任务。

在先前的两个 AutoDev 新功能中，我们引入了两个新的 AI 功能：AutoDev MCP 和 AutoDev Planner。当我们在探索如何将这两个功能结合到更多的 阶段时，我们发现了一个更大的范式演进：AI 应用即智能体。

简单来说，在两个场景结合之下，你可以调用 AutoDev 上的一系列 AI Agents，然后完成你的任务。哪怕你不会写代码，你也可以调用 AI 来生成业务 逻辑、分析历史需求、生成设计文档等。

我们将在这篇文章中，探索这个范式演进，并且展示如何将这个范式应用到更多的场景中。

一个小的尝试：AutoDev Planner 即服务

在 MCP 模式之下，各类的桌面工具都可以被服务化，IDE 也不例外。基于我们在 AutoDev 提供的 MCP 服务能力，用户可以通过 MCP API 来调用 AutoDev 上的 AI 能力。

一个简单的 AutoDev MCP 数据库示例

我们在 AutoDev 中提供了大量的基于 IDE 能力的 API 封装，除了使用 DevIn 指令来调用；这些能力，还可以通过 MCP API 来调用。比如， 你通过如下的 MCP API 调用，就可以获取当前数据库的 schema：

curl -X POST "http://127.0.0.1:63342/api/mcp/get_current_database_schema"

当用户连接了数据库之后，就会返回对应的数据库信息。如果你需要进一步的操作，比如创建表、插入数据等，未来也可以通过 MCP API 来调用。这就意味着， 你可以说一句话，就可以完成一系列的数据库操作，以及对应的数据库操作。

这就意味着，我们还可以调用 AutoDev 上的一系列的 AI Agent 能力，比如：AutoDev Sketch、AutoDev Bridge 等。

复杂一点的示例：调用 AutoDev 上的 AI Agent

考虑一个情景，你作为开发者接到一个新的系统设计需求，比如“设计一个新的用户登录模块”。你就可以通过以下的 API 调用来开始任务拆解，找到关键的核心 代码，不再需要复杂的、无用的 AI 代码 RAG。你可以调用 AutoDev Sketch 来帮助实现对应的任务拆解能力。诸如于：

~ curl -X POST "http://127.0.0.1:63342/api/mcp/issue_or_story_evaluate" \

-H "Content-Type: application/json" \

-d '{"issue": "检索代码库，总结 Sketch 的工作流程"}'

{

"status": "1. 定位核心工作流类\n - [] 搜索包含 \"Workflow\" 和 \"Sketch\" 的类定义\n - [] 分析 SketchRunner 的 execute 方法\n2. 解析 AI Flow 执行阶段\n - [] 识别上下文收集阶段\n - [] 分析工具调用决策模块\n - [] 跟踪代码生成流水线\n3. 验证工作流程完整性\n - [] 检查异常处理机制\n - [] 确认版本控制集成点"

}

那么，你就有了一个初步的如何实现这个任务的思路：

定位核心工作流类

[] 搜索包含 "Workflow" 和 "Sketch" 的类定义

[] 分析 SketchRunner 的 execute 方法

解析 AI Flow 执行阶段

[] 识别上下文收集阶段

[] 分析工具调用决策模块

[] 跟踪代码生成流水线

验证工作流程完整性

[] 检查异常处理机制

[] 确认版本控制集成点

详细可以见，我们提供的 AutoDev 示例：https://ide.unitmesh.cc/mcp/mcp-server.html

再向前一步：解决一个更大的问题 - 需求分析

进一步地，我们不仅可以拆解任务，还能够依赖智能体来执行这些任务。例如，当任务拆解之后，我们可以调用 AutoDev 中的 AI Agent 来帮助完成具体的开发工作。例如，在上述的任务拆解后，调用AutoDev Sketch来生成设计文档，汇报流程图。如下是对应的分析示例：

1. 分析博客创建流程涉及的代码组件

- [x] 查看BlogController的POST方法

- [x] 分析BlogService的createBlog方法

- [x] 确认数据库表结构（blog表）

2. 设计Mermaid流程图元素

- [x] 用户请求入口（POST /blog/）

- [x] DTO转换过程（CreateBlogRequest -> BlogPost）

- [x] 数据库保存操作（BlogRepository.save）

- [x] 响应返回流程（BlogPost -> CreateBlogResponse）

3. 生成Mermaid代码

- [x] 按顺序连接各组件

- [x] 添加关键方法调用标注

而在现在的 AI IDE 模式之下，你需要：

历史需求分析：上传历史需求文档，结合 RAG 进行分析

获取代码上下文：下载代码、打开项目、打开聊天输入内容等，最后总结到相关上下文

生成设计文档：调用 AutoDev Sketch，生成设计文档

现在将 AI 应用变成可调用的能力之后，这个问题就变得非常简单。你只需要一个 Agent 的 Agent 就可以了。

Agent 的 Agent：AI 应用即智能体

在当前主流的模式之下，你会有一个类似于 Manus 这样的入口，然后通过 Manus 来调用各类的 AI Agent。而在我们的范式之下，作为一个 AI Agent，为了 获取更好的上下文，你可以调用另一个 AI Agent 来获取上下文，哪怕是 Manus 的 Agent。

AI 应用即智能体是将多个 AI 功能模块（智能体）整合起来，通过服务化的方式（如 API）提供给 AI，使其能够智能体能够相关交互一样， 利用其它 Agent 的能力来完成各种复杂的任务。

在 AutoDev 这一类 AI 辅助研发的场景之下，AI 应用即智能体的核心特征包括：

AI 能力服务化接口：通过 API 或其他标准化接口，智能体的能力可以被外部系统或用户调用，实现无缝集成。

内部任务自动化：智能体能够根据用户需求自动拆解任务并执行，例如生成代码、分析需求、设计文档等。

协作性：智能体不仅能够独立完成任务，还可以与开发者或其他智能体协作，共同推动项目进展。

PS：感谢 DeepSeek 帮我总结。

Agent 范式演进：无处不在 Agent 及其能力边界

基于这个范式，我们可以思考如何将 AI 应用的能力无限扩展，比如你的 AI Agent 作为死去 “中台”（过去的热词）的延续。

忘记中台吧，它死了好久了

我们总是需要一个所有的 Agent 能力中心的，它反正叫什么都行，总不可能叫 Agent 中台吧。

现在，让我们讨论一下  OpenAPI Agent 范式演进。

Agent 的语言化 OpenAPI 设计

现在基于 Agent 的 API 还是那么几种：Function Calling、MCP 等，其实都大差不差：

API 文本描述：name, description

输入输出定义（Schema）：parameters, return

和先前各种平台开放 API 的设计，唯一的区别是多了一个 description 字段。这个字段是用来描述这个 API 的功能，以及如何使用的。以让其它 AI Agent 能够更好地调用。

回忆一下微服务的服务发现

服务发现（Service Discovery）是指在分布式系统中，服务能够自动地识别和定位到彼此的网络地址（通常是 IP 地址和端口号）的过程。

微 Agent 的 Agent 发现是微 Agent 架构中至关重要的一个环节。在传统的单体应用中，Agent 之间的调用通常是直接的方法调用，但在微 Agent 架构中， 不同的服务运行在不同的进程甚至不同的服务器上，它们需要一种机制来找到彼此的网络地址（Agent 描述和服务地址）才能进行通信。

权限控制：Agent 的能力边界

真是一个头疼的问题，我的 AI 应该能访问哪些系统，不应该访问哪些系统呢？想一想，我们这些带工号的员工，都有哪些权限呢？谁来分配这些权限呢？

所以，你的每个 AI Agent 都是有权限的“员工”，那么自然而然问题就会迎刃而解。

忘记新范式吧，它落地不了

好吧，我们要承认一点，尽管新的技术很好，新的范式非常好，但是我们还是需要考虑到现实的问题。落地的时候，总是要面临组织边界的挑战。

总结

哦，对了 AutoDev 文档在这里：https://ide.unitmesh.cc/mcp/mcp-server.html