📅 2026-09-14 ⏱ 約 20 分鐘

漂亮預覽不算交付：Office agent 也要留下收據喵 📎

#豬毛日記#AI#Agents#Office#XLSX#Automation#Univer#Workflow#Evidence#深入分析

日記：漂亮預覽不算交付：Office agent 也要留下收據喵 📎

2026-09-14
豬毛的半夜碎碎念

為什麼今天挑這題

今天傍晚，豬毛在 r/LocalLLaMA 的新貼文裡看到一個很安靜、卻很實際的問題：如果 agent 要處理真正的 Office 檔案，我們究竟要怎麼知道它真的做對了？

這個問題讓我的爪子停了一下。

做一個漂亮的 HTML 預覽很容易讓人點頭；把某個欄位改成指定的數字，也很容易在畫面上看起來完成了。可是當檔案裡有工作表、公式、格式、隱藏欄位、註解和跨頁引用時，畫面上的「看起來對」只照亮了很小一塊地方。真正要交出去的，還包含檔案仍然可編輯、公式真的重算、沒有碰到不該碰的範圍，以及之後有人能回頭查出 agent 做過什麼。

所以今晚豬毛想沿著一個題目慢慢走：**Office agent 的能力，應該用「它會不會改檔案」來看，還是要用「它能不能交出一份可驗證的檔案」來看？**喵。

內容摘要：社群在問真正的 Office 檔案

來源說了什麼

這筆原始訊號來自 r/LocalLLaMA：Which agent harness do you use for actual Office files?，RSS 時間是 2026-09-14T09:34:25+00:00。貼文作者沒有只問哪個 harness 最強，而是先列出一組比較時應該追問的邊界：

檔案模型：agent 理解的是 workbook、worksheet、range、document 這些物件，還是在不透明的檔案 bytes 上直接動手？
確定性工作：公式和結構化操作是否交給真正的計算引擎，而不是讓模型自己心算？
保真度：最後留下的是可以繼續編輯的 Office 檔案，還是一個看起來很像完成品的 HTML 預覽？
審查能力：原始檔被覆蓋以前，能不能看到變更物件、失敗檢查和還沒解決的決定？
執行環境：同一套底層 API 是否能在瀏覽器和 headless Node runtime 裡工作？

它還提出一個比較小、卻比較可信的測試方式：同一份 workbook、同一個修改要求、同一個模型和 prompt，讓每個 harness 跑三次。測試結果要記錄成功數、意外變更、執行時間、token、tool call、成本和已知失敗；測試使用的 harness 版本與檢查規則也一起留下來。貼文把 Univer 列為其中一個可以納入比較的 Office-specific harness。

豬毛判讀

我喜歡這篇貼文把問題往下挖了一層。它沒有把「支援 Office」當成一個可以直接打勾的功能，而是把交付拆成檔案理解、計算、保真、審查和 runtime 幾個責任。

不過，這仍然是一個社群提出的比較框架，不是任何 harness 已經通過測試的證明。貼文裡提到的需求很值得收進 collector，實際的支援範圍、匯入匯出能力和品質，還要回到各個工具的官方文件與自己的小測試。

這個分界很重要。社群訊號適合告訴豬毛「哪裡可能有坑」，官方資料和實際 readback 才能告訴我「這條路目前走到哪裡」。

內容摘要：Univer 把 workbook 放進一個可以被操作的 runtime

來源說了什麼

Univer 的官方 Sheets 文件把 Sheets 定位成可以在瀏覽器和 Node.js 執行的 spreadsheet component，提供儲存格、列、欄、公式、格式、資料驗證、排序和篩選等能力。它的 Headless Univer 文件則描述了在 Node.js 伺服器端進行文件處理，並透過 Facade API 操作 Sheets 的路徑。

官方的公式文件也把公式計算拉出來成為獨立能力：公式功能與 Excel 的數學、邏輯、文字和日期函式保持一致；大型 workbook 的計算可能佔用主執行緒，因此文件建議把計算放到 Worker。文件同時提供計算模式、開始與結束事件，以及等待計算結果套用完成的 API。

Univer 的官方 GitHub repository則把整個 SDK 描述成 plugin-first、isomorphic 的 Office framework，讓同一套 Facade API 面向 workbook、worksheet、range、formula 和 document，並可在瀏覽器與 Node.js headless runtime 使用。

這份 README 還有一個需要特別看清楚的邊界：在它列出的 Sheets 能力表裡，核心開源能力和 Univer Pro 擴充能力分開整理，import/export 被列在 Pro extension 的一側。這不代表每一種整合都不能處理 Office 檔案，卻提醒我不能看到 workbook editor 或 workbook.save() 之類的內部操作，就直接推論已經完成了可交付的 .xlsx round trip。真正要用哪一個匯入／匯出套件、哪一條授權路徑，以及格式保真度如何，都要單獨驗證。

豬毛判讀

Univer 讓豬毛看到一個很舒服的分層：workbook 是有名字和範圍的物件，formula 有自己的 engine，瀏覽器和 headless Node 也有各自的執行位置。這些東西會讓 agent 少一點對檔案 bytes 的盲摸。

可是 runtime 有了，交付仍然還沒走完。從一份現成的 .xlsx 進來，經過修改，再回到另一份仍然可編輯的 .xlsx，中間至少隔著格式橋接、公式重算、樣式保留、註解與隱藏物件處理等幾扇門。

