用 LongCat 开放平台接入大模型 API：双协议端点配置与首次调用

LongCat 开放平台是美团 LongCat 团队推出的大模型 API 服务，面向开发者与企业用户提供开箱即用的模型调用能力。它最值得注意的一点是原生兼容 OpenAI 与 Anthropic 两套协议标准：如果你的项目已经在用 OpenAI 的 SDK 或 Anthropic 的 SDK，通常只需要替换 base URL 与密钥，业务代码基本不用动。平台支持单次 128K tokens 的上下文窗口，适合长文档分析、多轮复杂对话这类任务。本文要解决的问题很具体：从零完成一次可运行的 API 调用，并把已有代码平滑迁移到 LongCat 的端点上。如果你只是想先看看这个平台是什么，可以查阅 LongCat 开放平台 的条目介绍；下面进入实操。

准备工作

账号与密钥

开始之前需要准备三样东西：一个可用的邮箱账号、一个 LongCat 开放平台账号、以及一把 API Key。

1. 打开 LongCat 开放平台的控制台页面，用邮箱完成注册。注册流程是标准的邮箱验证，不需要企业资质即可开始试用。
2. 登录后进入控制台的「API Keys」页面。系统会为账号自动生成一把默认密钥，可以直接使用；也可以按项目另行创建，便于后续区分调用来源与做权限隔离。
3. 把密钥复制下来保存到本地。密钥属于敏感凭据，不要写进前端代码、不要提交到公开仓库，建议放在环境变量或密钥管理服务里。

两个 API 入口

LongCat 提供两个不同风格的 API 入口，选哪个取决于你现有代码用的是哪套 SDK：

协议风格	Base URL	适用场景
OpenAI 风格	https://api.longcat.chat/openai	项目使用 OpenAI SDK、OpenAI 兼容客户端，或按 /chat/completions 路径发请求
Anthropic 风格	https://api.longcat.chat/anthropic	项目使用 Anthropic SDK，或按 /v1/messages 路径发请求

两个入口背后是同一套模型能力，差别只在请求与响应的报文格式。选错入口的典型症状是请求返回 404 或参数校验失败，遇到这种情况先检查 base URL 是否与所用 SDK 匹配。

运行环境

客户端侧没有特殊要求，任何能发 HTTPS 请求的环境都可以。用 Python 的话建议 3.8 以上，并准备好对应 SDK；用 curl 做连通性测试则不需要装任何东西。下文示例统一用环境变量承载密钥，这样命令可以原样复制执行：

export LONGCAT_API_KEY="你的密钥"
export LONGCAT_OPENAI_BASE="https://api.longcat.chat/openai"
export LONGCAT_ANTHROPIC_BASE="https://api.longcat.chat/anthropic"

Windows 的命令行环境请改用 set 或 $env: 语法设置同名变量，变量名保持一致即可。

操作步骤

第一步：用 curl 验证密钥与端点是否连通

在写任何业务代码之前，先用最小请求确认三件事：网络能通、密钥有效、端点路径正确。这一步能省掉后面大量排查时间。

OpenAI 风格入口的连通性测试：

curl -s "$LONGCAT_OPENAI_BASE/chat/completions" \
  -H "Authorization: Bearer $LONGCAT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "你的模型名",
    "messages": [
      {"role": "user", "content": "用一句话说明什么是 MoE 架构"}
    ]
  }'

Anthropic 风格入口的连通性测试：

curl -s "$LONGCAT_ANTHROPIC_BASE/v1/messages" \
  -H "x-api-key: $LONGCAT_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "你的模型名",
    "max_tokens": 256,
    "messages": [
      {"role": "user", "content": "用一句话说明什么是 MoE 架构"}
    ]
  }'

注意两种风格在鉴权头上不同：OpenAI 风格用 Authorization: Bearer，Anthropic 风格用 x-api-key，并且需要带上 anthropic-version 头。这是迁移时最容易漏掉的一处差异。

返回 200 并带有模型输出，说明链路已经打通。如果返回 401，检查密钥是否复制完整、是否带了多余空格；返回 404，检查 base URL 与路径拼接是否正确，注意 base URL 本身已经包含了协议风格前缀，不要再重复拼一次。

