SOTA Sync
全部文章
Agent 设计2026-06-11

AI 操作系统的 Four Cs 框架——如何用 Fable 搭一套工具无关的第二大脑

Nate Herk 把 Claude Fable 接入自己用了数月的 AI 操作系统，提出 Four Cs（Context / Connections / Capabilities / Cadence）作为搭建框架。前两层是第二大脑，后两层是真正的工作系统。

AI 操作系统的 Four Cs 框架——如何用 Fable 搭一套工具无关的第二大脑

Nate Herk 是一个 AI 自动化创业者，过去几个月一直在搭建自己的「AI 操作系统」。Claude Fable 上线当天，他没有急着冲进去，而是花了一整天把 Fable 接进已有的系统里，看它能在多大程度上替代、补充、补强他已经在用的能力。

这篇不是 Fable 评测，是一份已经跑通数月的 AI OS 搭建实录，骨架是 Four Cs 框架。

#先说 Fable 是什么

Fable 本质上是 Claude Mythos 5.0 的加强版——底层还是 Mythos，但额外加了一层网络安全护栏。

Mythos 是 Anthropic 一直在打磨的下一代模型，强到目前没有对外公开，只对 Project Glasswing 的网络安全和基础设施合作方开放。Fable 等于是把它从受限渠道释放出来，但多了一层 cyber safeguard。

两件事需要提前知道：

第一，Fable 只在 6 月 9 日到 6 月 22 日之间走订阅制，过了这个窗口就改成按 usage credits 结算。两周内想试就趁早。

第二，价格是 Opus 的两倍。输入 10/百万tokens，输出10 / 百万 tokens，输出 50 / 百万 tokens，吃订阅配额的速度明显比 Opus 快——这一点会在后续使用体验里反复出现。

#操作系统从默认值开始，不从架构开始

很多人刚开始搭建 AI OS 会想先画架构图：选什么模型、用什么 harness、怎么拆 agent。Nate 的顺序恰好相反。

第一步是关掉所有其他 AI 工具。不同的订阅、不同的 Custom GPT、不同的 project 全部关掉，强制自己只用一个 harness——Claude Code、Codex、或者任何你愿意长期用的那个。

关掉之后做一件事：在那个唯一的 harness 里把所有事情都做一遍。一周下来，你会发现 context、memory、preferences 已经在累积了。

操作系统不是从架构开始的，是从默认值开始的。

然后才是分层思考。第二大脑是第一层，没有它就没有操作系统。第二大脑回答的问题是：这个工具知不知道我的生意、生活、客户、YouTube 频道在发生什么？我能不能直接问它这些问题？

有了第二大脑之后，再在它上面建操作系统：skills、automations、真正从这个系统出发工作，而不是从 Apple 或 Windows 出发。

#Four Cs：搭建顺序

搭建和维护 AI OS 用的是 Four Cs 框架，顺序不能颠倒：

  1. Context ——你是谁，你的业务是谁
  2. Connections ——第二大脑能不能拿到活的实时数据，不只是静态笔记
  3. Capabilities ——你构建的 skills、agents、automations、pipelines
  4. Cadence ——让上面的能力自己跑起来，你睡觉时它也在工作

前两层是第二大脑。后两层才是操作系统。

这个顺序本身就是教学内容。即使你已经搭好了自己的系统，你仍然要按这个顺序去教团队，或者去给企业客户做 OS 交付——它是标准框架。

#Context：你的路由树

Context 的本质是一棵路由树。在 Claude Code 里，这棵树通常以 CLAUDE.md（或等价的 claude.md）作为入口。

这个文件里会有少量目标和流程的定义，但主体是路由——告诉 agent 规则在哪、参考在哪、skills 在哪、其他 project 在哪、wiki 在哪。对知识库来说，给它精确的 wiki 路径、热缓存、主索引，以及遍历方式。

常被问到的问题：context 多少算太多？什么时候该拆？

