debroid

一句话定位

给 AI 编程 agent 用的无头安卓调试器：agent 在终端里下命令， 通过 JDWP（Java 调试协议）对运行中的安卓应用设断点、抓异常、单步执行、 检查/修改变量、监听字段，全程无 GUI、输出严格 JSON。

做这个东西的人

Shreyas Patil（GitHub PatilShreyas），资深的 Android/Kotlin 开发者，Kotlin 社区知名， 日常写大量 Android 基础设施类开源项目。Apache-2.0，Kotlin/JVM + JDI 实现，配 GitHub Actions CI。

判断：这类工具只有真懂 JVM 调试协议的人写得出来——它直接把 Android Studio 里 人类调试用的那条 JDWP 通道暴露成机器可读的 CLI，而不是自己去搞截图识别或插桩。 这是"吃老本"的正确姿势：用领域里最成熟的那条协议，而不是发明新轮子。

它到底能做哪几件事

• 断点 → 任意类设行断点，类还没加载就自动延迟生效
• 异常陷阱 → 全局捕获已捕获/未捕获异常（默认只抓未捕获）
• 监视点 → 实时监控字段的访问和修改
• 深度检查 → 递归检查深层对象内存、局部变量、调用帧，带循环保护
• 实时修改 → 暂停的线程上 set-var 动态改内存、eval 求值 Java 表达式
• 单步执行 → Step Over / Into / Out / Resume
• 协程感知 → 能从 Kotlin Continuation 帧里抽出局部变量（协程调试是痛点，处理得很细）
• 对 6 个 agent harness 开箱 → Claude Code、Codex、Grok Build、OpenCode、Cursor、Antigravity 各有一键装技能的命令

架构上最值得注意的一点：CLI 无状态、daemon 常驻——agent 每次调用之间， 调试连接和断点状态由后台 daemon 保持，不会因为命令是一次性的而丢状态。

它明确不做：不做 GUI、不做插桩埋点、不做测试报告。且安全说明写着 daemon 无认证监听 localhost、暴露实时 JVM 操作能力——只能跑在完全可信的机器上。

它在替代什么旧行为

以前 AI agent 调安卓 bug 基本靠"盲人摸象"：写代码没问题，但运行时调试它做不到—— 它无法像人那样在 Android Studio 里点开 UI 设断点、看内存、暂停执行。 所以 agent 调 bug 只能看 logcat 猜，猜错就改一行跑一次，来回烧钱。

Debroid 替代的是"人坐在 Android Studio 里做的运行时调试"这个动作： 把 GUI 里的操作全部翻译成确定性的 JSON 命令，让 agent 自己 "假设 bug → 启动应用 → 精确停在出错行 → 读设备实时状态 → 评估修复"。

商业模式

无。 Apache-2.0 开源，免费，无托管服务，无定价。作者推测另有本职工作。

判断：这是典型的"个人开发者工具开源引流"形态，短期没有商业打算。 但它验证了一个品类——"让 agent 操作真实设备/真实运行时"——这个品类将来 大概率以"agent 原生工作流（harness/IDE/云调试服务）"的形式商业化，不在这条 CLI 上。

硬数字

• 162 star / 7 fork（2026-08-12，来自 pool 采集）
• 2026-08-02 创建，9 天内 90 个提交到 v0.1.0——早期开发密度很高
• Apache-2.0，Kotlin/JVM，约 22 个命令
• 用户、企业采用、融资：均未披露

四维评估

判断

执行质量在同期小项目里是顶尖的，但品类的商业化时机还早。

它最聪明的选择是复用 JDWP 而不是自己发明。调试协议是 JVM 世界二十年沉淀的 确定性接口，直接暴露成 JSON CLI，等于把"人用 IDE 调过的所有能力"一键交给 agent。 这个"包装成熟协议"的思路，比做截图识别、做插桩方案都更轻、更可靠、更便宜。

架构上"常驻 daemon + 无状态 CLI"也值得学：agent 工具最常见的问题是一次调用 就是一次新进程，状态全丢；daemon 常驻让调试会话跨调用存活，这是所有 agent 工具 界面层都该抄的结构。

但两个现实：一是平台单一（只有安卓），iOS 调试是另一个协议栈，短期不会自动覆盖； 二是"让 agent 调试移动应用"本身还是个超前需求——多数团队连"让 agent 写移动端代码" 都还没跑通。工具很好，需求在等它的队伍。

下一步看什么

① 三个月后 stars 是否破 1000——周初的热度有没有变成持续采用 ② 是否有人把 debroid 接进真实 CI/模拟器流程并公开（博客、issue、demo）——有没有真用 ③ 是否扩展 iOS/web 调试或出托管 daemon——单平台是硬上限，突破点在这

可借鉴的做法

产品逻辑：给 agent"手"时，优先找领域里最成熟的确定性协议（调试协议、脚本协议、CLI）， 包装成 JSON 接口，而不是自建插桩或视觉方案——复用协议省十年试错。

架构："常驻 daemon 持状态 + 无状态 CLI"是 agent 工具的标准结构， 让每次 agent 调用都能接上上次的上下文，是决定工具能不能被 agent 长期用的分水岭。

分发：把 SKILL.md 内嵌进二进制，一条命令装进 6 种 agent harness—— "agent 怎么学会用你的工具"是分发问题，不是文档问题，这个解法直接可抄。

结论

有待观察（执行值得关注）。 作者对、方案对、完成度高，但 162 星、单平台、 无商业化、需求早于市场，四条都指向"再等等"。把它当"让 agent 操作真实运行时" 这个品类的一个标杆样本记下来，三个月后看上面三条。