我曾经很容易把“有一个协调者、几个成员 Agent，再配一张流程图”当成一支小队的雏形。
在一次把研发流程映射到 Multica 小队的设计里，我先按熟悉的阶段拆角色：需求分析、技术设计、开发、测试，最后再加一个协调者。看起来很完整，甚至已经像一条可以自动运转的生产线。
但我很快发现，流程图没有回答真正麻烦的问题：需求不完整时谁能让流程停下来？成员说“完成”时谁来判断？一个结果交给下一个角色时，接手者到底拿到了什么？
这次设计让我改变了一个看似简单的判断：小队不是 Agent 的集合，而是一套关于责任、交接和证据的协议。
我先修正的不是角色，而是任务边界
当前公开的 Multica 小队设计方法，第一步不是列 Agent，而是固定小队为什么存在、服务谁、接收什么输入、交付什么结果，以及明确哪些事情不做。
这一步看起来不像“真正开始工作”，却决定了后面所有角色有没有边界。
比如“做一支处理客户投诉的小队”还不够具体。它到底负责分类、调查、回复建议，还是可以直接改变外部状态？它能读哪些资料？需要什么人工批准？如果缺少订单信息，它应该继续推测，还是停下来请求补充？
我现在会先把这些问题说清楚，再讨论需要几个 Agent。因为角色数量解决不了责任不清，流程图也不能自动生成停止条件。
案例真正的转折：从“谁来做”变成“谁来接住”
在那次小队设计里，最初的注意力都放在“哪个 Agent 负责哪一段”。后来我把问题换成了“这一段结束后，谁来接住什么”。
一个成员把任务交回协调角色时，最重要的不是写一句“已完成”，而是让接手者知道：当前阶段是什么，依据了哪些输入，产出了什么，哪些判断已经成立，哪些问题仍然未知，下一步应该由谁决定。
于是，Handoff 不再是流程末尾的一段格式化文本，而变成了小队能否继续工作的分界面。
这张图里最重要的不是“完成”路径，而是“阻塞”路径。
如果系统只会在顺利时继续推进，遇到缺口时却仍然生成一个看起来完整的结果，那么它拥有的是自动推进能力，不是稳定的协作能力。
这里需要说清楚：这是根据公开 Runtime Proof 契约整理出的设计案例，不是一次已经完成的第三方运行证明。它说明一支小队应该怎样被验证，不能被写成某支小队已经 runtime_verified。
小队不是越多角色越专业
角色拓扑真正要解决的是三件事：谁负责判断、谁负责执行、谁必须把结果交回去。
当前公开方法把协调 / 路由责任集中到一个默认决策角色，同时要求成员默认交回这个角色评估。成员不能横向互相派发任务，也不能把“建议下一责任人”写成“已经完成委派”。
我会给每个成员角色追问这些问题：
- 什么输入到达后才允许开始？
- 缺少什么时必须阻塞？
- 可以读取和修改什么？
- 产出的具体对象是什么？
- 完成、失败和阻塞分别怎样交回？
- 谁拥有下一步的决定权？
如果这些问题只能回答“它负责分析”或“它负责开发”，那还是岗位名称，不是可执行的角色边界。
通用方法和具体承载要分开
这也是我重新整理这篇文章时最需要修正的地方。
我以前很容易把通用方法、具体项目和第三方平台写成一条连续的自动化链，好像只要理解了 Maglev，就能直接生成一支已经可以运行的小队。
当前公开方法的边界更克制：它不预设目标项目一定使用 Maglev，不预设存在某个固定 CLI，也不直接创建第三方承载中的对象。具体项目要通过 Adapter Contract 说明自己的文件、命令、权限、写入门禁和验证证据。
这个边界让我重新区分两句话：
通用方法负责说明一支小队应该证明什么。
Adapter 负责说明在这个项目和承载环境里，具体怎样证明。
如果两层混在一起，文章很容易把某个样本的实现路径写成所有团队都适用的规则，也容易把静态模板误写成运行事实。
质量分级是在限制我的表达
当前 Multica 小队质量级别从设计到运行分成 L0-L3：
- L0：只有角色清单或初步意图，只能说是
draft； - L1：协同契约完整，可以说
collaboration_designed； - L2：Adapter 模板、测试和静态验证已经落地，可以说
template_verified； - L3：真实承载环境里完成任务触发、接力和 completed / blocked 两类终态 Handoff，才可以说
runtime_verified。
这套分级对作者有一个很实际的约束：我手里有什么证据，就只能写到什么程度。
有角色定义，不代表小队已经运行。
有模板校验，不代表成员真的接到了 Task。
有本地 plan 或 dry-run，也不代表发生过真实接力。
Runtime Proof 要求承载环境、对象标识、触发输入、精确 mention、终态 Handoff 和消费结果。缺少这些证据时，最诚实的说法是 unverified、blocked 或 awaiting_external，而不是把“看起来可以运行”写成“已经稳定运行”。
我现在会怎样审一支小队
我不会先看它有多少个 Agent，而会先看下面这些问题：
- 这支小队的唯一协调 / 路由责任角色是谁？
- 成员是否知道什么情况下必须阻塞？
- Handoff 能不能让下一责任人理解当前状态、证据、未知项和下一步？
- 是否明确禁止横向委派和重复派发？
- Adapter 是否说明了文件、命令、权限、写入和验证边界？
- 当前声明是设计完成、模板验证，还是已经有 Runtime Proof？
- completed 和 blocked 两条路径是否都被真实验证？
如果这些问题还答不上来，我不会先增加 Agent 数量。更可能需要补的是协同契约、适配器边界或运行证据。
结尾：我现在更在意它能不能停下来
多 Agent 并不会自动带来更强的协作。
一支小队真正有价值，不是因为它把更多执行者放进了同一条流程，而是因为每个执行者都知道自己的责任边界，协调角色知道什么时候该继续，成员知道什么时候必须停下来，接手者也能回查这次决定依据了什么。
所以我现在更愿意把小队设计理解成一种责任设计：先把谁能决定什么、谁应该交回什么、什么条件下必须停止说清楚，再谈如何接入具体平台和工具。
小队不是 Agent 名单。它是一份关于责任、证据和能力边界的可验证协议。