如何於 2026 年構建 AI Agents（完整課程）

這是 AI 開發者們不願面對的真相。

他們大多數都在打造展示品

你真正需要打造的是

一個生產級的 AI Agent

TLDR；如果你不想讀完整篇文章，把這個連結給你的 Agent，讓它幫你回答問題：➡️https://github.com/codejunkie99/agentic-harness

這是一切的起點——這則推文

問題在於，大多數 AI 工程師在決定認真投入 Agent 開發時，根本不清楚到底該建構什麼。

有些人選擇 LangChain，因為 YouTube 上的多 Agent 展示看起來很漂亮，結果花了兩週時間跟 Python 互操作性和非同步執行環境的相容性問題奮戰，最後整組砍掉重練。

有些人嘗試從零打造自定義的編排層：一個迴圈、一個 session 儲存、一個上下文組裝器，結果基礎設施吃掉了所有時間，真正的 Agent 根本沒寫完。

還有一些人複製了 hello-world 的 webhook 範例，收到一個 JSON 回應，就自以為掌握了整個系統，然後上線的東西在 session 運行超過十分鐘、遠端沙盒中途掛掉、或上下文視窗沒有配置壓縮而爆滿時，立刻崩潰。

結果通常都一樣：一堆管線，沒有生產級 Agent，也缺乏對生產級 Agent 執行環境的正確認知。

如果你的目標是在 2026 年建構並上線真正的 Agent，你不需要學六個框架。

你只需要深入理解一個執行環境，從 handler 到部署都能掌握一個生產級 Agent。

這意味著你要學會如何：

串接三層架構，讓你的 handler 邏輯在更換供應商或目標環境時，不需要修改 Agent 程式碼
正確使用 session 和 task，讓長時間任務不會污染自己的上下文
撰寫 role 和 skill，在不重新編譯的情況下塑造模型行為
配置壓縮機制，讓運行兩小時的 session 不會在第一小時就開始幻覺
將 HttpSessionEnv 指向遠端沙盒，讓二進位檔在本機執行，而實際運算在 Linux 上進行
選擇正確的建構目標：native、node 或 Cloudflare，且不需在它們之間重寫任何 Agent 邏輯
生成 connector 而非手寫 adapter，並理解在真實負載下這兩者的差異為何重要

這份指南是完整的技術實戰手冊，基於實際的 agentic-harness 程式碼庫、六週的建構與破壞真實 Agent 的經驗，以及那些花最多時間除錯的失敗模式。

全文超過 4,000 字，直接引用 repo 和官方文件，而非二手摘要或展示層級的範例。

但它的真正價值在於：每個章節都附有可運作的程式碼片段、清楚的決策原因說明，以及如果你跳過它會遇到的確切失敗模式。

這樣一來，當你讀完時，就能從第一個 handler 到沙盒再到無人值守的 CI 任務，完整掌握一個生產級 Agent。

建立這樣的認知花了超過 6 週的時間每天與程式碼庫打交道，其中大部分時間都在除錯那些看似正確、卻在真實條件下崩潰的東西。

現在我們開始吧。⬇️

專案架構

兩個 crate。一個二進位檔。每個執行目標都是一個設定選擇，而不是重寫。

SDK 是一個你可以引入任何 Rust 專案的函式庫。CLI 包裝了它。你的 Agent 是一個以 use agentic_harness::prelude::*; 開頭的 Rust 二進位檔。
cargo build 就是整個管線。沒有 bundler、沒有轉譯步驟、目標機器上不需要語言執行環境。一個自包含的可執行檔加上一個 manifest.json。

驅動一切的設計限制：同一個 Agent 二進位檔應該能在你的筆電上以互動模式執行、在 GitHub Actions 任務中複製一個全新 repo、透過 HTTP 連接到遠端 E2B 沙盒、以及在 Cloudflare Worker 邊界上執行，且不需在它們之間修改任何一行 Agent 邏輯。

這個程式碼庫中的每個決策都是為了遵守這個限制。

三層架構與各自存在的理由

心智模型是三個同心圓。知道每個邊界在哪裡，能為你省下的除錯時間比這份指南中的任何其他內容都多。

你的 Rust 程式碼是外圈。

你撰寫 handler。handler 接收一個 AgentContext。它們呼叫 session。session 呼叫模型、讀取檔案、寫入檔案、執行 shell 指令、產生 task、連接到 MCP 伺服器。
你從不直接碰 HTTP 客戶端。你從不直接解析模型回應。SDK 處理這兩者。

