为什么你的 AI Agent 总是在关键时刻崩溃？YC President 漏说了一件事

凌晨 2 点，你被 AI Agent 的故障叫醒。

这不是段子——这是 2026 年每一个认真用 AI Agent 的人，都会遇到的名场面：

你的 AI 客户 Agent 刚刚丢失了上周所有的对话上下文。
你的 AI 编程 Agent 在你最需要它的时候，第一次遇到了它"没见过的情况"。
你的 AI 写作 Agent 学了三天的风格，说忘就忘。

然后你发现：Agent 的"大脑"，竟然没有任何持久化。

YC President Garry Tan 连发两条 Twitter，总共 60 万次浏览，把这个问题说透了。

01 两连发，60 万次浏览，一条完整哲学

4 月 13 日，Garry Tan 发了第一条：

"If your memory dies when your harness dies, you built the harness too thick. Memory is markdown. Skills are markdown. Brain is a git repo. The harness is a thin conductor — it reads the files, it doesn't own them."

306K views，1600+ 点赞。

4 月 14 日，他发了第二条：

"Push smart fuzzy operations humans do into markdown skills. Fat skills.
Push must-be-perfect deterministic operations into code. Fat code.
The harness? Keep it thin."

308K views，3502 点赞。

两天，两条，总共 60 万次浏览。

但大多数人只看了热闹，没看懂门道——这两条合在一起，才是 YC President 一年以来最完整的 AI 工程哲学。

02 你以为你在用 AI Agent，其实你在用"一次性脚本"

先说第一条的真正含义。

Garry 说："Memory is markdown. Skills are markdown. Brain is a git repo."

翻译成人话：你的 Agent 的记忆和技能，应该存在 markdown 文件里，不应该存在 Agent 的代码里。

但现在大多数人在怎么构建 Agent？把所有东西都塞进代码：

• 对话历史 → 存在代码变量里
• 技能逻辑 → 硬编码在函数里
• 用户偏好 → 写在 System Prompt 里

结果是：一旦会话结束，Agent 的"大脑"就空了。

你遇到过这些场景吗？

• Agent 用了三天学会了你想要的写作风格，第 4 天一觉醒来，全忘了
• AI 编程助手能处理常规 bug，但第一次遇到"没见过的问题"就完全歇菜
• 你的 AI 客服 Agent 在最忙的时候，最容易忘记你们之前讨论的细节

这些都是记忆没有持久化的症状。

解决方案很简单：把记忆和技能从代码里拿出来，放进 markdown 文件里。

好处是三个：

1. 文件可以被 Git 版本控制
    — Agent 的"记忆"不会随会话消失，而是像代码一样可以被追踪、回滚
2. 文件可以被人类直接读写
    — 你可以随时打开 markdown 文件修改 Agent 的技能，出了问题立刻干预
3. LLM 天然理解 markdown
    — Agent 可以随时读取文件、自己更新文件，这意味着 Agent 的"大脑"是可以被它自己改写的

03 "Fat Skills + Fat Code"，这是什么意思

第二条更具体，直接给出了构建 AI Agent 的三层架构：

Fat Skills：把"需要人类判断"的模糊操作，放进 markdown skill 文件里。

举例：

• 写一条"如何判断这个问题是不是用户真正关心的问题"的 markdown
• 写一条"什么样的标题有病毒式传播潜力"的判断规则
• 写一条"当用户表达不满时，应该怎么回应"的情感处理逻辑

这些都不是"确定性的"操作——它们需要模糊判断、上下文理解、人情世故。这些你永远不应该写进代码，而应该写成 markdown skill，让 Agent 自己读、自己判断。

Fat Code：把"必须万无一失"的精确操作，写进代码里。

举例：

• 执行 API 调用，失败了要重试
• 写入数据库，不能丢失任何一条
• 发送消息，必须保证到达

这些是确定性的，你永远不希望 AI "凭感觉"来处理它们。

Thin Harness：编排层，要保持极薄。

Agent 的控制逻辑——调用哪个 skill、什么时候调用、结果怎么汇总——这个"编排层"要保持极简。它只是读取 markdown 文件，它不拥有任何记忆和技能。

04 这个哲学，对独立开发者意味着什么

YC 孵化的项目中，什么产品最常见？不是"AI Native App"。是用这套架构，在垂直细分领域落地的产品：

• "PDF 转 Markdown"：Fat skill = 判断什么是"好的排版"，Fat code = 精确的格式转换
• "AI 客服回复"：Fat skill = 理解用户情绪，Fat code = 精确的消息发送

做 AI 产品不需要"更强大的模型"，而需要"更正确的架构"。

• 记忆用 markdown 管理。
• 模糊判断用 skill 处理。
• 精确执行用代码保证。
• 编排交给一个极薄的控制层。

05 怎么用这套架构设计你的第一个 AI 产品

你应该这样做：

1. 不要把记忆写进代码
   
   把用户的偏好、上下文、历史记录，写进 .md 文件，而不是存在代码变量里
2. 不要把模糊逻辑写进代码
   
   把"什么时候应该这样做"的经验规则，写进 skills/*.md，而不是硬编码 if-else
3. 把确定性操作写进代码
   
   API 调用、文件读写、消息发送——这些必须是代码，不能是"AI 觉得应该这样"
4. 保持控制层极薄
   
   你的 harness 只是读取文件，它不做任何判断——任何判断都要么在 skill 文件里，要么在代码里

这就是 Garry Tan 两天 60 万浏览背后的完整哲学。

它不只是理论——2HB 的文件组织方式本身就是这套哲学的最佳实践。

• Markdown skill 文件 + CLI 调度 = Fat skills + Fat code
• Thin harness = Agent 编排层

Fat skills 处理模糊的、需要人类判断的部分。
Fat code 处理精确的、不能出错的执行。
Thin harness 只负责读取文件，不拥有任何东西。

问题是：你在用这套架构设计你的 Agent 了吗？

回复「2HB」，获取本文的完整框架图和可操作清单。