維運代理程式唯有能夠觀察到被要求調查的系統時，才具有實際價值。
AWS DevOps Agent 為團隊提供了處理雲端維運任務的自然語言入口。TrueWatch MCP Server 則讓該代理程式能以受控管的方式查詢可觀測性資料：日誌、指標、追蹤、RUM 資料、儀表板、監控器，以及相關的調查情境。兩者結合後，工程師可以從一個正式環境的問題出發，例如「這次錯誤激增前後發生了什麼變化？」，並讓代理程式透過範圍受限的工具蒐集證據，而不是僅憑提示內容臆測。
本指南將說明實際的連接流程。請將其視為一種整合模式，而非權限模型。MCP 解決的是介面層的問題：代理程式能否呼叫正確的可觀測性工具？正式環境部署仍然需要工作區範圍限制、最小權限金鑰、預設唯讀、對具副作用動作的審核機制，以及工具呼叫的稽核紀錄。
AWS DevOps Agent 帶來的價值
AWS DevOps Agent 是 AWS 推出的 AI 維運助理，這款 AI DevOps 代理程式旨在協助使用者透過自然語言互動來操作雲端資源、排解問題，並產生與基礎架構相關的輸出內容。
就可觀測性工作而言，重點並不在於聊天介面本身。真正的價值來自於將代理程式連接到最新的正式環境訊號，同時將該存取範圍加以限制。若沒有這層連接，代理程式只能推測可能的故障模式；透過範圍受限的 MCP 連接，它則能檢視當下的遙測資料，並引用其所使用的證據。
TrueWatch MCP Server 帶來的價值
TrueWatch 是專為維運現代正式環境系統的工程師打造的可觀測性平台，將基礎設施監控、應用程式效能監控（APM）、日誌管理、分散式追蹤、RUM、儀表板、告警與雲端資源資料整合到共享的調查情境中。
TrueWatch MCP Server 會將 TrueWatch 部分功能開放給相容 MCP 的用戶端使用。在本文中，AWS DevOps Agent 會連接至 TrueWatch MCP Server，並取得一組以讀取為主的工具，例如：
- list_checkers
- list_logging_query_rules
- list_dashboards
- query_log_data
- query_metric_data
- query_trace_data
- query_rum_data
請從唯讀工具開始使用。先讓代理程式蒐集證據、進行摘要並提出後續建議，之後再擴大存取範圍至會變更正式環境系統的工作流程。
整合路徑
整合流程如下：
AWS DevOps Agent -> MCP Server registration -> TrueWatch MCP Server -> TrueWatch observability data實際的 AWS 使用者介面可能會有所變動，但整體操作方式應大致相同：註冊 MCP 伺服器、新增端點與驗證資訊、將伺服器附加至 Agent Space、選擇允許使用的工具，並執行唯讀調查以驗證整個路徑是否正常運作。
1. 開啟 MCP 伺服器註冊入口
開啟 AWS DevOps Agent 主控台，在功能選單中前往 Setting，接著選擇 Register。 註冊頁面會列出第三方整合項目，例如 GitLab、ServiceNow、Slack 與 MCP Server。選擇 MCP Server 即可開始 TrueWatch MCP Server 的註冊流程。
當關聯流程成功啟動後，頁面應會顯示類似以下的訊息：
AWS DevOps Agent MCP Server associated successfully2. 設定 TrueWatch MCP Server 端點
在 MCP 伺服器詳細資訊頁面中，完成核心設定。
確認傳輸協定
MCP 伺服器必須支援 Streamable HTTP 傳輸方式，請在新增端點前先確認此項目。
選擇授權流程
開啟 Authorization 設定，並選擇與您的 TrueWatch MCP Server 設定相符的授權方式。
為伺服器命名
在 Name 欄位中，使用清楚易懂的名稱，例如：
TrueWatch MCP Server若您同時維運多個工作區，建議使用能描述環境的名稱，例如 TrueWatch MCP Server - Production Read Only。
新增端點 URL
在 Endpoint URL 欄位中，加入您工作區所對應的 TrueWatch MCP Server 端點。
目標格式範例：
https://toby-ai.truewatch.com/toby_ai_mcp/mcp在發布或分享本指南之前，請以最新的 TrueWatch 文件確認最終端點。此 URL 也可能出現在 AWS CloudTrail 日誌中，因此請避免在端點本身內嵌任何機密資訊。
若頁面提供 Description 欄位，可加入簡短的操作說明，例如：
用於正式環境調查的唯讀可觀測性工具。僅在符合您安全政策的情況下才啟用 Dynamic Client Registration，此選項可讓 DevOps Agent 在設定流程中向 MCP 授權伺服器完成註冊。
完成端點設定後，點選 Next。
3. 使用 API 金鑰授權
AWS DevOps Agent 支援多種授權流程，例如 OAuth Client Credentials、OAuth 3LO 與 API Key。本文的設定範例是針對 TrueWatch MCP Server 使用 API Key 授權方式。
此方式可省去瀏覽器重新導向的步驟，讓呼叫端應用程式擁有直接的驗證路徑。在正式環境中，請為此代理程式連線使用專屬金鑰，並將其範圍限縮至所需的最小資料與工具。
設定標頭
將固定的標頭名稱設定為：
Authorization設定 API 金鑰值
請依照您的 TrueWatch MCP Server 文件所定義的格式，使用 API 金鑰與站點金鑰。本文的設定範例使用以下組合值：
<TRUEWATCH_API_KEY>-<SITE_KEY>其中：
- <TRUEWATCH_API_KEY> 為您在 TrueWatch 工作區中建立的 API 金鑰。
- <SITE_KEY> 用於識別 TrueWatch 的部署區域或站點。
建立或檢視 API 金鑰
在 TrueWatch 主控台中，開啟 System Settings 並前往 API Keys。請為此整合建立新金鑰，或檢視現有的金鑰。
對於維運代理程式而言，較安全的起始做法如下：
- 唯讀存取權限
- 限定於工作區範圍內的權限
- 不使用廣泛的管理員角色
- 開發、預備與正式環境使用各自獨立的金鑰
- 訂定金鑰輪替政策並指定負責人
對應站點金鑰
TrueWatch 的部署區域會對應到不同的 OpenAPI 端點。在正式環境使用前，請先確認目前生效的對應關係。以下範例僅示範對應模式，不涉及內部部署細節：
const SITE_KEY_MAP = { us1: 'https://us1-openapi.truewatch.com', eu1: 'https://eu1-openapi.truewatch.com', ap1: 'https://ap1-openapi.truewatch.com',};檢查完設定後，若需要回顧先前的設定，可點選 Previous。接著點選 Next 送出設定，設定成功後應會顯示 MCP 伺服器關聯成功的訊息。
4. 將 MCP 伺服器附加至 Agent Space
回到 AWS DevOps Agent 主頁面，開啟 Agent Spaces。
Agent Spaces 用於控制 DevOps Agent 的存取範圍、能力邊界與操作範疇。當團隊、環境或風險等級需要彼此隔離時，請使用不同的 Agent Space。
開啟目標 Agent Space，點選 View details，然後找到 MCP Server。
5. 新增 MCP 工具並儲存設定
在 MCP 伺服器工具頁面中，選擇允許 AWS DevOps Agent 呼叫的工具。
本文的設定範例新增了七項 TrueWatch MCP 工具：
- list_checkers
- list_logging_query_rules
- list_dashboards
- query_log_data
- query_metric_data
- query_trace_data
- query_rum_data
請勿預設就給予代理程式所有工具的存取權限。對於正式環境系統，建議先從僅讀取資料的工具開始使用；除非已建立獨立的核准機制，否則應避免使用會修改、刪除、寫入、回復、擴縮或靜音正式環境行為的工具。
選好允許使用的工具後，點選 Save。
6. 啟動唯讀調查
完成 MCP Server 與工具權限設定後，開啟 Agent Space 詳細資訊頁面，並選擇 Operator access。
此區域包含拓撲、能力與網頁應用程式存取等維運檢視畫面。首次測試時，請將任務範圍限縮在唯讀操作。
點選 Start investigation，在 Investigation starting point 中輸入具體的調查請求。適合作為初次測試的範例包括：
分析過去 15 分鐘內的錯誤日誌，並依服務與錯誤類型進行分組。或：
找出近期有追蹤錯誤的服務，並摘要說明每項發現背後的證據。提示內容應告訴代理程式要蒐集哪些證據，以及如何進行摘要。
若頁面顯示 Fetching data 或 Investigating 等狀態，且輸出內容包含來自 MCP 工具的結果，即代表連接路徑運作正常。
示範：分析過去 15 分鐘的錯誤日誌
本文示範使用了一個簡單的請求：
分析過去 15 分鐘內的錯誤日誌。AWS DevOps Agent 會解析此請求、擬定調查計畫、呼叫 TrueWatch MCP 工具，並將回傳的資料進行摘要。
在此示範流程中，代理程式：
- 查詢了近期的錯誤資料
- 依類型將錯誤分組
- 找出受影響的服務
- 附上原始日誌樣本
- 摘要重點發現
三個服務、三種不同的故障模式——這正是微服務監控在實務上的樣貌：錯誤會對應到特定的服務與時間範圍，而不是全部混為一個籠統的事件。
範例結果樣貌
在此示範的時間範圍內，調查共辨識出三類錯誤。
找不到設定
- 錯誤類型：forethought.utils.exceptions.APIException
- 錯誤代碼：ftLogackupCfgNoExists
- 服務：inner-api
- 說明：找不到資料轉發設定
查詢逾時
- 錯誤類型：errors.errorString
- 服務：kodo-inner
- 說明：查詢逾時導致的內部伺服器錯誤
未知 API 錯誤
- 錯誤類型：forethought.utils.exceptions.APIException
- 錯誤代碼：ft.CloudCareApiError
- 服務：front-api
- 說明：未知的 API 錯誤
真正有價值的部分，不在於代理程式產出了一段文字，而在於這個答案可以追溯回具體的工具呼叫、時間範圍、服務、日誌樣本與查詢結果。
常見問題
Q：AWS DevOps Agent 是否應該擁有 TrueWatch 資料的寫入權限？ A：一開始不應該。請先僅使用唯讀工具，唯有在建立獨立的人工核准機制之後，才擴大至能修改、刪除或回復正式環境行為的工具。
Q：為此整合設定 API 金鑰時，最安全的做法是什麼？ A：請使用僅供此代理程式連線使用的專屬金鑰，而非共用或具管理員層級的金鑰。最佳做法是採用限定於工作區範圍內的權限、不使用廣泛的管理員角色、依環境（開發／預備／正式）分別使用不同金鑰，並訂定金鑰輪替政策且指定明確的負責人。
Q：我要如何確認這項整合真的可以安全地套用在正式環境上？ A：在完成第一次調查後，請檢查三件事：資料範圍（代理程式是否只查詢了預期的工作區／環境／時間範圍？）、工具範圍（每個已啟用的工具是否確實有被使用——若沒有，就將其移除），以及證據品質（工程師是否能將答案追溯回特定的服務、時間範圍、錯誤類型與查詢路徑？）。
Q：TrueWatch MCP Server 與 Toby AI Agents 有什麼差異？ A：MCP Server 是介面層，讓 AI 用戶端得以呼叫 TrueWatch 的可觀測性工具；Toby AI Agents 則是建構於其上的完整營運模型，涵蓋故障排解方法論、權限邊界、證據軌跡、核准流程、依角色而定的行為，以及事後驗證。MCP 回答的是「代理程式能否看到資料？」，而 Toby AI Agents 回答的是「代理程式是否應該採取行動，以及我們該如何治理這件事？」這正是符合正式環境需求的 AI 代理程式可觀測性所真正需要的。
Q：使用此設定時應避免哪些做法？ A：請勿預設就給予代理程式所有可用的工具。請勿在端點 URL 中內嵌機密資訊（因為它可能會出現在 AWS CloudTrail 日誌中）。對於任何會變更正式環境狀態的動作，請勿略過人工核准。請勿在正式環境的 Agent Space 中進行第一次測試——請先使用非正式環境的工作區。
