长时间运行，不等于真正的长任务 Agent

最近，Meta 发布了 Muse Spark 1.3，并把长周期任务作为这次升级的重点之一。

按照 Meta 的介绍，它可以在一条长对话中处理多个工作流，从混乱甚至相互冲突的资料中建立上下文，记录已经获得的信息，发现计划中的缺口，并在最后产出可以交付的结果。遇到困难时，它还会请求用户协助。

这些能力听起来都很重要。不过，从我使用 AI Agent 完成编程和内容生产任务的经验来看，能够长时间运行，并不等于真正具备了完成长任务的能力。

我交给 AI 时间最长的任务，主要还是写代码。有些任务会涉及多个模块，需要反复读取代码、修改、测试和修复；有时还会跨越多个会话。除此之外，我也使用 Skill 让 AI 完成文章或者漫画生产，这些任务同样包含多个步骤和不同工具。

这类任务最容易缺少的，其实是上下文。

这里的上下文不只是最初的一段提示词，还包括任务的目标、不能违反的限制、已经查看过的资料、做过哪些尝试、哪些方案失败了、目前进行到哪一步，以及最后应该怎样验收。

只要其中一部分丢失，AI 即使还在继续运行，也可能已经偏离了原来的任务。它可能重复做已经完成的工作，忘记之前明确的限制，或者解决了局部问题，却没有完成最终目标。

所以，记忆、状态记录和失败恢复之所以重要，不只是为了让任务“接着跑”，而是为了让 AI 在运行过程中始终知道自己正在做什么。

Meta 还特别提到，Muse Spark 1.3 遇到困难时会向用户求助。我认同 AI 必须知道自己什么时候做不到，但我认为，向人求助应该尽量减少。

人的主要责任，是确定目标、目的和边界。至于中间采用什么方案，应该尽量交给 AI 自主决定。一个方案行不通，可以尝试另一个；发现依赖缺失，可以先寻找替代路径；测试失败，可以根据结果继续修正。只要目标没有变化，也没有越过权限边界，AI 就不应该把每一个执行问题都重新交给用户。

否则，所谓的长任务 Agent，只是一个运行时间更长、却仍然需要人不断推动的工具。

当然，自主运行越久，另一个问题就越重要：我们怎么知道它真的完成了？

不能因为 AI 工作了几个小时，生成了很多文件，最后又告诉我们“任务已经完成”，就把它当作完成。真正的完成必须能够被验收。

我更倾向于把验收分成几层。

首先，在任务开始前设定一些硬性的验收指标，例如测试是否通过、文件是否生成、数据是否完整、输出格式是否符合要求。这些可以交给技术手段自动检查。

然后，可以让另一个模型或者一个新的会话独立验收。执行任务的 AI 已经拥有完整的过程上下文，也可能受到自己原有判断的影响；换一个没有参与执行的模型，更容易从结果本身发现遗漏。

最后，再由人检查结果是不是自己真正想要的。自动化测试能够判断程序有没有通过，却不能完全代替人判断产品是否好用、文章是否表达了真实想法，以及最终结果是否解决了原来的问题。

因此，真正的长任务 Agent，至少需要做到三件事：保留足够的上下文，在边界内自主尝试，以及用可以验证的结果证明任务已经完成。

运行时间只是续航。能够在很少的人为干预下持续向目标推进，并最终接受自动化、独立模型和人工的分层验收，才是真正完成长任务的能力。