企业ai落地方案：给 AI 工作流一套声明式语言

当你还在为每个 AI 流程写 500 行 Python 脚本的时候，有人已经用一份 .mthds 文件替代了所有胶水代码。

一个经典困境

企业落地 AI 的姿势，这两年基本定型了两种：

路径一：写代码。 LangChain、LlamaIndex，Python 一把梭。架构师把 prompt 写在字符串里，业务人员在旁边完全看不懂。迭代一个流程要改代码、跑测试、走 CI/CD，最后发现改了三个字——「请总结为四点」变成「请总结为五点」。

路径二：拖拽。 n8n、Dify、FastGPT，可视化低代码。产品经理可以上手了，但复杂逻辑表达受限，调试信息不透明，一接入 CI/CD 就头大。

两边的共同问题是什么？AI 工作流的「做什么」和「怎么做」搅在了一起。 prompt 细节嵌在 Python 函数里，流程结构藏在拖拽节点的连线中，没人能一眼看懂这套流程到底在干什么。

Pipelex 就是冲着这个痛点来的。

Pipelex 到底是什么

Pipelex，全称 Pipelex，2025 年 10 月在 Hacker News 以 Show HN 亮相，当天拿了 122 分、27 条评论。它的定位很精准：「Declarative language for composable AI workflows」——为可组合的 AI 工作流提供一套声明式语言。

说白了，就是让你用一份声明式配置文件来描述整个 AI 工作流，而不是写 Python 脚本或者拖拽节点。

看一眼它官方的定义更直接：「Devtool for agents and mere humans」——既给 AI Agent 用，也给普通人用。

这背后的逻辑是：你描述一份 .mthds 文件，Pipelex 引擎负责执行。你想改流程？改配置文件就行。你想让 Claude Code 帮你生成流程？一句话的事。

声明式到底好在哪

如果你熟悉 Kubernetes 的 YAML、Terraform 的 HCL 或者 SQL 的 DDL，你就能立刻理解 Pipelex 的哲学——把「做什么」和「怎么做」分开描述。 用户只定义目标状态，引擎负责解释执行。

放到 AI 工作流场景下，声明式的好处至少有三层：

第一层：可读。 业务人员看得懂每个步骤在干什么，可以 review，可以参与迭代，不需要从零学 Python。

第二层：可测。 每个 Pipe 都有明确的输入类型和输出类型，语义标注清晰，单步测试成本极低。你不需要 mock 一整个 LangChain 调用链。

第三层：可复用。 一份 .mthds 文件是一个完整的 AI 方法包，可以在不同模型之间运行，可以在社区共享，可以嵌套调用。这和 Docker 镜像可移植性的逻辑一模一样——而 Pipelex 确实被 HN 评论区称为「AI 工作流领域的 Dockerfile + SQL」。

一份配置长什么样

直接上代码，比什么都清楚。下面是一个真实的 CV 批量筛选工作流：

toml

[pipe.batch_analyze_cvs_for_job_offer]
type = "PipeSequence"
description = """
根据职位要求，批量分析候选人的匹配度
"""
inputs = { cvs = "Document[]", job_offer_pdf = "Document" }
output = "CandidateMatch[]"
steps = [
  { pipe = "prepare_job_offer", result = "job_requirements" },
  { pipe = "process_cv", batch_over = "cvs", batch_as = "cv_pdf", result = "match_analyses" },
]

[pipe.prepare_job_offer]
type = "PipeSequence"
inputs = { job_offer_pdf = "Document" }
output = "JobRequirements"
steps = [
  { pipe = "extract_one_job_offer", result = "job_offer_pages" },
  { pipe = "analyze_job_requirements", result = "job_requirements" },
]

[pipe.analyze_job_requirements]
type = "PipeLLM"
inputs = { job_offer_pages = "Page" }
output = "JobRequirements"
model = "$writing-factual"
prompt = "分析以下职位要求 @job_offer_pages"

不需要写一行 Python。流程结构、输入输出类型、步骤编排、模型选择，全部在 .mthds 文件中声明。你想给 100 份简历跑分析？改 inputs.json 就行，代码一行不动。

