1. 從跑通Demo到敢上生產(chǎn)AgentOps到底卡在哪大模型應(yīng)用這兩年最魔幻的地方在于Demo階段驚艷全場(chǎng)上線之后一地雞毛。我自己帶過(guò)幾個(gè)AI Agent項(xiàng)目從最開(kāi)始的單輪問(wèn)答到后來(lái)的多工具編排、多智能體協(xié)作幾乎每一個(gè)都經(jīng)歷過(guò)同一個(gè)階段本地跑得好好的一放到真實(shí)流量里就開(kāi)始出各種玄學(xué)問(wèn)題——回答突然變慢、工具調(diào)用莫名其妙失敗、同一個(gè)問(wèn)題兩次回答完全不一樣、Token消耗像脫韁的野馬。這些問(wèn)題的共同點(diǎn)是傳統(tǒng)監(jiān)控體系根本看不見(jiàn)它們。你拿APM去看一個(gè)Agent服務(wù)CPU、內(nèi)存、QPS、錯(cuò)誤率全都正常但用戶就是在罵街。因?yàn)锳gent的健康不在系統(tǒng)層而在推理鏈路層——Prompt怎么拼的、檢索召回了什么、工具調(diào)了幾次、模型返回了什么、Token燒了多少、這一步為什么走了這條分支。這就是AgentOps要解決的問(wèn)題。AgentOps可以理解為面向AI Agent的運(yùn)維體系它把LLM調(diào)用、工具執(zhí)行、檢索增強(qiáng)、多智能體協(xié)作這些環(huán)節(jié)全部納入可觀測(cè)范圍讓一個(gè)Agent的每一次決策過(guò)程都能被追蹤、被回放、被量化。而觀測(cè)云這類平臺(tái)恰好提供了承載這套體系的底座統(tǒng)一的指標(biāo)、日志、鏈路追蹤、事件告警再加上對(duì)LLM語(yǔ)義數(shù)據(jù)的原生支持。這篇文章不講概念科普我想把從0到1搭一套AgentOps體系的完整思路拆開(kāi)講——包括埋什么點(diǎn)、怎么埋、數(shù)據(jù)怎么組織、告警怎么設(shè)、踩過(guò)哪些坑。適合已經(jīng)跑通過(guò)Agent Demo、準(zhǔn)備往生產(chǎn)推的開(kāi)發(fā)者也適合正在做企業(yè)級(jí)AI應(yīng)用平臺(tái)、需要給上層業(yè)務(wù)提供可觀測(cè)能力的平臺(tái)團(tuán)隊(duì)。2. 先想清楚Agent的可觀測(cè)對(duì)象和傳統(tǒng)服務(wù)完全不是一回事2.1 傳統(tǒng)APM的三個(gè)盲區(qū)在動(dòng)手埋點(diǎn)之前必須先把認(rèn)知掰過(guò)來(lái)。傳統(tǒng)APM監(jiān)控的是請(qǐng)求-響應(yīng)這個(gè)黑盒它關(guān)心的是延遲、錯(cuò)誤、吞吐。但Agent的執(zhí)行過(guò)程是一個(gè)有狀態(tài)的、多步的、帶決策的鏈路傳統(tǒng)APM至少有三個(gè)盲區(qū)第一個(gè)盲區(qū)是語(yǔ)義盲區(qū)。一個(gè)HTTP 200的響應(yīng)在APM里是成功的但內(nèi)容可能是模型胡編的、答非所問(wèn)的、或者觸發(fā)了安全策略被截?cái)嗟?。系統(tǒng)層看不到回答質(zhì)量。第二個(gè)盲區(qū)是鏈路盲區(qū)。一次用戶提問(wèn)背后可能是意圖識(shí)別 → 檢索知識(shí)庫(kù) → 重排 → 拼Prompt → 調(diào)LLM → 解析工具調(diào)用 → 執(zhí)行工具 → 再調(diào)LLM → 生成最終答案。這中間任何一步出問(wèn)題APM只會(huì)告訴你這個(gè)請(qǐng)求耗時(shí)3秒但不會(huì)告訴你3秒里哪一步占了2.8秒。第三個(gè)盲區(qū)是成本盲區(qū)。LLM調(diào)用是按Token計(jì)費(fèi)的一個(gè)Agent如果陷入工具調(diào)用循環(huán)可能一次請(qǐng)求燒掉幾萬(wàn)Token。傳統(tǒng)監(jiān)控里這只是一次普通的函數(shù)調(diào)用賬單出來(lái)才知道疼。2.2 AgentOps要觀測(cè)的四類數(shù)據(jù)想清楚盲區(qū)之后AgentOps的觀測(cè)對(duì)象就清晰了。我一般把它分成四類數(shù)據(jù)類型具體內(nèi)容用途Trace鏈路一次Agent執(zhí)行的完整Span樹(shù)含每步輸入輸出問(wèn)題定位、回放Metric指標(biāo)延遲、Token數(shù)、工具調(diào)用次數(shù)、成功率趨勢(shì)監(jiān)控、容量規(guī)劃Log日志Prompt原文、模型原始返回、異常堆棧深度排查Event事件工具失敗、超時(shí)、內(nèi)容攔截、成本超閾值實(shí)時(shí)告警這四類數(shù)據(jù)在觀測(cè)云里對(duì)應(yīng)不同的數(shù)據(jù)類型但關(guān)鍵是它們要能通過(guò)同一個(gè)Trace ID串起來(lái)。否則你看到指標(biāo)異常卻找不到對(duì)應(yīng)的日志排查效率會(huì)大打折扣。2.3 一個(gè)反直覺(jué)的結(jié)論不是埋得越多越好新手容易犯的錯(cuò)是全埋。Prompt全文、模型完整返回、每一次檢索的Top100文檔全都塞進(jìn)可觀測(cè)平臺(tái)。結(jié)果就是存儲(chǔ)成本爆炸、查詢慢如蝸牛、真正有用的信號(hào)被淹沒(méi)。我的經(jīng)驗(yàn)是分層埋點(diǎn)核心鏈路LLM調(diào)用、工具執(zhí)行全量埋中間數(shù)據(jù)檢索結(jié)果、重排分?jǐn)?shù)采樣埋原始大文本完整Prompt、完整文檔只在異常時(shí)落盤(pán)。這個(gè)策略后面會(huì)詳細(xì)講怎么落地。3. 埋點(diǎn)設(shè)計(jì)把一次Agent執(zhí)行拆成可追蹤的Span樹(shù)3.1 Span的粒度怎么定埋點(diǎn)的第一步是確定Span的粒度。Span太粗定位不到問(wèn)題Span太細(xì)鏈路圖變成毛線團(tuán)。我一般按一次有意義的決策或一次外部調(diào)用來(lái)切分用戶請(qǐng)求入口一個(gè)Root Span意圖識(shí)別/路由一個(gè)Span每次檢索向量檢索、關(guān)鍵詞檢索各一個(gè)Span重排一個(gè)Span每次LLM調(diào)用一個(gè)Span這是最關(guān)鍵的每次工具調(diào)用一個(gè)Span多智能體之間的消息傳遞一個(gè)Span這樣一次典型的RAG Agent執(zhí)行大概會(huì)產(chǎn)生8-15個(gè)Span。這個(gè)粒度既能看清全貌又不會(huì)太碎。3.2 每個(gè)Span必須帶的屬性Span光有名字沒(méi)用必須帶足夠的屬性才能支撐后續(xù)分析。以LLM調(diào)用Span為例我固定會(huì)帶這些字段span.set_attribute(llm.provider, openai) # 或 anthropic / 本地模型 span.set_attribute(llm.model, gpt-4o) span.set_attribute(llm.request.type, chat) span.set_attribute(llm.prompt.tokens, prompt_tokens) span.set_attribute(llm.completion.tokens, completion_tokens) span.set_attribute(llm.total.tokens, total_tokens) span.set_attribute(llm.latency.ms, latency) span.set_attribute(llm.finish_reason, finish_reason) # stop / length / tool_calls span.set_attribute(llm.temperature, temperature) span.set_attribute(llm.stream, is_stream) span.set_attribute(agent.step, step_index) # 第幾步 span.set_attribute(agent.session_id, session_id)工具調(diào)用Span則帶span.set_attribute(tool.name, search_knowledge_base) span.set_attribute(tool.input.size, len(json.dumps(tool_input))) span.set_attribute(tool.success, success) span.set_attribute(tool.retry.count, retry_count) span.set_attribute(tool.latency.ms, latency)這些字段看起來(lái)瑣碎但它們是后面做聚合分析的基礎(chǔ)。比如你想知道哪個(gè)工具最容易失敗直接按tool.name分組統(tǒng)計(jì)tool.successfalse就行。3.3 Trace ID的透?jìng)魇巧€這里有個(gè)特別容易踩的坑Trace ID在異步和流式場(chǎng)景下會(huì)斷。Agent大量使用異步調(diào)用和流式輸出如果不在每個(gè)異步任務(wù)、每個(gè)回調(diào)里顯式傳遞上下文Span就會(huì)變成孤兒鏈路圖直接斷掉。我的做法是在請(qǐng)求入口生成一個(gè)session_id和trace_id然后通過(guò)上下文變量Python里用contextvarsJava里用ThreadLocal或Reactor的Context一路透?jìng)?。流式?chǎng)景下每個(gè)chunk的處理都要帶上這個(gè)上下文。觀測(cè)云的SDK支持OpenTelemetry標(biāo)準(zhǔn)用標(biāo)準(zhǔn)的Context傳播機(jī)制就能解決。提示如果你的Agent用了消息隊(duì)列做異步編排記得把Trace上下文塞進(jìn)消息頭里消費(fèi)端再還原出來(lái)。否則跨服務(wù)的鏈路會(huì)斷成兩截。3.4 采樣策略別讓可觀測(cè)拖垮生產(chǎn)全量埋點(diǎn)的成本在流量上來(lái)之后會(huì)非常嚇人。我的采樣策略是分層的錯(cuò)誤全采任何Span標(biāo)記為error100%上報(bào)慢請(qǐng)求全采超過(guò)P95延遲的請(qǐng)求100%上報(bào)正常請(qǐng)求采樣按5%-10%采樣大文本按需Prompt全文、檢索文檔只在錯(cuò)誤或慢請(qǐng)求時(shí)落盤(pán)這個(gè)策略在觀測(cè)云里可以通過(guò)SDK的采樣器配置也可以在后端用處理規(guī)則實(shí)現(xiàn)。實(shí)測(cè)下來(lái)存儲(chǔ)成本能降70%以上但排查問(wèn)題時(shí)該有的數(shù)據(jù)一個(gè)不少。4. 指標(biāo)體系建設(shè)從Token賬單到Agent健康度4.1 四層指標(biāo)體系埋點(diǎn)數(shù)據(jù)上來(lái)之后要把它組織成有意義的指標(biāo)。我一般分四層第一層資源層。LLM調(diào)用的QPS、延遲分布、錯(cuò)誤率、Token消耗速率。這層最接近傳統(tǒng)監(jiān)控用來(lái)判斷系統(tǒng)是否健康。第二層鏈路層。單次Agent執(zhí)行的平均Span數(shù)、平均步數(shù)、工具調(diào)用次數(shù)分布、檢索命中率。這層用來(lái)判斷Agent的執(zhí)行效率。第三層質(zhì)量層?；卮鸩杉{率、用戶追問(wèn)率、工具調(diào)用成功率、內(nèi)容攔截率。這層需要業(yè)務(wù)側(cè)配合埋點(diǎn)但價(jià)值最高。第四層成本層。單次請(qǐng)求平均Token成本、單用戶日均成本、按模型/按工具的成本拆分。這層直接關(guān)系到能不能活下去。4.2 幾個(gè)必須盯的核心指標(biāo)指標(biāo)不用多但有幾個(gè)是必須盯死的指標(biāo)計(jì)算方式告警閾值建議LLM調(diào)用P99延遲按model分組統(tǒng)計(jì) 10s 告警單請(qǐng)求Token數(shù)total_tokens的P95 閾值 告警工具調(diào)用失敗率fail/total 5% 告警Agent步數(shù)異常單請(qǐng)求Span數(shù)P99 20步 告警空回答率回答長(zhǎng)度為0的占比 2% 告警循環(huán)檢測(cè)同一工具連續(xù)調(diào)用3次立即告警其中循環(huán)檢測(cè)這個(gè)指標(biāo)特別重要。Agent陷入工具調(diào)用死循環(huán)是生產(chǎn)環(huán)境最常見(jiàn)的故障之一一次循環(huán)可能燒掉幾十萬(wàn)Token。我的做法是在Agent執(zhí)行器里加一個(gè)計(jì)數(shù)器同一個(gè)工具連續(xù)調(diào)用超過(guò)3次就強(qiáng)制中斷并上報(bào)事件。4.3 Token成本的可視化拆分Token成本這塊光看總數(shù)沒(méi)用必須能拆。我一般按三個(gè)維度拆按模型拆GPT-4o和本地小模型的成本差幾十倍要能看出各自占比按Agent拆哪個(gè)Agent最燒錢(qián)按用戶/租戶拆如果是SaaS要能定位到具體客戶觀測(cè)云的自定義指標(biāo)能力可以支持這種多維拆分。關(guān)鍵是在埋點(diǎn)時(shí)就把這些維度作為T(mén)ag打進(jìn)去后面聚合才方便。4.4 用儀表盤(pán)把Agent健康度講清楚指標(biāo)最終要落到儀表盤(pán)上。我給團(tuán)隊(duì)做的Agent健康度大盤(pán)固定包含這幾塊頂部是總覽卡片今日請(qǐng)求數(shù)、成功率、平均延遲、總Token消耗、預(yù)估成本。中間是趨勢(shì)圖延遲P50/P95/P99、Token消耗趨勢(shì)、錯(cuò)誤率趨勢(shì)。下面是明細(xì)表Top10慢請(qǐng)求、Top10高Token請(qǐng)求、工具失敗排行。這個(gè)大盤(pán)每天早上團(tuán)隊(duì)站會(huì)看一眼基本能判斷昨天Agent跑得怎么樣。有異常直接點(diǎn)進(jìn)去看Trace效率比翻日志高太多。5. 告警與根因定位讓問(wèn)題在用戶投訴前暴露5.1 告警規(guī)則怎么設(shè)才不擾民告警設(shè)得太松天天響團(tuán)隊(duì)會(huì)麻木設(shè)得太緊真出事了沒(méi)反應(yīng)。我的經(jīng)驗(yàn)是分級(jí)告警P0立即處理LLM調(diào)用失敗率10%、Agent循環(huán)檢測(cè)觸發(fā)、成本突增300%P11小時(shí)內(nèi)處理P99延遲10s、工具失敗率5%、空回答率2%P2當(dāng)天處理Token消耗環(huán)比增長(zhǎng)50%、檢索命中率下降P0告警直接打電話P1發(fā)群消息P2進(jìn)日?qǐng)?bào)。這樣既不會(huì)漏掉嚴(yán)重問(wèn)題也不會(huì)被噪音淹沒(méi)。5.2 從告警到根因的排查鏈路告警響了之后排查路徑要清晰。我總結(jié)的鏈路是告警 → 指標(biāo)下鉆 → Trace定位 → 日志確認(rèn) → 修復(fù)驗(yàn)證。舉個(gè)例子告警說(shuō)LLM調(diào)用P99延遲突增。第一步在儀表盤(pán)上按model分組看發(fā)現(xiàn)是某個(gè)特定模型的問(wèn)題。第二步點(diǎn)進(jìn)慢請(qǐng)求的Trace發(fā)現(xiàn)是Prompt特別長(zhǎng)檢索召回了太多文檔。第三步看檢索Span的日志發(fā)現(xiàn)是某個(gè)查詢觸發(fā)了全量掃描。第四步修復(fù)檢索邏輯加過(guò)濾條件。第五步觀察指標(biāo)恢復(fù)。這條鏈路能跑通的前提是前面埋點(diǎn)和指標(biāo)都做到位了。所以AgentOps是個(gè)系統(tǒng)工程不能指望某一個(gè)環(huán)節(jié)解決所有問(wèn)題。5.3 一個(gè)真實(shí)的排查案例說(shuō)個(gè)我印象最深的。有段時(shí)間用戶反饋Agent有時(shí)候答非所問(wèn)但監(jiān)控指標(biāo)全都正常。后來(lái)我們?cè)谫|(zhì)量層加了一個(gè)回答與問(wèn)題相關(guān)性的采樣評(píng)估才發(fā)現(xiàn)問(wèn)題出在檢索環(huán)節(jié)某些查詢的向量檢索返回了完全不相關(guān)的文檔但重排分?jǐn)?shù)卻很高導(dǎo)致模型基于錯(cuò)誤上下文生成答案。這個(gè)問(wèn)題的根因是重排模型的輸入格式和訓(xùn)練時(shí)不一致。如果沒(méi)有鏈路級(jí)的可觀測(cè)這種問(wèn)題幾乎不可能定位——因?yàn)閺南到y(tǒng)層看一切正常。注意Agent的很多問(wèn)題不是錯(cuò)誤而是錯(cuò)誤的內(nèi)容。所以質(zhì)量層的可觀測(cè)不能省哪怕它需要額外的評(píng)估成本。5.4 告警的降噪與聚合生產(chǎn)環(huán)境告警多了之后必須做聚合。比如一次模型服務(wù)抖動(dòng)可能瞬間產(chǎn)生幾百條告警。觀測(cè)云支持告警聚合和抑制規(guī)則我的配置是同一根因的告警5分鐘內(nèi)合并為一條關(guān)聯(lián)告警如延遲高和超時(shí)多合并展示。這樣團(tuán)隊(duì)收到的告警數(shù)量能降一個(gè)數(shù)量級(jí)但關(guān)鍵信息不丟。6. 落地過(guò)程中的坑我踩過(guò)的五個(gè)真實(shí)教訓(xùn)6.1 坑一Prompt里帶了敏感信息早期我們圖省事把完整Prompt直接上報(bào)到可觀測(cè)平臺(tái)。結(jié)果有一次排查問(wèn)題時(shí)發(fā)現(xiàn)Prompt里包含了用戶的手機(jī)號(hào)、訂單號(hào)甚至有一次帶上了內(nèi)部API的鑒權(quán)頭。這是嚴(yán)重的安全隱患。修復(fù)方案是上報(bào)前脫敏在SDK層加一個(gè)過(guò)濾器對(duì)Prompt和模型返回做正則替換把手機(jī)號(hào)、身份證、郵箱、密鑰模式全部打碼。觀測(cè)云支持在數(shù)據(jù)接入時(shí)配置處理規(guī)則但更穩(wěn)妥的做法是在客戶端就脫敏避免敏感數(shù)據(jù)出網(wǎng)。6.2 坑二流式響應(yīng)的Span收尾時(shí)機(jī)流式輸出場(chǎng)景下Span什么時(shí)候結(jié)束是個(gè)問(wèn)題。如果等第一個(gè)chunk就結(jié)束那延遲數(shù)據(jù)完全不準(zhǔn)如果等最后一個(gè)chunk那中間如果連接斷了Span可能永遠(yuǎn)不結(jié)束。我的做法是Span在收到第一個(gè)chunk時(shí)記錄first_token_latency在流結(jié)束時(shí)記錄total_latency并設(shè)置一個(gè)超時(shí)兜底比如60秒無(wú)數(shù)據(jù)就強(qiáng)制結(jié)束Span并標(biāo)記異常。這樣兩個(gè)延遲指標(biāo)都能拿到也不會(huì)出現(xiàn)懸掛Span。6.3 坑三多智能體協(xié)作的鏈路爆炸多智能體場(chǎng)景下Agent之間互相調(diào)用Span樹(shù)會(huì)變得非常深。如果不加控制一次請(qǐng)求可能產(chǎn)生上百個(gè)Span鏈路圖根本沒(méi)法看。我的處理方式是分層聚合單個(gè)Agent內(nèi)部的Span保持細(xì)粒度Agent之間的調(diào)用用一個(gè)協(xié)作Span包起來(lái)只記錄關(guān)鍵信息發(fā)起方、接收方、消息摘要、耗時(shí)。這樣鏈路圖保持在可讀的層級(jí)。6.4 坑四指標(biāo)基數(shù)爆炸給Span打Tag的時(shí)候如果不小心把高基數(shù)的字段比如用戶ID、請(qǐng)求ID打成Tag指標(biāo)基數(shù)會(huì)爆炸查詢直接卡死。我踩過(guò)一次把session_id打成了指標(biāo)Tag結(jié)果一天產(chǎn)生了幾百萬(wàn)個(gè)時(shí)間序列。教訓(xùn)是高基數(shù)維度只放在Trace里不要放進(jìn)Metric。指標(biāo)Tag只保留低基數(shù)的枚舉值比如model、tool_name、status。6.5 坑五可觀測(cè)本身的性能開(kāi)銷埋點(diǎn)是有成本的。SDK的序列化、網(wǎng)絡(luò)上報(bào)、上下文切換都會(huì)占用資源。我們?cè)缙谟猛缴蠄?bào)結(jié)果Agent的延遲被拉高了15%。后來(lái)改成異步批量上報(bào)Span先在內(nèi)存緩沖攢夠一批或到時(shí)間窗口再統(tǒng)一發(fā)送。同時(shí)把上報(bào)線程和業(yè)務(wù)線程隔離避免互相影響。改完之后開(kāi)銷降到3%以內(nèi)基本可以接受。7. 從單Agent到多智能體可觀測(cè)體系的擴(kuò)展思路7.1 單Agent時(shí)代的觀測(cè)重點(diǎn)單Agent場(chǎng)景相對(duì)簡(jiǎn)單觀測(cè)重點(diǎn)在LLM調(diào)用質(zhì)量和工具執(zhí)行可靠性。這時(shí)候指標(biāo)體系可以輕一點(diǎn)Trace粒度可以細(xì)一點(diǎn)因?yàn)镾pan總數(shù)不多。7.2 多智能體帶來(lái)的新挑戰(zhàn)多智能體一上來(lái)問(wèn)題就復(fù)雜了。首先是鏈路變長(zhǎng)一次任務(wù)可能經(jīng)過(guò)五六個(gè)Agent接力其次是狀態(tài)難追蹤每個(gè)Agent有自己的上下文出問(wèn)題時(shí)不知道是哪個(gè)環(huán)節(jié)傳錯(cuò)了最后是成本難歸因一個(gè)任務(wù)燒的錢(qián)要分?jǐn)偟蕉鄠€(gè)Agent上。我的應(yīng)對(duì)策略是引入任務(wù)級(jí)Trace在任務(wù)入口生成一個(gè)task_id所有參與的Agent的Span都掛在這個(gè)task下。同時(shí)給每個(gè)Agent的輸入輸出做摘要記錄這樣即使鏈路很長(zhǎng)也能快速看出信息在哪一步失真了。7.3 協(xié)作質(zhì)量的可觀測(cè)多智能體最怕的是互相甩鍋——A說(shuō)B給的信息不對(duì)B說(shuō)A的指令不清。要解決這個(gè)需要在Agent之間的消息傳遞上加觀測(cè)記錄消息的原始內(nèi)容、接收方的解析結(jié)果、是否觸發(fā)重試。我一般會(huì)統(tǒng)計(jì)幾個(gè)協(xié)作指標(biāo)消息傳遞成功率、消息解析失敗率、協(xié)作輪次分布、任務(wù)完成率。這些指標(biāo)能反映多智能體系統(tǒng)的整體健康度。7.4 面向未來(lái)的擴(kuò)展評(píng)估與反饋閉環(huán)AgentOps的終極形態(tài)不只是看還要能評(píng)和改。我現(xiàn)在在做的方向是把可觀測(cè)數(shù)據(jù)和評(píng)估體系打通線上采樣的Trace自動(dòng)進(jìn)入評(píng)估隊(duì)列用LLM-as-Judge或人工標(biāo)注打分評(píng)估結(jié)果反哺到Prompt優(yōu)化和模型選型。這個(gè)閉環(huán)一旦跑通Agent的迭代速度會(huì)快很多——因?yàn)槟阒栏哪睦?、改完有沒(méi)有效果而不是憑感覺(jué)調(diào)Prompt。8. 一些實(shí)操層面的經(jīng)驗(yàn)補(bǔ)充8.1 工具選型的取舍可觀測(cè)平臺(tái)的選擇上我傾向于用統(tǒng)一平臺(tái)而不是拼湊多個(gè)工具。原因是Agent的數(shù)據(jù)關(guān)聯(lián)性太強(qiáng)Trace、Metric、Log、Event必須能互相跳轉(zhuǎn)。如果分散在四個(gè)系統(tǒng)里排查一次問(wèn)題要開(kāi)四個(gè)頁(yè)面效率極低。觀測(cè)云這類一體化平臺(tái)的優(yōu)勢(shì)就在這里。SDK層面優(yōu)先選支持OpenTelemetry標(biāo)準(zhǔn)的這樣將來(lái)?yè)Q平臺(tái)成本低。LLM調(diào)用這塊Langfuse、Phoenix這類專用工具也可以作為補(bǔ)充但核心鏈路還是建議走統(tǒng)一的可觀測(cè)體系。8.2 團(tuán)隊(duì)協(xié)作的約定AgentOps落地不只是技術(shù)問(wèn)題還是協(xié)作問(wèn)題。我們團(tuán)隊(duì)有幾個(gè)約定所有新增Agent必須接入埋點(diǎn)SDK才能上線所有P0告警必須有明確的on-call負(fù)責(zé)人每周復(fù)盤(pán)一次告警和慢請(qǐng)求把共性問(wèn)題沉淀成規(guī)則。這些約定看起來(lái)瑣碎但能保證可觀測(cè)體系不會(huì)隨著項(xiàng)目推進(jìn)而荒廢。8.3 成本控制的幾個(gè)小技巧最后分享幾個(gè)控制可觀測(cè)成本的小技巧一是用列式存儲(chǔ)存Trace壓縮率高二是對(duì)歷史數(shù)據(jù)做分級(jí)存儲(chǔ)7天內(nèi)熱存30天后轉(zhuǎn)冷三是定期清理無(wú)用的Tag和指標(biāo)避免基數(shù)膨脹四是采樣策略動(dòng)態(tài)調(diào)整流量高峰期降采樣率。這些技巧單獨(dú)看都是小優(yōu)化但疊加起來(lái)能把可觀測(cè)成本壓到總成本的5%以內(nèi)對(duì)于要長(zhǎng)期跑的Agent系統(tǒng)來(lái)說(shuō)很關(guān)鍵。我在實(shí)際項(xiàng)目里最深的一個(gè)體會(huì)是AgentOps不是上線之后才考慮的事而是從設(shè)計(jì)Agent架構(gòu)時(shí)就要一起想。埋點(diǎn)、Trace透?jìng)?、指?biāo)定義這些東西后期補(bǔ)的代價(jià)遠(yuǎn)大于前期設(shè)計(jì)。所以如果你現(xiàn)在正在從0到1搭A(yù)gent建議把可觀測(cè)當(dāng)成一等公民來(lái)對(duì)待而不是等出問(wèn)題了再回頭補(bǔ)。