值得启用
- 任务跨规划、实现、验证或发布多个阶段
- 需要唯一 Lead 与多个专业边界协同
- 重复失败，需要根因迭代与明确停止条件
- 存在生产、数据、API 或迁移风险
- 完成声明必须留下结构化证据
- 需要 Beta、release、feedback 或 resume
14 dimensions
对比协作协议，不比较模型智商。
矩阵描述默认工作方式。任何工具都能通过额外工程补齐缺口；关键区别是这些能力是否已成为可验证的运行时契约。
| 维度 | VITD | 普通多角色提示词 | 单一编码 Agent | 无边界自动循环 |
|---|---|---|---|---|
| 任务分流 | Lead + bundle + risk | 按角色模板 | 通常直接执行 | 由循环策略决定 |
| 责任中心 | 唯一 Lead | 多视角易并列 | 单 Agent 明确 | 可能随轮次漂移 |
| 目标边界 | GoalFrame / Quick Slice | 依赖 prompt | 依赖任务说明 | 容易由反馈改写 |
| 生产 / 验收分离 | Worker / Verifier | 常为同轮互评 | 通常自验 | 通常自我反馈 |
| 失败状态 | 14 状态 + 合法转换 | 自然语言 | 工具状态 | 重试 / 继续 |
| 最大循环 | 有 max cycles | 通常无循环 | 可配置 | 可能持续运行 |
| 人工边界 | Human decision plane | 随时提问 | 权限时提问 | 往往晚触发 |
| 恢复能力 | 状态优先 resume | 依赖对话上下文 | 依赖 session | 通常有循环状态 |
| 发布门禁 | ship / hold + evidence | 建议型 | 依赖宿主流程 | 目标完成即停止 |
| 发布后反馈 | Feedback closure | 新对话处理 | 另起任务 | 可持续观察 |
| 反熵治理 | 删除 / 兼容 / 确认分类 | 无内建协议 | 依赖代码规范 | 易增加 fallback |
| 完成证据 | 结构化 evidence | 总结型 | 命令与 diff | 循环 metric |
| 真实多 Agent 声明 | 三档 fail-closed | 常为角色模拟 | 通常不声明 | 取决于宿主 |
| 简单任务成本 | 最小路线但有协议成本 | 很低 | 最低 | 可能过重 |
Use boundary
适合复杂交付，不必接管所有请求。
最好的路由器也应该知道什么时候不要出现。能用一步安全完成的任务，不应被包装成大型虚拟团队。
直接处理更合适
- 只是解释一个概念或回答单点问题
- 任务无需改动、交接或发布判断
- 一个明确命令就能安全验证并完成
- 只需要一次轻量 brainstorm
- 没有足够上下文建立可靠边界
- 用户明确不需要流程化产物
Tradeoffs
它用协议成本，换取交付可控性。
这不是免费收益。任务越简单，结构化路由和证据门禁的相对成本越高；任务越复杂，责任和恢复能力越有价值。
更多显式产物
复杂任务会生成约束、WorkOrder、验证报告和 completion evidence，需要维护者理解这些对象。
不替代模型与工具
系统协调现有编码、浏览、测试和 Agent 能力；它不会凭空创造宿主没有的 runtime。
更少隐性状态
范围、失败、恢复、人工介入和发布判断有固定位置，跨轮次交付不必靠记忆重建。
Decision guide
三问判断是否值得启用。
如果三个问题都是否，直接使用更轻量的工具通常更好。
- 是否存在多个责任阶段？
例如定义、实现、独立验证、Beta、发布或上线反馈。
- 失败是否需要可恢复？
任务跨 session、可能重复失败，或需要保留回滚与人工检查点。
- 完成是否必须被复核？
需要另一个人或自动门禁根据同一份证据做出 ship / hold 判断。
需要闭环时启用，需要速度时走最小路线。
从一次真实的小切片开始，再按风险扩展协作。