Agent Team 工程实践¶

Ch07.023 三层 Agent 架构：Skill / SubAgent / Agent Team 工程实践¶

📊 Level ⭐⭐ | 10.5KB | entities/baidu-netdisk-three-layer-agent-architecture.md

三层职责分层¶

| 层级 | 定位 | 解决的问题 | 适用场景 | ].md] |------|------|-----------|---------| ].md] | Skill | 执行单元（无状态） | 单点执行不稳定，同一件事做十遍结果不一样 | 具体执行动作的规范化 | ].md] | SubAgent | 串行调度（带 Memory） | 长链路上下文膨胀，幻觉 | 有前后依赖的步骤串行 | ].md] | Agent Team | 并行协作（Mailbox） | 多类型任务串行效率低 | 无强依赖的任务并行 | ].md] 整体方案的稳定性，最终由 Skill 的规范质量决定。SubAgent 和 Agent Team 提供的是调度骨架，骨架上每个节点能不能稳定输出，取决于 Skill 本身有没有真正约束执行过程，而不只是描述了执行目标。 ].md]

Skill：执行稳定性的核心¶

Skill 把一类任务的执行方式写成可复用的规范文件，AI 调用时按规范走，不再每次重新理解。它是无状态的，没有对话历史，只做一件事——被调用时稳定输出。 ].md] 最有用的约束：Checklist ].md] 把每个步骤拆成可以逐项打勾的检查项。AI 在多步骤任务里很容易跳步，有了 Checklist，每完成一步对照一项，遗漏率明显下降。 ].md] 关键设计：extractor→validator→fixer 三层拆分 ].md] 把提取和校验写在同一个 Skill 里，AI 会"自己审查自己"，天然倾向于认为结果没问题。后来拆成三个独立 Skill： ].md]

extractor：以调用语句为入口扫描依赖，生成初始提取包
validator：独立校验提取结果，关注"还缺什么"而不是"提了什么"
fixer：只处理 validator 指出的缺口，定向补充这个"提取→校验→修复"的三层结构，后来在代码转化阶段也沿用了：converter → validator → fixer，证明这个拆分逻辑是通用的。 ].md] Skill 不是提前规划出来的，而是被真实错误倒逼出来的——某个场景反复出错、发现"这类问题每次都要纠正"时，就是需要固化成 Skill 的信号。 ].md]

SubAgent：上下文隔离与 Memory 传递¶

SubAgent 解决长链路任务中的上下文膨胀问题。把长链路任务按步骤拆开，每个步骤交给一个 SubAgent 处理，各自有完全隔离的上下文，互不干扰。 ].md] 上下文隔离的代价：SubAgent 之间信息割裂，后续步骤不知道前序步骤做了什么。 ].md] 解决：Agent-Memory 机制 ].md] 每个 SubAgent 完成工作后，把关键信息提炼成结构化文件存下来，下一个 SubAgent 启动时读取这份文件，在自己的独立上下文里继续推进。 ].md] Memory 文件的关键区别：不是对话记录的备份，而是"后续步骤需要什么"的提炼。有效的做法是只提炼结构化的关键信息，比如资源映射表、模块结构配置、已确认的接口契约。 ].md] 判断标准：这个步骤的输入，是不是依赖上一个步骤的产出？是就用 SubAgent 拆开，步骤之间通过 Memory 传递关键信息。及早拆分任务，比等到幻觉出现再排查效率高很多。 ].md]

Agent Team：四路并行与 Mailbox 协调¶

Agent Team 把四类提取任务（UI 组件、布局文件、业务逻辑、资源文件）分给四个专业 Teammate 并行执行，各自独立上下文，只关注自己负责的那类文件。 ].md] 并行相比串行的核心优势：总耗时接近四类任务里最慢的那条路径，而不是四段累加。但更重要的是专注度提升带来的提取质量改善——一个 Teammate 只盯一类文件，对该类型的依赖模式会建立更强的识别，这是混合处理时很难做到的。 ].md] 跨 Teammate 依赖：Mailbox 消息通道 ].md] 四路并行并不是完全独立的。实际会遇到跨类型依赖（UI 发现 Dialog 需补充布局、业务发现字符串资源需补充）。通过 Mailbox 消息通道实时处理，不需要等一个提取全部完成再补充。 ].md]

核心设计原则¶

任务间有没有强依赖是唯一选型依据：有依赖需要串行 → SubAgent；没有强依赖可以并行 → Agent Team；具体执行动作 → Skill ].md]
Memory 要提炼不要备份：传递"后续步骤需要消费的结构化信息"，而非聊天记录原样 ].md]
上下文膨胀的临界点比想象中早：漂移比崩溃更危险，及早拆分任务更划算 ].md]
Skill 的质量决定整体稳定性：骨架上每个节点能不能稳定输出，取决于 Skill 有没有真正约束执行过程 ].md]

深度分析¶

