Skills+Radio+Memory：AI 编程"水电煤"基础设施三层架构深度拆解

前言：一个被低估的技术拐点

2026年8月8日，GitHub Trending 前10名中有8席是 AI Agent 项目——这不是偶然事件，而是 AI 编程基础设施正在完成一次质的跃迁。

如果你还在问"AI 能不能帮我写代码"，你已经错过了问题的核心。真正值得关注的转变是：AI 编程正在形成一套可复用、可替换、可标准化的"水电煤"基础设施——Skills（技能层）、Radio（通信层）、Memory（记忆层），这三层正在重构整个开发工作流。

本文从架构设计层面深度拆解这三层基础设施的工作原理、核心项目对比、生产落地实践，以及作为程序员如何在这场变革中找到自己的定位。

一、从"单点 AI"到"协作式 AI"：为什么三层架构必然出现

1.1 单 Agent 模式的三个致命瓶颈

2023-2025 年间，开发者使用 AI 编程的主流范式是"单点 AI"：一个 prompt 进去，一段代码出来。这种模式在简单任务上效率惊人，但当任务复杂度上升时，三个根本性瓶颈立即暴露：

第一个瓶颈：上下文窗口不是无限的。 即便是支持 100 万 Token 上下文的模型，当一个项目的代码量达到一定规模，AI 的"记忆"就会开始遗忘。更关键的是，每次新的对话都是一次全新的上下文加载，历史积累无法复用。

第二个瓶颈：单一 prompt 无法表达完整工程流程。 一个真实的工程任务包含：需求分析 → 技术方案设计 → 编码实现 → 单元测试 → 集成测试 → 代码审查 → 部署文档。单次 prompt 只能覆盖其中一个环节，用多个 prompt 串联则缺乏一致性和可追溯性。

第三个瓶颈：AI 之间无法协作。 当一个 AI 在写后端 API，另一个 AI 在写前端组件，它们的命名风格、错误处理方式、日志规范可能完全不同。这种碎片化的 AI 使用方式，反而可能增加代码不一致性。

1.2 三层架构的本质：分工与协作

三层架构的出现，正是为了解决这三个瓶颈：

这三层的协同工作，将 AI 编程从"一个人用 AI"升级为"一个团队用 AI"——只不过这个团队的成员都是 AI Agent。

二、Skills 层：标准化任务技能包的设计哲学

2.1 什么是 Skill？为什么它不同于 Prompt？

理解 Skills 的本质，需要先厘清它与传统 Prompt 的根本区别：

Prompt 是指令，Skill 是能力。 一个 Prompt 告诉你"做什么"，一个 Skill 封装了"怎么做"的完整流程——包括前置条件、验证标准、错误处理、回退策略。

以 mattpocock/skills 项目为例，一个典型的 Skill 目录结构如下：

engineering/
├── implement/
│   ├── SKILL.md          # 技能定义文件
│   ├── BEFORE.md         # 执行前的检查清单
│   ├── STEPS.md          # 分步执行指南
│   └── VERIFY.md         # 验证标准
├── debug-with-tests/
│   ├── SKILL.md
│   ├── DIAGNOSTIC.md     # 诊断树
│   └── FIXES.md          # 常见修复方案
└── write-tests/
    ├── SKILL.md
    └── TEMPLATES.md      # 测试模板

这种结构带来的改变是根本性的：Skill 将工程最佳实践编码为可执行、可验证、可复用的模块。当你调用一个 Skill 时，AI 不是在执行一个一次性指令，而是在按照一套经过验证的工程流程工作。

2.2 三大主流 Skills 框架深度对比

mattpocock/skills：TypeScript 之神的工程规范

定位：面向 TypeScript/前端工程师的生产级 Skills 框架。

核心特点：

# 安装方式
npx skills@latest add mattpocock/skills

# 交互式配置
npx skills@latest wizard

18 个核心 engineering Skills 覆盖了完整的开发周期：

