Tech Ecosystem Analysis

技术生态系统分析 MCP

在 ApifyForge 上查看 | 在 Apify Store 上使用

---

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf）：

{
  "mcpServers": {
    "tech-ecosystem-analysis-mcp": {
      "url": "https://ryanclinton--tech-ecosystem-analysis-mcp.apify.actor/mcp"
    }
  }
}

---

为 AI Agent 和大模型工作流提供技术生态系统分析——绘制技术关系图、追踪采用曲线、检测 CVE 漏洞，并基于 6 个实时数据源评估技术栈风险。通过模型上下文协议连接一次，你的 AI 助手即可使用结构化、数据驱动的情报评估任意框架、语言或工具。

此 MCP 服务在 Apify 平台的 Standby 模式下运行，提供 8 个工具，可并行协调 GitHub、NVD CVE 数据库、StackExchange、Hacker News、Wikipedia 和实时 Tech Stack Detector。每个工具都会返回结构化 JSON，其中包含每种技术的评分、趋势分类和可执行建议，可直接用于任何 Agent 工作流。

⬇️ 可以访问哪些数据？

数据点	来源	示例
📦 仓库数量、星标数、复刻数、贡献者活跃度	GitHub Search	React：热门仓库共获 45,231 个星标
🔐 CVE ID、CVSS 评分、严重程度、受影响版本	NVD CVE Database	CVE-2024-21490，CVSS 9.8，严重
💬 问答数量、回答率、标签热度、社区评分	StackExchange	TypeScript：回答率 94%，12,400 个问题
📰 讨论互动度、点赞模式、趋势情绪	Hacker News	Rust：平均 312 分，每篇帖子 187 条评论
📖 技术历史、生态背景、成熟度指标	Wikipedia	Go：首次出现于 2009 年，至今 15 年
🌐 从实时 URL 检测到的框架、CMS、CDN、分析工具	Tech Stack Detector	acmecorp.com：Next.js、Vercel、Cloudflare
📈 采用阶段分类（新兴/增长/成熟/衰退）	综合评分	SvelteKit：增长中，势头评分 74/100
⚠️ 加权暴露评分（严重 CVE × 3，高危 CVE × 2）	综合评分	OpenSSL：暴露评分 60/100

MCP 工具

工具	价格	返回内容
map_tech_ecosystem	$0.045	包含节点、边、图密度和热门技术的度中心性网络图
assess_tech_adoption	$0.045	GitHub 星标总数、SO 问题数量、回答率、增长率、趋势方向
detect_tech_vulnerabilities	$0.045	包含 CVSS 评分、严重程度和每种技术加权暴露评分的 CVE 列表
analyze_developer_sentiment	$0.045	每种技术的 HN 互动度（分数 + 评论）和 SO 质量（回答率、评分）
score_tech_stack_risk	$0.045	加权风险评分：CVE 暴露（40%）+ 社区反向评分（35%）+ 成熟度反向评分（25%）
track_framework_trends	$0.045	S 曲线阶段（新兴/增长/成熟/衰退）、势头评分、复刻/星标增长速度
assess_tech_maturity	$0.045	6 因素成熟度模型：历史、社区规模、文档质量、企业采用情况、生态广度、稳定性
generate_tech_report	$0.045	综合全部 7 项分析的完整报告，包含摘要、关键发现和建议

为什么使用 Tech Ecosystem Analysis MCP？

工程团队、安全分析师和 CTO 必须在信息不完整的情况下，做出影响数年的技术选择。手动研究 GitHub、StackOverflow、CVE 数据库和 Hacker News 上的信息，每个框架都要花费数小时，而且数据很快就会过时。咨询分析师收取数千美元提供报告，但这些报告在交付时就已经过时数周。

此 MCP 可自动完成整个研究流程。AI Agent 只需调用一次工具，就能获得实时采用数据、CVE 风险暴露、开发者情绪和成熟度分类，所有信息都包含在一份结构化响应中。数据在查询时从源数据库获取，而非来自缓存快照。

在 Apify 上运行时的平台优势：

• 定时运行 — 每周运行生态系统检查，追踪技术栈的风险状况如何随时间变化
• API 访问 — 从 CI/CD 流水线、Slack 机器人或任何 HTTP 客户端触发评估
• 并行执行 — 每次工具调用最多可同时运行 6 个 actor 调用，降低延迟
• 支出限额 — 设置每次运行的预算上限；达到限额时，服务端会返回正常的错误响应
• 集成 — 将结果连接到 Zapier、Make、webhook，或直接推送到 Notion 或 Confluence

