本文 的 原文 地址
原始的内容，请参考 本文 的 原文 地址
本文 的 原文 地址
尼恩说在前面
在45岁老架构师尼恩的读者交流群（50+人）里，最近不少小伙伴拿到了阿里、滴滴、极兔、有赞、希音、百度、字节、网易、美团这些一线大厂的面试入场券，恭喜各位！
阿里面试官：
说说 Harness /ReAct /PlanExec /Reflect /混合范式 的区别？
L同学答：
其实我们当时用的就是这个 react模式吧。
首先后就是思考 ，然后再就是让模型去进行一个推理推理完结果之后，让去让工具去进行一个执行自行之后把执行的结果再调给模型 ，让模型去再思考的这么一个一个一个模式吧。
这个太low了， 来看尼恩 20张图 穿透5大Agent 范式： Harness /ReAct /PlanExec /Reflect /混合范式 （史上最强）
通过这个 文章， 这里 尼恩给大家做一下 系统化、体系化的梳理，写一个系列的文章组成 尼恩编著 《Harness 架构与源码 学习圣经》 深入剖析 Harness AI 平台级 架构的 架构思维与 核心源码，使得大家可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”。
同时，也一并把这个题目以及参考答案，收入咱们的 《尼恩Java面试宝典PDF》V176版本，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。
尼恩编著 《Harness 架构与源码 学习圣经》
第一章： 什么是 Harness架构？2026年AI核心范式解析 ： Harness架构与Agent工程化
具体文章： 54k+Star 爆火！AI 框架 新王者 Harness Agent 来了！尼恩 来一次Harness穿透式解读
第二章： Harness架构 与 LangChain、LangGraph 三者联动 的底层逻辑
具体文章： Harness架构 与 LangChain、LangGraph 三者联动 的底层逻辑
第三章： DeerFlow 源码 14层Middleware 源码解析 ，又一个 “洋葱责任链模式” 架构思维 的 经典案例
具体文章： DeerFlow 源码 14层Middleware 源码解析 ，又一个 “洋葱责任链模式” 架构思维 的 经典案例
第四章： LangChain 超底层 四大设计模式 Design Patterns ，架构师 的 必备 内功，毒打面试官
具体文章： LangChain 超底层 四大设计模式 Design Patterns ，架构师 的 必备 内功，毒打面试官
第五章：Harness宏观架构：基于 PPAF 思维 & REPL 思维，完成 Lead-Agent和Sub-Agent深度拆解
具体文章： 第五章：Harness宏观架构：基于 PPAF 思维 & REPL 思维，完成 Lead-Agent和Sub-Agent深度拆解
第六章：Harness宏观架构：DeerFlow 2.0 断点续跑机制 架构设计与实现
具体文章： Harness宏观架构：DeerFlow 2.0 断点续跑机制 架构设计与实现
第七章： Harness 平台实战： 用 DeerFlow 构建 一个企业自己的 Manus 平台（ 企业长任务智能体平台）
具体文章： Harness 平台实战： 用 DeerFlow 构建 一个企业自己的 Manus 平台（ 企业长任务智能体平台）
第八章： Harness 超牛逼的 三级记忆架构 上下文+历史分层+事实列表 ！ 落地价值 逆天！！
具体文章： Harness 超牛逼的 三级记忆架构 上下文+历史分层+事实列表 ！ 落地价值 逆天！！
第九章： Harness 顶级架构：DeerFlow 2.0 沙盒 Sandbox 架构设计、Sandbox 源码深度解析（史上最深 、价值 逆天）
具体文章： Harness 顶级架构：DeerFlow 2.0 沙盒 Sandbox 架构设计、Sandbox 源码深度解析（史上最深 、价值 逆天）
第10章： 顶奢RAG架构之, 必不可少的 RAG评估体系：7大核心指标落地优化，让RAG从Demo走向生产
【RAG评估、RAG度量指标】顶奢RAG架构之, 必不可少的 RAG评估体系：7大核心指标落地优化，让RAG从Demo走向生产 full - 技术自由圈
第11章：Harness架构 ： DeerFlow 2.0 的 lead_agent 任务总调度 架构设计与实现解析
Harness架构 ： DeerFlow 2.0 的 lead_agent 任务总调度 架构设计与实现解析
第十二章： Harness 具体应用：AI编程王炸组合：顶级三剑客 OpenSpec 定方向，Superpowers定纪律，Harness定协同
顶级三剑客 OpenSpec 定方向，Superpowers定纪律，Harness定协同
第十三章： Harness 架构哲学和思维：架构思维、架构哲学、设计模式 大拆解、大总结、大提炼
Harness 架构哲学和思维：架构思维、架构哲学、设计模式 大拆解、大总结、大提炼
第十四章： 尼恩 20张图 穿透5大Agent 范式： Harness、ReAct、PlanExec、Reflect、混合范式 （史上最强）
本文
第13章： 深度解析字节跳动DeerFlow 2.0：基于LangGraph的生产级Super Agent驾驭层实现
具体文章： 尼恩还在写， 本周发布
第14章： 基于 PPAF 思维，完成 与 Harness 工程化的 Lead-Agent 和 Sub-Agent 深度拆解.
具体文章： 尼恩还在写， 本周发布
第15章：Harness架构 核心一：断点续跑机制 的 架构设计 与底层源码分析 .
具体文章： 尼恩还在写， 本周发布
第16章：Harness架构 核心二： XXX
具体文章： 尼恩还在写，后续发布
估计有 10章以上，具体请关注技术自由圈。
20张图 穿透5大Agent 范式： Harness /ReAct /PlanExec /Reflect /混合范式 （史上最强）
阿里面试官：
说说 Harness /ReAct /PlanExec /Reflect /混合范式 的区别？
L同学答：
其实我们当时用的就是这个 react模式吧。
首先后就是思考 ，然后再就是让模型去进行一个推理推理完结果之后，让去让工具去进行一个执行自行之后把执行的结果再调给模型 ，让模型去再思考的这么一个一个一个模式吧。
这个太low了，来看尼恩 20张图 穿透5大Agent 范式： Harness /ReAct /PlanExec /Reflect /混合范式 （史上最强）
答案先说：
Harness 并不是一个与 ReAct 或 Plan-Exec 并列的“行为范式”（Behavioral Paradigm），
Harness 是一种“工程架构范式”（Engineering Paradigm）。
- ReAct/Plan-Exec/Reflect /混合范式定义的是 Agent“怎么做决策、怎么执行”的逻辑流。是一种“行为范式”（Behavioral Paradigm），
- Harness定义的是“如何用工程手段约束模型的不确定性”的架构流。 是一种“工程架构约束范式”（Engineering Paradigm）。
尼恩将Harness视为一种独立的架构设计哲学/约束范式，将其与四大行为范式（我们将混合模式算作第四种）进行横向对比，并构建一个全新的对比维度。
一、 人人都在卷AI Agent架构
Agent和普通聊天机器人的核心区别，就在于“闭环能力”——普通机器人只懂“理解+生成”，而Agent能“理解目标→拆解任务→调用工具→接收反馈→修正错误”，本质上是一套带决策能力的闭环系统。
就像我们做架构设计，普通机器人是“单块应用”，只能做单一功能；而Agent是“微服务架构”，各个模块各司其职、协同工作。
这也是尼恩后面要重点融入的架构思维——模块化设计，把复杂任务拆成独立模块，降低耦合、提升可维护性。
当需求从“单次问答”变成“自主完成复杂任务”，核心问题就变了：这个Agent该如何思考、如何选工具、如何在失败后自愈？
这就是Agent架构范式存在的意义，也是尼恩当年踩的第一个坑——误以为Agent是“加长版Prompt”，忽略了闭环设计和模块化拆分。
二、 所有 Agent的 基础原理： 六步 通用闭环
不管是ReAct、Plan-Exec、Reflect、混合模式，基础原理 ， 都逃不开一个 六步 通用闭环 ：
(1) 理解任务：先搞清楚用户到底要什么，别瞎忙活（尼恩当年就因为没吃透需求，做了个“答非所问”的Agent，被领导骂惨）；
(2) 判断策略：想清楚，这个任务是一次直答就能搞定，还是需要多步骤、多工具配合？
(3) 调用工具：该搜资料搜资料、该查数据库查数据库，别死磕LLM的知识库（LLM的幻觉有多坑，尼恩比谁都清楚）；
(4) 读取反馈：工具返回的结果是成功还是失败？信息够不够用？有没有异常？
(5) 持续推进：根据反馈调整下一步动作，别一条路走到黑；
(6) 输出结果：把最终答案整理清楚，给用户一个能用的结果，别搞一堆乱七八糟的内容。
这里插一句，这个闭环其实就是”模块化设计”的体现： 每一步都是一个独立模块，可替换、可调试，比如调用工具模块出问题了，不用动整个Agent，只改这一个模块就行，这也是架构设计的核心思路之一。
六步各自承担的角色，用一张表说清楚：
| 步骤 | 架构角色 | 对应模块 | 出问题时的影响 |
|---|---|---|---|
| 理解任务 | 需求解析层 | Prompt 模板 / 意图识别 | 后续全跑偏 |
| 判断策略 | 路由决策层 | 任务复杂度判断 | 简单任务走重流程，浪费成本 |
| 调用工具 | 执行层 | 工具注册表 / API 网关 | 工具不可用，任务卡死 |
| 读取反馈 | 观测层 | 结果解析 / 异常捕获 | 错误被忽略，后续基于假数据推理 |
| 持续推进 | 编排控制层 | Agent Loop 状态机 | 陷入死循环或提前终止 |
| 输出结果 | 交付层 | 格式化 / 摘要 | 用户拿到一团乱麻 |
理解了这个闭环，再看后面的三大范式，就不会只停留在“背名词”的层面.
而是能看懂每一种范式的设计初衷——都是为了优化这个闭环，解决不同场景下的痛点。
三、ReAct模式：最经典的“边想边做”，新手入门首选（尼恩第一个落地的范式）
先澄清一个误区：
这里的ReAct，不是前端那个React框架！
是Reason + Act，也就是“推理+行动”，别搞混了哈= =
ReAct 太简单了，实现起来几乎没门槛，完全贴合人类“走一步看一步”的直觉。
用图表示就是：
它的核心逻辑很简单：思考→行动→观察→再思考，循环往复，直到完成任务。
如果你是小白的话，可以 用ReAct模式， 从0到1 做了一个简单的资料检索Agent。
资料检索Agent 核心就是“用户提问→LLM思考该搜什么→调用搜索工具→获取搜索结果→LLM再思考要不要继续搜→直到汇总出答案”。
不到半天就跑通了Demo 。
3.1 ReAct的工作流与实操细节
工作流其实很简单 ：
用户问题 → Thought（思考） → Action（执行动作） → Observation（观察结果） → 循环思考行动 → 输出最终答案。
记住：一定要设置最大迭代次数！
很多小伙伴没设，结果Agent陷入了无限循环——一直调用搜索工具，搜了一遍又一遍，停不下来，最后把Token耗光了
所以大家落地ReAct，一定要加循环限制，一般设6-8次就够了，避免死循环。
3.3 ReAct的优缺点：别盲目用，选对场景才重要
优点很明显，尼恩总结了4点：
(1) 实现简单，新手入门门槛极低，半天就能跑通Demo；
(2) 灵活度极高，适配环境不确定、需求多变的任务，比如故障调试、临时数据查询；
(3) 易与工具对接，不管是搜索、数据库，还是代码执行工具，接入起来都很简单；
(4) 链路透明，每一步思考、行动、观察都能追溯，调试起来很方便（尼恩当年排查bug，全靠这个）。
但缺点也很突出 ：
(1) 全局规划能力弱，容易“短视”。
比如做复杂报告，ReAct可能会漏掉关键步骤，或者跑偏主题；
(2) 复杂任务容易反复试探，Token成本偏高。
步骤越多，上下文越长，Token消耗线性增长，尼恩当年做一个10步的任务，Token消耗直接翻倍；
(3) 对Prompt和工具定义很敏感：Prompt写得不好，Agent就会乱调用工具；工具返回格式不统一，Agent就会无法识别反馈。
3.4 适用场景（尼恩实操总结，精准避坑）
别啥任务都用ReAct，它只适合这些场景：
简单FAQ+工具调用（比如客服Agent，回答用户问题并调用业务工具查数据）；
故障调试、问题排查（比如线上代码报错，Agent逐步调用调试工具排查原因）；
临时数据查询、文件读取（比如查某个数据库字段、读取本地文档内容）。
总结一句：新手入门，先做ReAct，快速跑通闭环，建立信心，别一开始就挑战复杂架构。
四、Plan-Exec模式：先规划再执行
Plan-Exec模式：先规划再执行 ， 是 复杂任务的“救命稻草”
比如： 领导让你做一个“行业调研报告生成Agent”，要求先检索资料、再分析数据、再撰写报告、最后校验格式。
如直接用ReAct做，结果惨不忍： Agent一会儿先写报告，一会儿再去检索资料，步骤混乱，还漏掉了数据分析师环节，最后生成的报告全是漏洞。
这时候你才意识到，ReAct搞不定复杂长流程任务，这时候就需要Plan-Exec模式出场了。
Plan-Exec的核心思想很简单：先想全、再做，也就是“先生成全局执行计划，再按步骤逐一落地”，像项目经理做项目一样，先拆解任务、排定步骤，再安排人员执行，避免混乱。
尼恩补充一个实操细节：计划一定要有”依赖关系”，比如”撰写报告”必须依赖”数据检索”和”数据分析”，不能颠倒顺序。
用表来说明每种步骤类型：
当年我没加依赖关系，Agent先执行“撰写报告”，再去检索资料，结果报告全是空白，又被领导骂了一顿= = 所以大家做Plan-Exec，一定要在计划中明确步骤依赖，避免顺序混乱。
尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。
完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取
4.3 Plan-Exec的优缺点：复杂任务必备，但别忽视成本
优点不用多说，尼恩用它解决了很多复杂任务，总结3点：
(1) 全局结构清晰，步骤可控，再也不会出现步骤混乱、遗漏关键环节的问题；
(2) 适配长流程、多阶段任务，比如行业报告、多文件代码修改、复杂数据分析；
(3) 可通过”强模型规划、弱模型执行”降本。 对于多步复杂任务成本有明显下降（规划用强模型只调用一次，执行用弱模型多次调用——取决于任务步数，步数越多降幅越明显）。
缺点也不能忽视 ：
(1) 初始计划可能失真——比如规划时没考虑到外部环境变化，导致后续步骤无法执行；
(2) 实现复杂度高，需要维护两个独立模块（规划+执行），开发和运维成本比ReAct高；
(3) 灵活度不足，计划一旦制定，遇到突发情况容易卡死（比如检索工具失效，Agent不知道如何调整）。
4.4 Plan-Exec的 适用场景
Plan-Exec适合这些复杂场景，别用在简单任务上，否则就是浪费资源：
长流程自动化工作流（比如企业办公自动化，从需求提交到审批完成）；
多阶段内容生成（比如行业调研报告、技术博客、PPT大纲）；
多文件批量处理（比如批量修改代码、批量转换文件格式）；
复杂数据分析（比如多维度数据统计、趋势分析、报告生成）。
五、Reflect反思模式：执行后复盘，Agent的“自检神器”
聊到Reflect，尼恩必须多说一句：它不是独立的架构范式！不是独立的！不是独立的！重要的事情说三遍= =
很多新手会把Reflect和ReAct、Plan-Exec并列，这是大错特错的。
部分小伙伴都 犯过这个错误，面试时被面试官问懵了 。
Reflect的核心定位，是“质量增强机制”。
为什么需要Reflect？因为LLM的幻觉太坑了！
Reflect 相当于给ReAct、Plan-Exec加装了一个“自检修复buff”——Agent做完任务后，自己检查一遍，发现错误就修正，直到达标。
类比一下，就像我们考试：ReAct是做完题直接交卷，不检查；Plan-Exec是先规划做题顺序，再做题，做完也不交卷；Reflect是做完题后，回头自查，修正错题，再交卷。
尼恩当年用Plan-Exec做报告，生成的内容看起来逻辑通顺，结果里面有很多事实错误， 后来加上Reflect，错误率直接下降了80%，太香了。
5.1 Reflect的工作流与核心闭环
工作流很简单，核心是”生成→评估→改进”的闭环：
Reflect 不是独立范式，而是叠加在 ReAct 或 Plan-Exec 之上的”质量增强层”。
它的核心闭环尼恩拆解为三步：
(1) 生成：Agent先完成任务，产出初稿或执行结果；
(2) 评估：Reflect模块校验结果，重点看是否有逻辑错误、事实偏差、信息遗漏、格式不规范；
(3) 改进：如果不达标，基于评估反馈重新生成；如果达标，直接输出。
这里尼恩补充一个实操细节：一定要设置最大反思轮次，一般2-3轮就够了，不然Agent会陷入“过度打磨”的死循环，比如一个简单的句子，反复修改，浪费Token和时间。
尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。
完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取
六、混合模式：生产场景 落地最多的架构 模式
聊到这里，大家可能会问：ReAct灵活但不适合复杂任务，Plan-Exec可控但不灵活，Reflect能提质量但增加成本，到底该选哪个？
尼恩的答案是：不用选，混合模式才是生产环境的终极解！
尼恩做过的生产级Agent，几乎都是混合模式——没有固定套路，就是根据任务场景，动态组合三大范式，最大化平衡灵活度、可控性、质量和成本。
这也是模块化设计和微服务解耦思维的终极体现：把ReAct、Plan-Exec、Reflect拆成独立模块，根据任务需求，按需组合、动态调度，比如：
简单任务：直接走ReAct，快速响应，降低成本；
复杂任务：走Plan-Exec，保证全局可控，避免跑偏；
高严谨任务：在ReAct/Plan-Exec基础上，叠加Reflect，提升质量；
突发情况：给Plan-Exec加动态重规划，遇到计划失效，自动调整步骤；
高风险操作：加人工确认兜底，避免Agent误操作。
6.1 混合架构核心流程（尼恩生产落地版）
混合架构的核心是"动态路由 + 统一质量层"，用图表示就是：
举个真实案例， 某支付企业做的“智能办公Agent”，就是混合架构：
用户简单查询（比如查员工信息）：走ReAct，调用数据库工具，快速返回结果；
用户复杂需求（比如生成月度工作报告）：走Plan-Exec，拆解为“检索数据→分析数据→撰写报告→格式校验”四个步骤；
报告生成后：叠加Reflect，校验数据准确性、逻辑严谨性、格式规范性；
遇到数据检索失败：触发动态重规划，调整检索工具或检索关键词。
这个架构落地后，稳定性提升了90%，成本降低了60%，领导和用户都很满意，这就是混合模式的魅力。
6.2 四大模式横向对比（尼恩独家总结，精准选型）
为了方便大家选型，尼恩做了一个对比表，把所有核心信息都列清楚了，直接对照着用，不用再瞎猜：
| 模式 | 核心思想 | 决策主体 | 规划方式 | 质量保障 | 核心优点 | 明显缺点 | 适配场景 |
|---|---|---|---|---|---|---|---|
| ReAct | 边思考边行动 | LLM 逐轮决策 | 无全局规划 | 靠人工检查 | 实现简单、灵活度高、易调试 | 全局规划弱、复杂任务易循环、Token成本高 | 工具助手、数据查询、客服、故障调试 |
| Plan-Exec | 先全局规划再执行 | Planner + Executor 分离 | 前置全局规划 | 靠步骤校验 | 结构清晰、长流程可控、可降本 | 计划易失真、灵活度低、实现复杂度高 | 长流程编排、多阶段报告、代码批量处理 |
| Reflect | 执行后自我复盘 | 叠加于主范式之上 | 不独立规划，只做校验 | LLM 自检 + 迭代修正 | 质量稳定、减少幻觉、适配高严谨场景 | 成本高、响应慢、反思可能出错 | 代码审查、金融医疗分析、高质量写作 |
| 混合模式 | 多范式动态组合 | 路由判断 + 动态选择 | 按任务复杂度动态切换 | Reflect 层统一兜底 | 适配全场景、平衡速度/成本/准确率 | 设计复杂、调优与运维成本高 | 企业级生产Agent、复杂业务中台 |
七、从零手写最简混合 Agent 框架（完整版・可运行）
聊了这么多理论，尼恩给大家写一个最简混合 Agent 框架，把ReAct、Plan-Exec、Reflect、意图识别、路由调度全部整合进去，新手可以直接复制复用，快速跑通 Demo，少踩坑。
这个框架融入了模块化设计和微服务解耦思维，每个模块独立可替换，方便后续扩展，尼恩当年就是从这个框架开始，逐步迭代出生产级架构的。
尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。
完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取
九、架构选型决策指南（尼恩 总结，直接套用）
很多新手看完，还是不知道该选哪种架构。
尼恩做了一个选型表，结合任务特征，直接对照着选，不用再纠结：
| 任务特征 | 推荐架构模式 | 尼恩实操建议 |
|---|---|---|
| 简单问答、单步工具调用、临时查询 | ReAct | 快速落地，加最大迭代限制，不用过度设计 |
| 多阶段流程、长任务、步骤有依赖 | Plan-Exec | 用强模型规划、弱模型执行，加步骤依赖校验 |
| 高专业度、低容错、需严谨纠错 | Reflect 叠加任意主范式 | 设置最大反思轮次，优化反馈Prompt，提升修正效果 |
| 任务复杂度差异大、场景多 | 混合模式 | 设计任务复杂度判断逻辑，动态调度范式，加容错机制 |
| 工具不稳定、容易调用失败 | 混合模式 + Reflect 自检重试 | 加工具调用异常处理、重试机制，避免任务卡死 |
另外，尼恩给不同身份的朋友提个建议：
(1) 新手入门：先实现 工具+ReAct，加迭代限制与错误处理，再逐步叠加Plan-Exec、Reflect；
(2) 课程/Demo项目：优先ReAct或Plan-Exec，结构清晰，容易展示设计思路；
(3) 企业生产系统：必上混合模式，配套状态管理、超时重试、日志监控、成本管控。
十 、Langchain、Langgraph、Harness 实现三大模式
很多朋友问尼恩：前面讲的三大范式，用Langchain、Langgraph、Harness怎么落地？
毕竟这三个工具是生产中最常用的，不用框架纯手写太费时间。
今天就结合实操代码，把每个工具实现三大模式的核心逻辑讲透。
还是老规矩，不堆名词、只讲落地 。
先跟大家交个底：这三个工具定位不同，用法也不一样，别搞混了。
Langchain主打“快速组装Agent”，适合新手快速落地Demo；
Langgraph主打“复杂流程可视化、状态管理”，适合生产级多节点闭环；
Harness主打“质量校验、成本管控”，完美适配Reflect模式 ！
10.1 Langchain：快速落地三大模式
Langchain的核心优势是“模块化封装”。
已经把ReAct、Plan-Exec的核心逻辑做好了，我们不用重复写循环、工具调用代码，只需要按需组合，新手半天就能跑通Demo，尼恩当年入门就是靠它。
这里有两个极易踩的坑，新手一定要记牢！
第一，verbose参数测试时建议开启，能清晰看到Agent每一步的思考和工具调用过程，排查bug时事半功倍；
第二，handle_parsing_errors的配置不能少，很多新手忽略这个，导致Agent遇到工具返回格式异常时直接崩溃，这个配置能让Agent自动忽略解析错误，重新思考调用逻辑。
另外，Langchain的ReActAgent还有一个实用技巧：可以通过agent_scratchpad参数，手动传入历史上下文，实现多轮对话的连贯性，比如用户追问“刚才的搜索结果里，ReAct的迭代次数为什么设6次”，Agent能基于上一轮的工具调用结果直接回答，不用重新检索，这也是模块化设计的体现。
10.1.2 Langchain实现Plan-Exec模式（解耦规划与执行，适配复杂任务）
很多新手用Langchain实现Plan-Exec时，会把规划和执行混在一起，导致后续无法单独优化某一个模块，违背了解耦思维！
尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。
完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取
这里有两个关键避坑点！
第一，反思Prompt一定要“具体”，不能笼统，比如不要写“检查逻辑是否正确”，要写“检查步骤依赖关系是否合理、是否有遗漏步骤”，否则Agent无法精准修正；
第二，不要用eval解析反思结果，生产环境建议用JSON解析，避免代码注入风险，尼恩当年图省事用eval，被领导指出安全隐患，后来改成了JSON解析，大家一定要注意。
10.2 Langgraph：生产级多节点 + 可视化流程（尼恩生产落地首选）
聊完Langchain，再给大家讲Langgraph。
很多新手觉得Langgraph和Langchain差不多，其实两者定位完全不同：Langchain适合快速搭Demo，而Langgraph适合做生产级复杂Agent。
Langgraph 核心优势是“流程可视化、状态管理、多节点闭环”，能轻松实现动态重规划、分支逻辑，这也是尼恩做企业级Agent时最常用的工具。
尼恩先给大家交个底：Langgraph的核心是”图（Graph）”，每个节点对应一个模块（比如规划节点、执行节点、反思节点、工具调用节点），边对应节点之间的跳转逻辑。
10.2.1 Langgraph实现混合架构（ReAct+Plan-Exec+Reflect，生产级落地）
这里我们搭建一个生产级混合架构，实现“任务复杂度判断→动态选择范式→执行→反思校验”的完整闭环，
包含4个核心节点：任务判断节点、ReAct执行节点、Plan-Exec执行节点、反思校验节点，边对应跳转逻辑（比如简单任务跳ReAct，复杂任务跳Plan-Exec）。
尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。
完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取
十一 Harness：一套Agent约束范式 ，和Reflect模式一样 完美适配 质量与成本双管控
最后聊Harness。
首先要澄清：Harness 不是一个可安装的 Python 包，而是一套Agent约束范式。
11.1 Harness 与 ReAct/Plan-Exec/Reflect 的对比
Harness 并不是一个与 ReAct 或 Plan-Exec 并列的“行为范式”（Behavioral Paradigm），
Harness 是一种“工程架构范式”（Engineering Paradigm）。
- 前三者（ReAct/Plan-Exec/Reflect）定义的是 Agent“怎么做决策、怎么执行”的逻辑流。是一种“行为范式”（Behavioral Paradigm），
- Harness定义的是“如何用工程手段约束模型的不确定性”的架构流。 是一种“工程架构约束范式”（Engineering Paradigm）。
尼恩将Harness视为一种独立的架构设计哲学/约束范式，将其与四大行为范式（我们将混合模式算作第四种）进行横向对比，并构建一个全新的对比维度。
核心对比：四大行为范式 vs. Harness 约束范式
可以把前四种看作是“剧本”（怎么演），而 Harness 是“导演与监制体系”（怎么管、怎么保质量）。
| 维度 | ReAct (边想边做) | Plan-Exec (先想后做) | Reflect (反思复盘) | 混合模式 (动态路由) | Harness (工程约束) |
|---|---|---|---|---|---|
| 核心定位 | 推理与行动的循环 | 任务编排与解耦 | 质量后置校验 | 场景自适应 | 全流程工程治理 |
| 关注点 | 单步推理的灵活性 | 全局流程的可控性 | 结果的准确性 | 资源与场景的平衡 | 系统的稳定性与可维护性 |
| 运作逻辑 | Thought -> Action -> Obs. | Plan -> Step1 -> Step2 | Generate -> Review -> Fix | If(简单) ReAct; Else Plan | Middleware Pipeline (中间件责任链) |
| 解决痛点 | 简单任务开发快 | 复杂任务不跑偏 | 事实性错误/幻觉 | 灵活性与质量的平衡 | Prompt 越写越乱、成本失控、缺乏监控 |
| 实现方式 | Prompt 工程 + 循环 | 强弱模型配合 + 依赖管理 | 自我评估 Prompt + 重试 | 路由判断 + 状态机 | 代码级中间件 (Logging, Guardrail, Budget) |
| 类比 | 即兴表演的演员 | 严格的项目经理 | 事后的质检员 | 智能调度中心 | 标准化的工业流水线 |
Harness Engineering 的核心思想是”用确定性的工程结构约束概率性的模型行为”, 不靠每次手写反思 Prompt，而是靠Middle ware 中间件pipeline 责任链自动拦截和校验，完美适配Reflect模式.
Harness Engineering 通过Middle ware 中间件pipeline 责任链， 帮我们解决“反思模块不精准、Token成本失控”的问题。
尼恩建议，大家 做企业级Agent时，都会把Harness和Langgraph结合使用，实现质量与成本的平衡。，
具体落地形态上，最典型的代表项目是DeepAgents（正在录制视频）和DeerFlow（正在录制视频）。
- DeepAgents： 整合了 LangChain 的开源 SDK Harness，通过 Middleware Pipeline + Backend Protocol + Profile 注册表来治理 Agent 行为
- DeerFlow： 尼恩已经写了大量的 深度文章了。
Harness 思维的精髓是：把 Reflect 模式中”反思→校验→修正”的逻辑，从手工封装 Prompt 下沉到框架的中间件pipeline 责任链。
11.2 Harness 思维落地：用中间件pipeline 责任链替代手写 Reflect（ 示意伪代码）
以下是架构示意伪代码，展示如何用 Middleware Pipeline 思维落地 Reflect 模式。
尼恩提示：原文3w字以上， 超过平台限制， 此处省略 1000字，具体请参考 免费pdf。
完整版本，请参考 尼恩 免费百度网盘 免费pdf ，点赞收藏本文后，截图 找尼恩获取
Agent 当成工厂：
(1) 执行节点 → 生产产品
(2) 质量检查节点 → 质检（就是 Reflect！）
(3) 预算节点 → 控制成本
(4) 重试路由节点 → 不合格就打回去重做
这一整条线，就叫：Middleware Pipeline（中间件流水线 / 责任链）。 它自动帮你完成：执行 → 检查 → 不通过 → 重执行 → 再检查 → 通过 → 输出。
对比手写 Reflect 的优势：手写方式每次反思都要重写 Prompt、重做异常处理、重新管迭代次数——三个任务三个版本，维护噩梦。
pipeline 责任链方式把这些横切逻辑收敛到中间件层：质量规则改一个地方、预算改一个地方、重试策略改一个地方，所有任务共享同一套治理。
11.3 三大工具的选型定位（修正版）
(1) 新手入门/Demo 项目：优先用 Langchain，快速搭建 ReAct Agent，半天跑通；
(2) 生产级复杂 Agent：用 Langgraph，负责流程可视化和状态管理——前面 10.2 节混合架构的核心载体；
(3) 需要 Harness 级工程质量：不要把 Harness 理解成”工具”——它是一套架构思维。
当你发现手写 Reflect Prompt 越来越复杂、异常处理越来越散落、成本越来越难管控时，就是你该引入 Harness 思维的信号。
具体落地可以用 DeepAgents（SDK Harness，通过 Middleware Pipeline + Backend Protocol + Profile 注册表治理）或 DeerFlow（Service Harness，YAML 驱动 + Session 树 + Event Sourcing）。
共同点是：把确定性约束写进代码，而不是写进 Prompt。
12. 面试高频考点（尼恩的vip经历，重点记）
很多朋友学完Agent架构，会去面试相关岗位，尼恩结合自己的面试经历，整理了3个高频考点，附标准答案，记牢了，面试能加分：
考点1：ReAct、Plan-Exec、Reflect三大范式的核心区别和适用场景？
标准答案：ReAct是“边想边做”，无全局规划，灵活度高、实现简单，适合简单工具调用、故障调试；Plan-Exec是“先规划后执行”，全局可控，适合复杂长流程、多阶段任务；Reflect不是独立范式，是质量增强机制，叠加在另外两种范式之上，适合高严谨、低容错场景，能抑制LLM幻觉。
考点2：生产级Agent落地，如何平衡灵活度、质量和成本？
标准答案：核心是“模块化设计+混合架构+成本管控”，用Langgraph实现模块化拆分和动态调度，简单任务走ReAct（保灵活、降成本），复杂任务走Plan-Exec（保可控），高严谨任务加Reflect/Harness（保质量）；同时用“强模型规划/反思、弱模型执行”降低成本，加容错机制和可观测性，保证系统稳定。
