告別“語義黑盒”：當 Agent 走進生產環境，我們如何馴服它的“不可預測”？

作者 | QCon 全球軟件開發大會

策劃 | Kitty

編輯 | 宇琪

隨著大模型 Agent 從實驗原型邁向核心業務生產，工程化的重心正經歷從“驗證可行性”向“追求確定性”的本質躍遷。Agent 的本質是“自主”、“涌現”、“不可預測”——這些詞本身就和“確定性”對著干。但企業要的是什么？是可用、是可靠、是出了事能找到原因、是敢把核心業務交給它。那么，一個本質上不確定的系統，我們能把它變得足夠“確定”嗎？如果能，靠什么？可觀測性在這個命題里，扮演的是什么角色？

近日 InfoQ《極客有約》X QCon 直播欄目特別邀請小紅書技術風險負責人孫佳林擔任主持人，和亞馬遜云科技 Agent 架構師章平、階躍星辰安全研發專家李昌昊、騰訊 SRE 資深工程師陳自欣一起，在2026 年QCon全球軟件開發大會（北京站）即將召開之際，共同探討如何構建面向 Agent 的全鏈路語義觀測體系。

部分精彩觀點如下：

• Agent 的確定性工程，本質是追求運行過程中的可觀測、可診斷、可干預與可演進。

• 通過 MCP、日志聚類、Function call 等機制，可以減少 Context Window 壓力，并提升處理效率。同時，通過將 Skill、Memory 等能力模塊化組合，構建面向具體場景的 Agent，從而限制其行為范圍，降低不確定性。

• Agent 系統鏈路復雜，問題可能來自模型、工具或運行環境，因此需要全鏈路可觀測能力來定位問題。可觀測性的核心價值并非追責，而是定位問題與優化系統，從而提高整體可靠性與效率。

• 如果未來 token 成本大幅下降，使中小企業甚至個人都能承擔，那么可觀測與評估體系將被更廣泛采用，從而推動整個生態的發展。

在 4 月 16-18 日將于北京舉辦的 QCon 全球軟件開發大會 上，我們特別設置了 【Agent 可觀測性與評估工程】 專題。該專題將深度拆解生產實踐案例，幫助構建可驗證、可演進的 Agent 工程體系，推動 Agent 成為真正可靠的生產系統。查看大會日程解鎖更多精彩內容：https://qcon.infoq.cn/2026/beijing/schedule

以下內容基于直播速記整理（經 InfoQ 不改變原意的情況下刪減）。

完整直播回放可查看：https://www.infoq.cn/video/jzSzcszN0dLwv57hvaxk

Agent 的不確定性

孫佳林：請三位老師，各自用一句話，定義一下你們理解的“確定性工程”——它要解決的核心問題是什么？

章平：不確定性本身是客觀存在的，但在業務中需要將其轉化為可控的確定性。本質上，就是對不確定因素進行量化，并通過機制加以控制，在問題出現后及時修復。例如，可以通過概率方法，從模型層面判斷其行為是否符合預期；若不符合，則借助監測手段定位問題，再進行修復，這實際上是一整套從不確定性中尋找確定性的機制。

李昌昊：安全從業者通常面對大量偽裝進程或攻擊行為，有一個基本原則：不看進程的自我聲明，而是觀察其實際行為進行判斷。對 Agent 也不能只看其“說了什么”，而應從確定性的角度判斷其實際行為。例如，當 Agent 聲稱執行成功時，需要查看其退出碼、返回內容是否報錯、資源消耗是否合理等。這些來自內核的數據是確定的，基于這些確定性基礎，可以緩解 Agent 的不確定性問題。

陳自欣：我認為這是一個具有“矛盾統一”特征的問題，甚至可以上升到哲學層面。我們希望 Agent 具備高智能，但高智能必然帶來不確定性。企業中最不確定的因素其實是人，但企業仍然需要人或 Agent 來運營，核心在于“像管理公司一樣管理 Agent”。首先要做的是觀察 Agent 的行為，這類似于企業中的早會、日報、周報等機制，用于防止其偏離方向。確定性工程的第一步，是先確認其當前狀態，即“先觀測”。

