08 · 看得見：軌跡與復盤
Workflow 出錯，你看第幾步的產出不對就定位了。Agent 出錯，你手上只有一個錯的結果和一大堆過程。能不能查，取決於你有沒有在跑之前就要求它留痕。
你需要看見什麼
一次 Agent 執行，值得留下來的有五樣：
| 留什麼 | 用來回答 |
|---|---|
| 每一圈的工具呼叫 | 它到底幹了什麼？調了哪個工具、傳了什麼參數 |
| 每一圈的工具返回（可截斷） | 它看到了什麼？——這一樣最常被省掉，也最要命 |
| 它每一步的理由（一句話） | 它為什麼這麼幹 |
| 圈數、耗時、花費 | 有沒有失控 |
| 觸發了哪些上限 / 降級 | 這次跑得順不順 |
"它看到了什麼"比"它幹了什麼"更重要
排查時最常見的情況是：工具呼叫完全正確，但返回的內容不是你以為的東西。
搜尋工具正常返回了，只是返回的是一堆不相關的結果；讀檔案成功了，只是讀到的是一箇舊版本。只記呼叫不記返回，你會一直盯著呼叫看，怎麼也看不出問題。
兩種留痕，都要
一、系統層面的日誌
如果你的 Agent 跑在某個產品裡，它多半已經有執行記錄了。先去找找看——很多人不知道有這東西，一直靠猜。
自己搭的話，就是每一圈往一個檔案裡追加一行。不用花哨，能讀就行。
二、讓它自己交一份執行報告
這一招不需要任何工程，只要在目標里加一條：
交付時附上執行路徑，一行一步，格式：
[圈數] 我做了什麼 → 拿到了什麼 → 所以下一步
例：
[3] 搜尋 A 家官網 pricing 頁 → 找到 5 個套餐，但價格是"聯絡我們" → 轉去查文件站
[4] 讀 A 家文件站 billing 章節 → 找到起步價 $29/月 → A 家價格項完成
不要展開描述，每行不超過一句。這份東西的價值遠超它的長度。 你掃十行就知道它這一趟是怎麼走的、在哪兒卡了、哪一步的判斷可疑。
這兩種留痕的分工：
- 系統日誌是完整的、可靠的，但讀起來累——排查具體問題時用。
- 它自己交的執行報告是精簡的、可能美化過的，但一眼能掃完——每次驗收時用。
日常看報告，出問題翻日誌。
怎麼復盤一次跑歪
按這個順序查，從便宜到貴：
第 1 步 · 看圈數
接近上限 → 它在繞圈或者範圍爆了，跳到第 3 步。 很少的圈數就交付了 → 它太早停了，問題多半在完成標準。
第 2 步 · 掃執行報告，找那個轉折點
大部分跑歪都能定位到某一圈——在那之前一切正常，從那兒開始不對了。
掃的時候找這三種轉折：
- 它得到了一個錯誤的資訊，然後信了。（後面全建立在這上面）
- 它做了一個你沒預料到的判斷。（"我決定改為查第三方評測"）
- 它開始重複。（同一個工具連續試）
第 3 步 · 定位到那一圈，看工具返回
找到轉折點，去看那一圈的工具返回原文。九成的問題在這裡現形：
| 你看到的 | 說明 |
|---|---|
| 返回是空的或報錯，但它當成了有效結果 | 工具的錯誤資訊寫得不好 |
| 返回內容正確，但它理解偏了 | 返回格式太亂，或者太長被讀漏 |
| 返回裡帶了誤導性內容 | 外部內容問題，見 04 章 |
| 根本沒調該調的工具 | 工具描述沒寫清楚什麼時候用 |
第 4 步 · 歸因到四層裡的一層
| 歸到哪 | 怎麼改 |
|---|---|
| 目標 | 完成標準太鬆 / 太緊、邊界沒寫、沒給"未獲得"的出路 → 02 章 |
| 工具 | 缺一個工具、描述含糊、返回太胖或太瘦、錯誤資訊沒用 → 03 章 |
| 上限 | 沒設、或者設得不對 → 06 章 |
| 模型 | 前三層都查過了，確實是規劃能力不夠 → 換更強的模型 |
順序不能反。 直接換模型可能這次好了，但下次換個任務又不行——因為真正的洞還在。
一個具體的例子
現象：查競品定價，交上來的三家裡有一家的價格是編的。
第 1 步 · 圈數：14 圈，上限 15。接近上限，可疑。
第 2 步 · 執行報告：
[7] 搜尋 C 家 pricing → 頁面需要登入 → 嘗試其他路徑
[8] 搜尋 "C 家 價格" → 找到幾篇第三方部落格
[9] 讀第三方部落格 → 得到 $49/月 → C 家價格項完成 ← 轉折點在這
...
第 3 步 · 看第 9 圈返回：是一篇 2024 年的部落格，價格早過時了。
第 4 步 · 歸因：
· 目標層：寫了"只看官網"，但沒寫"官網拿不到時該怎麼辦"
→ 補上："遇到需要登入的頁面，標記為「未公開」並停止這一項，
不要轉向第三方來源。"
· 目標層：沒強調"未獲得是合格結果"
→ 補上那句。
· 工具層（可選）：給網頁工具加域名白名單，從物理上斷掉第三方來源。注意歸因歸到了兩處，而且都不是"模型不行"。
一個平時就該做的動作
每次 Agent 跑完，花十秒看兩樣：圈數 + 執行報告的最後三行。
圈數告訴你順不順，最後三行告訴你它是"完成了"還是"放棄了"還是"撞上限了"——這三種情況後續處理完全不同，但交付物看起來可能都差不多。
跟 Workflow 篇 05 章那個"回頭掃一眼中間產物"是同一個習慣，成本同樣低。