不只是模型：Agent 真正需要的是「執行外殼」

AWS 推出的開源 Strands Harness，瞄準的是許多團隊都會遇到的落差：本機上看似有效的 AI Agent Demo，要變成可部署的應用程式，往往還得另外處理工具呼叫、狀態、記憶、上下文、權限與部署設定。

Strands Harness 建構在 Strands 生態系之上，提供一套已組裝好的通用型 Agent 基礎。開發者可先在本機啟動，再部署到偏好的供應商；AWS 對它的定位並非 AWS 專屬執行環境。7

這個「外殼」包住模型以外的關鍵能力，包括檔案操作、Shell 執行、網頁工具、上下文管理、持久工作階段與記憶、提示快取，以及多 Agent 委派。5 換句話說，團隊可以盡量維持相同的工具與狀態模型，將重心放在 Agent 任務設計，而不是每換一個模型供應商或執行環境就重寫 Agent 迴圈。

MCP 與多模型：整合外部工具，但也擴大信任邊界

Strands 支援 Model Context Protocol（MCP），這是讓 Agent 連接外部託管工具的開放標準。透過 MCP，Agent 可使用經核准的內部系統或第三方服務，不必將每個整合都硬寫進 Agent 本體。15

底層 Strands SDK 採可插拔、模型無關的供應商模式，支援 Amazon Bedrock、Anthropic API、OpenAI，以及 Ollama 等開源或本機模型選項。15 對希望避免被單一模型供應商綁定的團隊而言，這提供了架構彈性；但更換模型或執行階段後，仍應重新驗證回應品質、延遲與工具使用可靠性。

MCP 也不等於「接上就安全」。MCP 伺服器與外部工具本身就是信任邊界的一部分，應納入權限、審核與稽核設計。

從工作站到雲端：可攜，不代表一鍵上線

Strands Harness 的流程主張相當直接：先在本機製作 Agent 原型，整理成 Python 或 TypeScript 專案，將它當一般軟體測試，再依目標環境加入部署設定。相關報導指出，其部署指引涵蓋 AWS、Google Cloud、Azure、Cloudflare、Modal 與本機環境。6

不過，能部署不等於已具備正式環境的可靠性。團隊仍應自行落實：

• 僅授予 Agent 完成任務必要的檔案、Shell、網路與資料存取權限。
• 將密鑰與供應商憑證置於提示詞與原始碼之外。
• 對基礎設施變更、傳送訊息、修改正式資料等高影響操作，採用人工核准或沙箱隔離。
• 在正式使用前加入日誌、監控、測試與貼近實際工作負載的評測。

Harness 能降低整合成本，但無法代替組織決定可接受的風險、存取控制與可靠性門檻。

快速開始：用 Strands CLI 建立專案

官方快速入門要求 CLI 使用 Node.js 20 以上版本；Python 專案則需要 Python 3.10 以上。CLI 可引導開發者選擇 Python 或 TypeScript，並挑選模型供應商。2

# 安裝互動式 CLI
npm install -g @strands-agents/cli

# 啟動設定助理
strands

Python 專案的文件安裝方式如下：

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install strands-harness

TypeScript 則先初始化 Node.js 專案，再依最新快速入門安裝 @strands-agents/harness。2

實務上，可透過互動式設定先定義 Agent 角色、允許使用的工具、模型供應商與記憶需求，接著在本機執行；完成後，將產生或設定好的專案納入版本控制與測試，作為後續部署的產物。CLI 的產生與匯出流程可能隨版本變動，因此不宜假設固定指令；部署前應先查看 strands --help 與最新快速入門文件。2

模型可替換，供應商設定仍不可省略

Strands 雖然支援跨供應商，但可攜性不會消除各家平台的存取要求。Harness SDK 預設使用 Amazon Bedrock，因此必須設定 AWS 憑證，並為所選模型開啟存取權限。12 Anthropic、OpenAI 或其他供應商同樣有各自的憑證、端點、計價與政策控管需求。

若採用本機或開放權重模型，Strands 相關的 benchmark-harness 文件提到可透過 LiteLLM、vLLM 等介面與執行環境使用模型。18 這有助將 Agent 的操作設計與單一模型品牌分離，但模型切換後的品質、成本與失敗模式仍必須實測。

