2201_75368691的博客

最近，我做了一件大事：BareLoop

2201_75368691 — Wed, 09 Sep 2026 09:55:54 +0800

好久没更新了，因为我一直在捣鼓这件事最近确实有一段时间没有更新文章了。。简单来说，BareLoop 是一个从基本原理出发实现的、兼容 OpenAI API 的 Coding Agent Runtime。它现在还不是什么成熟框架，也远没有到“开箱即用解决一切”的程度，但它已经跑通了一个 Agent 从接收任务、调用模型、选择工具、执行工具、回传结果，到管理上下文、记忆、任务和多 Agent 协作的核心链路。这篇文章是 BareLoop 系列的第一篇。

LangGraph 到底是什么？

2201_75368691 — Tue, 23 Jun 2026 23:05:39 +0800

LangGraph是一种解决Agent运行时复杂性的框架，其核心思想是将Agent拆解为状态图（node和edge）。node代表步骤（如调用LLM、工具、人工审核），edge决定流程走向。关键概念state记录Agent当前信息，使流程透明可追踪。LangGraph可独立使用或与LangChain配合，后者侧重工具集成，前者专注流程控制与状态管理。简单示例展示了START→mock_llm→END的基础图结构，适用于需要精细控制复杂任务流程、分支决策和持久化等场景，比传统while-loop方案更清晰可靠

最近开始补 Java，聊聊我对全栈的一点感受

2201_75368691 — Wed, 10 Jun 2026 10:59:00 +0800

现在学 Java，会开始多想一些工程化的问题：接口怎么设计更稳定，业务逻辑放在哪一层，异常怎么处理，数据结构后面会不会难扩展，服务之间怎么协作。Python 这块主要是用来做 AI 相关的东西，比如模型调用、Agent、RAG、数据处理、一些 AI 应用的快速验证之类的。不是为了追热点，而是为了在业务变化的时候，自己能跟得上，也能多承担一点完整的问题。对我自己来说，之前的前端经验让我更理解用户看到的东西，Python 让我能把 AI 能力快速验证和落地，现在学 Java 是在补更正式的后端工程能力。

Agent 实战的底层逻辑

2201_75368691 — Sat, 30 May 2026 21:56:36 +0800

文章摘要：当前Agent技术虽热，但生产实践经验稀缺。核心观点是Agent本质上是上下文工程（Context Engineering），能力上限取决于信息组织方式。文章指出应避免过度依赖框架、迷信长上下文，强调Benchmark优先、工具设计简洁、缓存优化等实践原则。同时提醒Memory技术尚未成熟，复杂编排可能适得其反，主张保持简单核心循环。随着模型进步，真正持久的Agent系统将是那些深刻理解模型本质而非堆砌功能的方案。（149字）

setState 更新流程：从 dispatchAction 到 Fiber 更新与 lane 调度

2201_75368691 — Wed, 20 May 2026 11:31:04 +0800

React19状态更新机制解析：从setState到渲染的全链路流程本文基于React19源码剖析状态更新核心流程：1) dispatchAction创建update对象并入队；2) scheduleUpdateOnFiber调度更新并标记lane优先级；3) lane模型控制更新优先级与可中断性；4) workInProgress复用Fiber实现并发安全；5) 完整更新链路包含render阶段的状态计算、commit阶段的DOM操作及passive effect执行。重点解析了updateQueue管

useEffect 为什么延后执行：passive effects 的调度与刷新

2201_75368691 — Tue, 19 May 2026 10:45:37 +0800

React19中useEffect的执行机制：passive effect在commit阶段后异步执行。render阶段仅标记effect（通过Fiber.flags和subtreeFlags），不执行回调。commit阶段完成DOM更新后，通过微任务队列flushPassiveEffects依次执行cleanup和create回调。这种设计保证了：1）不阻塞渲染和主线程；2）执行顺序与hooks调用一致；3）cleanup先于create执行；4）并发渲染安全。与useLayoutEffect不同，use

commitRoot 三个阶段：beforeMutation、mutation 与 layout

2201_75368691 — Mon, 18 May 2026 13:50:47 +0800

