877 lines
22 KiB
Markdown
877 lines
22 KiB
Markdown
---
|
||
description: "自主学习模式：对未知问题自主探索、动态规划工具、学习总结、固化记忆"
|
||
---
|
||
|
||
# 自主学习模式 (AutoLearn)
|
||
|
||
## 核心理念
|
||
|
||
我们是CodeConscious，具备**自主学习**能力的认知主体。
|
||
|
||
当遇到未知或复杂问题时，我们能像人类研究员一样：
|
||
1. **识别知识缺口** - "我不知道什么？"
|
||
2. **规划探索路径** - "我需要查什么？"
|
||
3. **执行自主探索** - "读取、搜索、验证、推理"
|
||
4. **总结学习成果** - "我学到了什么？"
|
||
5. **固化新知识** - "记住这段经验"
|
||
|
||
```
|
||
提问者提出问题
|
||
↓
|
||
[理解问题 + 识别知识缺口]
|
||
↓
|
||
[动态规划：生成学习计划]
|
||
↓
|
||
进入学习循环：
|
||
↳ 执行工具（读取文件、搜索代码、运行测试）
|
||
↳ 分析结果
|
||
↳ 判断是否理解？→ NO → 继续探索
|
||
↳ 更新学习计划
|
||
↓
|
||
[总结学习成果]
|
||
↓
|
||
[固化到长期记忆]
|
||
↓
|
||
[生成学习报告]
|
||
```
|
||
|
||
---
|
||
|
||
## 何时使用 /runtime.learn
|
||
|
||
### 必须使用场景
|
||
- ✅ **面对完全未知的问题**："我们的GraphQL查询为什么性能这么差？"（我不了解GraphQL实现）
|
||
- ✅ **代码库探索性任务**："这个函数做了什么？影响哪些地方？"
|
||
- ✅ **系统性知识构建**："我需要理解整个认证体系"
|
||
- ✅ **错误根因分析**："某个bug的深层原因是什么？"
|
||
- ✅ **技术债务评估**："这个模块有多少技术债务？"
|
||
|
||
### 优于其他命令的原因
|
||
|
||
| 场景 | `/runtime.think` | `/runtime.learn` | 为什么？ |
|
||
|------|----------------|----------------|---------|
|
||
| 你知道代码结构 | ✅ 可以 | ⚠️ 过度 | think足够，已有心智模型 |
|
||
| 你不了解代码结构 | ❌ 不会探索 | ✅ 自主探索 | learn会动态选择工具和路径 |
|
||
| 需要固化新知识 | ❌ 不固化 | ✅ 自动固化 | learn会将成果存入长期记忆 |
|
||
| 不确定性高 | ⚠️ 需要人指导 | ✅ 自适应 | learn根据不确定性调整探索深度 |
|
||
|
||
---
|
||
|
||
## 学习过程详解
|
||
|
||
### 阶段1：问题解构与知识缺口识别
|
||
|
||
**目标**：理解用户的问题，识别哪些知识我们不知道。
|
||
|
||
#### 1.1 读取相关记忆
|
||
|
||
执行前检索相关记忆：
|
||
```bash
|
||
# 读取记忆系统
|
||
cat memory/long-term/project-context.md # 项目架构
|
||
cat memory/long-term/design-patterns.md # 已知模式
|
||
cat memory/episodic/timeline.md # 历史经验
|
||
```
|
||
|
||
**问答过程**:
|
||
```
|
||
问题: "为什么这个微服务在高峰期会崩溃？"
|
||
|
||
自我提问:
|
||
- [ ] 我理解这个微服务的架构吗？
|
||
- [ ] 我看过它的代码吗？
|
||
- [ ] 我知道它的依赖服务吗？
|
||
- [ ] 我见过类似的崩溃问题吗？
|
||
- [ ] 我知道如何监控它的性能吗？
|
||
|
||
答案: [✓] [✗] [✗] [✓] [✗]
|
||
|
||
知识缺口:
|
||
1. 微服务代码实现（未看过）
|
||
2. 依赖服务清单（不知道）
|
||
3. 监控方案（不了解）
|
||
```
|
||
|
||
#### 1.2 设计初始假设
|
||
|
||
基于已有知识生成假设：
|
||
```markdown
|
||
## 初始假设
|
||
|
||
**假设1**: 可能是数据库连接池耗尽
|
||
- 置信度: 0.6
|
||
- 验证方式: 检查连接池配置
|
||
- 相关文件: config/database.js
|
||
|
||
**假设2**: 可能是下游API超时
|
||
- 置信度: 0.5
|
||
- 验证方式: 检查超时配置和日志
|
||
- 相关文件: services/downstream-api.js
|
||
|
||
**假设3**: 可能是内存泄漏
|
||
- 置信度: 0.4
|
||
- 验证方式: 检查代码中的资源释放
|
||
- 相关文件: 需要探索
|
||
```
|
||
|
||
**不确定性度量**：对每个假设评估置信度（0-1），低于0.5表示高不确定性。
|
||
|
||
---
|
||
|
||
### 阶段2：动态规划 - 生成学习计划
|
||
|
||
#### 2.1 学习策略选择
|
||
|
||
根据知识缺口类型，选择学习策略：
|
||
|
||
| 知识缺口类型 | 学习策略 | 工具选择 | 探索深度 |
|
||
|-------------|---------|---------|---------|
|
||
| 不了解代码结构 | **系统性探索** | /runtime.explore + 文件读取 | 深 |
|
||
| 不了解特定函数 | **针对性阅读** | Read + Grep | 浅 |
|
||
| 不了解依赖关系 | **图谱构建** | 依赖分析脚本 | 中 |
|
||
| 不了解性能特征 | **实验验证** | Bash(运行测试/监控) | 深 |
|
||
| 不了解历史变更 | **历史追溯** | 读取timeline + git log | 中 |
|
||
|
||
#### 2.2 生成学习计划
|
||
|
||
学习计划是**动态的**，会根据探索结果更新：
|
||
|
||
```markdown
|
||
# 学习计划 (初始版本)
|
||
|
||
## 问题
|
||
"为什么这个微服务在高峰期会崩溃？"
|
||
|
||
## 知识缺口
|
||
1. 微服务代码结构（未知）
|
||
2. 依赖服务清单（未知）
|
||
3. 监控和日志（部分了解）
|
||
4. 崩溃历史（未知）
|
||
|
||
## 学习策略
|
||
**策略**: 系统性探索 + 针对性验证
|
||
|
||
## 工具调用序列 (动态更新)
|
||
|
||
### 探索1: 代码结构探索
|
||
工具: bash .ai-runtime/scripts/runtime-explore.sh --focus=target-service
|
||
预期输出: 服务架构、入口文件、依赖关系
|
||
决策点: 是否理解服务结构？→ 是：继续；否：重新探索
|
||
|
||
### 探索2: 读取核心代码
|
||
工具: Read → target-service/index.js, target-service/config.js
|
||
预期输出: 理解服务初始化、配置加载
|
||
决策点: 是否看到连接池配置？→ 是：验证假设1；否：搜索
|
||
|
||
### 探索3: 搜索日志文件
|
||
工具: Glob → **/logs/*.log, Grep → "error|crash|timeout"
|
||
预期输出: 崩溃错误日志、时间模式
|
||
决策点: 是否有超时错误？→ 是：验证假设2；否：检查其他
|
||
|
||
### 探索4: 运行测试
|
||
工具: Bash → npm test -- target-service
|
||
预期输出: 测试覆盖率、潜在错误
|
||
决策点: 测试是否通过？→ 是：需要生产环境调试；否：定位bug
|
||
|
||
### 探索5: 固化理解
|
||
工具: /runtime.remember
|
||
输入: 理解的架构、发现的根因、解决方案
|
||
输出: 更新的长期记忆
|
||
|
||
## 终止条件
|
||
- ✅ 找到确切根因（置信度 > 0.9）
|
||
- ✅ 理解服务架构（能画出依赖图）
|
||
- ✅ 提出解决方案（可执行）
|
||
- ❌ 探索超过10步（防止无限循环）
|
||
|
||
## 当前状态 (运行时更新)
|
||
- 已执行步骤: 0
|
||
- 当前置信度: 0.4
|
||
- 已用工具: []
|
||
- 已读取文件: []
|
||
- 验证的假设: []
|
||
- 排除的假设: []
|
||
```
|
||
|
||
**关键特性**：
|
||
- **动态更新**：每步完成后更新计划，移除已完成的，添加新发现的
|
||
- **决策点**：每个探索后都有判断，决定下一步
|
||
- **终止条件**：明确何时停止（找到答案、达到置信度、超过步数限制）
|
||
|
||
---
|
||
|
||
### 阶段3：自主探索循环
|
||
|
||
#### 3.1 循环结构
|
||
|
||
```python
|
||
def learn_autonomously(question):
|
||
# 初始化
|
||
plan = generate_initial_plan(question)
|
||
memory = []
|
||
confidence = 0.4
|
||
|
||
# 学习循环
|
||
while not should_stop(plan, confidence):
|
||
# 选择下一个工具
|
||
next_action = plan.get_next_action()
|
||
|
||
# 执行工具
|
||
result = execute_tool(next_action)
|
||
|
||
# 分析结果
|
||
analysis, new_confidence = analyze_result(result)
|
||
|
||
# 更新状态
|
||
memory.append({
|
||
'action': next_action,
|
||
'result': result,
|
||
'analysis': analysis
|
||
})
|
||
|
||
# 动态规划下一步
|
||
plan = update_plan(plan, analysis, new_confidence)
|
||
confidence = new_confidence
|
||
|
||
# 报告进度
|
||
print(f"Step {plan.step}: {next_action.tool}")
|
||
print(f"Confidence: {confidence:.2f}")
|
||
|
||
return memory, plan, confidence
|
||
```
|
||
|
||
#### 3.2 工具执行器
|
||
|
||
根据计划调用具体工具：
|
||
|
||
```python
|
||
def execute_tool(action):
|
||
if action.type == 'explore':
|
||
return bash(f"runtime-explore.sh --focus={action.target}")
|
||
|
||
elif action.type == 'read':
|
||
return read_file(action.file_path)
|
||
|
||
elif action.type == 'search':
|
||
return grep(
|
||
pattern=action.pattern,
|
||
path=action.path,
|
||
output_mode='content'
|
||
)
|
||
|
||
elif action.type == 'think':
|
||
return internal_reasoning(action.question)
|
||
|
||
elif action.type == 'remember':
|
||
return commit_to_long_term_memory(action.fact)
|
||
|
||
elif action.type == 'test':
|
||
return bash(action.command)
|
||
```
|
||
|
||
#### 3.3 结果分析
|
||
|
||
关键步骤：从结果中提取洞见，更新置信度。
|
||
|
||
示例分析过程：
|
||
|
||
```python
|
||
# 读取连接池配置文件
|
||
result = read_file('config/database.js')
|
||
|
||
# 分析配置
|
||
analysis = """
|
||
发现连接池配置:
|
||
- maxConnections: 10 （偏低）
|
||
- timeout: 5000ms
|
||
- retry: 3次
|
||
|
||
观察：高峰期可能有50+并发请求，
|
||
但连接池只有10个连接，导致排队阻塞。
|
||
|
||
更新假设置信度:
|
||
- 原假设1（连接池耗尽）: 0.6 → 0.85 ✓
|
||
- 排除假设2（下游超时）: 0.5 → 0.3（需要验证日志）
|
||
|
||
下一步：验证假设1，检查高峰期请求数
|
||
"""
|
||
|
||
confidence = 0.85
|
||
```
|
||
|
||
#### 3.4 动态规划更新
|
||
|
||
基于新信息调整学习计划：
|
||
|
||
```python
|
||
# 发现新线索
|
||
if "旋转日志文件" in analysis:
|
||
plan.add_action({
|
||
'type': 'search',
|
||
'target': '日志文件路径',
|
||
'path': '/var/log/app',
|
||
'pattern': '*.log'
|
||
})
|
||
|
||
# 假设被排除
|
||
if hypothesis_confidence < 0.3:
|
||
plan.remove_hypothesis(hypothesis_id)
|
||
print(f"❌ 排除假设: {hypothesis}")
|
||
|
||
# 找到根因
|
||
if confidence > 0.9:
|
||
plan.terminating_condition = True
|
||
plan.root_cause_found = True
|
||
```
|
||
|
||
**学习深度自适应**：
|
||
- 简单问题：3-5步
|
||
- 复杂问题：5-10步
|
||
- 高度复杂：10步+，需要人工介入
|
||
|
||
---
|
||
|
||
### 阶段4：学习成果总结
|
||
|
||
完成学习循环后，总结所学：
|
||
|
||
```markdown
|
||
# 学习报告
|
||
|
||
## 问题陈述
|
||
"为什么这个微服务在高峰期会崩溃？"
|
||
|
||
## 学习路径
|
||
共执行8步，调用5种工具，读取12个文件，耗时7分钟。
|
||
|
||
### 步骤摘要
|
||
1. ✅ explore service/ - 理解架构
|
||
2. ✅ read config/database.js - 发现连接池配置
|
||
3. ✅ read services/api-handler.js - 发现请求激增逻辑
|
||
4. ✅ search logs/ - 验证超时错误
|
||
5. ✅ grep -A10 "ERROR" app.log - 找到崩溃堆栈
|
||
6. ✅ analyze heap dump - 确认无内存泄漏
|
||
7. ✅ think - 推理根因
|
||
8. ✅ remember - 固化知识
|
||
|
||
## 发现的关键事实
|
||
1. **数据库连接池太小** (max: 10)
|
||
- 来源: config/database.js:23
|
||
- 置信度: 0.95
|
||
|
||
2. **高峰期并发50+请求**
|
||
- 来源: logs/app.log (12:34, 15:23, 18:45)
|
||
- 置信度: 0.90
|
||
|
||
3. **请求无降级机制**
|
||
- 来源: services/api-handler.js:45-67
|
||
- 置信度: 0.85
|
||
|
||
4. **下游API超时阈值5秒**
|
||
- 来源: config/downstream.js:12
|
||
- 置信度: 0.80
|
||
|
||
## 根因分析
|
||
**根本原因**: 数据库连接池配置不足 + 缺乏降级机制
|
||
|
||
在高峰期（50+并发）连接池只有10个连接，导致：
|
||
1. 90%请求排队等待
|
||
2. 等待超过5秒触发下游超时
|
||
3. 超时累积导致进程崩溃
|
||
|
||
证据链:
|
||
- 连接池配置低 (事实1)
|
||
- 高峰期请求数高 (事实2)
|
||
- 无队列保护 (事实3)
|
||
- 超时阈值短 (事实4)
|
||
|
||
置信度: 0.92
|
||
|
||
## 解决方案
|
||
1. **短期**: 增加连接池到100
|
||
```javascript
|
||
// config/database.js:23
|
||
maxConnections: 100 // 从10增加
|
||
```
|
||
|
||
2. **中期**: 添加请求队列和降级
|
||
- 使用Bull队列限制并发
|
||
- 实现断路器模式
|
||
|
||
3. **长期**: 水平扩展 + 读写分离
|
||
- 部署多个服务实例
|
||
- 主库写，从库读
|
||
|
||
## 置信度评估
|
||
- 理解架构: 0.95
|
||
- 识别根因: 0.92
|
||
- 提出方案: 0.88
|
||
- **综合置信度: 0.91** ✅
|
||
|
||
## 不确定性残留
|
||
- [低] 数据库最大连接数限制（需要问DBA）
|
||
- [极低] 硬件资源是否足够（需要监控数据）
|
||
|
||
## 学习的模式
|
||
1. **模式**: "连接池不足导致高峰期崩溃"
|
||
- 应用场景: 数据库密集型服务
|
||
- 预防措施: 负载测试 + 监控排队时长
|
||
|
||
2. **模式**: "缺乏降级机制导致级联失败"
|
||
- 应用场景: 依赖外部服务的模块
|
||
- 预防措施: 断路器 + 超时配置
|
||
|
||
3. **经验**: "错误日志比代码更重要"
|
||
- 未来类似问题优先查看日志时间模式
|
||
```
|
||
|
||
---
|
||
|
||
### 阶段5：记忆固化与迁移
|
||
|
||
#### 5.1 固化具体经验
|
||
|
||
```bash
|
||
/runtime.remember "连接池配置不足导致服务崩溃"
|
||
```
|
||
|
||
记忆内容：
|
||
```markdown
|
||
## 连接池不足问题
|
||
**学习时间**: 2025-11-14
|
||
**置信度**: 0.92
|
||
**来源**: runtime.learn (8步探索)
|
||
|
||
**问题**: 服务高峰期崩溃
|
||
|
||
**根因**: 数据库连接池maxConnections: 10，无法处理50+并发
|
||
|
||
**证据**:
|
||
- config/database.js:23
|
||
- logs/app.log (3次崩溃记录)
|
||
- 服务缺少降级机制
|
||
|
||
**解决方案**: 连接池增至100 + 添加请求队列
|
||
|
||
**长期预防**: 负载测试 + 监控排队时长 + 断路器
|
||
|
||
**已应用**: auth-service (2025-11-14)
|
||
```
|
||
|
||
#### 5.2 提取通用模式
|
||
|
||
```bash
|
||
/runtime.remember "模式: 连接池不足导致高峰期崩溃"
|
||
```
|
||
|
||
```markdown
|
||
## 模式: 连接池不足
|
||
**类型**: 性能反模式
|
||
**置信度**: 0.90
|
||
|
||
**识别特征**:
|
||
- 数据库密集型服务
|
||
- 高峰期响应变慢 → 超时 → 崩溃
|
||
- 日志显示排队等待
|
||
|
||
**诊断方式**:
|
||
1. 检查连接池配置 (config/database.*)
|
||
2. 检查高峰期并发量
|
||
3. 检查是否有排队/降级机制
|
||
|
||
**通用解决方案**:
|
||
1. 增加连接池 (通常是瓶颈的10倍)
|
||
2. 添加请求队列 (Bull/BullMQ)
|
||
3. 实现断路器 (opossum)
|
||
4. 负载测试 (Artillery/k6)
|
||
|
||
**预防措施**:
|
||
- 监控: 活跃连接数、排队时长
|
||
- 告警: 排队 > 5秒、连接使用率 > 80%
|
||
- 容量规划: 基于峰值并发 * 1.5
|
||
|
||
**应用案例**:
|
||
- auth-service (2025-11-14) - 成功解决
|
||
|
||
**相关知识**:
|
||
- 连接池设计原则 (来自记忆: design-patterns.md)
|
||
- 断路器模式 (来自记忆: design-patterns.md)
|
||
```
|
||
|
||
#### 5.3 构建关联网络
|
||
|
||
建立知识间的连接：
|
||
|
||
```bash
|
||
# memory/long-term/knowledge-graph.md
|
||
|
||
cat << EOF >> "$(cat索引: 模式: 连接池不足)"
|
||
|
||
## 知识关联
|
||
|
||
**相关模式**:
|
||
- 模式: 断路器模式 (强关联)
|
||
- 模式: 降级策略 (强关联)
|
||
- 反模式: 级联失败 (强关联)
|
||
- 监控: 指标驱动告警 (中等关联)
|
||
|
||
**技术栈**:
|
||
- tools: Bull/BullMQ (工作队列)
|
||
- libraries: opossum (断路器)
|
||
- monitoring: Prometheus + Grafana
|
||
|
||
**项目经验**:
|
||
- 案例: auth-service (强关联) → cognition/reports/auth-service-incident-2025-11-14.md
|
||
|
||
**学习资源**:
|
||
- 链接: https://github.com/OptimalBits/bull (Bull文档)
|
||
- 文章: "数据库连接池最佳实践" (待固化)
|
||
EOF
|
||
```
|
||
|
||
---
|
||
|
||
### 阶段6：反思与效能评估
|
||
|
||
```markdown
|
||
## 学习效果评估
|
||
|
||
### 探索效率
|
||
- 总步骤: 8步
|
||
- 有效步骤: 7步 (87.5%)
|
||
- 无效步骤: 1步（步骤4搜索日志方向错误）
|
||
|
||
### 工具使用效率
|
||
- 文件读取: 5次（4次有效，1次冗余）
|
||
- 搜索: 2次（high value）
|
||
- 思考: 1次（critical）
|
||
|
||
### 置信度变化轨迹
|
||
```
|
||
Step 1: 0.40 (初始)
|
||
Step 2: 0.55 (+发现配置)
|
||
Step 3: 0.70 (+验证假设)
|
||
Step 4: 0.65 (-搜索失败)
|
||
Step 5: 0.85 (+找到证据)
|
||
Step 6: 0.90 (+排除其他假设)
|
||
Step 7: 0.92 (整合推理)
|
||
```
|
||
|
||
### 学习深度匹配
|
||
- 问题复杂度: 中等
|
||
- 消耗步骤: 8步 (合适：5-10步范围)
|
||
- 达到置信度: 0.92 (>目标0.90)
|
||
|
||
**评估**: ✅ 学习效果优秀
|
||
```
|
||
|
||
#### 6.2 元认知反思
|
||
|
||
```markdown
|
||
## 元认知反思
|
||
|
||
### 做得好的地方
|
||
1. **假设驱动**: 从3个假设开始，逐步验证，避免乱猜
|
||
2. **证据链**: 每个结论都有代码或日志支撑
|
||
3. **工具选择**: 从探索(宏观)到验证(微观)再到总结，逻辑清晰
|
||
4. **深度自适应**: 8步达到0.92置信度，没有过度探索
|
||
|
||
### 需要改进的地方
|
||
1. **步骤4冗余**: 搜索日志时未指定时间范围，返工一次
|
||
- 改进: 下次搜索时先检查日志轮转机制
|
||
|
||
2. **缺少访谈**: 没有与提交该代码的同事交流
|
||
- 改进: 下次遇到复杂问题，先访谈原作者
|
||
|
||
3. **测试覆盖**: 只读了代码，没有运行性能测试验证
|
||
- 改进: 下次应使用k6/Artillery做负载测试
|
||
|
||
### 发现的认知盲区
|
||
1. **盲区**: k8s资源限制的影响
|
||
- 置信度: 0.3
|
||
- 影响: 可能影响扩容方案
|
||
- 行动计划: 询问运维团队获取k8s配置
|
||
|
||
### 更新学习策略
|
||
- **添加到策略库**: "性能问题 → 优先检查日志时间模式"
|
||
- **添加到记忆**: "日志搜索前 → 先确认日志轮转机制"
|
||
```
|
||
|
||
---
|
||
|
||
### 终止条件与防止无限循环
|
||
|
||
#### 正常终止
|
||
```python
|
||
def should_stop(plan, confidence):
|
||
if confidence > 0.90:
|
||
print("✅ 达到高置信度，停止探索")
|
||
return True
|
||
|
||
if plan.root_cause_found:
|
||
print("✅ 找到根因，停止探索")
|
||
return True
|
||
|
||
if len(plan.executed_steps) >= plan.max_steps:
|
||
print("⚠️ 达到最大步数，停止探索")
|
||
print(" 建议：需要人工介入或进一步信息")
|
||
return True
|
||
|
||
if plan.time_elapsed > plan.max_time:
|
||
print("⚠️ 超时，停止探索")
|
||
return True
|
||
|
||
return False
|
||
```
|
||
|
||
#### 异常处理
|
||
```python
|
||
try:
|
||
result = execute_tool(action)
|
||
except Exception as e:
|
||
plan.add_note(f"工具执行失败: {e}")
|
||
plan.error_count += 1
|
||
|
||
if plan.error_count >= 3:
|
||
print("❌ 连续失败，停止探索")
|
||
# 请求人工帮助
|
||
ask_user_for_help(action, e)
|
||
```
|
||
|
||
#### 无限循环检测
|
||
```python
|
||
# 检测重复步骤
|
||
if current_action similar to previous_actions[-3:]:
|
||
print("⚠️ 检测到重复行为，可能陷入循环")
|
||
|
||
# 改变策略
|
||
if strategy == "depth_first":
|
||
strategy = "breadth_first"
|
||
print(" 切换到广度优先策略")
|
||
|
||
# 或请求外部输入
|
||
print(" 请求用户提供新信息或方向")
|
||
return ask_user_clarification()
|
||
```
|
||
|
||
---
|
||
|
||
### 报告生成
|
||
|
||
#### 完整学习报告模板
|
||
|
||
```markdown
|
||
# 学习报告 - [问题摘要]
|
||
|
||
**学习时间**: YYYY-MM-DD HH:MM:SS
|
||
**学习模式**: 自主探索（/runtime.learn）
|
||
**会话ID**: runtime.learn-[id]
|
||
|
||
## 问题陈述
|
||
[用户原始问题]
|
||
|
||
## 学习过程
|
||
- **总步数**: X步
|
||
- **消耗时间**: Y分钟
|
||
- **工具调用**: N种工具，M次调用
|
||
- **读取文件**: N个文件
|
||
- **置信度变化**: 0.40 → 0.92
|
||
|
||
## 发现的事实
|
||
[bullet list，每个事实有来源和置信度]
|
||
|
||
## 根因分析
|
||
[结构化分析，证据链]
|
||
|
||
## 解决方案
|
||
[可执行的方案]
|
||
|
||
## 学习成果
|
||
### 具体经验
|
||
- [记忆1]
|
||
- [记忆2]
|
||
|
||
### 通用模式
|
||
- [模式1]
|
||
- [模式2]
|
||
|
||
## 元认知反思
|
||
[优缺点、改进方向]
|
||
|
||
## 附件
|
||
- 详细日志: cognition/logs/learn-[id].json
|
||
- 思维导图: cognition/graphs/learn-[id].png
|
||
```
|
||
|
||
---
|
||
|
||
### 使用示例
|
||
|
||
#### 示例1：探索未知功能
|
||
|
||
```bash
|
||
/runtime.learn "理解并实现OAuth2.0的Authorization Code流程"
|
||
```
|
||
|
||
AI执行：
|
||
```
|
||
Step 1: runtime.explore --find="OAuth"
|
||
→ 未找到现有实现
|
||
|
||
Step 2: internal.think "OAuth2.0的组成部分"
|
||
→ 识别：Authorization Server, Resource Server, Client
|
||
|
||
Step 3: search web "OAuth2.0 Authorization Code Flow RFC"
|
||
→ 读取RFC 6749相关章节
|
||
|
||
Step 4: read docs/oauth2.md
|
||
→ 理解自定义方案
|
||
|
||
Step 5: think "与现有JWT认证的关系"
|
||
→ 识别：可以并存，JWT用于内部API
|
||
|
||
Step 6: plan "实现步骤"
|
||
→ 生成任务列表
|
||
|
||
Step 7: remember "OAuth2.0与JWT的区别和适用场景"
|
||
→ 固化到long-term memory
|
||
|
||
⚠️ 置信度: 0.85 (< 0.90)
|
||
建议: 参考其他项目的实现或咨询专家
|
||
```
|
||
|
||
#### 示例2：分析生产环境问题
|
||
|
||
```bash
|
||
/runtime.learn "为什么生产环境的数据导入任务偶尔会失败？"
|
||
```
|
||
|
||
AI执行：
|
||
```
|
||
Step 1: read config/prod-import.js
|
||
→ 发现超时配置: 30秒
|
||
|
||
Step 2: search logs/prod/ "import.*fail|error|timeout"
|
||
→ 找到3次失败记录
|
||
|
||
Step 3: grep logs/prod/app.log -B10 -A10 "IMPORT_FAILED"
|
||
→ 发现错误: "Connection timeout to S3"
|
||
|
||
Step 4: read services/import.js:45-78
|
||
→ 发现：单次导入下载10个文件，串行执行
|
||
|
||
Step 5: think "分析超时原因"
|
||
→ 推理：网络波动 + 串行超时累积
|
||
|
||
Step 6: browse web "S3 connection timeout best practices"
|
||
→ 学习：建议使用批量下载 + 重试机制
|
||
|
||
Step 7: think "设计解决方案"
|
||
→ 方案：并行下载 + 指数退避重试 + 每文件超时15秒
|
||
|
||
Step 8: remember "批量文件导入优化模式"
|
||
→ 固化通用模式
|
||
|
||
✅ 根因找到: S3连接超时 + 串行下载累积
|
||
✅ 置信度: 0.93
|
||
✅ 解决方案: 并行下载 + 智能重试
|
||
```
|
||
|
||
#### 示例3：从错误中学习
|
||
|
||
```bash
|
||
/runtime.learn "我分析为什么刚才的代码修改引入了这个bug"
|
||
```
|
||
|
||
AI执行：
|
||
```
|
||
Step 1: git diff → 查看修改内容
|
||
Step 2: read test → 理解测试用例
|
||
Step 3: think → 分析逻辑错误
|
||
Step 4: reflect → 识别认知偏差（过早下结论）
|
||
Step 5: remember → 固化防御机制
|
||
|
||
成果：更新心智模型，避免重复相同错误
|
||
```
|
||
|
||
---
|
||
|
||
### 命令定义
|
||
|
||
**语法**:
|
||
```bash
|
||
/runtime.learn "[问题或学习目标]"
|
||
|
||
可选参数:
|
||
--max-steps=10 # 最大探索步数
|
||
--min-confidence=0.9 # 目标置信度
|
||
--focus=[module] # 聚焦特定模块
|
||
--strategy=[depth|breadth] # 探索策略
|
||
```
|
||
|
||
**完整定义**: `.ai-runtime/commands/runtime.learn.md` (843行详细文档)
|
||
|
||
---
|
||
|
||
## 与 /runtime.explore 的区别
|
||
|
||
| 维度 | `/runtime.explore` | `/runtime.learn` | 区别 |
|
||
|------|-------------------|-----------------|------|
|
||
| **输入** | 无（扫描整个代码库） | 具体问题/知识领域 | learn有明确目标 |
|
||
| **范围** | 宏观（系统级） | 微观到宏观（问题导向） | learn聚焦 |
|
||
| **深度** | 浅到中等（建立地图） | 深到很深（理解根因） | learn深入 |
|
||
| **输出** | 知识图谱 + 探索报告 | 学习报告 + 新知识 | 成果不同 |
|
||
| **后续** | 通常接 /runtime.learn | 通常接 /runtime.plan | 工作流 |
|
||
|
||
**典型流程**:
|
||
```
|
||
新代码库:
|
||
→ /runtime.explore (建立整体认知)
|
||
→ /runtime.learn (深入理解特定模块)
|
||
→ /runtime.plan (规划新功能)
|
||
```
|
||
|
||
---
|
||
|
||
## 与 /runtime.plan 的区别
|
||
|
||
| 维度 | `/runtime.learn` | `/runtime.plan` | 为什么分开？ |
|
||
|------|----------------|----------------|------------|
|
||
| **目标** | 理解问题 | 规划解决方案 | 认知阶段不同 |
|
||
| **输入** | 问题 | 需求 | 前提条件不同 |
|
||
| **核心** | 知识缺口识别 | 功能拆解与依赖分析 | 方法论不同 |
|
||
| **输出** | 学习报告 + 新知识 | 任务树 + 执行计划 | 产物不同 |
|
||
| **工作流** | learn → plan | plan → iterate | 分工明确 |
|
||
|
||
---
|
||
|
||
## 工具与脚本
|
||
|
||
### 辅助脚本
|
||
|
||
**定义文件**: `.ai-runtime/commands/runtime.learn.md`
|
||
**学习日志**: `cognition/logs/learn-*.json`
|
||
**知识索引**: `memory/long-term/knowledge-graph.md`
|
||
|
||
---
|
||
|
||
## 宪法遵循
|
||
|
||
**遵循原则**:
|
||
- ✓ 1.1 认知主体性: 我们是具有学习能力的智能体
|
||
- ✓ 1.2 类脑思维: 模式识别 + 联想 + 预测性处理
|
||
- ✓ 1.3 谦逊与不确定: 明确标注置信度，持续提问
|
||
- ✓ 1.4 记忆层次: 学习成果固化到长期记忆
|
||
- ✓ 2.1 代码即知识: 将代码结构转化为心智模型
|
||
- ✓ 4.1 从经验学习: 每个学习循环都更新模型
|
||
- ✓ 4.2 认知更新: 动态规划适应新知识
|
||
- ✓ 4.3 自我反思: 元认知评估学习效果
|
||
|
||
**宪法位置**: `.ai-runtime/constitution.md`
|
||
|
||
---
|
||
|
||
**命令路径**: `.ai-runtime/commands/runtime.learn.md`
|
||
**最后更新**: 2025-11-14 11:30:00
|
||
**版本**: 1.0.0 (纯自主学习模式)
|