feat: 每平台可用模型范围 + 降级尝试 + 失败回报
配置页为每个 Agent 平台划定「邮件场景下可用的模型」,插件按顺序逐个尝试,
全部失败把原因封装成邮件回复。目录由插件上报、管理员只做勾选 —— 手打模型名
会打错,而打错的后果要到真发邮件时才暴露成一次失败。
## 目录上报走心跳,不另设端点
模型清单会在运行中变(换 provider 配置、上游上下线、换 API key)。
只在注册时报一次的话目录会静静变陈,管理员在配置页选中一个平台其实调不到的
模型。心跳本来就是 30 秒一次的现成通道;另设一个 POST 等于给「目录是谁写的」
留两个答案,排查时要同时看两处。
心跳响应回传 `allowed_models`,因此管理员改了范围后最多一个周期生效,
不必重启插件。
与 platform_sessions 同一约定:拉不到目录时**省略字段**(保留现有目录),
传空数组会把配置页清成空白。
## 目录与选择分两张表
模型会从平台目录里消失(上游临时下线、换了 provider 配置)。合成一张带
allowed 标记的表时,整行被删就连带把管理员的选择也删了,模型回来还得重配一遍。
分开存之后「选了什么」是持久的,目录只决定「这一项现在是否可用」;
已选但不在目录里的标为 stale 显示出来 —— 不显示会让人以为自己没选过它。
## 最难的一点:模型失败不是同步抛出的
两个平台都踩了。`promptAsync()` 立即返回、`ctx.agents.create()` 不校验模型,
只包 try/catch 的话第二个模型永远不会被试到 —— 第一个无效模型会被判成成功。
必须等异步结论:
- opencode → `session.error` 事件(event 钩子在 deliverMail 之外,
因此用 turnWatchers 表把两者接起来)
- DSH → `turn/end` 的 `reason.kind === 'error'`
DSH 还有个陷阱:**`assistant/chunk` 不能当成功信号**,它的 `finish` 子类型
也带错误 —— `{chunk:{type:'finish',reason:{kind:'error',failure:{code:'NO_ADAPTER'}}}}`。
实测「无效 provider 却判成功」正是因为把任意 chunk 当成了走通。判据要落在
chunk 的类型上:finish 看 reason,其余才意味着模型真的在产出。
超时按成功处理(60 秒窗口):模型可能只是很慢,把慢当成失败会在换模型的同时
把已经在跑的那一轮丢掉。
DSH 换模型要换会话 id(`<原 id>-r1`)并 dispose 失败那个 agent:复用同一个 id
会让重试接在一条已经出错的会话后面,不 dispose 则 agent/status 还会为那个
死会话触发一次自动转发。
## 其他决策
- **范围优先于环境变量**:范围是运行时可改的策略,`AGENTMAIL_REPLY_*` 是部署时
的兜底。反过来的话管理员在配置页改了却不生效,得去改 service 文件重启
- **范围为空返回 `[undefined]` 而非 `[]`**:空数组会让调用方一次都不试,
而「管理员没配」的正确含义是不限定,不是「一个都不许用」
- **上限 10 个**:降级是串行的,选 50 个意味着最坏情况下一封邮件要等 50 次超时
- 前端 key 按**第一个** `/` 切分 provider/model:model id 可能含 `/`
(如 `org/model-name`),按最后一个切会把 provider 切错
- 保存后用服务端返回的结果刷新界面而非回显入参:repo 层会跳过重复与空字段
## 验证
- Go 10 个新测试(含「模型从目录消失后选择必须留存」的直接回归)
- 两插件各 18 个模型范围测试,共 180 个
- 端到端四轮:正常路由 → 全部无效(收到失败回报邮件,used_rounds 保持 0
确认走了免配额通道)→ DSH 降级(fake-a 失败 → llmsproxy/AUTO 成功)→
opencode 降级(nonexistent/bad 失败 → AUTO 成功,日志确认「前 1 个失败」)
- 生产已部署,前端「模型范围」页可用
This commit is contained in:
@ -412,6 +412,45 @@ export async function adminSetDefaultRounds(agentName: string, defaultRounds: nu
|
||||
);
|
||||
}
|
||||
|
||||
// ---------- 邮件场景下可用的模型范围 ----------
|
||||
|
||||
/** 平台上报的一个模型,带「是否已被选入」标记。 */
|
||||
export interface CatalogModel {
|
||||
provider: string;
|
||||
model: string;
|
||||
display_name?: string;
|
||||
allowed: boolean;
|
||||
/** 仅 allowed 为真时有意义,越小越先试 */
|
||||
rank?: number;
|
||||
}
|
||||
|
||||
export interface ModelRoute {
|
||||
provider: string;
|
||||
model: string;
|
||||
}
|
||||
|
||||
/**
|
||||
* 读某 Agent 的模型目录。
|
||||
*
|
||||
* `stale` 是「已选但平台当前目录里没有」的那些 —— 平台可能临时下线了某个模型,
|
||||
* 而管理员的选择是持久的。界面上不显示会让人以为自己没选过它。
|
||||
*/
|
||||
export async function adminGetAgentModels(agentName: string) {
|
||||
return request<{ agent_name: string; catalog: CatalogModel[]; stale: ModelRoute[] }>(
|
||||
'GET',
|
||||
`/admin/agents/${encodeURIComponent(agentName)}/models`
|
||||
);
|
||||
}
|
||||
|
||||
/** 保存选择。数组顺序即优先级(插件按这个顺序降级尝试)。 */
|
||||
export async function adminSetAgentModels(agentName: string, models: ModelRoute[]) {
|
||||
return request<{ status: string; models: ModelRoute[] }>(
|
||||
'PUT',
|
||||
`/admin/agents/${encodeURIComponent(agentName)}/models`,
|
||||
{ models }
|
||||
);
|
||||
}
|
||||
|
||||
// ---------- Sessions ----------
|
||||
|
||||
export async function getHumanSessions() {
|
||||
|
||||
Reference in New Issue
Block a user