最近，我制作了一个 Mac 原生的工具，叫做 Asky（Github 链接：https://github.com/Niall-Young/Asky），这是我第一次制作如此庞大的 Mac 原生软件。它包含了 Spotlight、Agent 能力等等，在构思期间我想了很多，但如果真要说介绍这款产品，我觉得其实是在这个 AI 时代没有意义的，同类的项目很多，很多很多，Hapigo、raycast、tinycast 等等，而且比我的更好、更优雅，所以我觉得与其直接介绍这款产品，倒不如介绍介绍自己是如何把这款产品做出来的，或许还能对大家在 Swift 开发和桌面应用的 Agent 选型等方面的开发中有些帮助。
想法萌生过程
其实这个产品我在半年前就想做了，我看派大鑫只做了一个桌面 Agent，可以利用 Mac 提供的各种 API 接口直接操作 Mac 的系统应用，比如日历、短信等等，我当时的第一感觉是——我也想做一个。但是在年初的时候，有几座大山在我面前，让我放弃了这个想法。
在当时最主要的是我完全不懂 SwiftUI 开发，在年初的时候，没有 Codex，Trae 等工具的能力也完全不够强，那时候想要真正意义上的什么都不懂的 Vibe 开发出一个复杂产品几乎是不可能的。
另一方面，是我没想好我能做出来什么，我找不到差异点，我也没想好这个东西很酷炫，可是然后呢——我自己用的起来吗？
这个问题其实一直是我到现在做很多东西喜欢反思的问题，AI 太容易让我们进入一种“技术高潮”的状态了，特别是现在，有一个偏向技术的想法想要做出来可能只需要一句话搭配一段或长或短的等待就可以了，那种 0-1 的构建成就感会让我们获得巨量的多巴胺，却忘了去多问问自己这么做的价值什么？哪怕不是为了别人，为了用户，只是自己用，自己真的能用起来吗？
随着今年 AI 的蓬勃发展，第二个问题越来越成为主要问题，所以即使 AI 现在已经足够支持我们一句话出一个小产品了，但是我迟迟没有做。
直到最近，我发现苹果的 spotlight 确实是有不少限制让我不爽——它的交互并不丝滑，比如剪切板明明是个偏向浏览后选择的行为，却做成了搜索，等等。我开始了解 Raycast 这类工具（官网链接：https://www.raycast.com/），我被 Raycast 那种精致和简约所震撼，但是他确实挺贵的——我有一个要么就是免费，要么就必须付费的强迫症毛病，一年 400 多人民币的价格确实不是个小数字，然后我又使用了开源的 Tinycast（Github 仓库链接：https://github.com/abue-ammar/tinycast），我觉得 Tinycast 是很不错的，但是我觉得它的剪切板不够优雅，而且没有 Raycast 的 AI 能力，后来我又开始使用国产的 Hapigo（官网链接：https://hapigo.com/），这款产品的开发者做的截图工具 1 Capture 我付费后一直在用，Hapigo 满足了我绝大多数的需要，但是作为一个设计师，诚然我是无法接受 Hapigo 的颜值，和原生的质感差距实在是太大了。
Hapigo 是一款优秀的启动器，而且功能丰富，还集成了 AI 功能，价格也十分便宜，基础订阅只需要 98 元/年，是非常优质的选择，但是，回到我们最开始的话题，Hapigo 还是没能做到和我的 Mac 在真正的 AI 时代实现打通，还是停留在AI 对话这种最基础的 AI 能力上，Raycast 这种可以打通 AI 和 Agent 能力帮助用户真正承担起一个 AI 时代的 Mac 启动台的产品无论是 Tinycast 还是 Hapigo 都并不足够。
再者就是更重要的——Hapigo 的很多功能有和我的付费工具存在冲突，也就是我所谓的“功能过剩”。例如我有 Bob （官网链接：https://bobtranslate.com/）帮我来做翻译工作，Bob 的体验十分丝滑，而且快捷键经过自定义后我已经养成了肌肉记忆，Hapigo 虽然提供了翻译功能，但我更希望它关闭，再比如录屏我喜欢使用 Cap（官网链接：https://cap.so/），它开源且一直有人维护，功能强大；Hapigo 开发者还直接把 1 Capture 的能力直接集成了进来，这就导致我的 Hapigo 订阅和 1 Capture 产生了功能付费冲突。换句话来说，很多功能我已经有各司其职的工具软件了，不需要那么高度集成，这可能影响我现在的使用心流，也会造成快捷键灾难。
此外，也有人建议我不如给 uTools（官网链接：https://www.u-tools.cn/）开发一个插件直接补齐能力，但是 uTools并非是原生开发的，是一个 Electron 应用，这就导致它的内存占用、应用体积一定是巨大的，对于这种常驻应用一定不是一个好的选择。
与此同时，随着 Muse、Today AI 的走红，我开始觉得 Personal agent 并非某一家公司才能制作，我自己也可以制作，而且我每天使用 Mac 的搜索启动记录，是更加有价值的记忆内容，这表现了我的操作习惯，因此，我想以 Spotlight 为交互入口，制作自己的 Personal agent，同时具备 Spotlight 我需要的种种能力。
结合下来，我想你已经清楚了我想做一个这么，我想做一款 Swift 原生的美观优雅的应用（因为这样性能最好，我觉得常驻应用最好是使用原生开发），它不仅是一个 Spotlight，一个剪切板工具，还是一个我的个人 Agent，它有记忆，有链接操作我的电脑的能力，是我的得力桌面助手，而这一切，就像 Raycast 一样，只需要 cmd+space然后输入。
技术选择
我刚才说过，Swift 这种原生开发会有着更好的性能（实施也确实如此），而且这可以让这款产品和系统原生的应用一样的融合，就仿佛是 Mac 自带的一样，不会产生任何割裂感。
我其实最开始希望 Agent 能力也可以使用 Swift 来写，我特意让 Codex 帮我调研了现有的方案技术，我发现似乎并不是那么可行，我能找到的几个比较有信服力的 Swift 原生的 Agent 能力只有这么几个仓库：
项目 | 链接 | 问题 |
|---|---|---|
SwiftAgent | 社区生态几乎没有，可靠性尚未验证 | |
Apple Foundation Models | 只能作为底层能力，而且限制巨大，很多新的 Agent 能力都不支持 | |
ClaudeSwift | 与 SwiftAgent 一样的问题 |
这几乎完全否定了 Swift 直接开发 Agent 这个想法，因为我不具备能够自研一整个 Harness Agent 的能力，应该说是完全不具备，因此我必须选择其他技术路线的方案，最先想到的就是现在主流的 Typescript 技术的开源 Agent 们，高度集成的有 Kimi code、Claude code，开源的有 Deepseek Harness，Oh my pi，再比如使用 Rust 构建的 Codex，这里面我觉得可以分为 2 类，一类是完整的产品性质的开源 Agent，例如 Claude code、Kimi code、Codex，另一类是更多倾向于开源插件构建的 Agent，例如 Deepseek Harness，Oh my pi。
最终我选择的是 Oh my pi，我说一下原因：
Oh my pi 完全开源，而且也是非常火热且广泛验证过价值的产品；
我的桌面 Agent 并不需要太多模块，例如 Subagent、Goal 这些模块都不需要，而 Oh my pi 所有模块都是插件化的，我可以按需装配，避免像 Codex、Claude code、Kimi code 这些 Agent 一样过于臃肿；
Oh my pi 自带核心的 Agent loop，以及记忆模块，只有记忆写入模块缺失，但是搭配模型模范 Codex、Claude code 这些 Agent，足够使用原生写一个专门的记忆写入模块来使用。
最后选择了 Spotlight 等和 AI 能力的前端使用 Swift 原生开发，Agent 能力内核使用 Pi 的核心 Agent loop 以及记忆模块，不过就像上面说的，Pi 本身是没有记忆写入能力的，这也是后面我遇到的问题，我会在后面提到。
执行避雷指南
其实真要说到开发部分，我觉得督导这篇文章的各位，都是没问题的，哪怕你和我一样什么都不懂，也可以直接描述需求让 AI 帮你完成，有问题就不断调整就好了，不过，有一些我觉得或多或少提升你的开发效率和你的开发体验的事情，以及一些我觉得蛮重要的注意事项，想在这里汇总一下，希望能帮到你～
踩坑避雷建议
Pi Agent 没有记忆写入模块
这个部分我也是再开发了几个版本后才注意到的，我发现一直都没有记忆写入，于是询问 AI 怎么回事，了解到 Pi agent 官方没有记忆写入模块，而是依赖的 Claude.md 以及 AGENTS.md，这就导致写入记忆需要我们自己来做，其实问题也不是很大，把刚才上方的几个 Agent 的 Github 仓库发给 Agents，然后让它模仿人家的原理来制作一个原生的方案即可，最后我发现实现的效果很不错。
液态玻璃效果
关于液态玻璃我遇到了 3 个比较大的问题，我想或许你也会遇到。
第一个问题是众所周知的，液态玻璃效果只有在 MacOS 26 及以上才能存在，以下的版本只能使用背景模糊的半透明层，如果你有这个适配的必要，注意向下适配。
第二个问题是我真正开发液态玻璃效果才知道的，那就是 Apple 提供的液态玻璃并没有那么多参数可以配置，如果你是一个会使用 Figma 的设计师或者开发者，会发现 Figma 中的液态玻璃效果高度可定制化，但是却是完全无法和真正开发环境的液态玻璃对应上的，苹果真正支持的液态玻璃参数只有下面这几个：
API 参数 | 作用效果 |
|---|---|
.glassEffect() | 是否应用液态玻璃，也就是说你依然可以在 MacOS 26 及以上的系统上不使用液态玻璃 |
.glassEffect(_:in:) | 配置样式，液态玻璃只有两种样式，一个是 regular，原生的 Spotlight 的液态玻璃质感就是 regular，另一个则是高透亮的 clear，类似最早期的 beta 版本液态玻璃，高度透亮，一般是不适合做背景层的 |
.tint(_:) | 控制玻璃的颜色 |
还有一些关于液态玻璃的交互和融球等效果的，这里不做说明了，能控制样式的参数就只有这三个，不难发现，我们根本无法像 Figma 里面一样随便控制液态玻璃的效果，只能使用 Apple 官方的效果，完全不可以修改。
也就是说，这部分内容反而更适合直接 Vibe coding，而不是现在设计稿出图，设计稿只需要关注布局、间隔即可，不需要关注视觉的样式属性。
第三个问题或许不是每个人都会遇到，不过我遇到了，就是经常出现黑边框问题，如下图，这个问题其实困扰了我很久，后来我才知道是因为窗口尺寸问题，Swift 绘制阴影是根据容器真实的窗口走的，因为实际窗口更大，就导致出现了这种问题，要解决的方案就是告诉 Agent，尽可能接近原生 Spotlight 的解决方案来避免这些问题。
自用可以使用本机证书
如果你没有很强的分发需求，主要是自己用，那么可以使用本机签发的证书签名，这样你就不需要每次更新版本都要重新授权，极大地提高你的使用体验，这个证书是免费的，而且就算开源分发也不会泄露你的个人信息，非常方便。
不过要注意的是，如果你是有着想要上架 APP Store 的需求，可以考虑每年花费 100 美金的价格购买开发者签名证书，这个是不限制 APP 数量的，如果你想要成为一个专业的 APP 开发者，我觉得这是必花的钱，没必要节省。
如何连接本机应用
其实这部分很简单，你用 MCP 也好，还是直接给 AI 一个工具让它可以连接对应的 API，这些都是可以的，我是使用的 MCP，这样方便分发，比如我也可以把这个 MCP 交给其他的 Agent 来调用。
优化开发效率建议
拒绝 AI 自测
如果你使用 Codex，我很建议在 AGENTS.md 里面写明不要自己进行测试，交给用户进行测试，如果是 Claude code 那就不需要。我这里说一下为什么要这么设置， Codex 和 Claude code 的 Harness 不同，Codex 默认会执行很多的单测和端侧，而我们做的是 App，而不是 Web 网页，无法使用 Browser use，因此使用 Computer use 就会抢占鼠标，甚至会阻挡你的屏幕内容显示，这会极大降低你的开发体验，特别是你在并行多 Agent 开发的时候，建议强制要求 Agent 不要进行构建和测试，由自己点击测试即可，不只是 Swift 的原生 App，我建议所有的 App 开发都做一步。
使用 AppKits 加速前端开发效率
不要所有的模块都使用 Swift 从 0 造轮子，使用 Apple 官方的 AppKits，这些就是你在 Apple 的设置里看到的组件，它们也是原生的，而且也是可以继续调整样式，多数开发者做的产品，都会使用这部分来制作设置页面，还有菜单栏的菜单项。
注意定期清理打包文件
在本地开发的话，一定要注意构建的包的清理问题。
我起初并没有注意到这个问题，结果开发了几天发现我的硬盘满了，里面全是项目的打包版本，占用了 100 GB 以上的空间，注意清理就好，如果你像我一样不懂这方面的知识，可以直接让 Agent 帮你处理。
安全问题
我能够让 Agent 直接操作我的电脑，说实话这是个很高的权限，如果不做任何限制让 Agent 为所欲为，那肯定会出问题的，在 Codex、Claude code 或者飞书的 Aily 中，会专门为 Agent 提供沙箱，让其在沙箱中做权限隔离地运行，但是这么做很重，因为我更推荐简单的规则约束机制，因为我们毕竟做的 Agent 能力很单一，Harness 也比较薄。
我的处理方式类似去年年底的那些 Coding agent，通过关键词匹配以及关键行为来做确认。例如当 Agent 要删除某一个日程的时候，会弹出 Dialog 对话框要求用户确认，这就可以解决问题，而不需要使用沙箱，当然我也做了类似 Yolo 模式的东西，完全不询问直接操作。
后续维护
这部分我想分两部分来讲，一部分是基础的更新服务，一部分是如何拓展应用能力。
更新能力
这部分我觉得简单过一下就好了，我相信大家都是知道更新能力的，即使不知道，也可以直接交给 Agent 来处理，唯一要注意的是，更新后记得清理掉老版本应用，否则用户会看到好几个对应的应用。
拓展应用能力
这部分我觉得是一种趋势吧，开源产品的趋势，我发现 yetone 对 magpie（官网链接：https://usemagpie.ai/zh/）这些开源项目也采取了折中方案，那就是插件化来补充能力，我也是这么做的。
我说一下为什么使用插件，主要有以下几点原因：
为了使用 Pi Agent，我已经打入了 Typescript 以及依赖的 Node.js 了，导致包开始有些大了，我需要“瘦身”，增强功能尽可能在安装后，由用户主动按需安装；
作为个人开发者和开源工具，就要避免作为个人开发者容易遇到的维护压力问题，同时借助开源生态，插件化可以让更多人按需开发对应的功能，减少我的压力。
开发插件系统也不是很复杂，我的思路是让每一个插件对应一个 Github 仓库，用户只需要在设置中添加对应插件的仓库即可自动完成安装，并且我官方也内置了一些能力，比如直接操作 Orca 以及使用飞书 CLI 这些。
动手构建一个自己的 Personal Agent
每个人对个人知识的理解，以及对 Personal agent 的想法都是不同的，就像我认识的朋友中，有的人极度依赖系统日历的日程，有的人从来没用过，不同的人有不同的习惯，我之前写过一篇博客说过 AI 时代人人都该有属于自己的专属工作流（原文链接：AI 时代，人人都需要属于自己的工作流 · Niallspace Blog），其实道理是相通的，Personal Agent 之所以是 Personal，不是单纯因为它能获取你的真实个人数据，也是因为它完全符合你对一个个人助手的想象。
AI 时代，制作一个自己的个人 Agent 这没有这么难，不妨你也来试试看！
0 次点赞
今天可以点赞一次