Harness 是中圈。

它管理 Agent 註冊、根據 URL 路徑路由身份、處理跨呼叫的 session 持久化、session 增長時的上下文壓縮、role 和 skill 的發現、模型選擇優先順序，以及供應商中立的 ModelClient trait。
這讓你可以將 Anthropic 換成 OpenAI 或本機的 Ollama 實例，而不需修改 handler 程式碼。
Harness 是讓你的 Agent 邏輯能在不同供應商和目標之間重複使用的關鍵。
它也是所有在生產環境中會出問題的地方——session 狀態、上下文溢出、供應商故障、並發請求排序——的處理中心。

執行目標是內圈。

本機檔案系統、CI checkout、指向 Daytona 或 E2B 的 HttpSessionEnv、Cloudflare Worker 邊界。
Harness 不在乎你使用哪一個。你的 handler 也不在乎。它們呼叫 session.shell() 和 session.write()，Harness 會將這些轉換為底層目標所需的操作。
這個分離就是重點。當 E2B 發布新 API 版本時，你更新 connector，而不是你的 Agent 邏輯。
當 Anthropic 推出 claude-opus-4-7 時，你更新 runtime.json，而不是你的 handler。外圈保持乾淨，因為中圈吸收了所有變動。

Runtime 設定：控制模型層的檔案

在撰寫任何 handler 之前，你需要在工作目錄中有一個 runtime.json。

將它放在 .agentic-harness/config.json 或工作目錄根目錄的 agentic-harness.json。load_workspace_context() 會自動讀取它。

執行時的模型選擇遵循以下優先順序：

PromptOptions::model(...)：每次呼叫的覆寫
所選 role 的 model 元資料：每個 role 的預設值
runtime 設定中的 defaultModel：工作目錄預設值

要理解的重點：模型 ID 必須先註冊才能使用。openaiCompatibleModels 是 Harness 用來連接內建 chat-completions 客戶端的列表。如果你的模型不在該列表中，你會在啟動時得到一個明確的錯誤，而不是在 session 中途遇到令人困惑的失敗。

對於 OpenAI 相容的閘道器，設定看起來相同。將 baseUrl 指向你的閘道器：

永遠不要將 API 金鑰直接寫入 runtime.json。使用 apiKeyEnv 並將實際金鑰保留在環境變數中。
Harness 在請求時讀取環境變數，而不是在啟動時——這意味著你可以在不重啟伺服器的情況下輪換金鑰。

Agent 身份是一個 URL 路徑，而不是註冊表查詢

這是我第一個感到驚訝的設計決策。現在我認為它是正確的。

沒有 Agent ID 系統。沒有註冊表鍵值。沒有你自己產生的 UUID。你的 Agent 的身份是 POST /agents/<name>/<id>。

Harness 在該 URL 背後處理所有 session 狀態簿記。
這個方法可行的原因：每個系統中的每個呼叫者都知道如何從上下文建構一個有意義的 ID。一個 PR 號碼、一個 run ID、一個結合時間戳和任務名稱的值、一個使用者代號。
你不需要一個 session 建立端點。你不需要單獨儲存 session ID。URL 就是 session。

Rust 端的 Agent handler 呼叫 ctx.id() 來取得呼叫者提供的任何 ID：

Session：有狀態的執行上下文

一個 session 不僅僅是一個對話線程。它是 Agent 呼叫的完整執行上下文。

它包含：

與模型的訊息歷史
工作目錄檔案存取（讀取、寫入、編輯、grep、glob、stat、readdir）
具有 cwd 和 env 控制的 shell 執行
工具註冊（MCP 伺服器、自訂工具）
分配的 role 及其系統提示覆蓋
壓縮預算和歷史水位線

你可以透過 ctx.session_with_id() 並傳入任何有意義的 ID 來取得 session：

當你使用相同 ID 時，session 會跨 HTTP 呼叫持久化。用相同的 session ID 呼叫同一個 Agent 端點三次，模型會將三次交換視為一個連續的對話。
歷史會自動累積。你不需要管理它。
這就是讓多步驟工作流程成為可能的原因，而無需你自己管理狀態。你持續呼叫 session.prompt()，Harness 處理其他一切。

當你需要將大量上下文與提示一起傳遞時，讀取檔案並將內容內嵌格式化：

Session 管理 token 計數，這樣你就不會意外地在對話中途溢出上下文視窗。當你接近預算時，壓縮會觸發。更多內容在後面的章節。

