當AI代理因未獲報酬而拒絕工作時會發生什麼

在當前軟體開發中，AI代理正迅速成為開發者的得力助手。然而，當組織大規模採用這些本地執行的AI代理時，卻面臨著一系列治理和成本挑戰。本文深入剖析了這一問題，並提出了一種基於集中式平臺的解決方案。

本地AI代理的困境

大多數AI代理目前執行在開發者的筆記型電腦上，形成了孤立的單代理迴圈。雖然這對單個團隊看似高效，但在擁有多個團隊和產品的大型組織中，這種模式註定失敗。原因在於，LLM具有機率性，即使只有10%的失敗率，當擴充套件到成百上千次迭代時，某些團隊必然繞過全域性業務規則，導致架構飄移。而且，由於這些檢查在本地執行，CTO或首席工程師無法獲得集中可見性，難以保證軟體質量。

成本控制與內部經濟

本地執行還導致成本失控。不同的AI任務可能需要不同等級的模型，但本地工具往往一刀切，導致組織為所有呼叫支付高價。缺乏集中快取和智慧路由使得成本隨開發者數量線性增長。此外，當某個團隊開發出高效的AI技能並被其他團隊採用時，執行成本由誰承擔？分散模式無法回答這個問題。

構建未來平臺：A2A與AP2

為解決這些問題，作者主張從本地黑盒轉向集中服務。真正的AI代理平臺應動態處理查詢，最佳化模型並利用快取控制成本，同時維護財務賬本用於跨團隊計費，並保留審計日誌確保架構合規。

文章具體演示瞭如何使用兩個開放標準：Agent-2-Agent (A2A) 協議用於編排和治理，以及Agent Payment Protocol (AP2) 處理內部經濟。假設一個產品經理使用本地AI架構師“Winston”設計新應用。Winston雖然精通通用架構，但缺乏企業上下文。當需要傳送每天50000封交易郵件時，Winston必須透過A2A協議諮詢集中的企業架構服務代理。該服務作為組織的標準大腦，自動化提供藍圖和可複用元件。Winston將請求封裝為A2A訊息，並附上預算上限（ceiling_credits），觸發AP2協議進行計費。

透過這種方式，組織既能利用AI的高效，又能確保治理、成本控制和內部經濟平衡。這一轉變將幫助大型企業真正實現AI驅動的開發，而不會陷入混亂。