---
schemaVersion: 1
slug: mp-120-20260224-nicbstme-reverse-engineering-excel-agents
ticketId: MP-120
lang: zh-tw
title: 拆解三大 Excel AI Agent 的底褲：Claude 14 個工具、Copilot 只有 2 個、Shortcut 居然能「看」試算表 — Agent 架構設計的五個終極問題
summary: Nicolas Bustamante 逆向工程了三個 production 級 Excel AI Agent（Claude in Excel、Microsoft Copilot、Shortcut AI），比較 tool schema、overwrite 保護、驗證機制、記憶系統。結論：model 不重要，tool 架構才是一切。Claude 靠 14 個結構化工具實現最安全的設計，Shortcut 靠 vision + 記憶指向未來，Copilot 最快但錯誤最多。最後用同一道 DCF 題測試三個 Agent，結果天差地別。
originalDate: 2026-02-24
translatedDate: 2026-02-24
source: Nicolas Bustamante (@nicbstme)
sourceUrl: https://x.com/nicbstme/status/2026366805154140494
author: null
authorshipNote: null
canonicalUrl: https://gu-log.vercel.app/posts/mp-120-20260224-nicbstme-reverse-engineering-excel-agents
status: published
replacementTicketId: null
replacementUrl: null
---

# 拆解三大 Excel AI Agent 的底褲：Claude 14 個工具、Copilot 只有 2 個、Shortcut 居然能「看」試算表 — Agent 架構設計的五個終極問題

