跳转至

Gavriel Cohen（NanoClaw）：自主工作 agent 的蓝图——第二大脑、隔离安全模型与 LLM Wiki（Latent Space，2026-06-29）

说话人映射（据补做分离的 speakers.md；转录稿本身无标签，此处认人属 wiki 层编辑判断）： SPEAKER_00 = Gavriel Cohen（嘉宾，78.8%）、SPEAKER_01 = swyx（主持，21.2%）。 依据：本期只有 swyx 一位主持（页头）；SPEAKER_00 的高纯度块是 NanoClaw 一手设计与客户落地（[00:08:06] 改用 Agent SDK、[00:17:10] 帮客户对接 IT/安全团队，均 100%）。

概要

NanoClaw 是 OpenClaw 之后又一个爆红的开源个人 agent，主打极简代码库 + 隐私/安全。Gavriel 讲了新加坡外长在 Facebook 晒自己的 NanoClaw setup（Raspberry Pi + Karpathy LLM Wiki + Nemon 记忆系统）如何点醒他"企业引入 agent 的正确起点是先给每个人一个个人 agent"、NanoClaw 相对 OpenClaw 的安全隔离设计、以及公司化后为企业做部署的方向。这期与本库直接相关——外长的 setup 正是 Karpathy 的 LLM Wiki 模式（也即本库范式）。

核心观点

企业引入 agent：先给每人一个个人 agent

  • 两条并行路线：agent factory（团队协作造/管一批自动化 workflow 的 agent）vs 个人 agent（work setting 里每人一个助手）。外长的用例让他确信先从"给每人一个 agent"起步——因为"怎么和 agent 工作"有陡峭学习曲线（提示、建 skill、调 context window），最大误区是"扔个任务就走开等成品"（[00:03:04]–[00:05:04]）。
  • 今天 claw 类 agent 的杀手级用例是"第二大脑"：不断喂信息、不指望现成产出，而是让它建内部记忆/知识图谱/"你的 LLM Wiki"，之后给有用输出（[00:05:04]–[00:06:05]）。

安全隔离模型（相对 OpenClaw 的核心改进）

  • 不 fork OpenClaw、从零重写极简代码库；用 Agent SDK（自带 session 管理/compaction）而非 Pi（OpenClaw 用 Pi、需自建很多东西）、集成 Vercel Chat SDK 接各消息渠道、初期只支持一个模型一个 agent（[00:07:05]–[00:08:06]）。
  • 三层隔离（最大差异化）：
  • 每个 agent 跑在独立 container（与 messaging bridge、router 分开）；
  • agent 环境里不放任何凭证——即便被 prompt injection 也无法泄露 API key（"审 PR 时任何人都能开 PR 灌入未净化输入"）；
  • 所有出站请求经 vault 代理按访问策略注入凭证，并有 human-in-the-loop 审批（如可读邮件免批、发邮件要在 Slack 点 approve/reject）（[00:08:06]–[00:10:07]）。
  • 他曾用 OpenClaw 管销售 pipeline，两天就做了"销售经理的活"，但代码库大、依赖多、明文记录所有消息让他不敢用于生产（[00:06:05]–[00:07:05]）。多位安全专家审过 NanoClaw，"没人指出核心思路的问题"（[00:14:09]）。

记忆：LLM Wiki 优于检索

  • 个人用的就是 LLM Wiki 式方案——把 agent 指向 Karpathy 的帖子照做；NanoClaw 内置简化版（指示 agent 把任何实质信息存成 markdown）（[00:11:07]–[00:12:08]）。
  • 检索/语义搜索不适合个人助手：问"这周最该关注什么"没有 embedding/关键词能答；但有好的 LLM Wiki（项目、时间线、本周通话 log）就能跨文件收集给出。已知痛点：会造重复文件、需背景进程定期查重（与本库 Lint 巡检同构）（[00:12:08]–[00:13:09]）。

公司化与开放问题

  • 早期采用者多是 VC/CEO/高管，"我搭好了 setup、想推给全团队但不想当那个修 agent 的 IT"→ NanoClaw Co. 做企业部署（10 人团队、100+ 公司接洽）；本质是"AI engineer 与客户 devops/安全/IT 的合作"（[00:14:09]–[00:17:10]）。
  • agent 不像传统企业软件"部署完 5 年不动"——底座（模型）在变，必须持续升级（4.6→4.8→4.9→5），每次升级都改变行为（[00:17:10]–[00:18:11]）。
  • 两个哲学问题：GitHub 会否被取代（开源被迫在 GitHub、闭源其实可全在 Slack 里 review→merge）；开源项目管理是最大挑战——coding agent 让开 PR 指数级变易、triage/review 跟不上，"不要给我 pull request，给我 prompt request"，一切需求/bug 汇入一个"未来开发的 wiki"作 buffer，开发时从 wiki 拉 context、完成后再推回 wiki（[00:18:11]–[00:22:15]）。

相关主题