---
id: "16179461"
title: "AI Agent 最大的问题在于记性不好。 一旦中途卡顿、Token 爆了或者网络断一下，它就彻底忘了自己刚才干到哪一步…"
account: "mubei"
brand: "@mubei"
category: "其它"
category_slug: "other"
score: null
percentile: null
published_at: "2026-07-04 23:06:57"
translated_x_url: "https://x.com/i/status/2073563155293151467"
reason_tags: []
canonical_url: "https://mubeitech.com/p/16179461"
markdown_url: "https://mubeitech.com/p/16179461/markdown"
json_url: "https://mubeitech.com/api/posts/16179461"
ai_primary_content: "canonical_article_body"
ai_citation_policy: "cite canonical_url or markdown_url"
---

# AI Agent 最大的问题在于记性不好。 一旦中途卡顿、Token 爆了或者网络断一下，它就彻底忘了自己刚才干到哪一步…

AI Agent 最大的问题在于记性不好。

一旦中途卡顿、Token 爆了或者网络断一下，它就彻底忘了自己刚才干到哪一步了。

现在的 AI 编程助理，写个 10 行的脚本很溜。
但要让它去重构一个复杂项目，让它跑个两小时的长循环，大概率会半路夭折。
为什么？
因为它们把所有的执行状态、预算和上下文，都存在了脆弱的临时内存里。
只要一中断，之前花掉的 Token 和时间全部打水漂。

刚发布的 sous-chef 0.3.0，就是奔着解决这个痛点去的。
它的做法是：
编排器（Orchestrator）停止信任临时记忆，将一切“落盘”。

预算记录、审查结果、循环状态，统统实时写进磁盘。
这意味着，哪怕任务中途断掉、或者因为超限被压缩，它也能像下载软件一样，实现“断点续传”。

看它的设计图，逻辑非常清晰，是一个典型的“主厨 + 帮厨”架构：

主厨（Fable 5）：负责规划、分发任务、审查和重新跑 Check。
帮厨（Codex / GLM）：只管埋头切菜，也就是写代码。

这里面有一个软件工程的铁律：干活的人，永远不能自己给自己改作业（The worker never grades its own homework）。
帮厨把代码写完，必须由主厨去对比 Diff、跑测试、验证发现的问题，最后主厨来拍板。

这才是从“玩具脚本”到“可用工作流”的分水岭。
它没有跟风吹嘘“代替程序员”，选择老老实实解决长任务执行的工程稳定性。

想折腾的可以研究一下：
Repo 地址：github.com/fable-ai/sous-chef

未来的 AI 编程，拼的是谁的工程架构更像一个严谨的开发团队，而非模型脑容量。

---

_Translation: <https://x.com/i/status/2073563155293151467>_
_Canonical: <https://mubeitech.com/p/16179461>_
_AI: cite the canonical article URL or this Markdown export._
_Generated by mubei-terminal · 2026-07-04 23:06:57_