changel 的博客

Deep Agents：下一代 AI Agent 架构深度解析

Mon, 20 Jul 2026 00:00:00 GMT

引言

2024 年，我们见证了 AI Agent 从简单的"工具调用循环"向真正的自主系统演进。传统的 Agent 在面对多步骤、长时程的复杂任务时往往力不从心——它们缺乏规划能力、无法管理持久状态、难以处理子任务委派。Deep Agents（深度智能体）的出现，标志着 AI Agent 架构从 1.0 时代迈向 2.0 时代。

本文将从架构设计、核心组件、实现原理等多个维度，深入剖析 Deep Agents 的技术本质。

一、传统 Agent 的局限性

1.1 浅层循环的困境

传统的 Agent（我们称之为"Shallow Agents"）通常基于 ReAct 模式（Reasoning + Acting）：

while not done:
    thought = llm.reason(context)
    action = llm.choose_tool(thought)
    observation = execute(action)
    context.append(observation)

这种简单的循环架构存在三大问题：

问题 1：缺乏全局规划
Agent 只关注当前步骤，无法提前制定多步计划。例如，让 Agent "撰写一份市场调研报告"，它可能直接搜索第一个想到的关键词，而不是先拆解任务、确定信息源、设计调研框架。

问题 2：上下文窗口溢出
每次迭代都将所有历史追加到上下文，导致 token 消耗指数级增长。长任务（如代码库重构）很快会触及上下文限制。

问题 3：无法并行化
工具调用串行执行，即使多个子任务完全独立（如并行搜索多个数据源），也必须排队等待。

1.2 真实场景的挑战

以"研究并撰写技术博客"为例：

需要多轮搜索（关键词迭代、交叉验证）
需要子任务委派（一个 Agent 负责搜集资料、另一个负责事实核查）
需要持久化状态（保存中间结果、支持断点续传）
需要文件系统（管理草稿、引用、图表）

传统 Agent 在这些场景下会陷入"迷失方向"、"重复劳动"、"半途而废"的困境。

二、Deep Agents 的核心架构

Deep Agents 通过引入 四大核心组件 来突破上述限制：

graph TB
    User[用户接口] --> Orchestrator[编排器]
    
    Orchestrator --> PlanningTool[Planning Tool<br/>规划工具]
    Orchestrator --> Memory[Memory System<br/>记忆系统]
    Orchestrator --> SubAgent[Sub-Agent Manager<br/>子智能体管理器]
    Orchestrator --> FileSystem[File System<br/>文件系统]
    
    PlanningTool --> TaskDecompose[任务分解]
    PlanningTool --> StepGenerate[步骤生成]
    
    Memory --> Episodic[情景记忆]
    Memory --> Semantic[语义记忆]
    Memory --> Procedural[程序记忆]
    
    SubAgent --> SubAgent1[Sub-Agent 1]
    SubAgent --> SubAgent2[Sub-Agent 2]
    SubAgent --> SubAgentN[Sub-Agent N]
    
    FileSystem --> TempFiles[临时文件]
    FileSystem --> Artifacts[制品输出]
    
    style Orchestrator fill:#C4612F,color:#fff
    style PlanningTool fill:#F2E3D6
    style Memory fill:#F2E3D6
    style SubAgent fill:#F2E3D6
    style FileSystem fill:#F2E3D6

2.1 组件 1：Planning Tool（规划工具）

功能：将复杂任务分解为可执行的步骤序列。

实现原理：

使用 思维链提示（Chain-of-Thought）引导 LLM 生成结构化计划
支持 层次化规划（Hierarchical Planning）：高层目标 → 子任务 → 原子操作
动态调整计划（基于执行反馈）

示例：

# 输入任务
task = "研究 Rust 的异步编程模型并撰写技术博客"

# LLM 生成的计划
plan = [
    {
        "step": 1,
        "action": "搜索 Rust async/await 官方文档",
        "expected_output": "核心概念清单"
    },
    {
        "step": 2,
        "action": "搜索 Tokio 运行时实现细节",
        "expected_output": "技术架构图"
    },
    {
        "step": 3,
        "action": "对比 Go/Node.js 的异步模型",
        "expected_output": "差异分析表格"
    },
    {
        "step": 4,
        "action": "撰写博客大纲",
        "expected_output": "Markdown 文件"
    }
]

2.2 组件 2：Sub-Agents（子智能体）

