我把一个AI代理放在Mac的刘海后面:通过审核卡片将随口说出或打字的内容变成提醒和待办事项。你会把自动批准的界限划在哪里?
摘要
一位独立开发者描述了一款Mac应用,该应用在刘海区域放置了一个AI代理,通过审核卡片将语音或文字输入转化为提醒、待办事项和日历事件,并向社区询问对重复操作是否应自动批准的看法。
我开发了一款Mac应用,一个代理隐藏在刘海后面。你可以说话或打字;它要么回答,要么将你的话变成真实的提醒、待办事项、笔记和日历事件。我是独立开发者,这是我自己的项目,而代理层正是我想听取意见的部分。根据版规,帖子里不放链接;我会在评论中放一个。最终重要的设计决策如下:
- 路由优先于模式。你不需要选择“聊天”或“操作”。系统自动读取请求并路由;当猜测错误时,可以通过“执行”和“询问”按钮强制指定。
- 每次写入前都会显示审核卡片。“把ship 4.9和回复Ken加到待办事项”会显示一张“Claude将执行”的卡片,包含两项内容,只有点击“执行”后才会运行。听错一句话不会造成损失。
- 纯打开操作跳过审核。“打开转换器”直接打开它,因为打开操作不会写入任何内容。只有在有后果时才需要审核。
- 语音需要一个词语阀门。设备端识别,每当监听激活时显示红点,这样会议中的咳嗽不会浪费一次运行。
- 它也中转其他代理的提示。Claude Code或Codex在终端中停下来请求权限时,刘海会显示“允许/拒绝”,并可以跳回对应的终端。从本周开始,提示会停留在所有显示器上直到被回答,即使在全屏模式下也是如此。它通过Claude Code使用用户自己的Claude订阅运行。没有API密钥,没有中间服务器,用户的数据不会触及我的服务器。
我反复思考的问题是:每次写入前都显示审核卡片是否应该永远作为默认行为,还是重复的相同操作应该在某些时候获得自动批准?你会把界限划在哪里?
相似文章
你实际上是如何为AI代理构建审批门的?我确信大多数都只是形同虚设
作者认为,许多针对AI代理的人工审批门效果不佳,如同虚设;并提出了一个框架,用于设计能够真正捕捉错误的有意义的审查机制。
在写了三次相同的胶水代码后,我为AI代理构建了一个人工审批收件箱
开发者推出Impri,一个面向AI代理的开放式核心人工审批收件箱,通过实施结构性屏障而非提示指令来防止未授权操作。
审批队列即架构:我如何构建一个运行真实产品的自主 Claude Code 智能体
作者详细阐述了“Aiden”的架构,这是一个管理名为 Delegate 的产品的自主 Claude Code 智能体,强调采用人在回路(human-in-the-loop)的审批队列系统,以确保生产环境中的安全性与效率。
让我坚持使用的智能体不写任何代码,它只是构建我的周五冲刺回顾
一个不写代码的AI智能体,但能帮助构建周五冲刺回顾,突出了一个具体的生产力用例。
@cursor_ai: 自动审查模式现已在 Cursor 中可用。它允许代理以更少的批准提示和更安全的执行来运行工具调用…
Cursor 发布了自动审查模式,该模式允许代理以更少的批准提示执行工具调用,同时保持安全。