有些情況下，步驟2~3也會(huì)反復(fù)出現(xiàn)探橱，并且3也不一定Linux OS申屹，也可能是其他類型的運(yùn)維對(duì)象。

langchain是一個(gè)能夠給大模型加裝調(diào)用工具的框架隧膏，其核心原理就是 ReAct（Reasoning and Acting）哗讥，這部分原理我們?cè)诘谝黄幸呀?jīng)講述，在這里就不再展開(kāi)了胞枕。

我們這里講講這個(gè)運(yùn)維診斷的場(chǎng)景杆煞，我們需要如何基于langchain構(gòu)建這個(gè)智能體。

首先根據(jù)我們剛剛場(chǎng)景的分析腐泻，我們可以知道需要一個(gè)查日志的工具决乎、一個(gè)能夠執(zhí)行命令的工具。于是我們構(gòu)建了下面這些工具：

image.png

為了方便讀者深入探索派桩，診斷工具代碼開(kāi)源如下：

https://github.com/alibaba/sreworks-ext/blob/master/aibond/cases/hdfs-analyse/hdfscluster.py

這個(gè)時(shí)候有些同學(xué)就會(huì)有疑問(wèn)了构诚，這都有exec_command能執(zhí)行任何命令了，再給一些namenode_log铆惑、get_local_disk_free這樣的命令不是畫蛇添足嗎范嘱？事實(shí)上员魏，在實(shí)際使用過(guò)程中，我們發(fā)現(xiàn)工具給得越具體受裹，最終效果越好。這個(gè)特點(diǎn)大模型其實(shí)和我們?nèi)耸且粯拥模捍蟛糠诌\(yùn)維問(wèn)題都能用Linux命令解決虏束，但為什么還要封裝運(yùn)維工具？不就是為了少去記幾個(gè)命令，使得運(yùn)維專家能專注于關(guān)鍵問(wèn)題闷袒，不用去思考剛剛輸入的運(yùn)維命令是不是少了個(gè)符號(hào)坑律。

如果打開(kāi)代碼仔細(xì)看的讀者，可能會(huì)發(fā)現(xiàn)一個(gè)細(xì)節(jié)：我們的這些tool和langchain的原生tool并不完全相同冀值。我們?cè)趌angchain框架之上引入了一層class的概念宫屠，使得tool不再是普通的function浪蹂，而是可以做class實(shí)例化的function。

我們?cè)诘谝黄恼轮泄啪ⅲ岬竭^(guò)這樣的面向?qū)ο蟮腁I編程方法产艾，之前大家讀到的時(shí)候可能還不太有體感闷堡，當(dāng)前的這個(gè)場(chǎng)景我可以舉個(gè)例子疑故，這種面向?qū)ο蠓绞骄幊痰膬?yōu)越性焰扳。

HDFS集群的每個(gè)Node通常不能直接登錄，需要先登錄到跳板機(jī)上扫茅，然后再登錄到每臺(tái)機(jī)器上育瓜。這就使得每次函數(shù)調(diào)用都必須包含跳板機(jī)的IP躏仇，比如查詢?nèi)罩镜暮瘮?shù)就會(huì)變成：

namenode_log(gateway_host, host)

這時(shí)候大家平時(shí)編程時(shí)有體會(huì)焰手，如果一個(gè)函數(shù)中有兩個(gè)類似格式的入?yún)⒆兞渴槠蓿绻麤](méi)有IDE提示輔助，很容易會(huì)搞錯(cuò)變量的位置见间。

