TrueForge 對決 Claude Managed Agents：企業該用低成本換取更多控制權嗎？

TrueForge 是 TrueFoundry 開源的 AI 代理（agent）執行框架，更精確地說，是圍繞語言模型運作的「代理執行層」。它負責管理工具呼叫、上下文、子代理、程式碼執行、審批、工作階段、狀態與追蹤記錄。TrueForge 採用 MIT 授權，設計目標是在企業可控制的基礎設施上運作，而不是把執行環境綁定在單一模型供應商上。

因此，企業真正要問的不是 TrueForge 是否能全面取代 Claude Managed Agents，而是：企業是否願意接手更多代理技術堆疊，以換取模型彈性、資料控制權，以及在特定工作負載下可能更低的任務成本？

TrueForge 與 Claude Managed Agents 快速比較

比較面向	TrueForge	Claude Managed Agents
執行環境	開源代理框架，企業可檢視、修改與自行運作	由 Anthropic 託管的代理執行環境
模型選擇	模型中立，可搭配不同的商用或開放權重模型	以 Anthropic 的 Claude 模型為核心
部署方式	在企業自行控制的雲端、資料中心或其他基礎設施上運作	由 Anthropic 管理執行環境與沙盒基礎設施
維運責任	企業負責擴展、修補、資安設定、可觀測性與事故回應	供應商承擔大部分平台維運工作
計費方式	軟體本身免費，但仍需支付運算、推論、儲存、監控與工程人力成本	Claude 標準 Token 費用，加上每個作用中工作階段每小時 0.08 美元；部分工具可能另計費。

TrueForge 的差異主要在架構，而非單純換了一個模型。企業可以讓同一套執行框架連接不同模型端點，並自行決定執行環境、資料與控制措施的所在地。Claude Managed Agents 則提供更垂直整合的路徑：需要自行組裝的基礎設施較少，但對 Anthropic 平台與模型生態系的依賴也更高。

基準測試究竟說了什麼？

TrueFoundry 表示，該公司以 DevRev Enterprise-Bench 中 14 項一級與二級任務比較兩套框架。這些任務要求代理跨越企業系統工作、呼叫 MCP 伺服器，並整合多個來源的資訊後產生答案；TrueFoundry 表示，每種設定使用相同任務，且各設定執行三次。

公司公布的結果如下：

• 使用相同的 Opus 4.8 模型： TrueForge 與 Claude Managed Agents 各自完成約 14 項任務中的 11 項。TrueForge 平均每次執行成本約為 8.50 美元，Claude Managed Agents 約為 11.80 美元，前者低約 30%。
• TrueForge 搭配 GLM-5.2： TrueFoundry 表示完成量同樣約為 11／14 項，平均每次成本約 2.90 美元，相較 Claude Managed Agents 搭配 Opus 的設定低約 75%。
• 另一組模型比較： TrueFoundry 此前也公布過 10 項任務的 GLM-5.2 與 Opus 4.8 比較，任務分成基礎、困難與長上下文類別。不過這是公司自行設計與執行的測試，並非中立機構驗證。

這些數字可以用來理解 TrueFoundry 的測試結果，但不能直接視為所有企業都能取得的價格保證。首先，14 項任務的樣本規模有限；其次，「節省約 75%」的比較同時更換了執行框架與模型，因此無法單獨分辨成本差異究竟來自 TrueForge 的效率，還是來自以 GLM-5.2 取代 Opus 4.8。另有報導提醒，所謂總營運成本下降，未必已包含基礎設施、人力與其他企業級支出。

TrueForge 的成本論點如何成立？

TrueFoundry 的核心論點是，代理執行環境可以透過控制模型實際執行的工作量，以及讓模型選擇變得可配置，降低整體支出。潛在節省主要來自兩個方向：

1. 執行流程效率。 框架可以管理工作階段、工具、狀態與上下文，避免每一步都以未整理的方式重播完整互動歷史。TrueFoundry 的公開說明強調代理循環的行為，並在一項比較中表示其規劃步驟較少；但目前可取得的資料不足以獨立確認相關實作細節，也不足以證明這種效果適用於不同工作負載。
2. 模型路由。 企業可把需要高階推理能力的任務交給前沿模型，將範圍較窄、風險較低或數量較大的工作，路由至成本較低的模型，包括 GLM-5.2 等開放權重模型。這也是 TrueForge 搭配 GLM-5.2 時，報告節省幅度明顯擴大的主要原因。

這項區分對預算規劃十分重要。企業若要重現測試，應同時量測輸入與輸出 Token、上下文增長、工具呼叫次數、重試、延遲、模型託管費、GPU 或雲端運算成本，以及人工審核時間，而不是只看開源軟體的授權費。

目前公開證據支持「這是 TrueFoundry 所報告的基準測試結果」，但尚未證明相同百分比會套用到每一種代理、模型、任務或併發量。

