生產環境 AI 智能體的四層上下文工程：Deep Insight 如何以實際程式碼實踐

當生產環境中的 AI Agent 處理數據分析和報告生成等工作時，上下文管理可能會成為主要瓶頸。200K token 的上下文視窗聽起來相當寬裕，但實際工作中，幾分鐘內便可能耗用大部分容量。數據分析和報告生成等工作可能令 Agent 在執行途中失敗、準確度下降，或令成本上升。已有不少公開指引探討這個問題，但各項技巧讀起來容易，實際應用卻不然。把這些技巧結合起來，便能帶來顯著成效：本文逐步講解的參考實作中，單一寫入並執行工具可將每個指令碼加入上下文的 token 數量減少約 95%，按需載入技能則可將系統提示詞縮短約 97%。

本系列會把這些指引整理成可直接應用的做法。Anthropic 的工程文章與 Strands Agents SDK 內置的功能，歸納出上下文工程的四個層面：在架構層面隔離上下文、透過提示詞加以控制、將上下文外置至檔案系統，以及透過獨立 Agent 和防護措施進行驗證。在本文（第 2 部分）中，你將瞭解每個層面的運作方式，以及如何在實際程式碼中實現。我們在 Deep Insight 中應用了這些技巧；這是一套以 Strands Agents SDK 和 Amazon Bedrock AgentCore 為基礎的開源多 Agent 數據分析方案，並會在全文中作為參考實作。

系列文章

• 第 1 部分：多 Agent 系統在生產環境中的 5 項挑戰，以及 Deep Insight 如何解決這些問題。
• 第 2 部分：生產環境 AI Agent 的上下文工程四個層面：Deep Insight 如何在實際程式碼中實現這些做法。
• 第 3 部分：實踐 Harness 工程：將 Deep Insight 從開發環境推展至生產環境。（即將推出！）

第一篇文章界定了生產環境中的多 Agent 系統必須解決的五項核心挑戰，並透過程式碼範例介紹 Strands Agents SDK、Amazon Bedrock 和 Bedrock AgentCore，以及 AWS Fargate 如何分別應對問題的不同層面。第二篇文章會探討建基於該架構之上的上下文工程四項實踐，並展示各項做法的實際實現。第三篇文章會指導你如何在 Amazon Virtual Private Cloud (Amazon VPC) 的安全私人網絡中部署和營運 Agent，涵蓋實際營運所需的一切。

甚麼是上下文工程？

上下文工程是一門專注於優化大型語言模型（LLM）有限上下文視窗內資訊的技術，目的是讓 Agent 發揮最佳效能。Amazon Bedrock 提供的 Anthropic Claude Sonnet 4.5 擁有 200K 上下文視窗，但複雜的生產環境工作很快便會超出其容量。例如，一項看似簡單的要求，例如「分析銷售數據並建立 DOCX 報告」，便要經過多個階段：載入和探索數據（5 min）、按類別進行銷售分析（3 min）、為時間序列分析生成五張圖表（10 min）、統計驗證（3 min），以及生成最終報告（5 min）。這些工作合計會在 15 分鐘內耗用超過 150K token。

在單一上下文中處理這類工作會引發問題：上下文視窗可能在任務完成前便用盡，過時的上下文會降低效能，而出錯時則需要重新執行整個流程。隨着上下文增長，模型對重要資訊的關注度會下降；在按 token 計費的情況下，效率低下亦會推高成本。

「隨着上下文窗口中的 token 數量增加，模型準確回想該上下文資訊的能力會下降（上下文腐化）。」

— Anthropic，《AI Agent 的有效上下文工程》（2025.09）

上下文工程正是為瞭解決這些問題，而且它不只是一套技巧。它涵蓋架構設計、提示詞撰寫、工具實作及驗證，是一門分層的專業領域，每一層都能補足前一層的不足。本文詳述如何運用四層方法，有效管理上下文。

如何處理超出上下文窗口的任務

Anthropic 發表了多種處理長時程任務的技巧。Deep Insight 將這些技巧歸納為四層，每一層都針對其他層的限制作出補足。下表列出這四層。