数据源

GitHub Search

查询仓库元数据，包括星标数、复刻数、主要语言、创建日期、最后更新日期和仓库主题。actor 每次查询最多收集 30 条结果，并通过匹配 language、name 和 description 字段，按技术筛选结果。星标总数用于计算采用评分（权重为 50%）和社区支持评分。

NVD CVE 数据库

从国家漏洞数据库获取实时漏洞记录。每条 CVE 均包含其 ID、CVSS 基础评分、严重性级别（LOW/MEDIUM/HIGH/CRITICAL）、受影响产品列表、描述和发布日期。漏洞风险暴露公式将严重 CVE 的权重设为 3 倍、高危 CVE 设为 2 倍、其他 CVE 设为 1 倍，最高为 100。风险级别阈值：CVSS >= 9.0 或存在任何严重 CVE 时为 CRITICAL；CVSS >= 7.0 时为 HIGH；CVSS >= 4.0 时为 MEDIUM。

StackExchange

获取问答讨论串，包括问题标题、标签、社区评分、已回答／未回答状态和创建日期。回答率同时影响采用评分（权重为 20%）和情绪评分（权重为 50%）。30 天的问题时间窗口用于衡量当前势头与历史活动的差异。

Hacker News

获取与每项技术匹配的讨论串。互动信号——赞成票数和评论数——会纳入情绪公式：HN 互动占情绪评分的 50%（赞成票数：40%，评论数：10%）。每项技术返回按赞成票数排序的前 5 篇帖子。

Wikipedia

提取文章文本，并解析其中的版本发布年份模式（released in YYYY、first appeared YYYY、created YYYY）。估算出的技术年龄用于成熟度模型（在综合成熟度评分中的权重为 20%），并为关系图提供生态系统背景信息。

Tech Stack Detector

通过 ryanclinton/website-tech-stack-detector actor 扫描实时网站。返回检测到的技术及其名称、类别、置信度评分和检测到的版本。在提供 URL 时，用于 map_tech_ecosystem、detect_tech_vulnerabilities 和 generate_tech_report。检测到的技术会自动加入 CVE 扫描。

评分算法的工作原理

采用评分（0–100）

GitHub 星标贡献（权重为 50%）：min(totalStars / 50,000, 1) × 50。StackOverflow 贡献（权重为 50%）：问题数量 min(count / 100, 1) × 30，加上回答率 × 20。增长率根据过去 30 天内创建的 SO 问题所占比例计算——超过 30% 则归类为 rising，低于 5% 则归类为 declining。

漏洞暴露评分（0–100）

加权严重性总和：(criticalCVEs × 3 + highCVEs × 2 + otherCVEs × 1) × 10，最高为 100。风险等级分类：当平均 CVSS >= 9 或存在任何严重 CVE 时为 CRITICAL；当平均 CVSS >= 7 时为 HIGH；当平均 CVSS >= 4 时为 MEDIUM；存在 CVE 但平均值低于 4 时为 LOW。

开发者情绪评分（0–100）

HN 组件（50%）：min(avgPoints / 100, 1) × 40 + min(avgComments / 50, 1) × 10。SO 组件（50%）：min(avgScore / 10, 1) × 30 + (1 - unansweredRatio) × 20。总体分类：positive >= 60，negative < 30，介于两者之间为 neutral。

技术栈风险评分（0–100）

三因素加权组合：CVE 暴露评分 × 0.40 +（100 − 社区支持评分）× 0.35 +（100 − 成熟度评分）× 0.25。社区支持：GitHub 星标（40%）、SO 覆盖率（30%）、最近 90 天有更新的仓库（30%）。风险阈值：critical >= 75，high >= 50，medium >= 25，低于 25 为 low。

成熟度评分（0–100）和 S 曲线分类

六项指标：技术年限 min(ageYears / 15, 1) × 20 + 社区规模 min(totalStars / 100,000, 1) × 20 + 文档质量 × 0.20 + 企业采用情况（星标数 > 1K 的仓库）× 0.15 + 生态系统广度（不同主题）× 0.15 + 稳定性指数 × 0.10。分类：评分 >= 70 且年限 >= 8 年时为成熟；评分 >= 45，或年限 >= 3 且社区规模 > 10K 时为增长中；评分 < 25、年限 > 10 年且最近更新少于 2 次时为衰退中；其他情况为新兴。

生态系统网络（度中心性）