目前 Nate 的答案：还没到上限，因为找东西很快。他在盯着一个简单信号——如果他问一个他自己知道在哪的文件，agent 花了五分钟去找，那就是架构需要更新的信号。

Nate 提出一个概念叫 architecture engineering ——继 context engineering、prompt engineering、harness engineering 之后的下一个手艺。没有标准答案，他的体检方法是：对我来说是不是直觉？手动能钻进文件夹找到东西吗？agent 也能吗？

有一个最近的小调整被很多人问到：他建了一个叫「Other Worlds」的文件夹，把以前在完全独立 repo 里打开的其他 Claude Code 项目都搬进来。所有频繁使用的东西都合并进主项目 Herk-2：

  • 同步 ：主项目推到 GitHub，拉到笔记本，所有东西跟着走，不需要切换机器前推六个 project
  • 可达性 ：主操作系统能拿到 book project、website、video edits、token dashboard 的 context，可以 CD 进去找需要的东西

合并的体量不算小。光是 YouTube OS 就有 projects、references、transcripts 三层，带深度钻取。

即便如此，在主目录跑 /context，启动时也只有大约 40,000 tokens——大部分是系统工具和少量 memory。Markdown 文件短期内不会是瓶颈。

没有标准答案，但有两个预警信号：烧 token、agent 找东西找 20 分钟。否则你可以按自己的偏好编排架构，只要路径直觉、agent 不浪费 token 就行。

#Connections：静态数据 vs 实时数据

有些数据是静态的：背景信息、会议记录、去年的进展和成绩。Connections 指的是持续变化的数据：ClickUp 上的团队消息、邮件、QuickBooks 上的 P&L。

定位自己的 connections 从第一梯队开始——每周都会打开的 app、Chrome 里的书签、跟人沟通的渠道（内部或外部）。这些高频的东西先拉进来。

如果想不出，可以按这个分类自查：revenue、customers、calendar、comms、tasks、meetings、knowledge。每个分类对应哪个工具？

对 Nate 来说，Skool 是 revenue 和 customers，YouTube 也是 customer 渠道，Stripe 和 QuickBooks 是 revenue，Google Workspace 是 calendar 和 comms，ClickUp 和 Slack 是 comms。

这些连接大多走 API key 和 endpoint。

这一层的体感检验很简单：如果现在打开 Claude Code 问它关于你和你的业务，回答听起来像一个陌生人，还是像一个队友？

#Fable 已经知道的——两个例子

第一个例子：跑 /goal，让 agent 看完 project，搞清楚它对 Nate 本人、YouTube 频道、生意知道多少，然后做一个视频，用 hyperframes 形式讲他走过的路。

它给出来的画像是准确的：Nate Herk、AI 自动化、芝加哥创业者、creator、dog dad。教普通人用 AI 搭建东西。2024 年发了 41 个视频，2025 年 261 个。免费 8 小时课程播放量超 150 万。YouTube → AIS free → AIS paid → 高客单教练 的飞轮。Uppit AI 是核心公司，13 人团队，覆盖所有 ventures。今年从 n8n 转向 Claude Code，任务不变，工具更锐利。

有一个细节错了——它说 62 万订阅，实际接近 80 万。这是静态数据问题，它用的是最近一次刷新的数字。如果让 agent 实时拉 YouTube 数据，会立刻更新到正确值。这一点值得说清楚：静态 vs 实时连接之间是真实存在的权衡。

整个视频从一个 prompt 来。

代价是 Fable 不便宜。第一次压力测试时，他 $200/月的 max plan 五小时配额，在一个多小时里烧完了。它吃配额的速度明显快于 Opus，小心使用。

第二个例子，同样是 /goal 的一次性 prompt，跑了 21 分钟。任务是：把所有 transcripts 和它们之间的关联整理成一个清爽的、任何人都能点击浏览的界面。

