Cline、Kilo、Qwen Code 长任务上下文管理对比：谁更不容易「死循环」

近日，Reddit 社区 r/LocalLLaMA 上一位开发者对 Cline、Kilo 和 Qwen Code 三款主流 AI 编码代理在长任务场景下的上下文与状态管理策略做了横向对比。核心结论是：三者将任务进度（TODO 状态）的存放位置设计成截然不同的方案，在面对长时间、多文件编辑任务时表现差异明显。

三种 TODO 状态管理思路

Cline：使用 Focus Chain 机制，把进度信息以 Markdown 文件形式保存在对话之外，按节奏重新注入上下文；同时提供 Memory Bank 维护项目级上下文，并配备独立的 gRPC 服务器减少对 VS Code 的耦合。在三者中最为成熟，但文件与模型实际可见内容之间仍存在同步 Bug。
Kilo：TODO 状态直接以 XML 块嵌入对话历史，触发上下文压缩时会被压平为散文式摘要，代理常常需要重新读取源文件以定位断点，在接近上下文上限时容易陷入「读—分析—压缩」的无限循环。该项目正在迁移到 opencode 引擎，预期可改善此问题。
Qwen Code：TODO 状态写入独立的本地文件（~/.qwen/todos/），与对话完全隔离，无论压缩多少次都不会丢失。在连续运行 2–3 小时的长任务中表现最稳定。

钩子系统：更细粒度的执行控制

作者最终选择 Qwen Code 的关键原因在于其钩子（hooks）系统的灵活性。Qwen Code 暴露 PreToolUse、PostToolUse、Stop、UserPromptSubmit 等生命周期事件，每个钩子都可以执行命令、HTTP 请求或基于提示词的逻辑，并真正支持 allow/deny/ask 三种拦截结果，而不是仅做日志记录。相比之下，Cline 和 Kilo 主要依赖系统提示，缺少工具调用层的强制执行手段。配合 settings.json 中的自定义模型提供方和按工具粒度的权限规则，以及支持钩子的扩展清单，Qwen Code 成为唯一允许在不修改源码的情况下挂载执行策略的方案。

自研扩展 FocusMemory：补齐语义搜索缺口

在记忆与搜索层面，三者都缺少原生的语义代码搜索能力。作者为此开发了基于 MCP 协议的扩展 FocusMemory（仓库地址：github.com/edwardyoon/FocusMemory），并在之上叠加因果决策链追踪。该扩展利用 Qwen Code 的钩子在工具调用层做硬性约束：

PreToolUse 钩子：在调用 grep_search 或 glob 之前，必须先调用 search_memory，避免盲目扫全库。
Stop 钩子：在任务看起来结束时提示（而非强制）将关键决策写回记忆。

以「订阅等级」「用户徽章」这类横跨多个展示面的功能为例，单文件改动量小、跨文件关联多，单纯靠 grep/glob 难以理清数据流向，常常导致代理要么读遍整个仓库，要么修了 A 处却带崩 B 处。语义搜索 + 因果链追踪正是为这种场景设计。

局限与邀请

作者坦言，FocusMemory 目前为自托管、MIT 协议，主要在 Python/PHP/Node.js 技术栈上自测，边界场景覆盖有限。所谓「硬门禁」规则（何时强制调用 search_memory、何时提示写回）本质上是一套针对其个人工作流调优的启发式策略，泛化效果需要更多不同代码库的反馈来迭代。作者欢迎社区试用并报告门禁规则的误报、漏报与完成信号遗漏等问题。