866ai

从零调用大模型 API：写出第一个可用的对话程序

· 4 次浏览 ·来源: 866ai
本文提供一步步的实操指引，帮助读者完成从环境配置、密钥申请到编写第一个对话程序的全过程。文章涵盖了请求结构的构建、流式输出的实现以及常见错误的排查方法，读者将能够快速上手并获得可运行的代码示例。

环境准备与密钥申请

在编写代码之前，首先需要确保运行环境已就绪。大多数读者选择使用 Python 作为调用大模型 API 的语言，因此需要先安装 Python 3.8 或更高版本。建议使用虚拟环境来隔离项目依赖，这可以通过命令 python -m venv myenv 创建，随后使用 source myenv/bin/activate（Linux/Mac）或 myenv\Scripts\activate（Windows）进入环境。

在获取 API 密钥之前，需要前往所选大模型平台的官方控制台注册账户并创建应用。平台通常会提供一组密钥，包括密钥 ID 和密钥秘钥，这些信息将用于身份验证。请务必将密钥信息妥善保存，避免在代码中明文硬编码导致泄露。对于初次使用，建议先查看平台文档，了解不同模型版本的定价和配额限制，以免后续因超出配额而中断调试。

编写首个对话请求

有了环境和密钥后，接下来编写实际的请求代码。以 OpenAI 兼容的 API 为例，核心在于构建符合规范的 JSON 请求体。最基础的对话请求通常包含模型名称和消息列表，消息列表中每一条记录都包含角色（如 user 或 assistant）和对应的内容文本。以下是一个最简 Python 代码片段，展示如何使用 requests 库发送请求：

import requests
import json

api_key = "your-api-key-here"
url = "https://api.example.com/v1/chat/completions"
headers = {
    "Authorization": f"Bearer {api_key}",
    "Content-Type": "application/json"
}
payload = {
    "model": "glm-4",
    "messages": [
        {"role": "user", "content": "你好，请介绍一下今天的天气。"}
    ]
}
response = requests.post(url, headers=headers, json=payload)
print(response.json())

在上述代码中，需要将占位符 your-api-key-here 替换为实际获得的密钥。model 字段决定了调用哪一个具体的大模型版本，不同平台的模型名称命名规则各异，请务必使用平台文档中提供的准确名称。messages 数组是对话历史的载体，首次调用时通常只包含一条 user 角色的消息，后续的交互可以通过累加历史消息来实现上下文的连贯性。

处理流式输出与响应

大模型的响应通常不是一次性返回完整结果，而是通过流式传输的方式逐块返回。这对于需要实时展示结果的界面非常有用。在代码层面，需要在请求 payload 中开启流式选项，并重写响应的处理逻辑。以同样基于 requests 的示例，只需在 payload 中添加 "stream": true，并配合 stream=True 参数一起使用 requests.post：

response = requests.post(url, headers=headers, json=payload, stream=True)
for line in response.iter_lines():
    if line:
        decoded = line.decode('utf-8')
        if decoded.startswith("data: "):
            chunk = decoded[len("data: "):]
            if chunk != "[DONE]":
                import json as j
                data = j.loads(chunk)
                # 在这里处理每一块返回的文本，通常在 data.choices[0].delta.content 中能找到新生成的内容片段
                print(data.get("choices", [{}])[0].get("delta", {}).get("content", ""), end="", flush=True)
print()

流式输出的关键在于逐行读取响应，每一行通常以 "data: " 开头，后面跟着一段 JSON 数据。读取时需要过滤掉结束标记 "[DONE]"，并从嵌套的字段中提取实际的文本内容。这种方式可以显著降低 perceived latency（感知延迟），用户可以在模型思考的同时看到第一部分的文本输出，体验更加流畅。

常见错误排查与最佳实践

在实际操作中，初学者最常遇到的问题通常与请求参数配置或网络连接有关。最典型的错误是返回 "401 Unauthorized"，这通常意味着 API 密钥输入错误、过期或缺少授权头部。请仔细检查 Authorization header 的格式是否为 "Bearer " 后面跟着空格和实际密钥，以及密钥是否具有调用目标模型的权限。

另一个常见问题是 "400 Bad Request"，这往往是因为请求体的结构不符合 API 规范。例如，消息角色只能是 "system"、"user" 或 "assistant"，内容字段不能为空，或者模型名称拼写错误。针对这些情况，建议先使用平台提供的 "Playground" 或 "Console" 界面进行简单的手工测试，确认请求格式无误后再回到代码中复现。此外，注意观察返回的 HTTP 状态码和错误信息体，大多数平台都会在 JSON 响应中提供具体的错误码和建议的修正方案，阅读这些信息是解决问题的最快途径。

为了保证调用的稳定性，还有一些不成文的最佳实践值得注意。首先，对于生产环境的代码，建议实现密钥的环境变量读取，而不是直接在源码中写死，可以使用 os.environ.get("API_KEY") 来获取，这样可以避免代码被意外提交到公开仓库。其次，合理设置请求超时时间，防止因模型长时间未响应而导致程序卡死。最后，关注平台的速率限制（Rate Limit），如果在短时间内发送了大量请求，可能会触发请求被拒绝，此时应实现指数回退重试机制或适当降低请求频率。