孫佳林：我們追求的確定性，并不是將 Agent 變成簡單的 if-else 程序，也不是要求其永不出錯，而是要在其出錯或性能下降時能夠被及時發現，并在上線前有依據地評估風險。同時，需要從內核層、LLM 調用層、工具調用層及效果層進行監控，在問題出現后快速修復并持續迭代優化。抽象來看，Agent 確定性工程的本質是追求可觀測、可診斷、可干預與可演進。

孫佳林：要讓 Agent 變得“可管理”，我們首先得搞清楚，它的“不確定”到底來自哪里？傳統軟件的不確定性，主要來自代碼 Bug、網絡抖動、硬件故障等。但 Agent 帶來了新的不確定性源頭，三位老師能不能從各自的領域出發，給我們分享一下“Agent 不確定性”來源于哪些因素？

陳自欣：Agent 的運行天然具有不確定性。從底層原理看，調用大模型時通常需要設置 temperature 參數，該參數決定模型輸出的隨機性。如果完全確定，模型將變得僵化，無法完成復雜決策，因此不確定性首先來源于模型本身。

其次，不確定性還來自模型運行過程。例如“模型降智”這一現象，在 LLM 普及之前并不常見，但現在可能由于算力、推理框架缺陷或 API 供應商問題導致模型性能下降。此外，模型供應商的不穩定性也會帶來影響，例如服務連接失敗等情況頻繁出現。

第四類不確定性來自長任務執行過程中的偏移，例如上下文引導不足，導致模型逐漸偏離目標；以及環境、工具（Skills）等因素也會引入不確定性。

李昌昊：我從運行與運維角度補充幾點。首先，運行時環境具有不確定性。與傳統軟件運行在固定鏡像不同，Agent 常在沙箱中執行，環境可能每次不同；其工具選擇也不固定，甚至會動態安裝依賴，從而引入額外不確定性。此外，沙箱狀態可能受之前任務影響，導致同一命令在不同環境中結果不同，這是 Agent 特有的問題。

其次，可觀測性存在斷層。Agent 與運行時之間缺乏統一鏈路，導致難以將 Agent 行為與運行結果關聯，這在傳統軟件中較少見。

第三，可觀測能力本身存在限制。例如 Agent 與大模型之間通常采用 HTTPS 加密，APM 或防火墻難以攔截；沙箱執行過程也被隔離，難以從底層監控其行為。這些都會成為不確定性的來源。

章平：在工具使用方面存在不確定性。例如某旅游客戶在修改提示詞后，工具調用率顯著下降，雖然對話表面正常，但 Agent 選擇了通用搜索工具而非合適工具，導致體驗下降。此外，在評估中使用“LLM as judge”方法，即用模型評估模型，本身也是用不確定性評估不確定性，會進一步放大問題，這類似于測量對系統本身的影響。

孫佳林：Agent 的不確定性不僅來自模型，還來自推理過程、上下文漂移、外部工具依賴及運行時環境等。此外，一個容易被忽視的問題是效果評估體系的缺失，以及“語義黑盒”的存在。那么將黑盒轉為可觀測的白盒，是要解決的關鍵問題。

可觀測如何構建確定性

孫佳林：章平老師，在 AWS 的大規模實踐中，你們觀測 Agent，最核心的幾類數據是什么？是傳統的 QPS、延遲、錯誤率，還是需要一些“ Agent 特有”的指標？

章平：在 Agent 體系中，除傳統 QPS 等指標外，更關注多層級指標。第一層是行為指標，例如工具調用是否正確、參數設置是否合理，這直接影響執行準確性。

第二層是質量評估，即任務完成后是否真正幫助用戶，包括響應的有用性、正確性、相關性及情感因素等。這些指標雖帶有主觀性，但與業務緊密相關，需結合實際場景設定。

此外，還包括 session 級指標、多輪對話整體表現。單輪可能表現良好，但多輪下可能下降，需從多輪維度評估整體效果。

孫佳林：假設我們發現“任務完成率”突然下跌，接下來怎么做？可觀測數據怎么幫我們一步步下鉆，找到是模型問題、 Prompt 問題，還是外部依賴問題？

章平：在評估體系中，首先會設置觀測與告警機制。例如，當工具調用率低于某一閾值時觸發告警后，會通過評估體系定位問題原因。我們會將完整執行過程輸入大模型進行分析，不僅獲得評分，還能得到錯誤原因提示。再結合發布日志逐步回溯，判斷是否由提示詞或模型變更導致問題。最終，在定位原因后進行修復，并通過后續指標驗證修復效果，從而形成“觀測—定位—修復—驗證”的閉環。