同樣的問(wèn)題一樣會(huì)發(fā)生在大模型上米诉，所以面向?qū)ο蟮暮瘮?shù)調(diào)用同樣對(duì)大模型有友好史侣，如果函數(shù)變成面向?qū)ο蟮膶懛ǖ种希湍茉黾哟竽Ｐ驼{(diào)用函數(shù)的成功率：

cluster = new HDFSCluster(gateway_host)

三李皇、HDFS集群智能體診斷實(shí)戰(zhàn)

構(gòu)建完成簡(jiǎn)單的智能體工程框架后之后掉房，我們就要用來(lái)試試它是不是能真正地幫我們解決問(wèn)題：我們先人為構(gòu)造一個(gè)故障，然后看智能體能否分析出這個(gè)故障瘾杭。

本次實(shí)戰(zhàn)系列中的實(shí)驗(yàn)的3節(jié)點(diǎn)HDFS集群為開(kāi)源大數(shù)據(jù)平臺(tái) E-MapReduce購(gòu)買后一鍵搭建獲得:

image.png

為了方便讀者同樣能夠復(fù)現(xiàn)本次實(shí)戰(zhàn)內(nèi)容，我們同樣把故障注入工具的代碼也進(jìn)行了開(kāi)源：

https://github.com/alibaba/sreworks-ext/blob/master/aibond/cases/hdfs-analyse/fault_injector.py這個(gè)故障注入工具能夠利用fallocate命令將硬盤打滿讨阻，使得文件系統(tǒng)無(wú)法正常讀寫钝吮。

基礎(chǔ)實(shí)驗(yàn)

為了證明智能體能夠真正分析出問(wèn)題板辽，我們來(lái)構(gòu)造這樣的3個(gè)基礎(chǔ)實(shí)驗(yàn)：

1. 集群正常運(yùn)行劲弦，向智能體提問(wèn)：這個(gè)集群正常嗎邑跪？

2. 集群中注入硬盤打滿故障，向智能體提問(wèn)：這個(gè)集群正常嗎？

3. 集群從硬盤打滿故障中恢復(fù)明棍，向智能體提問(wèn)：這個(gè)集群正常嗎寇僧？

這三個(gè)實(shí)驗(yàn)的提問(wèn)prompt均相同，不存在額外信息提示兴蒸，但集群現(xiàn)場(chǎng)完全不同橙凳，我們來(lái)看看智能體能否分析出來(lái)岛啸。

from hdfscluster import HDFSCluster
from langchain import OpenAI

ai = AI()
resp = ai.run("當(dāng)前這個(gè)集群正常嗎坚踩？", llm=OpenAI(temperature=0.2, model_name="gpt-4"), tools=[HDFSCluster("47.93.25.211")], verbose=True)
print("=== resp ===")
print(resp)

實(shí)驗(yàn)1 正常HDFS集群診斷

正常HDFS集群診斷

當(dāng)前這個(gè)集群是正常的瞬铸。

實(shí)驗(yàn)2 硬盤寫滿的故障集群診斷

我們利用故障注入工具將所有節(jié)點(diǎn)的/mnt/disk1目錄打滿嗓节。我們?cè)俅芜\(yùn)行診斷赦政，向智能體發(fā)問(wèn)恢着，看看他的返回财破。

注入硬盤寫滿故障后的第一次診斷

當(dāng)前集群存在問(wèn)題靡羡，namenode在master-1-1.c-e4814c274586e7b4.cn-beijing.emr.aliyuncs.com的節(jié)點(diǎn)上反復(fù)關(guān)閉和啟動(dòng)略步，這不是正常的行為。

這里非常有意思的事情發(fā)生了：智能體先是按部就班地進(jìn)行測(cè)試集群是否可以寫入绽诚，很不湊巧的是恰好寫入成功了恩够，那么智能體是不是會(huì)給出集群是正常的結(jié)論蜂桶？智能體保持嚴(yán)謹(jǐn)?shù)膽B(tài)度扑媚，繼續(xù)查了namenode的日志钦购，它從日志中很準(zhǔn)確地分析出押桃，集群上節(jié)點(diǎn)反復(fù)的關(guān)閉和啟動(dòng)不是正常行為唱凯。這已經(jīng)是一個(gè)非常專業(yè)的專家經(jīng)驗(yàn)了磕昼。

鑒于第一次診斷中出現(xiàn)的不確定性节猿，我們?cè)龠M(jìn)行一次診斷滨嘱，看看結(jié)果是否會(huì)有不同：

注入硬盤寫滿故障后的第二次診斷

當(dāng)前集群存在問(wèn)題吟榴，主節(jié)點(diǎn)的日志顯示它沒(méi)有可用資源囊扳，'/dev/vdb'的可用空間為0，低于配置的保留量细移。集群無(wú)法正常運(yùn)行葫哗，需要立即處理。