它真的搭了一个前端出来，分类包含 ideas、tools and harnesses、techniques。点进去能看到真实的关联：Agentic Workflows 接进 Context Windows，Claude Code 连到 Codex、Open Claw、Hermes Agent，几乎所有东西都能找到。甚至标出了每个概念出现在哪些视频里。顶部加了「我是新手」「我搭东西」「我做生意」三个入口档位。

要做到这些，agent 必须自己构建 UI、读真实 transcripts、绘制真实关联、考虑用户旅程。一个 prompt 做到这些，相当惊人。

绝大部分情况下 Nate 不用数据库，是 markdown 文件加上 Karpathy 的 LLM wiki 思路，用 Obsidian 管理。

关于模型本身：benchmark 不是最好的评判方式，harness 和使用方式更关键，很大程度上是体感。Karpathy 的评价很准确——可以给 Fable 远超你以往习惯的任务，模型「get it」。这跟 Nate 的体验一致：Fable 更能理解他想做什么。

但 Fable 也有粗糙的地方。有时候慢，有时候 cyber safeguard 该响不该响，跟你说这个做不了。护栏在发布期过于敏感是正常的，社区反馈多了会调。

#Capabilities：Skills、Agents、装配线

Context 和 Connections 有了，Capabilities 才是真正能做的事。

这是另一个 adoption test：你能默认在 AI OS 里完成工作，而不是打开一个 Chrome 标签？发那封邮件、拉那个报告之前，能不能先打开 VS Code？

接入一个工具的时候，先检查有没有 API endpoint——有就抓住它。CLI？也抓住。Nate 偏好 CLI 和 API 而非 MCP server，因为控制更多、通常更便宜，但 MCP 也行。

Skills 不一定要是十步怪兽。一个 skill 可以就是一个 prompt。每周一早上、每周五晚上写同样的东西，就把它做成 skill。在 Claude Code 里头脑风暴出好东西，告诉它把这个变成 skill，下周就更快。

Skill 第一次不会完美，这是重点。每用一次就是一次数据。告诉它哪里好、哪里不好、更新它、再跑。Nate 有 20 多个本地 skill 加一堆全局 skill，每次用都反馈，告诉它更新 skill。一个四个月前做的 generate-image skill 还在改——因为偏好、模型、endpoint 都变。没有 finished product。

Nate 用装配线思维，回到 n8n 时代就是一个 AI 做一件事做到位。一个做轮子，一个做车轴，一个做车壳，最后拼起来。

所有事塞进一个 session 会模糊、会撞上 context rot。Nate 的做法是分阶段：起一个 agent 去研究 X，拿到输出，/clear，引入 draft，再走一轮精修。把产出链通过专用 agent 串起来。

并行任务委托出去。Fable 价格高，并行任务推给 Sonnet 或 Haiku 这些便宜 worker，最后拿一个干净的汇总回来——这就是 dynamic workflow 的核心模式。

#Cadence：挣到自动化的权利

Cadence 是你睡觉时也在跑的东西，也是你必须挣到的步骤。

挣到的方式是证明 skills 已经 battle-tested，找到对的 use case。因为加更多 AI = 成本更高、风险更高、维护更多。自动化不等于甩手——仍然需要可见性，仍然要 check in，仍然要有人 owner。

触发方式分三类：

  • Manual ——你主动调用，可以留在 AI OS 里
  • Event ——新邮件、新客户预约电话，触发一个流程
  • Schedule ——每周一、每周日晚上

部署方式全开放：Claude Code routines、loops、Modal 上的确定性脚本、让你的 Claude OS 自己搭一个 n8n 自动化再推回 n8n。选适合你的。

但有一个不能跳过的部分：prompt 永远不是 permission layer 。

假设它能做到，它就会做。如果它能发邮件，它可能会。如果它能读那个数据库，它就会读。

Nate 团队在这件事上摔过一次。一个 agent 从任务列表里主动拿了一个任务，理解错了，决定需要写一个折扣码，然后把它发给了 15 万到 20 万人。一个本来不该发出去的码。后来只能发道歉信。

