kata - 给人和 AI 代理共用的本地 issue 账本

AI 编码代理越来越会写代码，但它们仍然很容易丢掉“正在做什么”。一次长任务里，计划可能散在聊天记录、临时 markdown、GitHub Issues、TODO 注释和终端输出之间。上下文一压缩，或者换一个 agent 接手，很多细节就变成需要重新追问的背景噪声。

今天推荐的 kenn-io/kata 想把这层状态单独做出来。它是一个 Go 写的本地优先 issue tracker，给 AI 代理提供稳定 CLI 和 JSON 输出，给人类提供 TUI 浏览、分派、编辑和监督界面。GitHub 当前页面显示项目约有 211 stars、12 forks，主要语言是 Go，许可为 MIT；仓库当前没有发布 release。

项目概览

属性	详情
仓库	kenn-io/kata
Stars	约 211
Forks	12
主要语言	Go
许可	MIT
创建时间	2026 年 4 月 30 日
状态	early public preview
Release	暂无 GitHub Releases

它不是项目管理系统，而是任务状态层

kata 的 README 把定位说得很窄：它不是完整项目管理套件，也不是 git workflow engine，更不是 agent worker pool。它更像一个耐用的任务账本，让人和 agent 都能理解“有哪些事、谁在处理、进度怎样、哪些任务互相阻塞”。

这个边界很重要。很多团队已经有 GitHub Issues、Linear、Jira 或 markdown 计划文档。kata 不是要直接替代它们，而是解决本地工作会话里的一个小问题：agent 需要一个结构化、可查询、可更新的地方记录任务、决策、链接、评论和状态变化。

相比“让 agent 在聊天里记住计划”，这种方式更可恢复。agent 可以先搜索已有 issue，避免重复创建；创建时可以带 idempotency key；读写可以使用 JSON；关闭任务时需要写清楚完成依据。对长时间、多轮、多 agent 的本地开发来说，这些约束比自由文本更稳。

架构：本地 daemon 加 SQLite

kata 的架构选择很明确：任务数据不直接放进仓库历史，而是存在 KATA_HOME 下的本地 SQLite 数据库里，由一个长运行 daemon 提供 API。仓库里只需要一个小的、无 secret 的 .kata.toml，把当前 workspace 绑定到某个 kata project。

这带来几个效果。

第一，代码仓库保持干净。issue 历史不会和代码 commit 混在一起，也不会在每个分支里出现不同版本的任务数据库。

第二，一个本地 kata project 可以被多个 checkout 或 worktree 共享。只要 .kata.toml 指向同一个 project，它们就会看到同一个 issue ledger。

第三，非 git workspace 也能工作。kata 可以从 git remote 推断项目名，但它的核心状态不依赖 Git 对象或远端同步。

代价也很清楚：当前默认形态是本地优先，不会天然跟着 git push 分享到团队。README 提到未来会有 authenticated shared server mode，但现在不要把本地 daemon 直接暴露到公网或不可信网络。

CLI 给 agent，TUI 给人

kata 的两个入口分别服务两类使用者。

给 agent 的入口是 CLI。常用命令包括：

kata init
kata create "fix login race" --body "Safari can double-submit the callback."
kata list
kata show abc4
kata comment abc4 --body "Reproduced on macOS."
kata close abc4 --done --message "Fixed; verified tests pass." --commit <sha>

README 特别强调 agent 工作流：先搜索再创建，尽量更新已有 issue，读写时优先用 --json，不要隐式创建 project，只有真正完成时才关闭任务。这些规则听起来朴素，但正是 agent 容易犯错的地方。

给人的入口是 kata tui。它让人可以浏览、整理、编辑和监督 agent 写下的工作，而不用直接读 JSON。对我来说，这个组合比“只有 agent API”更现实：人仍然需要一个低摩擦界面来检查任务是否重复、关闭是否草率、关系是否合理。

issue 关系和关闭约束

kata 支持 parent、blocks、blocked-by、related 等关系。它们可以在 create 或 edit 时添加：

kata create "add auth callback" --parent abc4 --blocks d4ex
kata edit abc4 --related f9aa

这种关系模型比简单 TODO 列表有用，尤其适合 agent 拆任务。一个大任务可以拆出子项，阻塞关系可以告诉 agent 先做什么，related 则保留上下文但不表示执行顺序。

