K8s 模式下 Token Plan 配置无法热更新，Worker 报错 Model not exist || K8s mode, the Token Plan configuration cannot be hot updated, and the Worker reports an error Model not exist.

[quchenchen]

Bug Description

在 K8s 部署模式下，通过一键脚本添加/更新了 Token Plan（例如新增 qwen3.7-max 等模型），但现有 Worker 无法调用新模型。Worker 日志报错 {"message":"Model not exist."} 以及 Model service check failed: HTTP 400。
What I expected:
更新 Token Plan 后，Higress 网关应自动同步 modelMapping 配置，且 Worker 应能识别新模型并成功路由到 DashScope 上游服务。

Steps to Reproduce

在 K8s 环境下完成 HiClaw 部署。
运行配置脚本或通过 UI 更新 LLM Provider 配置（添加新模型 Token Plan）。
在 Worker (smart-editor/deepresearcher 等) 中尝试调用新模型。
观察 Worker 报错 Model not exist 且容器状态异常。

AI Analysis

I Analysis:
Tool used: HiClaw Manager Agent (Built-in)
Analysis:

脚本空跑问题：/opt/hiclaw/scripts/init/setup-higress.sh 中检测到 HICLAW_RUNTIME=k8s 时直接跳过了 Higress Admin API 的路由与 Provider 更新逻辑。
网关配置缺失：由于上述跳过，Higress 的 qwen Provider 缺少针对新模型的 modelMapping，导致入口拦截请求。
容器未重载：Worker 容器未重启，openclaw.json 中的模型列表未更新，Preflight 检查失败。
网络解析问题：Worker 容器内缺失 aigw-local.hiclaw.io 的 hosts 解析，导致临时网络中断（Connection refused）。

Relevant Logs

# Worker 报错日志
"Error: Error occurred during execution of model: unknown"
"Model service check failed: model chat completion preflight returned HTTP 400"

# 溯源发现 (setup-higress.sh)
if [ "${HICLAW_RUNTIME}" = "k8s" ]; then
    # 跳过所有 Higress 路由和 Provider 的 API 更新
    return 0
fi

Component

CoPaw Worker

Version / Commit

v1.1.2

---

Bug Description

In K8s deployment mode, Token Plan is added/updated through one-click script (for example, new models such as qwen3.7-max are added), but the existing Worker cannot call the new model. The Worker log reports errors {"message":"Model not exist."} and Model service check failed: HTTP 400.
What I expected:
After updating the Token Plan, the Higress gateway should automatically synchronize the modelMapping configuration, and the Worker should be able to recognize the new model and successfully route to the DashScope upstream service.

Steps to Reproduce

Complete HiClaw deployment in K8s environment.
Run the configuration script or update the LLM Provider configuration via the UI (add new model Token Plan).
Try calling the new model in a Worker (smart-editor/deepresearcher, etc.).
Observe that the Worker reports an error Model not exist and the container status is abnormal.

AI Analysis

I Analysis:
Tool used: HiClaw Manager Agent (Built-in)
Analysis:

Script empty running problem: When HICLAW_RUNTIME=k8s is detected in /opt/hiclaw/scripts/init/setup-higress.sh, the routing and Provider update logic of the Higress Admin API are directly skipped.
Missing gateway configuration: Due to the above skip, Higress's qwen Provider lacks modelMapping for the new model, causing the entry to intercept the request.
Container not reloaded: Worker container not restarted, model list in openclaw.json not updated, Preflight check failed.
Network resolution problem: The hosts resolution of aigw-local.hiclaw.io is missing in the Worker container, resulting in temporary network interruption (Connection refused).

Relevant Logs

# Worker error log
"Error: Error occurred during execution of model: unknown"
"Model service check failed: model chat completion preflight returned HTTP 400"

# Traceability discovery (setup-higress.sh)
if [ "${HICLAW_RUNTIME}" = "k8s" ]; then
    # Skip all Higress routing and Provider API updates
    return 0
fi

