AI应用开发极简路线：从Prompt到Agent实战指南

兜兜转转看了一堆“AI应用开发学习路线”，要么是几十个视频链接的搬运合集，要么是一上来就甩一套 LangChain 源码。真正想动手做点东西的人，反而不知道第一步应该落在哪里。

这篇文章我打算换一种讲法：不谈那些宏大的“人工智能导论”，也不扯大模型训练细节，就围绕AI 应用开发本身拆出一条极简路线。你不需要数学基础，不需要自己训练模型，只需要会用 Python、会调接口，就能在两周左右做出一个带业务价值的 AI 应用。

内容会覆盖四个核心知识点：Prompt 工程、上下文管理、Function Calling、RAG 与 Agent。同时我会给出一条可以直接照着练的完整实战案例，包含可复制代码和运行说明。新手可以用它入门，后端开发也能快速把大模型接入自己的业务。

1. AI 应用开发到底在做什么

1.1 先搞清楚：这不是算法岗

很多初学者把 AI 应用开发和算法研究混在一起，然后被“神经网络”“反向传播”“分布式训练”这些词劝退。

实际上，AI 应用开发更接近传统后端开发的延伸。核心工作不是训练模型，而是：

• 调用大模型 API，把模型能力接入具体业务流程。
• 设计 Prompt，让模型按预期格式输出结果。
• 管理上下文，处理多轮对话和历史记忆。
• 连接外部系统，让模型能查数据库、调接口、操作工具。
• 处理模型返回的幻觉、截断、不稳定等问题。

换句话说，模型是一个已经存在的服务，你要做的是把它变成可用的产品功能。

1.2 应用开发与大模型的关系

当前主流大模型（包括 ChatGPT、DeepSeek、通义千问、文心一言、Kimi 等）都提供了 HTTP API 接口。开发者只需要按照协议传入消息内容，就能拿到模型的回复。

这个模式下，应用开发的复杂度从“怎么训练模型”转移到了“怎么组织输入、处理输出”。

以最常见的对话接口为例，一次 API 调用包含两个关键部分：

• messages：对话消息列表，决定模型看到什么内容。
• model：指定使用哪个模型。

应用层要做的事情就是动态构造 messages、解析返回值、循环调用。

这也是为什么很多招聘 JD 上写的“AI 应用开发”要求其实不高：熟悉 Python/Java，了解 HTTP 和 JSON，懂得怎么调 API，再加一点 Prompt 设计经验就够了。

1.3 当前岗位与市场的真实情况

“中小自研公司 AI 应用开发岗位多吗”这个问题，答案要分两面看。

一方面，很多公司并没有单独设立“AI 应用开发工程师”这个岗位，而是把它并入后端开发或全栈开发。你在面试时看到的要求往往是“熟悉 Spring Boot / Python 后端开发，有 AI 应用开发经验优先”。

另一方面，业务侧对大模型落地的需求确实在快速增加。客服助手、知识库问答、代码辅助、内容生产、自动化流程等场景都需要有人去对接大模型能力。

所以我的建议是：不要把“AI 应用开发”当成一个脱离后端体系的独立方向。把它当作后端开发的一项核心加分技能，学习性价比反而更高。

2. 学习前需要具备的能力模型

在动手之前，先对照一下知识储备。AI 应用开发对基础要求不算高，但也不是零基础就能直接上手。

2.1 基础能力清单

如果你的 Python 基础还停留在“看过语法”阶段，建议先花 3 到 5 天写几个小脚本，比如爬取网页、处理 CSV、调用一个第三方天气 API，补齐基础能力再进入大模型 API 学习。

2.2 学习路径中的五个层次

• 第一层：API 调用。学会用代码与大模型对话，理解 messages、role、temperature 等基础参数。
• 第二层：Prompt 工程。学会通过提示词控制模型的输出格式、风格和准确性。
• 第三层：上下文管理。解决多轮对话、长文本、记忆丢失问题。
• 第四层：RAG 检索增强。把私有知识库接入模型，让模型基于你的资料回答。
• 第五层：Agent 智能体。让模型具备调用工具、规划任务、自主决策的能力。

