企业官网建设流程全解析

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_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_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_KEY="sk-你的Key" export TAOTOKEN_BASE_URL="https://taotoken.net/api"

Windows PowerShell：

$env:TAOTOKEN_API_KEY="sk-你的Key" $env:TAOTOKEN_BASE_URL="https://taotoken.net/api"

如果你用 Python，OpenAI SDK 兼容方式最省事：

import os from openai import OpenAI client = OpenAI( api_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"], ) resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": "用一句话解释什么是 RAG"}], ) print(resp.choices[0].message.content)

如果你用 Node.js：

import 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 Compatible，Base URL 填https://taotoken.net/api，API Key 填你的 Key，Model 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-mini，Agent 的规划用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_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.environ["TAOTOKEN_BASE_URL"], ) def load_and_chunk(path): with open(path, "r", encoding="utf-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( model="text-embedding-3-small", input=texts, ) 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，然后算余弦相似度，取 TopK：

def 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_k=2): query_vec = embed_texts([query])[0] scores = [cosine_similarity(query_vec, vec) for vec in chunk_vectors] ranked = sorted(range(len(scores)), key=lambda i: scores[i], reverse=True) 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( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.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_key=os.environ["TAOTOKEN_API_KEY"], base_url=os.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( model="gpt-4o-mini", messages=messages, tools=tools, tool_choice="auto", ) 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_ascii=False), }) return "达到最大步数，未完成。" print(run_agent("北京今天天气怎么样？我该穿什么？"))

跑通后你会看到类似输出：模型先调get_weather拿到北京 2 度晴，再调get_clothing_advice拿到“建议穿羽绒服”，最后生成一句完整回答。这就是多步推理加工具调用的完整链路。

这里有几个验证点。第一，tool_choice="auto"让模型自己决定是否调工具，你也可以强制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 Code，401 可能是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 found，Model ID 写错，去控制台看可用模型列表。二是rate limit exceeded，请求太频繁，加个 sleep 或降低并发。三是context length exceeded，Prompt 太长，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 打磨好。