keyman632-优快云博客

原创从 ReAct 到 Planning：从走一步看一步到先拆解再推进

文章摘要：本文探讨了Planning在AI智能体中的必要性及其与ReAct的区别。当任务复杂度增加时，ReAct的"边走边想"模式容易出现全局规划不足、路径重复等问题，而Planning则通过预先拆解任务、制定路线图来解决这些问题。Planning适用于多阶段、强依赖的复杂任务，能增强全局观和可解释性，但也存在额外成本和计划偏差的风险。文章强调Planning与ReAct是互补关系：Planning负责宏观任务分解，ReAct处理具体执行。同时澄清Planning不同于静态的Workfl

2026-06-29 14:55:19 365

原创项目实战：带你手把手实现agent的ReAct模式

本文通过一个极简Python项目从零实现了一个最小可运行的ReAct Agent，核心包括三个部分：模型节点（负责推理决策）、工具节点（执行具体操作）以及两者间的循环连接。项目仅保留最核心结构，通过4个文件清晰呈现：状态管理（messages历史记录）、工具定义（时间查询/笔记读写）和流程控制（模型决策路由）。代码展示了ReAct核心机制——模型通过检查tool_calls判断是否需要行动，工具执行后结果返回消息历史，模型基于新观察继续推理，形成"思考->行动->观察->再思考&

2026-06-11 15:03:44 540

原创 Middleware 详解：Agent 为什么需要额外的行为控制层

本文探讨了Middleware在复杂Agent系统中的核心价值与实践意义。文章指出，随着Agent系统复杂度提升，日志记录、安全检查等横切控制逻辑若分散在各节点会导致代码重复、维护困难等问题。Middleware通过将这些全局约束逻辑集中治理，实现业务与控制解耦，使系统具备统一审计、风控等企业级能力。关键要点： Middleware定位为流程外的统一控制层，负责日志、权限、风控等非业务逻辑与Workflow/Node分工明确：Workflow管流程，Node管业务，Middleware管约束典型应用场

2026-06-10 14:27:47 430

原创从 messages 到结构化字段：LangGraph 状态设计指南

本文探讨了LangGraph中状态管理的核心问题：如何合理设计State结构。文章指出，关键在于区分两类数据：1）需要持续喂给模型理解的对话历史（适合放入messages）；2）用于程序逻辑判断和节点协作的结构化状态（应拆分为独立字段）。通过正反案例对比，作者揭示了"全塞进messages"的弊端：路由判断脆弱、结构化数据难提取、Prompt污染等问题，并提出了实用的设计原则：messages承载交互历史，独立字段管理流程控制信号和结构化中间结果。文章强调合理的状态划分能显著提升图的可维

2026-06-09 17:38:10 639

原创为什么 Agent 不能只会跑：从 Checkpoint 到 Human-in-the-Loop，LangGraph 怎么处理暂停、恢复与人工介入

文章摘要：本文探讨了Agent系统从Demo走向生产环境必须解决的工程化问题——如何实现任务的中断、恢复与人工介入。核心机制包括：Checkpoint（保存任务状态，确保故障后可恢复）、Interrupt（主动暂停高风险步骤等待确认）、Human-in-the-Loop（关键决策由人类兜底）。通过发送违约邮件等场景，说明这些能力是规避风险（如误删库、财务损失）的必要设计，而非模型的“补丁”。文章强调，Workflow框架需结合状态持久化和流程控制，才能支撑长周期、高合规要求的业务闭环。最终指出，Agent

2026-06-08 14:50:59 683

原创 ReAct vs Workflow：谁更适合你的 Agent 系统？

摘要： ReAct与Workflow的核心差异在于流程控制权的归属：ReAct由大模型实时决策下一步动作，适合开放探索型任务（如信息检索、故障排查），灵活性高但可控性弱；Workflow通过预定义节点和规则驱动流程，适合强约束型任务（如审批流、客服分流），稳定性强但灵活性低。实际应用中，成熟系统常采用混合架构：Workflow把控宏观流程合规性，ReAct在特定节点内实现动态探索。选型时需权衡业务需求——优先灵活性选ReAct，优先可控性选Workflow。二者的本质区别并非工具调用与否，而是模型在流程中的

2026-06-07 14:56:55 683

原创 Workflow Agent 是什么：为什么很多生产级系统不再把流程完全交给模型

本文探讨了WorkflowAgent的设计理念及其与ReAct模式的核心区别。WorkflowAgent通过显式定义流程中的状态(State)、节点(Node)和路由(Route)，将控制权从大模型转移到预定义的流程图中，从而提升系统的确定性、可控性和可审计性。文章分析了Workflow的优势（如适合强约束业务、便于加入人工节点）和局限（灵活性降低、设计成本增加），指出其在生产级系统中的适用场景。最后强调Workflow不是替代而是优化ReAct的方式，建议在需要确定性的业务流程中使用Workflow框架，

2026-06-07 14:46:44 494

原创 ReAct 解析：Agent 如何在思考、行动、观察中循环推进任务

摘要： ReAct（Reason-Act）是一种智能体（Agent）设计模式，强调通过多轮“思考-行动-观察”循环动态调整策略完成任务，而非单次工具调用。其核心在于模型根据中间结果（如工具返回数据）持续判断下一步动作，适用于开放型任务（如搜索、调研）。与FunctionCalling（工具调用协议）不同，ReAct关注的是流程控制逻辑，灵活性高但存在可控性弱、成本高、稳定性差等问题。当业务需要强流程约束时，Workflow（工作流）架构更合适。ReAct的本质是模型与工具的循环协作，体现了智能体的动态决策能

2026-06-06 23:38:30 691

原创 LangChain / LangGraph 中的 Function Calling 机制详解

文章摘要： FunctionCalling并非大模型直接执行函数，而是模型生成结构化任务单后由外部运行时执行并回传结果。文章拆解了FunctionCalling的核心流程：1）用户提问触发；2）模型生成带tool_calls的AIMessage（含工具名、参数及唯一ID）；3）外部运行时执行对应函数并返回ToolMessage（需严格匹配ID）；4）模型结合结果输出最终答案。关键点包括：工具实际运行在本地环境，tool_call_id是任务链的核销依据，LangChain等框架仅负责协议转换与调度。常见误区

2026-06-05 23:57:18 717

原创 LangGraph 的 State 机制：为什么节点返回 dict，却不会覆盖全局状态？

文章摘要： LangGraph采用集中式状态管理机制，State作为全局唯一事实来源由引擎托管。节点通过返回PartialUpdate（状态补丁）而非完整State来修改数据，合并逻辑由字段绑定的Reducer决定。核心概念包括：1）State是只读快照；2）节点返回需修改字段的字典；3）Reducer定义合并策略（如add_messages实现消息追加）。常见误区包括直接修改入参、忽略Reducer绑定等。理解State->PartialUpdate->Reducer的流转机制是掌握LangG

2026-06-04 15:46:08 545

原创大模型工程化必修：一文看懂 LangChain/LangGraph 四大核心消息类（BaseMessage 家族全解）

本文深度解析了LangChain/LangGraph中四大核心消息类（SystemMessage、HumanMessage、AIMessage、ToolMessage）的作用及配合机制。SystemMessage定义智能体的人设和规则，HumanMessage承载用户输入，AIMessage兼具文本生成和工具调用功能，ToolMessage则反馈工具执行结果。文章通过代码示例展示了这些消息类在智能体生命周期中的流转过程，并详细剖析了每个类的关键字段和应用场景，包括防御提示词注入、多模态处理、状态机路由等高级

2026-06-03 15:29:11 850

2402_89119316的博客