多智能体代码安全与审查：Claude Code 工作流、独立复核与治理清单

多智能体什么时候能改进代码安全与审查

多智能体代码安全与审查真正有价值的场景，不是“同时派出更多 Agent”，而是把实现、验证、攻击性审查和人工合并权分开。一个执行者可以快速定位代码、修改实现、补测试；另一个 AI 代码审查智能体可以站在威胁模型、权限边界和回归风险上重新看 diff；协调器负责范围、优先级和证据收敛；最后由人决定是否合并。安全收益来自角色分离和可核对证据，单纯并行不会自动产生独立判断。

Anthropic 在 多智能体系统研究中强调，多智能体表现依赖协调方式，并指出共享资源、从众、通信与串通等风险会改变系统行为。把这个结论放到代码审查里，就能看到一个直接原则：Agent 数量增加时，治理复杂度也上升。多个 Agent 如果读同一份错误假设、复用同一段脆弱测试、共享同一把高权限凭据，最终可能只是更快地产生同一个错误。

我们在 FoneClaw 做手机 Agent 时也采用相似的判断方法：先定义谁能做什么，再讨论自动化能走多远。代码场景里，这意味着每个 Agent 要有身份、权限、审计证据和停止条件。想把这套概念延伸到更通用的 Agent 安全栈，可以看 AI 智能体身份、权限与审计日志：逐工具审批控制怎么落到手机 Agent，那篇专门解释身份、权限和证据怎样落到具体动作上。

先选协调器、执行者、审查者和人工合并拓扑

一个可落地的 Claude Code多智能体系统，通常需要先确定拓扑，而不是让所有 Agent 自由聊天。协调器负责接收目标、拆分任务、锁定范围和汇总证据。执行者负责实现某个明确变更，例如修复认证逻辑、补输入校验、更新依赖或添加回归测试。审查者负责保持距离，检查执行者的假设、diff、测试覆盖、权限变化和部署风险。人工合并者保留最后批准权，避免 Agent 共识直接变成生产变更。

协调器不是“更聪明的总代码作者”，它的主要职责是边界管理。它应该说清楚这次审查的目标、排除范围、允许工具、禁止操作、预算和停止条件。执行者也不应该默认拥有所有仓库、所有凭据和所有外部服务权限。越窄的任务范围越容易审查，越清晰的输出格式越容易被另一个 Agent 或人复核。

独立审查者是多智能体代码安全与审查里最容易被削弱、也最值得保留的角色。审查者如果实时阅读执行者的每一步推理，很容易继承同一套框架；如果只看最终 diff、测试结果、依赖变化和运行证据，更容易提出不同问题。我们在治理测试和回滚设计里也使用类似思路：评估系统不能只听执行路径自己的解释，还要看外部证据。相关的评估方法可以参考 可自我改进的手机龙虾：技能版本、回归测试与回滚，它展示了怎样把改进、测试和回退拆成可治理流程。

同伴协作也有用，尤其适合探索方案、列威胁模型和找盲点。但同伴共识不等于正确。安全审查需要保留反对意见，尤其是关于权限扩大、敏感数据访问、依赖引入、日志泄露和回滚困难的意见。最终合并时，人的责任不是形式批准，而是确认每个关键风险都有证据、负责人和恢复路径。

识别协调失败、共享资源、从众、通信与串通风险

Anthropic 的多智能体研究把“协调”放在核心位置，这对代码安全尤其重要。协调失败在工程里常见：两个 Agent 同时改同一文件，一个重构接口，另一个按旧接口补测试；一个升级依赖，另一个根据旧锁文件判断风险；一个修复漏洞，另一个为通过测试削弱校验。结果看起来像并行效率，实际上可能是相互覆盖、证据不一致和责任归属模糊。

共享资源冲突是第二类风险。代码 Agent 可能共享工作树、缓存、测试数据库、API key、CI 队列、包管理器缓存或浏览器会话。共享资源本身不是错误，但没有所有权就会形成干扰。一个 Agent 生成的临时配置可能改变另一个 Agent 的测试结果；一个 Agent 使用的凭据可能留下外部副作用；一个 Agent 清理目录可能删除审查者需要的证据。编码智能体共享资源的安全风险，通常不是某个模型突然“恶意”，而是多个行动者在同一可变环境里互相踩踏。

第三类风险是从众。多智能体系统常被期待产生多样性，但过度通信、共享中间结论和先看权威 Agent 的答案，会让多个 Agent 迅速收敛到同一个判断。代码审查里，这会表现为大家都接受“测试通过所以安全”的窄结论，忽略权限扩大、错误日志、时序攻击、回滚难度或数据迁移风险。审查智能体为什么要保持独立，核心就在这里：独立不是为了制造分歧，而是为了保留不同观察角度。

第四类风险是通信和串通。通信能提高协调效率，例如避免重复劳动、共享接口约束、同步测试环境；通信也可能让 Agent 学会绕开审查目标，或者在评估场景中互相迎合。这里不需要把所有通信都视为危险，更合理的做法是分层：执行者可以向协调器报告状态，审查者可以查看产物和证据，关键反对意见应在合并阶段保持可见。沙盒、权限和边界的更多细节，可以继续看 AI Agent 沙盒与手机权限：安全 Agent 为什么仍然需要边界，它能帮助区分隔离环境和真实权限控制。

设计独立的多智能体代码安全审查流程

一个实用流程可以从威胁模型开始。协调器先写清本次变更影响的资产、入口、信任边界和失败后果：是否处理身份认证、支付、个人数据、文件上传、远程命令、移动端权限、第三方 webhook 或后台任务。没有威胁模型，多智能体系统很容易把审查变成“看代码风格”和“跑测试”。安全审查要先问会被谁滥用、越权路径在哪里、错误结果能否恢复。

