1. LLM & AI Agent 기본 이론

LLM (Large Language Model)이란?

LLM은 대규모 언어 모델의 약자로, 방대한 텍스트 데이터를 학습하여 자연어를 이해하고 생성하는 AI 모델입니다. 2017년 Google이 발표한 "Attention Is All You Need" 논문에서 제안된 Transformer 아키텍처를 기반으로 하며, GPT, Claude, Gemini, LLaMA 등이 대표적입니다.

AI Agent란?

AI Agent는 LLM + Tool + Skill + 자율적 추론/행동 루프를 결합한 시스템입니다. 단순 텍스트 생성을 넘어, 스스로 판단하고 외부 도구를 호출하여 실제 작업을 수행합니다.

AI Agent 생태계의 4가지 확장 개념

Tool (도구)

AI 시스템과 함께 사용하는 독립적인 외부 기능입니다. Agent가 직접 호출하여 LLM 자체로는 할 수 없는 작업을 수행합니다.

• Calculator: 수학 연산 수행
• Python REPL: Python 코드 실행
• API Request: 외부/내부 API 호출
• DB Query: 데이터베이스 검색

Agent는 사용자 요청을 분석한 후, 어떤 Tool을 사용할지 스스로 판단하여 호출합니다.

Skill (지식/지침)

AI 시스템이 특정 작업 시 자동으로 참조하는 지식 파일입니다. 코드 실행 없이 AI의 지식만 확장합니다.

• 예: "프론트엔드 디자인" Skill을 추가하면, UI 생성 요청 시 AI가 디자인 원칙을 자동 참조
• 설치가 간단하고, AI의 판단 기준과 전문 지식을 넓히는 역할

Plugin (확장 패키지)

명령어, 훅, 동작을 하나의 패키지로 묶은 확장입니다. AI 시스템의 행동 자체를 확장합니다.

• 예: 개발 워크플로 Plugin을 설치하면 TDD, 코드 리뷰, 체계적 디버깅 등 전문 워크플로 제공
• 마켓플레이스에서 설치하며, 여러 Skill + Tool을 번들로 제공

MCP (Model Context Protocol)

AI가 외부 서비스(DB, API, SaaS)에 직접 접근할 수 있게 해주는 프로토콜입니다.

• 예: Notion MCP를 설정하면 AI가 Notion 워크스페이스의 문서를 검색/업데이트
• 외부 서비스 연동에 API 키나 인증 정보가 필요할 수 있음

1. LLM & AI Agent Fundamentals

What is an LLM?

LLM stands for Large Language Model — an AI model trained on vast text data to understand and generate natural language. Based on the Transformer architecture from Google's "Attention Is All You Need" paper (2017). Examples: GPT, Claude, Gemini, LLaMA.

What is an AI Agent?

An AI Agent combines LLM + Tools + Skills + an autonomous reasoning/action loop. Beyond text generation, it autonomously decides and invokes external tools to perform real tasks.

4 Extension Concepts in the AI Agent Ecosystem

Tool

Independent external functions used alongside the AI system. The Agent invokes them to perform tasks the LLM can't do on its own.

• Calculator: Math operations
• Python REPL: Code execution
• API Request: External/internal API calls
• DB Query: Database search

The Agent analyzes the request and autonomously decides which Tool to use.

Skill (Knowledge/Instructions)

Knowledge files the AI automatically references during specific tasks. Extends the AI's knowledge without code execution.

• Example: Adding a "Frontend Design" Skill makes the AI auto-reference design principles when generating UI
• Easy to install; expands the AI's judgment criteria and expertise

Plugin (Extension Package)

Bundled packages of commands, hooks, and behaviors that extend the AI system's actions.

• Example: A dev workflow Plugin provides TDD, code review, systematic debugging workflows
• Installed from marketplaces; bundles multiple Skills + Tools together

MCP (Model Context Protocol)

A protocol enabling the AI to directly access external services (databases, APIs, SaaS).

• Example: Setting up Notion MCP lets the AI search and update Notion workspace documents
• May require API keys or authentication for external service integration

1. LLM 与 AI Agent 基础理论

什么是 LLM？

LLM 即大型语言模型，通过学习海量文本数据来理解和生成自然语言。基于 Google 2017 年发表的 "Attention Is All You Need" 论文提出的 Transformer 架构。代表模型：GPT、Claude、Gemini、LLaMA。

什么是 AI Agent？

AI Agent 结合了 LLM + 工具（Tool）+ 技能（Skill）+ 自主推理/行动循环。超越简单文本生成，能自主判断并调用外部工具执行实际任务。

AI Agent 生态系统的 4 个扩展概念

Tool（工具）

与 AI 系统配合使用的独立外部功能。Agent 调用它们执行 LLM 自身无法完成的任务。

• Calculator：数学运算
• Python REPL：代码执行
• API Request：调用外部/内部 API
• DB Query：数据库检索

Skill（知识/指令）

AI 在特定任务中自动参考的知识文件。无需代码执行即可扩展 AI 的知识。

• 示例：添加"前端设计"Skill 后，AI 在生成 UI 时自动参考设计原则
• 安装简单；扩展 AI 的判断标准和专业知识

Plugin（扩展包）

将命令、钩子、行为打包为一个扩展。扩展 AI 系统的行为本身。

• 示例：开发工作流 Plugin 提供 TDD、代码审查、系统化调试等工作流
• 从市场安装；捆绑多个 Skill + Tool

MCP（Model Context Protocol）

使 AI 能直接访问外部服务（数据库、API、SaaS）的协议。

• 示例：设置 Notion MCP 后，AI 可搜索和更新 Notion 工作区文档
• 可能需要 API 密钥或认证信息

1. LLM & AI Agent 基礎理論

LLM（大規模言語モデル）とは？

LLMは大規模言語モデルの略で、膨大なテキストデータを学習して自然言語を理解・生成するAIモデルです。2017年にGoogleが発表した "Attention Is All You Need" 論文で提案されたTransformerアーキテクチャを基盤としており、GPT、Claude、Gemini、LLaMAなどが代表例です。

AI Agentとは？

AI AgentはLLM + Tool + Skill + 自律的な推論・行動ループを組み合わせたシステムです。単純なテキスト生成を超え、自ら判断して外部ツールを呼び出し、実際のタスクを実行します。

AI Agentエコシステムの4つの拡張概念

Tool（ツール）

AIシステムと組み合わせて使う独立した外部機能です。AgentがLLM単体では実行できないタスクを行うために呼び出します。

• Calculator：数学演算の実行
• Python REPL：Pythonコードの実行
• API Request：外部・内部APIの呼び出し
• DB Query：データベース検索

Agentはユーザーのリクエストを分析した後、どのToolを使うかを自律的に判断して呼び出します。

Skill（知識・指示）

AIシステムが特定のタスク時に自動的に参照する知識ファイルです。コード実行なしにAIの知識だけを拡張します。

• 例：「フロントエンドデザイン」SkillをAIに追加すると、UI生成のリクエスト時にデザイン原則を自動参照
• 導入が簡単で、AIの判断基準と専門知識を広げる役割を担う

Plugin（拡張パッケージ）

コマンド、フック、動作をひとつのパッケージにまとめた拡張です。AIシステムの行動そのものを拡張します。

• 例：開発ワークフローPluginを導入すると、TDD・コードレビュー・体系的なデバッグなどの専門ワークフローを提供
• マーケットプレイスからインストールし、複数のSkill + Toolをバンドルとして提供

MCP（Model Context Protocol）

AIが外部サービス（DB、API、SaaS）に直接アクセスできるようにするプロトコルです。

• 例：Notion MCPを設定すると、AIがNotionワークスペースのドキュメントを検索・更新
• 外部サービス連携にAPIキーや認証情報が必要な場合あり

Token: 반도체의 Memory처럼, AI의 기본 단위

반도체에서 Memory(메모리)가 데이터를 저장하는 기본 단위라면, LLM에서 Token은 언어를 처리하는 기본 단위입니다. 한 단어가 1~3개의 토큰으로 분해되며, 모든 비용과 성능이 토큰 수로 결정됩니다.

• 비용: API 과금 단위 = 토큰 수 (입력 + 출력)
• 속도: 토큰이 많을수록 처리 시간 증가
• Context Window: 모델이 한 번에 처리할 수 있는 최대 토큰 수 (예: 128K, 200K, 1M)

Tokenomics: Token이 경제의 새로운 단위가 되다

NVIDIA CEO Jensen Huang은 GTC 2026에서 "AI Factory" 개념을 발표하며, 데이터센터를 전기와 데이터를 원료로 토큰(지능의 단위)을 생산하는 공장으로 재정의했습니다. 그가 제시한 공식은 다음과 같습니다:

이 공식은 에너지 효율(Tokens per Watt)이 곧 매출로 직결됨을 의미합니다. 1GW급 AI Factory 하나가 약 1,000억 달러의 건설 비용에 연간 1,500억 달러의 토큰 매출을 올릴 것으로 전망됩니다.

Huang은 "제1차 산업혁명은 전기를 생산했고, 제2차 산업혁명은 AI Factory를 통해 지능을 생산한다"고 선언했습니다. 토큰은 이제 석유나 전기처럼 측정·거래 가능한 경제적 산출물이 되었으며, 이를 Tokenomics(토큰 경제학)라 부릅니다.

KV-Cache: 토큰 생성의 핵심 메커니즘

토큰을 효율적으로 생산하려면 KV-Cache(Key-Value Cache)에 대한 이해가 필수입니다. CPU에 L1/L2 캐시가 있듯이, LLM에는 KV-Cache가 있습니다.

Transformer의 Attention 연산에서 새로운 토큰을 생성할 때마다, 이전에 처리한 모든 토큰의 Key와 Value 벡터를 다시 계산해야 합니다. KV-Cache는 이미 계산된 K, V를 GPU 메모리에 저장해두어 재계산을 생략함으로써 추론 속도를 획기적으로 높입니다.

왜 단편화가 발생했나? (PagedAttention 이전)

기존 방식에서는 KV-Cache를 연속 메모리(contiguous allocation)로 할당했습니다. 요청이 들어올 때 출력 길이를 미리 알 수 없으므로, 최대 가능한 컨텍스트 길이(예: 2048토큰)만큼 VRAM을 미리 예약합니다. 실제로는 100토큰만 생성하고 끝나더라도 나머지 1948토큰분 메모리는 잠긴 채 낭비됩니다.

요청마다 다른 시점에 종료되면서 중간중간 빈 구멍이 생기지만, 이 구멍들은 연속 공간이 아니라 새 요청에 할당할 수 없습니다. 이것이 OS의 외부 단편화(External Fragmentation)와 동일한 문제이며, GPU 메모리의 60~80%가 이렇게 낭비되었습니다.

PagedAttention: OS 가상 메모리에서 영감을 얻은 해법

OS가 외부 단편화를 페이징(Paging)으로 해결했듯, vLLM의 PagedAttention(Woosuk Kwon et al., 2023)은 KV-Cache를 고정 크기 블록(기본 16토큰)으로 나누어, 토큰이 생성될 때마다 필요한 만큼만 동적 할당합니다. 블록들이 물리적으로 연속일 필요가 없으므로 단편화가 사라집니다.

• 메모리 낭비 60~80% → 4% 미만으로 절감
• 동일 GPU에서 처리량(throughput) 2~4배 향상
• 공통 프롬프트 프리픽스의 KV-Cache를 여러 요청이 공유(Automatic Prefix Caching)

VRAM이 부족하면? — OS Page Fault와 같은 원리

사용자가 너무 많아 KV-Cache용 VRAM이 가득 차면, OS에서 Page Fault가 발생하는 것과 동일한 상황이 벌어집니다. vLLM은 이를 계층적 캐시(Hierarchical Cache)로 처리합니다:

1. GPU VRAM 가득 참 → 우선순위 낮은 요청의 KV-Cache를 CPU 메모리로 스왑(eviction)
2. CPU도 부족 → 디스크로 스왑
3. 그래도 부족 → 요청을 큐에 대기(waiting)시키거나 선점(preemption)

OS에서 Page Fault가 너무 잦으면 스래싱(Thrashing)이 발생하듯, KV-Cache 스왑이 빈번하면 추론 성능이 급격히 저하됩니다. 이것이 프로덕션 환경에서 GPU 수와 VRAM 크기가 중요한 근본적인 이유입니다.

후술할 Section 3의 vLLM 컴포넌트가 바로 이 PagedAttention 기반 추론 엔진을 Langflow에서 사용하는 방법입니다.

하지만 나날이 증가하는 사용자와 그들이 소비하는 막대한 토큰량에 비해 GPU 수가 한정적이라면, PagedAttention과 KV-Cache 최적화도 무색하게 추론 성능과 속도가 급격히 떨어집니다. 결국 충분한 GPU 인프라 확보가 안정적인 서비스의 전제 조건입니다.

However, if the number of GPUs is limited relative to ever-growing users and their massive token consumption, even PagedAttention and KV-Cache optimizations become insufficient — inference performance and speed degrade sharply. Ultimately, securing adequate GPU infrastructure is the prerequisite for stable service.

然而，如果相对于不断增长的用户及其海量 Token 消耗，GPU 数量有限，即使 PagedAttention 和 KV-Cache 优化也无济于事——推理性能和速度会急剧下降。最终，确保充足的 GPU 基础设施是稳定服务的前提。

しかし、増え続けるユーザーと膨大なToken消費量に対してGPU数が限られている場合、PagedAttentionやKV-Cache最適化も及ばず、推論性能と速度は急激に低下します。結局、十分なGPUインフラの確保が安定サービスの前提条件です。

Token: Like Memory in Semiconductors, the Basic Unit of AI

Just as Memory is the basic unit of data storage in semiconductors, Tokens are the basic unit of language processing in LLMs. A single word breaks down into 1-3 tokens, and all costs and performance are determined by token count.

• Cost: API billing unit = token count (input + output)
• Speed: More tokens = more processing time
• Context Window: Maximum tokens a model can process at once (e.g., 128K, 200K, 1M)

Tokenomics: Tokens as a New Economic Unit

At GTC 2026, NVIDIA CEO Jensen Huang introduced the "AI Factory" concept — redefining data centers as factories that convert electricity and data into tokens (units of intelligence). His formula:

Energy efficiency (Tokens per Watt) directly translates to revenue. A 1GW AI Factory costs ~$100B to build and is projected to generate $150B in annual token revenue.

Huang declared: "The first industrial revolution produced electricity; the second, with AI Factories, produces intelligence." Tokens have become a measurable, tradeable economic output like oil or electricity — a concept known as Tokenomics.

KV-Cache: The Core Mechanism of Token Generation

Efficient token production requires understanding KV-Cache (Key-Value Cache). Just as CPUs have L1/L2 cache, LLMs have KV-Cache.

Each time the Transformer generates a new token, it needs all previously computed Key and Value vectors. KV-Cache stores these in GPU memory, skipping recomputation and dramatically accelerating inference.

Why Did Fragmentation Occur? (Before PagedAttention)

Traditional systems allocated KV-Cache as contiguous memory. Since output length is unknown at request time, the system pre-reserves the maximum context length (e.g., 2048 tokens). If only 100 tokens are actually generated, the remaining 1948 tokens' worth of memory stays locked and wasted.

As requests finish at different times, gaps appear — but these gaps aren't contiguous, so new requests can't use them. This is exactly external fragmentation, just like in OS memory management, wasting 60-80% of GPU memory.

PagedAttention: Inspired by OS Virtual Memory

Just as OS solved external fragmentation with paging, vLLM's PagedAttention (Woosuk Kwon et al., 2023) splits KV-Cache into fixed-size blocks (default 16 tokens), dynamically allocated as tokens are generated. Blocks don't need to be physically contiguous, eliminating fragmentation.

• Memory waste reduced from 60-80% to under 4%
• 2-4x throughput improvement on the same GPU
• Automatic Prefix Caching: shared KV-Cache across requests with common prefixes

