淘汰「Context」這個詞：重新定義軟體設計中的資訊傳遞與工作流

SOURCE | 資訊源評估

• 準確性與深度：由 Linear 共同創辦人兼執行長 Karri Saarinen 撰寫，針對當前 AI Agent 領域盲目堆砌「Context（上下文／脈絡）」的工程亂象提出深刻批判。文章將問題從底層的「資料儲存與檢索（RAG／長視窗）」拉升至頂層的「意圖定義、領域結構與工作流設計」，具備極高的產品與系統架構洞察力。
• 易理解性：全篇無晦澀演算法術語，以 Slack 歷史訊息檢索、決策簡報（Briefing）與程式碼審查（Code Review）等日常研發場景為隱喻，直指資訊過載與時效性衰變的本質，邏輯極度清晰。
• 閱讀策略建議：建議軟體架構師、AI 應用工程師與產品負責人精讀。閱讀時應將文中的「Context」映射至自身系統的 Prompt 工程、Memory 架構與 Agent 狀態機設計，反思是否正用「擴大儲存容量」來逃避「明確定義規格與結構」的職責。

NAPKIN | 餐巾紙

• 一句話核心：我們正錯誤地將 AI 的「理解（Understanding）」當成「儲存問題（Storage Problem）」來解決；真正有效的智慧協作不靠傾倒全量歷史資料，而靠結構化的當下意圖、邊界約束與精準剪裁。

$$\text{Effective Intelligence} = \frac{\text{Intent}_{\text{current}} \times \text{Structure}(\text{Goal}, \text{Constraints}, \text{Expected Outcome})}{\text{Raw Historical Volume} \times \text{Temporal Decay} + \text{Noise}}$$

公式白話解析：Agent 與人類協作的有效產出，取決於當下意圖的清晰度與工作流結構（目標、限制條件、預期結果範例）的乘積；若盲目塞入未經篩選的原始歷史紀錄，隨時間失效的舊決策與廢棄討論將形成巨大雜訊，大幅稀釋並誤導決策品質。

• 行動觸發：盤點團隊現有的 AI Agent 或知識庫管線，立即停用籠統的 context 命名與無差別的歷史紀錄注入，改為顯式定義四個結構化欄位：DecisionRationale（決策原因）、CurrentObjective（當前目標）、Invariants（不可變更約束）與 AcceptanceExample（驗收範例）。

[傳統盲區：把理解當成儲存問題]
全量文件 + Slack 紀錄 + 歷史 Log + 工具呼叫軌跡 ──> 塞入巨型 Context ──> 資訊迷航與過時誤導

[架構正解：以結構收斂當下焦點]
歷史原始資料 ──> 結構化工作流 (Project / Code Review) ──> 提煉當下意圖與約束 ──> 精準決策與執行

ROUND 1: SKELETON | 骨架掃描

• 核心問題：為何我們捕捉所有文件、Slack 討論與系統軌跡餵給 Agent，卻依然無法讓它真正理解現況並做出正確行動？
• 核心答案：「擁有資訊」不等於「理解局勢」，將一切統稱為 Context 只是用資料檢索逃避定義目標、約束與工作結構的責任。
• 論證結構：破除迷思（批判全量捕捉謬誤）$\rightarrow$ 重新定義（對比精簡簡報與歷史資料時效衰變）$\rightarrow$ 解法落地（以結構化工作流與四大提問聚焦當下）。
• 3點章節骨架：
  1. 詞彙通膨與儲存幻覺：「Context」已退化為包山包海的垃圾桶詞彙，業界誤以為只要儲存所有歷史軌跡，理解就會自動湧現。
  2. 篩選的價值與時效性毒藥：真正理解局勢在於懂得省略無關資訊；未經治理的過期決策與廢棄討論，比沒有資訊更具誤導性。
  3. 以結構與具體問題取代 Context：放棄追問擁有多少 Context，改用 Project 與 Code Review 等結構載體，明確定義當下目標、約束與驗收標準。

ROUND 2: DISSECTION | 血肉解剖

