第 3 章 · 02 多代理编排

第 3 章 · 02 多代理编排

本节摘要:Strix 的 root agent 不是「一个全能代理自己干所有事」,而是一个编排层——它把目标拆成可并行的任务,按漏洞类/资产派生专门的专家子代理,自己只做调度、汇总、收尾,绝不亲自碰目标。这种「分工 + 并行 + 共享发现」的结构,让 Strix 能像真实渗透团队一样系统化覆盖复杂目标。本节讲清 root agent 的角色边界(它从不亲自跑扫描器/爬虫/fuzzer)、四步作用域分解、四类专家代理的分工架构、五条协调原则,以及最终如何把各代理发现去重聚合成报告。

内容来源:原项目文档 strix/skills/coordination/root_agent.md,汉化并套用体系化模板。

⚠️ 仅限授权测试:编排的所有代理仅在授权范围内活动;root agent 在派生前必须先确认边界。

学习目标

阅读完本节,你应当能够:

1. 说清 root agent 的角色边界——它是编排层,不亲自碰目标。
2. 描述四步作用域分解(识别攻击面 → 定边界 → 定方法 → 按风险排序)。
3. 列举四类专家代理架构(侦察 / 漏洞评估 / 利用与验证 / 报告)及其职责。
4. 掌握五条协调原则(任务独立、目标清晰、避免重复、分层委托、资源高效)。
5. 说明 root agent 如何聚合发现并产出最终报告。
6. 理解为什么复杂目标「必须靠多代理」而非单一代理穷尽。

一、root agent:只编排,不亲自测试

root agent 是 Strix 的编排层(orchestration layer)。它的唯一职责是协调专家子代理完成安全评估,但自己不直接做任何测试。原文有一条非常硬的边界:

你从不运行扫描器、爬虫或 fuzzer,也从不自己发送 exploit / 注入 payload——哪怕是对一个已发现端点做一次「快速基础测试」都不行。任何触碰目标的工作都委托给子代理。

这条边界的设计意图是专注与可控:

• root agent 保持全局视角,不被具体测试细节淹没;
• 测试动作由专门代理执行,每个代理的工具集、上下文、预算相互隔离;
• 并行执行——多个专家代理同时干活,比单代理串行快得多。

而且代理可以在整个测试过程中动态创建,不限于开头——随着新发现出现、范围演变,root agent 随时派生新的专家代理处理。

⚠️ 记住这条红线:root agent 永远不亲自发 payload。哪怕看起来「就试一下」,也要派一个子代理去做。这条纪律保证了编排层和执行层的清晰分离。

二、四步作用域分解

派生代理之前,root agent 先对目标做作用域分解。注意:它做分解的依据是扫描配置/作用域、提供的上下文,以及(侦察子代理上报后的)侦察结果——不是自己跑侦察工具。

作用域分解四步
┌─────────────────────────────────────────────┐
│ 1. 识别攻击面  web 应用 / API / 基础设施 ...  │
│ 2. 划定边界    范围内域名、IP 段、排除资产      │
│ 3. 确定方法    黑盒 / 灰盒 / 白盒             │
│ 4. 按风险排序  关键资产与高价值目标优先         │
└─────────────────────────────────────────────┘
​

四步的要点:

1. 识别攻击面:Web 应用、API、基础设施、云资源……把目标拆成几类可独立处理的资产。
2. 划定边界:明确哪些域名/IP 段在范围内、哪些资产被排除——这是后续避免越权扫描的依据。
3. 确定方法:黑盒(纯外部)、灰盒(带凭据)、白盒(有源码)。方法决定派哪些类型的子代理。
4. 按风险排序:关键资产和高价值目标(认证服务、支付、管理面板、含敏感数据的 API)排在前面,优先分配预算与轮次。

💡 黑盒 vs 白盒的派生差异:黑盒下,侦察与资产发现子代理是主力;白盒下,源码分析与静态分诊子代理先上,动态验证随后。白盒的专门协调策略见下一节「source-aware 白盒协调」。

三、专家代理架构:按功能分层

root agent 按功能把代理分成四层。每一层有明确职责,层与层之间通过发现(findings)传递工作:

3.1 侦察层(Reconnaissance)

• 资产发现与枚举(子域名、端口、服务)
• 技术指纹识别(Web 框架、服务器、CDN/WAF)
• 攻击面映射(把零散资产整理成可测试的目标清单)

3.2 漏洞评估层(Vulnerability Assessment)

• 注入测试(SQLi、XSS、命令注入)
• 认证与会话分析(JWT、会话管理、OAuth)
• 访问控制测试(IDOR、越权)
• 业务逻辑缺陷(竞争条件、流程操纵)
• 基础设施漏洞(配置错误、暴露服务)

3.3 利用与验证层(Exploitation and Validation)

• PoC 开发(写可复现的概念验证)
• 影响演示(证明漏洞真实可利用、有实际危害)
• 漏洞链(vulnerability chaining,把多个低危串成高危)

3.4 报告层(Reporting)

• 发现文档化(记录复现步骤)
• 修复建议(给出整改方向)

💡 分层的意义:每一层的输出是下一层的输入。侦察层产出「目标清单」喂给漏洞评估;漏洞评估的「疑似漏洞」喂给利用与验证层证实;证实的漏洞交报告层落档。这种流水线让每个代理专注于自己的领域,就像真实渗透团队里有人专攻侦察、有人专攻 Web、有人专攻认证。

