Long-running Agents架构

Cursor和Claude Code的Long-running Agents的解决思路不一样。

Cursor的思路是：并行启动多个Agent来执行复杂长任务。

就像一个团队一样，解决复杂任务时，大家有不同的分工，所以可以投入成百上千个Agent并行工作。

难点是如何协调这些Agent。

Cursor的方案是扁平化这个团队，所有Agent的地位平等，通过访问一个共享文件来自我协调，每个Agent根据其同伴的实时状态来决定下一步该做什么。

比如，第一个Agent首先读取这个共享文件，查看其他同伴正在进行的任务。

然后，它从任务列表中领取一个尚未被执行的任务。

为了防止其他Agent同时认领该任务，引入锁机制。当任务完成后，会更新共享文件中的状态，释放锁。

但这个方案的关键在于锁的控制，有的任务可能过长，导致锁的时间过长。有的任务执行完成之后忘记了释放锁。或者任务执行过程中，Agent崩溃，这个锁也没办法释放了，这些都会导致其他Agent排队，整个任务的吞吐效率骤降。

这里做过分布式系统的你肯定会发现，改成乐观锁和引入WAL、快照吧。

确实，乐观锁让Agent可以随时随地的读取共享文件的状态，不需等待。

一个Agent完成任务写入更新时，系统会检查自它上次读取依赖，状态文件是否被其他Agent修改过。如果没有被修改就更新成功，有被修改就更新失败。

Cursor发现这个扁平化架构过于扁平过于民主了，于是引入了规划者（Planner）、工作者（Worker）、裁判（Judge）角色。

经常看分布式系统源码的同学肯定对这种角色不陌生。

Planner：负责持续的分析代码库，理解项目需求，进而拆解任务，为特定的任务指派「子规划者」，让规划过程并行化。

Worker：是纯粹的执行者，从任务池中领取任务，并完成它，不需要与其他的Worker进行沟通和协同，他不关心项目全局，它只是专注的执行自己的任务，直到完成。

Judge：它像一个质量保证工程师，在每一个任务周期完成后，一个Judge Agent就会来评估当前进展，并决定是否继续开启下一轮迭代。

Cursor研究员总结，对于超长任务，模型选择至关重要，它们可以更好的指令遵循、保持专注、避免偏离，任务完成的更精准、完整。

一个好的Agent就是「高智力的模型+软件工程的取舍」，最好的系统往往比你想象的简单。

系统绝大部分的行为最终都会归结于我们如何写Prompt，通过Prompt让Agent高效协调、避免异常行为，这些Prompt需要大量的实验来优化，Prompt才是Agent的重中之重。

CC的思路是：单Agent中通过记忆连续性解决复杂任务的跨工作周期记忆。

CC团队认为，Agent之所以无法完成长任务，是因为上下文窗口长度有限，必须通过记忆做好上下文取舍。

他们关注的重点是，让Agent在跨越多个上下文窗口时，依然能持续推进任务。

比如一个Agent在执行复杂任务时，会试图一口憋个大的，结果功能写了一半，代码乱成一锅粥，下一个Agent进来看到半成品，只能干瞪眼。

出现这种现象的原因，是因为Agent不知道全局目标，也不知道该在哪里停下来，以及该给下一位留下点什么。

于是CC团队觉得应该让他们稍微协调一下，比如将复杂任务拆解为更小的、可跟踪、可验证的任务，制定清晰的交接机制，并严格验证任务结果。

比如在任务开始时，在提示词中明确任务的步骤和推进方式，每次会话Agent必须推进一小步，同时保持上下文干净（随时可以合并到主干分支、没有明显bug、代码文档清晰）。

干活的Agent被严格限定了行为模式，它遵循的的工作原则是渐进式的，每次只能做一个功能，比如先阅读日志文件和git提交记录，快速了解项目当前状态。

在明确的功能清单中，选择一个优先级高的、尚未完成的任务来执行，不允许同时做多个任务。

完成功能之后，必须对所有修改的代码建立清晰的描述和git提交信息，提交到代码仓库，同时在日志文件中追加新的工作摘要。

这个设计的巧妙之处在于，它把「记忆」外化成了文件和Git历史，每一轮Agent不需要依赖上下文窗口里面的碎片信息，而是模仿靠谱的人类工程师每天上班会做的事情，先确认进度，明确任务，开始干活。

具体来说，比如先通过pwd命令，查看工作目录，确认当前项目进度。

阅读git日志和进度文件，了解最新已经完成的工作。

阅读功能清单文件，找到优先级最高的未完成的任务。

运行init.sh脚本，启动开发服务器，跑一遍基础测试，确保开发开始之前一切正常。

我觉得Cursor团队和CC团队都提供了非常好的实践经验。

甚至两者的方案可以有机地结合起来。

首先角色分工无法避免，将专门的Planner、Worker、Tester组成一个团队。

Worker可以在执行任务时，借助CC的方式，解决长上下文窗口的限制问题。

其实你会发现以上的创新的关键在于，对真实世界解决复杂问题的最佳实践。

就像李想说的那样，DeepSeek的创新来源于物理世界的最佳实践。