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.04 기준)

Major Model Providers (as of Apr 2026)

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

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

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 없이도 Langflow 자체 Local ChromaDB에 임베딩을 적재하여 간단한 RAG를 구축할 수 있어, 초기 실험용으로 적합합니다.

Knowledge (Document Collections)

Manage document collections for RAG in the Knowledge tab on the main page. Without a separate VectorDB, Langflow stores embeddings in its built-in Local ChromaDB — ideal for initial experiments.

Knowledge（文档集合）

在主页的 Knowledge 标签中管理用于 RAG 的文档集合。无需单独的 VectorDB，Langflow 自带的 Local ChromaDB 即可存储嵌入——适合初期实验。

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

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

Knowledge 생성 과정

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

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 stored in Langflow's built-in Local ChromaDB.

创建 Knowledge

1. 点击 + Add Knowledge，设定名称，选择 Embedding Model，添加 Source（File 或 Folder）。
2. 添加后下一步可预览约 5 个 Chunk，测试 Chunk size 和 delimiter 设置。
3. Embedding 结果存储在 Langflow 自带的 Local ChromaDB 中。

Knowledge の作成

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

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 をより速く正確に構成できます。

Table Operations: 여러 Table 입력 한 번에 연결

Table Operations 컴포넌트는 Table 타입의 데이터를 가공(필터링, 병합, 정렬 등)하는 데 사용됩니다. 이때 여러 Table 타입 컴포넌트의 출력을 Table Operations의 입력에 동시에 연결할 수 있습니다.

예를 들어, Read File로 읽어온 CSV 데이터 테이블 여러 개나, SpreadSheet 형태의 컴포넌트 출력 등을 한꺼번에 Table Operations에 넣어 병합(merge)하거나 비교 연산을 수행할 수 있습니다.

Table Operations: Connect Multiple Table Inputs at Once

The Table Operations component processes Table-type data (filtering, merging, sorting, etc.). You can connect multiple Table-type component outputs to Table Operations' input simultaneously.

For example, connect several CSV tables loaded via Read File or SpreadSheet-type component outputs all at once to merge or compare them in a single Table Operations step.

Table Operations：一次连接多个 Table 输入

Table Operations 组件用于处理 Table 类型数据（过滤、合并、排序等）。可以将多个 Table 类型组件的输出同时连接到 Table Operations 的输入。

例如，将通过 Read File 读取的多个 CSV 数据表或 SpreadSheet 类型组件的输出同时输入 Table Operations，进行合并或比较运算。

Table Operations：複数の Table 入力を一括接続

Table Operations コンポーネントは Table 型データの加工（フィルタリング、マージ、ソートなど）に使用されます。複数の Table 型コンポーネントの出力を Table Operations の入力に同時に接続できます。

例えば、Read File で読み込んだ複数の CSV データテーブルや、SpreadSheet 型コンポーネントの出力などをまとめて Table Operations に入力し、マージや比較演算を実行できます。

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 (OpenAI 호환)

Flow를 OpenAI 호환 API로 외부에 노출합니다. Share > API Access에서 확인하세요.

8. API Access (OpenAI Compatible)

Expose your Flow as an OpenAI-compatible API. Check Share > API Access.

8. API 访问（OpenAI 兼容）

将 Flow 作为 OpenAI 兼容 API 对外暴露。在 Share > API Access 中查看。

8. API アクセス（OpenAI 互換）

Flow を OpenAI 互換 API として外部に公開します。Share > API Access で確認してください。

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) マルチターン会話

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 주요 신기능

2026년 초 출시된 Langflow 1.9는 AI 에이전트 개발 경험을 크게 향상시키는 기능들이 추가되었습니다.

Langflow Assistant (AI 코파일럿)

Langflow UI 안에 내장된 AI 어시스턴트입니다. 자연어로 "이런 컴포넌트가 필요해"라고 설명하면, Assistant가 Custom Component 코드를 자동 생성합니다.

사용 방법

1. LLM Provider 설정: Settings에서 Anthropic, OpenAI 등 LLM Provider를 먼저 구성합니다.
2. Assistant 열기: Langflow UI에서 Assistant를 실행합니다.
3. 자연어로 설명: 원하는 컴포넌트 기능을 자연어로 입력합니다 (프롬프트 최대 500자).
4. 자동 생성: Assistant가 Custom Component를 즉시 생성합니다.

주요 특징

• 자연어 → 컴포넌트 자동 생성: Python 코드를 직접 작성하지 않아도 됩니다
• Flow 실행 및 검증: 생성한 Flow를 Assistant가 직접 실행하고 결과를 검증
• 비개발자도 활용: 코딩 경험 없이도 커스텀 로직을 구현할 수 있습니다
• 스트리밍 대화: /assist/stream API로 실시간 진행 상황 확인

MCP 기반 상호운용성

Langflow의 모든 Flow가 자동으로 MCP Tool로 노출됩니다. 외부 AI 에이전트나 IDE가 Langflow Flow를 직접 발견하고 호출할 수 있습니다.

• Flow를 MCP 서버로 자동 게시
• 외부 에이전트가 Visual Builder 없이도 Flow를 실행