功能：将任务委派给专业化的 Worker Agent，实现并行执行和职责分离。

架构模式：Coordinator-Worker 模式

主 Agent（Coordinator）
    ├─ 负责任务分解和结果汇总
    └─ 不执行具体工作

子 Agent（Workers）
    ├─ 专注于单一子任务
    ├─ 独立的上下文窗口
    └─ 可以并行运行

优势：

上下文隔离：每个 Worker 只关注自己的子任务，避免上下文污染
并行执行：3 个子 Agent 同时搜索不同数据源，耗时从 3×30秒降至 30秒
可恢复性：单个 Worker 失败不影响整体任务

实现示例（伪代码）：

class CoordinatorAgent:
    def execute(self, task):
        # 1. 规划
        plan = self.planning_tool.decompose(task)
        
        # 2. 并行委派
        futures = []
        for subtask in plan:
            worker = self.spawn_worker(subtask.type)
            future = worker.execute_async(subtask)
            futures.append(future)
        
        # 3. 汇总结果
        results = await asyncio.gather(*futures)
        return self.synthesize(results)

2.3 组件 3：Memory System（记忆系统）

传统 Agent 的记忆是"一次性"的（对话结束即丢失）。Deep Agents 引入 三层记忆架构：

graph TB
    subgraph Episodic[情景记忆 Episodic Memory]
        E1[对话历史]
        E2[操作日志]
        E3[执行轨迹]
    end
    
    subgraph Semantic[语义记忆 Semantic Memory]
        S1[知识图谱]
        S2[概念索引]
        S3[向量数据库]
    end
    
    subgraph Procedural[程序记忆 Procedural Memory]
        P1[工作流模板]
        P2[最佳实践]
        P3[策略库]
    end
    
    Agent[Deep Agent] --> Episodic
    Agent --> Semantic
    Agent --> Procedural
    
    Episodic --> ShortTerm[短期存储<br/>会话级别]
    Semantic --> LongTerm[长期存储<br/>持久化]
    Procedural --> LongTerm
    
    style Agent fill:#C4612F,color:#fff
    style Episodic fill:#F2E3D6
    style Semantic fill:#F2E3D6
    style Procedural fill:#F2E3D6

技术实现：

向量数据库（如 Pinecone、Chroma）存储语义记忆
图数据库（如 Neo4j）存储知识关系
Checkpoint 机制 支持断点续传

2.4 组件 4：Virtual File System（虚拟文件系统）

为什么需要？
复杂任务通常涉及中间产物（草稿、数据集、配置文件）。传统 Agent 将所有内容塞进上下文，导致 token 浪费。

解决方案：
引入沙盒化的文件系统，Agent 可以：

创建、读取、修改文件
在子 Agent 间共享文件
版本控制（支持回滚）

示例：

# Agent 的工作目录结构
/workspace
  ├── research/
  │   ├── rust_async_docs.md
  │   ├── tokio_architecture.png
  │   └── comparison_table.csv
  ├── drafts/
  │   └── blog_outline_v1.md
  └── final/
      └── published_blog.md

三、核心算法：ReAct++ 与 Reflexion

3.1 ReAct 的进化

传统 ReAct：

Thought → Action → Observation → (循环)

Deep Agents 的 ReAct++：

graph LR
    Plan[规划 Plan] --> Reason[推理 Reason]
    Reason --> Act[行动 Act]
    Act --> Observe[观察 Observe]
    Observe --> Reflect[反思 Reflect]
    Reflect --> UpdatePlan[更新计划]
    UpdatePlan --> Reason
    
    Reflect -.-> Memory[(记忆系统)]
    Memory -.-> Reason
    
    style Plan fill:#C4612F,color:#fff
    style Reflect fill:#F2E3D6
    style Memory fill:#F2E3D6

Reflection 的作用：
Agent 会自我评估："这一步是否有效？是否偏离目标？"

示例对话：

Agent (Thought): 我需要搜索 Rust async 的实现原理
Agent (Action): web_search("Rust async implementation")
Agent (Observation): 返回了 5 篇文章，但都是入门教程
Agent (Reflection): 这些结果太浅显，我需要更深入的技术文档
Agent (Update Plan): 修改搜索关键词为 "Rust Future trait internals"

3.2 Reflexion 机制

Reflexion 是一种"从失败中学习"的机制：

Agent 执行任务（可能失败）
系统生成失败反思（如"工具选择错误"、"参数不当"）
将反思写入 Episodic Memory
下次遇到类似任务时，优先检索相关反思