这五个层次是层层递进的关系。绝大多数 AI 应用开发岗位的核心技能就在第三层到第五层之间。

2.3 框架选型上的一个提醒

很多教程一开始就教 LangChain、LlamaIndex、Spring AI 这类框架。我不是说框架没用，而是不建议零基础直接学。

原因很简单：框架抽象了大量细节，如果不懂底层逻辑，遇到报错会完全不知道从哪里排查。

更合理的顺序是：先用原生 SDK 读懂一次完整的大模型 API 调用流程，再引入框架提升开发效率。

3. 环境准备与版本说明

本部分给出一个通用的开发环境搭建方案。版本号不建议追求最新，稳定即可。

3.1 运行环境

• 操作系统：Windows 10 / macOS / Linux 均可。
• Python 版本：建议 3.10 及以上。
• 包管理工具：pip 或 conda。
• 开发工具：VS Code 或 PyCharm。
• API 服务：OpenAI 接口兼容的大模型服务均可，例如 DeepSeek、通义千问等（文中示例以“自定义 Base URL”方式接入，不依赖任何特定服务商）。

如果你的大模型 API 是 OpenAI 官方接口，默认配置即可。如果是国内服务商提供的兼容接口，只需要修改base_url和model。

3.2 项目依赖

在项目根目录创建requirements.txt：

openai>=1.30.0 python-dotenv>=1.0.0

安装命令：

pip install -r requirements.txt

这里使用的openai官方 Python 包并非只能连接 OpenAI 官方服务。只要服务商提供 OpenAI 兼容接口，都可以通过配置base_url来接入。这样既方便切换服务商，也能复用生态里成熟的 SDK 能力。

3.3 环境变量配置

在项目目录下创建.env文件：

OPENAI_API_KEY=你的API密钥 OPENAI_BASE_URL=https://api.deepseek.com/v1 OPENAI_MODEL=deepseek-chat

如果使用官方 OpenAI 服务，可以不填OPENAI_BASE_URL，代码默认走官方地址；OPENAI_MODEL则按你实际使用的模型名填写。

创建.env.example作为团队协作时的模板，不要把真实密钥提交到 Git 仓库。

3.4 项目结构

ai-assistant/ ├── .env # 本地密钥配置（勿提交） ├── .env.example # 配置模板 ├── requirements.txt # 依赖清单 ├── ai_tools.py # 工具函数定义 └── main.py # 主程序入口

4. 核心原理速览：四个关键词

在进入实战之前，先花一点时间理解 AI 应用开发最常见、也最核心的四个概念。后面的学习路线和代码都围绕它们展开。

4.1 Prompt Engineering（提示词工程）

大模型本身是一个概率生成模型，输入决定输出。好的 Prompt 能显著提升回答的准确性和格式稳定性。

一个实用的 Prompt 通常包含以下要素：

• 角色设定：告诉模型你希望它扮演什么身份。
• 任务描述：明确要求模型做什么。
• 输出约束：指定格式、字数、风格。
• 上下文材料：提供任务相关的参考资料。
• 边界说明：什么情况应该拒绝回答，什么情况应该提问澄清。

写 Prompt 不是一次就能成功的，建议在实际业务中准备一个 Prompt 版本管理目录，每轮修改都记录前后效果，便于回滚比较。

4.2 Context 上下文管理

大模型的输入输出长度都有限制。对话记录越长，消耗的 Token 越多，响应也越慢。

上下文管理的核心思路是：只把当前任务最需要的对话片段、知识片段传给模型，而不是把整个历史记录都无脑拼进请求。

常用手段：

• 滑动窗口：只保留最近 N 轮对话。
• 摘要替换：把早期对话总结成一句摘要放入上下文。
• 相关性筛选：从知识库中检索出与当前问题最相关的片段。