构建包含以下节点类型的有向图：technology、repo、discussion、vulnerability、article、website。边类型：implements（repo → technology，根据标准化星标数加权）、describes（article → technology，权重为 0.5）、uses（website → technology，根据检测置信度加权）。度中心性 = 节点度数 / (N − 1)。图密度 = 2E / (N × (N − 1))。

技术生态系统分析的使用场景

工程团队技术选型

评估新框架的 CTO 和工程负责人需要的信息不止是一篇博客文章。将候选技术栈传入 score_tech_stack_risk，即可在投入工程资源之前，获取按 CVE 加权并结合社区情况调整的风险评分。只需调用一次工具，即可比较 React、Vue 和 Svelte。

安全团队 CVE 映射

开展季度漏洞审查的安全工程师可以将生产环境使用的技术列表（或用于自动检测的 Web 应用 URL）传入 detect_tech_vulnerabilities。该工具会返回按 CVSS 评分和暴露权重排序的 CVE 列表，可直接用于修复优先级工作流。

VC 和并购技术尽职调查

评估公司技术护城河或潜在责任的投资分析师需要了解目标公司的技术栈处于增长曲线的哪个阶段，或是否即将失去社区支持。generate_tech_report 会在一次 AI Agent 调用中生成完整分析，涵盖采用趋势、成熟阶段、CVE 暴露情况和情绪。

开发者关系和内容策略

DevRel 团队在决定将会议演讲、教程和社区赞助资源投入何处时，可以使用 track_framework_trends 找出处于增长阶段且势头评分较高的框架。通过实时数据替代昂贵的调查研究。

框架迁移规划

为从老旧框架迁移制定商业论证的团队需要了解候选框架是否真正成熟，还是仍不稳定。assess_tech_maturity 会生成一个包含 6 个因素的成熟度模型，提供企业采用情况代理指标、生态系统广度和稳定性指数，为迁移决策提供结构化依据。

AI Agent 持续监控

使用 AI 编码助手的工程组织可以将此 MCP 接入定时运行的 Apify 任务。每周调用 score_tech_stack_risk 评估生产技术栈，自动发现新 CVE 或社区健康度下降，避免问题演变成事故。

如何连接此 MCP 服务

Claude Desktop

添加到你的 claude_desktop_config.json：

{
  "mcpServers": {
    "tech-ecosystem-analysis": {
      "url": "https://tech-ecosystem-analysis-mcp.apify.actor/mcp",
      "headers": {
        "Authorization": "Bearer YOUR_APIFY_TOKEN"
      }
    }
  }
}

Cursor / Windsurf / Cline

在 MCP 客户端设置中添加相同的 URL 和 Authorization 标头。该服务使用 Streamable HTTP 传输，无需配置 SSE。

直接使用 HTTP

curl -X POST "https://tech-ecosystem-analysis-mcp.apify.actor/mcp" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_APIFY_TOKEN" \
  -d '{
    "jsonrpc": "2.0",
    "method": "tools/call",
    "params": {
      "name": "assess_tech_adoption",
      "arguments": {
        "technologies": ["TypeScript", "Rust", "Go"]
      }
    },
    "id": 1
  }'

Python（通过 openai-agents 或任何 MCP 客户端）

import httpx

response = httpx.post(
    "https://tech-ecosystem-analysis-mcp.apify.actor/mcp",
    headers={
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_APIFY_TOKEN",
    },
    json={
        "jsonrpc": "2.0",
        "method": "tools/call",
        "params": {
            "name": "score_tech_stack_risk",
            "arguments": {
                "technologies": ["Django", "Flask", "FastAPI"]
            }
        },
        "id": 1,
    }
)

result = response.json()
for tech in result["result"]["content"]:
    print(tech["text"])

输入参数

参数	类型	必填	默认值	描述
port	integer	否	3054	MCP 服务的端口号（1024–65535）。在 Standby 模式之外运行时使用。

MCP 服务没有其他 actor 级别的输入。所有配置均作为工具参数在每次工具调用时传递。

工具参数参考

map_tech_ecosystem

参数	类型	必填	描述
technologies	string[]	是	要映射的技术，例如 ["React", "Node.js", "PostgreSQL"]
urls	string[]	否	用于检测其他技术的网站 URL

assess_tech_adoption

参数	类型	必填	描述
technologies	string[]	是	要评估的技术，例如 ["TypeScript", "Rust", "Go"]

detect_tech_vulnerabilities

参数	类型	必填	描述
technologies	string[]	是	要与 NVD CVE 数据库进行核对的技术
urls	string[]	否	网站 URL — 自动检测到的技术会加入 CVE 扫描