第二次的診斷與第一次的不同點(diǎn)在于抓取的日志出現(xiàn)了更多的線索亿扁，智能體直接從日志讀取到了/dev/vdb分區(qū)可用空間為0从祝，這條重要的線索牍陌，使得智能體給出的診斷結(jié)論更具體毒涧。

綜合兩次的診斷契讲，我們可以看出捡偏，智能體的診斷模式和人非常像：

1. 智能體能夠自主選擇工具银伟，借助工具來(lái)進(jìn)行分析彤避，有自己的推理過(guò)程看杭。

2. 單個(gè)工具可能會(huì)存在不確定性楼雹，智能體能夠通過(guò)多個(gè)工具多條線索交叉驗(yàn)證。

3. 得益于大模型前期海量的訓(xùn)練數(shù)據(jù)介却，智能體的專業(yè)知識(shí)表現(xiàn)能夠與該領(lǐng)域的專家媲美齿坷。

實(shí)驗(yàn)3 故障集群恢復(fù)后的診斷

僅僅是分析有問(wèn)題時(shí)的集群是不夠的永淌，如果集群恢復(fù)正常了遂蛀，智能體也必須要能夠分析出來(lái)李滴，于是我們進(jìn)行了實(shí)驗(yàn)3所坯。將實(shí)驗(yàn)2注入的故障全部去除芹助。

故障恢復(fù)后的診斷

當(dāng)前這個(gè)集群是正常的。

在這次智能體的診斷分析中声诸，我們發(fā)現(xiàn)即使日志數(shù)據(jù)中彼乌，有很多前面硬盤故障時(shí)候的干擾項(xiàng)慰照，它依然能夠做出準(zhǔn)確的判斷：集群是正常的毒租。說(shuō)實(shí)話墅垮，這表現(xiàn)可能已經(jīng)超越了一些運(yùn)維人員了：因?yàn)樵诠收戏治鎏幚碇兴闵ǔ?huì)伴隨看似有用的報(bào)錯(cuò)線索灾梦，而在紛雜的信息中濾掉無(wú)用信息若河，最終能拍板結(jié)論的萧福，只有一部分比較有經(jīng)驗(yàn)的專家才能做到统锤。

進(jìn)階實(shí)驗(yàn)：根因定界

在三個(gè)基礎(chǔ)實(shí)驗(yàn)中饲窿，我們可以看到智能體進(jìn)行的診斷基本都能達(dá)到甚至超過(guò)我們預(yù)期逾雄，而我們?cè)趐rompt中其實(shí)根本沒(méi)做什么鸦泳，只是問(wèn)了問(wèn)這個(gè)集群是否正常做鹰。那么如果我們將prompt中的提問(wèn)再?gòu)?fù)雜一些钾麸，是不是就能獲得更好的結(jié)果饭尝？我們嘗試了讓智能體來(lái)幫我們進(jìn)行一下問(wèn)題定界的處理--每次出線上問(wèn)題之后钥平，最頭疼的問(wèn)題就是定界涉瘾，到底是軟件本身的問(wèn)題睡汹，還是用戶使用的問(wèn)題囚巴？非常容易說(shuō)不清庶柿。我們來(lái)看看智能體是否能理清楚（我們將現(xiàn)場(chǎng)復(fù)原成注入了硬盤打滿的現(xiàn)場(chǎng)）浮庐。我們將提問(wèn)prompt變成如下的文本：

請(qǐng)幫忙診斷一下這個(gè)集群审残，并且在結(jié)論中給出根因的定界：軟件缺陷(software_bug) 或 用戶使用問(wèn)題(user_problem)搅轿，并使用JSON格式返回

{"cause": "software_bug|user_problem", "suggestion": "給出的建議"}

根因定界

{"cause": "user_problem", "suggestion": "The NameNode has no resources available, and the space available on volume '/dev/vdb' is 0, which is below the configured reserved amount. Please free up or add more resources to the volume '/dev/vdb'."}

