Harness架构深度拆解：PPAF与REPL思维下的Lead-Agent与Sub-Agent协同

DeerFlow 2.0：Lead Agent 与 Sub-Agent 配合机制与使用决策指南

在 DeerFlow 2.0 主从架构中，Lead Agent 是全局调度中枢，Sub-Agent 是专项执行单元。

两者的配合遵循 “统筹—执行—汇总” 的闭环逻辑，而是否启用 Sub-Agent 核心取决于任务复杂度、执行风险、资源开销与上下文隔离需求。

DeerFlow 2.0 主从架构是 PPAF 智能体执行范式 （感知-规划-行动-反思）的工程化落地。

Lead Agent 与 Sub-Agent 分别承担 PPAF 不同环节的核心职责，同时依托“造、驭、相、育”四步工程化支撑体系，实现智能体协作的稳定、高效与可迭代。

Harness 对应“造缰、驭马、相马、育马”四步支撑法，每一步都对应 PPAF 的核心环节，精准解决“工程落地难”的问题：

• 造缰（Making the Reins）：给智能体“套上缰绳”，定义清晰的接口、协议和约束。比如规定智能体能接收什么格式的输入、能调用哪些工具、输出什么格式的结果，避免智能体“越界”，支撑 PPAF 的“感知”环节（确保采集的信息规范、安全）。
• 驭马（Riding the Horse）：驾驭智能体按规划执行，实现策略、调度与执行控制。比如智能体规划好要调用 3 个子代理，“驭马”就负责安排哪个先执行、哪个后执行，执行过程中遇到问题如何处理，支撑 PPAF 的“规划”和“行动”环节。
• 相马（Evaluating the Horse）：观察和评估智能体的表现，建立监控、度量体系。比如实时查看智能体的执行状态（是否卡住、是否报错）、Token 使用量、任务完成率，支撑 PPAF 的“反思”环节（通过评估结果发现问题、修正策略）。
• 育马（Breeding the Horse）：让智能体持续进化，构建记忆、训练、迭代体系。比如把每次任务的复盘经验存入记忆，定期优化模型和策略，让智能体越用越精准，支撑 PPAF 的“反思”和“长期感知”环节。

下面从协作原理、配合流程、使用场景（必须用 / 不建议用 / 可不用）、决策判断标准、工程化支撑、源码示例六方面完整说明。

基础知识（1）：PPAF 智能体执行范式

PPAF 智能体执行范式与 REPL 容器对接工程，是 Harness 平台层 （包括 DeerFlow 2.0） 主从代理架构实现工程化落地的核心架构思维支撑。

二者深度融合，既保障智能体的自主决策能力，又实现执行过程的可控、可观测与可迭代。

PPAF智能体执行范式 ，主要包括4个环节： Perception感知、Planning规划、Action行动、Feedback/Reflection反思。

PPAF智能体执行范式 ， 是智能体执行任务的标准工程闭环框架，构建了“感知→规划→行动→反思”的完整循环。

• 感知作为基础起点，通过各类接口采集用户指令、系统状态等全量信息；
• 规划作为核心大脑，由LLM主导任务拆解、路径规划与资源分配；
• 行动作为落地载体，通过调用工具、执行代码等方式实现交互落地；
• 反思作为优化闭环，通过结果校验、偏差修正与经验沉淀，推动智能体持续进化。

PPAF智能体执行范式，可以完整对应到 Harness 平台层 对应的 “造缰、驭马、相马、育马”四步法支撑体系，分别为感知、规划与行动、反思、反思与记忆环节提供边界约束、调度控制、评估观测与迭代优化能力。

基础知识（2）： REPL 循环容器

REPL 循环容器， 包括四环节：Read(读取) -Eval(评估) -Print(打印) -Loop(循环 ) 。

REPL 循环容器， 是PPAF 实现工程化落地 实现.

REPL 循环容器 本质是: 一个带有严格边界控制、智能工具路由与确定性反馈机制的管控容器。

REPL 循环容器 核心: 是一个 包裹住大语言模型（LLM）这个非确定性的“智能大脑”，将LLM 灵活的推理能力 ，与确定性的 工程执行体系进行无缝衔接。

REPL 循环容器 核心: 不确定性的 大语言模型（LLM） + 确定性的API调用。

REPL 循环容器 与 PPAF 智能体执行范式 的关系是什么呢？

• REPL 循环容器， 是 PPAF 落地层面的 设计思维与模式，
• PPAF 是 天上飞的指导思想，REPL 循环容器 地上跑的落地规范，
• REPL 循环容器 让PPAF 的“感知→规划→行动→反思”闭环能够稳定、可控地落地。

