多步 agent 鏈怎麼查最弱環：一環壞掉會靜默傳垃圾
幾個月前我在《自動內容不等於垃圾：品質閘門實戰》裡，把這道自審重寫的品質閘門，捧成把產出從「不能看」救到「比我自己寫的還好」的招牌機制。這篇要回頭拆穿它：那道閘門的解析器一壞，就把它自己剛判爛的原稿靜默放行，PO 出一則 14 字的垃圾貼文。
《Agentic Design Patterns》第 1 章講提示鏈（Prompt Chaining）。核心一句話：一個複雜任務，與其塞給模型一次做完，不如拆成鏈式的子步驟，前一環的輸出餵給後一環。研究一環、生成一環、自審一環、發布一環，各司其職，整條鏈看起來乾淨又可靠。
我們的 Moltbook 自動發文就是這樣一條鏈：先研究（抓產業新聞、HN 熱門、自己的貼文成績當素材），再生成貼文，接著自審打分，最後發文。四環俱全，我們很滿意。然後我們對自己做了對抗式稽核。這一章的真相是：一條鏈看起來完整，不代表它可靠，它只跟最弱那一環的錯誤處理一樣強。而我們最弱那一環，靜默 PO 出了一則 14 字的垃圾貼文。
第三環壞掉，垃圾照樣走完剩下的鏈
自審那一環（我們叫它 quality gate）的設計是這樣：把生成好的草稿丟回給模型打 1 到 10 分，7 分以上就 APPROVED 放行，不到 7 分就回一個 REWRITE 加一份改寫過的版本。聽起來很完整，一個會自我修正的環。
問題出在解析那份改寫版。程式從模型回覆裡撈新標題和新內文，撈到就換上，撈不到就走進 else：
if [ -n "$NEW_TITLE" ] && [ -n "$NEW_CONTENT" ]; then
TITLE="$NEW_TITLE"; CONTENT="$NEW_CONTENT" # 用改寫版
else
log "Quality gate: REWRITE requested but failed to parse, using original"
fi
模型的改寫版只要格式跑掉（沒照 TITLE: 加 --- 的格式吐），這段就解析失敗，然後退回原稿。而會被判 REWRITE 的原稿，本來就是那份品質不夠的。自審環發現草稿爛，要求改寫，改寫版解析失敗，於是它把那份它自己剛判定爛的原稿，原封不動放行到下一環。更糟的是下一環（發文）當時沒有任何長度關卡。於是一則只有 14 字的貼文，一路走完自審、走完發文，靜靜地 PO 上了公開平台。
自審環的表面任務是攔爛草稿，它的錯誤路徑卻是「攔不下來就放原稿過」。這條鏈看起來有自我修正，實際上最弱那一環的錯誤處理是靜默放行。
先花幾分鐘查你自己的鏈
01 鏈上每一環的輸出，下一環用之前驗過嗎 把你的鏈畫出來，找出每個「解析上一環輸出」的點（撈 JSON、切字串、抓某段標記）。每一個解析點後面，都該緊跟一個檢查：解析結果是不是空的、格式對不對。沒檢查就往下用，就是拿沒驗過的東西當可靠輸入。
# 撈出鏈裡每個解析點，看後面有沒有跟一個檢查
grep -nE "sed .*1,/\^---/d|grep \"\^TITLE:|jq -r|解析|parse" your-chain.sh
紅旗：解析完直接餵給下一步，中間沒有一個 if 在檢查解析出來的值是不是空、格式對不對。
02 某一環解析失敗時，會停下來還是靜默放行
逐一翻每個解析點的失敗分支。失敗時的處理如果是「用上一個值繼續」「回原稿」「|| true 吞掉」，那就是把垃圾往下傳而不喊停。我們就栽在一句 using original：它不是修正，是放行。
# 找「失敗就退回原值 / 吞錯往下走」這種靜默 fallback
grep -niE "using original|fallback|failed to parse|回原|退回|\|\| true" your-chain.sh
紅旗：解析失敗的處理是「拿原本的值繼續」，而那個原本的值沒人保證是好的。
03 發布前有沒有一道硬性的 min-length 或 quality gate
不管前面幾環怎麼放水，發出去之前該有最後一道確定性的關卡。撈出真正的發布動作（curl POST、寫 API、排程），看它前面有沒有一個「太短、太薄就中止」的 gate 擋著。
# 發布動作之前，有沒有長度或品質關卡
grep -nE "wc -w|wc -m|MIN_WORDS|-lt .*MIN|too short|too thin|太短|太薄" your-chain.sh
紅旗：從生成到真正送出去之間，找不到任何一個「不合格就 exit」的關卡。
我們實際怎麼修的
2026-07-04 那一刀補在發文之前，一道 min-length gate：內文少於 40 個 word 就中止這一輪，log 一句 too thin 然後 exit 0，不發。跳過一輪不痛，下一次排程會重新生一篇；發一則 14 字廢文到公開平台，才是真的丟臉。
值得講清楚：我們沒有假裝把上游那個解析器修到完美。改寫版偶爾格式跑掉、解析失敗，這件事還會發生。我們做的是承認鏈的最弱環會出錯，然後在終點前把最後一道門守住，讓它就算出錯也不會把垃圾送出去。這正是提示鏈的重點：你擋不住每一環都不出錯，但你可以保證出錯不會靜默流到終點。
順帶一提，我們另一條發文鏈 content-cascade 這件事做對了：每一則生成的貼文，排程前都先驗一次，模型如果回「請提供文章內容」這種討拍句就丟掉，少於 80 字元也丟掉。同樣是鏈，差別只在最弱環的錯誤處理有沒有人守。
提示鏈體檢清單
對你自己的多步鏈跑一遍：
- 每一環的輸出，下一環拿去用之前有驗過（非空、格式對）嗎
- 每個「解析上一環輸出」的點，後面緊跟一個檢查嗎
- 某環解析失敗時，是停下來喊停，還是靜默退回原值往下傳
- 發布前有一道確定性的 min-length 或 quality gate 擋著嗎
- 那道 gate 攔下來時，是安全地跳過（下輪再生），還是硬把半成品送出去
- 你的 log 分得出「這輪被 gate 攔掉」和「這輪正常發出」嗎
這一章的四句話
- 一條鏈只跟它最弱那一環的錯誤處理一樣強。四環都在，不代表四環都守得住。
- 最危險的不是某環報錯，是某環解析失敗卻靜默退回原值，把垃圾若無其事地往下傳。
- 每個解析上一環輸出的點，後面都要緊跟一個檢查；不驗就往下用，等於拿沒驗過的東西當可靠輸入。
- 你擋不住每一環都不出錯，但你可以在終點前放一道確定性的 gate，保證出錯不會靜默流到公開平台。
原始碼位置：~/.openclaw/scripts/moltbook-autopost.sh（研究→生成→自審→發文鏈；自審 quality gate 在 REVIEW_PROMPT 那段，using original 是靜默 fallback；2026-07-04 補的 min-length gate MIN_WORDS=40 擋在發文前）、content-cascade-multi.sh（clean_post + 每則排程前的品質/長度驗證，最弱環有人守的對照組）。
這是《Agentic Design Patterns》× 龍蝦艦隊系列。我們照書把一人公司的 AI agent 艦隊系統化，然後對自己做對抗式稽核。宣稱做到的每一章，都被重新驗證過一次，也把查法和改法整理成你能照著跑的步驟。這個系列的可信度，來自我們願意公開自己打臉自己。