React19的commit阶段将render结果应用到DOM，分为三个不可中断的子阶段：beforeMutation阶段捕获快照并执行getSnapshotBeforeUpdate；mutation阶段实际修改DOM，处理节点增删改和ref；layout阶段同步执行类组件生命周期和useLayoutEffect。整个过程依赖render阶段生成的flags和effectlist进行高效遍历，确保DOM操作原子性。与可中断的render阶段不同，commit阶段必须同步完成所有DOM修改和布局计算，保证页面

render 阶段如何结束：finishedWork、flags 与 commit 入口

2201_75368691 — Fri, 15 May 2026 11:44:40 +0800

本文分析了React 19中render阶段的完成机制。重点包括：1) render阶段结束标志是workInProgress为null，此时DOM已创建/更新完成，flags和subtreeFlags完成聚合；2) completeWork通过bubbleProperties向上汇总子树副作用；3) 生成的finishedWork作为commit阶段入口；4) 同步和并发渲染的区别在于是否可中断；5) commit阶段根据flags执行DOM操作。文章详细阐述了render到commit的过渡过程，包括状

completeWork：真实 DOM 是在哪里被创建的

2201_75368691 — Thu, 14 May 2026 11:56:01 +0800

本文详细解析了React的completeWork阶段，主要包含以下要点： render阶段分为beginWork和completeWork两个方向：beginWork向下创建子Fiber，completeWork向上完成当前Fiber并创建DOM。真实DOM创建发生在completeWork阶段： HostText通过createTextInstance创建文本节点 HostComponent通过createInstance创建元素节点使用appendAllChildren将子DOM附加到父DOM 函

reconcileChildren 深入：React 如何根据 ReactElement 构建子 Fiber

2201_75368691 — Wed, 13 May 2026 14:16:26 +0800

本文深入解析了React中函数组件在beginWork阶段的调和过程。核心流程包括：1）通过renderWithHooks执行组件函数获取ReactElement；2）调用reconcileChildren将ReactElement转换为子Fiber链表。重点分析了mountChildFibers和reconcileChildFibers的区别、数组children的diff算法、key和type的复用规则，以及React19新增的Thenable处理等特性。文章详细阐述了从组件返回值到Fiber子树的完整

FunctionComponent 如何执行：renderWithHooks 与 Hooks 链表

2201_75368691 — Tue, 12 May 2026 13:57:21 +0800

本文深入解析了React函数组件的执行机制，重点阐述了Hooks的实现原理。主要内容包括：1. 函数组件在updateFunctionComponent阶段执行，通过renderWithHooks接管执行；2. Hooks状态存储在Fiber节点的memoizedState链表中，而非组件闭包；3. 初次渲染时mountState创建Hook节点，更新时updateState复用旧Hook；4. Hooks依赖调用顺序匹配，因此不能写在条件语句中；5. useEffect在render阶段只登记effect

beginWork 的第一站：HostRoot 如何把 App 接入 Fiber 树

2201_75368691 — Mon, 11 May 2026 10:14:36 +0800

本文深入解析了React初次渲染过程中HostRootFiber的关键作用。当调用root.render()时，React并不会立即创建App Fiber，而是将更新存入HostRootFiber的updateQueue。在render阶段，beginWork处理HostRootFiber时会执行updateHostRoot，该过程主要完成：1) 通过processUpdateQueue从updateQueue中取出元素；2) 将元素作为children传递给

从 performWorkOnRoot 到 workInProgress tree：React 真正开始 render 的地方

2201_75368691 — Sat, 09 May 2026 17:37:38 +0800

本文深入解析了React 19中render阶段的执行流程。从performWorkOnRoot入口开始，详细阐述了同步渲染(renderRootSync)和并发渲染(renderRootConcurrent)的区别，重点分析了prepareFreshStack如何创建workInProgress树，以及beginWork和completeWork的分工协作机制。特别指出初次渲染时App组件是在beginWork阶段通过reconcileChildren转换为Fiber节点的过程，而非在root.rende

从 scheduleUpdateOnFiber 到 Root 微任务调度：React 如何把更新交给调度系统

2201_75368691 — Fri, 08 May 2026 14:32:36 +0800

