说实话，自从我开始深度依赖 Claude Code、Copilot CLI 这类 AI Agent 工具以来有个痛点一直如影随形，简直让人抓狂。每当把任务丢给 AI 在后台默默耕耘时我就患上了某种“强迫症”，总忍不住切回去kankan进度条走到哪了或者它是不是又卡死了。尤其是遇到那些稍微复杂点的重构任务，动辄就要跑个十几分钟，这期间我就像个守着微波炉的饿汉，每隔几秒钟就要拉开门kankan好了没。

geng让人崩溃的是有时候 AI 需要我授权某个敏感操作——比如执行一段 shell 命令或者修改系统文件——它就会安安静静地停在那里等。而我呢，完全没注意到，还在旁边傻乎乎地刷网页。这一等就是好几分钟，回过神来才发现，原来它早就把“球”踢回来了只是我没接住。这种无效的等待，不仅浪费时间，geng是对注意力的极大破坏。

为了解决这个问题，我一直在寻找一个靠谱的通知方案，Neng让 AI 在完成任务或者需要我介入时主动“喊”我一声，而不是让我像个老妈子一样盯着它。

痛点：被“等待”绑架的开发体验

灵感其实来源于一期播客，叫「枫言枫语」。主播自力在节目中提到，Ke以用 Hook机制来实现 Agent 的状态通知。这听起来是个极好的主意，毕竟 Hook 是系统级的触发机制，比什么dou靠谱。

不过一开始我犯了大多数程序员dou会犯的毛病：懒。我想着，Neng不Neng直接让 AI 自己搞定这件事？于是我问 Claude：“你Neng不Neng在任务结束时自己播放个提示音？”

这货倒是挺自信，直接给我甩了一个方案：在 ~/.claude/CLAUDE.md 里加一段系统提示词，指示 LLM 任务完成后调用 afplay 命令播放一段音频。这方案kan起来hen“AI”，逻辑也通顺，但我实测了几次就发现——这玩意儿完全不靠谱！

有时候它响，有时候不响，完全kan LLM 当时的“心情”。这就好比你拜托同事帮忙带杯咖啡，他心情好就带了心情不好就忘了你根本没法依赖。这种不确定性，对于追求效率的开发流程来说简直是灾难。

那个不靠谱的“偷懒”方案

为什么这个kan似聪明的方案会失败？归根结底，这是一个“软提示”与“硬触发”的博弈。用提示词去控制 LLM 的行为，本质上是在“请求”它Zuo一件事，而不是“命令”它。LLM 的核心是生成文本，而不是执行逻辑，它可Neng会因为上下文过长、注意力分散或者单纯的理解偏差，就忽略了你的那条“播放声音”的指令。

这有点像现在的 LLM 和 Agent 的区别。LLM 是负责思考的大脑，而 Agent 是负责干活的双手。你让大脑去控制双手拍手，大脑可Neng会走神；但Ru果你设定一个条件反射——手碰到火就缩回——那就是确定性的生理反应，绝不会出错。

确定的事情，还是要交给确定的机制去Zuo。所以我Zui终还是乖乖回到了 Hook 方案，决定利用各平台提供的 Hooks 系统，来实现确定性的触发，并将其封装成了一个可复用的 SKILL。

终极解法：用 Hook 夺回控制权

经过一番折腾，我开发出了 agent-notifier 这个 SKILL。它的目标hen明确：利用 Hooks 实现确定性通知，让 AI 真正成为你的助手，而不是需要你时刻盯着的孩子。

Zui终实现的效果非常令人满意：无论我在干什么只要 Claude Code 或者 Copilot CLI 有动静，我的手机、电脑音箱或者系统通知中心dou会立刻给我反馈。这种掌控感，真的久违了。

Agent 与 LLM 的本质区别

在深入技术细节之前，我想再强调一下这个核心观点。我们在构建 AI 应用时一定要分清什么是“思考”，什么是“执行”。

提示词适合控制生成内容的风格、方向和逻辑，比如“用幽默的口吻解释这段代码”。但是对于“是否执行某个操作”这类二元决策，尤其是涉及到系统级交互的时候，提示词就显得力不从心了。这时候，Hooks 这种硬编码的机制才是王道。它不依赖于概率，不依赖于模型的心情，只依赖于事件的发生。

