加餐-子代理专题总结&春节练习

你好，我是黄佳。春节即将到来，预祝你假期愉快。

今天的加餐我们对前六讲子代理的专题做个简要总结，并宣布一下假期的安排和练习作业。

子代理专题总结

经过六讲的学习，你已经掌握了子代理的完整知识体系。

我们可以把整个体系分为两层能力：

第一层： 结构化分工（Sub-Agents）
第二层： 协作型认知（Agent Teams）

Sub-Agents 解决的是“工程控制问题”，也就是“单脑如何安全分工”。 之后我们掌握了子代理的四种使用模式。

单独使用
    ↓
┌────────────────────────────┐
│  只读型（代码审查）          │
│  高噪声（测试/日志）         │
└────────────────────────────┘
    ↓
并行 / 流水线
    ↓
┌────────────────────────────┐
│  并行探索（独立任务）        │
│  流水线编排（依赖任务）      │
│  混合模式（部分独立+部分依赖）│
└────────────────────────────┘

Sub-Agents 应用场景是上下文污染、权限边界、高噪声干扰、阶段性分工和可控编排。

Agent Teams 解决的是“认知协作问题”，也就是多脑如何互相挑战。

当任务之间不只是 执行依赖 ，而是 认知依赖 时，并行已经不够了。

例如：

多个假设可能互相关联
不同视角可能互相推翻
架构决策需要立场冲突
根因链需要跨模块拼接

这时就要进入 Agent Teams。

                 Team Lead
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
    Teammate A  ↔  Teammate B  ↔  Teammate C

Agent Teams 应用场景是锚定偏见、单视角误判、过早收敛和决策质量不足等。

各种模式的综合运用：一个完整案例

在第 5 至 7 讲，我们学习了四种子代理。让我们用一个完整案例把它们串起来。

场景：你的电商系统在大促期间出现了“支付超时”问题，需要排查并修复。

第一阶段：并行探索（了解现状）

同时启动三个只读型探索子代理：
├── payment-explorer: 分析支付链路代码
├── order-explorer: 分析订单处理流程
└── infra-explorer: 分析基础设施配置（超时设置、连接池等）

这里同时运用了 并行模式 （三个同时工作）和 只读型 （只看不改）。

第二阶段：高噪声处理（收集线索）

启动两个高噪声处理子代理：
├── log-analyzer: 分析大促期间的错误日志（可能几万行）
└── test-runner: 跑支付相关的测试看看有没有失败

这里运用了 高噪声处理模式 ——日志和测试输出都是典型的高噪声场景。

第三阶段：假设竞争（Agent Teams 介入）

这一步如果只用 Sub-Agents，风险是什么？每个子代理只向主对话汇报。是否会出现 infra 的连接池问题，N+1 查询是否可能存在级联关系。

第四阶段：流水线修复（解决问题）

基于前两阶段的信息，启动修复流水线：
Locator → Analyzer → [人工审批] → Fixer → Verifier

这里运用了 流水线模式 ，并在关键阶段设置人工审批。

第五阶段：并行验证（确认修复）

修复后，并行验证：
├── test-runner: 跑全量测试
├── performance-checker: 验证超时是否解决
└── code-reviewer: 审查修复代码的质量

整体编排

Phase 1: Parallel Explore (只读)
    ↓ 综合三份探索报告
Phase 2: Parallel Noise-filter (只读)
    ↓ 综合日志分析和测试结果
Phase 3: Hypothesis Debate (Agent Teams)
    ↓ 团队协作讨论
Phase 4: Sequential Pipeline (读写)
    ↓ 修复完成
Phase 5: Parallel Verify (只读+执行)
    ↓ 确认修复有效
Done

注意每个阶段的权限变化 ：只有 Phase 4 的 Fixer 有写权限，其他所有子代理都是只读的。这就是第 3 讲中“最小权限原则”在复杂场景中的体现。 贯穿始终的工程方法论 ：

第 5 讲的方法论：痛点驱动设计（痛点→缺什么→选机制→画边界→验证）
第 6 讲的方法论：信噪比框架 + 输出格式设计 + 模型选择验证
第 7 讲的方法论：交接契约 + 编排者决策 + 混合模式选型

共同主线：不是"学会配置子代理"，而是"面对任何工程场景，
         能判断是否需要子代理、需要什么样的子代理、如何组合它们"

春节假期作业

春节即将到来，预祝你假期愉快。按照我们的课程安排，春节假期（2.16～2.22）这一周会暂停更新，你可以利用这个时间回顾前面的课程，查漏补缺。这里我也准备了两个综合性的思考题与你探讨。假期之后，我们将开启“ Skills 技能系统 ”的学习，敬请期待。

参考“各种模式的综合运用”案例，为你自己项目中的一个复杂问题设计完整的子代理编排方案。要求：

明确用了哪些模式
标注每个子代理的权限
标注人工介入点

回到“电商大促支付超时”这个完整案例，假设 **不使用任何子代理** ，而是只在主对话中让 AI 一步步帮你排查和修复，请回答：
- 在 Phase 1（问题探索）阶段，哪些信息最容易被遗漏或相互覆盖？为什么？
- 在 Phase 2（日志 / 测试分析）阶段，高噪声输出会对后续判断产生哪些具体干扰？
- 在 Phase 4（修复阶段），如果没有权限隔离，AI“好心修改”可能带来哪些工程风险？
- 从审计、回滚、团队协作的角度看，这种“单对话全包”的方式有哪些不可控点？
最后，请用一句话总结： 子代理真正解决的是不是“能力问题”，还是哪一类“工程风险”？

Quartz

探索