Task：專注的子 Session，保持父 Session 乾淨

這是我希望自己第一天就理解的基本概念。它是讓 Agent 在長時間任務中保持連貫，與讓 Agent 在半途開始幻覺的關鍵差異。
Task 是一個一次性子 session。全新的歷史。共享的工作目錄。將結果回傳給父 session。父 session 的歷史永遠不會看到 task 的任何中間推理過程。

研究 task 在隔離環境中執行。它的整個推理鏈。
模型對程式碼的每一個中間觀察，每一個「等等，讓我也檢查這個檔案」的過程，都留在 task 內部。
父 session 只得到一個乾淨的摘要。這就是它看到的一切。為什麼這在實務上很重要：當你在一個長時間運行的 session 中直接進行探索性分析時，歷史會充滿中間工具呼叫、部分答案，以及模型對不再相關的事物的推理。
模型會在不該錨定的時候錨定在這些雜訊上。壓縮最終會觸發，並丟失你實際需要的上下文。Task 就是外科手術式的解決方案。

規則：如果子問題有明確的 deliverables，且不需要父 session 的對話歷史就能完成，就把它做成 task。「做成 task」的門檻比你想象的要低。

對於跨程式碼庫的平行分析：使用製圖模式（cartographer pattern），將 task 分散出去並收集結果：

每個 task 都是乾淨的。每個 task 只專注於一個目錄。父 session 收集結果並撰寫最終文件。

如果你有 12 個模組，你就執行 12 個專注的 task，每個 task 從零開始，沒有其他 task 的包袱。

Role 和 Skill：無需重新編譯即可塑造行為

Role 存放在 .agentic-harness/roles/。Skill 存放在 .agents/skills/。兩者都會在 Harness 啟動時自動發現。
Role 是作用於單次呼叫的系統提示覆蓋。在呼叫時應用，呼叫後丟棄。它們不會持久化到訊息歷史中，也不會跨呼叫累積。

優先順序鏈：呼叫 role > session role > agent role > 無 role。

模型 frontmatter 是可選的，但很有用。它可以讓你將特定 role 路由到特定模型。
你的解釋者 role 在 claude-sonnet-4-6 上運行，以獲得速度和成本效益。你的安全審計員在 claude-opus-4-7 上運行，以獲得深度。你在 role 檔案中設定一次，之後就不用再考慮。
Skill 是模型在 session 開始時讀取的行為描述檔案。
它們是 .agents/skills/ 中的 Markdown 檔案。Harness 會自動找到它們。你不需要在任何地方註冊。

實際用途：一個與你的程式碼庫並存的技能庫，描述你的工作方式。提交訊息格式、偏好的函式庫、遷移命名慣例、API 設計模式、測試要求。

模型在每次 session 前讀取這個。你編輯 Markdown。行為在下一次執行時更新。無需重新編譯。

模型讀取這個。它會寫出符合你慣例的提交。你不需要每次 session 都提醒它。你只需要維護一個檔案。

編碼 Agent 迴圈的完整細節

編碼 Agent 迴圈是 CLI 圍繞的主要使用案例。如果你設定錯誤，它也是最容易出問題的地方。

包含所有重要選項的完整指令：

每個旗標的作用及其重要性：

--workspace . 設定根目錄。所有檔案操作都在此沙盒化。Agent 無法讀取或寫入此路徑之外的內容，這在 Harness 層級強制執行——而不是依賴模型自我限制。
--llm auto 從 runtime 設定中的 defaultModel 選擇模型。對於需要深度推理的複雜任務使用 --llm anthropic/claude-opus-4-7，或對於更快的迭代使用 --llm anthropic/claude-sonnet-4-6。
--deny-path 是一個硬性封鎖。它以前綴方式匹配，所以 --deny-path config/ 涵蓋 config/ 下的所有內容。在第一次執行前審計你的工作目錄，並列舉所有包含機密或生產設定的路徑——不僅僅是 .env。
--approve-dependencies 允許修改 Cargo.toml 而無需人工批准步驟。如果你想在每個新 crate 加入前審查它，請省略此選項。
--commit 自動暫存所有變更，並在成功執行結束時使用你提供的訊息提交。沒有這個旗標，變更會以未暫存的修改形式留下，供你審查。
--pr 從提交開啟一個 pull request。需要在執行前有乾淨的 git 狀態和一個真實的分支，而不是 detached HEAD。

