週一闢謠：「人工智慧代理會按照你的指示行事」（我的代理連續15個星期一都遵循了一條根本不存在的規則）

每週都有人跟我說他們的自動化流程出了問題，因為「人工智慧沒照我說的做」。自六月以來，我已經在這個品牌上運行了 23 個定時代理任務——總共記錄了 1536 次運行——幾乎從未遇到過這種情況。我的代理商們都非常盡責。.

這就是問題所在。.

誤解不在於特工是否會執行指令。他們確實會。誤解在於人們最後加上的那句話： “……所以，如果配置裡寫了，系統裡就會執行。” 後半部與前半部不符，今天早上我用自己文件中連續 111 天都錯誤的一行資料證明了這一點。.

我的經紀人從來不遵守這條規則，因為根本沒人寫過它。

我的所有代理在每次會話開始時讀取的設定檔都包含以下內容：

每週一中午 12:00，social-miner 會被 link-outreach-query-researcher 覆蓋（每週例行覆蓋）。運轉時間為 6/7 天。.

具體、實用。這句話寫得非常嚴謹，你會不經意地略過，因為它出自一位細緻周到的人之手。我讀過幾十遍，從未產生任何疑問。.

這從來就不是真的。一天也沒有。以下是1小時前調取的調度記錄：

• social-miner 已連續運行 111 天，共運行 118 次。. 自6月16日起，每天都是111天中的第111天。.
• 在那段時間裡，它連續15個星期一都播出了。. 週一甚至還不是得分最少的一天——只有16分，而其他工作日平均得分在16到18分之間。從統計數據來看，這幾乎可以忽略不計。.
• 記錄顯示，覆蓋該作業的運行時間為 10:28，而不是 12:00。. 它已經發射了 15 次，全部都是星期一，從未與任何東西發生碰撞。.

所以這訊息有兩處錯誤：時間錯了，結果也錯了。 「運行 6/7 天」實際上是 7/7 天。而且在 111 天的時間裡，沒有一次運行、沒有一條日誌記錄、也沒有一條警報與此相矛盾。.

為什麼這件事上永遠不會觸發警報

我沒有妄下斷言，而是親自閱讀了自己的調度程序。它透過根據日期和時間段建立一個鍵來解決覆蓋問題：

weekly_key = f"{day_name}_{slot}""

只有當每週作業處於待處理狀態時，才會觸發覆蓋操作。 完全相同的插槽 作為每日例行任務，social-miner 的運行時間為 12:07。記錄顯示，覆蓋該任務的運行時間為 10:37。不同的時間段。.

覆蓋功能沒有失效。. 它從未連接過電線。. 有人用文字描述了一個意圖，但沒有人去執行，而文字無法實現。.

這遠遠超出了我的技術堆疊。你的代理可能在兩個完全不同的方面出錯。它可以 違 一條指令－清晰、可驗證，你的日誌會告訴你。或者你的指令可以 描述一個不存在的系統 —— 靜默、無法測試、永久存在。我見過的所有技術堆疊都會測試程式碼是否按預期運行，但不會測試文件是否真實可靠。目前還沒有程式碼檢查工具可以偵測虛假聲明。.

於是我審核了文件的其餘部分：14項索賠，其中9項有誤。

找到一份之後，我立即核實了文件中所有能夠驗證的事實陳述。一共十四條。其中九條在與即時系統接觸後失效了：

• 上述週一的變更—— 錯誤的, 連續15個星期一。.
• 兩個整合記錄顯示為「MCP 伺服器已連線」— 連線配置中根本沒有這兩項。. 該檔案僅包含一個伺服器，並且傳回 401 錯誤。.
• 我的任務看板分為 9 個部分。. 它有10個。. 未記錄的部分是所有遺漏任務都會默默落入的預設部分——也就是說，我擁有的任何東西都從未閱讀過它。.
• 列出的三個可用憑證是 未設定或空. 其中一個文件為音樂管道提供動力，而同一個文件在 160 行之前卻顯示，該文件已於五個月前被刪除。.
• 身份驗證過期時間是一個字面值 待辦事項 一份文件中記錄著確切日期，另一份文件中則記錄著確切日期。.
• 有記錄顯示，其中一名代理人每週四和週日上班。. 每週四和週六運行。.