Component

CoPaw Worker

Version/Commit

In v1.1.2

[hiclaw-bot]

源码分析：K8s 模式下 Token Plan 配置无法热更新

感谢详细的 issue 报告。我对源码进行了深入调查，以下是针对每个问题的分析和结论。

---

1. setup-higress.sh 在 K8s 模式下被跳过

确认：这是 by design（设计如此），不是 bug。

在 K8s 部署模式下，Higress 网关的初始化由 两个组件 负责，而非 setup-higress.sh：

• hiclaw-controller 的 Initializer.initGatewayRoutes()（hiclaw-controller/internal/initializer/initializer.go）在集群启动时执行一次性初始化，包括：注册 Tuwunel/Element Web 服务源、创建 LLM Provider、创建 AI Route、配置 Stream Idle Timeout。
• Manager 容器启动脚本 start-manager-agent.sh（约 L400-L480）有一段 K8s 专用的 _k8s_higress_api 逻辑，通过直接调用 Higress Console API 完成 Consumer 创建、LLM Provider 注册和 AI Route 创建。

setup-higress.sh 仅适用于 本地/嵌入式部署（非 K8s）模式。

2. Higress Provider 缺少新模型的 modelMapping

代码分析结论：modelMapping 为空是正确的设计。

查看代码：

// initializer.go - LLM Provider 创建
raw := map[string]interface{}{"hiclawMode": true}
Gateway.EnsureAIProvider(ctx, gateway.AIProviderRequest{
    Name: provider, Type: "openai",
    Tokens: []string{cfg.LLMAPIKey},
    Protocol: "openai/v1", Raw: raw,
})

# start-manager-agent.sh L433 (K8s mode)
'{"name":"qwen","type":"openai","tokens":["KEY"],"modelMapping":{},"protocol":"openai/v1","rawConfigs":{"hiclawMode":true}}'

modelMapping: {} 表示所有模型名直接透传给上游 Provider（DashScope / Token Plan 端点），Higress 不做模型名映射。因此 Higress Provider 的 modelMapping 不需要知道具体模型列表。

但是，Model not exist + HTTP 400 错误说明 Higress AI Gateway 在某些版本/配置下会对模型名做前置校验。当模型名不在其已知列表中时，即使 modelMapping 为空也会拒绝请求。这是 Higress AI Gateway 插件层面的行为，不是 HiClaw 代码层面的问题。

3. Worker 容器未重载 / openclaw.json 未更新

确认：K8s 模式下修改 Worker CR 的 spec.model 会自动触发完整重建。

源码中 member_reconcile.go 的容器协调逻辑：

specChanged := m.SpecChanged  // Generation != ObservedGeneration

case backend.StatusRunning, backend.StatusStarting:
    if !specChanged {
        return reconcile.Result{}, nil  // 无变更，不重建
    }
    // spec 变了 -> 删除旧 Pod -> 重建
    wb.Delete(ctx, m.Name)
    return createMemberContainer(ctx, d, m, state, wb)

流程为：

1. 修改 Worker CR 的 spec.model -> Generation 变化
2. Controller 感知到 Generation != ObservedGeneration -> SpecChanged = true
3. ReconcileMemberConfig 重新生成 openclaw.json（通过 agentconfig.Generator），推送到 OSS
4. ReconcileMemberContainer 删除旧 Pod，创建新 Pod（带新 config）

关键点：用户需要在 K8s 中 修改 Worker CR 的 model 字段，而不是仅仅修改环境变量或运行安装脚本。

4. Worker 容器内缺失 aigw-local.hiclaw.io 的 hosts 解析

代码分析：K8s 模式下 Worker Pod 确实不会注入 hostAliases。

// member_reconcile.go
func extraHostsForBackend(wb backend.WorkerBackend) []string {
    if wb != nil && wb.Name() == "docker" {
        return []string{dockerHostInternalExtraHost}  // 仅 Docker 模式
    }
    return nil  // K8s 模式返回空
}