기타 주요 개선

• 배포 스테퍼 UI: Flow 배포를 단계별로 안내하는 새로운 배포 페이지
• 글로벌 모델 설정 (1.8): API 키를 한 번만 설정하면 모든 Flow에서 공유
• Traces (1.8): Flow 실행 과정을 단계별로 추적·디버깅
• OpenAI Responses API 호환 (1.6): /responses 엔드포인트 지원

11. Langflow 1.9 Key Features

Released early 2026, Langflow 1.9 brings major improvements to the AI agent development experience.

Langflow Assistant (AI Copilot)

A built-in AI assistant inside the Langflow UI. Describe what you need in natural language, and the Assistant auto-generates Custom Component code.

How to Use

1. Configure LLM Provider: Set up Anthropic, OpenAI, etc. in Settings first.
2. Open Assistant: Launch the Assistant from the Langflow UI.
3. Describe in natural language: Type the desired component functionality (max 500 characters).
4. Auto-generate: The Assistant instantly creates the Custom Component.

Key Features

• Natural language → Auto-generated components: No need to write Python manually
• Flow execution & validation: Assistant runs and validates Flows directly
• Non-developers welcome: Implement custom logic without coding experience
• Streaming chat: Real-time progress via /assist/stream API

MCP-Based Interoperability

All Langflow Flows are automatically exposed as MCP Tools. External AI agents and IDEs can discover and invoke Flows directly.

• Flows auto-published as MCP servers
• External agents can execute Flows without the Visual Builder

Other Key Improvements

• Deployment Stepper UI: New guided deployment page
• Global Model Settings (1.8): Configure API keys once, share across all Flows
• Traces (1.8): Step-by-step Flow execution debugging
• OpenAI Responses API (1.6): /responses endpoint support

11. Langflow 1.9 主要新功能

2026年初发布的 Langflow 1.9 大幅提升了 AI Agent 开发体验。

Langflow Assistant（AI 助手）

内置于 Langflow UI 中的 AI 助手。用自然语言描述需求，Assistant 自动生成自定义组件代码。

• 自然语言 → 自动生成组件：无需手动编写 Python
• Flow 执行与验证：Assistant 直接运行和验证 Flow
• 流式对话：通过 /assist/stream API 实时查看进度

基于 MCP 的互操作性

所有 Langflow Flow 自动暴露为 MCP 工具。外部 AI Agent 和 IDE 可直接发现和调用 Flow。

其他关键改进

• 部署引导 UI：新的分步部署页面
• 全局模型设置 (1.8)：API 密钥一次配置，所有 Flow 共享
• Traces (1.8)：逐步追踪 Flow 执行过程
• OpenAI Responses API (1.6)：/responses 端点支持

11. Langflow 1.9 主要新機能

2026年初頭にリリースされたLangflow 1.9は、AIエージェント開発体験を大幅に向上させます。

Langflow Assistant（AIコパイロット）

Langflow UIに内蔵されたAIアシスタント。自然言語で説明するだけで、カスタムコンポーネントのコードを自動生成します。

• 自然言語 → コンポーネント自動生成：Python手書き不要
• Flow実行・検証：Assistantが直接Flowを実行し検証
• ストリーミング：/assist/stream APIでリアルタイム進捗確認

MCPベースの相互運用性

すべてのLangflow Flowが自動的にMCPツールとして公開されます。外部AIエージェントやIDEから直接発見・呼び出し可能です。

その他の主要改善

• デプロイステッパーUI：新しいガイド付きデプロイページ
• グローバルモデル設定 (1.8)：APIキーを一度設定、全Flowで共有
• Traces (1.8)：Flow実行のステップごとのデバッグ
• OpenAI Responses API (1.6)：/responsesエンドポイントサポート

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

12. 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.

12. 哈尼斯工程（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 才是团队的差异化资产。

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

「ボトルネックはモデルではなく環境にある」 — ハーネスエンジニアリングは、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 저장소 — 소스 코드, 이슈, 릴리스 노트

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) — Qwen 3.5 시리즈, 다국어/멀티모달
• GLM (Zhipu AI) — GLM-5 시리즈, MoE 아키텍처
• Kimi (Moonshot AI) — Kimi K2.5 시리즈, 긴 컨텍스트
• 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

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) — Qwen 3.5 series, multilingual/multimodal
• GLM (Zhipu AI) — GLM-5 series, MoE architecture
• Kimi (Moonshot AI) — Kimi K2.5 series, long context
• 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、发布说明

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（阿里巴巴） — Qwen 3.5 系列
• GLM（智谱 AI） — GLM-5 系列
• Kimi（月之暗面） — Kimi K2.5 系列
• Llama（Meta） — Llama 4 系列

本指南

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

参考資料

公式ドキュメント

• Langflow 公式ドキュメント — コンポーネント、API、インストールガイド
• Langflow GitHub リポジトリ — ソースコード、Issues、リリースノート

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） — Qwen 3.5 シリーズ
• GLM（Zhipu AI） — GLM-5 シリーズ
• Kimi（Moonshot AI） — Kimi K2.5 シリーズ
• Llama（Meta） — Llama 4 シリーズ

本ガイド

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