第二步：在 OpenAI SDK 中切换 base URL

已有 OpenAI 项目的迁移成本最低。以 Python 为例，初始化客户端时把 base_url 指向 LongCat 的 OpenAI 风格入口，密钥从环境变量读取：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LONGCAT_API_KEY"],
    base_url=os.environ["LONGCAT_OPENAI_BASE"],
)

resp = client.chat.completions.create(
    model="你的模型名",
    messages=[
        {"role": "system", "content": "你是一名严谨的技术文档编辑。"},
        {"role": "user", "content": "把下面这段需求整理成三条验收标准：……"},
    ],
)

print(resp.choices[0].message.content)

除了 api_key 与 base_url 两个参数，其余调用方式与原来完全一致：messages 的结构、choices 的取值路径、流式输出的处理逻辑都不需要改。这也是双协议兼容的实际价值——迁移是配置层面的动作，不是重写。

如果项目里有多处硬编码了 OpenAI 的官方地址，建议统一收敛到一个配置模块，通过环境变量切换，避免散落各处的地址在迁移时被漏掉。

第三步：在 Anthropic SDK 中切换 base URL

使用 Anthropic SDK 的项目同理，把 base_url 指向 Anthropic 风格入口：

import os
from anthropic import Anthropic

client = Anthropic(
    api_key=os.environ["LONGCAT_API_KEY"],
    base_url=os.environ["LONGCAT_ANTHROPIC_BASE"],
)

msg = client.messages.create(
    model="你的模型名",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "总结这份合同里的违约责任条款要点。"},
    ],
)

print(msg.content[0].text)

Anthropic 风格的响应内容是一个内容块数组，取文本时要按块遍历，而不是直接取字符串字段。这一点在把结果接入下游系统时容易出错，建议在封装层统一做一次归一化，把两种协议的返回都转成同一种内部结构。

第四步：处理长上下文任务

平台支持单次 128K tokens 的上下文，这决定了一些任务可以直接做，而不必先切块再拼接。典型做法是把整份文档放进 messages 里，配合明确的指令让模型输出结构化结果：

with open("contract.txt", encoding="utf-8") as f:
    doc = f.read()

resp = client.chat.completions.create(
    model="你的模型名",
    messages=[
        {"role": "system", "content": "你是合同审阅助手，只依据原文作答，找不到依据时明确说明。"},
        {"role": "user", "content": f"请从以下合同中提取：签约方、生效日期、违约责任、争议解决方式。\n\n{doc}"},
    ],
)

长上下文不等于可以无限塞。输入越长，单次请求消耗的 tokens 越多，响应时间也会变长。做批量文档处理时，建议先估算单份文档的 token 量，再决定是一份一请求还是合并处理。另外，长文档任务里把「找不到依据时明确说明」这类约束写进 system 提示，能显著减少模型凭空补全的情况。

第五步：在沙箱环境完成验证

正式接入生产系统之前，先在沙箱环境把功能跑通。验证清单建议覆盖以下几项：

• 正常请求：单轮问答能返回预期内容。
• 多轮对话：把历史消息按顺序追加进 messages，确认上下文能被正确理解。
• 长输入：用接近上限的长文档测试一次，观察是否被截断、耗时是否可接受。
• 异常分支：故意用错误密钥、错误模型名各发一次请求，确认你的代码能正确捕获并处理错误码，而不是静默失败。
• 流式输出：如果产品需要逐字显示，确认流式模式下的分块拼接逻辑正确。

这几项都通过之后，再把配置切到生产环境，并同步调整密钥管理方式。

一个完整示例

下面是一个从读取文档、调用模型到写出结果的最小可运行脚本，用 OpenAI 风格入口，覆盖了配置、请求、错误处理与结果落盘四个环节：

import os
import json
from openai import OpenAI, APIError, APIConnectionError

client = OpenAI(
    api_key=os.environ["LONGCAT_API_KEY"],
    base_url=os.environ["LONGCAT_OPENAI_BASE"],
)

