• 反射：UE 通过 UClass/UProperty 等系统在运行时提供类型信息和动态访问能力。
  UE 的反射系统是通过 UHT 工具和特定宏实现的代码生成机制。你用 UCLASS 标记类、UPROPERTY 标记变量、UFUNCTION 标记函数，这些宏会被 UHT 识别。
  UHT 在编译前扫描这些标记，生成.generated.h 和.cpp 文件，里面包含类的反射注册代码，比如 StaticClass () 函数和 UClass 对象的构造逻辑。
  生成的代码会把类信息注册到引擎全局的 GObjectClasses 数组里，让引擎在运行时能动态获取类结构、调用函数或访问属性，这支撑了蓝图交互、垃圾回收等核心功能。

因为 UE 需要在运行时动态处理代码信息。比如蓝图可视化编程，引擎得通过反射知道 C++ 类有哪些函数和变量，才能让蓝图调用它们。

比如你在 C++ 里写了一个角色类，里面有个 UFUNCTION 标记的跳跃函数 Jump ()。没有反射的话，蓝图编辑器根本不知道这个 Jump () 函数存在，因为编译后的机器码里，函数名和参数这些信息都被优化掉了。
有了反射，UHT 会在编译时为这个 Jump () 函数生成反射元数据，包括函数名、参数类型、返回值，以及它属于哪个类。引擎运行时能通过这些元数据，在蓝图编辑器里把 Jump () 函数显示出来，你才能拖拽节点调用它。
如果后续你在 C++ 里给 Jump () 加了一个高度参数，反射系统会自动更新元数据，蓝图里对应的函数节点也会同步显示出新参数，整个过程不需要手动写任何蓝图和 C++ 交互的绑定代码。

回退操作 Command 模式（轻量级）：**

1
2
3
4

每次操作封装为 ICommand { Do(); Undo(); }
维护 undoStack 和 redoStack
执行操作 → 压入 undoStack，清空 redoStack
Undo → 弹出 undoStack，执行 Undo()，压入 redoStack

2. Snapshot 模式（适用于复杂场景）：

1
2
3
4

操作前序列化整个对象状态的快照
Undo 时直接恢复快照
优点：实现简单，不容易出 bug
缺点：内存开销大

实际项目中的混合方案：

• 简单属性修改 → Command 模式（记录 oldValue/newValue）
• 复杂操作（节点图变更、场景编辑）→ Snapshot 或 Diff 模式
• 合并机制：连续同类操作合并（如拖拽 Slider 时合并为一条记录）

UE智能指针对比表

关键区别说明

1. 管理对象边界：前三种严格用于UObject派生类，依赖UE垃圾回收系统；后三种用于非UObject类型，靠手动内存管理机制。

2. UObject指针细分：

• TObjectPtr是强引用，会让UObject保持存活，是日常开发的首选。
• TWeakObjectPtr是弱引用，当UObject被标记为回收时，指针会自动置空，常用在UI控件引用角色对象这类场景。
• TSoftObjectPtr存储的是资源路径而非直接内存地址，对象未加载时可异步加载，适合开放世界游戏引用远处的资源。

3. 非UObject指针细分：

• TSharedPtr通过引用计数共享对象，当引用计数为0时自动释放内存，但需注意手动避免循环引用。
• TUniquePtr是独占式指针，不允许复制，只能通过移动语义转移所有权，性能开销最小。
• TWeakPtr需要绑定到TSharedPtr使用，当TSharedPtr释放对象后，TWeakPtr会自动失效，解决循环引用问题。

ECS 架构是什么？和传统 OOP 有什么区别？

核心概念：

• Entity：ID 标识，不存数据
• Component：纯数据（Position, Velocity, Health…）
• System：纯逻辑（MovementSystem 遍历所有 Position+Velocity 组件）

核心区别：OOP 以对象为核心，数据与逻辑封装在类中，易形成复杂继承树；ECS 将数据与逻辑分离，实体为组件容器，系统批量处理同类组件，数据连续存储提升缓存效率，支持动态组合与并行计算。
UE5 Mass 系统案例：作为 ECS 实现，Mass 用 “片段” 存储实体数据，“处理器” 统一处理逻辑。如《黑客帝国》Demo 中的万人级 crowd 模拟，通过将角色位置、速度等数据打包连续存储，移动处理器可批量更新所有角色坐标，性能远超传统 Actor 方案。

堆Stack 栈heap

• 堆（Heap）：动态分配内存，大小不固定，生命周期由程序员控制，访问速度较慢，适合存储大对象或需要在运行时确定大小的数据。（没有固定的存取顺序）
• 栈（Stack）：自动分配内存，大小固定，生命周期由函数调用控制，访问速度快，适合存储局部变量和函数参数。（有固定的存取顺序，后进先出）

Function Calling 的原理是什么？你在项目中怎么用的？

原理： LLM 不直接执行函数，而是 输出结构化的函数调用意图（函数名 + 参数），由宿主程序解析并执行。

RAG 是什么？你是怎么实现的？

RAG（Retrieval-Augmented Generation） = 先检索相关文档，再让 LLM 基于检索结果回答。

ControlNet 是什么？它解决了什么问题？

参考答案：

ControlNet 为预训练 Diffusion Model 添加 空间控制能力。

解决的问题： 原始 Text-to-Image 无法精确控制生成图像的构图、姿态、边缘等空间结构。

原理：

• 在 Stable Diffusion 的 U-Net 每个 Block 上添加一个并行的 “Zero Convolution” 分支
• 输入额外的条件图（边缘检测/Canny、深度图、姿态/OpenPose、法线贴图等）
• 训练时只训练 ControlNet 分支，冻结原始模型

常见 ControlNet 类型：

• Canny Edge：控制轮廓
• Depth：控制深度结构
• OpenPose：控制人物姿态
• Segment：控制区域分割
• Scribble：控制草图

LoRA 是什么？为什么它很受欢迎？

LoRA（Low-Rank Adaptation） 是一种参数高效微调方法。
LoRA 是一种参数高效的大模型微调技术，核心是冻结原模型权重，仅训练少量低秩矩阵来模拟任务适配所需的参数更新。它参数量仅为全量微调的 0.1%-1%，大幅降低显存占用和训练成本，且推理时可合并权重无额外延迟。
在游戏领域，能快速微调图生图模型生成风格统一的角色装备、场景素材，或微调对话模型让 NPC 生成符合设定的自然台词，适配小团队高效开发需求。

MVC、MVP、MVVM 的区别是什么？

• MVP的Preseter和MVVM的ViewModel在职责上非常相似，都是处理业务逻辑和数据交互的中介，但MVVM通过数据绑定机制让ViewModel直接更新View，减少了Presenter中大量的UI更新代码，使得代码更简洁、可测试性更强。MVVM适合复杂UI交互较多的项目，而MVP则更适合简单UI或需要严格分离测试的场景。

GPU 渲染流水线的完整阶段？

参考答案：

GPU 渲染管线（Rendering Pipeline）是 GPU 执行图形渲染的完整流程：

应用阶段（CPU 侧）：

1
2
3
4

1. 应用阶段（Application Stage）
   → 视锥体裁剪（Frustum Culling）
   → 批次合批（Draw Call Batching）
   → 输出 Draw Call + 顶点数据到 GPU

几何阶段（GPU 顶点着色器）：

1
2
3
4
5
6
7
8
9

2. 顶点着色器（Vertex Shader）
   → 模型空间 → 世界空间 → 视图空间 → 齐次裁剪空间
   → 顶点变换：LocalMatrix × WorldMatrix × ViewMatrix × ProjectionMatrix

3. 曲面细分（Tessellation，可选）
   → Hull Shader → Tessellator → Domain Shader

4. 几何着色器（Geometry Shader，可选）
   → 以图元为单位处理，可生成/销毁图元

光栅化阶段（Rasterization）：

1
2
3
4
5
6
7
8
9
10

5. 图元装配 & 裁剪
   → Clipping（齐次空间裁剪）
   → Perspective Divide → NDC → Viewport Transform

6. 背面剔除（Back-face Culling）
   → 根据顶 点环绕顺序（顺时针/逆时针）剔除背面

7. 光栅化（Rasterization）
   → 离散化：点/线/三角形 → 片段（Fragment）
   → 视口变换：NDC → Screen Space

片段/像素阶段：

1
2
3
4
5
6
7
8

8. 片段着色器（Fragment / Pixel Shader）
   → 逐像素着色：光照计算、纹理采样、颜色输出

9. 逐片段操作（Per-Fragment Operations）
   → 深度测试（Depth Test / Z-Test）
   → 模板测试（Stencil Test）
   → 混合（Alpha Blending）
   → 输出到 Framebuffer

UE “Reflection” Concept

• Reflection: UE provides runtime type information and dynamic access capabilities through systems like UClass and UProperty.
  UE’s reflection system is a code-generation mechanism implemented via the UHT tool and specific macros. You mark classes with UCLASS, variables with UPROPERTY, and functions with UFUNCTION — these macros are recognized by UHT.
  Before compilation, UHT scans these markers and generates .generated.h and .cpp files containing the reflection registration code for each class, such as the StaticClass() function and the construction logic for UClass objects.
  The generated code registers class information into the engine’s global GObjectClasses array, enabling the engine at runtime to dynamically retrieve class structure, invoke functions, or access properties — which in turn powers blueprint interaction, garbage collection, and other core features.

This exists because UE needs to dynamically process code information at runtime. Blueprint visual scripting, for example, requires the engine to know via reflection which functions and variables a C++ class exposes so that blueprints can call them.

Say you write a character class in C++ with a Jump() function marked with UFUNCTION. Without reflection, the blueprint editor has no idea Jump() exists — the function name, parameters, and all that metadata get optimized away in the compiled machine code.
With reflection, UHT generates reflection metadata for Jump() at compile time, including its name, parameter types, return value, and which class it belongs to. At runtime, the engine uses this metadata to surface Jump() in the blueprint editor as a callable node you can drag in.
If you later add a height parameter to Jump() in C++, the reflection system automatically updates the metadata, and the corresponding blueprint node syncs up to show the new parameter — no manual binding code between blueprint and C++ required.

Undo/Redo — Command Pattern (Lightweight)

1
2
3
4

Wrap each operation as ICommand { Do(); Undo(); }
Maintain undoStack and redoStack
Execute operation → push to undoStack, clear redoStack
Undo → pop from undoStack, call Undo(), push to redoStack

2. Snapshot Pattern (for complex scenarios):

1
2
3
4

Serialize a snapshot of the entire object state before each operation
On Undo, restore the snapshot directly
Pros: simple to implement, less prone to bugs
Cons: high memory overhead

Hybrid approach for real projects:

• Simple property edits → Command pattern (record oldValue/newValue)
• Complex operations (node graph changes, scene edits) → Snapshot or Diff pattern
• Merge mechanism: collapse consecutive operations of the same type (e.g., dragging a slider merges into a single history entry)

UE Smart Pointer Comparison

Key Distinctions

1. Object boundary: The first three are strictly for UObject-derived classes and rely on UE’s garbage collection system; the last three are for non-UObject types and use manual memory management.

