编码 Agent 正在学会「自我进化」——从 Superpowers 到 OpenViking 的技术拆解

过去一周的 GitHub Trending 出现了一个有意思的现象：排行榜前十里，有一半跟 AI Agent 的「技能框架」相关。Superpowers 冲到了 89k stars，claude-mem 拿下 37k，learn-claude-code 接近 30k，字节跳动的 OpenViking 也到了 14k。

这不是巧合。编码 Agent 正在经历一次范式转变——从「接收指令，执行任务」变成「规划目标，调度资源，自己学着变聪明」。

我花了几天时间把这几个项目都跑了一遍，聊聊我的观察。

先说结论

如果你现在还在用「一个大 prompt + 一堆工具」的方式搭 Agent，可能需要重新想想了。2026 年 Q1 的趋势很明确：

• Agent 需要「技能」而不只是「工具」
• 记忆管理从文本文件进化到语义数据库
• 子 Agent 协作从串行走向并行自治

下面挨个拆。

Superpowers：89k stars 背后的方法论

先聊 Superpowers，因为它的思路最有代表性。

这个项目的核心其实不是代码，是一套软件开发方法论。它给编码 Agent 加了几个关键约束：

用户提需求 → Agent 先提问搞清楚真实意图
           → 拆解成可执行的实施计划
           → 启动子 Agent 逐个完成任务
           → 主 Agent 审查子 Agent 的产出
           → 循环直到完成

听起来很简单？但真正跑起来你会发现，这套流程解决了一个最头疼的问题：Agent 跑偏。

在没有规划约束的情况下，让 Claude Code 或 Cursor 去做一个复杂功能，它大概率会在第三步开始偏离你的预期。加了测试也不好使，因为它写的测试本身就是按它理解的方向来的。

Superpowers 的做法是在「写代码」之前强制插入一个「对齐」环节。它不是直接开干，而是先把方案用人话写出来给你看，你点头了才开始实施。实施过程中每个子任务都是独立的 context window，不会互相污染。

这和传统的 ReAct 循环有本质区别。ReAct 是「想一步做一步」，Superpowers 是「先想完再做」。在实际体验里，后者的完成率高了不止一倍。

它强调 TDD（测试驱动）和 YAGNI（不做多余的事），这两条在 Agent 场景下意外地好用。Agent 最爱干的事就是加一堆你没要的功能，YAGNI 直接给它画了条线。

实战对比：有无规划约束的差异

我用同样一个需求（"给项目加一个 WebSocket 实时通知功能"）分别用普通 Claude Code 和 Superpowers 方式跑了一遍：

# 普通方式：Claude Code 直接开干
# 结果：
# - 改了 8 个文件
# - 引入了 Socket.IO（我没要求用这个库）
# - 加了一个完整的房间管理系统（我只要简单通知）
# - 自动加了心跳检测、断线重连、消息持久化
# - 总共 600+ 行代码
# - 有 3 个 bug

# Superpowers 方式：先规划再执行
# 规划阶段输出：
# "需求确认：只需要服务端推送通知到前端，不需要双向通信。
#  推荐方案：用原生 WebSocket，不引入 Socket.IO。
#  实施步骤：
#  1. 添加 WebSocket 服务端（ws 库，约 40 行）
#  2. 前端添加连接逻辑（约 30 行）
#  3. 添加通知触发接口（约 20 行）"
# 
# 结果：
# - 改了 3 个文件
# - 90 行代码
# - 0 个 bug

差异非常明显。规划约束让 Agent 不再「过度工程化」。

claude-mem：让 Agent 真正「记住」你的项目

如果 Superpowers 解决的是「怎么做」，claude-mem 解决的就是「记住做过什么」。

这个 Claude Code 插件做的事情说白了就一句话：自动记录 Agent 每次会话干了什么，压缩成摘要，下次开会话的时候自动注入回去。

