Langflow

Langflow 是以 Python 为基础的可视化 AI 应用框架，用组件与连线组织模型、提示词、数据、Agent 和工具。它适合需要把 AI 原型继续接入程序的开发者：先在画布上观察数据怎样流动，再通过 API 或 MCP 提供能力，也可以用 Python 编写自定义组件。可视化降低了组合现有模块的成本，但模型配置、工具权限和服务部署仍然需要明确处理。

用 Simple Agent 看清一次工具调用

官方快速入门从 New Flow 中选择 Simple Agent 模板开始。它包含 Chat Input、Agent 和 Chat Output，并把 Calculator、URL 等组件作为工具接给 Agent。主线负责收消息和回消息，工具分支提供额外动作；画布上连了一个工具，不代表每轮对话都会执行它。

先把模型接通，再检查连线承担什么

按当前文档，可以在个人设置的 Model Providers 中配置提供商 API Key、启用模型，再回到 Agent 选择 Language Model。模型凭据用于请求模型服务，不是让外部程序访问 Langflow 的通行证。若模型节点本身无法运行，应先处理连接和账号条件，而不是反复调整下游输出组件。

Chat Input 把用户消息送入流程，Agent 根据消息和工具说明决定如何处理，Chat Output 则提供最终聊天输出。将组件拆开观察，可以判断错误发生在输入、模型调用还是工具执行阶段。单独组件能运行，只说明这一环节的条件成立，仍需回到整条 Flow 检查组合结果。

“回答了 8”不等于证明计算器被调用

官方示例在 Playground 中询问“4+4”，并检查 Calculator 的 evaluate_expression 工具调用及返回结果。这个小例子的意义是查看执行轨迹：模型自己也可能知道答案，所以只看到“8”不能证明工具连接成功。

沿消息中的调用记录查看工具名称、传入表达式和输出，再对照最终回复，才能确认这条工具路径是否真正参与。若 Agent 没有调用，需结合工具描述和任务需求分析，不宜仅凭答案正确就跳过检查。这是官方文档中的验证方式，本页没有连接模型或产生实际调用费用。

同样的思路可以用于网页工具：先限定目标页面和需要提取的信息，检查返回内容再看摘要。对于会写入数据或发送消息的工具，测试范围还要与实际权限对应，不能把只读演示直接扩大成可任意执行的助手。

从现成组件走到自己的 Python 处理逻辑

Langflow 提供模型、数据加载、向量存储、检索、提示词和工具等组件类别，便于搭建 RAG 或多步骤处理。知识库应用通常需要把材料加载、切分、索引与检索连接起来，再将检索内容交给模型；把向量库接上并不等于文档已经完成入库，入库流程与问答流程仍应分别检查。

组件的输入输出约定是连线的基础。上一步返回的内容能否被下一步使用，要看端口要求和实际数据，而不只是两个方块是否放在相邻位置。遇到空结果时，可先单独运行数据处理环节，确认文件被读取、字段存在，再继续查模型提示词。

内置模块不够时，可以编写继承 Component 的 Python 类，声明输入、输出以及处理方法。官方自定义组件文档以 DataFrameProcessor 展示过滤、排序和聚合等处理：适合把稳定的数据逻辑封装成画布中的一个节点，而不是把长脚本塞进提示词要求模型模拟执行。

这也意味着扩展能力依赖真实运行环境。组件使用的 Python 依赖、文件路径和外部服务需要在部署环境中可用；本机装有某个库，并不保证服务器也有。自定义组件会执行代码，应按软件依赖管理和代码审阅处理，不能因它显示为一个可拖拽方块，就忽略其访问能力。

Flow 做好以后，API 与 MCP 怎样交付

API 请求要区分两套密钥和真正的服务器地址

完成流程后，可从 Share 的 API access 获取调用示例。官方示例使用 POST /api/v1/run/FLOW_ID，请求体包含 input_value、input_type、output_type 等字段，并用 x-api-key 传入 Langflow API Key。这里的 Key 负责访问流程服务，不能拿模型提供商的 Key 来替代。

生成示例中的地址和 Flow ID 需要对应实际环境。默认本机地址只能在相应网络条件下访问，将 localhost 复制到远程网站并不会自动变成线上服务。应用密钥也不应直接写进公开前端代码；需要考虑由受控后端调用、访问范围和请求成本。

接入时先检查响应结构，明确应用需要的是最终文字还是其他流程结果，再处理错误和等待状态。Playground 中的一次成功对话是原型证据，不是 API 在所有输入下都稳定工作的证明。

MCP 暴露的是工具，名称和描述会影响选择

官方 MCP Server 文档要求作为工具暴露的 Flow 包含 Chat Output。一个项目可以提供多个 Flow 工具，使用 Share 或项目中的 MCP Server 入口，再通过 Edit Tools 选择需要暴露的流程并设置名称、描述。这里是在给客户端提供可调用能力，与在流程里接入外部 MCP 服务方向相反。

如果两个流程分别处理不同产品资料，工具描述应写明资料范围和适合回答的问题，而不是都叫“智能问答”。否则客户端即使能发现两个工具，也未必知道该选哪个。对外提供服务时还需启用适当认证，避免把仅供本地试验的流程直接暴露给不受控的调用者。

桌面试验与持续运行的服务，承担不同责任

官方提供 Desktop、Python 包及 Docker 等安装部署路径。Desktop 面向本地使用，当前安装文档列出的部分能力与服务端部署存在差异，例如不支持 Shareable Playground 和 Voice Mode。需要多人访问或由应用持续调用时，应按服务部署需求选择，而不是只看哪个安装入口更快。

部署文档覆盖容器、服务器、代理与安全配置等主题。把 Flow 与依赖一起交付，确认模型连接、持久化数据和访问认证，再验证目标网络中的 API，是从画布原型走向服务的实际工作。升级后还应复查自定义组件及相关依赖，不能假定导入同一份流程文件就完全复现了原环境。

Langflow 的集成组件与 Python 扩展适合愿意控制数据流的开发者；如果主要需求是维护现成知识库和业务配置，也可以先阅读AI Agent 平台选型指南比较不同工具的侧重点。选择依据应是团队愿意承担哪些集成与运维工作，而不只是画布看起来是否直观。