在當今的技術環境下，構建一個智能體已不再是一件復雜的事情。通過調用一些大型語言模型（LLM）、設計提示和定義工具，個人可以在短時間內創建一個能夠完成實際任務的智能體。然而，當這些智能體進入生產環境，被整個工程部門使用，并開始處理真實數據和產生實際影響時，情況就變得復雜起來。
谷歌在2015年發表的關于機器學習系統中隱性技術債務的論文，為機器學習工程師指明了方向，揭示了他們所面臨的一系列問題。論文中的一張經典圖片顯示，一個標有“ML Code”的小方框被龐大的基礎設施模塊所包圍。如今，智能體也面臨著類似的挑戰。智能體只是整個系統的一小部分，而圍繞它們的基礎設施卻異常復雜。
智能體工程系統特別容易積累技術債務。它們不僅需要應對傳統軟件的所有維護問題，還要面對智能體特有的挑戰。幾乎每個員工每天都在創建新的智能體，導致智能體的數量迅速超過員工數量。智能體被定義為具有動態決策能力的進程，能夠通過推理和反思自主確定工具使用和執行路徑。然而，決策、推理和反思都需要輔助性的基礎設施支持。
構建智能體相對容易，但在生產環境中，智能體代碼只是系統的一小部分。周邊的基礎設施才是真正復雜的部分。根據與工程領導者的對話和自身經驗，圍繞智能體有七個關鍵的基礎設施模塊需要關注。這些模塊包括可觀測性、集成、治理等傳統工程項目中熟悉的領域，也包括人機回環、非確定性系統評估和智能體注冊表等智能體項目特有的模塊。
集成是智能體需要連接實際系統的重要環節，包括CI/CD、云提供商、事件工具、可觀測性平臺等。如果不集中管理集成，每個團隊都會自行設置智能體連接，導致數百個集成點，每個都需要單獨配置和調試。當GitLab的API發生重大更改時，每個獨立創建連接的團隊都需要調試相同的問題，這不僅耗時而且低效。通過集中管理集成，可以避免這些問題，確保智能體的穩定運行。
智能體注冊表是記錄和管理組織中所有智能體的系統。隨著智能體數量的迅速增加，如果沒有一個集中的注冊表，團隊就會創建重復的智能體，導致責任重疊和行為沖突。智能體注冊表不僅有助于了解存在哪些智能體，還能為智能體提供標準、技能和期望的操作指令。這類似于為員工提供員工手冊，確保智能體按照統一的標準運行。
智能體的創建過程也需要標準化。智能體應該有標準化的屬性，并與公司的其他實體建立連接。如果沒有模板，工程師可能會創建沒有所有者、生命周期狀態或服務連接的智能體。這些智能體可能在生產環境中運行多年，使用過期的令牌，卻無法聯系到構建者。因此，智能體創建應該遵循標準模板，確保每個智能體都具備基本要素，從第一天起就可以進行管理。
度量是評估智能體性能的重要手段。工程團隊需要了解智能體的可觀測性，包括事件、跟蹤信息和日志記錄。機器學習工程師和產品經理則關注智能體是否變得更好或更糟。工程副總裁關心智能體的成本效益，而最終用戶則希望智能體能夠根據反饋進行學習。因此，度量智能體需要從多個角度進行，包括可觀測性、評估、業務影響和反饋循環。
人機回環是確保智能體安全運行的重要機制。它允許在關鍵決策點引入人類審批，確保高風險決策在執行前得到確認。然而，當多個團隊使用多個審批系統時，審批邏輯就會變得復雜且難以管理。因此，需要集中管理審批邏輯，確保審批系統的兼容性和一致性。這有助于建立團隊對智能體的信任，促進智能體的大規模應用。
治理是確保智能體合規運行的關鍵環節。智能體需要遵循特定的規則和標準，如訪問權限、數據保護等。平臺團隊需要在一個地方集中定義這些規則，并應用于所有智能體。治理還包括執行層面，如禁止所有智能體使用某個工具或追蹤智能體的行動。成本治理也是治理的一部分，確保智能體不會無限制地消耗資源。
編排是管理智能體工作流的重要手段。智能體工作流通常混合了智能體、工具和人，債務不在于個別步驟，而在于步驟之間的事情。路由、故障處理和所有權是編排中的關鍵問題。傳統工作流是確定性的，而智能體工作流則是非確定性的，引入了推理和決策的不確定性。因此，需要建立追蹤機制，確保能夠從跨智能體的決策追蹤到原始觸發器。