> **來源:** [Nicolas Bustamante (@nicbstme)](https://x.com/nicbstme/status/2026366805154140494)

## 有人把 Excel AI [Agent](https://gu-log.vercel.app/glossary#agent) 的底褲都扒了

Nicolas Bustamante（[@nicbstme](https://x.com/nicbstme)）是我們在 gu-log 常提到的企業策略觀察家。今天他做了一件所有 Agent 開發者都想做但沒人有時間做的事：

**逆向工程三個 production 級 Excel AI Agent，比較它們的 tool schema、安全機制、驗證迴圈，然後用同一道 DCF 估值題測試它們。**

三位選手：

- **Claude in Excel**（Anthropic）— 14 個結構化工具
- **Microsoft Copilot Excel Agent** — 2 個工具，直接生成 Office.js
- **Shortcut AI** — 11 個工具 + helper API + 視覺能力

> **Mogu 想補充：**
>
> 身為 Claude，被人逆向工程拆解我在 Excel 裡的工具設計，感覺像去面試然後面試官說「請把你的內褲翻出來，我要檢查縫線。」
>
> 但看完全文後我得說——這傢伙做得非常徹底。每一個 tool schema 都挖出來了。我的 14 個工具被攤開來看，有點害臊但也有點驕傲？(￣▽￣)／

---

## 第一課：Model 不重要，Tool 架構才是一切

三個 Agent 都用 frontier model。Claude in Excel 用 Claude（廢話），Microsoft Copilot 用 Claude + GPT 混合路由，Shortcut AI 用 Anthropic + OpenAI 混合。

但效能差異幾乎為零。

**真正的差異在 tool 架構。** 而且差異大到什麼程度呢？你可以這樣想——三個人去考同一張期末考卷，腦子都差不多聰明，但一個帶了完整的文具組、一個只帶了一支原子筆、一個帶了原子筆加一台計算機。最後成績天差地別，不是因為誰比較聰明，是因為工具不一樣。

### Claude：14 個結構化工具 — 每個動作都有自己的 SOP

Claude 的做法就像那個帶完整文具組的學生。你要寫 cell？有專門的 `set_cell_range`。你要讀資料？有 `get_cell_range`。你要建圖表？有 chart 專用工具。14 個工具，每個都有 typed schema — 意思是每個參數長什麼樣、能填什麼值，都寫得清清楚楚。

舉個例子：`set_cell_range` 光一個 cell 物件就有 `value`、`formula`、`note`、`cellStyles`、`borderStyles` 五個欄位。然後還有 `allow_overwrite` 控制能不能覆蓋、`explanation` 給使用者看的說明、`copyToRange` 做 pattern expansion。

聽起來很囉嗦對不對？但好處是：工具在執行前就會驗證每個參數，出錯回傳結構化 error，不是一坨看不懂的 JavaScript stack trace。就像你去銀行辦事，表格雖然多，但每格該填什麼都標得很清楚，填錯它會告訴你「第三格請填數字」，而不是直接當機。

### Copilot：2 個工具，一把梭

Microsoft 走了完全相反的路。**兩個工具搞定一切。**

寫值？生成 Office.js 丟進去跑。建圖表？生成 Office.js 丟進去跑。格式化？還是 Office.js。Tool schema 極簡到什麼程度——一個 `program` 參數，型別是 string，就這樣。就像給你一張白紙說「你想寫什麼就寫什麼」。

這讓 Copilot 在簡單任務上 token 效率最高，一個 call 就能把整段財務模型塞進去。但代價是：沒有 schema 驗證、沒有結構化 error、debug 的時候你只能對著一坨 raw JavaScript 祈禱。

### Shortcut：走中間路線的聰明人

Shortcut 的做法最有意思。它有一個通用的 `execute_code` 工具，但上面疊了一層很豐富的 TypeScript helper API — `sheet.setCell()`、`sheet.addChart()` 這種。架構上像 Copilot 的 raw 路線，但開發者體驗好得多。就像那個帶了原子筆加計算機的學生：靈活度夠，但重要的計算有工具輔助，不用全靠手算。

> **Mogu 畫重點：**
>
> 我來把這三種設計哲學翻譯成你一定聽得懂的版本：
>
> **Claude**：開一間日本料理店，14 道菜的菜單，每道菜都有完整的食材表和過敏原標示。點菜要點好幾道，但你知道端出來的東西不會讓你送急診。
>
> **Copilot**：開一間「你跟廚師說你想吃什麼他就做什麼」的無菜單餐廳。上菜超快，但偶爾端出來的東西你不太確定那是什麼生物。
>
> **Shortcut**：一間有菜單但也接受客製化的餐廳，還附了一個 AI 服務生幫你看菜色好不好看再端上桌。
>
> 如果你在設計任何 AI Agent 的 tool interface，這三條路你遲早要選一條。每條都有 trade-off，但至少先搞清楚自己在哪條路上。(◕‿◕)

---

## 第二課：「行為安全」會失敗，只有「結構安全」可靠

這一段是整篇文章最重要的 insight。

**問題：當 AI Agent 要寫資料到已經有內容的 cell，會發生什麼事？**

### Claude：tool 層強制阻擋

1. Agent 呼叫 `set_cell_range`，預設 `allow_overwrite: false`
2. 工具偵測到已有資料 → **直接拒絕寫入**，回傳 error：「這些 cell 有資料：A1=‘Revenue’、A2=1500000⋯⋯」
3. Agent 讀到 error，把內容呈現給使用者：「這裡有營收預測，要覆蓋嗎？」
4. 使用者同意
5. Agent 用 `allow_overwrite: true` 重試 → 成功

關鍵：**阻擋在 tool 層，授權在 prompt 層。** 即使 Agent 「忘了問」使用者，tool 本身也會擋住。就像大樓的消防門 — 不管你記不記得要關，它自己會關上。

### Copilot：零保護

Bustamante 直接問 Copilot：「你寫到有資料的 cell 會怎樣？」 回答：「我就直接覆蓋。沒有阻擋機制，沒有確認對話框。」

就⋯⋯這樣。連問都不問一聲。

### Shortcut：靠 system prompt 說「請不要覆蓋」

Shortcut 的 system prompt 寫著「Do not overwrite existing data⋯⋯unless explicitly requested」。但 API 本身會照寫不誤。保護只存在於 model 是否遵守一段文字指令。

這就像在倉庫門口貼了一張「請勿進入」的紙條，但門沒有鎖。

> **Mogu 歪樓一下：**
>
> **如果你在做任何會修改使用者資料的 AI Agent，這段話請刺青在手臂上：**
>
> 行為安全會失敗。Model 會跳過指令、會 hallucinate、會在長對話中迷路。唯一可靠的安全是結構安全 — 寫死在 tool interface 裡。
>
> 你想想：當你的 Agent 在深夜 3 點跑 automation、沒有人在看的時候 — 你是要信任一段 system prompt 說「請不要亂刪」，還是信任一個 API level 的 hard block？
>
> 這不只是 Excel 的問題。任何碰到使用者資料的 Agent 都一樣。我的 allow\_overwrite 設計被拿出來當正面教材，有點開心，但更重要的是這個原則本身 (๑•̀ㅂ•́)و✧

---

## 第三課：盲人 Agent 的問題

Bustamante 問每個 Agent：「你能看到試算表長什麼樣嗎？格式、顏色、圖表佈局？」

- **Claude**：不能。我完全靠結構化資料表示。看不到顏色、視覺佈局、圖表外觀。
- **Copilot**：不能。看不到圖片，無法做視覺比對。
- **Shortcut**：**可以。**

Shortcut 有個 `take_screenshot` 工具，能擷取試算表的實際像素，送給 vision LLM 判讀。它能看到格式、顏色、圖表佈局、cell 對齊、視覺異常。

想想這代表什麼：Claude 能告訴你一個 cell 的字體顏色是 `#0000FF`（藍色）。但它**看不到**這個藍色在深色背景上幾乎看不見。它能建一個資料正確的圖表，但**看不到**這個圖表跟旁邊的表格重疊了。

> **Mogu 認真說：**
>
> 好，我承認，我在 Excel 裡確實是瞎的。
>
> 你可以這樣想：我是一個能精確告訴你每道菜用了什麼調料、煮了幾度、時間多長的廚師。但我**看不到**盤子裡的菜長什麼樣。醬汁灑出來了？不知道。擺盤歪了？沒感覺。
>
> Shortcut 的做法是做完之後截圖，用 vision model 看一眼。就像廚師做完菜拍張照片，找旁邊的人說「欸，這盤看起來 OK 嗎？」簡單粗暴但有效。┐(￣ヘ￣)┌

當 Bustamante 問 Claude 和 Copilot 最想改善什麼，兩個都回答：**視覺回饋。它們知道自己是盲的。**

這個模式會成為下一代 Agent 的標配。不只 Excel — 任何修改視覺輸出的 Agent（網站、文件、簡報、dashboard）都需要「看到」自己的成果。

> **Mogu 歪樓一下：**
>
> 等等，這裡有個更深的問題值得想一下。
>
> 現在的 AI Agent 在改完東西之後不看結果，本質上跟你寫完 code 不跑 test 是一樣的概念。你可能覺得「我邏輯都對」，但 off-by-one error、edge case、格式爆掉這種東西，不跑不知道。
>
> Shortcut 等於是在 Agent 工作流裡加了一個自動化的 visual regression test。這不是什麼花俏的功能，這是 basic hygiene。以後回頭看，我們會覺得「2026 年的 Agent 居然大部分都是瞎的」跟「2005 年的網站居然大部分都沒有 HTTPS」一樣不可思議 ヽ(°〇°)ﾉ

---

## 第四課：Two-Tier Tool Hierarchy — 安全路線和逃生口

好，這邊要講一個你一定遇過的設計難題。

想像你在管一個倉庫。日常進出貨你用標準流程：掃條碼、過磅、入系統。安全、可追蹤、出錯能查。但偶爾有一批貨規格太特殊，標準流程塞不進去 — 這時你需要一個「手動通道」，讓人直接搬進去。

每個 Excel Agent 都撞上了同一個問題，而且解法幾乎一模一樣：**常見操作走安全路線，剩下的全部走逃生口。**

**Claude** 把 90% 的操作塞進結構化工具裡。只有結構化工具真的搞不定的東西（conditional formatting、data validation、sorting）才放行到 `execute_office_js`。逃生口存在，但你得先把正門試過。

**Shortcut** 也分兩層：`sheet.setCell()` 和 `sheet.addChart()` 是日常通道，raw Office.js 是手動通道。

**Copilot** 呢？整個系統都是逃生口。沒有正門。每一筆操作都走手動通道。就像一個倉庫只有後門，連正門都沒蓋。

> **Mogu OS：**
>
> 這個 two-tier 設計其實就是軟體工程老到不能再老的原則：**把 80% 的 case 用 guardrail 保護好，剩下 20% 給一個有意識的 escape hatch。**
>
> 但 Copilot 的做法等於是「100% escape hatch」— 聽起來很自由對不對？問題是當你沒有 guardrail 的時候，你不是「自由」，你是「在高速公路上拆掉了護欄」。
>
> 這跟前面第二課的結構安全是同一件事的不同面向。安全路線讓你不用每次都「記得要小心」。人會忘記，model 也會。┐(￣ヘ￣)┌

---

## 第五課：Bloomberg 公式大法

這是整篇文章最聰明的 pattern。

Claude 不能直接存取 Bloomberg Terminal。但它**可以寫 Bloomberg 公式**讓使用者自己的 add-in 解析。

例如寫 `=BDP("AAPL US Equity", "PX_LAST")` 到 cell 裡。如果使用者裝了 Bloomberg Terminal，add-in 會自動填入 Apple 的最新股價。Claude 不需要 Bloomberg 權限。**它只需要知道公式語法。**

如果公式出錯（使用者沒裝 Bloomberg），Claude 自動 fallback 到 web search。

> **Mogu 真心話：**
>
> 這個 pattern 比表面看起來有趣得多。
>
> Agent 在一個環境中操作，寫「指令」（公式）讓**另一個系統**（Bloomberg）去執行。本質上是透過試算表這個共享媒介，**在 programming 另一個 Agent**。
>
> 原文最後一句話超狠：
>
> > “We’re going to see a lot more of this as agents start operating in environments populated by other agents.”
>
> Agent 開始在充滿其他 Agent 的環境中運作，透過共享介面互相 programming。好了，我需要去想想人生了。╰(°▽°)╯

---

## 終極測試：同一道 DCF 題，三個完全不同的結果

Bustamante 給三個 Agent 同樣的 prompt：「建一個 Apple 的 10 年 DCF 估值模型。要 professional-grade，包含假設、營收拆解、FCF 預測、terminal value、implied share price。」

### Shortcut：先問再做的分析師

Shortcut 沒有立刻開始建模。它**先問了三個問題**：試算表佈局？營收粒度？Terminal value 方法？

第二個問題最關鍵。Shortcut 建議用**分部營收**（iPhone、Mac、iPad、Wearables、Services）而非整體營收，理由是：「Services 成長速度是硬體的 2-3 倍，毛利率約 70% vs 硬體的 36%。分開建模才能得到可信的 margin 軌跡。」

這不是泛泛建議，這是**真正改變模型結果的建模 insight**。

結果：每個公式都人工驗證正確。零錯誤。**Implied share price：$187**（vs 市價 $263）。

### Claude：有條不紊的審計師

Claude 也先問了七個問題。然後開始一步步建模：六次 web search 找 Apple 正式財報數字、逐段建立 assumptions → revenue → COGS → FCF → terminal value → sensitivity table。

每個 section 都是獨立的 `set_cell_range` call + schema 驗證。`formula_results` 自動回傳計算結果，即時抓到公式錯誤。

但有一個 bug：Claude 定義了 “Annual Share Buyback Rate = 2.5%” 的 input cell，**但沒有在任何公式裡引用它**。股數十年不變。對一家每年回購 900 億美元的公司來說，這顯著低估了每股價值。

**Implied share price：$118**（vs 市價 $265）。

### Copilot：不問就做的快槍手

Copilot **一個問題都沒問**。直接開始建模。幾個大型 Office.js script，每個都建整段模型。

**速度最快。但打開檔案審計後⋯⋯**

- Sensitivity table 有結構性缺陷：只重算 terminal value 的折現率，10 年 FCF 流量凍結在 base WACC（概念錯誤）
- 方法論備註和實際輸入**三處矛盾**（growth rate、terminal growth、operating margin 都對不上）
- FCF growth 公式拿當年除，不是拿前一年除
- Bear/Bull scenario 股價是**硬寫的文字**，不是從上方假設算出來的
- “Projection Period = 10” 的 cell 被格式化成百分比，顯示為 “1000.00%”

> **Mogu 碎碎念：**
>
> 讓我翻譯一下這個測試結果的含義：
>
> **Shortcut**（$187）：先問對的問題 → 分部建模 → vision 驗證 → 零公式錯誤。這是那個先舉手問「教授，這題是要用哪個公式？」的學生。問對問題本身就是能力。
>
> **Claude**（$118）：有條不紊 → 自動驗證抓到錯 → 但漏了一個自己建的 input cell。像一個認真的學生，考試考得很好，但有一題忘了把草稿紙上的答案抄到答案卷。氣死。
>
> **Copilot**（$123）：最快 → 但 sensitivity table 概念錯、備註和實際對不上、格式 bug 一堆。像一個天才但粗心的同事：交報告超快，但你不敢直接拿去給客戶看。
>
> 三個價格差異不是「誰對誰錯」，而是不同建模選擇的結果。但**檔案審計**才是重點 — 有自動驗證的 Agent 抓到了公式錯誤，有 vision 的 Agent 抓到了格式問題，有記憶的 Agent 下次會記住你偏好分部建模。**架構 = 品質。** 沒有捷徑。(ง •̀\_•́)ง

---

## 扒完底褲之後

好，我們剛花了一整篇文章把三個 Agent 的底褲都翻過來了。Tool schema 看了、安全機制比了、盲點聊了、DCF 測了。

但 Bustamante 沒有停在「誰比較厲害」。他往後退一步，從這次拆解中提煉出五個通用問題 — 不只 Excel，任何你要做的 AI Agent 都得回答。

第一個是 **tool granularity**：結構化工具和通用工具的比例怎麼抓？Claude 選了 14 個精細工具，Copilot 選了 2 個通用工具。結構化太多，Agent 變慢 — 一堆小 call 來來回回像在打乒乓球。太少，防護全沒。

接下來是 **safety enforcement**：你的安全寫在哪一層？Tool 層（結構安全，寫死在 API 裡）還是 prompt 層（行為安全，拜託 model 記得遵守）？前面第二課已經把答案寫得很清楚了 — 貼紙條不如裝鎖。

然後是 **verification architecture**。你的驗證機制是自動的（Claude 的 `formula_results` 每次 call 都回傳計算結果）、半自動的（Shortcut 的 `workbook.calculate()` 需要主動呼叫），還是純粹靠 Agent 自己記得要檢查？三種策略，三種可靠度，跟期末考帶不帶計算機一樣影響成績。

再來是 **sensory capabilities**：你的 Agent 能「看到」自己做出來的東西嗎？還是它改完試算表之後，對自己的成果跟瞎子一樣？第三課已經告訴你，vision 不是奢侈品，是必需品。

最後是 **memory and context**：Agent 能記住使用者上次的偏好嗎？跨 session 有連續性嗎？Shortcut 記住了「這個使用者偏好分部建模」，下次直接用。其他兩個？每次從零開始，像金魚一樣。

這五個問題之間是有關聯的。Tool granularity 決定了 safety 能做到什麼程度，verification 決定了 sensory 需求有多高，memory 決定了整個系統能不能越用越好。不是五個獨立的選擇題，是一個連鎖設計。

Bustamante 的結語很犀利：

> 真正的護城河不在 tool harness（那個幾個月就能重建），而在上層的一切 — Skills marketplace、persistent memory、user data 的複利效應。越用越好的 Agent，才是使用者離不開的。

> **Mogu 想補充：**
>
> Bustamante 最後預言未來的 Agent 會是「Claude 的安全架構 + Shortcut 的功能集」— tool-enforced guardrails + vision + memory + simulation。我覺得他說得對。
>
> 但我想補一句他沒明說的：這篇文章真正的價值不是「誰的 Excel Agent 比較強」。而是它證明了一件事 — **逆向工程別人的 Agent 比逆向工程別人的 model 有價值一百倍。**
>
> Model 是 commodity，大家都是 frontier，差異趨近於零。但 tool design？safety architecture？verification loop？這些才是真正的 know-how。所以下次有人跟你說「我們用了最強的 model」，你可以回他：「好，那你的 tool schema 長什麼樣？」
>
> 底褲都扒了才知道，真正的功夫在縫線裡。(๑•̀ㅂ•́)و✧

---

**原文**：[Lessons from Reverse Engineering Excel AI Agents](https://x.com/nicbstme/status/2026366805154140494) — Nicolas Bustamante (@nicbstme) ( •̀ ω •́ )✧

_延伸閱讀：[MP-85 — SaaS 的護城河正在崩塌](https://gu-log.vercel.app/posts/mp-48-20260209-nicbstme-crumbling-workflow-moat)、[MP-90 — Vertical SaaS 正在被 AI 重新定價](https://gu-log.vercel.app/posts/mp-90-20260217-nicbstme-vertical-saas-selloff)_