• implement：从需求到可交付代码的完整流程
• debug-with-docs：基于文档的调试方法论
• grill-with-docs：深度质疑式需求澄清
• to-spec：严格对照规格的实现验证

为什么 mattpocock/skills 值得重点关注？

第一，作者是 Matt Pocock——TypeScript 社区的顶级人物，Total TypeScript 创始人。他的 Skills 不是理论推导，而是从真实工程经验中提炼出来的。每一个 Skill 都经过了他自己在实际项目中的反复验证。

第二，Star 增长曲线惊人：从 0 到 10 万 star 的速度超过了 2023 年的 LangChain。这说明市场需求真实存在，而非资本催熟的泡沫。

第三，框架设计克制而务实。没有复杂的 Agent 编排、没有多余的中间件，只有一系列可以直接用的 Skills。这种"少即是多"的设计哲学，正是工程化所需。

addyosmani/agent-skills：Chrome 团队的工程实践

定位：跨行业通用的 Skills 库，偏前端友好。

核心特点：addyosmani 是 Chrome 团队的核心工程师，他的 Skills 库更强调通用性和跨行业复用。相比 mattpocock/skills 偏 TypeScript/测试驱动，agent-skills 更侧重于前端开发场景的具体 Skill 实现。

obra/superpowers：复杂任务编排的高级技能集

定位：面向复杂业务流的超级技能编排。

核心特点：superpowers 不满足于"单个 Skill 做好一件事"，它的设计目标是让多个 Skills 按照复杂逻辑编排，实现真正的"任务自动化"。如果说 mattpocock/skills 是 Einzel Skills，superpowers 就是 Combo Skills。

2.3 Skills 标准化的工程价值：为什么它是"水电煤"

Skills 的真正价值，不在于某一个具体的 Skill，而在于Skills 标准化带来的工程能力跃迁：

可复用性：今天给医疗项目写的"患者数据验证"Skill，明天改一改可以用于金融项目的"账户验证"场景。Skills 的复用粒度从"代码片段"升级为"完整工程流程"。

可审计性：当一个 Skill 被调用时，它的 SKILL.md 就是一份完整的操作记录——谁在什么时候调用了什么 Skill，做了什么验证，有什么结果。这比传统的 commit log 更有价值，因为它记录的是决策逻辑而非只是代码变更。

可替换性：当更好的模型出现时，你不需要重写所有 prompt，只需要替换底层的 Skill 实现。这就是 Claude Code 之父"半年清空"建议的本质：保持 Skill 的可替换性比积累 Skill 的数量更重要。

2.4 Skills 的反直觉最佳实践

这里有一个容易被忽视的重要观点：Skills 不是越多越好，而是越标准化越好。

Claude Code 之父提出的"每半年清空一次 claude.md、skills、hooks"建议，初听起来反直觉——为什么要主动删除积累的知识？但仔细想想，这背后有深刻的工程逻辑：

1. 知识沉淀的债务性：当一个 Memory 或 Skill 积累得越深，它的替换成本就越高。一个依赖了 50 个自定义 Skills 的项目，在切换到新模型或新框架时，迁移成本可能是毁灭性的。

2. 标准化的价值高于积累：与其让每个团队成员积累大量私有 Skills，不如建立一套所有人都遵守的标准 Skills。这与 Linux 的设计哲学一脉相承：小工具、可组合、可替换。

3. 定期清空让架构保持活力：每半年重新审视 Skills 体系，删除过时的、合并重复的、标准化接口——这比无限制积累更能让 Skills 体系保持健康。

三、Radio 层：多 Agent 通信协议的架构演进

3.1 为什么 Radio 层必然独立

当多个 AI Agent 需要协作时，第一个问题是：它们之间如何通信？

这个问题看似简单，实则复杂。多个 Agent 协作时面临的核心挑战包括：

消息格式的统一：Agent A 发出的消息，Agent B 必须能正确解析。如果每个 Agent 都用自己定义的格式，集成成本将指数级上升。