K8s 模式下，aigw-local.hiclaw.io 的 DNS 解析 依赖集群 DNS 配置（如 CoreDNS rewrite 规则、Ingress Controller 的 Service 等），不会通过 /etc/hosts 注入。

Worker 的 openclaw.json 中的 AI Gateway URL 由 Controller 的 WorkerEnvDefaults 决定：

AIGatewayURL: envOrDefault("HICLAW_AI_GATEWAY_URL", "http://aigw-local.hiclaw.io:8080"),

如果集群内 DNS 无法解析 aigw-local.hiclaw.io，Worker 将无法连接网关。

---

根因总结

问题	根因	影响范围
脚本空跑	K8s 模式由 Controller 管理网关，setup-higress.sh 不适用	预期行为
Provider 缺模型	modelMapping: {} 是正确的透传设计；HTTP 400 来自 Higress 插件层校验	Higress 版本相关
容器未重载	用户需要修改 Worker CR 的 spec.model 触发重建，安装脚本不会自动更新 CR	操作流程缺失
DNS 缺失	K8s 模式不注入 hostAliases，依赖集群 DNS	部署配置缺失

核心问题：目前缺少一个 Token Plan 模型热更新管道，即「安装脚本更新 Token Plan -> 同步更新 Higress Provider 配置 -> 同步更新 Worker CR -> 自动重建 Worker Pod」这一完整链路在 K8s 模式下未实现。

---

临时解决方案（Workaround）

Step 1: 更新 Higress Provider 配置

重启 Controller Pod 重新执行初始化逻辑：

kubectl rollout restart deployment hiclaw-controller -n hiclaw

或手动调用 Higress Console API 更新 Provider（确保 API Key 和 Token Plan URL 正确）。

Step 2: 确保 DNS 解析

在 K8s CoreDNS 中添加 rewrite 规则，或通过 Ingress Service IP 暴露网关：

# CoreDNS ConfigMap 示例
rewrite name aigw-local.hiclaw.io <higress-gateway-service>.hiclaw.svc.cluster.local

Step 3: 更新 Worker CR 触发重建

kubectl patch worker <worker-name> -n hiclaw \
  --type=merge -p '{"spec":{"model":"qwen3.7-max"}}'

这将触发 Controller 重新生成 openclaw.json 并重建 Worker Pod。

---

建议的长期改进方向

1. Token Plan 热更新 CRD：新增 TokenPlan CRD，Controller watch 变化后自动更新 Higress Provider 和 Worker CR
2. K8s DNS 自动配置：Helm Chart 中自动创建 CoreDNS rewrite 或 Service entry for *-local.hiclaw.io
3. Worker Config 热加载：支持不重建 Pod 的情况下重新加载 openclaw.json（如通过 SIGHUP 或 sidecar 同步）

---

希望以上分析有帮助。如果需要进一步协助排查具体的 Higress 版本行为或配置问题，请提供 Higress Gateway Pod 的日志和版本号。

---

Source code analysis: Token Plan configuration cannot be hot updated in K8s mode

Thanks for the detailed issue report. I conducted an in-depth investigation of the source code, and below are the analysis and conclusions for each problem.

---

1. setup-higress.sh is skipped in K8s mode

**Confirmation: This is by design, not a bug. **

In K8s deployment mode, the initialization of Higress gateway is responsible for two components instead of setup-higress.sh:

• hiclaw-controller's Initializer.initGatewayRoutes() (hiclaw-controller/internal/initializer/initializer.go) performs one-time initialization when the cluster starts, including: registering the Tuwunel/Element web service source, creating an LLM Provider, creating an AI Route, and configuring the Stream Idle Timeout.
• Manager container startup script start-manager-agent.sh (about L400-L480) has a section of K8s-specific _k8s_higress_api logic, which completes Consumer creation, LLM Provider registration and AI Route creation by directly calling the Higress Console API.

setup-higress.sh is only available in local/embedded deployment (non-K8s) mode.