2. UObject pointer breakdown:

   • TObjectPtr is a strong reference that keeps the UObject alive — the go-to choice for everyday development.
   • TWeakObjectPtr is a weak reference; when a UObject is marked for collection, the pointer is automatically nulled. Common in scenarios like UI widgets holding references to character objects.
   • TSoftObjectPtr stores a resource path rather than a direct memory address. The asset can be asynchronously loaded when it isn’t in memory, making it ideal for open-world games referencing distant assets.

3. Non-UObject pointer breakdown:

   • TSharedPtr shares an object via reference counting, automatically freeing memory when the count reaches zero. Be mindful of circular references — they must be avoided manually.
   • TUniquePtr is an exclusive pointer: no copying allowed, ownership transfers only through move semantics. Lowest performance overhead.
   • TWeakPtr must be bound to a TSharedPtr. Once TSharedPtr releases the object, TWeakPtr automatically becomes invalid, resolving circular reference issues.

What is ECS Architecture? How Does It Differ from Traditional OOP?

ECS essentially saves CPU time on data lookups.

Core concepts:

• Entity: an ID only, stores no data
• Component: pure data (Position, Velocity, Health…)
• System: pure logic (MovementSystem iterates all Position+Velocity components)

Core difference: OOP centers on objects — data and logic are encapsulated in classes, which tends to grow complex inheritance trees. ECS separates data from logic: entities are containers for components, systems process batches of the same component type, contiguous data storage improves cache efficiency, and the architecture naturally supports dynamic composition and parallel computation.
UE5 Mass system example: as an ECS implementation, Mass stores entity data in “fragments” and unifies logic in “processors.” The Matrix Awakens demo’s crowd simulation of thousands of characters packs position, velocity, and other data into contiguous storage, letting the movement processor batch-update all character coordinates — performance that far exceeds the traditional Actor approach.

Stack vs. Heap

• Heap: Dynamically allocated memory, variable size, lifetime controlled by the programmer, slower access. Suitable for large objects or data whose size is determined at runtime. (No fixed access order.)
• Stack: Automatically allocated memory, fixed size, lifetime controlled by the function call, fast access. Suitable for local variables and function parameters. (Fixed access order: last in, first out.)

What Is Function Calling and How Have You Used It in Projects?

How it works: The LLM doesn’t execute functions directly — it outputs a structured function-call intent (function name + arguments), which the host program parses and executes.

What Is RAG and How Did You Implement It?

RAG (Retrieval-Augmented Generation) = retrieve relevant documents first, then have the LLM answer based on those retrieved results.

What Is ControlNet and What Problem Does It Solve?

Reference answer:

ControlNet adds spatial control capabilities to a pretrained Diffusion Model.

The problem it solves: Raw Text-to-Image generation cannot precisely control the composition, pose, edges, or other spatial structure of generated images.

How it works:

• A parallel “Zero Convolution” branch is added to each block of Stable Diffusion’s U-Net
• Additional conditioning images are fed as input (edge detection / Canny, depth maps, pose / OpenPose, normal maps, etc.)
• During training, only the ControlNet branch is trained; the original model weights are frozen

Common ControlNet types:

• Canny Edge: controls outlines
• Depth: controls depth structure
• OpenPose: controls human pose
• Segment: controls region segmentation
• Scribble: controls sketch-based guidance

What Is LoRA and Why Is It So Popular?

LoRA (Low-Rank Adaptation) is a parameter-efficient fine-tuning method.
LoRA freezes the original model weights and trains only a small number of low-rank matrices to approximate the parameter updates needed for task adaptation. The trainable parameter count is just 0.1%–1% of full fine-tuning, drastically reducing VRAM usage and training cost. During inference, the weights can be merged with the base model, adding no extra latency.
In game development, LoRA lets you quickly fine-tune an image-to-image model to generate stylistically consistent character equipment and environment assets, or fine-tune a dialogue model so NPCs produce setting-appropriate natural dialogue — a great fit for small teams that need to move fast.

What Is the Difference Between MVC, MVP, and MVVM?

MVP’s Presenter and MVVM’s ViewModel are very similar in responsibility — both act as intermediaries handling business logic and data interaction. The key difference is that MVVM’s data-binding mechanism lets ViewModel update the View directly, eliminating the large amount of UI-update code you’d write in a Presenter. This makes the code more concise and testable. MVVM suits projects with complex, frequent UI interactions; MVP fits simpler UIs or scenarios where strict test isolation is needed.

What Are the Complete Stages of the GPU Rendering Pipeline?

Reference answer:

The GPU Rendering Pipeline is the full process by which a GPU executes graphics rendering:

Application Stage (CPU side):

1
2
3
4

1. Application Stage
   → Frustum Culling
   → Draw Call Batching
   → Outputs Draw Calls + vertex data to GPU

Geometry Stage (GPU vertex shaders):

1
2
3
4
5
6
7
8
9

2. Vertex Shader
   → Model Space → World Space → View Space → Homogeneous Clip Space
   → Vertex transform: LocalMatrix × WorldMatrix × ViewMatrix × ProjectionMatrix

3. Tessellation (optional)
   → Hull Shader → Tessellator → Domain Shader

4. Geometry Shader (optional)
   → Processes per-primitive, can emit or discard primitives

Rasterization Stage:

1
2
3
4
5
6
7
8
9
10

5. Primitive Assembly & Clipping
   → Clipping (homogeneous space clipping)
   → Perspective Divide → NDC → Viewport Transform

6. Back-face Culling
   → Discards back-facing primitives based on vertex winding order (CW/CCW)

7. Rasterization
   → Discretization: points / lines / triangles → Fragments
   → Viewport Transform: NDC → Screen Space

Fragment / Pixel Stage:

1
2
3
4
5
6
7
8

8. Fragment Shader (Pixel Shader)
   → Per-pixel shading: lighting calculations, texture sampling, color output

9. Per-Fragment Operations
   → Depth Test (Z-Test)
   → Stencil Test
   → Alpha Blending
   → Output to Framebuffer

目标：以最少的折腾时间，把 Obsidian 用成”长期可复利”的知识库；先稳住基本功，再按需扩展插件与方法论。

0. 为什么是 Obsidian

• 本地优先：所有笔记是 .md 纯文本，跟随 Git/网盘随便同步；与本仓库 Hexo 博客天然兼容（notes/_posts/**/*.md 可直接被博客引擎消费）。
• 链接驱动：用 [[wikilink]] 把碎片连成网，长期沉淀越久越值钱。
• 插件生态：核心插件 + 社区插件 ≈ “可编程的笔记系统”。
• 零锁定：随时可以离开，文件即数据。

1. 我自己的文件目录路径

这个 Vault 的根目录 C:\Users\youdr\iCloudDrive\Doc\notes\ 下有四个隐藏文件夹，分别服务于不同的工具链：

1
2
3
4
5

notes/
├── .claude/       # Claude Code 的 vault 级配置
├── .claudian/     # Claudian 插件的运行时数据
├── .obsidian/     # Obsidian 本体的所有配置
└── .omc/          # oh-my-claudecode (OMC) 的状态存储

1. 学习路径总览（建议按周推进）

2. W1：基础——把”骨架”立起来

2.1 核心概念

