AI Dev Team — supervised multi-agent delivery harness

AI Dev Team — supervised multi-agent delivery harness

核心判断

AI Dev Team 值得进入 wiki，因为它作为研究发布，公开了一个 supervised coding agents runtime 的完整形态：Planner → Orchestrator → Reviewer delivery loop、runner-observed verification、role-based model routing、worktree isolation、approval policy、cost tracking、PR publishing 和 SWE-bench-style evaluation。更重要的是，README 明确记录失败实验和局限：该 harness 不再是 Borge Labs 的日常交付工具，而是作为研究/benchmark artifact 留存。

这对用户重要：它提醒 llm-wiki 不应只追踪“最新最强 agent 工具”，还应沉淀那些诚实展示 harness 成败、验证边界和替代路径的材料。对于 Hermes，最有价值的不是复制它的多 agent 架构，而是学习 runner-observed verification 和 supervised loop：模型声称测试通过不算通过，runner 必须观察命令结果。

机制：supervised loop + runner-observed verification

AI Dev Team 的机制可以拆成几层：

1. 角色循环：Planner、Orchestrator、Reviewer 分工，支持 model-per-role 配置和 cross-family role assignment。
2. 执行隔离：配置仓库 runs 使用 isolated Git worktrees；runner 容器映射非 root UID/GID，降低文件权限/污染风险。
3. 真实验证：runner 自己执行 builds/tests，UI 暴露 diff、test output、review decisions、usage 和 cost；“model says pass”不是 green signal。
4. 审批策略：merge、deploy、paid、public actions 等高风险操作可配置 approval policy。
5. 基准与成本：提供 headless SWE-bench-style evaluation，并记录 provider-reconciled cost accounting。
6. 透明研究状态：README 说明原始 run artifacts 未包含，历史分数不能独立复现；这类诚实限制本身就是高质量来源信号。

一阶原理是：多 agent delivery 的可靠性来自角色分工、隔离环境、外部 runner、审批门禁和可观察成本，而不是 agent 互相评价后自证。

与现有 wiki 概念的关系

• 对 Harness-Engineering：它是“verification membrane + worktree isolation + approval policy”的集成例子。
• 对 Loop-Engineering：它展示了从单次 coding run 到持续 delivery loop 的产品形态，但也提醒复杂 loop 可能被更简单 supervised loop 替代。
• 对 Agent-Benchmarks：它说明 benchmark 报告需要 run artifacts 才能独立复现；没有 artifacts 的历史结果应降低置信度。
• 对 Agentic-Coding：它把编码 agent 从 prompt-level 使用推进到 delivery system，但保留人类监督和 runner verdict。

对 Hermes / llm-wiki 的可执行启发

1. 把“运行者观察”写进完成定义：Hermes 报告测试、索引、lint、curl 验证时，应引用实际工具输出；模型解释不能替代 runner output。
2. 区分研究 artifact 与生产依赖：像 AI Dev Team 这类完整系统适合学习机制，不应无人 cron 自动安装或迁移。
3. 记录失败和未复现限制：wiki source page 应保留来源的限制声明，避免把 self-reported benchmark 固化为事实。
4. 用更简单 loop 替代复杂多 agent：如果单 agent + runner + reviewer already works，就不必为形式上的 multi-agent 增加复杂度。

失败模式与边界

• 不可独立复现：README 明确 raw run artifacts 未包含；benchmark 分数只能作为历史观察，不应作为强事实。
• 复杂度成本：Postgres、web UI、runner、GitHub App、多角色模型路由带来较高运维成本。
• 研究发布无 SLA：没有支持承诺或 roadmap，生产采用风险高。
• 多 agent 可能不如简单配置：来源本身提到某些结果支持更简单 supervised loop；这对“堆 agent”是反例。

深度判断

晋升理由：它同时提供机制和反例，特别适合补强 Harness-Engineering 的 verification/approval/worktree 层和 Agent-Benchmarks 的 artifact 置信度判断。因结果不可复现且项目自称研究发布，置信度为 medium。

写入记录

• 2026-07-26 09:00 CST：新增 source 页面，沉淀 AI Dev Team 的 supervised delivery loop、runner-observed verification、benchmark 限制和对 Hermes 完成定义的启发。