Token导航 LogoToken导航

MCP Server · 开发工具

MCP Dev Pipline

一个由AI驱动的软件开发工作流,通过三个自治代理(产品经理、开发者和架构师)模拟真实开发团队,从自然语言需求到代码提交和审查的全流程自动化。

stdio官方级别未说明来源级核验工具 12
代码审查PythonAI代理

快速开始

作者 / 组织
VitalyTarasiu
提供方
VitalyTarasiu
运行时
Python

工具数量

12

来源目录标注

资源数量

0

来源目录标注

提示词数量

0

来源目录标注

GitHub Star

0

仓库热度

收录来源

1 个

MCP World

选型结论

MCP Dev Pipline 属于开发工具类 MCP Server,公开资料标注 12 个工具,通过stdio 本地进程接入,客户端适配情况以官方文档为准,有可以直接复制的安装命令;接入前要先准备 访问 Token。

分类

开发工具

传输方式

stdio

认证方式

访问 Token

部署方式

公开资料未说明

安装与配置

安装命令

python3 -m venv .venv

公开命令不是通用的启动方式,拼不出可靠配置示例;请在客户端 MCP 配置里按官方文档填写 command 和 args。

上手步骤

  1. 1

    准备运行环境

    stdio 服务在本地起进程,需要先装好 Python,再按安装命令拉取依赖。

  2. 2

    安装服务

    复制下面的安装命令执行;命令里带占位符的位置换成自己的密钥或路径。

  3. 3

    写入客户端配置

    在客户端的 MCP 配置里填启动命令和参数,保存后完全退出客户端再打开,让新配置生效。

  4. 4

    验证是否可用

    连接成功后客户端会列出 12 个工具,随便调一个只读工具确认能返回结果。

接入前确认

不要直接授予不必要的文件、网络或账号权限;先核对安装命令和配置内容。

详细介绍

多代理开发管道

基于AI构建的软件开发工作流程 微软AutoGen v0.4三个自主代理模拟了一个真实的开发团队: 产品经理 创建Jira任务,a 开发者 编写代码并打开PR,以及 建筑师 审查代码——所有这些都是由单一的自然语言需求驱动的。

______________________________________________________________________

代理

代理LLM模型角色工具
产品经理gpt-4o-mini将用户需求转化为结构化的Jira任务create_jira_issue
开发者gpt-4o-mini读取Jira票证,探索仓库,实现代码,创建PRget_jira_issue, get_repo_tree, get_file_content, create_branch, create_or_update_file, create_pull_request, add_jira_comment
建筑师gpt-4o审查PR差异,批准或请求更改get_pr_diff, get_pr_files, get_file_content, add_pr_review, approve_pull_request
开发人员(修复模式)gpt-4o-mini读取架构师的审查意见,将修复推送到同一分支get_pr_reviews, get_pr_review_comments, get_file_content, create_or_update_file

______________________________________________________________________

