当 Claude Code、Cursor、Cline 等 AI 编码工具清一色采用 Electron 架构时，一个完全基于原生 macOS 堆栈的项目正在重新定义「与系统深度对话」的可能性。Agent! 使用纯 Swift 6.2 与 SwiftUI 构建，放弃 Node.js 运行时，以原生二进制形态直接运行在 macOS 上。这一架构选择带来的不是简单的性能提升，而是系统级能力的质变 —— 从 Accessibility API 的精准 UI 自动化，到 XPC 架构下的特权分离，再到 ScriptingBridge 对 51 个系统事件的原生桥接，每一项都是 Electron 方案难以企及的深度。
原生架构的核心优势
Electron 本质上是一个封装了 Chromium 与 Node.js 的沙盒环境，其能力边界受限于 Web API 与 Node 原生模块的交集。当 AI 编码工具需要控制系统应用的 UI 元素、读取 iMessage 数据库、或以特权用户身份执行 shell 命令时，Electron 只能通过 AppleScript 或第三方桥接库曲线实现，而 Agent! 则直接运行在 macOS 的原生运行时中。Swift 6.2 编译器生成的机器码与系统框架无缝链接，Foundation、AppKit、SwiftUI 的每一项 API 都可以直接调用，无需考虑跨语言调用开销或运行时兼容性问题。
这种架构的直接收益体现在响应延迟上。以 Xcode 项目构建为例，Agent! 通过内置的 xcode 工具直接调用 xcodebuild，构建过程中的错误与警告实时流回应用界面，错误行可点击跳转。而在 Electron 方案中，这一流程需要通过子进程管道传递，缓冲区管理增加了不可忽略的延迟。类似地，当用户请求「打开 Safari 并搜索航班价格」时，Agent! 调用内置的 Safari 自动化模块，通过 JavaScript 与 AppleScript 的混合执行直接操作 DOM，这个路径在原生架构下的执行链远短于 Electron 的 IPC 桥接。
Accessibility API 的深度 automation
Agent! 的桌面自动化能力建立在 AXorcist 之上，这是一个基于 macOS Accessibility API 的元素发现与操作框架。与传统的坐标点点击或图像识别方案不同，AXorcist 通过角色的属性匹配（role、title、appBundleId）精确定位 UI 元素 —— 点击「发送」按钮时不再依赖相对坐标，而是直接定位到系统中那个真实的 NSButton 对象。这意味着无论窗口位置如何移动、UI 布局如何调整，自动化脚本都能可靠执行。
更关键的是，原生架构让 Agent! 能够在系统权限层面与 Accessibility 框架深度集成。当 AI 判断需要「点击 Finder 侧边栏中的 Documents」时，完整的元素树查询、属性读取、动作派发都在同一个进程内完成，无需像 Electron 方案那样在主进程与渲染进程之间反复序列化 UI 描述对象。AXorcist 支持 25 个顶层动作与 30 多个 AX 子类型，涵盖点击、输入、滚动、拖拽、菜单操作等常见场景，而这些能力在 Web 端很难可靠复现。
权限模型与安全防御
原生架构还带来了更精细的权限控制。Agent! 采用双层 XPC 服务模型：Launch Agent 以当前用户身份运行，负责日常的 shell 执行与文件操作；Launch Daemon 以 root 身份运行，仅在需要系统级特权时通过 XPC 调用激活。这种分离遵循了 macOS 的最小权限原则 ——AI 不会因为需要执行一个 sudo 命令就获得完整的 root 会话，而是通过一个经用户一次性批准后的特权通道完成特定操作。
安全层面也体现了原生架构的深度。Shell Safety Service 在进程构造之前就拦截灾难性命令（rm -rf /、dd 写盘等），这道过滤发生在 LLM 输出与系统调用之间，无法被模型绕过。TCC（Transparency, Consent and Control）路由机制则将敏感的 AppleScript、JXA、屏幕截图、可访问性请求重新导向到 Agent! 自身持有的 TCC 权限上下文中执行，避免了通过子进程触发权限请求时常见的「权限漂移」问题。这些防御层在 Electron 环境下难以实现，因为 Web 进程的 TCC 上下文与系统原生应用的上下文存在本质差异。
实践参数与选型建议
对于考虑从 Electron 方案迁移的团队，以下参数值得评估。首先是硬件要求：Agent! 需要 macOS 26.4 以上版本且为 Apple Silicon 芯片，这一门槛排除了 Intel Mac 与旧版系统，但换来了统一的 ARM64 架构与硬件加速能力。其次是 AI 供应商的选择 —— 项目内置 17 个 provider，对于追求成本的场景推荐 GLM-5.1 通过 Z.ai 或 BigModel（每百万 token 成本极低），对于复杂推理任务仍推荐 Claude 或 OpenAI。
自动化能力的实际效果高度依赖系统权限的授予程度。完整启用桌面 automation 需要在「系统设置 → 隐私与安全性 → 可访问性」中授权，远程 iMessage 控制则需要「完全磁盘访问」权限。这些权限一旦授予，Agent! 即可实现从「语音唤起 Agent! 执行测试套件」到「iPhone 短信控制 Mac 查找文件」的完整工作流，而这类场景在 Electron 方案中要么根本无法实现，要么需要极其复杂的第三方库拼接。
原生 macOS 架构为 AI 编码工具打开的，是一个被 Electron 玻璃天花板长期压抑的系统级能力空间。当 AI 不再仅是一个运行在 WebView 中的对话界面，而是作为一个拥有完整系统权限的原生应用时，它与 macOS 之间的交互深度将迎来质变。这条技术路径的代价是平台锁定与更高的开发复杂度，但对于追求极致系统集成度的场景，它提供的能力边界远非 Electron 方案所能覆盖。
资料来源：GitHub macOS26/Agent 项目文档（https://github.com/macos26/agent）