feat: 第10/11轮 — resource参数 + model解析

#27: resource core/memory被忽略→固定2核8GB
#28: 6层解析回退3个隐蔽缺陷

Co-Authored-By: Claude <noreply@anthropic.com>

Author: CC11001100

docs/08-analysis-rounds/unknown-gaps-index.md

@@ -42,8 +42,8 @@
 | 23 | 无登录失败限流 | login() 无重试限制 | P2 | 安全加固 |
 | 24 | 浏览器指纹伪装策略 | browser-headers.ts 4 域名专用生成器 | 新维度 | 源码分析 | ✅ 已完成 → [报告](unknown-browser-fingerprint.md) |
 | 25 | Conversation Manager 清理与超时机制 | conversation-manager.ts 369 行 | P0 | 源码分析 | ✅ 已完成 → [报告](unknown-conversation-cleanup.md) |
-| 26 | Express 中间件链与 SSE 流控制 | server.ts 331 行 | P0 | 源码分析 |
-| 27 | 任务创建 resource 参数的实际影响 | task-runner.ts resource: {core, memory, life} | P0 | 源码分析 |
-| 28 | model_id 6 层解析回退的精确行为 | models.ts resolveModel() | P0 | 源码分析 |
+| 26 | Express 中间件链与 SSE 流控制 | server.ts 331 行 | P0 | 源码分析 | ✅ 已完成 → [报告](unknown-express-sse.md) |
+| 27 | 任务创建 resource 参数的实际影响 | task-runner.ts resource: {core, memory, life} | P0 | 源码分析 | ✅ 已完成 → [报告](unknown-resource-params.md) |
+| 28 | model_id 6 层解析回退的精确行为 | models.ts resolveModel() | P0 | 源码分析 | ✅ 已完成 → [报告](unknown-model-resolution.md) |
 | 29 | admin-login.ts OAuth 6 步超时保护 | 10 分钟 session TTL + 状态清理 | P0 | 源码分析 |
 | 30 | types.ts 类型系统的设计演进 | 180 行完整类型定义 | P0 | 源码分析 |

docs/08-analysis-rounds/unknown-model-resolution.md