analyze_developer_sentiment

参数	类型	必填	描述
technologies	string[]	是	要衡量情绪倾向的技术

score_tech_stack_risk

参数	类型	必填	描述
technologies	string[]	是	要评估综合风险的技术

track_framework_trends

参数	类型	必填	描述
frameworks	string[]	是	要追踪的框架，例如 ["Next.js", "SvelteKit", "Remix"]

assess_tech_maturity

参数	类型	必填	描述
technologies	string[]	是	要放入 S 曲线生命周期模型的技术

generate_tech_report

参数	类型	必填	描述
technologies	string[]	是	要纳入完整报告的技术
urls	string[]	否	用于自动检测技术栈的网站 URL

⬆️ 输出示例

assess_tech_adoption — 输出示例

[
  {
    "technology": "TypeScript",
    "githubMetrics": {
      "totalRepos": 18,
      "totalStars": 98421,
      "avgStars": 5468,
      "topRepos": [
        { "name": "microsoft/TypeScript", "stars": 98421, "url": "https://github.com/microsoft/TypeScript" },
        { "name": "type-challenges/type-challenges", "stars": 43102, "url": "https://github.com/type-challenges/type-challenges" }
      ]
    },
    "stackOverflowMetrics": {
      "totalQuestions": 84,
      "avgScore": 4.2,
      "answerRate": 0.94,
      "recentActivity": 31
    },
    "adoptionScore": 79,
    "trend": "rising",
    "growthRate": 0.37
  }
]

score_tech_stack_risk — 输出示例

[
  {
    "technology": "Log4j",
    "cveExposure": {
      "score": 89,
      "totalCves": 7,
      "criticalCves": 2,
      "highCves": 3
    },
    "communitySupport": {
      "score": 42,
      "githubStars": 3210,
      "soQuestions": 14,
      "recentActivity": 1
    },
    "maturityFactor": {
      "score": 58,
      "ageYears": 18,
      "releaseFrequency": "infrequent"
    },
    "overallRisk": 76,
    "riskLevel": "critical",
    "recommendation": "Log4j has critical risk. Immediate review: 7 CVEs (2 critical) with limited community support."
  }
]

generate_tech_report — 输出示例（节选）

{
  "title": "Technology Ecosystem Report: React, TypeScript, PostgreSQL",
  "generatedAt": "2026-03-21T09:14:02.341Z",
  "technologies": ["React", "TypeScript", "PostgreSQL"],
  "summary": "Analyzed 3 technologies. Ecosystem contains 47 nodes and 83 relationships. Graph density: 0.076. Top technologies: TypeScript, React, PostgreSQL. Overall risk assessment: LOW — stack is healthy.",
  "sections": {
    "adoption": [
      { "technology": "React", "adoptionScore": 88, "trend": "stable" },
      { "technology": "TypeScript", "adoptionScore": 79, "trend": "rising" },
      { "technology": "PostgreSQL", "adoptionScore": 71, "trend": "stable" }
    ],
    "vulnerabilities": [
      { "technology": "React", "riskLevel": "low", "totalCves": 2, "avgCvss": 4.3, "exposureScore": 20 },
      { "technology": "TypeScript", "riskLevel": "none", "totalCves": 0, "avgCvss": 0, "exposureScore": 0 },
      { "technology": "PostgreSQL", "riskLevel": "medium", "totalCves": 6, "avgCvss": 6.1, "exposureScore": 40 }
    ],
    "maturity": [
      { "technology": "React", "maturityLevel": "mature", "maturityScore": 87 },
      { "technology": "TypeScript", "maturityLevel": "growing", "maturityScore": 61 },
      { "technology": "PostgreSQL", "maturityLevel": "mature", "maturityScore": 91 }
    ]
  },
  "recommendations": [
    "Technology stack appears healthy. Continue regular security audits and dependency updates."
  ],
  "riskSummary": {
    "overallRisk": "LOW — stack is healthy",
    "criticalFindings": [],
    "positiveIndicators": [
      "React: positive developer sentiment (score: 74/100)",
      "TypeScript: strong growth momentum (82/100)"
    ]
  }
}

输出字段

assess_tech_adoption