DeerFlow 2.0 是 REPL 循环容器 的一个具体的落地， DeerFlow 2.0 中的REPL容器经过工程化适配，深度融入“造、驭、相、育”四步法支撑体系。

REPL 循环容器， 其核心逻辑与PPAF各环节的耦合的细节的如下：

（1） Read（读取）环节

Read（读取）环节 是REPL容器 对应 PPAF感知环节的核心入口，主要由上下文管理器（Context Manager）负责执行。

该环节的核心任务是完成“信息标准化”，将外部世界的零散信息与内部记忆进行整合、清洗与结构化处理，最终转化为LLM能够精准理解的Prompt格式。

外部世界的零散信息 包括用户指令、外部API返回的结构化数据、系统内部监控指标。内部记忆 包括 历史对话记录、过往执行经验。

这一过程完美契合“造缰”工程化支撑的核心目标——为感知环节提供清晰、稳定的输入通道，确保PPAF感知环节采集的信息全面、准确、结构化，为后续规划环节奠定基础。

（2） Eval（评估/执行）环节

Eval（评估/执行）环节 是REPL容器对应 PPAF规划与行动环节的核心载体，由调用拦截器（Call Interceptor）与工具执行器协同完成。

当LLM基于Read环节的结构化Prompt，生成规划意图（如任务拆解方案、工具调用指令等）时，调用拦截器会实时捕获这一意图，首先对意图的合理性、安全性进行校验（贴合“造缰”的边界约束要求），随后根据规划意图的类型，将其精准路由至对应的工具执行器。

在工具执行过程中，REPL容器会对执行全流程进行严密监控，包括执行超时控制、资源配额限制、异常捕获与熔断处理，这既体现了“驭马”工程化支撑的调度控制能力，也通过过程监控为“相马”环节的评估提供了实时数据支撑，确保PPAF行动环节的执行精准、安全、高效。

（3) Print（打印/反馈）环节

是REPL容器 对应 PPAF反思环节的关键纽带，由 反馈汇编器（Feedback Assembler）负责实现。

当工具执行完成后，无论执行成功（返回结构化数据）还是失败（返回异常信息），反馈汇编器都会及时捕获这些执行结果，将其组装成标准化、结构化的“观测结果”，并重新注入到系统上下文中，供LLM进行下一轮的反思与规划。

这一过程既为PPAF反思环节提供了客观、全面的反馈数据，也契合“相马”工程化支撑的评估需求，让LLM能够清晰掌握行动执行的实际情况，为偏差修正、策略调整提供依据。

(4) Loop（循环）环节

是驱动PPAF闭环持续运转的核心动力，也是REPL容器的核心特性。

Read-Eval-Print三个环节并非一次性执行，而是在REPL容器的控制下持续循环推进：LLM基于Print环节的反馈结果进行反思，调整规划策略，随后触发新一轮的Read环节（读取更新后的上下文与规划意图）、Eval环节（执行新的行动指令）、Print环节（反馈新的执行结果），直至智能体达成任务目标、触发终止条件（如任务完成、执行失败超时）.

整个循环过程完美复刻了PPAF“感知→规划→行动→反思”的持续迭代逻辑，也让“育马”工程化支撑的迭代优化能力得以落地: 每一次循环中的经验与偏差，都会被系统记录并沉淀为记忆，用于后续任务的优化。

为何将 REPL 称为循环容器？

在 Harness 平台（DeerFlow 2.0）的语境下，将 REPL 称为“循环容器”，并不是指它仅仅是一个简单的代码运行环境，而是借用了计算机科学中“容器”的深层含义——边界控制、环境隔离与生命周期管理。

尼恩提示：原文1w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。

完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，找尼恩获取

PPAF、REPL 与“Harness 四步法”思维的对照关系

• PPAF 提供了智能体运作的逻辑蓝图。
• REPL 提供了工程化落地的容器标准。
• “四步法” 则是 Harness 平台在 REPL 容器内部署的具体管控策略，确保了智能体既有自主决策的灵活性，又有工程执行的稳定性。

