AI 找不到資料時可以怎麼回答

以前 AI 助理讀自訂表格讀不到資料時，會直接說「這筆資料不存在」。這句話常常是錯的：一列資料看不到，可能是被 row policy 濾掉、可能是欄位被隱藏、可能是 SCP channel 範圍不含它、可能是這張表沒有被納入這個聊天室的洞察系統，也可能是有人的寫入還在等核准、還沒落地。

「我看不到」和「它不存在」是兩件不同的事，而使用者以前收到的是自信的那一句。所以現在只要讀到零列，就會附帶一個判定，而 AI 只有在判定允許時才可以否認它存在。

absence 物件

當讀取在第一頁沒有回傳任何資料列（沒有送 cursor，且 page 為 1），AI 的資料列查詢工具會附上一個 absence 物件，帶三種判定之一：

absence 物件是說「這筆資料不存在」的唯一依據。沒有它，誠實的回答是：在我能看到的範圍裡找不到。接在 cursor 之後的空頁，只表示已經讀完，所以不帶 absence，計數呼叫也不帶。

held 判定，以及使用者接下來該做什麼

held 只在「已提出但不在表裡」的暫存變更狀態上成立：pending、applying、apply_failed、discarded。applied 刻意排除，因為那一列已經落地，讀得到。

每種狀態的下一步不同，AI 被要求要說清楚是哪一種：

• pending / applying：還在等核准。沒有東西壞掉，就是需要有人去審。
• apply_failed：核准已經過了，但接著被這張表的某條規則拒絕。判定會附上 reason，引用被拒絕的那筆寫入；正確的做法是修正 reason 指出的資料再重送。重新核准沒有用，因為核准早就完成了。若是 unique_tuple 的拒絕，reason 只會寫出約束與它的欄位，不會有衝突的資料列或它的值；請修正真正填錯的資料，而且絕不要只為了繞過規則就更改業務 key。
• discarded：那筆請求已被取消或駁回，沒有什麼在等。

每一筆 held 項目都帶有 status、change_type、matched_on、requested_at、resolved_at 與 reason。matched_on 是比對到的 payload 值，截斷到 80 字元；requested_at 與 resolved_at 是以 Asia/Taipei 表示的 ISO 8601 時間（resolved_at 是該變更最後一次更新的時間，所以在 pending 或 applying 的項目上，它不是處理完成的時間）；reason 是為該變更記錄的錯誤文字，截斷到 300 字元，沒有記錄時為 null。一次判定最多回報 3 筆。

探測不會洩漏資料

暫留探測回答的是「是不是有人未落地的寫入造成這次找不到」，這代表它要讀暫存變更，因此有兩層閘門。

「有哪些暫存列存在」交給與核准清單相同的查詢：管理者看得到這張表的紀錄，其他人只看得到自己提出的請求，加上目標資料列本來就通過他 row 層 ACL 的紀錄。外部 client 只看得到自己提出的請求。在房間 session 中讀取部門資料表時，房間 grant 是連管理者也受約束的硬上限，所以呼叫者在那裡不會被當成管理者，探測只會讀到他自己提出的請求。

「哪些內容可以讀」是第二層、也更窄的閘門。探測從 payload 推導出來的欄位——matched_on，以及引用被拒絕寫入的 reason——會交出標準通道刻意不給非管理者的內容，所以「可以列出但不能讀」的紀錄會被跳過，而跳過就會把這次掃描標記為不完整。

只有真的跑完的探測才能斷言「不存在」

任何沒有真的掃描的離開路徑都會把掃描標記為不完整，而不完整的掃描永遠不會得出 not_found：它會判成 not_visible，除非已經找到 held 的寫入，那時會回傳該 held 判定。這涵蓋：查詢裡沒有可用的比對字串、缺少主體、未落地的暫存紀錄超過 200 筆（只讀取最新的 200 筆）、payload 太大走不完（超過 5,000 個節點）、暫存的 command plan（它的 payload 指向其他資料表，所以絕不會被走訪）、caller 不能讀的 payload，以及探測本身失敗。

這個偏誤是刻意的：少報一個暫留是比較小的錯，而暫留永遠不會被憑空製造出來。

哪些參數會餵給探測

探測要比對的字串來自一組固定的參數。在 custom_tables_find_records 是 search_text，當成子字串比對值收集。在 custom_tables_query_records 是 filters 與 any_of——而且只有這兩個。比較新的那幾個讀取參數一個都不會貢獻：全域 q 文字搜尋與 computed_filters 述語對探測是不存在的。在那兩個參數之內，也只有「在找某個東西」的運算子算數：eq 與 in 貢獻的是整個值；contains、starts_with、ends_with 與 like 貢獻的是至少 3 個字元的子字串（like 的萬用字元會被拿掉）；neq、not_in、not_contains 這類否定運算子永遠不算。find_records 的 search_text 同樣有 3 個字元的下限（長度在修剪後才計算），所以一到兩個字元的搜尋，絕不能認領任何一筆待處理的寫入。這樣的搜尋也沒有可用的比對字串，所以針對它的 find_records 零列回答，判定一律是 not_visible：絕不會是 not_found，也絕不會是 held。