字段	类型	描述
technology	string	技术名称
githubMetrics.totalRepos	number	与该技术匹配的仓库数
githubMetrics.totalStars	number	匹配仓库的 Star 总数
githubMetrics.avgStars	number	每个仓库的平均 Star 数
githubMetrics.topRepos	array	按 Star 数排名前 5 的仓库，包含名称、Star 数和 URL
stackOverflowMetrics.totalQuestions	number	与该技术匹配的 SO 问题数
stackOverflowMetrics.avgScore	number	匹配问题的社区平均评分
stackOverflowMetrics.answerRate	number	有已采纳答案的问题占比（0–1）
stackOverflowMetrics.recentActivity	number	过去 30 天内创建的问题数
adoptionScore	number	加权采用评分（0–100）
trend	string	rising、stable 或 declining
growthRate	number	近期 SO 活动与总活动的比率（0–1）

detect_tech_vulnerabilities

字段	类型	描述
technology	string	技术名称（包括从 URL 自动检测到的名称）
cves	array	CVE 记录，包含 id、severity、cvssScore、description、publishedDate
riskLevel	string	critical、high、medium、low 或 none
totalCves	number	匹配的 CVE 总数
avgCvss	number	CVSS 基础分平均值
exposureScore	number	加权暴露分数（0–100）

score_tech_stack_risk

字段	类型	描述
technology	string	技术名称
cveExposure.score	number	CVE 暴露度组成部分（0–100）
cveExposure.criticalCves	number	严重级别为 CRITICAL 的 CVE 数量
cveExposure.highCves	number	严重级别为 HIGH 的 CVE 数量
communitySupport.score	number	社区健康度组成部分（0–100）
communitySupport.githubStars	number	匹配仓库的 GitHub 星标总数
communitySupport.soQuestions	number	匹配的 SO 问题数量
communitySupport.recentActivity	number	最近 90 天内更新的仓库数量
maturityFactor.score	number	成熟度组成部分（0–100）
maturityFactor.ageYears	number	根据 Wikipedia 估算的年限
maturityFactor.releaseFrequency	string	frequent、regular 或 infrequent
overallRisk	number	综合风险分数（0–100）
riskLevel	string	critical、high、medium 或 low
recommendation	string	通俗易懂的行动建议

assess_tech_maturity

字段	类型	描述
technology	string	技术名称
maturityLevel	string	emerging、growing、mature 或 declining
indicators.age	string	格式化的年限字符串，例如 “15 年（自 2009 年起）”
indicators.communitySize	number	匹配仓库的 GitHub 星标总数
indicators.documentationQuality	number	文档评分（0–100）：Wikipedia 收录情况 + SO 答复率
indicators.enterpriseAdoption	number	基于星标数 > 1K 的仓库计算的代理评分（0–100）
indicators.ecosystemBreadth	number	各仓库的 GitHub 唯一主题数量，按比例换算为 100 分
indicators.stabilityIndex	number	答复率 + 最近更新比例（0–100）
maturityScore	number	综合成熟度分数（0–100）
description	string	通俗易懂的成熟度描述

track_framework_trends

字段	类型	描述
framework	string	框架名称
githubTrend.stars	number	匹配仓库的星标总数
githubTrend.forks	number	匹配仓库的复刻总数
githubTrend.recentRepos	number	最近 6 个月创建的仓库数量
githubTrend.growthRate	number	最近 6 个月创建的仓库占比
stackOverflowTrend.questionCount	number	匹配的 SO 问题总数
stackOverflowTrend.recentQuestions	number	最近 30 天内的 SO 问题数量
stackOverflowTrend.trendDirection	string	up、stable 或 down
adoptionPhase	string	S 曲线阶段：emerging、growing、mature、declining
momentum	number	综合势头分数（0–100）

运行技术生态系统分析需要多少费用？

此 MCP 采用按事件付费模式——每次工具调用费用为 $0.045。全部 8 个工具的定价相同。平台计算费用已包含在内。

场景	工具调用次数	每次调用费用	总费用
快速漏洞扫描（1 项技术）	1	$0.045	$0.045
检查 3 个框架的采用情况	1	$0.045	$0.045
对一个技术栈运行完整的 8 工具套件	8	$0.045	$0.36
每周监控（8 个工具 × 4 周）	32	$0.045	$1.44
团队使用——每月 10 份报告	80	$0.045	$3.60

Apify 免费套餐包含每月 $5 的抵用金——足以进行 110 次单独工具调用，或生成 13 份完整的 8 工具生态系统报告，无需订阅。你可以为每次运行设置最高支出限额，以控制费用。

与人工研究或分析师报告相比：咨询公司出具一份技术尽职调查报告通常需要 $2,000–5,000，并耗时 2–3 周。使用此 MCP，你的 AI Agent 只需 $0.045，就能在几秒内生成相同的结构化数据。

Tech Ecosystem Analysis MCP 的工作原理

