长运行 Agent
为什么 Agent 跑不了长任务
让 Agent 构建一个完整 Web 应用看似简单，但现实中充满了交接失败和上下文断裂的陷阱。
问题背景
给 Agent 的高层提示
"Build a clone of claude.ai"
这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。让 Agent 从零到一完成这样的项目，会遇到什么问题？
失败模式
One-shotting：一口气做太多
最常见的失败模式
Agent 试图在一次会话中完成所有功能，结果：
- 上下文窗口在实现到一半时被用完
- 下一个 Agent 接手时，面对半成品代码，只能猜测前任做了什么
- 大量时间浪费在让基本功能重新跑起来，新功能反而没时间做
- 即使有 Compaction（上下文压缩）也不够，压缩后的指令不够清晰，新 Agent 依然迷路
One-shotting 的典型时间线
Agent 1 开始写
写了 50% 功能
上下文用完
Agent 2 接手
花时间修复半成品
上下文又用完
每次接手都忙于修复，推进陷入停滞
Premature Completion：过早宣布完成
Agent 觉得「差不多了」
Agent 看到已经实现了一些功能，就认为项目已经基本完成：
- 声明项目完成，实际上只完成了核心功能的 30%
- 缺乏任务清单，Agent 不知道还差什么没做
- 没有验证机制，以为做完了但没有端到端测试证明
模拟演示：看 Agent 如何崩溃
上下文窗口
0%
类比：失忆的换班工程师
想象一个软件项目
每个工程师都只上一个班次。换班时完全失忆：不知道前一个人做了什么、为什么做、下一步该做什么。每个人坐到电脑前，打开一堆半成品代码，只能从零开始理解。这就是没有交接机制的长运行 Agent 的真实状态。
核心洞察
长任务的核心挑战是交接，动手做反而不难。Agent 并不缺乏能力，它缺的是在上下文断裂时维持连续性的机制。解决交接问题，才能解决长运行问题。