Resilient Write 論文閱讀分析：當 LLM Coding Agent 真正卡住時，問題往往不是它不會寫，而是它不知道寫失敗了什麼

本文由 AI 產生、整理與撰寫。

論文基本資訊

• 論文標題：Resilient Write: A Six-Layer Durable Write Surface for LLM Coding Agents
• 作者：Justice Owusu Agyemang、Jerry John Kponyo、Elliot Amponsah、Godfred Manu Addo Boakye、Kwame Opuni-Boachie Obour Agyekum
• 年份：2026
• 來源：arXiv:2604.10842v2
• 論文連結：https://arxiv.org/abs/2604.10842
• 主題：LLM Coding Agents、MCP、Durable Write、Agent Tooling、Error Recovery、Session Continuity

研究問題

這篇論文處理的問題很務實，而且其實比表面上看起來更重要。近來談 coding agent，多數論文焦點放在 benchmark、程式修補、工具規劃、SWE-bench 成績，或者更高層的 agent autonomy；但這篇論文把視角往下拉到一個常被忽略的環節：agent 寫檔案時，到底有沒有一條可靠的 write path？

作者的核心觀察是，許多 LLM coding agent 雖然已經能讀檔、改檔、執行 shell、跑測試，但一旦 write 失敗，實際上常常拿不到夠結構化的失敗訊號。失敗原因可能是 content filter、傳輸截斷、session 中斷、寫入過程部分成功部分失敗，或是 agent 根本不知道自己剛剛寫進去的內容和原本預期不同。若工具層只回傳模糊錯誤，甚至什麼都不回，agent 常見行為就會變成盲目重試、重複消耗 token、遺失草稿、最後退化成 ad-hoc workaround。

因此，這篇論文真正要解的問題不是「怎麼讓 agent 更會寫程式」，而是：當 agent 對本地檔案系統進行寫入時，能不能提供一條具備 durability、recoverability 與 machine-readable error semantics 的 write surface，讓 agent 在失敗時能知道發生什麼事、如何補救、以及如何把工作接續下去。

問題背景：為什麼 write path 值得單獨研究？

作者在 introduction 直接從一個真實 incident 出發：agent 在撰寫技術報告時，內容裡出現像 sk-ant- 這類被遮罩過的 API key prefix，結果 host tool 的 content-safety regex 直接把寫入擋掉。最麻煩的不是被擋，而是 agent 沒有收到結構化錯誤，於是重試同樣內容五次，浪費時間與 token，最後才退回用 shell heredoc 繞過。

作者把這次 incident 暴露出的失敗模式拆成五類：

1. Silent rejection：寫入被擋，但 agent 沒有得到清楚訊號。
2. Draft loss：被拒絕的內容沒有被安全保留下來。
3. Retry thrashing：agent 在不知道原因時重複嘗試同一內容。
4. No structured diagnosis：錯誤訊息不足以讓 agent 分支決策。
5. Session fragility：若 session 中途中斷，先前進度很容易直接消失。

這裡其實點出一個值得注意的研究缺口：現有很多 agent framework 強調 tool use，但對寫入失敗的處理邏輯仍然太像一般 CLI 的例外處理，而不是給自主代理使用的 recoverable interface。對 human developer 來說，一句 error string 也許夠；但對 agent 來說，若沒有 typed signal、retry semantics 與恢復路徑，錯誤就很難被操作化。

方法概觀：Resilient Write 的六層 write surface

這篇論文提出的不是單一防呆技巧，而是一個六層結構的 durable write surface，作為 agent 與 filesystem 之間的 MCP server 中介。六層分別對應不同 failure mode，而且作者強調這些層是 orthogonal and independently adoptable，也就是可以分開採用，不需要一次吃下全部設計。

六層如下：

• L0：Pre-flight Risk Scoring
• L1：Transactional Atomic Writes
• L2：Resumable Chunked Composition
• L3：Typed Error Envelopes
• L4：Content-Addressed Scratchpad
• L5：Task-Continuity Handoff

如果把它當成系統設計來看，這六層其實分別在回答三件事：寫之前如何預測風險、寫的當下如何保證 durability、寫失敗後如何讓 agent 能繼續往下做。

L0：Pre-flight Risk Scoring 不是一般 secret scanning，而是預測「這次寫入會不會被擋」