第 1 步：调用工具并扣费

当 MCP 客户端调用工具时，服务会立即扣除 Actor.charge() 事件的费用。如果已设置支出限额且达到该限额，工具会返回结构化错误 JSON，而不会继续执行——避免产生意外超支。

第 2 步：并行执行 actor

runActorsParallel() 通过 Apify 客户端同时启动所有必需的数据源 actor。每个 actor 使用 256 MB 内存，超时时间为 180 秒。通过 dataset.listItems({ limit: 500 }) 收集结果。执行失败的 actor 会返回空数组——评分函数会妥善处理缺失数据，不会抛出错误。

各工具的数据源：

• map_tech_ecosystem：GitHub（20 条结果）+ Wikipedia（5 条结果）+ 每个 URL 对应的 Tech Stack Detector
• assess_tech_adoption：GitHub（30 条）+ StackExchange（30 条）
• detect_tech_vulnerabilities：NVD CVE（30 条）+ 每个 URL 对应的 Tech Stack Detector
• analyze_developer_sentiment：Hacker News（30 条）+ StackExchange（30 条）
• score_tech_stack_risk：NVD CVE（30 条）+ GitHub（20 条）+ StackExchange（20 条）+ Wikipedia（5 条）
• track_framework_trends：GitHub（30 条）+ StackExchange（30 条）
• assess_tech_maturity：GitHub（20 条）+ StackExchange（20 条）+ Wikipedia（5 条）
• generate_tech_report：全部 5 个数据源（每个 30 条结果）+ 每个 URL 对应的 Tech Stack Detector

第 3 步：评分与分类

每个评分函数都会根据 language、name、description、title 和 tags 字段，使用不区分大小写的子字符串匹配，对每项技术筛选原始 actor 结果。评分在进程内计算，不调用外部 API。所有中间评分都会限制在 0 到 100 之间。generateReport 函数会依次对同一个数据对象调用全部 7 个评分函数，并汇总输出。

第 4 步：响应

结果会序列化为格式化的 JSON，并作为类型为 text 的 MCP 内容块返回。Streamable HTTP 传输会处理每个请求的会话生命周期——服务会针对每个发往 /mcp 的 POST 请求创建一个新的 McpServer 实例，避免请求之间共享状态。

获取最佳结果的提示

1. 每次调用提供 2–5 项技术，以生成更丰富的网络图。 单项技术调用适用于漏洞检查，但生态系统映射需要共现数据，才能构建有意义的关联。

2. 尽职调查时使用 generate_tech_report，监控时使用单项工具。 完整报告会调用全部 6 个数据源并运行全部 7 个评分函数，适合一次性分析。对于每周自动检查，只调用 score_tech_stack_risk 和 detect_tech_vulnerabilities，以尽量降低成本。

3. 在漏洞扫描中添加网站 URL。 将生产应用的 URL 传递给 detect_tech_vulnerabilities 或 generate_tech_report。Tech Stack Detector 会识别你可能未列出的技术，并自动将其加入 CVE 扫描。

4. 结合增长率解读成熟度评分。 某项技术可能处于 growing 阶段（势头强劲），但成熟度评分仍然较低——这意味着它的采用率正在上升，但生态系统仍不稳定。结合这两项信号才能全面了解情况。

5. 比较候选项时，先使用 track_framework_trends，再使用 assess_tech_maturity。 趋势数据告诉你某个框架的发展方向，成熟度则告诉你它目前的状况。做迁移决策时，两者都需要参考。

6. 如果要向多位用户或可能循环调用工具的 Agent 提供此 MCP，请为 Apify 运行设置支出限额。 服务端会妥善处理达到限额的事件，并返回可解析的错误。

7. 在 Agent 记忆中缓存 generate_tech_report 的结果。 完整报告内容全面；除非技术发生变化，否则 Agent 无需在每个会话中重复运行。评估新披露的 CVE 时，detect_tech_vulnerabilities 等单项工具则适合使用最新结果。

与其他 Apify Actor 和 MCP 结合使用

Actor / MCP	组合使用方式
Website Tech Stack Detector	单独运行以审计竞争对手的网站，再将检测到的技术传入 detect_tech_vulnerabilities
Company Deep Research	将公司情报与技术栈风险结合起来，全面评估供应商或收购目标
OSS Dependency Risk MCP	将此 MCP 检出的 CVE 暴露情况与供应链依赖分析结合，以全面覆盖开源风险
Website Content to Markdown	将技术文档网站转换为 markdown，以便借助大模型分析 API 稳定性和破坏性变更
NVD CVE Vulnerability Search	针对 detect_tech_vulnerabilities 结果中出现的特定 CVE ID，直接查询相关 CVE
GitHub Repo Search	生态系统映射识别出关键项目后，深入查询特定仓库
Startup Due Diligence	将技术生态系统风险评分作为创业公司技术风险评估的输入信号

