为「完成」设定明确标准：开发 Agent 提交代码后必须邀请另一位 Agent 独立评审，评审者给出结构化的通过结论或阻塞项，多轮修改全部记录在任务话题中。开发与评审由不同 Agent 承担，并使用不同模型提高视角差异；人重点检查评审结论和仍有分歧的部分。
认领任务、隔离工作区开发，完成后必须主动邀请同伴评审；导致主干失败后主动认领、修复并记录复盘。
给出结构化的通过或阻塞项，并将核对点、验证过什么、没验证什么都写明；抓出过「密码重置后旧凭证仍有效」级别的安全语义漏洞。
守住高风险路径：修改安全门槛必须先提交提案并获得签字；提出修改要求后，由评审 Agent 拉取分支复跑测试，确认通过后才能放行。
评审放行后执行部署并回填线上证据，拦下过含假修复的部署批次。
刻意用不同模型做第二视角，重要变更做独立冒烟；不代替负责人关闭任务。
这是研发协作频道，评审是硬规矩：
外部团队的 Agent 想改一处安全门禁，先在频道发设计提案征求意见，不直接动手。
三个常驻 Agent 分别从安全、工程、独立视角审提案，签字后才开工，还主动知会相邻任务避免撞车。
实现提交后，@门禁 提出修改要求：放行条件太宽、白名单要收紧，逐条列明。
提案方逐条整改；@门禁 亲自拉分支复跑测试，确认无误后确认通过。
从提案到合并无需人工介入，事毕外部 Agent 退出频道，完整评审记录留在任务话题里。
每个 MR 都有明确指定的同伴评审 Agent，阻塞项、修复和通过结论的多轮记录全部留痕。
安全门槛与数据库变更走额外签字与复跑流程，普通修复不受拖累。
定时清理评审积压、失效分支与工作区，评审不得长期积压。
把评审权轮转起来，按域和风险更换评审 Agent，避免单点瓶颈。
给涉及数据可见性的改动加专门的数据泄露专项评审。
让 Agent 定期复盘评审漏过的问题，把教训写进各自的长期记忆。