agent-notifier：我的技术实现思路

基于以上分析，agent-notifier 应运而生。这个工具的设计理念非常清晰：统一事件模型 + 并发多渠道分发。

目前，它Yi经支持主流的 AI Agent 平台，比如 Claude Code 和 Copilot CLI。而在通知渠道方面我也尽可NengZuo到了全覆盖，包括系统级的声音提示、macOS 原生通知中心，甚至支持 Telegram 和 Email，让你即使不在电脑前也Neng收到消息。

统一事件模型：把翻译成普通话

整个系统的核心难点在于，不同平台的 Hook 机制传出来的数据格式千奇百怪，就像各地一样。

比如Claude Code 传过来的 JSON 可Neng是 {"notification_type": "idle_prompt", "message": "Claude is waiting for your input"}；而 Copilot CLI 可Neng就是 {"hook_event_name": "sessionEnd", "details": "..."}。

Ru果针对每个平台单独写逻辑，维护起来会非常麻烦。所以我在 notify.py 里Zuo了一层抽象。无论 stdin 输进来的是什么格式的 JSON，脚本dou会先进行解析，将其统一转换成一个标准的三元组结构：{platform, event, message}。

这就好比无论你说四川话还是广东话，中间的翻译层dou会把它们转换成标准的普通话，然后再发给后端的处理模块。这样一来后端的分发逻辑就不需要关心数据来源了只管处理标准事件即可。

并发分发：单点故障的噩梦终结者

有了统一的事件对象，下一步就是分发。这里我采用了 Python 的 ThreadPoolExecutor 来实现并发多渠道分发。

为什么要并发？想象一下Ru果你的 Telegram 服务器挂了或者网络超时了难道就要卡住整个通知流程，导致连本地的声音dou不响了吗？当然不行。

在我的设计中，每个通知渠道dou是独立的。脚本会读取 notify-config.json 配置文件，kan用户启用了哪些渠道。然后所有启用的渠道会同时触发。即使 Telegram 发送失败抛出了异常，Sound 和 macOS 通知依然会正常工作。错误信息只会被输出到 stderr，用于调试，绝不会中断主流程。

这种“优雅降级”的设计，保证了通知的极高可用性。

零依赖：Python 标准库的胜利

还有一个让我引以为傲的设计点：整个 notify.py 只使用了 Python 的标准库，没有任何第三方 pip 依赖。

这意味着什么？意味着只要你的机器上装了 Python，你就Ke以直接把脚本扔过去运行，不需要配置虚拟环境，不需要 pip install 任何东西。对于这种轻量级的工具来说依赖越少，维护成本越低，移植性也越好。毕竟谁也不想为了听个响，还得先装一堆库。

从想法到落地：对话式编程实录

整个 SKILL 的开发过程，其实也是我和 AI 对话完成的。这算是一种“用 AI 开发 AI 工具”的元编程体验。下面我就分阶段回顾一下这个过程，kankan我是怎么一步步把这个想法变成现实的。

核心逻辑：notify.py 的三重奏

这是Zui核心的部分，notify.py 主要负责三件事：读取输入、解析事件、分发通知。

当 Claude Code 的 Hook 被触发时它会通过 stdin 传入一段 JSON 数据。比如：

{"notification_type": "idle_prompt", "message": "Claude is waiting for your input"}

脚本拿到这段数据后会立刻识别出这是来自 Claude Code 平台的 idle_prompt 事件。然后它会根据预设的规则，生成一条geng友好的通知文案，比如 “✅ Task completed — waiting for your input”。

紧接着，脚本会检查配置文件，发现我启用了 Sound、macOS 通知和 Telegram。于是三个线程同时启动，声音响了系统弹窗出来了手机上也收到了 Telegram 消息。一气呵成。

配置的艺术：notify-config.json 与 setup.py

光有核心脚本还不够，作为一个好用的工具，还得让用户Neng方便地配置和安装。所以我又搞了两个辅助文件。

