很多团队的问题不是 Jira 里没有数据，而是数据被关在一组网络 API、分页搜索和界面筛选器里。你想问一个很直接的问题：哪个 epic 卡住最多、最近哪些 issue 反复 reopen、某个决定到底写在 comment 还是 wiki 里。Jira 和 Confluence 都能存这些信息，但临场要把它们串起来，经常会变成一轮又一轮网页点击、JQL 妥协和 REST API 脚本。

今天看的是 midagedev/gadak。它的思路很直接：把 Jira 和 Confluence 同步成一份本地 SQLite 文件，issue、comment、history、wiki page 一起进索引。然后你可以用桌面 app、浏览器 UI、CLI、SQL，甚至 MCP/agent surface 去读同一份镜像。README 里最有代表性的例子是：JQL 没有 GROUP BY，但一旦数据在 SQLite 里，“哪个 epic 未解决 issue 最多”就是一条普通 SQL。

按 GitHub repository API、README、LICENSE、Languages API、Commits API 和 Releases API 在 2026-08-24 21:07 Asia/Shanghai 能核验的公开信息，midagedev/gadak 当前有 24 stars、2 forks。仓库主语言是 Go，同时包含 TypeScript、Svelte、Shell 等前端和配套代码。许可证是 Apache-2.0。仓库创建于 2026-08-04 12:52:06 UTC，最近公开 push 是 2026-08-24 12:56:43 UTC，默认分支是 main。最新 GitHub Release 是 v0.17.1，发布于 2026-08-23 23:46:18 UTC，提供 macOS、Linux、Windows 的二进制包和校验文件。

项目概览

属性详情
仓库midagedev/gadak
定位Jira / Confluence 的本地 SQLite 镜像、搜索和 agent 查询层
Stars24
Forks2
主要语言Go
许可证Apache-2.0
创建时间2026-08-04 12:52:06 UTC
最新 push2026-08-24 12:56:43 UTC
默认分支main
最新 Releasev0.17.1，2026-08-23 23:46:18 UTC
安装形态Homebrew、release archive、install script、Docker / source build
关键词Atlassian、Jira、Confluence、SQLite、local-first、CLI、MCP、full-text search

把协作系统变成可以查询的文件

gadak 的核心不是再做一个 Jira 客户端，而是把工作系统里的记录变成一份你能直接查询的本地文件。Connected workspace 会连到 Atlassian Cloud，同步 Jira issue、comment、changelog、Confluence page 等数据；standalone workspace 则可以不接 Atlassian，当成一个本地 issue origin 使用。README 也强调，mirror 是 cache，Jira 仍然是 source of truth；项目停用时删掉本地目录，不会丢掉远端 Jira 数据。

这个边界很重要。很多“替代 Jira”的工具会要求团队迁移工作流，现实里阻力很大。gadak 选择的是旁路：既不要求团队放弃 Jira，也不把所有功能都塞进一个新 SaaS。它把现有系统镜像到本地，然后围绕这份镜像提供更低延迟、更容易组合的查询入口。

对程序员来说，最自然的入口是 CLI 和 SQL。README 展示了 gadak sql，也有 gadak issue、gadak search、gadak serve 等命令。问题不再是“Jira UI 有没有这个筛选器”，而是“SQLite 里有没有这些列”。这让一次临时排查变得更像查日志或查业务库：写查询、验证结果、保存脚本，而不是手动在多个界面里拼线索。

为什么这适合 agent

gadak 把 MCP 和 agent surface 放进定位里，不是为了赶概念，而是因为 agent 最怕那种跨系统、跨页面、需要反复分页的上下文。一个 coding agent 被问到“这个 bug 之前怎么讨论过”，如果只能查网页，它会遇到两个问题：读取成本高，且上下文容易碎。把 issue、comment、history、wiki page 做成本地索引后，agent 可以先用 SQL 或 search 缩小范围，再打开具体记录。

这和普通 RAG 知识库也不一样。Jira/Confluence 数据有强结构：状态、assignee、priority、epic、label、history、comment、page。只做向量搜索会丢掉很多可计算的信息。SQLite 镜像的好处是，全文搜索和结构化查询可以并排使用。你可以先找包含某个错误码的 comment，再按 project、status 或 epic 聚合，也可以让 agent 先查历史变更，再回到当前 issue。

README 还提到，读取 mirror 是一个二进制调用，打开具体项可以用 gadak://view?issue=... 这样的链接。这说明它不只想服务自己的 UI，也想让 launcher、脚本、agent host 接上去。一个本地工具如果能同时提供 CLI、deep link、MCP 和 SQL，组合空间会比单一桌面 app 大很多。

实际能改善哪些场景

