編輯 | 云昭
出品 | 51CTO技術棧（微信號：blog51cto）
上周，我和一位最近剛上線 AI Agent 的 PM 聊天。指標看上去非常亮眼：89% 的準確率、毫秒級的響應、用戶調研反饋積極。
但實際情況卻很打臉，上線沒多久，用戶紛紛棄用了。
典型的場景就是，用戶一旦遇到真正的問題，Agent 就秒變菜雞了。
比如，當用戶同時遇到賬單爭議和賬號被鎖時：
“我們的 Agent 能完美處理常規請求，但面對復雜問題時，用戶嘗試一次不順利，就立刻放棄轉而找人工?！?/p>
其實，這個問題似曾相識，絕非個例。幾乎所有做智能客服的團隊都會踩這個坑：
很多團隊不斷把精力放在讓 Agent “更聰明”上，但真正的挑戰其實是架構決策，而這些決策決定了用戶如何體驗、如何逐步信任 Agent。
為什么有的 Agent 看起來“有魔力”，有的卻讓人抓狂，以及在架構上究竟該如何取舍？
小編剛剛讀到了一篇ProductCurious社區上一位大牛今天發表的文章，可以說是把這些問題解釋得非常透徹。
圖片
AI Agent 的架構與產品決策問題，事關產品的成敗。
我們將用一個客服 Agent 的例子，來展示不同的架構選擇如何影響結果。還會看到一個反直覺的信任策略（提示：不是“更準確”），為什么它更有利于用戶采納。
一、用戶究竟為什么會棄用？
假如你要做一個幫助用戶處理賬號問題的 Agent——重置密碼、賬單咨詢、套餐變更等等。
但如果用戶這時候告知：“我無法登錄賬號，而且訂閱似乎不對了”，這時候 Agent 到底應該怎么處理呢？
圖片
場景 A：Agent 立即查詢系統：發現昨天密碼已重置但郵件未送達，同時賬單異常導致套餐被降級。它解釋清楚發生了什么，并提供“一鍵修復”選項。
場景 B：Agent 開始追問澄清：“你上次成功登錄是什么時候？看到的報錯信息是什么？能詳細說下訂閱問題嗎？” 收集完信息后，它說：“讓我幫你轉接人工客服來核查賬號和賬單。”
很明顯，A 明顯優于 B。
同樣的用戶請求，同樣的底層系統，卻是兩種完全不同的產品體驗。
所以，用戶不往往不是因為 Agent 笨而離開，而是因為：
體驗不連續：簡單問題能答，復雜問題就崩。
信任感缺失：Agent 自信滿滿，但結果不對。
所以，決定 Agent 成敗的關鍵，不是準確率，而是：它在復雜、不確定場景下的表現。
二、四個Agent產品決策層
我們可以把 Agent 架構看成一個堆棧，每一層都是你必須做的產品決策。
圖片
第 1 層：上下文與記憶（Agent 記住什么？）
決策：你的 Agent 該記多少？記多久？
這里不僅是是一個技術上的存儲的問題，還涉及到理解的幻覺問題。記憶決定了 Agent 更像“機器人”還是“熟悉的同事”。
對于客服 Agent 而言，就需要判斷：
- 只存當前對話，還是存用戶完整歷史？
- 是否記錄用戶使用習慣？
- 是否記下過往投訴？
因此，我們就需要管理這幾類記憶，比如：
- 會話記憶：只記當前對話
- 客戶記憶：跨會話的歷史交互
- 行為記憶：使用模式（如常用移動端）
- 上下文記憶：賬號狀態、活躍訂閱、近期活動
記得越多，越能預測需求，但也增加復雜性和成本。
第 2 層：數據與集成（接多深？）
決策：Agent 應該接入哪些系統？有多大權限？
接得越深，越難被替代，也越容易出故障。
對于客服 Agent 的選擇如下：
- 只接 Stripe 的賬單系統？
- 還是也接 Salesforce CRM、Zendesk 工單、用戶數據庫、審計日志？
第 3 層：技能與能力（你的差異化在哪？）
決策：Agent 應該具備哪些技能？深度如何？
這里決定你能否建立用戶依賴。關鍵不是功能越多越好，而是選對能力。
客服 Agent 的決策思考如下：
- 只讀賬號信息？
- 還是能修改賬單、重置密碼、變更套餐？
每多一個技能，價值提升，但復雜性與風險也上升。
圖片
實現提示：可以通過 MCP 讓技能在不同 Agent 之間復用，而不是每次都重建。
第 4 層：評估與信任（用戶如何預期？）
決策：你如何衡量成功，并向用戶傳達 Agent 的局限？
關鍵不是“更準確”，而是更可信。
客服 Agent 的決策考量如下：
- 是否展示置信度？
- 是否解釋推理過程？
- 是否執行前都二次確認？
常見信任策略：
- 置信度提示：“我對賬號狀態很有把握，但賬單細節需要再確認?！?/li>
- 透明推理：“我發現兩次登錄失敗，付款方式也過期了。”
- 優雅邊界：“這個賬單問題較復雜，我轉給擁有更多工具的專員?！?/li>
- 確認模式：什么時候直接執行，什么時候征求許可
反直覺發現：當 Agent 承認不確定性 時，用戶的信任度反而更高。
三、那么，Agent架構該如何做？四種常見架構模式
理解層次后，Agent 產品開發面臨的核心問題則是：
Agent 如何調用技能？技能如何訪問數據？用戶等待時如何評估？
這就涉及到編排模式。不同模式決定了你的開發體驗、調試難度與迭代速度。
圖片
1. 單 Agent 架構（入門）
一個 Agent 包辦所有。
- 優點：簡單易建、好調試、成本可控
- 缺點：復雜請求下容易昂貴，難以單獨優化
大部分團隊從這里起步，很多甚至無需升級。
2. 技能路由架構（需要效率時）
有一個路由器來分發任務給專門的技能。
- 優點：高效，可用便宜模型處理簡單技能
- 缺點：技能間協調復雜，誰來決定何時交接？
MCP 在這里大顯身手，標準化了技能暴露方式。
3. 工作流架構（企業最愛）
預定義流程，類似 LangGraph、CrewAI、AutoGen。
- 優點：可審計，合規友好，步驟可優化
- 缺點：邊緣情況卡死，用戶體驗僵硬
4. 協作式架構（未來方向）
多個專門 Agent 用 A2A 協議協作。
- 愿景：如 Booking.com 的 Agent 和 美國航空的 Agent 自動對接解決跨系統問題。
- 現實：安全、計費、信任、可靠性問題尚未解決。調試極其困難。
圖片
所以建議：如果大家正在學習開發 Agent，還是要從簡單開始。單 Agent 架構能覆蓋大多數場景。只有遇到實際瓶頸再增加復雜度。
四、關于信任的最大誤區
但請記住：即使架構完美，如果用戶不信任，Agent 依然會失敗。
用戶不會因為 Agent 永遠正確而信任它，而是因為它“在犯錯時還表現得那么理直氣壯”。
簡單舉個例子更容易理解：
- bad 案例：Agent 自信滿滿地說“我已重置密碼并更新賬單地址”，結果用戶仍然無法登錄 → 技術問題變成了信任問題。
- good 案例：Agent 說“我 80% 確信這樣能解決問題，如果不行，我會立即轉人工。”
你看，雖然技術能力是一樣的，但體驗會截然不同。要打造可信的 Agent，需關注三點：
- 置信度校準：說 60% 時，就真的要做到 60%。
- 推理透明：展示檢查過程與證據。
- 優雅交接：觸及邊界時，順暢轉人工，并帶上完整上下文。
很多時候，用戶要的不是“更準確”，而是“更透明”。
五、一個毫無AI感的AI客服做法
“我真的不理解，怎么有人會直接把一堆工具和數據源交給 AI，讓它們對客戶開放使用。就用戶體驗來說，這簡直糟透了，有時候甚至比電話語音菜單還差。
”一位非常厲害的網友也分享了自己幫企業打造智能客服的經驗?！霸谖铱磥?，應該慢慢、謹慎地過渡到 AI 優先的客服方式！”
1.明確 AI 的能力范圍：只允許它解決那些高概率能搞定的問題。提示語可以是：“你只能幫助處理以下問題?！?/p>
2.立刻轉人工：如果超出范圍，就立即轉交人工，比如“如果你不能幫忙，立刻轉人工。”
3.“解鎖代理”機制：給客服人員配一個 AI，他們可以用它來回答問題，并評估效果，用這些反饋來推動開發路線。
4.逐步擴展范圍：如果“解鎖代理”在某類問題上表現不錯，就把它納入可處理范圍。
5.最后，還需要有一個方法，在你更新系統時能回放和測試歷史對話。（這在我的 TODO 清單里）
“我給一些小企業實現過這種流程，結果非常順暢，幾乎沒人察覺到背后有 AI。在某個客戶那里，甚至沒有顯式的“轉人工”步驟：客服人員直接在手機上收到提醒，接管對話?！?/p>
六、Agent 帶來新的崗位新變化
在 AI Agent 如火如荼的時代，許多原來的開發思路、設計框架都產生了amazing 的變化。
最大的一個感受就是，我們以前單純圍繞用戶需求來做開發、做產品的做法似乎已經不太奏效，我們還需要面向 AI 或 Agent 的能力去逐步構建和引導。
小編一直以為，AI 絕不會擠壓人類的工作空間。相反，它會創造出更多共走崗位新角色。根據小編之前的調查，以及跟多位在一線負責 AI 產品開發的大佬的采訪交流，總結至少會有以下幾個方向的進化：
- 智能體體驗設計師：設計人與 Agent 的交互模式，關注“提示語”“反饋機制”“上下文切換”的體驗。（上下文工程就是其中一塊）
- AI 能力編排師：不需要寫底層代碼，但要理解如何調用不同智能體、工具與 API，編排成完整解決方案。（這一塊，小編了解到已經有數家中大廠在如此做了。）
- 價值驗證者：用實驗快速驗證“AI 生成體驗”是否真的為用戶帶來價值。（初創產品MVP打造）
- 風險管控者：對 AI 帶來的倫理、安全、合規風險提出產品層面的應對措施。（各種對齊技巧等等）
話說回來，希望本文提供的Agent 決策框架，能幫助到大家！提前祝周末愉快~
參考鏈接：https://www.productcurious.com/p/a-pms-guide-to-ai-agent-architecture