局限性

• 数据时效性取决于来源 API。 GitHub 和 StackExchange 的结果反映查询时的当前状态。NVD 的 CVE 数据反映已公开披露的漏洞——零日漏洞按定义不在数据库中。
• 评分基于信号，而非权威结论。 成熟度和采用度评分源自公开活动信号。某项技术可能 GitHub 星标很多，但企业生产质量不佳；也可能星标很少，却得到机构广泛采用。
• 技术名称匹配使用子字符串搜索。 查询 “Go” 也会匹配 “Django”、“MongoDB” 等。使用 “Golang” 或 “Go programming language” 等具体名称可提高筛选准确性。
• Wikipedia 年限提取取决于文章文本模式。 如果 Wikipedia 中没有符合已识别格式的发布年份，ageYears 默认值为 5，成熟度评分的准确性会降低。
• 没有历史趋势数据。 评分反映某个时间点的快照。该工具无法显示星标增长图表或 12 个月的 CVE 历史记录——只能显示当前状态。
• CVE 匹配基于文本，而非 CPE。 NVD Actor 根据描述和受影响产品名称匹配 CVE。对于常见技术名称，这可能导致误报；对于产品命名不明显的 CVE，也可能漏报。
• 并行 Actor 调用的超时时间为 180 秒。 对于较大的技术列表（10 项以上技术），在 Apify 平台负载较高时，部分 Actor 可能超时并返回部分数据。
• 检测网站技术栈需要 URL 可公开访问。 受密码保护、设置 IP 允许列表或屏蔽机器人的网站将不会返回技术数据。

集成

• Apify API — 通过 HTTP 从 CI/CD 流水线或安全工具触发评估运行
• Webhooks — 当 generate_tech_report 运行检测到严重 CVE 或风险级别变化时触发警报
• Zapier — 将生态系统分析结果连接到 Jira 工单创建流程，用于 CVE 修复工作流
• Make — 构建自动化的每周技术栈健康仪表板，并发送到 Slack 或电子邮件
• Google Sheets — 将采用度评分和成熟度分类导出到共享团队电子表格，用于维护技术雷达
• LangChain / LlamaIndex — 在 ReAct Agent 中将此 MCP 用作工具，以实现自主技术研究和推荐工作流

故障排除

所有技术的工具调用都返回空数组。 这通常意味着所有并行 Actor 调用都超时了，或者 Apify 令牌的额度不足。请检查 Apify 账户余额，并确保 Authorization 标头中传入的令牌拥有 Actor:run 权限。每次工具调用都需要消耗额度来运行底层 Actor。

CVE 结果似乎不完整，或包含无关的漏洞。 NVD Actor 使用文本匹配。请尝试使用更具体的技术名称，例如使用“Apache Log4j”而不是“Log4j”，或使用“OpenSSL”而不是“SSL”。“Java”或“Python”等宽泛词汇会匹配数千个无关 CVE，导致结果过多。

assess_tech_maturity 对所有技术都返回 ageYears: 5。 Wikipedia 文章提取未能按照可识别的模式找到发行年份。对于历史描述方式不同的技术，这种情况很常见。评分仍然有效，但年龄贡献会默认取最低值。请结合其他成熟度指标解读结果。

map_tech_ecosystem 返回的图谱较稀疏，边很少。 如果技术在 GitHub 结果中的共同出现频率较低，就会形成稀疏图谱。请使用通常会一起使用的相关技术，例如 ["React", "TypeScript", "Tailwind", "Vite"]，而不是 ["React", "Kubernetes", "PostgreSQL"] 这类互不相关的技术。

在 generate_tech_report 期间出现达到支出限额的错误。 完整报告是单次调用中成本最高的操作（一次计费事件）。如果出现此错误，说明运行级支出限额设置得过低。请在 Apify Console 的运行设置中提高限额，或者通过 API 调用 Actor 时设置更高的 maxTotalChargeUsd。

负责任地使用

