fnvtk/karuo-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
karuo-ai/运营中枢/参考资料/卡若AI优化方案_借鉴Yinova拆解.md

7.4 KiB
Raw Permalink Blame History

卡若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%+，响应更快。

二、收口：统一信息看板，不要散落

当前问题

  • 任务交接靠"任务交接单"模板，但实际很少严格执行
  • 执行日志散在多个路径：水溪/执行日志/、运营中枢/工作台/、个人/1、卡若：本人/记忆.md
  • 跨组协作时，信息靠"概念传递"而非"实际文件中转"

优化方案

2.1 引入"共享看板"机制

在 运营中枢/ 下新增一个轻量看板文件：

运营中枢/工作台/当前任务看板.md

结构：

## 当前任务看板（自动维护）

| 任务ID | 描述 | 负责人 | 状态 | 上下文摘要 | 更新时间 |
|:---|:---|:---|:---|:---|:---|
| T001 | 部署卡若AI网关 | 金仓 | 执行中 | 端口18789已就绪 | 14:30 |
| T002 | 拆解Yinova项目 | 火炬+水泉 | 已完成 | 10目录已产出 | 20:30 |

规则：

  • 每个任务开始时，自动写入一行
  • 每个任务结束时，更新状态为"已完成"并附结果摘要
  • 跨组协作时，接收方先读看板确认上下文，不依赖口头交接

2.2 归一化日志入口

目前写日志的地方至少 4 个。建议收口为 2 个：

类型 路径 写入者
执行日志 运营中枢/工作台/执行日志/ 所有角色（按日期）
经验沉淀 水溪/经验库/待沉淀/ 保持不变

其他散落的日志入口（如 个人/1、卡若：本人/记忆.md 的每日沉淀、gitea_push_log 等）保留但不再作为主日志。

三、讨论要有规则：引入"收敛轮次"

当前问题

  • 思考→拆解→执行→验证 有流程，但没有"分歧怎么处理"的规则
  • 多技能匹配时"合并执行"，但合并的逻辑不透明
  • 缺少"置信度"概念，用户看不到"这个结论有多靠谱"

优化方案

3.1 跨组任务引入"观点-依据-置信度"三件套

当任务涉及 2 个以上负责人时，每个角色必须输出：

- 观点：[一句话结论]
- 依据：[数据/文件/经验]
- 置信度：[高/中/低]

3.2 默认 2 轮收敛

  • 第 1 轮：各角色独立输出观点+依据+置信度
  • 第 2 轮：大总管综合，如果置信度全高 → 直接出结论；有低/分歧 → 追加 1 轮定向补充
  • 最多 3 轮，第 3 轮强制由大总管裁决并标注"裁决依据"

3.3 研讨会机制升级

当前协同规范里有"研讨会"流程，但触发条件模糊。建议明确：

触发条件 执行方式
涉及 ≥3 个组 自动走研讨会
任一组置信度为"低" 补充轮 + 研讨会
用户主动要求 立即走研讨会

四、输出要清晰：推理链可见

当前问题

  • 复盘格式强（目标/结果/达成率），但"怎么得出结论的"看不到
  • 用户看到的是结果，看不到"为什么选了这个方案而不是那个"

优化方案

4.1 复盘增加"决策链"字段

在现有复盘格式中增加（可选，复杂任务时强制）：

### 决策链
- 方案A：[描述] → 不采纳，原因：[xxx]
- 方案B：[描述] → 采纳，原因：[xxx]
- 置信度：高

4.2 多角色任务增加"观点流"

类似 Yinova 建议的"中间栏各角色观点流"：

### 各角色观点
- 火炬：建议用 SQLite 替代 JSON，依据是并发写风险
- 金仓：建议保持 JSON，依据是部署复杂度
- 大总管裁决：采纳火炬方案，加文件锁兜底

五、安全护栏：超时、熔断、预算

当前问题

  • 异常处理有红线（不改结构、不删文件、不破系统），但偏"禁止类"
  • 缺少"主动防御类"护栏：token 预算、执行超时、上下文裁剪
  • Pipeline 失败重试 2 次后只能"通知用户"，缺自动降级

优化方案

5.1 上下文裁剪

  • 对话超过 20 轮时，自动压缩前 10 轮为摘要
  • 保留最近 10 轮完整原文
  • 摘要格式：每轮 1 行（目标+结果）

5.2 降级策略

场景 降级方式
技能文件不存在 走通用流程（已有，保持）
API 全部失败 邮件告警 + 返回可读降级回复（已有，保持）
跨组协作某组无响应 跳过该组意见，大总管独裁并标注"缺 XX 组输入"
Pipeline 某步重试失败 标记降级，非强依赖则跳过继续

六、架构演进路线（给你做决策用）

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），所有新增均融入现有运营中枢与参考资料目录。