小加号笔记

记忆 是 Agent 和「一次性聊天机器人」的根本分界线。能记住你昨天说过什么、记得自己擅长什么、记得项目里术语怎么用——这才像个「能长期协作的 Agent」。但 LLM 本身是「无状态」的，它没有记忆，所有「记忆」都要靠外部机制模拟。

本文借用认知心理学的记忆分类框架（工作记忆 / 情景记忆 / 程序性记忆），系统讲透 Agent 的记忆怎么设计、为什么会「失忆」、各类记忆的对应策略。如果你已读过本博客的「AI Agent 技能实战解析」，那篇讲的 Skills 其实就是本文说的「程序性记忆」——两篇互为补充。

先想一个很常见的场景：

你昨天让 Agent 帮你把登录功能重构，今天打开新会话说：

把昨天那个功能加个验证。

如果 Agent 能知道「那个功能」是哪个功能，还知道项目代码结构、测试用例，你会觉得它像一个连续协作的助手；如果它反问「哪个功能？代码结构是什么？」，你就会明显感觉它“断片”了。

这背后不是模型突然聪明或突然变笨，而是记忆系统有没有把正确的信息带到这一次调用里。

本文脉络：
  一    为什么 Agent 需要记忆：LLM 的「无状态」困境
  二    借用认知心理学：人类记忆的三分类
  三    工作记忆：上下文窗口与压缩
  四    情景记忆：会话历史与跨会话记忆
  五    程序性记忆：Skills 与知识库
  六    三类记忆的协同：一次完整调用怎么走
  七    常见「失忆」症状与诊断
  八    设计原则与陷阱
  九    面试速答

Superpowers 是一套「装在编码 Agent 上的软件开发方法论」，由一组可组合的 Skills 构成。它解决的不是「让 Agent 写代码更快」，而是「让 Agent 像一个靠谱的工程师那样工作」——先想清楚需求、再设计方案、然后写测试、按计划实现、互相 review、最后干净交付。

本文拆解它的 14 个核心 Skills、7 步工作流，以及它为什么能跨 Claude Code、Codex、Cursor、Antigravity 等十种 Agent 工具运行。如果你已经读过本博客的「AI Agent 技能实战解析」，这篇是它的进阶——看一个真实、完整、生产级的 Skills 体系长什么样。

本文脉络：
  一    Superpowers 是什么：不是工具，是方法论
  二    核心工作流：从想法到交付的 7 步
  三    14 个 Skills 全景：按职责分类
  四    设计哲学：TDD、系统化、证据驱动
  五    它是怎么「自动生效」的：session-start 注入
  六    跨 Agent 适配：一份 Skills，十种工具
  七    和单兵 Skill 的区别：为什么是「体系」
  八    上手与踩坑
  九    速查表

Matt Pocock 开源的 mattpocock/skills 是一套面向真实工程工作的 AI Agent 技能库。

它把需求澄清、领域建模、TDD、Bug 诊断、代码评审、任务拆分、PRD 编写等工程动作，拆成一组可以被 Claude Code / Codex 等 Agent 调用的 skills。使用它的重点，是让 Agent 按一套清晰流程协助工程工作。

本文脉络：

• 一、mattpocock-skills 提供了什么
• 二、skills结构：它是怎么组织起来的
• 三、如何安装和初始化
• 四、两类技能：用户主动调用与模型自动触发
• 五、核心使用流程：从想法到交付
• 六、几个代表性 Skill 解析
• 七、按场景怎么使用
• 八、一个简单示例
• 九、使用建议
• 十、总结

做 AI 应用时，很容易遇到三个听起来相近的问题：

• 我要不要让模型调用函数？
• 我要不要接 RAG？
• 我要不要做 MCP Server？

这三个东西都能让模型“连接外部世界”，但它们解决的问题并不一样。Function Calling 偏向“让模型调用应用里的函数”，RAG 偏向“让模型基于外部知识回答”，MCP 偏向“让 AI 应用用标准协议连接外部工具、数据和工作流”。选错了，轻则架构绕，重则权限失控、维护困难。

本文脉络：

• 一、先给结论：三者不是替代关系
• 二、Function Calling：应用内的函数调用接口
• 三、RAG：让模型带着外部知识回答
• 四、MCP：AI 应用连接外部能力的标准协议
• 五、核心区别：到底谁负责什么
• 六、怎么选：按问题类型做判断
• 七、怎么组合：真实系统里通常三者一起用
• 八、常见误区
• 九、速查表

上一篇文章讲了 MCP 的协议定位：它让 AI 应用能用统一方式连接外部工具和上下文。但真正落地时，最常见的问题不是“协议怎么定义”，而是“我到底该把什么能力接给 Agent”。

数据库是一个很好的起点。它足够真实，能明显提升 Agent 的分析能力；同时也足够危险，稍不注意就会把生产数据、写权限、慢查询和敏感信息一起暴露出去。本文用一个只读数据库 MCP Server，把“能用”和“安全”放在同一个示例里讲清楚。

本文脉络：

• 一、为什么先做只读数据库工具
• 二、目标架构：Host、MCP Server、MySQL 怎么配合
• 三、准备一个只读数据库账号
• 四、初始化 TypeScript MCP Server 项目
• 五、实现两个工具：查看表结构与只读查询
• 六、在 AI Agent 中配置 stdio MCP Server
• 七、实际对话效果：Agent 怎么用这个工具
• 八、安全护栏：不要只靠“提示词禁止写库”
• 九、从本地 stdio 进阶到远程服务
• 十、常见问题