核心能力拆解

Pipelex 的能力可以分为四个层面：

一、类型系统。 这是 Pipelex 区别于所有「prompt 工程工具」的核心差异。它提供了一套语义类型系统——Text、Number、Document、Image、Page，以及自定义的 Concept（概念）。你定义的每个结构化类型都带有描述，这意味着 AI 理解你的意图，而不是只看到字符串。 输入输出之间有语义连接，不是凭空对接。

二、管道编排。 支持 PipeLLM（LLM 调用）、PipeSequence（顺序执行）、PipeExtract（文档解析），以及即将上线的并行执行和条件分支。尤其 batch_over 语法可以直接对数组做批量处理——一份简历是处理，一百份简历也是同一套逻辑，自动扇出扇入。

三、多模型路由。 支持 60+ 模型，涵盖 OpenAI、Anthropic、Google Gemini、Mistral，以及本地的 Ollama、vLLM。你甚至可以用 Pipelex 自己的 Gateway 获得免费额度，一个 API 密钥同时搞定 LLM 调用、OCR 文档提取和图片生成。

四、Run Anywhere。 一次定义，到处执行：CLI 命令跑、Python SDK 调、Node.js 调、REST API 调、MCP 协议让 Agent 调、n8n 工作流里当节点用。这个覆盖面相当可以了。

再加上 VS Code 扩展（语法高亮 + 流程图可视化）、MTHDS Hub（社区共享方法库）、Claude Code 插件（一句话 /mthds-build 自动生成工作流定义），整个生态虽然还在早期，但骨架已经搭得很完整。

和 BAML 怎么比

这是一定会被问到的问题。BAML 是另一个声名在外的声明式 AI 工具，许多开发者会自然地把两者放在一起对比。Pipelex 的官方的回应很坦诚：

BAML 定位是类型化单 LLM 调用函数定义工具——你定义 prompt 函数、编译生成 SDK，然后在自己的应用代码里调用。多步骤编排、非 LLM 操作（比如 PDF 解析、图片生成）需要你在应用层自己实现。

Pipelex 定位是完整的 AI 工作流编排引擎——LLM 调用、文档提取、OCR、图像生成、条件分支、并行执行，所有操作在 .mthds 文件里都是原生一等公民。你不需要额外写任何胶水代码。

结论很简单：如果你只需要可靠的带类型约束的 LLM 调用，选 BAML。如果你要编排端到端的多步骤 AI 流程，选 Pipelex。 两者不冲突，甚至可能互补。

局限与野心

Pipelex 不是完美方案，它的作者在 HN 评论区坦率列出了当前不足：

• 暂不支持结果缓存，推理模式不能自定义
• 没有断点续跑能力，流程失败需要全量重来
• 连接器生态薄弱，暂不支持直接对接第三方业务系统
• 成本统计只覆盖 LLM 调用，图片生成和 OCR 不在统计范围内
• 没有官方托管 API，需要用户自行部署

但这些恰恰暴露了团队的路线图野心：集成 Temporal.io 做持久化工作流引擎，支持多节点横向扩展和断点续跑；开发 MCP 客户端能力，让 Pipelex 流程能调用任意 MCP 工具；推出大文档分层处理（Pyramid RAG）方案；官方托管 API 已在开发中。

最后一个问题：谁需要 Pipelex

回到开头那个困境。如果你是一个 AI 工程师，每天在 LangChain 里和 prompt 字符串搏斗，Pipelex 可能让你从「胶水代码」中解放出来。如果你是一个技术产品经理，想设计 AI 流程但不想依赖开发排期，Pipelex 的 .mthds 文件可能让你第一次真正「上手」AI 工作流。

HN 上有一条评论很精准：「声明式工作流是个好主意，而且我喜欢这个 AI-first 的设计原则——pipeline 的创建和编辑本身也可以用 AI 完成。」

用 Pipelex 自己的话说：这套语言既给 Agent，也给凡人。

这或许就是 AI 工作流基础设施的下一站——不是让开发者写更聪明的胶水代码，而是让胶水代码本身消失。

参考来源：Pipelex GitHub | Hacker News 讨论