1. 从 Prompt 到 Agent大模型应用开发到底在做什么大模型应用开发说白了就是让 LLM 这个“只会聊天的接口”变成能干活的业务组件。它适合后端、前端、数据、测试等任何非 AI 背景的开发者你不需要懂反向传播只要会调 HTTP 接口、会写 JSON就能把大模型接进业务。核心检索词就三个大模型、LLM、RAG、AI Agent、Prompt。我见过太多人卡在第一步以为要先把 Transformer 论文啃完才能动手。其实完全不用。你写后台业务时数据库对你就是个黑盒你只管增删改查大模型应用开发也一样你只管“怎么把问题描述清楚、怎么把外部数据喂进去、怎么让它调用工具”。真正决定应用好坏的往往不是模型本身而是你围绕它做的工程Prompt 设计、RAG 召回质量、Agent 工具编排。一个典型的大模型应用架构和你平时写的服务没本质区别用户请求进来应用层做预处理然后调用 LLM 这个下游服务LLM 返回结果应用层再解析、执行、回填。区别在于LLM 的返回不是固定结构而是自然语言或半结构化 JSON所以你需要用 Prompt 去“约定协议”用代码去“兜底解析”。举个最小例子你让 LLM 提取主谓宾要求输出{subject:,predicate:,object:}。如果你只说“以 JSON 输出”它可能回你一段解释加 JSON你的程序直接解析失败。你必须明确写“只输出 JSON不要任何解释”。这就是 Prompt 工程的第一课把大模型当成一个很聪明但不懂你常识的实习生指令要写到没有歧义。再往上走一层就是 RAG。因为 LLM 的知识来自训练数据训练之后的新知识、你的私有业务文档它一概不知道。你不可能每次把整本手册塞进 Prompt上下文长度有限塞多了还会稀释注意力、增加幻觉。RAG 的思路很直接先根据用户问题去检索最相关的片段再把这几段喂给 LLM让它基于这些片段回答。检索靠的是 Embedding 和向量数据库后面会展开。最后是 AI Agent。问答是你问它答Agent 是你说目标它自己规划步骤、调用工具、多轮推理直到把活干完。比如“帮我查一下今天北京天气如果下雨就提醒我带伞”Agent 会先调天气工具拿到结果后判断是否下雨再决定是否触发提醒。它依赖的是 Function Calling 能力你把工具用 JSON Schema 描述清楚模型在需要时返回tool_calls你的框架执行对应函数把结果回传循环直到模型给出最终答案。这三个模块不是割裂的。Prompt 是基础RAG 是给模型补业务知识Agent 是让模型动手做事。2026 年做应用开发你不需要从零训练模型但必须把这三块串起来才能做出真正有用的东西。接下来我会用 TaoToken 作为统一入口带你从配置 Key 开始一步步跑通 RAG 最小代码和 Agent 工具调用验证。2. TaoToken 统一 Key 配置一次接入多模型省去反复换 Base URL做应用开发最烦的事情之一就是每换一个模型就要改 Base URL、改 Key、改 SDK 初始化代码。今天用这个模型测 Prompt明天换那个模型比效果代码里到处是硬编码。TaoToken 解决的就是这个问题它提供一个统一的 API 入口你用同一个 Key、同一个 Base URL就能调用多家主流大模型。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。为什么这对 RAG 和 Agent 开发特别重要因为 RAG 里你可能需要用 Embedding 模型做向量化用 Chat 模型做生成Agent 里你可能需要不同能力的模型分别处理规划、工具调用、总结。如果每个模型都要单独申请 Key、单独配环境变量工程上会很乱。统一 Key 之后你只需要在配置里改model字段就能切换模型代码结构不变。先拿 Key。进入控制台在 API Keys 页面创建一个新 Key。建议按项目命名比如rag-demo、agent-test方便后续排查。创建后立刻复制保存页面刷新后就不再完整显示。这个 Key 就是你所有请求的凭证不要提交到 Git不要写在前端代码里。拿到 Key 后配置环境变量。Linux/macOS 下可以这样export TAOTOKEN_API_KEYsk-你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/apiWindows PowerShell$env:TAOTOKEN_API_KEYsk-你的Key $env:TAOTOKEN_BASE_URLhttps://taotoken.net/api如果你用 PythonOpenAI SDK 兼容方式最省事import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 用一句话解释什么是 RAG}], ) print(resp.choices[0].message.content)如果你用 Node.jsimport OpenAI from openai; const client new OpenAI({ apiKey: process.env.TAOTOKEN_API_KEY, baseURL: process.env.TAOTOKEN_BASE_URL, }); const resp await client.chat.completions.create({ model: gpt-4o-mini, messages: [{ role: user, content: 用一句话解释什么是 RAG }], }); console.log(resp.choices[0].message.content);如果你用 Claude Code 这类工具配置方式略有不同。Claude Code 的 settings 文件通常放在~/.claude/settings.json你需要写入 Base URL、Key 和 Model ID 三件套{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的Key, ANTHROPIC_MODEL: claude-3-5-sonnet-20241022 } }注意Claude Code 走的是 Anthropic 兼容协议Base URL 同样是https://taotoken.net/api但环境变量名是ANTHROPIC_*。如果你用 Cline 或 CC Switch 这类支持 MCP 的工具配置里同样要写全三件套Base URL、API Key、Model ID。Cline 的配置一般在 VS Code 设置里搜索 Cline找到 API Provider 选 OpenAI CompatibleBase URL 填https://taotoken.net/apiAPI Key 填你的 KeyModel ID 填你要用的模型名。如果你用 Codex它的auth.json通常在~/.codex/auth.json配置结构类似{ api_key: sk-你的Key, base_url: https://taotoken.net/api, model: gpt-4o-mini }这里有个坑不同工具的配置字段名不一样有的叫base_url有的叫baseURL有的叫ANTHROPIC_BASE_URL。你复制配置时一定要看清工具文档别把 OpenAI 的字段名塞进 Claude Code 的 settings 里。另外Model ID 必须写对比如gpt-4o-mini、claude-3-5-sonnet-20241022、deepseek-chat这些写错了会直接报模型不存在。统一 Key 的另一个好处是你可以在代码里做一个模型路由层。比如 RAG 的 Embedding 用text-embedding-3-small生成用gpt-4o-miniAgent 的规划用claude-3-5-sonnet全部走同一个 client只改 model 参数。这样你后续做效果对比、成本优化时切换成本极低。3. RAG 最小可运行代码Chunk、Embedding、检索、生成四步走RAG 听起来高大上拆开就是四步把文档切块Chunk把块向量化Embedding把向量存起来并检索把检索结果拼进 Prompt 让 LLM 生成答案。这一章我给你一个最小可运行版本你复制到本地就能跑。依赖只有两个openai和numpy向量存储先用内存里的 list不引入向量数据库方便你理解流程。先安装依赖pip install openai numpy然后准备一份小文档比如knowledge.txt内容随便写几段模拟你的业务知识库。我这里用一段关于“退货政策”的文本退货政策自签收之日起 7 天内商品未拆封且不影响二次销售可以申请无理由退货。 超过 7 天但在 15 天内如果商品存在质量问题可以申请换货或维修。 定制类商品不支持无理由退货但如果是质量问题可以联系客服协商。 退款将在审核通过后 3 到 5 个工作日原路返回。接下来是完整代码。第一步读取文档并按段落切块。实际项目中你会用更复杂的 Chunk 策略这里先用最简单的按空行切import os import numpy as np from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) def load_and_chunk(path): with open(path, r, encodingutf-8) as f: text f.read() chunks [c.strip() for c in text.split(\n) if c.strip()] return chunks chunks load_and_chunk(knowledge.txt) print(f共切出 {len(chunks)} 个 chunk)第二步对每个 chunk 做 Embedding。这里用text-embedding-3-small你也可以换成其他 Embedding 模型只要 TaoToken 支持def embed_texts(texts): resp client.embeddings.create( modeltext-embedding-3-small, inputtexts, ) return [item.embedding for item in resp.data] chunk_vectors embed_texts(chunks) chunk_vectors np.array(chunk_vectors) print(f向量维度{chunk_vectors.shape})第三步检索。用户提问后把问题也做 Embedding然后算余弦相似度取 TopKdef cosine_similarity(a, b): a np.array(a) b np.array(b) return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) def retrieve(query, top_k2): query_vec embed_texts([query])[0] scores [cosine_similarity(query_vec, vec) for vec in chunk_vectors] ranked sorted(range(len(scores)), keylambda i: scores[i], reverseTrue) return [chunks[i] for i in ranked[:top_k]] query 我买了东西超过7天还能退吗 retrieved retrieve(query) for i, r in enumerate(retrieved): print(f[{i}] {r})第四步把检索结果拼进 Prompt调用 Chat 模型生成答案def rag_answer(query): context \n.join(retrieve(query)) prompt f你是一个客服助手。请严格根据以下资料回答用户问题如果资料中没有相关信息就说“资料中未提及”。 资料 {context} 用户问题{query} resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], temperature0.2, ) return resp.choices[0].message.content print(rag_answer(我买了东西超过7天还能退吗))跑通后你会看到模型基于检索到的“超过 7 天但在 15 天内如果商品存在质量问题可以申请换货或维修”来回答而不是瞎编。这就是 RAG 的最小闭环。但你要知道这个版本离生产还有距离。Chunk 按空行切太粗暴遇到长段落会切出超长块Embedding 质量下降检索只用了向量相似度没有重排序没有处理多轮对话历史。实际优化方向包括按语义切块、加滑动窗口保留上下文、用 BM25 加向量混合检索、加一个重排序模型对 TopN 做二次排序。这些才是 RAG 的核心竞争力也是你后续要花时间打磨的地方。另外Embedding 模型的选择很关键。自然语言文档用通用 Embedding 模型没问题但代码仓库要用 code embedding 模型否则检索出来的代码片段相关性很差。TaoToken 支持多种 Embedding 模型你可以在控制台看模型列表按业务场景选。4. Agent 工具调用验证从 Function Calling 到多步推理Agent 的核心是让模型自己决定调用哪个工具、传什么参数、什么时候结束。这一章我用一个“天气查询 穿衣建议”的最小 Agent 来验证工具调用链路。你需要先理解 Function Calling 的交互流程你先把工具用 JSON Schema 描述给模型模型返回tool_calls你执行函数把结果以role: tool的消息回传模型再决定下一步。先定义两个工具查天气和查温度建议。实际项目中你会调真实 API这里用 mock 函数模拟import json import os from openai import OpenAI client OpenAI( api_keyos.environ[TAOTOKEN_API_KEY], base_urlos.environ[TAOTOKEN_BASE_URL], ) def get_weather(city: str) - dict: mock { 北京: {temp: 2, condition: 晴, wind: 3级}, 上海: {temp: 8, condition: 小雨, wind: 2级}, } return mock.get(city, {temp: 15, condition: 多云, wind: 1级}) def get_clothing_advice(temp: int, condition: str) - str: if temp 5: return 建议穿羽绒服注意保暖。 elif temp 15: return 建议穿外套加毛衣。 else: return 建议穿长袖或薄外套。然后把工具描述成 JSON Schema传给模型tools [ { type: function, function: { name: get_weather, description: 查询指定城市的当前天气, parameters: { type: object, properties: { city: {type: string, description: 城市名如北京} }, required: [city], }, }, }, { type: function, function: { name: get_clothing_advice, description: 根据温度和天气状况给出穿衣建议, parameters: { type: object, properties: { temp: {type: integer, description: 温度摄氏度}, condition: {type: string, description: 天气状况}, }, required: [temp, condition], }, }, }, ]接下来是 Agent 循环。你发一条用户消息模型可能直接回答也可能返回tool_calls。如果是后者你执行对应函数把结果追加到消息列表再次调用模型直到模型不再请求工具def run_agent(user_input: str, max_steps: int 5): messages [{role: user, content: user_input}] for step in range(max_steps): resp client.chat.completions.create( modelgpt-4o-mini, messagesmessages, toolstools, tool_choiceauto, ) msg resp.choices[0].message messages.append(msg) if not msg.tool_calls: return msg.content for call in msg.tool_calls: name call.function.name args json.loads(call.function.arguments) if name get_weather: result get_weather(**args) elif name get_clothing_advice: result get_clothing_advice(**args) else: result {error: unknown tool} messages.append({ role: tool, tool_call_id: call.id, content: json.dumps(result, ensure_asciiFalse), }) return 达到最大步数未完成。 print(run_agent(北京今天天气怎么样我该穿什么))跑通后你会看到类似输出模型先调get_weather拿到北京 2 度晴再调get_clothing_advice拿到“建议穿羽绒服”最后生成一句完整回答。这就是多步推理加工具调用的完整链路。这里有几个验证点。第一tool_choiceauto让模型自己决定是否调工具你也可以强制tool_choice{type:function,function:{name:get_weather}}来测试单个工具。第二tool_call_id必须原样回传否则模型无法对应结果。第三如果模型返回的arguments不是合法 JSON你的json.loads会抛异常生产环境要加 try/except 兜底。如果你用 Claude Code 或 Cline 这类支持 MCP 的工具工具注册方式不同但底层逻辑一样MCP Server 启动后告诉 Client 自己有哪些工具Client 把工具列表转成模型能理解的 Schema模型返回调用请求Client 执行并回传。你可以把上面的 Python 函数包装成 MCP Server就能被 Claude Code 直接调用。MCP 的 stdio 模式适合本地工具HTTP/SSE 模式适合远程服务配置时注意区分。Agent 的难点不在单次调用而在多步规划和错误恢复。比如模型调了不存在的工具、参数类型不对、工具执行超时你都需要在循环里处理。实际项目中建议加日志把每一步的messages打出来方便排查模型为什么“想歪了”。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一章我按真实报错来梳理。你跑上面代码时大概率会遇到这几类问题。第一类401 Unauthorized。报错信息通常是Error code: 401 - {error: {message: Invalid API key}}。原因很简单Key 错了、过期了、或者环境变量没生效。排查步骤先确认echo $TAOTOKEN_API_KEY能打印出 Key且没有多余空格再确认 Key 没有在控制台被删除最后确认 Base URL 是https://taotoken.net/api不是官网首页。如果你用 Claude Code401 可能是ANTHROPIC_API_KEY没配或者配成了 OpenAI 的 Key。注意Claude Code 走 Anthropic 协议Key 要用对应格式。第二类local proxy failed。这个报错常见于 Cline、Claude Code 这类工具意思是本地代理启动失败或连接不上。原因通常是 Base URL 填错、网络不通、或者工具配置里开了代理但代理没启动。排查先确认https://taotoken.net/api能通可以用curl -I https://taotoken.net/api测试再检查工具配置里的 Base URL 有没有多写斜杠或路径最后确认没有配置额外的本地代理端口。如果你在 settings.json 里写了ANTHROPIC_BASE_URL确保没有拼写错误。第三类reading choices。这个报错通常是TypeError: NoneType object is not subscriptable或KeyError: choices出现在你解析响应时。原因是 API 返回结构和你预期不一致可能是模型名写错、请求被拒绝、或者返回了错误对象。排查先把原始响应print(resp)打出来看是choices为空还是整个响应是 error。常见原因是 Model ID 不存在比如你写了gpt-4o但实际可用的是gpt-4o-mini。另外如果你用了流式输出但没处理delta也会出现类似问题。第四类OAuth 相关报错。这个多见于 Claude Code 或 Codex 的登录流程。报错可能是OAuth token expired或failed to refresh token。原因是工具尝试用 OAuth 方式认证但你配置的是 API Key 方式。解决检查工具配置确保认证方式选的是 API Key而不是 OAuth。Claude Code 的 settings.json 里如果同时有 OAuth 和 API Key 配置可能会冲突建议只保留 API Key 三件套ANTHROPIC_BASE_URL、ANTHROPIC_API_KEY、ANTHROPIC_MODEL。除了这四类还有几个高频坑。一是model not foundModel ID 写错去控制台看可用模型列表。二是rate limit exceeded请求太频繁加个 sleep 或降低并发。三是context length exceededPrompt 太长RAG 检索的 TopK 调小或者换更大上下文的模型。四是tool_calls解析失败模型返回的 arguments 不是合法 JSON加 try/except 并让模型重新生成。排查时记住一个原则先看原始响应再看你的解析代码。大部分问题出在配置和模型名而不是代码逻辑。把print(resp)和print(messages)加上能省很多时间。6. 把统一 Key、RAG 和 Agent 串成你的开发工作流到这里你已经有了统一 Key 配置、RAG 最小闭环、Agent 工具调用验证以及一套排错方法。接下来要做的是把它们串成你日常的开发工作流。我的建议是分三层推进。第一层先用 TaoToken 统一 Key 把模型调用跑通确认 Chat、Embedding、Function Calling 都能正常工作。第二层拿你手头最熟悉的一份业务文档跑通 RAG 最小版本然后逐步优化 Chunk 和检索策略观察回答质量变化。第三层挑一个你每天重复做的小任务比如查数据、发通知、整理文件把它包装成工具用 Agent 循环跑起来。在这个过程中TaoToken 的价值会越来越明显你不需要为每个模型单独维护 Key 和 Base URL切换模型只改一个字段。RAG 的 Embedding 和生成可以用不同模型Agent 的规划和执行也可以用不同模型全部走同一个入口。这样你才能把精力放在 Prompt 设计、Chunk 策略、工具编排这些真正决定效果的地方。如果你还没拿 Key去控制台创建一个然后从模型对话页面先测一条请求确认链路通。接入文档里有各语言的示例代码遇到问题先对照文档检查 Base URL 和 Model ID。长期做编码和 Agent 的话可以关注 Coding Plan它更适合高频调用场景。最后说一个我自己的经验RAG 和 Agent 的效果八成取决于你的数据和工具设计而不是模型本身。Chunk 切得好、工具描述得清楚小模型也能跑出好结果Chunk 切得烂、工具参数模糊再强的模型也救不回来。所以别急着换模型先把你的文档切块和工具 Schema 打磨好。