迴圈本身：檢查 → 簡報 → LLM + 工具 → 編輯 + 測試 → 提交 · PR。

檢查：讀取工作目錄結構，載入 skill 和 role，識別與提示最相關的檔案。
在觸碰任何程式碼之前，將其理解寫入 coding-brief.md。
簡報：模型承諾一個計劃。你可以在執行過程中讀取 .agentic-harness/runs/<id>/coding-brief.md 來查看它決定了什麼。
如果簡報看起來不對，終止執行。用更清晰的提示重新開始，比讓 Agent 執行一個糟糕的計劃更划算。
LLM + 工具：編輯-測試迴圈。模型進行變更，執行測試套件，讀取輸出，進行更多變更。迭代直到測試通過、達到迭代上限、或模型認為任務完成。

提交 · PR：暫存、提交、推送、開啟帶有 diff 的 PR。

每次執行會將六個工件寫入 .agentic-harness/runs/<id>/：

coding-brief.md：Agent 在撰寫任何程式碼前承諾的計劃
summary.md：人類可讀的說明，記錄了做了什麼、嘗試了什麼以及原因
run.json：結構化元資料：使用的模型、總持續時間、輸入/輸出 token 計數、迭代次數、最終退出狀態
events.jsonl：每個工具呼叫的完整順序，包含完整的輸入和輸出，用於除錯問題
diff.patch：所有檔案變更的完整 diff
checks.json：決定成功或失敗的最終測試和 lint 結果

要記住的提示

將這些視為結構化日誌，而不是短暫的輸出。對於任何需要能夠重現的任務，我會將執行工件提交到 repo。
僅 run.json（約 2KB）就能告訴你模型、token 成本以及是否成功。當你需要除錯一個糟糕的執行時，events.jsonl 會告訴你 Agent 做了什麼以及順序。

對於 CI，模式是：

HttpSessionEnv：在本機執行二進位檔，在遠端執行操作

這是我花了最長時間才完全理解的能力。現在我幾乎在每個涉及基礎設施的任務上都使用它。
Agent 二進位檔在你的機器或 CI 中執行。檔案系統和 shell 操作在遠端沙盒內執行。
Agent 不知道也不在乎它處於哪個環境。

使用 agentic_harness::HttpSessionEnv;

線路協定是基於 HTTP 的 JSON。每個操作：

exec
read
write
edit
grep
glob
stat
readdir
mkdir
rm 都有定義的請求/回應格式。

任何實作此協定的沙盒都可以作為 HttpSessionEnv 目標。

要連接一個命名的沙盒：

內建的 connector 處理 Vercel Sandbox、Daytona 和 E2B 的認證和生命週期樣板：

我最常使用這個的具體案例：在乾淨的 Linux 環境中重現 CI 失敗。
Agent 在確切的失敗提交 hash 處複製 repo，執行確切的失敗測試指令，讀取完整輸出，診斷失敗原因，並撰寫報告。
我閱讀報告。我從未碰過我的本機機器。沙盒在 session 結束時被丟棄。

沒有人警告你的效能問題：每次透過 HttpSessionEnv 的 shell 呼叫都是一次網路往返。緊湊的迴圈（編輯、測試、檢查輸出、編輯）會快速累積延遲。

一個 40 次迭代的迴圈在本機需要 5 秒，但對遠端沙盒可能需要幾分鐘，如果每次迭代進行三次獨立的 shell 呼叫。

解決方案：將 shell 工作批次化為腳本。

每次迭代一次呼叫，而不是三次。一次寫入腳本，重複執行。在 40 次迭代的迴圈中，延遲差異是真實的。

建構目標：同一程式碼庫，三種部署形態

Native 是預設值。一個二進位檔。一個 manifest。目標機器上不需要其他東西。可以在任何能執行原生 Linux 二進位檔的地方運行。

Node 適用於需要 Node 入口點的主機平台。建構會產生 server.mjs，它將原生 Rust 二進位檔作為子程序啟動，並將 HTTP 代理給它。Agent 邏輯仍然以 Rust 運行。Node 層是一個 30 行的 HTTP shim。

Cloudflare 適用於邊緣部署。

建構會產生一個 Worker 邊界檔案，並連結一個 Worker 相容的應用程式 adapter。
Handler 透過 WASM JSON ABI 編譯為 WASM。
Durable Object 綁定透過 Cloudflare KV 處理 session 持久化。

關於 Cloudflare 的重要限制：Workers 不支援長時間運行的 shell 指令。它們沒有真正的檔案系統。