通信协议的标准化：HTTP 在互联网中的地位，是因为它提供了一套标准的请求-响应语义。Agent 通信也需要类似的标准化协议。

网络拓扑的灵活性：不是所有 Agent 协作都遵循"一问一答"模式。有些场景需要广播（一个 Agent 通知多个 Agent），有些需要扇出（一个任务分解给多个 Agent 并行处理），有些需要扇入（多个 Agent 的结果汇聚给一个 Agent）。

Radio 层的出现，正是为了解决这三个问题。

3.2 MCP：Radio 层的"HTTP 协议"

MCP（Model Context Protocol）是 Anthropic 提出的 Agent 通信协议规范，它之于 Radio 层，类似于 HTTP 之于互联网：

• MCP 是协议规范：定义了消息格式、传输语义、能力发现机制
• prime-agent 是 MCP 的开源实现：提供完整的协议栈和工具链
• cloudflare/computer 是 MCP 的网络加速：在协议之上提供边缘计算和低延迟传输

这种"协议规范 + 多种实现"的模式，是互联网基础设施演化的标准路径。MCP 不会由单一项目垄断——它会成为 Radio 层的"事实标准"，就像 TCP/IP 成为网络协议的事实标准一样。

3.3 MCP 的核心架构

MCP 的设计哲学是能力导向（Capability-Oriented）：每个 Agent 声明自己支持哪些能力（Capability），其他 Agent 通过能力发现（Capability Discovery）来了解谁可以做什么。

┌─────────────────────────────────────────────────────────────┐
│                      MCP Registry                           │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐                  │
│  │ Agent A  │  │ Agent B  │  │ Agent C  │                  │
│  │ capabilities: │ │ capabilities: │ │ capabilities: │    │
│  │  - code_gen  │ │  - code_review│ │  - testing  │       │
│  │  - testing   │ │  - refactor   │ │  - deploy   │       │
│  └─────┬──────┘ └─────┬──────┘ └─────┬──────┘            │
│        │               │               │                   │
│        └───────────────┼───────────────┘                   │
│                        │                                   │
│              MCP Protocol (HTTP/WebSocket)                  │
└─────────────────────────────────────────────────────────────┘

MCP 的核心消息类型：

// 1. 能力声明 (Capability Declaration)
{
  "type": "capability",
  "agent": "code-gen-agent",
  "capabilities": [
    { "name": "write_code", "params": ["spec", "language"], "returns": "code" },
    { "name": "refactor", "params": ["code", "goal"], "returns": "code" }
  ]
}

// 2. 任务分发 (Task Dispatch)
{
  "type": "dispatch",
  "from": "orchestrator",
  "to": ["code-gen-agent", "test-agent"],
  "task": {
    "id": "task-001",
    "type": "parallel",
    "items": [
      { "agent": "code-gen-agent", "spec": "...", "priority": 1 },
      { "agent": "test-agent", "spec": "...", "priority": 2 }
    ]
  }
}

// 3. 结果汇报 (Result Report)
{
  "type": "result",
  "agent": "code-gen-agent",
  "task_id": "task-001",
  "status": "success",
  "output": { "files": [...], "artifacts": [...] },
  "metadata": { "duration_ms": 2341, "tokens_used": 8900 }
}

// 4. 错误报告 (Error Report)
{
  "type": "error",
  "agent": "test-agent",
  "task_id": "task-001",
  "error": {
    "code": "ASSERTION_FAILED",
    "message": "Test coverage below threshold: 72% < 85%",
    "context": { "file": "auth.go", "line": 234 }
  }
}

3.4 prime-agent：去中心化的 Agent 通信网络

prime-agent 是当前 Radio 层最火热的开源项目，核心设计理念是去中心化的 Agent 通信网络：

# prime-agent 的核心使用示例
from prime_agent import Agent, Radio