SYSTEM_PROMPT = (
    "你是技术文档摘要助手。输出必须是 JSON，包含 summary 与 keywords 两个字段，"
    "keywords 为字符串数组，最多五个。不要输出 JSON 以外的任何内容。"
)

def summarize(path: str) -> dict:
    with open(path, encoding="utf-8") as f:
        text = f.read()

    try:
        resp = client.chat.completions.create(
            model="你的模型名",
            messages=[
                {"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": text},
            ],
        )
    except APIConnectionError as e:
        raise RuntimeError(f"网络连接失败：{e}") from e
    except APIError as e:
        raise RuntimeError(f"接口返回错误：{e}") from e

    raw = resp.choices[0].message.content.strip()
    return json.loads(raw)

if __name__ == "__main__":
    result = summarize("input.txt")
    with open("result.json", "w", encoding="utf-8") as f:
        json.dump(result, f, ensure_ascii=False, indent=2)
    print(result["summary"])

运行前确认三件事：LONGCAT_API_KEY 与 LONGCAT_OPENAI_BASE 已导出；model 字段填的是账号可用的模型名；当前目录下有 input.txt。执行 python summarize.py，成功时会在当前目录生成 result.json。

这个脚本有两个值得保留的设计。一是把 system 提示里的输出格式约束写死，让下游可以直接 json.loads，减少解析失败；二是把网络错误与接口错误分开捕获，便于在日志里区分是链路问题还是参数问题。生产环境还应在此基础上加上重试与超时控制。

如果要把这个脚本改成 Anthropic 风格，只需替换客户端初始化与结果取值两处：客户端换成 Anthropic(api_key=..., base_url=os.environ["LONGCAT_ANTHROPIC_BASE"])，请求换成 client.messages.create(...) 并补上 max_tokens，结果从 msg.content[0].text 取。提示词与业务逻辑不用动。

注意事项

免费额度与计费

注册用户每日可获得一定量的免费 tokens 调用额度，超出后按平台规则计费。免费额度的具体数值、重置时间、是否按账号还是按密钥计算，以及各模型的单价，都可能调整，请以官网控制台当前展示的信息为准。做成本估算时不要依赖本文或任何第三方文章里的数字。

上下文上限

128K tokens 是单次请求的上下文窗口上限，输入与输出共享这个预算。把超长文档整段塞入时，要预留输出所需的空间，否则可能因为超出上限而报错或被截断。分批处理长文档时，注意跨批次的语义衔接，避免摘要结果前后矛盾。

协议差异带来的坑

• 鉴权头不同：OpenAI 风格用 Authorization: Bearer，Anthropic 风格用 x-api-key。
• Anthropic 风格需要 anthropic-version 请求头，且 max_tokens 通常是必填项。
• 响应结构不同：前者取 choices[0].message.content，后者取 content[0].text。
• base URL 已包含风格前缀，拼接路径时不要重复添加 /v1 之类的前缀。

密钥与数据安全

平台提供独立密钥管理与请求审计日志，传输链路加密。实践上仍应做到：按项目或环境分配不同密钥，便于出问题时快速定位与吊销；不要把密钥写进客户端代码；定期轮换密钥。涉及敏感数据的场景，先确认平台的合规与隐私策略是否满足所在行业的要求，再决定是否接入。

模型名与可用性

请求中的 model 字段必须填账号实际可用的模型标识。不同账号、不同地区可用的模型可能不同，具体以控制台列出的清单为准。模型下线或更名时，硬编码模型名的代码会直接失败，建议把模型名也放进配置层统一管理。

错误处理与重试

生产环境务必为请求设置超时，并对限流类错误做退避重试。不要对所有错误一律重试——参数错误、鉴权失败这类问题重试多少次都不会成功，反而会放大日志噪音。建议按错误码分类处理：可重试的走退避，不可重试的直接抛出并告警。

上线前的最后检查

切换生产前，再确认一遍：环境变量在生产环境已正确注入；密钥权限范围符合最小必要原则；日志里不会打印完整密钥与用户原文；监控能覆盖请求失败率与耗时；成本告警阈值已设置。这几项做完，接入工作才算真正收尾。