Fivetran CLI：为AI Agent打造的数据管道组合工作流

用户喜爱 Fivetran，因为它让可靠的数据移动变得简单。选择一个数据源，完成身份验证，选择你的表，数据就开始落地。它就是能用，没有不必要的复杂性。

Fivetran CLI 将这种简单性带到终端。它为工程师提供基于文本的界面，让他们在已经工作的环境中管理 Fivetran。从一条命令行，他们可以创建和更新连接、配置 schema、触发同步、管理账户资源，以及构建、测试和部署自定义连接器。由于这些命令可以接受结构化配置并返回机器可读的输出，它们也可以成为详细、可重复工作流的构建块。

这使得 CLI 成为 AI 代理的自然接口。将其与编码工具（如 Claude Code、Codex、Gemini CLI 或dbt Wizard）配合使用，人们就可以用自然语言操作 Fivetran。他们用文字描述结果和方法，工具将该请求转换为完成任务所需的命令。

MCP 服务器为代理提供标准化接口，以访问该服务器暴露的上下文和工具。CLI 为代理提供对受支持终端命令的直接访问，使其特别适用于细粒度的可脚本化工作流。团队不必二选一，而是可以使用 MCP 提供上下文，使用 CLI 执行操作。

这很重要，因为数据工作的完成方式正在改变。AI 代理已经在从终端读取 dbt 项目、编写数据模型、运行验证测试并帮助修复故障。重复的身份验证循环、UI 导航以及人员、代理和代码之间的交接会中断这一流程并拖慢迭代。

我们希望保留 Fivetran 对人类而言的简单性，同时使其能力对代理兼容、可扩展且可发现。这就是Fivetran CLI所提供的。

[CTA_MODULE]

可组合性

经过时间考验的 Unix 哲学仍然成立：创建独立的工具，让它们做好一项工作，使用纯文本交流，并把组合交给 shell。新变化在于坐在 shell 前的是谁。人类非常擅长组合 CLI，而代理非常擅长利用为人构建的工具。在 CLI 中，人们在 shell 脚本或终端会话中组合专注的命令。--help标志是自文档化的。退出代码就是裁决。stdout 上的 JSON 是下一步可以消费的结构化数据。同样的特性对编码代理变得有用：检查可用命令、传递结构化输入，并检查操作是否成功。

Fivetran CLI 为数据移动层提供了与 dbt 多年来相同的终端原生界面。这种熟悉感简化了你的工具的心智模型和操作模型，因此数据模型可以照常设计和测试，但现在还增加了新能力：为模型提供数据的数据源也可以被立起来。

三部分，一个循环：

• Fivetran CLI移动数据：创建连接、塑造 schema、触发同步、部署自定义连接器。
• dbt v2转换数据：从同一个终端构建、测试并针对生产进行延迟（defer）。
• dbt Wizard（或任何编码工具）驱动工作：Wizard 是已经理解 dbt 项目（血缘、契约、测试）的工具。像 Claude Code、Codex 或 Gemini CLI 这样的通用工具为你提供跨越整个技术栈的单一代理。无论哪种方式，工具都是整合这些工具的组件。

在此设置中，CLI 和 dbt 执行管道工作；工具进行协调，因为它是将一切绑定在一起的粘合剂。它调用每个工具，读取返回内容，并决定下一步做什么。Fivetran CLI 和 dbt 不依赖于驱动它们的工具，并且相同的命令暴露给所有工具。

CLI 是工具行动的方式。MCP 服务器是它知道该做什么以及刚刚发生了什么的方式。有两类对管道工作很重要：

• 项目和任务跟踪（Jira、Linear、Asana、GitHub Issues）。对新数据源、新表或变更指标的请求通常从工单开始。连接跟踪器后，工具读取工单，使用 Fivetran CLI 和 dbt 构建变更，链接 PR，并将状态回帖。提出请求的人永远不必将需求转换为管道指令，也没有人需要将工单重新输入到提示中。
• 运营信号
• （同步状态、失败作业、警报、日志）。Fivetran CLI 设置管道：fivetran beta webhook create-group 推送同步事件，fivetran beta log-service account create将日志路由到你的可观测性栈。该栈（Datadog、Grafana、PagerDuty 或你运行的其他任何东西）的 MCP 服务器让工具读取它们。当同步失败或上游 schema 发生变化时，工具会看到它，使用 fivetran beta connection get 拉取连接，读取错误，并提出修复建议。失败成为下一次迭代，而不是 Slack 线程。

放在一起，循环自行闭合——工单进来，工具构建，同步运行，故障浮现，工具修复它，工单移至完成。你在每一步审查差异。上下文切换消失了。

上下文从顶部进入（你的优先级、工单、故障），工具做出决定，CLI 在下面完成工作。工具返回的一切都会供给下一个决定。

工具包

代理依赖三类工具：运行循环的工具、它用来行动的命令行界面，以及它从中读取上下文的 MCP 服务器。所有内容都可以通过 pip 安装或在几分钟内连接。创建 API 密钥后，无需浏览器。

‍

‍

每个工具都暴露具名操作，接收普通输入（标志、JSON 文件），返回结构化输出，并在失败时明确报错。这就是执行环境所需的全部契约。Fivetran CLI 还增加了 REST API 无法提供的一项功能——它 发现自己的接口表面 通过 --help 实现，因此执行环境永远不必在任务中途阅读端点文档。MCP 服务器在上下文方面做同样的工作，提供执行环境可以发现和调用的具名工具，而不是跟踪器的截图或粘贴的堆栈跟踪。