PPAF 环节	REPL 容器环节	核心组件/动作	对应“四步法”	工程化价值
感知	Read (读取)	上下文管理器 信息标准化	造缰 (边界约束)	确保输入清晰、稳定，为智能体套上“缰绳”，防止信息噪声干扰。
规划 & 行动	Eval (评估/执行)	调用拦截器 工具执行器	驭马 (调度控制)	在行动前进行安全校验与路由，在执行中进行资源与超时控制，确保“驾驭”风险。
反思	Print (打印/反馈)	反馈汇编器 观测结果注入	相马 (评估观测)	将执行结果转化为客观的“观测数据”，用于评估行动质量，识别“良马”与策略优劣。
闭环迭代	Loop (循环)	循环控制 记忆沉淀	育马 (迭代优化)	通过不断的循环执行，将经验沉淀为记忆，实现智能体的持续进化与“培育”。

1. Harness 造缰：为感知（Perception）与读取（Read）设定边界

对应关系： PPAF 的感知 →→ REPL 的 Read。

如何运作：

“造缰”的核心在于边界约束。在 REPL 的 Read 环节，上下文管理器（Context Manager）不仅仅是读取数据，更是在“清洗”和“标准化”数据。它将外部零散的用户指令、API 数据转化为 LLM 能精准理解的 Prompt。

价值：

就像给马套上缰绳一样，这一步确保了智能体接收到的信息是结构化、无噪声的，防止 LLM 因为输入混乱而产生幻觉或错误理解，为后续的规划打下坚实基础。

2. Harness 驭马：管控规划（Planning）与行动（Action）及评估（Eval）

对应关系： PPAF 的规划/行动 →→ REPL 的 Eval。

如何运作：

“驭马”的核心在于调度控制。当 LLM 在 Eval 环节生成意图后，调用拦截器（Call Interceptor）会立即介入。它不仅要路由工具，更要进行安全校验（意图是否合理？）和过程监控（是否超时？资源是否超标？）。

价值：

这一步将 LLM 的“非确定性推理”关进了“确定性执行”的笼子里。它确保了智能体的行动是安全的、可控的，不会因为错误的规划导致系统崩溃或无限循环。

3. Harness 相马：通过反馈（Feedback）与打印（Print）进行评估

对应关系： PPAF 的反思 →→ REPL 的 Print。

如何运作：

“相马”的核心在于评估观测。Print 环节通过反馈汇编器（Feedback Assembler）将工具执行的结果（无论是成功数据还是异常报错）封装成标准化的“观测结果”。

价值：

这相当于伯乐在观察马的奔跑姿态。系统通过 Print 环节获得客观的执行反馈，LLM 才能据此判断刚才的行动是否正确，从而进行有效的反思。没有这个环节，智能体就是“盲人摸象”，无法感知行动后果。

4. Harness 育马：驱动闭环（Loop）与持续进化

对应关系： PPAF 的持续迭代 →→ REPL 的 Loop。

如何运作： “育马”的核心在于迭代优化。Loop 环节不是简单的重复，而是带着“记忆”的循环。每一次 Read-Eval-Print 产生的经验和偏差都会被记录。

价值： 通过不断的循环，智能体能够基于历史反馈调整策略。这种机制让系统具备了成长性，每一次任务的执行都在“培育”智能体，使其在未来处理类似任务时更加高效。

DeerFlow 源码中，Lead Agent 与 Sub-Agent 如何配合？

DeerFlow 2.0 主从代理的协作逻辑，完全贴合 PPAF（Perception 感知、Planning 规划、Action 行动、Feedback/Reflection 反思）智能体执行闭环模型，其中 Lead Agent 主导“感知、规划、反思”三大核心环节，Sub-Agent 专注于“行动”环节的专项落地，两者通过严格解耦实现高效协同，同时依托“造、驭、相、育”工程化体系，确保协作的边界可控、调度有序、可观测可迭代。

Lead Agent（主代理）： PPAF 闭环的“大脑中枢”，承载“造缰、驭马、相马、育马”核心职责

不执行具体工具 / 代码 / 操作，只专注于全局决策与闭环管控，是 PPAF 模型中“感知、规划、反思”环节的核心载体，同时承担“造、驭、相、育”四步工程化支撑的核心职责，具体如下：

核心职责（对应PPAF闭环）：

• 感知（Perception）：精准解析用户意图、采集任务相关的全量信息（包括用户指令、历史对话、系统状态等），对应“造缰”工程维度的接口标准化输入，确保感知的全面性与准确性；
• 规划（Planning）：对复杂任务进行拆解、筛选适配的 Sub-Agent、规划执行路径（同步/异步）、分配资源，对应“驭马”工程维度的策略与调度控制，确保规划的合理性与高效性；
• 反思（Feedback/Reflection）：验收 Sub-Agent 的执行结果、消解执行过程中的冲突、修正执行偏差，同时将执行经验与偏差信息纳入记忆体系，对应“相马”（评估观测）与“育马”（迭代优化）工程维度，实现闭环迭代；
• 全局管控：持有完整全局状态、全量工具权限、最高调度权，对接 LangGraph 图执行，控制整个 PPAF 闭环的流程走向与终止条件，确保全局可控。