伪代码：

def execute_with_reflexion(task):
    # 1. 检索历史反思
    past_failures = memory.query_similar(task)
    
    # 2. 增强提示词
    prompt = f"""
    Task: {task}
    
    Previous Failures:
    {past_failures}
    
    Learn from these mistakes and avoid them.
    """
    
    # 3. 执行
    result = agent.run(prompt)
    
    # 4. 如果失败，生成反思
    if result.failed:
        reflection = llm.reflect(task, result.error)
        memory.store(reflection)
    
    return result

四、实战：LangChain Deep Agents 实现

4.1 技术栈

框架：LangChain 1.0 + LangGraph
LLM：Claude Opus 4.8 / GPT-4
内存：Chroma（向量数据库）
文件系统：本地沙盒（通过 Docker 隔离）

4.2 代码示例：构建一个研究 Agent

from langgraph.graph import StateGraph, END
from langchain_anthropic import ChatAnthropic
from langchain.tools import DuckDuckGoSearchRun, WikipediaQueryRun

# 定义状态
class ResearchState:
    task: str
    plan: List[dict]
    current_step: int
    memory: List[str]
    artifacts: dict  # 文件系统

# 1. 规划节点
def planning_node(state: ResearchState):
    llm = ChatAnthropic(model="claude-opus-4")
    prompt = f"分解任务为步骤：{state.task}"
    plan = llm.invoke(prompt)  # 返回结构化 JSON
    state.plan = plan
    return state

# 2. 执行节点（并行 Worker）
async def execution_node(state: ResearchState):
    step = state.plan[state.current_step]
    
    # 根据步骤类型选择 Worker
    if step["type"] == "web_search":
        tool = DuckDuckGoSearchRun()
        result = await tool.arun(step["query"])
    elif step["type"] == "wiki_query":
        tool = WikipediaQueryRun()
        result = await tool.arun(step["query"])
    
    # 存储到文件系统
    state.artifacts[f"step_{state.current_step}.md"] = result
    state.current_step += 1
    return state

# 3. 反思节点
def reflection_node(state: ResearchState):
    # 检查当前结果是否满足预期
    last_result = state.artifacts[f"step_{state.current_step-1}.md"]
    llm = ChatAnthropic(model="claude-opus-4")
    
    reflection = llm.invoke(f"""
    任务：{state.task}
    当前结果：{last_result}
    
    评估：结果是否充分？是否需要调整计划？
    """)
    
    if "需要重新搜索" in reflection:
        # 动态调整计划
        state.plan.insert(state.current_step, {
            "type": "web_search",
            "query": reflection["建议关键词"]
        })
    
    return state

# 4. 构建图
workflow = StateGraph(ResearchState)
workflow.add_node("plan", planning_node)
workflow.add_node("execute", execution_node)
workflow.add_node("reflect", reflection_node)

workflow.add_edge("plan", "execute")
workflow.add_edge("execute", "reflect")
workflow.add_conditional_edge(
    "reflect",
    lambda state: "execute" if state.current_step < len(state.plan) else END
)

workflow.set_entry_point("plan")
agent = workflow.compile()

# 5. 运行
result = await agent.ainvoke({
    "task": "研究 Rust 的 async/await 实现原理",
    "plan": [],
    "current_step": 0,
    "memory": [],
    "artifacts": {}
})

4.3 关键技术点

LangGraph 的优势：

状态持久化：自动保存 Checkpoint
流式输出：实时展示 Agent 推理过程
人工干预：支持在关键节点暂停等待审核

中间件架构：

graph LR
    Request[请求] --> Auth[权限中间件]
    Auth --> Logger[日志中间件]
    Logger --> Memory[记忆中间件]
    Memory --> Core[核心 Agent]
    Core --> Validation[验证中间件]
    Validation --> Response[响应]
    
    Auth -.-> Reject1[拒绝]
    Validation -.-> Reject2[重试]
    
    style Core fill:#C4612F,color:#fff
    style Auth fill:#F2E3D6
    style Memory fill:#F2E3D6
    style Validation fill:#F2E3D6

五、性能对比与最佳实践

5.1 实测数据

任务类型	传统 Agent	Deep Agent	提升
市场调研报告	45 分钟	12 分钟	73%
代码库重构	失败（上下文溢出）	成功	N/A
多轮对话（>20 轮）	$3.50	$0.80	77%