三层架构揭示 AI 工程化的核心矛盾：执行稳定性与上下文管理的权衡 ].md] Skill 解决"同一件事做十遍结果不一样"，SubAgent 解决"任务链路越长幻觉越多"，Agent Team 解决"并行任务串行处理效率低"。这三个问题并非独立，而是 AI 在复杂工程场景下必然遇到的递进挑战——执行层的不稳定会累积成上下文层的幻觉，上下文膨胀又制约了并行协作的可能性。三层架构的价值在于为每一层提供了针对性的解法，而非试图用单一机制应对所有问题。 ].md]
extractor→validator→fixer 模式是跨场景通用的质量门禁设计 ].md] 这个三元组最初用于解决"AI 自己审查自己"的心理盲区——当提取和校验在同一个 Agent 内完成，Agent 会天然认为自己的输出没问题。后来这个模式被代码转化阶段直接复用（converter → validator → fixer），证明其结构与具体任务类型无关，本质是一种"生成→独立校验→定向修复"的流水线设计。它解决的问题本质是：让生成者和校验者拥有独立的评估视角。 ].md]
Memory 的设计哲学是架构解耦的关键：SubAgent 之间不传递历史，只传递结构化的后续消费信息 ].md] 网盘案例中，UI 转化 SubAgent 必须知道资源映射表才能准确处理引用，但不需要知道资源提取过程中的对话细节。这个区别非常重要：Memory 文件的设计目标是支撑下游步骤的执行，而不是记录上游步骤的执行过程。这意味着 Memory 的内容应该由下游步骤的输入需求反推得出，而非由上游步骤自行决定输出什么。 ].md]
Agent Team 的专注度提升收益往往被低估：并行不只是效率问题，更是质量保险 ].md] 四个 Teammate 各司其职带来的质量改善，比时间缩短更难量化但更值得关注。当一个 Agent 同时处理 UI、布局、业务、资源四类文件时，它的注意力是分散的，对每类文件的依赖模式认知是浅层的。而专注布局的 Teammate 对 include 嵌套引用的识别准确率会显著高于通用 Agent。这种专注度形成的模式识别能力，是并行架构独有的隐性收益。 ].md]
上下文膨胀的隐蔽性在于漂移而非崩溃：幻觉的早期症状极难察觉 ].md] 幻觉出现时不是突然全错，而是逐渐偏离——每一步的输出看起来都还在合理范围内，直到最后才发现方向已经不对。这个特性使得上下文膨胀比明显的崩溃更难处理，因为它推迟了问题的发现时机。"及早拆分任务"的本质是在漂移幅度尚小、定位成本尚低时主动制造断点，而非等到问题暴露再被动排查。 ].md]

实践启示¶

从第一个真实错误开始设计 Skill，而非从预期行为出发 ].md] 规范的边界条件不是规划出来的，是踩出来的。某个场景反复出错、每次都要手动纠正时，才是固化 Skill 的最佳时机——此时团队已经清楚问题所在，规则的适用范围和限制也最明确。先用粗糙流程跑通全链路，再把高频出错点逐一固化成 Skill，是更高效的演进路径。 ].md]
Memory 文件由下游需求驱动设计，而非上游自行决定 ].md] 在设计 SubAgent 间的 Memory 传递时，应该先问"下游步骤真正需要什么输入才能正确执行"，再据此设计 Memory 的结构和内容。如果只把对话记录原样存下来再读进去，上下文一样会膨胀。有效的做法是：下游 SubAgent 启动时，其 prompt 中应该已经包含了前序步骤产出的结构化信息，而非需要自己去解析的非结构化记录。 ].md]
用单依赖判断作为架构选型的唯一准则，消除选型时的过度思考 ].md] "这个步骤的输入是不是依赖上一个步骤的产出"是判断 SubAgent vs Agent Team 的唯一准则。不需要考虑任务复杂度、文件数量或模型能力——这些因素只会增加选型的不确定性。强依赖串行，弱依赖并行，这个规则足够简单，也足够稳定。 ].md]
为 Teammate 间的跨类型依赖预留 Mailbox 机制，而非假设完全独立 ].md] 即使任务看起来可以完全并行，实际运行中总会出现跨类型依赖（UI 发现 Dialog 需补充布局、业务发现缺字符串资源）。Agent Team 设计阶段就应该预留 Mailbox 消息通道，否则跨依赖只能通过重新启动一轮任务来解决，代价极高。Mailbox 的实现可以是共享文件、消息队列或任何异步通信机制，关键是解耦发送和接收的时序。 ].md]
在提取阶段投入足够的 Skill 规范，因为后续所有阶段都依赖它 ].md] 整体方案的稳定性由 Skill 的规范质量决定，SubAgent 和 Agent Team 提供的是调度骨架，骨架上每个节点能不能稳定输出，取决于 Skill 有没有真正约束执行过程。这意味着在三层架构中，Skill 层的基础设施投入回报率最高——一个 extractor Skill 的改进会同时惠及所有使用它的 Teammate 和 SubAgent。 ].md]