以下各節會依次介紹每一層，説明該層的要求、為何單靠前一層並不足夠，以及 Deep Insight 如何實踐相關做法。

1. 透過多代理架構隔離上下文

為每個專門代理設定獨立的上下文窗口，並只向協調器傳送經壓縮的結果。Deep Insight 採用由協調員、規劃員、計劃審核員、監督員及工具代理（Coder、Validator、Reporter、Tracker、Auditor）組成的層級架構。

若只使用單一代理，從用戶要求、資料探索、分析、圖表生成、驗證到撰寫報告的所有資訊，都會累積在同一個上下文中，很容易超出窗口。為每個代理設定獨立上下文，即使用量最高的 Coder，總量也能維持在 25K tokens 以下。每個代理只會收到所需資訊，並以完成通知及簡短摘要通知其他代理。

隔離的關鍵在於盡量減少共享資訊。Deep Insight 使用 Python 字典 shared_state，只儲存四項內容：

• messages：上一個代理的最後訊息（而非完整對話記錄）。
• clues：從各代理收集而來的精簡摘要。
• full_plan：由 Planner 生成並由 Tracker 更新的檢查清單。
• history：代理名稱及訊息的簡短記錄。

線索採用固定的 CLUES_FORMAT：每個代理不會傳遞完整對話（數萬個 token），而只會傳遞經壓縮的核心結果。

# coder_agent_tool.py -- context passing format
CLUES_FORMAT = "Here is clues from {}:\n\n<clues>\n{}\n</clues>\n\n"
RESPONSE_FORMAT = "Response from {}:\n\n<response>\n{}\n</response>\n\n*Please execute the next step.*"

# After Coder completes: add only compressed result to clues
clues += CLUES_FORMAT.format("coder", response["text"])

Anthropic 在《我們如何建構多代理研究系統》一文中亦推薦這種模式。文章介紹了協調者－工作者模式：主代理將工作委派給專門的子代理，而每個代理只在自己的上下文中工作。你不必自行建構這套架構：Strands Agents SDK 中的 agents-as-tools 模式可在框架層面提供這種隔離。

2. 透過提示詞控制上下文輸入

單靠 Layer 1 隔離並不足夠：即使上下文彼此獨立，生成冗長回應的 Agent 仍會令 Supervisor 的上下文膨脹。Layer 2 透過提示詞限制各 Agent 的輸出。

在 Deep Insight 中，我們使用提示詞限制各 Agent 回傳給 Supervisor 的資訊量。Deep Insight 的提示詞顯示，三項規則發揮了主要作用。

「從最強大的模型和簡單的提示詞開始，再根據實際觀察到的失敗個案，逐步加入具體指示。」

— Anthropic，《AI Agent 的有效上下文工程》（2025.09）

實作細節 2-1：為每個 Agent 明確設定輸出 Token 預算

每個 Agent 的提示詞都會指定回應的 Token 數量上限，避免冗長回應污染 Supervisor 的上下文。

Anthropic 的 ” 為 Agent 編寫有效工具” 文章建議，為工具提供 CONCISE 或 DETAILED 回應選項，以提升上下文使用效率。可在更上一層，於每個 Agent 的系統提示詞中採用相同概念。在 Deep Insight 中，所有 Agent 共用同一種標準格式：

## Status
[SUCCESS | PARTIAL_SUCCESS | ERROR]
## Completed Tasks
- [Task 1 from FULL_PLAN -- use exact wording so Tracker can match]
- [Task 2 -- be specific, not generic]
## Key Insights
- [Key finding 1 with numbers and ratios]
- [Key finding 2 with business implications]
## Generated Files
- ./artifacts/chart.png -- brief description
- ./artifacts/calculation_metadata.json -- N calculations

實作細節 2-2：自包含程式碼理念

Coder Agent 的提示詞明確指出「變數不會在不同指令碼之間持續存在」。每個指令碼都必須包含所有必要的匯入項目，並直接載入數據。提示詞提供了錯誤和正確的例子：

# WRONG -- Attempting to use a variable from Turn 1 in Turn 2
# Turn 1:
df = pd.read_csv('data.csv')
total = df['Amount'].sum()

# Turn 2:
print(f"Total: {total}")  # NameError: name 'total' is not defined