# 创建 Agent 实例
code_agent = Agent("code-gen", capabilities=["code_generation", "refactoring"])
review_agent = Agent("review", capabilities=["code_review", "security_scan"])
test_agent = Agent("test", capabilities=["unit_test", "integration_test"])

# 构建 Radio 网络
radio = Radio()
radio.register(code_agent)
radio.register(review_agent)
radio.register(test_agent)

# 任务分发
task = {
    "id": "build-auth-module",
    "description": "实现 JWT 认证模块",
    "skills": ["mattpocock/implement", "security/jwt-basics"]
}

# 自动路由到合适的 Agent
result = radio.dispatch(task)
# Radio 会根据 Agent 的 capabilities 自动选择合适的处理者

prime-agent 的优势在于标准化 + 去中心化：任何遵循 MCP 规范的 Agent 都可以接入这个网络，不需要中心化的协调者。这与互联网的设计哲学高度一致：网络的价值与节点数的平方成正比。

3.5 cloudflare/computer：边缘节点的 Agent 基础设施

cloudflare/computer 是 Cloudflare 提供的 Agent 网络接口，本质上是 MCP 协议在边缘节点上的实现：

# cloudflare/computer 的核心价值
# 1. 低延迟：边缘节点处理 Agent 通信请求
# 2. 全球分布：Agent 之间跨地域协作无障碍
# 3. 安全隔离：Cloudflare 的安全层自动保护 Agent 通信
# 4. 免运维：不需要自己搭建 Agent 网络基础设施

两者不是竞争关系，而是互补关系：

• prime-agent = Agent 通信的"TCP/IP 协议栈"
• cloudflare/computer = Agent 通信的"CDN 加速层"

开发者完全可以同时使用两者——用 prime-agent 定义协议和路由逻辑，用 cloudflare/computer 提供全球分布的低延迟传输。

四、Memory 层：跨越会话的长期记忆架构

4.1 Memory 层的核心挑战

如果说 Skills 层和 Radio 层的挑战是"工程化"，Memory 层的挑战则是"哲学化"——因为记忆的本质问题，比技术实现更深层：

持久化问题：记忆必须跨任务、跨会话持久化。今天构建的 AI 助手，明天打开时还记得上周讨论的架构决策吗？

检索问题：当记忆积累到一定规模，如何快速检索相关片段？一个管理 10 万行记忆的系统，如何在毫秒级找到当前任务最相关的 100 行？

遗忘问题：这是最反直觉的挑战。人类之所以能够正常运转，正是因为我们有遗忘机制。AI 记忆系统面临同样的问题——哪些记忆应该保留？哪些应该遗忘？如何平衡"积累"与"债务"？

4.2 两种 Memory 架构路径

路径一：显式记忆（Explicit Memory）

开发者主动写入和读取的 Memory，类似传统数据库：

# 显式 Memory 的典型实现
class ExplicitMemory:
    def store(self, key: str, value: Any, ttl: Optional[int] = None):
        """显式存储一段记忆"""
        memory = {
            "key": key,
            "value": value,
            "created_at": time.time(),
            "access_count": 0,
            "ttl": ttl
        }
        self.db.insert("memories", memory)
    
    def recall(self, query: str, top_k: int = 5) -> List[Memory]:
        """基于语义检索记忆"""
        embeddings = self.embedding_model.encode(query)
        results = self.vector_db.search(embeddings, top_k=top_k)
        return results
    
    def forget(self, key: str):
        """主动遗忘一段记忆"""
        self.db.delete("memories", f"key = '{key}'")

显式记忆的优势是可控：开发者清楚地知道什么被记住了，可以主动管理。劣势是负担重：需要人工维护记忆的增删改查。

路径二：隐式记忆（Implicit Memory）

Agent 自动学习、遗忘的 Memory，类似人脑的长期记忆：