現象：AI 領域將文件、Slack、Log、Traces 全數視為 Context 並無差別收集
  ├── 痛點 1：檢索不等於理解（如同在 Slack 翻找整天仍不知下一步該做什麼）
  ├── 痛點 2：歷史軌跡存在時間衰變（廢棄提案、失效決策比缺失資訊更危險）
  └── 本質診斷：把「理解（Understanding）」降維成「儲存問題（Storage Problem）」
        └── 架構轉向：拒絕籠統的 Context，拆解為四個具體維度
              ├── 1. 為什麼當初做此決策？ (Why a decision was made)
              ├── 2. 我們現在要達成什麼？ (What we're trying to achieve now)
              ├── 3. 什麼東西絕對不能改？ (Something it shouldn't change)
              └── 4. 令人滿意的結果長怎樣？ (An example of a happy result)

• 3點關鍵證據：
  1. Slack 搜尋與決策簡報的對比：擁有 Slack 全量歷史不代表知道下一步；有用的簡報之所以簡短，是因為深思熟慮過該納入什麼、剔除什麼干擾項。
  2. 歷史文件的時間腐敗（Temporal Rot）：堆積數十年的文件無法自動產生策略；六個月前寫得極清楚但現已失效的說明，對 Agent 而言是高置信度的誤導毒藥。
  3. Linear 產品架構實證（Project 與 Code Review）：Code Review 只需聚焦「改了什麼、為何改、影響什麼」，完全不必載入公司歷史或無效的工具呼叫軌跡。
• 隱形假設與邊界：
  • 隱形假設：假設任務發起者具備足夠領域認知，能在事前清晰定義目標、邊界與驗收範例，且系統具備維護決策時效性的機制。
  • 適用邊界：適用於目標導向的研發與決策執行；但在事故根因追蹤（Forensics）或合規審計場景，全量原始軌跡（Traces／Logs）的無損儲存依然不可或缺。

ROUND 3: SOUL | 靈魂提取

• 作者盲點：文章推崇結構化工作流，卻淡化了「誰來承擔結構化與資訊保鮮的認知成本」；未來仍需依賴具備時效感知與垃圾回收能力的背景 Agent 協助壓縮。
• 知識連接：與軟體工程的 ADR（架構決策紀錄） 狀態管理、DDD 限界上下文（Bounded Context） 及認知心理學的工作記憶負荷理論高度共鳴——智慧在於精準遺忘與焦點收斂。
• 行動觸發：重構團隊內部的 Agent Prompt 與 MCP 工具，將回傳「全量歷史對話」的 API 改為按工作流階段回傳「有效決策狀態」與「變更影響範圍」的結構化視圖。
• 2點留白提問：
  1. 提問一：為 Agent 建立長期記憶與 RAG 時，如何設計「知識墓碑機制（Tombstoning）」，防止半年前的舊決策成為今日的幻覺來源？
     • 架構師視角：應為知識加上類似 MVCC 或 ADR 的生命週期標籤（如 valid_from、superseded_by），讓檢索層預設僅讀取當前生效（Active）的決策快照。
  2. 提問二：若人類在指派任務時自己都說不清「不可變更約束」與「預期結果範例」，工作流結構該如何發揮作用？
     • 架構師視角：結構的價值在於強制暴露缺失；系統應透過 Schema 攔截邊界不清的任務，引導人類先與規劃型 Agent 完成規格對齊，而非放任盲目執行。
• 2點跨域映射：
  1. 資料庫設計（Event Sourcing vs. Materialized View）：傾倒全量 Slack 與 Log 如同每次查詢都重播百萬條 Event Log；結構化簡報則是專為當下任務打造的「物化視圖（Materialized View）」。
  2. 軍事指揮體系（Mission Command vs. 全量情報流）：指揮官不會將所有原始電報轉發給前線小隊，而是下達明確的「指揮官意圖、交戰規則與預期態勢」，這正是高可靠 Agent 的任務簡報架構。

DEEP READ | 精讀指引

• 原文金句摘錄一：

  “I think we are treating understanding too much like a storage problem. If we capture enough, perhaps the agent will figure out what we meant and produce what we hoped for. But more information doesn’t remove the need to be clear about what we want at any point in time.”

  • 推薦理由：直接戳破當前 AI 工程界最昂貴的幻覺——企圖用百萬級 Token 視窗與海量向量檢索，來填補人類「需求定義不清」的惰性。基礎設施的吞吐量永遠無法替代業務意圖的清晰度。
• 原文金句摘錄二：

  “And those decisions need to stay current. A clear explanation from six months ago can be more misleading than a missing one if nobody knows it’s no longer true.”

  • 推薦理由：精準點出企業知識庫與 Agent 記憶系統的最大隱患——「高清晰度的過期資訊」。缺乏時效性驗證與淘汰機制的知識累積，其負面破壞力遠大於資訊缺失。

STRUCTURE MAP | 全書結構圖

淘汰「Context」一詞 (Retire the word "context")
  ├── 診斷亂象：萬物皆 Context 的陷阱 ──> 文件、Slack、Traces 全量收集 ──> 資訊過載卻不知如何行動
  ├── 重新定義：什麼才是真正的理解 ──> 懂得取捨的簡報 (Briefing) + 警惕歷史資訊的時間衰變
  ├── 核心批判：把「理解」誤當成「儲存問題」 ──> 資料量無法替代當下意圖、目標與邊界的清晰度
  └── 解法落地：以具體問題與工作流結構取代籠統 Context
        ├── 四大提問：決策原因 / 當前目標 / 不可變更約束 / 理想結果範例
        └── 結構載體：以 Project 連結目標、以 Code Review 收斂變更焦點

淘汰「Context」這個詞：重新定義軟體設計中的資訊傳遞與工作流 (Architectural Deep Dive)

前言/背景

在當前的 AI 系統與 Agent 架構浪潮中，「Context（上下文／脈絡）」已成為最被濫用的技術詞彙。從企業內部的設計文件、會議逐字稿、Slack 討論串、系統日誌（Logs），到 Agent 執行過程中的追蹤軌跡（Traces）、評測結果（Evals）與隨機工具呼叫（Tool Calls），工程團隊習慣將所有能捕捉到的資料全部貼上「Context」的標籤，並假設只要將這些資料全部塞進大型語言模型的長視窗或向量資料庫中，智慧與理解就會自動湧現。Linear 執行長 Karri Saarinen 撰文指出，這種「全量捕捉、無差別供應」的思維，正把複雜的認知與決策問題錯誤地簡化為底層的資料儲存問題。

章節詳細總結

1. 「理解」不是儲存問題：全量歷史紀錄的時效性衰變與檢索迷航

許多工程團隊在建構 AI Agent 時，陷入了「資料越多越好」的迷思。然而，正如人類在 Slack 中搜尋歷史訊息的痛苦經驗一樣，「資訊存在於某處」完全不等於「找得到、看得懂、且知道下一步該做什麼」。當我們說一個人類工程師「具備 Context」時，並不是指他背誦了公司所有的歷史對話，而是指他理解當前局勢：知道某件事為何發生、團隊現在要達成什麼目標、以及哪些問題尚未定案。一份優秀的決策簡報（Briefing）之所以簡短有力，正是因為經過了嚴格的認知過濾，剔除了會分散注意力的雜訊。

更嚴重的是，全量歷史資料帶有強烈的「時間腐敗（Temporal Decay）」特性。在真實的軟體研發週期中，許多構想早已被放棄、舊的架構決策已不再適用、無數討論最終無疾而終。如果系統只是盲目地將過往紀錄打包餵給 Agent，一份「六個月前寫得極度清晰、但如今已不再成立」的舊決策說明，對模型造成的誤導遠比「完全沒有這份資料」更加致命。

架構權衡 (Trade-offs)

• 優勢：放棄全量原始資料注入、改採「精煉簡報（Curated Briefing）」模式，能大幅降低 Token 消耗與推理延遲，並消除過時決策對模型注意力機制（Attention）的干擾。
• 劣勢與成本：需要額外的資料治理機制來區分「當前有效狀態」與「歷史歸檔紀錄」；若過度裁剪且缺乏按需回溯（On-demand Lookup）通道，排查歷史根因時可能缺乏線索。
• 選型建議：將系統記憶拆分為「預設注入的當前工作視圖（Active Working Briefing）」與「按需查詢的歷史歸檔工具」，嚴禁將未經篩選的原始對話串直接作為預設 Prompt 輸入。

2. 以「結構化工作流」與「四個具體問題」取代籠統的 Context

為了跳出「不斷建造新的資料儲存與檢索系統」的死胡同，Saarinen 主張在工程與產品設計中直接淘汰籠統的「Context」一詞，改為針對眼前的任務提出四個具體且可回答的架構問題：決策脈絡（Why）——當初為什麼做出某項決策？當前目標（Objective）——我們現在正試圖達成什麼具體成果？不變約束（Constraints）——有哪些既有行為或架構邊界是絕對不能更動的？以及驗收範例（Expected Result）——一個令人滿意的輸出結果長什麼樣子？

這正是「結構（Structure）」在軟體工程工具中存在的意義。以 Linear 的產品設計為例，**專案（Project）**將零散的工作連結到明確的業務目標；**程式碼審查（Code Review）**則提供了一個在變更合入前進行判斷的結構化場域。在進行 Code Review 時，審查者與 Agent 只需要聚焦於「這次改了什麼、為什麼要改、以及它可能影響哪些關聯模組」，而完全不需要載入整間公司的歷史文件或 Agent 先前嘗試過的無效工具呼叫。結構的存在，幫助人類與 Agent 在特定時刻收斂出真正重要的資訊，讓資訊具備明確的用途與語義。

架構權衡 (Trade-offs)

• 優勢：透過強型別的工作流結構（如 Project、Issue、Code Review 階段）約束資訊輸入，能使 Agent 的行為高度可預測、可測試，並將人機協作介面標準化。
• 劣勢與成本：要求任務發起者在啟動 Agent 前必須先定義目標、約束與範例，提高了任務啟動的前置門檻，無法滿足「隨手丟一句模糊指令就期待完美結果」的預期。
• 選型建議：在設計企業級 Agent 平台時，應以工作流狀態機為核心骨架，為不同階段（規劃、編碼、審查、部署）定義專屬輸入 Schema，強制要求提供目標與邊界約束。

總結與結論

1. 從「容量思維」轉向「意圖與剪裁思維」：AI 應用的瓶頸已不再是 Context Window 能塞進多少資料，而在於系統能否精準剔除無關與過時的歷史雜訊，向 Agent 傳遞清晰的當下意圖。
2. 過期的高清晰度資訊是系統毒藥：沒有生命週期管理與狀態標記的知識庫，隨時間推移必然退化為誤導源；架構設計必須確保決策紀錄具備「時效性驗證」能力。
3. 工作流結構即是最好的資訊過濾器：不要問 Agent 擁有多少 Context，要問它為了完成「現在這一步」究竟需要什麼；透過 Project 與 Code Review 等結構化容器來收斂焦點，才是提升人機協作效能的根本之道。

Source URL: https://x.com/karrisaarinen/status/2118057321654046811