为什么 Agent 跑不了长任务
一口气做太多、做完就收工，两种典型失败模式
本页解决的问题
先给结论「为什么 Agent 跑不了长任务」要解决的关键问题是什么？
一口气做太多、做完就收工，两种典型失败模式
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。让 Agent 从零到一完成这样的项目，会遇到什么问题？
Agent 试图在一次会话中完成所有功能，结果：
- 上下文窗口在实现到一半时被用完
- 下一个 Agent 接手时，面对半成品代码，只能猜测前任做了什么
- 大量时间浪费在让基本功能重新跑起来，新功能反而没时间做
- 即使有 Compaction（上下文压缩）也不够，压缩后的指令不够清晰，新 Agent 依然迷路
Agent 看到已经实现了一些功能，就认为项目已经基本完成：
- 声明项目完成，实际上只完成了核心功能的 30%
- 缺乏任务清单，Agent 不知道还差什么没做
- 没有验证机制，以为做完了但没有端到端测试证明
「问题背景」如何改变一次回答
「这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。」说明，模型处理的不是我们眼中的“字数”，而是一段段 Token。Token 的切分方式会影响输入长度、上下文能放下多少内容，以及一次请求要花多少计算。
长度、信息量和上下文不是一回事
当「这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。」变长时，先要分清三件事：文字被切成多少 Token、哪些内容真正参与当前判断、以及旧内容是否已经超出上下文窗口。删掉重复说明通常比单纯把窗口开得更大更有效。
- 下一个 Agent 接手时，面对半成品代码，只能 猜测 前任做了什么
- 大量时间浪费在让基本功能 重新跑起来 ，新功能反而没时间做
- 即使有 Compaction（上下文压缩）也不够，压缩后的指令 不够清晰 ，新 Agent 依然迷路
先保留会改变判断的内容
可以用「这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。」做一次对照：保留同样的问题，分别删掉重复背景、压缩格式和移除无关历史，比较答案质量、延迟与 Token 数量。
从「问题背景」走到「失败模式」
「问题背景」先把问题落在「这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。 让 Agent 从零到一完成这样的项目 ，会遇到什么问题」上；到了「失败模式」，讨论继续推进到「Agent 试图在一次会话中完成所有功能，结果」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
处理长文本时，先保留会改变结论的内容，再决定如何压缩格式和历史；上下文更长只有在新增信息真正有用时才值得付出代价。
- 「问题背景」：这不是一个小任务。一个完整的聊天应用需要认证系统、对话管理、流式输出、文件上传、Markdown 渲染、多轮历史…加起来可能有 200+ 个独立功能点。 让 Agent 从零到一完成这样的项目 ，会遇到什么问题
- 「失败模式」：Agent 试图在一次会话中完成所有功能，结果
- 「最后的要点」：缺乏任务清单，Agent 不知道 还差什么没做
最后的「最后的要点」把讨论落到「缺乏任务清单，Agent 不知道 还差什么没做」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。