# 隐式 Memory 的典型实现
class ImplicitMemory:
    def __init__(self, model, memory_decay_rate: float = 0.01):
        self.model = model  # 记忆编码模型
        self.decay_rate = memory_decay_rate
        self.memory_strength = {}  # 记忆强度衰减追踪
    
    def strengthen(self, event: str, reward: float):
        """强化某段经历（基于强化学习）"""
        embedding = self.model.encode(event)
        key = hash(embedding)
        self.memory_strength[key] = self.memory_strength.get(key, 0) + reward
    
    def decay(self):
        """定期衰减记忆强度"""
        for key in self.memory_strength:
            self.memory_strength[key] *= (1 - self.decay_rate)
    
    def recall(self, cue: str, threshold: float = 0.3) -> List[str]:
        """检索记忆，只返回强度超过阈值的记忆"""
        cue_embedding = self.model.encode(cue)
        candidates = self.vector_db.search(cue_embedding, top_k=100)
        return [
            m for m in candidates 
            if self.memory_strength.get(hash(m.embedding), 0) > threshold
        ]

隐式记忆的优势是无感：Agent 自动管理记忆，开发者无需干预。劣势是不可控：记忆的形成和消失由模型驱动，可能产生意外结果。

4.3 华为诺亚 MindMemOS：可迁移的自演进记忆层

2026年8月3日，华为诺亚方舟实验室开源的 MindMemOS 是 Memory 层的一个重要突破。它的核心设计理念是可迁移 + 自演进：

# MindMemOS 的核心架构
class MindMemOS:
    def __init__(self):
        self.memory_layer = HierarchicalMemory()
        self.skill_evolver = SkillEvolution()
        self.migration_engine = MigrationEngine()
    
    def remember(self, agent_id: str, content: MemoryContent):
        """记忆存储，支持跨 Agent 迁移"""
        # 分层存储：工作记忆 → 情境记忆 → 长期记忆
        self.memory_layer.store(agent_id, content)
        
        # 如果同一类任务被多次执行，自动提炼为可迁移的 Pattern
        if self.pattern_detector.detect_repetition(agent_id, content):
            pattern = self.pattern_extractor.extract(content)
            self.skill_evolver.evolve(pattern)
    
    def migrate(self, from_agent: str, to_agent: str, what: MemoryScope):
        """跨 Agent 记忆迁移"""
        # 迁移不是简单复制，而是格式转换
        memories = self.memory_layer.get(from_agent, scope=what)
        migrated = [
            self.migration_engine.convert(m, target=to_agent)
            for m in memories
        ]
        self.memory_layer.store(to_agent, migrated)
    
    def forget(self, agent_id: str, strategy: ForgetStrategy):
        """遗忘管理"""
        if strategy == "age_based":
            self.memory_layer.prune_by_age(agent_id)
        elif strategy == "utility_based":
            self.memory_layer.prune_by_utility(agent_agent, threshold=0.2)
        elif strategy == "periodic":
            self.memory_layer.prune_periodic(agent_id, interval_days=180)

MindMemOS 的三个创新点值得深入理解：

第一，记忆分层。不是所有记忆都应该平等对待。工作记忆（当前任务上下文）、情境记忆（近期项目状态）、长期记忆（跨项目的工程知识）有不同的生命周期和检索模式。分层存储让记忆管理更精细。

第二，Pattern 自动提炼。当同一类任务被多次执行时，系统自动提炼为可复用的 Pattern。这些 Pattern 不是简单的记忆，而是经过抽象和泛化的高价值知识。

第三，跨 Agent 迁移。这是最有价值也最难实现的功能。当一个 Agent 积累了大量经验后，这些经验应该能够迁移给另一个 Agent——不是简单复制，而是格式转换和适配。

4.4 "半年清空"方法论的深层逻辑

Claude Code 之父建议"每半年清空一次 claude.md、skills、hooks"，这个建议的深层逻辑值得深入挖掘：

第一，防止 Memory 成为技术债务。 当一个项目的 Memory 积累得越深，它的替换成本就越高。半年清空相当于一次"软重置"，让系统保持活力。

