4.6 KiB
Pipeline v2 Model Proxy Architecture
Pipeline v2 procedure runner 通过 model proxy 链路将容器内 OpenCode 的模型请求路由到外部 API 提供商。本文档记录 proxy 链路的稳定架构、各 model 组件的差异和 D601 宿主服务部署约束。
Proxy Chain 总体架构
OpenCode (container)
↓ HTTP (127.0.0.1:17655)
In-container model proxy (opencodeContainerHarness)
↓ HTTP/HTTPS
Upstream origin (per model config)
↓ (if host proxy)
External API provider (HTTPS)
每个 model 组件在 config.json 的 proxy 字段声明 in-container proxy 的监听端口和上游地址。OpenCode 的 provider config 中 baseUrl 固定指向 http://127.0.0.1:{proxy.port}/{path},由 harness 在容器启动时写入。
In-container proxy 的职责:
- 注入 auth token(从容器环境变量读取,按
ANTHROPIC_AUTH_TOKEN→ANTHROPIC_API_KEY→OPENAI_API_KEY优先级查找) - 429 rate limit 自动重试与 quota pause 计时(暂停时间不计入 node active timeout)
- 请求/响应透传(streaming 兼容)
Model 组件 Proxy 配置对比
| Model | proxy.upstreamOrigin | 宿主服务 | Auth env |
|---|---|---|---|
minimax-m27 |
https://api.minimaxi.com |
无(容器直连) | ANTHROPIC_AUTH_TOKEN |
gpt-5.5 |
http://host.docker.internal:17680 |
hyueapi-proxy.service |
OPENAI_API_KEY |
minimax-m27(直连模式)
容器内 proxy 直接 HTTPS 连接 api.minimaxi.com,无需宿主中间层。适用于上游 API 不需要 Host header 覆盖或 TLS SNI 特殊处理的场景。
gpt-5.5(宿主 proxy 模式)
容器内 proxy 通过 Docker host.docker.internal 连接宿主 port 17680 的 HTTP reverse proxy,由宿主 proxy 完成 HTTP→HTTPS 升级和 Host: hyueapi.com header 注入。
两跳设计原因:hyueapi.com 使用 Cloudflare,要求 TLS SNI 与 Host header 匹配;容器内 Node.js HTTP proxy 只做 HTTP 转发,TLS 终止由宿主 proxy 完成,避免容器内处理 Cloudflare 证书验证和 SNI 问题。
D601 宿主 hyueapi-proxy 服务
部署路径:~/pipeline/services/hyueapi-proxy/proxy.mjs
systemd user service:~/.config/systemd/user/hyueapi-proxy.service
# 状态检查
systemctl --user status hyueapi-proxy.service
# 重启
systemctl --user restart hyueapi-proxy.service
# 验证(需要 auth)
KEY=$(cat ~/pipeline/.state/secrets/gpt-5.5/OPENAI_API_KEY)
curl -H "Authorization: Bearer $KEY" http://127.0.0.1:17680/v1/models
服务行为:
- 监听
0.0.0.0:17680(容器通过host.docker.internal访问) - 上游
hyueapi.com:443(HTTPS) - 覆盖
Hostheader 为hyueapi.com - 透传所有其他 header(包括
Authorization) - 无认证、无缓存、无日志(生产态)
Harness Token 注入规则
scripts/src/opencodeContainerHarness.ts 中 in-container proxy 的 token 查找顺序:
ANTHROPIC_AUTH_TOKEN → ANTHROPIC_API_KEY → OPENAI_API_KEY
model 组件的 auth.envNames 声明注入到容器的环境变量名。对于 OpenAI-compatible 提供商(如 gpt-5.5),envNames 必须包含 OPENAI_API_KEY,harness 才能在 proxy 层自动注入 Bearer token。
Smoke Test 验证
每个 model 组件应配套一个 smoke-test pipeline 用于验证端到端连通性:
components/pipeline/gpt-5.5-smoke-test/config.json
components/procedure/gpt-5.5-smoke-connectivity/config.json
Smoke test 验证链路:
- 容器启动,harness 写入 OpenCode provider config 并启动 in-container proxy
- OpenCode server 启动,harness 创建 session 并发送 prompt
- 模型通过 proxy chain 完成请求(
POST /v1/responses) - 模型执行任务并通过 OA skill 提交
benchmark-repair-result-v1 - Harness 验证 OA submission 存在且 container exit code = 0
运行方式:
cd ~/pipeline
npx tsx scripts/pipeline-cli.ts procedure start \
--pipeline gpt-5.5-smoke-test \
--node smoke \
--task "Connectivity test: ..."
新增 Model 组件检查清单
- 创建
components/model/{id}/config.json,声明opencode、auth、proxy和runtimeEnv - 创建
.state/secrets/{id}/{ENV_NAME}存放 API key - 如果上游需要 Host header 覆盖或 TLS 特殊处理,部署宿主 proxy 服务并将
proxy.upstreamOrigin指向http://host.docker.internal:{port} - 确认
auth.envNames中的变量名在 harness token 查找链中(当前支持ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、OPENAI_API_KEY) - 创建 smoke-test pipeline 和 procedure 组件
- 运行 smoke test 验证端到端连通性
- 提交到 pipeline 仓库