LoopTroop：本地优先AI编程编排器，通过状态持久化解决上下文膨胀

问题：长期任务中的上下文腐烂

AI 编程工具在让你快速写一个函数、生成样板代码、或修复单个 bug 时表现很好。但一旦你把一个复杂的多文件功能工单交给 Agent，通常在 10 到 15 次工具调用之后事情就会开始崩溃。

上下文窗口会被终端输出、编译器错误、大型文件转储和半生不熟的 diff 填满。当这些噪音堆积起来后，模型开始遗忘早期的需求、重新引入之前已修复的 bug，或者产生幻觉代码。

LoopTroop 选择了一条不同的路：用上下文工程取代无限的聊天历史。LoopTroop 不是让一个冗长的对话随时间推移而质量下降，而是将工作分解为不同的阶段，将状态持久化到磁盘作为持久化文件，并为每个步骤向模型提供干净、最小化的微上下文。

LoopTroop 围绕"慢而精确"的理念构建。催促 Agent 立即写代码通常会在清理工作中浪费更多时间，而不是在前期做结构化的规划。

在写任何规格或代码之前，LoopTroop 会运行一个交互式访谈。它扫描你的代码库，检测工单中的歧义，并就架构、权衡和边缘情况向你提出直接的澄清问题。这确保了在任何代码被触碰之前，计划真正反映了你想要的东西。

LoopTroop 使用 LLM Council 来规划 PRD 和任务分解，而不是依赖单个模型的偏见来设计功能架构：

多个配置好的模型独立起草各自的提案。

模型匿名审查和投票，给出最佳方案的得分。

获胜计划吸收其他草案中最强的思路，并运行覆盖率检查以确保没有遗漏需求。

大型工单被分解为小的、自包含的工作单元，称为 Bead。每个 bead 定义了：

• 一个具体、狭窄的目标
• 具体的验收标准
• 验证完成的自动化测试命令

Agent 一次实现一个 bead，带着一个只关注该任务的干净 prompt。

当 Agent 陷入循环或未能通过验证检查时，传统工具只是将失败回溯追加到聊天中，污染后续尝试。

LoopTroop 使用恢复循环模式：

每个 bead 执行都有时间限制。

如果一个 bead 失败或卡住，LoopTroop 停止尝试，写一个简短的诊断说明解释哪里出了问题，然后丢弃嘈杂的会话历史。

下一次迭代从干净的上下文重新开始，只携带那个紧凑的失败说明。失败转化为有针对性的学习，而不是上下文污染。

LoopTroop 是一个桌面 GUI，而不是 CLI 命令或托管云平台。它为你提供了一个干净的 Kanban 界面来管理多个代码库和多个活动工单：

• 实时跟踪阶段进展。
• 检查 council 草案、投票细分和 PRD。
• 监控实时执行日志和终端输出。
• 在一个窗口中审查 bead 状态、测试输出和最终 Git diff。

LoopTroop 旨在让你在关键决策点掌控全局：

• 你回答初始访谈问题。
• 你审查并批准生成的 PRD 和 bead 分解。
• 你可以在 bead 实现过程中介入、暂停或调整。
• 在任何内容被移交到主分支之前，你审查经过验证的更改。

执行引擎：LoopTroop 使用 OpenCode harness 进行文件操作、终端执行和模型通信。

模型无关：你可以配置任何在你的设置中支持的模型或提供商（Anthropic、OpenAI、Google、DeepSeek、通过 Ollama 的本地模型等），用于主要的实现者和 council 成员。

本地化：在你的机器上本地运行，对抗你的本地 Git 仓库。

链接与试用

源代码：https://github.com/looptroop-ai/LoopTroop

视频演示：https://www.youtube.com/watch?v=LYiYkooc_iY

任何反馈、批评或 bug 报告都热烈欢迎。如果你决定尝试这个应用，它在你的项目上运行良好或在你的技术栈上完全崩溃，请在这里留言或在 GitHub 上开一个 issue。我很想听听你的想法！