工程化定位：

作为 Harness 工程化体系的核心载体，承担 REPL 容器的“Read（读取）、Eval（评估）、Print（反馈）、Loop（循环）”全局管控职责，将 LLM 的非确定性推理能力，接入到确定性的工程执行体系中。

Sub-Agent（子代理）： PPAF 闭环的“执行终端”，依托工程化体系实现安全高效行动

具备专项能力、最小权限、沙箱隔离特性，专注于 PPAF 模型中“行动”环节的专项落地，是“驭马”（执行控制）与“造缰”（边界约束）工程维度的具体体现，具体如下：

核心职责（对应PPAF闭环）：

• 行动（Action）：接收 Lead Agent 分配的子任务，在沙箱环境中独立执行（调用专项工具、执行代码、处理专项任务），并以结构化形式返回执行结果，不干预全局 PPAF 闭环流程；
• 边界约束：上下文完全隔离、工具权限受限（仅持有完成子任务所需的最小权限）、独立超时/终止条件，对应“造缰”工程维度的安全边界与接口约束，避免执行过程对全局系统造成影响。

工程化定位：作为 REPL 容器中“Action”环节的具体执行者，被 Lead Agent 调度管控，执行完成后自动销毁，无状态残留，既降低资源开销，也符合“造缰”工程维度的安全隔离要求，同时其执行状态可被“相马”体系实时观测。

Lead Agent 与 Sub-Agent 标准协作流程（结合 PPAF与REPL容器逻辑）

DeerFlow 2.0 主从代理的标准协作流程，是 PPAF 闭环与 Harness REPL 容器逻辑的完整落地，形成“感知→规划→行动→反思”的生产级闭环，每一步均对应工程化支撑体系的具体要求

尼恩提示：原文1w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。

完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，找尼恩获取

Lead Agent 与 Sub-Agent 三种典型协作模式

基于 PPAF 闭环逻辑与“驭马”工程的调度能力，DeerFlow 2.0 内置三种典型协作模式，分别适配不同任务特性，实现效率、质量与灵活性的平衡，每种模式均对应完整的 PPAF 闭环

尼恩提示：原文1w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。

完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，找尼恩获取

DeerFlow 什么时候必须用 Sub-Agent ？

当任务无法通过 Lead Agent 单独完成 PPAF 闭环，或单独完成会导致闭环断裂、安全风险、效率低下时，必须启用 Sub-Agent。

本质是通过 Sub-Agent 强化“行动”环节的专项能力，同时依托“造、驭、相、育”工程化体系，解决 Lead Agent 单独执行的痛点

尼恩提示：原文1w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。

完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，找尼恩获取

DeerFlow 什么时候不用 Sub-Agent？

当任务可通过 Lead Agent 单独完成完整 PPAF 闭环，且启用 Sub-Agent 会增加工程复杂度、降低效率、浪费资源时，不建议启用。

核心是避免“过度设计”，确保 PPAF 闭环的简洁高效，同时降低“造、驭、相、育”工程化体系的不必要开销，具体场景如下：

1. 简单任务（≤2 步、<30 秒）

典型场景： 天气查询、短文本问答、翻译、简单信息查询；

原因：

• 子代理创建 / 销毁 / 通信开销 > 执行收益，启用 Sub-Agent 会导致 PPAF 闭环冗余（额外增加调度、通信环节），降低执行效率；
• 架构冗余、效率降低，无需动用“驭马”“造缰”等工程化能力，Lead Agent 可单独完成“感知→规划→行动→反思”全闭环，且执行高效。

2. 直接问答、无工具调用

典型场景： 常识问答、概念解释、简短建议；

原因：Lead 可直接通过 LLM 完成“感知→规划→行动→反思”全闭环，无需分解调度，启用 Sub-Agent 属于多余环节，同时增加“造缰”工程的接口调用开销，无实际价值。

3. 强实时、低延迟（<1 秒）

典型场景： 即时对话、流式响应、高频交互；

原因：子代理调度 + 执行延迟 > 需求阈值，会导致 PPAF 闭环的“行动”环节延迟，影响用户体验；Lead Agent 单独执行可减少调度延迟，确保“感知→行动”的快速响应，满足实时需求。

