这周在 GitHub 上逛下来最直接的感受是AI 大模型已经不再是什么新鲜事“Agent”和“Skills”这两个词才是真正让开发者开始动手的点。搜索热词里几乎每天都在出现 pi agent、agent framework、skills 开发、claude code skills 这些关键词仓库的提交频率也比上个月明显加快。如果你正打算进入 Agent 开发或者已经在用 Claude Code、OpenCode 这类工具这篇周报会帮你把这周值得关注的项目、技能包和踩坑点一次理清楚。我会先从生态趋势说起再拆几个典型的 Agent 项目然后重点讲 Skills 到底是什么、怎么安装和编写最后给出一份可以直接照着做的学习路线和排错清单。全程是我自己翻榜单、跑代码、读文档后的真实记录不保证全覆盖但保证每条都能落地。1. 本周生态速览AI / Agent / Skills 为什么被绑在一起讨论1.1 从“大模型对话”到“Agent 执行”生态发生了实质转变这周有一个很明显的趋势GitHub 上高热度项目不再满足于“给你一个聊天框”而是转向“给你一个能执行任务的智能体”。换句话说大家默认大模型已经很能打接下来要比的是怎么让它自己查资料、调工具、跑代码、改文件最后交付一个结果。这类项目通常不会直接暴露模型而是封装成一个 agent 智能体。你告诉它目标它自己规划步骤调用各种 Skill 或者外部工具然后一步步执行。整个链条里Agent 负责“想”Skills 负责“做”所以两个关键词经常一起出现。以前我们管这种能力叫插件、插件系统到了 2026 年大家的统一叫法越来越倾向于 Skills。从开发者的角度看这意味着门槛在变化以前写 AI 应用要懂模型微调、懂提示词工程现在更需要懂怎么搭 Agent 的循环、怎么定义工具接口、怎么把技能写清楚。本周热词里反复出现的“agent 开发学习路线”“skills 开发”其实都在反映这种诉求。1.2 本周热词里的几个明显信号把相关热词摊开看有几个信号非常集中Pi Agent 和 Hermes Agent 反复出现这类名字看着像同一个项目实际上 GitHub 上同名或者近名的仓库非常多有偏个人助理的也有偏自动化任务的。光看名字下判断很容易踩坑后文我会专门讲怎么快速识别。Claude Code 手动安装 Skills 成为高频问题很多人已经把 Claude Code 当成日常编码工具但“怎么把 GitHub 上的 skills 装进去”依然是问得最多的问题。这其实不是操作复杂而是不同工具的 Skills 目录结构不一样官方文档更新又太快。Superpower Skills、Opencode Skills、Codex Skills 被频繁提及这些是社区里比较有代表性的 Skills 集合。它们解决的问题很相似给 Agent 规划、编码、测试、文档等能力包让 Agent 不用从零开始瞎试。前端开发 Skills 和图片生成 Skills 是垂直需求大户说明 Skills 不只是通用指令更多人开始为具体场景定制技能比如前端页面规范、视觉素材生成、专利辅助检索等。这些信号叠加起来基本可以判断Skills 正在成为 Agent 时代的“插件机制”而 GitHub 就是最大的插件分发市场。1.3 适合谁看这篇周报适合几类人在用 Claude Code、OpenCode 或 Codex 做日常开发的工程师想给工具加一点“专业能力”。正准备选型 Agent 框架但又分不清各种项目区别的开发者。被“Agent execution terminated due to error”这种报错困住想弄明白到底哪里出了问题的人。对 Agent 和 Skills 完全陌生但想从零开始学习的新手。如果你不属于上面任何一类这篇文章也能帮你建立一个比较完整的认知框架至少下次看到“agent”“skills”不会一头雾水。2. Agent 项目这周的“智能体”仓库到底在做什么2.1 Agent 项目的三个层次我在翻项目的时候习惯先分类否则很容易被仓库数量淹没。本周看到的 Agent 项目大致分三个层次第一层单 Agent 应用。这类项目最简单本质是一个循环接收用户目标调用模型做规划执行工具调用把结果追加回上下文继续循环直到目标完成。代表形态是很多“AI 助手”“自动编码机器人”。它们通常结构清晰适合新手阅读源码。第二层多 Agent 协作系统。多个 Agent 各司其职比如规划 Agent 负责拆任务执行 Agent 负责干活审查 Agent 负责检查结果。这类项目比单 Agent 复杂很多因为要处理消息路由、任务状态同步、失败重试等问题。你在 GitHub 上看到那些动不动就有几十个文件的项目往往属于这类。第三层Agent 框架和运行时。这是给开发者用的底座比如一些知名框架。框架本身不直接解决问题而是提供状态管理、工具注册、记忆机制和人机交互界面。很多“Agent 项目”其实是在某个框架之上写的应用如果你只想要一个能跑的业务工具不一定要从框架层开始造轮子。分清这三个层次非常重要。技术选型时第一层适合快速验证第二层适合复杂业务流程第三层适合做平台或者深度定制。本周有人问“agent 项目到底该怎么看”我的回答是先看它属于哪一层再看它的文档和示例最后动手跑一遍。2.2 框架层的关注点Harness 和 Agent 到底有什么区别这周有个热词特别值得展开harness 和 agent 区别。很多人第一次看到 harness 这个词会懵其实理解起来不难。Agent 是“会思考的那颗大脑”它决定下一步要做什么调用哪个模型采用什么策略什么时候停止。Harness 是“承载大脑的那台机器”它负责把输入传给 Agent给 Agent 提供工具列表管理上下文窗口记录日志处理权限以及把工具返回值送回给 Agent。打个比方Agent 是司机Harness 是汽车和道路系统司机做决策车负责把决策变成实际的移动。在具体项目里Harness 和 Agent 经常是拆开的。比如一个仓库里有个agent.py定义决策循环同时有个harness.py负责命令行交互、配置文件读取和工具初始化。看懂这个结构以后遇到“Agent execution terminated due to error”你就知道该去哪一层排查如果是工具调用失败问题多半在 Harness 层如果是模型乱规划或者一直绕圈问题多半在 Agent 层。这里有个实战建议选型的时候不要只看 Agent 有多聪明还要看 Harness 的调试能力。一个带日志、支持逐步回放、能手动确认工具调用的 Harness往往比一个“看起来很智能但黑盒”的 Agent 更可靠。2.3 从“Pi Agent”到“Hermes Agent”如何判断一个 Agent 项目是否适合你这周热门词里出现好几次“Pi Agent”和“Hermes Agent”。我特意搜了一下发现同名项目不止一个有的偏轻量对话有的偏任务自动化还有的只是某个大项目里的示例模块。面对这种情况我有几个固定动作看 README 的第一屏。如果作者连“这个项目解决什么问题、怎么安装、怎么运行”都没写清楚大概率维护质量堪忧。看最近提交时间。如果一个 Agent 项目半年没更新基本上可以认为它已经被作者抛弃。2026 年的 Agent 生态变化太快隔一个月可能接口就变了。看运行方式。是命令行工具、本地 Web 服务还是需要部署到云端这决定了你接入成本。看模型依赖。有些项目绑定特定模型有些支持 OpenAI 兼容接口。想省钱或者用本地模型就要选支持自定义模型地址的。我个人的习惯是每天从热门列表里挑三四个项目读 README然后挑一个最容易跑通的做本地实验。单纯“收藏即学会”没有意义真正跑一次你才会发现文档里没写的隐藏依赖。3. Skills 生态Agent 时代的“插件市场”正长在 GitHub 上3.1 Skills 到底是什么Skill 和 Agent 又是什么关系这是本周被问得最多的一个概念性问题。简单说Agent 是决策者Skill 是执行工具。Agent 决定“怎么做”Skill 负责“做什么”。一个 Agent 可以挂很多 Skills就像一个人可以会写代码、会做饭、会修电脑一样。从文件结构上看目前多数工具对 Skills 的约定已经比较接近。以 Claude Code 为例一个 Skill 通常是一个文件夹里面有一个SKILL.md加上若干辅助文件。SKILL.md的开头是 YAML 格式的 front matter至少包含name和description两个字段。description 特别重要因为 Agent 会读它来判断“当前任务适不适合调用这个 Skill”。如果描述写得含糊Agent 可能压根不会触发这个技能。Skill 的正文部分就是给 Agent 看的操作手册什么时候用它、按照什么顺序做、有哪些注意事项、验收标准是什么。可以把它理解成“喂给 AI 的 SOP 文档”。和普通文档的区别在于它有明确的结构并且可以被 Agent 自动检索、加载和引用。所以“Skill 和 Agent 的区别”可以一句话概括Agent 是流程控制者Skill 是具体能力单元Agent 决定要不要用某个 SkillSkill 只负责把某件事做好。3.2 Claude Code / OpenCode / Codex 的 Skills 实践清单不同工具对 Skills 的支持路径略有不同我按这周看到的社区实践列了一个表工具典型存放位置入口文件说明Claude Code.claude/skills/skill-name/SKILL.md最流行的格式社区资源最多OpenCode.opencode/skill/或全局配置目录SKILL.md支持项目级与全局级技能Codex部分项目使用独立技能目录Markdown 描述文件生态迭代较快以官方文档为准注意这个表只能代表“当前常见做法”因为工具版本更新很快今天有效的路径明天可能就变了。我在实操中发现最好的方式不是记死路径而是直接去对应工具的官方文档里搜skills或者skill关键字。再强调一次description字段一定要好好写。上周我看一个社区仓库作者把所有 Skill 的 description 都写成了“用来干活的技能”结果 Agent 基本不会自动调用。后来改成“当用户需要生成前端组件时使用输入为组件需求说明输出为可运行的 HTML/CSS 代码”调用率一下就上来了。这就像搜索引擎的标题一样决定了你的 Skill 会不会被“检索”到。3.3 社区 Skills 仓库与手动安装方法社区里比较有代表性的技能集合包括 Superpower Skills、OpenCode Skills、Codex Skills 等。这些集合通常会把几十个技能打包在一个仓库里方便批量安装。它们覆盖的方向很广代码审查、TDD、需求拆解、文档生成、图片生成、前端开发等。手动安装一个 Skill 的流程其实不复杂我以 Claude Code 为例把目标仓库克隆到本地。找到对应的 Skill 文件夹确认里面有SKILL.md。复制该文件夹到你项目的.claude/skills/目录或者用户级~/.claude/skills/目录。重启 Claude Code 会话然后直接提一个与该技能描述匹配的需求。观察 Agent 输出里是否出现了技能加载或者“使用 skill xxx”的日志。这里有一个常见坑很多人把 Skill 放进目录以后发现“没生效”其实是因为会话缓存。重启会话基本能解决大部分问题。还有一个坑是有的 Skill 会引用同目录下的其他文件如果复制的时候漏了子目录Agent 就会找不到参考文件。所以复制时最好整个文件夹一起复制不要只复制那个 Markdown 文件。如果你安装的是图片生成类 Skills记得检查它依赖的外部服务。很多图片生成技能只是封装了 API 调用并不会真的在本地绘图。安装之前先读一遍 SKILL.md 的“依赖”部分否则跑起来才发现缺 API Key会非常浪费时间。4. Agent 加 Skills 的实战从提示词到 IDE 插件4.1 一套值得直接抄的工作流很多人以为 Agent 开发就是写一堆提示词其实更高效的模式是“提示词 Skills 明确交付物”。这周我在测试一个前端开发场景时跑通了一套工作流步骤大概是下面这样给 Agent 一个目标“把当前页面的导航栏改造成响应式布局。”Agent 读项目结构找到相关代码文件。Agent 匹配到一个前端开发 SkillSkill 里写了该项目的样式规范、组件拆分原则、可访问性要求。Agent 按照 Skill 的步骤修改代码并自检是否符合规范。Agent 生成一个简短总结说明改了哪些文件、为什么这样改。整个过程里提示词只承担“描述目标”的作用真正决定输出质量的是 Skill 里的操作规范。这就像你要一个实习生干活光说“改一下页面”他可能自由发挥但你给他一份 SOP他就能产出符合预期的结果。4.2 从提示词到 IDE 插件落地方式越来越丰富随着 Agent 生态成熟GitHub 上也开始出现大量配套工具。热度比较高的有两类一类是“AI 编程提示词”资源库专门收集高质量提示词模板比如代码审查提示词、测试用例生成提示词、需求分析提示词另一类是 IDE 插件比如 PyCharm AI 插件以及其他编辑器插件它们把 Agent 能力直接嵌到开发环境里。我的观点是提示词资源库虽然看起来简单但价值很高。好的提示词不是随便写几句“请帮我写代码”而是包含上下文、约束条件和验收标准的结构化内容。你可以用这些提示词喂给 Agent也可以把它们改造成一个 Skill。甚至可以说提示词库就是没有 front matter 的 Skills只是少了结构化封装。4.3 本地测试的重要性这周有一个热词是“ai 编程”但真正把 AI 编程用好需要在本地做大量验证。我的习惯是准备一个小型 demo 仓库用来测试各种 Skills。选便宜或者本地的模型跑一版确认逻辑没问题再用更强模型。每次只改一个 Skill 或一版提示词避免多种变量混在一起。本地验证还有一个好处你能看到 Agent 的完整调用链。如果 Agent 输出了结果你可以往回翻日志看它是怎么拆解任务的、调用了哪些 Skill、每步花了多久。这些信息在线上环境里反而不容易拿到。5. 学习路线与常见问题排查记录5.1 从零开始学 Agent 开发的建议顺序如果你是完全的新手看到“agent 开发学习路线”这个词不知道从哪入手我给你一个保守但有效的顺序先会调模型接口。不管什么 Agent底层都是模型调用。你至少要熟悉一种 OpenAI 兼容接口知道怎么传消息、怎么处理流式输出。理解函数调用。Agent 之所以能“做事”核心是模型会输出结构化工具调用。先自己实现一个最简单的工具调用循环哪怕只是让模型决定“加一还是减一”。跑一个现成的 Agent 项目。找个结构清晰、星标多的单 Agent 项目跟着 README 跑通。跑通以后不要急着改代码先把日志读懂。学习 Skills 格式。打开一个社区 Skills 仓库看SKILL.md是怎么组织的。然后自己做一个小技能比如“总结当前目录下的 TODO 注释”挂到 Agent 上。再尝试多 Agent 和框架。有了单 Agent 的基础再去看框架项目就轻松很多因为你已经知道 Agent 循环、工具调用、上下文管理这些核心概念。这条路看起来慢但每一步都在建立基础。如果你直接去啃复杂的多 Agent 框架大概率会被各种抽象概念绕晕。5.2 Agent 运行报错排查从“execution terminated”说起这周热词里有一条特别显眼“Agent execution terminated due to error.”很多新手看到这个报错以为天塌了其实它是一个很笼统的兜底错误意思是“Agent 循环被终止了因为某个地方发生了错误”。碰到这个报错我的排查顺序是看详细日志。这个错误通常会把真正的异常信息打在前面几行。不要只盯着最后一行往上面翻五到十行基本能找到“Root cause”。检查工具调用是否成功。Agent 报错的高发区是工具层文件路径不存在、API Key 没配置、网络请求超时、返回值格式不对。你可以手动调一下 Agent 要调用的那个工具看能不能独立跑通。检查上下文长度。任务太长或者中间结果太大会把上下文窗口挤爆。这种情况模型会截断或者报错导致循环中断。检查模型配置。模型名写错、接口地址配错、余额不足这些都会导致“execution terminated”。把自动执行改成手动确认。很多 Harness 支持“自动执行工具”和“每步确认”两种模式。排查阶段建议改成手动确认这样你能看到每一步发生了什么。实际上这个报错不可怕可怕的是没有日志直接退出。如果你用的工具没有详细日志我甚至建议你在本地复现一遍把任务拆得更小让错误更容易暴露。5.3 这周的避坑记录这周我自己踩了好几个坑挑三个有代表性的第一个坑Skill 的 description 写得太含糊。我测试某个技能集合时发现 Agent 从头到尾没调用任何技能。打开 SKILL.md 一看description 写着“帮助用户处理开发任务”。这种描述等于没写。修正以后把关键词改成具体场景比如“前端开发”“代码审查”“单元测试”立刻就能触发。第二个坑复制 Skill 时漏掉了子目录。某个技能用到了assets/下的模板文件我只复制了SKILL.md结果 Agent 一直找不到模板。后来把整个文件夹复制过去才正常。这个教训适用于所有 Skills 安装只要有相对路径引用就必须整个目录一起搬。第三个坑不同工具版本之间兼容性问题。同一个 Skill 在 Claude Code 某个版本能用升级以后就提示格式错误。原因是 front matter 里多了几个字段旧版本不认。这种问题没法完全避免只能养成“读官方文档”和“升级前先看 changelog”的习惯。6. 每周刷完这些项目后我留下的几个小习惯6.1 每周只挑三四个项目做深度测试不看星标高低我现在每周会固定花一个下午从本周关注列表里挑三四个仓库做深度测试。判断标准不是星标多不多而是能不能在十分钟内跑通 demo。README 有没有把“解决什么问题”讲明白。代码结构是否清晰作者是否还在维护。有没有配套的 Skills 或者工具生态。这样坚持下来比单纯刷热门列表收获大得多。热门列表容易让人产生“收藏了就会了”的错觉而深度测试才能逼你面对真实问题。6.2 把顺手可用的 Skill 改造成自己的版本社区现成的 Skills 可以用但往往不完全贴和自己的项目。我的做法是先跑一遍社区的 Skill看它的步骤和输出格式然后改成符合自己团队规范的版本。改动通常集中在几个地方代码风格、目录约定、提交信息格式、审批流程。改完之后我会把这个 Skill 放在团队的.claude/skills/目录里提交到仓库这样所有成员都能用。Agents 会变模型会换但技能文档沉淀下来以后反而成了团队知识库里长期有效的部分。这也是我为什么觉得 Skills 比单纯调提示词更有价值提示词是一次性的技能是可积累的。如果你正准备开始接触 Agent 生态我建议你从这周开始做一件小事选一个自己每天都在做的重复任务把它写成一个最简单的 Skill挂到本地工具上跑一周。不用管写得好不好先体验一遍“Agent 按照你的文档去做事”这个过程。等这一步跑通了后面无论是学框架还是做复杂 Agent都会顺手很多。