# CORRECT -- Every script is self-contained
import pandas as pd
df = pd.read_csv('./artifacts/cache/df_main.csv')  # Load from cache
total = df['Amount'].sum()
print(f"Total: {total}")

這項規則與上下文工程有關，原因在於參照先前指令碼中的變數，會要求 Agent「記住」之前的對話，也就代表過往程式碼必須保留在上下文中。自包含原則則表示過往程式碼可以安全地從上下文移除。

實作細節 2-3：Supervisor 的區段完成規則

Supervisor 的提示詞包含以下規則：「在目前 Agent 區段的所有檢查清單項目都標記為 [x] 前，不要轉到下一個 Agent。」我們在提示詞中訂明這項規則，因為判斷 Coder 的工作是否完成，需要 Supervisor 根據 Tracker 的更新資訊解讀計劃。單靠程式碼很難表達這項判斷。

3.「上下文中只保留指標，實際數據存於檔案」

Layer 1 隔離不同 Agent 的上下文，Layer 2 限制各 Agent 的輸出。但當 Coder Agent 產生 100 行 Python 程式碼時，程式碼本身也會進入上下文。即使提示詞要求「簡短回應」，有些程式碼仍無法簡短呈現。Layer 3 透過工具設計，將大量內容移出上下文，存入檔案系統。以下實作細節展示了四種最能發揮作用的技巧。

實作細節 3-1：透過 Write and Execute Tool 將程式碼移出上下文

Coder 會讀取分析計劃、編寫 Python 程式碼，並執行程式碼以產生視覺化圖表。但程式碼一旦變長，傳統做法（分開使用寫入檔案和執行工具）就會令每個指令碼的 100 行程式碼直接進入上下文，累積超過 1,000 行。

解決方法是將兩個步驟合併為單一工具，讓程式碼不會以訊息形式進入上下文。Deep Insight 的 Coder Agent 會使用一個 write_and_execute_tool 來完成這項工作。

以下是 write_and_execute_tool 的一部分。寫入並執行檔案後，它只會傳回摘要：「已寫入 105 行，執行成功，已完成五個類別的分析。」程式碼保留在檔案中，上下文只剩約三行摘要。按這個例子計算，可節省約 95% 的 token。

# write_and_execute_tool.py
def _handle_write_and_execute_tool(file_path, content, timeout=300):
    """Write a Python script and immediately execute it."""
    # Step 1: Write file
    with open(file_path, 'w', encoding='utf-8') as f:
        f.write(content)
    # Step 2: Execute immediately
    result = subprocess.run(
        f"python {file_path}",
        shell=True,
        capture_output=True,
        timeout=timeout
    )
    # Return only summary
    return f"Written {len(content.split(chr(10)))} lines to {file_path}\n" \
        f"Execution successful\n" \
        f"Output: {result.stdout[:500]}"  # Only first 500 chars

「伺服器端篩選：在資料到達上下文前，於執行層篩選資料，減少 98.7% 的 token（由 150K 減至 2K）。」

— Anthropic，《使用 MCP 執行程式碼》（2025.11）

實作細節 3-2：在 Coder agent 中以模組重用共用邏輯

共用模組會在不同分析中重複使用。無需每次重新生成，只要將常用函數定義為模組一次，再匯入使用，便可避免浪費 token 和重複佔用上下文。

如果沒有這種做法，每次分析都定義 to_python_type() 或 track_calculation() 等函數，10 次分析便會產生 200–300 行重複程式碼。Deep Insight 會在第一項任務開始前生成名為 coder_analysis_utils.py 的模組。模組包含轉換 numpy 類型、追蹤計算中繼資料及儲存為 JSON 的函數。其後的分析只需匯入該模組，以兩行匯入程式碼取代重新生成的 20–30 行程式碼，既可節省 token，亦能提升一致性並方便除錯。

# coder_analysis_utils.py -- common module generated before first task
import numpy as np
import json
from datetime import datetime

_calculations = []

def to_python_type(value):
    """Convert numpy/pandas types to Python native types"""
    if isinstance(value, (np.integer, np.int64)): return int(value)
    elif isinstance(value, (np.floating, np.float64)): return float(value)
    elif isinstance(value, np.ndarray): return value.tolist()
    return value

