LangSmith Context Hub 是用來建立、版本化與部署 Agent context 的服務。你可以把整套 Agent 指令、工具說明和參考檔案放成一個 Agent，也能把單一任務整理成可被多個 Agent 重用的 Skill。
最實用的工作流是：用 AGENTS.md 或 SKILL.md 建立內容，每次儲存產生一個 commit，在 staging 測試，確認後晉升到 production，應用程式只拉取核准版本。這能避免團隊修改一句政策後，所有線上 Agent 立即一起改變行為。
要先釐清一個常見誤解：Context Hub 適合管理長期、可審核的指令與知識；個別對話、工作階段狀態和使用者偏好屬於執行期記憶，應放在 LangGraph store 或自己的資料庫。
Agent、Skill 和 linked repository 差在哪？
Agent 是最上層的 context bundle，入口通常是 AGENTS.md。它可以包含角色、工作流程、工具規則、輸出標準與其他檔案，適合描述一個完整 Agent 如何工作。
Skill 是可重用的任務知識，入口是 SKILL.md。例如客服退款判斷、品牌文案審查或資料庫遷移步驟，都可以做成 Skill，讓多個 Agent 引用。
Linked repository 讓 Agent 或 Skill 引用其他 Context Hub 資源。官方文件列出的連結類型包括 file、agent 和 skill。未固定版本的連結會跟著來源更新，適合開發期快速迭代；正式環境要釘住 commit 或核准標籤，否則上游修改可能改變多個 Agent。
若你正在比較不同 Skill 規格，可參考AI Agent Skills 工作流指南與Claude Skills 教學。
在介面建立第一個 Context
- 進入 LangSmith 的 Context Hub。
- 若要建立完整 Agent，選擇 Agent 並加入
AGENTS.md；若是單一可重用流程，選擇 Skill 並加入SKILL.md。 - 寫清楚目標、可用工具、輸入輸出格式、拒絕條件和需要人工確認的步驟。
- 加入少量能區分正確與錯誤行為的 examples 或參考文件。
- 儲存變更。Context Hub 會為每次儲存建立 commit，可比較、回復和加標籤。
- 在 staging 綁定測試應用，通過評估後再晉升到 production。
目前官方文件提供的環境晉升名稱是 staging 與 production。舊稿常寫成 dev、staging、prod 三個固定環境，容易讓人以為 Context Hub 預設就有三階段；開發版本可以用最新 commit 或團隊自訂流程管理，正式晉升則依官方標籤操作。
用 SDK 推送與拉取 Skill
官方文件要求 Python langsmith>=0.7.35 或 TypeScript langsmith>=0.5.23。以下示意把本機 Skill 推到 Hub，再拉取 production 版本；實際參數以你使用的 SDK 版本為準。
from langsmith import Client
from langsmith.schemas import FileEntry
client = Client()
client.push_skill(
"support-style",
files=[
FileEntry(
path="SKILL.md",
content="# Support style\nAnswer with verified policy and next steps.",
)
],
)
skill = client.pull_skill("support-style:production")建立完整 Agent 時，可使用 push_agent 與 pull_agent。部署程式應明確指定 :production 或特定 commit，測試環境則指定 :staging。若所有環境都拉取未固定的最新版本，回復與問題追蹤會變得困難。
Context Hub 和 Agent 記憶差在哪？
| 資料類型 | 適合放哪裡 | 例子 |
|---|---|---|
| 長期指令與政策 | Context Hub | 品牌語氣、退款規則、工具操作限制 |
| 可重用任務知識 | Context Hub Skill | 報表檢查、客服分類、程式碼審查流程 |
| 單次對話狀態 | 執行期 state | 本輪工具結果、尚未完成的步驟 |
| 使用者長期偏好 | Store 或資料庫 | 語言、通知偏好、已授權資料來源 |
Context Hub 裡的 commit 適合稽核「Agent 當時被要求怎麼做」。執行期 store 則回答「這位使用者或這個工作階段發生過什麼」。兩者更新頻率、權限與刪除要求不同，混在同一份 AGENTS.md 會造成個資、版本與容量問題。
使用 LangChain 的託管 Agent 團隊，可搭配Managed Deep Agents Runtime 指南規劃執行層；多人共同維護時，也可參考Workspace Agents 企業治理建立角色分工。
Production 部署應做哪些檢查？
第一步是建立最小評估集。每次 Context 變更至少測正常案例、邊界案例、拒絕情境與工具權限。只看文字是否流暢，無法發現政策遺漏或工具誤用。
第二步是保存可追蹤版本。每次執行應記錄 Agent commit、引用 Skill commit、模型版本與工具設定。出現回歸時，才能判斷問題來自 context、模型或程式碼。
第三步是分離編輯與晉升權限。領域專家可以提出政策修改，負責人審查差異與評估結果後再把版本晉升到 production。高風險 Agent 還應要求第二位核准者。
第四步是控制 linked repository。正式版本若引用未固定的 Skill，上游更新可能繞過原本的審查。部署前列出所有連結及其 commit，確保結果可重現。
什麼情況不需要 Context Hub？
只有一個簡單 prompt、由單人維護、沒有 staging 與稽核需求的原型，可以先留在程式碼庫。Context Hub 的價值會在三種情況變明顯：多個 Agent 重用相同 Skill、非工程角色頻繁修改政策、線上行為需要版本回復與稽核。
團隊也不必把所有文件搬進去。大型知識庫更適合檢索系統，機密憑證留在 secrets manager，使用者資料放在有生命週期管理的資料庫。Context Hub 應保留真正會塑造 Agent 行為、需要版本治理的內容。
常見問題
Context Hub 可以取代 GitHub 嗎？
它專注於 Agent context 的版本、協作與部署，適合讓領域專家共同維護。應用程式碼、基礎設施與一般文件仍可留在 GitHub，兩者可搭配使用。
正式環境應拉取 latest 還是 production？
建議使用 production 標籤或固定 commit。latest 適合快速開發，線上服務需要可重現、可回復的版本。
使用者偏好應寫進 AGENTS.md 嗎？
不適合。AGENTS.md 是共享且可版本化的 Agent context；個人偏好與對話資料應存於有權限、保存期限與刪除機制的執行期 store 或資料庫。