🔄 卡若AI 同步 2026-02-25 20:42 | 更新:运营中枢参考资料、运营中枢工作台 | 排除 >20MB: 14 个
This commit is contained in:
252
运营中枢/参考资料/卡若AI优化方案_借鉴Yinova拆解.md
Normal file
252
运营中枢/参考资料/卡若AI优化方案_借鉴Yinova拆解.md
Normal file
@@ -0,0 +1,252 @@
|
||||
# 卡若AI 优化方案 — 借鉴 Yinova 项目拆解
|
||||
|
||||
> 来源:对 Yinova(64卦群控台)的深度拆解 + 群主5条优化建议的映射
|
||||
> 更新:2026-02-25
|
||||
> 分析者:卡若AI · 火炬 + 水泉
|
||||
|
||||
---
|
||||
|
||||
## 核心结论(先说人话)
|
||||
|
||||
**卡若AI 要从"全量加载重引擎"变成"按需调度轻协作引擎"。**
|
||||
|
||||
Yinova 的问题是"64个进程同时跑太重",卡若AI 的问题是"60个技能概念全量挂载、每次启动链路过重、协同过程缺收敛"。方向一样:**减重、收口、有规则、看得清、有护栏**。
|
||||
|
||||
---
|
||||
|
||||
## 一、减重:按需加载,不全量挂载
|
||||
|
||||
### 当前问题
|
||||
|
||||
- 每次对话启动要读 `BOOTSTRAP.md` + `SKILL_REGISTRY.md`(60 技能全表)
|
||||
- 大部分对话只用到 1~3 个技能,但概念上"全员在线"
|
||||
- 启动链路信息量大,影响响应速度与上下文利用率
|
||||
|
||||
### 优化方案
|
||||
|
||||
#### 1.1 技能分级:热/温/冷
|
||||
|
||||
| 级别 | 定义 | 加载策略 |
|
||||
|:---|:---|:---|
|
||||
| 热技能(≤8个) | 近 30 天使用 ≥3 次 | 启动时预加载到上下文 |
|
||||
| 温技能 | 近 30 天使用 1~2 次 | 仅加载触发词索引,命中后读 SKILL.md |
|
||||
| 冷技能 | 30 天未使用 | 不加载,需要时全路径读取 |
|
||||
|
||||
**实现方式**:在 `SKILL_REGISTRY.md` 增加 `heat` 字段(auto/manual),或维护一份 `运营中枢/skill_heat_map.json`,每次对话结束更新计数。
|
||||
|
||||
#### 1.2 启动瘦身
|
||||
|
||||
当前启动三步:读 BOOTSTRAP → 读 SKILL_REGISTRY → 匹配后读 SKILL.md
|
||||
|
||||
建议改为:
|
||||
|
||||
1. 读 BOOTSTRAP(保持不变,身份与流程必须在)
|
||||
2. 读**热技能摘要表**(≤8 条,含触发词+路径,不含全表)
|
||||
3. 用户输入后,按触发词匹配 → 命中热技能直接执行 → 未命中再懒加载 SKILL_REGISTRY
|
||||
|
||||
**预期收益**:启动上下文减少 60%+,响应更快。
|
||||
|
||||
---
|
||||
|
||||
## 二、收口:统一信息看板,不要散落
|
||||
|
||||
### 当前问题
|
||||
|
||||
- 任务交接靠"任务交接单"模板,但实际很少严格执行
|
||||
- 执行日志散在多个路径:`水溪/执行日志/`、`运营中枢/工作台/`、`记忆.md`
|
||||
- 跨组协作时,信息靠"概念传递"而非"实际文件中转"
|
||||
|
||||
### 优化方案
|
||||
|
||||
#### 2.1 引入"共享看板"机制
|
||||
|
||||
在 `运营中枢/` 下新增一个**轻量看板文件**:
|
||||
|
||||
```
|
||||
运营中枢/工作台/当前任务看板.md
|
||||
```
|
||||
|
||||
结构:
|
||||
|
||||
```markdown
|
||||
## 当前任务看板(自动维护)
|
||||
|
||||
| 任务ID | 描述 | 负责人 | 状态 | 上下文摘要 | 更新时间 |
|
||||
|:---|:---|:---|:---|:---|:---|
|
||||
| T001 | 部署卡若AI网关 | 金仓 | 执行中 | 端口18789已就绪 | 14:30 |
|
||||
| T002 | 拆解Yinova项目 | 火炬+水泉 | 已完成 | 10目录已产出 | 20:30 |
|
||||
```
|
||||
|
||||
**规则**:
|
||||
- 每个任务开始时,自动写入一行
|
||||
- 每个任务结束时,更新状态为"已完成"并附结果摘要
|
||||
- 跨组协作时,接收方先读看板确认上下文,不依赖口头交接
|
||||
|
||||
#### 2.2 归一化日志入口
|
||||
|
||||
目前写日志的地方至少 4 个。建议收口为 2 个:
|
||||
|
||||
| 类型 | 路径 | 写入者 |
|
||||
|:---|:---|:---|
|
||||
| 执行日志 | `运营中枢/工作台/执行日志/` | 所有角色(按日期) |
|
||||
| 经验沉淀 | `水溪/经验库/待沉淀/` | 保持不变 |
|
||||
|
||||
其他散落的日志入口(如记忆.md 的每日沉淀、gitea_push_log 等)保留但不再作为主日志。
|
||||
|
||||
---
|
||||
|
||||
## 三、讨论要有规则:引入"收敛轮次"
|
||||
|
||||
### 当前问题
|
||||
|
||||
- 思考→拆解→执行→验证 有流程,但没有"分歧怎么处理"的规则
|
||||
- 多技能匹配时"合并执行",但合并的逻辑不透明
|
||||
- 缺少"置信度"概念,用户看不到"这个结论有多靠谱"
|
||||
|
||||
### 优化方案
|
||||
|
||||
#### 3.1 跨组任务引入"观点-依据-置信度"三件套
|
||||
|
||||
当任务涉及 2 个以上负责人时,每个角色必须输出:
|
||||
|
||||
```
|
||||
- 观点:[一句话结论]
|
||||
- 依据:[数据/文件/经验]
|
||||
- 置信度:[高/中/低]
|
||||
```
|
||||
|
||||
#### 3.2 默认 2 轮收敛
|
||||
|
||||
- 第 1 轮:各角色独立输出观点+依据+置信度
|
||||
- 第 2 轮:大总管综合,**如果置信度全高 → 直接出结论**;**有低/分歧 → 追加 1 轮定向补充**
|
||||
- 最多 3 轮,第 3 轮强制由大总管裁决并标注"裁决依据"
|
||||
|
||||
#### 3.3 研讨会机制升级
|
||||
|
||||
当前协同规范里有"研讨会"流程,但触发条件模糊。建议明确:
|
||||
|
||||
| 触发条件 | 执行方式 |
|
||||
|:---|:---|
|
||||
| 涉及 ≥3 个组 | 自动走研讨会 |
|
||||
| 任一组置信度为"低" | 补充轮 + 研讨会 |
|
||||
| 用户主动要求 | 立即走研讨会 |
|
||||
|
||||
---
|
||||
|
||||
## 四、输出要清晰:推理链可见
|
||||
|
||||
### 当前问题
|
||||
|
||||
- 复盘格式强(目标/结果/达成率),但"怎么得出结论的"看不到
|
||||
- 用户看到的是结果,看不到"为什么选了这个方案而不是那个"
|
||||
|
||||
### 优化方案
|
||||
|
||||
#### 4.1 复盘增加"决策链"字段
|
||||
|
||||
在现有复盘格式中增加(可选,复杂任务时强制):
|
||||
|
||||
```markdown
|
||||
### 决策链
|
||||
- 方案A:[描述] → 不采纳,原因:[xxx]
|
||||
- 方案B:[描述] → 采纳,原因:[xxx]
|
||||
- 置信度:高
|
||||
```
|
||||
|
||||
#### 4.2 多角色任务增加"观点流"
|
||||
|
||||
类似 Yinova 建议的"中间栏各角色观点流":
|
||||
|
||||
```markdown
|
||||
### 各角色观点
|
||||
- 火炬:建议用 SQLite 替代 JSON,依据是并发写风险
|
||||
- 金仓:建议保持 JSON,依据是部署复杂度
|
||||
- 大总管裁决:采纳火炬方案,加文件锁兜底
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 五、安全护栏:超时、熔断、预算
|
||||
|
||||
### 当前问题
|
||||
|
||||
- 异常处理有红线(不改结构、不删文件、不破系统),但偏"禁止类"
|
||||
- 缺少"主动防御类"护栏:token 预算、执行超时、上下文裁剪
|
||||
- Pipeline 失败重试 2 次后只能"通知用户",缺自动降级
|
||||
|
||||
### 优化方案
|
||||
|
||||
#### 5.1 Token 预算
|
||||
|
||||
| 场景 | 建议预算 |
|
||||
|:---|:---|
|
||||
| 单技能执行 | ≤ 4000 tokens 输出 |
|
||||
| 跨组协作 | ≤ 8000 tokens 输出 |
|
||||
| 研讨会 | ≤ 12000 tokens 输出 |
|
||||
|
||||
超预算时:自动压缩中间过程,保留结论+决策链。
|
||||
|
||||
#### 5.2 执行超时
|
||||
|
||||
| 步骤类型 | 超时 | 超时后 |
|
||||
|:---|:---|:---|
|
||||
| 单步 shell 命令 | 60s | 自动 kill + 记录 |
|
||||
| API 调用 | 15s | 重试 1 次 → 降级回复 |
|
||||
| Pipeline 单步 | 5min | 回退 + 重试 |
|
||||
| 全 Pipeline | 30min | 停止 + 通知 |
|
||||
|
||||
#### 5.3 上下文裁剪
|
||||
|
||||
- 对话超过 20 轮时,自动压缩前 10 轮为摘要
|
||||
- 保留最近 10 轮完整原文
|
||||
- 摘要格式:每轮 1 行(目标+结果)
|
||||
|
||||
#### 5.4 降级策略
|
||||
|
||||
| 场景 | 降级方式 |
|
||||
|:---|:---|
|
||||
| 技能文件不存在 | 走通用流程(已有,保持) |
|
||||
| API 全部失败 | 邮件告警 + 返回可读降级回复(已有,保持) |
|
||||
| 跨组协作某组超时 | 跳过该组意见,大总管独裁并标注"缺 XX 组输入" |
|
||||
| token 不够用 | 砍中间过程,保结论 |
|
||||
|
||||
---
|
||||
|
||||
## 六、架构演进路线(给你做决策用)
|
||||
|
||||
### Phase 1(本周可做,0 风险)
|
||||
|
||||
- [ ] 在 SKILL_REGISTRY 增加 `heat` 分级字段
|
||||
- [ ] 新建 `运营中枢/工作台/当前任务看板.md`
|
||||
- [ ] 复盘格式增加"决策链"可选字段
|
||||
- [ ] 异常处理增加超时与 token 预算条目
|
||||
|
||||
### Phase 2(1~2 周,需要验证)
|
||||
|
||||
- [ ] 实现热技能摘要表,启动链路瘦身
|
||||
- [ ] 跨组任务强制"观点-依据-置信度"三件套
|
||||
- [ ] Pipeline 增加降级策略
|
||||
- [ ] 日志入口归一化
|
||||
|
||||
### Phase 3(持续迭代)
|
||||
|
||||
- [ ] skill_heat_map.json 自动化维护
|
||||
- [ ] 研讨会机制升级(自动触发条件)
|
||||
- [ ] 上下文裁剪与压缩的自动化脚本
|
||||
- [ ] 对话质量评分(置信度统计、决策链完整率)
|
||||
|
||||
---
|
||||
|
||||
## 七、对照总结
|
||||
|
||||
| Yinova 群主建议 | 卡若AI 对应优化 | 优先级 |
|
||||
|:---|:---|:---|
|
||||
| 1) 减重,按需调用 | 技能分级 + 启动瘦身 | P1 |
|
||||
| 2) 沟通收口,共享看板 | 当前任务看板 + 日志归一化 | P1 |
|
||||
| 3) 讨论轮次有规则 | 观点三件套 + 2轮收敛 + 研讨会升级 | P2 |
|
||||
| 4) 输出清晰可追溯 | 决策链 + 观点流 | P2 |
|
||||
| 5) 安全护栏 | token预算 + 超时 + 降级 + 裁剪 | P1 |
|
||||
|
||||
---
|
||||
|
||||
*本方案不改变卡若AI整体结构(红线1),所有新增均融入现有运营中枢与参考资料目录。*
|
||||
@@ -159,3 +159,4 @@
|
||||
| 2026-02-25 16:50:32 | 🔄 卡若AI 同步 2026-02-25 16:50 | 更新:运营中枢、运营中枢参考资料、运营中枢工作台 | 排除 >20MB: 13 个 |
|
||||
| 2026-02-25 17:06:13 | 🔄 卡若AI 同步 2026-02-25 17:06 | 更新:运营中枢、运营中枢参考资料、运营中枢工作台 | 排除 >20MB: 13 个 |
|
||||
| 2026-02-25 17:09:20 | 🔄 卡若AI 同步 2026-02-25 17:09 | 更新:运营中枢工作台 | 排除 >20MB: 13 个 |
|
||||
| 2026-02-25 19:36:35 | 🔄 卡若AI 同步 2026-02-25 19:36 | 更新:总索引与入口、水桥平台对接、卡木 | 排除 >20MB: 14 个 |
|
||||
|
||||
@@ -162,3 +162,4 @@
|
||||
| 2026-02-25 16:50:32 | 成功 | 成功 | 🔄 卡若AI 同步 2026-02-25 16:50 | 更新:运营中枢、运营中枢参考资料、运营中枢工作台 | 排除 >20MB: 13 个 | [仓库](http://open.quwanzhi.com:3000/fnvtk/karuo-ai) [百科](http://open.quwanzhi.com:3000/fnvtk/karuo-ai/wiki) |
|
||||
| 2026-02-25 17:06:13 | 成功 | 成功 | 🔄 卡若AI 同步 2026-02-25 17:06 | 更新:运营中枢、运营中枢参考资料、运营中枢工作台 | 排除 >20MB: 13 个 | [仓库](http://open.quwanzhi.com:3000/fnvtk/karuo-ai) [百科](http://open.quwanzhi.com:3000/fnvtk/karuo-ai/wiki) |
|
||||
| 2026-02-25 17:09:20 | 成功 | 成功 | 🔄 卡若AI 同步 2026-02-25 17:09 | 更新:运营中枢工作台 | 排除 >20MB: 13 个 | [仓库](http://open.quwanzhi.com:3000/fnvtk/karuo-ai) [百科](http://open.quwanzhi.com:3000/fnvtk/karuo-ai/wiki) |
|
||||
| 2026-02-25 19:36:35 | 成功 | 成功 | 🔄 卡若AI 同步 2026-02-25 19:36 | 更新:总索引与入口、水桥平台对接、卡木 | 排除 >20MB: 14 个 | [仓库](http://open.quwanzhi.com:3000/fnvtk/karuo-ai) [百科](http://open.quwanzhi.com:3000/fnvtk/karuo-ai/wiki) |
|
||||
|
||||
Reference in New Issue
Block a user