4.3 Function Calling（函数调用）

Function Calling 是大模型与外部系统交互的关键能力。模型本身无法查数据库、无法调接口，但可以通过输出结构化的调用指令，让程序替它执行。

典型流程：

1. 把可用工具的描述传给模型。
2. 模型判断当前问题是否需要调用工具。
3. 如果需要，模型返回“工具名 + 参数”。
4. 程序执行真实工具函数，得到结果。
5. 把工具执行结果返回给模型，模型据此生成最终回复。

这一机制是 AI Agent 的技术基础，后面实战案例会完整演示这个过程。

4.4 RAG（检索增强生成）

RAG 解决的是“大模型不知道你的私有数据”问题。

原理不复杂：

1. 把知识文档切分为文本块。
2. 对每个块做向量化，存入向量数据库。
3. 用户提问时，先从向量库中检索最相关的文本块。
4. 将检索到的文本块和问题一起发给模型。
5. 模型基于给定的资料生成回答。

RAG 适合做企业知识库问答、文档助手等场景。相比重新训练模型，RAG 的成本低、更新快，是目前应用落地的主流方案。

4.5 Agent（智能体）

Agent 可以理解为“增强版的大模型应用”：模型作为决策大脑，通过调用多个工具完成复杂任务。

一个简单的 Agent 至少具备：

• 任务理解能力。
• 工具调用能力。
• 多步推理能力。
• 记忆能力。

当前学习路线中，Agent 属于较高级的阶段，建议先用 Function Calling 打好基础，再尝试多工具协作、任务规划等进阶玩法。

5. 极简学习路线：按阶段拆解

下面按“周”给出一个参考节奏。基础好的可以压缩时间，基础薄弱的可以适当延长，关键是每个阶段都要有可运行的产出。

5.1 第一阶段：API 调用（约 1 周）

学习目标：

• 理解 Chat Completion 接口的基本请求格式。
• 能通过 Python 代码发送消息并接收回复。
• 能动态构造 messages 列表，模拟多轮对话。

核心知识点：

• system、user、assistant三种角色含义。
• temperature、max_tokens等参数作用。
• API Key 的安全管理方式。

动手练习：

• 写一个命令行版翻译工具。
• 写一个固定角色的客服机器人。

注意：不要止步于“调通了”。要重点实验 system prompt 对输出的影响，比如让模型“只回复 JSON”、让模型“遇到不懂就说是不知道”，观察输出变化。

5.2 第二阶段：Prompt 工程（约 1 周）

学习目标：

• 掌握结构化 Prompt 的编写规范。
• 学会用 Prompt 控制输出格式、语气和内容边界。

核心知识点：

• 角色扮演、思维链、Few-shot（少样本示例）。
• 输出约束的写法。
• 处理模型幻觉的基本策略。

动手练习：

• 设计一个“简历优化助手”的 Prompt，要求输出固定 JSON 结构。
• 设计一个“敏感内容守卫” Prompt，要求对于不相关问题拒绝回答并说明原因。

建议把常用的 Prompt 模板沉淀成模块，方便在多个项目中复用。

5.3 第三阶段：RAG 检索增强（约 2 周）

学习目标：

• 理解文档切分、向量化、检索、重排的基本流程。
• 能实现一个简单的知识库问答应用。

核心知识点：

• 文本切分策略。
• Embedding 向量的含义。
• 向量数据库选型（生产环境可选 Chroma、Milvus、Qdrant 等，初学可用简单相似度检索代替）。

动手练习：

• 把一个 Markdown 文档作为知识库，做一个“文档问答机器人”。
• 对比“直接问模型”和“RAG 检索后问答”的效果差异，总结原因。

这里强调一点：RAG 的效果更多取决于文档切分和检索质量，不完全取决于模型本身。建议初学阶段先不引入重量级向量数据库，用关键词或 TF-IDF 方案跑通流程，再逐步替换。