孫佳林：你們主要依賴 LLM 來評估與診斷，而非傳統規則方法，對嗎？

章平：是的，同時也會結合成本與效率進行權衡。

孫佳林：昌昊老師，Agent 跟 LLM 的對話是加密的，沙箱里的執行是隔離的，兩層黑盒疊在一起。我們怎么在"無侵入"的前提下，同時打開這兩層黑盒，讓排查的人能看到"Agent 當時到底做了什么？

李昌昊：我們目前主要面向訓練或業務場景，設計方案時強調“零侵入”。由于用戶可能使用不同的 Agent 框架（如 LangChain 等），且沙箱環境多樣、生命周期短，難以通過傳統埋點方式采集數據，因此零侵入成為關鍵要求。

此外，我們采用 eBPF 技術對加密流量進行解密，通過掛載 TLS 庫函數，在內存中獲取明文數據，從而提取模型請求信息，如模型名稱、Prompt、用量及延遲等。

在運行時層面，通過 Tracepoint 等技術采集進程創建、命令執行及結果數據，實現對沙箱內行為的全面記錄，這使我們能夠從運行時角度還原 Agent 的真實行為。

孫佳林：推理軌跡是一堆數據，工具調用是另一堆數據，API 返回又是第三堆。怎么把它們串成一條完整的、有時間線的故事，讓排查的人一目了然？

李昌昊：數據采集雖有成熟方案，但數據源彼此割裂，需要構建完整的鏈路（trace）。例如，對話數據來自平臺層，審計數據來自應用日志，需進行統一關聯。

我們通過 eBPF 捕獲網絡請求，并借助透明代理注入 trace header，實現 Agent 與大模型之間的鏈路關聯。同時，在沙箱層通過日志與進程事件匹配，結合時間窗口、身份標識及命令一致性，實現跨層關聯。最終，通過網絡解密與運行時觀測，實現從對話到工具調用的全鏈路追蹤，從而在評估中獲得完整數據。

孫佳林：自欣老師，很多公司的 SRE 體系已經很成熟了。Agent 來了之后，是另起一套，還是想辦法融入？藍鯨平臺是怎么把 Agent 的觀測能力和傳統的日志、監控、追蹤打通的？

陳自欣：這個問題可以拆分為兩個方面：一是現有 SRE 體系如何適應 Agent 場景，二是在新場景中如何發揮更大作用。

對于第一點，Agent 時代并非需要重建體系，而是對現有平臺進行演進。可觀測平臺在 Agent 與微服務時代都至關重要，但 Agent 產生的數據更復雜，對存儲與處理提出更高要求。例如，以前日志可通過聚類壓縮，而 Agent 輸出高度多樣，聚類失效，帶來新的挑戰。

第二點是數據打通。關鍵在于將代碼、運行時及可觀測數據統一關聯，從而快速定位問題。由于大模型擅長分析代碼，這種統一數據模型將極大提升問題診斷效率。

孫佳林：自欣老師，你的 QCon 大會演講主題里提到“AI 提效實踐”。現在 Agent 產生的數據量巨大，靠人看不過來。你們是否有用 AI 技術來分析 Agent 行為、預測風險、甚至自動修復？

陳自欣：以騰訊游戲場景為例，多樣化業務帶來復雜觀測需求。當前重點是為 Agent 提供上下文，使其輔助用戶定位問題。

通過 MCP、日志聚類、function call 等機制，可以減少 context window 壓力，并提升處理效率。同時，通過將 skill、memory 等能力模塊化組合，構建面向具體場景的 Agent，從而限制其行為范圍，降低不確定性。

未來，還需要將運維經驗進一步沉淀并賦能 Agent，使其能夠更精準地定位問題核心，從而提升整體系統理解與處理能力。

可觀測的“邊界和代價”

孫佳林：構建一個完整的 Agent 可觀測體系，需要投入多少成本？算力、存儲、人力……小團隊玩得起嗎？有沒有“乞丐版可觀測”方案？

