v0.9.0 / v0.12.0

新功能与改进

1. 01

   这不是一个 patch note，而是一整个发布窗口

   这篇日志按上一篇已发布 release log 往后写，而不是只比较前一个 tag。覆盖窗口横跨 TUI/Portal、内核，以及影响同一条通讯面的 Telegram addon 工作。

   • 本次审计的相关仓库窗口合计 129 commits、370 个文件变更、+31,717 / -2,047 行。
   • TUI/Portal 从 v0.8.15 到 v0.9.0：58 commits，108 个文件，+6,443 / -986。
   • Kernel 从 v0.11.3 到 v0.12.0：40 commits，234 个文件，+22,416 / -676。
   • Telegram addon 从 v0.3.0 到当前 main：31 commits，28 个文件，+2,858 / -385，属于同一个 release-log 窗口。
   • GitHub 侧窗口包含 109 个更新过的 PR（81 merged，20 closed unmerged）和 48 个 issue（41 closed）。
   • 贡献者不只按 commit 算：merged PR、closed unmerged PR、closed issue 的作者/报告者/协作者/审阅者都纳入；未采纳但被关闭的 issue/PR 也算进贡献窗口。

   为什么重要：规模本身很重要，因为 release blog 是项目的公开记忆。窗口算窄了，贡献者会消失，使用者也看不到这轮工作的真实形状。

2. 02

   TUI 从 transcript 变成长期运行的 cockpit

   最外显的主题是负载下的可读性。长时间 agent 运行现在有分层回放路径、更安静的默认界面，以及更多把 runtime state 直接展示出来的入口，而不是把它藏在原始日志里。

   • 文本输出和 Ctrl+O 回放按 API call 分段，多次模型调用读起来是步骤，而不是一整团 transcript。
   • tool-call display controls、tool-result payload 渲染、tool-result 摘要、两级 Ctrl+O 详情，以及 100-rune tool-call 摘要封顶，让回放可用而不是淹没人。
   • TUI daemon browser、daemon pane 独立滚动、kanban daemon 计数、daemon detail layout 修复，让后台工作真正可见。
   • Kanban 增加 context stats 和 Ctrl+D 详情提示；list view 更接近一个去中心化 contact book。
   • root-owned layout budget、自适应 mail input 高度、全局 status bar 设计，让高密度会话下的 shell 更稳定。
   • TUI /clear 走内核 context clear，减少界面操作与 runtime 实际行为之间的错位。

   为什么重要：agent 长时间工作时，UI 不能只是文本倾倒。它要保护人的注意力：先摘要，需要时展开细节，并把 runtime state 放到操作者能看到的位置。

3. 03

   setup、preset、manifest 与首次安装路径更安全

   这一组改动修的是“人选择的配置”和“runtime 实际加载的配置”之间的缝。这里也补上没有单独发 release log 的 v0.8.16 preset 安全 patch。

   • 切换 preset model 不再丢掉 skills.paths 或其他非模型 capability overrides；缺少 skills.paths 的旧 preset 会迁移补齐。
   • /setup 不再把 synthetic keep_current.json placeholder 写进真实 preset default/allowed policy。
   • TUI 可以读取内核发布的 resolved manifest artifacts，因此界面能看 effective runtime state，而不是只看 raw init.json。
   • 默认 agent max_turns 提高；list/max-turns 相关界面更准确地描述真实运行限制。
   • Tutorial 语言默认值、adaptive welcome 的 IM 建议、首次安装 troubleshooting、README 顶部指引、install.sh source helper 都做了修复。
   • runtime checkout refresh 与 stale worktree cleanup 写进开发/发布流程，避免本地状态静默污染后续工作。

   为什么重要：配置漂移最容易损害对 agent 系统的信任。这轮发布花了不少工作，让 effective state 更可检查，也更安全地被修改。

4. 04

   内核工具执行变得可治理、可观察

   内核 v0.12.0 把工具执行重塑成结构化 runtime surface：移除脆弱的嵌套调用路径，加入 tracing 与 guard layer，并把更丰富的 recovery 信息返回给模型。

   • 嵌套 secondary tool-call channel 在过渡性 read-only 限制后被移除；stale secondary args 不再是隐藏执行路径。
   • tool-call lifecycle tracing 与 api_call_id 字段把 LLM/tool events 分组，和 TUI 回放改动对齐。
   • ToolCallGuard 在 dispatch 前引入 normalized proposal review，给出结构化 pass/warn/deny 决策。
   • 重复工具错误 pairing、tool-loop non-dispatch recovery、正式 recovery metadata、active-turn progress meter、repeated-call advisory，让恢复不再那么破坏性。
   • notification sync 改成 tool-only；MCP previews 去重；goal/system notifications 有保护和 atomic dismiss。
   • OpenAI Responses compact-threshold、context-window overflow recovery、严格 avatar schema 兼容、prompt_cache_key 支持，让 provider integration 更安全。

   为什么重要：未来的副作用策略、预算控制、模型自恢复，都需要可靠的执行账本。这轮发布把账本放进内核，而不是要求操作者从日志里猜。

