imsg：把 macOS 的 Messages 数据库变成可脚本化的 NDJSON 流
Apple Messages.app 的 CLI，以便您的代理可以发送和接收短信/iMessage。
秒懂
- 它是什么？
- imsg 是一个 Swift 写的命令行工具，让代理和脚本直接读取、监听和发送 iMessage/SMS。它绕开私有框架，靠 SQLite 只读和 AppleScript 发送，但高级功能需要关闭 SIP。
- 适合谁用？
- 适合需要把 iMessage 接入自动化工作流的人，比如个人助理脚本、客服机器人或家庭自动化。不适合依赖发送稳定性的人，因为 AppleScript 发送无法指定发件号码，且高级功能需要关闭 SIP。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 Swift（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月14日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决什么问题，谁需要它
macOS 的 Messages 应用没有官方 CLI，也没有稳定的脚本接口。想自动化收发 iMessage，过去只能靠 AppleScript 点击 UI 或逆向私有框架。imsg 的目标是给脚本和代理一个干净的管道：读数据库、监听变化、发送消息，全部通过标准输出。它面向两类人：一是写个人自动化脚本的开发者，二是需要在 macOS 上集成消息能力的 AI 代理。它不面向普通用户，因为安装后还要折腾权限和命令行。
读、听、发：三条路径的架构差异
imsg 的核心设计是分开三条路径。读取走 SQLite 只读模式，直接打开 `~/Library/Messages/chat.db`，不碰任何私有框架。监听用 `watch` 命令，它跟踪数据库和 WAL 文件系统事件，macOS 丢事件或轮转 sidecar 文件时还有轮询兜底。发送走 Messages.app 的 AppleScript 自动化接口，不是直接写数据库。这三条路径里，读和听是安全的，发送依赖系统权限。高级功能，比如已读回执、打字指示器、贴纸和投票，则需要注入一个 helper 到 Messages.app 内部，这要求关闭 SIP，而且可能被当前 macOS 的库校验或私有 entitlement 检查拦截。
安装和第一个命令：权限是最大门槛
安装很简单，Homebrew 一条命令：`brew install steipete/tap/imsg`。要求 macOS 14 或更新。装完先别急着跑，必须给终端授予完全磁盘访问权限，在系统设置里的隐私与安全性里设置，然后重新打开终端。没有这个权限，读不了 `chat.db`。之后 `imsg chats --limit 3` 列出会话，拿到 id，再 `imsg history --chat-id 42 --limit 10` 读历史。发送和点按回复还需要在自动化里授权 Messages，通讯录权限是可选的，只影响名字解析。这里有个实际坑：你的终端模拟器本身必须继承这个权限，否则子进程还是读不到。
NDJSON 和 JSON-RPC：为机器设计的输出
`--json` 参数让每个命令输出一行一个 JSON 对象，人看的进度和警告都走 stderr，所以 stdout 可以安全地管道给其他程序。文档建议管道有限命令时用 `jq -s` 把多行合成一个数组。`imsg rpc` 启动一个长期运行的 stdio 服务，走 JSON-RPC，这是给代理和网关用的。这个设计比一次性命令更适合长时间运行的 agent，因为不用每次启动都重新读取数据库。JSON schema 覆盖了聊天、消息、附件、反应、投票、定时消息和统计，字段结构是稳定的。
发送的局限：AppleScript 的边界
`imsg send` 通过 AppleScript 让 Messages.app 发送，这是它最大的软肋。文档明确说，当多个号码共享同一个 Apple ID 时，它不能强制指定用哪个号码发出。这意味着你在多号码环境下无法精确控制发件人。另一个限制是短信：需要先在配对的 iPhone 上开启文本信息转发。这些限制不是 imsg 的 bug，而是 AppleScript 接口本身的能力边界。如果你需要精细的发送控制，比如选择发件号码或发送富媒体，普通路径做不到，得走高级 IMCore，但那就得关闭 SIP。
Linux 版：只读，别指望收发
Linux 有 x86_64 的只读构建，但它只能读取从 macOS 拷贝过来的 `chat.db`，不能连接 iMessage，也不能发送消息。这个版本的价值有限，主要是给服务器端做离线分析，比如统计消息数量或搜索历史。如果你打算在 Linux 服务器上跑一个消息代理，这个版本帮不上忙。它连不上 iMessage 网络，也没有 AppleScript 可用。所以 Linux 版更像一个数据库查看器，而不是消息客户端。
维护成本和许可证
项目用 MIT 许可证，没有 Apple 官方关联，iMessage 和 SMS 是各自所有者的商标。开发层面，包结构分三层：`IMsgCore` 是可复用的 Swift 核心，`imsg` 是 CLI，`IMsgHelper` 是可选注入的 helper。用 Swift 6 写，目标 macOS 14。维护活跃度从最近的 v0.14.2 看还行，但高级功能依赖关闭 SIP，这意味着每次 macOS 更新都可能破坏注入 helper 的兼容性。普通路径的读和发相对稳定，因为它用的是公开的数据库格式和 AppleScript 接口。升级成本主要在高级功能上，如果你只用标准路径，升级大概就是 brew upgrade 的事。
编辑结论
适合需要把 iMessage 接入自动化工作流的人，比如个人助理脚本、客服机器人或家庭自动化。不适合依赖发送稳定性的人，因为 AppleScript 发送无法指定发件号码，且高级功能需要关闭 SIP。先用 `imsg chats --limit 3` 确认 Full Disk Access 已生效，再跑 `imsg watch --chat-id <id> --json` 验证流式输出。若你能接受只读分析，Linux 版可以读拷贝过来的 chat.db，但别指望它收发消息。
社区笔记