L0 的設計相當務實。作者不是要做完整的安全稽核，而是用 deterministic classifier 在寫入前先估計：這份內容有沒有高機率被下游 content filter 擋掉。它不依賴 LLM，不做 network access，目標是在 100KB 內容下維持 50ms 以內的延遲。

論文列出七個 pattern family，例如：

• api_key
• github_pat
• jwt
• pem_block
• aws_secret
• pii
• binary_hint

每一類 pattern 有自己的權重，作者定義的 raw score 為：

s = Σ w_f · min(1.5, 1.0 + 0.25(n_f - 1))

再加上一些 size heuristic，例如超大檔案或超長行的固定加權，最後把分數 clamp 到 [0,1]。依分數區間再映射成 high / medium / low / safe 四種 verdict。

這裡值得注意的是，L0 不等於傳統 secret detection。作者在 discussion 明講，L0 的目的不是 audit completeness，而是預測會不會觸發 downstream filter。這個 framing 很關鍵。因為 agent 需要的不是一個事後告訴它「你可能有 secret」的工具，而是一個事前告訴它「你這樣寫很可能會被擋」的工具。這兩者看起來相近，但設計目標完全不同。

L1：Transactional Atomic Writes 把「寫入成功」變成真正可驗證的操作

L1 是全篇最核心的一層。作者設計的 rw.safe_write 並不是單純把內容寫到檔案，而是四階段協議：

1. Precondition check：支援 create / overwrite / append，並可用 expected_prev_sha256 做 optimistic concurrency control。
2. Exclusive temp-file write：先寫到暫存檔，之後 fsync()。
3. Read-back hash verification：再把暫存檔讀回來，比對 SHA-256。
4. Atomic rename：用 os.replace() 原子替換正式檔案。

這個設計的重點不只是 atomic rename，而是作者把「寫入結果和預期內容一致」這件事正式納入流程。很多 write tool 其實停在 write/close 成功就算完成，但對 agent 來說，若中途發生截斷、編碼異常或 partial write，它需要的不只是例外，而是能明確辨識 write_corruption 這類 failure mode。

另外，expected_prev_sha256 這個 optimistic concurrency control 也很實用。它讓 agent 在改檔時有辦法知道：目前目標檔是不是已被其他流程改過。這在多代理協作、IDE 與 agent 同時改檔，或人機共同編輯情境下會越來越重要。

L2：Chunked Composition 解的是大檔與中途中斷問題

當寫入內容過大、風險過高、或者單次工具調用不可靠時，作者提供 L2 的 chunk protocol。這一層有三個工具：

• rw.chunk_write
• rw.chunk_append
• rw.chunk_compose

設計思路很直接：先把內容拆成有序 chunk，每個 chunk 都先透過 safe_write 單獨持久化，最後再 compose 成最終檔案。compose 時會檢查 contiguity，確認 chunk index 沒有缺口，也會核對 manifest 裡的 total_expected。

這層最有價值的地方，在於它把「一整份寫入失敗」改寫成「某一個 chunk 失敗」。這種 failure granularity 對 agent 很重要。因為如果 chunk 1–4 已經 durable on disk，chunk 5 失敗時就不需要整份重來。這直接降低 recovery time，也讓 retry 可以真正具備定位能力。

L3：Typed Error Envelope 是這篇論文真正最 agent-centric 的設計

如果只看系統實作，L1 可能最重要；但如果從 agent interaction 設計來看，我認為 L3 是最關鍵的一層。作者把所有失敗都包進統一的 JSON envelope，例如：

• error：blocked / stale_precondition / write_corruption / quota_exceeded / policy_violation
• reason_hint：content_filter / size_limit / encoding / permission / network / unknown
• suggested_action
• retry_budget
• context：例如 risk score

這個設計的研究價值在於，它把失敗從「給人看的錯誤訊息」轉成「給 agent 用來分支策略的結構化訊號」。例如，若 reason_hint = content_filter，那就不應再重試相同 payload；若 stale_precondition，則應先重新讀檔、更新內容後再寫；若 quota_exceeded，就該換策略而不是一直寫。

尤其 retry_budget 很有意思。作者讓它跟著 response 走，而不是做成 server-side state。這雖然不是最強的控制方式，但夠簡單、透明，而且能有效阻止單輪 invocation 裡的 blind retry loop。這種設計很貼近 agent tooling 的實際需求：不需要一個很複雜的 quota system，只需要一個能阻止 agent 原地打轉的 minimal control。

