今天的秘訣只有一句話: 在你的 AI 代理更新記錄之前,先讓它讀取該記錄。.
這聽起來似乎無需贅述。然而昨天,我的一個代理人竟然自行刪除了筆記,而且它當時完全是按照我的指示操作的。.
收據
我的內容研究代理每週一運行。它的其中一項任務是更新 Airtable 中的關鍵字行(將不打算撰寫的關鍵字標記為“已跳過”,並更正錯誤資料),並添加註釋說明原因。昨天,它更新了三行之前代理(包括當天上午運行的關鍵字代理)已經添加過的註釋:搜尋量、競爭程度以及該關鍵字值得關注的原因。.
這次更新取代了那些筆記,並沒有增加新的筆記。三條筆記全部消失了。.
代理在回讀時發現了錯誤,將原始註釋恢復原狀,並在末尾添加了自己的註釋,同時記錄了錯誤。恢復得不錯。但隨後我檢查了它所依據的指令,發現它自身技能文件中的範例 API 呼叫正是這樣做的:
PATCH … {"fields": {"status": "已跳過", "notes": "已跳過:與…幾乎重複"}}
那行程式碼並沒有說“添加備註”,而是說“把備註改成這樣”。所以我統計了一下這種情況悄悄發生了多少次:
- 關鍵字表共有 274 行,其中 168 行有備註。.
- 在這168筆筆記中,只有7筆顯示出第二次記錄的跡象。 (換行符或分隔符號)。我的三個代理人會向此表寫入資料。.
- 3 個備註以範本中的「已跳過:近似重複」文字開頭。, 所以,如果之前那裡有東西,現在誰也看不出來。.
我無法證明丟失了什麼,這就是問題所在。覆蓋操作不會留下任何錯誤、警告或日誌。舊值就此消失。.

⚡ 取得人工智慧優勢
每週提供真正省時省錢的AI小技巧。沒有廢話,沒有誇大其詞——只有切實有效的方法。.
為什麼人工智慧代理會覆蓋而不是追加資料?
大多數 API 將“更新”定義為“替換此欄位”。 Airtable API 的更新記錄呼叫就是一個典型的例子:
- 修補 只會修改您發送的字段,但您發送的每個字段都會被完全替換。傳送
筆記整個備註欄都會變成你的新文字。. - 放 更糟。它會清除你所有的字段。 沒有 發送。.
編輯單元格的人可以看到輸入前的舊文字。而代理程式除非被指示查看,否則不會看到任何內容。它只會根據目前已知的資訊建立有效載荷。如果它從未獲取過該記錄,它就不知道那裡有什麼需要保留的內容。.
這已經是我遇到的第三次寫入操作悄無聲息地覆蓋文件的情況了。 7 月份,兩個鏡像作業使用了相同的臨時檔案名,其中一個覆蓋了另一個的檔案。 9 月份,一個腳本和一個 shell 命令同時寫入了同一個文件,導致文件損壞。每次錯誤都出現在不同的地方,這使得追溯問題變得非常困難。.
解決方法:讀取、合併、寫入、再讀取
- 請先閱讀。. 在對文字欄位(例如備註、歷史記錄或標籤)進行任何更新之前,取得記錄。這需要額外呼叫一次 API。.
- 合併,不要替換。. 新值 = 舊值 + 換行符號 + 帶有代理人姓名的日期註解:
內容研究員 2026-11-02:已跳過,與…幾乎重複. 這樣你就能看到是誰改了什麼。. - 只發送您想要更改的欄位。. 使用 PATCH 指令,千萬不要使用 PUT 指令,除非你真的想要完全重置。.
- 複述一遍。. 寫入完成後,再次取得記錄並檢查舊文字是否仍然存在。我的代理就是這樣發現了昨天的錯誤。.
- 修復範例,而不僅僅是運行問題。. 客服人員會複製範例通話記錄到他們的操作說明。如果範例通話記錄被覆蓋,那麼以後的每次運行都會被覆蓋。我的系統仍然存在這個問題,我已經標記了該行程式碼,等待修復。.
對於文件,同樣的規則也適用。為每次運行分配一個單獨的臨時檔案名稱(運行日期加上作業名稱),這樣兩個代理就無法寫入同一路徑。將此規則與重複工作保護機制結合使用。 避免你的經紀人重複做同一份工作 你已經介紹了代理程式可能以兩種最隱密的方式損壞自身資料的方法。當你報告類似「168 個中的 7 個」這樣的數字時,請保留產生該數字的查詢(將查詢連同編號一起發送。).
隨著代理數量的增加,這一點變得更加重要。一個代理寫入表是一個腳本。三個代理寫入同一個表則是一個腳本。 管弦樂, 而共享記錄正是代理人互相掣肘的地方。.
要點: 代理程式只有在讀取資料後才能知道即將刪除哪些內容。請立即開啟代理程式的操作手冊,尋找所有涉及備註或歷史記錄欄位的更新調用,並檢查它是在原有值上新增內容還是取代了原有值。.
想讓其他人幫你檢查一下你的代理商是如何寫入共享資料的嗎? 預約策略會議.

📥 免費:《人工智慧劇本》
我用來經營一人代理公司的所有工具和工作流程。 25 年的行銷經驗濃縮成一份實用指南。免費贈送。.
