v0.8.13 / v0.11.1

新功能与改进

1. 01

   Molt continuation：上下文脱落后少一点猜测

   molt 是 LingTai agent 在有限上下文中继续活下去的方式。这一版把 molt 后续接的路径收紧：molt 后的新 self 收到更明确的唤醒信号，而不是依赖从文本里猜测下一步。

   • post-molt continuation notice 现在从真实的 molt result 触发，而不是依赖猜出来的 next_action heuristic。
   • molt 后 notification 可以在上下文脱落后唤醒 successor，让它读取 summary、pad 与未完成工作，而不是静默停住。
   • defer 只发生在真正的 molt result 上，降低无关通知被延迟、重复、或挂到错误 turn 上的概率。
   • 这个改进在长开发会话里最明显：agent 可以有意识地 shed context，带着 handoff 重新打开，然后继续 release、PR 或调查线程，少一点人工重新定位。

   为什么重要：LingTai 把 conversation 视为临时层，把工作状态放进 durable 层。更可靠的 post-molt continuation 让这套记忆模型更像实际生产能力，而不只是仪式。

2. 02

   Soul flow 变得更偏探索，也更懂 voice

   这个窗口后段的两项 kernel 改动，让 idle 时的 inner voice 不再像强制 productivity checklist，而更像可配置的反思伙伴。

   • kernel PR #204 把默认 soul-flow 姿态调成更偏探索式反思，而不是狭窄地提取任务清单。
   • kernel PR #206 让 soul-flow consultation 走配置好的 voice prompt；自定义 soul voice 会影响 current-insight 与 past-self consultation。
   • 这和 molt 的记忆模型相互呼应：conversation 是临时层，但反思与 handoff 应该帮助下一轮注意到忙碌中的 self 可能漏掉的东西。

   为什么重要：LingTai 的“内在声音”应该是 agent 可以培养和调音的东西，而不是只有一种性格的硬编码旁白。

3. 03

   SQLite 轨迹索引：JSONL 仍是事实源，查询变快

   本地 agent 轨迹现在有了一个派生 SQLite sidecar：可以重建、检查、查询，但不取代 append-only JSONL 事实记录。

   • kernel PR #201 新增 logs/log.sqlite，作为 logs/events.jsonl 的 fail-open、可重建索引，并提供 lingtai-agent log rebuild|doctor|query <agent_dir>。
   • 只读 SQL 查询支持安全的 SELECT / WITH ... SELECT / EXPLAIN 路径，同时保持 JSONL 是事实源。
   • kernel PR #203 把索引扩展到 agent chat history、chat archive、daemon events 与 daemon chat history，并新增 chat_entries 表和 source provenance 字段。
   • TUI PR #221 在 migration 中加入交互式历史 backfill：先询问用户，说明大历史可能耗时，确认后显示进度条；跳过也不影响正常使用。

   为什么重要：agent 会生成大量本地历史。保持 JSONL 耐久，同时增加 SQL inspection，让调试、trajectory mining 和未来 UI 视图都少很多痛苦。

4. 04

   WhatsApp 进入一等 MCP 通道集合

   WhatsApp 现在按 LingTai 其它一等通讯通道的方式接入：curated MCP registration、runtime dependency、TUI wiring，以及 README channel 文档。

   • 新的 lingtai-whatsapp 包提供 WhatsApp Cloud API MCP server，并已打 v0.1.0 tag。
   • kernel PR #188 注册 curated whatsapp MCP，PR #189 增加 lingtai-whatsapp>=0.1.0 runtime dependency。
   • TUI PR #216 把 WhatsApp 接入 MCP setup surface，PR #220 在 README channel 列表中补上 WhatsApp。
   • 和其它 MCP 通道一样，真正激活仍取决于用户提供 provider credentials；但注册、打包、文档路径已经进入 first-party。

   为什么重要：LingTai 面向人的通道变宽了，同时不需要为每个平台发明一套单独的集成模型。

5. 05

   诊断与常驻指导继续向 kernel-owned manuals 收拢

   这个窗口继续把操作知识从分散的 UI 文案里收拢到 agent 需要时可加载的 intrinsic skills/manuals。

   • kernel PR #185 新增 intrinsic lingtai-doctor skill，并扩展只读诊断：agent health、stale paths、heartbeat/process 分歧、MCP/addon path 问题等。
   • TUI PR #213 让 /doctor 复用 kernel-owned intrinsic doctor，而不是在 TUI 里维护另一套诊断脚本路径。
   • kernel PR #187 与 TUI PR #215 把展开版 runtime guidance 路由到 system-manual，让 resident prompt 变小，但详细 procedure 仍可按需加载。
   • TUI PR #214 增加 standing guidance：重要 human-facing deliverable 在合适时优先做 standalone HTML。

   为什么重要：agent 应该随身携带可持久的操作知识，同时 always-on prompt 要足够小，把空间留给真正的工作。

6. 06

   产品叙事、license 对齐与公开文档整理

   这次发布也整理了项目对外形状：LingTai 是什么、用什么 license、以及新用户从哪里看到支持的通道。

   • TUI PR #212 扩展项目 README，PR #219 把 README 重新定位为产品入口，而不只是开发说明。
   • TUI PR #220 在 README 通讯通道列表中加入 WhatsApp，与新的 first-party MCP 路径对齐。
   • kernel PR #200 与 TUI PR #218 将仓库 license 对齐到 Apache-2.0。
   • 这个发布窗口也包含面向网站元数据的日常 star-count 维护提交。

   为什么重要：当 LingTai 越来越容易安装、也越来越容易扩展时，对外入口也需要用产品当前自己的语言解释这套系统。