What if VRAM Runs Out? — Same Principle as OS Page Faults

When too many concurrent users exhaust KV-Cache VRAM, it's analogous to OS page faults. vLLM handles this with hierarchical caching:

1. GPU VRAM full → evict lower-priority requests' KV-Cache to CPU memory
2. CPU full → swap to disk
3. Still full → queue requests or preempt

Just as excessive page faults cause thrashing in an OS, frequent KV-Cache swaps degrade inference performance sharply. This is the fundamental reason GPU count and VRAM size matter in production deployments.

The vLLM components in Section 3 are how you use this PagedAttention-powered inference engine within Langflow.

Token：如同半导体中的 Memory，AI 的基本单位

正如Memory是半导体中数据存储的基本单位，Token是 LLM 处理语言的基本单位。一个单词分解为 1-3 个 Token，所有成本和性能都由 Token 数量决定。

• 成本：API 计费单位 = Token 数量（输入 + 输出）
• 速度：Token 越多，处理时间越长
• 上下文窗口：模型一次可处理的最大 Token 数（如 128K、200K、1M）

Tokenomics：Token 成为新的经济单位

NVIDIA CEO Jensen Huang 在 GTC 2026 上提出 "AI Factory" 概念——将数据中心重新定义为以电力和数据为原料、生产Token（智能单位）的工厂。其公式：Revenue = Tokens per Watt × Available Gigawatts。1GW 级 AI Factory 建设成本约 1000 亿美元，预计年产 Token 收入 1500 亿美元。Token 已成为如石油、电力一般可衡量、可交易的经济产出。

KV-Cache：Token 生成的核心机制

高效生产 Token 需要理解 KV-Cache。Transformer 每生成一个新 Token，都需要之前所有 Token 的 Key 和 Value 向量。KV-Cache 将其存储在 GPU 内存中，跳过重新计算。GPU 加载模型后，剩余 VRAM 即用于 KV-Cache——剩余越多，可并发处理的请求越多。70B 模型处理 8K 上下文时，每请求约 20GB。

为什么会产生碎片化？（PagedAttention 之前）

传统方式将 KV-Cache 分配为连续内存。由于无法预知输出长度，系统会预留最大上下文长度（如 2048 Token）。实际只生成 100 Token，其余内存仍被锁定浪费。请求在不同时间结束，产生不连续的空隙——这正是 OS 的外部碎片化，浪费了 60-80% GPU 内存。

PagedAttention：受 OS 虚拟内存启发的解决方案

如同 OS 用分页（Paging）解决碎片化，PagedAttention（Woosuk Kwon 等，2023）将 KV-Cache 拆分为固定大小块（默认 16 Token），按需动态分配，块无需物理连续。内存浪费从 60-80% 降至 4% 以下，吞吐量提升 2-4 倍。

VRAM 不足时？——与 OS Page Fault 相同的原理

并发用户过多耗尽 VRAM 时，vLLM 通过分层缓存处理：GPU VRAM 满 → 换出到 CPU 内存 → 换出到磁盘 → 排队等待。如同 OS 中频繁 Page Fault 导致抖动（Thrashing），KV-Cache 频繁换出会使推理性能急剧下降。这就是生产环境中 GPU 数量和 VRAM 大小至关重要的根本原因。

后文 Section 3 的 vLLM 组件正是在 Langflow 中使用这一 PagedAttention 推理引擎的方式。

Token：半導体のMemoryのように、AIの基本単位

半導体でMemoryがデータ保存の基本単位であるように、LLMではTokenが言語処理の基本単位です。1つの単語が1〜3個のTokenに分解され、すべてのコストとパフォーマンスがToken数で決まります。

• コスト：API課金単位 = Token数（入力 + 出力）
• 速度：Tokenが多いほど処理時間が増加
• Context Window：モデルが一度に処理できる最大Token数（例：128K、200K、1M）

Tokenomics：Tokenが経済の新たな単位に

NVIDIA CEO Jensen HuangはGTC 2026で「AI Factory」構想を発表し、データセンターを電力とデータからToken（知能の単位）を生産する工場として再定義しました。公式：Revenue = Tokens per Watt × Available Gigawatts。1GW級AI Factoryは建設費約1,000億ドル、年間Token売上1,500億ドルを見込みます。Tokenは石油や電気のような測定・取引可能な経済的産出物となりました。

KV-Cache：Token生成の核心メカニズム

効率的なToken生産にはKV-Cacheの理解が必須です。Transformerは新しいTokenを生成するたびに、それまでのすべてのTokenのKeyとValueベクトルが必要です。KV-Cacheはこれらをメモリに保存し再計算をスキップします。GPUにモデルを読み込むと、残りのVRAMがKV-Cacheに使われ、残りが多いほど同時処理できるリクエストが増えます。70Bモデルで8Kコンテキストの場合、リクエスト1件あたり約20GBが必要です。

なぜフラグメンテーションが発生したのか？（PagedAttention以前）

従来方式ではKV-Cacheを連続メモリで割り当てていました。出力長が事前に分からないため、最大コンテキスト長（例：2048トークン）分のVRAMを予約します。実際に100トークンしか生成しなくても残りは無駄になります。リクエストが異なるタイミングで終了し、不連続な隙間が生まれますが、連続空間ではないため新しいリクエストに使えません。これはOSの外部フラグメンテーションと同じ問題で、GPUメモリの60〜80%が浪費されていました。

PagedAttention：OS仮想メモリに着想を得た解決策

OSがページングで外部フラグメンテーションを解決したように、PagedAttention（Woosuk Kwonら、2023）はKV-Cacheを固定サイズブロック（デフォルト16トークン）に分割し、トークン生成時に必要な分だけ動的割当てします。ブロックが物理的に連続である必要がないため、フラグメンテーションが解消されます。メモリ浪費60〜80%→4%未満、スループット2〜4倍向上。

VRAMが不足したら？——OS Page Faultと同じ原理

同時ユーザーが多すぎてKV-Cache用VRAMが枯渇すると、OSのPage Faultと同様の状況が発生します。vLLMは階層キャッシュで対処します：GPU VRAM満杯→CPUメモリへスワップ→ディスクへスワップ→キュー待ち。OSで頻繁なPage Faultがスラッシングを引き起こすように、KV-Cacheの頻繁なスワップは推論性能を急激に低下させます。これが本番環境でGPU数とVRAMサイズが重要な根本的理由です。

後述のSection 3のvLLMコンポーネントが、このPagedAttentionベースの推論エンジンをLangflowで使用する方法です。

주요 모델 프로바이더 (2026.08 기준)

Major Model Providers (as of Aug 2026)

主要模型提供商（截至2026年8月）

主要モデルプロバイダー（2026年8月時点）

2. 왜 Langflow인가

Langflow는 비주얼 드래그 앤 드롭으로 LLM 애플리케이션과 AI Agent를 구축할 수 있는 오픈소스 플랫폼입니다.

2. Why Langflow?

Langflow is an open-source platform for building LLM applications and AI Agents through visual drag-and-drop.

2. 为何选择 Langflow？

Langflow 是通过可视化拖拽构建 LLM 应用和 AI Agent 的开源平台。

2. なぜ Langflow か

Langflow はビジュアルなドラッグ＆ドロップで LLM アプリケーションと AI Agent を構築できるオープンソースプラットフォームです。

다른 플랫폼과의 비교

AI 워크플로 빌더는 Langflow 외에도 여러 가지가 있습니다. 각 플랫폼의 특성을 비교하면 Langflow를 선택해야 하는 이유가 명확해집니다.

Comparison with Other Platforms

Several AI workflow builders exist beyond Langflow. Comparing their characteristics makes the case for Langflow clear.

与其他平台的比较

除 Langflow 外还有多种 AI 工作流构建工具。比较各平台特点可以明确选择 Langflow 的理由。

他プラットフォームとの比較

Langflow 以外にも AI ワークフロービルダーは複数あります。各プラットフォームの特性を比較すると、Langflow を選ぶ理由が明確になります。

Langflow의 차별점

LangChain & LangGraph 네이티브 호환

Langflow는 LangChain 위에 구축된 플랫폼입니다. LangChain의 컴포넌트(Retriever, Chain, Memory 등)를 네이티브로 사용할 수 있고, LangGraph의 멀티 에이전트 오케스트레이션도 Flow 안에서 구현할 수 있습니다. 다른 플랫폼들은 LangChain을 부분적으로만 지원하지만, Langflow는 LangChain 생태계의 비주얼 IDE 역할을 합니다.

Python 코드 완전 제어

Dify나 Flowise는 코드를 샌드박스 내에서만 실행하지만, Langflow의 Custom Component는 제한 없는 Python 환경에서 동작합니다. subprocess로 패키지를 설치하고, 사내 라이브러리를 import하며, 컴포넌트를 한번 작성해 여러 Flow에서 재사용할 수 있습니다.

폐쇄망(Air-gapped) 보안

Langflow를 자체 호스팅하면 프롬프트, 문서, 벡터 임베딩 등 모든 데이터가 사내 인프라를 벗어나지 않습니다. vLLM으로 호스팅한 로컬 모델만 사용하면 외부 API 호출이 전혀 발생하지 않아, GDPR이나 사내 보안 규정을 완벽히 준수할 수 있습니다. 이는 Make.com 같은 클라우드 전용 도구로는 불가능한 구성입니다.

What Sets Langflow Apart

Native LangChain & LangGraph Compatibility

Langflow is built on top of LangChain. It natively supports LangChain components (Retriever, Chain, Memory, etc.) and can implement LangGraph multi-agent orchestration within Flows. Other platforms only partially support LangChain; Langflow serves as the LangChain ecosystem's visual IDE.

Full Python Code Control

Dify and Flowise restrict code to sandboxed environments. Langflow's Custom Components run in an unrestricted Python environment — install packages via subprocess, import internal libraries, write once and reuse across multiple Flows.

Air-gapped Security

Self-hosted Langflow ensures all data — prompts, documents, vector embeddings — never leaves your infrastructure. Using only locally-hosted models via vLLM, zero external API calls are made, fully complying with GDPR and internal security policies. This is impossible with cloud-only tools like Make.com.

Langflow 的差异化优势

原生兼容 LangChain & LangGraph

Langflow 基于 LangChain 构建，原生支持 LangChain 组件，可在 Flow 中实现 LangGraph 多 Agent 编排。其他平台仅部分支持 LangChain，而 Langflow 是 LangChain 生态的可视化 IDE。

Python 代码完全控制

Dify 和 Flowise 将代码限制在沙盒中。Langflow 的 Custom Component 在无限制的 Python 环境中运行——可安装包、导入内部库、一次编写多处复用。

离线（Air-gapped）安全

自托管 Langflow 确保所有数据（Prompt、文档、向量嵌入）不离开内部基础设施。仅使用 vLLM 本地模型时零外部 API 调用，完全符合 GDPR 及内部安全策略。

Langflow の差別化ポイント

LangChain & LangGraph ネイティブ互換

Langflow は LangChain 上に構築されたプラットフォームです。LangChain コンポーネントをネイティブに使用でき、LangGraph のマルチエージェントオーケストレーションも Flow 内で実装できます。他のプラットフォームは LangChain を部分的にしかサポートしませんが、Langflow は LangChain エコシステムのビジュアル IDEです。

Python コード完全制御

Dify や Flowise はコードをサンドボックスに制限しますが、Langflow の Custom Component は制限のない Python 環境で動作します。パッケージインストール、社内ライブラリ import、一度書いて複数 Flow で再利用が可能です。

エアギャップ（閉域網）セキュリティ

セルフホストの Langflow はすべてのデータ（プロンプト、ドキュメント、ベクトル埋め込み）が社内インフラから出ません。vLLM ローカルモデルのみ使用すれば外部 API 呼び出しはゼロで、GDPR や社内セキュリティポリシーに完全準拠できます。

3. Component 소개

Langflow에서 모든 것은 컴포넌트로 시작합니다. 컴포넌트는 Flow를 구성하는 블록이며, 좌측 사이드바에서 캔버스로 드래그하여 사용합니다. 각 컴포넌트의 왼쪽은 입력 포트, 오른쪽은 출력 포트이며, 호환되는 포트끼리 선으로 연결합니다.

주요 컴포넌트 카테고리

3. Components Overview

Everything in Langflow starts with components. Components are the building blocks of Flows — drag them from the sidebar onto the canvas. Each component has input ports on the left and output ports on the right, connected by wires between compatible ports.

Key Component Categories

3. 组件介绍

Langflow 中一切从组件开始。组件是构成 Flow 的积木——从侧边栏拖到画布上使用。每个组件左侧是输入端口，右侧是输出端口，通过连线连接兼容的端口。

主要组件类别

3. コンポーネント紹介

Langflow ではすべてがコンポーネントから始まります。コンポーネントは Flow を構成するブロックで、左サイドバーからキャンバスにドラッグして使用します。各コンポーネントの左側が入力ポート、右側が出力ポートで、互換性のあるポート同士を線で繋ぎます。

主要コンポーネントカテゴリ

메인 페이지: Knowledge & Files

Langflow 메인 페이지에서는 Flow 외에도 Knowledge와 Files를 관리할 수 있습니다.

Main Page: Knowledge & Files

Beyond Flows, the Langflow main page lets you manage Knowledge and Files.

主页：Knowledge 和 Files

除了 Flow，Langflow 主页还可以管理 Knowledge 和 Files。

メインページ：Knowledge & Files

Flow 以外にも、Langflow メインページでは Knowledge と Files を管理できます。

Knowledge (문서 컬렉션)

메인 페이지의 Knowledge 탭에서 RAG에 사용할 문서 컬렉션을 관리합니다. 별도 VectorDB 없이도 기본값인 로컬 Chroma에 임베딩을 적재하여 간단한 RAG를 구축할 수 있어, 초기 실험용으로 적합합니다.

Langflow 1.10부터는 DB Providers 설정으로 백엔드를 바꿀 수 있습니다 — Chroma(로컬, 기본값) / Chroma Cloud / OpenSearch.1.10

Knowledge (Document Collections)

Manage document collections for RAG in the Knowledge tab on the main page. Without a separate VectorDB, embeddings land in local Chroma (the default) — ideal for initial experiments.

Since Langflow 1.10, the DB Providers setting lets you switch backends: Chroma (local, default) / Chroma Cloud / OpenSearch.1.10

Knowledge（文档集合）

在主页的 Knowledge 标签中管理用于 RAG 的文档集合。无需单独的 VectorDB，嵌入将存入默认的本地 Chroma——适合初期实验。

自 Langflow 1.10 起，可通过 DB Providers 设置切换后端：Chroma（本地，默认）/ Chroma Cloud / OpenSearch。1.10

Knowledge（ドキュメントコレクション）

メインページの Knowledge タブで RAG 用のドキュメントコレクションを管理します。別途 VectorDB なしでもデフォルトのローカル Chroma にエンベディングを格納でき、初期の実験に最適です。

Langflow 1.10 からは DB Providers 設定でバックエンドを変更できます — Chroma（ローカル、デフォルト）/ Chroma Cloud / OpenSearch。1.10

Knowledge 생성 과정

1. + Add Knowledge로 이름을 지정하고, Embedding Model과 Source(File 또는 Folder)를 추가합니다.
2. Source 추가 후 Next Step에서 약 5개 Chunk를 미리보기할 수 있어, Chunk size와 delimiter를 간단히 테스트할 수 있습니다.
3. Embedding 수행 시 선택한 DB Provider에 적재됩니다. 기본값은 Langflow 자체 로컬 Chroma입니다.

Creating Knowledge

1. Click + Add Knowledge, set a name, select Embedding Model, and add Source (File or Folder).
2. After adding sources, the Next Step shows a preview of ~5 chunks to test chunk size and delimiter settings.
3. Embeddings are written to the selected DB Provider — Langflow's built-in local Chroma by default.

创建 Knowledge