AWS 的成本說法：值得驗證，不是採購保證

AWS 表示，在六項基準中，若以相同的 Claude 或 GPT 模型執行，Strands Harness 的成本比其他 harness 低 28%，且準確度大致相當。7 另有報導將其描述為相較 Claude Code 與 Codex 約低 45%，但納入 DeepSeek Harness 後差距縮小為 28%。比較對象不同，這些數字不應被混為單一、普遍適用的節省幅度。5

這些比較之所以有參考價值，是因為上下文建構、工具輸出處理、協調與驗證機制，確實可能同時影響 token 用量與任務結果。一篇研究立場論文也指出，在長時程任務、模型能力相近的條件下，Agent 執行 harness 對效能差異的影響，可能大於模型本身。17

但上述基準仍是 AWS 報告的結果。《The Register》指出，發布時的比較將通用型 harness 與程式設計 Agent 相比，並形容這是 AWS 在「自己批改自己的作業」。3 這不代表結果必然錯誤，而是表示它不能單獨證明 Strands 在每一種 Agent 工作負載下都更便宜或更好。

較公平的內部評估，應固定模型、提示詞、任務集、工具、權限、重試策略、延遲目標與成本算法。總成本也不只包含輸入與輸出 token，還可能包括工具呼叫、儲存、基礎設施、人工作業、失敗重跑，以及錯誤操作的代價。

適合哪些團隊？

對希望快速取得具備真實工具存取與有狀態行為的通用型 Agent 起點，同時保留模型與部署目標選擇權的開發者，Strands Harness 特別值得嘗試。當本機概念驗證原本得大幅重寫，才能補上記憶、工具整合、上下文控制或雲端部署路徑時，它的價值會更明顯。57

比較務實的做法是：從範圍狹小、已沙箱化的 Agent 開始，只開放真正必要的工具，並針對代表性任務衡量成功率、延遲與全成本。AWS 的 28% 成本主張可作為待驗證的假設，而不是正式導入前的預測。

不只是模型：Agent 真正需要的是「執行外殼」

AWS 推出的開源 Strands Harness，瞄準的是許多團隊都會遇到的落差：本機上看似有效的 AI Agent Demo，要變成可部署的應用程式，往往還得另外處理工具呼叫、狀態、記憶、上下文、權限與部署設定。

Strands Harness 建構在 Strands 生態系之上，提供一套已組裝好的通用型 Agent 基礎。開發者可先在本機啟動，再部署到偏好的供應商；AWS 對它的定位並非 AWS 專屬執行環境。7

這個「外殼」包住模型以外的關鍵能力，包括檔案操作、Shell 執行、網頁工具、上下文管理、持久工作階段與記憶、提示快取，以及多 Agent 委派。5 換句話說，團隊可以盡量維持相同的工具與狀態模型，將重心放在 Agent 任務設計，而不是每換一個模型供應商或執行環境就重寫 Agent 迴圈。

MCP 與多模型：整合外部工具，但也擴大信任邊界

Strands 支援 Model Context Protocol（MCP），這是讓 Agent 連接外部託管工具的開放標準。透過 MCP，Agent 可使用經核准的內部系統或第三方服務，不必將每個整合都硬寫進 Agent 本體。15

底層 Strands SDK 採可插拔、模型無關的供應商模式，支援 Amazon Bedrock、Anthropic API、OpenAI，以及 Ollama 等開源或本機模型選項。15 對希望避免被單一模型供應商綁定的團隊而言，這提供了架構彈性；但更換模型或執行階段後，仍應重新驗證回應品質、延遲與工具使用可靠性。

MCP 也不等於「接上就安全」。MCP 伺服器與外部工具本身就是信任邊界的一部分，應納入權限、審核與稽核設計。

從工作站到雲端：可攜，不代表一鍵上線

Strands Harness 的流程主張相當直接：先在本機製作 Agent 原型，整理成 Python 或 TypeScript 專案，將它當一般軟體測試，再依目標環境加入部署設定。相關報導指出，其部署指引涵蓋 AWS、Google Cloud、Azure、Cloudflare、Modal 與本機環境。6