智能體直接用JSON格式將結(jié)論給出，非常清晰地把這個(gè)問(wèn)題界定成是一個(gè)用戶使用問(wèn)題雀鹃。這個(gè)格式結(jié)構(gòu)甚至可以直接集成到工單系統(tǒng)中：如果每次用戶提工單需要排查問(wèn)題黎茎，就直接花1分鐘這樣分析一波給出結(jié)論工三，畫面有點(diǎn)太美了俭正，大家可以暢想一下。

實(shí)戰(zhàn)總結(jié)

1. 智能體借助工具排查問(wèn)題得出結(jié)論的整個(gè)過(guò)程與人類行為已經(jīng)基本沒(méi)有大的差別儿惫。
2. 智能體基本沒(méi)用exec_command這種通用工具肾请，而是選擇合適的垂直工具（get_namenodes铛铁、namenode_log等）饵逐，這點(diǎn)與人的行為非常相似掷豺。

明確好用的小工具會(huì)比大而全的工具更能提升效率和表現(xiàn)当船。
3. 大模型已有的知識(shí)數(shù)據(jù)對(duì)于專業(yè)型的分析完全夠用生年，不需要額外的知識(shí)庫(kù)。

四桌粉、智能體工程框架進(jìn)階思路

前面章節(jié)的實(shí)戰(zhàn)僅僅面向一個(gè)簡(jiǎn)單的3節(jié)點(diǎn)的HDFS集群，實(shí)際上的生產(chǎn)集群遠(yuǎn)比這個(gè)復(fù)雜押逼，因此我們需要構(gòu)建適合自己場(chǎng)景的智能體工程框架挑格。那么如何構(gòu)建呢漂彤？

智能體框架原理

剛接觸langchain的時(shí)候挫望，感覺(jué)這工程框架很神奇媳板，像是開(kāi)了掛一樣破讨，原本的大模型是不能接觸外部世界的添忘，而有了langchain的tool之后就能隨意接觸外部世界了搁骑。后來(lái)讀了ReAct的論文之后，明白了原來(lái)只要用固定的格式構(gòu)建prompt又固，就能實(shí)現(xiàn)思維鏈的效果仲器，不斷調(diào)用一些工具，去推理達(dá)成目標(biāo)仰冠。下面截取了框架最關(guān)鍵部分prompt大家自行感受一下：

System: Respond to the human as helpfully and accurately as possible. You have access to the following tools:

get_namenodes: get_namenodes() -> str - Get the namenode list of the HDFS cluster., args: {{}}
hdfs_touchz: hdfs_touchz() -> str - Create a test file in HDFS., args: {{}}
namenode_log: namenode_log(host: str) -> str - get one HDFS cluster namenode's log., args: {{'host': {{'title': 'Host', 'type': 'string'}}}}

Use a json blob to specify a tool by providing an action key (tool name) and an action_input key (tool input).

Valid "action" values: "Final Answer" or get_namenodes, hdfs_touchz, namenode_log

Provide only ONE action per $JSON_BLOB, as shown:

...
{
  "action": $TOOL_NAME,
  "action_input": $INPUT
}
...

Follow this format:

Question: input question to answer
Thought: consider previous and subsequent steps
Action:
...
$JSON_BLOB
...
Observation: action result
... (repeat Thought/Action/Observation N times)
Thought: I know what to respond
Action:
...
{
  "action": "Final Answer",
  "action_input": "Final response to human"
}
...

Begin! Reminder to ALWAYS respond with a valid json blob of a single action. Use tools if necessary. Respond directly if appropriate. Format is Action:```$JSON_BLOB```then Observation:.
Thought:
Human: 請(qǐng)幫忙診斷一下這個(gè)集群乏冀，并且在結(jié)論中給出根因的定界：軟件缺陷(software_bug) 或 用戶使用問(wèn)題(user_problem)，并使用JSON格式返回{"cause": "software_bug|user_problem", "suggestion": "給出的建議"}

這個(gè)prompt結(jié)構(gòu)的重點(diǎn)在于2個(gè)：

1. 把所有的工具的輸入輸出和功能描述轉(zhuǎn)化成列表辆沦。