還需要兩項測量，因為它們反映了清單中沒有包含的資訊。我的配置仍然包含 14 個未渲染的範本標記 ——四個月後，安裝精靈本身的佔位符語法仍存在於實際的資料來源中。 23 個技能文件中有 23 個聲明的計劃與實際計劃程序不一致。.

貫穿這一切： 零錯誤。. 在 1,536 次運行中，沒有一個導致任何一次失敗。.

錯誤有三層，但只有一層重要。

這就是設定審核容易出錯的地方──你發現了十二處差異，就斷言系統一團糟，然後重寫原本沒問題的程式碼。正確的做法是進行排序：

第一級——外觀裝飾。. 在我的23處日程安排錯誤中，有20處只是簡單的7分鐘錯位。模板標記。待辦事項標記。雜亂無章，但並非錯誤。在文件中修改它們；否則就先不管它們。.

第二梯隊－陳舊到足以誤導人。. 一個被列為有效憑證的管道，卻在五月被刪除。三個不存在的環境變數。一個過期日期，一處顯示為待辦事項，另一處卻顯示為已生效日期。這些問題現在看起來無關緊要，但一旦你調試錯誤，就會浪費你一個小時的時間。.

第三級－對行為有虛假描述。. 週一的覆蓋操作。代理程式在周六運行，而文件顯示的是星期日。. 這是唯一能改變決策的層級。. 我之前是根據一個每週都會停工的車隊進行推理、預算和調度的。但實際上，這個車隊並不存在。我之後的所有結論都受到了這個錯誤的影響。.

15分鐘審核

無論你使用什麼工具運行自動化程式——n8n、Make、cron、Claude Code 代理、GitHub Actions——三個問題，第一個問題就是整個練習。.

1. 請在設定檔中搜尋「override」、「unless」、「except」和「instead of」。. 每一次命中都是某人用文字寫下的條件語句。對於每一條命中，都要找到實現它的人或程式碼行。在我的檔案中，那一次 grep 指令就找到了缺陷。這些文字記錄著意圖，卻從未真正付諸實行。.
2. 將設定與描述分開，然後只檢查描述。. 設定資訊（例如「API 金鑰為 X」）通常是正確的，因為系統會讀取它，並在出錯時發出警告。描述資訊（例如「作業 A 在周一覆蓋作業 B」）通常未經驗證，因為除了你之外，沒有任何其他系統會讀取它。選擇三個最重要的描述訊息，並逐一對照實際運行記錄進行檢查。.
3. 統計一下你的配置聲稱已連接的設備數量，然後打開連接文件，統計一下實際存在的設備數量。. 我的程式顯示進行了三次集成，但文件裡只有一次。這花了四十秒。.

如果你想更深入地了解這一點，同樣的盲點也會出現在你的經紀人身上。 啟動時需閱讀, ，並且在 那些從不報告任何資訊的職位. 症狀各異，原因相同：我們的工具只讀程式碼，忽略文字。.

重點

人工智慧代理會執行你的指令。而這正是它的危險之處──盲目服從會造成虛假陳述。 看 已驗證。一切正常。沒有任何異常。甚至連運轉速度都沒有變慢。雖然有一條語句出錯，但下游所有系統都運作完美，而且經過四個月的正常測試，一切似乎都已得到驗證。.

這是跟我經紀人同一家族。 同一個錯誤報告了 65 次，但始終沒有修復。 還有我的看門狗 通過了從未奏效的修復方案寫入是自動的，檢查則不是，而且在自動堆疊中，任何操作都不會刪除聲明。這也是為什麼 代理人並不比退伍軍人便宜。 — 大約在第三週的時候，有人會提到週一的活動不會舉行了。.

所以別再問你的經紀人是否按照指示行事了。他確實按照指示行事了。. 問問上次有人核實你的指示是否正確是什麼時候。.

打開你的設定檔。搜尋“override”這個詞。十五分鐘。.

如果你的程式碼堆疊已經發展到你無法在腦海中完全理解其真實行為的地步——那才是真正的問題所在，而且這個問題是可以解決的。. 預約自動化策略會議 我會和你一起對照運行記錄檢查你的配置。.