Hearth

一句话定位

一个家庭共享的工作空间，家里人的计划、笔记、日程和成员都在里面， 一个 agent 能读懂这些上下文，还能就地写小程序跑起来。

做这个东西的人

jmtulloss（Jonathan Tullis，Retool 联合创始人）为自家建的。基于他们正在开发的 Playground 库——面向"协作式 AI 编码"的底层：同步文件、agents、人、应用代码 沙箱、策略层。Hearth 是家庭规模示例，同一套库还在做建筑施工项目产品 Bear （bear.build）。站点 ourhearth.ai。

判断：Retool 创始人做个人项目，最大的信号是他在验证"agent 自己写工具"这个 范式是否成立——家庭只是最小规模的试验场，施工项目才是商业目标。

它到底能做哪几件事

• 家庭共享工作空间 → 计划、笔记、日程、成员、周期性家庭仪式，同步到所有设备
• 上下文 agent → 能读懂上述所有内容并跨上下文工作，"像共享版 Obsidian 加了个 agent"
• agent 建应用 → 在家庭笔记之上生成小应用并在同一空间内运行，示例是日历和 旅行应用
• 工具即权限 → 接 IoT 设备用 API token 配代理，agent 可以调用设备而拿不到 token
• 多成员协同 → 全家共享同一份数据，集成对所有人可见
• 明确处于 beta，作者建议源码稳定开放前别放敏感内容，计划开源

它在替代什么旧行为

家庭事务分散在三四个工具里：群聊里的计划、各人手机里的日历、冰箱贴上的便签、 共享表格。信息碎片化，没人能一眼看到全家安排，同步全靠人肉。

Hearth 把计划、笔记、日程收进一个共享空间，再由 agent 消费这些上下文—— 这是"全家共用的第二个大脑"，替代的是"家庭信息散落各处 + 每次靠人肉同步"。 关键增量在 agent：它不只是存，而是在这个上下文里主动产出工具。

商业模式

未披露定价。 beta 阶段，计划开源。公司层面在推进同一技术栈的 Bear（建筑施工）， 家庭产品目前没有任何商业模式信息。

判断：家庭场景基本不可能是主收入，Hearth 更像是 Playground 库的活广告。 真正的商业逻辑要看 Bear——把"agent 自己建工具"卖给施工方，是建筑行业 数字化的老故事换新引擎。

硬数字

• HN Show HN 8 分 / 3 评论（2026-08-13），traction 很小
• 未开源：源码未放出，暂无 star/fork 数据
• 已有 Home Assistant 应用示例在 github.com/bearbuild/hearth-apps
• 用户数、定价：未披露

四维评估

判断

值得记住的是一句话：agent 应该在它读得懂上下文的地方自己造工具。 现在多数 agent 产品的边界是"在固定工具集里选工具"，Hearth 的方向是 agent 直接 在用户数据之上生成自己的工具和 UI。这是 agent 应用的下一层抽象，家庭、公司、 工地只是三种不同的数据场景。

但 8 分和 3 条评论说明它没有离开作者的自留地。 全文只有一个承诺和一个 试验场：承诺是"源码快开源了"，试验场是作者自家。最诚实的证据反而是那句 "源码稳定前别放敏感内容"——作者自己都不确定现在的隔离设计扛得住。

家庭这个场景选得巧但不赚钱。 选家庭是因为上下文密度高、隐私边界真实、 非技术人员使用，是最小且最完整的测试环境。但消费者不会为"agent 给我造个 日历应用"付费——他们连概念都难理解。商业故事在 Bear，不在 Hearth。

工具即权限这个细节值得单独记一笔。 用 API token 配代理让 agent 调用设备 而接触不到 token，是 agent 权限设计里少见的干净做法。

下一步看什么

① 源码是否按承诺开源——不开源就是营销稿 ② "agent 建的应用"在真实家庭里的留存——作者说过全家在用，但没有任何数据 ③ Bear（施工版）是否公开价格与客户——那才是商业真相

可借鉴的做法

产品逻辑："agent 自己写工具再用工具"是 agent 应用的下一层抽象。如果你做 agent 产品，把"让 agent 在用户数据之上生成自己的 UI/工具"当作能力而不是功能， 家庭、公司、工地只是三种不同数据场景。最小测试环境要满足：上下文密度高、 隐私边界真实、用户不要求技术能力。

定价结构：无。未披露。

结论

有待观察。 概念亮、来源可信，但 8 分 traction、未开源、无定价，全部承诺都 指向"未来"。用三条指标等它兑现。