openclaw 多 agent 协同原则。
第一,步骤级可验证(不是靠感觉)
以前你只能看最终结果好不好;现在每个节点都有一个“可检查产物”:
A 节点给出验收标准
B 节点给出事实/约束/边界用例清单
D 节点给出实现与最小测试
E 节点给出挑错清单和最小修复
F 节点给出最终交付与验证步骤
你想验证哪一步,就检查哪一步的材料包是否满足闸门规则。不是“我觉得对”,是“字段齐不齐、引用对不对、测试有没有、边界用例够不够”。
第二,排查可定位(能知道错在哪一段)
最终结果出问题时,你不再需要重新从头猜。你能非常快地问一句:“这是定义错、证据不全、推理跳步、可行性没覆盖、还是红队漏检?”
举例:
•如果最后做出来的东西不符合预期:通常是 A 的验收标准写错/缺失,或范围边界不清。
•如果方案听着很对但一落地全是坑:通常是 B 的约束/风险没列全,或 D 的可靠性/失败模式没做。
•如果红队没指出明显问题:E 的输入不够隔离,或者闸门要求不够硬。
第三,可复盘可进化(知道下一次该改哪一个变量)
每次失败都会落到 FailureCode + minimal_fix。你就能做真正的“单变量迭代”:下一轮只改一个点,比如补字段、加强闸门、增加边界用例、把红队隔离成独立代理,而不是每次都“重写提示词求好运”。
第四,可恢复(中断后能继续)
只要你把任务状态写进“任务卡/真相源”(哪怕先是一个本地文件),你就能做到:对话断了、工具重启了,也知道当前在哪个节点、上次闸门过没过、该重试还是回滚、缺什么信息。否则你永远在“重新解释一遍需求”。
第五,防抄近路(把聪明变成可控)
你朋友说的“越聪明越要边界清晰”,在这里对应的就是:每个角色只交自己那份材料包。Agent 想抄近路也抄不了,因为闸门会卡住:缺验收、缺边界用例、缺测试、缺引用,就不能往下走