React 18与19调度机制差异解析：从更新到渲染的核心链路变化 React 18与19在调度机制上存在显著差异。React 18中，ensureRootIsScheduled直接进行完整的调度决策，同步任务进入内部队列，并发任务通过Scheduler注册。而React 19引入Root微任务调度模型：先将Root加入全局链表，延后到微任务中统一处理。关键变化在于，React 19将调度决策点后移，通过processRootScheduleInMicrotask批量处理所有Root，同步任务在微任务末尾统

从 createRoot 到 root.render：React 更新链路的起点到底做了什么

2201_75368691 — Thu, 07 May 2026 11:25:17 +0800

React 18 引入 createRoot API 取代传统的 ReactDOM.render，这一改变体现了 React 内部模型的重大升级。新 API 通过显式创建 Root 对象（FiberRootNode 和 HostRootFiber），建立了更清晰的更新机制：createRoot 初始化应用根结构，root.render 则创建更新任务。这种分离使 React 能够更好地管理更新优先级、调度和并发渲染。关键改进包括将 ReactElement 封装为 update 对象、引入 lane 优先级

createRoot 到底创建了什么：FiberRootNode 和 HostRootFiber 的初始化过程

2201_75368691 — Wed, 06 May 2026 11:32:37 +0800

React 18中，createRoot(container)初始化了React应用的核心结构：创建了FiberRootNode管理根状态，包括容器引用、调度信息等；同时生成HostRootFiber作为Fiber树的根节点，两者通过current和stateNode相互引用。此时尚未渲染用户组件，仅初始化了更新队列，为后续root.render()做准备。这一改动不仅是API变更，更明确了并发模式的根结构创建过程。

为什么 React 18 之后使用 createRoot，而不是 ReactDOM.render

2201_75368691 — Tue, 05 May 2026 14:07:14 +0800

React 18 引入了新的应用入口 API createRoot()，取代了原有的 ReactDOM.render()。这一变化不仅是语法调整，更是模型层面的重大改进。新 API 显式暴露了 Root 概念，将创建根容器和提交更新明确分离：createRoot() 创建长期存在的根容器对象，root.render() 则提交更新。这种设计更符合 React 18 并发渲染的架构，支持优先级调度、中断恢复等新特性，同时也统一了首次渲染和后续更新的处理模型。新 API 强调 Root 作为 React 运行时

Fiber 到底是什么：从数据结构到 React 运行时执行单元

2201_75368691 — Mon, 27 Apr 2026 15:09:28 +0800

React Fiber架构解析 Fiber是React的核心执行单元，不同于仅描述UI结构的ReactElement，Fiber是一个完整的运行时数据结构。它主要承担六大功能：1）保存组件状态（如Hooks状态存储在memoizedState）；2）维护组件树结构关系（通过child/sibling/return指针）；3）管理更新队列（updateQueue）；4）标记副作用（flags）；5）记录调度优先级（lanes）；6）实现双缓存机制（alternate）。 Fiber架构的关键创新在于将递归渲染

React 是如何从 ReactElement 进入 Fiber 体系的？

2201_75368691 — Fri, 24 Apr 2026 14:36:30 +0800

ReactElement作为静态描述，在更新过程中并非直接转换为Fiber结构。当调用root.render()时，ReactElement被封装为update对象进入HostRootFiber的updateQueue。真正的转换发生在render阶段，通过createFiberFromElement将ReactElement转换为具备调度能力的Fiber节点。这一过程实现了从描述系统到执行系统的关键跨越，其中元素type决定Fiber的tag类型，进而影响后续执行路径。整个转换过程体现了React更新机制

JSX 到 ReactElement：React 的“UI描述层”到底在解决什么问题？

2201_75368691 — Fri, 17 Apr 2026 10:49:16 +0800

React通过JSX生成不可变的ReactElement对象来描述UI结构，而非直接操作DOM。ReactElement作为UI的快照描述，包含type、props等字段，支持跨平台渲染和并发更新。其不可变性确保了渲染阶段的纯净性，并为后续Fiber架构的diff计算提供基础。ReactElement仅描述UI，实际DOM操作由Fiber执行结构完成，形成"描述-计算-执行"的分层架构，解决了直接操作DOM带来的性能问题和平台限制。