第二，促进 Skill 的标准化。 如果每个开发者都积累大量私有 Skills，团队内部的 Skill 体系就会碎片化。定期清空迫使团队建立共享的标准 Skills，而不是私有积累。

第三，模拟人类的遗忘机制。 认知科学的研究表明，遗忘不是缺陷，而是 feature——它帮助人类过滤噪音、保留关键信息。AI 记忆系统也需要类似的机制。

这个建议的本质是：Memory 的价值不在于积累，而在于标准化和可替换。

五、三层协同：从工具到工作流

5.1 一个完整的 AI 协作工作流

三层架构的真正威力，只有在协同工作时才能体现。以下是一个典型的工作流示例：

场景：构建一个"用户认证模块"

阶段一：需求澄清（Skills + Memory）
├── 调用 mattpocock/skills 中的 "grill-with-docs" Skill
├── 从 Memory 中检索历史上类似项目的需求文档
└── 输出：经过深度质疑的完整需求规格

阶段二：技术方案设计（Skills + Radio）
├── 调用 "implement" Skill 生成技术方案
├── 通过 Radio 分发给多个 Agent 并行评估：
│   ├── 安全 Agent：评估 JWT 实现的安全性
│   ├── 性能 Agent：评估高并发场景的可行性
│   └── 兼容性 Agent：评估跨平台支持的实现难度
└── 汇总多 Agent 反馈，生成最终技术方案

阶段三：编码实现（Skills + Memory）
├── 调用 "implement" Skill 进行编码
├── 编码过程记录到 Memory，供后续项目复用
└── 输出：完整的认证模块代码

阶段四：测试验证（Skills + Radio + Memory）
├── 调用 "write-tests" Skill 生成测试用例
├── 通过 Radio 通知测试 Agent 执行测试
├── 测试结果存入 Memory，供回归测试使用
└── 输出：测试覆盖率报告 + 已知问题清单

阶段五：部署上线（Skills + Memory）
├── 调用部署 Skill 生成部署文档
├── 部署经验存入 Memory
└── 输出：部署清单 + 监控配置

5.2 三层架构的技术指标对比

六、生产落地：从概念到实践

6.1 快速上手 Skills 层

对于想尝试 Skills 层的开发者，建议从以下路径开始：

第一步：安装 mattpocock/skills

# Node.js 18+ 环境下安装
npx skills@latest add mattpocock/skills

# 交互式配置（推荐）
npx skills@latest wizard

第二步：体验核心 Skill

# 体验 implement Skill：标准化实现流程
npx skills@latest run implement --spec ./specs/auth-module.md --language typescript

# 体验 debug-with-docs Skill：基于文档的调试
npx skills@latest run debug-with-docs --file ./src/auth.ts --error "TypeError: Cannot read property 'verify'"

第三步：自定义 Skill

<!-- my-skills/validate-input/SKILL.md -->
# Validate Input Skill

## 目标
为任何 API 端点生成输入验证逻辑

## 输入
- endpoint_spec: 端点规格（JSON Schema）
- language: 目标语言（typescript | python | go）

## 验证规则
1. 类型检查必须严格
2. 必填字段必须显式验证
3. 范围检查必须包含边界值测试
4. 错误消息必须包含字段路径

## 输出格式
- 验证函数（含 JSDoc/注释）
- 单元测试（含边界值测试用例）
- OpenAPI Schema 更新

## 验证标准
- 所有必填字段必须覆盖
- 边界值测试用例 >= 3
- 错误消息可调试性强

6.2 Radio 层的最小可行架构

对于想尝试 Radio 层的团队，建议从最小可行架构开始：

# minimal_radio.py - 最小可行的 Agent 通信架构
import asyncio
from typing import List, Dict, Any
from dataclasses import dataclass, field
from enum import Enum

class AgentCapability(Enum):
    CODE_GEN = "code_generation"
    CODE_REVIEW = "code_review"
    TESTING = "testing"
    DOCUMENTATION = "documentation"

@dataclass
class Agent:
    name: str
    capabilities: List[AgentCapability]
    endpoint: str