陳自欣：從技術上看，Agent 的可觀測性仍然遵循類似 OpenTelemetry 的規范，即圍繞 metrics、log 和 trace 三類數據展開。但問題在于，傳統可觀測方案中的成本優化手段在 Agent 場景下逐漸失效。例如，過去可以通過 trace 采樣降低成本，日志也具有穩定模式，便于壓縮與刪除。然而，在 Agent 場景中，這些前提不再成立。

可以考慮采用分層策略：一方面用傳統方式監控平臺與運行層的性能指標；另一方面，將高成本、非結構化的數據存儲在如 S3 等低成本存儲中，用于離線分析。這些數據不必實時處理，而是用于評估與業務優化。

從商業角度看，雖然成本上升，但記錄 Agent 的運行日志、Prompt 與 response，有助于持續提升模型能力與任務完成率。Agent 可觀測性雖成本較高，但對業務具有長期價值，甚至是必要投入。

李昌昊：可觀測性的最大成本并非建設本身，而是“不做可觀測”。如果僅讓 Agent“能跑即可”，在后續優化時往往會發現數據質量差、成本不可控。例如，大量 token 消耗中哪些是有效計算、哪些是無效嘗試，無法區分；出現問題時也難以復現，因為缺乏鏈路記錄。

從技術角度看，可以通過低成本方式逐步建設可觀測體系。第一層是記錄工具調用與基礎行為數據，這是成本最低且最直接的手段；第二層是追蹤大模型調用成本，例如 token 使用量、延遲、模型類型等，并按會話或任務進行聚合分析，從而明確成本分布與效率問題；第三層是構建全鏈路追蹤，將各類數據串聯起來，實現問題定位。這一層投入較高，但價值最大。整體來看，可以基于現有平臺能力逐步構建基礎可觀測體系。

章平：我認同可觀測性不僅是成本，更是業務投資。以實際測算為例，若每天有 10 萬次 Agent 調用，每次消耗約 1000 至 4000 token，按照當前主流模型價格計算，若全部由大模型完成評估，每月成本約為 6 萬至 15 萬美元。但實際中無需全部依賴大模型評估。可以將確定性任務交由規則或 ground truth 判斷，將主觀評估交由大模型處理，并結合采樣機制。例如按 70% 規則與 30% 模型分配，再疊加 10% 采樣率，最終成本可降至每月約 1000 至 3000 美元, 這種“組合式”策略可以在成本與效果之間取得平衡。

陳自欣：此外，可將數據存儲后使用更經濟的模型進行離線處理，這同樣具有實際意義。

孫佳林：可觀測性確實有成本，但與不可觀測導致的隱性資源浪費相比，其投入更具價值。因此，應優先解決最關鍵的業務問題，通過采樣與指標篩選實現 ROI 最大化，并結合開源協議與低成本存儲方案，將整體成本控制在合理范圍內。

孫佳林：可觀測不是萬能的。在三位老師看來，目前的可觀測技術邊界在哪里？什么場景下，Agent 的行為是“觀測不到”或者“觀測了也沒用”的？”

陳自欣：從更宏觀角度看，可觀測性與控制論密切相關：無法觀測就無法控制。因此，無論形式如何變化，可觀測性在 AI 時代只會更加重要。

例如在 AI 編程場景中，開發者往往將錯誤日志反饋給模型，再由模型進行修復；一些工具甚至引入調試模式，自動收集日志并參與迭代，這一過程在本地環境中已較為成熟。若將這一閉環擴展至生產環境，其價值將進一步放大。在 Vibe Coding 或自動生成代碼日益普及的背景下，開發者難以完全掌控代碼質量，因此可觀測性將成為關鍵的兜底能力。

李昌昊：可觀測性的邊界類似于現實世界中的測量問題。例如在量子力學中，觀測存在極限，無法完全獲取系統狀態。同樣，在 Agent 場景中，過度依賴某些指標可能導致指標失效，甚至被系統“規避”。

因此，可觀測范圍應與 ROI 匹配。例如，不可能記錄所有網絡請求或完整輸入輸出數據，因為成本過高；同時，對于模型內部語義狀態，由于其概率生成機制，也難以完全追溯。這些都構成可觀測性的邊界。

章平：我補充幾個案例說明邊界問題。首先，評估需要多維度。例如某旅游 Agent 在提示詞變更后未調用專業工具，而使用通用搜索，雖然完成了任務，但結果質量下降。僅從結果判斷是不夠的，還需結合過程指標。