• Vault（库）：一个文件夹 = 一个 Vault。所有 .md 与 .obsidian/ 配置都在里面。
• Note（笔记）：一个 .md 文件 = 一条笔记。命名建议：日期前缀 + 主题，如 20260509.ObsidianFunctionLearning.md。
• Frontmatter（YAML 元数据）：文件最顶部的 --- 块，存放 title / tags / date / status，被 Dataview / 主题 / Hexo 共同消费。
• Link（双链）：[[文件名]] 或 [[文件名|显示文本]]；[[A#二级标题]] 跳转到具体小节；[[A^block-id]] 引用块。
• Backlink（反向链接）：右侧面板自动列出”谁链接了我”，是 Obsidian 的灵魂功能。
• Tag（标签）：#topic/subtopic 支持层级；和文件夹是互补关系，不是替代。

2.2 必须背下来的快捷键

2.3 W1 练习

1. 在 notes/ 打开 Vault，写 3 条笔记（任意主题）。
2. 让其中两条用 [[]] 互相链接。
3. 给每条加 tags: [...]，在右侧面板看 Backlink。

3. W2：组织——确立结构与模板

3.1 文件夹策略（与本仓库现状对齐）

当前仓库已有的目录可直接套用：

1
2
3
4
5
6
7

notes/
├── _posts/        # Hexo 发布的正式文章（双语）
│   ├── zh-CN/
│   └── en/
├── Learning/      # 学习笔记 / 个人草稿（本文件所在）
├── AIdocs/        # 项目级架构、决策、路线图
└── about/         # 关于页

建议在 Learning/ 下再分：

• daily/：每日笔记（自动创建）
• topic/：主题长文（成熟后迁出到 _posts/）
• inbox/：临时草稿，未分类

3.2 三种主流方法论（任选其一即可，别全上）

建议：你已经有 _posts / Learning / AIdocs 这种”项目+资源”分布，先跑 PARA，等笔记数量过 500 篇再考虑 Zettelkasten。

3.3 必装核心插件（自带）

进入 设置 → 核心插件，把这些打开：

• ✅ Daily Notes：每日一篇时间轴笔记
• ✅ Templates：插入模板内容
• ✅ Outline：右侧大纲
• ✅ Backlinks / Outgoing Links：反向 / 正向链接面板
• ✅ Graph View：知识图谱
• ✅ Tag Pane：标签面板
• ✅ File Recovery：自动备份，强烈推荐
• ⚠️ Workspaces：多布局切换（进阶可开）

4. W3：进阶——让笔记自己动起来

4.1 必装社区插件（短列表，不要贪多）

4.2 Dataview 入门示例

在任意笔记里写：

1
2
3
4
5
6

```dataview
TABLE date, status, file.tags AS tags
FROM "Learning"
WHERE status = "in-progress"
SORT date DESC
```

→ 自动列出 Learning/ 下所有 status: in-progress 的笔记。

4.3 Templater 模板示例

在 notes/Templates/learning.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

---
title: <% tp.file.title %>
date: <% tp.date.now("YYYY-MM-DD") %>
tags: []
status: in-progress
---

# <% tp.file.title %>

## 背景

## 内容

## 参考

→ 新建笔记时一键套用，title / date 自动填。

5. W4：工作流——把 Obsidian 嵌进现有管线

本仓库是 Hexo 博客 + Git 版本管理 + Obsidian 笔记 的三件套，目标是：

1
2
3
4

草稿（Learning/inbox/） →
成熟（Learning/topic/） →
发布（_posts/zh-CN/ 与 _posts/en/） →
博客上线（Hexo build）

5.1 与 Hexo 兼容的 frontmatter

博客文章需要的字段（参考 notes/_posts/ 现有文章）：

1
2
3
4
5
6
7

---
title: 文章标题
date: 2026-05-09 12:00:00
categories: [分类]
tags: [标签1, 标签2]
lang: zh-CN
---

5.2 与 Git 联动

• 用 Obsidian Git 插件做”自动 commit”。
• 但本仓库已经有自己的提交规范（见 git log 风格），建议：
  • 写作期间：手动 commit。
  • 每日睡前：用 Obsidian Git 一键 push。

5.3 与博客主题（hexo-theme-magnetic）的注意事项

• 你当前主题里的 tag-graph.js 与 Obsidian Graph View 是两套图谱，互不影响。
• 笔记里 [[wikilink]] 在博客渲染时不会自动转成超链接（除非装 Hexo 插件 hexo-filter-github-emojis 类的扩展）。如果要发到博客，改成标准 Markdown 链接。

6. 进阶专题（按需展开）

6.1 Canvas（白板）

内置功能，新建白板 → 把多张笔记拖进来当卡片，画连线。适合做知识地图、项目看板。

6.2 Sync 方案对比

6.3 移动端

• iOS / Android 客户端免费。
• 移动端 + iCloud / Git 跨设备 → 手机随手记，电脑深度整理。

7. 路径布置建议（针对本仓库）

关键问题：根目录 D:\Project\UGit\EugenePage\.obsidian 已存在，说明 Vault 当前打开的是整个仓库而不是 notes/。

两种方案，二选一：

方案 A：把 notes/ 单独作为 Vault（推荐）

• 在 Obsidian 起始页 → “打开文件夹作为库” → 选 D:\Project\UGit\EugenePage\notes。
• 优点：Vault 范围干净，只看到笔记，不被 themes/、scripts/ 干扰。
• 操作：把根目录的 .obsidian/ 移动到 notes/.obsidian/（或删掉重建），并在 .gitignore 里保留 notes/.obsidian/workspace.json（个人布局，不必跟踪）但保留核心插件配置。

方案 B：保持仓库根作为 Vault

• 优点：可以同时编辑主题代码与笔记。
• 缺点：Graph View 会扫描所有 .md，大量噪音。
• 必须做：在 Obsidian 设置 → 文件与链接 → 排除的文件 里把 themes/、node_modules/、public/ 全部排除。

.gitignore 建议（任一方案都加）

1
2
3
4
5

# Obsidian 个人配置（团队不共享）
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.obsidian/cache
.obsidian/plugins/*/data.json   # 视情况，含敏感的不要 push

但 .obsidian/core-plugins.json、community-plugins.json、appearance.json、hotkeys.json 建议跟踪，方便多机同步。

8. 插件/流程

Image Auto Upload

复制或拖入图片时自动上传至图床，与 PicGo 生态兼容。底层依赖 PicList（PicGo 的社区增强版）的命令行接口，需提前配置好图床后方可使用。功能定位与 Typora 的图片上传一致，是笔记软件的基础素质之一。

Obsidian CLI + Claudian

让 AI（Claude Code）直接读写 Vault 的桥梁，分两步启用：

1. 开启 CLI：设置 → 关于 → Obsidian CLI → 点击注册 → 重启 Obsidian。
2. 安装插件：从社区插件市场搜索并安装 Claudian。

   前提：本机已完成 Claude Code 的配置，Claudian 会自动识别并接入。
   

整体的体验下来，会很像在 VSCode 里面使用 GitHub Copilot。在输入框的 Yolo 功能,，相当于是自动化修改。
而且 Claude 里面其实也有 Plan 模式的，点击 Shift + Tab 就可以直接在对话框里切换 Plan 模式
然后和它共同商量每一步应该怎么做，最后再让它去执行.
同时使用斜杠，依旧可以调用一些 Claude 里面的命令.

这一部分参考教程：
https://www.bilibili.com/video/BV1xFwxzKE5D

配套 Claude Code Skills（kepano/obsidian-skills）

Obsidian CEO Steph Ango 在 kepano/obsidian-skills 发布了一组官方 Agent Skill，让 Claude Code 真正”懂” Obsidian 的文件格式与协议。安装方式：把每个 skill 文件夹放到 vault 的 .claude/skills/<name>/ 下，仅对该 vault 启动的 Claude Code 生效，不会污染全局或其它项目。

关于 obsidian-cli 的常见误解：这个 skill 不等于”装一个独立 CLI 工具”。obsidian:// URI 协议从 Obsidian 1.0 起就是默认内置功能，skill 的作用只是让 Claude 学会调用它来实现”打开某篇笔记、触发某个命令、跳转到指定 block”等操作。HTTP API 部分若想启用，需要额外安装社区插件 Local REST API（可选）。

与 Claudian 的关系：Claudian 是 Obsidian 端的插件，提供”在 Obsidian UI 里跟 Claude Code 对话”的入口；上面这些 skill 是 Claude Code 端的能力包，让 Claude 在读写 vault 文件时更专业。两者互补、不冲突。

下面我挨个介绍我比较推荐的这几个 skills。

Advanced Canvas 插件 + json-canvas

比如说我这一篇文章的顶部，有一个关于文件路径的介绍。上面有个思维导图，这个思维导图就是用 JSON Canvas 画出来的。
如果遇到一些比较难的文章或者是比较复杂的架构，可以让他帮你整理思维导图，方便理解。

Advanced Canvas 提供 30+ 增强功能：自定义流程图节点样式、Graph View 集成、幻灯片演示模式；支持 Portal（Canvas 套娃）与单节点嵌入 Markdown。

9. 参考资源

• 官方文档：https://help.obsidian.md/
• 官方论坛：https://forum.obsidian.md/
• 中文社区：少数派（sspai.com）的 Obsidian 系列
• YouTube：Linking Your Thinking、Nicole van der Hoeven、Bryan Jenks
• 方法论：
  • Niklas Luhmann《How to Take Smart Notes》（Zettelkasten 圣经）
  • Tiago Forte《Building a Second Brain》（PARA 提出者）

Introduction

As the MCP (Model Context Protocol) standard gains traction, more and more DCC applications are adding AI assistant integrations. In the Houdini ecosystem, two major open-source MCP projects currently exist:

1. capoomgit/houdini-mcp — an early-stage project with a clean, minimal structure
2. healkeiser/fxhoudinimcp — a newer, more feature-complete implementation

This post compares the two across architecture design, feature coverage, installation experience, and extensibility to help you pick the right one for your workflow.

Overview Comparison

Architecture Comparison

houdini-mcp (capoomgit)

1

Claude Desktop  ──(stdio)──>  MCP Bridge Script  ──(TCP :9876)──>  Houdini Plugin

• Communication: The MCP Bridge Script talks to Claude via stdin/stdout and to Houdini via a custom TCP socket.
• Server side: A hand-rolled HoudiniMCPServer listening on localhost:9876.
• Inspired by: Adapted from blender-mcp.

fxhoudinimcp (healkeiser)

1

Claude Desktop / Cursor / Claude Code  ──(stdio/streamable-http)──>  FXHoudini MCP Server  ──(HTTP :8100)──>  Houdini hwebserver

• Communication: The MCP Server talks to AI clients via stdio or streamable-http, and talks to Houdini via HTTP/JSON.
• Server side: Uses Houdini’s built-in hwebserver directly — no custom server process needed.
• Thread safety: Uses hdefereval.executeInMainThreadWithResult() to ensure all hou.* API calls run on the main thread.

Architecture Analysis

Verdict: fxhoudinimcp’s architecture is more robust — it reuses Houdini’s native components, reducing the surface area for custom-code bugs.

Feature Coverage Comparison

houdini-mcp Feature Set

Provides basic Houdini control:

• Create and modify nodes
• Execute Python / HScript code
• Basic scene operations
• OPUS integration: Connects to the OPUS procedural furniture and environment asset library via RapidAPI (exclusive feature)

fxhoudinimcp Feature Set (19 categories, 168 tools)

Highlights:

• One-click workflows: Instant Pyro, RBD, FLIP, and Vellum simulation setup
• Full USD/LOPs support: 18 tools covering the USD pipeline
• Copernicus (COPs) support: Image processing node operations
• Scene context analysis: Error detection and Cook chain tracing

Installation and Configuration Comparison

houdini-mcp Installation Steps

1. Install uv (Python package manager)
2. Manually create the Houdini scripts directory and copy files
3. Run uv add "mcp[cli]" in the directory
4. Manually create a Shelf Tool
5. (Optional) Create a Houdini Package JSON for auto-loading
6. Configure claude_desktop_config.json

1
2
3
4
5
6
7
8

{
  "mcpServers": {
    "houdini": {
      "command": "uv",
      "args": ["run", "python", "C:/path/to/houdini_mcp_server.py"]
    }
  }
}

fxhoudinimcp Installation Steps

1. pip install fxhoudinimcp (or uv pip install fxhoudinimcp)
2. Copy the Package JSON to the Houdini packages directory
3. Configure the MCP client

1
2
3
4
5
6
7
8
9
10
11
12

{
  "mcpServers": {
    "fxhoudini": {
      "command": "python",
      "args": ["-m", "fxhoudinimcp"],
      "env": {
        "HOUDINI_HOST": "localhost",
        "HOUDINI_PORT": "8100"
      }
    }
  }
}

Claude Code support (one-liner):

1

claude mcp add --scope user fxhoudini -- python -m fxhoudinimcp

Installation Experience Comparison

Client Support Comparison

Exclusive Features

Exclusive to houdini-mcp

• OPUS integration: Access to the OPUS procedural asset library (furniture and environment assets) via RapidAPI. Requires a RapidAPI account and an active API subscription.

Exclusive to fxhoudinimcp

• One-click simulation workflows: Pyro / RBD / FLIP / Vellum setup in a single call
• Deep USD/LOPs support: 18 dedicated tools
• Copernicus image processing: COPs node operations
• Scene error analysis: Automatic Cook error detection and reporting
• Environment variable configuration: HOUDINI_HOST, HOUDINI_PORT, FXHOUDINIMCP_AUTOSTART, and more
• Dual transport mode: stdio + streamable-http

Recommendations by Use Case

Choose houdini-mcp (capoomgit) if you:

• Only need basic AI control of Houdini
• Are already using a uv-based workflow
• Specifically need OPUS procedural asset library integration
• Have a simple project scope and want to get started quickly

Choose fxhoudinimcp (healkeiser) if you:

• Need comprehensive Houdini coverage (SOPs, LOPs, DOPs, TOPs, COPs, etc.)
• Work with USD/LOPs pipelines
• Want one-click simulation workflows (Pyro / FLIP / Vellum / RBD)
• Prefer a standardized installation via a PyPI package
• Use Claude Code CLI as your primary AI tool
• Need guaranteed thread safety
• Value active maintenance and long-term project evolution

Conclusion

Overall recommendation: For most users, fxhoudinimcp is the better choice — broader feature coverage, a more robust architecture, and a smoother installation process. If you specifically need the OPUS procedural asset library integration, houdini-mcp is worth a look as a complementary tool.

References

• capoomgit/houdini-mcp
• healkeiser/fxhoudinimcp
• blender-mcp — the project that inspired houdini-mcp

引言

随着 MCP（Model Context Protocol）协议的普及，越来越多的 DCC 软件开始接入 AI 助手。在 Houdini 生态中，目前有两个主要的 MCP 开源项目：

1. capoomgit/houdini-mcp — 早期项目，结构简洁
2. healkeiser/fxhoudinimcp — 后起之秀，功能全面

本文从架构设计、功能覆盖、安装体验、扩展性等维度进行对比，帮助选择适合自己工作流的项目。

总览对比

架构设计对比

houdini-mcp（capoomgit）

1

Claude Desktop  ──(stdio)──>  MCP Bridge Script  ──(TCP :9876)──>  Houdini Plugin

• 通信方式：MCP Bridge Script 通过 stdin/stdout 与 Claude 通信，通过自定义 TCP Socket 与 Houdini 通信。
• 服务端：自己实现的 HoudiniMCPServer，监听在 localhost:9876。
• 灵感来源：基于 blender-mcp 改写。

fxhoudinimcp（healkeiser）

1

Claude Desktop / Cursor / Claude Code  ──(stdio/streamable-http)──>  FXHoudini MCP Server  ──(HTTP :8100)──>  Houdini hwebserver

• 通信方式：MCP Server 通过 stdio 或 streamable-http 与 AI 客户端通信，通过 HTTP/JSON 与 Houdini 通信。
• 服务端：直接使用 Houdini 内置的 hwebserver，无需额外启动自定义服务器。
• 线程安全：使用 hdefereval.executeInMainThreadWithResult() 确保 hou.* API 调用在主线程执行。

架构差异分析

结论：fxhoudinimcp 的架构更稳健 — 复用 Houdini 原生组件，减少自定义代码带来的潜在问题。

功能覆盖对比

houdini-mcp 功能范围

提供基础的 Houdini 控制：

• 创建和修改节点
• 执行 Python / HScript 代码
• 场景基础操作
• OPUS 集成：通过 RapidAPI 接入 OPUS 的程序化家具和环境资产库（独有功能）

fxhoudinimcp 功能范围（19 个分类，168 个工具）

亮点：

• 一键工作流：Pyro、RBD、FLIP、Vellum 模拟一键搭建
• USD/LOPs 全面支持：18 个工具覆盖 USD 工作流
• Copernicus (COPs) 支持：图像处理节点操作
• 场景上下文分析：错误检测、Cook 链追踪

安装与配置对比

houdini-mcp 安装步骤

1. 安装 uv（Python 包管理工具）
2. 手动创建 Houdini 脚本目录并复制文件
3. 在目录中运行 uv add "mcp[cli]"
4. 手动创建 Shelf Tool
5. （可选）创建 Houdini Package JSON 实现自动加载
6. 配置 claude_desktop_config.json

1
2
3
4
5
6
7
8

{
  "mcpServers": {
    "houdini": {
      "command": "uv",
      "args": ["run", "python", "C:/path/to/houdini_mcp_server.py"]
    }
  }
}

fxhoudinimcp 安装步骤

1. pip install fxhoudinimcp（或 uv pip install fxhoudinimcp）
2. 复制 Package JSON 到 Houdini packages 目录
3. 配置 MCP 客户端

1
2
3
4
5
6
7
8
9
10
11
12

{
  "mcpServers": {
    "fxhoudini": {
      "command": "python",
      "args": ["-m", "fxhoudinimcp"],
      "env": {
        "HOUDINI_HOST": "localhost",
        "HOUDINI_PORT": "8100"
      }
    }
  }
}

Claude Code 支持（一行命令）：

1

claude mcp add --scope user fxhoudini -- python -m fxhoudinimcp

安装体验对比

客户端支持对比

独有功能

houdini-mcp 独有

• OPUS 集成：通过 RapidAPI 接入 OPUS 程序化资产库，可获取家具和环境资产。需要注册 RapidAPI 账号并订阅 API。

fxhoudinimcp 独有

• 一键模拟工作流：Pyro / RBD / FLIP / Vellum 一键搭建
• USD/LOPs 深度支持：18 个工具
• Copernicus 图像处理：COPs 节点操作
• 场景错误分析：自动检测和报告 Cook 错误
• 环境变量配置：HOUDINI_HOST、HOUDINI_PORT、FXHOUDINIMCP_AUTOSTART 等
• 双传输模式：stdio + streamable-http

适用场景建议

选择 houdini-mcp（capoomgit）的情况

• 只需要基础的 AI 控制 Houdini 功能
• 已经在使用 uv 工作流
• 需要 OPUS 程序化资产库的集成
• 项目结构简单，希望快速上手

选择 fxhoudinimcp（healkeiser）的情况

• 需要全面的 Houdini 功能覆盖（SOPs、LOPs、DOPs、TOPs、COPs 等）
• 需要 USD/LOPs 工作流支持
• 需要一键模拟工作流（Pyro / FLIP / Vellum / RBD）
• 希望使用标准化安装（PyPI 包）
• 使用 Claude Code CLI 作为主要 AI 工具
• 需要线程安全保障
• 重视项目的活跃维护和长期演进

结论

综合推荐：对于大多数用户，fxhoudinimcp 是更好的选择 — 更全面的功能覆盖、更稳健的架构、更便捷的安装流程。如果你特别需要 OPUS 程序化资产库的集成，可以额外关注 houdini-mcp。

参考链接

• capoomgit/houdini-mcp
• healkeiser/fxhoudinimcp
• blender-mcp — houdini-mcp 的灵感来源

Last updated: 2026-04-30

As AI Agent technology evolves at a rapid pace, new agent development frameworks keep appearing. This document surveys and compares six of the most widely adopted Agent frameworks available today, helping developers choose the right tool for their use case.

Table of Contents

• I. Framework Overview Comparison
• II. LangGraph
• III. CrewAI
• IV. LlamaIndex
• V. Dify
• VI. OpenAI Agents SDK
• VII. Google ADK
• VIII. Framework Selection Guide

I. Framework Overview Comparison

II. LangGraph

2.1 Introduction

LangGraph is a low-level orchestration framework developed by the LangChain team, specifically designed for building long-running, stateful AI Agents. It draws design inspiration from Google’s Pregel and Apache Beam.

Core positioning: rather than abstracting away prompts or architecture, LangGraph provides low-level infrastructure that gives developers fine-grained control over agent workflows. It is already used in production by companies such as Klarna, Replit, and Elastic.

2.2 Core Architecture

LangGraph models agent workflows as a Graph, built from three core components:

• State: A shared data structure, typically defined using TypedDict or a Pydantic Model
• Nodes: Functions that encode agent logic — they receive the current state and return an updated state
• Edges: Functions that determine the next node, supporting conditional branching or fixed transitions

2.3 Key Features

• Persistence: Saves the graph state as a checkpoint after each execution step; supports in-memory, Redis, and other backends
• Human-in-the-Loop: Uses interrupt() to pause execution and wait for human input before resuming
• Streaming: Supports multiple streaming modes including values, messages, and updates
• Subgraphs: Supports nested graphs where subgraphs have their own independent checkpoints and interrupt capabilities
• Time Travel: Can rewind to any historical checkpoint, with support for forking and replaying
• Visualization: After compilation, can generate Mermaid diagrams to visualize the workflow structure

2.4 Code Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

from typing import Literal
from langgraph.graph import StateGraph, MessagesState, START, END
from langchain.messages import SystemMessage, HumanMessage, ToolMessage

# Define tools
def multiply(a: int, b: int) -> int:
    """Multiply two numbers."""
    return a * b

def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

tools = [multiply, add]
tools_by_name = {tool.name: tool for tool in tools}

# Define nodes
def llm_call(state: MessagesState):
    """LLM decides whether to call a tool"""
    return {
        "messages": [
            llm_with_tools.invoke(
                [SystemMessage(content="You are a helpful arithmetic assistant.")]
                + state["messages"]
            )
        ]
    }

def tool_node(state: dict):
    """Execute tool calls"""
    result = []
    for tool_call in state["messages"][-1].tool_calls:
        tool = tools_by_name[tool_call["name"]]
        observation = tool.invoke(tool_call["args"])
        result.append(ToolMessage(content=str(observation), tool_call_id=tool_call["id"]))
    return {"messages": result}

# Define conditional edge routing
def should_continue(state: MessagesState) -> Literal["tool_node", END]:
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tool_node"
    return END

# Build and compile the graph
builder = StateGraph(MessagesState)
builder.add_node("llm_call", llm_call)
builder.add_node("tool_node", tool_node)
builder.add_edge(START, "llm_call")
builder.add_conditional_edges("llm_call", should_continue, ["tool_node", END])
builder.add_edge("tool_node", "llm_call")

agent = builder.compile()

# Run
result = agent.invoke({"messages": [HumanMessage(content="Add 3 and 4, then multiply by 5.")]})

2.5 Strengths and Limitations

Strengths: Fine-grained control, stateful execution, native human-in-the-loop, fault-tolerant recovery, time-travel debugging, framework-agnostic

Limitations: Steep learning curve, lots of boilerplate code, best experience requires the LangSmith ecosystem, fast-moving release cycle

III. CrewAI

3.1 Introduction

CrewAI is a Python framework for orchestrating multiple autonomous AI Agents, built entirely from scratch with no dependency on LangChain or any other framework. Its core idea is to simulate real team collaboration through role-playing.

3.2 Core Concepts

• Agent: Identity and behavior defined through role, goal, and backstory
• Task: A concrete unit of work; can specify the assigned agent, context dependencies, and output format
• Crew: A collection of collaborating agents, defining the execution process and memory configuration
• Tools: A rich set of built-in tools (search, file read/write, code execution, etc.) with MCP integration support
• Process: Either Sequential or Hierarchical (automatically creates a Manager Agent)

3.3 Key Features

• Role-playing design: Intuitive role definitions that closely mirror real team collaboration
• Collaborative workflows: Agents can delegate tasks to one another and pass context between them
• Four memory systems: Short-term memory, long-term memory, entity memory, and contextual memory
• Flows: Enterprise-grade event-driven workflow orchestration, supporting @start, @listen, and @router decorators
• Checkpoint & Fork: Supports saving, restoring, and branching execution state
• YAML-driven configuration: Agents and tasks can be defined via YAML files

3.4 Code Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

from crewai import Agent, Task, Crew, Process

# Define Agents
researcher = Agent(
    role='Senior AI Researcher',
    goal='Discover the latest development trends in the AI Agent space',
    backstory='You are an experienced researcher with a knack for spotting cutting-edge technology developments.',
    verbose=True,
    memory=True,
)

writer = Agent(
    role='Technical Report Writing Specialist',
    goal='Transform research findings into clear, well-structured reports',
    backstory='You are a technical writing expert who excels at turning complex information into readable reports.',
    verbose=True,
    memory=True,
)

# Define Tasks
research_task = Task(
    description='Conduct comprehensive research on {topic} and gather the latest development trends.',
    expected_output='A detailed list of research findings with 10 key points',
    agent=researcher,
)

writing_task = Task(
    description='Write a complete technical report based on the research findings.',
    expected_output='A complete report in Markdown format',
    agent=writer,
    context=[research_task],
    output_file='report.md',
)

# Assemble the Crew and run
crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff(inputs={'topic': 'multi-agent collaboration systems'})

3.5 Strengths and Limitations

Strengths: Fully standalone with no external dependencies, intuitive role-playing design, four memory systems, YAML-driven configuration, active community (100,000+ certified developers)

Limitations: Python only, high API overhead for multi-agent collaboration, complex to debug, enterprise features require a paid plan

IV. LlamaIndex

4.1 Introduction

LlamaIndex (formerly GPT Index) is an open-source framework that started out focused on RAG (Retrieval-Augmented Generation) and has since expanded into a document intelligence and OCR platform. Founded by Jerry Liu in 2022.

4.2 Core Concepts

• Workflow: An event-driven orchestration mechanism where steps are defined using the @step decorator
• Context: A global runtime context that coordinates data passing between steps and supports persistence
• Event-driven architecture: StartEvent → custom events → StopEvent, forming a directed graph
• AgentWorkflow: A high-level abstraction that automatically selects the appropriate agent type based on LLM capabilities

4.3 Agent Types

4.4 Key Features

• RAG + Agent integration: RAG is a first-class capability, not an add-on; supports 130+ data formats
• Multi-agent collaboration: Native support for multi-agent handoff mechanisms
• Context persistence: Workflow state can be serialized and restored, suitable for production environments
• LlamaParse: Enterprise-grade document parsing and OCR
• 300+ integration packages: Covers mainstream LLMs, vector databases, and data sources

4.5 Code Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.core.agent.workflow import FunctionAgent
from llama_index.llms.openai import OpenAI
import asyncio

# Build a RAG index
documents = SimpleDirectoryReader("data").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()

# Define tools
def multiply(a: float, b: float) -> float:
    """Multiply two numbers."""
    return a * b

async def search_documents(query: str) -> str:
    """Search documents for answers."""
    response = await query_engine.aquery(query)
    return str(response)

# Create the agent
agent = FunctionAgent(
    tools=[multiply, search_documents],
    llm=OpenAI(model="gpt-4o-mini"),
    system_prompt="You are a helpful assistant that can calculate and search documents.",
)

# Run
async def main():
    response = await agent.run("What did the author do in college? Also, what's 7 * 8?")
    print(response)

asyncio.run(main())

4.6 Strengths and Limitations

Strengths: Deep RAG + Agent integration, flexible event-driven architecture, 300+ ecosystem integrations, multi-agent support, LlamaParse enterprise-grade parsing

Limitations: Steep learning curve, relatively heavy framework, TypeScript version has incomplete feature coverage, fast release cycle with frequent breaking changes, enterprise features require a paid plan

V. Dify

5.1 Introduction

Dify (Do It For You) is an open-source LLM application development platform positioned as an agentic workflow builder. It combines Backend-as-a-Service with LLMOps, enabling both non-technical users and developers to rapidly build AI applications.

5.2 Core Features

• Visual workflow builder: Drag-and-drop canvas supporting parallel processing, conditional branching, and loop nodes
• Agent strategies: Supports Function Calling, ReAct, and custom strategy plugins
• RAG pipeline: A complete data source → processing → knowledge base → retrieval flow
• Model management: Seamless integration with hundreds of LLMs, with model switching and performance comparison
• Prompt IDE: An intuitive prompt authoring interface
• LLMOps: Monitor and analyze application logs and performance

5.3 Agent Strategies

5.4 How to Create an Agent

Dify uses a visual / no-code approach:

1. Create an “Agent” type application in Dify Studio
2. Select an LLM model
3. Set the Agent strategy (automatically detects Function Calling support)
4. Choose from 50+ built-in tools or add custom tools
5. Write a system prompt
6. Preview and debug, then publish with one click

5.5 Integration Capabilities

• API: Full RESTful API with SSE streaming support
• SDK: Node.js, PHP, and Java clients
• Plugin system: Six plugin categories — models, tools, agent strategies, extensions, data sources, and triggers
• MCP integration: Native support for the Model Context Protocol
• Deployment: Docker Compose, Kubernetes, Terraform, AWS CDK

5.6 Strengths and Limitations

Strengths: Low-code / no-code, ready out of the box (50+ built-in tools), rapid path from prototype to production, multi-model support, active community (800+ contributors)

Limitations: Limited customization flexibility (less than code-first frameworks), execution subject to step/time limits, license is not pure Apache 2.0, risk of platform lock-in, advanced reasoning modes are less mature than dedicated frameworks

VI. OpenAI Agents SDK

6.1 Introduction

OpenAI Agents SDK is a lightweight multi-agent framework officially released by OpenAI, evolved from the internal Swarm experimental project. Its core philosophy is minimalist design — building complex workflows from just a few concepts: Agent, Handoff, Guardrail, and Tool.

6.2 Core Concepts

• Agent: An LLM configured with instructions, tools, guardrails, and handoff capabilities
• Runner: The agent executor, providing run() (async), run_sync() (synchronous), and run_streamed() (streaming)
• Handoff: Task delegation between agents; the receiving agent inherits the full conversation history
• Guardrails: Safety rails in three categories — input guardrails, output guardrails, and tool guardrails
• Tools: Supports function tools, MCP tools, OpenAI hosted tools, and Agent as Tool

6.3 Key Features

• Minimalist design: Few core primitives, gentle learning curve
• Provider-agnostic: Supports 100+ LLMs via any-llm / LiteLLM
• Three-layer guardrails: Safety validation at the input → output → tool level
• Built-in Tracing: Visualize and debug agent execution flows
• Realtime Agents: Build voice agents (gpt-realtime-1.5)
• Sandbox Agents: Added in v0.14.0 — executes code in a containerized environment
• Structured output: Define output types via Pydantic Model using output_type

6.4 Code Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

import asyncio
from agents import Agent, Runner, function_tool

# Define a tool
@function_tool
def get_weather(city: str) -> str:
    """Get the weather for a specified city."""
    return f"The weather in {city} is sunny."

# Define specialist Agents
billing_agent = Agent(
    name="Billing Agent",
    instructions="You are a billing specialist.",
)

refund_agent = Agent(
    name="Refund Agent",
    instructions="You are a refund specialist.",
)

# Define a triage Agent
triage_agent = Agent(
    name="Triage Agent",
    instructions="Route the user's question to the correct specialist Agent: billing issues -> Billing Agent; refund issues -> Refund Agent.",
    handoffs=[billing_agent, refund_agent],
    tools=[get_weather],
)

# Run
async def main():
    result = await Runner.run(
        triage_agent,
        "I was charged twice for my subscription. Please help me resolve this.",
    )
    print(f"Final answer: {result.final_output}")
    print(f"Handled by Agent: {result.last_agent.name}")

asyncio.run(main())

6.5 Strengths and Limitations

Strengths: Officially maintained, minimalist design, provider-agnostic, three-layer guardrails, built-in tracing, voice agent support

Limitations: Still at 0.x — API may change, deep dependency on the OpenAI ecosystem, no parallel agent execution support, no built-in persistent memory system

VII. Google ADK

7.1 Introduction

Google ADK (Agent Development Kit) is an open-source, code-first agent development framework released by Google. Its design philosophy is to make AI agent development feel like traditional software development. It is optimized for Gemini and Google Cloud, while remaining model-agnostic and deployment-agnostic.

7.2 Core Concepts

• LlmAgent (alias Agent): The core building block — combines an LLM model, instructions, and tools
• SequentialAgent: Executes sub-agents one after another in order (pipeline style)
• ParallelAgent: Runs multiple sub-agents concurrently
• LoopAgent: Repeatedly executes sub-agents with support for exit conditions
• sub_agents: Nesting sub-agents to build hierarchical multi-agent architectures

7.3 Key Features

• Multi-agent orchestration: Sequential, parallel, loop-based, and LLM-driven dynamic routing
• Built-in tools: Google Search, Vertex AI Search, code executor, and more
• Google ecosystem integration: Native Gemini, Vertex AI Agent Engine, Cloud Run
• Flexible deployment: Local, Agent Engine (fully managed), Cloud Run, GKE, Docker
• Built-in evaluation: CLI tool adk eval for systematic agent performance assessment
• A2A protocol: Supports Agent-to-Agent remote communication
• Lifecycle callbacks: before/after_agent, before/after_model, and before/after_tool hooks

7.4 Code Example

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

import asyncio
from google.adk.agents import Agent, SequentialAgent
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from google.genai import types
from google.adk.tools import google_search

# Define a weather Agent
weather_agent = Agent(
    name="weather_assistant",
    model="gemini-2.5-flash",
    instruction="You are a weather query assistant. Use Google Search to find the latest weather information.",
    tools=[google_search],
)

# Define a translation Agent
translate_agent = Agent(
    name="translate_assistant",
    model="gemini-2.5-flash",
    instruction="You are a translation assistant. Translate content into Chinese.",
)

# Compose into a sequential workflow
pipeline = SequentialAgent(
    name="WeatherPipeline",
    sub_agents=[weather_agent, translate_agent],
)

# Run
session_service = InMemorySessionService()
runner = Runner(agent=pipeline, app_name="weather_app", session_service=session_service)

async def run_agent(query: str):
    session = session_service.create_session(
        app_name="weather_app", user_id="user_1", session_id="session_1"
    )
    content = types.Content(role='user', parts=[types.Part(text=query)])
    async for event in runner.run_async(
        user_id="user_1", session_id="session_1", new_message=content
    ):
        if event.is_final_response() and event.content and event.content.parts:
            print(f"Agent reply: {event.content.parts[0].text.strip()}")

asyncio.run(run_agent("What's the weather in Tokyo today?"))

7.5 Strengths and Limitations

Strengths: Code-first, powerful orchestration (sequential / parallel / loop), deep Google ecosystem integration, built-in evaluation, multi-language support (Python / Java / Go / TS), Apache 2.0 open source

Limitations: Best experience requires Gemini and Google Cloud, relatively new framework with an early-stage community ecosystem, frequent releases mean the API may change, access to Google services is restricted from mainland China

VIII. Framework Selection Guide

Choose by Use Case

Choose by Team Profile

Note: The framework information above is based on research conducted in April 2026. All frameworks iterate quickly — check the official documentation for the latest information before getting started.

更新时间：2026-04-30

随着 AI Agent 技术的快速发展，各类 Agent 开发框架层出不穷。本文档对当前主流的 6 个 Agent 框架进行调研和对比分析，帮助开发者选择合适的工具。

目录

• 一、框架概览对比
• 二、LangGraph
• 三、CrewAI
• 四、LlamaIndex
• 五、Dify
• 六、OpenAI Agents SDK
• 七、Google ADK
• 八、框架选型指南

一、框架概览对比

二、LangGraph

2.1 简介

LangGraph 是由 LangChain 团队开发的底层编排框架，专门用于构建长时间运行的、有状态的 AI Agent。设计灵感来自 Google 的 Pregel 和 Apache Beam。

核心定位：不抽象化提示词或架构，提供底层基础设施，让开发者精细控制 Agent 工作流。已被 Klarna、Replit、Elastic 等公司用于生产环境。

2.2 核心架构

LangGraph 将 Agent 工作流建模为图（Graph），由三个核心组件构成：

• State（状态）：共享数据结构，通常用 TypedDict 或 Pydantic Model 定义
• Nodes（节点）：编码 Agent 逻辑的函数，接收当前状态、返回更新后的状态
• Edges（边）：决定下一个节点的函数，支持条件分支或固定转换

2.3 关键特性

• 持久化（Persistence）：每个执行步骤将图状态保存为 checkpoint，支持内存、Redis 等后端
• 人机协作（Human-in-the-Loop）：通过 interrupt() 暂停执行，等待人工输入后恢复
• 流式输出（Streaming）：支持 values、messages、updates 等多种流式模式
• 子图（Subgraphs）：支持图嵌套，子图拥有独立的 checkpoint 和中断能力
• 时间旅行：可回溯到任意历史 checkpoint，支持 fork 和重放
• 可视化：编译后可生成 Mermaid 图形展示工作流结构

2.4 代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

from typing import Literal
from langgraph.graph import StateGraph, MessagesState, START, END
from langchain.messages import SystemMessage, HumanMessage, ToolMessage

# 定义工具
def multiply(a: int, b: int) -> int:
    """Multiply two numbers."""
    return a * b

def add(a: int, b: int) -> int:
    """Add two numbers."""
    return a + b

tools = [multiply, add]
tools_by_name = {tool.name: tool for tool in tools}

# 定义节点
def llm_call(state: MessagesState):
    """LLM 决定是否调用工具"""
    return {
        "messages": [
            llm_with_tools.invoke(
                [SystemMessage(content="You are a helpful arithmetic assistant.")]
                + state["messages"]
            )
        ]
    }

def tool_node(state: dict):
    """执行工具调用"""
    result = []
    for tool_call in state["messages"][-1].tool_calls:
        tool = tools_by_name[tool_call["name"]]
        observation = tool.invoke(tool_call["args"])
        result.append(ToolMessage(content=str(observation), tool_call_id=tool_call["id"]))
    return {"messages": result}

# 定义条件边路由
def should_continue(state: MessagesState) -> Literal["tool_node", END]:
    last_message = state["messages"][-1]
    if last_message.tool_calls:
        return "tool_node"
    return END

# 构建并编译图
builder = StateGraph(MessagesState)
builder.add_node("llm_call", llm_call)
builder.add_node("tool_node", tool_node)
builder.add_edge(START, "llm_call")
builder.add_conditional_edges("llm_call", should_continue, ["tool_node", END])
builder.add_edge("tool_node", "llm_call")

agent = builder.compile()

# 运行
result = agent.invoke({"messages": [HumanMessage(content="Add 3 and 4, then multiply by 5.")]})

2.5 优势与局限

优势： 精细化控制、有状态执行、原生人机协作、容错恢复、时间旅行调试、框架无关

局限： 学习曲线较陡、样板代码多、最佳体验需配合 LangSmith 生态、版本迭代快

三、CrewAI

3.1 简介

CrewAI 是一个用于编排多个自主 AI Agent 的 Python 框架，完全从零构建，不依赖 LangChain 或其他框架。核心理念是通过角色扮演模拟真实团队协作。

3.2 核心概念

• Agent（智能体）：通过 role（角色）、goal（目标）、backstory（背景故事）定义身份和行为
• Task（任务）：具体工作单元，可指定执行者、上下文依赖和输出格式
• Crew（团队）：一组协作 Agent 的集合，定义执行流程和记忆配置
• Tools（工具）：丰富的内置工具集（搜索、文件读写、代码执行等），支持 MCP 集成
• Process（流程）：Sequential（顺序）或 Hierarchical（层级，自动创建 Manager Agent）

3.3 关键特性

• 角色扮演设计：直观的角色定义方式，贴近真实团队协作
• 协作工作流：Agent 间可委派任务、传递上下文
• 四种记忆系统：短期记忆、长期记忆、实体记忆、上下文记忆
• Flows（流程编排）：企业级事件驱动工作流，支持 @start、@listen、@router 装饰器
• Checkpoint & Fork：支持执行状态的保存、恢复和分支
• YAML 配置驱动：Agent 和 Task 可通过 YAML 文件定义

3.4 代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

from crewai import Agent, Task, Crew, Process

# 定义 Agent
researcher = Agent(
    role='高级 AI 研究员',
    goal='发现 AI Agent 领域的最新发展趋势',
    backstory='你是一位经验丰富的研究员，擅长发现前沿技术的最新动态。',
    verbose=True,
    memory=True,
)

writer = Agent(
    role='技术报告撰写专家',
    goal='将研究发现转化为清晰、结构化的报告',
    backstory='你是一位技术写作专家，擅长将复杂信息转化为易读的报告。',
    verbose=True,
    memory=True,
)

# 定义 Task
research_task = Task(
    description='对 {topic} 进行全面调研，收集最新的发展趋势。',
    expected_output='包含 10 个要点的详细研究发现列表',
    agent=researcher,
)

writing_task = Task(
    description='根据研究发现撰写一份完整的技术报告。',
    expected_output='完整的 Markdown 格式报告',
    agent=writer,
    context=[research_task],
    output_file='report.md',
)

# 组建 Crew 并执行
crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
    verbose=True,
)

result = crew.kickoff(inputs={'topic': '多智能体协作系统'})

3.5 优势与局限

优势： 完全独立无依赖、角色扮演直观、四种记忆系统、YAML 配置驱动、活跃社区（10 万+ 认证开发者）

局限： 仅支持 Python、多 Agent 协作 API 开销大、调试复杂、企业功能需付费

四、LlamaIndex

4.1 简介

LlamaIndex（原名 GPT Index）是一个开源框架，最初专注于 RAG（检索增强生成），现已扩展为文档智能体和 OCR 平台。由 Jerry Liu 于 2022 年创立。

4.2 核心概念

• Workflow（工作流）：事件驱动的编排机制，通过 @step 装饰器定义步骤
• Context（上下文）：全局运行时上下文，协调步骤间数据传递，支持持久化
• 事件驱动架构：StartEvent → 自定义事件 → StopEvent，形成有向图
• AgentWorkflow：高层封装，自动根据 LLM 能力选择合适的 Agent 类型

4.3 Agent 类型

4.4 关键特性

• RAG + Agent 一体化：RAG 是核心能力而非补充，130+ 数据格式接入
• 多智能体协作：原生支持多 Agent 交接（handoff）机制
• Context 持久化：工作流状态可序列化恢复，适合生产环境
• LlamaParse：企业级文档解析和 OCR
• 300+ 集成包：覆盖主流 LLM、向量数据库、数据源

4.5 代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

from llama_index.core import VectorStoreIndex, SimpleDirectoryReader
from llama_index.core.agent.workflow import FunctionAgent
from llama_index.llms.openai import OpenAI
import asyncio

# 构建 RAG 索引
documents = SimpleDirectoryReader("data").load_data()
index = VectorStoreIndex.from_documents(documents)
query_engine = index.as_query_engine()

# 定义工具
def multiply(a: float, b: float) -> float:
    """Multiply two numbers."""
    return a * b

async def search_documents(query: str) -> str:
    """Search documents for answers."""
    response = await query_engine.aquery(query)
    return str(response)

# 创建智能体
agent = FunctionAgent(
    tools=[multiply, search_documents],
    llm=OpenAI(model="gpt-4o-mini"),
    system_prompt="You are a helpful assistant that can calculate and search documents.",
)

# 运行
async def main():
    response = await agent.run("What did the author do in college? Also, what's 7 * 8?")
    print(response)

asyncio.run(main())

4.6 优势与局限

优势： RAG + Agent 深度集成、事件驱动架构灵活、300+ 生态集成、多智能体支持、LlamaParse 企业级解析

局限： 学习曲线较陡、框架较重、TS 版本功能覆盖不全、版本迭代快有 breaking changes、企业功能需付费

五、Dify

5.1 简介

Dify（Do It For You）是一个开源的 LLM 应用开发平台，定位为智能体工作流构建器。将 Backend-as-a-Service 与 LLMOps 结合，让非技术用户和开发者都能快速构建 AI 应用。

5.2 核心功能

• 可视化工作流构建器：拖拽式画布，支持并行处理、条件分支、循环节点
• Agent 策略：支持 Function Calling、ReAct 和自定义策略插件
• RAG 管道：完整的数据源 → 处理 → 知识库 → 检索流程
• 模型管理：无缝集成数百种 LLM，支持模型切换和性能比较
• Prompt IDE：直观的提示词编写界面
• LLMOps：监控和分析应用日志和性能

5.3 Agent 策略

5.4 创建 Agent 的方式

Dify 采用可视化/无代码方式：

1. 在 Dify Studio 中创建 “Agent” 类型应用
2. 选择 LLM 模型
3. 设置 Agent 策略（自动检测 Function Calling 支持）
4. 从 50+ 内置工具中选择或添加自定义工具
5. 编写系统提示词
6. 调试预览后一键发布

5.5 集成能力

• API：完整的 RESTful API，支持 SSE 流式响应
• SDK：Node.js、PHP、Java 客户端
• 插件系统：模型、工具、Agent 策略、扩展、数据源、触发器六类插件
• MCP 集成：原生支持 Model Context Protocol
• 部署：Docker Compose、Kubernetes、Terraform、AWS CDK

5.6 优势与局限

优势： 低代码/无代码、开箱即用（50+ 内置工具）、快速原型到生产、多模型支持、活跃社区（800+ 贡献者）

局限： 自定义灵活性受限（不如代码框架）、执行有步骤/时间限制、许可证非纯 Apache 2.0、平台锁定风险、高级推理模式不如专用框架成熟

六、OpenAI Agents SDK

6.1 简介

OpenAI Agents SDK 是 OpenAI 官方推出的轻量级多智能体框架，从内部 Swarm 实验项目演化而来。核心理念是极简设计——只用 Agent / Handoff / Guardrail / Tool 几个概念构建复杂工作流。

6.2 核心概念

• Agent：配置了指令、工具、护栏和交接能力的 LLM
• Runner：Agent 执行器，提供 run()（异步）、run_sync()（同步）、run_streamed()（流式）
• Handoff：Agent 间的任务委托，被委托者继承完整对话历史
• Guardrails：安全护栏，分输入护栏、输出护栏、工具护栏三类
• Tools：支持函数工具、MCP 工具、OpenAI 托管工具、Agent as Tool

6.3 关键特性

• 极简设计：核心原语少，学习曲线平缓
• Provider 无关：通过 any-llm / LiteLLM 支持 100+ LLM
• 三层护栏：输入 → 输出 → 工具级别的安全校验
• 内置追踪（Tracing）：可视化调试 Agent 运行流程
• Realtime Agents：支持构建语音 Agent（gpt-realtime-1.5）
• Sandbox Agents：v0.14.0 新增，在容器环境中执行代码
• 结构化输出：通过 Pydantic Model 定义 output_type

6.4 代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

import asyncio
from agents import Agent, Runner, function_tool

# 定义工具
@function_tool
def get_weather(city: str) -> str:
    """获取指定城市的天气信息。"""
    return f"The weather in {city} is sunny."

# 定义专业 Agent
billing_agent = Agent(
    name="Billing Agent",
    instructions="你是账单问题专家。",
)

refund_agent = Agent(
    name="Refund Agent",
    instructions="你是退款问题专家。",
)

# 定义分流 Agent
triage_agent = Agent(
    name="Triage Agent",
    instructions="根据用户问题路由到正确的专业 Agent：账单 -> Billing Agent；退款 -> Refund Agent。",
    handoffs=[billing_agent, refund_agent],
    tools=[get_weather],
)

# 运行
async def main():
    result = await Runner.run(
        triage_agent,
        "我的订阅被扣了两次费用，请帮我处理。",
    )
    print(f"最终回答: {result.final_output}")
    print(f"处理 Agent: {result.last_agent.name}")

asyncio.run(main())

6.5 优势与局限

优势： 官方维护、极简设计、Provider 无关、三层护栏、内置追踪、语音 Agent 支持

局限： 仍处 0.x 阶段 API 可能变动、深度依赖 OpenAI 生态、不支持并行 Agent 执行、无内置持久化记忆系统

七、Google ADK

7.1 简介

Google ADK（Agent Development Kit） 是 Google 推出的开源、代码优先的 Agent 开发框架。设计理念是让 AI Agent 开发更像传统软件开发，针对 Gemini 和 Google Cloud 优化，但保持模型无关和部署无关。

7.2 核心概念

• LlmAgent（别名 Agent）：核心构建块，组合 LLM 模型 + 指令 + 工具
• SequentialAgent：按顺序依次执行子 Agent（管道式）
• ParallelAgent：并发执行多个子 Agent
• LoopAgent：重复执行子 Agent，支持退出条件
• sub_agents：通过嵌套构建层级式多 Agent 架构

7.3 关键特性

• 多 Agent 编排：顺序、并行、循环和 LLM 驱动的动态路由
• 内置工具：Google Search、Vertex AI Search、代码执行器等
• Google 生态集成：原生 Gemini、Vertex AI Agent Engine、Cloud Run
• 灵活部署：本地、Agent Engine（全托管）、Cloud Run、GKE、Docker
• 内置评估：CLI 工具 adk eval 系统化评估 Agent 性能
• A2A 协议：支持 Agent-to-Agent 远程通信
• 生命周期回调：before/after_agent、before/after_model、before/after_tool 钩子

7.4 代码示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

import asyncio
from google.adk.agents import Agent, SequentialAgent
from google.adk.runners import Runner
from google.adk.sessions import InMemorySessionService
from google.genai import types
from google.adk.tools import google_search

# 定义天气 Agent
weather_agent = Agent(
    name="weather_assistant",
    model="gemini-2.5-flash",
    instruction="你是一个天气查询助手。使用 Google 搜索查找最新天气信息。",
    tools=[google_search],
)

# 定义翻译 Agent
translate_agent = Agent(
    name="translate_assistant",
    model="gemini-2.5-flash",
    instruction="你是一个翻译助手，将内容翻译成中文。",
)

# 组合成顺序工作流
pipeline = SequentialAgent(
    name="WeatherPipeline",
    sub_agents=[weather_agent, translate_agent],
)

# 运行
session_service = InMemorySessionService()
runner = Runner(agent=pipeline, app_name="weather_app", session_service=session_service)

async def run_agent(query: str):
    session = session_service.create_session(
        app_name="weather_app", user_id="user_1", session_id="session_1"
    )
    content = types.Content(role='user', parts=[types.Part(text=query)])
    async for event in runner.run_async(
        user_id="user_1", session_id="session_1", new_message=content
    ):
        if event.is_final_response() and event.content and event.content.parts:
            print(f"Agent 回复: {event.content.parts[0].text.strip()}")

asyncio.run(run_agent("What's the weather in Tokyo today?"))

7.5 优势与局限

优势： 代码优先、强大编排能力（顺序/并行/循环）、Google 生态深度集成、内置评估、多语言支持（Python/Java/Go/TS）、Apache 2.0 开源

局限： 最佳体验需 Gemini 和 Google Cloud、框架较新社区生态初期、高频发布 API 可能变动、中国大陆访问 Google 服务受限

八、框架选型指南

按使用场景选择

按团队特点选择

注意：以上框架信息基于 2026 年 4 月的调研，各框架迭代较快，建议使用前查看官方文档获取最新信息。

↑ Playable right here (requires an internet connection to load)

Core gameplay: Patterned tiles are stacked across the board. Tap an accessible tile to send it into a 7-slot collection tray at the bottom. Match 3 identical patterns and they clear automatically. Clear every tile from the board to complete the level.

Key highlights of the project:

1. Mathematically guaranteed solvability: Level layouts are generated from a difficulty formula where total tile count = patternTypes × setsPerType × 3, which structurally ensures every pattern appears in multiples of three. A backtracking solver runs inside a Web Worker to forward-validate each layout — only layouts with a confirmed solution path are accepted. The solver also records the optimal move count, which serves as the star-rating baseline.
2. Procedural audio synthesis: Every interactive sound effect — taps, clears, combos, power-ups, warnings — is synthesized in real time via the Web Audio API. Zero audio files, zero network requests. Combo sounds are built on a C-major chord progression system, progressively brightening from triangle waves to sawtooth waves to give players a satisfying sense of escalating momentum. When BGM is playing, sound effects auto-duck by 6dB and smoothly recover over 200ms.
3. Data-driven architecture: Difficulty curves, power-up properties, and theme configurations are all declarative, editable config tables. A designer can tune difficulty curves and power-up parameters by editing JS config files directly — no touching game logic code. Six visual themes each have their own library of 32 emoji patterns, a background image, and a BGM track; themes rotate automatically every 3 levels.
4. PWA + offline support: Full Progressive Web App support is implemented — installable to a phone’s home screen and fully playable offline. The Service Worker uses a three-tier caching strategy: precached static assets, cache-first for CDN resources, and Stale-While-Revalidate for theme media. Dual-CDN failover provides automatic fallback.
5. Zero-cost online leaderboard: Built on Supabase’s free tier (PostgreSQL + REST API). A UUID is auto-generated on first visit and stored in localStorage — no account required. The database enforces row-level security (RLS); the client holds only the anon key. All input goes through dual regex validation plus XSS sanitization. Scores earned offline are queued locally and submitted automatically once connectivity is restored.

On the engineering side: tile occlusion uses spatial hashing (O(n) instead of O(n²)); clear particle effects use a pre-allocated object pool to avoid GC jitter; opacity calculations follow an exponential decay model based on the Weber–Fechner law; and the collection slots use a smart clustering insertion algorithm to help players quickly spot matching opportunities.

The entire project was completed within 24 hours. My own code spans 14 JS modules + 3 CSS files + 1 HTML file, covering 10,000 levels, 6 power-up types, and 6 themes. AI assistance generated the vast majority of the code, along with all audio synthesis parameters and BGM assets. My role focused on architecture design, requirements refinement, data structure design, and overall code quality.

↑ 上方可直接游玩（需要联网加载）

核心玩法：版面上堆叠着带有图案的瓦片，点击可用瓦片将其送入底部 7 格收集槽，凑齐 3 个相同图案自动消除，清空版面上所有瓦片即通关。

项目的主要亮点：

1. 数学可解性保证：关卡布局由难度公式推导生成，瓦片总数 = patternTypes × setsPerType × 3，从根本上保证每种图案数量均为 3 的倍数。同时，Web Worker 中运行回溯求解器对每个布局做正向验证，只有确认存在通关路径才会采用，并记录最优步数作为星级评分基准。
2. 程序化音效合成：所有交互音效（点击、消除、连击、道具、警告等）均通过 Web Audio API 实时合成，零音频文件、零网络请求。连击音效基于 C 大调和弦递进系统设计，从三角波到锯齿波逐渐变亮，给玩家”蓄力”的感知。BGM 播放时音效自动 Ducking（降 6dB），200ms 后平滑恢复。
3. 数据驱动架构：难度曲线、道具属性、主题配置均为可编辑的声明式配置表。策划可直接修改 JS 配置文件调整难度曲线和道具参数，无需触碰游戏逻辑代码。6 套视觉主题各有独立的 32 emoji 图案库、背景图和 BGM，每 3 关自动轮换。
4. PWA + 离线支持：实现了完整的 Progressive Web App 支持——可安装到手机主屏幕、支持完全离线游玩。Service Worker 采用三级缓存策略（静态资源预缓存、CDN 资源缓存优先、主题媒体 Stale-While-Revalidate），双 CDN 容灾自动回退。
5. 零成本在线排行榜：使用 Supabase 免费层（PostgreSQL + REST API），首次访问自动生成 UUID 存入 localStorage，无需注册。数据库启用行级安全（RLS），客户端仅持有 anon key，输入经双重正则校验 + XSS 清洗。离线成绩存入本地队列，联网后自动提交。

工程方面，瓦片覆盖关系使用空间哈希（O(n) 替代 O(n²)），消除特效使用预分配粒子对象池避免 GC 抖动，透明度计算遵循韦伯-费希纳定律的指数衰减模型，槽位采用智能聚类插入算法帮助玩家快速识别匹配机会。

整个项目在 24 小时内完成，自有代码 14 个 JS 模块 + 3 个 CSS + 1 个 HTML，覆盖 10,000 关、6 种道具、6 套主题。过程中 AI 辅助生成了绝大部分代码与全部音效参数、BGM 资产，我主要负责架构设计、需求梳理、数据结构设计及代码质量把控。

↑ Live site preview above (or visit talk-lingo.com directly)

The project covers three user-facing portals: a student portal (browse teachers, book lessons, credit wallet, review system), a teacher portal (personal profile, calendar scheduling, earnings dashboard, rating feedback), and an admin backend (data dashboard, teacher approval, review moderation, violation management, system parameter configuration) — totaling 28+ pages and 34+ components.

Key technical highlights:

1. Dynamic Pricing and Salary Algorithm: The platform’s core differentiating design. Lesson prices float dynamically based on a teacher’s booking rate — high-demand teachers see prices automatically rise, while prices pull back when demand is low, creating a positive incentive loop. Teacher salaries are similarly auto-adjusted based on demand and ratings, ensuring top teachers earn higher returns. All parameters are configurable in the admin backend, so strategy adjustments require no code changes.
2. Pairwise Comparison Review System: Students can evaluate two teachers they’ve taken lessons with in a head-to-head comparison. This produces more reliable quality signals than traditional independent scoring, helping the platform more accurately identify differences in teaching ability.
3. Multi-Dimensional Radar Chart Scoring: Teacher evaluations span multiple teaching dimensions, visualized as radar charts. This gives students an intuitive view of a teacher’s style and strengths, and provides teachers with clear direction for improvement.
4. Mainland China Network Optimization: Geo-aware routing via Cloudflare Workers automatically selects the optimal access path for mainland users, reducing latency and improving availability.
5. Full Internationalization Support: Complete bilingual coverage in Chinese and English, with 874 translation keys managing all user-facing copy through a translation system.

On the tech stack side, the frontend uses Next.js (App Router + Server Components) + TypeScript + Tailwind CSS + shadcn/ui. The backend runs on Supabase (PostgreSQL + Auth + Storage + Realtime), with Row-Level Security enforcing data access control. The app is deployed on Vercel, with Cloudflare handling CDN and DNS. The entire project was built from scratch to production launch, covering full-stack development end to end: database design (21 tables + 26 migration scripts), authentication and authorization, payment wallet, scheduled jobs, SEO optimization, and more.

↑ 上方为线上实站点预览（也可直接访问 talk-lingo.com）

项目包含三个用户端：学生端（浏览教师、预约课程、信用钱包、评价系统）、教师端（个人档案、日历排班、收入看板、评分反馈）和管理后台（数据看板、教师审批、评价审核、违规管理、系统参数配置），合计 28+ 个页面、34+ 个组件。

技术上的主要亮点：

1. 动态定价与薪资算法：平台核心差异化设计。课程价格根据教师预约率动态浮动——高需求教师价格自动上调，低需求时回调，形成正向激励循环。教师薪资同样根据需求与评价自动调节，确保优秀教师获得更高回报。所有参数可在管理后台配置，无需改代码即可调整策略。
2. 配对比较评价系统：学生可以对上过课的两位教师进行头对头对比评价，比传统独立评分能产生更可靠的质量信号，帮助平台更准确地识别教学水平差异。
3. 多维度雷达图评分：教师评价覆盖多个教学维度，通过雷达图可视化呈现，帮助学生直观了解教师的教学风格和强项，也为教师提供清晰的改进方向。
4. 中国大陆网络优化：通过 Cloudflare Workers 实现地理感知路由，针对大陆用户自动选择最优访问路径，降低延迟并提升可用性。
5. 完整的国际化支持：中英双语全覆盖，874 个翻译键，所有面向用户的文案均通过翻译系统管理。

技术栈方面，前端采用 Next.js（App Router + Server Components）+ TypeScript + Tailwind CSS + shadcn/ui，后端使用 Supabase（PostgreSQL + Auth + Storage + Realtime），通过 Row-Level Security 确保数据安全。部署在 Vercel 上，Cloudflare 提供 CDN 和 DNS 服务。整个项目从零到上线，涉及完整的全栈开发：数据库设计（21 张表 + 26 个迁移脚本）、认证授权、支付钱包、定时任务、SEO 优化等。

1. Project Overview

Hermes Agent is an open-source, self-learning AI agent framework developed by Nous Research.

Core philosophy: an agent should grow alongside its user — through a built-in learning loop, it creates skills from experience and continuously improves. The more you use it, the better it gets.

2. Core Features

2.1 Self-Learning Feedback Loop

• Automatically creates reusable Skill documents after completing complex tasks
• Skills self-iterate and improve through usage
• Built-in FTS5 full-text search + LLM summarization for cross-session memory recall
• Honcho-based user modeling to understand who you are

2.2 Multi-Platform Integration

A single Gateway process covers: Telegram, Discord, Slack, WhatsApp, Signal, Email. Supports voice memo transcription with continuous cross-platform conversations.

2.3 Terminal Interface

Full TUI: multi-line editing, slash command completion, conversation history, interrupt redirection, and streaming tool output.

2.4 Model-Agnostic

Supports Nous Portal, OpenRouter (200+ models), OpenAI, Anthropic, Hugging Face, Xiaomi MiMo, and more. Switch with hermes model — zero code changes required.

2.5 Scheduled Tasks

Built-in Cron scheduler. Define scheduled tasks in natural language (daily digests, backups, audits) and results are automatically delivered to any platform.

2.6 Parallel Sub-Agents

Spawn isolated sub-agents for parallel workflows. Supports Python scripts that call tools via RPC, compressing multi-step pipelines into single-turn operations with zero context overhead.

2.7 Flexible Deployment

6 terminal backends: Local, Docker, SSH, Daytona, Singularity, Modal. Serverless on-demand wake-up keeps idle costs near zero.

3. Quick Start

1
2
3
4
5
6
7
8
9
10

# Install (supports Linux / macOS / WSL2 / Termux)
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# Start
source ~/.bashrc
hermes              # Start a conversation
hermes model        # Select a model
hermes tools        # Configure tools
hermes gateway      # Start the message gateway
hermes setup        # Full setup wizard

4. Comparison with OpenClaw

OpenClaw (formerly Clawdbot/MoltBot) was released in January 2026 by Austrian engineer Peter Steinberger, and is the hottest open-source agent project of 2026 (200k+ Stars). Hermes has a clear lineage connection — it even ships a built-in OpenClaw migration tool (hermes claw migrate).

Summary: OpenClaw has a more mature ecosystem and a larger community — a better fit for users who need autonomous execution out of the box. Hermes is lighter and emphasizes a “the more you use it, the better it knows you” self-learning mechanism, making it ideal for users who want an agent that’s a long-term companion and continuously adapts to their habits. Migration paths exist between the two, so you can switch as needed.

5. Comparison with Other Tools

6. Assessment

Strengths: Unique self-learning mechanism, model-agnostic, broad platform coverage, flexible deployment, active community.

Limitations: The project is relatively new (only 2 months old), and API stability remains to be seen. Compared to mature tools like Claude Code, the ecosystem and plugin count still have room to grow.

Best Use Case: When you want a long-running personal agent that continuously learns your preferences — especially for cross-platform scenarios (Telegram, WeChat, etc.).

Sources: Hermes GitHub | Hermes Official Docs | OpenClaw GitHub | MIT Technology Review China

一、项目概览

Hermes Agent 是 Nous Research 开发的开源、自学习 AI Agent 框架。

核心理念：Agent 应该随用户一起成长——通过内置学习循环，从经验中创建技能、持续改进，越用越强。

二、核心特性

2.1 自学习闭环

• 完成复杂任务后自动创建可复用的 Skill 文档
• Skill 在使用过程中自我迭代优化
• 内置 FTS5 全文搜索 + LLM 摘要，支持跨会话记忆召回
• 基于 Honcho 的用户画像建模，理解你是谁

2.2 多平台接入

单一 Gateway 进程即可覆盖：Telegram、Discord、Slack、WhatsApp、Signal、Email。支持语音备忘录转录，跨平台对话连续。

2.3 终端交互

完整的 TUI 界面：多行编辑、斜杠命令补全、对话历史、中断重定向、流式工具输出。

2.4 模型无关

支持 Nous Portal、OpenRouter (200+ 模型)、OpenAI、Anthropic、Hugging Face、小米 MiMo 等，hermes model 一键切换，零代码改动。

2.5 定时任务

内置 Cron 调度器，用自然语言定义定时任务（日报、备份、审计），结果自动投递到任意平台。

2.6 并行子代理

可生成隔离子代理并行工作流，支持通过 RPC 调用工具的 Python 脚本，将多步骤流水线压缩为零上下文开销的单轮操作。

2.7 灵活部署

6 种终端后端：Local、Docker、SSH、Daytona、Singularity、Modal。支持 Serverless 按需唤醒，空闲时几乎零成本。

三、快速上手

1
2
3
4
5
6
7
8
9
10

# 安装（支持 Linux / macOS / WSL2 / Termux）
curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

# 启动
source ~/.bashrc
hermes              # 开始对话
hermes model        # 选择模型
hermes tools        # 配置工具
hermes gateway      # 启动消息网关
hermes setup        # 完整设置向导

四、与 OpenClaw 对比

OpenClaw（前身 Clawdbot/MoltBot）由奥地利工程师 Peter Steinberger 于 2026 年 1 月发布，是 2026 年最火的开源 Agent 项目（200k+ Stars）。Hermes 与之有明确的渊源——内置了 OpenClaw 迁移工具（hermes claw migrate）。

总结：OpenClaw 生态更成熟、社区更大，适合需要”开箱即用”自主执行的用户；Hermes 更轻量、更强调”越用越懂你”的自学习机制，适合希望 Agent 长期陪伴并持续适应自己习惯的用户。两者有迁移路径，可以按需切换。

五、与其他工具对比

六、评价

优势：自学习机制独特、模型无关、多平台覆盖、部署灵活、社区活跃。

局限：项目较新（仅 2 个月），API 稳定性待观察；与 Claude Code 等成熟工具相比，生态和插件数量尚有差距。

适用场景：需要一个长期运行、持续学习你偏好的个人 Agent，尤其是跨平台（Telegram/微信）使用场景。

参考来源：Hermes GitHub | Hermes 官方文档 | OpenClaw GitHub | MIT Technology Review China

1.1 What is SQL

SQL (Structured Query Language): the standard programming language for managing relational databases.

• RDBMS: Relational Database Management System
• Common databases (by type): MySQL, PostgreSQL, SQLite, Oracle, SQL Server
  1. SQLite: lightweight, embedded — great for mobile apps
  2. MySQL: open-source, widely used — great for web apps
  3. PostgreSQL: open-source, feature-rich — great for complex apps
  4. Oracle: enterprise-grade, fully featured — great for large-scale apps
  5. SQL Server: developed by Microsoft — great for Windows environments

1.2 Basic SQL Categories

Four schools of thought — these are the disciplines you use to communicate with a database. Master them and you’re a data wrangler; give up and you’re just a data janitor. 🐶

II. Basic Syntax

2.1 Basic Rules

• SQL statements end with a semicolon ; (some databases allow omitting it)
• Keywords are case-insensitive, but the convention is to write keywords in uppercase and table/column names in lowercase
• Strings and dates are wrapped in single quotes ' '
• Comments: -- single-line comment, /* multi-line comment */

2.2 Writing Style

1
2
3
4
5
6
7
8
9
10
11

-- Recommended writing style
SELECT
    id,
    name,
    email
FROM
    users/* Whether to use double quotes depends on the database type */
WHERE
    status = 'active'
ORDER BY
    create_time DESC;

2.3 Common Operators

Arithmetic Operators

Comparison Operators

Logical Operators

2.4 Common Commands (MySQL)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

-- Show all databases
SHOW DATABASES;

-- Show all tables in the current database
SHOW TABLES;

-- View table structure
DESC table_name;
-- or
DESCRIBE table_name;

-- View the CREATE TABLE statement
SHOW CREATE TABLE table_name;

-- Show full column info for a table
SHOW FULL COLUMNS FROM table_name;

2.5 ⚠️ Things to Watch Out For

1. Query syntax keywords have a specific ordering relationship.
2. 

III. DDL — Data Definition

2.1 Creating a Database

1
2

CREATE DATABASE database_name;
USE database_name;

2.2 Creating a Table

1
2
3
4
5

CREATE TABLE table_name (
    column1 data_type [constraint],
    column2 data_type [constraint],
    ...
);

Common data types:

• Integer: INT, BIGINT
• Decimal: DECIMAL(m,n), FLOAT, DOUBLE
• String: VARCHAR(n), CHAR(n), TEXT
• Date/Time: DATE, DATETIME, TIMESTAMP

2.3 Constraints

1
2
3
4
5
6
7

CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    email VARCHAR(100) UNIQUE,
    age INT DEFAULT 18,
    FOREIGN KEY (dept_id) REFERENCES departments(id)
);

Common constraints:

• PRIMARY KEY: primary key, uniquely identifies a row
• NOT NULL: value cannot be null
• UNIQUE: value must be unique
• DEFAULT: default value
• FOREIGN KEY: foreign key constraint
• AUTO_INCREMENT: auto-increment (MySQL)

2.4 Altering Table Structure

1
2
3
4
5
6
7
8
9
10
11

-- Add a column
ALTER TABLE table_name ADD column_name data_type;

-- Modify a column
ALTER TABLE table_name MODIFY column_name new_data_type;

-- Drop a column
ALTER TABLE table_name DROP COLUMN column_name;

-- Rename a table
ALTER TABLE table_name RENAME TO new_table_name;

2.5 Dropping a Table

1
2

DROP TABLE table_name;           -- Drop the table entirely
TRUNCATE TABLE table_name;       -- Clear all data (keep the structure)

III. DML — Data Manipulation

3.1 Inserting Data

1
2
3
4
5
6
7
8
9
10
11

-- Insert a single row
INSERT INTO table_name (col1, col2) VALUES (val1, val2);

-- Insert multiple rows
INSERT INTO table_name (col1, col2) VALUES
(val1, val2),
(val3, val4),
(val5, val6);

-- Import from another table
INSERT INTO table_name SELECT * FROM other_table WHERE condition;

3.2 Updating Data

1
2
3

UPDATE table_name
SET col1 = new_val1, col2 = new_val2
WHERE condition;

3.3 Deleting Data

1

DELETE FROM table_name WHERE condition;

IV. DQL — Data Query (Core)

4.1 Basic Queries

1
2
3
4
5
6
7
8
9
10
11