`micro-one-api` v0.2.8 正式新增 **Anthropic Messages API 入站端点** `POST /v1/messages`。

这意味着什么?如果你的团队已经用 `micro-one-api` 网关统一管理了上游的 GLM、DeepSeek、Kimi、MiniMax、通义千问、OpenAI-compatible 等渠道,那么现在 **Claude Code CLI 用户只需改两个环境变量**,就能把请求打到你的网关上,由网关选路、鉴权、计费,完全复用你现有的 OpenAI 渠道——**不需要 Anthropic 官方 key,也不需要中间协议转换代理**。

```bash
export ANTHROPIC_BASE_URL=http://your-gateway-host:8080
export ANTHROPIC_API_KEY=your-relay-token
```

下面我们聊聊为什么做这件事、怎么做的、踩了哪些坑,以及这对团队 AI 基础设施意味着什么。

---

## 一、为什么 Claude Code CLI 让网关层很难受

Claude Code CLI 是 Anthropic 推出的命令行编码 Agent。它和大多数 AI Coding 工具有一个关键区别:它**不走 OpenAI 协议**,而是走 Anthropic 原生的 Messages API:

- 端点固定是 `POST /v1/messages`
- 鉴权头固定是 `x-api-key` + `anthropic-version: 2023-06-01`
- 请求/响应是 Anthropic 自有格式(例如 `content blocks`、`system` 顶层字段、`tool_use` / `tool_result` 块)
- 流式响应是 Anthropic 特有的 SSE 事件序列(`message_start` → `content_block_start` → `content_block_delta` → `content_block_stop` → `message_delta` → `message_stop`)

这就带来一个尴尬:很多团队已经建好的 AI 网关(包括我们 `micro-one-api` 的早期版本)是 **OpenAI 协议优先**的,只暴露 `/v1/chat/completions`。结果就是——Claude Code CLI 一上来打 `/v1/messages`,网关直接 `404 page not found`。

你不能要求用户去改 CLI 的协议;你也不能为每个 Anthropic 客户端单独搭一个协议转换代理。**唯一干净的做法,是在网关入站侧补齐 Anthropic Messages 协议**。

这正是 v0.2.8 做的事。

---

## 二、v0.2.8 的核心能力:入站协议适配

我们没有改动任何上游 provider 适配器(出站方向),而是在 `relay-gateway` 的入站侧新增了一个 handler,实现 **Anthropic Messages 协议 ↔ 内部 OpenAI 兼容选路链路**的双向转换。

一句话概括:

> **客户端说 Anthropic 方言,上游讲 OpenAI 方言,网关实时做同声传译。**

### 1. 请求转换(Anthropic → 内部)

| Anthropic 客户端发来的 | 网关转成内部的 |
|---|---|
| 顶层 `system` 字段(string 或 content blocks 数组) | OpenAI 的 `system` role message |
| `messages[].content` 是纯字符串 | 直接映射 |
| `messages[].content` 是 content blocks 数组(`text` / `tool_use` / `tool_result`) | 拆解为 OpenAI 的 `content` / `tool_calls` / `tool` role 消息 |
| `tools[]`(Anthropic 的 `input_schema`) | OpenAI 的 `function` 工具定义(`parameters`) |
| `tool_choice`(auto / any / tool) | OpenAI 的 `auto` / `required` / 具名选择 |

### 2. 响应转换(内部 → Anthropic)

上游返回的 OpenAI 格式 `ChatCompletionsResponse`,会被转回 Anthropic 的 `message` 结构:

```json
{
  "id": "msg_xxx",
  "type": "message",
  "role": "assistant",
  "content": [
    {"type": "text", "text": "2 + 2 equals 4."}
  ],
  "model": "GLM-5.2",
  "stop_reason": "end_turn",
  "usage": {"input_tokens": 26, "output_tokens": 199}
}
```

`finish_reason` 也做了语义映射:`stop`→`end_turn`、`length`→`max_tokens`、`tool_calls`→`tool_use`。

### 3. 流式 SSE 适配(最复杂的部分)

这是整个特性里最 tricky 的地方。OpenAI 的流式是朴素的 `data: {chunk}` 序列,而 Anthropic 是一套**有状态的、分阶段的**事件流:

```
event: message_start        ← 消息骨架(空 usage)
event: content_block_start  ← 开启一个内容块(index 0 = text)
event: content_block_delta  ← 增量文本(text_delta)
event: content_block_stop   ← 关闭内容块
event: message_delta        ← stop_reason + 最终 usage
event: message_stop         ← 结束
```

网关需要在读取 OpenAI chunk 的同时,**实时维护 Anthropic 的"内容块状态机"**:何时开 block、何时发 delta、何时关 block、何时收尾。

### 4. Thinking 模式:一个上线当天就踩到的坑

我们最早只转换 `content` 字段。结果 v0.2.8 部署到线上、用智谱 GLM-5.2 一测,**返回的文本是空的**。