所以，只用 q 收窄、或只用 interval 述語（overlaps、contains_point、is_empty 或 is_not_empty，它們都不指名 held 寫入可能帶有的字串）收窄的 query_records 呼叫沒有可用的比對字串，掃描會被標記為不完整，判定被強制成 not_visible。它永遠不可能回 not_found，也永遠不會浮出一筆帶著那段文字的 held 寫入——即使那筆寫入真的存在。如果這次讀取的目的是判定一筆資料存不存在，就把那個字串放進 filters 的 eq 或 contains 條件，或改用 find_records，讓探測真的跑起來。q 是用來找到資料列的，不是用來證明資料列不存在的。

為什麼一筆資料會「看起來不存在」

AI 自己的說明現在把這些列為原因，你在處理使用者「系統把我的資料弄丟了」的回報時也值得知道：

• 所在聊天室從未被授權這張表，或該房的授權列收窄了這個房間能看到的範圍——自 2026 年 7 月下旬起，agent session 解析部門表時，以所在聊天室的授權作為硬性天花板，並把房間授權那一步釘選在該房間：該房間沒有授權列就沒有存取權，管理者也一樣；有授權列時，結果是該列與使用者自己的階梯結果逐軸取交集——所以你在 REST 上讀得到的資料列，在這個房間裡可能是隱形的；見 effective permissions
• row policy 把那一列濾掉，包含每次請求才解析的 $me、$today、$now
• 使用者用來過濾的欄位被 column ACL 隱藏
• SCP channel 範圍 在這個聊天室不含那一列
• 這張表沒有被納入這個聊天室的洞察系統、是 company scope 的表（沒有任何 job 會載入它們），或是該房間 chatroom scope 的表中超出最新 1,000 張的其中一張
• 寫入確實存在，但還沒落地：等核准中、正在套用、被規則拒絕，或已被丟棄

只有最後一項是暫留。列層級的原因——被收窄的房間 grant、row policy、SCP channel scope——會回 not_visible，那正是它的用途。隱藏欄位也一樣：只要資料表有任何一個欄位對呼叫者隱藏（由 column ACL 或房間 grant 的欄位允許清單決定），即使搜尋從未碰到那個欄位，它也算是被收窄的視圖。其他原因根本到不了 absence 物件：房間從未被授權的資料表、或不在它 insight systems 內的資料表，根本不在房間的資料表清單裡，所以工具回的是列出可用資料表的「無法解析資料表」錯誤；以隱藏欄位做篩選則被當成未知欄位拒絕。

AI 實際上能對一張表提出哪些問題——運算子、上限，以及沿路會撞到的拒絕——見 Agent 工具箱。

小型查找、分析與異動確認（v5.10.0）

custom_tables_find_records 的 matches 現在包含 {id, label, data}，另有 has_more 與 next_cursor。data 使用可見的顯示欄名，補齊人員／附件顯示資料並移除隱藏欄位，因此小型文字查找可直接回答，不必再呼叫 analyst。條件查詢、計數、彙總、比較與跨表問題仍交給 analyst。

Analyst 對清單或單一值查找使用一次伺服器端篩選／排序查詢；彙總與衍生指標仍需驗證。對使用者的回答採業務名稱與人員顯示名稱，並說明列權限造成的可見範圍限制；只有明確要求時才顯示 ID。Schema 提示也會依欄位型別說明輸入格式、限制與唯讀計算欄位，並以有長度上限、經過消毒的 about: 文字帶上每個欄位自己的說明（見有界的探索）。

異動確認採人員與資料的業務名稱，只詢問一次。客戶的回覆由一套確定性的封閉世界文法對照那份 proposal 來判讀：單純的同意，或同意並回應該 proposal 自己的動作或宣告的目標，會確認它；帶有同意用語、或對 proposal 自己動作或內容的回應，而文法無法完整讀完的回覆會擱置它，助理會再問一次；拒絕、兩者都沒有的回覆，或另提別的要求則會撤銷它（見伺服器如何解讀一則確認）。遭拒或參數錯誤不等於寫入成功；把遭拒的值改放其他欄位，需要使用者另行提出要求。批次工具只宣告目前 grant 允許的 action kinds。封閉世界的判讀方式是在 v5.10.0 之後、於 v5.10.12 才出現的；v5.10.0 比對的是一份有限的確認用語清單。