StagedWorkspace 以內容雜湊同步代理的解析檢視與原生檔案，OfficeQA Pass@1 增加 8.3 至 12.1 點

程式代理通常可依賴 Git commit、diff 與測試結果確認目前狀態，但處理 PDF、試算表、簡報或混合文件時，搜尋索引、預覽畫面、原生檔案及送交評分的版本可能互不一致。8 月 18 日發表的 [StagedWorkspace](https://arxiv.org/abs/2608.18050)把這個問題定義為「工作區狀態契約」：代理看到的每個解析紀錄與差異，都必須指向原生內容的特定雜湊。

其工作區保留基準版本、暫存修改與提交版本。原生檔案一旦改變，系統會重新解析並更新可搜尋紀錄；代理可同時使用結構化文字進行檢索，也能檢查原始 PDF、活頁簿或投影片，避免解析器遺失版面、公式及圖表資訊。提交前的 diff 則讓代理檢查自己實際改動了甚麼，而不是只相信先前的文字摘要。

研究團隊在固定代理框架中，分別移除原生或解析檢視。雙檢視設定在所有受測模型上取得最高點估計：相較較受限的單一檢視，OfficeQA Pro Pass@1 增加 8.3 至 12.1 個百分點，APEX-Agents 平均 rubric 分數增加 4.7 至 9.2 點。完整 SW-Agent 配合 Gemini 3.1 Pro 在 OfficeQA 得 63.9%，配合 GPT-5.4 Nano 在 APEX 得 42.1；作者引用的同模型既有成績分別為 29.3% 與 25.5。另在 57 項檔案編輯任務中，顯示 diff 的設定也取得較高觀察分數。

這項結果提醒開發者，文件代理的「上下文」不只是 token，而包含具版本語義的外部狀態。[OfficeQA 官方工具庫](https://github.com/databricks/officeqa)本身提供原始 PDF、解析文件與評分程式，正好說明不同表示層的工程負擔。不過跨系統成績受模型、工具與執行框架影響，不能把完整系統與已發表基線的差距全歸因於版本控制；目前最可信的證據仍是同一框架內的消融。下一步應驗證協作代理、並行編輯、解析失敗及回滾時，內容雜湊契約能否持續成立。