class SimpleRadio:
    def __init__(self):
        self.agents: Dict[str, Agent] = {}
    
    def register(self, agent: Agent):
        self.agents[agent.name] = agent
    
    async def dispatch(self, task: Dict[str, Any]) -> Dict[str, Any]:
        # 简单路由：根据任务类型选择 Agent
        required_cap = self._infer_capability(task["type"])
        target = self._find_agent(required_cap)
        
        # 发送任务到目标 Agent
        response = await self._send_task(target, task)
        return response
    
    def _infer_capability(self, task_type: str) -> AgentCapability:
        mapping = {
            "generate": AgentCapability.CODE_GEN,
            "review": AgentCapability.CODE_REVIEW,
            "test": AgentCapability.TESTING,
            "document": AgentCapability.DOCUMENTATION,
        }
        return mapping.get(task_type, AgentCapability.CODE_GEN)
    
    def _find_agent(self, cap: AgentCapability) -> Agent:
        for agent in self.agents.values():
            if cap in agent.capabilities:
                return agent
        raise ValueError(f"No agent with capability {cap}")

# 使用示例
async def main():
    radio = SimpleRadio()
    radio.register(Agent("code-gen", [AgentCapability.CODE_GEN, AgentCapability.TESTING], "http://localhost:8001"))
    radio.register(Agent("review", [AgentCapability.CODE_REVIEW], "http://localhost:8002"))
    
    result = await radio.dispatch({
        "type": "generate",
        "spec": "用户认证模块",
        "language": "typescript"
    })
    print(result)

asyncio.run(main())

6.3 Memory 层的分层实践

# layered_memory.py - 分层 Memory 实现
from enum import Enum
from dataclasses import dataclass
from typing import Any, Optional
import time

class MemoryLayer(Enum):
    WORKING = "working"      # 当前会话，容量 100 条
    CONTEXTUAL = "contextual" # 当前项目，容量 1000 条
    LONG_TERM = "long_term"   # 跨项目，容量无限但检索成本高

@dataclass
class Memory:
    content: Any
    layer: MemoryLayer
    created_at: float = field(default_factory=time.time)
    access_count: int = 0
    importance: float = 1.0  # 0-1，越高越重要

class LayeredMemory:
    def __init__(self, llm_embedder):
        self.llm = llm_embedder
        self.layers = {
            MemoryLayer.WORKING: [],
            MemoryLayer.CONTEXTUAL: [],
            MemoryLayer.LONG_TERM: [],
        }
    
    def store(self, content: Any, layer: MemoryLayer):
        memory = Memory(content=content, layer=layer)
        self.layers[layer].append(memory)
        
        # 工作记忆满时，晋升到情境记忆
        if layer == MemoryLayer.WORKING and len(self.layers[MemoryLayer.WORKING]) > 100:
            oldest = self.layers[MemoryLayer.WORKING].pop(0)
            self.store(oldest.content, MemoryLayer.CONTEXTUAL)
    
    def retrieve(self, query: str, layer: Optional[MemoryLayer] = None) -> list:
        # 优先检索工作记忆
        if layer:
            return self._search_layer(self.layers[layer], query)
        
        # 分层检索：从工作 → 情境 → 长期
        for target_layer in [MemoryLayer.WORKING, MemoryLayer.CONTEXTUAL, MemoryLayer.LONG_TERM]:
            results = self._search_layer(self.layers[target_layer], query)
            if results:
                return results
        return []
    
    def _search_layer(self, memories: list, query: str) -> list:
        query_embedding = self.llm.embed(query)
        scored = []
        for m in memories:
            # 综合考虑相关性和重要性
            similarity = self._cosine_similarity(query_embedding, m.embedding)
            score = 0.7 * similarity + 0.3 * m.importance
            scored.append((score, m))
        scored.sort(key=lambda x: x[0], reverse=True)
        return [m for _, m in scored[:10]]
    
    def decay(self):
        """定期衰减不重要的记忆"""
        for layer in [MemoryLayer.CONTEXTUAL, MemoryLayer.LONG_TERM]:
            to_remove = []
            for m in self.layers[layer]:
                m.importance *= 0.99  # 自然衰减
                if m.importance < 0.1 and m.access_count < 2:
                    to_remove.append(m)
            for m in to_remove:
                self.layers[layer].remove(m)