1. 点击 + Add Knowledge，设定名称，选择 Embedding Model，添加 Source（File 或 Folder）。
2. 添加后下一步可预览约 5 个 Chunk，测试 Chunk size 和 delimiter 设置。
3. Embedding 结果存入所选的 DB Provider，默认为 Langflow 自带的本地 Chroma。

Knowledge の作成

1. + Add Knowledge で名前を指定し、Embedding Model と Source（File または Folder）を追加します。
2. Source 追加後の Next Step で約5つの Chunk をプレビューでき、Chunk size と delimiter を簡単にテストできます。
3. エンベディングは選択した DB Provider に格納されます。デフォルトは Langflow 自体のローカル Chroma です。

Flow 내에서 Knowledge Base 컴포넌트를 사용하면 생성한 Knowledge를 언제든지 참조할 수 있습니다.

Use the Knowledge Base component in your Flow to reference created Knowledge at any time.

在 Flow 中使用 Knowledge Base 组件可随时引用已创建的 Knowledge。

Flow 内で Knowledge Base コンポーネントを使うと、作成した Knowledge をいつでも参照できます。

Files (파일 관리)

메인 페이지의 My Files 탭에서 Langflow 환경의 파일을 중앙 관리합니다.

Files (File Management)

Centrally manage files in the My Files tab on the main page.

Files（文件管理）

在主页的 My Files 标签中集中管理文件。

Files（ファイル管理）

メインページの My Files タブで Langflow 環境のファイルを一元管理します。

• PDF, CSV, TXT, JSON 등을 업로드하여 여러 Flow에서 공유 가능
• Flow에서 File 컴포넌트로 업로드한 파일을 직접 참조하여 데이터를 읽어올 수 있습니다.
• Read File 컴포넌트(위 두 번째 이미지)를 사용하면 My Files에 업로드된 파일을 Flow 안에서 직접 읽어올 수 있습니다. 파일 경로를 지정하거나 목록에서 선택하여 텍스트 데이터를 추출합니다.
• 파일을 한 곳에서 관리하므로, 동일한 파일을 여러 Flow에 중복 업로드할 필요가 없습니다.

• Upload PDF, CSV, TXT, JSON, etc. and share across multiple Flows
• Use the File component in Flows to directly reference uploaded files and read data.
• The Read File component (second image above) lets you read files uploaded to My Files directly within a Flow. Specify the file path or select from the list to extract text data.
• Centralized file management eliminates the need to upload the same file to multiple Flows.

• 上传 PDF、CSV、TXT、JSON 等，可在多个 Flow 中共享
• 在 Flow 中使用 File 组件直接引用已上传的文件来读取数据。
• Read File 组件（上方第二张图片）可在 Flow 中直接读取已上传到 My Files 的文件。指定文件路径或从列表中选择来提取文本数据。
• 集中管理文件，无需在多个 Flow 中重复上传相同文件。

• PDF、CSV、TXT、JSON などをアップロードし、複数の Flow で共有可能
• Flow の File コンポーネントでアップロードしたファイルを直接参照してデータを読み込めます。
• Read File コンポーネント（上の2番目の画像）を使うと、My Files にアップロードしたファイルを Flow 内で直接読み取れます。ファイルパスを指定するか、リストから選択してテキストデータを抽出します。
• ファイルを一箇所で管理するため、同じファイルを複数の Flow に重複アップロードする必要がありません。

Air-gapped 환경에서 vLLM 활용

Langflow는 기본적으로 Anthropic, Google Generative AI, IBM Watson X, Ollama, OpenAI 등 유료/외부 Model Provider를 지원합니다. 하지만 폐쇄망(Air-gapped) 환경에서는 외부 API에 접근할 수 없으므로, 사내 GPU 서버에서 vLLM으로 호스팅한 모델을 사용해야 합니다.

Langflow는 vLLM 및 vLLM Embeddings 컴포넌트를 기본 제공하여, OpenAI-compatible API 형태로 서빙되는 vLLM 서버에 바로 연결할 수 있습니다. 이를 통해 폐쇄망(Air-gapped)에서도 LLM 기반 텍스트 생성과 임베딩을 활용한 RAG 파이프라인을 구성할 수 있습니다.

Using vLLM in Air-gapped Environments

Langflow natively supports external Model Providers such as Anthropic, Google Generative AI, IBM Watson X, Ollama, and OpenAI. However, in air-gapped environments where external APIs are inaccessible, you need to use models hosted via vLLM on internal GPU servers.

Langflow provides built-in vLLM and vLLM Embeddings components that connect directly to vLLM servers serving OpenAI-compatible APIs. This enables LLM-based text generation and embedding-powered RAG pipelines even in air-gapped networks.

在离线环境中使用 vLLM

Langflow 默认支持 Anthropic、Google Generative AI、IBM Watson X、Ollama、OpenAI 等外部 Model Provider。但在离线（Air-gapped）环境中无法访问外部 API，需要使用内部 GPU 服务器上通过 vLLM 托管的模型。

Langflow 内置 vLLM 和 vLLM Embeddings 组件，可直接连接以 OpenAI-compatible API 形式提供服务的 vLLM 服务器。这使得在离线网络中也能构建基于 LLM 的文本生成和嵌入驱动的 RAG 管道。

エアギャップ環境での vLLM 活用

Langflow はデフォルトで Anthropic、Google Generative AI、IBM Watson X、Ollama、OpenAI などの外部 Model Provider をサポートしています。しかし、エアギャップ（閉域網）環境では外部 API にアクセスできないため、社内 GPU サーバーで vLLM を使用してホスティングしたモデルを利用する必要があります。

Langflow は vLLM および vLLM Embeddings コンポーネントを標準搭載しており、OpenAI-compatible API として提供される vLLM サーバーに直接接続できます。これにより、閉域網でも LLM ベースのテキスト生成やエンベディングを活用した RAG パイプラインを構築できます。

Provider 방식 vs vLLM 방식 비교

vLLM은 UC Berkeley의 Woosuk Kwon 등이 개발한 고성능 LLM 추론 엔진입니다 (논문 | 공식 문서). PagedAttention 기법으로 GPU 메모리를 효율적으로 관리하며, OpenAI-compatible API를 제공하여 다양한 오픈소스 모델을 쉽게 서빙할 수 있습니다.

Langflow에는 범용 Embedding Model과 Language Model 컴포넌트도 있습니다. 이들은 Provider 드롭다운에서 Anthropic, OpenAI 등 외부 서비스를 선택하는 방식입니다. 반면 vLLM 컴포넌트는 사내 GPU에서 직접 호스팅한 모델의 API Base URL을 지정하여 연결하므로, 폐쇄망(Air-gapped)에서 외부 Provider 없이 사용할 수 있습니다.

Provider vs vLLM Comparison

vLLM is a high-performance LLM inference engine developed by Woosuk Kwon et al. at UC Berkeley (paper | docs). It uses PagedAttention for efficient GPU memory management and provides an OpenAI-compatible API for serving various open-source models.

Langflow also provides generic Embedding Model and Language Model components, which select external services like Anthropic or OpenAI from a Provider dropdown. In contrast, vLLM components connect by specifying the API Base URL of models self-hosted on internal GPUs — usable in air-gapped networks without external providers.

Provider 方式 vs vLLM 方式对比

vLLM 是由加州大学伯克利分校的 Woosuk Kwon 等人开发的高性能 LLM 推理引擎（论文 | 官方文档）。它使用 PagedAttention 技术高效管理 GPU 内存，并提供 OpenAI-compatible API 来服务各种开源模型。

Langflow 还提供通用的 Embedding Model 和 Language Model 组件，通过 Provider 下拉菜单选择 Anthropic、OpenAI 等外部服务。而 vLLM 组件通过指定内部 GPU 服务器上自托管模型的 API Base URL 连接——可在无外部 Provider 的离线网络中使用。

Provider 方式 vs vLLM 方式の比較

vLLM は UC Berkeley の Woosuk Kwon らが開発した高性能 LLM 推論エンジンです（論文 | 公式ドキュメント）。PagedAttention で GPU メモリを効率的に管理し、OpenAI-compatible API で様々なオープンソースモデルを簡単にサービングできます。

Langflow には汎用の Embedding Model と Language Model コンポーネントもあります。これらは Provider ドロップダウンから Anthropic や OpenAI などの外部サービスを選択する方式です。一方、vLLM コンポーネントは社内 GPU でセルフホストしたモデルの API Base URL を指定して接続するため、外部 Provider なしの閉域網で使用できます。

컴포넌트 연결 시 Port Type(색상)의 중요성

Langflow에서 컴포넌트를 연결할 때, 각 포트에는 데이터 타입에 따른 고유한 색상이 부여됩니다. 같은 색상(같은 타입)의 포트끼리만 연결할 수 있으며, 호환되지 않는 타입의 포트를 연결하려 하면 선이 연결되지 않습니다. 이 색상 시스템을 이해하면 Flow를 더 빠르고 정확하게 구성할 수 있습니다.

Port Type (Color) Matters When Connecting Components

When connecting components in Langflow, each port is assigned a unique color based on its data type. Only ports of the same color (same type) can be connected — incompatible types won't link. Understanding this color system helps you build Flows faster and more accurately.

连接组件时 Port Type（颜色）的重要性

在 Langflow 中连接组件时，每个端口根据数据类型分配唯一的颜色。只有相同颜色（相同类型）的端口才能连接——不兼容的类型无法链接。理解此颜色系统有助于更快、更准确地构建 Flow。

コンポーネント接続時の Port Type（色）の重要性

Langflow でコンポーネントを接続する際、各ポートにはデータ型に応じた固有の色が割り当てられます。同じ色（同じ型）のポート同士のみ接続可能で、互換性のない型のポートは繋がりません。この色システムを理解すると Flow をより速く正確に構成できます。

Data Operations: 하나의 컴포넌트로 Text · JSON · Table 처리1.11

Langflow 1.11부터 기존의 Text Operations, JSON Operations, Table Operations 세 컴포넌트가 Data Operations 하나로 통합되었습니다. 컴포넌트 안의 Input Type 셀렉터로 처리할 데이터 종류를 고르면, 그에 맞는 연산 목록이 나타납니다.

덕분에 "이 데이터는 Text인가 Table인가"에 따라 컴포넌트를 갈아끼울 필요가 없어졌고, 파이프라인 중간에 데이터 형태가 바뀌어도 같은 컴포넌트로 이어갈 수 있습니다.

Data Operations: One Component for Text, JSON, and Table1.11

As of Langflow 1.11, the former Text Operations, JSON Operations, and Table Operations components are consolidated into a single Data Operations component. Pick your data kind with the Input Type selector inside the component, and the matching operation list appears.

You no longer swap components based on whether the data is Text or Table, and when the shape changes mid-pipeline you can keep going with the same component.

Data Operations：一个组件处理 Text · JSON · Table1.11

从 Langflow 1.11 起，原先的 Text Operations、JSON Operations、Table Operations 三个组件已合并为单一的 Data Operations 组件。通过组件内的 Input Type 选择器指定数据类型，即可显示对应的操作列表。

不再需要根据数据是 Text 还是 Table 来更换组件，管道中途数据形态改变时也可用同一组件继续处理。

Data Operations：1つのコンポーネントで Text · JSON · Table を処理1.11

Langflow 1.11 から、従来の Text Operations、JSON Operations、Table Operations の3コンポーネントが Data Operations 1つに統合されました。コンポーネント内の Input Type セレクタで扱うデータ種別を選ぶと、それに応じた演算リストが表示されます。

データが Text か Table かでコンポーネントを差し替える必要がなくなり、パイプライン途中でデータ形態が変わっても同じコンポーネントで続けられます。

Input Type = Table: 여러 Table 입력 한 번에 연결

Table 모드에서는 여러 Table 타입 컴포넌트의 출력을 하나의 입력에 동시에 연결할 수 있습니다. 예를 들어 Read File로 읽어온 CSV 테이블 여러 개나 SpreadSheet 컴포넌트의 출력을 한꺼번에 넣어 병합(Merge)하거나 비교 연산을 수행합니다.

Input Type = Table: Connect Multiple Table Inputs at Once

In Table mode you can connect multiple Table-type outputs to a single input simultaneously. For example, feed in several CSV tables loaded via Read File, or SpreadSheet component outputs, all at once to Merge or compare them in one step.

Input Type = Table：一次连接多个 Table 输入

在 Table 模式下，可将多个 Table 类型组件的输出同时连接到一个输入。例如把通过 Read File 读取的多个 CSV 表或 SpreadSheet 组件的输出一并输入，进行合并（Merge）或比较运算。

Input Type = Table：複数の Table 入力を一括接続

Table モードでは複数の Table 型コンポーネントの出力を1つの入力に同時接続できます。例えば Read File で読み込んだ複数の CSV テーブルや SpreadSheet コンポーネントの出力をまとめて入力し、マージ（Merge）や比較演算を実行します。

4. Custom Component 만들기

기본 컴포넌트로 부족할 때, Python으로 Custom Component를 직접 작성합니다. 가장 기초부터 시작해 봅시다.

4. Building Custom Components

When built-in components aren't enough, write Custom Components in Python. Let's start from the basics.

4. 创建自定义组件

当内置组件不足时，使用 Python 编写自定义组件。从最基础开始。

4. カスタムコンポーネントの作成

組み込みコンポーネントで不足する場合は、Python でカスタムコンポーネントを直接作成します。まず基礎から始めましょう。

Step 1. 가장 기본 (Input 1개 + Output 1개)

입력 텍스트를 그대로 출력하는 최소 컴포넌트입니다.

Step 1. The Simplest (1 Input + 1 Output)

A minimal component that passes input text through.

Step 1. 最基本（1个输入 + 1个输出）

将输入文本原样输出的最简组件。

Step 1. 最も基本的な構成（Input 1つ + Output 1つ）

入力テキストをそのまま出力する最小構成のコンポーネントです。

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class HelloComponent(Component):
    display_name = "안녕 컴포넌트"
    description = "입력을 그대로 출력하는 기본 컴포넌트"

    inputs = [
        StrInput(name="input_text", display_name="입력 텍스트", required=True),
    ]

    outputs = [
        Output(display_name="결과", name="result", method="run"),
    ]

    def run(self) -> Data:
        self.status = self.input_text
        return Data(data={"text": self.input_text})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class HelloComponent(Component):
    display_name = "Hello Component"
    description = "A basic component that passes input through"

    inputs = [
        StrInput(name="input_text", display_name="Input Text", required=True),
    ]

    outputs = [
        Output(display_name="Result", name="result", method="run"),
    ]

    def run(self) -> Data:
        self.status = self.input_text
        return Data(data={"text": self.input_text})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class HelloComponent(Component):
    display_name = "你好组件"
    description = "将输入原样输出的基本组件"

    inputs = [
        StrInput(name="input_text", display_name="输入文本", required=True),
    ]

    outputs = [
        Output(display_name="结果", name="result", method="run"),
    ]

    def run(self) -> Data:
        self.status = self.input_text
        return Data(data={"text": self.input_text})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class HelloComponent(Component):
    display_name = "ハローコンポーネント"
    description = "入力をそのまま出力する基本コンポーネント"

    inputs = [
        StrInput(name="input_text", display_name="入力テキスト", required=True),
    ]

    outputs = [
        Output(display_name="結果", name="result", method="run"),
    ]

    def run(self) -> Data:
        self.status = self.input_text
        return Data(data={"text": self.input_text})

StrInput & Output 인자 설명

Custom Component의 inputs와 outputs에서 사용하는 주요 인자(argument)를 정리합니다.

StrInput 주요 인자

StrInput & Output Arguments

Key arguments used in Custom Component inputs and outputs.

StrInput Arguments

StrInput 和 Output 参数说明

自定义组件 inputs 和 outputs 中使用的主要参数。

StrInput 参数

StrInput と Output の引数説明

カスタムコンポーネントの inputs と outputs で使用する主要な引数をまとめます。

StrInput の主要引数

Output 주요 인자

