Personal Archive yy的博客
English EN
AI 应用开发的5种模式
· 6 分钟阅读

AI 应用开发的5种模式

从 HTTP API、官方 SDK、AI 开发框架、低代码平台到 AI 编程工具 SDK，梳理 AI 应用开发的 5 种模式和后续学习路线。

技术 #AI #AI 应用开发 #SDK #Agent #工程化

最近读完 程序员鱼皮-面试官皱眉：“你简历上写精通 AI 开发？” 我自信：“不就是调个接口吗？” 他没绷住笑：“就这？” 这篇文章，觉得不错，在这记录一下学习笔记。

这篇文章记录了一个更清晰的分层视角：AI 应用开发不仅仅是“调一个接口”，而是从底层协议到 Agent 自动化的一组能力层级。

如果把这些层级先看懂，后面再去研究框架、平台、工具，思路会稳很多。

先记结论

  • HTTP API 解决的是“怎么直接跟模型说话”。
  • 官方 SDK 解决的是“怎么少写样板代码”。
  • AI 开发框架 解决的是“怎么组织完整应用能力”。
  • 低代码平台 解决的是“怎么更快搭原型并交付流程”。
  • AI 编程工具 SDK 解决的是“怎么把 Agent 能力接进自动化任务”。

为什么“调 API”只是入口

AI 应用开发的复杂度，不在“能不能发请求”，而在“发请求之后怎么组织能力”。

从这个角度看，本文更像一张学习地图：

  • 越底层，越接近协议和请求细节
  • 越往上，越接近应用编排和自动化
  • 每一层，都会帮我们减少一种复杂度

如何知道自己最适合哪种方式：先看它属于哪一层，再看这一层到底替我们省了什么。

第一层：HTTP API

这是最原始、也最值得先搞懂的一层。

本质很简单：程序通过 HTTP 请求，把输入发给大模型，再把响应拿回来自己处理。

这层最有价值的地方，不是“方便”，而是“透明”。我们能清楚看到请求地址、鉴权方式、消息格式、返回结构、流式输出这些最基础的东西。

常见的两种协议风格是：

我觉得学习这一层时，最该盯住的是几个关键词：

  • messages：对话消息列表
  • temperature：控制随机性
  • max_tokens：控制输出长度
  • usage：看 Token 消耗
  • stream / SSE：实现流式返回

举个短例子看下：

展开代码
curl https://api.deepseek.com/chat/completions \
  -H "Authorization: Bearer 你的API密钥" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [
      { "role": "system", "content": "你是一个有用的助手" },
      { "role": "user", "content": "用一句话介绍什么是AI应用开发" }
    ]
  }'

这一层适合：

  • 学底层原理
  • 排查 SDK 包装不清楚的问题
  • 使用某些 SDK 尚未覆盖的语言或接口

第二层：官方 SDK

SDK 的本质不是另一套新能力，它只是把 HTTP API 再包装了一层。

它帮我们省掉的，主要是这些重复劳动：

  • 拼请求头
  • 构造 JSON
  • 解析响应
  • 处理错误码
  • 处理流式数据

所以 SDK 更像一个“把常见坑都先封住”的工具包。

我自己会把这一层理解成：

HTTP API 是自己搭管道，SDK 是直接用现成水龙头。

比如 OpenAI 的 Python SDK 只要几行，就能完成一次聊天请求；而如果底层服务兼容 OpenAI 协议，很多时候只要改 base_url 和模型名，就能切到别的供应商。

这层最适合：

  • 日常业务开发
  • 快速接入模型
  • 不想手写太多底层请求细节的时候

第三层：AI 开发框架

如果说 SDK 解决的是“怎么快速调模型”，那框架解决的就是“怎么把 AI 做成应用”。

这一步开始，关注点就不只是单次问答了，而是：

  • 记忆
  • RAG
  • 工具调用
  • MCP 接入
  • 多 Agent 协作
  • 工作流编排

也就是说，框架处理的是完整应用的问题，而不是单次请求的问题。

这一层可以重点关注：

  • LangChain
  • LangGraph
  • LangChain4j
  • Spring AI
  • Vercel AI SDK

SDK 让我们更方便地调模型，框架让我们更方便地组织 AI 应用。

它们不是一回事，也不是替代关系。

如果要做的是一个需要长期运行、需要接工具、需要记上下文、需要按步骤推进的 AI 应用，那就已经是在框架层面思考问题了。

第四层：低代码平台

如果说前面三层更偏工程，那这一层更偏落地速度。

低代码平台的意义很直接：让我们先把一个 AI 流程跑起来，不必先把工程骨架写完整。

常见的平台有：

  • Dify
  • Coze
  • 阿里云百炼
  • n8n

这类平台很适合：

  • 快速验证想法
  • 搭知识库问答
  • 做工作流编排
  • 给非技术角色使用

但它的边界也很清楚。

一旦开始在意这些事：

  • 复杂定制
  • 工程治理
  • 版本管理
  • 测试和回归
  • 代码级可控性

那很多能力还是会慢慢回到代码里。

所以低代码更像一个起点或临时落脚点，不是所有场景的终点。

第五层：AI 编程工具 SDK

这是我觉得最容易被忽略、但很值得继续研究的一层。

普通模型 SDK 通常是“生成文本”。而 AI 编程工具 SDK 更像是“让 Agent 进入我们的开发环境”。

它能做的事情不只是回答问题，还包括：

  • 读项目代码
  • 改文件
  • 跑命令
  • 使用项目规则
  • 读取 Skill / MCP 等上下文

可以把它理解成：我们不是在调用一个聊天模型，而是在调用一个会干活的 AI 程序员。

这类工具现在可以重点关注：

  • Cursor SDK
  • Claude Agent SDK
  • GitHub Copilot SDK

它适合的场景很实用：

  • 自动生成报告
  • 代码审查
  • 批量重构
  • CI/CD 辅助
  • 项目内自动化任务

如果后面想把 AI 能力嵌进自己的产品、脚本或者自动化流程里，这一层会越来越重要。

怎么选择

下面这张表，是我给自己做的快速判断版。

模式解决的问题适合场景学习重点
HTTP API直接调用模型学原理、调试、特殊接口协议、参数、流式输出
官方 SDK减少样板代码大多数日常开发初始化、调用封装、错误处理
AI 开发框架组织完整应用能力RAG、工具调用、多 Agent编排、记忆、状态管理
低代码平台快速搭建和交付流程原型验证、知识库、工作流节点配置、集成方式、边界
AI 编程工具 SDK把 Agent 接进开发环境自动化任务、代码工作流文件操作、命令执行、项目上下文

我自己的结论是：

  • 做项目：先用最少成本解决当前问题
  • 学习：从 HTTP API 往上学，理解每层封装掉了什么复杂度
  • 真正开发：这些模式通常是组合使用，不是互相排斥

我的后续学习路线

这篇更像一个起点。接下来我会继续沿着这 5 个方向往下挖：

  1. 大模型 API 协议和流式输出
  2. SDK 封装和 provider 设计
  3. RAG、工具调用和 MCP
  4. Dify / Coze 的工作流设计
  5. Cursor / Claude Code 这类 Agent SDK 自动化

如果把这一系列继续写下去，我希望最后得到的不是一堆零散名词，而是一张AI应用开发的架构地图。

评论