管道流量

                        ┌─────────────────────────┐
                        │   User types requirement │
                        │   in plain English       │
                        └────────────┬────────────┘
                                     │
                     ┌───────────────▼───────────────┐
                     │  Phase 1: Product Manager     │
                     │  ─────────────────────────    │
                     │  • Parses the requirement     │
                     │  • Creates Jira task           │
                     │  • Auto-assigns to user        │
                     │  Model: gpt-4o-mini            │
                     └───────────────┬───────────────┘
                                     │ Jira key (e.g. TUP-4609)
                     ┌───────────────▼───────────────┐
                     │  Phase 2: Developer            │
                     │  ─────────────────────────     │
                     │  • Reads Jira ticket           │
                     │  • Explores repository tree    │
                     │  • Reads source files           │
                     │  • Creates feature branch      │
                     │  • Commits code changes        │
                     │  • Creates Pull Request        │
                     │  • Comments PR link on Jira    │
                     │  Model: gpt-4o-mini             │
                     │  Context: independent          │
                     └───────────────┬───────────────┘
                                     │ PR number (e.g. #234)
                     ┌───────────────▼───────────────┐
              ┌─────►│  Phase 3a: Architect Review   │
              │      │  ─────────────────────────     │
              │      │  • Gets PR diff                │
              │      │  • Examines changed files      │
              │      │  • Checks correctness,         │
              │      │    completeness, quality,       │
              │      │    security, best practices     │
              │      │  • Submits review              │
              │      │  Model: gpt-4o                  │
              │      │  Context: independent          │
              │      └───────────┬────────┬──────────┘
              │                  │        │
              │            APPROVED   CHANGES_REQUESTED
              │                  │        │
              │                  │   ┌────▼────────────────────┐
              │                  │   │  Phase 3b: Developer Fix│
              │                  │   │  ───────────────────    │
              │                  │   │  • Reads review comments│
              │                  │   │  • Reads current code   │
              │                  │   │  • Pushes fixes         │
              │                  │   │  Model: gpt-4o-mini     │
              │                  │   │  Context: independent   │
              │                  │   └────────────┬───────────┘
              │                  │                │
              └──────────────────┘◄───────────────┘
              (max 3 review rounds)
                                     │
                     ┌───────────────▼───────────────┐
                     │  Pipeline Complete             │
                     │  PR is open — NOT merged       │
                     │  Manual merge required         │
                     └───────────────────────────────┘

______________________________________________________________________

AutoGen的使用方法——详细设计

架构:独立的单代理团队

此管道使用 AutoGen v0.4 (autogen-agentchat)经过深思熟虑的设计选择: 每个代理都在自己的独立团队中运行 而不是共享单个群聊。这给了每个代理一个完全独立的上下文——他们永远看不到彼此的内部推理。

# Each phase creates a FRESH agent + single-agent team
agent = AssistantAgent(
    name="developer",
    model_client=OpenAIChatCompletionClient(model="gpt-4o-mini", api_key=...),
    system_message=DEV_SYSTEM_MESSAGE,
    tools=[get_jira_issue, get_repo_tree, ...],
)
team = RoundRobinGroupChat(
    participants=[agent],
    termination_condition=TextMentionTermination("PHASE_COMPLETE") | MaxMessageTermination(60),
)
result = await Console(team.run_stream(task="Read Jira ticket TUP-123 and..."))
为什么选择单代理团队而不是共享群聊?
方法共享 SelectorGroupChat独立的单代理团队(我们使用什么)
上下文所有代理都能看到所有消息每个代理只能看到自己的任务
独立代理可能会受到彼此推理的影响真正的隔离——只能通过Jira/GitHub进行通信
每个代理的型号每个代理可以有不同的模型✓每个代理可以有不同的模型✓
多步骤工具调用由团队重新提示处理由 RoundRobinGroupChat 重新提示
审查循环需要复杂的选择器逻辑简单的Python for 循环
每轮新的上下文需要手动 on_reset()每轮创建一个新的代理实例

使用的关键AutoGen部件

1. AssistantAgent --每个代理都是 AssistantAgent 配置有:

  • A. 系统消息 (角色说明、工作流程步骤、规则)
  • A. 模型客户端 (OpenAIChatCompletionClient 包装OpenAI模型)
  • A. 工具列表 (LLM可以调用的Python函数)

这 AssistantAgent 在内部处理工具调用循环:它调用LLM,如果LLM请求工具调用,则执行LLM,反馈结果,并重复,直到LLM生成最终的文本响应。

2. RoundRobinGroupChat --将单个代理打包成一个“团队”,该团队:

  • 将任务发送给代理
  • 如果代理人回应但没有说 PHASE_COMPLETE,重新提示它继续
  • 这对于 gpt-4o-mini 有时在几个工具调用后停止,而不是完成所有步骤

3. TextMentionTermination --当代理的响应包含特定字符串时,停止团队:

  • 项目经理、开发人员: "PHASE_COMPLETE"
  • 建筑师: "APPROVED" 或 "CHANGES_REQUESTED"

4. MaxMessageTermination --防止无限循环的安全网(每相最多60条消息)。

5. Console --将所有代理事件(工具调用、结果、文本响应)实时流式传输到stdout,以便您可以查看管道的工作情况。

代理商如何沟通

代理 从不 查看彼此的消息。它们仅通过外部系统进行通信:

PM ──creates──► Jira Issue ◄──reads── Developer
                                          │
                                     creates PR
                                          │
Developer ──comments──► Jira      GitHub PR ◄──reviews── Architect
                                          │
                                    review comments
                                          │
Developer (fix) ──reads──► PR reviews ◄──writes── Architect

审查循环(Python编排)

审查循环是一个简单的Python for 循环--不是AutoGen编排:

for round_num in range(1, 4):  # max 3 rounds
    # Create FRESH architect (independent context)
    arch = AssistantAgent(name="architect", model_client=gpt4o, ...)
    arch_team = RoundRobinGroupChat([arch], ...)
    arch_result = await Console(arch_team.run_stream(task=f"Review PR #{pr}"))

    if "APPROVED" in arch_result:
        break  # Done!

    # Create FRESH developer (independent context)
    dev = AssistantAgent(name="developer", model_client=gpt4o_mini, ...)
    dev_team = RoundRobinGroupChat([dev], ...)
    await Console(dev_team.run_stream(task=f"Fix review comments on PR #{pr}"))

每次迭代都会创建 新代理实例 --这保证了架构师在每一轮都会重新审查PR,而不会记住之前的审查,开发人员在没有上下文的情况下阅读最新的审查评论。

自我批准解决方案

GitHub阻止批准您自己的PR(两个代理使用相同的令牌)。工具会自动回退:

APPROVE attempt → GitHub 422 error → fallback to COMMENT with "APPROVED" in body

管道检查 "APPROVED" 在文本中,这可以无缝地工作。

______________________________________________________________________

安装

# 1. Clone the repository
git clone https://github.com/VitalyTarasiu/MCP-dev-pipline.git
cd MCP-dev-pipline

# 2. Create virtual environment
python3 -m venv .venv
source .venv/bin/activate        # macOS / Linux
# .venv\Scripts\activate         # Windows

# 3. Install dependencies
pip install -r requirements.txt

依赖项

包装用途
autogen-agentchatAutoGen v0.4代理框架
autogen-ext[openai]AutoGen的OpenAI模型客户端
tiktokenOpenAI模型的令牌计数
atlassian-python-apiJira REST API客户端
PyGithubGitHub REST API客户端
python-dotenv负载 .env 配置

______________________________________________________________________

用法

python main.py

首次运行--交互式设置

首次运行时,CLI会提示进行Jira/GitHub配置 打开浏览器 对于缺少令牌时的SSO身份验证:

==========================================================
    Multi-Agent Development Pipeline
==========================================================

  Jira Configuration
  ----------------------------------------
  URL [https://think-up.atlassian.net]:
  User email [vitaly.tarasiuk@thinkup.global]:
  Project key [TUP]:

  Jira API token not found. Opening browser for token creation...
  1. Sign in with SSO if prompted
  2. Click 'Create API token'
  3. Name it (e.g. 'MCP Pipeline') and click Create
  4. Copy the token

  Press Enter to open the browser...
  Paste your Jira API token: ****

  GitHub Configuration
  ----------------------------------------
  Repo (owner/repo) [thinkup-global/api-controller]:
  Base branch [dev]:

  Found token from GitHub CLI (gh).       ← auto-detected

==========================================================

  Enter your requirement:
  > Add logging to the applyCoupon method for inactive promotion codes

==========================================================
  Jira     : https://think-up.atlassian.net (TUP)
  GitHub   : thinkup-global/api-controller (branch: dev)
  Assignee : vitaly.tarasiuk@thinkup.global
==========================================================

  Phase 1 -- Product Manager creating Jira task
  ...
  Phase 2 -- Developer implementing changes
  ...
  Phase 3.1a -- Architect reviewing PR #234
  ...
  ──────────────────────────────────────────────────────
  Architect Review (round 1):
  ──────────────────────────────────────────────────────
  The changes introduce proper logging for inactive promotion codes...
  - Correctness: Aligned with Jira task requirements ✓
  - Completeness: All existing code preserved ✓
  ...
  APPROVED
  ──────────────────────────────────────────────────────

  >>> PR #234 APPROVED by architect

==========================================================
  Pipeline Complete
  Jira : https://think-up.atlassian.net/browse/TUP-4609
  PR   : https://github.com/thinkup-global/api-controller/pull/234
  Status: PR is open -- NOT merged (manual merge required)
==========================================================

后续运行

所有凭据都保存到 .env (git忽略)。下一次运行时,您只需确认Jira项目、GitHub仓库,然后键入您的要求:

python main.py

身份验证流程

服务如何进行身份验证
Jira打开浏览器→ Atlassian SSO→ 创建API令牌→ 将其粘贴回去
GitHub自动检测 gh CLI令牌。如果未找到:打开浏览器→ GitHub SSO→ 您可以使用以下命令创建PAT repo 范围→ 粘贴它
开放人工智能打开浏览器→ OpenAI仪表板→ 复制API密钥→ 粘贴它

所有令牌都存储在 .env 并在未来的运行中重复使用。你可以自由切换Jira项目或GitHub仓库——这些代币在你的所有项目中都有效。

______________________________________________________________________

项目结构

MCP-dev-pipline/
├── main.py                  # Interactive CLI — prompts, browser auth, runs pipeline
├── config.py                # Reads .env into a Config dataclass
├── auth.py                  # Browser-based SSO helpers (legacy)
├── pipeline/
│   ├── __init__.py
│   └── dev_pipeline.py      # AutoGen agent orchestration + review loop
├── tools/
│   ├── __init__.py
│   ├── jira_tools.py        # create_jira_issue, get_jira_issue, add_jira_comment
│   └── github_tools.py      # branches, files, PRs, reviews, approve
├── requirements.txt
├── .env.example             # Template for environment variables
├── .env                     # Your credentials (git-ignored, auto-created)
├── .gitignore
└── README.md

______________________________________________________________________

配置

环境变量

变量描述默认值
OPENAI_API_KEY用于LLM调用的OpenAI API密钥*(必填)*
DEVELOPER_MODEL开发人员和项目经理代理模型gpt-4o-mini
ARCHITECT_MODEL建筑师代理模型gpt-4o
PM_MODELPM代理模型gpt-4o-mini
JIRA_URL您的Jira实例URL*(提示)*
JIRA_USER您的Jira电子邮件*(提示)*
JIRA_API_TOKENJira API代币*(浏览器SSO)*
JIRA_PROJECT_KEYJira项目密钥(例如。 TUP)*(提示)*
GITHUB_TOKENGitHub个人访问令牌*(自动/浏览器)*
GITHUB_REPO目标回购为 owner/repo*(提示)*
BASE_BRANCH分行PR目标dev

自定义模型

编辑 .env 交换模型:

DEVELOPER_MODEL=gpt-4o-mini    # cheap & fast for code generation
ARCHITECT_MODEL=gpt-4o          # smart for code review
PM_MODEL=gpt-4o-mini            # cheap for task creation

______________________________________________________________________

需求

工具与能力

工具数量

12

资源数量

0

提示词数量

0

能力标签

AI开发工作流Python本地部署多代理系统自动化代码生成代码审查Jira集成GitHub集成

数量来自来源目录的标注,具体工具清单以官方文档为准。

典型使用场景

让助手直接读代码

把仓库、提交记录和 issue 交给模型检索,补全和重构时不用来回复制文件。

在对话里跑命令

触发构建、测试和脚本,执行结果直接回到上下文,省去切终端。

接进开发流程

把 PR、CI 状态和代码审查接进助手,减少在几个工具之间跳。

选择建议

值得选的地方

  • 工具数量 12 个,一次接入能覆盖的操作比单点工具更全。
  • 有现成的安装命令,不用自己找入口,照着跑就能起服务。
  • 公开说明写得比较完整,接入前能看清能力边界。

先想清楚的地方

  • stdio 方式要求本地装好 Python,换机器要重新装一遍。
  • 需要自备访问 Token,没有凭据没法直接试。
  • 第三方目录整理,版本更新和行为细节以官方仓库为准。

更适合

  • 需要在开发工具场景里让模型直接调用外部能力的人。
  • 想先快速试一下、能接受在本地跑服务的人。

不太适合

  • 完全不想在本地装环境的人。
  • 暂时拿不到访问 Token的人。
  • 需要厂商级 SLA 和技术支持的生产环境。

同类对比

5 个同类
MCP Server工具数传输方式安装命令收录来源最后核验
MCP Dev Pipline

MCP World · 本页

12stdio有1 个2026-05-17
Git 838e2ec1

MCP World

12stdio有2 个2026-05-17
Markitdown MCP 2c653a5f

MCP World

1stdio有1 个2026-05-17
Context7 831acf40

MCP World

0stdio有1 个2026-05-17
Context7 MCP C671e75a

MCP World

0stdio有1 个2026-05-17

按同分类和工具数量挑出最接近的几条,字段以各自详情页为准。

常见问题

5 条

MCP Dev Pipline 怎么安装?

公开资料给出的安装命令是 python3 -m venv .venv,运行环境为 Python。装完后按客户端要求写进 MCP 配置,重启客户端生效。

MCP Dev Pipline 怎么在 Claude Desktop、Cursor 里配置?

它是stdio 本地进程,客户端配置里要写启动命令和参数,运行环境是 Python;保存后完全退出客户端再打开,配置才会生效。

MCP Dev Pipline 收费吗?

本站只整理公开资料,不代收费用,也没有标注具体价格。是否收费取决于服务本身和背后的接口额度,正式使用前按官方说明确认。

MCP Dev Pipline 需要 API Key 吗?

公开资料标注的认证方式是访问 Token,也就是要先拿到凭据才能连上;凭据只填在自己本地的配置里,不要写进公开仓库。

MCP Dev Pipline 支持哪些客户端?

公开资料没有标注具体客户端;能配置本地 MCP 命令的客户端都能接,配置方式参照官方文档。

来源信息

继续浏览同类 MCP