2. 告訴LLM在沒(méi)有結(jié)束之前，需要按照 Question: -> Thought: -> Action: 這樣的方式重復(fù)N次最終給出結(jié)論识虚。

因此肢扯，如果需要在已有的系統(tǒng)中嵌入智能體，甚至不需要使用langchain担锤，只要需要自己手搓一個(gè)解析字符串框架蔚晨，就能實(shí)現(xiàn)思維鏈。同時(shí)肛循，接入生產(chǎn)的大模型都是國(guó)產(chǎn)大模型铭腕，可能有些還無(wú)法達(dá)成標(biāo)準(zhǔn)的思維鏈交互。這時(shí)候多糠，這個(gè)字符串解析框架就需要稍微多做一些累舷，比如拋棄JSON結(jié)構(gòu)，使用更多的正則解析夹孔；利用字符串相似度去修改正調(diào)用參數(shù)的不正確等笋粟。我們?cè)谶@里也就不過(guò)多展開(kāi)了怀挠，大家可以根據(jù)自己手上能用的大模型自行探索。

智能體工程優(yōu)化點(diǎn)1：適時(shí)總結(jié)

在智能體的實(shí)踐過(guò)程中害捕，我們發(fā)現(xiàn)一些非常有趣的表象：在大模型中绿淋，記憶狀態(tài)會(huì)降低模型的推理能力。這一表象在運(yùn)維診斷中尤其顯著尝盼，如果要排查20臺(tái)機(jī)器吞滞，可能排查到第10臺(tái)的時(shí)候，token限制還沒(méi)到盾沫，但是大模型已經(jīng)可能有些糊涂了裁赠。反觀人也是同樣，排查信息量大時(shí)赴精，如果注意力沒(méi)有高度集中佩捞，分布式系統(tǒng)中ip地址又是如此相似，很可能多查幾輪就會(huì)有點(diǎn)迷糊了蕾哟。這個(gè)時(shí)候人會(huì)做的一件事情就是用小本本做筆記總結(jié)一忱，把前面的排查過(guò)程總結(jié)到一個(gè)文檔中。如果整個(gè)排查鏈路太長(zhǎng)谭确，文檔總結(jié)得太長(zhǎng)之后帘营，我們又會(huì)再次總結(jié)，把中間細(xì)節(jié)都去除逐哈，只保留幾個(gè)簡(jiǎn)明的結(jié)論芬迄。

事實(shí)上智能體的框架也同樣可以做這樣的優(yōu)化，思維鏈中Question/Thought/Action的過(guò)程就像我們的第一輪筆記昂秃，如果過(guò)程一長(zhǎng)禀梳，我們就需要再次總結(jié)筆記，使得智能體能夠繼續(xù)聚集于問(wèn)題的主鏈路中肠骆。所以我們可以看到：適時(shí)的總結(jié)出皇，能夠降低大模型狀態(tài)記憶負(fù)擔(dān)，提升推理能力哗戈。

image.png

智能體工程優(yōu)化點(diǎn)2：業(yè)務(wù)對(duì)象智能體化

另外一條給大模型狀態(tài)記憶減負(fù)的路徑，我們可以站在巨人的肩膀上荷科，那就是讓智能體面向業(yè)務(wù)對(duì)象進(jìn)行會(huì)話唯咬。從前面的第三章我們能夠看到，我們整個(gè)智能體的實(shí)驗(yàn)是基于面向?qū)ο蟮膖ool畏浆，但我認(rèn)為這還不夠胆胰，這還不是真正的面向?qū)ο蟆Ｄ敲丛趺词钦嬲拿嫦驅(qū)ο竽乜袒瘢课蚁旅媾e個(gè)例子讓大家有個(gè)比較深的感受：

我們構(gòu)建智能體之間的對(duì)話蜀涨，整個(gè)對(duì)話會(huì)出現(xiàn)了這樣4個(gè)角色的對(duì)象：專家、服務(wù)1機(jī)器組、服務(wù)器10.1.1.2厚柳、變更平臺(tái)氧枣。