有一个值得指出的细节：安装 fivetran-cli 也会安装 Connector SDK，因此 fivetran init、fivetran debug 和 fivetran deploy 与资源管理共享同一个可执行文件。没有预构建连接器的源是一条绕路，而不是死胡同。由于 Connector SDK 也可用，按需构建新自定义连接器的能力也同样存在。

演练：在一次会话中从工单到收入模型

假设我们想把 Stripe 数据落地到 Snowflake，并发布一个 fct_mrr 模型。我们将使用一个通用执行环境，连接 Fivetran CLI、dbt v2 和通过 MCP 连接的任务跟踪器。提示词是你输入的内容，命令是执行环境运行的内容。

你： 接起 DATA-412。

执行环境通过跟踪器 MCP 读取工单。财务部门希望按客户、按月统计 MRR，源为 Stripe，目标为生产 Snowflake 仓库。它复述计划并请求继续。即使问题没有被清晰记录，你的代理很可能具备记录内部数据管理方式的技能，并能填补必要的利益相关者信息缺口。

你： 继续。找到目标，弄清 Stripe 需要什么，并起草连接配置。

注意它如何返回 Stripe 所需的配置字段，这样执行环境就能基于实时元数据构建正确的负载，而不是猜测。它写入 connections/stripe.json 并向你展示该文件。

你： 看起来正确。创建它并运行设置测试。

创建调用返回 JSON，同时执行环境将新的连接 ID 提取到 $CONN 并向前传递。测试退出代码为 0 表示凭据和网络路径工作正常。非零表示执行环境读取错误（保留 API 请求 ID）并告诉你需要修复什么。

你： 我们只需要 charges、customers、invoices 和 subscriptions。缩小架构范围并启动第一次同步。

两个配置文件现在都在你的仓库中。这就是你的审查界面和回滚方式。

你： 在它落地期间，向 dbt 项目添加一个 Stripe 源，并按客户 × 月粒度构建 fct_mrr。在宣称完成之前验证它。

接下来，Wizard 索引整个项目（模型、DAG、契约、测试、语义定义）。它找到现有的收入模型，检查已有消费方，写入源和模型，然后生成一个验证步骤，针对你的开发架构运行 dbt build --select +fct_mrr，在报告结果之前检查粒度和扇出。通用执行环境通过 dbt v2 CLI 和用于血缘的 dbt MCP 服务器也能达到同样效果；Wizard 只是到达时已经加载了这些上下文。

你： 打开 PR 并更新工单。

执行环境推送分支，打开包含配置文件和模型的 PR，通过跟踪器 MCP 在 DATA-412 上发布摘要评论，并将其移至 In Review。提交工单的人在他们提交的地方看到进展。

迭代循环：低成本地改变主意

管道需求会变化，当凭据过期或源架构变化时同步可能失败。团队需要一种方式来更新管道并调查失败，而不必手动重复每个设置步骤。能够更快地迭代和从失败中恢复，意味着能够管理更大的平台复杂性。

触发一：需求变化。 DATA-412 上出现一条评论。

你： 财务希望 MRR 在行项目级别，而不是发票级别。引入 invoice_line_item，重做模型，并在更改任何内容之前查看下游会有什么影响。

执行环境处理两个方面。在数据移动方面：

在转换方面，影响分析优先。执行环境沿着从 fct_mrr 到每个下游消费方的 DAG 遍历，并报告影响范围：哪些模型、哪些暴露、哪些测试。然后它进行重构，并且由于 dbt v2 配合 dbt State 只重建已更改的内容，重新运行很快：

触发二：管道报错。两天后，Stripe 同步在一夜之间失败。警报通过运维 MCP 到达执行环境，而不是等待有人注意到仪表板。

执行环境读取状态块，找到失败原因，并提出修复方案：在轮换凭据后重新运行设置测试，在上游变更后重新加载架构，或重新同步某个历史记录看起来有问题的表。它将发现的内容发布在工单上，使记录集中在一处。你批准后，它运行命令，下一次同步就干净了。

在这个循环中经常出现的几条单行命令：

• 不应该离开源端的列：fivetran beta connection-schema column update --connection-id $CONN --schema-name stripe --table-name customer --column-name email --config '{"enabled": false}'
• 历史记录看起来有问题的表：fivetran beta connection-schema resync-table --connection-id $CONN --config-file resync/stripe-charge.json（具有破坏性，因此 CLI 在运行前会询问）
• 没有预构建连接器的源：fivetran init，用 fivetran debug 针对本地 DuckDB 输出进行迭代，然后 fivetran deploy。同一个可执行文件，同一个会话。

其中每一项都会生成 harness 可以读取的 JSON，以及一个你可以提交的文件。审查变更就是审查一个 diff，而不是重放某人的点击操作。

开始使用

两次安装和一个环境变量：

然后选择你的 harness。如果你使用 dbt，请在项目目录中运行 dbt-wizard。如果你希望在整个技术栈中使用一个 agent，请在那里打开 Claude Code、Codex 或 Gemini CLI。连接你的事务跟踪器的 MCP 服务器，如果你有 observability 栈，也连接它的。每个厂商都记录了只需一行的设置方法。

然后交给 harness 一张跨越数据移动与转换之间界限的工单。当它第一次自行运行 fivetran beta connection-schema get、而你无需从浏览器粘贴任何内容时，这个循环的形态就一下子清晰了。

资源管理命令目前处于 beta 阶段，我们正在积极根据人们（以及 harness）的实际使用方式来塑造它们。如果某个工作流感觉不顺手，或者你期望的命令不存在，请告诉我们。完整的命令参考见 Fivetran CLI 文档，而 发行说明会跟踪最新变化。

[CTA_MODULE]