后端架构变革：从固定API转向AI智能体系统
通过实际代码示例、用例以及需要考虑的实用权衡，了解当 AI 智能体取代固定 API 路由时后端设计会发生怎样的变化。
长期以来，后端开发一直遵循一种简单的模式：设置路由，客户端发起请求，服务器返回响应。
POST /create-order
GET /user/123
这种模式结构清晰、易于理解，且在生产环境中具备良好的扩展性。
但问题在于：
应用程序中每一种可能的请求路径都必须提前规划好。
每当用户尝试超出预设范围的请求时，解决办法始终相同：编写更多代码、添加更多路由、堆砌更多条件判断。
现在想象另一种类型的请求。用户只需输入：
“帮我查找明天最便宜的航班并预订它。”
并没有一个单一的端点能够完成这项任务。正是在这里，传统模式开始显得力不从心。
如今我们如何构建后端（API）
让我们来看一个具体的场景。
电子商务流程（基于API）
// Step 1: Get product
GET /products/:id
// Step 2: Add to cart
POST /cart// Step 3: Create order
POST /order// Step 4: Payment
POST /payment
这些步骤每一个都是：
- 预先确定的
- 可明确控制的
- 硬编码在流程中的
甚至这些路由背后的逻辑也往往呈现这样的形式：
if (user.isLoggedIn) {
createOrder()
} else {
throw new Error("Unauthorized")
}
这种方法效果不错，但它隐含了一个前提：你必须事先知道用户可能通过系统走过的所有路径。
使用智能体构建相同功能
无需逐一列出步骤，只需描述期望的结果即可。
“订购价格低于70,000卢比的最便宜iPhone”
有了这种转变，后端的结构也会随之改变。
第一步：定义工具（你的API）
const tools = [
{
name: "search_products",
description: "Search products by name and filters",
},
{
name: "create_order",
description: "Create order for a product",
},
{
name: "make_payment",
description: "Process payment",
}
]
仔细看看发生了什么变化。
底层的 API 依然存在——只是以可调用的工具形式呈现。
步骤 2：让智能体自行决策
通过类似 Ollama 配合 Gemma 4 的设置：
const userGoal = "Buy the cheapest iPhone under 70000"
const response = await agent.run({
goal: userGoal,
tools
})
在背后，智能体会自行处理问题：
- 调用
search_products - 按价格筛选
- 选择最佳选项
- 调用
create_order - 触发
make_payment
没有人工编写的固定流程。
直白说明的核心差异
以下是简化的区别：
API：
你需要编写：
Step 1 → Step 2 → Step 3
智能体：
你需要编写：
Goal → System figures out steps
这就是这种转变的本质。
实际应用价值
让我们看看具体场景而非抽象概念。
1. 客户支持自动化
无需使用诸如以下的独立接口：
/get-order/cancel-order/refund
而是让系统处理单个请求，例如：
User: "My order is late, cancel it and refund"
随后，该系统会：
- 检查订单状态
- 取消订单
- 触发退款流程
2. 内部开发工具
例如：
"查看过去1小时内API延迟增加的原因"
该系统能够：
- 查询日志
- 检查各项指标
- 推测可能存在的问题
3. 失踪人员查询平台
这一案例值得重点介绍。
用户上传照片并询问：
"查询此人是否被报告为失踪人员"
该系统的处理流程将为：
- 调用图像匹配服务
- 查询数据库
- 返回找到的匹配结果
这些操作都不需要遵循固定的、预定义的API流程。
架构结构
从高层次来看，其实很简单：
User → Agent → Tools → Your Existing Backend
现有的API并不会消失——只需为它们添加封装，这样代理就可以在需要时调用它们。
示例实现（Node.js风格）
app.post("/tools/create_order", async (req, res) => {
const { productId } = req.body
const order = await createOrder(productId)
res.json(order)
})
代理只需将此接口作为其可用工具之一来调用即可。
实际会遇到的挑战
这种方法并非没有问题。
1. 调试变得更困难
使用传统API时，你是在调试自己的代码。
而使用代理时，往往需要去排查模型为何选择特定操作。
2>行为并不总是一致
相同的输入每次都可能产生不同的输出。
3. 开支可能迅速上升
为了完成原本只需一个请求就能处理的任务，代理可能需要发起5次API调用并经过10个推理步骤。
4. 安全性需要更多关注
你必须严格控制代理能够访问的工具以及它所接触的数据。
这对作为后端开发者的你意味着什么
不要把事情弄得比必要的更复杂。
持续构建API
它们依然是所有其他功能的基础。
将API设计为可调用的工具
从工具定义的角度来思考：
{
"name": "get_user_orders",
"description": "Fetch all orders for a user"
}
构建一个小型代理项目
选择一些易于管理的功能，比如订单助手、日志分析器或内部聊天机器人。Ollama或Gemma 4这类工具是不错的起点。
将思维转向目标，而非固定流程
这种思维方式的转变比任何具体的工具选择都更为重要。
结语
API为后端系统提供了结构，而智能体则赋予其灵活性。未来并非API与智能体的对立，而是二者的结合。如果你已经掌握构建优质API的方法，那就已经走了一半的路程。不妨问问自己：如果后端能够自行规划操作步骤会怎样？
相关阅读
- 了解AI智能体：目标、工具、记忆与智能体循环 —— 一篇适合初学者的文章，详细解释了AI智能体与聊天机器人的区别，涵盖了核心组件、决策循环、自主程度以及实际应用场景。