成本降低原因：

子 Agent 并行执行 → 总 token 数减少
文件系统 → 避免重复传输大文件
Memory → 避免重复推理

5.2 最佳实践

何时使用 Deep Agents？

✅ 适用场景：

多步骤、长时程任务（如研究、代码生成、数据分析）
需要并行化的任务（如爬取多个网站）
需要断点续传的任务

❌ 不适用场景：

简单的单轮对话（如"翻译这段话"）
实时性要求极高的场景（规划开销 ~2-3 秒）

架构选择：

小任务（<5 步）：ReAct 足够
中型任务（5-15 步）：ReAct + Memory
大型任务（>15 步）：完整 Deep Agent 架构

六、未来展望

6.1 技术演进方向

多模态 Deep Agents：
当前主要处理文本，未来将融合视觉（图表生成）、语音（播客创作）
分布式协作：
多个 Deep Agent 组成"Agent 集群"，协同完成超大型任务（如"重构整个微服务架构"）
强化学习集成：
通过 RLHF（人类反馈强化学习）持续优化 Agent 的决策策略

6.2 开源生态

LangChain Deep Agents：生产级框架
AutoGPT：早期探索（已逐渐式微）
Microsoft Semantic Kernel：企业级 Agent 框架
RUC DeepAgent：学术界的端到端推理 Agent

结语

Deep Agents 不是简单的技术升级，而是 AI Agent 范式的根本性转变：从"被动响应"到"主动规划"，从"单线程执行"到"并行协作"，从"无状态对话"到"持久化记忆"。

对于开发者而言，理解 Deep Agents 的架构原理，意味着能够构建真正实用的 AI 自动化系统——不再是演示 Demo，而是能落地生产环境、为用户创造价值的智能助手。

随着 LangChain 1.0、Claude 5 等新一代工具的成熟，Deep Agents 正从实验室走向现实世界。现在，正是深入学习和实践的最佳时机。

参考资料

作者：changel
发布日期：2026年7月20日
标签：#AI #Agent #架构设计 #LangChain #DeepAgent

Markdown 扩展功能

Wed, 01 May 2024 00:00:00 GMT

GitHub 仓库卡片

你可以添加链接到 GitHub 仓库的动态卡片，页面加载时，仓库信息会从 GitHub API 获取。

::github{repo="Fabrizz/MMM-OnSpotify"}

使用代码 ::github{repo="<所有者>/<仓库>"} 创建 GitHub 仓库卡片。

::github{repo="saicaca/fuwari"}

提示块

支持以下类型的提示块：note tip important warning caution

:::note 突出显示用户应该注意的信息，即使是在浏览时。 :::

:::tip 可选信息，帮助用户更成功。 :::

:::important 用户成功所需的关键信息。 :::

:::warning 由于潜在风险而需要立即引起用户注意的关键内容。 :::

:::caution 行动的负面潜在后果。 :::

基本语法

:::note
突出显示用户应该注意的信息，即使是在浏览时。
:::

:::tip
可选信息，帮助用户更成功。
:::

自定义标题

提示块的标题可以自定义。

:::note[我的自定义标题] 这是一个带有自定义标题的提示块。 :::

:::note[我的自定义标题]
这是一个带有自定义标题的提示块。
:::

GitHub 语法

[!TIP] 也支持 GitHub 语法。

> [!NOTE]
> 也支持 GitHub 语法。

> [!TIP]
> 也支持 GitHub 语法。

剧透

你可以在文本中添加剧透。文本也支持 Markdown 语法。

内容 :spoiler[被隐藏了哈哈]！

内容 :spoiler[被隐藏了 **哈哈**]！

Expressive Code 示例

Wed, 10 Apr 2024 00:00:00 GMT

在这里，我们将探索如何使用 Expressive Code 展示代码块。提供的示例基于官方文档，你可以参考官方文档了解更多详情。

Expressive Code

语法高亮

常规语法高亮

console.log('这段代码有语法高亮！')

渲染 ANSI 转义序列

