第二部｜能力邊界 · 第 4 章

Context、AGENTS.md 與 Skills

把專案規則與領域知識放入正確層級，使用 progressive loading 控制 context 成本。

Context 不是把所有資料都塞給模型。好的 context engineering 是分層：穩定規則常駐、能力 schema 隨 request 提供、領域知識只在命中時載入。

Context 的四個層級

1. System prompt：Agent 身分、工作目錄、基本 workflow。
2. Project instructions：目前 cwd 的 AGENTS.md 全文。
3. Skill metadata：name、description、absolute location。
4. Conversation：user、assistant、tool results，以及必要的 compact summary。

Tool definitions 由 provider request 的 tools 欄位傳送，不是假裝成 system 文字。這讓模型只能選本次真正存在的能力。

AGENTS.md 是專案規則

Tiny-agent 啟動時只讀目前工作目錄的 ./AGENTS.md。它會進入明確的 project context 區塊：

<project_context>
Project-specific instructions and guidelines:
<project_instructions path="/workspace/AGENTS.md">
...全文...
</project_instructions>
</project_context>

這些規則適合放 coding style、測試命令、架構決策與禁止事項。不應放 credential，也不應把 volatile runtime state 寫在裡面。

Skills 使用 Progressive Loading

Tiny-agent 遞迴掃描：

.tiny-agent/skills/**/SKILL.md

啟動時只解析 frontmatter：

---
name: i-have-adhd
description: Shape responses so an ADHD reader can act on them.
---

System prompt 只得到 metadata 與 location；完整正文不會預先佔用 context。模型自動判斷任務命中後，才使用本次提供的 read 能力讀取全文。若本次用 --plugin edit 禁用了 read，模型自動載入時必須說明缺少能力，不能假裝 skill 已載入。

明確的 /skill:name 是另一條路徑：CLI 會直接讀取已發現的 skill 檔案，再把正文與 user request 一起交給 Agent，因此不需要啟用 read tool。這是 trusted host 操作，不是模型取得了額外檔案權限。

為什麼不一次全部載入

親手驗證

tiny-ts --plugin read

# 互動輸入：CLI明確載入，不依賴read tool
/skill:i-have-adhd 幫我把工作拆成可執行步驟

明確的 /skill:name 會由 CLI 讀取 skill 正文，並把它與本次 user request 一起送給 Agent。Repo 內 example 是自包含的 i-have-adhd，不需要外部服務。

Context 會持續成長

每次 model、tool call 與 tool result 都會讓下一輪 input 變長。Provider prompt cache 可以降低重複 prefix 成本，卻不減少 context window 佔用。你需要同時觀察：

• 每次 physical request 的 input、cacheRead 與 cache hit rate。
• active context 是否包含巨大 tool result。
• 是否已到需要 /compact 的時機。
• summary 是否仍保留決策、修改檔案、錯誤與下一步。

Context engineering 不是單獨的 prompt 技巧，而是 Tool 結果截短、Skill 漸進載入、Session 投影與 Compaction 共同形成的系統行為。

第 1 章的責任表把「持續與恢復」交給了 Session，但還沒解釋 Session 怎麼做到。你剛才看到的 context 持續成長，正是逼我們現在開始解釋 Session 的原因——下一章先從 crash 後仍可重建的 durable facts 講起。