Output Arguments

Output 参数

Output の主要引数

Step 2. 처리 로직 추가 (Input 2개)

두 번째 Input을 추가하여 텍스트를 가공합니다.

Step 2. Adding Logic (2 Inputs)

Add a second input with processing logic.

Step 2. 添加处理逻辑（2个输入）

添加第二个输入并加入处理逻辑。

Step 2. 処理ロジックの追加（Input 2つ）

2つ目の Input を追加してテキストを加工します。

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextProcessor(Component):
    display_name = "텍스트 처리기"
    description = "접두사를 붙여 텍스트를 처리합니다"

    inputs = [
        StrInput(name="input_text", display_name="입력 텍스트", required=True),
        StrInput(name="prefix", display_name="접두사", value="[처리됨]"),
    ]

    outputs = [
        Output(display_name="처리 결과", name="processed", method="process_text"),
    ]

    def process_text(self) -> Data:
        result = f"{self.prefix} {self.input_text}"
        self.status = result
        return Data(data={"text": result})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextProcessor(Component):
    display_name = "Text Processor"
    description = "Processes text by adding a prefix"

    inputs = [
        StrInput(name="input_text", display_name="Input Text", required=True),
        StrInput(name="prefix", display_name="Prefix", value="[Processed]"),
    ]

    outputs = [
        Output(display_name="Result", name="processed", method="process_text"),
    ]

    def process_text(self) -> Data:
        result = f"{self.prefix} {self.input_text}"
        self.status = result
        return Data(data={"text": result})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextProcessor(Component):
    display_name = "文本处理器"
    description = "通过添加前缀处理文本"

    inputs = [
        StrInput(name="input_text", display_name="输入文本", required=True),
        StrInput(name="prefix", display_name="前缀", value="[已处理]"),
    ]

    outputs = [
        Output(display_name="处理结果", name="processed", method="process_text"),
    ]

    def process_text(self) -> Data:
        result = f"{self.prefix} {self.input_text}"
        self.status = result
        return Data(data={"text": result})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextProcessor(Component):
    display_name = "テキスト処理器"
    description = "接頭辞を付けてテキストを処理します"

    inputs = [
        StrInput(name="input_text", display_name="入力テキスト", required=True),
        StrInput(name="prefix", display_name="接頭辞", value="[処理済み]"),
    ]

    outputs = [
        Output(display_name="処理結果", name="processed", method="process_text"),
    ]

    def process_text(self) -> Data:
        result = f"{self.prefix} {self.input_text}"
        self.status = result
        return Data(data={"text": result})

Step 3. 여러 Output 추가

하나의 컴포넌트에서 여러 Output을 제공할 수 있습니다.

Step 3. Multiple Outputs

A single component can provide multiple outputs.

Step 3. 多个输出

一个组件可以提供多个输出。

Step 3. 複数の Output の追加

1つのコンポーネントから複数の Output を提供できます。

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextAnalyzer(Component):
    display_name = "텍스트 분석기"
    description = "텍스트를 분석하여 여러 결과를 출력합니다"

    inputs = [
        StrInput(name="input_text", display_name="입력 텍스트", required=True),
    ]

    outputs = [
        Output(display_name="원본", name="original", method="get_original"),
        Output(display_name="대문자", name="upper", method="get_upper"),
        Output(display_name="통계", name="stats", method="get_stats"),
    ]

    def get_original(self) -> Data:
        return Data(data={"text": self.input_text})

    def get_upper(self) -> Data:
        return Data(data={"text": self.input_text.upper()})

    def get_stats(self) -> Data:
        stats = f"글자수: {len(self.input_text)}, 단어수: {len(self.input_text.split())}"
        self.status = stats
        return Data(data={"text": stats})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextAnalyzer(Component):
    display_name = "Text Analyzer"
    description = "Analyzes text and outputs multiple results"

    inputs = [
        StrInput(name="input_text", display_name="Input Text", required=True),
    ]

    outputs = [
        Output(display_name="Original", name="original", method="get_original"),
        Output(display_name="Uppercase", name="upper", method="get_upper"),
        Output(display_name="Statistics", name="stats", method="get_stats"),
    ]

    def get_original(self) -> Data:
        return Data(data={"text": self.input_text})

    def get_upper(self) -> Data:
        return Data(data={"text": self.input_text.upper()})

    def get_stats(self) -> Data:
        stats = f"Characters: {len(self.input_text)}, Words: {len(self.input_text.split())}"
        self.status = stats
        return Data(data={"text": stats})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextAnalyzer(Component):
    display_name = "文本分析器"
    description = "分析文本并输出多个结果"

    inputs = [
        StrInput(name="input_text", display_name="输入文本", required=True),
    ]

    outputs = [
        Output(display_name="原文", name="original", method="get_original"),
        Output(display_name="大写", name="upper", method="get_upper"),
        Output(display_name="统计", name="stats", method="get_stats"),
    ]

    def get_original(self) -> Data:
        return Data(data={"text": self.input_text})

    def get_upper(self) -> Data:
        return Data(data={"text": self.input_text.upper()})

    def get_stats(self) -> Data:
        stats = f"字符数: {len(self.input_text)}, 词数: {len(self.input_text.split())}"
        self.status = stats
        return Data(data={"text": stats})

from langflow.custom import Component
from langflow.io import StrInput, Output
from langflow.schema import Data


class TextAnalyzer(Component):
    display_name = "テキスト分析器"
    description = "テキストを分析して複数の結果を出力します"

    inputs = [
        StrInput(name="input_text", display_name="入力テキスト", required=True),
    ]

    outputs = [
        Output(display_name="原文", name="original", method="get_original"),
        Output(display_name="大文字", name="upper", method="get_upper"),
        Output(display_name="統計", name="stats", method="get_stats"),
    ]

    def get_original(self) -> Data:
        return Data(data={"text": self.input_text})

    def get_upper(self) -> Data:
        return Data(data={"text": self.input_text.upper()})

    def get_stats(self) -> Data:
        stats = f"文字数: {len(self.input_text)}, 単語数: {len(self.input_text.split())}"
        self.status = stats
        return Data(data={"text": stats})

Step 4. Tool Mode로 Agent에 연결하기

Custom Component를 Tool Mode로 전환하면 Agent가 자율적으로 호출할 수 있는 도구가 됩니다. 코드에서 tool_mode=True를 Input에 설정하면 해당 입력이 Tool로 노출됩니다.

Step 4. Connecting to Agent via Tool Mode

Converting to Tool Mode turns your component into a tool the Agent can invoke. Set tool_mode=True on Inputs to expose them as tool parameters.

Step 4. 通过工具模式连接 Agent

转换为工具模式后，组件成为 Agent 可自主调用的工具。在 Input 中设置 tool_mode=True 来将其暴露为工具参数。

Step 4. Tool Mode で Agent に接続する

カスタムコンポーネントを Tool Mode に切り替えると、Agent が自律的に呼び出せるツールになります。Input に tool_mode=True を設定すると、その入力がツールパラメーターとして公開されます。

Message vs Data 이해하기

Custom Component를 만들 때, 출력 타입으로 Message와 Data 중 하나를 선택합니다. 이 둘의 차이를 이해하는 것이 중요합니다.

Understanding Message vs Data

When building Custom Components, you choose between Message and Data as output types. Understanding the difference is important.

理解 Message 与 Data

创建自定义组件时，需要在 Message 和 Data 之间选择输出类型。理解两者的区别很重要。

Message と Data の理解

カスタムコンポーネントを作成する際、出力タイプとして Message と Data のどちらかを選択します。この違いを理解することが重要です。

5. Custom Component로 pip install 하기

환경에 필요한 패키지가 없을 때, subprocess로 직접 설치합니다.

5. pip install via Custom Component

Install packages directly via subprocess when needed.

5. 通过自定义组件 pip install

需要时通过 subprocess 直接安装包。

5. カスタムコンポーネントで pip install する

環境に必要なパッケージがない場合、subprocess で直接インストールします。

설치된 패키지 목록 확인 (pip list)

Checking Installed Packages (pip list)

查看已安装的包列表 (pip list)

インストール済みパッケージ一覧確認 (pip list)

프로그래밍적 확인 (importlib)

Programmatic Check (importlib)

编程方式查看 (importlib)

プログラム的な確認 (importlib)

6. 간단한 Flow 사용법

Flow는 컴포넌트를 연결하여 구성한 AI 파이프라인입니다.

6. Basic Flow Usage

A Flow is an AI pipeline built by connecting components.

6. 简单 Flow 使用方法

Flow 是通过连接组件构建的 AI 管道。

6. 簡単な Flow の使い方

Flow はコンポーネントを繋いで構成した AI パイプラインです。

Settings: Global Variables

Flow에서 반복 사용하는 값(API Key, 서버 URL 등)을 Settings > Global Variables에서 한 곳에 등록하고, 모든 컴포넌트에서 참조할 수 있습니다.

Settings: Global Variables

Register frequently used values (API keys, server URLs, etc.) in Settings > Global Variables and reference them across all components.

Settings：Global Variables

在 Settings > Global Variables 中注册常用值（API 密钥、服务器 URL 等），在所有组件中引用。

Settings：Global Variables

繰り返し使用する値（APIキー、サーバーURLなど）を Settings > Global Variables で一元登録し、全コンポーネントから参照できます。

Run Flow: 다른 Flow를 서브프로세스로 실행

Run Flow 컴포넌트는 현재 Flow 안에서 다른 Langflow Flow를 서브프로세스로 실행할 수 있는 기능입니다. 이를 통해 복잡한 파이프라인을 여러 개의 독립적인 Flow로 분리하고, 필요할 때 호출하는 모듈화된 설계가 가능합니다.

주요 활용 사례

• Flow 체이닝: 여러 Flow를 순차적으로 연결하여 복잡한 워크플로우를 구성
• 조건부 실행: 특정 조건에 따라 다른 Flow를 선택적으로 실행
• Agent 도구 통합: Run Flow를 Agent의 Tool로 연결하여, Agent가 상황에 맞는 Flow를 자율적으로 호출

Run Flow: Execute Another Flow as a Subprocess

The Run Flow component lets you run another Langflow Flow as a subprocess within your current Flow. This enables a modular design — split complex pipelines into independent Flows and invoke them as needed.

Key Use Cases

• Flow chaining: Connect multiple Flows sequentially for complex workflows
• Conditional execution: Selectively run different Flows based on conditions
• Agent tool integration: Attach Run Flow as an Agent Tool, letting the Agent autonomously invoke the right Flow

Run Flow：将其他 Flow 作为子进程执行

Run Flow 组件可以在当前 Flow 中将另一个 Langflow Flow 作为子进程运行。这实现了模块化设计——将复杂管道拆分为独立 Flow，按需调用。

主要使用场景

• Flow 链式调用：顺序连接多个 Flow 构建复杂工作流
• 条件执行：根据条件选择性运行不同 Flow
• Agent 工具集成：将 Run Flow 作为 Agent 工具，让 Agent 自主调用合适的 Flow

Run Flow：別の Flow をサブプロセスとして実行

Run Flow コンポーネントは、現在の Flow 内で別の Langflow Flow をサブプロセスとして実行できます。これにより複雑なパイプラインを独立した Flow に分割し、必要に応じて呼び出すモジュール化設計が可能です。

主な活用例

• Flow チェイニング：複数の Flow を順次接続して複雑なワークフローを構成
• 条件付き実行：特定条件に応じて異なる Flow を選択的に実行
• Agent ツール統合：Run Flow を Agent の Tool として接続し、Agent が状況に応じた Flow を自律的に呼び出し

Batch Run: LLM으로 Table 데이터를 일괄 처리

Batch Run 컴포넌트는 Table의 특정 텍스트 컬럼에 대해 LLM을 행(row) 단위로 일괄 실행합니다. CSV 파일이나 SpreadSheet에서 읽어온 대량의 데이터를 한 번에 LLM으로 처리할 때 유용합니다.

설정 방법

Batch Run: Process Table Data with LLM in Bulk

The Batch Run component runs a language model over each row of a text column in a Table. Ideal for bulk-processing large datasets from CSV files or SpreadSheets through an LLM.

Setup Steps

Batch Run：用 LLM 批量处理 Table 数据

Batch Run 组件对 Table 的特定文本列逐行运行 LLM。适用于通过 LLM 批量处理从 CSV 或 SpreadSheet 读取的大量数据。

设置方法

Batch Run：LLM で Table データを一括処理

Batch Run コンポーネントは Table の特定テキスト列に対して LLM を行単位で一括実行します。CSV や SpreadSheet から読み込んだ大量データを LLM で一度に処理する際に便利です。

設定方法

출력 Table 구조

Output Table Structure

输出 Table 结构

出力 Table 構造

7. Agent 만들기 (Tool Mode)

Agent는 LLM이 도구를 자율적으로 선택하고 호출하여 작업을 수행합니다.

7. Building Agents (Tool Mode)

The Agent autonomously selects and invokes tools to accomplish tasks.

7. 创建 Agent（工具模式）

Agent 自主选择和调用工具执行任务。

7. Agent の作成（Tool Mode）

Agent は LLM がツールを自律的に選択・呼び出してタスクを実行します。

설정 팁

• 시스템 프롬프트: Agent 역할과 사용 가능한 도구를 명확히 설명
• 모델: Function Calling 지원 모델 사용
• Tool description: 구체적으로 작성할수록 Agent가 정확히 선택합니다

Tips

• System Prompt: Clearly describe Agent role and available tools
• Model: Use one that supports Function Calling
• Tool description: More specific = better tool selection

配置技巧

• 系统提示词：清晰描述 Agent 角色和可用工具
• 模型：使用支持 Function Calling 的模型
• Tool description：描述越具体，Agent 选择越准确

設定のヒント

• システムプロンプト：Agent の役割と使用可能なツールを明確に説明
• モデル：Function Calling をサポートするモデルを使用
• Tool description：具体的に書くほど Agent が正確に選択します

8. API Access

완성한 Flow는 HTTP API로 외부에 노출할 수 있습니다. 엔드포인트를 확인하려면 Share > API Access를 여세요. 현재 두 가지 API가 제공되며, 목적에 따라 고르면 됩니다.

8. API Access

A finished flow can be exposed over HTTP. Open Share > API Access to find the endpoints. Two APIs are available today; pick based on what you need.

8. API 访问

完成的 Flow 可通过 HTTP API 对外暴露。打开 Share > API Access 查看端点。目前提供两种 API，可按用途选择。

8. API アクセス

完成した Flow は HTTP API として外部に公開できます。エンドポイントは Share > API Access で確認します。現在2種類の API が提供されており、目的に応じて選べます。

8-1. OpenAI 호환 API

Flow를 OpenAI 호환 API로 노출합니다. Flow ID를 model 이름처럼 사용하는 것이 핵심입니다.

8-1. OpenAI-Compatible API

Exposes the flow as an OpenAI-compatible API. The trick is that the Flow ID acts as the model name.

8-1. OpenAI 兼容 API

将 Flow 作为 OpenAI 兼容 API 暴露。关键在于将 Flow ID 用作 model 名称。

8-1. OpenAI 互換 API

Flow を OpenAI 互換 API として公開します。Flow ID を model 名として使う点がポイントです。

1) requests 호출

1) requests call

1) requests 调用

1) requests での呼び出し

2) OpenAI SDK 호환

2) OpenAI SDK compatible

2) OpenAI SDK 兼容

2) OpenAI SDK 互換

3) 스트리밍

3) Streaming

3) 流式

3) ストリーミング

4) 멀티턴 대화

4) Multi-turn

4) 多轮对话

4) マルチターン会話

8-2. Workflow API v21.11

1.11에서 추가된 새 API입니다 (Beta). OpenAI 호환성을 버리는 대신, Flow를 "실행"하는 데 필요한 제어권을 더 많이 줍니다 — 호출할 때마다 컴포넌트 설정을 바꾸거나, 오래 걸리는 작업을 백그라운드 잡으로 던져 놓을 수 있습니다.

