pipelex
用 .mthds 声明式文件定义 AI 方法，支持跨 60+ 模型的管道编排和可复用工作流
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
用 .mthds 声明式文件定义 AI 方法，支持跨 60+ 模型的管道编排和可复用工作流
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
当你在 2025 年需要搭建一个 AI pipeline 时，传统方案是写几百行 Python 代码，手动管理模型调用、错误重试、输出解析和结果组合——每一行都是技术债。而 Pipelex 换了一种思路：用声明式的 .mthds 文件描述 AI 方法，用 Pipelex 执行器运行它们。就像 Terraform 用 HCL 管理基础设施一样，Pipelex 用 TOML-like 语法管理 AI 工作流，让非 AI 专业开发者也能快速构建和复用复杂的 AI 流程。
AI 应用开发的现状是：每个团队、每个项目都在重复发明轮子。同样的"从 PDF 提取文本 → 总结要点 → 按受众生成摘要"流程，团队 A 可能用 LangChain 实现，团队 B 用 LlamaIndex，团队 C 直接调 API——代码无法复用，知识无法积累。
Pipelex 的核心团队（Evotis S.A.S.）在 2025 年 5 月发起了 MTHDS 开放标准，试图为 AI 方法（Method）建立一套统一的描述规范：用什么模型、输入什么类型、输出什么结构、Prompt 怎么写——全部写在 .mthds 文件里，像配置文件一样可分享、可版本化、可组合。任何兼容 MTHDS 的运行时（如 Pipelex）都可以执行这些方法，打破了工具和框架之间的壁垒。
截至 2026 年初，MTHDS 生态已包含：官方 Pipelex 执行器（Python）、TypeScript/JavaScript SDK（npm: mthds）、VS Code 语法高亮插件、面向 Claude Code 和 Codex 的插件（/mthds-build、/mthds-run 等命令）、在线 Hub（mthds.sh）供社区分享方法包。
MTHDS 的基本单元是 Method（方法），在 .mthds 文件中声明。一个方法的定义非常简洁：
[pipe.summarize_article]
type = "PipeLLM"
inputs = { article = "Text", audience = "Text" }
output = "Text"
prompt = "Summarize $article in three bullet points for $audience."
这定义了一个 LLM 调用方法：输入两个 Text，输出一个 Text，Prompt 中用 $变量名 引用输入。Pipelex 会自动处理类型校验、结构化输出（通过 instructor 库）和跨 60+ 模型的路由。
Pipe 的类型体系是理解 Pipelex 的关键：
-> 语法）**Concept（概念）**是 MTHDS 的类型系统。相比传统的字符串/Pydantic class，MTHDS 用语义描述数据："这是 Document 类型"、"这是 CandidateMatch 类型"，AI 模型理解输入输出的含义，而不是机械地匹配字段名。这让方法复用成为可能——只要输入输出的 concept 兼容，就可以跨项目组合使用。
Pipelex 的 Python 执行器（v0.34.0）是一个精心设计的模块化系统，核心依赖包括：
| 依赖 | 作用 |
|---|---|
instructor>=1.13 | 结构化 LLM 输出解析 |
openai>=2.0.0 | OpenAI 兼容 API 客户端（也是其他模型的统一接口） |
pydantic>=2.10 | 数据模型验证 |
networkx>=3.4 | DAG 图构建（Pipe 依赖关系分析） |
mthds>=0.4 | MTHDS 标准解析和包管理 |
rich>=13.8 | CLI 终端输出美化 |
typer>=0.16 | CLI 框架 |
opentelemetry-* | 链路追踪和可观测性 |
portkey-ai | 多模型网关路由 |
langfuse | ML 可观测性和评估 |
源码结构反映了清晰的分层设计：
pipelex/pipe_controllers/ — 7 种 Pipe 类型的控制器实现（LLM/Extract/Sequence/Batch/Parallel/Condition/SubPipe），每个控制器实现统一的 PipeControllerProtocolpipelex/core/ — 核心运行时：interpreter（解析执行）、registry（方法注册）、bundles（包管理）、concepts（类型系统）、stuffs（数据值对象）、validation（校验）pipelex/graph/ — DAG 可视化，支持 Mermaid 和 ReactFlow 两种格式输出pipelex/pipe_run/ — Pipeline 的实际执行引擎执行流程简述：.mthds 文件 → MTHDSBundleParser 解析 → Interpreter 构建 DAG → GraphTracer 拓扑排序 → 按依赖顺序执行各 PipeController → 结果通过 Stuff 对象在 Pipe 间传递 → 最终输出。
代码质量方面，项目要求：keyword-only 参数（def foo(self, *, arg) 强制所有非 subject 参数为 keyword-only）、完整类型注解（pyright/mypy 严格检查）、Ruff 代码格式化和未使用 import 检查、plxt TOML/MTHDS/PLX 文件格式检查。CLAUDE.md 中明确要求每次代码修改后必须运行 make agent-check，质量门槛较高。
Pipelex 支持多种安装和运行方式：
方式一：AI 编码工具集成（推荐新手）
Claude Code 用户粘贴一行命令即可安装 MTHDS 插件，获得 /mthds-build、/mthds-run 等交互式命令，边对话边构建 AI 方法。Codex 用户同理。
方式二：独立 CLI
uv tool install pipelex
pipelex init
pipelex doctor # 验证安装
方式三：Python SDK
from pipelex.pipelex import Pipelex
from pipelex.pipeline.runner import PipelexRunner
runner = PipelexRunner()
response = await runner.execute_pipeline(
pipe_code="my_method",
inputs={...}
)
配置 AI 访问有三种路径：
README 中附带了一个完整的生产级示例：CV 批量筛选系统，包含 PDF 解析、简历提取、职位需求分析、候选人匹配评分，展示了 Sequence + Batch + SubPipe 的组合用法。
Pipelex 作为一个新生代项目，仍面临一些挑战：
1. 依赖 Python 生态：Python 3.10+ 是硬性要求，在非 Python 环境中（如纯移动端或边缘计算场景）无法直接使用。虽然提供了 TypeScript SDK 和 REST API，但运行时核心仍是 Python。
2. 无容器化支持：项目中没有 Dockerfile、docker-compose 或 Kubernetes manifest，对于需要在 Docker/K8s 环境中部署的企业用户来说，缺少开箱即用的容器化方案。
3. MTHDS 生态仍处于早期：Hub 上方法包的数量和质量还在增长中，开放标准的社区接受度需要时间验证——这与当年 JSON Schema 和 OpenAPI 的推广轨迹类似。
4. 学习曲线：理解 Concept 类型系统、MTHDS 包依赖和多种 Pipe 类型的组合，需要一定的学习成本。项目文档虽然详尽，但对于只想"快速调一个 LLM API"的用户来说可能显得过于复杂。
5. 与 Mistral Workflows 的边界：文档提到未来会推出 Mistral Workflows 专用编排包，这意味着 Pipelex 的定位可能逐渐分化为"通用 MTHDS 执行器"和"Mistral 平台专用包"两条路径。
Pipelex 的出现代表了 AI 应用开发领域的一个趋势：从代码驱动到声明式配置驱动。当 AI 模型调用本身变得足够标准化（OpenAI API 兼容），如何高效编排这些调用就成了新的痛点。LangChain、LlamaIndex 选择了 Python 代码优先；Pipelex 选择了配置文件优先，两条路各有优劣。
截至 2026 年 6 月，Pipelex 仓库已有 682 stars、56 forks，上线约 13 个月。作为一个垂直于 AI 方法声明式编排的细分工具，这个增长速度值得关注。它的生态布局（Claude Code 插件、Codex 集成、TypeScript SDK、VS Code 扩展、在线 Hub）显示出清晰的开发者工具定位，而非单纯的技术库。
如果你需要：
Pipelex 是一个值得关注的选项。它的 MTHDS 标准能否像 OpenAPI 那样成为行业共识，还需要看社区的参与度和生态的持续建设。