YT 学习笔记

Skill 按需加载 vs agents.md 每轮注入

19分钟阅读下载 MD

封面

Ras Mic · 12:53 · 发布 2026-06-09 · 1.2 万次观看(截至抓取) · 观看原视频

主旨

拆解作者做 agentic engineering 时,常驻在 harness 里的 Claude Skills 与 AGENTS.md 两类持久化指令的本质差别、各自适用场景,以及具体在用的三个 skill(code structure、grep loop、code simplify)与一份 agents.md 的内容。

核心论点

  1. Skill 与 agents.md 按”是否每轮都需要”分工:前者按需加载元数据,后者每轮全量注入 context,两者并存且不互相替代。(→ 详解1)
  2. Skill 真正生效靠”元数据常驻 + instructions 按需”,以 944→53 token 的实测说明省 context 不是口号。(→ 详解2)
  3. agents.md 只放每轮都用的工作流约束;绝不放 agent 能自行搜索/查到的代码库信息——后者属于”喂饭”,不该塞进每轮固定 context。(→ 详解3)
  4. 三个具体 skill 构成作者 harness 的常驻工具:code structure 把 slop 重构成 service layer、grep loop 把 PR review 闭环到 5/5、code simplify 兜底复杂代码。(→ 详解4)
  5. 把项目所用开源库的源码下载到本地目录,让 agent 实时查源码补足训练盲区,等于把”外部知识”按需塞进 context,而非寄望模型权重里已记下。(→ 详解5)

知识点详解

1. Skill 与 agents.md 的本质差别 00:40

作者开场先把”skill vs agents.md 哪个好”这层常见争论压平:不是二选一,而是分工不同。

两者最大的不同是加载机制。Skill 是按需加载的——agent 在每一轮 context 里看到的只是 skill 的 name 和 description(元数据),真正的 instructions 要等模型判断”这次任务用得到”才会被读入。而 AGENTS.md 是每次会话开始就全量塞进 system prompt 的,无论这一轮用不用得到那段工作流,内容都在。

作者用 4:1 的对比来锚定这层分工00: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

作者随即拆开一个 skill 的内部结构。所有 skill 都长一样:顶上是一段元数据(name + description),底下是 instructions。这是 Claude Skills 的标准骨架,Anthropic 的官方 skill 模板与第三方自建 skill 几乎都遵循这套结构01:46。

关键点在于模型怎么”知道”该不该调一个 skill。作者用 OpenAI 的 tokenizer 实测,把自己的 code structure skill 完整放进 context 大约是 944 token,但只放 name+description 进去只有 53 token03:02。每轮常驻的只有 53 token,真正读 instructions 是模型判断”这次需要 code structure”时才发生03:24。

这套机制的现实价值是两点。第一,context 预算被释放——每轮常驻的几十个 token,而不是几百个;作者三个 skill 叠加也只占百级 token。第二,指令不会被冗余信息稀释——instructions 不会污染对话的注意力,只在被触发的那一轮被读到。这两点一起让 skill 比”全量放 agents.md”在 context 利用上更经济,也直接呼应 静态上下文与动态上下文 的”恒定加载 vs 按需加载”权衡。

3. agents.md 的内容边界:工作流约束,不写代码库信息 06:05

AGENTS.md 每轮全量注入,意味着写进去的每一行都在持续消耗 context。作者给出一条非常具体的判断标准:agents.md 只放 agent 不知道、且每轮都会用到的工作流约束。

作者展示自己 agents.md 里的第一段是分支与 PR 流程07:01:「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。

反例是代码库结构信息。作者明确说09:27:「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

作者的 harness 里有三个 skill 常驻,各自解决 agentic engineering 里一类”做完才知道”的活。

code structure(作者自制):把 agent 生成的代码重构成 Service Layer 架构03:35。原话是 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。

grep loop(Greptile 官方):这是视频标题里的”loop”。它的工作方式是一个反馈闭环——先让 Greptile 评审 PR,拿到一个 0-5 的置信分;如果没到 5 分,grep loop 让 agent 拉取 Greptile 留下的 review 评论(包括 summary、代码高亮、建议与修复 prompt),分析完后推送修复 commit;然后等 Greptile 再评审,循环到 5/5 为止05:49。作者在视频里展示了其中一个 PR 跑了 19 分钟(实际是 19 分钟多),最后确实拿到 5/510:37。这个 skill 名字里的 “loop” 就在说”它会一直循环到 5 分为止”11:14。

code simplify(Anthropic 官方):最后一道兜底。保留功能、简化代码12:07。作者说使用时机是基于直觉,觉得一段代码太复杂、读不懂,就跑一次 code simplify 整理;没有严格的触发判据。

三个 skill 加起来覆盖了写完 → 审查 → 简化三段收尾动作的自动化,都靠 slash 命令触发、不需要每轮常驻 instructions。

5. 用开源源码替代训练盲区 07:46

最后一个核心机制是用项目自带的开源库源码当 agent 的可查资料库。作者用了一个叫 open source 的小工具,功能是把仓库里 imports 列出的所有开源依赖的源码下载到本地一个目录08:19。

背后动机是08:25:the models might not be trained on the most up-to-date information——模型权重里某个库的 API 形态可能已经过期,直接问 agent 怎么调,得到的答案往往是过时甚至错误的签名。

解法是把”调用文档”换成”调用源码”。作者在 agents.md 里告诉 agent 你有这个工具可以用。当 agent 真的需要调某个库(比如 SvelteKit 的 remote functions),它会主动去源码目录里搜相关函数,而不是赌自己记得08:38。这不是把整份源码塞进 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 内部的具体形态。
  • 印证:Agentic课·导论 定义了 Claude Skills 的「文件夹+skill.md」打包机制;本片用 944→53 token 实测独立印证其元数据常驻、instructions 按需加载的设计收益。
  • 互补:CC高阶课·模型分散 讲 AGENTS.md 为什么要平台无关(换 agent 可接手),本片讲里面该写什么(内容边界)——写 agents.md 前两篇合看。

一手来源与延伸

术语

  • 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 03:02
  2. agents.md 该写什么、不该写什么?判断标准是什么? 答案:只写 agent 不主动查就不知道、且每轮都要用的工作流约束(如分支/PR 流程);不写代码库结构、技术栈等 agent 能自查的信息。详解3 07:01 09:27
  3. grep loop 这个 skill 的反馈闭环具体怎么走?触发条件是什么? 答案:Greptile 评审 PR 拿 0-5 分 → 未到 5 分时让 agent 拉 review 评论并修 → 推送修复 commit → 再评审,循环到 5/5 为止;视频里一个 PR 跑了 19 分钟才闭环。详解4 05:49 10:37
  4. code structure skill 的作用对象和结果是什么? 答案:把 agent 默认产出的 slop 代码(堆在一起)按 service layer 架构拆成独立 service,让后续人/agent 都能持续读懂。详解4 03:46 03:35
  5. open source 工具解决的是什么问题?与 skill 按需加载思路有什么共通点? 答案:解决”模型权重里库 API 签名陈旧”的问题——把第三方库源码下载到本地,让 agent 按需检索正确调用方式,而不是寄望模型记得;与 skill 按需加载都是”不预塞 context、只暴露按需检索能力”的思路。详解5 08:25 08:38

关系图谱

反向链接