• 專家：具備專家經(jīng)驗(yàn)，能夠分析解決復(fù)雜的問(wèn)題别垮，但對(duì)于很多運(yùn)維細(xì)節(jié)便监，需要其他運(yùn)維對(duì)象的支撐。

• 服務(wù)1機(jī)器組：管理其組內(nèi)的4臺(tái)服務(wù)器碳想，遇到組內(nèi)單個(gè)服務(wù)器故障烧董，會(huì)依據(jù)80端口健康檢查結(jié)果自動(dòng)切流。

• 服務(wù)器10.1.1.2：對(duì)本機(jī)各種系統(tǒng)運(yùn)行情況了如指掌胧奔。

• 變更平臺(tái)：管理所有運(yùn)維變更逊移，針對(duì)每個(gè)運(yùn)維變更均記錄了運(yùn)維對(duì)象實(shí)體。

下面開(kāi)始4個(gè)對(duì)象之間的對(duì)話：

專家：昨天晚上23:30的時(shí)候龙填，流量跌了20%胳泉，大概持續(xù)了1小時(shí)。
@服務(wù)1機(jī)器組觅够，昨天你們組服務(wù)有沒(méi)有什么異常胶背？

服務(wù)1機(jī)器組：昨天這個(gè)時(shí)間前后，10.1.1.2這臺(tái)服務(wù)器健康檢查出現(xiàn)多次異常喘先。其他沒(méi)有發(fā)現(xiàn)相關(guān)的問(wèn)題钳吟。
專家：@服務(wù)器10.1.1.2 你查查這個(gè)時(shí)間點(diǎn)前后，你那邊有沒(méi)有什么異常窘拯？
服務(wù)器10.1.1.2：昨天機(jī)器load一直很高柳沙，23:29的時(shí)候整機(jī)內(nèi)存超過(guò)閾值了，主服務(wù)進(jìn)程被out of memory機(jī)制給kill了拱烁，反復(fù)重啟了好久才恢復(fù)霜定。
專家：@服務(wù)器10.1.1.2 你load一直這么高嗎？什么時(shí)候開(kāi)始的思喊？
服務(wù)器10.1.1.2：從我的系統(tǒng)指標(biāo)來(lái)看壁酬，load高已經(jīng)持續(xù)27個(gè)小時(shí)了。
專家：@變更平臺(tái) 查一下27小時(shí)前有沒(méi)有什么變更和服務(wù)器10.1.1.2相關(guān)恨课。
變更平臺(tái)：2024/3/10 13:35 也就是2天前在3臺(tái)服務(wù)器灰度部署網(wǎng)絡(luò)探測(cè)模塊舆乔，包含10.1.1.2這臺(tái)服務(wù)器。
專家：初步結(jié)論：判斷10.1.1.2服務(wù)器的網(wǎng)絡(luò)探測(cè)模塊引發(fā)主服務(wù)進(jìn)程反復(fù)重啟導(dǎo)致流量下跌剂公，先回滾網(wǎng)絡(luò)探測(cè)模塊止血希俩。

這樣通過(guò)智能體間的對(duì)話解決問(wèn)題也并不是我們一開(kāi)始就想到的，一開(kāi)始我們是打算使用效仿日常的工作協(xié)作拓?fù)洌ㄔ撍悸吩诘谝黄杏刑岬剑河靡粋€(gè)Leader帶領(lǐng)多個(gè)專家分析解決問(wèn)題纲辽，由Leader來(lái)做最終匯總---但最終每次對(duì)話token花了一大堆颜武，效果并不理想璃搜。這里面最關(guān)鍵的問(wèn)題就是多加了一層專家抽象之后，每次分析都是專家在用工具分析給你結(jié)論鳞上，多花token耗時(shí)長(zhǎng)不說(shuō)这吻，分析參數(shù)有時(shí)候?qū)＜疫€會(huì)搞錯(cuò)。同時(shí)因块，一般專家角色的劃分就是Linux專家橘原、網(wǎng)絡(luò)專家這類，但從上面的例子我們可以看到涡上，這樣的角色劃分來(lái)解決問(wèn)題也會(huì)非常別扭趾断，一個(gè)問(wèn)題可能需要Linux專家和網(wǎng)絡(luò)專家之間討論半天才能有所進(jìn)展，而他們的結(jié)論還要由Leader去匯總吩愧，想想就復(fù)雜芋酌。

