--- title: 'Skill 按需加载 vs agents.md 每轮注入' video_id: 2Wu2OvRLiJc url: https://youtu.be/2Wu2OvRLiJc title_en: "This loop + skill fixes AI slop" channel: Ras Mic published: 2026-06-09 duration: "12:53" topics: ["Claude Code 定制扩展", "Agent 工程", "AI 编程与建站"] noted: 2026-07-07 value: A views: '1.2万' --- [![封面](https://i.ytimg.com/vi/2Wu2OvRLiJc/maxresdefault.jpg)](https://youtu.be/2Wu2OvRLiJc) > Ras Mic · 12:53 · 发布 2026-06-09 · 1.2 万次观看(截至抓取) · [观看原视频](https://youtu.be/2Wu2OvRLiJc) ## 主旨 拆解作者做 agentic engineering 时,常驻在 harness 里的 Claude Skills 与 AGENTS.md 两类持久化指令的本质差别、各自适用场景,以及具体在用的三个 skill(code structure、grep loop、code simplify)与一份 agents.md 的内容。 ## 核心论点 1. **Skill 与 agents.md 按"是否每轮都需要"分工:前者按需加载元数据,后者每轮全量注入 context,两者并存且不互相替代。**([[#1-skill-与-agentsmd-的本质差别-0040|→ 详解1]]) 2. **Skill 真正生效靠"元数据常驻 + instructions 按需",以 944→53 token 的实测说明省 context 不是口号。**([[#2-skill-的按需加载机制944-token-与-53-token-的差距-0146|→ 详解2]]) 3. **agents.md 只放每轮都用的工作流约束;绝不放 agent 能自行搜索/查到的代码库信息——后者属于"喂饭",不该塞进每轮固定 context。**([[#3-agentsmd-的内容边界工作流约束不写代码库信息-0605|→ 详解3]]) 4. **三个具体 skill 构成作者 harness 的常驻工具:code structure 把 slop 重构成 service layer、grep loop 把 PR review 闭环到 5/5、code simplify 兜底复杂代码。**([[#4-三个-skill-的具体作业方式-0346|→ 详解4]]) 5. **把项目所用开源库的源码下载到本地目录,让 agent 实时查源码补足训练盲区,等于把"外部知识"按需塞进 context,而非寄望模型权重里已记下。**([[#5-用开源源码替代训练盲区-0746|→ 详解5]]) ## 知识点详解 ### 1. Skill 与 agents.md 的本质差别 [00:40](https://youtu.be/2Wu2OvRLiJc?t=40) 作者开场先把"skill vs agents.md 哪个好"这层常见争论压平:不是二选一,而是分工不同。 两者最大的不同是**加载机制**。Skill 是按需加载的——agent 在每一轮 context 里看到的只是 skill 的 name 和 description(元数据),真正的 instructions 要等模型判断"这次任务用得到"才会被读入。而 AGENTS.md 是每次会话开始就**全量**塞进 system prompt 的,无论这一轮用不用得到那段工作流,内容都在。 作者用 4:1 的对比来锚定这层分工[00:50](https://youtu.be/2Wu2OvRLiJc?t=50):"skills are on a need-to-know basis, where agents.md file is given to the agent every single time"。换句话说,选哪条机制取决于这段指令是不是"每轮通用"——是的话放 agents.md,不是的话包成 skill 留待按需触发。两套机制并存才完整,丢掉任一边都会让 context 失衡。 ### 2. Skill 的按需加载机制:944 token 与 53 token 的差距 [01:46](https://youtu.be/2Wu2OvRLiJc?t=106) 作者随即拆开一个 skill 的内部结构。所有 skill 都长一样:顶上是一段元数据(name + description),底下是 instructions。这是 Claude Skills 的标准骨架,Anthropic 的官方 skill 模板与第三方自建 skill 几乎都遵循这套结构[01:46](https://youtu.be/2Wu2OvRLiJc?t=106)。 关键点在于**模型怎么"知道"该不该调一个 skill**。作者用 OpenAI 的 tokenizer 实测,把自己的 code structure skill 完整放进 context 大约是 944 token,但只放 name+description 进去只有 53 token[03:02](https://youtu.be/2Wu2OvRLiJc?t=182)。每轮常驻的只有 53 token,真正读 instructions 是模型判断"这次需要 code structure"时才发生[03:24](https://youtu.be/2Wu2OvRLiJc?t=204)。 这套机制的现实价值是两点。第一,**context 预算被释放**——每轮常驻的几十个 token,而不是几百个;作者三个 skill 叠加也只占百级 token。第二,**指令不会被冗余信息稀释**——instructions 不会污染对话的注意力,只在被触发的那一轮被读到。这两点一起让 skill 比"全量放 agents.md"在 context 利用上更经济,也直接呼应 [[静态上下文与动态上下文]] 的"恒定加载 vs 按需加载"权衡。 ### 3. agents.md 的内容边界:工作流约束,不写代码库信息 [06:05](https://youtu.be/2Wu2OvRLiJc?t=365) AGENTS.md 每轮全量注入,意味着**写进去的每一行都在持续消耗 context**。作者给出一条非常具体的判断标准:agents.md 只放 agent 不知道、且**每轮都会用到**的工作流约束。 作者展示自己 agents.md 里的第一段是分支与 PR 流程[07:01](https://youtu.be/2Wu2OvRLiJc?t=421):「Use staging as the integration branch for feature work. Create a feature branch from the latest staging, preferably in an isolated work tree under work trees. Open small focused PR's from each feature branch into staging...」——这种"团队约定 agent 不知道、每次提交都要遵守"的硬规则,正是 agents.md 该放的内容[07:05](https://youtu.be/2Wu2OvRLiJc?t=425)。 反例是代码库结构信息。作者明确说[09:27](https://youtu.be/2Wu2OvRLiJc?t=567):「for the love of all things, do not put the code base information. Like don't say, 'this is a React code base.' The agent knows. It can search the code.」——这类信息 agent 打开文件就能看到,放进 agents.md 只会徒增每轮 token、还会随项目演化而失效。 判断标准可以收成一句话:**agent 不主动查就不知道、且每轮都要用** 的内容才进 agents.md;能查的、偶尔用的、随项目变的信息,都不该进。这条边界与 CLAUDE.md 同源(作者口播中 agents.md 与 Claude.md 并提,同一套配置文件在不同平台的名字)。 ### 4. 三个 skill 的具体作业方式 [03:46](https://youtu.be/2Wu2OvRLiJc?t=226) 作者的 harness 里有三个 skill 常驻,各自解决 agentic engineering 里一类"做完才知道"的活。 **code structure**(作者自制):把 agent 生成的代码重构成 Service Layer 架构[03:35](https://youtu.be/2Wu2OvRLiJc?t=215)。原话是 most of the time agents are just generating slop code. This structures it.——agent 默认产出的是堆在一起的 slop,跑一次 code structure 把它按业务职责切到独立 service,后续无论人读还是 agent 接续都更顺。触发方式很简单:`/code structure` 一句 slash 即可,agent 自己会调 skill 文件并按 instructions 重写[03:46](https://youtu.be/2Wu2OvRLiJc?t=226)。 **grep loop**(Greptile 官方):这是视频标题里的"loop"。它的工作方式是一个反馈闭环——先让 Greptile 评审 PR,拿到一个 0-5 的置信分;如果没到 5 分,grep loop 让 agent 拉取 Greptile 留下的 review 评论(包括 summary、代码高亮、建议与修复 prompt),分析完后推送修复 commit;然后等 Greptile 再评审,循环到 5/5 为止[05:49](https://youtu.be/2Wu2OvRLiJc?t=349)。作者在视频里展示了其中一个 PR 跑了 19 分钟(实际是 19 分钟多),最后确实拿到 5/5[10:37](https://youtu.be/2Wu2OvRLiJc?t=637)。这个 skill 名字里的 "loop" 就在说"它会一直循环到 5 分为止"[11:14](https://youtu.be/2Wu2OvRLiJc?t=674)。 **code simplify**(Anthropic 官方):最后一道兜底。保留功能、简化代码[12:07](https://youtu.be/2Wu2OvRLiJc?t=727)。作者说使用时机是基于直觉,觉得一段代码太复杂、读不懂,就跑一次 code simplify 整理;没有严格的触发判据。 三个 skill 加起来覆盖了写完 → 审查 → 简化三段收尾动作的自动化,都靠 slash 命令触发、不需要每轮常驻 instructions。 ### 5. 用开源源码替代训练盲区 [07:46](https://youtu.be/2Wu2OvRLiJc?t=466) 最后一个核心机制是用项目自带的开源库源码当 agent 的可查资料库。作者用了一个叫 **open source** 的小工具,功能是把仓库里 imports 列出的所有开源依赖的源码下载到本地一个目录[08:19](https://youtu.be/2Wu2OvRLiJc?t=499)。 背后动机是[08:25](https://youtu.be/2Wu2OvRLiJc?t=505):the models might not be trained on the most up-to-date information——模型权重里某个库的 API 形态可能已经过期,直接问 agent 怎么调,得到的答案往往是过时甚至错误的签名。 解法是把"调用文档"换成"调用源码"。作者在 agents.md 里告诉 agent 你有这个工具可以用。当 agent 真的需要调某个库(比如 SvelteKit 的 remote functions),它会主动去源码目录里搜相关函数,而不是赌自己记得[08:38](https://youtu.be/2Wu2OvRLiJc?t=518)。这不是把整份源码塞进 context,而是**让 agent 拥有按需检索源码的能力**——与 skill 的按需加载思路一脉相承,只是对象从"自有 skill"换成"第三方库的源码"。 这套机制真正解决的是**模型知识陈旧**问题。让 agent 能搜到正确源码,胜于寄望权重里有正确签名。 ## 可执行步骤 - [ ] 把当前项目的 skills 与 agents.md 列成清单,逐条标注"每轮都用到 / 偶尔用到 / 用不到",看哪些 skill 适合从 agents.md 拆出来。 - [ ] 找一个你最近调过 API 的开源库,跑一次 open source 类工具把它源码下载到本地,试着让 agent 在 context 已知"可查"的前提下查询某个函数签名。 - [ ] 把 agents.md 里"项目是 X 技术栈"、"项目用 Y 数据库"这类代码库描述删掉,验证是否影响 agent 工作。 - [ ] 给一个反复出错的 PR 配 grep loop 类 skill,跑一次 5/5 闭环,看看到底循环几轮、花多少时间。 ## 关联 - 进阶:本片(2026-06-09)是 ras-mic 频道讲 harness 拆解的最早一集,讲 harness 内部的静态/动态上下文如何划分;后续 [[2026-06-23-用AI构建精美UI的设计工作流]](UI 层)与 [[2026-07-02-我如何构建应用（完整系统设计概览）]](系统架构)分别展开 UI 与后端,合看才是完整链路——先看本片理解上下文管理原则,再读后两片的具体实现。 - 印证:[[静态上下文与动态上下文]] 主张恒定加载 vs 按需加载的权衡决定专精多 agent 还是通才 agent+skills;本片用 944→53 token 的实测把这条权衡具象成 skill 的 name+description 与 agents.md 全量注入的对比——同一权衡,在本片是"skill vs agents.md",在通用语境是"专精多 agent vs 通才+skill"两种解法。 - 印证:[[Harness]] 三源共识(harness 决定 agent 效果 90%、模型只占 10% 的层级划分);本片是这套共识在"上下文管理"子项下的具体作业示范——三个 skill + 一份 agents.md 的组合,就是作者认为值得长期投入维护的那层可控杠杆,印证 harness 内部的具体形态。 - 印证:[[MxyRjL7NG18-Agentic 工作流课/01-导论|Agentic课·导论]] 定义了 Claude Skills 的「文件夹+skill.md」打包机制;本片用 944→53 token 实测独立印证其元数据常驻、instructions 按需加载的设计收益。 - 互补:[[UPtmKh1vMN8-Claude Code 高阶课/26-分散你的模型选择|CC高阶课·模型分散]] 讲 AGENTS.md 为什么要平台无关(换 agent 可接手),本片讲里面该写什么(内容边界)——写 agents.md 前两篇合看。 ## 一手来源与延伸 - [Greploop skill(GitHub)](https://github.com/greptileai/skills/tree/main/greploop) — Greptile 团队开源的 PR 评审→修复闭环 skill,视频里"grep loop"指的就是它。 - [Code Structure skill(GitHub)](https://github.com/michaelshimeles/skills/tree/main/code-structure) — 作者自制的把代码重构成 service layer 架构的 skill。 - [Code Simplifier(Anthropic claude-plugins-official)](https://github.com/anthropics/claude-plugins-official/blob/main/plugins/code-simplifier/agents/code-simplifier.md) — Anthropic 官方 skill,保留功能地简化代码。 - [Daytona(赞助商)](https://rasmic.link/daytona) — 视频中的 Daytona 沙盒演示;有 $100 信用 affiliate,见立场与利益节。 ## 术语 - Claude Skills — Anthropic 把可复用指令打包为「文件夹 + skill.md」的模块化机制;顶层是 name + description 元数据,下面是 instructions。 - AGENTS.md — 平台无关的 agent 配置文件(对应 Claude Code 的 CLAUDE.md),每轮会话开始时全量注入。 - Service Layer — 把代码按业务职责拆成独立 service 的架构模式,本片用 code structure skill 自动套用。 - Greptile — AI PR 评审服务,对 PR 评 0-5 分并留下修复建议;grep loop 的"评审方"。 - Daytona — 为 AI agent 提供隔离沙盒与算力的托管服务,本片用作内嵌预览与构建环境。 - Vibe Coding(口播中) — 不写代码、靠自然语言让 agent 写代码的用法;作者用其内嵌工具时提及。 - Grep Loop(本片命名) — 围绕 Greptile 评审的修复闭环:拉 review → 修 → 再评审,循环到 5/5。 - Open Source(本片中的小工具) — 把项目依赖的开源库源码下载到本地目录,让 agent 按需检索调用方式。 ## 立场与利益 视频的赞助商是 Daytona(description 明示 "Thank Daytona for sponsoring the video",中段有 Daytona 沙盒演示段,文末给出 $100 credit affiliate 链接),与利益同向的主张是"Daytona 是性能最强的 sandbox provider"以及"$100 免费 credit"——这两条都是赞助/affiliate 导流话术,采信前需外部印证,标"待印证"。其余 skill 选型、agents.md 边界、open source 工具用法与 Daytona 商业无关,属利益中性。 Greptile 作者口播明示"does sponsor some videos, but this video is not sponsored",所以"grep loop 用 Greptile 当评审方"这条选型与本次赞助无关;不过 Greptile 仍是该 skill 的核心依赖,选它本身有伙伴关系倾向,标"选型偏置,采信前可独立验证"。 ## 价值定位 适合**已经在用 Claude Code 或同类 agent 编码工具、想把 context 管理做得更细**的开发者,提供一套"skill 和 agents.md 到底怎么分"的具体判断标准,以及三个可直接安装试用的 skill 链接。偏认知 + 可直接搬用,不是"零基础 agentic 工程入门"。 实操价值在于把"agents.md 越写越长导致 context 塞爆"这个常见痛点落到 skill + 简短 agents.md 的具体拆分上;另外 grep loop 的"PR review → 自动修 → 循环到 5/5"工作流,是少数把"agentic 反馈闭环"在日常 PR 流里跑通的实例,值得搬到自己仓库试一次。 与 [[2026-07-02-我如何构建应用（完整系统设计概览）]] 重叠但各有侧重:那片讲后端/数据库/service 边界(系统架构),本片讲 harness 内部上下文管理(harness 划层)——合看才覆盖"用 AI 做产品"从 harness 到系统架构的完整链路。本片独有的增量是 skill 与 agents.md 的分工标准、三个具体 skill、open source 工具这套组合。 ## 自检问题 1. skill 在每轮 context 里实际常驻的是什么?完整的 instructions 什么时候才被读入? **答案**:每轮常驻的只有 name+description(本片实测约 53 token,而完整 instructions 约 944 token);instructions 是模型判断"这次任务用得到"时才被读入。详解2 [03:24](https://youtu.be/2Wu2OvRLiJc?t=204) [03:02](https://youtu.be/2Wu2OvRLiJc?t=182) 2. agents.md 该写什么、不该写什么?判断标准是什么? **答案**:只写 agent 不主动查就不知道、且每轮都要用的工作流约束(如分支/PR 流程);不写代码库结构、技术栈等 agent 能自查的信息。详解3 [07:01](https://youtu.be/2Wu2OvRLiJc?t=421) [09:27](https://youtu.be/2Wu2OvRLiJc?t=567) 3. grep loop 这个 skill 的反馈闭环具体怎么走?触发条件是什么? **答案**:Greptile 评审 PR 拿 0-5 分 → 未到 5 分时让 agent 拉 review 评论并修 → 推送修复 commit → 再评审,循环到 5/5 为止;视频里一个 PR 跑了 19 分钟才闭环。详解4 [05:49](https://youtu.be/2Wu2OvRLiJc?t=349) [10:37](https://youtu.be/2Wu2OvRLiJc?t=637) 4. code structure skill 的作用对象和结果是什么? **答案**:把 agent 默认产出的 slop 代码(堆在一起)按 service layer 架构拆成独立 service,让后续人/agent 都能持续读懂。详解4 [03:46](https://youtu.be/2Wu2OvRLiJc?t=226) [03:35](https://youtu.be/2Wu2OvRLiJc?t=215) 5. open source 工具解决的是什么问题?与 skill 按需加载思路有什么共通点? **答案**:解决"模型权重里库 API 签名陈旧"的问题——把第三方库源码下载到本地,让 agent 按需检索正确调用方式,而不是寄望模型记得;与 skill 按需加载都是"不预塞 context、只暴露按需检索能力"的思路。详解5 [08:25](https://youtu.be/2Wu2OvRLiJc?t=505) [08:38](https://youtu.be/2Wu2OvRLiJc?t=518)