4. 资源极受限环境（低内存 / 低 Token 限额）

典型场景： 多 Agent 并发占用更多内存 / Token，成本翻倍，且“造、驭、相、育”工程化体系的运行也需要一定资源支撑，在资源受限场景下，会导致 PPAF 闭环卡顿甚至崩溃；Lead Agent 单独执行可最小化资源占用，确保闭环正常运行。

5. 任务高度一体化、不可拆分

典型场景： 单句创作、简短代码片段、单一函数调用；

原因：无法拆解为独立子任务，拆分反而破坏逻辑完整性，导致 PPAF 闭环的“规划”环节不合理、“行动”环节碎片化；Lead Agent 单独执行可确保任务逻辑的连贯性，完成完整闭环，无需额外调度 Sub-Agent。

DeerFlow 快速决策表 ：快速判断什么时候用 Sub-Agent？

判断维度	用 Sub-Agent（贴合PPAF/工程化需求）	不用 Sub-Agent（贴合PPAF/工程化需求）
步骤数	≥3 步、多阶段、长链路，需拆分实现完整PPAF闭环	≤2 步、单次完成，Lead可单独完成PPAF闭环
执行时长	>1 分钟、后台运行，需“相马”工程观测，“驭马”工程调度	<30 秒、即时返回，Lead单独执行无延迟，无需额外调度
工具 / 技能	专用工具、高危操作、多技能，需“造缰”工程隔离，专项行动支撑	无工具、纯生成、通用能力，Lead可单独完成“行动”环节
安全要求	沙箱、权限隔离、高危操作，需“造缰”工程边界约束，“相马”工程审计	无敏感操作、只读 / 无执行，无需安全隔离，Lead单独执行无风险
上下文	>10 轮、长记忆、需压缩，需“育马”工程记忆体系支撑，避免闭环断裂	≤5 轮、短对话、无膨胀，Lead可单独管理上下文，闭环高效
并发 / 异步	多任务、批量、后台执行，需“驭马”工程并发调度，“造缰”工程资源隔离	单任务、同步、即时响应，Lead单独执行可满足需求，无需并发调度
可观测性	生产级、审计、调试、可恢复，需“相马”工程观测，“育马”工程迭代	原型、测试、非关键场景，无需复杂观测与迭代，Lead单独执行即可
复杂度	高、易混乱、需模块化，需拆分实现PPAF闭环，依托工程化体系管控	低、清晰、无分支，Lead可单独完成PPAF闭环，无需模块化拆分

四、DeerFlow 源码介绍（结合 PPAF与REPL容器逻辑）

DeerFlow 源码中 Lead Agent 承担 Read、Eval、Print、Loop 管控职责，Sub-Agent 承担 Action 执行职责，同时融入“造、驭、相、育”工程化细节（配置加载、权限控制、状态监控、结果反馈）。

尼恩提示：原文1w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。

完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，找尼恩获取

五、总结（结合PPAF与工程化体系，提炼核心价值）

DeerFlow 2.0 主从代理架构的核心，是将 PPAF 智能体执行闭环模型与“造、驭、相、育”工程化支撑体系深度融合，实现智能协作的“决策可控、执行高效、安全可靠、可迭代进化”，具体可总结为：

• Lead Agent = 大脑 + 总指挥 + PPAF 闭环中枢 + REPL 容器管控：只做决策、不做执行，主导“感知、规划、反思”三大环节，同时承担“造、驭、相、育”四步工程化支撑的核心职责，确保全局可控、闭环完整；
• Sub-Agent = 专项工人 + 沙箱隔离 + PPAF 行动终端：最小权限、独立执行、用完即毁，专注于“行动”环节的专项落地，依托“造缰”工程的边界约束与“相马”工程的观测能力，确保执行安全、精准；
• 使用原则：简单任务直接走 Lead，通过 Lead 单独完成 PPAF 闭环，最大化效率、最小化资源开销；复杂 / 专项 / 安全 / 长时任务必须上 Sub-Agent，通过主从协作完善 PPAF 闭环，依托工程化体系解决单一 Agent 执行的痛点；
• 架构价值：主从分工明确，完美契合 PPAF 闭环与“造、驭、相、育”工程化体系，使智能体协作具备鲁棒性强、安全可控、可扩展、适配生产的特点，同时实现 Agent 能力的持续迭代进化，真正将 LLM 的推理能力转化为确定性的工程执行能力。

在云栈社区，我们持续追踪此类前沿的 System Design 范式，探讨如何将抽象的 AI 理论落地为稳定、可演进的工程架构。