8-2. Workflow API v21.11

A new API added in 1.11 (Beta). It gives up OpenAI compatibility in exchange for more control over how the flow runs — override component settings per call, or hand long-running work off as a background job.

8-2. Workflow API v21.11

1.11 新增的 API（Beta）。它舍弃了 OpenAI 兼容性，换来对 Flow"运行方式"更强的控制权 — 可在每次调用时覆盖组件设置，或将耗时任务作为后台作业提交。

8-2. Workflow API v21.11

1.11 で追加された新しい API です（Beta）。OpenAI 互換性を手放す代わりに、Flow の「実行」に対するより多くの制御を提供します — 呼び出しごとにコンポーネント設定を上書きしたり、長時間の処理をバックグラウンドジョブとして投げたりできます。

3가지 실행 모드

• sync — 인라인 실행. 완료까지 기다렸다가 WorkflowExecutionResponse를 한 번에 받습니다.
• stream — SSE(Server-Sent Events)로 진행 상황을 실시간 수신합니다.
• background — 큐에 적재하고 job 객체를 즉시 반환합니다. 이후 폴링으로 결과를 확인합니다.

주요 요청 필드

• tweaks — 컴포넌트별 파라미터를 호출 시점에 덮어씁니다. Flow를 고치지 않고 모델명이나 Temperature만 바꿔 호출할 때 유용합니다.
• globals — 요청 스코프 변수 (sync 모드 전용).

스트리밍 프로토콜 (stream_protocol)

• langflow (기본값) — Langflow 내부 EventManager 이벤트: token, add_message, end_vertex 등. Flow 내부 동작까지 들여다볼 때.
• agui — AG-UI 프로토콜: RUN_STARTED, TEXT_MESSAGE_*, TOOL_CALL_* 등. 클라이언트가 에이전트 생애주기 이벤트를 기대할 때.

Three execution modes

• sync — runs inline. Waits for completion and returns a single WorkflowExecutionResponse.
• stream — streams progress in real time over SSE (Server-Sent Events).
• background — queues the run and returns a job object immediately; poll for the result afterwards.

Key request fields

• tweaks — overrides per-component parameters at call time. Handy for changing a model name or temperature without editing the flow.
• globals — request-scoped variables (sync mode only).

Streaming protocols (stream_protocol)

• langflow (default) — Langflow's internal EventManager events: token, add_message, end_vertex, etc. Use it when you want visibility into the flow's internals.
• agui — the AG-UI protocol: RUN_STARTED, TEXT_MESSAGE_*, TOOL_CALL_*, etc. Use it when your client expects agent lifecycle events.

三种执行模式

• sync — 内联执行。等待完成后一次性返回 WorkflowExecutionResponse。
• stream — 通过 SSE（Server-Sent Events）实时接收进度。
• background — 写入队列并立即返回 job 对象，随后通过轮询获取结果。

主要请求字段

• tweaks — 在调用时覆盖各组件的参数。无需修改 Flow 即可更改模型名或 Temperature。
• globals — 请求作用域变量（仅 sync 模式）。

流式协议（stream_protocol）

• langflow（默认）— Langflow 内部 EventManager 事件：token、add_message、end_vertex 等。适合需要观察 Flow 内部动作时。
• agui — AG-UI 协议：RUN_STARTED、TEXT_MESSAGE_*、TOOL_CALL_* 等。适合客户端期待代理生命周期事件时。

3つの実行モード

• sync — インライン実行。完了まで待って WorkflowExecutionResponse を一度に受け取ります。
• stream — SSE（Server-Sent Events）で進捗をリアルタイムに受信します。
• background — キューに投入し job オブジェクトを即座に返します。以降はポーリングで結果を確認します。

主なリクエストフィールド

• tweaks — コンポーネントごとのパラメータを呼び出し時に上書きします。Flow を編集せずモデル名や Temperature だけ変えたい場合に便利です。
• globals — リクエストスコープの変数（sync モード専用）。

ストリーミングプロトコル（stream_protocol）

• langflow（既定）— Langflow 内部の EventManager イベント：token、add_message、end_vertex など。Flow の内部動作まで見たい場合に。
• agui — AG-UI プロトコル：RUN_STARTED、TEXT_MESSAGE_*、TOOL_CALL_* など。クライアントがエージェントのライフサイクルイベントを期待する場合に。

1) sync 모드 — tweaks로 파라미터 덮어쓰기

1) sync mode — overriding parameters with tweaks

1) sync 模式 — 用 tweaks 覆盖参数

1) sync モード — tweaks でパラメータを上書き

2) background 모드 — 오래 걸리는 작업 폴링

2) background mode — polling a long-running job

2) background 模式 — 轮询耗时任务

2) background モード — 長時間処理のポーリング

Settings: Langflow API Keys

외부 시스템에서 Langflow Flow를 호출하려면 API Key가 필요합니다. Settings > Langflow API Keys에서 관리합니다.

Settings: Langflow API Keys

To call Langflow Flows from external systems, you need an API Key. Manage them at Settings > Langflow API Keys.

Settings：Langflow API Keys

从外部系统调用 Langflow Flow 需要 API Key。在 Settings > Langflow API Keys 中管理。

Settings：Langflow API Keys

外部システムから Langflow Flow を呼び出すには API Key が必要です。Settings > Langflow API Keys で管理します。

9. RAG Pipeline 구축하기

RAG(Retrieval-Augmented Generation)는 LLM이 외부 문서를 검색(Retrieval)한 후 그 내용을 바탕으로 답변을 생성(Generation)하는 패턴입니다. 폐쇄망(Air-gapped) 내 사내 문서를 LLM이 참고하도록 만들 수 있어 실무에서 가장 많이 사용됩니다.

RAG가 필요한 이유

• LLM은 학습 데이터에 없는 사내 문서, 매뉴얼, 규정을 모름
• RAG로 관련 문서를 검색하여 LLM에 컨텍스트로 제공
• 할루시네이션(거짓 정보 생성)을 크게 줄일 수 있음

RAG Flow 구조

9. Building a RAG Pipeline

RAG (Retrieval-Augmented Generation) is a pattern where the LLM retrieves external documents first, then generates answers based on that content. Essential for making LLMs reference internal documents in air-gapped environments.

Why RAG?

• LLMs don't know your internal docs, manuals, or policies
• RAG retrieves relevant docs and provides them as context to the LLM
• Significantly reduces hallucinations

RAG Flow Structure

9. 构建 RAG 管道

RAG（检索增强生成）是 LLM 先检索外部文档，再基于内容生成回答的模式。在封闭网络中让 LLM 参考内部文档的必备方案。

为什么需要 RAG？

• LLM 不了解内部文档、手册、规章
• RAG 检索相关文档并作为上下文提供给 LLM
• 显著减少幻觉（生成虚假信息）

RAG Flow 结构

9. RAG パイプラインの構築

RAG（Retrieval-Augmented Generation）は LLM が外部ドキュメントを検索（Retrieval）した後、その内容を基に回答を生成（Generation）するパターンです。閉域網内の社内ドキュメントを LLM が参照できるようにする方法として最も実務で活用されています。

RAG が必要な理由

• LLM は学習データにない社内文書・マニュアル・規程を知らない
• RAG で関連文書を検索し、LLM にコンテキストとして提供
• ハルシネーション（誤情報の生成）を大幅に削減できる

RAG Flow の構造

단계별 구축

Phase 1: 문서 인덱싱

Phase 2: 검색 및 응답

RAG 프롬프트 예시

Step-by-Step Build

Phase 1: Document Indexing

Phase 2: Retrieval & Response

RAG Prompt Example

分步构建

Phase 1：文档索引

Phase 2：检索与回答

RAG 提示词示例

ステップごとの構築

Phase 1：文書インデクシング

Phase 2：検索と応答

RAG プロンプト例

10. 실전 Tips & 트러블슈팅

Trace (Flow Activity) — 네이티브 Observability

Phoenix 같은 외부 Tracing 도구 없이도, Langflow 1.8+부터 Flow Activity에서 실행 과정을 네이티브로 추적할 수 있습니다.

• Flow Activity 패널: Flow 실행 후 각 컴포넌트의 입력/출력, 실행 시간, 상태를 단계별로 확인
• 에러 추적: 어떤 컴포넌트에서 실패했는지, 어떤 에러가 발생했는지 즉시 파악
• 토큰 사용량: LLM 호출 시 사용된 토큰 수와 비용 확인
• 실행 이력: 과거 실행 결과를 저장하여 비교/분석 가능

Trace (Flow Activity) — Native Observability

Since Langflow 1.8+, Flow Activity provides native execution tracing without external tools like Phoenix.

• Flow Activity panel: View each component's input/output, execution time, and status step by step
• Error tracking: Instantly identify which component failed and what error occurred
• Token usage: Check token counts and costs for LLM calls
• Execution history: Past runs are saved for comparison and analysis

Trace（Flow Activity）— 原生可观测性

从 Langflow 1.8+ 起，Flow Activity 无需 Phoenix 等外部工具即可原生追踪执行过程。

• Flow Activity 面板：逐步查看每个组件的输入/输出、执行时间和状态
• 错误追踪：即时识别哪个组件失败及错误原因
• Token 用量：查看 LLM 调用的 Token 数量和成本
• 执行历史：保存过去的运行结果用于比较和分析

Trace（Flow Activity）— ネイティブ Observability

Langflow 1.8+ から、Phoenix などの外部ツールなしで Flow Activity でネイティブに実行過程を追跡できます。

• Flow Activity パネル：各コンポーネントの入出力、実行時間、ステータスをステップごとに確認
• エラー追跡：どのコンポーネントで失敗したか、どんなエラーが発生したか即座に把握
• トークン使用量：LLM 呼び出しで使用されたトークン数とコストを確認
• 実行履歴：過去の実行結果を保存して比較・分析可能

Flow 설계 Best Practices

• 작게 시작: 복잡한 Flow를 한 번에 만들지 말고, 2~3개 컴포넌트로 기본 동작을 확인한 후 점진적으로 확장하세요.
• Playground에서 즉시 테스트: 컴포넌트를 추가할 때마다 Playground에서 동작을 확인하세요.
• 각 컴포넌트 개별 실행: 컴포넌트의 재생(▷) 버튼으로 개별 테스트가 가능합니다. 문제 발생 시 어디서 실패했는지 빠르게 찾을 수 있습니다.
• Freeze 활용: 정상 동작이 확인된 컴포넌트는 Freeze하여 재실행 시 불필요한 API 호출을 줄이세요.

자주 발생하는 문제

10. Pro Tips & Troubleshooting

Flow Design Best Practices

• Start small: Don't build complex Flows at once. Verify basic operation with 2-3 components, then expand.
• Test immediately in Playground: Check behavior after each component addition.
• Run components individually: Use the play (▷) button to test each component. Quickly identify where failures occur.
• Use Freeze: Freeze verified components to avoid unnecessary API calls on re-runs.

Common Issues

10. 实战技巧与故障排除

Flow 设计最佳实践

• 从小开始：不要一次构建复杂 Flow。先用2-3个组件验证基本功能，再逐步扩展。
• 在 Playground 中立即测试：每添加一个组件就检查行为。
• 单独运行组件：使用播放（▷）按钮测试各组件。快速定位故障点。
• 使用 Freeze：冻结已验证的组件，避免重新运行时的不必要 API 调用。

常见问题

10. 実践 Tips & トラブルシューティング

Flow 設計のベストプラクティス

• 小さく始める：複雑な Flow を一度に作らず、2〜3個のコンポーネントで基本動作を確認してから段階的に拡張してください。
• Playground ですぐテスト：コンポーネントを追加するたびに Playground で動作を確認してください。
• 各コンポーネントを個別実行：コンポーネントの再生（▷）ボタンで個別テストが可能です。問題発生時にどこで失敗したか素早く特定できます。
• Freeze を活用：正常動作が確認できたコンポーネントは Freeze して、再実行時の不要な API 呼び出しを削減しましょう。

よくある問題

프롬프트 엔지니어링 팁

• 역할 부여: "당신은 ~한 전문가입니다"로 시작하면 답변 품질이 향상됩니다.
• 출력 형식 지정: "JSON으로 답변하세요", "3가지로 요약하세요" 등 형식을 명시하세요.
• Few-shot 예시: 원하는 입출력 예시를 프롬프트에 포함하면 정확도가 높아집니다.
• 제약 조건: "~하지 마세요", "반드시 ~하세요" 등 경계를 명확히 설정하세요.
• Chain of Thought: "단계별로 생각해주세요"를 추가하면 복잡한 추론에 효과적입니다.

Langflow IDE vs Runtime

Langflow는 개발 환경(IDE)과 운영 환경(Runtime)이 분리되어 있습니다.

• Dev Environment (IDE): 개발자/비즈니스 사용자가 Flow를 설계, 프로토타이핑, 테스트하는 환경
• Production Environment (Runtime): 검증된 Flow가 배포되어 GenAI 애플리케이션이 REST API로 호출하는 환경

Dev에서 충분히 테스트한 Flow를 Production으로 프로모션(승격)하여 운영합니다.

Prompt Engineering Tips

• Assign a role: Start with "You are an expert in ~" to improve answer quality.
• Specify output format: "Reply in JSON", "Summarize in 3 points", etc.
• Few-shot examples: Including input/output examples in prompts improves accuracy.
• Set constraints: "Do not ~", "Always ~" — set clear boundaries.
• Chain of Thought: Adding "Think step by step" helps with complex reasoning.

Langflow IDE vs Runtime

Langflow separates Development (IDE) and Production (Runtime) environments.

• Dev Environment (IDE): Where developers/business users design, prototype, and test Flows
• Production Environment (Runtime): Where validated Flows are deployed; GenAI apps call them via REST API

Flows are promoted from Dev to Production after thorough testing.

提示词工程技巧

• 分配角色：以"你是~领域的专家"开头可提高回答质量。
• 指定输出格式："用JSON回答"、"总结为3点"等。
• Few-shot 示例：在提示词中包含输入/输出示例可提高准确性。
• 设置约束："不要~"、"必须~"——设定明确边界。
• 思维链：添加"请逐步思考"有助于复杂推理。

Langflow IDE 与 Runtime

Langflow 将开发环境（IDE）和生产环境（Runtime）分离。

• Dev Environment（IDE）：开发者/业务用户设计、原型验证和测试 Flow 的环境
• Production Environment（Runtime）：经验证的 Flow 部署后，GenAI 应用通过 REST API 调用

Flow 在 Dev 中充分测试后升级（Promote）到 Production。

プロンプトエンジニアリングのヒント

• 役割の付与：「あなたは〜の専門家です」で始めると回答品質が向上します。
• 出力形式の指定：「JSON で回答してください」「3点に要約してください」など形式を明示します。
• Few-shot 例示：期待する入出力の例をプロンプトに含めると精度が高まります。
• 制約条件：「〜しないでください」「必ず〜してください」など境界を明確に設定します。
• Chain of Thought：「ステップごとに考えてください」を追加すると複雑な推論に効果的です。

Langflow IDE と Runtime

Langflow は開発環境（IDE）と運用環境（Runtime）が分離されています。

• Dev Environment（IDE）：開発者・ビジネスユーザーが Flow を設計・プロトタイピング・テストする環境
• Production Environment（Runtime）：検証済みの Flow がデプロイされ、GenAI アプリが REST API で呼び出す環境

Dev で十分にテストした Flow を Production へプロモーション（昇格）して運用します。

컨테이너 기반 아키텍처

현재 Langflow는 Kubernetes 클러스터 위에 컨테이너 형태로 배포되어 있습니다. Ingress Controller와 Load Balancer를 통해 여러 Langflow Replica Pod가 요청을 분산 처리하며, Storage Pod에서 Flow 데이터를 관리합니다.

Container-based Architecture