排查后发现:GLM-5.2 是 thinking-mode 模型,它把推理过程放在 `reasoning_content` 字段里,而不是 `content`。DeepSeek-R1 等模型也是同样的模式。

我们立即补上了 thinking 模式支持:把 `reasoning_content` 转换为 Anthropic 的 `thinking` content block,并在流式响应里用 `thinking_delta` 事件逐段输出。等真正的文本内容开始抵达时,再关闭 thinking block、开启 text block。这也是 Anthropic 原生 Claude 模型处理 extended thinking 的方式,所以对 Claude Code CLI 来说是完全自然的。

这个经历也再次说明:**协议适配不能只对着官方文档抄字段名,必须用真实上游跑一遍**。

---

## 三、安全:按 GitHub Security pipeline 标准过一遍

`micro-one-api` 在 `.github/workflows/security.yml` 里配了一套完整的安全流水线:CodeQL、gosec(SAST)、govulncheck(SCA)、gitleaks(密钥扫描)、Trivy、SBOM、license 检查。

v0.2.8 的新代码我们按同样标准做了 code review,发现并修复了 3 个问题:

| 问题 | 风险 | 修复 |
|---|---|---|
| 流式 SSE 写入中途出错会触发二次 `WriteHeader` | 中(连接异常) | header 已写出后改为 `break`,与现有 chat/completions 一致 |
| `Plan()` 失败复用了 OpenAI 错误格式 | 中(Anthropic SDK 无法解析) | 新增 `handleAnthropicPlanError`,返回 Anthropic 错误信封 |
| `max_tokens` 无上限,可被恶意请求拉满 | 低(资源耗尽) | 新增 64000 上限 |

最终扫描结果:**gosec 0 issues / govulncheck 0 vulns / gitleaks 0 leaks**(新代码)。

我们非常欢迎社区继续帮忙做安全审计——所有提交都走这套 pipeline,Issue 和 PR 里发现的安全问题我们会优先处理。

---

## 四、部署体验:一条命令接入

v0.2.8 **无数据库迁移、无配置文件变更**,可以直接滚动更新。

### 管理员侧:更新网关

只需重建并重启 `relay-gateway` 服务(Docker Compose / K8s 均可),其他 8 个服务无需重启。

### 用户侧:配置 Claude Code CLI

```bash
export ANTHROPIC_BASE_URL=http://your-gateway-host:8080
export ANTHROPIC_API_KEY=your-relay-token
```

然后正常使用 `claude` 命令即可。网关会:

1. 校验 token(复用现有 `identity-service` 鉴权链路)
2. 选路(根据模型 → 渠道优先级 → 负载均衡)
3. 预扣额度(`billing-service` reserve)
4. 转换请求并调用上游
5. 转换响应并返回
6. 结算额度 + 写用量日志(按 `/v1/messages` 端点记录)

**这意味着 Claude Code 的每一次调用,都会像 OpenAI 协议的调用一样,完整进入你的账务、用量统计和渠道健康监控体系。**

---

## 五、这对团队 AI 基础设施意味着什么

我们想强调一下 v0.2.8 的战略意义,而不只是"加了个端点":

### 1. 真正的多协议入口

网关现在同时讲两种最重要的 AI API 方言:**OpenAI Chat Completions** 和 **Anthropic Messages**。无论客户端是 OpenAI SDK、LangChain、Claude Code CLI、还是原生 Anthropic SDK,都能用同一套 token、同一套额度、同一个管理后台。

### 2. 上游解耦

你的 Claude Code CLI 用户不需要知道、也不需要拥有 Anthropic 官方 key。网关可以把请求路由到任何你配置好的上游(GLM、DeepSeek、Kimi、MiniMax、通义、本地 Ollama……),只要该渠道在管理后台配了对应模型。

这对成本优化(用更便宜的国产模型替代)、合规(数据不出境)、可用性(上游故障自动切换备用渠道)都有直接价值。

### 3. 统一治理

所有协议的流量都收敛到一套治理体系:鉴权、限流、额度预扣/结算、用量多维聚合、成本/毛利分析、对账、渠道健康探测、Prometheus 指标。**你不用为 Anthropic 流量单独搭一套监控。**

### 4. 面向 Agent 时代

Claude Code CLI 只是 Agent 类工具的开端。这类工具大量使用工具调用(tool_use / tool_result)和流式响应。v0.2.8 已经完整支持 Anthropic 的工具调用协议转换,为后续接入更多 Agent 框架打下了基础。

---

## 六、技术实现要点(给二次开发者)

核心代码集中在 `internal/relay/server/anthropic_inbound.go`(约 900 行),结构清晰:

```
anthropic_inbound.go
├── 请求转换 convertAnthropicToChatCompletions()
│   ├── extractSystemText()        ← system string/array 双形态
│   ├── convertAnthropicMessage()  ← content blocks 拆解
│   ├── convertAnthropicToolsToOpenAI()
│   └── convertAnthropicToolChoiceToOpenAI()
├── 响应转换 convertChatCompletionsToAnthropic()
│   ├── thinking block 支持
│   └── tool_use 还原
├── 流式转换 handleAnthropicStreamingResponse()
│   ├── 内容块状态机(text / thinking 切换)
│   └── usage/stop_reason 收尾
├── 鉴权 extractTokenFromAnthropicRequest()  ← x-api-key + Bearer
├── 计费 复用 reserveQuota / commitQuota / releaseQuota
└── 错误 handleAnthropicPlanError() ← Anthropic 错误信封
```

