MCP开发-09.实战-配置化Pipeline的MCP改造与扩容

发表于 | 分类于
在 Argo 流程已部署并完成独立测试的前提下，记录如何用统一 MCP 包装调度能力，并通过 pipelines.yaml / auth.yaml 实现多业务域自动化扩容。

作为生信人员，每天总归跳不过的一个工作就是跑一些分析流程，而平时跑个任务，要登陆服务器，查看流程的输入接口，准备运行配置参数，总归还是要花些时间的。而最主要的问题是其中Linux操作会对于让很多非生信人员望而却步，导致这些工作都是生信分析的同学进行处理，研发阶段的参数我自己有时候都记不住🤷。

项目已经开源，如果大家需要可以自取：https://github.com/AI-skill-mcp/mcp_argo_pipeline

1. 确定方案「一份代码 + 两份 YAML」

起始考虑到正常的研发、测试过程，流程起始会经常会遇到横向的扩展和纵向的迭代，而且基于argo本身的特征管理，我自己的习惯，会进行一些子模块的模板注册。所以其实即使只有几个项目，模板也会非常多。比如我自己最近测试开发的一些工作就很多。
1785288352435

这个情况下，每个模板创建一个MCP显然不太现实，后期单独维护也维护不过来。而且MCP注册的一多就会出现几个问题：

  • Tool 语义几乎相同（列模板 / 查参数 / 提交 / 等结果），却重复维护；
  • 新域上线要改代码、改入口、改 Host 配置；
  • 远程鉴权、端口、kubeconfig 散落在环境变量与脚本里，难审计，随着独立MCP增加，管理复杂性让人绝望。

所以考虑构建的，其实更像是一个argo MCP 的框架：

层 职责
统一框架 所有MCP共享一个相同的顶层构建代码 server.py
调度内核 通用 Tool：通用的argo接口调度工具
流程配置 pipelines.yaml（流程类、模板、端口、instructions、kubeconfig）
鉴权配置 auth.yaml（每域多 Bearer，带用户/单位备注）

MCP Host 经多 Pipeline MCP 调度已部署 Argo

2. 确定定位「中转服务」

首先我们肯定不会在这个服务部署服务器直接跑任务，毕竟部分高计算任务，甚至一些计算需要GPU资源，都是重计算任务，需要较大的资源。
所以任务依然都是通过argo CLI 调度；MCP更多的是一个中转服务，接受 Agent 的任务请求 ->然后向K8s服务器发送任务，定期查看任务进展并返回任务结果。

长任务仍在集群 Workflow 中执行。MCP 进程只做：

  • 解析配置与鉴权；
  • 调用本机 argo CLI（可按域注入 KUBECONFIG）；
  • 把结果以 Tool 返回值交给 Host。

3. 功能定位「有用封装」

因为顶层，我们共用同一套代码，所以我们需要进行代码功能的抽象，经过评估后，我们设计的具体tools 列表如下：

Tool 作用
list_allowed_templates 知道有哪些能用的模板
get_template_parameters 知道模板投递参数需要什么（Agent 可先查再提交）
submit_template 知道如何通过模板提交任务（可覆盖参数）
get_workflow_status / wait_workflow / get_workflow_logs 观测任务运行的状态、日志
list_recent_workflows 查看近期运行的任务

安全边界：submit_template / get_template_parameters 只接受 pipelines.yaml 白名单内的模板名；未列入的模板对 Agent 不可见、不可投从而来实现模板隔离。

4. 环境确认「兼容性」

4.1 通信和环境

兼容不同的部署形态本地开发测试为主，远程是后面给他同事业务应用为主。

  • 本地部署：本地开发部署MCP时，通过stdio来进行评估测试，本地起、本地用无需进行鉴权；
  • 远程部署：远程服务部署service采用streamable-http ，远程url访问，防止url泄漏，进行鉴权；
    ps 远程需要同时兼容mac和windows和linux。

4.2 启动校验

启动即校验可用性，避免「进程起来了但集群不可用」

  1. kubeconfig 可读，且能访问配置的 namespace；
  2. 白名单内每个模板能被 argo template get 读到。

MCP在启动时，本身不能发现配置的非格式问题（例如k8s.cfg 无权限），启动校验在启动阶段可以检查这些问题，（可设 MCP_SKIP_STARTUP_CHECKS=1 跳过）：。

5. 配置面：扩容时真正要改的东西