Langflow is deployed as containers on a Kubernetes cluster. An Ingress Controller and Load Balancer distribute requests across multiple Langflow Replica Pods, with a Storage Pod managing Flow data.

基于容器的架构

Langflow 以容器形式部署在 Kubernetes 集群上。通过 Ingress Controller 和 Load Balancer 将请求分配到多个 Langflow Replica Pod，Storage Pod 管理 Flow 数据。

コンテナベースのアーキテクチャ

現在 Langflow は Kubernetes クラスター上にコンテナ形式でデプロイされています。Ingress Controller と Load Balancer を通じて複数の Langflow Replica Pod がリクエストを分散処理し、Storage Pod で Flow データを管理します。

11. Langflow 최신 기능 (1.9 → 1.11)

본 가이드가 처음 작성된 1.9 이후로 두 번의 마이너 릴리스가 있었습니다. 사내 환경의 버전이 제각각일 수 있으므로, 각 기능에 도입 버전을 태그로 표시했습니다. 쓰고 계신 버전보다 높은 태그가 붙은 기능은 아직 없는 기능입니다.

11. What's New in Langflow (1.9 → 1.11)

Two minor releases have landed since this guide was first written against 1.9. Because installations in an organization drift apart, every feature below carries a version tag. If a tag is newer than the version you run, that feature isn't there yet.

11. Langflow 最新功能 (1.9 → 1.11)

自本指南基于 1.9 编写以来，已发布两个次要版本。由于各处环境的版本可能不一致，下列每项功能均标注了引入版本标签。标签高于您所用版本的功能，即尚未提供的功能。

11. Langflow 最新機能 (1.9 → 1.11)

本ガイドが 1.9 を基準に書かれて以降、2回のマイナーリリースがありました。社内環境のバージョンはまちまちになりがちなため、各機能に導入バージョンのタグを付けています。お使いのバージョンより新しいタグの機能は、まだ存在しない機能です。

Langflow Assistant — 이제 Flow 전체를 만듭니다1.9 → 1.10

Langflow UI 안에 내장된 AI 어시스턴트입니다. 1.9에서는 자연어로 설명하면 Custom Component 코드를 생성해 주는 수준이었지만, 1.10부터는 컴포넌트가 서로 연결된 Flow 전체를 만들어냅니다. "URL에서 제목을 뽑아 채팅으로 답하는 Flow를 만들어줘"라고 하면 Chat Input → 커스텀 컴포넌트 → Chat Output까지 배선된 상태로 완성됩니다.

사용 방법

1. LLM Provider 설정: Settings에서 Assistant가 사용할 LLM Provider를 먼저 구성합니다.
2. Assistant 열기: Langflow UI에서 Assistant를 실행합니다.
3. 자연어로 설명: 원하는 기능을 자연어로 입력합니다 (프롬프트 최대 500자).
4. 생성 및 검증: Assistant가 Flow를 생성하고, 직접 실행해 결과까지 확인합니다.

Langflow Assistant — Now It Builds Entire Flows1.9 → 1.10

An AI assistant built into the Langflow UI. On 1.9 it generated Custom Component code from a natural-language description; since 1.10 it produces a complete, wired-up flow. Ask for "a flow that extracts titles from URLs and answers in chat" and you get Chat Input → custom component → Chat Output already connected.

How to use it

1. Configure an LLM provider: set up the provider the Assistant will use in Settings.
2. Open the Assistant: launch it from the Langflow UI.
3. Describe it in natural language: type what you want (prompt limit 500 characters).
4. Generate and validate: the Assistant builds the flow, runs it, and checks the result.

Langflow Assistant — 现在可生成完整 Flow1.9 → 1.10

内置于 Langflow UI 中的 AI 助手。在 1.9 中，它根据自然语言描述生成自定义组件代码；自 1.10 起可生成组件间已连线的完整 Flow。只需说"做一个从 URL 提取标题并在聊天中回复的 Flow"，即可得到 Chat Input → 自定义组件 → Chat Output 已连接的成品。

使用方法

1. 配置 LLM Provider：先在 Settings 中配置 Assistant 使用的 LLM Provider。
2. 打开 Assistant：在 Langflow UI 中启动。
3. 用自然语言描述：输入所需功能（提示词上限 500 字符）。
4. 生成与验证：Assistant 生成 Flow 并直接运行确认结果。

Langflow Assistant — Flow 全体を作れるように1.9 → 1.10

Langflow UI に内蔵された AI アシスタントです。1.9 では自然言語の説明からカスタムコンポーネントのコードを生成する程度でしたが、1.10 からはコンポーネントが繋がった Flow 全体を作り上げます。「URL からタイトルを抽出してチャットで答える Flow を作って」と頼めば、Chat Input → カスタムコンポーネント → Chat Output まで配線された状態で完成します。

使い方

1. LLM Provider の設定：Assistant が使う LLM Provider を Settings で先に構成します。
2. Assistant を開く：Langflow UI から起動します。
3. 自然言語で説明：欲しい機能を入力します（プロンプト最大500文字）。
4. 生成と検証：Assistant が Flow を生成し、実行して結果まで確認します。

Memory Bases — 세션을 넘어서는 대화 기억1.10

기존 Chat Memory는 같은 세션 안에서 최근 메시지를 시간순으로 불러오는 방식이었습니다. Memory Base는 대화 메시지를 자동으로 임베딩해 벡터로 저장하고, 질문과 의미가 가까운 과거 대화를 세션 경계를 넘어 찾아옵니다. "지난주에 얘기했던 그 설비 이슈"를 Agent가 기억하게 만드는 기능입니다.

비슷해 보이는 세 가지 개념을 구분하는 것이 핵심입니다.

Memory Bases — Conversation Memory Across Sessions1.10

Classic chat memory pulls recent messages in chronological order within one session. A Memory Base instead embeds conversation messages into a vector store automatically and retrieves past exchanges that are semantically close to the current question — across session boundaries. This is what lets an agent remember "that equipment issue we discussed last week."

The key is telling three similar-looking concepts apart.

Memory Bases — 跨会话的对话记忆1.10

传统 Chat Memory 是在同一会话内按时间顺序调取最近消息。而 Memory Base 会自动将对话消息嵌入并存为向量，跨越会话边界检索与当前问题语义相近的历史对话。这正是让 Agent 记住"上周聊过的那个设备问题"的功能。

关键在于区分三个看似相似的概念。

Memory Bases — セッションを越える会話の記憶1.10

従来の Chat Memory は同一セッション内の直近メッセージを時系列で取得する方式でした。Memory Base は会話メッセージを自動的に埋め込みベクトルとして保存し、質問と意味的に近い過去の会話をセッションの境界を越えて探し出します。「先週話したあの設備の問題」を Agent に覚えさせる機能です。

似て見える3つの概念を区別することが重要です。

만들고 연결하기

1. 좌측 사이드바에서 Memories → Create를 누르고, 이름과 Embedding Model을 지정합니다.
2. Flow에 Memory Base 컴포넌트를 놓고 방금 만든 메모리를 드롭다운에서 선택합니다.
3. 컴포넌트의 Tool Mode를 켠 뒤, 출력을 Agent의 Tools 입력에 연결합니다 (7장 Tool Mode 참조).

주요 옵션

• Auto-capture — 기본 활성. 메시지가 일정량 쌓이면 자동으로 적재됩니다.
• LLM Preprocessing — 임베딩 전에 LLM으로 대화를 요약(distill)합니다. 잡담이 많은 대화에서 검색 품질이 올라갑니다.
• Kill phrases — 응답에 특정 문구가 있으면 적재를 건너뜁니다. 기본값은 NO_INGEST입니다.
• 세션 필터링 — 기본값은 현재 세션의 청크만 조회합니다. 세션을 넘어 검색하려면 이 설정을 조정해야 합니다.

Creating and connecting one

1. Click Memories in the left sidebar → Create, then give it a name and an embedding model.
2. Drop a Memory Base component into your flow and pick the memory you just created from the dropdown.
3. Turn on Tool Mode and wire its output to the Agent's Tools input (see Chapter 7, Tool Mode).

Key options

• Auto-capture — on by default; ingestion triggers once messages reach a batch threshold.
• LLM Preprocessing — distills conversations with an LLM before embedding. Improves retrieval quality on chatty conversations.
• Kill phrases — skip ingestion when a response contains a given term. Default is NO_INGEST.
• Session filtering — by default only chunks from the current session are retrieved. Adjust this to search across sessions.

创建与连接

1. 在左侧边栏点击 Memories → Create，指定名称和 Embedding Model。
2. 在 Flow 中放置 Memory Base 组件，并从下拉菜单选择刚创建的记忆库。
3. 开启组件的 Tool Mode，将其输出连接到 Agent 的 Tools 输入（参见第 7 章 Tool Mode）。

主要选项

• Auto-capture — 默认开启。消息累积到阈值时自动写入。
• LLM Preprocessing — 嵌入前用 LLM 对对话进行提炼。在闲聊较多的对话中可提升检索质量。
• Kill phrases — 响应中包含特定短语时跳过写入。默认值为 NO_INGEST。
• 会话过滤 — 默认仅检索当前会话的分块。如需跨会话检索，须调整此设置。

作成と接続

1. 左サイドバーの Memories → Create を押し、名前と Embedding Model を指定します。
2. Flow に Memory Base コンポーネントを置き、作成したメモリをドロップダウンで選択します。
3. コンポーネントの Tool Mode を有効にし、出力を Agent の Tools 入力に接続します（7章 Tool Mode 参照）。

主なオプション

• Auto-capture — 既定で有効。メッセージが一定量たまると自動的に取り込まれます。
• LLM Preprocessing — 埋め込み前に LLM で会話を要約（distill）します。雑談の多い会話で検索品質が向上します。
• Kill phrases — 応答に特定の文言が含まれる場合、取り込みをスキップします。既定値は NO_INGEST です。
• セッションフィルタ — 既定では現在のセッションのチャンクのみ取得します。セッションを越えて検索するには調整が必要です。

Human-in-the-Loop (HITL) — 사람의 승인을 기다리는 Flow1.11

Agent에게 실제 권한을 주려면 "이 작업은 사람이 한 번 봐야 한다"는 지점이 반드시 생깁니다. HITL은 Flow를 그 지점에서 일시정지하고 checkpoint를 만든 뒤, 사람의 판단을 기다립니다. 승인/거부를 선택하면 checkpoint에서 재개되며, 이미 끝난 단계는 다시 실행되지 않습니다.

두 가지 방식

• Human Input 컴포넌트 — 설정한 액션(예: Approve / Reject)마다 출력 분기가 생깁니다. 승인과 거부에서 서로 다른 경로를 태우고 싶을 때 씁니다.
• Agent Tool의 "Requires approval" — 특정 Tool에만 승인 게이트를 겁니다. 분기를 만들지 않고 해당 Tool 실행 직전에만 멈춥니다. 위험한 도구 하나만 막고 싶을 때 간단합니다.

Human-in-the-Loop (HITL) — Flows That Wait for Approval1.11

The moment you give an agent real authority, some step inevitably needs a human to look at it. HITL pauses the flow there and creates a checkpoint while it waits for a decision. Once approved or rejected, the run resumes from the checkpoint — and steps that already finished are not re-executed.

Two ways to do it

• Human Input component — creates an output branch per configured action (e.g. Approve / Reject). Use it when approval and rejection should follow different paths.
• "Requires approval" on an agent tool — gates one specific tool. It adds no branches and simply pauses right before that tool runs. Simplest when you only need to gate one risky tool.

Human-in-the-Loop (HITL) — 等待人工审批的 Flow1.11

一旦赋予 Agent 实际权限，必然出现"这一步需要人来看一眼"的节点。HITL 会在该节点暂停 Flow 并创建 checkpoint，等待人工判断。选择批准/拒绝后，运行将从 checkpoint 恢复，且已完成的步骤不会重新执行。

两种方式

• Human Input 组件 — 为每个配置的动作（如 Approve / Reject）生成输出分支。适用于批准与拒绝需走不同路径的场景。
• Agent Tool 的 "Requires approval" — 仅对特定 Tool 设置审批门。不生成分支，只在该 Tool 执行前暂停。仅需拦截某个高风险工具时更为简便。

Human-in-the-Loop (HITL) — 人の承認を待つ Flow1.11

Agent に実際の権限を与えると、「この作業は人が一度確認すべき」という地点が必ず生じます。HITL はその地点で Flow を一時停止して checkpoint を作り、人の判断を待ちます。承認/却下を選ぶと checkpoint から再開され、すでに完了した工程は再実行されません。

2つの方式

• Human Input コンポーネント — 設定したアクション（例：Approve / Reject）ごとに出力の分岐ができます。承認と却下で別の経路を通したい場合に使います。
• Agent Tool の「Requires approval」 — 特定の Tool にのみ承認ゲートをかけます。分岐を作らず、その Tool の実行直前だけ停止します。危険な道具を1つだけ止めたい場合に簡単です。

A2A (Agent2Agent) 프로토콜1.11

Flow를 A2A 에이전트로 게시하면 외부 에이전트가 이를 발견하고 호출할 수 있고, 반대로 원격 A2A 에이전트를 내 Flow 안에서 호출할 수도 있습니다. 게시하면 /api/v1/a2a/<flow-id> 주소가 생기고, 다른 에이전트가 읽을 수 있는 Agent Card(이름, 설명, 입력 계약, 태그, 예시)가 함께 노출됩니다.

MCP와 무엇이 다른가

• MCP — Flow를 도구(Tool)로 노출합니다. 호출하는 쪽이 주도권을 갖고, Flow는 함수처럼 불려갑니다.
• A2A — Flow를 에이전트로 노출합니다. 상대도 자율적으로 판단하는 주체이며, 에이전트 간 작업 위임에 가깝습니다.

A2A (Agent2Agent) Protocol1.11

Publish a flow as an A2A agent and other agents can discover and invoke it; conversely, you can call remote A2A agents from inside your own flow. Publishing exposes an address at /api/v1/a2a/<flow-id> along with an Agent Card — name, description, input contract, tags, and examples — that other agents can read.

How is this different from MCP?

• MCP — exposes a flow as a tool. The caller holds the initiative and the flow gets invoked like a function.
• A2A — exposes a flow as an agent. The other side reasons for itself too; this is closer to delegating work between agents.

A2A (Agent2Agent) 协议1.11

将 Flow 发布为 A2A 代理后，外部代理即可发现并调用它；反之也可在自己的 Flow 中调用远程 A2A 代理。发布后会生成 /api/v1/a2a/<flow-id> 地址，并同时公开可供其他代理读取的 Agent Card（名称、描述、输入契约、标签、示例）。

与 MCP 有何不同

• MCP — 将 Flow 暴露为工具（Tool）。主动权在调用方，Flow 像函数一样被调用。
• A2A — 将 Flow 暴露为代理（Agent）。对方同样是自主判断的主体，更接近代理间的任务委派。

A2A (Agent2Agent) プロトコル1.11

Flow を A2A エージェントとして公開すると、外部エージェントがそれを発見し呼び出せるようになり、逆にリモートの A2A エージェントを自分の Flow 内から呼ぶこともできます。公開すると /api/v1/a2a/<flow-id> のアドレスが生成され、他のエージェントが読み取れる Agent Card（名前、説明、入力契約、タグ、例）も併せて公開されます。

MCP と何が違うのか

• MCP — Flow をツール（Tool）として公開します。主導権は呼び出す側にあり、Flow は関数のように呼ばれます。
• A2A — Flow をエージェントとして公開します。相手も自律的に判断する主体であり、エージェント間のタスク委譲に近い関係です。

Workflow API v2 & AG-UI 스트리밍1.11

Flow를 외부에서 호출하는 새로운 API가 추가되었습니다. sync / stream / background 세 가지 실행 모드와 AG-UI 프로토콜 스트리밍을 지원합니다. 기존 /api/v1/responses도 그대로 쓸 수 있으며, 두 API의 선택 기준과 예제 코드는 8장 API Access에서 자세히 다룹니다.