他没有怪搭这个流程的人。把它做成了 case study，让整个团队理解风险和如何安全工作。几乎需要这次教训才能真正学进去。

修复方式是 keys, not prompts 。如果一个 agent 没有能进那个房间发邮件的 key，它物理上发不出去。这是可以真正信任的 permission layer。然后再修指令，确保不再发生，继续 loop。每一次滑倒都是数据，不是失败。

#三个使用 tips

  1. 当思想伙伴用，但要带怀疑 。不要问怎么做、拿答案、就说 go。跟它头脑风暴，让它做 devil's advocate，自己也做。起 sub-agents 给不同视角。Nate 喜欢让 sub-agents 或 agent 团队互相辩论，自己基于直觉做更 informed 的判断。这些模型仍然偏讨好，会想取悦你，记着这点。

  2. 让它采访你 。Nate 用一个叫 Grill Me 的 skill——最初来自 Matt Pocock，他改了一下用来写 brainstorm 文档。它会问他 15、25、30 个问题，把脑子里的知识拉进 OS。可以直接告诉一个全新 setup：用 Grill Me 把关于我业务的所有东西都学会。Nate 今天跑了一次用来规划整个视频。

  3. 让它 verify 自己的工作 。这是最重要的一点。在那个 relationship-map 构建里，Nate 告诉它这是 YouTube 的 demo，不需要 production ready，只要好懂，然后用一个 dynamic workflow 去验证所有东西准确、工作。让它视觉检查结果，测试新手、软件工程师、生意 owner 三类人能不能都点得通。打开 Playwright 浏览器点点看。你怎么 verify 实习生的工作，就给 Claude Code 同样的能力——这是 70% 一次过和 92% 一次过的区别。

#它只是文件夹和文件

模型和 harness 只是引擎。系统是你在搭建的。

归根到底，这一切都是文件夹和文件。所以你明天切到 Codex、切回 Sonnet 4.5，无所谓。每个 coding agent 都能用它。

这就是为什么 Nate 同时维护 .claude、.codex、.agents，加上 claude.md 和 agents.md。他想让这件事尽可能 tool agnostic。同时也日常用 Codex 跑，看看哪个更好。

你不是学 Claude Code 或学 Codex——你是同时学一切，因为你搭的是自己的可复用 IP。Folders 和 markdown files、skills 和 routing logic、logs 和 wikis。不是 Claude Code 的 AI OS，是你自己的个人操作系统。

这应该能减轻追新模型的压力。某一天你可能跑自己的 harness 在开源模型上，不需要技术背景，它就这么发生了。

#闪电问答

  • 全天跑要花多少？ 看情况。Nate 做知识工作，不是重 coding，$200/月 plan。很少撞五小时上限，偶尔撞每周上限。
  • 数据去哪？ Claude 模型是去 Anthropic。闭源，处理敏感数据多的话可能不想用闭源模型。
  • 要会写代码吗？ 不需要。
  • 第一天、空文件夹、第一步？ 用 Nate 在免费 Skool 社区里放的 AIS OS GitHub repo，跟着走一天就跑起来。
  • 它自信地错了怎么办？ Check 工作，然后告诉它更新 CLAUDE.md 和 skills，确保下次不再发生。永远让它给你数据的精确信源。
  • 实时连接怎么工作？ API 或 CLI。查工具的 API 文档，交给 Claude Code 或者让它自己研究，告诉它精确的 endpoint。用 scoped API key——一个 key 只能读会议记录，不能编辑或删除任何东西。Keys, not prompts。
  • 如果我几周不管它？ 没什么大事。同步数据回去就行。
  • 团队每个人都搭自己的吗？ 是的，但先自己学会再去教。决定共享知识住在哪（ClickUp、Slack、Notion、Drive），给所有人只读权限。最差情况是所有人重复造知识和活，真正的瓶颈永远是 adoption。

#收尾

你不是搭一个 Claude Code AI OS。你是搭自己的第二大脑，在文件夹和文件里，任何模型都能插进去。