本地运行的代码智能体经常陷入一种荒诞的沉默:它能在一个指令下重构整个代码仓库、完成复杂的跨库迁移,却会因为系统弹出一个授权窗口而彻底卡住。智能体在终端深处打印出一行无人注意的提示请点击允许,而你的终端早被堆叠的浏览器和编辑器挡在下层,双方在静默中无限等待。

开发者 Franz Enzenhofer 开源的 bigarrow 0.4.2(项目名为 big-arrow-on-the-screen),就是为了解决这个断层。作为适配 Claude Code 与 Codex 的终端技能,它做的事情极其纯粹:当自动化流程撞上必须人类确认的壁垒时,直接在屏幕顶层画出一个巨大的亮色箭头和提示标牌,指明该按哪里。

终端里的静默阻断与屏幕上的物理箭头

在多窗口协同的开发场景里,纯文本交互正在暴露出严重的注意力损耗。智能体遇到 macOS 权限弹窗、双重认证(2FA)、验证码或支付确认时,操作系统基于安全策略阻断了代码的自动操作,智能体只能停下来等人。

悬浮箭头驻留最高保护层,引导操作而不中断下层键入(示意图)
悬浮箭头驻留最高保护层,引导操作而不中断下层键入(示意图)
Code
bigarrow point --element "Allow" --app "System Settings" --text "Franz, click Allow"

这行命令执行后,屏幕上会出现一个带有文字说明的大箭头,指向系统设置中的按钮,并在倒计时结束后或用户点击后自动消失。除了单次指向,工具还提供了持续常驻并在任务结束时销毁的控制方式。

这个看似简单的功能,在底层解决了一个极容易引发用户烦躁的交互缺陷:焦点劫持。如果一个后台绘图程序每次提醒都在系统层面抢走键盘和鼠标焦点,用户正在键入的文字就会被打断。

bigarrow 核心工作流:阻断到放行 1. 遭遇安全阻断 TCC 权限 / OAuth 系统禁止脚本点击 终端陷入静默挂起 2. 顶层视觉引导 AppKit 不抢占焦点 混合穿透保留点击 高亮指向物理按钮 3. 人类接管与恢复 用户完成授权动作 标牌自动或手动销毁 返回退出码 0 继续流程

为了做到绝对静默,该项目用 Swift 编写,底层基于 AppKit 的 NSPanel 构建覆盖层,设置了 .borderless 与 .nonactivatingPanel 样式,窗口层级设在 .screenSaver 级别,并启用了 ignoresMouseEvents = true。更关键的细节在事件分发:其内部的 OverlayApplication 采用 .accessory 激活策略,由代码手动分发 AppKit 事件,彻底弃用了会悄悄夺走焦点的 NSApplication.run()。

免权限绘制与需权限定位的落差

项目在文档中给出了相当吸引人的宣传:绘制本身完全不需要任何 macOS 系统权限。这一表述在技术上是成立的,但如果用户打算真正使用其最核心的元素查找能力,现实就要复杂得多。

提示牌受击即关闭,尖端镂空让点击直接穿透至底层确认按钮(剖面示意)
提示牌受击即关闭,尖端镂空让点击直接穿透至底层确认按钮(剖面示意)

通过物理坐标参数(--at、--rect)绘制覆盖图层确实免权限,因为操作系统允许轻量级窗口随意浮动在桌面上。然而,智能体并不总是知道弹窗按钮的精确像素位置。一旦使用了按文本寻找按钮的 --element 参数,程序就必须遍历操作系统的可访问性树(Accessibility Tree)。

绘制能力与权限需求对比 基础绘制模式(--at / --rect) 权限门槛:零系统权限需求 实现原理:原生浮动 NSPanel 局限所在:需调用方预先计算像素坐标 定位精度:依赖外部视口比例与分辨率 语义定位模式(--element) 权限门槛:强依赖 Accessibility 授权 授权主体:终端宿主(Ghostty/VS Code 等) 浏览器适配:Chrome 需强制开启 AX 树 潜在代价:宿主被授予全局无障碍嗅探权

这意味着,运行智能体的宿主环境(无论是 Ghostty、iTerm2、VS Code 还是 Claude 原生客户端)必须在系统设置中拥有 Accessibility 权限。如果是定位浏览器内部的 DOM 按钮,Chrome 默认还会忽略无障碍树读取请求,除非用户以 --force-renderer-accessibility 参数启动浏览器,否则智能体依然只能退回到像素坐标模式。

另一个微妙的设计在于交互穿透。项目初期强调全穿透,但在实际使用中,完全无法交互的悬浮物往往带来新的困扰。当前的机制改为了混合点击:

  • 用户点击箭头指示牌或箭身时,会直接关闭整个提示。
  • 箭头尖端及所指的目标区域保持点击穿透,用户可以直接按到下层的真实按钮。
  • 当指定目标程序时,工具默认会将该窗口提升至最前,若不希望桌面被扰动,需主动传入 --no-raise 参数。

针对代理程序调用的稳定性,工具规范化了退出状态码体系:0 代表成功,2 代表参数错误,3 代表未找到目标,4 代表缺少系统权限;开发者还可以直接通过 bigarrow doctor 命令排查当前宿主的授权状态。

退回指引:智能体在操作系统防线前的妥协

在当前的 AI 叙事里,多数人习惯了假定智能体会向着无所不能的端到端自动化演进,甚至试图用模拟鼠标与视觉模型去绕过系统的安全边界。但 bigarrow 展现出了完全相反的务实路径:只指引,不代点击。

智能体在系统防线前只投射光标指引,把按键动作留给人类(示意图)
智能体在系统防线前只投射光标指引,把按键动作留给人类(示意图)

现代操作系统的安全基石(如 macOS 的 TCC 机制)从架构设计上就故意阻断了未知软件代按确认键的可能性。如果一个智能体为了绕过限制去滥用辅助功能模拟点击,不仅工程极不稳定,还会带来巨大的越权风险。

不越俎代庖去按下那个按钮,反而守住了人机分工里最合规的安全边界。

从项目工程的成熟度来看,该项目目前仍处在极其早期的极客原型阶段:

项目现状快照(版本 0.4.2) 27 GitHub Star 收藏数 0 公开 Fork 与 Issue 0 份 独立第三方安全审计文件

该工具的初始代码记录始于 2026-10-08,并在次日更迭至 0.4.2,检索时在 GitHub 上仅有 27 颗星,没有分支也没有开放议题。虽然作者声明了无常驻后台守护进程、无数据遥测与无网络调用,但仓库内缺少独立的第三方安全审计文件。

  • 风险.当开发者为了让工具自动寻找界面按钮,而轻率地将终端或编辑器的 Accessibility 权限完全开放时,潜在的系统攻击面也随之扩大,可能导致宿主工具链获得过度宽泛的无障碍监听能力。

在更完善的本地代理交互协议确立之前,CLI 终端并不会消亡,但混合式的桌面引导正在成为主流解法。智能体负责繁重的逻辑分析与目标定位,最终的责任判定与物理按压依然交还给屏幕前的人类。向操作系统的安全边界低头,不是智能体的退化,而是它真正融入生产环境的必经代价。