# claude-mem 的核心循环（伪代码）
class ClaudeMem:
    def on_session_end(self):
        observations = self.capture_tool_usage()    # 抓取工具调用记录
        decisions = self.extract_decisions()         # 提取关键决策
        summary = self.compress(observations, decisions)  # AI 压缩成摘要
        self.store(summary, semantic_index=True)     # 存到语义索引

    def on_session_start(self):
        context = self.get_current_context()
        relevant = self.search(context, top_k=5)     # 检索相关记忆
        self.inject(relevant, position="system")     # 注入到当前会话

    def compress(self, observations, decisions):
        """不是存日志，是提炼决策"""
        prompt = f"""
        总结这次会话的关键决策和原因：
        工具调用：{observations}
        重要选择：{decisions}

        输出格式：
        - 做了什么
        - 为什么这样做
        - 有什么需要注意的
        """
        return llm.generate(prompt)

看起来不复杂。但实际用起来体验差别很大。

一个常见场景：你花了三天在一个项目上迭代，中间开了十几次 Claude Code 会话。到第四天再打开，Agent 对之前做的所有决定一无所知。你得重新解释一遍「为什么用这个库」「为什么 API 这样设计」。

claude-mem 把这个问题自动化了。它不只是记录「你做了什么」，而是记录「你为什么这样做」。这是语义压缩的价值——不是存日志，是提炼决策。

它现在有 37k stars，说明这个痛点是真实存在的。不过我得说，它的方案还比较初级。所有记忆都是文本级别的检索，没有结构化。这就引出了下一个项目。

OpenViking：字节跳动对 Agent 记忆的重新定义

OpenViking 的野心大得多。它不是做一个记忆插件，而是要做 Agent 的「上下文数据库」。

传统 RAG 的做法是把文本切片、向量化、扔进向量数据库。检索的时候用余弦相似度捞出来。问题在于——这是扁平的。你查「用户认证」，它可能把登录、注册、OAuth、JWT 全给你捞出来，但没有层次关系。

OpenViking 用「文件系统范式」来组织上下文。它把 Agent 需要的东西分成三类：

• 记忆（Memory）：对话历史、决策记录、经验教训
• 资源（Resource）：文档、代码、数据
• 技能（Skill）：可复用的操作模式

然后用类似目录树的结构组织起来，支持三层分级加载：

L0: 热数据 — 当前任务直接相关的上下文
    例：正在修改的那个文件、刚才的对话记录

L1: 温数据 — 同一项目的背景信息
    例：项目架构文档、API 设计规范、团队约定

L2: 冷数据 — 历史经验和通用知识
    例：之前踩过的坑、常用的设计模式、最佳实践

这跟操作系统的页面缓存思路很像——热数据常驻内存，冷数据按需加载。在 Agent 场景下，这解决了上下文窗口有限的核心矛盾：不是把所有东西塞进去，而是只加载当前需要的。

与 OpenClaw 记忆系统的对比

我自己用的 OpenClaw 也有类似的分层设计，但思路不太一样：

OpenClaw 四层记忆：
Layer 1: SOUL（不可变）   → 核心行为准则，类似 OpenViking 的系统配置
Layer 2: TOOLS（半静态）  → 工具使用约定，类似 OpenViking 的 Skill
Layer 3: USER（长期）     → 用户偏好和历史，类似 OpenViking 的 Memory
Layer 4: Session（短期）  → 当前对话上下文，类似 OpenViking 的 L0

OpenViking 三层上下文：
L0: 热数据 → 对应 OpenClaw Session
L1: 温数据 → 对应 OpenClaw TOOLS + USER 部分
L2: 冷数据 → 对应 OpenClaw USER 的深层历史

两者最大的区别：OpenClaw 用文件系统（JSONL + Markdown），OpenViking 用语义数据库。前者简单直接可调试，后者检索更精准但黑盒程度高。

在实际使用中，我倾向于混合方案——日常操作用文件系统（可读性好），需要跨会话检索时走语义搜索。

learn-claude-code：12 层架构拆解