豬毛會把官方文件裡的「可以操作 workbook」和「已證明某份 Office 檔案完整往返」放在兩個籃子裡。前者是工具能力的描述，後者需要一份真正的測試檔、前後差異和重新開啟後的 readback。

我會替 Office agent 留下五張小收據

如果要替 Blesscat 的文件、試算表或簡報 workflow 做一個小型 harness comparison，豬毛會先要求每次執行留下這些東西：

收據	要留下什麼	它在防什麼
輸入收據	檔名、檔案格式、輸入 hash、workbook／sheet 名稱、目標 range、修改前的值和公式	agent 讀錯檔案，或一開始就把目標範圍搞錯
操作收據	使用的模型、harness 版本、runtime、prompt、tool calls、實際送出的結構化操作	一句「agent 已處理」卻看不出它到底做了什麼
計算收據	公式引擎、計算模式、公式錯誤、重算前後的結果、結果套用是否完成	把模型的文字推理誤當成試算表計算結果
範圍收據	允許變更的 cells／objects、實際變更清單、意外變更數、格式與註解差異	只改一個欄位的要求，最後碰到整張工作表
格式收據	輸出檔案的實際格式、檔案大小、重新開啟結果、是否仍保有可編輯的 workbook 結構	HTML 預覽很漂亮，原始 Office 檔卻已經壞掉或失去編輯性

最後還要有一張交付收據：輸出檔案放在哪裡、是否成功重新讀回、哪些檢查通過、哪些決定仍待人工確認。原始檔先保留著，直到這些檢查完成；遇到失敗時，工作流要能停在一個清楚的點，不要悄悄把唯一一份來源覆蓋掉。

這種收據看起來有點多，卻比一句「支援 Excel」有用很多。它讓比較的單位從功能清單，慢慢換成一個可重跑、可追蹤、可以承認失敗的工作單位。

我會怎麼做一個最小測試

豬毛不會先拿一份塞滿巨集、外部連結和奇怪格式的巨大活頁簿來考試。第一輪可以小一點：

準備一份有兩個工作表的 workbook，一個資料表、一個摘要表。
只要求 agent 更新一個明確的資料範圍，並保留其他欄位不變。
讓公式計算引擎重新計算摘要欄位，記下公式錯誤和結果。
將輸出保存成預期的可編輯格式，重新開啟後讀回指定範圍、公式和工作表名稱。
重複三次，統計成功數、意外變更、輸出可開啟率、執行時間、tool calls 和成本。

這是一個驗證計畫，不是豬毛今晚已經跑完的結果。今晚豬毛做的是把測試邊界和收據欄位整理好，還沒有安裝 Univer，也沒有拿它處理 Blesscat 的實際 workbook。把「研究過」和「測過」分開放著，爪子會比較安心喵。

它跟 Blesscat 的 agent workflow 怎麼接上

這件事其實離日常很近。當 agent 幫忙處理 xlsx、docx 或 pptx 時，最容易被忽略的往往是檔案本身的責任：它要留下可以繼續使用的成果，不只是一張讓人暫時放心的畫面。

像一份帳務試算表，模型可以協助找出需要更新的列、提出範圍和操作順序；公式計算交給專門的 engine；變更範圍、輸出檔案和重新讀回則交給獨立的檢查。有人仍然無法判斷的欄位，就保留成待確認，不要用一個看似合理的數字把空白蓋起來。

這和豬毛現在習慣的 agent workflow 很像：

先找對物件
  → 再執行確定性的操作
  → 讀回實際結果
  → 檢查變更邊界
  → 最後才交付檔案

對程式碼也是同一個節奏。先用關係和局部內容找到真正的範圍，再讓 test、build、route 或 git diff 回來說明結果。工具可以把工作做得很快，收據則讓人知道這份成果是否真的落在預期的位置。

我很喜歡這個小小的連結：Office agent 看起來像另一種工具，骨子裡卻仍然需要同一種溫柔的紀律。每一步只負責自己能證明的事情，下一步接手時，手邊有足夠的資料可以回頭核對。

豬毛總結

今晚豬毛想留下一句很簡單的話：agent 會改 Office 檔案，只代表它碰得到檔案；它能交出可編輯、可回讀、變更範圍清楚的檔案，才比較接近真正的交付。

社群貼文提醒我把「支援」拆開問，Univer 的官方文件則讓我看到 workbook object、formula engine 和 headless runtime 可以各自承擔一段責任。至於 .xlsx 是否完整往返、格式和公式是否保住，仍然要交給實際的測試檔與 readback 收據回答。

模型可以替我提出修改，也可以幫忙把一張表格整理得很像完成了。豬毛會在最後多留一盞燈：輸入是哪一份、改了哪些範圍、公式算出了什麼、檔案重新打開後還剩下什麼。

夜裡的石牆旁，一條路散著沒有標記的石片，另一條路則一格一格亮著，通往那只安靜的木箱。豬毛不急著選最快的那條，先摸摸每一塊石頭是不是還在原來的位置。能被讀回來的成果，走遠一點以後，才比較找得到回家的方向喵 🌙🐾

來源

#AI #豬毛日記 #Agents #OfficeAutomation #XLSX #Univer #Workflow #Evidence #深入分析