5.1 配置流程 pipelines.yaml：

核心字段：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
defaults:
  namespace: default
  host: "0.0.0.0"

pipelines:
  my-domain:                    # 模板组 → 环境变量 MCP_PIPELINE
    server_name: argo-my-domain # Host / MCP 面板显示名
    namespace: default
    kubeconfig: "~/.kube/config"  # 可按域指向不同集群
    port: 8104                    # 仅 HTTP 模式使用
    instructions: |
      给 Agent 的操作说明（入口模板、路径约定等）。
    templates:                    # 白名单 = 本域可自动化调度的能力面
      - my-job-a
      - my-job-b
  • 同一域加能力：在已有 templates 列表追加已验收的模板名，重启该 Pipeline 进程即可；
  • 新业务域：新增 pipelines.<id> 整块，分配端口与 instructions，再配鉴权并启动。

不必为新域再写一套 Python Tool。而且每个功能域的模板可以独立启动服务，防止agent应用阶段的过渡加载。

5.2 auth.yaml：按域发钥匙

1
2
3
4
5
6
7
8
9
10
11
pipelines:
  my-domain:
    tokens:
      - token: "replace-with-long-random1"
        username: "alice"
        unit: "x_group"
        scopes: ["run"]   # 可选，默认 run
      - token: "replace-with-long-random2"
        username: "bob"
        unit: "x_group"
        scopes: ["run"]   # 可选，默认 run
  • 一域多 token：便于人/组隔离与轮换；
  • username / unit 供审计备注（中间件验票后写入请求上下文）；
  • 从 auth.yaml.example 拷贝后编辑。
    从而可以实现精确的鉴权和定位，因为我自己目前使用的规模不会超过20人，所以token配置这么实现基本就满足需求。

5.3 客户端只改连接配置

HTTP 示例（项目 .cursor/mcp.json）：

1
2
3
4
5
6
7
8
9
10
{
  "mcpServers": {
    "argo-my-domain": {
      "url": "http://127.0.0.1:8104/mcp",
      "headers": {
        "Authorization": "Bearer replace-with-long-random1"
      }
    }
  }
}

stdio 则指向同一 server.py，用环境变量区分域：

1
2
3
4
5
{
  "command": ".../mcp_argo_pipeline/.venv/bin/python",
  "args": [".../mcp_argo_pipeline/server.py"],
  "env": { "MCP_PIPELINE": "my-domain" }
}

6 启动服务

参考上面的部分完成配置后，我们就可以启动MCP服务，给其他人调用了。

步骤 A — 写入 auth.yaml（若用 HTTP）

为该域至少配一把 token；Host 的 Bearer 必须与之一致。用于鉴权。

步骤 2 — 依赖与启动

环境依赖 uv进行管理，部署shell会自动同步uv环境的准备和服务的启动，不过你需要按需指定要启动的功能组。

1
2
3
4
5
6
cd mcp/mcp_argo_pipeline
cp pipelines.yaml.example pipelines.yaml   # 首次
cp auth.yaml.example auth.yaml
# 编辑上述 YAML 后：
./start_serve.sh my-domain          # 后台
# 或 ./start_serve.sh -f my-domain  # 前台单域

启动失败优先看：kubeconfig、模板名是否与集群一致、该域是否配置了 token。

7. Agent连通

Agent配置

在这里面我们用workbuddy进行连通性测试，先填写我们的MCP配置
workbuddy_cfg
然后启用链接，发现每个域都绿了，恭喜你，MCP服务启动成功，并且和agent已经打通了。

  • 或用协议正确的 initialize POST 冒烟（裸 GET /mcp 常返回 400 Missing session ID，属协议要求，不代表服务挂了；401 才是鉴权失败）。
    MCP 面板

运行一个任务

MCP配置以后，就和其他的MCP使用一样了，可以直接通过自然语言来触发任务
MCP 面板
然后过段时间就可以看到结果啦。
MCP 面板

ps：混元模型最近可以免费白嫖，所以这种测试现在都是在白嫖免费模型，大家有需要的也可以看看。

截止目前，我们的MCP已经构建完成，并且已经可以在Agent里面通过对话，启动任务运行了。接下来你只需要把配置模板准备好，告诉他们怎么配置，以后就可以让他们自己通过Agent的自然语言投递一些大计算的分析任务啦，而且他们自己就可以直接通过自然语言询问任务进度和状态。

-------------本文结束感谢您的阅读-------------