旅人

LangGraph 给了你把 Agent 建模成图的能力，但「图长什么样」仍然需要你设计。 LangChain 文档总结了五种常见的工作流模式，覆盖了从简单流水线到复杂多 Agent 协作的大部分场景。选对模式，比堆更多 prompt 有效得多。 Agent 的核心等式在聊模式之前，先对齐 Agent 是什么： Agent = LLM + Tools + Memory + Planning LLM 是大脑 Tools 是手脚——描述写得好不好，直接决定 Agent 能不能正确行动 Memory 提供记忆力 Planning 决定逻辑能力 Agent loop 本质上就是一个 while 循环：推理 → 调工具 → 写回上下文 → 再推理，直到达到目标或停止。 Agent 面临的现实问题： 记忆 — 上下文窗口有限，长任务容易忘 烧 token — 每轮循环都在消耗 推理路径易失效 — 走偏了就是资源浪费 五种工作流模式1. Prompt Chaining（提示链）每步在前一步输出上增强，类似建造者模式。每步职责不同。 例子：生成小说 → 检查剧情连贯 →...

节点和 State 搞定之后，下一关是控制图的流转。 LangGraph 提供了三种层次的编排能力：边（Edge） 做常规路由，Send 做动态并行分发，Command 做「改状态 + 强制跳转」的特种操作。 日常开发里，90% 的路由用条件边就够了；但剩下 10% 的边界场景——工具强制收尾、中断恢复、子图交还父图——Command 是绕不开的。 边的四种形式边决定 Node 之间的连接方式，分两类 API： 类型 API 说明 普通边 add_edge("A", "B") 固定从 A 到 B 普通入口 add_edge(START, "A") 固定从 START 到 A 条件边 add_conditional_edges(...) 根据函数返回值选路 条件入口 add_conditional_edges(START, router, {...}) 根据条件决定从哪开始 条件判断函数可以返回节点名，也可以只返回 True/False，然后在 add_conditiona...

建 LangGraph 的第一件事不是写节点，而是划分 State。 State 就像一块公共笔记板：prompt、历史消息、中间结果、计数器……所有节点需要共享的数据都放在这里。字段又叫 Channel。 搞懂 State 的读写规则和 Reducer 的合并逻辑，后面写复杂 Agent 才不会乱。 State 的三层视角LangGraph 允许你为不同节点定义不同的 State 视角，但底层框架为了注入和高可用，实际是把所有 State 混合在一起的。 类型 作用 InputState 约束 invoke() 的入参，调用时只填这里定义的字段 OutputState 约束 invoke() 的返回值，result = graph.invoke(...) 只能拿到这些字段 PrivateState 内部字段，不用传给 StateGraph()，框架会自动映射 几个容易误解的点： 节点 return 时，不需要严格按 OutputState 来写——只要 return 的 key 在底层混合 State 里存在，框架就会自动更新 PrivateStat...

如果你已经会用 LangChain 调模型、绑工具，但一碰到「Agent 要循环推理、要分支、要并行」就不知道怎么组织代码——LangGraph 就是为此而生的。 它不是一个 prompt 框架，而是一个编排运行时：把 Agent / LLM 应用建模成一张有向状态图，每个节点读状态、做操作、写回状态，边决定数据往哪流。 三个关键数据结构回到 LangGraph 的核心，Everything 都可以归结为三个概念： 概念 一句话 本质 Node 数据处理的逻辑 Python 函数 Edge 决定数据流转的结构 Python 函数 State 存储数据的结构 TypedDict Node 和 Edge 本质上都是函数——Node 接收 State 做操作，Edge 决定下一个 Node 是谁。 State 是三者中设计成本最高的：划分不好，后面加节点、加并行、加汇总都会痛苦。所以第一篇入门，第二篇就专门讲 State，不是巧合。 LangGraph 把 LLM 应用的各部分拆成节点（Node）和边（Edge）： 概念 作用 Node...

