再添加供应商模型的时候，对话报错，删除新添加的供应商还是报错

[xxch]

Bug Description

再添加供应商模型的时候，对话报错，删除新添加的供应商还是报错。基本上不能用了，需要删除重新安装就好了。

Steps to Reproduce

再添加供应商模型的时候，对话报错，删除新添加的供应商还是报错。基本上不能用了，需要删除重新安装就好了。

AI Analysis

No response

Relevant Logs

Component

Manager Agent

Version / Commit

No response

[oss-maintainer]

Issue Evaluation

Category: bug | Status: Needs Info

Verified against current main. The report lacks logs, version, and the exact error text, so it cannot be reproduced as-is, but the codebase contains a plausible root cause consistent with the described symptom ("adding a provider model breaks chat; deleting the provider does not fix it; only reinstall helps"):

• The model-switch flow (manager/agent/skills/model-switch/scripts/update-manager-model.sh) persists a newly selected model as the Manager's primary model (agents.defaults.model.primary) but has no removal/fallback path. If the underlying Higress provider/AI route is later deleted, Manager chats keep targeting a model that can no longer be routed.
• Manager reconciliation treats a missing provider — or a provider without an AI route — as an error (agentteams-controller/internal/gateway/higress.go), and the update API only sets spec.modelProvider when the value is non-empty (internal/server/resource_handler.go), so a stale provider reference cannot be cleared through the API and keeps failing reconciliation.
• Manager config is continuously synced through object storage (manager/scripts/init/start-manager-agent.sh), so a stale persisted primary model survives restarts — consistent with "deleting the provider still errors until a full reinstall".

To confirm which path applies, please provide:

• Version / image tag or commit, and deployment mode (embedded / k8s / aliyun)
• Exact steps taken: how the provider/model was added and how it was deleted (Higress provider, AI route, or both)
• The chat error message / HTTP status, plus Manager, controller, and Higress logs around the failure
• Sanitized post-failure Manager config (openclaw.json) and Manager CR spec.model / spec.modelProvider values
• Whether restarting the Manager or explicitly switching back to a known-good model changes the behavior

---

Automated evaluation by github-manager-bot

[shiyiyue1102]

我在当前 main 上用隔离环境复现了恢复问题：Manager 切换到新增 Provider 的模型后，删除对应 Provider/Route 不会回退 Manager.spec.model，重启后仍会继续请求已不可用的模型；如果配置了 spec.modelProvider，当前更新 API 也无法显式清空它。

已经准备了针对恢复路径的修复：Manager 更新 API 支持显式清空 modelProvider，agt update manager 同时增加 --model-provider 参数。修复合入并发布后，可以执行 agt update manager --name default --model <可用模型> --model-provider= 恢复，不需要重新安装。

原报告中“新增后立即报错”的具体触发条件仍请补充版本、部署方式和错误日志，以便确认是否是同一条链路。

[shiyiyue1102]

恢复路径修复已经提交为 PR #1232：

#1232

该 PR 让 Manager 更新 API 能区分“未提供 modelProvider”和“显式清空 modelProvider”，并新增 agt update manager --model-provider。修复发布后可用下面的命令切回可用模型并解除已删除 Provider 的绑定，无需重新安装：

agt update manager --name default --model <可用模型> --model-provider=

分支已重放到当前 main，Controller 全量 go test ./... 通过。

原报告中“新增 Provider 后立即报错”的首次失败原因仍需要版本、部署方式、具体错误和日志才能进一步确认，因此 PR 只声明解决已复现的持久化恢复缺陷，不会自动关闭本 issue。

---

Recovery path fix has been submitted as PR #1232:

#1232

This PR enables the Manager update API to distinguish between "no modelProvider provided" and "clear modelProvider explicitly", and adds agt update manager --model-provider. After the repair is released, you can use the following command to switch back to the available models and unbind the deleted Provider without reinstalling:

agt update manager --name default --model <available model> --model-provider= 

The branch has been replayed to the current main, and the Controller's full go test ./... passed.

The reason for the first failure in the original report of "an error was reported immediately after adding the Provider" still requires the version, deployment method, specific errors and logs to be further confirmed. Therefore, the PR only states that the persistent recovery defect has been resolved and will not automatically close this issue.