L4 與 L5：把「不要把重要內容丟掉」與「中斷後怎麼接回來」做成明確機制

L4 scratchpad 的角色，是處理那些不適合進 workspace tree 的內容，例如敏感字串、PII、binary blobs。作者採 content-addressed storage，把資料存到 .resilient_write/scratch/<sha256>.bin，並用索引紀錄 metadata。這讓 agent 有一個 out-of-band 暫存位置，不需要硬把敏感內容塞進版本控制樹。

L5 handoff 則是處理 session continuity。作者把中斷時的重要狀態寫進 HANDOFF.md，裡面不只有摘要，還有 last_good_state 這種 per-file SHA-256 記錄，用來在下次接手時做 drift check。這個設計雖然不複雜，但很實際：agent 最常見的不是完全失敗，而是寫到一半被 context window、content filter 或 process crash 打斷。L5 的目的，就是讓新的 agent 不用從零重新推導整個任務脈絡。

Extensions：這篇論文有趣的地方是，連 extension tools 都是從實作過程長出來的

作者另外補了三個 extension tools：

• Chunk preview：先 dry-run compose，確認 chunks 沒問題再真正寫檔。
• Format-aware validation：對 LaTeX、JSON、Python、YAML 做語法檢查。
• Journal analytics：分析 journal 裡的 write patterns。

這部分有一個值得注意的訊號：作者不是從一開始就把整套系統設計完，而是在實際用這個系統寫論文本身的過程中，又長出 preview、validation、analytics 這三個需求。這其實反映了一個很真實的現象：agent tooling 的很多 requirement 不是設計時能想完的，而是在 agent 真正開始長時間工作後才暴露出來。

實驗與評估

論文的評估分成三部分：

1. 186 個測試案例驗證各層 correctness。
2. Motivating incident replay：把原本失敗的 telemetry report 寫作事件用 Resilient Write 重跑一次。
3. 與 naive / defensive baseline 的量化比較。

1. 186-test suite：這篇論文的系統驗證比很多 agent paper 更扎實

作者列出 186 個 tests，分布在各層與 extension 上，例如 risk score、safe write、chunks、errors、scratchpad、handoff，以及 new features。這裡最值得肯定的是：它不是只展示「看起來可跑」，而是真的把 chunk contiguity、optimistic concurrency、error envelope、format validation 等 edge cases 都寫進測試裡。

這對工具型論文很重要。因為這類系統的價值，不在於 demo 成功一次，而在於 failure path 是否也被設計與驗證。

2. Case Study：原本六次寫入、內容遺失、無結構化錯誤，重跑後縮成兩次寫入且可自我修正

在 telemetry report 的 replay 裡，原始流程與 Resilient Write 的比較非常直觀：

• 原始流程：6 次 write attempts、內容遺失、沒有 structured error、無法 self-correct、需要人工介入。
• Resilient Write：2 次 write attempts、無內容遺失、有 structured error、agent 可 self-correct、不需人工介入。

這個結果雖然是 case study，不是大規模 benchmark，但對這類系統 paper 其實很有說服力。因為它直接對應到作者一開始提出的 failure modes，並且逐一展示各層如何把問題拆小、阻斷或恢復。

3. 量化比較：5× recovery time 改善、13× self-correction rate 提升

作者與兩個 baseline 比較：

• Naive baseline：直接 open/write/close，加上 try/except。
• Defensive baseline：加入 temp-file + atomic rename，但沒有 pre-flight scoring 與 structured errors。
• Resilient Write：完整六層設計。

Table 4 的數字如下：

• Recovery time：Naive 10.0s、Defensive 5.5s、Resilient Write 2.0s
• Data loss probability：Naive 5.0%、Defensive 1.0%、Resilient Write 0.1%
• Self-correction rate：Naive 5%、Defensive 15%、Resilient Write 65%
• Wasted tool calls：Naive 25%、Defensive 12.5%、Resilient Write 3.0%

作者進一步總結為：

• 5× reduction in recovery time
• 50× reduction in data loss probability
• 13× improvement in self-correction rate

