我组建了一支能自我审查的 AI 开发团队——多代理循环的实践心得

大多数多代理演示五分钟内很惊艳，五小时后却一无是处。经过数月打造 Task Hounds —— 一个开源、本地的多代理开发工作区 —— 以下是真正关键的设计决策。

搭建

Task Hounds 让三个代理围绕一个项目循环运行：

• Manager：理解上下文、维护计划，每轮仅分配一个具体任务
• Worker：执行任务，并提交结构化报告：变更的文件、测试结果、已知问题
• Reviewer：在 Manager 决定下一步前，检查结果是否存在 Bug、UX 问题和风险

人类编写 Directive（任务使命），并可在运行中注入想法或新任务。所有内容——计划、待办、报告、反馈、实时代理流——均持久化到本地 SQLite，并在实时仪表盘中渲染。

经验 1：一次一个任务优于并行一切

我最初的想法是并行 Worker。演示效果很好，却什么都没交付：代理互相踩文件，Manager 也无法归因失败。将循环序列化为一次一个任务，看起来更慢，却实际完成了更多工作。

经验 2：给人类一个写保护锚点

目标漂移是长循环的隐形杀手。大约第 10 轮，计划已悄然偏离最初要求。我们的解决方案：Human Directive 会被复制到每个会话，且循环禁止修改。只有人类可以更改使命。漂移现在会表现为与固定锚点的可见差异，而非无声变异。

经验 3：结构化交接，而非聊天历史

在代理间传递对话历史会失败两种方式：它会撑爆上下文窗口，也会让下游代理锚定在上游的推理噪声上。Task Hounds 的每一次跳转都是固定文档：Manager 的记忆是一个明确的 JSON 交接，每轮仅读取一次；Worker 的输出是固定的报告模式。如果机器可读的 todo JSON 无效，循环会在发布任何工作前修复它。

经验 4：Reviewer 不得拥有权力

早期 Reviewer 可以直接分配修复。结果：无限评审循环，两个代理永远在谈判。现在 Reviewer 只向 Manager 提交结构化反馈，由 Manager 决定：修复、继续或停止。将判断与决策分离，稳定了整个循环。

经验 5：信任是 UI 问题，而非模型问题

我赋予系统自主权最大变化的来源并非更好的模型，而是能够“看到”。当每个决策都是 SQLite 中的一行、仪表盘中的一个面板时，“是否让它运行一小时？”就变成了一个基于证据的问题，而非信仰问题。

仍待解决的难题

• 与 LLM 的文本契约依然脆弱；结构化输出 / 工具调用将取代我们部分修复层
• 成本：三个角色消耗的 token 多于单次提示。我们押注 plan→implement→review 比反复提示困惑的单一代理更省 token —— 这对长任务成立，对小改动不成立
• 跨平台打磨（托管运行时目前以 Windows 为主；Docker 运行在所有平台）

试用

Task Hounds 采用 MIT 许可：https://github.com/catowabisabi/task-hounds
3 分钟演示：https://www.youtube.com/watch?v=pu-Rt8Ye4EQ

如果你也构建过代理循环——你的在规划、执行还是评审环节失败？我很乐意在评论区交流心得。