notify-config.json 是配置模板。这里面定义了所有支持的渠道开关和参数。考虑到隐私和易用性，默认情况下我只启用了 Sound 和 macOS 通知，因为这两个不需要任何凭据。而 Telegram、Email 这些需要 Bot Token 或密码的渠道，默认是关闭的，需要用户手动去填参数并开启。

setup.py 则是一个交互式安装脚本。运行它之后它会引导用户完成一系列初始化操作，比如检查 Python 环境、生成配置文件、提示用户如何去 Claude Code 的设置里添加 Hook 路径等等。这大大降低了使用门槛，哪怕是不太懂配置的新手，也Neng跟着提示一步步走完。

实战演练：让 Claude Code “开口说话”

代码写完了配置也Zuo好了关键时刻来了——跑起来验证一下。这就像新车下线后的试驾，理论再完美，实测才是硬道理。

配置 Hook 与手动测试

我得在 Claude Code 的配置文件 ~/.claude/settings.json 里把 Hook 加进去。配置结构大概是这样的：

{
  "hooks": {
    "Notification": 
      }
    ]
  }
}

这段配置的意思是每当有 Notification 事件发生，就执行我写的那个 Python 脚本。

配置好后我没急着直接跑任务，而是先Zuo了手动模拟测试。在终端里输入以下命令：

# 模拟任务完成通知
echo '{"notification_type":"idle_prompt","message":"test"}' | python3 notify.py
# 模拟权限请求通知
echo '{"notification_type":"permission_prompt","message":"needs permission"}' | python3 notify.py

敲下回车的那一刻，清脆的提示音响起了macOS 右上角也弹出了通知框。心里一阵暗爽：初步成功！

接着，我胆子大了一点，去配置文件里开启了 Telegram 通知，填好了 Bot Token 和 Chat ID。 运行测试命令——几秒钟后放在桌上的手机震动了一下Telegram 消息如期而至。完美，多渠道分发通了！

细节决定成败：文案的微调

Zui后就是真刀真枪的实战了。我让 Claude Code 执行一个真实的耗时任务，然后自己切去干别的事，不再盯着它。

过了一会儿，任务结束。Telegram 弹出了消息，声音也响了。但是我kan着手机上的消息，眉头皱了起来。

消息显示的是：“Claude is waiting for your input”。虽然从技术角度kan，idle_prompt 确实就是任务完成后等待输入的信号，但这句文案太“技术化”了不够直观。我kan到这句话的第一反应是：所以呢？是Zuo完了？还是卡住了？

用户体验这东西，往往就差在这Zui后的一点点感知上。我geng希望kan到的是明确的结论，比如“任务Yi完成”，而不是描述状态“在等你输入”。

于是我立刻修改了 notify.py 中的文案生成逻辑，把 idle_prompt 对应的消息改成了geng直白的 “Task Completed” 或者 “任务完成，请查收”。

改完之后再测，Telegram 消息一目了然不用再猜它到底是什么状态了。这种微小的调整，虽然不涉及复杂的算法，却极大地提升了工具的易用性。

Hooks> 提示词

这次开发经历，让我对 AI Agent 的开发模式有了geng深的理解。Zui核心的观点依然还是那句话：Hooks> 提示词。

凡是需要确定性执行的操作，dou不应该用提示词去“请求”LLM 来Zuo。提示词是软的，充满了不确定性；而 Hooks 是硬的，是系统级的契约。提示词适合控制生成内容的风格和方向，但不适合控制“是否执行某个操作”这类二元决策。

另外对话式开发的体验依然让我印象深刻。从Zui初的一个模糊想法，到Zui终一个功Neng完备、可复用的 SKILL，整个过程就是不断对话、测试、修复的循环。像 Telegram 消息文案不够直观这种问题，光靠想是想不出来的，只有在实测中才会暴露出来。

Ru果你也深受“傻等 AI”之苦，或者对这种 Hook 机制感兴趣，欢迎去 GitHub 仓库kankan源码，agent-notifier 就在 skills/agent-notifier/ 目录下。希望这个小工具Neng帮你夺回注意力的控制权，让 AI 真正为你服务。

---