如果你曾用 ChatGPT 问过一个它训练数据之外的问题，或者需要它根据你的专业文档生成答案，你可能就遇到了大模型的两大”绝症”：知识过时 和 幻觉问题。 RAG（Retrieval-Augmented Generation）就是为解决这些问题而生的技术方案。它不是重新训练模型，而是聪明地把 LLM 变成一个”可查阅资料的专家”。 为什么需要 RAG？大模型的四大痛点 静态知识库 - 训练数据有截止日期 幻觉问题 - 编造看起来真实的回答 领域局限 - 专业知识覆盖不完整 数据泄露 - 可能泄露训练数据信息 RAG 的核心价值： 减少幻觉，提高答案准确性 增加实时性，快速适配新数据 扩展领域知识，支持专业应用 降低数据泄露风险（配合私有部署） RAG 的完整流程 graph LR A["文档输入<br/>PDF/Word/Excel<br/>txt等"] B["文本分块<br/>切分策略"] C[&...

对于后端来说，如果文件上传的时候采用一整个上传的方式，那么后端需要在内存中留出很大一部分空间来进行一个中转。如果文件过大，那么可能会造成内存空间的拥挤，频繁的IO造成服务器性能的下降，在web这个多并发的情况下，性能的下降会导致响应时间的增加，严重甚至会导致服务的崩溃。所以我们要对大文件的上传进行专门的优化。 同时，过大的文件传输也会长时间的占用网络信道，会导致网络的拥塞，其余的服务响应时间也会增加。 总结来说，传统整文件上传面临三个核心问题： 内存压力 — 服务端需要一次性将整个文件加载到内存中，上百MB甚至GB级的文件很容易导致OOM 网络不稳定 — 传输过程中一旦网络中断，整个文件需要重新上传，用户体验极差 上传时间过长 — 单连接串行传输，无法充分利用带宽，用户等待时间长 整体方案：文件分片核心思路是：将大文件切分成多个小片段，逐片上传，最后在服务端合并还原。 我们和前端约定，在上传文件的时候，将文件切片处理，传输的时候附带有文件的唯一标识，以及文件切片数，切片标识。 在后端时，我们创建临时文件夹来存储临时切片，在前端传入的标识和切片总数达标的时候，开始在后端合...

consistency（C 一致性）表示更新操作成功后，所有节点在同一时间的数据完全一致 availability（A 可用性）用户访问时，结果是否符合预期 partitions（P 分区容错性）可以理解为容灾，在某节点下线的时候，是否依旧能提共满足CA的服务 这是一个简单的分布式系统 图1 分布式系统结构 三选二指的是CAP理论中是没有办法达到三者共存的状态的。当我们选择其中两种特性的时候，便绝对没有办法保证另一种属性 CP状态订单创建后，等待库存减少后才返回结果。保证数据一致，强一致性表现，用户体验差。（类似银行存钱） AP订单创建后，不等待库存减少后就返回结果。那库存数据怎么办？（异步处理后通知订单系统，若异步处理失败，有补偿机制（重新发请求，补录，校对程序）保证数据一致）。（类似淘宝） AC不拆分数据库系统，在一个数据库的一个事务中完成操作，即单体应用。下单，减库存在一个事务。缺点：不能做分区， 分区涉及网络，进而涉及分区容错性，进而选CP,AP

原始数据库最基本的功能：将数据存入库 和 将数据从库里取出 数据结构的处理由此引出了我们存入库和取出库时对于数据结构的处理 分为了静态与动态处理 静态:如mysql 存进去的时候就已经限定好了一个是一个二维的对象 动态:如文档型数据库 里边的内容拿出来的时候要自定义解析的情况 如何存储 世界上最简单的数据库123456789#!/bin/bashdb_set () &#123; echo "$1,$2" >> database&#125;db_get () &#123; grep "^$1," database | sed -e "s/^$1,//" | tail -n 1&#125; 上述的代码完成了一个极极极极简的数据库,存入数据时的复杂度是O(n),相当于一个单向链表，也相当于是一个日志 在DDIA中日志并非指的是我们在后端项目中用于记录各种操作的日志文件,指的其实是一份仅追加文件 散列索引因为在上述的简单数据库中，取出数据的时候只能使用从头到尾扫描的方式...

完成前边的内容之后，距离完整的spring框架就只剩下一个WebMVC了对于spring的WebMvc来说，提供了以下的组件和API支持： 一个DispatcherServlet作为核心处理组件，接收所有URL请求，然后按MVC规则转发； 基于@Controller注解的URL控制器，由应用程序提供，Spring负责解析规则； 提供ViewResolver，将应用程序的Controller处理后的结果进行渲染，给浏览器返回页面； 基于@RestController注解的REST处理机制，由应用程序提供，Spring负责将输入输出变为JSON格式； 多种拦截器和异常处理器等。 但是对于我们的简单WebMvc来说，只需要支持核心内容就好 DispatcherServlet @Controller注解 @RestController注解 ViewResolver 首先，Java Web应用一般遵循Servlet标准，这个标准定义了应用程序可以按接口编写哪些组件：Servlet、Filter和Listener，也规定了一个服务器（如Tomcat、Jetty、JB...

JDBCTemple 声明式事务 支持REQUIRED传播模式 首先配置DataSource因为我们先前已经实现了读取xml和yaml文件的方法，所以，对于JDBC的配置，我们只需要从properties中拿东西就好了 在我们的配置文件中配置文件内容 12345# application.propertiessummer.datasource.url=jdbc:mysql://localhost:3306/summer_jdbc?useUnicode=true&characterEncoding=utf-8&serverTimezone=UTCsummer.datasource.username=rootsummer.datasource.password=your_passwordsummer.datasource.driver-class-name=com.mysql.cj.jdbc.Driver 然后实现一个由HikariCP连接池库支持的DataSource 12345678910111213141516171819202122232425...