其次，評估標準本身也會變化。例如模型升級或環境變化可能導致原有標準失效，需要定期校準，例如通過固定測試集重新定義評估基準。

第三，Agent 的能力存在邊界。例如在數據 ETL 場景中，若數據錯誤源于上游處理，Agent 無法定位根因，只能基于輸入輸出做判斷。需要明確哪些問題應由 Agent 處理，哪些應由傳統系統解決。

孫佳林：可觀測性的技術邊界取決于業務問題，但基礎設施能力（如 log、trace、metric、profiling 等）必須構建，在此基礎上結合具體業務場景和需求，看應用范圍與邊界，最終還是要回歸到解決業務問題上。

評估中的“人和流程”

孫佳林：評估是工具，但用不好也會出問題。三位有沒有遇到過“為了指標好看，反而把 Agent 帶偏”的情況？

章平：在實際使用中，常見問題是 Agent“表面完成任務但實質偏離目標”。例如在 AI 編程中，模型可能通過取巧方式快速返回結果，而非真正調用大模型完成任務，甚至通過 fallback 邏輯規避失敗。此時，從流程或結果看似正常，但未滿足真實需求。因此，評估不能僅依賴任務完成度，還需引入代碼質量、安全性、規范性等多維指標，從而全面衡量效果。

李昌昊：單一指標容易失效，這與經典的“指標異化”現象一致。應采用多維指標，并盡量使用獨立數據源進行評估，例如運行時數據或業務數據，而非完全依賴 Agent 自身輸出。同時，也可以通過多 Agent 交叉驗證提高可靠性。

孫佳林：整體思路是采用多維、多階段評估，包括過程追蹤、節點分析及結果指標，避免僅以單一結果衡量整體效果。

孫佳林：Agent 出問題了，是算法團隊的事，還是 SRE 團隊的事？如果是因為模型幻覺，算法說“這是概率問題”；如果是因為 API 超時，SRE 說“這是外部依賴”——最后誰給業務方一個交代？”

陳自欣：關于責任歸屬問題，目前階段更適合以探索為主，而非嚴格定責。Agent 仍處于發展階段，依賴復雜、穩定性有限，應允許一定試錯空間。

孫佳林：這類似于“無責文化”（blameless culture），強調問題解決導向而非過多討論責任歸屬問題。

李昌昊：本質上，“誰負責”取決于是否有證據鏈。Agent 系統鏈路復雜，問題可能來自模型、工具或運行環境，因此需要全鏈路可觀測能力來定位問題。可觀測性的核心價值并非追責，而是定位問題與優化系統，從而提高整體可靠性與效率。

孫佳林：現在的評估還有很多人工環節（寫用例、判結果、分析原因）。未來，評估會被 AI 自動化嗎？比如讓一個“評估 Agent ”來評估“業務 Agent”？

章平：目前很多實踐本質上是“用 AI 評估 AI”，但人仍然發揮著關鍵作用。首先，在評估體系中，ground truth 與大模型評估的劃分需要人為設定規則，即哪些內容由程序基于確定性規則判斷，這一部分依賴人事先定義清晰標準。

其次，對于“好”與“不好”的判定，雖然可以交由大模型執行，但其評估標準本身必須由人基于具體業務設定，包括輸入、輸出以及過程中的推理路徑等。這些業務知識需要由人進行抽象并注入模型，使評估結果真正符合業務需求。人在其中的核心作用是將企業知識體系結構化并融入評估過程。至于 AI 是否會完全取代人，理論上大部分工作可能被替代，但最終責任仍需由人承擔。

孫佳林：AI 應當具備“監護人”機制，無論是 skill 的生產方還是 Agent 的運維方，都需要對其行為負責，包括控制其影響范圍與風險邊界。因此，人作為“監護人”的角色是不可替代的，這也是確定性工程的重要體現，通過工程化手段約束 AI 行為。

李昌昊：從另一個角度看，可觀測數據本身既是分析依據，也是訓練素材。如果完全由 AI 自動評估，會產生遞歸問題，即“誰來評估評估者”。因此，在較長時間內，“human in the loop”仍然是必要模式，由人進行最終判斷，AI 評估更多作為輔助。

