前几天,一位vip面试阿里。

阿里面试官:

说说 Harness /ReAct /PlanExec /Reflect /混合范式 的区别?

L同学答:

其实我们当时用的就是这个 react模式吧。

首先后就是思考 ,然后再就是让模型去进行一个推理推理完结果之后,让去让工具去进行一个执行自行之后把执行的结果再调给模型 ,让模型去再思考的这么一个一个一个模式吧。

这个太low了,

来看尼恩 20张图 穿透5大Agent 范式: Harness /ReAct /PlanExec /Reflect /混合范式 (史上最强)

通过这个 文章, 这里 尼恩给大家做一下 系统化、体系化的梳理,写一个系列的文章组成 尼恩编著 《Harness 架构与源码 学习圣经》 深入剖析 Harness AI 平台级 架构的 架构思维与 核心源码,使得大家可以充分展示一下大家雄厚的 “技术肌肉”,让面试官爱到 “不能自已、口水直流”

阿里面试官:

说说 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

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

在这里插入图片描述

更多推荐