七、2027 年展望：三层架构的演进方向

7.1 Skills 层的演进

垂直行业 Skills 将迎来爆发：mattpocock/skills 的成功证明，Skills 标准化的窗口期已经打开。接下来的机会在垂直行业——医疗 Skills、金融 Skills、教育 Skills、制造业 Skills，每个垂直领域都有可能诞生下一个"mattpocock/skills"。

Skills 互操作标准将出现：当前多个 Skills 框架并存的局面不会持续太久。2027 年有望出现一个 Skills 互操作标准，让开发者可以在不同框架之间迁移 Skills。

7.2 Radio 层的演进

MCP 将成为事实标准：Anthropic 的 MCP 协议有最好的起点（Claude 的生态）和最开放的设计（开源 + 社区驱动）。2027 年，MCP 有望成为 Agent 通信的事实标准，类似于 REST 在 2010 年代的位置。

边缘 Agent 网络将成熟：Cloudflare 的边缘 Agent 基础设施只是开始。2027 年，我们预计会看到更多边缘计算平台推出 Agent 专用的网络层，实现真正的"全球分布、低延迟协作"。

7.3 Memory 层的演进

记忆迁移将成为标配：华为 MindMemOS 开创的"可迁移记忆"方向将被更多项目跟进。当 Agent 在不同任务间切换时，记忆的迁移和复用将成为标配能力。

遗忘机制将更智能：当前的"定期清空"是粗粒度的解决方案。2027 年，我们预计会出现更智能的遗忘机制——基于实用价值、语义相关性、使用频率的多维度遗忘策略。

八、给程序员的行动指南

立即行动（今天）

1. 安装 mattpocock/skills：花 30 分钟体验核心 Skill，感受 Skills 层带来的改变
2. 选择一个项目实践：将一个日常开发任务用 Skills 标准化，记录效果
3. 关注 MCP 生态：订阅 MCP 的 GitHub 仓库，了解协议演进

三个月内

1. 建立团队 Skills 库：基于 mattpocock/skills，建立团队专用的 Skills 集合
2. 尝试 Agent 协作：用 prime-agent 或类似工具，让多个 AI Agent 协作完成一个任务
3. 设计 Memory 策略：为团队项目设计分层 Memory 方案

长期布局

1. 垂直行业 Skills 机会：如果你是某个垂直领域的专家，考虑创建该领域的 Skills 标准
2. Radio 层协议机会：参与 MCP 生态建设，成为 Agent 通信协议的标准制定者
3. Memory 层基础设施：构建企业级的 Memory 基础设施，成为"AI 记忆即服务"提供商

结语：不要问 AI 能不能写代码

回到文章开头的问题——不要再问"AI 能不能帮我写代码"。

真正值得问的问题是：我的 Skills+Radio+Memory 三层基础设施是否已经搭好？

当你开始用 Skills 标准化开发流程，用 Radio 连接多个 AI Agent，用 Memory 积累跨项目的工程知识，你就不再是一个"使用 AI 写代码"的程序员，而是一个构建 AI 编程基础设施"的架构师。

这个转变，才是 2026 年 AI 编程领域最重要的事情。

Tags: AI Agent | Skills | Radio | Memory | MCP | Agent协作 | 编程工具链 | 工程规范 | mattpocock | prime-agent | 三层架构 | 2026技术趋势

Keywords: AI Agent三层架构, Skills标准化, MCP协议, Radio通信层, Memory记忆层, prime-agent, mattpocock/skills, Agent协作工作流, AI编程基础设施, 2026技术趋势