第一类场景是 triage。项目经理或工程师想看“哪些 issue 其实长期卡在同一状态”，Jira UI 可以查一部分，但涉及历史聚合时就很笨。gadak 同步 changelog 后，可以在本地按状态变化时间做查询。它不一定替代正式报表，但适合工程师临时回答那些报表还没覆盖的问题。

第二类是跨 Jira 和 Confluence 的检索。很多决策写在 wiki，执行状态在 issue，后续争论又在 comment。gadak 把页面、标题、正文和评论放进同一套搜索体验里，至少能减少“我记得见过这句话，但不记得在哪个系统”的摩擦。

第三类是本地自动化。比如每周生成一份风险清单、找出无人负责但优先级高的 issue、把某个 epic 的未解决项发给 agent 生成实施建议。直接打 Atlassian API 也能做，但要处理认证、分页、字段映射和速度。gadak 已经把这些变成一份持续刷新的本地数据库，脚本只需要面对 SQLite。

第四类是离线或低延迟搜索。README 里列了 benchmark，强调本地查询相对 REST API 的速度优势，也承认首次同步和 watch tick 有成本。这个说法比较可信，因为它没有把同步成本藏起来。对每天都在查同一批工作项的人来说，先付一次同步成本，换来本地搜索和聚合，逻辑上成立。

设计上值得注意的地方

最值得注意的是它没有把 mirror 当成唯一真相。Connected 模式下写操作会穿透到 origin，然后刷新 mirror；standalone 模式下本地 origin 文件才是 durable state。这个设计减少了“本地缓存和远端系统谁说了算”的混乱，也让试用成本变低。

其次是安装路径比较实在。macOS 可以用 Homebrew cask 装桌面 app，也可以只装 CLI；Windows 和 Linux 有 release archive；README 还给了 install script、Docker 和源码构建方向。一个 24 stars 的项目能把多平台二进制、checksums 和 v0.17.1 release 做出来，这比只放一段概念 README 更值得观察。

第三是它把限制写得比较清楚。README 的功能表明确列出 board UI、dashboard、Jira notifications 等不在范围内，也说明 JQL 只映射 documented subset，无法表达的 clause 会拒绝而不是静默丢掉。对这种镜像工具来说，诚实拒绝比半对半错更重要。

可以怎么试

如果你已经有 Atlassian Cloud，可以先拿一个非关键站点或小项目试。README 给出的 CLI 路径是：安装后运行 gadak init && gadak sync && gadak serve，然后打开 gadak serve 打印出的本地地址。第一次不要急着让它写回 Jira，先验证同步出来的字段、搜索质量和 SQL schema 是否符合你的团队数据。

如果只是想看交互方式，可以先试 README 里的 demo 或 standalone workspace。Standalone 模式不需要 Atlassian 账号，可以用 gadak init --standalone 创建本地工作区，再用 CLI 创建 issue。它不能证明真实 Jira 数据的同步质量，但能快速感受 Web UI、CLI 和本地文件模型。

更适合程序员的测试，是拿几个真实问题写 SQL：某个 epic 的未解决项、最近一周 reopen 的 issue、某个关键词出现在 comment 还是 wiki page、某个 assignee 的 blocker 分布。能不能自然回答这些问题，比 UI 是否漂亮更能说明工具是否值得留在工作流里。

Caveats

第一，项目非常年轻。仓库创建于 2026-08-04，当前只有 24 stars。虽然 release 和 README 都相当完整，但它仍然处在 0.x 阶段，不适合直接放进关键团队流程。

第二，它主要面向 Atlassian Cloud 和本地工作区。自托管 Jira、复杂权限模型、超大实例、多站点组织、合规审计等场景都需要单独验证。README 里也明确了一些暂不覆盖的功能，例如 board UI、dashboard 和 Jira notification inbox。

第三，镜像不是实时真相。它依赖 sync 和 watch tick，README 也提到 mirror 会落后 Jira 一个同步间隔。用它做决策前，要知道你看到的是本地镜像，而不是刚刚发生的远端状态。

第四，agent 接入要谨慎。让 agent 查询 issue 和 wiki 很有用，但写回 comment、transition、assign 等操作需要权限边界和审计策略。gadak 提供 surface，不代表每个团队都应该马上开放写权限。

总结

midagedev/gadak 有意思的地方，是它把“工作流数据能不能被查询”放在 UI 之前。Jira 和 Confluence 继续做源系统，gadak 把它们镜像成本地 SQLite，再把 CLI、Web UI、SQL、MCP 和 deep link 接在同一份文件上。

它还很新，适合小范围试用，不适合盲目押注。但如果你经常在 Jira、Confluence、脚本和 agent 之间搬上下文，gadak 提供的方向很清楚：先把数据拿回本地，变成一个可以搜索、聚合、审计和复用的文件。

项目地址：https://github.com/midagedev/gadak