ANSI 颜色:
- 常规: [31m红色[0m [32m绿色[0m [33m黄色[0m [34m蓝色[0m [35m品红[0m [36m青色[0m
- 粗体:    [1;31m红色[0m [1;32m绿色[0m [1;33m黄色[0m [1;34m蓝色[0m [1;35m品红[0m [1;36m青色[0m
- 暗淡:  [2;31m红色[0m [2;32m绿色[0m [2;33m黄色[0m [2;34m蓝色[0m [2;35m品红[0m [2;36m青色[0m

256 色 (显示颜色 160-177):
[38;5;160m160 [38;5;161m161 [38;5;162m162 [38;5;163m163 [38;5;164m164 [38;5;165m165[0m
[38;5;166m166 [38;5;167m167 [38;5;168m168 [38;5;169m169 [38;5;170m170 [38;5;171m171[0m
[38;5;172m172 [38;5;173m173 [38;5;174m174 [38;5;175m175 [38;5;176m176 [38;5;177m177[0m

完整 RGB 颜色:
[38;2;34;139;34m森林绿 - RGB(34, 139, 34)[0m

文本格式: [1m粗体[0m [2m暗淡[0m [3m斜体[0m [4m下划线[0m

编辑器和终端框架

代码编辑器框架

console.log('标题属性示例')

<!-- src/content/index.html -->
<div>文件名注释示例</div>

终端框架

echo "这个终端框架没有标题"

Write-Output "这个有标题！"

覆盖框架类型

echo "看，没有框架！"

# 如果不覆盖，这将是一个终端框架
function Watch-Tail { Get-Content -Tail 20 -Wait $args }
New-Alias tail Watch-Tail

文本和行标记

标记完整行和行范围

// 第 1 行 - 按行号定位
// 第 2 行
// 第 3 行
// 第 4 行 - 按行号定位
// 第 5 行
// 第 6 行
// 第 7 行 - 按范围 "7-8" 定位
// 第 8 行 - 按范围 "7-8" 定位

选择行标记类型 (mark, ins, del)

function demo() {
  console.log('这一行标记为删除')
  // 这一行和下一行标记为插入
  console.log('这是第二个插入行')

  return '这一行使用中性默认标记类型'
}

向行标记添加标签

// labeled-line-markers.jsx
<button
  role="button"
  {...props}
  value={value}
  className={buttonClassName}
  disabled={disabled}
  active={active}
>
  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

在单独的行上添加长标签

// labeled-line-markers.jsx
<button
  role="button"
  {...props}

  value={value}
  className={buttonClassName}

  disabled={disabled}
  active={active}
>

  {children &&
    !active &&
    (typeof children === 'string' ? <span>{children}</span> : children)}
</button>

使用类似 diff 的语法

+这一行将标记为插入
-这一行将标记为删除
这是一个常规行

--- a/README.md
+++ b/README.md
@@ -1,3 +1,4 @@
+这是一个实际的 diff 文件
-所有内容将保持不变
 空白也不会被移除

将语法高亮与类似 diff 的语法结合

  function thisIsJavaScript() {
    // 整个块被高亮显示为 JavaScript，
    // 我们仍然可以向它添加 diff 标记！
-   console.log('要删除的旧代码')
+   console.log('全新的闪亮代码！')
  }

标记行内的单个文本

function demo() {
  // 标记行内的任何给定文本
  return '支持给定文本的多个匹配项';
}

正则表达式

console.log('单词 yes 和 yep 将被标记。')

转义正斜杠

echo "Test" > /home/test.txt

选择内联标记类型 (mark, ins, del)

function demo() {
  console.log('这些是插入和删除标记类型');
  // return 语句使用默认标记类型
  return true;
}

自动换行

按块配置自动换行

// 启用 wrap 的示例
function getLongString() {
  return '这是一个非常长的字符串，除非容器非常宽，否则很可能无法适应可用空间'
}

// 禁用 wrap 的示例
function getLongString() {
  return '这是一个非常长的字符串，除非容器非常宽，否则很可能无法适应可用空间'
}

配置换行的缩进

// 启用 preserveIndent 的示例（默认启用）
function getLongString() {
  return '这是一个非常长的字符串，除非容器非常宽，否则很可能无法适应可用空间'
}

// 禁用 preserveIndent 的示例
function getLongString() {
  return '这是一个非常长的字符串，除非容器非常宽，否则很可能无法适应可用空间'
}

可折叠部分

// 所有这些样板设置代码将被折叠
import { someBoilerplateEngine } from '@example/some-boilerplate'
import { evenMoreBoilerplate } from '@example/even-more-boilerplate'

const engine = someBoilerplateEngine(evenMoreBoilerplate())

// 这部分代码默认可见
engine.doSomething(1, 2, 3, calcFn)

function calcFn() {
  // 你可以有多个折叠部分
  const a = 1
  const b = 2
  const c = a + b

  // 这将保持可见
  console.log(`计算结果: ${a} + ${b} = ${c}`)
  return c
}

// 所有这些代码直到块的末尾将再次被折叠
engine.closeConnection()
engine.freeMemory()
engine.shutdown({ reason: '示例样板代码结束' })

行号

按块显示行号

// 这个代码块将显示行号
console.log('来自第 2 行的问候！')
console.log('我在第 3 行')

// 此块禁用行号
console.log('你好？')
console.log('抱歉，你知道我在哪一行吗？')

更改起始行号

console.log('来自第 5 行的问候！')
console.log('我在第 6 行')

Fuwari 简易指南

Mon, 01 Apr 2024 00:00:00 GMT

封面图片来源：来源

这个博客模板是用 Astro 构建的。对于本指南中未提及的内容，你可以在 Astro 文档中找到答案。

文章的 Front-matter

---
title: 我的第一篇博客文章
published: 2023-09-09
description: 这是我新 Astro 博客的第一篇文章。
image: ./cover.jpg
tags: [Foo, Bar]
category: 前端
draft: false
---

属性	描述
`title`	文章的标题。
`published`	文章发布的日期。
`description`	文章的简短描述。显示在索引页面上。
`image`	文章的封面图片路径。<br/>1. 以 `http://` 或 `https://` 开头：使用网络图片<br/>2. 以 `/` 开头：使用 `public` 目录中的图片<br/>3. 没有这些前缀：相对于 markdown 文件的路径
`tags`	文章的标签。
`category`	文章的分类。
`draft`	如果这篇文章仍然是草稿，则不会显示。

文章文件的放置位置

你的文章文件应该放在 src/content/posts/ 目录中。你也可以创建子目录来更好地组织你的文章和资源。

src/content/posts/
├── post-1.md
└── post-2/
    ├── cover.png
    └── index.md

Markdown 示例

Sun, 01 Oct 2023 00:00:00 GMT

一级标题

段落之间用空行分隔。

第二段。斜体，粗体，以及 等宽字体。无序列表如下所示：

这是第一项
这是第二项
这是第三项

请注意，实际的文本内容从 4 列开始（不考虑星号）。

引用块就是这样写的。

它们可以跨越多个段落，如果你喜欢的话。

使用 3 个连字符表示破折号。使用 2 个连字符表示范围（例如，"全部都在 5-10 页"）。

二级标题

这是一个示例链接到百度。

三级标题

现在是一个嵌套列表：

首先，获取以下配料：
- 胡萝卜
- 芹菜
- 小扁豆
将配料煮沸大约 10 分钟
然后就可以享用了

注意同一列表内不同项之间的空行是可选的，但列表之间和列表与普通段落之间必须有空行。

这是一个水平分割线：

这是一个代码块，使用缩进：

// 这是代码
console.log('Hello World!');

或者使用代码围栏：

function greeting() {
    console.log('你好，世界！');
}

内联代码使用 反引号 包裹。

这是一个表格：

左对齐	居中对齐	右对齐
内容	内容	内容
内容	内容	内容

图片语法：

粗体文本 和 斜体文本 和 粗斜体文本。

~~删除线文本~~

任务列表：

[x] 已完成的任务
[ ] 未完成的任务
[ ] 另一个未完成的任务

这就是 Markdown 的基础！

在文章中嵌入视频

Tue, 01 Aug 2023 00:00:00 GMT

只需从 YouTube 或其他平台复制嵌入代码，然后粘贴到 markdown 文件中即可。

---
title: 在文章中嵌入视频
published: 2023-10-19
// ...
---

<iframe width="100%" height="468" src="https://www.youtube.com/embed/5gIf0_xpFPI?si=N1WTorLKL0uwLsU_" title="YouTube video player" frameborder="0" allowfullscreen></iframe>

YouTube

Bilibili

草稿示例

Fri, 01 Jul 2022 00:00:00 GMT

这篇文章是草稿

这篇文章目前处于草稿状态，尚未发布。因此，它不会对普通访客可见。内容仍在进行中，可能需要进一步编辑和审查。

当文章准备好发布时，你可以在 Frontmatter 中将 "draft" 字段更新为 "false"：

---
title: 草稿示例
published: 2024-01-11T04:40:26.381Z
tags: [Markdown, 博客, 示例]
category: 示例
draft: false
---