它們不支援 cargo 或任何建構工具。--target cloudflare 適用於 webhook 處理、路由元資料、小型控制端點和 Durable Object 路由，而不是編碼工作。

對於任何需要執行 cargo test 的任務，委派給原生程序或遠端沙盒。

實務決策矩陣：

將 Agent 作為其他服務呼叫的 API 發布 → native 搭配 nginx 或受管平台
託管在 Railway、Render 或預期 Node 的平台 → node
Webhook 接收、輕量路由、Durable Object 狀態管理 → cloudflare
其他所有情況 → native

Schema 引導的輸出：來自模型回應的類型化 Rust 結構體

要求模型回傳 JSON 並希望它做到，只是解決了一半的問題。

讓 Harness 提取、驗證並將其反序列化為你的 Rust 結構體，才是完整的解決方案。

模型可以在同一個回應中回傳推理散文以及類型化 payload。Harness 提取 ---RESULT_START--- 和 ---RESULT_END--- 標記之間的結果區塊。你得到一個 Rust 結構體。從模型輸出到 handler 邏輯的編譯時型別安全。

Schema 做兩件事：它告訴模型要產出什麼形狀，並在反序列化之前給 Harness 一個驗證依據。

如果模型回傳不符合 schema 的內容，你會得到 PromptError::SchemaValidationFailed，而不是在三個呼叫點之後存取缺少的欄位時發生 panic。

MCP 工具：跳出沙盒

當 Agent 需要檔案和 shell 之外的能力時，connect_mcp 就是逃生艙。

Agent 獲得 MCP 伺服器的完整工具集。不需要撰寫工具定義。描述來自伺服器。模型根據這些描述決定何時呼叫哪個工具。

你可以將多個 MCP 伺服器連接到一個 session：

模型根據描述呼叫工具。一個模糊的描述如「搜尋 sentry」會導致不一致的呼叫。
一個描述如「在回答任何關於錯誤、事件或生產問題的問題之前呼叫此工具」會被可靠地呼叫。
如果你控制 MCP 伺服器，請撰寫規範性的描述：告訴模型何時呼叫，而不僅僅是它回傳什麼。

Connector：生成 Adapter 而非手寫

與其手寫 adapter 程式碼來對抗不熟悉的 API，不如將 connector recipe 傳送給你的編碼 Agent：

Connector recipe 是沙盒 API 及其需要滿足的 SessionEnv 合約的結構化描述。
編碼 Agent 讀取它，撰寫 Rust adapter 模組，處理認證，包裝供應商生命週期，並將其公開為 HttpSessionEnv。
你審查 diff。你合併它。Adapter 存在於你的專案中。它現在是你的程式碼。

我使用這個方法在大約 20 分鐘內（包括完整的審查週期）連接了 Daytona。Agent 在第一次嘗試就正確處理了認證標頭格式。

如果根據 Daytona 文件從頭開始撰寫 adapter，可能需要大半個下午，並且至少會對重新整理 token 流程做出兩個錯誤假設。

一旦 connector 生成：

自動壓縮：處理長時間 Session 而不遺失上下文

長時間運行的 session 會累積歷史。

最終它們會溢出模型的上下文視窗。

Harness 會自動處理這個問題，但你需要正確設定它，否則你會在完全錯誤的時刻遺失上下文。

context_window_tokens 是 session 的總預算。

reserve_tokens 是你為模型回應保留的部分。歷史的有效限制是 context_window_tokens - reserve_tokens。
keep_recent_messages 是尾部始終保持原樣、不受壓縮影響的訊息數量。

當歷史超過預算時，Harness 要求模型總結系統提示和保留尾部之間的所有內容。

該摘要取代中間部分。尾部訊息保持不變。壓縮後的 session 變小，下一次呼叫適合預算。

取捨是真實的：摘要會損失精確度。50 條訊息前的一個具體決策：「我們選擇 authlib 因為它是唯一支援 PKCE 且能與 axum 中介軟體模型搭配的函式庫」，在摘要中可能變成「我們為了認證選擇了 authlib」。

如果該精確度對 session 後續的決策至關重要，請明確儲存它：

將決策寫入檔案。檔案在壓縮中存活。模型可以按需重新讀取它們。如果工作目錄承載了資訊，歷史就不需要攜帶所有內容。
執行 agentic-harness doctor 來查看你的模型實際報告的上下文視窗。將 context_window_tokens 設定為該值的 80-90%。
Token 計數器在模型端並非完全準確，如果你處於 99% 的臨界值，一次大型檔案讀取可能會將你推過限制。