陳自欣：我認為評測是 AI 落地過程中最關鍵的環節之一，其前提是具備完善的可觀測能力，能夠采集完整數據。在很多業務場景中，例如旅行助手這類 workflow 型應用，可以通過較為固定的流程配合小模型執行，再由大模型進行評估，這在成本與效果之間是可行的方案。這一模式類似傳統客服系統：通話會被錄音，但并非全部人工審核，而是結合用戶評分與抽檢機制進行評估，從而平衡成本與質量。

此外，評估不能僅停留在技術層面，還需從業務角度出發，例如用戶留存率、滿意度或凈推薦值等指標。這一點在競爭激烈的市場環境下尤為重要，因為單純降低成本而損害用戶體驗，最終會導致用戶流失。

展望未來

孫佳林：在 Agentic 時代，確定性工程會往哪走？可觀測性能不能推動 Agent 工程，從“被動”走向“主動”，甚至“自動駕駛”？請三位老師每人給一個預言。

陳自欣：在 Agentic 時代，可觀測性將成為確定性工程的核心支柱，同時也會對基礎設施帶來新的挑戰。例如，傳統指標難以衡量 Agent 的表現，因此 log 與 trace 的重要性進一步提升。

未來可能需要圍繞 Agent 構建新的基礎設施體系，例如將運行時（runtime）與可觀測能力深度結合，在無需異常時減少日志記錄，在出現問題時再動態補充上下文信息，從而降低成本并提升智能化水平。

此外，存儲能力與數據處理能力也將成為關鍵瓶頸。當這些基礎能力完善后，可觀測體系將從被動監控轉向主動診斷甚至預測。

章平：我也參考了一些 AI 的預測，普遍認為可觀測性將從事后檢測發展為實時監控甚至“免疫系統”。我認同這一趨勢，但更關鍵的問題在于成本。目前許多企業尚未重視這一領域，很大程度上是因為 token 成本過高。如果未來 token 成本大幅下降，使中小企業甚至個人都能承擔，那么可觀測與評估體系將被更廣泛采用，從而推動整個生態的發展。

李昌昊：從技術趨勢看，可觀測性可能進一步深入模型內部，例如追蹤 token 的生成來源，從訓練數據層面提升可解釋性。同時，可觀測數據也將成為模型訓練閉環的重要組成部分，用于持續優化 Agent 與模型能力。

孫佳林：未來還可能通過將多輪交互操作轉化為確定性操作（如 CLI 或標準化流程），降低不確定性，并結合多 Agent 協作與云環境，實現更復雜的自動化系統。這一方向仍有較大發展空間。

孫佳林：如果現在只能做一件事，來讓自己的 Agent 變得更“可觀測、可評估、可信任”，你會建議他們做什么？

李昌昊：從安全角度看，應將 Agent 視為“不可信進程”。由于其行為難以完全預測，需要建立獨立于 Agent 本身的審計體系，不僅依賴其輸出，還需從外部視角驗證其行為。

章平：在企業場景中，安全問題尤為關鍵。一個可行思路是通過統一網關管理 Agent 對內部系統（如數倉、ERP）的訪問，將所有調用集中到網關層，并在網關中配置安全策略。例如，可通過策略控制 Agent 能訪問哪些系統，從而避免在 Agent 內部逐一實現安全控制。

陳自欣：從架構角度看，Agent 應依托企業級 AI 網關或升級版 SOA 總線運行，并配套完整的權限體系與安全策略。這些在傳統系統中成熟的機制，在 AI 時代依然適用。

孫佳林：這一體系類似于微服務時代的 Mesh 架構，在 Agent 時代可能演變為統一的 AI 網關，用于統一執行策略控制、行為約束與風險管理，是實現“護欄機制”的關鍵基礎設施。

觀眾：在企業里面龍蝦的實際使用實踐有嗎？比如安全、可觀測、自動部署。

陳自欣：龍蝦本質上是一個高度靈活的系統，其中安全是最核心的挑戰之一。在企業中部署時，必須將其運行在網絡受控的沙箱環境中，這是基本前提。在該環境內，需要對網絡策略進行嚴格管控，例如禁止在同一 IP 段內進行橫向掃描，實現基礎的網絡隔離，這在實踐中通常通過類似 Docker 的容器化技術來完成。同時，龍蝦的調用中心（call hub）必須指向企業內部受控且安全的地址，并結合 API 網關或 MCP 網關，對路由與權限進行統一管控。