5.4 第四阶段：Function Calling 与 Agent（约 2 周）

学习目标：

• 理解函数调用的完整链路。
• 能接入自定义工具，如查天气、查数据库、执行计算。

核心知识点：

• tools 参数写法。
• 解析模型返回的 tool_calls。
• 多轮工具调用的循环逻辑。

动手练习：

• 做一个带“查询时间”“计算器”两个工具的命令行助手。
• 尝试让模型自主决定是否调用工具。

这部分是当前应用开发面试的高频点，值得多花时间。要弄清楚：什么时候模型会触发 tool_calls，怎么把工具结果传回模型，以及如何避免死循环。

5.5 第五阶段：工程化与部署（约 2 周）

学习目标：

• 掌握 FastAPI 或 Flask 接口封装。
• 掌握流式输出、日志监控、配置管理等工程能力。
• 了解生产环境的安全边界与成本控制。

核心知识点：

• 异步接口封装。
• 请求日志和 Token 消耗统计。
• 限流、鉴权、Compliance 边界。
• 前后端分离架构中 WebSocket / SSE 的流式方案。

动手练习：

• 将以上任意一个命令行工具改造成 Web API。
• 增加简单鉴权逻辑与接口调用日志。

6. 完整实战案例：Function Calling 命令行助手

下面这个案例适合在第四阶段练习。它完整展示了 API 调用、上下文管理、工具调用三部分内容，代码可以直接复制运行。

先强调一下：不同服务商对 Function Calling 的支持程度有差异。本文以 OpenAI 兼容接口为例，如果你的服务商不支持 tools 参数，需要替换为支持该能力的服务。

6.1 创建项目结构

mkdir ai-assistant cd ai-assistant touch .env requirements.txt ai_tools.py main.py

6.2 编写工具函数

打开ai_tools.py，定义两个工具：get_current_time（获取当前时间）和calculator（计算数学表达式）。

# 文件路径：ai_tools.py import datetime import math def get_current_time(): """获取当前本地时间""" now = datetime.datetime.now() return {"result": now.strftime("%Y-%m-%d %H:%M:%S")} def calculator(expression: str): """ 计算简单数学表达式。 仅支持数字、加减乘除、括号、幂运算等基础表达式。 """ allowed_chars = set("0123456789+-*/(). ") if not all(char in allowed_chars for char in expression): return {"error": "表达式包含非法字符"} try: result = eval(expression, {"__builtins__": {}}, {"math": math}) return {"result": result} except Exception as exc: return {"error": f"计算失败: {exc}"} TOOLS = [ { "type": "function", "function": { "name": "get_current_time", "description": "获取当前的本地日期和时间，不需要参数", "parameters": { "type": "object", "properties": {} } } }, { "type": "function", "function": { "name": "calculator", "description": "计算数学表达式，例如 '12 * 5 + 3'", "parameters": { "type": "object", "properties": { "expression": { "type": "string", "description": "要计算的数学表达式" } }, "required": ["expression"] } } } ] def call_function(name: str, arguments: dict): """根据模型返回的工具名称和参数，执行对应的真实函数""" if name == "get_current_time": return get_current_time() if name == "calculator": return calculator(arguments.get("expression", "")) return {"error": f"未知工具: {name}"}

这里有一个需要特别说明的安全点：示例中的calculator使用了eval，在真实业务里应尽量避免直接执行用户输入。生产环境建议用ast.literal_eval或专用计算库，这里仅作演示。

6.3 编写主程序

打开main.py，实现完整的调用流程：

