Token导航 LogoToken导航TokenDH.com
Idwo MCP Agent logo
AI代理未说明官方级别未说明来源级核验

Idwo MCP Agent

MCP Server

一个通过AI驱动的决策智能编排GitHub、JIRA和Slack之间复杂开发工作流的MCP服务器代理。

工具数

5

提示词数

0

GitHub Stars

0

资源数

0
工作流自动化开发工具TypeScriptClaudeClaude

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

作者 / 组织

90cigars

提供方

90cigars

最后核验

2026/5/17 20:21

快速接入

先看主来源和安装命令,再打开仓库或文档;下面只保留这个条目的关键接入事实。

详细介绍

智能开发工作流编排器(IDWO)

一个高级的MCP(模型上下文协议)服务器代理,通过使用AI驱动的决策在GitHub、JIRA和Slack上智能地编排动作,自动化复杂的开发人员工作流程。

![TypeScript](https://www.typescriptlang.org/) ![OpenAI](https://openai.com/) ](https://www.docker.com/) ![Kubernetes](https://kubernetes.io/)

🎯 概述

IDWO通过提供智能自动化来弥合不同开发工具之间的差距,该自动化可以理解上下文、做出决策并跨平台执行多步骤工作流。与简单的基于webhook的自动化不同,IDWO使用基于LLM的分析来提供上下文、自适应的工作流管理。

关键能力

  • 🧠 AI驱动的分析:使用GPT-4分析拉取请求、分类问题并评估发布准备情况
  • 🔄 跨平台编排:无缝协调GitHub、JIRA和Slack之间的操作
  • 📊 智能洞察:生成团队生产力指标并确定工作流程瓶颈
  • 🎛️ MCP集成:适用于ChatGPT、Claude、GitHub Copilot和任何MCP兼容接口
  • ⚡ 实时工作流同步:在所有集成平台上保持一致的状态

🏗️ 建筑

graph TB
    A[MCP Client] --> B[IDWO MCP Server]
    B --> C[OpenAI Agent]
    B --> D[GitHub Integration]
    B --> E[JIRA Integration] 
    B --> F[Slack Integration]
    B --> G[Workflow Orchestrator]
    
    C --> H[GPT-4 Analysis]
    D --> I[GitHub API]
    E --> J[JIRA REST API]
    F --> K[Slack Web API]
    G --> L[State Management]

核心组件

  • MCP服务器:公开工具并处理客户端请求
  • 服务集成:带有错误处理功能的GitHub、JIRA和Slack API客户端
  • AI 代理:OpenAI集成用于智能决策
  • 工作流编排器:协调跨服务的多步骤操作
  • 状态管理:跟踪工作流状态并保持一致性

🚀 快速开始

先决条件

  • Node.js 22+
  • Docker和Docker Compose(可选)
  • 用于OpenAI、GitHub、JIRA和Slack的API密钥

安装

  1. 克隆存储库
   git clone https://github.com/your-org/idwo-mcp-server.git
   cd idwo-mcp-server
  1. 安装依赖项
   npm install
  1. 配置环境
   cp .env.example .env
   # Edit .env with your API keys and configuration
  1. 构建并启动
   npm run build
   npm start

Docker快速入门

# Start with all dependencies
docker-compose up -d

# Production deployment
docker-compose -f docker-compose.prod.yml up -d

🔧 配置

环境变量

必需的API密钥

OPENAI_API_KEY=sk-your-openai-api-key-here
GITHUB_TOKEN=ghp_your-github-token-here
JIRA_URL=https://your-domain.atlassian.net
JIRA_USERNAME=your-email@company.com
JIRA_API_TOKEN=your-jira-api-token
SLACK_BOT_TOKEN=xoxb-your-slack-bot-token

可选配置

# Database & Cache
DATABASE_URL=postgresql://user:password@localhost:5432/idwo
REDIS_URL=redis://localhost:6379

# Security
JWT_SECRET=your-jwt-secret-key
ENCRYPTION_KEY=your-32-character-encryption-key

# Performance
RATE_LIMIT_MAX_REQUESTS=100
CIRCUIT_BREAKER_TIMEOUT=5000

服务设置

GitHub

  1. 使用创建个人访问令牌 repo, read:org,以及 read:user 权限
  2. GITHUB_TOKEN 环境变量

JIRA

  1. 在Atlassian帐户设置中创建API令牌
  2. 配置 JIRA_URL, JIRA_USERNAME,以及 JIRA_API_TOKEN

Slack

  1. 创建具有适当范围的Slack应用程序(chat:write, channels:read, users:read)
  2. 将应用程序安装到您的工作区并获取机器人令牌
  3. SLACK_BOT_TOKEN 和其他Slack配置

OpenAI

  1. 从OpenAI平台获取API密钥
  2. OPENAI_API_KEY 并且可选 OPENAI_MODEL

📖 MCP工具参考

analyze_pr

使用AI驱动的洞察力分析拉取请求。

{
  "owner": "string",
  "repo": "string", 
  "pull_number": 123,
  "include_jira_context": true
}

响应:风险评估、建议的审查人员、估计的审查时间、相关的JIRA票证

smart_triage

自动对问题进行分类和优先级排序。

{
  "issue_key": "PROJ-123",
  "github_issue_url": "https://github.com/org/repo/issues/456",
  "team_context": "backend-team"
}

响应:优先级、类别、工作量估算、建议的受让人和冲刺

orchestrate_release

协调跨多个平台的发布。

{
  "release_version": "v2.1.0",
  "repository": "org/repo",
  "jira_project": "PROJ",
  "slack_channel": "#releases",
  "dry_run": false
}

响应:准备度评分、阻断剂、测试覆盖率、建议

sync_workflow_status

跨平台同步状态更新。

{
  "workflow_id": "pr-org-repo-123",
  "status_update": "in-review",
  "platforms": ["github", "jira", "slack"]
}

get_team_insights

生成生产力分析并识别瓶颈。

{
  "team_name": "backend-team",
  "time_period": "30d",
  "include_predictions": true
}

响应:速度趋势、瓶颈、指标、预测

🧪 测试

单元测试

npm run test
npm run test:watch

集成测试

npm run test:integration

覆盖范围报告

npm run test -- --coverage

测试结构

  • 单元测试:单个组件功能
  • 集成测试:端到端工作流验证
  • 模拟服务:外部API模拟
  • 错误场景:故障模式测试

🚢 部署

地方发展

npm run dev  # Development with hot reload

Docker部署

# Build production image
docker build -t idwo-mcp-server .

# Run with docker-compose
docker-compose up -d

Kubernetes部署

# Apply manifests
kubectl apply -f deployment/k8s/

# Or using Helm
helm install idwo deployment/helm/idwo-chart/ \
  --set secrets.openai.apiKey=$OPENAI_API_KEY \
  --set secrets.github.token=$GITHUB_TOKEN

生产注意事项

  • 使用托管数据库(RDS、Redis ElastiCache)
  • 配置适当的机密管理(Kubernetes机密、HashiCorp Vault)
  • 设置监控和警报(普罗米修斯、格拉法纳)
  • 实施适当的日志聚合(ELK堆栈)
  • 配置负载平衡器和入口控制器

🔒 安全考虑

当前安全措施

  • 认证:OAuth 2.0适用于所有服务集成
  • 加密:在静止和传输过程中加密的敏感数据
  • 速率限制:请求限制以防止滥用
  • 输入验证:所有输入的Zod模式
  • 网络安全:Docker网络隔离,Kubernetes网络策略
  • 集装箱安全:非root用户,只读文件系统,最小攻击面

潜在安全风险和缓解措施

风险影响缓解
API密钥暴露加密的秘密存储、轮换策略
快速注射培养基输入消毒、输出验证
服务帐户泄露最低权限访问,定期密钥轮换
数据过滤网络分段、审计日志记录
DoS攻击中等速率限制,断路器

安全最佳实践

  1. 秘密管理:使用外部秘密存储(Vault、AWS Secrets Manager)
  2. 访问控制:为不同的用户角色实现RBAC
  3. 审计日志:记录所有API调用和工作流执行
  4. 网络安全:使用VPC、安全组和网络策略
  5. 定期更新:保持依赖关系更新并扫描漏洞

⚡ 性能和可扩展性

当前性能特征

  • 响应时间:简单操作为亚秒,人工智能分析为2-5s
  • 吞吐量:每个实例每分钟100多个请求
  • 并发:始终异步/等待,连接池
  • 内存使用:~512MB基线,2GB负载
  • CPU 使用率:典型为0.1-0.5个CPU内核,AI推理时为1+

扩展策略

水平缩放

  • Kubernetes HPA:基于CPU/内存的自动缩放(2-10个Pod)
  • 负载平衡:在健康情况下循环
  • 无状态设计:没有本地状态依赖关系

性能优化

  • 连接池:与API的持久HTTP连接
  • 缓存:用于API响应和计算结果的Redis
  • 断路器:不健康的服务很快就会失败
  • 批处理:在可能的情况下进行集团运营

瓶颈分析

组件瓶颈解决方案
OpenAI API速率限制、延迟请求队列、响应缓存
GitHub API速率限制智能分页、缓存
JIRA API响应缓慢连接池,超时
数据库查询性能索引、读取副本

监控指标

  • 请求延迟百分比(p50、p95、p99)
  • 按服务和操作分类的错误率
  • API费率限制利用率
  • 数据库连接池使用情况
  • 内存和CPU利用率

🐛 故障场景和测试

常见故障模式

API服务故障

  • GitHub API中断:断路器防止级联故障
  • JIRA速率限制:请求排队和退避策略
  • 松弛服务降级:伐木后的退化很好
  • OpenAI超时:使用指数回退重试逻辑

基础设施故障

  • 数据库连接:具有自动重新连接功能的连接池
  • Redis缓存丢失:回退到直接API调用
  • 网络分区:服务网格弹性模式
  • Pod故障:Kubernetes自动重启和扩展

测试策略

混沌工程

# Simulate service failures
kubectl patch deployment idwo-server -p '{"spec":{"template":{"spec":{"containers":[{"name":"idwo-server","env":[{"name":"GITHUB_TOKEN","value":"invalid"}]}]}}}}'

# Network partitioning
kubectl apply -f tests/chaos/network-partition.yaml

# Resource constraints
kubectl apply -f tests/chaos/memory-pressure.yaml

负载测试

# Install k6 and run load tests
k6 run tests/load/pr-analysis.js
k6 run tests/load/workflow-orchestration.js

集成测试场景

  • API身份验证失败
  • API响应格式不正确
  • 超时和重试逻辑
  • 费率限制处理
  • 数据一致性检查

恢复程序

  1. 服务补救:通过健康检查自动重启
  2. 数据恢复:时间点数据库恢复
  3. 国家和解:工作流状态验证和修复
  4. 监控:自动警报和事件响应

📈 监测和可观察性

指标收集

  • 应用程序指标:请求率、响应时间、错误计数
  • 商业米制公约:工作流程完成率、人工智能准确性
  • 基础设施指标:CPU、内存、网络、磁盘使用情况
  • 自定义指标:API配额使用率、缓存命中率

日志策略

  • 结构化日志记录:带相关ID的JSON格式
  • 日志级别:错误、警告、信息、调试以及适当的筛选
  • 集中收集:ELK堆栈或云日志服务
  • 日志保留:调试30天,审计日志1年

警报规则

  • 错误率高(5分钟内>5%)
  • 响应时间下降(p95>10s)
  • API费率限制消耗(>80%)
  • 工作流编排失败
  • 基础设施资源枯竭

仪表盘

  • 操作仪表板:系统健康状况、请求指标、错误率
  • 商业仪表盘:工作流程完成、用户采用率、投资回报率指标
  • 仪表盘:响应时间、吞吐量、资源利用率

🔮 未来路线图

近期改善(3-6个月)

多租户架构

  • 组织隔离:每个租户单独的数据和配置
  • RBAC实现:组织内基于角色的访问控制
  • 计费集成:使用情况跟踪和成本分配

增强分析

  • 预测分析:用于冲刺计划和风险评估的ML模型
  • 异常检测:团队行为或系统绩效中的异常模式
  • 自定义指标:用户定义的KPI和仪表板定制

中期扩张(6-12个月)

其他集成

  • 线性:现代开发团队的问题跟踪
  • 概念:文件和知识管理
  • PagerDuty:事件管理和警报
  • Discord 的中文翻译是“不和谐”或“纷争”。:团队沟通和通知

先进的人工智能能力

  • 自定义模型微调:特定于组织的人工智能模型
  • 多模态分析:代码、文档和视觉内容
  • 自动代码审查:AI驱动的代码质量评估

工作流生成器

  • 可视化编辑器:拖放工作流创建
  • 模板库:预构建的自动化模式
  • 自定义操作:用户定义的工作流步骤

长期愿景(12个月以上)

多云部署

  • 云不可知:AWS、GCP、Azure部署选项
  • 边缘计算:低延迟的区域部署
  • 混合云:本地和云混合架构

高级分析平台

  • 数据湖集成:历史数据分析和报告
  • 实时流媒体:实时工作流监控和警报
  • ML管道:自动化模型训练和部署

平台生态系统

  • 插件架构:第三方集成和扩展
  • API市场:社区贡献的工作流模板
  • 开发人员SDK:用于构建自定义集成的工具

📚 架构决策与权衡

技术栈决策

TypeScript与Python

已选择:TypeScript

  • 优点:卓越的异步处理,共享前端/后端代码,更好的MCP生态系统
  • 缺点:较小的机器学习生态系统,更复杂的构建过程
  • 替代:Python和FastMCP用于数据密集型工作流

API直接集成与Webhook架构

选择:API与断路器的直接集成

  • 优点:实时数据,精细控制,更容易测试
  • 缺点:API消耗更高,潜在的轮询开销
  • 替代:用于高容量场景的事件驱动webhooks

单片与微服务

已选择:模块化单片

  • 优点:部署更简单,类型共享,调试更容易
  • 缺点:规模限制、技术耦合
  • 未来:随着团队和复杂性的增长,微服务转型

基础设施决策

Kubernetes与无服务器

已选择:带有无服务器选项的Kubernetes

  • 优点:更好的资源利用率、服务网格优势、供应商中立性
  • 缺点:操作复杂,基础设施成本较高
  • 替代:AWS Lambda适用于对成本敏感的低容量部署

PostgreSQL+Redis vs NoSQL

选择:PostgreSQL+Redis混合

  • 优点:ACID合规性、成熟的工具、灵活的查询
  • 缺点:运营开销与托管服务
  • 替代:DynamoDB+ElastiCache用于云原生架构

人工智能集成决策

OpenAI API与自营模型

选择:OpenAI API与Self-hosted回退

  • 优点:最新型号、可靠性、综合性能
  • 缺点:供应商锁定、大规模成本、数据隐私问题
  • 替代:Ollama用于敏感数据或成本优化

🤝 贡献

开发设置

  1. 分叉存储库
  2. 创建要素分支: git checkout -b feature/amazing-feature
  3. 安装依赖项: npm install
  4. 运行测试: npm test
  5. 提交拉取请求

代码规范

  • TypeScript:严格模式已启用
  • ESLint:强制代码样式
  • 更漂亮:自动格式化
  • 开玩笑:全面测试覆盖率(>90%)
  • 常规承诺:语义提交消息

拉取请求流程

  1. 确保所有测试通过
  2. 根据需要更新文档
  3. 添加新功能的测试
  4. 请求维护人员审查
  5. 处理反馈并合并

📄 许可证

此项目根据MIT许可证获得许可-请参阅 许可证 文件以获取详细信息。

🙏 致谢

______________________________________________________________________

📞 支持

  • 问题:
  • 讨论:
  • 文档: 维基
  • 电子邮件: team@your-org.com

______________________________________________________________________

*内置于❤️ 面向开发者社区*

目录标签

目录标签

工作流自动化开发工具TypeScriptClaude本地部署AI决策跨平台集成MCP协议

支持客户端

Claude

接入字段

传输方式(transport,传输协议)

未说明

鉴权方式(authType,认证方式)

oauth

工具数量(toolCount,工具数)

5

资源数量(resourceCount,资源数)

0

提示词数量(promptCount,提示词数)

0

权限和风险

未说明oauth部署方式未说明

接入前请确认传输方式、认证方式和部署位置,并根据实际工具能力限制访问范围。

安装前确认

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

仍需确认:installCommand

来源信息

继续浏览同类 MCP