Pine：给 CLI Agent 工作流用的原生 macOS 代码编辑器
AI coding agent 越来越能干以后，一个很普通的麻烦反而变明显了：人还是在编辑器里看代码，agent 却常常在 terminal 里工作。Claude Code、Codex、Gemini CLI、OpenCode 这类工具擅长跑命令、改文件、等待确认，但它们不会天然知道你正在看哪个文件、Git 状态哪里变了、LSP 诊断是否已经刷新，或者另一个项目里的 agent 是否卡在了权限提示上。
很多团队的临时解法是把 IDE、terminal multiplexer、Git UI、通知工具和聊天窗口拼在一起。这能跑，但会让人一直切窗口。更微妙的问题是，agent 的状态很难和编辑器里的真实代码状态对齐：terminal 说完成了，编辑器里可能还有 diagnostics；某个 agent 等待输入，人却在另一个 workspace 里看 diff。
今天看的是 batonogov/pine。它不是另一个套着 WebView 的 AI dashboard，而是一个 SwiftUI + AppKit 写的原生 macOS 代码编辑器。README 的核心句子很直接：agent 仍然待在 terminal，代码仍然留在视野里，Pine 把二者放到同一个工作面。项目面向 macOS 26+，强调 no Electron runtime，内置 terminal、LSP code intelligence、Git context、split panes、project-wide search、Markdown preview，以及跨项目 Agent Inbox。
按 GitHub repository API、README、LICENSE、Releases 和最近 commits 在 2026-08-13 能核验的公开信息，batonogov/pine 当前有 20 stars、0 forks。仓库主语言是 Swift，许可证是 MIT。仓库创建于 2026-03-09 16:00:01 UTC，最近公开 push 是 2026-08-13 09:39:39 UTC，默认分支是 main。最新 GitHub Release 是 v2.3.1，发布时间 2026-08-12 04:03:04 UTC，release 附带 Pine-2.3.1.dmg。最近 commit 是 a52b384，信息为 “fix: make descriptor path recovery sanitizer-safe (#1451)”。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | batonogov/pine |
| 定位 | 面向 CLI-agent workflow 的原生 macOS 代码编辑器 |
| Stars | 20 |
| Forks | 0 |
| 主要语言 | Swift |
| 许可证 | MIT |
| 创建时间 | 2026-03-09 16:00:01 UTC |
| 最新 push | 2026-08-13 09:39:39 UTC |
| 默认分支 | main |
| 最新 GitHub Release | v2.3.1，2026-08-12 04:03:04 UTC |
| 关键词 | macOS、SwiftUI、AppKit、code editor、terminal、LSP、Git、Agent Inbox |
它选择不把 agent 做进编辑器
Pine 有趣的地方，是它没有试图重新发明一个完整的 AI IDE。现在很多工具会把聊天、补全、agent、review 和项目管理都塞进一个界面。这个方向当然有价值，但对已经习惯 CLI agent 的人来说，问题不一定是“缺少一个聊天面板”。他们可能已经在 terminal 里登录好了 Claude Code 或 Codex，也有自己的 shell、环境变量、认证和工作目录习惯。
Pine 的选择是保留这个现实。Agent 仍然是 terminal 进程。编辑器提供的是围绕 terminal 的工作面：内置 VT100/xterm terminal，支持 multiple tabs、themes、TUI apps、clickable file links、OSC 8 links、send-to-terminal、pane maximize 和 global quick-terminal hotkey。也就是说，它不要求你把 agent 迁移到某个新的 hosted runtime，而是把 terminal 当作一等公民放进编辑器。
这对本地工作流很重要。很多 agent 的可靠性来自它们就在真实 shell 里运行：能用项目里的工具链，能读本地 Git 状态，能触发测试，能请求权限。Pine 更像是在这个基础上补齐人类需要的可见性，而不是替换 agent 本身。
Agent Inbox 是更具体的切入点
README 里 “New in Pine 2.0” 的重点是 Cross-project Agent Inbox。这个功能听起来像一个普通任务列表，但它针对的是 CLI agent 的一个真实痛点：session 会散在多个项目、多个 terminal tab、多个 branch 和多个 worktree 里。人离开一会儿回来，最先需要知道的不是代码如何补全，而是哪一个 agent 在等你、哪一个已经完成、哪一个应该回到原来的 live session 继续看。
Pine 把 durable tasks、exact live session routing、isolated worktrees、task recovery、evidence-based completion briefs 和 privacy-bounded notifications 放在同一组 agent-aware workflow 里。这里的关键词不是“自动写更多代码”，而是让 agent session 的生命周期可见。对多项目开发者来说，这比又一个聊天入口更实际。
这个设计也解释了为什么 Pine 会强调 useful signals without surveillance。Agent 状态提醒很容易滑向过度监控：读取所有 terminal 输出、推测每个进程、把本地工作流上传到服务端。Pine 的 README 把通知限定在 verified events 或 detected process exits 这类边界内，至少从定位上看，它想做的是本地、可解释、隐私边界更清楚的提醒。
编辑器能力没有被省掉
只做 terminal wrapper 很容易变成半成品。Pine 的另一部分价值，是它把传统编辑器功能也补得比较完整。LSP code intelligence 覆盖 diagnostics、completion、hover、go-to-definition、code actions、rename 和 Problems panel。语法高亮内置 Swift、TypeScript、Python、Go、Rust、Java、Kotlin、Ruby、C/C++ 等 grammar。还有 symbol navigation、code folding、minimap、find and replace、project-wide search、Quick Open、Markdown preview、status bar、bracket matching 和 large-file handling。
Git 集成也贴近普通开发：sidebar 里的 file status、gutter diff markers、blame view、title bar 或 Git menu 里的 branch switching。对 agent workflow 来说，Git 不是装饰功能。Agent 改完文件后，人要看的往往是哪些文件变了、变更在函数边界内还是跨模块扩散、诊断是否清空、需要切哪个 branch 或 worktree 继续。
Pine 的架构说明也比较清楚：MVVM，SwiftUI views 由 AppKit 的 NSViewRepresentable 支撑；editor core 使用原生 NSTextStorage / NSLayoutManager / NSTextContainer；syntax highlighting 在后台队列异步执行；Git operations 用 GCD 并行；project-wide search 用 Swift concurrency 和 sliding-window parallelism。它不是把网页编辑器打包成桌面壳，而是认真走 macOS native stack。
安装路径直接，但平台很窄
Pine 的安装入口是 Homebrew Cask：
brew install --cask batonogov/tap/pine-editor也可以从 GitHub Releases 下载最新 .dmg。从源码构建需要 macOS 26+ 和 Xcode 26+，依赖通过 Swift Package Manager 解析。README 还提到 Sparkle auto-updates，以及英文、德文、西班牙文、法文、日文、韩文、巴西葡萄牙文、俄文、简体中文等本地化。
这里也有最明显的 caveat：它只适合 macOS 用户，而且要求较新的系统和 Xcode。团队如果跨 Windows、Linux、远程容器或浏览器开发环境，Pine 很难成为统一入口。它更像是给某类个人开发者准备的本地工作台：主力机器是 Mac，日常离不开 CLI agent，又不想把编辑器换成一个大型 Electron IDE。
另一个 caveat 是项目还很小。20 stars、0 forks、11 个公开 issues，说明它还处在非常早期的社区阶段。最新 release 和 commit 很活跃，这很好；但如果要把它当主力编辑器，最好先拿一个非关键项目试用，观察崩溃恢复、terminal session restore、LSP 表现、大文件处理和 Git 操作是否适合自己的习惯。
适合谁试
Pine 最适合三类人。
第一类是已经把 Claude Code、Codex、Gemini CLI、OpenCode 作为日常工具的 macOS 开发者。你不想把 agent 从 terminal 里拿出来，但希望代码、terminal、Git、diagnostics 和 agent 状态在同一个原生窗口里。
第二类是同时维护多个小项目的人。多个 agent session 分散时，Cross-project Agent Inbox 和 exact live session routing 的价值会比单项目里更明显。它解决的是“我该回到哪个 session”这种低层摩擦。
第三类是偏好本地工具和原生性能的人。Pine 没有 Electron runtime，走 SwiftUI / AppKit 和系统文本组件。这不会自动保证所有体验都更好，但至少它认真押注在 macOS 桌面能力上，而不是把浏览器应用重新包装一次。
不适合的场景也很清楚。如果你的团队已经重度依赖 VS Code extension ecosystem，或者工作主要发生在 remote Linux desktop、browser IDE、container workspace 里，Pine 的 macOS-native 优势未必能抵消迁移成本。如果你只偶尔用一次 agent，也可能用现有 editor 加 terminal split 就够了。
总结
batonogov/pine 的价值不是“又一个 AI 编辑器”，而是承认 CLI agent 已经成为真实工作流的一部分，然后把编辑器围绕这个事实重新整理。Agent 继续在 terminal 里跑，代码继续在编辑器里看，LSP、Git、terminal、notifications 和 cross-project task state 负责把这两边粘起来。
它现在还很年轻，平台边界也窄。但正因为如此，它适合 Gumi 记录：小、具体、最近活跃，解决的是开发者已经在经历的 workflow friction。对 Mac 上重度使用 CLI agent 的人来说，Pine 值得放进试用列表。