def track_calculation(calc_id, value, description, formula,
                      source_file, source_columns, importance):
    """Track calculation metadata -- Validator independently verifies later"""
    _calculations.append({
        "id": calc_id, "value": to_python_type(value),
        "description": description, "formula": formula,
        "source_file": source_file, "source_columns": source_columns,
        "importance": importance
    })

def save_calculation_metadata(path="./artifacts/calculation_metadata.json"):
    """Save all tracked calculations to JSON"""
    with open(path, 'w', encoding='utf-8') as f:
        json.dump({"generated_at": datetime.now().isoformat(),
                   "calculations": _calculations}, f, ensure_ascii=False, indent=2)

實作細節 3-3：透過結構化筆記儲存和分享分析結果

我們使用結構化筆記分享詳細分析結果，無需經由每個 agent 的上下文傳遞。Deep Insight 會將這些結果存放在名為 all_results.txt 的檔案中，agent 可按需要讀取。

例如，Coder agent 會在每項分析任務完成後，將結果附加至 all_results.txt：

with open('./artifacts/all_results.txt', 'a', encoding='utf-8') as f:
    f.write(f"""
## Category Sales Analysis (completed at: 14:32)
- Top revenue category: Fruit (417,166,008 KRW, 45% of total)
- Top 3 categories: Fruit, Vegetables, Meat (78% of total)
- Generated file: ./artifacts/category_sales_chart.png
""")

每次分析後，Coder 都會將詳細結果記錄在這個檔案中；Reporter 撰寫最終報告時則會讀取該檔案。其他 agent 亦會透過 all_results.txt 以相同方式協作。

如果不使用筆記，Coder 每完成一項任務便會將詳細結果傳給 Supervisor，令這些內容不斷累積在其上下文中。使用筆記後，只需傳送一則約 30 個 token 的訊息，例如「類別銷售分析已完成，找到 3 項重要洞見，詳細結果已儲存至 all_results.txt」，Reporter 便可在需要時讀取檔案。

這種做法不只適用於單一檔案。檔案系統本身亦可作為 agent 之間的通訊匯流排，正如 Deep Insight 所示：

「『即時載入』方式會在執行階段動態載入資料至上下文，而非預先處理所有相關資料，令上下文保持最新、切合需要，並能適應任務狀態的演變。」

— Anthropic，《為 AI Agent 有效設計上下文》（2025.09）

實作細節 3-4：透過 Skills 只載入所需知識

這種做法不會把所有專業知識都放進系統提示詞，而是在需要時才載入。若包含每份技能指南（數據結構檢查、README 生成、技能建立、系統提示詞撰寫、工具建立），內容會超過 20K 個 token；每次呼叫都會向 Coder agent 載入不必要的資訊，而且新增技能時必須重新部署。

Deep Insight 的 Skills 系統在啟動時只載入約 500 個 token 的技能目錄，技能清單中只有名稱和簡短説明。當用戶要求「建立 README 檔案」時，agent 會判斷「我需要 readme-generator 技能」，然後呼叫 skill_tool(skill_name="readme-generator")。SkillLoader 會讀取 readme-generator/SKILL.md，並傳回一份約 3K 個 token 的詳細指南。

# 1. Skill Discovery (at initialization)
from src.utils.skills.skill_utils import initialize_skills
available_skills, skill_prompt = initialize_skills(
    skill_dirs=["./skills"],
    verbose=True
)

# 2. Add to System Prompt (~500-token catalog)
system_prompt = base_prompt + skill_prompt

# 3. Runtime -- Agent loads skill when needed
# Agent decides: "This is README generation, I need the readme-generator skill"
# -> skill_tool(skill_name="readme-generator")
# -> Returns full SKILL.md content (~3K tokens)

每項技能都以 SKILL.md 檔案定義，由 YAML frontmatter 和詳細的 Markdown 指南組成。檔案包含 name、description、license 和 allowed-tools 等中繼資料，以及 Overview、When to Use This Skill、詳細指示和 Best Practices。要新增技能，只需在 skills/ 下建立新目錄並撰寫 SKILL.md 檔案，系統便會自動發現該技能。

