Squad 失败复盘

Squad 是我们做过最有野心的 Agent 尝试之一。

如果说 Oracle 试图让一个 Agent 接住目标并持续完成任务，那么 Squad 想再向前一步：让一组 Agent 围绕一个长期目标形成分工，自己制定计划、并行行动、交换结果，并随着环境变化不断调整。

它不是把几个模型调用串在一起。我们真正想象的是一种小型 AI 组织：拥有持续存在的目标、不同能力的角色、跨越多轮交互的状态，以及在用户不在场时仍然推进工作的能力。

Squad 最终没有成立。但它的失败不是因为系统无法运行。恰恰相反，它可以做很多事。真正的问题是，我们无法可靠地判断这些行动是否正在把它带向正确的结果。

Squad 出彩的地方

Squad 最重要的判断，是把时间带进了 Agent 的产品设计。

大多数 Agent 围绕一次任务组织自己：理解请求，调用工具，返回结果。Squad 面对的却是可能持续数周甚至数月的目标。一次计划不可能覆盖全部变化，一次上下文也不可能容纳全部历史，因此系统必须能够保留任务、重新规划、暂停恢复，并在新的信息出现后继续行动。

我们为它设计了不同角色。有的角色理解目标和安排工作，有的角色执行具体任务，也有角色负责重新审视阶段和组织结果。任务可以并行推进，计划可以在过程中演化，用户也可以在关键位置 review、补充信息或改变方向。

这些设计让 Squad 看起来不再像一条 workflow。它更像一个会持续调整的组织：成员知道自己正在承担什么，系统知道工作处于哪个阶段，新的结果能够改变后续安排。

这个方向本身至今仍然吸引我。真正的长期 Agent，可能确实需要组织结构，而不只是一条更长的推理链。

活动很容易伪装成进展

Squad 可以不断产生行动：创建计划、拆分任务、分配角色、生成材料、发送进度、完成阶段，再根据结果重新规划。

从产品界面看，它是活着的。系统持续出现新的消息、状态和交付物，每一个局部步骤也都可能显得合理。

但活动并不等于进展。

一个系统完成了十项任务，只能说明它完成了十项任务，不能说明长期目标因此更接近实现。计划写得更完整、角色讨论得更充分、生成的材料更多，也可能只是在提高系统内部的一致性，而没有改变外部结果。

短任务通常拥有天然的结束条件。代码能否运行，文件是否生成，问题是否得到回答，都可以很快检查。长期任务没有这么慷慨。系统今天作出的选择，可能要几周甚至几个月后才显现效果。

当反馈迟迟不来，Agent 最擅长做的事情——持续行动——反而可能成为风险。

LHT 最难的是 Evaluation

Long-horizon task（LHT，长周期任务）困难的不只是步骤更多、上下文更长或者工具更复杂。它真正困难的地方是 Evaluation。

首先，反馈是延迟的。系统作出决定时，结果还不存在。等结果出现，已经有许多后续行动建立在这个决定之上。

其次，反馈是稀疏而模糊的。一个长期项目变好或变坏，往往没有单一指标。用户判断、市场变化、协作质量和偶然事件都会影响结果。

更麻烦的是归因。即使几个月后看到了结果，也很难判断究竟是哪一次计划、哪一个角色或哪一个中间选择造成了它。环境在变化，目标本身也可能已经改变。

这意味着 Squad 缺少一个足够快、又足够真实的学习回路。它能够根据新信息重新规划，却不知道什么证据足以说明旧计划是错的；它能够 review 自己的工作，却没有独立于自身叙事的标准来判断 review 是否可靠。

没有 Evaluation，重规划很容易变成对原有假设的重新包装。

Multi-Agent 不会自动带来纠错

我们曾经对角色分工抱有很高期待。不同 Agent 可以提供不同视角，一个负责执行，另一个负责审查，看起来比单个 Agent 更不容易犯错。

但更多角色首先放大的是产能，不一定是判断力。

如果所有角色使用相似的信息、共享相似的假设，并且最终仍由同一套模糊标准判断结果，那么讨论和 review 只会让错误显得更有共识。一个 Agent 的盲点可以被多个 Agent 写成一份结构完整的计划。

Context、Memory 和更好的协调机制能够让系统更一致，却不能证明方向正确。系统记得越多，只代表它更忠实地延续过去；如果最初的判断就错了，连续性甚至会让偏差积累得更稳定。

Multi-Agent 解决的是如何组织行动。Evaluation 才决定这些行动是否值得继续。

为什么蜜蜂视角也没有解决问题

我们甚至讨论过一种更激进的思路：用蜜蜂的视角模拟长期任务。

一只蜜蜂的生存、采集、分工和群体延续，可以被压缩到更短的观察周期。环境里也存在清晰得多的反馈：资源是否增加、个体是否存活、群体是否延续。也许我们可以用这种方式，把几个月后才能验证的问题，变成短时间内可以重复运行的模拟。

这个想法很有吸引力，因为它试图解决 Evaluation 的时间成本。但它很快暴露了一个根本问题：缩短时间，不等于保留问题。

当我们把现实目标改写成生存、资源或繁衍，评价标准也已经被替换了。真实的长期任务包含变化的人类判断、不可逆的选择、缓慢形成的信任，以及无法被提前枚举的环境变化。一个压缩模拟越容易计分，就越可能删掉原问题中最重要的部分。

它能够告诉我们 Agent 是否学会了适应那个模拟，却不能告诉我们 Squad 是否能在现实世界里作出几个月后仍然正确的决定。

更快的错误反馈，仍然是错误反馈。

Squad 为什么失败

Squad 的问题不是缺少计划、角色、状态、工具或持续运行能力。我们在这些方面投入了大量工作，而且其中许多设计后来仍然影响了我对 Agent Systems 的理解。

它失败在更靠前的位置：我们先构建了一个能够长期行动的系统，却没有先定义一个能够长期判断它的系统。

当结果无法被及时验证时，自主运行只是在扩大不确定性。系统越勤奋，产生的路径越多；角色越多，归因越困难；运行越久，纠正错误的成本越高。

我们能观察它是否在运行，却无法证明它是否在进步。

这不是最后补一套测试就能解决的问题。Evaluation 决定了任务应该如何被切分、哪些决定可以交给 Agent、哪里必须等待人，以及系统能安全地自主多久。它不是 Agent 完成之后的评分器，而是整个产品的边界。

如果重新开始

如果今天重新构建 Squad，我不会先问需要多少个角色，或者计划应该分成多少阶段。我会先问：系统最迟什么时候能够知道自己错了？

长期目标仍然可以存在，但它需要由不同时间尺度的证据支撑：

• 立即验证一次行动是否合法、结果是否真实产生；
• 在阶段结束时验证外部状态是否按预期改变；
• 在不可逆决策前引入人的判断；
• 对真正需要数月观察的结果，明确承认当前只能使用代理指标，而不是把它们当作答案。

Agent 不应该因为目标很长，就获得同样长的无监督时间。更合理的做法，是把长期目标组织成一系列能够产生证据的判断，并根据证据逐步扩大系统的行动空间。

Squad 让我看到了长期 Agent 可能拥有的形态：持续存在、多人协作、理解时间，并允许人随时进入其中。它也让我更早看到这条路上真正的限制。

一个 Agent 能执行多久，并不决定它能走多远。

它能够多快知道自己走错了，才决定。