• 此 MCP 仅访问来自开放数据库（GitHub、NVD、StackExchange、Hacker News、Wikipedia）的公开数据。
• NVD 的 CVE 数据属于美国政府的公共领域资料，不受使用限制。
• GitHub、StackExchange 和 Hacker News 数据受其各自的 API 服务条款约束。
• 请勿使用漏洞数据来攻击系统。CVE 信息仅用于防御性安全研究和风险评估。
• 有关网页抓取合法性的指导，请参阅 Apify 的指南。

❓ 常见问题

单次工具调用最多可以分析多少种技术？ 没有硬性限制。评分函数会处理输入数组中的所有技术。实际使用中，每次调用分析 1–10 种技术可获得最佳信噪比。列表过长（20 种以上）会稀释 GitHub 和 SO 查询结果，因为所有技术都会合并到单个搜索查询中。

技术生态分析能检测我自己的代码库中的漏洞吗？ 不能——此 MCP 分析的是技术本身（框架、语言或库），而不是你的特定版本或配置。它会获取某项技术所有公开已知的 CVE。你可以用它找出技术栈中存在哪些已知 CVE 的组件，然后对照实际依赖版本进行核查。

CVE 漏洞数据有多新？ 每次工具调用时，都会从美国国家漏洞数据库实时获取 CVE 数据。数据不会缓存——每次调用 detect_tech_vulnerabilities 或 score_tech_stack_risk 都会反映当前已发布的 CVE 数据库状态。

技术生态分析适用于专有技术或内部技术吗？ 技术必须在 GitHub、StackOverflow 或 NVD 上留有记录，才能返回有意义的数据。内部工具或未发布的库会返回空结果。此功能适用于任何公开的框架、语言、数据库、云服务或开源库。 这与 Snyk 或 Dependabot 有什么不同？ Snyk 和 Dependabot 会分析锁定文件中的特定依赖项版本。此 MCP 会从社区和安全情报层面分析技术生态系统，包括采用趋势、成熟阶段、开发者情绪和生态系统健康状况。两者互为补充：使用 Snyk 修补特定版本的 CVE，使用此 MCP 进行战略性技术选型和风险评分。

我可以安排此 MCP 自动运行吗？ 可以。你可以通过 Apify API 按计划触发该 Actor（使用 Apify Scheduler 或任何 cron 服务）。每次定时运行都会连接到 MCP 服务，并调用你配置的工具。这适用于每周监控技术栈健康状况，例如在出现新的严重 CVE 时发出提醒。

每次工具调用的典型响应时间是多少？ 每次工具调用最多会并行执行 4 次 Actor，单次超时时间为 180 秒。典型延迟为 15–45 秒，具体取决于数据源的响应时间。generate_tech_report 耗时最长，因为它会同时运行全部 6 个数据源。

抓取 GitHub、StackOverflow 和 Hacker News 的数据合法吗？ 所有数据源均通过其官方公共 API 访问，而非通过网页抓取。GitHub Search API、NVD 的 REST API、StackExchange API 和 Hacker News Firebase API 均可公开使用。请参阅 Apify 关于网页抓取合法性的指南。

我可以在商业产品或报告中使用输出结果吗？ 可以。NVD 数据属于美国政府公有领域数据。根据其服务条款，GitHub 和 StackExchange API 数据通常可用于分析和报告。重新分发前，请根据你的具体使用场景查看各数据源的条款。

如果某次工具调用期间，底层 Actor 之一发生故障，会怎样？ runActorsParallel 函数会捕获每个 Actor 的错误，并为对应数据源返回空数组。评分函数能够妥善处理数据缺失：它们只会在相关评分项中计为零，而不会抛出错误。该工具始终会返回结果；但如果部分数据源发生故障，结果的可信度可能会降低。

S 曲线阶段与趋势方向有什么区别？ 趋势方向（up/stable/down）反映短期动能，依据过去 30 天的 StackOverflow 活动量与历史总量进行判断。采用阶段（emerging/growing/mature/declining）则是生命周期分类，结合星标数量阈值和 6 个月内的增长率进行判断。一项技术可能处于 mature 阶段，同时趋势为 stable，甚至是 down——对于成熟技术而言，这很正常。

帮助我们改进

如果你遇到问题，可以在 Apify 账户中启用运行共享，帮助我们更快地排查问题：

1. 前往 账户设置 > 隐私
2. 启用 与公开 Actor 创建者共享运行记录

这样，当出现问题时，我们就能查看你的运行详情，从而更快地修复问题。只有该 Actor 的开发者能看到你的数据，公众无法查看。

支持

发现错误或有功能建议？请在此 Actor 页面上的 问题选项卡中提交问题。有关自定义评分算法、其他数据源或企业集成，请通过 Apify 平台联系我们。