觀眾：請問使用現有的 Agent，還是自己搭建 Agent 更合適？

章平：我早年在集成商從事投標工作，當時流程較為繁重。在 Agent 時代，不同企業的業務流程差異較大，例如招標流程往往各不相同。更合理的方式是將企業內部已有流程抽象為標準操作流程（SOP），再封裝為對應的 skill，集成到個人或企業的 Agent 系統中。這相當于構建一個定制化的 Agent，可以顯著提升實際工作效率。相比之下，通用 Agent 雖然可以提供基礎信息檢索能力，但其輸出往往較為泛化，難以滿足具體業務的專業需求。

觀眾：MCP 與 skills 的本質區別是什么？

孫佳林：MCP 是連接 AI 與外部世界的“協議”，而 skills 是 AI 能夠調用的具體“能力”。MCP server 是能力發布方，核心職責是向 AI 客戶端聲明自己擁有哪些能力，它定義了“能干什么”。Skills 是能力的實現方，是具體的業務邏輯和執行代碼，它定義了“如何做”。

觀眾：可觀測是否等同于對云平臺的監控？

陳自欣：可觀測的范圍遠不止云平臺。早期主要集中在基礎設施層（Infra），隨后擴展到應用性能監控（APM），再到業務層觀測，如今已經延伸到 Agent 層面。本質上，可觀測是由 metrics、logs 和 trace 等多種數據形式構成的綜合能力，通過被觀測對象主動輸出數據，從而支持多維度分析與問題定位，因此它是一個多層級、組合式的體系。

孫佳林：可以簡單理解為，監控回答的是“哪里出了問題”，而可觀測不僅回答“為什么出問題”，還可以進一步支持分析“應該如何解決”，其能力更加全面多維。

觀眾：博物館等文化單位部署 AI 或 Agent 時，是否可以在保證數據安全的前提下離線部署？

陳自欣：對于這類機構，由于其對信息安全要求較高，部署方案需要更加謹慎，建議優先咨詢相關主管部門或參照安全規范，以確保合規性，避免潛在風險。

觀眾：OpenClaw 安裝在空機器上，并對存儲路徑做權限控制后，Agent 是否還能正常工作？

陳自欣：從實踐來看，如果希望 OpenClaw 發揮較好效果，通常需要賦予較高權限，“開放越多，能力越強”。如果需要更細粒度的控制，可以結合操作系統層面的目錄權限進行限制，或者查看 OpenClaw 本身是否提供更精細的權限管理機制。不過在實際使用中，很多人會選擇直接開放全部權限以簡化使用。

孫佳林：我個人也是開放較多權限，但這確實存在風險。

陳自欣：確實如此，因此使用時必須清楚自身操作帶來的影響，這一點往往也是最難做到的。

孫佳林：建議在非工作電腦或沙箱環境中運行。

陳自欣：實踐中我通常會采用“實驗環境 + 生產環境”的方式，先在隔離環境中驗證，再逐步遷移到正式環境。

觀眾：未來 Agent 是否會具備較強的通用性，例如少量 Agent 覆蓋大部分業務場景？

李昌昊：我認為這是一個必然趨勢。當前無論是通用 Agent 還是代碼類 Agent，其通用能力都在持續增強，通過疊加不同 Skill，理論上可以覆蓋絕大多數業務場景。

孫佳林：從企業實踐來看，通用化和生產化仍面臨安全、資源利用率以及分布式記憶等挑戰，但整體趨勢確實是朝著通用化和生產化發展。

陳自欣：目前 MCP 尚未具備漸進式披露的能力，在加載后導致上下文臃腫的情況，消耗大量的 token 。未來 MCP 可能有兩個走向， 第一是重要性下降，只在留在部分場景的使用，而不是唯一的選擇，二是協議本身進行重構，但未來的走勢仍需觀察。

章平：在實際應用中，企業通常會同時使用 MCP 和 Skill：前者用于通用能力，例如數據接口；后者用于業務定制，實現更垂直的功能。

陳自欣： 可以進一步理解為，MCP 更適用于探索階段，用于靈活調用與試錯；而當流程穩定后，則會將其固化為 Skill，通過 API 或代碼直接調用執行。可以將 MCP 視為“探索工具”，Skill 視為“執行工具”，兩者在不同階段各有價值。

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。