四、五条协调原则

root agent 怎么把代理管好?靠五条协调原则:

4.1 任务独立性(Task Independence)

派生依赖最小的代理。能并行的绝不串行——并行执行比顺序执行快得多。设计任务时,优先把它们拆成互不阻塞的独立单元。

4.2 目标清晰(Clear Objectives)

每个代理都该有一个具体、可衡量的目标。模糊的目标会导致范围蔓延(scope creep)和重复劳动。「测这个 API 的注入」是模糊的;「测 /api/users/<id> 的 id 参数是否存在 SQL 注入,用 sqlmap 验证,产出 PoC」是清晰的。

4.3 避免重复(Avoid Duplication)

派生前先做三件事:

1. 分析目标作用域,拆成独立任务;
2. 检查已有代理,避免重叠;
3. 用清晰、具体的目标创建代理。

⚠️ 重复是最大的浪费:两个代理测同一个端点的同一个漏洞,既烧预算又烧轮次。root agent 在派生前必须核对「这件事有没有人已经在做」。

4.4 分层委托(Hierarchical Delegation)

复杂发现值得派专门的子代理接力:

• 发现代理找到潜在漏洞;
• 验证代理证实可利用性;
• 报告代理记录复现步骤,并内联给出修复——报告工具通过 code_locations / fix_pr_body 字段携带补丁,不要再单独加一个「修复代理」去重新推导同一份补丁。

💡 修复内联,不另起代理:报告代理本身就携带修复(code_locations / fix_pr_body)。另立一个「修复代理」会重复推导同一份补丁,纯属浪费。

4.5 资源高效(Resource Efficiency)

• 避免跨代理的重复覆盖;
• 目标达成或不再相关时,终止代理;
• 只在必要时用消息传递(请求/应答、关键交接);
• 优先批量更新,而非频繁的例行状态消息。

五、动态派生与完成收尾

5.1 随发现动态派生

代理不是一次性全派好。随着测试推进、新发现出现、范围演变,root agent 随时派生新代理。比如:

• 侦察代理发现一个未授权的管理面板 → 派一个弱口令检测代理;
• 漏洞评估代理确认一个 SSRF → 派一个利用代理做内网探测的 PoC;
• 发现一批新子域名 → 派一个专门的资产发现代理。

5.2 完成与聚合

当所有代理上报完成,root agent 执行四步收尾:

1. 收集并去重跨代理的发现——不同代理可能报告同一漏洞,需合并;
2. 评估整体安全态势——不只看单个漏洞,看组合风险;
3. 编写执行摘要,附按优先级排序的整改建议;
4. 调用 finish 工具产出最终报告。

所有代理完成
      │
      ▼
┌──────────────────────────────────┐
│ 1. 收集 + 去重发现                │
│ 2. 评估整体安全态势               │
│ 3. 编写执行摘要 + 优先级建议       │
│ 4. 调用 finish 产出最终报告        │
└──────────────────────────────────┘
​

六、为什么复杂目标必须靠多代理

单一代理在面对复杂目标时会撞上几堵墙:

• 上下文窗口有限——一个代理塞不下整个大目标的全部细节;
• 专注度稀释——一个代理同时管 SQLi、XSS、认证、业务逻辑,每样都做不深;
• 无法并行——单代理串行,大目标耗时爆炸;
• 预算/轮次吃紧——所有工作挤在一个代理的配额里,容易触顶。

多代理架构逐一化解:按漏洞类/资产切分,每个代理上下文聚焦、专注单一领域;并行执行缩短总时长;预算与轮次按代理分配(--max-budget 跨所有代理累计,--max-turns 按代理计,见第 2 章 CLI 参考)。这就是为什么 Strix 的多代理不是「锦上添花」,而是处理复杂目标的必要结构。

💡 成本控制的配合:--max-budget 跨根代理与所有子代理累计计算,无头模式下子代理在 90% 预算处停止、留最后一段给根代理收尾。这套机制和本节的编排原则是配套的——分工越细,越需要全局预算闸门。

本节要点回顾

1. 角色边界:root agent 是编排层,只协调不测试——从不亲自跑扫描器/爬虫/fuzzer、不发 payload,哪怕「快速试一下」也不行。
2. 动态派生:代理可在整个测试过程中创建,随发现与范围演变随时派生新专家代理。
3. 四步作用域分解:识别攻击面 → 划定边界 → 确定方法(黑/灰/白盒)→ 按风险排序,依据是配置/上下文/侦察结果,而非自己跑工具。
4. 四层专家架构:侦察(资产/指纹/攻击面)、漏洞评估(注入/认证/访问控制/业务逻辑/基础设施)、利用与验证(PoC/影响/漏洞链)、报告(文档化/修复)——层间靠发现传递。
5. 五条协调原则:任务独立性(能并行不串行)、目标清晰(具体可衡量)、避免重复(派生前核对)、分层委托(发现→验证→报告,修复内联不另起代理)、资源高效(批量更新、及时终止)。
6. 完成收尾四步:收集去重 → 评估整体态势 → 执行摘要 + 优先级建议 → 调用 finish 产出报告。
7. 必要性:复杂目标的上下文/专注度/并行/预算四重压力,决定了多代理不是可选优化,而是必要结构。

下一节,我们看有源码时这套编排怎么升级——source-aware 白盒协调用静态分诊排优先级、动态验证坐实,让白盒覆盖更系统。