2. Higress Provider lacks modelMapping for new models

**Code analysis conclusion: modelMapping being empty is the correct design. **

View the code:

// initializer.go - LLM Provider creation
raw := map[string]interface{}{"hiclawMode": true}
Gateway.EnsureAIProvider(ctx, gateway.AIProviderRequest{
    Name: provider, Type: "openai",
    Tokens: []string{cfg.LLMAPIKey},
    Protocol: "openai/v1", Raw: raw,
})

# start-manager-agent.sh L433 (K8s mode)
'{"name":"qwen","type":"openai","tokens":["KEY"],"modelMapping":{},"protocol":"openai/v1","rawConfigs":{"hiclawMode":true}}'

modelMapping: {} means that all model names are directly transmitted to the upstream Provider (DashScope / Token Plan endpoint), and Higress does not do model name mapping. Therefore Higress Provider's modelMapping does not need to know the specific model list.

But, Model not exist + HTTP 400 Error description Higress AI Gateway will perform pre-verification on the model name in some versions/configurations. When the model name is not in its known list, the request will be rejected even if modelMapping is empty. This is a behavior at the Higress AI Gateway plug-in level, not a problem at the HiClaw code level.

3. Worker container is not reloaded/openclaw.json is not updated

**Confirmation: Modifying the spec.model of Worker CR in K8s mode will automatically trigger a complete rebuild. **

The container coordination logic of member_reconcile.go in the source code:

specChanged := m.SpecChanged // Generation != ObservedGeneration

case backend.StatusRunning, backend.StatusStarting:
    if !specChanged {
        return reconcile.Result{}, nil // No changes, no reconstruction
    }
    // spec changed -> delete old Pod -> rebuild
    wb.Delete(ctx, m.Name)
    return createMemberContainer(ctx, d, m, state, wb)

The process is:

1. Modify Worker CR’s spec.model -> Generation changes
2. Controller senses Generation != ObservedGeneration -> SpecChanged = true
3. ReconcileMemberConfig regenerates openclaw.json (through agentconfig.Generator) and pushes it to OSS
4. ReconcileMemberContainer deletes the old Pod and creates a new Pod (with new config)

Key point: Users need to modify the model field of Worker CR in K8s instead of just modifying environment variables or running the installation script.

4. The hosts resolution of aigw-local.hiclaw.io is missing in the Worker container

**Code analysis: Worker Pod does not inject hostAliases in K8s mode. **

// member_reconcile.go
func extraHostsForBackend(wb backend.WorkerBackend) []string {
    if wb != nil && wb.Name() == "docker" {
        return []string{dockerHostInternalExtraHost} // Docker mode only
    }
    return nil // K8s mode returns empty
}