啟動時，agent 載入約 500 個 token 的技能目錄，而不是浪費超過 20,000 個 token 載入完整指南（減少約 97%）。需要時，則可再載入幾千個 token 的技能詳細指示。

4. 透過驗證 agent 和防護措施確保品質

即使有第 1 至第 3 層，仍有一個風險：各 agent 彼此看不到對方的工作，因此如果 Coder 計算出錯，Reporter 便會把錯誤帶進報告。第 4 層是最後一道防線。

「提供測試工具，讓 agent 可以自行驗證功能，並修正單靠程式碼不易發現的錯誤。讓模型以描述清晰的提交訊息，把進度提交到 git，並在進度檔案中撰寫進度摘要。」

— Anthropic，《適用於長時間執行 agent 的有效 Harness》（2025.11）

實作詳情 4-1：Tracker、Validator 和 Auditor agent：進度追蹤與品質保證

Tracker 會即時更新計劃中的檢查清單。Coder 完成數據載入後，Supervisor 會呼叫 Tracker；Tracker 根據「數據載入完成（1,000 行，5 欄）」等資訊，將計劃項目由 [ ] 更新為 [x]。這讓用戶和系統都能清楚掌握目前進度。

Validator 會獨立重新執行 Coder 的計算，以驗證準確性。它會讀取 calculation_metadata.json，根據來源數據重新執行每項計算並進行比較：差異在 0.01 以內即通過，不符的結果則會被標記。已驗證的計算結果會交給 citations.json，供 Reporter 引用。Reporter 完成後，Auditor 會對照 citations.json 和 calculation_metadata.json 檢查最終 DOCX，但不會修改這些檔案。它會在 audit_findings.json 記錄引用缺陷，並可要求 Reporter 最多進行兩次有針對性的重試。

實作詳情 4-2：按重要程度優先驗證計算項目

逐一驗證所有計算項目效率不高，因此應按重要程度限定驗證範圍。Deep Insight 的 OptimizedValidator 會採用以下門檻：

• 超過 50 項計算：嚴格篩選，驗證所有高優先級項目，並只驗證 10 項中優先級項目。
• 超過 20 項計算：中度篩選，驗證所有高優先級項目，並驗證 15 項中優先級項目。
• 20 項或以下計算：驗證大部分項目，包括所有高優先級項目、所有中優先級項目，以及 5 項低優先級項目。

此外，系統會採用型別安全的比較方式：為避免 numpy 與 Python 之間的型別問題，所有數值都會轉換為 float()，並檢查絕對差值是否低於 0.01：

# validator.md -- type-safe numerical comparison
try:
    match = abs(float(expected) - float(actual)) < 0.01
except:
    match = str(expected) == str(actual)

實作細節 4-3：SummarizingConversationManager：最後一道安全網

在特殊情況下，上下文仍可能溢出，因此要在其他層之下保留一道安全網。Deep Insight 使用 Strands Agents SDK 中的 SummarizingConversationManager 做到這一點。

# strands_sdk_utils.py -- safety net configuration at agent creation
agent = Agent(
    model=llm,
    system_prompt=system_prompts,
    tools=tools,
    conversation_manager=SummarizingConversationManager(
        summary_ratio=0.5,  # summarize oldest 50% on overflow
        preserve_recent_messages=10,  # always preserve 10 most recent messages
        summarization_system_prompt=apply_prompt_template("summarization", {})
    )
)

溢出時，LLM 會把最舊 50% 的訊息摘要成一則訊息，同時始終保留最近 10 則，以維持目前任務所需的上下文。摘要提示詞（summarization.md）要求原樣保留 clues、plans 和 tracking status。

實作細節 4-4：透過選擇性提示詞快取優化成本

上下文工程不只着眼於節省 token，也涵蓋成本優化。可根據各個 Agent 使用相同提示詞的頻率，為其啟用提示詞快取。Deep Insight 各 Agent 的設定如下：