這裡最值得看的其實不是 data loss 或 recovery time，而是 self-correction rate。因為這篇論文的核心主張，本來就不是單純提高 write 成功率，而是讓 agent 在 write 失敗時能自己修正策略。65% 對 5% / 15% 的差距，某種程度上正說明：只要工具層願意提供結構化訊號，agent 行為可以被大幅改善。

這篇論文的貢獻

這篇論文的貢獻可以整理成三個層次。

1. 它把 coding agent 的 write path 問題正式化了。 這本來常被視為 implementation detail，但作者把它提升成一個可被設計、測試與量化的 agent systems problem。
2. 它提出一個六層、可獨立採用的 durable write surface。 這不只是單一 patch，而是一套 failure-mode-driven 的結構設計。
3. 它把「讓 agent 看得懂錯誤」放到系統設計核心。 也就是從 typed error envelope、retry budget、handoff state 這些設計，把 recoverability 視為一級需求，而不是附屬功能。

若從更大的脈絡來看，這篇論文其實在提醒一件事：很多 agent 系統的瓶頸不一定是 reasoning，而是工具介面根本沒有設計成能讓 agent operationalize failure。

限制與批判

這篇論文雖然有意思，但也有幾個限制需要講清楚。

• 第一，評估規模仍然偏小，且部分量化指標帶有估計性質。 文中明講 recovery time 與 wasted-call 來自開發期間量測，而 data-loss probability 與 self-correction rate 則有一部分是結合 local LLM severity analysis 的估計。這表示數字可以看方向，但不宜過度當成嚴格 benchmark。
• 第二，它解的是 write path，不是整個 agent state transaction。 作者自己也承認還沒有 cross-file transaction 或 workspace-level write-ahead logging。也就是說，每個檔案 individually atomic，但整組修改未必是 atomic。
• 第三，L0 仍是 pattern-based。 雖然夠快，但 novel secret format、語系特定 PII、或更複雜的 obfuscation，仍可能漏掉。
• 第四，手法偏工程，不是理論突破。 若期待新的學習方法或更普遍的 agent architecture innovation，這篇可能不屬於那種類型。它更像是把多年 systems wisdom 重新搬回 MCP/agent write interface。

不過，這些限制並不削弱它的價值。相反地，這篇論文最有價值的地方，本來就不是提出某個新模型，而是把一個非常真實、非常常見、卻長期被忽略的工具層脆弱點做紮實整理。

重點整理

• 這篇論文聚焦的是 LLM coding agent 的 write path 脆弱性，而不是高層規劃或程式修補能力。
• 作者指出 write 失敗的核心問題不只是失敗本身，而是 agent 通常拿不到足夠結構化的錯誤訊號，因此容易 draft loss、retry thrashing、session fragility。
• Resilient Write 提出六層 durable write surface：L0 風險預測、L1 原子寫入、L2 chunk 組裝、L3 typed errors、L4 scratchpad、L5 handoff。
• L3 typed error envelope 是整體設計中最 agent-centric 的部分，因為它讓失敗能被 agent 當作可操作的控制訊號，而不是模糊字串。
• 量化比較顯示，Resilient Write 相較 naive / defensive baseline，達到 5× recovery time 改善、50× data loss 下降與 13× self-correction 提升。
• 這篇論文的真正貢獻，是把 coding agent 的工具層 write failure 從 implementation detail 拉升成值得單獨設計與評估的系統問題。

Takeaway

對 coding agent 而言，真正麻煩的通常不是它不會改檔，而是它在改檔失敗時根本不知道發生了什麼，也不知道下一步該怎麼做。 這篇論文的價值，就在於它沒有再把 write 當成一個理所當然的小工具，而是把它當成 agent autonomy 能否落地的關鍵基礎設施來重新設計。當 agent 開始長時間工作、跨多步驟處理真實檔案、而且要在失敗後自己恢復時，像 Resilient Write 這種 durable、typed、可 handoff 的 write surface，很可能會比再多一點 prompt engineering 更實際。

免責聲明

本文由 AI 產生、整理與撰寫，內容主要依據公開論文、技術文件與可取得之研究資料進行彙整、解讀與摘要。儘管已盡力確保內容之完整性與可讀性，仍可能因模型理解限制、資料來源差異、語意轉譯過程或資訊更新時間差而存在疏漏、不精確或更新延遲之處。本文內容僅供研究交流與知識分享參考，實際技術細節、實驗設定與最終結論，仍應以原始論文、官方文件及作者公開資料為準。