不過，能部署不等於已具備正式環境的可靠性。團隊仍應自行落實：

• 僅授予 Agent 完成任務必要的檔案、Shell、網路與資料存取權限。
• 將密鑰與供應商憑證置於提示詞與原始碼之外。
• 對基礎設施變更、傳送訊息、修改正式資料等高影響操作，採用人工核准或沙箱隔離。
• 在正式使用前加入日誌、監控、測試與貼近實際工作負載的評測。

Harness 能降低整合成本，但無法代替組織決定可接受的風險、存取控制與可靠性門檻。

快速開始：用 Strands CLI 建立專案

官方快速入門要求 CLI 使用 Node.js 20 以上版本；Python 專案則需要 Python 3.10 以上。CLI 可引導開發者選擇 Python 或 TypeScript，並挑選模型供應商。2

# 安裝互動式 CLI
npm install -g @strands-agents/cli

# 啟動設定助理
strands

Python 專案的文件安裝方式如下：

python -m venv .venv
source .venv/bin/activate  # Windows: .venv\Scripts\activate
pip install strands-harness

TypeScript 則先初始化 Node.js 專案，再依最新快速入門安裝 @strands-agents/harness。2

實務上，可透過互動式設定先定義 Agent 角色、允許使用的工具、模型供應商與記憶需求，接著在本機執行；完成後，將產生或設定好的專案納入版本控制與測試，作為後續部署的產物。CLI 的產生與匯出流程可能隨版本變動，因此不宜假設固定指令；部署前應先查看 strands --help 與最新快速入門文件。2

模型可替換，供應商設定仍不可省略

Strands 雖然支援跨供應商，但可攜性不會消除各家平台的存取要求。Harness SDK 預設使用 Amazon Bedrock，因此必須設定 AWS 憑證，並為所選模型開啟存取權限。12 Anthropic、OpenAI 或其他供應商同樣有各自的憑證、端點、計價與政策控管需求。

若採用本機或開放權重模型，Strands 相關的 benchmark-harness 文件提到可透過 LiteLLM、vLLM 等介面與執行環境使用模型。18 這有助將 Agent 的操作設計與單一模型品牌分離，但模型切換後的品質、成本與失敗模式仍必須實測。

AWS 的成本說法：值得驗證，不是採購保證

AWS 表示，在六項基準中，若以相同的 Claude 或 GPT 模型執行，Strands Harness 的成本比其他 harness 低 28%，且準確度大致相當。7 另有報導將其描述為相較 Claude Code 與 Codex 約低 45%，但納入 DeepSeek Harness 後差距縮小為 28%。比較對象不同，這些數字不應被混為單一、普遍適用的節省幅度。5

這些比較之所以有參考價值，是因為上下文建構、工具輸出處理、協調與驗證機制，確實可能同時影響 token 用量與任務結果。一篇研究立場論文也指出，在長時程任務、模型能力相近的條件下，Agent 執行 harness 對效能差異的影響，可能大於模型本身。17

但上述基準仍是 AWS 報告的結果。《The Register》指出，發布時的比較將通用型 harness 與程式設計 Agent 相比，並形容這是 AWS 在「自己批改自己的作業」。3 這不代表結果必然錯誤，而是表示它不能單獨證明 Strands 在每一種 Agent 工作負載下都更便宜或更好。

較公平的內部評估，應固定模型、提示詞、任務集、工具、權限、重試策略、延遲目標與成本算法。總成本也不只包含輸入與輸出 token，還可能包括工具呼叫、儲存、基礎設施、人工作業、失敗重跑，以及錯誤操作的代價。

適合哪些團隊？

對希望快速取得具備真實工具存取與有狀態行為的通用型 Agent 起點，同時保留模型與部署目標選擇權的開發者，Strands Harness 特別值得嘗試。當本機概念驗證原本得大幅重寫，才能補上記憶、工具整合、上下文控制或雲端部署路徑時，它的價值會更明顯。57

比較務實的做法是：從範圍狹小、已沙箱化的 Agent 開始，只開放真正必要的工具，並針對代表性任務衡量成功率、延遲與全成本。AWS 的 28% 成本主張可作為待驗證的假設，而不是正式導入前的預測。