这是「程序猿DD」（didispace）开源的 OctaFuse Gateway 昨天发布的 2.10.0 版本说明。先一句话定位：OctaFuse 是一个可自托管、面向 Agent 的开源 AI 网关，把多家供应商的文本/图像/语音/工具能力收进一个 Base URL + 一个 API Key，统一做路由、密钥、预算、计费与审计，TypeScript 实现，支持 Cloudflare D1 / Postgres / MySQL 部署[citation:web:9.52]。
2.10.0 的三个升级，本质是在回答一个问题：「网关和客户端之间，哪些参数该由谁说了算？」
一、路由参数强制覆盖（Force override）
这是本次最核心的功能。背景是：不同模型/供应商对请求格式的要求不一样，有些参数该由客户端自己定，有些请求头/请求体字段却必须固定——客户端一旦漏传或传错，请求就失败。
2.10.0 在 2.9.0「把请求头与请求体默认参数分开配置」的基础上，增加独立的强制覆盖开关：
默认：客户端同名值优先（向后兼容）；
开启请求体强制覆盖：路由配置的值覆盖客户端值；
开启请求头强制覆盖：只锁定 header，不影响 body 的合并方式。
一个具体例子（max_tokens）：
| 场景 | 路由配置 | 客户端传入 | 最终生效 |
|------|:---:|:---:|:---:|
| 未开强制覆盖 | 4096 | 8192 | 8192（客户端优先） |
| 开启强制覆盖 | 4096 | 8192 | 4096（路由锁定） |
它解决的真实痛点也很典型：OpenCode 会校验 x-opencode-session 这个 Header，很多客户端补不了、或传的值不合规，直接被上游拒绝。通过 OctaFuse 在路由里配好这个 Header 并开启强制覆盖，接入这条路由的客户端无需逐个改造，也无法再覆盖这个固定值[citation:web:9.55]。
配置用统一的信封结构表达：
{
"headers": { "HTTP-Referer": "https://example.com", "X-Title": "My App" },
"body": { "max_tokens": 4096, "temperature": 0.7 },
"force_override": { "headers": true, "body": true }
}
几个设计细节值得注意：
force_override 只写要开的那一侧，没写的视为关闭；开关只改变「同名值」的优先级，客户端与路由各自独有的字段仍保留，messages 等请求内容不会被整体替换；
鉴权与传输边界不放开：Authorization、X-API-Key、X-Goog-API-Key、Host、Content-Type、Cookie 等仍由 Gateway 强制控制，路由和客户端都覆盖不了；
历史扁平格式的 custom_params 仍可运行，两侧按「未强制覆盖」处理，新后台保存后自动整理成信封结构。
二、模型入口发现（inbound）
同一个模型可能同时开放 Chat Completions、Responses、Anthropic Messages、Gemini generateContent 多个入口，过去客户端从 /v1/models 只能拿到模型 ID，还得额外约定「该调哪个接口」。2.10.0 在 GET /v1/models 的 model_info 里新增 inbound 字段，直接列出当前可用的请求入口[citation:web:9.55]：
{
"id": "example-model",
"model_info": {
"inbound": [
{ "protocol": "openai", "operation": "responses" },
{ "protocol": "openai", "operation": "chat" },
{ "protocol": "anthropic","operation": "messages" }
]
}
}
关键语义：inbound 描述的是客户端应该调用的协议与操作，不是供应商侧的上游协议，也不表示推荐顺序；目前只汇总 LLM 文本入口，不含图片生成和音频接口。
三、额度变更可追溯
管理员直接修正永久额度时，2.10.0 引入独立的 adminpatchwallet 原因码，并记录调整前后的永久额度总额、已消费金额、当前余额；若同一次还改了周期额度，则归入周期额度调整，两类操作可清晰区分。审计日志的事件类型、来源、原因、操作者、操作来源支持多选组合筛选，排查时能同时保留创建、加额、管理修改等关联记录[citation:web:9.55]。
四、其他更新（简述）
Responses 流式兼容：上游 SSE 缺少顶层 sequence_number 时，网关按当前连接补递增序号；上游已有序号则保持不变，避免严格校验该字段的客户端中断；
新增模型预设：claude-fable-5-1、gpt-6-astra、deepseek-v4.1-flash；
DeepSeek 价格：按最新目录调整 deepseek-v4-flash 价格，保留工作日峰谷配置；已有模型需手动更新新价格，模型目录导入不会覆盖同 ID 数据库记录。
五、升级注意（滚动升级顺序）
本次无新增数据库迁移（完成 2.9.0 的 0028 即可），但因为后台会把路由参数保存为新信封结构，而旧版 Proxy 读不懂新格式，升级顺序必须这样[citation:web:9.55]：
先把所有 Proxy 升级到 2.10.0；
确认旧 Proxy 全部退出流量；
再升级 Admin 并检查关键路由；
最后按需设置请求头/请求体的强制覆盖。
一句话总结这个版本：「普通参数继续交给客户端，关键字段和上游 Header 由网关锁定」——它在不破坏客户端灵活性的前提下，把运维该管的边界收回了网关，同时让模型入口和额度变动都变得可发现、可追溯。
如果你是在选型 AI 网关，或已经在用 OctaFuse 想评估升级，我可以进一步帮你对比它和 LiteLLM / One-API / Kong AI Gateway 在「路由粒度、鉴权边界、计费审计」上的差异，或把这版的 force_override 配置用法整理成一份可直接照抄的 Admin API 示例。
本回答由AI生成，仅供参考，请仔细甄别，谨慎投资
0 评论