你在同一个代码库上运行多个 AI 编程代理。可能是 3 个，也可能是 13 个。它们各自需要管理自己的工作：创建 issue、更新状态、检查依赖、报告进度。整个代理集群每分钟产生几十次写入。
这就是 agentic engineering：人类协调 AI 代理集群来交付软件。这种工作流是全新的，但每个人做的第一件事都是去找自己已经熟悉的工具。Jira。Linear。GitHub Issues。Notion。团队在用的任何项目管理工具。
然而行不通。这种不匹配并非表面问题，而是架构层面的。
延迟扼杀吞吐量
一次 Jira API 调用需要 200-800ms。Linear API 更快但仍需 100-300ms。创建一个 issue、读取其依赖、更新其状态：三次 HTTPS 往返，经过 DNS 解析、TLS 握手和 JSON 序列化。好的情况下大约 500ms。
本地 CLI 写入 SQLite 数据库不到 50ms，通常不到 10ms。
听起来像舍入误差，但乘以操作次数就不一样了。代理处理一个任务时可能会创建 2-3 个子 issue、更新父级状态、检查阻塞项、评论进度。六次操作。每次 500ms 就是 3 秒的纯等待。每次 10ms 就是 60 毫秒。本来 30 秒能完成任务周期的代理，现在要把 10% 的时间花在等待 HTTP 上，而不是写代码。
扩展到 13 个代理，开销就是每小时数分钟。
认证基础设施是脆弱的粘合剂
每个代理都需要 API 令牌。令牌会过期。存在速率限制。一个代理连续快速发出 20 次更新就会触发 429 Too Many Requests。它不再做正事，而是陷入指数退避的重试循环。
你凭空添加了一整套与工作本身毫无关系的故障模式：令牌轮换、密钥管理、代理间的速率限制分配。这些都是为了一个本该微不足道的能力——往本地数据库写一条记录——而产生的运维开销。
当 issue 追踪器是磁盘上的文件时，没有需要认证的对象。代理能读文件系统，就能读写 issue。少一个会出故障的环节。
数据模型假设用户是人类
打开 Jira。你看到冲刺、故事点、带头像和邮箱的负责人，以及包含"审核中""准备梳理"等状态的工作流。整个数据模型是为做站会、冲刺规划和回顾的人类团队设计的。
代理不做站会。不用故事点估算。不需要有七个状态和四个审批关卡的工作流。
代理需要的是依赖图。这个任务被那个任务阻塞。这个 epic 有 12 个子项，其中 7 个已完成。这个代理 45 秒前认领了这个 issue，至今没有反馈。根本的数据结构是带阻塞关系的任务树，不是在列之间移动的卡片看板。
SaaS 工具加装了"自动化"功能，但底层核心模型仍然是为人类设计的 Kanban 看板。你可以写 Jira 插件让代理创建 issue。但你改变不了 Jira 把你的代理当成冲刺团队成员这个事实。
云端依赖是单点故障
你的代理在本地运行。读本地文件、写本地代码、提交到本地 git 仓库。离线能跑，在飞机上能跑，在 2000ms 延迟的网络上也能跑。无所谓。
但如果 issue 追踪器是 SaaS 产品，每个代理操作都需要互联网。Linear 宕机 10 分钟？整个集群停摆。家里网络抖动 30 秒？所有代理进入重试循环。本应协调工作的 issue 追踪器变成了整个系统的单点故障。
本地优先意味着 issue 追踪器和文件系统一样可靠。始终可用，始终快速，始终在你的掌控之中。
写入量差了好几个数量级
SaaS 项目管理工具面向 5-10 人的人类团队，每天几十次更新。整个团队大约 50-100 次写入。
13 个代理每隔几分钟更新一次 issue，单个项目每小时产生数百次 API 调用。这不是用量的边际增长，而是完全不同的使用模式。对人类团队来说绰绰有余的速率限制，对代理集群而言是不可逾越的硬墙。
而且问题不只是数量，还有并发。三个代理同时更新同一个 epic 的子项。状态字段的竞争条件。评论线程的乐观锁失败。这些是 SaaS 工具从未需要解决的问题，因为人类不会从三个终端同时更新同一个 issue。
协作意味着交出数据
要和队友共享 Jira 项目，双方都需要 Jira 账号。数据存在 Atlassian 的服务器上。你按席位、按月付费，换取通过 API 访问自己项目数据的特权。
想换个工具？把能导出的东西导成 CSV，剩下的只能放弃。评论、附件、自定义字段、审计历史，能不能以可用格式取出来全凭运气。SaaS 模式用数据所有权换便利。
但协作不需要中间商。如果 issue 数据库由 Dolt（数据库版 Git）之类的工具管理，你推送到远端，队友拉取。像给代码创建分支一样给 issue 数据库创建分支。合并也一样。用同样的工具和思维模型解决冲突。数据始终属于你。协作像 git 一样运行，而不像订阅服务。
真正有效的方案
抛开品牌名称，想想代理真正需要 issue 追踪器具备什么：
- 本地优先。 无网络依赖。数据库是磁盘上的文件。
- CLI 原生。 代理生活在终端里，接口也应该如此。
- Git 支撑。 可版本化、可合并、可审计。无厂商锁定。
- 零认证开销。 代理能读文件系统就能追踪 issue。
- 低延迟。 每次操作低于 50ms，不是 500ms。
- 无需中间人即可同步。 像 git 仓库一样 push 和 pull，不走 API webhooks。
这就是我每天在用的。beads 是一个专为这种工作流打造的 Git 原生 issue 追踪器。所有数据存储在本地 SQLite 数据库中，通过 Dolt 实现版本控制和同步。CLI 是主要接口。代理像运行其他命令一样创建、更新和查询 issue。
Beadbox 是我在其上构建的可视化层。它监听本地数据库的变更，实时渲染依赖树、epic 进度和代理活动。代理用 CLI，我用仪表盘。两者从同一个本地数据库读取。
老工具本身没有问题
Jira 在其擅长的领域表现出色：通过结构化工作流协调人类团队。Linear 对追求速度和精致的小团队来说很美。GitHub Issues 对开源协作毫无摩擦。
它们都不是坏工具。只是在解决不同的问题。如果你的工作流是五个人跑两周冲刺，继续用它们就好。
但如果你在同一个代码库上运行 5 个、10 个或 13 个 AI 代理进行实时协调，你已经超越了 SaaS 模式的承载范围。Agentic engineering 需要为 agentic engineering 而生的工具，不是在人类工作流上加个 API 接口。