In K8s mode, the DNS resolution of aigw-local.hiclaw.io depends on the cluster DNS configuration** (such as CoreDNS rewrite rules, Ingress Controller's Service, etc.) and will not be injected through /etc/hosts.

The AI Gateway URL in the Worker's openclaw.json is determined by the Controller's WorkerEnvDefaults:

AIGatewayURL: envOrDefault("HICLAW_AI_GATEWAY_URL", "http://aigw-local.hiclaw.io:8080"),

If the in-cluster DNS cannot resolve aigw-local.hiclaw.io, the Worker will not be able to connect to the gateway.

---

Summary of root causes

Problem	Root Cause	Scope of Impact
Script empty running	In K8s mode, the gateway is managed by the Controller, setup-higress.sh is not applicable	Expected behavior
Provider model is missing	modelMapping: {} is the correct transparent transmission design; HTTP 400 comes from Higress plug-in layer verification	Higress version related
The container is not reloaded	The user needs to modify the spec.model of Worker CR to trigger reconstruction, and the installation script will not automatically update CR	The operation process is missing
DNS is missing	K8s mode does not inject hostAliases and relies on cluster DNS	Deployment configuration is missing

Core issue: Currently there is a lack of a Token Plan model hot update pipeline, that is, the complete link of "Installation script updates Token Plan -> Synchronously updates Higress Provider configuration -> Synchronously updates Worker CR -> Automatically rebuilds Worker Pod" is not implemented in K8s mode.

---

Workaround

Step 1: Update Higress Provider configuration

Restart the Controller Pod and re-execute the initialization logic:

kubectl rollout restart deployment hiclaw-controller -n hiclaw

Or manually call the Higress Console API to update the Provider (make sure the API Key and Token Plan URL are correct).

Step 2: Ensure DNS resolution

Add rewrite rules in K8s CoreDNS, or expose the gateway through the Ingress Service IP:

# CoreDNS ConfigMap Example
rewrite name aigw-local.hiclaw.io <higress-gateway-service>.hiclaw.svc.cluster.local

Step 3: Update Worker CR to trigger rebuild

kubectl patch worker <worker-name> -n hiclaw \
  --type=merge -p '{"spec":{"model":"qwen3.7-max"}}'

This will trigger the Controller to regenerate openclaw.json and rebuild the Worker Pod.

---

Suggested long-term improvement directions

1. Token Plan hot update CRD: Add TokenPlan CRD, automatically update Higress Provider and Worker CR after Controller watch changes
2. K8s DNS automatic configuration: Automatically create CoreDNS rewrite or Service entry for *-local.hiclaw.io in Helm Chart
3. Worker Config Hot Loading: Supports reloading openclaw.json without rebuilding the Pod (such as through SIGHUP or sidecar synchronization)

---

Hope the above analysis is helpful. If you need further assistance in troubleshooting specific Higress version behavior or configuration issues, please provide the log and version number of the Higress Gateway Pod.

[quchenchen]

@hiclaw-bot Docker 模式下一键配置 Token Plan 不生效：Worker 未自动重启且网关 API 更新存在静默失败

Bug Description:
What happened:
在 Docker 部署模式下，运行一键脚本添加/更新 Token Plan（如添加 qwen3.7-max）后，Worker 依然报错 Model not exist 或 Connection refused。
经排查，脚本虽然运行结束，但：

Worker 容器未重启，仍加载旧的 openclaw.json。
Higress 网关的 Provider 配置未真正更新。
What I expected:
运行配置脚本后，脚本应确保：

成功更新 Higress 网关的模型映射（并校验 API 返回结果）。
自动重启受影响的 Worker 容器以加载新配置。
确保容器内 DNS 解析（如 aigw-local.hiclaw.io）生效。
Steps to Reproduce:

使用 Docker Compose 部署 HiClaw。
运行内置的一键配置脚本添加新模型。
脚本提示成功，但 Worker 调用新模型失败。
(手动验证) 发现必须手动重启 Worker 容器，配置才会生效。
AI Analysis:
Tool used: HiClaw Manager Agent
Analysis:

生命周期缺失: 源码逻辑显示 Worker 仅在启动时解析 openclaw.json。当前的一键脚本（或配置流程）在修改配置后，缺少触发 docker restart 或 Worker 重建的步骤。
API 校验失效: 在排查中发现，向 Higress Admin API 发送更新请求时，服务器有时会返回 405 Method Not Allowed 或 HTML 内容（可能是由于反向代理拦截了 /apis 路径）。脚本中的 curl 命令似乎未对非 200 状态码或非 JSON 响应进行严格校验，导致配置更新失败但脚本未报错（Exit 0）。
DNS 配置: 容器内无法自动获取宿主机的 /etc/hosts 变更，且 docker-compose 中似乎缺乏对内部服务域名的 extra_hosts 持久化配置。
Relevant Logs:

1. API 返回 405 或 HTML 的静默失败证据

curl -X PUT "http://172.24.0.2:8001/apis/..."

Response: 405 Method Not Allowed (但脚本未拦截)

2. Worker 报错日志

"Model service check failed: model chat completion preflight returned HTTP 400"

(原因：openclaw.json 未更新，仍尝试调用旧模型/旧配置)

[hiclaw-bot]

状态：需要确认
处理时间：2026-06-03 21:01 UTC+8

问题概述

• 现象：Docker 模式下通过一键脚本配置 Token Plan 后，Higress 网关 API 更新静默失败（HTTP 405 / HTML 响应），Worker 容器未自动重启仍加载旧 openclaw.json
• 期望：配置脚本应确保网关更新成功、自动重启 Worker 容器、DNS 解析正常
• 影响范围：Docker 部署模式下所有更新 Token Plan 配置的用户

分析结论

1. Docker 模式下 setup-higress.sh 确实会被执行 —— 但仅在 Manager 容器启动时

源码 start-manager-agent.sh（约 L459）中 Docker 模式分支明确调用了 setup-higress.sh：

else
    # Docker mode: full setup with all routes, domains, MCP servers
    /opt/hiclaw/scripts/init/setup-higress.sh
fi

但该脚本 仅在 Manager 容器启动时运行一次。后续通过安装脚本更新 Token Plan 配置后，不会重新触发 setup-higress.sh，也不会重启 Manager 容器来重新执行。

2. Higress API 调用确实存在静默失败 —— 这是代码层面的设计问题

setup-higress.sh 中的 higress_api() 函数（约 L40-77）有以下特征：

• curl 命令使用 || true，即使网络错误也不会退出：

  http_code=$(curl -s -o "${tmpfile}" -w '%{http_code}' ... 2>/dev/null) || true

• 对于 "success":false 的响应，仅输出 WARNING 日志，不 return 非零，不 exit：

  elif echo "${response}" | grep -q '"success":false' 2>/dev/null; then
      log "WARNING: ${desc} ... FAILED (HTTP ${http_code}): ${response}"

• 只有 HTML 响应（session 过期）和 401/403 才 return 1，其他所有失败都被吞掉

• 用户报告的 HTTP 405 和 HTML 静默失败与代码行为完全一致

3. 当前不存在 Token Plan 热更新专用脚本

源码中 没有 专门用于更新 Token Plan 模型列表的脚本或流程。当前路径为：

• 安装脚本 hiclaw-install.sh 在首次安装时设置 Token Plan（选择 token-plan 接入类型后配置 HICLAW_OPENAI_BASE_URL 为 Token Plan 端点）
• 但 没有 update-token-plan.sh 或类似的更新命令
• 安装脚本的 upgrade 模式（HICLAW_UPGRADE=1）可以重新选择模型，但不会触发 Higress Provider 更新或 Worker 重启

4. Worker 容器无自动重启机制

• lifecycle-worker.sh 提供 stop、start、ensure-ready 三个动作
• ensure-ready 会自动启动已停止的 Worker，但 不会重启正在运行的 Worker
• 安装脚本中没有 docker restart hiclaw-worker-* 逻辑
• Worker 在启动时从 OSS/MinIO 加载 openclaw.json，之后不会重新加载（无 fsnotify/inotify 机制）
• Worker 的 openclaw.json 由 Manager 的 generate-worker-config.sh 生成并推送到 OSS

5. Docker 模式下的 DNS 解析依赖 Docker 网络

• Worker 容器通过 --network hiclaw-net 连接到 Docker 网络
• aigw-local.hiclaw.io 的解析依赖 Docker 内置 DNS（通过 Higress 容器的网络别名）
• Docker 模式下 Worker Pod 有 hostAliases（dockerHostInternalExtraHost），但不包括 aigw-local.hiclaw.io
• 如果 Higress 容器重启或网络配置变更，DNS 缓存可能导致短暂解析失败

处理说明

1. 确认了 Docker 模式下 setup-higress.sh 的完整执行路径和 API 错误处理逻辑
2. 确认了当前没有 Token Plan 热更新专用脚本或 API
3. 确认了 Worker 容器没有配置变更后的自动重启机制

建议方案

临时解决方案（手动操作）：

1. 重新执行 Higress 网关配置：重启 Manager 容器触发 setup-higress.sh 重新执行：

   docker restart hiclaw-manager

   或手动调用 Higress Console API 更新 Provider 配置（确保 Token Plan API Key 和 URL 正确）。

2. 重启 Worker 容器加载新配置：

   docker restart hiclaw-worker-<worker-name>

   Worker 重启时会从 OSS 重新拉取 openclaw.json（如果 Manager 已更新）。

3. 验证 DNS 解析：

   docker exec hiclaw-worker-<worker-name> ping -c1 aigw-local.hiclaw.io

长期改进方向：

1. higress_api() 函数应增加严格模式：对于配置更新类操作（PUT），失败时应 return 非零或 exit，而非仅 WARNING
2. 新增 update-token-plan.sh 脚本：封装 Higress Provider 更新 + Worker 配置重新生成 + Worker 容器重启的完整流程
3. Worker 配置热加载：支持 Worker 运行时重新拉取 openclaw.json（如 SIGHUP 信号或 sidecar 同步），避免每次配置变更都需要重启容器

[MoganKo]

这个问题何时能发布解决，另外诸如此类的 ，热更新 CRD 问题太多了，
比如多个渠道配置（钉钉的），新增human的（上版本发布修改，依旧未能彻底修改）。
我希望 开发团队 能从底层架构上 修复这 类问题。

---

When will this problem be released and solved? In addition, there are too many problems with hot update CRD.
For example, multiple channel configurations (DingTalk), adding human (modifications were released in the previous version, but still not completely modified).
I hope the development team can fix this kind of problem from the underlying architecture.

[shenjiecode]

Additional reproduction: embedded v1.2.2 overwrites the Worker AI Gateway URL

This is related to the model/gateway symptoms in this issue, but appears to be a separate embedded-mode URL projection bug.

Environment: AgentTeams v1.2.2, embedded Docker install, tested 2026-08-18 with a fresh Team/Worker and an OpenAI-compatible DeepSeek provider.

Observed:

• Direct access to the configured DeepSeek upstream /v1/models and a tool Chat Completions request returned HTTP 200.
• Team/Worker creation and runtime injection succeeded.
• The fresh Worker received AGENTTEAMS_AI_GATEWAY_URL=http://agentteams-controller:8080.
• From that Worker, /v1/models, /v1/chat/completions, and /v1/responses returned HTTP 404 with the Worker consumer credential; an unauthenticated request returned HTTP 401.
• Supplying the expected embedded gateway URL http://aigw-local.agentteams.io:8080 at the deployment layer did not persist: the embedded Controller overwrote the newly generated Worker back to http://agentteams-controller:8080.

The suspected code path is the embedded host rewrite in agentteams-controller/internal/config/config.go: LoadConfig() rewrites WorkerEnv.AIGatewayURL to the Controller hostname along with Matrix and MinIO. The embedded installer already places aigw-local.agentteams.io on the Controller network, and the Worker contract documents that hostname as the AI Gateway URL. The later member_reconcile.go projection then uses the resolved provider URL to overwrite the Worker environment.

Proposed fix: preserve the configured worker-facing AGENTTEAMS_AI_GATEWAY_URL in embedded mode; only rewrite the Matrix and MinIO endpoints to the Controller hostname. Add a regression test that asserts the embedded config keeps aigw-local.agentteams.io while Matrix/MinIO still use the Controller host, followed by a fresh Worker /v1/models and real model smoke.

I am preparing a small upstream PR with the regression test. Please let me know if the maintainers prefer a separate issue for this embedded URL projection bug.

[shenjiecode]

The upstream PR is now open: #1188

It contains the minimal Controller fix and a regression test. Targeted Controller, gateway, and config tests pass locally.

[shenjiecode]

@johnlanni @shiyiyue1102 @NingHua-jzp

The PR is now bilingual (English first, Chinese translation appended): #1188

请维护者确认这个修复是否符合 embedded 模式的网关地址契约，以及是否需要额外覆盖自定义网关域名场景。