<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Harness on Tarragon</title><link>https://tarrragon.github.io/blog/tags/harness/</link><description>Recent content in Harness on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Tue, 12 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/harness/index.xml" rel="self" type="application/rss+xml"/><item><title>4.17 Coding agent harness：scaffold / context engineering / subagent</title><link>https://tarrragon.github.io/blog/llm/04-applications/coding-agent-harness/</link><pubDate>Tue, 12 May 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/llm/04-applications/coding-agent-harness/</guid><description>&lt;p>教材整體 framing 是「LLM 寫 code 工程實務」、模組四前面 11 章寫的是&lt;strong>通用 LLM 應用層原理&lt;/strong>（RAG / tool use / agent / VLM 等）。本章補上「coding agent 怎麼設計」這層 — 為什麼 Claude Code / Cursor / Aider / Codex 這類工具長那樣、scaffold 跟 harness 怎麼分、context budget 怎麼配。本章把這些設計取捨從特定產品抽出來、寫成跨工具世代不變的工程原理。&lt;/p>
&lt;h2 id="本章目標">本章目標&lt;/h2>
&lt;p>讀完本章後、你應該能：&lt;/p>
&lt;ol>
&lt;li>用 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/scaffold-vs-harness/" data-link-title="Scaffold vs Harness" data-link-desc="Coding agent 的兩個工程層次：scaffold 是建構時靜態結構、harness 是 runtime 的 tool dispatch &amp;#43; context management &amp;#43; safety">scaffold vs harness&lt;/a> 分層拆解任何 coding agent。&lt;/li>
&lt;li>對自己工作流計算 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/context-budget/" data-link-title="Context Budget" data-link-desc="Coding agent 的 context window 拆分配額：system prompt &amp;#43; tool schema &amp;#43; history &amp;#43; file content &amp;#43; reasoning &amp;#43; tool result 各佔多少、留多少 margin">context budget&lt;/a>、看到 budget 超標訊號時知道怎麼修。&lt;/li>
&lt;li>判斷何時值得拆 &lt;a href="https://tarrragon.github.io/blog/llm/knowledge-cards/subagent/" data-link-title="Subagent" data-link-desc="Coding agent 中把特定責任拆給專門子 agent 的設計模式、各 subagent 有獨立 context、由 main agent 透過 handoff 調度">subagent&lt;/a>、何時用 single agent。&lt;/li>
&lt;li>看 Claude Code / Cursor / Aider 等 coding agent 的設計差異、能對應到本章 framing。&lt;/li>
&lt;/ol>
&lt;h2 id="scaffold-vs-harness-分層">Scaffold vs Harness 分層&lt;/h2>
&lt;p>Coding agent 的內部結構分兩層：&lt;/p>





