当我们停止对 AI Agent 进行手动更新时，Agent 的能力演进通常就会中断。尽管 GitHub 上每天都有大量新的开源工作流与架构设计，但要想把这些成果转化为 Agent 可用的能力，依然高度依赖人工搜寻、阅读与编写。
为了解决这一效率瓶颈，@**Daniel García** 设计并实现了一套自动化系统，能够持续扫描 GitHub、提取可复用的工作流并将其标准化为 Agent Skill，实现 Agent 能力的自主扩展。
整体架构设计
在深入各个独立 Agent 的细节之前，我们先来看系统的全局架构。
表面上看它是一条单一生产线，实际上每个 Agent 仅承担一项明确的职责，并将结构化输出传递给下一阶段。这种单一职责拆分保证了各个组件的简洁性，降低了维护难度，也允许单个 Agent 在不破坏整体系统的前提下独立升级。
系统没有试图用单个庞大的 Prompt 解决所有问题，而是将任务拆解为 8 个粒度更小的步骤。每个 Agent 只专注于做好一件事，处理完结构化数据后向下传递，无需了解整套系统的全貌。
各阶段的运作逻辑如下：
Scout：发现候选仓库
起点是回答一个问题：新的技术方案从何而来？
在这个系统中，答案是 GitHub。Scout 负责持续监控 GitHub Trending 以及特定的 GitHub Search 查询，寻找可能包含新 AI 工作流、Agent 架构或工程范式的仓库。该组件不读取仓库细节，也不对代码质量做判断，而只做一件事——发现候选对象并传递至下一阶段。
一个典型的查询逻辑如下：
Query:
("agent framework" OR langgraph OR mcp OR "multi-agent")
Filters:
stars:>100
pushed:>2026-06-01
language:Python
archived:false
sort:updated-desc
在进入模型分析之前，被发现的仓库已经被整理为结构化对象：
{
"name": "awesome-mcp-server",
"stars": 842,
"language": "Python",
"last_updated": "2026-07-09T14:32:00Z",
"status": "QUEUED"
}
输入：GitHub Trending、GitHub Search
输出：新发现的仓库列表
Filter：过滤机制
发现仓库只是基础，难点在于筛选出有价值的目标。绝大多数仓库并不包含可复用的 AI 工作流。如果在游戏、CSS 框架、数据集或入门模板上运行后续的 LLM 分析，会造成算力与 Token 的浪费。在仓库被提交给 LLM 处理之前，Filter 这步会先剔除不相关的项目。
具体做法是，Filter 先应用一组确定性规则（Deterministic rules，即基于固定逻辑条件而无需概率推理的硬性判断规则），进行初步分类。
判定保留的输出示例：
{
"repository": "awesome-mcp-server",
"category": "AI Agent",
"language": "Python",
"decision": "KEEP",
"reason": "Contains reusable agent workflows"
}
判定剔除的输出示例：
{
"repository": "css-animation-library",
"category": "CSS",
"language": "TypeScript",
"decision": "REJECT",
"reason": "Outside AI workflow scope"
}
Filter 这么做的目标是拦截比较明显的噪声，让成本较高的分析阶段聚焦在有潜力的目标上。
Reader：按需阅读
Reader 是整套生产线中的关键环节之一。许多仓库分析工具会直接扫描源代码，但这么做效率太低。结构良好的仓库通常会在文档中阐明其架构设计。因此，Reader 会严格按照以下顺序增量加载上下文：
README
↓
docs/
↓
examples/
↓
package.json
↓
requirements.txt
↓
source code
只有当上一步提供的信息不足时，Reader 才会读取下一步。在多数情况下，文档和示例已经足够说明工作流逻辑，系统可以跳过源代码解析。
Reader 增量构建上下文的输出格式如下：
{
"repository": "langgraph-agent",
"context_loaded": [
"README",
"docs/workflows.md",
"examples/basic_agent.py"
],
"source_code_loaded": false,
"decision_reason": "Workflow identified before code analysis."
}
这种增量读取方式降低了 Token 消耗与推理开销。系统无需先学习实现细节，而是优先理解项目的实际运行逻辑。
Workflow Extractor：提取工作流
这一步非常关键，目标是要识别出值得复用的工作流。如果未找到符合要求的工作流，仓库会直接退出生产线；如果找到，工作流会被提取为后续节点皆可解析的标准化结构。
Extractor 提取出的完整工作流结构如下：
{
"skill_name": "github-pr-reviewer",
"goal": "Review GitHub pull requests before merge",
"inputs": [
"Pull Request URL",
"Repository Context"
],
"steps": [
"Read changed files",
"Identify risky modifications",
"Check coding standards",
"Generate review comments"
],
"outputs": [
"Review Summary",
"Action Items"
],
"failure_modes": [
"Missing project context",
"Large architectural refactor"
]
}
从这一步开始，生产线将不再处理原始仓库，而是直接针对提取出的可复用工作流进行操作。
Skill Score：质量打分
是否所有工作流都适合转化为 Agent Skill？答案是否定的。在生成 Skill 之前，提取出的工作流需要经过客观评估。系统会通过预设的硬性规则引擎进行校验，避免引入额外的模型判断。
评估指标如下表所示：
| 检查项 | 结果 |
| README 是否存在 | ✅ |
| 示例代码是否存在 | ✅ |
| 工作流步骤是否 ≥ 3 步 | ✅ |
| 是否具备可复用性 | ✅ |
| 是否具备通用性 | ✅ |
| 置信度是否 > 0.85 | ✅ |
若有任意一项未通过，该工作流就会被拒绝。评估输出为结构化 JSON：
{
"skill_name": "github-pr-reviewer",
"score": 0.94,
"checks": {
"readme": true,
"examples": true,
"min_steps": true,
"reusable": true,
"general_purpose": true
},
"decision": "PASS"
}
这里采用的是规则引擎而非 LLM，目的是通过更低成本获取更高的处理速度、以及更具确定性的校验结果。
Skill Generator：技能生成
通过校验的工作流会在此阶段转化为标准化的 Agent Skill 包。
无论工作流源自何种架构或仓库，Skill Generator 都会将其统一转换为固定格式，确保其他 Agent 可以直接加载。
生成的 Skill 定义文件：
name: github-pr-reviewer
version: 1.0.0
description: Review GitHub pull requests and generate actionable feedback.
inputs:
- github_pull_request
- repository_context
steps:
- Read changed files
- Identify risky modifications
- Verify coding standards
- Generate review comments
outputs:
- review_summary
- review_comments
tags:
- github
- code-review
- engineering
生成器同时会创建配套的文件目录规范：
github-pr-reviewer/
├── SKILL.md
├── examples.md
├── commands.md
├── metadata.json
└── tests.md
通过统一数据格式，从 LangGraph 项目提取的工作流与从 MCP 服务器提取的工作流在转化后保持一致，上层 Agent 无需关注其初始来源。
Reviewer：独立审核
Reviewer 唯一的职责是评估生成的 Skill 是否具备发布价值，它不参与任何代码生成或修改逻辑。生成 Skill 的 Agent 不应当同时承担质量裁决工作，将生成与审核解耦能够提升系统的可靠性。
其 Prompt 逻辑设定非常直接：
Would an experienced engineer install this Skill without editing it?
Answer only:
YES or NO
Explain your reasoning in one paragraph.
Point out any missing assumptions or unclear steps.
If NO, suggest the minimum changes required for approval.
Do not rewrite the entire Skill.
典型的审核结果如下：
{
"decision": "YES",
"confidence": 0.96,
"reason": "The workflow is reusable, clearly documented and can be applied outside the original repository."
}
如果判定为 NO，生产线在此中断；若判定为 YES，则进入最终阶段。
Publisher：自动化发布
审核通过后，后续流程由自动化工具接管。Publisher 在独立分支上准备 Release，不直接修改主分支。操作路径如下：
GitHub Action
↓
创建分支（Create Branch）
↓
提交 Skill 包（Commit Skill Package）
↓
发起 Pull Request（Open Pull Request）
↓
指派审核员（Assign Reviewer）
生成的 Pull Request 包含全部必要文件：
Title:
Add Skill: github-pr-reviewer
Files:
✓ SKILL.md
✓ examples.md
✓ commands.md
✓ metadata.json
✓ tests.md
所有的 PR 均不会自动合并。生产线负责发现仓库、提取工作流、生成格式化 Skill 并准备 PR，而最终的合并决定权仍交由人类工程师。
结语
目前，大部分 AI 工具获取新能力的前提是要人类先完成发现与适配。这套系统的目的在于消除该自动化断层。通过将“发现仓库 $$\rightarro$$ 理解结构 $$\rightarro$$ 提取工作流 $$\rightarro$$ 转换 Skill”全流程转化为多 Agent 协作生产线，自动过滤弱需求方案，仅将高置信度的 Skill 提交至最终审核。
这并非为了取代工程师，而是剔除机械化的搜寻与清洗工作，让工程师将精力聚焦在更重要的核心决策问题上。Agent 也不应仅依赖一次性的训练，而是通过生产线机制，持续从人类每天构建的开源项目中吸收与演进能力。