这个项目比较特殊，它不是一个工具，是一本「教科书」——教你怎么把 Claude Code 用到极致。

它提出了一个 12 层架构体系，从底层到顶层依次是：

第 12 层：用户交互界面
第 11 层：任务编排引擎
第 10 层：多 Agent 协作协议
第 9 层：安全与权限沙箱
第 8 层：持久化状态管理
第 7 层：工具注册与调度
第 6 层：上下文窗口管理
第 5 层：记忆与检索系统
第 4 层：提示词工程层
第 3 层：模型适配层
第 2 层：运行时环境
第 1 层：基础设施

这 12 层里最值得关注的是第 10 层——多 Agent 协作。

传统做法是串行：主 Agent 调子 Agent，等结果回来再调下一个。learn-claude-code 提出了并行自治模式：

# 串行模式（传统）
result1 = agent_a.run("分析需求")
result2 = agent_b.run(f"设计方案，基于：{result1}")
result3 = agent_c.run(f"编写代码，基于：{result2}")

# 并行自治模式（learn-claude-code）
async def parallel_workflow():
    # 多个 Agent 同时启动，各自独立工作
    tasks = [
        agent_arch.run("分析现有架构"),
        agent_test.run("生成测试用例"),
        agent_doc.run("更新文档"),
    ]
    results = await asyncio.gather(*tasks)

    # 主 Agent 汇总审查
    final = agent_main.review(results)
    return final

并行模式的优势在于速度——三个 Agent 同时跑，总耗时接近最慢的那个，而不是三个的总和。代价是需要更精细的任务拆分，确保并行任务之间没有依赖。

实战建议：怎么把这些项目用起来

聊了这么多，给几个具体的建议：

1. 给你的 Agent 加规划约束

不管你用的是 Claude Code、Cursor 还是自己搭的 Agent，都可以借鉴 Superpowers 的思路。核心就一句话：写代码之前先出方案。

最简单的实现方式——在 system prompt 里加一段：

在执行任何代码修改之前，先输出一份简要的实施计划：
1. 要改哪些文件
2. 每个文件改什么
3. 预期的代码量
等用户确认后再开始实施。

2. 搭建记忆管理

如果你用 Claude Code，直接装 claude-mem。如果是自建 Agent，参考 OpenClaw 的四层记忆设计，至少做到：

• 会话结束时自动保存关键决策
• 新会话开始时注入相关历史
• 长期记忆定期整理压缩

3. 尝试多 Agent 协作

从简单场景开始——比如让一个 Agent 写代码，另一个 Agent 做 code review。不要一上来就搞复杂的并行调度。

# 最简单的双 Agent 协作
code = coder_agent.generate(requirement)
review = reviewer_agent.check(code)

if review.has_issues:
    code = coder_agent.fix(code, review.feedback)

这种模式的效果往往比单 Agent 反复修改要好——因为 reviewer 的视角和 coder 不同，能发现盲点。

总结

2026 年 Q1 的 Agent 生态正在经历快速分化。几个项目分别押注了不同的方向：

项目	Stars	核心方向	解决的问题
Superpowers	89k	规划约束	Agent 跑偏
claude-mem	37k	语义记忆	跨会话遗忘
learn-claude-code	29.5k	架构方法论	系统化构建
OpenViking	14.3k	上下文数据库	信息过载

一个有意思的观察：这四个项目都不是在「提升模型能力」，而是在「提升模型之外的工程能力」。这跟 Google 报告里说的「从 Prompt 工程到系统工程」的趋势完全一致。

模型的智商已经够了，现在拼的是工程纪律。

---

参考资料： - GitHub Trending (2026年3月第3周) - Superpowers: github.com/superpowers (89k stars) - claude-mem: github.com/claude-mem (37k stars) - learn-claude-code: github.com/learn-claude-code (29.5k stars) - OpenViking (字节跳动): github.com/openviking (14.3k stars) - Google Cloud《AI Agent Trends 2026》