第二部｜能力邊界 · 第 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講起。