UI 다국어 지원1.10

Langflow UI 자체가 7개 언어를 지원합니다 — 영어, 프랑스어, 스페인어, 독일어, 포르투갈어, 일본어, 중국어. 프로필 설정에서 변경합니다.

기타 주요 개선

• Redis 기반 Job Queue 1.10 — 멀티워커 배포에서 작업을 안정적으로 분배합니다.
• Python 3.10–3.14 지원 1.10 — 공식 Docker 이미지는 3.14 기준입니다.
• File System 컴포넌트 1.10 — 샌드박스가 적용된 파일 read/write. read-only 모드로 제한할 수 있습니다.
• IBM Db2 컴포넌트 1.10 — 엔터프라이즈 DB 연동.
• MCP 기반 상호운용성 1.9 — 모든 Flow가 자동으로 MCP Tool로 노출되어, 외부 에이전트나 IDE가 Visual Builder 없이 Flow를 실행할 수 있습니다.
• 배포 스테퍼 UI 1.9 — Flow 배포를 단계별로 안내하는 배포 페이지.
• 글로벌 모델 설정 1.8 — API 키를 한 번만 설정하면 모든 Flow에서 공유됩니다.
• Traces 1.8 — Flow 실행 과정을 단계별로 추적·디버깅 (10장 참조).

Workflow API v2 & AG-UI Streaming1.11

A new API for calling flows from outside, with three execution modes — sync / stream / background — and AG-UI protocol streaming. The existing /api/v1/responses still works; see Chapter 8, API Access for how to choose between them, with example code.

UI Internationalization1.10

The Langflow UI itself speaks seven languages — English, French, Spanish, German, Portuguese, Japanese, and Chinese. Switch in your profile settings.

Other Notable Improvements

• Redis-backed job queue 1.10 — reliable work distribution across multi-worker deployments.
• Python 3.10–3.14 support 1.10 — official Docker images are built on 3.14.
• File System component 1.10 — sandboxed file read/write, restrictable to read-only.
• IBM Db2 component 1.10 — enterprise database integration.
• MCP interoperability 1.9 — every flow is exposed as an MCP tool automatically, so external agents and IDEs can run flows without the Visual Builder.
• Deployment stepper UI 1.9 — a guided, step-by-step deployment page.
• Global model settings 1.8 — configure API keys once and share them across all flows.
• Traces 1.8 — step-by-step execution tracing and debugging (see Chapter 10).

Workflow API v2 & AG-UI 流式传输1.11

新增了从外部调用 Flow 的 API，支持 sync / stream / background 三种执行模式以及 AG-UI 协议流式传输。原有的 /api/v1/responses 仍可继续使用；两者的选择标准与示例代码详见第 8 章 API Access。

UI 多语言支持1.10

Langflow UI 本身支持 7 种语言 — 英语、法语、西班牙语、德语、葡萄牙语、日语、中文。在个人资料设置中切换。

其他主要改进

• 基于 Redis 的 Job Queue 1.10 — 在多 worker 部署中稳定分配任务。
• 支持 Python 3.10–3.14 1.10 — 官方 Docker 镜像基于 3.14。
• File System 组件 1.10 — 带沙箱的文件读写，可限制为只读模式。
• IBM Db2 组件 1.10 — 企业级数据库集成。
• 基于 MCP 的互操作性 1.9 — 所有 Flow 自动暴露为 MCP 工具，外部代理与 IDE 无需 Visual Builder 即可执行 Flow。
• 部署引导 UI 1.9 — 分步引导的部署页面。
• 全局模型设置 1.8 — API 密钥一次配置，所有 Flow 共享。
• Traces 1.8 — 逐步追踪与调试 Flow 执行过程（参见第 10 章）。

Workflow API v2 & AG-UI ストリーミング1.11

Flow を外部から呼び出す新しい API が追加されました。sync / stream / background の3つの実行モードと AG-UI プロトコルのストリーミングに対応します。既存の /api/v1/responses もそのまま利用可能で、両者の選択基準とサンプルコードは8章 API Access で詳しく扱います。

UI の多言語対応1.10

Langflow UI 自体が7言語に対応します — 英語、フランス語、スペイン語、ドイツ語、ポルトガル語、日本語、中国語。プロフィール設定で変更します。

その他の主要な改善

• Redis ベースの Job Queue 1.10 — マルチワーカー配備でタスクを安定して分配します。
• Python 3.10–3.14 対応 1.10 — 公式 Docker イメージは 3.14 ベースです。
• File System コンポーネント 1.10 — サンドボックス付きのファイル読み書き。read-only モードに制限可能です。
• IBM Db2 コンポーネント 1.10 — エンタープライズ DB 連携。
• MCP ベースの相互運用性 1.9 — すべての Flow が自動的に MCP ツールとして公開され、外部エージェントや IDE が Visual Builder なしで Flow を実行できます。
• デプロイステッパー UI 1.9 — 段階的に案内するデプロイページ。
• グローバルモデル設定 1.8 — API キーを一度設定すれば全 Flow で共有されます。
• Traces 1.8 — Flow 実行のステップごとの追跡・デバッグ（10章参照）。

12. 1.11 업그레이드 & 폐쇄망 체크리스트

1.11은 편리한 신기능만 들어온 릴리스가 아닙니다. 설치 방식과 기본 인증 동작이 바뀌어, 기존 방식 그대로 올리면 컨테이너가 아예 뜨지 않거나 쓰던 컴포넌트가 사라질 수 있습니다. 폐쇄망 운영자가 반드시 먼저 읽어야 할 내용입니다.

12. Upgrading to 1.11 & Air-gapped Checklist

1.11 isn't just a bag of new features. Installation layout and default authentication behavior both changed, so lifting your existing setup as-is can leave the container refusing to start, or components you relied on missing. Read this first if you operate an air-gapped instance.

12. 1.11 升级 & 封闭网络检查清单

1.11 并非只带来便利的新功能。安装方式与默认认证行为均已改变，若按原样部署，容器可能根本无法启动，或原本使用的组件消失。封闭网络运维人员务必优先阅读。

12. 1.11 アップグレード & 閉域網チェックリスト

1.11 は便利な新機能だけのリリースではありません。インストール方式と既定の認証動作が変更されており、従来のまま起動するとコンテナが立ち上がらない、使っていたコンポーネントが消えるといった事態が起こり得ます。閉域網の運用担当者は必ず先に目を通してください。

12-1. lfx-bundles 분리 — 폐쇄망 최대 이슈1.11

1.11부터 상당수의 서드파티 통합이 core langflow 패키지에서 빠져나와 lfx-bundles 패키지의 long-tail 번들로 이동했습니다. 인터넷이 되는 환경에서는 pip install이 알아서 끌어오므로 티가 나지 않지만, 폐쇄망에서는 "있던 컴포넌트가 사라졌다"로 나타납니다.

12-1. The lfx-bundles Split — The Big One for Air-gapped Sites1.11

As of 1.11, many third-party integrations moved out of the core langflow package into long-tail bundles inside the lfx-bundles package. With internet access pip install pulls them in and you never notice. Air-gapped, it shows up as "components that used to be there are gone."

12-1. lfx-bundles 拆分 — 封闭网络的最大问题1.11

从 1.11 起，大量第三方集成已从核心 langflow 包移出，转入 lfx-bundles 包中的 long-tail 捆绑包。在联网环境中 pip install 会自动拉取，毫无察觉；但在封闭网络中，表现为"原有组件消失了"。

12-1. lfx-bundles の分離 — 閉域網における最大の課題1.11

1.11 から多くのサードパーティ統合が core langflow パッケージを離れ、lfx-bundles パッケージの long-tail バンドルへ移動しました。インターネットがあれば pip install が自動取得するため気づきませんが、閉域網では「あったはずのコンポーネントが消えた」という形で表面化します。

폐쇄망 반입 절차

인터넷 구간에서 wheel을 먼저 수집한 뒤, 사내로 옮겨 오프라인 설치합니다. 운영 환경과 동일한 Python 버전 / OS / CPU 아키텍처에서 수집해야 합니다 — 그렇지 않으면 플랫폼이 맞지 않는 wheel을 받게 됩니다.

Bringing packages into an air-gapped network

Collect wheels on an internet-connected machine, move them inside, and install offline. Collect on the same Python version, OS, and CPU architecture as production — otherwise you'll end up with wheels for the wrong platform.

封闭网络导入流程

先在联网环境收集 wheel，再转入内网离线安装。必须在与生产环境相同的 Python 版本 / 操作系统 / CPU 架构上收集，否则会得到平台不匹配的 wheel。

閉域網への搬入手順

インターネット区間で wheel を収集し、社内へ移してオフラインで導入します。本番と同じ Python バージョン / OS / CPU アーキテクチャで収集してください — そうしないとプラットフォームの合わない wheel を取得することになります。

12-2. 인증 기본값 변경 — 컨테이너가 안 뜨는 이유1.11

1.11은 인증 기본값을 fail-closed로 전환했습니다. 즉, 설정이 빠지면 조용히 기본값으로 넘어가는 대신 기동 자체가 실패합니다. 업그레이드 직후 "컨테이너가 계속 죽는다"의 대부분이 여기서 옵니다.

• 레거시 langflow / langflow 기본 superuser 자격증명이 완전히 제거되었습니다.
• 공식 Docker 이미지가 LANGFLOW_AUTO_LOGIN=false 상태로 출고됩니다.
• LANGFLOW_SUPERUSER_PASSWORD가 필수입니다. 없으면 기본 비밀번호를 만드는 대신 기동에 실패합니다.
• LANGFLOW_SECRET_KEY를 더 이상 자동 생성하지 않습니다. 프로덕션에서는 직접 생성해 명시적으로 지정하세요.

12-2. Authentication Defaults Changed — Why Your Container Won't Start1.11

1.11 flipped authentication defaults to fail-closed: when configuration is missing, startup fails instead of quietly falling back to a default. Most "the container keeps dying" reports right after upgrading trace back to this.

• The legacy langflow / langflow default superuser credentials are gone entirely.
• Official Docker images ship with LANGFLOW_AUTO_LOGIN=false.
• LANGFLOW_SUPERUSER_PASSWORD is required. Without it, startup fails rather than creating a default password.
• LANGFLOW_SECRET_KEY is no longer auto-generated. Generate one and set it explicitly in production.

12-2. 认证默认值变更 — 容器无法启动的原因1.11

1.11 将认证默认值改为 fail-closed：配置缺失时不再静默回退到默认值，而是直接启动失败。升级后"容器不断挂掉"的情况大多源于此。

• 旧版 langflow / langflow 默认 superuser 凭据已彻底移除。
• 官方 Docker 镜像以 LANGFLOW_AUTO_LOGIN=false 出厂。
• LANGFLOW_SUPERUSER_PASSWORD 为必填。缺失时不会创建默认密码，而是启动失败。
• LANGFLOW_SECRET_KEY 不再自动生成。生产环境请自行生成并显式指定。

12-2. 認証デフォルトの変更 — コンテナが起動しない原因1.11

1.11 では認証のデフォルトが fail-closed に変わりました。設定が欠けている場合、黙ってデフォルトにフォールバックせず起動そのものが失敗します。アップグレード直後の「コンテナが落ち続ける」の大半はこれが原因です。

• レガシーな langflow / langflow の既定 superuser 資格情報は完全に削除されました。
• 公式 Docker イメージは LANGFLOW_AUTO_LOGIN=false で出荷されます。
• LANGFLOW_SUPERUSER_PASSWORD が必須です。無い場合は既定パスワードを作らず起動に失敗します。
• LANGFLOW_SECRET_KEY は自動生成されなくなりました。本番では自身で生成し明示的に設定してください。

LANGFLOW_SECRET_KEY는 아래처럼 생성합니다. 이 키가 바뀌면 기존에 저장된 Global Variable과 API Key를 복호화할 수 없으므로, 한 번 정하면 안전한 곳에 보관하고 재배포 시에도 동일한 값을 쓰세요.

Generate LANGFLOW_SECRET_KEY as below. If this key changes, previously stored Global Variables and API keys can no longer be decrypted — set it once, keep it somewhere safe, and reuse the same value across redeployments.

按如下方式生成 LANGFLOW_SECRET_KEY。该密钥一旦更改，此前保存的 Global Variable 与 API Key 将无法解密，因此确定后请妥善保管，重新部署时也使用同一值。

LANGFLOW_SECRET_KEY は以下のように生成します。このキーが変わると既存の Global Variable と API Key を復号できなくなるため、一度決めたら安全な場所に保管し、再デプロイ時も同じ値を使用してください。

12-3. 그 밖의 Breaking Change

• Workflow API v2 요청 스키마 변경: 1.10.x에서 v2를 쓰던 클라이언트 코드는 그대로 동작하지 않습니다. 8장 참조.
• Input Schema 창 제거: 별도 패널이던 Input Schema가 각 컴포넌트 내부의 Parameters로 흡수되었습니다. UI 조작 경로가 달라졌으므로, 사내 교육 자료에 예전 화면 캡처가 있다면 갱신이 필요합니다.
• Text / JSON / Table Operations의 legacy 전환: Data Operations로 통합되었습니다. 기존 Flow는 계속 동작합니다 — 3장 참조.

12-3. Other Breaking Changes

• Workflow API v2 request schema changed: client code written against v2 on 1.10.x will not work unchanged. See Chapter 8.
• Input Schema pane removed: the separate Input Schema panel was absorbed into Parameters inside each component. The UI path changed, so internal training material with older screenshots needs refreshing.
• Text / JSON / Table Operations went legacy: consolidated into Data Operations. Existing flows keep working — see Chapter 3.

12-3. 其他 Breaking Change

• Workflow API v2 请求结构变更：在 1.10.x 上针对 v2 编写的客户端代码无法原样运行。参见第 8 章。
• Input Schema 窗口移除：原独立的 Input Schema 面板已并入各组件内部的 Parameters。UI 操作路径已改变，内部培训材料中的旧截图需要更新。
• Text / JSON / Table Operations 转为 legacy：已合并至 Data Operations。既有 Flow 仍可运行 — 参见第 3 章。

12-3. その他の Breaking Change

• Workflow API v2 リクエストスキーマの変更：1.10.x で v2 向けに書いたクライアントコードはそのままでは動作しません。8章参照。
• Input Schema ウィンドウの廃止：独立パネルだった Input Schema が各コンポーネント内の Parameters に統合されました。UI 操作経路が変わったため、社内教育資料に古い画面キャプチャがある場合は更新が必要です。
• Text / JSON / Table Operations の legacy 化：Data Operations に統合されました。既存 Flow は動作し続けます — 3章参照。

12-4. 업그레이드 체크리스트

1.9 / 1.10 → 1.11 이관 시 아래 순서로 확인하세요.

1. Flow 백업: 이관 전 모든 Flow를 JSON으로 Export 해 둡니다. 되돌릴 수단을 먼저 확보하세요.
2. 사용 중인 컴포넌트 목록화: 어떤 서드파티 번들에 의존하는지 정리합니다. Docling 등 PyTorch 계열을 쓰는지 특히 확인.
3. wheel 사전 반입: 12-1의 절차로 langflow + 필요한 번들을 수집해 사내로 옮깁니다.
4. 환경변수 설정: 12-2의 4개 변수를 먼저 채웁니다. 이걸 빼면 기동 자체가 안 됩니다.
5. 스테이징에서 기동 확인: 운영에 바로 올리지 말고, 컨테이너가 뜨고 로그인이 되는지부터 확인합니다.
6. Flow 동작 검증: Data Operations로 통합된 컴포넌트, Knowledge의 DB Provider 설정, Agent의 Tool 연결을 차례로 점검합니다.
7. API 클라이언트 점검: /api/v1/responses를 쓰는 코드는 그대로 동작합니다. v2를 쓰던 코드만 스키마를 맞춥니다.

12-4. Upgrade Checklist

Work through these in order when moving 1.9 / 1.10 → 1.11.