啟用快取的 Agent 會在系統提示詞和工具定義中插入快取點，重複呼叫時可將輸入 token 成本降低最多 90%。這是 Strands Agents SDK 原生支援的功能。表格中沒有列出 Plan Reviewer，因為它是 human-in-the-loop 步驟，負責收集用戶批准或意見回饋，而不是呼叫模型。

結論

本文詳細介紹了一套四層工程方案，可用於有效管理超出上下文視窗限制的複雜任務所需的上下文。

• 第 1 層（架構層級隔離）：透過多 Agent 架構，讓每個 Agent 在獨立的上下文中工作，只傳遞經壓縮的摘要。
• 第 2 層（提示詞控制）：透過輸出 token 預算、標準化回應格式和自包含程式碼理念，主動限制流入上下文的內容。
• 第 3 層（使用檔案系統）：write_and_execute_tool 讓程式碼留在上下文之外；檔案系統充當 Agent 之間的通訊匯流排；知識只在需要時才延遲載入。
• 第 4 層（驗證與安全措施）：Validator 獨立重新計算並驗證、Auditor 對最終報告進行唯讀引用審核、Tracker 追蹤進度、SummarizingConversationManager 防止溢出，以及選擇性提示詞快取，共同管理品質和成本。

每一層都構成一道防線，彌補前一層的不足。架構隔離不足時，提示詞會限制輸出；提示詞控制不足時，工具會把內容留在上下文之外；如果問題仍然出現，驗證機制便會將其找出。

這些層面均記載於 Anthropic 的工程技術文章中：「為 AI Agent 有效設計上下文」、「使用 MCP 執行程式碼」，以及 「我們如何建構多 Agent 研究系統」。他們建議的許多做法，已經內置於 Strands Agents SDK，無需自行建置：SummarizingConversationManager、提示詞快取，以及 Agent 作為工具的模式。

建構正式投入使用的 Agent 時，單靠 LLM 的上下文視窗往往並不足夠。運用這些上下文工程技術，有效管理上下文，並擴展 Agent 以應付生產環境的工作負載。

本文使用的參考實作 Deep Insight 是開源的。你可以檢視程式碼，並按你的領域需要加以擴展。

• GitHub
• 工作坊

作者簡介

Yoonseo Kim

Yoonseo 是一名解決方案架構師，協助客戶運用 AWS 技術解決業務挑戰。她對 AI/ML 深感興趣，專注協助客戶設計及優化 Agentic AI 工作負載，並支援相關基礎設施和評估環境。

Gonsoo Moon

Gonsoo 是 AWS 的 AI/ML 專家解決方案架構師。他憑藉在不同 AI/ML 應用場景及生產環境部署方面的經驗，與客戶緊密合作，協助解決 AI/ML 挑戰。他亦與數據科學家、開發人員及分析師分享 AI/ML 知識，致力為韓國以至世界各地帶來正面改變。

Jiyun Park

Jiyun 是一名解決方案架構師，協助軟件及互聯網行業的客戶將工作負載遷移至雲端。她與客戶合作設計雲端解決方案，助他們實現業務目標。

Chloe Kwak

Chloe 是 Applied AI Solutions 組織內 Amazon Connect Decisions 的高級專家解決方案架構師，支援 APJ 各地的客戶。她曾在 Korea Retail 團隊工作數年，協助零售及電子商務客戶在 AWS 上推動現代化，並將 AI/ML 投入生產環境。現時，她協助客戶運用 Agentic AI 進行需求與供應規劃，親身參與從數據準備、預測驗證到正式推出的整個過程。

Jesam Kim

Jesam 是一名解決方案架構師，協助企業客戶採用雲端技術及解決業務挑戰。他專注於 AI/ML，包括推薦系統和生成式 AI，協助客戶設計切合業務需要的架構。

Kyutae Park, Ph.D.

Kyutae 是一名 AI 專家解決方案架構師，憑藉在機器學習、MLOps 及 Agentic AI 方面的豐富經驗，協助各行各業的客戶設計及建構應用 AI 工作負載。他專注於透過 Agentic AI 推動智能自動化及營運創新，將自主決策和多 Agent 協作架構應用於實際業務環境。透過這些工作，他協助客戶運用 AWS AI/ML 服務及應用生成式 AI，實現切實的業務成果，並建立可持續的競爭優勢。