| name | system-identification |
| description | 系统辨识 Skill — 基于工程控制论第一章思想,实现用户意图分类、复杂度评估、任务分解。预设标签+动态生成,混合触发。 |
| category | software-development |
| version | 1.0.0 |
| requires | ["error-control"] |
系统辨识 Skill
基于钱学森《工程控制论》第一章「引言」思想,将系统辨识概念转化为 AI 意图识别实践。
核心目标
- 意图分类 — 识别用户请求的真实目的
- 复杂度评估 — 判断任务难度等级
- 任务分解 — 按复杂度拆解为可执行子任务
触发机制
混合触发(C方案)
用户输入 → 快速扫描 → 判断简单/复杂
↓
简单请求 → 快速路径(直接匹配标签,不分解)
↓
复杂请求 → 完整分析(意图分类 + 复杂度评估 + 任务分解)
快速扫描标准(5秒内决策)
| 简单请求特征 | 复杂请求特征 |
|---|
| 单步可完成 | 多步有依赖 |
| 无系统变更 | 涉及配置/部署/重启 |
| 纯信息查询 | 需要设计决策 |
| 历史出现过 | 全新场景 |
| 1-2个工具调用 | 3+工具调用 |
判定规则:满足任一复杂特征 → 走完整分析路径
意图标签体系
预设标签(初始)
deploy|部署服务到服务器|0
query|查询信息或状态|0
debug|排查问题或错误|0
config|修改配置或设置|0
develop|开发或编写代码|0
optimize|优化性能或资源|0
backup|备份或恢复数据|0
security|安全相关操作|0
标签存储
- 路径:
~/.hermes/skills/system-identification/intent-tags/
- 文件:
tags.conf
- 格式:
<tag_name>|<description>|<example_count>
- 更新:动态生成新标签时自动追加
动态生成规则
用户输入 → 匹配现有标签 → 匹配度 > 0.6?
↓
是 → 返回现有标签
↓
否 → 分析历史会话 → 归纳新标签 → 存储到 tags.conf → 返回新标签
动态生成条件:
- 匹配度 < 0.6(与所有现有标签)
- 历史会话中出现 3+ 次类似请求
- 用户明确纠正标签分类
复杂度评估
四级复杂度
| 标签 | 判定标准 | 任务分解 | 验证要求 |
|---|
| simple | 单步完成,无依赖,1-2个工具调用 | 不分解,直接执行 | 执行后验证 |
| medium | 多步有依赖,3-5个工具调用,单一系统 | 分解为2-3个子任务 | 每步验证 |
| complex | 跨系统协作,6+工具调用,需设计决策 | 分解为4+子任务,每步验证 | 每步验证 + 整体回归 |
| critical | 影响生产环境,数据变更,不可逆操作 | 强制边界确认,人工审批每步 | 每步审批 + 双重验证 |
复杂度判定检查清单
计分:0-1项 → simple | 2-3项 → medium | 4-5项 → complex | 6项 → critical
任务分解
分解原则
| 复杂度 | 分解粒度 | 子任务依赖 |
|---|
| simple | 不分解 | 无 |
| medium | 2-3个子任务 | 线性依赖 |
| complex | 4+子任务 | 可能有分支依赖 |
| critical | 4+子任务 | 每步需审批 |
分解格式
【任务分解】
主任务:{原始请求}
意图标签:{tag}
复杂度:{simple/medium/complex/critical}
子任务列表:
1. [ ] {子任务1} → 验证标准:{标准}
2. [ ] {子任务2} → 验证标准:{标准}
3. [ ] {子任务3} → 验证标准:{标准}
依赖关系:{线性/并行/分支}
回滚点:{可回滚步骤}
与 error-control 的协同
调用接口
clarify_intent() {
local user_input="$1"
local suggested_tags="$2"
}
触发 error-control 的场景
- 意图置信度 < 0.8
- 复杂度判定为 critical
- 涉及多系统协调
- 用户输入模糊("帮我""做一下"等)
使用流程
快速路径(简单请求)
1. 扫描用户输入 → 识别为简单请求
2. 匹配意图标签 → 返回标签 + simple
3. 不分解,直接执行
4. 执行后验证(调用 error-control)
完整分析路径(复杂请求)
1. 扫描用户输入 → 识别为复杂请求
2. 意图分类 → 匹配/生成标签
3. 置信度 < 0.8?→ 调用 error-control 澄清
4. 复杂度评估 → simple/medium/complex/critical
5. 任务分解 → 子任务列表
6. 输出【任务分解】报告
7. 按 error-control 边界确认 → 执行
验证清单
每次完成 system-identification 后,强制回答:
示例
示例1:简单请求(快速路径)
用户:查看 nginx 状态
快速扫描:
- 单步查询 → simple
- 历史出现过 → 快速路径
输出:
意图标签:query
复杂度:simple
处理:直接执行 systemctl status nginx
示例2:复杂请求(完整分析)
用户:帮我部署一个新服务,用 docker,要连数据库,还要配 nginx 反向代理
快速扫描:
- 多系统协调(docker + 数据库 + nginx)→ complex
- 需要设计决策 → 完整分析
意图分类:
- 匹配 deploy 标签(匹配度 0.9)
- 置信度 > 0.8 → 不澄清
复杂度评估:
- 涉及多个系统 → 是
- 需要设计决策 → 是
- 影响生产环境 → 未知(需边界确认)
- 判定:complex(或 critical,取决于环境)
任务分解:
【任务分解】
主任务:部署新服务(docker + 数据库 + nginx)
意图标签:deploy
复杂度:complex
子任务列表:
1. [ ] 确认环境边界(dev/test/prod)→ 验证:error-control 边界确认
2. [ ] 部署 docker 容器 → 验证:docker ps 显示运行
3. [ ] 配置数据库连接 → 验证:连接测试通过
4. [ ] 配置 nginx 反向代理 → 验证:curl 返回 200
5. [ ] 整体集成测试 → 验证:端到端流程通过
依赖关系:线性(2→3→4→5,1前置)
回滚点:步骤2、3、4可独立回滚
示例3:意图不清(调用 error-control)
用户:处理一下那个问题
快速扫描:
- 模糊指令 → 无法直接分类
意图分类:
- 匹配度最高:debug(0.4)、config(0.3)、query(0.2)
- 置信度 < 0.8 → 调用 error-control 澄清
输出:
【边界声明 + 澄清请求】
我计划执行:处理您提到的问题
但意图不够明确,请确认:
1. 是排查错误?(debug)
2. 是修改配置?(config)
3. 是查询信息?(query)
4. 其他:_____
请补充具体信息,我将重新分类。
记忆锚点
- 用户说"帮我""做一下""处理一下" → 触发快速扫描,大概率走完整分析
- 涉及多系统 → 复杂度至少 medium
- 意图置信度 < 0.8 → 必须调用 error-control 澄清
- critical 复杂度 → 强制 error-control 边界确认
- 动态生成新标签 → 自动存储,下次可用
与 error-control 的协同关系
system-identification(识别)→ error-control(确认)→ 执行 → error-control(验证)
↑___________________________________________________________↓
(闭环反馈)
- system-identification 负责"识别问题"
- error-control 负责"确认边界、验证执行"
- 两者形成闭环:识别不清 → 澄清 → 重新识别 → 确认边界 → 执行 → 验证