# 文件路径：main.py import json import os from dotenv import load_dotenv from openai import OpenAI from ai_tools import TOOLS, call_function # 加载 .env 环境变量 load_dotenv() def get_client(): return OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1"), ) def chat(client, messages): model = os.getenv("OPENAI_MODEL", "gpt-4o-mini") response = client.chat.completions.create( model=model, messages=messages, tools=TOOLS, tool_choice="auto", ) return response.choices[0].message def run_conversation(): client = get_client() system_prompt = ( "你是智能助手。如果你认为用户的问题需要调用工具来解决，请使用工具。" "调用工具后，请结合工具返回的结果组织最终回复。" "回复使用简洁、自然的中文。" ) messages = [{"role": "system", "content": system_prompt}] print("AI 助手已启动，输入 exit 退出。") print("你可以尝试：现在几点？ 计算 (23*45+12)/7") while True: user_input = input("\n>>> ") if user_input.lower() in ["exit", "quit"]: break messages.append({"role": "user", "content": user_input}) # 工具调用循环：模型可能要求连续调用多个工具 for _ in range(5): # 最多循环 5 次，防止死循环 message = chat(client, messages) messages.append(message) if not message.tool_calls: print(f"\nAI: {message.content}") break # 遍历模型要求的工具调用 for tool_call in message.tool_calls: function_name = tool_call.function.name arguments = json.loads(tool_call.function.arguments) print(f" [工具调用] {function_name}({arguments})") result = call_function(function_name, arguments) messages.append({ "role": "tool", "tool_call_id": tool_call.id, "content": json.dumps(result, ensure_ascii=False), }) else: print("AI: 工具调用次数过多，已终止。") if __name__ == "__main__": run_conversation()

6.4 运行与验证

python main.py

运行效果示例：

AI 助手已启动，输入 exit 退出。 你可以尝试：现在几点？ 计算 (23*45+12)/7 >>> 现在几点？ [工具调用] get_current_time({}) AI: 当前时间是 2025年03月10日 14:30:22。 >>> 计算 (23*45+12)/7 [工具调用] calculator({'expression': '(23*45+12)/7'}) AI: 计算结果为 149.57142857142858。

6.5 结果说明

这个案例包含三个关键环节：

1. messages.append(message)：不能漏掉模型返回的 assistant 消息，否则工具调用结果无法正确关联。
2. tool_call_id：工具结果必须回传给对应的tool_call_id，模型才能理解这是哪次调用的结果。
3. 循环结构：模型可能多次提出工具调用需求，因此需要使用循环，直到模型不再返回tool_calls为止。

7. 一个极简 RAG 实例

为了帮助理解 RAG 的核心流程，再给出一个不依赖向量数据库的简易版本。生产环境可以在此基础上替换为向量数据库和 Embedding 模型。

7.1 思路与实现

思路：把文档按段落切分，当用户提问时，用简单的关键词相似度选出最相关的段落，拼接到 Prompt 中，再发给大模型。

# 文件路径：simple_rag.py import os from dotenv import load_dotenv from openai import OpenAI load_dotenv() def load_document(path): with open(path, "r", encoding="utf-8") as f: text = f.read() # 按空行切分为段落 paragraphs = [p.strip() for p in text.split("\n\n") if p.strip()] return paragraphs def retrieve(question, paragraphs, top_k=2): # 计算每个段落与问题的简单关键词重合度 question_words = set(question) scored = [] for idx, para in enumerate(paragraphs): score = len(set(para) & question_words) scored.append((score, idx, para)) scored.sort(key=lambda x: x[0], reverse=True) return scored[:top_k] def ask_with_rag(question, doc_path): client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), base_url=os.getenv("OPENAI_BASE_URL", "https://api.openai.com/v1"), ) paragraphs = load_document(doc_path) hits = retrieve(question, paragraphs) context = "\n\n".join([para for _, _, para in hits]) messages = [ {"role": "system", "content": "你是一个基于给定资料回答问题的助手。只根据提供的资料作答，资料中没有的内容要明确说明不知道。"}, {"role": "user", "content": f"资料：\n{context}\n\n问题：{question}"}, ] response = client.chat.completions.create( model=os.getenv("OPENAI_MODEL", "gpt-4o-mini"), messages=messages, ) return response.choices[0].message.content

7.2 运行说明

准备一个.txt格式的知识文档，然后调用：