1. Back up flows: export every flow to JSON before you start. Secure your way back first.
2. Inventory your components: note which third-party bundles you depend on. Check especially for PyTorch-based ones like Docling.
3. Stage the wheels: use the 12-1 procedure to collect langflow plus the bundles you need and move them inside.
4. Set environment variables: fill in the four variables from 12-2 first — without them nothing starts.
5. Boot in staging: don't go straight to production; confirm the container starts and you can log in.
6. Verify flows: check the components folded into Data Operations, the Knowledge DB Provider setting, and Agent tool connections in turn.
7. Check API clients: code using /api/v1/responses keeps working. Only v2 callers need schema updates.

12-4. 升级检查清单

从 1.9 / 1.10 → 1.11 迁移时，请按以下顺序确认。

1. 备份 Flow：迁移前将所有 Flow 导出为 JSON。先确保有回退手段。
2. 梳理所用组件：整理依赖了哪些第三方捆绑包，特别确认是否使用 Docling 等 PyTorch 系组件。
3. 预先导入 wheel：按 12-1 的流程收集 langflow 及所需捆绑包并转入内网。
4. 配置环境变量：先填好 12-2 的四个变量，缺失则根本无法启动。
5. 在预发布环境启动验证：不要直接上生产，先确认容器能启动且可以登录。
6. 验证 Flow 运行：依次检查并入 Data Operations 的组件、Knowledge 的 DB Provider 设置以及 Agent 的 Tool 连接。
7. 检查 API 客户端：使用 /api/v1/responses 的代码可照常运行，仅使用 v2 的代码需调整结构。

12-4. アップグレードチェックリスト

1.9 / 1.10 → 1.11 への移行時は以下の順に確認してください。

1. Flow のバックアップ：移行前に全 Flow を JSON でエクスポート。まず戻れる手段を確保します。
2. 使用コンポーネントの棚卸し：どのサードパーティバンドルに依存しているか整理。Docling など PyTorch 系の使用有無を特に確認。
3. wheel の事前搬入：12-1 の手順で langflow と必要なバンドルを収集し社内へ移します。
4. 環境変数の設定：12-2 の4変数を先に埋めます。これが無いと起動しません。
5. ステージングで起動確認：いきなり本番に上げず、コンテナが起動しログインできるかから確認します。
6. Flow の動作検証：Data Operations に統合されたコンポーネント、Knowledge の DB Provider 設定、Agent の Tool 接続を順に点検します。
7. API クライアントの点検：/api/v1/responses を使うコードはそのまま動作します。v2 を使うコードのみスキーマを合わせます。

13. 하네스 엔지니어링 (Harness Engineering)

"모델이 아니라 환경이 병목이다" — 하네스 엔지니어링은 AI 에이전트가 안정적으로 작업할 수 있도록 제약, 피드백, 운영 시스템을 설계하는 방법론입니다. 2026년 2월 HashiCorp과 OpenAI에 의해 공식화되었습니다.

프롬프트 < 컨텍스트 < 하네스

AI 활용 패러다임은 세 단계로 진화하고 있습니다:

1단계: Prompt Engineering — "무엇을 물어볼까?" 단일 입력-출력 쌍 안에서 지시문을 최적화합니다. "You are an expert X. Do Y like Z" 형태의 일회성 기법입니다.

2단계: Context Engineering — "무엇을 보여줄까?" LLM이 작업을 완수하는 데 필요한 모든 정보를 동적으로 조립하는 체계적 설계입니다. Context Window 안에 시스템 프롬프트 + 대화 히스토리 + 검색 문서 + 현재 입력 + 출력 예약분을 어떻게 배분할지가 핵심입니다.

3단계: Harness Engineering — "환경을 어떻게 설계할까?" 프롬프트와 컨텍스트를 넘어, 제약·피드백 루프·운영 시스템 전체를 설계합니다. 모델 성능은 빠르게 평준화되지만, 하네스는 팀이 직접 쌓아야 하는 차별화 자산입니다.

13. Harness Engineering

"The bottleneck is the environment, not the model" — Harness Engineering is the methodology of designing constraints, feedback loops, and operational systems so AI agents can work reliably. Formalized in Feb 2026 by HashiCorp and OpenAI.

Prompt < Context < Harness

AI utilization has evolved through three paradigms:

Stage 1: Prompt Engineering — "What to ask?" Optimize instructions within a single input-output pair.

Stage 2: Context Engineering — "What to show?" Systematically assemble all information the LLM needs: system prompt + conversation history + retrieved docs + current input + reserved output. The "Lost in the Middle" phenomenon (Liu et al., 2023) shows up to 20% accuracy drop when relevant info sits in the middle of the context.

Stage 3: Harness Engineering — "How to design the environment?" Beyond prompts and context, design constraints, feedback loops, and operational systems as a whole. Model performance is rapidly commoditizing; the harness is the differentiating asset teams must build.

13. 哈尼斯工程（Harness Engineering）

"瓶颈在于环境，而非模型" — 哈尼斯工程是设计约束、反馈循环和运营系统以使AI Agent可靠工作的方法论。2026年2月由HashiCorp和OpenAI正式提出。

Prompt < Context < Harness

第1阶段：Prompt Engineering — "问什么？" 在单次输入输出中优化指令。

第2阶段：Context Engineering — "展示什么？" 系统性地动态组装所有信息。"Lost in the Middle"现象显示相关信息在上下文中间时准确率下降高达20%。

第3阶段：Harness Engineering — "如何设计环境？" 超越 Prompt 和 Context，设计约束 + 反馈循环 + 运营系统。模型性能快速同质化，Harness 才是团队的差异化资产。

13. ハーネスエンジニアリング

「ボトルネックはモデルではなく環境にある」 — ハーネスエンジニアリングは、AIエージェントが安定的に動作できるよう制約、フィードバック、運用システムを設計する方法論です。2026年2月にHashiCorpとOpenAIにより公式化されました。

Prompt < Context < Harness

第1段階：Prompt Engineering — 「何を聞くか？」単一の入出力ペアで指示を最適化。

第2段階：Context Engineering — 「何を見せるか？」LLMに必要なすべての情報を体系的に動的組立。「Lost in the Middle」現象では、関連情報がContext中央にあると精度が最大20%低下します。

第3段階：Harness Engineering — 「環境をどう設計するか？」PromptとContextを超え、制約＋フィードバック＋運用システム全体を設計。モデル性能がコモディティ化する中、ハーネスこそチームの差別化資産です。

하네스의 6가지 구성 요소

Langflow에서의 하네스 엔지니어링

Langflow의 Flow 자체가 하네스의 일부입니다. Flow를 설계할 때 하네스 관점을 적용하면 안정성과 재현성이 크게 향상됩니다:

• Prompt Template = 컨텍스트 파일 역할 (일관된 지시사항)
• Tool Mode = MCP 서버 역할 (외부 도구 연결)
• Freeze = 검증된 결과 캐싱 (불필요한 API 호출 방지)
• Traces (1.8+) = 관찰 가능성 (실행 과정 추적)
• Dev → Prod 프로모션 = 피드백 루프 (검증 후 배포)

6 Components of a Harness

Harness Engineering in Langflow

Langflow Flows are themselves part of the harness. Applying harness thinking to Flow design greatly improves stability and reproducibility:

• Prompt Template = Context files (consistent instructions)
• Tool Mode = MCP servers (external tool connection)
• Freeze = Caching verified results (prevent unnecessary API calls)
• Traces (1.8+) = Observability (execution tracking)
• Dev → Prod promotion = Feedback loop (validate before deploy)

哈尼斯的 6 个组成部分

Langflow 中的哈尼斯工程

• Prompt Template = 上下文文件
• Tool Mode = MCP 服务器
• Freeze = 缓存已验证的结果
• Traces = 可观测性
• Dev → Prod = 反馈循环

ハーネスの6つの構成要素

Langflowでのハーネスエンジニアリング

• Prompt Template = コンテキストファイル
• Tool Mode = MCPサーバー
• Freeze = 検証済み結果のキャッシュ
• Traces = 観測可能性
• Dev → Prod = フィードバックループ

Langflow 내부 아키텍처 (개발자용)

Langflow를 단순 사용이 아닌 개발·운영 관점에서 이해하기 위한 아키텍처 요약입니다. DeepWiki 분석을 기반으로 합니다.

3-Tier 풀스택 구조

패키지 구조

Langflow Internal Architecture (For Developers)

An architecture summary for understanding Langflow from a development and operations perspective, based on DeepWiki analysis.

3-Tier Full-Stack Architecture

Package Structure

Langflow 内部架构（开发者用）

从开发和运维角度理解 Langflow 的架构摘要，基于 DeepWiki 分析。

三层全栈架构

包结构

Langflow 内部アーキテクチャ（開発者向け）

Langflow を開発・運用の観点から理解するためのアーキテクチャ要約です。DeepWiki 分析に基づいています。

3層フルスタック構成

パッケージ構成

백엔드 서비스 구조

Backend Service Architecture

后端服务架构

バックエンドサービス構成

데이터베이스 & 배포

• DB 지원: SQLite (개발), PostgreSQL v15+ (프로덕션), Couchbase/ClickHouse (옵션)
• 마이그레이션: Alembic 기반 스키마 버저닝 (langflow/alembic/)
• 캐싱: DiskCache 또는 Redis로 Flow 실행 결과 캐싱, 컴포넌트 인덱스 캐싱으로 시작 시간 단축

배포 옵션

개발자를 위한 주요 환경변수

Database & Deployment

• DB Support: SQLite (dev), PostgreSQL v15+ (production), Couchbase/ClickHouse (optional)
• Migrations: Alembic-based schema versioning (langflow/alembic/)
• Caching: DiskCache or Redis for flow results, component index caching for faster startup

Deployment Options

Key Environment Variables for Developers

数据库与部署

• DB 支持：SQLite（开发）、PostgreSQL v15+（生产）、Couchbase/ClickHouse（可选）
• 迁移：基于 Alembic 的 schema 版本管理
• 缓存：DiskCache 或 Redis 缓存 Flow 结果，组件索引缓存加速启动

部署选项

开发者关键环境变量

データベース & デプロイ

• DB サポート：SQLite（開発）、PostgreSQL v15+（本番）、Couchbase/ClickHouse（オプション）
• マイグレーション：Alembic ベースのスキーマバージョニング
• キャッシュ：DiskCache または Redis で Flow 実行結果をキャッシュ、コンポーネントインデックスキャッシュで起動時間短縮

デプロイオプション

開発者向け主要環境変数

출처: DeepWiki — langflow-ai/langflow

Source: DeepWiki — langflow-ai/langflow

来源：DeepWiki — langflow-ai/langflow

出典：DeepWiki — langflow-ai/langflow

참고자료

공식 문서

• Langflow 공식 문서 — 컴포넌트, API, 설치 가이드
• Langflow GitHub 저장소 — 소스 코드, 이슈, 릴리스 노트
• Langflow 릴리스 노트 — 버전별 신기능과 breaking change 원본
• Langflow 1.11 릴리스 발표 — HITL, A2A, Workflow API v2
• Langflow 1.10 릴리스 발표 — Memory Bases, DB Providers, 다국어

LLM 추론 엔진

• vLLM 공식 문서 — 설치, 모델 서빙, OpenAI-compatible API
• vLLM 논문 — Woosuk Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" (2023)

AI 기초 논문 & 아티클

• Attention Is All You Need — Vaswani et al. (2017), Transformer 아키텍처 원 논문
• Context Engineering: AI 시대의 새로운 핵심 역량 — SK Devocean, Prompt → Context Engineering 진화 분석
• Jensen Huang on Compute as a New Economic Engine — Morgan Stanley, Tokenomics와 AI Factory 비전

오픈소스 모델

• Qwen (Alibaba) — Qwen3.8 시리즈(Max / 27B), 다국어·멀티모달
• GLM (Zhipu AI) — GLM-5.2 / 5.3, MoE 아키텍처
• Kimi (Moonshot AI) — Kimi K3, 긴 컨텍스트(1M)
• Llama (Meta) — Llama 4 시리즈, 오픈소스 LLM

본 가이드

• langflow-guide GitHub — 본 가이드 소스 코드
• Issues — 내용 추가/수정 요청

References

Official Documentation

• Langflow Official Docs — Components, API, installation guide
• Langflow GitHub Repository — Source code, issues, release notes
• Langflow Release Notes — the source of truth for new features and breaking changes
• Langflow 1.11 announcement — HITL, A2A, Workflow API v2
• Langflow 1.10 announcement — Memory Bases, DB Providers, i18n

LLM Inference Engine

• vLLM Official Docs — Installation, model serving, OpenAI-compatible API
• vLLM Paper — Woosuk Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention" (2023)

AI Foundation Papers & Articles

• Attention Is All You Need — Vaswani et al. (2017), original Transformer paper
• Context Engineering: A New Core Competency for the AI Era — SK Devocean, Prompt → Context Engineering evolution
• Jensen Huang on Compute as a New Economic Engine — Morgan Stanley, Tokenomics and AI Factory vision

Open Source Models

• Qwen (Alibaba) — Qwen3.8 series (Max / 27B), multilingual and multimodal
• GLM (Zhipu AI) — GLM-5.2 / 5.3, MoE architecture
• Kimi (Moonshot AI) — Kimi K3, long context (1M)
• Llama (Meta) — Llama 4 series, open-source LLM

This Guide

• langflow-guide GitHub — Source code for this guide
• Issues — Request content additions/changes

参考资料

官方文档

• Langflow 官方文档 — 组件、API、安装指南
• Langflow GitHub 仓库 — 源码、Issues、发布说明
• Langflow 发布说明 — 各版本新功能与 breaking change 的原始出处
• Langflow 1.11 发布公告 — HITL、A2A、Workflow API v2
• Langflow 1.10 发布公告 — Memory Bases、DB Providers、多语言

LLM 推理引擎

• vLLM 官方文档 — 安装、模型服务、OpenAI-compatible API
• vLLM 论文 — Woosuk Kwon 等，PagedAttention（2023）

AI 基础论文与文章

• Attention Is All You Need — Vaswani 等（2017），Transformer 原始论文
• Context Engineering：AI 时代的新核心能力 — SK Devocean
• Jensen Huang on Compute as a New Economic Engine — Morgan Stanley, Tokenomics

开源模型

• Qwen（阿里巴巴） — Qwen3.8 系列
• GLM（智谱 AI） — GLM-5.2 / 5.3
• Kimi（月之暗面） — Kimi K3 系列
• Llama（Meta） — Llama 4 系列

本指南

• langflow-guide GitHub — 本指南源码
• Issues — 请求添加/修改内容

参考資料

公式ドキュメント

• Langflow 公式ドキュメント — コンポーネント、API、インストールガイド
• Langflow GitHub リポジトリ — ソースコード、Issues、リリースノート
• Langflow リリースノート — バージョンごとの新機能と breaking change の原典
• Langflow 1.11 リリース発表 — HITL、A2A、Workflow API v2
• Langflow 1.10 リリース発表 — Memory Bases、DB Providers、多言語対応

LLM 推論エンジン

• vLLM 公式ドキュメント — インストール、モデルサービング、OpenAI-compatible API
• vLLM 論文 — Woosuk Kwon ら、PagedAttention（2023）

AI 基礎論文・記事

• Attention Is All You Need — Vaswani ら（2017）、Transformer 原論文
• Context Engineering：AI時代の新たなコア能力 — SK Devocean
• Jensen Huang on Compute as a New Economic Engine — Morgan Stanley, Tokenomics

オープンソースモデル

• Qwen（Alibaba） — Qwen3.8 シリーズ
• GLM（Zhipu AI） — GLM-5 シリーズ
• Kimi（Moonshot AI） — Kimi K3 シリーズ
• Llama（Meta） — Llama 4 シリーズ

本ガイド

• langflow-guide GitHub — 本ガイドのソースコード
• Issues — コンテンツの追加・修正リクエスト