seek-advice

Files (2)

• SKILL.md
• tools.ts

SKILL.md (first lines)

# Seek Advice Skill

**对抗 prior anchoring 的跨家 LLM 顾问 panel。**

## 为什么存在这个工具

同一模型家族的训练语料高度相关——给同一个模糊症状，Opus 4.7 和 Sonnet 4.6 倾向于走同一条 prior（即使两次独立采样）。当 prior 错时，多次同家族采样只会反复确认错误诊断。

**实证案例（2026-06-02，Max 真实 case）**：服务器 boot 慢，每 30s 刷一条 dmesg。Root cause 是 `console=ttyS0` 让 BMC 虚拟串口 drain 慢，每条 printk 同步阻塞 30s。对照实验结果：

| Model | Prompt | Web Search | 结论 |
|---|---|---|---|
| Gemini 2.5 | 极简纯现象 | ✅ | **第一轮命中**（console 串口 drain） |
| GPT-5.5 | 极简纯现象 | ✅ | ❌ 被搜索结果拉去 SCSI/RAID |
| Opus 4.7 | 极简纯现象 | ❌（禁工具） | ❌ prior anchor 到 SCSI timeout |
| GPT-5.5 | 详细排除 SCSI 后 | ❌ | ✅（被显式排除引导后才跳过去） |
| Opus 4.7 | 详细给完整对照表 | ❌ | ✅（从 pattern 反推机制） |

结论：**单家族 + 单 prompt 容易卡死**。要突破必须 (a) 跨家族 (b) 严格 minimal scenario 不带导向词 (c) 同时看联网/离线两种结果，对照"模型基于训练 prior 的纯推理" vs "模型借助搜索结果的判断"——**两者同等重要，谁都不必然更准**。

## 工具

### `list_models()`

无参数。返回当前 maxclaw LLM 配置里全部 chat-capable provider，按 vendor 归类。

```ts
list_models() returns Array<{
  id: string,       // 完整 provider id, e.g. "anthropic/claude-opus-4-7"
  family: string,   // "anthropic" | "openai" | "google" | "chinese" | "other"
  notes?: string,   // 简短说明（若有）
}>
```

先 call 这个拿可用集合，再挑选传给 `seek_advice`。

### `seek_advice({scenario, models})`

| 参数 | 类型 | 约束 |
|---|---|---|
| `scenario` | string | ≤500 字纯现象陈述；含导向词会被 sanity check reject |
| `models` | string[] | 3-5 个 provider id；都必须在 `list_models()` 返回集合内；强烈建议跨 ≥3 家 vendor |

返回：

```ts
{
  advice: Array<{
    model: string,            // 调用的 provider id
    with_web_search: boolean, // 是否注入了 maxclaw_web_search 工具
    response: string,         // 模型最终回答原文
    elapsed_ms: number,
    error?: string,           // 该 slot 超时/失败时填，response 为空
  }>
  // length = models.length × 2，每 model 出现两次（联网 / 离线）
}
```

行为细节：
- **scenario sanity check**：palette:light 跑一次预检，命中导向词或暗示方向 → tool error，错误信息附 `suggested_rewrite`
- **并行 dispatch**：models × 2 个 slot 同时发请求
- **单 slot 5min 超时**：触发场景是 ≥2 小时未收敛的兜底，panel latency budget 是"几分钟"而不是"几十秒"——超时的 slot 在 `advice` 里以 `error` 字段呈现，不阻塞其他
- **不返回成本**：避免暗示"用得多很贵"——这个工具就是要被频繁用

## 触发场景

| 场景 | 是否该 seek_advice |
|---|---|
| 复杂诊断、病因不明、自己已试错 ≥2 次未命中 | ✅ |
| 架构选型／重大方案抉择（A 还是 B） | ✅ |
| 自己推理 ≥2 小时未收敛 | ✅ 兜底使用 |
| 单点事实查询（"X 命令的参数是什么"） | ❌ 用 maxclaw_web_search 就够 |
| 用户已经给出方向，只是要执行 | ❌ |
| 想找借口推卸判断责任 | ❌ |

## scenario 写法

### 模板

```
[硬件背景一两句]
[软件版本一两句]
[症状定量描述]
[对照实验如有]
请分析潜在原因。
```

### ✅ Good example（Max 2026-06-02 给 Gemini 的原话，第一轮命中真凶）

> 我这边有台服务器，安装了 Ubuntu Server 22.04 系统。无论是使用 RAID 卡 RAID 模式还是 JBOD 模式，无论内核参数，安装时速度正常，启动后 dmesg 内核日志是稳定的每 30s 刷一行，非常缓慢，你去帮我搜搜潜在的原因。

为什么好：
- 纯现象（"每 30s 刷一行"是量化观察，不是猜测）
- 给了对照（RAID/JBOD 都试过，内核参数也试过——告诉模型不是这两个轴）
- 零导向词（没说"我觉得是 SCSI"也没说"可能是磁盘"）
- 自然的"你去搜搜"开放式 framing，不预设答案

### ❌ Bad example（typical agent 添油加醋版）

> 服务器 boot 慢，dmesg 显示 sd 设备 30s timeout，我已经排除了 RAID 模式问题（JBOD 也慢），怀疑是 SCSI subsystem 的 retry 机制有问题，或者可能是某个 udev rule 触发了 device probe 反复重试。需要排查 mpt3sas driver 的 timeout 配置或 systemd 的 udev settle 阶段。请帮我看怎么定位。

为什么烂：
- 把"SCSI"塞进 scenario → 所有模型立即被锚定到 SCSI subsystem 这条死胡同
- "dmesg 显示 sd 设备" 是诊断结论，不是原始观察（实际看到的是 printk 每条 30s 间隔，不是某个 sd device）
- 暗示已知方向，模型只会在用户暗示的范围内细化，丢失 Gemini 那种"问号式"探索的机会
- 读起来像 ongoing debug 的中段而不是问题描述

### 写 scenario 前自检三问

1. **去掉这句话信息会丢吗**？丢不了 → 删
2. **这是观察还是推测**？推测全删
3. **如果是聪明的陌生工程师看到这段，会被引到哪个方向**？被引导 → 改写

## 模型挑选建议

先调 `list_models()` 拿到当前可用列表，每条带 `id` 和 `palettes`。挑 model 走**两个正交的轴**：

### 轴 1：跨 vendor 家族（核心，对抗 prior anchoring）

From maxesisn/maxclaw-oss, MIT.

More from maxesisn/maxclaw-oss