这里写自定义目录标题欢迎使用Markdown编辑器一、Chain 式 Agent 的困境为什么多轮任务总是掉链子二、核心转变把工作流画成一张图三、一个完整的实战3 小时搭出带记忆的客服助手生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# LangGraph 实战把智能体从串成链升级为画成图一、Chain 式 Agent 的困境为什么多轮任务总是掉链子如果你做过 Agent 开发多半遇到过这样的场景用户先问我的耳机什么时候到Agent 查了订单告诉你已发货接着用户追问那能退吗Agent 突然像失忆一样——“什么耳机你谁订单号呢”。这种聊着聊着就断片的现象几乎是所有用传统 Chain链方式构建的 Agent 的通病。问题出在哪里表面看是记忆丢了根子上却是架构不对。用 Chain 做 Agent本质上是把一次调用串成一条直线LLM 输出 → 决定调用哪个工具 → 拿到结果 → 再喂给 LLM。每一步的输入输出都是一次性的状态只能靠手动拼进上下文控制流只能靠写死的 if-else。一旦任务需要分支、循环、回退或者中间结果需要变道这种线性结构就立刻捉襟见肘。我曾在客服场景里被这个问题反复折磨用户连续提问查订单 → 查退货政策 → 推荐替代品用 Chain 跑第一轮还正常第二轮就开始胡言乱语第三轮直接报错。一开始我怀疑是模型不行后来才意识到——问题不在模型在架构。同一个 LLM换一种编排方式表现天差地别。二、核心转变把工作流画成一张图LangGraph 给出的解决方案是抛弃一条路走到黑的线性链把 Agent 的工作流改造成一张有向图。在这张图里状态State是贯穿全程的共享黑板通常是一个字典存着对话历史、工具输出、下一步要做什么节点Node是执行单元本质就是函数——读状态、改状态边Edge决定节点之间的流转关系条件边Conditional Edge根据状态里的某个字段比如next_action动态决定下一步是调工具还是直接回答。这个设计带来的最大好处是把控制流从代码里抽离出来。你不再需要写一堆 if-else 去管理下一步走哪而是在图上直接画一条带条件的边后期要调整流程改个配置就行不用重构整个 Agent。更关键的是这种图结构天然支持循环。Agent 调工具 → 工具返回结果 → Agent 继续决策 → 再调工具……直到完成任务。这在 Chain 里几乎没法优雅实现——你只能手动写个 while True然后祈祷别死循环。而在图模型里循环就是图上的一个环是一等公民。这里我还想补充一点自己的观察把 Agent 从链升级为图表面上只是数据结构的变化实质上是对任务本质认知的升级。链式思维假设任务是一条确定性的流水线而图式思维承认任务是一张充满分支与回环的地图——后者显然更贴近真实世界的工作流。这也是为什么把 AI 画成图而不是串成链正在成为 Agent 工程的主流范式。三、一个完整的实战3 小时搭出带记忆的客服助手光讲概念没有说服力我们用 LangGraph 完整搭一个带记忆的客服助手。环境版本Python 3.12、langchain 0.3.x、langgraph 0.2.x。模型用 GPT-4o-mini温度设为 0尽量让它照章办事而不是自由发挥。第一步定义状态。客服助手需要记住当前用户在问什么订单、查过哪些内容所以状态里至少要包含对话历史、订单上下文和下一步动作fromtypingimportTypedDict,AnnotatedclassAgentState(TypedDict):messages:Annotated[list,add_messages]# 对话历史order_context:dict# 当前订单上下文next_action:str# 下一步动作**第二步定义工具。**客服需要三个工具订单查询、退货政策查询、知识库搜索。在 LangChain 里用 tool 装饰器定义即可函数名和 docstring 会成为模型理解这个工具是干嘛的的依据。 pythonfromlangchain_core.toolsimporttooltooldefquery_order(order_id:str)-str:根据订单号查询订单状态与物流信息returndb.get_order(order_id)tooldefcheck_return_policy(category:str)-str:查询某个商品品类的退货政策returnpolicy_lookup[category]**第三步定义节点与条件边。**这是 LangGraph 的核心。我们设计三个节点agentLLM 决策、tools执行工具调用、respond直接回答。agent 节点根据 LLM 的输出决定走哪条条件边 pythonfromlanggraph.graphimportStateGraph,ENDdefagent_node(state):# LLM 决定是调用工具还是直接回答resultllm_with_tools.invoke(state[messages])ifresult.tool_calls:return{messages:[result],next_action:tools}return{messages:[result],next_action:respond}deftools_node(state):# 批量执行工具调用executed[]forcallinstate[messages][-1].tool_calls:executed.append(tool_executor.invoke(call))return{messages:executed,next_action:agent}graphStateGraph(AgentState)graph.add_node(agent,agent_node)graph.add_node(tools,tools_node)graph.add_edge(tools,agent)# 工具执行完回到 agentgraph.add_conditional_edges(agent,lambdas:s[next_action],{tools:tools,respond:END})graph.set_entry_point(agent)appgraph.compile() 注意 graph.add_edge(tools,agent) 和条件边的配合**tools 永远回到 agent 继续决策**agent 则根据 next_action 决定是再调工具还是结束。这就构成了一个天然的思考-行动-观察循环而循环的出口由条件边动态控制不会死锁。**第四步挂上持久化记忆。**要让 Agent 在多轮、跨会话场景下不失忆可以把状态存储接入外部持久层比如 Redis 或 SQLite每次请求按会话 ID 恢复状态。这样即使用户隔天再回来Agent 也能记住这位用户上次问的是哪笔订单。 这套实现下来我的体会是LangGraph 真正解决的不只是循环怎么写更是Agent 的每一步做了什么、为什么这么做变得**可观测、可回溯**。节点、状态、边都显式可见调试时一眼就能看出问题出在决策还是执行环节——这是 Chain 那种黑盒流水线完全做不到的。## 四、实战中踩过的坑与避坑建议在把 LangGraph 从 Demo 推向生产的过程中有几个坑非常典型值得单独记录。**坑一把所有逻辑都塞进一个巨大的 agent 节点。**这样做的结果是退化成带工具的高级 Chain图的优势荡然无存。正确做法是让节点保持小且专一个节点只做一件事把复杂性交给图结构去表达。**坑二循环出口设计不清晰。**条件边的判断逻辑如果过于模糊Agent 容易陷入工具调用-失败-重试-再失败的死循环。我的建议是给节点加**最大轮次上限**并在工具连续失败 N 次后强制走抱歉暂时无法处理的分支宁可降级也不能空转。**坑三忽略状态里的敏感信息。**客服场景的订单上下文里可能包含地址、电话等隐私数据。状态在持久化时务必做脱敏或者限制只保存完成任务所必需的最小字段。这既是合规要求也能降低数据泄露的后果。**坑四混用记忆与状态的概念。**在 LangGraph 里状态是每次图执行的局部变量而记忆是跨任务、跨会话的持久知识。不要把临时状态当长期记忆用否则状态会越积越大、上下文越来越臃肿最终拖垮性能和成本。## 五、从客服助手到更复杂的编排这个带记忆的客服助手只是一个起点。图的表达能力远不止于此你可以在图上并行挂多个节点处理不同任务可以用子图Subgraph把一个完整流程封装成可复用的积木还可以结合条件边实现路由分流——把问题按难度分给不同能力的模型。 事实上LangGraph 这类图编排思想的普及正在悄悄改变整个 Agent 工程的面貌开发者从串代码转向画流程Agent 从不可控的黑盒走向可观测的白盒。对于想要把智能体真正用起来的团队来说这可能是今年最值得投入的工程范式之一。**Markdown编辑器**所展示的欢迎页。如果你想学习如何使用Markdown编辑器,可以仔细阅读这篇文章了解一下Markdown的基本语法知识。## 新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客1.**全新的界面设计**将会带来全新的写作体验2.在创作中心设置你喜爱的代码高亮样式Markdown**将代码片显示选择的高亮样式**进行展示3.增加了**图片拖拽**功能你可以将本地的图片直接拖拽到编辑区域直接展示4.全新的**KaTeX数学公式**语法5.增加了支持**甘特图的mermaid语法[^1]**功能6.增加了**多屏幕编辑**Markdown文章功能7.增加了**焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置**等功能功能按钮位于编辑区域与预览区域中间8.增加了**检查列表**功能。[^1]:[mermaid语法说明](https://mermaid.js.org/intro/)## 功能快捷键撤销kbdCtrl/Command/kbdkbdZ/kbd重做kbdCtrl/Command/kbdkbdY/kbd加粗kbdCtrl/Command/kbdkbdB/kbd斜体kbdCtrl/Command/kbdkbdI/kbd标题kbdCtrl/Command/kbdkbdShift/kbdkbdH/kbd无序列表kbdCtrl/Command/kbdkbdShift/kbdkbdU/kbd有序列表kbdCtrl/Command/kbdkbdShift/kbdkbdO/kbd检查列表kbdCtrl/Command/kbdkbdShift/kbdkbdC/kbd插入代码kbdCtrl/Command/kbdkbdShift/kbdkbdK/kbd插入链接kbdCtrl/Command/kbdkbdShift/kbdkbdL/kbd插入图片kbdCtrl/Command/kbdkbdShift/kbdkbdG/kbd查找kbdCtrl/Command/kbdkbdF/kbd替换kbdCtrl/Command/kbdkbdG/kbd## 合理的创建标题有助于目录的生成直接输入1次kbd#/kbd并按下kbdspace/kbd后将生成1级标题。输入2次kbd#/kbd并按下kbdspace/kbd后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。## 如何改变文本的样式*强调文本*_强调文本_**加粗文本**__加粗文本__标记文本~~删除文本~~引用文本 H~2~Ois是液体。2^10^运算结果是1024.## 插入链接与图片链接:[link](https://www.csdn.net/).图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。## 如何插入一段漂亮的代码片去[博客设置](https://mp.csdn.net/console/configBlog)页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的 代码片.javascript//An highlighted block var foobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。1注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。注脚的解释 ↩︎
LangGraph 实战：把智能体从“串成链“升级为“画成图“
这里写自定义目录标题欢迎使用Markdown编辑器一、Chain 式 Agent 的困境为什么多轮任务总是掉链子二、核心转变把工作流画成一张图三、一个完整的实战3 小时搭出带记忆的客服助手生成一个适合你的列表创建一个表格设定内容居中、居左、居右SmartyPants创建一个自定义列表如何创建一个注脚注释也是必不可少的KaTeX数学公式新的甘特图功能丰富你的文章UML图表流程图FLowchart流程图导出与导入导出导入欢迎使用Markdown编辑器你好 这是你第一次使用# LangGraph 实战把智能体从串成链升级为画成图一、Chain 式 Agent 的困境为什么多轮任务总是掉链子如果你做过 Agent 开发多半遇到过这样的场景用户先问我的耳机什么时候到Agent 查了订单告诉你已发货接着用户追问那能退吗Agent 突然像失忆一样——“什么耳机你谁订单号呢”。这种聊着聊着就断片的现象几乎是所有用传统 Chain链方式构建的 Agent 的通病。问题出在哪里表面看是记忆丢了根子上却是架构不对。用 Chain 做 Agent本质上是把一次调用串成一条直线LLM 输出 → 决定调用哪个工具 → 拿到结果 → 再喂给 LLM。每一步的输入输出都是一次性的状态只能靠手动拼进上下文控制流只能靠写死的 if-else。一旦任务需要分支、循环、回退或者中间结果需要变道这种线性结构就立刻捉襟见肘。我曾在客服场景里被这个问题反复折磨用户连续提问查订单 → 查退货政策 → 推荐替代品用 Chain 跑第一轮还正常第二轮就开始胡言乱语第三轮直接报错。一开始我怀疑是模型不行后来才意识到——问题不在模型在架构。同一个 LLM换一种编排方式表现天差地别。二、核心转变把工作流画成一张图LangGraph 给出的解决方案是抛弃一条路走到黑的线性链把 Agent 的工作流改造成一张有向图。在这张图里状态State是贯穿全程的共享黑板通常是一个字典存着对话历史、工具输出、下一步要做什么节点Node是执行单元本质就是函数——读状态、改状态边Edge决定节点之间的流转关系条件边Conditional Edge根据状态里的某个字段比如next_action动态决定下一步是调工具还是直接回答。这个设计带来的最大好处是把控制流从代码里抽离出来。你不再需要写一堆 if-else 去管理下一步走哪而是在图上直接画一条带条件的边后期要调整流程改个配置就行不用重构整个 Agent。更关键的是这种图结构天然支持循环。Agent 调工具 → 工具返回结果 → Agent 继续决策 → 再调工具……直到完成任务。这在 Chain 里几乎没法优雅实现——你只能手动写个 while True然后祈祷别死循环。而在图模型里循环就是图上的一个环是一等公民。这里我还想补充一点自己的观察把 Agent 从链升级为图表面上只是数据结构的变化实质上是对任务本质认知的升级。链式思维假设任务是一条确定性的流水线而图式思维承认任务是一张充满分支与回环的地图——后者显然更贴近真实世界的工作流。这也是为什么把 AI 画成图而不是串成链正在成为 Agent 工程的主流范式。三、一个完整的实战3 小时搭出带记忆的客服助手光讲概念没有说服力我们用 LangGraph 完整搭一个带记忆的客服助手。环境版本Python 3.12、langchain 0.3.x、langgraph 0.2.x。模型用 GPT-4o-mini温度设为 0尽量让它照章办事而不是自由发挥。第一步定义状态。客服助手需要记住当前用户在问什么订单、查过哪些内容所以状态里至少要包含对话历史、订单上下文和下一步动作fromtypingimportTypedDict,AnnotatedclassAgentState(TypedDict):messages:Annotated[list,add_messages]# 对话历史order_context:dict# 当前订单上下文next_action:str# 下一步动作**第二步定义工具。**客服需要三个工具订单查询、退货政策查询、知识库搜索。在 LangChain 里用 tool 装饰器定义即可函数名和 docstring 会成为模型理解这个工具是干嘛的的依据。 pythonfromlangchain_core.toolsimporttooltooldefquery_order(order_id:str)-str:根据订单号查询订单状态与物流信息returndb.get_order(order_id)tooldefcheck_return_policy(category:str)-str:查询某个商品品类的退货政策returnpolicy_lookup[category]**第三步定义节点与条件边。**这是 LangGraph 的核心。我们设计三个节点agentLLM 决策、tools执行工具调用、respond直接回答。agent 节点根据 LLM 的输出决定走哪条条件边 pythonfromlanggraph.graphimportStateGraph,ENDdefagent_node(state):# LLM 决定是调用工具还是直接回答resultllm_with_tools.invoke(state[messages])ifresult.tool_calls:return{messages:[result],next_action:tools}return{messages:[result],next_action:respond}deftools_node(state):# 批量执行工具调用executed[]forcallinstate[messages][-1].tool_calls:executed.append(tool_executor.invoke(call))return{messages:executed,next_action:agent}graphStateGraph(AgentState)graph.add_node(agent,agent_node)graph.add_node(tools,tools_node)graph.add_edge(tools,agent)# 工具执行完回到 agentgraph.add_conditional_edges(agent,lambdas:s[next_action],{tools:tools,respond:END})graph.set_entry_point(agent)appgraph.compile() 注意 graph.add_edge(tools,agent) 和条件边的配合**tools 永远回到 agent 继续决策**agent 则根据 next_action 决定是再调工具还是结束。这就构成了一个天然的思考-行动-观察循环而循环的出口由条件边动态控制不会死锁。**第四步挂上持久化记忆。**要让 Agent 在多轮、跨会话场景下不失忆可以把状态存储接入外部持久层比如 Redis 或 SQLite每次请求按会话 ID 恢复状态。这样即使用户隔天再回来Agent 也能记住这位用户上次问的是哪笔订单。 这套实现下来我的体会是LangGraph 真正解决的不只是循环怎么写更是Agent 的每一步做了什么、为什么这么做变得**可观测、可回溯**。节点、状态、边都显式可见调试时一眼就能看出问题出在决策还是执行环节——这是 Chain 那种黑盒流水线完全做不到的。## 四、实战中踩过的坑与避坑建议在把 LangGraph 从 Demo 推向生产的过程中有几个坑非常典型值得单独记录。**坑一把所有逻辑都塞进一个巨大的 agent 节点。**这样做的结果是退化成带工具的高级 Chain图的优势荡然无存。正确做法是让节点保持小且专一个节点只做一件事把复杂性交给图结构去表达。**坑二循环出口设计不清晰。**条件边的判断逻辑如果过于模糊Agent 容易陷入工具调用-失败-重试-再失败的死循环。我的建议是给节点加**最大轮次上限**并在工具连续失败 N 次后强制走抱歉暂时无法处理的分支宁可降级也不能空转。**坑三忽略状态里的敏感信息。**客服场景的订单上下文里可能包含地址、电话等隐私数据。状态在持久化时务必做脱敏或者限制只保存完成任务所必需的最小字段。这既是合规要求也能降低数据泄露的后果。**坑四混用记忆与状态的概念。**在 LangGraph 里状态是每次图执行的局部变量而记忆是跨任务、跨会话的持久知识。不要把临时状态当长期记忆用否则状态会越积越大、上下文越来越臃肿最终拖垮性能和成本。## 五、从客服助手到更复杂的编排这个带记忆的客服助手只是一个起点。图的表达能力远不止于此你可以在图上并行挂多个节点处理不同任务可以用子图Subgraph把一个完整流程封装成可复用的积木还可以结合条件边实现路由分流——把问题按难度分给不同能力的模型。 事实上LangGraph 这类图编排思想的普及正在悄悄改变整个 Agent 工程的面貌开发者从串代码转向画流程Agent 从不可控的黑盒走向可观测的白盒。对于想要把智能体真正用起来的团队来说这可能是今年最值得投入的工程范式之一。**Markdown编辑器**所展示的欢迎页。如果你想学习如何使用Markdown编辑器,可以仔细阅读这篇文章了解一下Markdown的基本语法知识。## 新的改变我们对Markdown编辑器进行了一些功能拓展与语法支持除了标准的Markdown编辑器功能我们增加了如下几点新功能帮助你用它写博客1.**全新的界面设计**将会带来全新的写作体验2.在创作中心设置你喜爱的代码高亮样式Markdown**将代码片显示选择的高亮样式**进行展示3.增加了**图片拖拽**功能你可以将本地的图片直接拖拽到编辑区域直接展示4.全新的**KaTeX数学公式**语法5.增加了支持**甘特图的mermaid语法[^1]**功能6.增加了**多屏幕编辑**Markdown文章功能7.增加了**焦点写作模式、预览模式、简洁写作模式、左右区域同步滚轮设置**等功能功能按钮位于编辑区域与预览区域中间8.增加了**检查列表**功能。[^1]:[mermaid语法说明](https://mermaid.js.org/intro/)## 功能快捷键撤销kbdCtrl/Command/kbdkbdZ/kbd重做kbdCtrl/Command/kbdkbdY/kbd加粗kbdCtrl/Command/kbdkbdB/kbd斜体kbdCtrl/Command/kbdkbdI/kbd标题kbdCtrl/Command/kbdkbdShift/kbdkbdH/kbd无序列表kbdCtrl/Command/kbdkbdShift/kbdkbdU/kbd有序列表kbdCtrl/Command/kbdkbdShift/kbdkbdO/kbd检查列表kbdCtrl/Command/kbdkbdShift/kbdkbdC/kbd插入代码kbdCtrl/Command/kbdkbdShift/kbdkbdK/kbd插入链接kbdCtrl/Command/kbdkbdShift/kbdkbdL/kbd插入图片kbdCtrl/Command/kbdkbdShift/kbdkbdG/kbd查找kbdCtrl/Command/kbdkbdF/kbd替换kbdCtrl/Command/kbdkbdG/kbd## 合理的创建标题有助于目录的生成直接输入1次kbd#/kbd并按下kbdspace/kbd后将生成1级标题。输入2次kbd#/kbd并按下kbdspace/kbd后将生成2级标题。以此类推我们支持6级标题。有助于使用TOC语法后生成一个完美的目录。## 如何改变文本的样式*强调文本*_强调文本_**加粗文本**__加粗文本__标记文本~~删除文本~~引用文本 H~2~Ois是液体。2^10^运算结果是1024.## 插入链接与图片链接:[link](https://www.csdn.net/).图片:带尺寸的图片:居中的图片:居中并且带尺寸的图片:当然我们为了让用户更加便捷我们增加了图片拖拽功能。## 如何插入一段漂亮的代码片去[博客设置](https://mp.csdn.net/console/configBlog)页面选择一款你喜欢的代码片高亮样式下面展示同样高亮的 代码片.javascript//An highlighted block var foobar;生成一个适合你的列表项目项目项目项目1项目2项目3计划任务完成任务创建一个表格一个简单的表格是这么创建的项目Value电脑$1600手机$12导管$1设定内容居中、居左、居右使用:---------:居中使用:----------居左使用----------:居右第一列第二列第三列第一列文本居中第二列文本居右第三列文本居左SmartyPantsSmartyPants 是一个文本转换工具主要功能是将普通的 ASCII 标点符号自动转换为更美观的印刷体标点符号。例如原始符号转换后说明引号“引号”直引号变弯引号单引号‘单引号’直单引号变弯单引号--–两个连字符变短破折号---—三个连字符变长破折号...…三个点变省略号创建一个自定义列表MarkdownText-to-HTMLconversion toolAuthorsJohnLuke如何创建一个注脚一个具有注脚的文本。1注释也是必不可少的Markdown将文本转换为HTML。KaTeX数学公式您可以使用渲染LaTeX数学表达式 KaTeX:Gamma公式展示Γ ( n ) ( n − 1 ) ! ∀ n ∈ N \Gamma(n) (n-1)!\quad\forall n\in\mathbb NΓ(n)(n−1)!∀n∈N是通过欧拉积分Γ ( z ) ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) \int_0^\infty t^{z-1}e^{-t}dt\,.Γ(z)∫0∞tz−1e−tdt.你可以找到更多关于的信息LaTeX数学表达式here.新的甘特图功能丰富你的文章2014-01-072014-01-092014-01-112014-01-132014-01-152014-01-172014-01-192014-01-21已完成进行中计划一计划二现有任务Adding GANTT diagram functionality to mermaid关于甘特图语法参考 这儿,UML图表可以使用UML图表进行渲染例如下面产生的一个序列图王五李四张三王五李四张三李四想了很长时间, 文字太长了不适合放在一行.你好李四, 最近怎么样?你最近怎么样王五我很好谢谢!我很好谢谢!打量着王五...很好... 王五, 你怎么样?关于UML图表语法参考 这儿,流程图链接长方形圆圆角长方形菱形关于Mermaid语法参考 这儿,FLowchart流程图我们依旧会支持flowchart.js的流程图语法Created with Raphaël 2.3.0开始我的操作确认结束yesno关于Flowchart流程图语法参考 这儿.导出与导入导出如果你想尝试使用此编辑器, 你可以在此篇文章任意编辑。当你完成了一篇文章的写作, 在上方工具栏找到文章导出生成一个.md文件或者.html文件进行本地保存。导入如果你想加载一篇你写过的.md文件在上方工具栏可以选择导入功能进行对应扩展名的文件导入继续你的创作。注脚的解释 ↩︎
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