@@ -0,0 +1,224 @@
+---
+description: model_id 6 层解析回退机制的精确行为分析 — resolveModel() 从精确匹配到模糊回退的完整链路
+protocol_version: based on proxy/src/models.ts (103 行)
+confidence: high
+last_verified: 2026-07-05
+---
+
+# model_id 6 层解析回退的精确行为
+
+> **所属分类:** 新维度 #28 — model_id 6 层解析回退
+> **关键发现:** 6 层回退设计巧妙但有 3 个隐蔽缺陷：大小写敏感、display_name 空值、第一兜底可能匹配错误模型
+
+## 1. 6 层解析回退架构
+
+```mermaid
+flowchart TB
+    subgraph Input["客户端请求"]
+        ID["model: 'monkeycode/BaiZhiCloud/gpt-5.4'"]
+    end
+
+    subgraph Layer1["L1: 精确匹配"]
+        EXACT["`monkeycode/${provider}/${model}`<br/>=== openaiModelId"]
+    end
+
+    subgraph Layer2["L2: Provider/Model 匹配"]
+        PM["`${provider}/${model}`<br/>=== openaiModelId"]
+    end
+
+    subgraph Layer3["L3: Model 名称匹配"]
+        MN["model.name === openaiModelId<br/>大小写敏感"]
+    end
+
+    subgraph Layer4["L4: Display Name 匹配"]
+        DN["display_name === openaiModelId<br/>大小写敏感"]
+    end
+
+    subgraph Layer5["L5: 默认模型"]
+        DEF["is_default === true"]
+    end
+
+    subgraph Layer6["L6: 第一个可用模型"]
+        FIRST["models[0] || null"]
+    end
+
+    subgraph Fail["解析失败"]
+        NULL["return null<br/>→ 客户端收到 404"]
+    end
+
+    ID --> Layer1
+    Layer1 -->|命中| DONE["✅ 返回 MonkeyCodeModel"]
+    Layer1 -->|未命中| Layer2
+    Layer2 -->|命中| DONE
+    Layer2 -->|未命中| Layer3
+    Layer3 -->|命中| DONE
+    Layer3 -->|未命中| Layer4
+    Layer4 -->|命中| DONE
+    Layer4 -->|未命中| Layer5
+    Layer5 -->|命中| DONE
+    Layer5 -->|未命中| Layer6
+    Layer6 -->|找到| DONE
+    Layer6 -->|空列表| NULL
+```
+
+## 2. 每层匹配的精确条件
+
+```typescript
+// proxy/src/models.ts:64-90
+async resolveModel(openaiModelId: string): Promise<MonkeyCodeModel | null> {
+  const models = await this.fetchModels()
+
+  // L1: monkeycode/BaiZhiCloud/gpt-5.4
+  const exact = models.find((m) => this.toOpenAIModelId(m) === openaiModelId)
+  if (exact) return exact
+
+  // L2: BaiZhiCloud/gpt-5.4
+  const byProviderModel = models.find((m) => `${m.provider}/${m.model}` === openaiModelId)
+  if (byProviderModel) return byProviderModel
+
+  // L3: gpt-5.4
+  const byModelName = models.find((m) => m.model === openaiModelId)
+  if (byModelName) return byModelName
+
+  // L4: display_name 匹配
+  const byDisplayName = models.find((m) => m.display_name === openaiModelId)
+  if (byDisplayName) return byDisplayName
+
+  // L5: is_default
+  const defaultModel = models.find((m) => m.is_default)
+  if (defaultModel) return defaultModel
+
+  // L6: 第一个
+  return models[0] || null
+}
+```
+
+## 3. 每一层的客户端输入示例
+
+| 层 | 客户端输入示例 | 命中条件 | 匹配复杂度 |
+|----|--------------|---------|-----------|
+| L1 | `monkeycode/BaiZhiCloud/qwen3.5-plus` | 完整前缀+provider+model | 精确匹配 |
+| L2 | `BaiZhiCloud/qwen3.5-plus` | `/` 分割的两个字段 | 精确匹配 |
+| L3 | `qwen3.5-plus` | 单字段匹配 model 名 | 精确匹配（可能误配） |
+| L4 | `通义千问 Qwen3.5` | display_name 精确匹配 | 较弱（可能为空） |
+| L5 | 任意值 | is_default 标记 | 弱（返回默认模型） |
+| L6 | 任意值 | 第一个有值 | 最弱（随机匹配） |
+
+## 4. 线上实测的模型 ID 示例
+
+```javascript
+// 从线上实际获取的 37 个模型
+// ID 格式: monkeycode/{provider}/{model}
+const modelIds = [
+  "monkeycode/BaiZhiCloud/monkeycode-pro/minimax-m2.7",
+  "monkeycode/BaiZhiCloud/kimi-k2.6",
+  "monkeycode/BaiZhiCloud/gpt-5.5",
+  "monkeycode/BaiZhiCloud/monkeycode-pro",
+  "monkeycode/BaiZhiCloud/qwen3.5-plus",
+  // ... 共 37 个
+]
+
+// L1 匹配示例:
+resolveModel("monkeycode/BaiZhiCloud/qwen3.5-plus") → ✅ 直接命中
+
+// L2 匹配示例:
+resolveModel("BaiZhiCloud/qwen3.5-plus") → ✅ 命中 L2
+
+// L3 匹配示例: 危险！
+resolveModel("monkeycode-pro") → ❌ L1 未命中 → ❌ L2 未命中
+  → → 匹配 L3: model.name === "monkeycode-pro"
+  → → → **可能匹配到错误的模型！**
+```
+
+## 5. 3 个隐蔽缺陷
+
+### 缺陷 1: L3 同名模型可能误配
+
+```javascript
+// 线上有多个 model 名称相同的模型（不同 provider）：
+const model1 = { provider: "BaiZhiCloud", model: "glm-5", ... }
+const model2 = { provider: "BaiZhiCloud", model: "glm-5", ... }  // 实际是同一个
+
+// 但如果扩展到不同 provider：
+// L3 匹配时只查 model 名，可能忽略 provider 差异
+```
+
+实际上是：37 个模型都来自 `BaiZhiCloud`，所以 L3 误配概率低。但如果扩展到多提供商，L3 可能匹配到错误 provider 的同名模型。
+
+### 缺陷 2: `display_name` 可能为空
+
+```typescript
+// proxy/src/types.ts:67-68
+name: string
+display_name: string
+```
+
+从线上数据看，部分模型 `display_name` 为空字符串。当 L4 匹配 `"" === openaiModelId` 时，空字符串永远不会匹配非空用户输入，所以 L4 实际是安全的（只是永远跳过）。
+
+### 缺陷 3: L6 兜底可能匹配错误模型
+
+当所有 5 层都失败时，`models[0]` 返回的是**模型列表的第一个**，没有任何筛选逻辑。第一个模型可能是 `pro` 级别的付费模型，basic 用户拿到这个模型后会创建任务失败。
+
+## 6. 缓存行为
+
+```typescript
+// proxy/src/models.ts:11-14
+private cacheTTL: number = 5 * 60 * 1000  // 5 分钟缓存
+
+fetchModels(): Promise<MonkeyCodeModel[]> {
+  if (this.models.length > 0 && Date.now() - this.lastFetch < this.cacheTTL) {
+    return this.models  // 缓存命中
+  }
+  // 缓存失效 → 请求后端
+  const result = await fetch(...)
+  this.models = result
+  this.lastFetch = Date.now()
+}
+```
+
+```mermaid
+flowchart TB
+    subgraph Cache["缓存逻辑"]
+        CHECK{"模型列表非空<br/>&<br/>距上次请求 < 5分钟?"}
+        HIT["✅ 返回缓存<br/>this.models"]
+        MISS["❌ 请求后端<br/>GET /api/v1/users/models"]
+        UPDATE["更新 this.models<br/>更新 lastFetch"]
+    end
+
+    subgraph Clear["缓存清理"]
+        CLEAR_API["POST /admin/refresh-models<br/>clearCache()"]
+        LOGIN_API["POST /admin/login/verify<br/>clearCache()"]
+        CLEAR["this.models = []<br/>this.lastFetch = 0"]
+    end
+
+    CHECK -->|是| HIT
+    CHECK -->|否| MISS
+    MISS --> UPDATE
+    UPDATE --> HIT
+    CLEAR_API --> CLEAR
+    LOGIN_API --> CLEAR
+```
+
+## 7. 关键发现
+
+| 发现 | 详情 |
+|------|------|
+| **6 层回退覆盖所有输入格式** | 从完整 ID 到模糊名称都支持 |
+| **L3 有误配风险** | model 名匹配忽略 provider，多提供商时可能匹配错 |
+| **L4 (display_name) 实际无效** | 线上数据 display_name 多为空 |
+| **L6 兜底可能暴露付费模型** | basic 用户拿到 pro 模型后任务会失败 |
+| **5 分钟缓存合理** | 与模型变更频率匹配 |
+| **缓存仅在 admin 端点触发清除** | 用户无法主动刷新模型列表 |
+| **大小写敏感** | 所有匹配都是 `===`，无法处理大小写差异 |
+
+## 8. 改进建议
+
+1. **L3/L4 加大小写不敏感** — `.toLowerCase()` 比较
+2. **L6 兜底按用户 access_level 过滤** — 只返回 basic 用户可用的模型
+3. **L4 跳过空 display_name** — 避免不必要的比较
+4. **增加 `resolveModel(modelId, accessLevel)` 参数** — 按用户等级过滤
+
+---
+
+**更新状态:** ✅ 新维度已分析完成
+**更新索引:** docs/08-analysis-rounds/unknown-gaps-index.md