print(ask_with_rag("公司的年假制度是什么？", "knowledge.txt"))

这个简化版能帮你理解 RAG 的骨架。真正落地时，建议把关键词匹配换成向量检索，引入sentence-transformers或云厂商的 Embedding 接口，再配合向量数据库做大规模检索。

8. 常见问题与排查思路

8.1 高频问题排查表

8.2 排查工具与技巧

建议在开发阶段开启“完整请求日志”，包括：

• 时间戳。
• 入参 messages 大小。
• 模型返回内容。
• 工具调用详情。
• Token 消耗。

这样能快速定位是 Prompt 问题、上下文问题还是模型能力边界问题。

9. 最佳实践与工程建议

结合多个 AI 应用项目的落地经验，整理出下面几条容易踩坑但值得坚持的建议。

9.1 API Key 绝对不能写进代码

把密钥写入环境变量或密钥管理平台，.env文件加入.gitignore。密钥泄漏的后果不仅是经济损失，还可能产生合规风险。

9.2 Prompt 工程要版本化

Prompt 和普通代码一样会持续迭代。建议用一个prompts/目录存放各类 Prompt，遵循“一个场景一个文件”的原则。修改时保留历史版本，并记录不同版本的验证结果。

9.3 先验证效果，再做强封装

不要一开始就引入微服务、消息队列、复杂 Agent 编排框架。先用脚本验证模型输出的质量和稳定性，确认业务可行后再考虑工程架构。

9.4 想清楚模型能力边界

大模型适合做内容生成、意图理解、文本分类、总结归纳等任务。对于精确计算、多步规则校验、强一致性的业务，应让代码处理而不是指望模型。结合 Function Calling 把模型不擅长的事情交给程序。

9.5 安全与合规不能省

• 对用户输入做内容安全检测，防止提示词注入攻击。
• 对模型输出做基础校验，涉及个人信息、法规内容时设人工审核环节。
• 避免让模型访问无关系统权限，所有工具调用遵循最小权限原则。
• 涉及生产环境变更、数据导出的操作，要经过合法授权并保留审计日志。

9.6 成本控制要前置

模型调用成本按 Token 计算，失控的主要场景是长对话、密集重试和 Agent 死循环。建议：

• 设置单用户单日调用上限。
• 对长文本做摘要压缩。
• 为 Agent 设置最大循环次数和超时时间。
• 将高频固定回复命中缓存，减少重复调用。

9.7 日志是 AI 应用调试的生命线

记录每一次请求和响应之外，还要记录“为什么选择这个 Prompt”“为什么触发这次工具调用”。AI 应用比传统应用更依赖可观测性，因为错误往往不是崩溃，而是“悄悄给出了错误答案”。

10. 下一步学习建议

这条极简路线的终点，其实是一个更广阔的技术世界的起点。当你掌握了 API 调用、Prompt 设计、上下文管理和 Agent 基础之后，接下来可以根据你的工作方向做针对性的深入：

• 转向 Web 应用开发：学习 FastAPI / Flask 接口开发，把命令行助手改造成 Web 服务，再结合 Vue / React 做一个可视化聊天窗口。
• 转向业务落地：调研企业知识库场景，把简易 RAG 换成向量数据库方案，处理 PDF、Word 等复杂格式的文档解析。
• 转向后端整合：如果你在 Java / Spring 技术栈，可以关注 Spring AI 等框架，把大模型能力整合进现有的 Spring Boot 项目。
• 转向 Agent 编排：在多工具协作、任务规划、记忆管理方面继续深入，尝试做一个能完成多步骤任务的自动化助手。

无论选择哪条路，都建议保持“每个阶段都有能运行的产物”这个习惯。AI 应用开发和其他技术方向一样，看一百个教程，不如亲手调通一次接口。把上面第 6 节和第 7 节的代码跑起来，再基于自己的业务场景做一次改造，你对 AI 应用开发的理解会比看五篇万字长文更有价值。