{"id":"16179461","account":"mubei","brand":"@mubei","title":"AI Agent 最大的问题在于记性不好。 一旦中途卡顿、Token 爆了或者网络断一下，它就彻底忘了自己刚才干到哪一步…","summary":"AI Agent 最大的问题在于记性不好。 一旦中途卡顿、Token 爆了或者网络断一下，它就彻底忘了自己刚才干到哪一步了。 现在的 AI 编程助理，写个 10 行的脚本很溜。 但要让它去重构一个复杂项目，让它跑个两小时的长循环，大概率会半路夭折。 为什么？ 因为它们把所有的执行…","body":"AI Agent 最大的问题在于记性不好。\n\n一旦中途卡顿、Token 爆了或者网络断一下，它就彻底忘了自己刚才干到哪一步了。\n\n现在的 AI 编程助理，写个 10 行的脚本很溜。\n但要让它去重构一个复杂项目，让它跑个两小时的长循环，大概率会半路夭折。\n为什么？\n因为它们把所有的执行状态、预算和上下文，都存在了脆弱的临时内存里。\n只要一中断，之前花掉的 Token 和时间全部打水漂。\n\n刚发布的 sous-chef 0.3.0，就是奔着解决这个痛点去的。\n它的做法是：\n编排器（Orchestrator）停止信任临时记忆，将一切“落盘”。\n\n预算记录、审查结果、循环状态，统统实时写进磁盘。\n这意味着，哪怕任务中途断掉、或者因为超限被压缩，它也能像下载软件一样，实现“断点续传”。\n\n看它的设计图，逻辑非常清晰，是一个典型的“主厨 + 帮厨”架构：\n\n主厨（Fable 5）：负责规划、分发任务、审查和重新跑 Check。\n帮厨（Codex / GLM）：只管埋头切菜，也就是写代码。\n\n这里面有一个软件工程的铁律：干活的人，永远不能自己给自己改作业（The worker never grades its own homework）。\n帮厨把代码写完，必须由主厨去对比 Diff、跑测试、验证发现的问题，最后主厨来拍板。\n\n这才是从“玩具脚本”到“可用工作流”的分水岭。\n它没有跟风吹嘘“代替程序员”，选择老老实实解决长任务执行的工程稳定性。\n\n想折腾的可以研究一下：\nRepo 地址：github.com/fable-ai/sous-chef\n\n未来的 AI 编程，拼的是谁的工程架构更像一个严谨的开发团队，而非模型脑容量。","category":"其它","score":null,"percentile":null,"reason_tags":[],"translated_x_url":"https://x.com/i/status/2073563155293151467","translated_status_id":"2073563155293151467","published_at":"2026-07-04 23:06:57","created_at":"2026-07-05T01:00:17+02:00"}