部署與治理：控制權越大，責任也越重

自建部署會改變誰能控制代理的執行環境。使用 TrueForge 時，企業可以把執行框架放在自有或自行管理的基礎設施內，設定網路邊界，並決定提示內容、文件、工具輸出與追蹤記錄如何處理。這可能有助於處理資料落地位置與內部存取要求，但自建並不會自動帶來合規。

企業仍必須自行設計與執行存取控制、資料保存政策、稽核機制、模型治理，以及安全的工具權限。實際部署 TrueForge 時，客戶可能需要負責：

• 執行環境升級與安全修補；
• 可用性、擴展能力與容量規劃；
• 密鑰管理與身分系統整合；
• 沙盒隔離與連接器權限；
• 可觀測性、追蹤記錄保存與事故回應；
• 模型端點、GPU 容量與效能漂移。

託管服務則能移除其中大部分工作，縮短從原型到上線的時間。代價是企業對執行環境的控制較少，也會更依賴供應商的平台。對託管與自建代理的比較，業界通常會從合規、資料所有權、模型路由、營運能力與工作負載適配度來判斷，而不是只比較軟體價格。

哪些工作負載適合哪一種方式？

TrueForge 較適合以下情境：

• 需要嚴格的網路邊界或資料落地位置控制；
• 希望更換模型供應商，或使用開放權重模型；
• 需要自訂審批、稽核與可觀測性流程；
• 執行長時間、工具密集或高流量的代理任務；
• 已有平台工程、資安或 SRE 團隊，能夠維運整套堆疊。

Claude Managed Agents 較適合以下情境：

• 重視快速初始部署；
• 希望直接使用託管沙盒與執行環境；
• 不想承擔大量基礎設施管理工作；
• 工作負載標準化，沒有高度模型可攜性需求；
• 不希望額外建立值班、維運與事故回應能力。

自建並不代表一定比較便宜。在低流量或流量難以預測的情況下，託管服務可能更具經濟效益，因為供應商吸收閒置容量與大量平台人力成本。當使用量穩定、模型選擇能帶來明顯節省，且企業已有基礎設施能力時，自建才更可能展現成本優勢。

TrueFoundry 的創辦人、融資與早期採用者

TrueFoundry 於 2021 年由三名前 Meta 工程師創立：Nikunj Bajaj、Abhishek Choudhary 與 Anuraag Gutgutia。

公司宣布完成 1,900 萬美元 A 輪融資，由 Intel Capital 領投，Peak XV、Eniac Ventures 與 Jump Capital 參與，另有天使投資人加入。

TrueForge 被報導的早期正式生產採用者包括 NetApp、Automatiq，以及 TrueFoundry 內部的 Ask TFY 系統。這些案例顯示產品已有早期企業使用，但不等同於其可靠性已在廣泛、獨立的生產部署中獲得證明。

TrueForge 在代理市場的位置

TrueForge 位於「代理執行框架／執行環境」這一層，與底層模型，以及主要協助開發者撰寫代理邏輯的工具有所不同。

• Claude Managed Agents： 將 Anthropic 模型、託管執行與基礎設施整合在一起。優勢是部署路徑完整，取捨則是模型與執行環境的可攜性較低。
• TrueForge： 強調企業自有、模型中立的執行環境，並主打自建部署、模型路由與企業控制措施。
• DeepSeek 相關 Harness： 屬於開放模型與開放執行環境趨勢的一部分，但目前資料不足以對其與 TrueForge 進行嚴謹的功能逐項比較。
• OpenAI Codex CLI： 主要是面向開發者的程式碼代理與命令列工作流程，並非一般企業多工具業務代理所需的完整控制平面。
• LangChain Deep Agents： 更適合理解為用來建構規劃流程或子代理工作流的框架；它可以與生產級執行環境互補，而不是 TrueForge 的直接同類替代品。

給企業採購者的結論

TrueForge 最可信的產品主張，不是宣稱託管代理已經過時，而是認為部分企業會希望掌握代理底層的執行框架，以便選擇模型、控制部署位置，並依照自身治理要求調整代理循環。

在相同 Opus 4.8 模型下約低 30%，以及改用 GLM-5.2 時最高約低 75% 的基準測試結果值得驗證，但在企業以自身任務重現之前，應視為待驗證假設，而不是既定結論。

較可靠的評估方式，是使用真實工具與資料進行受控試點，並比較任務成功率、失敗模式、尾端延遲、Token 與上下文消耗、模型與基礎設施成本、資安控制、維運工時，以及人工審核需求。對沒有能力或沒有必要自行維運整套堆疊的團隊而言，Claude Managed Agents 可能仍是更合適的產品；對最重視控制權、模型可攜性與長期工作負載經濟效益的企業，TrueForge 則值得作為一個範圍受控的企業試點，但不能被視為通往生產可靠性的保證捷徑。