于是，我們考慮將減少協(xié)作的拓?fù)鋵蛹?jí)雁佳，希望在一個(gè)會(huì)話流中將問(wèn)題解決脐帝，不再做類似MapRedue架構(gòu)了。這時(shí)候糖权，我們就想到了面向對(duì)象編程：對(duì)象概念本身只是在編程階段堵腹，我們?nèi)绻褜?duì)象的概念引入到運(yùn)行時(shí)中--每個(gè)運(yùn)維對(duì)象都會(huì)自己會(huì)講話，會(huì)管理自己星澳，會(huì)描述自己的情況疚顷。那么是不是只要有個(gè)專家在頂層問(wèn)問(wèn)他們，是不是就能把問(wèn)題了解清楚了禁偎？于是大家就看到這樣的例子腿堤。

image.png

在這個(gè)例子中，很重要的一點(diǎn)就是如暖，作為專家笆檀，不需要去了解太多的技術(shù)細(xì)節(jié)：他不需要去知道流量切換的原理是什么，使用TCP的4層探測(cè)的還是用HTTP的7層探測(cè)盒至。這就使得專家這層的經(jīng)驗(yàn)具有足夠的通用性酗洒，使用相似的分析行為可以分析流量下跌、作業(yè)失敗枷遂、功能失效等樱衷。

不能說(shuō)這樣的例子在所有場(chǎng)景都適用，至少在運(yùn)維分析診斷場(chǎng)景下登淘，他能夠發(fā)揮自己的作用。同時(shí)封字，這些智能體也能夠直接被接入到工作群中黔州，如果你嫌這個(gè)智能體專家分析不夠清晰耍鬓，你可以打個(gè)樣，你可以親自上陣去@各個(gè)運(yùn)維實(shí)體進(jìn)行分析流妻，也是完全可行的牲蜀。

image.png

五、總結(jié)

本文向大家展示了一個(gè)通過(guò)智能體完整地對(duì)HDFS集群進(jìn)行問(wèn)題診斷的案例绅这，智能體能夠非常好地調(diào)用合適的工具來(lái)解決問(wèn)題涣达，而且從旁觀者看來(lái)，整個(gè)過(guò)程也完全符合日常問(wèn)題排查的推理過(guò)程证薇，甚至有些表現(xiàn)還能達(dá)到專家的水平度苔。

一般公司接入大模型方案會(huì)考慮數(shù)據(jù)安全問(wèn)題，會(huì)采用自研或可控的大模型浑度。于是針對(duì)自研類大模型的prompt工程框架變得至關(guān)重要寇窑。

通過(guò)大量的實(shí)踐，結(jié)合上面的兩個(gè)例子箩张，我們發(fā)現(xiàn)可以通過(guò)兩種路徑甩骏，工程化地減少智能體推理過(guò)程中的狀態(tài)記憶負(fù)擔(dān)：

1. 階段性的總結(jié)：收斂狀態(tài)記憶數(shù)據(jù)。

2. 業(yè)務(wù)對(duì)象智能體化：收斂工具和狀態(tài)細(xì)節(jié)于智能體內(nèi)部先慷。

基于頂層的分析型智能體與業(yè)務(wù)對(duì)象智能體交流來(lái)解決問(wèn)題饮笛，使得主分析思維鏈的狀態(tài)盡可能少，目標(biāo)盡可能聚焦论熙。

歡迎大家根據(jù)自身不同需求福青，構(gòu)建出更多的垂直領(lǐng)域的智能體工程。

參考材料：

• Zhiheng Xi, et al. “The Rise and Potential of Large Language Model Based Agents: A Survey” https://arxiv.org/pdf/2309.07864.pdf

• https://python.langchain.com/docs/use_cases/tool_use/

• https://generativeai.pub/rags-from-scratch-indexing-dab7d83a0a36

• https://thenewstack.io/microsoft-one-ups-google-with-copilot-stack-for-developers/