docs/08-analysis-rounds/unknown-resource-params.md

@@ -0,0 +1,117 @@
+---
+description: 任务创建 resource 参数的实际影响深度分析 — core/memory/life 从代理请求到 Go 后端到 Docker 容器的完整链路
+protocol_version: based on proxy/src/task-runner.ts, docs/06-vm-taskflow/05-resource-management.md, Go 源码
+confidence: high
+last_verified: 2026-07-05
+---
+
+# 任务创建 resource 参数的实际影响
+
+> **所属分类:** 新维度 #27 — 任务创建 resource 参数
+> **关键发现:** `core` 和 `memory` 参数被后端完全忽略（固定 2 核/8GB），只有 `life` 真正生效
+
+## 1. 两层资源模型的真实行为
+
+```mermaid
+flowchart TB
+    subgraph Proxy["代理层请求"]
+        P_CORE["resource.core = 1"]
+        P_MEM["resource.memory = 1GB"]
+        P_LIFE["resource.life = 3600s"]
+    end
+
+    subgraph Parse["Go 后端解析"]
+        GO_CORE["Cores: '2'<br/>(固定值，忽略请求)"]
+        GO_MEM["Memory: 8GB<br/>(固定值，忽略请求)"]
+        GO_LIFE["Life: 3600s<br/>(使用请求值)"]
+        GO_CONCUR["并发限制: 3<br/>(team_policy.go)"]
+    end
+
+    subgraph Docker["Docker 容器实际分配"]
+        D_CPU["--cpus=2"]
+        D_MEM["--memory=8g"]
+        D_LIFE["--stop-timeout=3600"]
+    end
+
+    P_CORE -.->|❌ 忽略| GO_CORE
+    P_MEM -.->|❌ 忽略| GO_MEM
+    P_LIFE -->|✅ 使用| GO_LIFE
+    GO_CORE --> D_CPU
+    GO_MEM --> D_MEM
+    GO_LIFE --> D_LIFE
+    GO_CONCUR -->|超限则 429| D_QUEUE["任务排队"]
+```
+
+## 2. 参数对比表
+
+| 参数 | 代理请求值 | 后端实际值 | 是否生效 | 最终 Docker 值 |
+|------|-----------|-----------|---------|-------------|
+| `core` | 1 | **2** (固定) | ❌ 忽略 | `--cpus=2` |
+| `memory` | 1,073,741,824 (1GB) | **8,589,934,592 (8GB)** (固定) | ❌ 忽略 | `--memory=8g` |
+| `life` | 3,600 (1h) | 3,600 (使用请求值) | ✅ 生效 | `docker run --stop-timeout=3600` |
+
+## 3. life 参数的完整链路
+
+```mermaid
+sequenceDiagram
+    participant Proxy as 代理 task-runner.ts
+    participant Go as Go 后端
+    participant TaskFlow as TaskFlow 调度
+    participant Docker as Docker 容器
+    participant Timer as 代理超时定时器
+
+    Proxy->>Go: POST /tasks {resource: {life: 3600}}
+    Go->>TaskFlow: VM Spec {life_time: 3600s}
+    TaskFlow->>Docker: docker run --stop-timeout=3600
+    Note over Docker: 容器最多运行 3600s
+    Docker-->>TaskFlow: 超时 → 自动停止
+    
+    Note over Proxy: 同时...
+    Proxy->>Timer: setTimeout(3600000)
+    Note over Timer: 代理层也设 1h 超时
+    Timer-->>Proxy: 超时 → cleanup() + resolve()
+    
+    Note over Proxy,Docker: 双层超时保护
+    Note over Proxy: 代理层先超时（300ms 精度）
+    Note over Docker: 远端 3600s 后自动销毁
+```
+
+## 4. 代理层的超时保护
+
+```typescript
+// proxy/src/task-runner.ts:15-16
+// 匹配 resource.life = 3600 的常量
+const TASK_TIMEOUT_MS = parseInt(process.env.MONKEYCODE_TASK_TIMEOUT_MS || "3600000", 10)
+// 可通过环境变量覆盖，默认 3600000ms = 1h = resource.life
+
+// 超时处理（proxy/src/task-runner.ts:180-186）
+setTimeout(() => {
+  if (!resolved) {
+    console.warn(`[TaskRunner] Task ${taskId} timed out after ${TASK_TIMEOUT_MS / 1000}s`)
+    cleanup()  // 只关本地 WS
+    resolve()  // 静默结束
+  }
+}, TASK_TIMEOUT_MS)
+```
+
+## 5. core 和 memory 被忽略的后果
+
+- 后端不论请求什么值都是 **2 核 8GB**，这是**固定配置**，走配置中心或环境变量
+- 这意味着免费用户和付费用户拿到的 VM 资源**完全相同**
+- 唯一区分付费等级的是 `concurrency limit`（团队并发上限 3）
+
+## 6. 关键发现
+
+| 发现 | 详情 |
+|------|------|
+| **core/memory 参数被忽略** | 无论请求什么值，后端固定分配 2核/8GB |
+| **life 参数完全生效** | Docker 容器的停止时间和代理超时都使用它 |
+| **双层超时保护** | 代理层 HTTP 超时(更早) + Docker 远端超时(兜底) |
+| **`TASK_TIMEOUT_MS` 可配** | 但 resource.life 是 hardcoded 3600 |
+| **免费/付费资源无差异** | CPU/内存相同，仅并发数不同 |
+| **主机是 Mac Studio** | 104 核 CPU / ~800GB 内存，资源充足 |
+
+---
+
+**更新状态:** ✅ 新维度已分析完成
+**更新索引:** docs/08-analysis-rounds/unknown-gaps-index.md