电商下单系统 是系统设计面试里的经典题：它看起来只是“用户点一下提交订单”，背后却串起商品、价格、优惠、库存、订单、支付、履约、消息、风控、对账等多个子系统。

面试官真正想看的，不是你能不能画出很多服务，而是你能不能把关键矛盾讲清楚：如何防止重复下单，如何避免库存超卖，如何处理支付回调，如何保证订单状态最终一致，如何在大促高峰下削峰降级。

本文脉络：

• 一、题目理解：先把边界讲清楚
• 二、核心需求与非功能指标
• 三、容量估算：下单系统到底有多大压力
• 四、整体架构：同步链路短，异步链路长
• 五、下单主流程：从提交订单到待支付
• 六、库存设计：预占、确认、释放
• 七、支付设计：支付单、回调、对账
• 八、订单状态机：用状态流转保护一致性
• 九、数据模型与分库分表
• 十、幂等、一致性与补偿
• 十一、高并发与高可用设计
• 十二、常见追问

MCP（Model Context Protocol） 是一个让 AI 应用连接外部系统的开放协议。它把“模型要读哪些上下文、能调用哪些工具、有哪些可复用提示词”抽象成一套标准接口，让 AI Agent 不必为每个数据源、每个工具、每个应用都单独写一套集成逻辑。

如果把大模型看成大脑，MCP 就像它和现实世界之间的“标准接口层”：文件、数据库、搜索、日历、代码仓库、监控系统都可以通过 MCP Server 接进来，由 AI 应用统一发现、授权、调用和消费结果。

本文脉络：

• 一、为什么需要 MCP：AI 应用的“连接器爆炸”
• 二、MCP 是什么：给 AI 应用用的标准上下文协议
• 三、核心架构：Host、Client、Server 各做什么
• 四、三类服务端能力：Tools、Resources、Prompts
• 五、一次 MCP 调用是怎么发生的
• 六、本地与远程：stdio 和 Streamable HTTP
• 七、最小实战：创建一个 MCP Server，并让 AI Agent 调用
• 八、安全边界：为什么 MCP 不是“自动放权”
• 九、MCP 适合什么场景，不适合什么场景
• 十、MCP、Function Calling、RAG、Agent Skill 的区别
• 十一、常见问题

Skill（技能） 是现代 AI Agent（如 Claude、Codex 等）增强能力的主流方式：把某一类任务的「操作手册 + 工具 + 参考资料」打包成一个独立单元，Agent 在需要时自动加载、按章执行。它解决了「靠 prompt 硬塞所有规则」带来的臃肿、不可复用、上下文爆炸问题。

本文从一个真实的 Skill（技术写作技能）切入，讲透 Skill 是什么、三层加载机制怎么工作、SKILL.md 怎么写，以及设计一个好 Skill 的核心原则。如果你正在用 Claude Code / Codex / Cursor 等 Agent 工具，这篇能帮你从「只会写 prompt」升级到「会造工具」。

本文脉络：
  一    为什么 prompt 不够用：Agent 增强方式的演进
  二    Skill 是什么：三层加载机制
  三    SKILL.md 的结构：frontmatter + 正文
  四    渐进式披露：Skill 设计的第一原则
  五    实战案例：真实技能拆解 + 完整示例 + 怎么使用
  六    怎么写好一个 Skill：六个关键原则
  七    Skill vs Prompt vs 工具调用：什么时候用哪个
  八    常见误区与陷阱
  九    速查表

降级（Degradation） 是高可用系统应对故障的最后一道体验防线：当熔断已经跳闸、限流已经拒绝、下游确实调不通时，降级决定「这一刻给用户看到什么」。它不解决问题，它管的是「出了问题之后，用户能不能接受」。

限流是「我主动控制流量」，熔断是「下游病了我不再打扰它」，降级是「出了岔子，先给用户一个能用的兜底」——三者合起来就是稳定性三板斧。建议和「限流详解」「熔断详解」对照着看，这篇是这三部曲的收尾。

本文脉络：
  一    为什么需要降级（故障不可避免，但体验可以兜住）
  二    降级的本质：用「有损」换「可用」
  三    降级的触发时机（谁来喊降级）
  四    三类降级：读降级 / 写降级 / 非核心降级
  五    降级的数据与缓存设计（来源 / key 构建 / 内容去重 / 更新过期）
  六    与熔断、限流、重试的协同（稳定性三板斧）
  七    生产实践与常见陷阱
  八    面试速答

熔断（Circuit Breaker） 是高可用系统应对「下游故障」的核心手段：当被调用的服务出现持续错误或超时时，熔断器主动「跳闸」，在一段时间内直接快速失败、不再发起真实调用，从而避免上游线程被拖死、引发级联雪崩。

限流是「我主动控制流量」，熔断是「下游病了我不再打扰它」——建议和「限流详解」对照着看，两者正好凑成稳定性三板斧的两条腿。下面就从故障怎么传染说起，一路讲透三态状态机、触发条件、恢复策略、主流框架，以及和限流/降级/重试怎么打配合。

本文脉络：
  一    为什么需要熔断（级联雪崩与故障传播）
  二    熔断器状态机（Closed / Open / Half-Open）
  三    触发条件（错误率 / 超时 / 失败次数）
  四    恢复策略（探测窗口、半开试探）
  五    常见熔断框架（Hystrix / Resilience4j / Sentinel）
  六    熔断后的兜底（降级 / Fallback）
  七    与限流、降级、重试的协同（稳定性三板斧）
  八    生产实践与常见陷阱
  九    面试速答