Finch 是一款新出的，本地端小巧的通用智能体产品。 身边的朋友会很奇怪，如今智能体产品琳琅满目，各个身怀绝技。一个名不见经传的小公司，为何要做这样一个不靠谱的决定？
就像是电脑刚走入家庭的时代，AI刚刚走入大众视野。在各大活跃的社区，人们用不同的想法做出各种产品，让更多人看到创意。每个智能体的开发者，都迫切地想与大家分享自己的开发理念。
我与团队是在今年年初开始深度使用AI，全面拥抱AI编程。随着 OpenClaw 点燃了全民对智能体的热情，我们也希望让公司每位小伙伴能拥有一名数字员工。
从第一次在 Discord 上和自己的智能体对话，到线下分享时有用户问，
“能不能把你的个人助理也分享给我”
这些记忆依旧新鲜。用户的需求，并没有因为 OpenClaw 的热度消退而削减。
随着 OpenClaw 不断迭代，这个优秀的项目成为了开源社区的 Playground。如果要应用到商业场景上，那么需要面对大量的稳定性修复，以及避免特性变化带来的用户体验差异。
逐渐地，我意识到团队需要研发一款属于自己的智能体。无论是效率，或商业场景的探索。
对于 Finch，我并没有报以商业目标，它是团队能往更高攀登的垫脚石。在研发过程，也是对 AI 的一次自由探索。我相信在 AI 早期阶段，想法比目标重要。
如果非要填上几个理由，那么理由也非常简单
-
培养AI Native团队最好的做法，那就是做一款Agent产品
-
无论未来变化如何，我们都需要一个能灵活的Loop基座
-
通过做产品，掌握技术原理
关于Finch的设计
如果 AI 能快速做出的产品，那么这款产品是没价值的
这是我的合伙人讲过的一句，令我印象深刻。
拥抱 Vibe Coding 是没错的，能快速实现想法。但是对产品本身的深度思考，AI 永远无法取代人的设计与思考。
Finch 从 1.1.0 版本开始，并没有考虑如何快速做出成品，快速推出市场，快速赢得用户。
赢，不是我们的目标。就像《功夫女足》里说的：“踢球不是为了赢，踢球只是为了踢球”。如果能与更多踢球的朋友交流，那会更有趣。
为了能让大多数人也容易上手，Finch 定位是一款端产品。如果设计成服务端产品，那么门槛天然无法降低。如果是一个在线 Agent，也同样无法利用强大的个人电脑资源，从端架构开始设计目前最好的选择。就像手机无法取代电脑生产一样，云，亦可成为端的辅助。
事实证明是对的，目前 Finch 的用户里，有许多是对智能体了解不深，对个人助理有需求的用户，但是他们不知道如何用 CLI ，更不知道如何配置 JSON。
从架构开始思考
无论做任何产品，这个原则都是必要的。
如今各大基础模型，都会拿出看家的前端设计本领。而软件设计，是需要从架构开始思考的，不是从前端界面开始。记得没有 AI 的时代，我开发 PJBlog，头一年的时间，全花在学习如何 ASP 开发上，搭建后端服务。
不要轻易相信模型产商告诉你的评分，那只是对 Demo 的评价。做好一款产品所需要的细节，一样也没少。更不要相信前端已死这样的鬼话，技术架构师无法被 AI 取代。
也奉劝程序员朋友一句，别浪费时间在争论什么库好用上。
说回 Finch，前4个版本都是在完善端架构设计。每周都用 AI 重构一次架构，直到符合我的设计要求。
应该如何分离计算和渲染、应该如何为后续提供嵌入式、应该如何做好性能、应该如何分离模块。这些刚好是我过往的工作知识积累。
从第一个版本的 400M，一直迭代成如今的 130M 的包体，极端的 CPU loop 占用率从 70% 减少到 20%，都是为了让 Finch 足够轻量。不放过任何一个让资源占用增长的质疑。
当然，这些过程，如果没有 AI 的帮助，我想我们也无法在短短的 2 个月内达到一个满意的成品。反映了，每个人过去的经验，会被 AI 放大价值。为 Harness 提供了大量的问题角度。
Finch 是 Finch 自我演化出来的
自我演化，不做自动迭代。
当所有人都在追求用多 Agent，多 Skill 武装出一个自动化生产的 Agent 军团。我选择了笨拙的方式，监制。
每一次 Finch 完成的功能，都会被我不断质疑。为什么这么做？有更好的选择么？不断判断每一次Finch生成的设计与代码，我大量时间花在测试与产品体验上。
我发现，目前的 AI 能生成 70% 的代码，但是达到产品级的 30% 的细节，始终无法被 AI 直接解决。就算你用了大量优秀的 Design skills，如果缺乏对设计品质的要求与理解。那么，做出来的产品必然 AI 味。
感性，无法全用文字表达。
我又回到了过去，每一个像素对齐的年代。每一个图标应该如何表达意图，文字的间距如何令阅读更舒服，字体大小，字体选择，产品的色调应该如何定，如何设计每一个可复用的组件...
这一切无法用 skill 全部描述。就像一次在企业内训中，一位企业家提到，“知识只存在我们的脑袋里”。
直到现在，Finch 依旧坚持无 skill 开发。但是 Finch 会有坚持设计原则，对设计的约束。所有设计原则都是在过程中积累出来的——只有这样，才能做出极简与约束，并且规则在团队内是共享的。
Finch 项目里的 **AGENTS.md **已经超过 30k，每次会话都会注入开发场景的上下文。在这个规则中，索引的文档也超过 150 份。这些 md 文件，比 Finch 的 TS 代码还更具价值。记录了 Finch 全过程演化。
Finch 的自我演化过程中，它也在不断修正自己。应该如何迭代，多次与我讨论。渐渐地，Finch 长出了自己的编程底座——Codex、Claude Code 能做的事，它也能做到。拥有了用编程解决现实问题的能力。
如今，Finch 不再需要依赖外部编程工具，也能帮助你做出可以上架 Steam 的游戏，可以做出能直接发布的商用官网，做出金融报表...
你只需要选择你喜欢用的模型即可开始。
关于cowork
Finch 能做什么？
这是最近我遇到过最多的问题。但凡，第一次接触 Finch 的用户，必然会把 Finch 与 Codex， Work Buddy，Claude Code 比较。
很正常，如果没有这些工具的启发，Finch 可能做不出来。在技术领域这么多年，很久没遇到像 AI 时代这样令人兴奋的事情了。
如果要说 Finch 最大的短板，那就是小团队，还无法供给模型，也没推广经费。并且，Finch 也不打算迎合目前主流的需求，譬如如何快速做好一个PPT，快速做出一个汇报材料，这其实是重资源投入。并且，这些旧媒介，会随着AI发展，被 Markdown 和 HTML 取代。我想应该可以有更好的交互方式。
Finch 是为个体创意和创作而生。如果是为了创作，那么Finch不应该是一款用完即走的工具。
为了能更好地陪你实现想法，Finch 有一个有趣的设计：第一次启动后，会有一个破冰环节。
你和智能体就像第一次见面的朋友，需要相互认识——你要给 Finch 起一个名字，Finch 也要认识你、了解你的喜好。这是 Finch 第一件需要记住的事情。
名字会出现在应用的各个场景里。整个应用就是 Finch 智能体的化身、AI 能力的延展，让 AI 拥有与你「握手」和互动的能力。只有这样，它才能像电影《Her》里的智能体一样，成为你的个人助理——为你收邮件、为你创作程序、为你整理资料、提醒你日程。拥有名字的智能体，会以更自然的身份与人对话。
从某种角度看，Finch 本身就像一个拥有你记忆的养成游戏。
团队讨论最多的问题是，Finch应该如何定位。
关于这个问题，我一直无法给出明确答案，这样做并不符合商业直觉。但是从产品本身，Finch 不应该有过于明确的定义，应该以开放的方式来面对问题。
Finch 提供强大的Harness基座与开放能力，为不同场景准备好了Agent Loop。
我不能用过去的产品惯性来定义一款智能体产品。
如果你愿意，你可以把Finch安装到一台空白的电脑里，让它自己写出各种各样的应用。试问应该如何定义？
在Finch里，你是找不到Cowork或Coding的入口的，因为没必要。
你只需要创建一个工作空间即可。至于你在各个工作空间里，做编程，还是做深度调研，由你决定。
每一个空间都可以有独立的对话规则和明确的要求。例如，你还可以把一个对话空间当做一个英语学习角，让智能体陪你一起学习英语。我之前用 Discord + OpenClaw 就是这样做的。
你不需要事先定义角色，只要用自然语言说出你的要求即可。如果你还是有定义角色的习惯，也没关系，用自然语言和 Finch 提出，“请创建一个运营身份的空间” 即可。
自然语言沟通，是 Finch 一直努力的方向。用户的评价也证明这些看不见的技术投入是正确的。
唯一明确区分的，只有对话。当你专注于创作的时候，对话只是用来做一些项目之外的临时沟通。
这样就够了。
第一次接触Agent的你，并不用学习 Finch 能做什么，不需要掌握 prompt 技巧。可以和 Finch 先聊聊，你想做什么？
关于轻量化设计
GUI 与 程序应该成为AI的延伸
轻量化设计，是 Finch 从一开始的坚持。
这一点得感谢有 AI，它让小团队在架构选型上，可以减少对开源的依赖。如今的开源项目动辄引入大量依赖包，这些依赖并不会马上用到你的项目里，却会成为 App 的负担。
Finch 使用的开源组件非常克制。在 Agent Loop 方面，只用了 Pi 这个超级轻量的组件。非常感谢 Pi 团队对 Agent Harness 的极简设计，它也启发了 Finch 的轻量化思路。
Finch 没有内置 MCP（仅作为小工具），也不做 ACP，甚至连多 Agent 功能也没打算内置。
我认为，用一个 App 去控制多个 Agent 工作，这件事情本身就挺奇怪的。原因在于，这些优秀的 Agent App 或 CLI 都和模型做了深度绑定，开发者也没办法。要做好一个编程工具，不是一件容易的事。
参考 Pi 的设计，Finch 的内核同样极简，只有 4 个工具，负责文件的增，删，改，查。作为一个操作系统，基础的文件操作必须强大，且对用户无感，这也是 Finch Core 的关键。并且，Finch 的内核可随时插拔，与界面端彻底解耦——即使客户端卡死，Loop 的工作也不会中断。
你随时可以离开电脑。工作完成后，它就像一位微信好友，替你留好新消息，静静等你回来。
当然，你也可以试试 Finch 工具箱里的桌面宠物小工具，提醒会更有趣——它是我们的开发同学，在工作之余，用小工具能力自己设计的。
轻量化，需要克制和做大量的减法。
与其他 Harness Agent 不同。Finch 不靠各种先进功能武装自己，功能过多使得我们精力分散，无法一层一层把基础能力积累厚实。Finch 有大量功能实现后，又被删减掉了。如果没有 AI，删减功能的做法，开发会从情感上有所不舍。
在延展性方面，Finch 通过小工具验证了一个设计理念。为 AI 开放 GUI 标准和程序。在有限的设计规则中，AI 能为你提供更好的人机交互。这是Finch小工具给我们带来的新的灵感。
Finch 小工具是一种可插拔的程序设计，就像微信的小程序或VSCode的扩展。
客户端不需要频繁发版，通过小工具就能延展各种各样 Finch 的功能：桌面宠物、Todo list、站点编辑器等等，甚至我没想过还能与过去做的开源项目 PJBlog，做一次 20 年后的联动，用更少的代码实现了博客的编辑与发布。
开发者不需要自己折腾 Loop，这样做能极大程度保持 Finch 本身的轻量化设计，和发挥创意。
做小工具，是无意而为之的设计。对于智能体本应该如此，我是没想到这样的设计，在没做出来之前，我们都想不到应该可以怎么用。
以团队最喜欢的 Todo list 小工具为例，它能在跨 session 的对话中，快速记下待办和进行中的事项。
深度使用 Agent 编程的朋友，一定遇到过这样的痛点：多个 Agent 同时工作时，随时冒出来的想法和需求，总找不到一个地方快速记录。Todo list 小工具无意中解决了它——记录与会话联动，体验无缝。
类似的小工具，在 Finch 的小工具社区里还有不少，Git 小工具、宠物小工具、计划小工具，都基于 Finch 的开放能力实现。这里也特别感谢，我们用户提的宝贵建议，小工具这个名字是用户起的。
如今绝大多数的 Agent ，都在做极端的 skill 推荐，做 skill 的自进化。而 Finch 选择了一条老路。
我的朋友还和我说，
“这样做，不是开倒车了么？”
而我并不那么认为，反而是在用户的视角上看，枯萎技术更有机会创造出新的价值。
事实证明，把确定的事情交给程序，不确定的事情交给 LLM。Finch 顺手解决了金融场景或企业场景里对数据隐私安全的需求，还节约了 token。
小工具可以通过程序提前处理需要加密的信息，AI 来处理；可以识别 OCR，不需要 AI 在你电脑里找各种工具；还能安全收集你的密钥，经过程序加解密，不用经过 LLM。
为此，我们还搭建了 Finch 的社区站点，放在GitHub上。为开发者提供了，小工具的各种案例。
https://github.com/finchtoys/finch-releases
结语
如今，Finch 如期交出了第一个对外发布的版本，让更多用户能体验到这款有温度的智能体产品。我们希望你能真正拥有一个陪你创作、陪你学习的智能体，而不是把时间浪费在学习大量新技术概念上。
就像 Finch 官网上写的：“好工具应该让人忘记工具本身，只专注于创造。”
为此，Finch 团队非常感谢每一位早期的种子用户——没有你们的反馈，Finch 不会长成今天的样子。这一路走来，Finch 以一种 “无目标” 的方式向前探索，不以赢为目的。只因喜欢而设计，才能遇见许多无法规划的惊喜——这大概就是一款“没有 AI 味”的应用，该有的样子。
好了，如果你感兴趣体验一下这款新出的智能体工具，那么欢迎下载。如果你觉得不好用，也没关系。这都是我们持续改进的动力。
用心做一款让大家喜欢的产品。
Finch 官网：
Finch 小工具案例站：
https://github.com/finchtoys/finch-releases
本文首发于 RoboAge：https://www.roboage.net/thread/finch-ai-ai-mrxispb1
评论