&lt;div class="highlight">&lt;pre tabindex="0" class="chroma">&lt;code class="language-text" data-lang="text">&lt;span class="line">&lt;span class="ln"> 1&lt;/span>&lt;span class="cl">Scaffold（建構時靜態結構、編譯 / 載入時就決定）：
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 2&lt;/span>&lt;span class="cl"> - System prompt 模板（agent 角色、輸出約束、錯誤處理 policy）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 3&lt;/span>&lt;span class="cl"> - Tool schema 註冊（read_file / write_file / run_bash / web_fetch 等 spec）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 4&lt;/span>&lt;span class="cl"> - Subagent 拓樸（main agent + 子 agent 關係）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 5&lt;/span>&lt;span class="cl"> - Skill / playbook 註冊（特定任務的 known recipe）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 6&lt;/span>&lt;span class="cl"> - 安全 policy（permission boundary、要 confirm 的動作清單）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 7&lt;/span>&lt;span class="cl">
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 8&lt;/span>&lt;span class="cl">Harness（runtime 動態運作、每個 query / loop iteration 跑）：
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln"> 9&lt;/span>&lt;span class="cl"> - Tool dispatch（接 LLM tool call、call function、回 result）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">10&lt;/span>&lt;span class="cl"> - Context budget 管理（剪裁 history、塞新內容、避免超 budget）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">11&lt;/span>&lt;span class="cl"> - Safety / 中斷（confirm UI、permission check、可逆性判斷）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">12&lt;/span>&lt;span class="cl"> - Error recovery（tool failed → retry / fallback / escalate）
&lt;/span>&lt;/span>&lt;span class="line">&lt;span class="ln">13&lt;/span>&lt;span class="cl"> - Telemetry（trace / metrics / cost、見 [4.20 OTel tracing](/llm/04-applications/llm-tracing-and-observability/)）&lt;/span>&lt;/span>&lt;/code>&lt;/pre>&lt;/div>&lt;p>不同 coding agent 的 scaffold / harness 比較：&lt;/p></description><content:encoded><![CDATA[<p>教材整體 framing 是「LLM 寫 code 工程實務」、模組四前面 11 章寫的是<strong>通用 LLM 應用層原理</strong>（RAG / tool use / agent / VLM 等）。本章補上「coding agent 怎麼設計」這層 — 為什麼 Claude Code / Cursor / Aider / Codex 這類工具長那樣、scaffold 跟 harness 怎麼分、context budget 怎麼配。本章把這些設計取捨從特定產品抽出來、寫成跨工具世代不變的工程原理。</p>
<h2 id="本章目標">本章目標</h2>
<p>讀完本章後、你應該能：</p>
<ol>
<li>用 <a href="/blog/llm/knowledge-cards/scaffold-vs-harness/" data-link-title="Scaffold vs Harness" data-link-desc="Coding agent 的兩個工程層次：scaffold 是建構時靜態結構、harness 是 runtime 的 tool dispatch &#43; context management &#43; safety">scaffold vs harness</a> 分層拆解任何 coding agent。</li>
<li>對自己工作流計算 <a href="/blog/llm/knowledge-cards/context-budget/" data-link-title="Context Budget" data-link-desc="Coding agent 的 context window 拆分配額：system prompt &#43; tool schema &#43; history &#43; file content &#43; reasoning &#43; tool result 各佔多少、留多少 margin">context budget</a>、看到 budget 超標訊號時知道怎麼修。</li>
<li>判斷何時值得拆 <a href="/blog/llm/knowledge-cards/subagent/" data-link-title="Subagent" data-link-desc="Coding agent 中把特定責任拆給專門子 agent 的設計模式、各 subagent 有獨立 context、由 main agent 透過 handoff 調度">subagent</a>、何時用 single agent。</li>
<li>看 Claude Code / Cursor / Aider 等 coding agent 的設計差異、能對應到本章 framing。</li>
</ol>
<h2 id="scaffold-vs-harness-分層">Scaffold vs Harness 分層</h2>
<p>Coding agent 的內部結構分兩層：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln"> 1</span><span class="cl">Scaffold（建構時靜態結構、編譯 / 載入時就決定）：
</span></span><span class="line"><span class="ln"> 2</span><span class="cl">  - System prompt 模板（agent 角色、輸出約束、錯誤處理 policy）
</span></span><span class="line"><span class="ln"> 3</span><span class="cl">  - Tool schema 註冊（read_file / write_file / run_bash / web_fetch 等 spec）
</span></span><span class="line"><span class="ln"> 4</span><span class="cl">  - Subagent 拓樸（main agent + 子 agent 關係）
</span></span><span class="line"><span class="ln"> 5</span><span class="cl">  - Skill / playbook 註冊（特定任務的 known recipe）
</span></span><span class="line"><span class="ln"> 6</span><span class="cl">  - 安全 policy（permission boundary、要 confirm 的動作清單）
</span></span><span class="line"><span class="ln"> 7</span><span class="cl">
</span></span><span class="line"><span class="ln"> 8</span><span class="cl">Harness（runtime 動態運作、每個 query / loop iteration 跑）：
</span></span><span class="line"><span class="ln"> 9</span><span class="cl">  - Tool dispatch（接 LLM tool call、call function、回 result）
</span></span><span class="line"><span class="ln">10</span><span class="cl">  - Context budget 管理（剪裁 history、塞新內容、避免超 budget）
</span></span><span class="line"><span class="ln">11</span><span class="cl">  - Safety / 中斷（confirm UI、permission check、可逆性判斷）
</span></span><span class="line"><span class="ln">12</span><span class="cl">  - Error recovery（tool failed → retry / fallback / escalate）
</span></span><span class="line"><span class="ln">13</span><span class="cl">  - Telemetry（trace / metrics / cost、見 [4.20 OTel tracing](/llm/04-applications/llm-tracing-and-observability/)）</span></span></code></pre></div><p>不同 coding agent 的 scaffold / harness 比較：</p>
<table>
  <thead>
      <tr>
          <th>工具</th>
          <th>Scaffold 特點</th>
          <th>Harness 特點</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Claude Code</td>
          <td>Skill registry、subagent system、structured permission</td>
          <td>強 context budget 管理、explicit handoff、trace</td>
      </tr>
      <tr>
          <td>Cursor</td>
          <td>Composer + chat + tab、tool list 較簡</td>
          <td>IDE-integrated、tool dispatch 在 client + server 切</td>
      </tr>
      <tr>
          <td>Aider</td>
          <td>跟 git 緊密、edit-format spec</td>
          <td>Repl-style、自動 commit、線性 loop</td>
      </tr>
      <tr>
          <td>Codex CLI</td>
          <td>跟 OpenAI assistants API 對齊</td>
          <td>Stream-based、tool call 即時執行</td>
      </tr>
      <tr>
          <td>Continue.dev</td>
          <td>Plugin-style、provider 抽象</td>
          <td>較輕量、tool dispatch 在 plugin host</td>
      </tr>
  </tbody>
</table>
<p>關鍵理解：所有 coding agent 都遵循這個 framing、差異在「scaffold 多複雜」「harness 多強」、不是有沒有這兩層。</p>
<h2 id="context-budget-工程實務">Context Budget 工程實務</h2>
<p><a href="/blog/llm/knowledge-cards/context-budget/" data-link-title="Context Budget" data-link-desc="Coding agent 的 context window 拆分配額：system prompt &#43; tool schema &#43; history &#43; file content &#43; reasoning &#43; tool result 各佔多少、留多少 margin">Context budget</a> 是 coding agent harness 的核心責任。實務拆分（以 200K context 模型為例）：</p>
<table>
  <thead>
      <tr>
          <th>元件</th>
          <th>預算 %</th>
          <th>內容</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>System prompt + tool schema</td>
          <td>5-15%</td>
          <td>Agent 角色、輸出約束、tool spec</td>
      </tr>
      <tr>
          <td>Conversation history</td>
          <td>10-30%</td>
          <td>過去回合的 user query + assistant + tool call</td>
      </tr>
      <tr>
          <td>Current task file context</td>
          <td>30-50%</td>
          <td>開啟檔案、grep 結果、@-mention</td>
      </tr>
      <tr>
          <td>Tool result（current step）</td>
          <td>0-20%</td>
          <td>file read / bash output / test result</td>
      </tr>
      <tr>
          <td>Reasoning trace（若 reasoning model）</td>
          <td>0-15%</td>
          <td><code>&lt;think&gt;...&lt;/think&gt;</code> 段</td>
      </tr>
      <tr>
          <td>Margin / safety buffer</td>
          <td>10-20%</td>
          <td>Generation 階段不被 context limit 截斷</td>
      </tr>
  </tbody>
</table>
<p>關鍵 25% 規則：<strong>Scaffold 部分（system prompt + tool schema + conversation history）合計不超過 25% context</strong>。剩 75% 給「當下任務」、避免 <a href="/blog/llm/knowledge-cards/lost-in-the-middle/" data-link-title="Lost in the Middle" data-link-desc="LLM 對 long context 中段內容的 attention / recall 顯著低於開頭與結尾的現象">lost-in-the-middle</a> 把指令吃掉。</p>
<p>超標訊號跟對應策略：</p>
<table>
  <thead>
      <tr>
          <th>超標訊號</th>
          <th>緩解策略</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>模型開始忽略 system prompt 指令</td>
          <td>用 <a href="/blog/llm/knowledge-cards/prompt-cache/" data-link-title="Prompt Cache" data-link-desc="重複出現的 prompt prefix 在推論伺服器或 LLM 服務端被 cache、後續 query 跳過 prefill、大幅降 cost 跟 TTFT">prompt cache</a> 把 system prompt 攤平</td>
      </tr>
      <tr>
          <td>Tool call 重複過去步驟</td>
          <td>History 過長、需要 summarize 舊回合</td>
      </tr>
      <tr>
          <td>回答跟前文重複 / 矛盾</td>
          <td>中段 lost-in-the-middle、reorder 重要內容到末尾</td>
      </tr>
      <tr>
          <td>Generation 被截斷</td>
          <td>Margin 不夠、降低 file content 或 history</td>
      </tr>
      <tr>
          <td>Reasoning trace 截斷</td>
          <td>換更長 context 模型、或拆任務</td>
      </tr>
  </tbody>
</table>
<p>實作概要：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl">每個 turn 開始時、harness 算：
</span></span><span class="line"><span class="ln">2</span><span class="cl">  available_input = context_window - reserve_margin
</span></span><span class="line"><span class="ln">3</span><span class="cl">  used = len(system + tool_schema + history + new_content)
</span></span><span class="line"><span class="ln">4</span><span class="cl">
</span></span><span class="line"><span class="ln">5</span><span class="cl">  if used &gt; available_input × 0.75：
</span></span><span class="line"><span class="ln">6</span><span class="cl">    觸發 summarize：把舊 history 壓縮成 1 段摘要
</span></span><span class="line"><span class="ln">7</span><span class="cl">    或觸發 dispatch：交給 subagent 處理特定子任務、回主 agent 時只帶 summary</span></span></code></pre></div><h2 id="subagent-設計">Subagent 設計</h2>
<p><a href="/blog/llm/knowledge-cards/subagent/" data-link-title="Subagent" data-link-desc="Coding agent 中把特定責任拆給專門子 agent 的設計模式、各 subagent 有獨立 context、由 main agent 透過 handoff 調度">Subagent</a> 把單一大 agent 拆成多個專責子 agent、各自有獨立 context。何時用：</p>
<table>
  <thead>
      <tr>
          <th>情境</th>
          <th>用 subagent？</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Single agent context 撐不住任務複雜度</td>
          <td>是</td>
      </tr>
      <tr>
          <td>Specialty 邊界清楚（test / docs / refactor 各自有專家）</td>
          <td>是</td>
      </tr>
      <tr>
          <td>任務簡單（autocomplete、單行修改）</td>
          <td>否</td>
      </tr>
      <tr>
          <td>Specialty 邊界模糊（強行拆增加 handoff overhead）</td>
          <td>否</td>
      </tr>
      <tr>
          <td>本地小模型（&lt; 14B）</td>
          <td>否（handoff 對小模型不穩）</td>
      </tr>
  </tbody>
</table>
<p>主流 subagent 模式：</p>
<h3 id="1-search-subagent">1. Search subagent</h3>
<p><strong>Specialty</strong>：在大 codebase 找相關片段、不污染 main agent context
<strong>Tool</strong>：grep / find / semantic search
<strong>Output</strong>：top-K 相關段落 + 摘要、main agent 不需要看完整 grep 結果</p>
<h3 id="2-test-runner-subagent">2. Test runner subagent</h3>
<p><strong>Specialty</strong>：跑測試、解讀失敗、提出 fix 建議
<strong>Tool</strong>：run_bash（pytest / jest 等）+ read failed test
<strong>Output</strong>：「測試結果 + 失敗根因 + 建議 fix」、不是完整 test log</p>
<h3 id="3-docs-writer-subagent">3. Docs writer subagent</h3>
<p><strong>Specialty</strong>：寫 docstring / README / commit message
<strong>System prompt</strong>：強化「寫作風格、語言、長度」、跟 main coding agent 完全不同的 system prompt
<strong>Output</strong>：寫好的 docs 文字</p>
<h3 id="4-code-review-subagent">4. Code review subagent</h3>
<p><strong>Specialty</strong>：對 PR diff 做 review、檢查 style / bug / security
<strong>Tool</strong>：git diff / grep
<strong>Output</strong>：comments 列表</p>
<h3 id="5-long-running-task-subagent">5. Long-running task subagent</h3>
<p><strong>Specialty</strong>：跑可能持續數分鐘的任務（如 large-scale refactor）、main agent 不阻塞
<strong>Tool</strong>：背景 process management
<strong>Output</strong>：階段性進度回報 + 最終結果</p>
<p>主 agent 對 subagent 的 handoff 設計：</p>





<div class="highlight"><pre tabindex="0" class="chroma"><code class="language-text" data-lang="text"><span class="line"><span class="ln">1</span><span class="cl">main agent 收到任務
</span></span><span class="line"><span class="ln">2</span><span class="cl">   ↓ 判斷 specialty
</span></span><span class="line"><span class="ln">3</span><span class="cl">   ↓ 用 dispatch_subagent tool 呼叫
</span></span><span class="line"><span class="ln">4</span><span class="cl">   tool spec：{name, task_brief, expected_output_format}
</span></span><span class="line"><span class="ln">5</span><span class="cl">   ↓
</span></span><span class="line"><span class="ln">6</span><span class="cl">Subagent 在自己 context 內跑完
</span></span><span class="line"><span class="ln">7</span><span class="cl">   ↓ 回 summary（不是完整 trace）
</span></span><span class="line"><span class="ln">8</span><span class="cl">   ↓
</span></span><span class="line"><span class="ln">9</span><span class="cl">main agent 拿到 summary、繼續推進</span></span></code></pre></div><h2 id="跟既有概念的關係">跟既有概念的關係</h2>
<table>
  <thead>
      <tr>
          <th>既有章節</th>
          <th>跟本章的關係</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td><a href="/blog/llm/04-applications/tool-use-principles/" data-link-title="4.3 Tool use 原理：LLM 跟外部世界互動" data-link-desc="Structured output 是 LLM 跨入工程系統的橋、function calling 取捨、為什麼本地小模型 tool use 表現崩潰">4.3 Tool use</a></td>
          <td>Tool spec 是 scaffold 的核心、tool dispatch 在 harness</td>
      </tr>
      <tr>
          <td><a href="/blog/llm/04-applications/agent-architecture/" data-link-title="4.4 Agent 架構原理" data-link-desc="Agent loop 結構、失敗模式、什麼任務適合 vs 不適合、跟人類審查的協作模型">4.4 Agent 架構</a></td>
          <td>Agent loop 是 harness 的內部執行迴圈</td>
      </tr>
      <tr>
          <td><a href="/blog/llm/04-applications/application-protocols/" data-link-title="4.6 應用層協議：function calling / structured output / MCP" data-link-desc="三個常被混為一談的概念：模型能力、sampling 約束、server 協議，三者的層級差異與組合方式">4.6 應用層協議</a></td>
          <td>Function calling / MCP 是 tool 跟 subagent 之間的協議</td>
      </tr>
      <tr>
          <td><a href="/blog/llm/04-applications/long-context-engineering/" data-link-title="4.11 Long context engineering" data-link-desc="128K / 1M context 模型怎麼用：claimed vs effective context、lost-in-the-middle、context 設計策略、Long context vs RAG 取捨">4.11 Long context</a></td>
          <td>Context budget 是 long context 的工程實務面</td>
      </tr>
      <tr>
          <td><a href="/blog/llm/04-applications/prompt-caching-engineering/" data-link-title="4.18 Prompt caching 工程實務：cost / latency 最大槓桿" data-link-desc="Prompt cache 怎麼運作、cache_control 設計、coding agent 跟 long-context 的 cache pattern、anti-pattern 跟 cache miss 訊號">4.18 Prompt caching</a></td>
          <td>是 scaffold 部分（system + tool schema）的 cost / latency 優化</td>
      </tr>
      <tr>
          <td><a href="/blog/llm/04-applications/agent-memory-architecture/" data-link-title="4.19 Agent memory 分層架構" data-link-desc="Agent 在 context window 之外管理長期狀態的設計：working / short-term / long-term episodic / semantic / procedural 五個層次、寫入時機、retrieval 設計、失敗模式">4.19 Agent memory</a></td>
          <td>History 跟 long-term memory 是 harness 跟 storage 的界面</td>
      </tr>
  </tbody>
</table>
<h2 id="跟具體-coding-agent-的-mapping">跟具體 coding agent 的 mapping</h2>
<p>讀者實際用 / 想客製某個 coding agent 時、用本章的 framing 拆解：</p>
<h3 id="claude-code">Claude Code</h3>
<p><strong>Scaffold</strong>：CLAUDE.md（system prompt 入口）、Skills registry、SubagentTypes、tool schema
<strong>Harness</strong>：context budget management、Task tool（dispatch subagent）、permission system、trace
<strong>特色</strong>：完整 scaffold-harness 分層、強 subagent system、explicit context budget</p>
<h3 id="cursor">Cursor</h3>
<p><strong>Scaffold</strong>：System prompt 較固定、tool list 較簡、Composer mode 是 scaffold variant
<strong>Harness</strong>：IDE 整合度高、tool dispatch 跨 client / server、streaming response
<strong>特色</strong>：產品優化重於可客製、scaffold 半開放</p>
<h3 id="aider">Aider</h3>
<p><strong>Scaffold</strong>：edit-format（diff / udiff / whole）+ git integration、tool 較少（read / edit / run）
<strong>Harness</strong>：repl-style loop、自動 commit、線性對話
<strong>特色</strong>：CLI-first、scaffold 簡單、harness 圍繞 git 設計</p>
<h3 id="continuedev搭本地-llm">Continue.dev（搭本地 LLM）</h3>
<p><strong>Scaffold</strong>：Provider-agnostic、tool list 由 plugin 註冊
<strong>Harness</strong>：較輕量、tool dispatch 在 VS Code extension host
<strong>特色</strong>：適合本地 LLM、scaffold / harness 都相對開放</p>
<h2 id="失敗模式跟緩解">失敗模式跟緩解</h2>
<p>Coding agent 常見失敗：</p>
<table>
  <thead>
      <tr>
          <th>失敗</th>
          <th>根因</th>
          <th>緩解</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Context 用爆、模型失憶</td>
          <td>Budget 設計不當</td>
          <td>25% 規則、prompt cache、subagent 分擔</td>
      </tr>
      <tr>
          <td>Tool call infinite loop</td>
          <td>Harness 沒設 step 上限或 cost cap</td>
          <td>加 max_steps / max_cost、定期讓 user check</td>
      </tr>
      <tr>
          <td>Subagent 答錯仍被 main 採用</td>
          <td>Main agent 沒 verify subagent output</td>
          <td>加 verification step、let main 看 subagent trace</td>
      </tr>
      <tr>
          <td>修改檔案後 test 沒跑</td>
          <td>Scaffold 沒強制「先 test 後 commit」</td>
          <td>System prompt 加 explicit checklist、harness 加 hook</td>
      </tr>
      <tr>
          <td>Reasoning model 配短 context</td>
          <td>Reasoning trace 擠壓任務 context</td>
          <td>配 64K+ context、或拆任務</td>
      </tr>
      <tr>
          <td>Permission boundary 不夠細</td>
          <td>Scaffold 安全 policy 太寬</td>
          <td>副作用類 tool 拆細、加 confirm UI（見 <a href="/blog/llm/01-local-llm-services/hands-on/permission-boundary/" data-link-title="Hands-on：Ollama 改檔案 / 寫程式碼的權限邊界在哪" data-link-desc="四組對照實驗：Ollama 自己沒 FS / shell 權限、wrapper 才有；--dry-run / --confirm / --auto 三檔審查粒度的取捨">hands-on permission-boundary</a>）</td>
      </tr>
  </tbody>
</table>
<h2 id="本地小模型跑-coding-agent-的限制">本地小模型跑 coding agent 的限制</h2>
<p>本地 &lt; 14B 模型跑完整 coding agent 通常不穩、根因（跟 <a href="/blog/llm/03-theoretical-foundations/reasoning-models/" data-link-title="3.8 Reasoning models：test-time compute paradigm" data-link-desc="Chain-of-thought 從 prompting 技巧演化成訓練 paradigm、reasoning model 的內部運作、本地可跑的選項與適用任務">3.8 reasoning-models</a> / <a href="/blog/llm/04-applications/agent-architecture/" data-link-title="4.4 Agent 架構原理" data-link-desc="Agent loop 結構、失敗模式、什麼任務適合 vs 不適合、跟人類審查的協作模型">4.4 agent-architecture</a> 已述）：</p>
<ol>
<li><strong>Tool use 不穩</strong>：小模型 function calling 訓練不足、tool call 格式錯誤率高</li>
<li><strong>Long context 退化</strong>：&lt; 14B 模型 effective context 通常 &lt; 16K、coding agent 場景容易撞 budget</li>
<li><strong>Reasoning 弱</strong>：multi-step planning、failure recovery 都需要 reasoning 能力</li>
<li><strong>Subagent handoff 失敗</strong>：小模型對「該 handoff 給誰」的判斷不穩</li>
</ol>
<p>實務組合：</p>
<ul>
<li><strong>Autocomplete + 簡單 chat</strong>：本地 7B-14B coder（Qwen3-Coder / Gemma 4 coder）可勝任</li>
<li><strong>完整 coding agent</strong>：30B+ 本地模型或雲端旗艦</li>
<li><strong>混用</strong>：本地小模型當 autocomplete + 雲端旗艦當 agent</li>
</ul>
<h2 id="何時過時--何時不過時">何時過時 / 何時不過時</h2>
<p><strong>不會過時的部分</strong>：</p>
<ul>
<li>Scaffold vs harness 分層 framing</li>
<li>Context budget 配額概念跟 25% 規則</li>
<li>Subagent 設計原則跟 handoff 機制</li>
<li>失敗模式分類（context 爆、infinite loop、permission 邊界）</li>
<li>本地小模型限制</li>
</ul>
<p><strong>會變的部分</strong>：</p>
<ul>
<li>具體 coding agent（Claude Code / Cursor / Aider 等持續演化）</li>
<li>Subagent registry 標準化（目前各家不同）</li>
<li>Tool schema 標準化（MCP 是其中一條路）</li>
<li>本地小模型的 agent 能力（會逐步追上）</li>
</ul>
<h2 id="下一章">下一章</h2>
<p>下一章：<a href="/blog/llm/04-applications/prompt-caching-engineering/" data-link-title="4.18 Prompt caching 工程實務：cost / latency 最大槓桿" data-link-desc="Prompt cache 怎麼運作、cache_control 設計、coding agent 跟 long-context 的 cache pattern、anti-pattern 跟 cache miss 訊號">4.18 Prompt caching 工程實務</a>、看 scaffold 部分的 cost / latency 優化。</p>
]]></content:encoded></item></channel></rss>