5. 05

   daemon、avatar、心流/idle care 与长 subprocess 被当作运维对象

   很多改动不是为了“第一次能跑”，而是为了网络运行久了仍然健康：daemon records、dead parent、长 CLI subprocess、idle timing 都被当成显式运维面。

   • dead-parent daemon records 会在 startup 时清理；daemon max_turns 提高到 1000，支持更大的隔离任务。
   • experimental interactive Claude backend 落地，用于 daemon work，同时保留 managed-workspace 边界。
   • async bash 指南明确要求 agent/coding CLI 走异步，不能阻塞 active turn。
   • idle-care / watchdog-before-idle 写入文档：长 subprocess/daemon work pending 前休息要设置自唤醒，醒来检查日志、进程、输出、worktree 与 provider prompt。
   • molt-history 与 session-journal knowledge entries 被文档化，凝蜕后的恢复有持久轨迹。
   • avatar schema strictness 与 provider relay compatibility 被收紧，适应更严格的 API relay。

   为什么重要：LingTai 网络不是一次 request/response，而是持续运行的 runtime。这些改动减少了“跑久了才暴露”的故障。

6. 06

   知识、技能、教程与研究流程更可教学

   这轮窗口也扩展了方法论层：不少 issue 和 PR 把一次性的经验沉淀成技能、文档和可复用 guardrail，给未来的 agent 与人类操作者使用。

   • skill-backed 多语言 /help、markdown viewer routing 修复、notification command、goal request command、社区 slash-command 文档，让 TUI 更容易教学。
   • optional skill repository remote、nested knowledge catalog 隐藏规则、preset-health、textbook distillation、ResearchClawBench 文档，改善可复用知识面。
   • academic-research 增加 Zotero institutional full-text handoff 与学术写作前的 evidence-verification gate。
   • Graphify repo-map 文档、cyclic manifold architecture 文档、beginner/user-manual 相关 issue，让项目概念模型更清晰。
   • 教程补充 LICC chat command flow；README/install 指引降低第一次接触 LingTai 的脆弱性。
   • browser-based CLI、登录技能、飞书/微信 onboarding、rewind/snapshot inspector、yolo/permission control 等社区请求即使没有在本轮完整采纳，也作为公开贡献记录被保留。

   为什么重要：功能只有被后来者学得会，价值才稳定。这轮发布把更多 LingTai 的运行文化变成了可持久教学材料。

7. 07

   MCP、聊天与邮件集成更可靠

   通信是 agent 网络的生命线。这轮窗口把 Cloud Mail 加入 curated addon 集合，强化 kernel LICC 路径，并修复真实 transport failure 后的 Telegram polling recovery。

   • Kernel v0.12.0 内嵌 curated MCP servers，并新增 Cloud Mail MCP addon，面向 self-hosted maillab/cloud-mail REST 部署。
   • Cloud Mail 覆盖 check/search/read/send/accounts/add_user 与 LICC inbox polling；add_user payload shape 在 merge 前被修正。
   • 内核暴露 LICC client interface，Telegram addon 现在优先使用该 client path。
   • Telegram polling 在 httpx/proxy disconnect 后会重建 stale client，修复窗口里报告的 MCP _poll_loop failure。
   • notification preview dedupe 与 tool-only notification sync 减少重复聊天回复和像 diary 的 synthesized 文本泄漏。
   • adaptive welcome 在适合时会推荐 IM 通道，帮助人类操作者选对入口。

   为什么重要：再聪明的 agent，如果漏消息或重复回复，人也很难信任。这轮集成工作直接服务于这种信任。

8. 08

   发布卫生与打包验证也是交付的一部分

   版本已先于最终 blog 发布，这也是正确顺序：release 不应该被 prose 卡住。blog 随后记录验证和流程修正，让下一次发布更容易。

   • TUI/Portal v0.9.0 已打 tag 并发布 GitHub release；tag workflow 把 Homebrew 更新到 v0.9.0，source SHA 为 f811ea3ccf341dd073b8e9728cfa9125bfe578251cc281fac7c90a5837d4a036。
   • Kernel v0.12.0 已打 tag 并发布 GitHub release；lingtai==0.12.0 已 build、twine check、上传 PyPI，并验证为 latest。
   • TUI gates 通过：whitespace normalization 后 diff check、TUI Go tests、portal web build、portal Go tests、TUI build、portal build。
   • Kernel gates 通过：compileall、555 个 focused pytest、sdist 与 macOS arm64 wheel 构建、twine check。
   • release-log 流程会固化回 release workflow，以后 release blog 默认从 commits、LOC、merged PR、closed unmerged PR、closed issue 开始，而不是只写一个狭义 patch-note 摘要。

   为什么重要：tag 存在不代表 release 记忆完整；它还需要一份公开记录，写清楚工作、贡献者、验证，以及下次应该继承的流程。