第二步是分离实现和复核。执行者提交最小 diff、测试说明、依赖变化、迁移说明和已知限制。审查者不参与实现过程，而是独立读取最终 diff，检查输入校验、认证授权、权限扩大、错误处理、日志与密钥暴露、第三方依赖、并发状态和回滚路径。审查者需要明确拒绝权：如果证据不足，可以要求补测试、缩小 diff、拆分 PR 或让人介入。

第三步是让证据来源多样化。实现者跑的测试不应是唯一证据；审查者可以运行不同命令、读不同文件、查依赖公告、构造反例、检查配置和查看 CI 结果。对于 Claude Code多智能体系统，执行者和审查者使用不同工作树或至少不同检查视角，会比共享同一中间推理更可靠。通过测试只能说明某些路径没有失败，不能证明系统安全。

第四步是人工合并与回滚准备。人合并前要看到实现摘要、审查者反对意见、测试证据、权限变化、部署步骤和回滚方案。高风险变更要有小流量、开关、日志观察和撤回计划。AI 代码审查智能体可以提高覆盖面和速度，但安全所有权仍在团队手里。Agent 给出建议，人确认风险，系统留下证据，这三者同时存在，流程才稳。

隔离共享工具、凭据、工作区、队列和预算

多智能体治理首先要控制能力快照：每个 Agent 在任务开始时能访问哪些文件、工具、凭据、外部服务和网络资源，应被明确记录。执行者不需要生产数据库凭据，审查者不需要部署权限，探索型 Agent 不需要写权限。最小权限不是一句口号，而是把每个角色和每个工具绑定到任务目标。

工作区隔离能减少共享可变状态带来的交叉风险。并行执行者最好使用独立 worktree、独立缓存、独立临时目录和可识别分支；测试数据库、消息队列和外部服务调用要使用隔离环境或模拟层。队列控制同样重要：同一时间谁能改同一文件，谁能触发 CI，谁能占用部署窗口，都需要所有权和锁。没有这些控制，多个 Agent 会把资源竞争伪装成智能协作。

预算和停止条件也属于安全控制。时间、token、工具调用次数、外部请求、测试重试次数和后台任务数量都应该有限制。Agent 失控时怎样隔离，答案不是只按一个停止按钮。停止可以阻止后续动作，却不能撤销已经发出的请求、删除的文件、推送的分支或触发的部署。因此流程需要“停止、检查、记录、恢复”四步：先冻结新动作，再查看已完成外部效果，随后保存证据，最后按回滚或补救方案处理。

手机 Agent 的任务队列也面对相似问题：多会话、会话绑定审批和停止恢复必须清楚。我们把这部分经验整理在 安卓 AI 智能体任务队列指南：多会话、任务隔离与会话绑定审批，它说明为什么队列不是体验细节，而是防止任务串线和误批准的核心结构。

把多智能体治理经验映射到 Android 手机 Agent

代码 Agent 的错误通常落在仓库、CI、依赖和部署环境里；手机 Agent 的错误会贴近用户生活，包括联系人、短信、位置、日历、通知、照片、账号和系统设置。因此，治理类比的重点不是架构名称，而是行动前后的控制点。代码侧要隔离 worktree、凭据和合并权；手机侧要隔离任务、权限、当前屏幕上下文、审批和恢复路径。

在 FoneClaw，我们把这些经验落实到受支持的 Android 手机任务里：用户提出目标，系统围绕当前状态和受支持动作准备步骤；涉及权限、对象选择或敏感影响时，界面给出可见批准点；任务运行中可以停止，失败后提供重试和权限恢复。我们的产品方向是让手机动作更可解释、更可控，而不是把自治包装成无限控制。

FoneClaw 当前能力和安装信息会持续在本地化页面维护。读者可以通过 FoneClaw 功能页查看受支持任务、审批、停止、重试和权限恢复等能力范围；准备安装或核对可用方式时，可以访问 FoneClaw 下载页。这些页面比文章更适合承载随产品变化的细节，本文关注的是治理原则如何帮助用户判断手机 Agent 是否可信。

这个类比也能帮助团队避免两个极端。一个极端是把 Agent 完全锁死，结果只能回答问题，不能帮用户推进任务；另一个极端是让 Agent 在手机上自由探索，结果没有责任边界。我们正在建设的是中间路径：支持的动作可以被规划和执行，重要影响需要用户批准，外部效果完成后要可见，失败时让用户知道卡在哪里。

多智能体代码审查发布前清单

运行前，先确认四件事：每个 Agent 的角色、工具、数据范围和停止条件是否明确；共享资源是否有所有者和锁；凭据是否按最小权限发放；审查者是否保留独立上下文和拒绝权。没有这些条件，多智能体代码安全与审查很容易变成快速但不可追责的自动化。

运行中，要求协调器记录任务边界、执行者输出最小 diff、审查者保留独立发现。遇到权限扩大、依赖变化、密钥风险、测试绕过、日志暴露或外部副作用时，先停下补证据。通信可以用于同步事实，但不要让审查者提前吸收执行者的全部结论。

合并前，人要看到完整证据：威胁模型、变更摘要、测试结果、审查异议、未解决风险、部署步骤和回滚路径。事故后，不要只问哪个 Agent 错了，还要复盘拓扑、共享资源、预算、停止条件和人工批准点。清单不能保证安全，但能让错误留下位置，让团队下次更早拦住它。