更值得注意的是关闭约束。README 里写到，daemon 会拒绝一些结构上危险的关闭模式，例如父 issue 仍有未关闭子项时关闭父项，或短时间内批量关闭多个同级任务。关闭时还要求 --message、--commit、--test、--reviewed、--evidence 等证据字段来说明“完成”是什么意思。

这不是形式主义。agent 最容易把“我改了代码”误判成“任务完成”。kata 把关闭动作设计得更明确，能减少这种草率收尾。

事件流、digest 和备份

kata 的 issue 变化会进入 durable events。CLI 可以读取事件，也可以 tail 实时事件：

kata events --after 0 --limit 100 --json
kata events --tail

这给长跑 agent 留了一个恢复点。下一轮会话可以从事件游标继续，而不是只靠聊天上下文猜测发生过什么。kata digest 还可以按时间窗口汇总活动，查看某个 agent 或人做了哪些创建、评论、关闭和标签变更。

备份方面，kata export 会导出 JSONL，kata import 可以从 JSONL 重建数据库。JSONL 可读、可 diff、可放进私有备份仓库。注意当前 import 是重建新数据库，不是把单个项目增量合并进已有数据库；这一点适合灾备和迁移，但不适合当作多人同步机制。

和 Beads、git-bug 的差异

README 里直接比较了 kata、Beads 和 git-bug，这部分很值得读。

Beads 更像一个分布式图 issue tracker，默认在项目里创建 .beads/ Dolt 数据库，强调分支、合并、push/pull、server mode 和 agent workflow。git-bug 则更 git-native，把 issue、评论和身份存成 Git 对象，通过普通 Git remote 同步。

kata 选了另一端：状态存在用户本地服务里，仓库只保存 .kata.toml 绑定。它牺牲了“跟代码一起天然分发”的能力，换来更小的复杂度和更干净的仓库 footprint。

如果你想要任务状态随仓库流动，git-bug 或 Beads 可能更合适。如果你想要一个本地 agent 任务 ledger，不希望任务数据库进入代码历史，kata 的设计就更贴近这个需求。

安装和当前边界

kata 目前是单个 Go binary，README 写明支持 macOS、Linux 和 Windows，但还没有预构建 release binaries。当前安装方式主要是从源码安装：

go install github.com/wesm/kata/cmd/kata@latest

也可以 clone 后构建，例如 Windows 下：

go build -o kata.exe ./cmd/kata

这里有几个现实边界需要提前知道。

• 项目仍是 early public preview，命令契约和 UI 细节可能变化。
• 当前没有 GitHub Releases，团队统一安装版本时需要自己固定 commit 或 module 版本。
• 默认本地 daemon 没有认证，不应该暴露给不可信网络。
• 共享团队模式还在未来规划里，现在更适合作为个人或同机 agent 工作流。
• 任务状态不在 Git 里，换机器前要记得 kata export 备份。

这些限制不影响试用，但决定了它更适合谨慎引入，而不是立刻当成团队唯一 issue 系统。

适合谁试

kata 适合几类开发者：

• 经常让 Claude Code、Codex、Gemini CLI、OpenCode 等工具连续处理任务的人；
• 想给 agent 一个结构化本地任务层，而不是只靠 markdown plan 的人；
• 使用多个 worktree 或多个 checkout，并希望共享本地任务状态的人；
• 需要人类通过 TUI 检查 agent 任务、评论和关闭依据的人；
• 对 GitHub Issues 或 Linear 感到太重，但普通 TODO 又太轻的个人项目维护者。

如果你的项目已经有成熟 issue 系统，而且 agent 只是偶尔帮你改一小段代码，kata 可能显得多余。但如果你每天都在和多个 agent session 协作，本地任务 ledger 会变成很实用的基础设施。

总结

kenn-io/kata 抓住了 AI 编码工作流里一个具体问题：代码可以由 agent 写，但任务状态不能只存在聊天里。它用本地 daemon、SQLite、CLI、TUI、事件流和 JSONL 备份，给人和 agent 之间加了一层可审计的任务账本。

我最看重的是它的克制。kata 没有试图把 issue tracking、项目管理、agent 调度和 Git 同步全部塞进一个系统，而是先把“本地任务状态可读、可写、可恢复”这件事做好。对于正在认真整理 AI agent 工作流的开发者，它值得关注。

项目地址：https://github.com/kenn-io/kata