测试覆盖 11 个用例(`anthropic_inbound_test.go`),涵盖:纯文本、system、content blocks、tool_use、tool_result、响应转换、路由注册、x-api-key 鉴权、Bearer 鉴权、流式事件序列、缺失鉴权拒绝。

如果你正在做类似的协议适配,这份代码可以作为 Anthropic Messages ↔ OpenAI 双向转换的参考实现。

---

## 七、谁适合用 micro-one-api

- 正在用 Claude Code CLI / Anthropic SDK,但希望统一管理多个上游模型渠道的团队。
- 已经有 OpenAI 协议的网关,想低成本补齐 Anthropic 协议入口的开发者。
- 需要为内部用户/团队做 token、额度、用量统计和成本核算的平台型团队。
- 研究 AI API 网关、多协议适配、Go Kratos 微服务实现的工程实践者。
- 正在搭建 AI 中台 / 内部开发者平台,希望网关层能同时服务 OpenAI 和 Anthropic 客户端。

如果你只需要一个极简个人代理,完整微服务架构可能会显得偏重;但如果你关注长期运营、多人管理、账务审计和多协议扩展,它会很有参考价值。

---

## 八、合规与边界提醒

`micro-one-api` 是开源软件,**不提供任何第三方模型服务、账号、订阅、API Key 或代理资源**。

部署者需自行确保:

- 上游 API Key / 账号来源合法,符合上游服务商条款。
- 不用于规避第三方服务的认证、授权、计费、风控、速率限制或区域限制。
- 正确保护用户数据、请求/响应内容、日志和账务数据。
- 生产环境替换默认密钥,配置 HTTPS、限流、访问控制和日志审计。

完整免责声明见仓库 [`DISCLAIMER.md`](https://github.com/mengbin92/micro-one-api/blob/main/DISCLAIMER.md)。

---

## 链接

- 📦 **GitHub**: https://github.com/mengbin92/micro-one-api
- 🏷️ **v0.2.8 Release**: https://github.com/mengbin92/micro-one-api/releases/tag/v0.2.8
- 📖 **发版公告**: [docs/release-v0.2.8.md](https://github.com/mengbin92/micro-one-api/blob/main/docs/release-v0.2.8.md)

---

## 写在最后

AI 应用进入真实业务以后,问题往往不只是"怎么调用模型",而是"怎么稳定、可控、可审计地管理模型调用"。协议多样性(OpenAI / Anthropic / Gemini……)只会越来越多。

`micro-one-api` 的思路是:在网关层就把多协议入口做扎实,让上游解耦、统一治理这些能力自然落地,而不是每来一个新客户端就临时加一个代理。

v0.2.8 向这个方向迈进了一步。如果你对多模型网关、AI API 管理平台或 Go Kratos 微服务实践感兴趣,**欢迎 Star、试用、提 Issue 或参与贡献**。社区的真实反馈(尤其是不同上游模型的适配坑)是我们持续迭代最重要的输入。

> 如果这篇文章对你有帮助,欢迎在 GitHub 给个 ⭐ Star,也欢迎在评论区交流你团队是怎么管理多模型/多协议 API 的。

micro-one-api v0.2.8 正式新增 Anthropic Messages API 入站端点 POST /v1/messages。

让 Claude Code CLI 直接接入你的 AI 网关：micro-one-api v0.2.8 发布

后端

micro-one-api v0.2.8新增Anthropic Messages API支持，实现OpenAI与Anthropic协议双向转换。无需Anthropic官方key，通过网关统一管理GLM、DeepSeek等上游渠道，复用现有鉴权、计费体系。支持流式SSE响应和工具调用，为团队提供多协议入口、统一治理和成本优化能力。

微服务架构

安全审计

负载均衡

日志审计

代码解释

数据库

API管理

DeepSeek

路由

GitHub

Agent

2026年中大促 | AI 领航 智绘未来

apigw

timatrix

cngw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

micro-one-api v0.2.8新增Anthropic Messages API支持，实现OpenAI与Anthropic协议双向转换。无需Anthropic官方key，通过网关统一管理GLM、DeepSeek等上游渠道，复用现有鉴权、计费体系。支持流式SSE响应和工具调用，为团队提供多协议入口、统一治理和成本...

让 Claude Code CLI 直接接入你的 AI 网关：micro-one-api v0.2.8 发布-腾讯云开发者社区-腾讯云

让 Claude Code CLI 直接接入你的 AI 网关：micro-one-api v0.2.8 发布

让 Claude Code CLI 直接接入你的 AI 网关：micro-one-api v0.2.8 发布

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