← 发布
中文 English

id 20260730-1 · 2026-07-30 · Kernel v0.19.0 · TUI/Portal v0.12.0

Kernel v0.19.0 · TUI/Portal v0.12.0

LingTai 0.19.0 / 0.12.0：统一工具协议、可见的长任务与唯一规范生命周期

这次协同发布让 LingTai 更适合作为长期运行的系统：面向模型的工具统一到 LingTai Tool Protocol v2；Task Card 为长任务提供完整、可见的生命周期；安装、更新与移除脚本获得唯一规范源；渠道、通知、邮件与 TUI 的可靠性改进让失败更有界、更可观察。本次发布窗口包含 85 个提交、72 个已合并 PR，来自 4 位人类贡献者。

升级 / runtime

$ curl -fsSL https://lingtai.ai/install.sh | bash

Kernel v0.19.0 通过 GitHub 与 Gitee 发布 15 个 CPython wheel、1 个 sdist fallback、lingtai-kernel-release-manifest.json 与 SHA256SUMS，并将同一组冻结的 wheel/sdist 字节发布至 PyPI。TUI/Portal v0.12.0 发布 GitHub 源码 Release、更新 Homebrew 配方，并生成绑定 kernel v0.19.0 的 Windows AMD64 bundle。按照本次明确的发布范围，Windows 产物只进行了交叉构建与哈希校验，未执行。受支持的安装与升级入口为 curl -fsSL https://lingtai.ai/install.sh | bash；现有 Homebrew 用户继续受到支持。

新功能与改进

  1. 01

    运行时与各通信渠道统一为一套工具协议

    LingTai Tool Protocol v2 让面向模型的工具共享可预测的 action/input 信封，同时保留每个集成真实的所有权与副作用边界。

    • Web、email、system、daemon、Psyche、Telegram、IMAP、Feishu、WeChat、WhatsApp 与 Cloud Mail 现统一采用 ToolFamily 契约，不再各自暴露不同调用形状。
    • Web 搜索与浏览保留完整输出；各渠道适配器则保持传输 stdout 仅承载协议，并如实暴露限流与重试状态。
    • 这让模型面对的语法更小、更一致，同时不把不同渠道伪装成具有相同的运行语义。

    为什么重要：新工具与新渠道更容易学习、审计和组合；失败仍可追溯到真正拥有该行为的集成。

  2. 02

    长任务通过完整的 Task Card 生命周期变得可见

    Task Card 现拥有声明式内建生产者、明确的终止生命周期、尊重可编程意图的 Telegram 投影，以及用于查看当前产物的 TUI 界面。

    • 智能体可启动、检查、重试、停止并移除一个真实的 Task Card watch，不再把过期进度留给用户。
    • Telegram 继续拥有其传输层投影与自动组合；可编程 frame 仅控制任务状态及 active/inactive 意图。
    • TUI 新增 /taskcard，操作者无需翻查聊天记录即可打开同一份当前产物。

    为什么重要：用户可以看到长任务正在做什么、是否仍在运行，以及其进度产物何时被明确退役。

  3. 03

    安装、更新与移除现在拥有唯一的规范生命周期

    Lingtai-AI/lingtai 仓库现统一拥有 POSIX 与 PowerShell 的完整生命周期；公开网站只镜像这些精确字节，不再维护独立 installer 分叉。

    • 稳定入口 install.sh 与 install.ps1 覆盖安装和更新，并在其后提供规范的 fix、verify、dev 与移除子流程。
    • 新的 remove.sh 与 remove.ps1 只删除 receipt 明确拥有的安装状态，保留用户配置、secrets、presets、projects、auth 与共享工具，并支持第二次幂等执行。
    • Web 字节一致性检查会在任何镜像漂移时明确失败，避免文档与复制粘贴 URL 静默偏离维护中的生命周期源。

    为什么重要：用户面对的是一套有文档的生命周期与一个清晰所有权边界，而不是随时间漂移的平台脚本。

  4. 04

    邮件、通知与操作界面以更诚实的方式处理失败

    一轮广泛的可靠性改进让渠道重试、通知投递、实时日志、凭证处理与邮件会话侧栏都更有界、更可观察。

    • Telegram 限流会传播真实重试契约；WeChat 与 Cloud Mail 会重试失败的唤醒投递；Feishu 保持 MCP stdio 仅承载协议；文件系统邮件轮询被切片，不再独占整个 turn。
    • 并发 daemon 终态唤醒与合成通知调用保持 schema 合法，实时 SQLite 读取者也能看到当前数据。
    • TUI 邮件侧栏获得更清晰的焦点、折叠与鼠标行为，一致的凭证家族处理，以及避免重复扫描邮件历史的更快实时网络刷新。

    为什么重要：当真正失败的是传输、重试或实时视图时，操作者会获得更少的静默停滞与更清晰的证据。

贡献者

感谢本发布窗口中提交代码、共同完成提交、参与 PR / review / assignment、报告或推动 issue closure 的贡献者。

验证

最终 release validation 来自干净 release worktree，commit Kernel candi.

链接