多Agent协作跑长任务我折腾了三年，今天发现这套框架把整件事收口了——LoopX 把目标、进度、交接全管起来了

多 Agent 协作跑长任务我折腾了三年，今天发现这套框架把整件事收口了——LoopX 把目标、进度、交接全管起来了

你有没有这种感觉：让 AI Agent 跑一个单点任务，它干得挺好；但一旦涉及多天、多轮交接的工程任务，聊着聊着它就「失忆」了——上下文断了、目标偏了、交接的时候什么都没留下。

这不是工具的问题，是工程范式的问题。

最近翻到一个开源项目叫 LoopX，14.8k Stars，定位很清晰：给长时间跑的 AI Agent 团队做一个本地控制平面，把目标、进度、交接、证据全部持久化。它不替换你的 Agent 运行时，它做的是在旁边「盯着」。

单 Agent vs 长任务团队，差距在哪

单点任务里，Agent 在一次会话里把事情做完，不存在上下文断裂的问题。但工程场景里，长任务有几个绕不开的挑战：

目标漂移：聊了两天，中途换了方向，但 Agent 还记着最初的目标。
交接丢失：A Agent 做完前半段，B Agent 接手时不知道前面干了什么、证据在哪。
进度不可见：项目经理问进度，要么靠人肉汇报，要么 Agent 给你一堆聊天记录自己看。
重复劳动：同样的话要跟不同的 Agent 说 N 遍。

LoopX 的思路是：把这些全都结构化，变成状态，而不是靠聊天记录「猜」。

LoopX 怎么管状态

LoopX 的核心是一个紧凑的状态层，包含这几个字段：

objective + gates + todos + scope + evidence + quota

每次 Agent 执行一个 turn，结果会写回 evidence，更新 todos，决定下一个 tick 是否继续。每次交接 human judgment 进来，判断目标有没有漂移、要不要调整。

整个链路看起来是这样的：

objective / issue / project
│
▼
LoopX state: objective + gates + todos + scope + evidence + quota
│
├─ human judgment needed? ── yes ─▶ ask a concrete question and wait
│
├─ safe fallback available? ──────▶ run one bounded agent slice
▼
Codex / Claude Code / Cursor / shell agent executes one turn
│
▼
write evidence + handoff + next todo ─▶ quota decides the next tick

这个设计解决了两个核心问题：状态不丢 human 在环路里。

实际跑起来是什么体验

以一个 issue-fix 循环为例：

第一个 Agent 接受任务，先 claim 这个 todo，开始写代码；
代码写完，写 evidence：「修复了 XX，改动了 YY 文件」；
下一个 turn 来了，B Agent 接手，看 evidence 就知道前面干了什么；
如果 human 觉得方向偏了，可以 gate 这个 todo，重新注入 objective；
quota 机制控制每一轮花多少，防止 Agent 在没有有效进展的情况下继续烧 token。

LoopX 自己的文档里提到，他们跑了两个真实 trajectory：OpenViking Issue-Fix 和 Auto ML，每个都超过 200+ 个 turn。在这种量级下，没有结构化状态管理是不可想象的。

这套方案和现在的工作流怎么配合

LoopX 是 Agent-agnostic 的，支持 Codex、Claude Code、Cursor 以及其他 shell agent。你不需要换工具，它在旁边做一个持久化的控制平面。

对于团队场景，它的设计更明显：一个非工程师的项目经理，可以通过 board 可视化看到每个 todo 的状态，判断要不要 human review、要不要调整 scope。Agent 之间通过 typed continuation 和 handoff 交接，不需要每次都从零解释上下文。

落地怎么起步

LoopX 本身是 Python 写的，装起来很快：

pip install loopx

然后在你的项目根目录初始化：

loopx init

它会在本地生成状态文件，默认是 SQLite，后续可以换成其他存储。Agent 执行的时候，通过 SDK 把 evidence 和 todos 写进去，human review 通过它的 CLI 或者飞书文档做（他们有中文文档）。

对于已经有 Claude Code 工作流的团队，LoopX 的学习成本不高——你不需要改现有的 prompt 逻辑，只需要在关键节点加上 evidence writeback。

下一个问题是：谁来管这个状态

这是 LoopX 没有完全解决的问题。它把状态管理做得很清晰，但 human review 的频率和质量还是取决于团队流程。一个建议是：先把 gate 设置好，哪些 todo 需要 human 才能通过，哪些可以跑完直接写 evidence。流程定好了，这套机制才能真正发挥价值。

总体来说，LoopX 解决的是「Agent 从单点任务到长流程工程」这个过渡阶段的核心矛盾：状态丢失和交接困难。如果你有多 Agent 协作的场景，或者你的项目经常跑着跑着上下文就断了，建议先跑一遍他们的文档和 example repo，看看这个范式适不适合你的团队。