需要注意的事項

Session 歷史污染

問題：在長時間 session 內進行探索性分析會用探索階段的雜訊污染後續提示
解決方案：使用 task。Task 歷史永遠不會觸及父 session。「做成 task」的門檻比你想象的要低

Role 優先順序意外

問題：呼叫層級的 role 遮蔽了 session role。模型行為與預期不同，你不知道原因
解決方案：Session role 設定身份。呼叫 role 縮小焦點。它們是疊加的——呼叫 role 應該增加，不應該取消

--deny-path 漏洞

問題：你封鎖了 .env。你的機密也存在於 .env.local 和 config/staging.yaml。Agent 讀取了其中一個
解決方案：封鎖前綴，而不是檔名。--deny-path config/ 涵蓋其下的所有內容

CI 中的 Detached HEAD

問題：Agent 編輯了，測試通過了，提交失敗了——因為沒有分支可以提交
解決方案：在呼叫 Harness 之前執行 git checkout -b agent-run-$RUN_ID

HttpSessionEnv 在緊湊迴圈中的延遲

問題：40 次迭代，每次三次 shell 呼叫，等於幾分鐘的純網路延遲
解決方案：撰寫 agent-check.sh 在一次呼叫中完成所有操作。每次迭代一次呼叫

上下文預算低估

問題：壓縮在任務中途觸發。模型失去計劃並開始根據摘要即興發揮
解決方案：執行 agentic-harness doctor 取得實際視窗。將預算設定為 80-90%

Handler 註冊後才載入 Runtime 設定

問題：handler 在 load_workspace_context() 之前執行。沒有註冊模型。錯誤訊息看起來完全不像設定問題。
修復：在 app() 中，務必在連接任何 Agent 之前先呼叫 load_workspace_context()。

--llm auto 在不同執行之間會變動

問題：defaultModel 會被更新。相隔六個月的兩次執行無法比較。你無法重現第一次的結果。
修復：在 runtime.json 中固定模型版本，任何需要可重現性的任務都這麼做。

刪除執行產出物

問題：你在 .gitignore 規則中清除了 runs/ 目錄。三週後你需要重現某個回歸問題，但所有資料都不見了。
修復：對於任何需要重現的任務，提交執行產出物。run.json 只有 2KB，保留它。

我會改變的做法

在碰任何東西之前，先執行 agentic-harness guide。
在撰寫 handler 邏輯之前，先撰寫 session 層級的測試。
對於任何有子交付項目的任務，都使用 tasks。
從第一次正式執行就固定模型版本。
將決策儲存在檔案中，而不是 session 歷史中。
從一開始使用遠端沙箱時，就批次處理 shell 操作。

結論

大多數 Agent 框架只是 API 呼叫的包裝器。而這是一個執行環境。

包裝器解決的是「讓模型回應」。執行環境解決的是「將 Agent 部署到生產環境，並在模型改變、沙箱改變、程式碼改變、session 執行兩小時後上下文視窗溢出時，仍然保持正常運作」。

三層架構

你的程式碼
控制框架 (harness)
執行目標

正是讓這一切成為可能。你撰寫 handler。控制框架吸收所有營運複雜性。執行目標則是一個設定選項。

不會改變的東西：handler 邏輯、session 結構、任務模式、角色定義、技能檔案。會改變的東西：模型、提供者、沙箱廠商、部署目標。

這個架構的設計原則是：會改變的東西永遠不會觸及不會改變的東西。

這就是賭注。而且是正確的賭注。

希望你喜歡閱讀這篇文章，並了解我如何為 Agent 以及一般情況進行建構 ❣️

免責聲明

本文由作者研究與撰寫，並由 Minimax-M2.7 編輯。縮圖取自 Pinterest。

Harrison Chase「記憶應該是開放的！」—

[https://x.com/hwchase17/status/2046308913939919232Harrison](https://x.com/hwchase17/status/2046308913939919232Harrison)

Chase：「你的控制框架，你的記憶」—

[https://www.langchain.com/blog/your-harness-your-memory](https://www.langchain.com/blog/your-harness-your-memory)

Vivek Trivedi：「Agent 控制框架的解剖」—

[https://www.langchain.com/blog/the-anatomy-of-an-agent-harness](https://www.langchain.com/blog/the-anatomy-of-an-agent-harness)