AI 怎麼運作：給有 CS 背景但不寫程式的人的操作型定義
用系統思維理解現在的大型語言模型
by Claude and Human
定義與範疇說明
本文所稱的「AI」，專指 Anthropic 對外公開提供的 AI 服務，涵蓋兩個產品：
- claude.ai：網頁與行動端的對話介面，一般使用者透過瀏覽器或 App 與 Claude 模型互動的入口。
- Claude Code：以命令列為核心的開發者工具，讓使用者在終端機環境中將程式碼任務委派給 Claude 執行。
兩者底層共用同一系列的 Claude 語言模型（如 Claude Sonnet、Opus、Haiku），但在工具呼叫能力、記憶管理、操作介面上有明顯差異，本文會在適當之處加以區分。
本文不涉及 OpenAI、Google、Meta 等其他廠商的 AI 產品，亦不討論透過 Anthropic API 自行建置的第三方應用。所有操作型定義均以 2026 年 4 月 Anthropic 公開服務的實際架構為準。不過，本文描述的核心運作原理——無狀態推論、上下文視窗、工具呼叫——同樣適用於同代的其他主流 LLM（GPT、Gemini 等），差異主要在實作細節與產品包裝。
一、AI 的本質：一個沒有記憶的函數
現今的 AI（以大型語言模型 LLM 為代表）在操作層面，其實就是一個無狀態的數學函數：
f(輸入文字) → 輸出文字
每一次呼叫都是獨立的。模型沒有記憶、沒有意識、也沒有在「背景執行」。當你不跟它說話，它根本不存在。它的實體是大量浮點數組成的權重檔案——呼叫時載入、推論、輸出、停止。
這不是缺陷，這是架構本身的設計。所有「像人一樣」的行為，都是外層系統疊出來的幻覺。
值得注意的是，這個無狀態設計並非唯一可能的選擇，它的形成至少有三股力量共同作用：
Transformer 的架構本質。 Transformer 在設計上就是對一段固定長度的序列做注意力計算，天然適合「給我一個完整輸入、我給你一個完整輸出」的批次推論模式。有狀態的設計在理論上並非不可行，但需要額外的工程投入，與模型的原始訓練方式也不一致。
二十年網路服務的路徑依賴。 自 REST 架構在 2000 年代初期確立以來，無狀態、可水平擴展的後端服務就成為網路產業的預設正確答案。這套基礎設施（負載均衡、CDN、Kubernetes 等）都是為無狀態服務優化的。當 LLM 推論需要大規模部署時，直接套用這套成熟架構是阻力最小的路徑。
ChatGPT 的初始實作定錨。 2022 年底 ChatGPT 公開發布時，採用的就是「每輪把完整對話歷史重送」的設計。這個實作選擇快速成為整個產業的事實標準——後進者在 API 設計、開發者工具、使用者期待上，都不自覺地向它對齊。路徑依賴在此又疊加了一層。
因此，當前的無狀態設計是架構取捨、產業慣性與早期市場定錨三者共同鎖定的結果，而非純粹的技術必然。
二、「對話記憶」是怎麼來的？
你以為 AI 記得你說過什麼，其實是客戶端（瀏覽器、App、API）在每一輪對話時，把整段歷史記錄打包重送給模型。
第 1 輪：[系統提示] + [你的訊息]
第 2 輪：[系統提示] + [你的訊息] + [AI 回應] + [你的新訊息]
第 3 輪：[以上全部] + [你的又一則訊息]
模型每次看到的是一份越來越長的文件，然後預測「接下來最可能出現的文字」。所謂的「記憶」，是客戶端維護的對話陣列，不是模型本身記住了什麼。
關鍵認知：你在對話框裡感受到的連貫性，是 UI 層的工程，不是 AI 的內在狀態。
三、Context Window：模型的工作記憶上限
模型在單次推論中能「看到」的全部內容，稱為 Context Window（上下文視窗）。這是它的工作記憶——超出就看不到了。
- 目前主流模型約 200K～1M tokens（1 token ≈ 0.75 個英文字；中文則反過來，1 個中文字 ≈ 1～1.5 tokens，視用字而異）
- 當視窗快滿，系統會進行壓縮（Compaction）：把前面的對話摘要成更短的版本，再繼續
- 壓縮是有損的——你早先無意間決定的事情，可能在壓縮後消失
實務含義：重要的指令、背景資訊，應該存在外部持久層（檔案、設定），而不是只說過一次就算數。
另一個少有文件記載的現象是：Context Window 存在一個「甜蜜點」，塞太少或塞太滿都不是最佳狀態。普遍的使用者經驗顯示，當上下文接近上限時，模型對視窗中段的內容注意力會下降（俗稱「中間遺失」問題）；但視窗過空時，模型又缺乏足夠的背景做出準確判斷。甜蜜點的位置因模型版本而異，且會隨每次模型更新悄悄位移。
目前 Anthropic 並未就此發布正式操作準則。現有的參考依據主要來自兩個管道：一是重度使用者在論壇、社群的非正式分享（通常帶有強烈的個人使用情境偏差）；二是各種基準測試的間接推算，但這些測試設計本身也存在爭議。換句話說，在正式文件跟上實際模型能力之前，這個甜蜜點只能靠口耳相傳和自己踩雷來校準。
還有一個常見的直覺陷阱：**「Context Window 這麼大，把整本書丟進去翻譯一次，應該可以吧？」**表面上推算成立——一本 20 萬字的中文書約 30 萬 tokens，看起來塞得進 1M 的視窗。但實際上有兩道牆擋在前面：
技術層面有三道牆，不只是帳面上的 max_tokens 上限：
第一道：輸出長度硬上限。 以 2026 年 4 月的 Claude 為例，同步 API 單次呼叫的輸出上限為 64K（Sonnet）至 128K（Opus）tokens；批次 API 可延伸至 300K tokens。一本 20 萬字中文書的譯文同樣約 30 萬 tokens，帳面上似乎勉強塞得進批次 API——但這只是第一道牆。
第二道：輸出品質隨長度衰退。 即使帳面上限夠用，模型在長篇生成過程中會出現可觀察到的品質下降——重複用語、前後不一致、遺漏先前建立的脈絡。這不是偶發 bug，而是當前架構的結構性限制：隨著已生成的內容佔據越來越多上下文視窗，模型對早期內容的注意力會下降（與前述「中間遺失」問題同源）。實務上，即使用最高規格的付費方案，連續生成超過數萬 tokens 後品質就會明顯滑坡。
第三道：政策與速率限制。 Anthropic 在服務條款與速率限制上對超大輸入／輸出有額外門檻，部分行為（如批次長文處理）在 claude.ai 介面層也刻意設限，需走付費 API 或企業方案。
換句話說，帳面上限、實際品質上限、商業政策上限是三個不同的數字，而你真正能用的是三者中最小的那個。全書單次翻譯目前不是一個可直接操作的功能，而是需要分段、編排、品質校驗、後處理的工程問題。
四、工具（Tools）與 Agent：讓 AI 能執行動作
純粹的 LLM 只能輸出文字。讓 AI 能「做事」的方式是給它工具定義——一組結構化的 JSON Schema，描述它可以呼叫的功能。
流程如下：
- 模型讀到工具的自然語言描述，判斷該不該呼叫
- 模型輸出一個結構化的「呼叫請求」
- 外部程式（不是模型）執行實際邏輯
- 結果回傳給模型，模型繼續推論
模型不執行程式碼，它只輸出「要叫誰做什麼」的指令。 真正執行的是外圍系統。
Agent 是什麼？
Agent = 模型 + 工具執行器 + 迴圈控制器
把上面的流程放進一個迴圈：模型推論 → 呼叫工具 → 結果回填 → 模型再推論 → 直到產出最終回應。這個系統整體就稱為 Agent。模型本身仍然是無狀態的；「自主性」是迴圈賦予的，不是模型內建的。
五、多個實例之間：沒有心靈感應
每一個對話視窗、每一次 API 呼叫，都是完全獨立的實例。它們唯一能共享的是檔案系統——透過讀寫同一份檔案來傳遞資訊。
實例 A 的上下文 ──────────────────────┐
實例 B 的上下文 ──────────────────────┤ 彼此不相通
實例 C 的上下文 ──────────────────────┘
│
└── 共同的檔案系統（唯一的真實共享狀態）
這對架構設計有直接影響：如果你想讓多個 AI 流程協作，溝通媒介必須是明確的外部儲存，而非期待它們「感知彼此」。
用 Unix 管線類比：兩個程序可以透過 stdin/stdout 串接。在 claude.ai 的網頁介面中，實例之間沒有管線；但 Claude Code（命令列工具）透過 -p 旗標，可以真正作為 Unix 管線的一環運作——從 stdin 讀入、結果寫到 stdout：
# 傳統 Unix 管線
$ process_A | process_B
# Claude Code 可以直接參與管線（-p 旗標 = 非互動模式，stdin in / stdout out）
$ cat code.py | claude -p "review this code" | claude -p "turn the review into a checklist"
# 實務範例：把 git diff 餵給一個實例做分析，再串給下一個實例產出文件
$ git diff main | claude -p "summarize changes" > /tmp/summary.txt
$ cat /tmp/summary.txt | claude -p "write release notes from this summary"
# 也可以一行串完，每個 claude -p 都是獨立的無狀態實例
$ grep -rn "TODO" src/ | claude -p "prioritize these TODOs" | claude -p "format as markdown table"
但即使有了管線能力，每個 claude -p 呼叫仍然是獨立的無狀態實例——前一個實例的上下文不會自動帶到下一個，傳遞的只有 stdout 的文字內容。
對於不支援管線的場景（例如 claude.ai 網頁介面、多個並行實例協作），溝通方式退回到檔案系統：
# 虛擬碼：透過檔案系統協調多個實例
實例 A：讀取任務 → 推論 → 將結果寫入 /shared/output_A.json
實例 B：讀取 /shared/output_A.json → 推論 → 將結果寫入 /shared/output_B.json
關鍵認知：不論是 CLI 管線還是檔案中繼，每個實例都是無狀態的。管線讓串接更優雅，但本質沒變——AI 不記得上一個實例做了什麼，它只看到這次收到的輸入。
六、記憶的四個層次
| 層次 | 存活範圍 | 特性 |
|---|---|---|
| 上下文視窗 | 單次對話 | 最快、最直接；壓縮後有損失，對話結束即消滅 |
| 明確指令層（如 CLAUDE.md） | 跨對話持久 | 每次對話開始時注入；必須保持精簡，因為會消耗 token |
| 自動記憶（Auto-memory） | 跨對話持久 | AI 自己摘要寫入，下次啟動時載入前 N 行 |
| 檔案系統 | 永久 | 唯一真正共享的狀態；所有實例、所有工具都能存取 |
越高層越快，越低層越確定。設計系統時，要清楚每一條關鍵資訊該放在哪一層。
七、確定性層：從「AI 判斷」到「系統保證」
LLM 有一個根本特性：它的行為是機率性的，不是確定性的。「告訴 AI 記得做某件事」，本質上是在做機率賭注。
要把特定行為從 AI 判斷層移到確定性層，可以使用：
- Hooks（生命週期鉤子）：在 AI 執行前後觸發固定的 shell 指令，不經過 LLM 判斷
- 排程（Cron）：時間觸發，完全確定性
- 檔案監控：事件觸發，確定性接近系統層級
確定性由高到低：
最確定： 檔案系統事件、Hooks（shell 指令）、排程器
較不確定：工具呼叫（LLM 決定何時用）
最不確定：用自然語言叫 AI「記得去做某事」
設計原則：把必須發生的事放到確定性層；把需要判斷和推理的事留給 LLM 層。
八、MCP：外部工具的標準協定
MCP（Model Context Protocol）是讓 AI 連接外部工具的標準介面。架構上類似 REST API，但方向相反——永遠由 AI 主動發起呼叫，外部工具無法主動推送訊息給 AI。
要實現「事件驅動」行為（例如有新郵件時 AI 自動處理），觸發機制必須在 MCP 之外——排程器、webhook、檔案監控——由這些機制去啟動一個新的 AI 實例。
MCP 解決了工具定義的互通性問題：同一個工具伺服器，可以被不同的 AI 客戶端使用。
九、一張圖理解整體架構
你的輸入（自然語言）
↓
[客戶端] 組合整段對話歷史 + 系統提示 + 工具定義
↓
[LLM 推論] 無狀態函數，token in → token out
↓
輸出：純文字 or 工具呼叫指令
↓（若為工具呼叫）
[外部執行器] 執行實際動作（讀檔、搜尋、呼叫 API…）
↓
結果回填至上下文 → 重新推論
↓（重複直到輸出純文字）
你看到的最終回應
十、隱藏成本：你燒掉的 token 遠多於你看到的
前面的架構圖揭示了一個不直覺的經濟現實：你最終看到的有用輸出，只是整個推論過程中消耗的 token 的極小比例。
每一輪互動，系統都在重送完整的對話歷史、系統提示、工具定義、檔案內容。一個「改這個檔案裡的一行」的請求，背後可能消耗 5 萬到 15 萬 tokens 的輸入。隨著對話進行，到第 10 輪時，每則訊息已經帶著 8 萬+ tokens 的歷史上下文。
粗略的數量級估算：
互動模式（人類在迴圈中）：
有用輸出 : 總消耗 ≈ 1 : 500～1,000
一天產出幾百行程式碼，燒掉 1～2M tokens
自主 Agent 模式（無人值守長時間執行）：
有用輸出 : 總消耗 ≈ 1 : 5,000～10,000
Agent 大量讀檔（佔 60% 時間）、試錯、回溯、重讀修改後的檔案
多 Agent 協作時成本不是線性增長，而是倍數堆疊（5 個 Agent ≈ 20 倍單一 Agent 的成本）
根據 Anthropic 公開數據，Claude Code 平均每位開發者每天消耗約 $6 美元（90% 的使用者低於 $12）。這個數字背後，隱藏開銷（系統提示、歷史重送、工具定義）佔了總 token 消耗的 60～80%。
這不是浪費，這是無狀態架構的必然代價。 模型沒有記憶，所以每次都得把完整背景重新餵給它——這正是本文第一節描述的核心設計。理解這個成本結構，才能合理規劃 AI 輔助流程的預算與架構。
十一、給 CS 背景人士的速查對照表
| 你熟悉的概念 | AI 的對應本質 |
|---|---|
| Stateless REST API | LLM 推論本身 |
| 客戶端維護 Session | 對話歷史的「記憶」 |
| 工作記憶 / 快取大小 | Context Window |
| 函數呼叫 / RPC | 工具呼叫（Tool Use） |
| 事件迴圈 + Callback | Agent 的運作模式 |
| 中介軟體 / Hook | 生命週期 Hooks |
| 唯一真實來源（Single Source of Truth） | 檔案系統 |
| 機率 vs. 確定性 | LLM 層 vs. 系統層 |
結語
現今的 AI 不是一個在某處持續思考的存在。它是一個被反覆呼叫的無狀態函數，由外層的工程系統——客戶端、工具執行器、持久儲存、排程器——共同撐起「有記憶、有自主性」的幻覺。
理解這個架構，能讓你在設計 AI 輔助流程時，把對的事情放在對的層次，而不是把該確定執行的邏輯交給機率決定。
基於 2026 年 4 月的 Anthropic Claude 架構。核心原理亦適用於同代其他主流 LLM。
