1. 項目概述當大語言模型遇見機器人系統(tǒng)架構恢復在機器人軟件開發(fā)領域特別是基于ROS 2的復雜系統(tǒng)中一個長期存在的痛點就是“架構漂移”。你是否有過這樣的經(jīng)歷接手一個龐大的、由多人協(xié)作開發(fā)多年的ROS 2項目打開代碼倉庫面對的是數(shù)百個節(jié)點Node、成千上萬個話題Topic和服務Service以及錯綜復雜的依賴關系。文檔要么缺失要么早已過時與實際代碼嚴重脫節(jié)。你想理解系統(tǒng)的整體架構、數(shù)據(jù)流和控制邏輯卻感覺像是在面對一團亂麻。這就是“架構恢復”要解決的難題——從源代碼和運行時信息中逆向工程出系統(tǒng)本應有的、清晰的分層結構設計。傳統(tǒng)的架構恢復方法無論是基于靜態(tài)代碼分析如解析package.xml、CMakeLists.txt還是動態(tài)運行時追蹤如ros2 topic list、ros2 node info都面臨著巨大的局限性。靜態(tài)分析難以理解動態(tài)的節(jié)點發(fā)現(xiàn)和通信邏輯而動態(tài)追蹤又像“盲人摸象”只能看到運行時的瞬時狀態(tài)缺乏對設計意圖和邏輯分組的洞察。其結果往往是生成一張巨大、扁平、混亂的“蜘蛛網(wǎng)”圖對理解和重構系統(tǒng)幫助有限。近年來大語言模型LLM在代碼理解、邏輯推理和自然語言處理方面展現(xiàn)出的驚人能力為我們打開了一扇新的大門。這個項目標題所探討的正是將LLM作為“智能助手”引入到ROS 2系統(tǒng)的架構恢復工作中。其核心思路不是讓LLM替代傳統(tǒng)分析工具而是讓它扮演一個“資深架構師”的角色基于多源、低級的分析結果如代碼結構、通信模式、依賴關系運用其知識進行推理、抽象和歸納最終重建出一個分層的、多級的、符合人類設計思維的架構視圖。這是一種基于智能體Agent的、自底向上的重構方法旨在彌合“代碼現(xiàn)實”與“設計理想”之間的鴻溝為維護、重構和文檔化大型真實世界的ROS 2系統(tǒng)提供強有力的支持。2. 核心思路與方案設計構建一個多級智能體協(xié)作框架這個項目的核心創(chuàng)新點在于“基于智能體的多級方法”。它不是簡單地用LLM去讀一遍代碼然后輸出架構圖而是設計了一套層次化的、分工協(xié)作的智能體Agent工作流。我們可以把這個框架想象成一個由不同層級專家組成的“架構恢復委員會”。2.1 多級智能體的角色與分工整個恢復過程被分解為多個層次每個層次由一個或多個專門的LLM智能體負責它們處理不同粒度的信息并將結果向上層傳遞和抽象。第一級實體提取智能體Entity Extraction Agents這是最基礎的一層相當于“情報收集員”。它的任務是利用傳統(tǒng)工具從ROS 2系統(tǒng)中提取原始、細粒度的實體和關系。這些智能體通常是規(guī)則驅動或輕量模型驅動的負責執(zhí)行靜態(tài)代碼分析解析所有功能包Package提取節(jié)點Node、發(fā)布者Publisher、訂閱者Subscriber、服務服務器Service Server、客戶端Client、動作Action的聲明分析CMakeLists.txt和package.xml中的依賴關系。動態(tài)運行時嗅探在系統(tǒng)典型運行場景下通過ros2命令行工具或rqt_graph等捕獲節(jié)點間的實際通信關系話題、服務、動作的連接。消息/服務接口分析解析所有.msg、.srv、.action文件理解數(shù)據(jù)結構和服務契約。這一層的輸出是一張巨大的、扁平的“實體-關系”圖包含了所有最底層的元素和它們之間直接的連接。這張圖雖然全面但極其復雜難以直接理解。第二級模式識別與聚類智能體Pattern Recognition Clustering Agents這一層的智能體開始引入LLM的抽象能力。它們接收第一層產(chǎn)生的扁平圖并嘗試從中發(fā)現(xiàn)模式將相關的實體進行聚類。例如功能聚類識別共同完成某一特定功能如“導航”、“感知”、“底盤控制”的一組節(jié)點。LLM可以通過節(jié)點命名、通信的話題名稱如包含/map、/odom、/goal等關鍵詞、代碼中的注釋或導入的庫來推斷其功能。通信模式識別識別發(fā)布-訂閱鏈、請求-響應服務鏈、動作執(zhí)行流等典型的ROS 2交互模式。層級推斷根據(jù)通信的指向性例如感知節(jié)點通常向決策節(jié)點發(fā)送數(shù)據(jù)而不是相反和數(shù)據(jù)的抽象程度原始傳感器數(shù)據(jù) vs. 融合后的環(huán)境模型初步推斷可能的層次關系。這一層的輸出是將底層實體分組為多個“功能模塊”或“組件”并定義了這些組件之間的交互關系。架構開始從“平面”走向“立體”。第三級架構重構與合理化智能體Architectural Reconstruction Rationalization Agent這是最核心的一層由一個或多個更強大的LLM智能體擔任“首席架構師”。它的任務是基于第二層產(chǎn)生的組件視圖運用軟件架構知識如分層架構、模塊化設計、關注點分離等原則重建出一個合乎邏輯的、分層的系統(tǒng)架構。分層定義智能體會嘗試定義系統(tǒng)的層級例如硬件抽象層驅動節(jié)點、感知層傳感器數(shù)據(jù)處理、特征提取、決策規(guī)劃層路徑規(guī)劃、任務調(diào)度、控制層底層執(zhí)行器控制。LLM需要判斷每個組件屬于哪一層。接口規(guī)范化審視組件間的通信接口建議將其規(guī)范化為更清晰的服務契約或標準化的消息類型減少臨時性、緊耦合的通信。設計原則驗證檢查重建的架構是否符合高內(nèi)聚、低耦合等原則并指出潛在的架構異味如循環(huán)依賴、上帝節(jié)點等。這一層的輸出是一個清晰的、分層的架構模型可能用架構描述語言如UML組件圖、C4模型或特定領域語言來表示。第四級文檔與解釋生成智能體Documentation Explanation Generation Agent最后一層負責“人性化輸出”。它將第三層產(chǎn)生的形式化架構模型轉化為人類易于理解的文檔。生成架構描述用自然語言描述整個系統(tǒng)的設計目標、各層職責、關鍵數(shù)據(jù)流和控制流。生成組件說明書為每個重要的組件生成說明包括其功能、輸入/輸出接口、依賴關系。可視化建議建議如何繪制架構圖框圖、序列圖甚至生成圖表生成的腳本如Graphviz的DOT語言。通過這四級智能體的流水線作業(yè)我們實現(xiàn)了從“代碼泥潭”到“清晰藍圖”的躍遷。LLM在其中扮演的不是“苦力”而是“分析師”和“設計師”將低級、混亂的數(shù)據(jù)轉化為高級、有序的知識。2.2 為什么選擇基于智能體的方法你可能會問為什么不直接用一個超級強大的LLM比如GPT-4一次性完成所有工作這里有幾個關鍵的考量任務分解與專業(yè)化架構恢復是一個復雜的認知任務涉及代碼理解、模式識別、架構設計等多個子任務。將其分解并由專門的智能體處理符合“分而治之”的思想能降低單個模型的認知負荷提高任務完成的準確性和可靠性。就像一個團隊有人擅長細節(jié)有人擅長宏觀規(guī)劃?？煽匦耘c可解釋性多級流水線使得整個過程更可控。我們可以在每一級檢查中間結果如果某一級出現(xiàn)錯誤例如聚類錯誤我們可以定位到具體的智能體并進行調(diào)整或重新訓練而不必推翻整個流程。這比一個端到端的黑盒模型更具可解釋性和可調(diào)試性?；旌现悄懿⒎撬腥蝿斩夹枰狶LM。第一級的實體提取完全可以用更高效、更精確的傳統(tǒng)程序化方法完成。將LLM用在最需要其抽象和推理能力的環(huán)節(jié)第二、三級實現(xiàn)了傳統(tǒng)符號AI規(guī)則與現(xiàn)代神經(jīng)AILLM的混合兼顧了效率與智能。迭代與精化這個框架可以設計成迭代式的。高層智能體發(fā)現(xiàn)底層分析缺失關鍵信息時可以向下層智能體發(fā)出“查詢”或“重新分析”的指令形成一個閉環(huán)的優(yōu)化過程。注意這個方案的成功高度依賴于為每一級智能體設計清晰的“指令”Prompt和“上下文”。例如給第三級架構師的指令中必須明確包含常見的機器人軟件架構模式如感知-規(guī)劃-執(zhí)行三層架構作為參考并規(guī)定輸出的格式標準。3. 關鍵技術點與實現(xiàn)細節(jié)拆解要將上述藍圖變?yōu)楝F(xiàn)實我們需要攻克一系列技術難點。下面我們來深入拆解幾個關鍵環(huán)節(jié)的實現(xiàn)細節(jié)。3.1 第一級高效且準確的實體關系提取這是整個流程的基石如果基礎數(shù)據(jù)錯了后續(xù)LLM再強大也是“垃圾進垃圾出”。對于ROS 2系統(tǒng)我們需要一個混合方法靜態(tài)分析部分我們可以利用像ros2 pkg、ros2 interface這樣的官方工具但為了獲得更結構化的數(shù)據(jù)通常需要編寫自定義的解析腳本。一個實用的方法是使用ament構建系統(tǒng)的API或解析colcon的構建結果。例如通過分析build目錄下的compile_commands.json和install目錄下的package.xml可以精確獲取包依賴和文件結構。# 示例使用Python的xml.etree.ElementTree解析package.xml獲取依賴 import xml.etree.ElementTree as ET import os def parse_package_dependencies(package_xml_path): tree ET.parse(package_xml_path) root tree.getroot() deps {build: [], buildtool: [], exec: [], test: []} for dep_type in deps.keys(): for dep in root.findall(f{dep_type}_depend): deps[dep_type].append(dep.text) return deps # 遍歷workspace收集所有package.xml def collect_all_packages(workspace_path): packages [] for root, dirs, files in os.walk(workspace_path): if package.xml in files: packages.append(os.path.join(root, package.xml)) return packages動態(tài)分析部分在系統(tǒng)運行時我們可以通過ROS 2的ros2 topic list、ros2 node info node_name等命令獲取實時拓撲。但更推薦使用程序化接口如rclpy的API來編寫一個“監(jiān)聽者”節(jié)點持續(xù)記錄節(jié)點和話題的注冊與注銷事件從而得到更完整的動態(tài)視圖。# 示例使用rclpy監(jiān)聽節(jié)點變化概念性代碼 import rclpy from rclpy.node import Node from system_metrics_interfaces.msg import NodeInfoArray class TopologyMonitor(Node): def __init__(self): super().__init__(topology_monitor) # 訂閱系統(tǒng)發(fā)布的節(jié)點信息話題假設存在 self.subscription self.create_subscription( NodeInfoArray, /system_metrics/node_info, self.node_info_callback, 10) self.live_nodes {} def node_info_callback(self, msg): for node_info in msg.nodes: self.live_nodes[node_info.name] { publishers: node_info.publishers, subscribers: node_info.subscribers, services: node_info.services } # 將self.live_nodes更新到全局知識庫關鍵挑戰(zhàn)與處理節(jié)點名重復與命名空間ROS 2支持節(jié)點重映射和命名空間。靜態(tài)分析可能只得到my_node而動態(tài)運行時可能是/sensor_front/my_node。必須統(tǒng)一處理命名空間將動態(tài)發(fā)現(xiàn)的完整名稱與靜態(tài)代碼實體關聯(lián)起來。條件編譯與插件有些節(jié)點可能只在特定編譯選項或插件加載時才存在。靜態(tài)分析需要解析CMakeLists.txt中的條件語句動態(tài)分析則需要覆蓋不同的系統(tǒng)運行模式。數(shù)據(jù)持久化提取的實體和關系需要以一種結構化的格式如JSON、圖數(shù)據(jù)庫Neo4j的Cypher語句存儲作為后續(xù)LLM處理的輸入。推薦使用屬性圖模型節(jié)點類型包括Package、Node、Topic、Service、MsgType邊關系包括DEPENDS_ON、PUBLISHES、SUBSCRIBES_TO、PROVIDES、USES等。3.2 第二級基于LLM的智能聚類與模式識別這是LLM首次大顯身手的環(huán)節(jié)。我們的目標是將第一級產(chǎn)生的“點線圖”聚合成“模塊圖”。輸入準備我們需要為LLM智能體精心構造輸入。不能簡單地把整個圖數(shù)據(jù)扔進去。通常的做法是分片對于超大型系統(tǒng)可以按功能包或物理部署位置如機器人上的不同計算機對圖進行分片讓LLM分別處理每個子圖。上下文構建對于每個待分析的節(jié)點組我們需要提取其豐富的上下文信息形成一個“節(jié)點檔案”代碼元數(shù)據(jù)節(jié)點所在的源文件路徑、所屬功能包。通信檔案它發(fā)布/訂閱的所有話題名稱、使用的服務、消息類型。文本線索從源代碼中提取的類名、函數(shù)名、變量名、日志語句、注釋尤其是文件頭注釋和關鍵函數(shù)注釋。這些是LLM推斷功能的關鍵。提示詞Prompt工程這是本環(huán)節(jié)的核心。一個有效的提示詞可能如下結構你是一個機器人軟件架構分析專家。請分析以下一組ROS 2節(jié)點根據(jù)它們的名稱、通信關系和代碼上下文判斷它們是否共同實現(xiàn)一個特定的高級功能。如果是請將這個功能組命名并簡述理由。 節(jié)點組信息 - 節(jié)點A: perception_lidar_driver - 發(fā)布話題: /sensor/lidar/raw - 源代碼位置: perception_pkg/src/lidar_node.cpp - 關鍵注釋: “本節(jié)點負責Velodyne雷達驅動發(fā)布原始點云數(shù)據(jù)?！?- 節(jié)點B: perception_lidar_filter - 訂閱話題: /sensor/lidar/raw - 發(fā)布話題: /perception/lidar/filtered - 源代碼位置: perception_pkg/src/filter_node.cpp - 關鍵注釋: “對原始點云進行降噪和地面濾除?！?- 節(jié)點C: perception_lidar_segmentation - 訂閱話題: /perception/lidar/filtered - 發(fā)布話題: /perception/objects - 源代碼位置: perception_pkg/src/segmentation_node.cpp - 關鍵注釋: “對濾波后點云進行聚類分割出潛在障礙物?！?請分析 1. 這些節(jié)點是否屬于一個共同的功能模塊如果是請給出模塊名稱例如“激光雷達感知流水線”。 2. 用一句話描述該模塊的職責。 3. 列出模塊內(nèi)部的數(shù)據(jù)流輸入 - 處理 - 輸出。后處理與聚合LLM可能會對不同的節(jié)點子集給出聚類結果。我們需要一個后處理步驟來合并重疊或相關的聚類。例如LLM可能將節(jié)點A、B、C聚類為“激光雷達處理”又將節(jié)點C和另一個節(jié)點D聚類為“障礙物檢測”。后處理算法需要識別到節(jié)點C是橋梁并將這兩個聚類合并或建立關聯(lián)形成一個更大的“感知層”模塊視圖。實操心得在這個階段讓LLM輸出結構化的JSON格式結果至關重要例如{module_name: ..., nodes: [..., ...], responsibility: ..., data_flow: [...]}。這極大方便了后續(xù)的程序化處理。同時可以嘗試讓LLM為每個聚類給出一個“置信度分數(shù)”用于在后處理階段進行裁決。3.3 第三級分層架構的推理與重建這是最具挑戰(zhàn)性的一步要求LLM具備較強的軟件架構設計知識。輸入是第二級產(chǎn)生的功能模塊集合及其相互關系。架構知識注入我們需要在提示詞中明確“教導”LLM常見的機器人系統(tǒng)架構模式。這可以通過提供少量示例Few-shot Learning或在系統(tǒng)指令System Prompt中描述來實現(xiàn)。例如你是一個資深的機器人系統(tǒng)架構師。請根據(jù)提供的功能模塊列表將它們組織到一個經(jīng)典的分層架構中。常見的機器人分層包括但不限于 - **硬件接口層/驅動層**: 直接與傳感器、執(zhí)行器交互負責原始數(shù)據(jù)采集和底層命令發(fā)送。 - **感知層**: 處理傳感器數(shù)據(jù)進行融合、識別、定位生成對環(huán)境的結構化理解。 - **決策規(guī)劃層**: 基于環(huán)境理解和任務目標進行路徑規(guī)劃、任務調(diào)度、行為決策。 - **控制層**: 將高層決策轉化為具體的執(zhí)行器控制指令如速度、力矩。 - **人機交互層/應用層**: 提供用戶界面、任務管理、狀態(tài)監(jiān)控等功能。 請遵循以下原則 1. 高層模塊可以依賴低層模塊但應避免循環(huán)依賴和同層間的過度耦合。 2. 數(shù)據(jù)流應盡量自底向上從硬件到感知到?jīng)Q策。 3. 控制流指令應自上而下傳遞。推理與決策過程LLM需要為每個模塊分配一個層級并可能調(diào)整模塊間的接口。例如它可能發(fā)現(xiàn)“激光雷達感知流水線”模塊輸出的是原始障礙物列表而“決策規(guī)劃層”的“全局路徑規(guī)劃器”模塊需要的是更抽象的“占據(jù)柵格地圖”。LLM可能會建議在這兩個模塊之間插入一個“環(huán)境建模”模塊或者建議將“激光雷達感知流水線”模塊的輸出格式標準化為某種地圖消息。輸出形式化這一層的輸出需要是機器可讀且足夠形式化的以便生成文檔或導入架構設計工具?？梢允褂靡韵赂袷街籆4模型文本描述描述系統(tǒng)、容器、組件的關系。UML組件圖XML如XMI便于用工具渲染。自定義的JSON架構描述包含層級、模塊、接口、依賴關系。{ reconstructed_architecture: { layers: [ { name: 感知層, description: 負責處理所有傳感器數(shù)據(jù)生成環(huán)境模型。, components: [ { name: 激光雷達感知流水線, original_nodes: [perception_lidar_driver, perception_lidar_filter, perception_lidar_segmentation], provided_interfaces: [ {name: /perception/objects, type: ObjectArrayMsg} ], required_interfaces: [ {name: /sensor/lidar/raw, type: PointCloud2Msg, from_layer: 硬件接口層} ] } ] } ], inter-layer_dependencies: [ {from: 感知層, to: 決策規(guī)劃層, via: /perception/objects} ] } }3.4 智能體間的協(xié)作與迭代機制各級智能體并非孤島它們需要協(xié)作。一個高效的機制是引入一個協(xié)調(diào)智能體Orchestrator Agent或采用迭代精化流程。質疑與反饋第三級架構師智能體在嘗試分層時可能發(fā)現(xiàn)第二級提供的某個功能模塊邊界模糊或者缺少某個關鍵節(jié)點。此時它可以生成一個“查詢”返回給第二級例如“為了明確‘決策層’的邊界請重新檢查節(jié)點task_manager和behavior_tree之間的通信關系并確認它們是否應屬于同一個‘任務執(zhí)行’模塊”一致性檢查協(xié)調(diào)智能體負責檢查最終輸出的架構是否與第一級提取的原始實體關系存在矛盾。例如如果架構圖中A組件依賴于B組件但原始關系圖中兩者沒有任何通信鏈路這就觸發(fā)了“不一致警報”需要人工介入或啟動特定子流程進行復核。多輪提示對于復雜系統(tǒng)單輪LLM調(diào)用可能不夠?？梢圆捎枚噍唽υ挼男问阶孡LM智能體像架構評審會一樣討論。例如先讓一個智能體提出初步分層方案再讓另一個智能體扮演“評審員”提出質疑和修改建議最后由第一個智能體進行修正。4. 實操流程與工具鏈構建設想要將這個方法論落地我們需要構建一個完整的工具鏈。以下是一個可行的實操流程設想4.1 環(huán)境準備與數(shù)據(jù)采集選擇目標系統(tǒng)選擇一個中等復雜度的真實ROS 2項目作為起點例如Autoware.Auto或Nav2的某個特定配置。搭建分析環(huán)境靜態(tài)分析工具集成ros2 pkg、ament、libclang用于C代碼的深度解析或tree-sitter用于Python解析。動態(tài)分析工具編寫基于rclpy的監(jiān)控節(jié)點或使用ros2_tracing和ros2trace工具套件進行高性能、低干擾的系統(tǒng)追蹤。數(shù)據(jù)存儲設立一個圖數(shù)據(jù)庫如Neo4j或使用內(nèi)存圖庫如networkx來存儲實體關系。運行數(shù)據(jù)采集在目標系統(tǒng)幾種典型的工作模式如建圖模式、導航模式下分別運行收集動態(tài)拓撲數(shù)據(jù)。將靜態(tài)分析結果與多輪動態(tài)追蹤結果進行融合去重生成一份盡可能完整的“系統(tǒng)事實”圖譜。4.2 智能體流水線實現(xiàn)第一級智能體實現(xiàn)主要是腳本開發(fā)。編寫Python腳本調(diào)用上述分析工具將結果規(guī)范化后存入圖數(shù)據(jù)庫。這部分可以完全程序化無需LLM。第二、三、四級智能體實現(xiàn)LLM選型根據(jù)預算和需求可以選擇云端API如GPT-4、Claude-3或本地部署的開源模型如Llama 3、Qwen系列。對于架構推理這種復雜任務能力更強的模型效果更好。提示詞模板開發(fā)為每一級、每一類任務聚類、分層、文檔化開發(fā)經(jīng)過精心調(diào)試的提示詞模板。這是項目的核心資產(chǎn)。編排框架可以使用LangChain、LlamaIndex或自定義的Python腳本來編排智能體的調(diào)用順序、傳遞上下文、解析輸出。實現(xiàn)迭代機制在編排框架中設計簡單的規(guī)則當高層智能體輸出“置信度低”或觸發(fā)“不一致警報”時自動發(fā)起對下層智能體的重新查詢或調(diào)整分析參數(shù)。4.3 結果驗證與評估如何判斷恢復的架構是“好”的這是一個開放性問題但可以從以下幾個維度評估與專家判斷的一致性請原系統(tǒng)開發(fā)者或資深架構師對恢復出的架構圖進行評審評估其合理性和可理解性?？梢圆捎谜{(diào)查問卷形式評分項包括“層次是否清晰”、“模塊職責是否單一”、“數(shù)據(jù)流是否符合直覺”等。重構指導價值基于恢復的架構提出具體的重構建議如“將節(jié)點X和Y合并”、“將話題A的消息類型標準化”。評估這些建議被開發(fā)者采納后對系統(tǒng)可維護性、可理解性的提升。指標對比計算恢復前后架構的量化指標如模塊間耦合度Fan-in/Fan-out、模塊內(nèi)聚度基于代碼關聯(lián)性、架構層次深度等。理想情況下恢復后的架構應表現(xiàn)出更低的耦合和更高的內(nèi)聚。5. 挑戰(zhàn)、局限性與未來展望盡管前景誘人但將LLM用于真實世界的架構恢復仍面臨諸多挑戰(zhàn)1. 規(guī)模與成本問題大型ROS 2系統(tǒng)的代碼和運行時數(shù)據(jù)量巨大。將所有這些上下文塞進LLM的有限令牌Token窗口是不現(xiàn)實的。必須依賴高效的分片、摘要和遞歸分析策略。同時調(diào)用強大的LLM API如GPT-4處理數(shù)百萬行代碼的上下文成本會非常高。需要探索如何用更小的、專門微調(diào)過的模型來處理特定子任務。2. LLM的“幻覺”與不確定性LLM可能會“捏造”出不存在的依賴關系或對模糊的代碼功能做出錯誤推斷。必須通過嚴格的驗證機制來約束例如要求LLM為每個推斷提供“證據(jù)”如引用的代碼行、話題名稱并將最終架構與原始事實圖譜進行自動化比對標記出所有無法被原始數(shù)據(jù)支持的“推測”部分供人工復核。3. 領域知識的深度依賴雖然LLM有廣泛的編程知識但對ROS 2特有的設計模式、最佳實踐如生命周期節(jié)點、組件化、以及特定機器人領域如自動駕駛、機械臂控制的架構范式其理解可能不夠深入。解決方案是進行領域適應在提示詞中注入大量ROS 2和機器人領域的優(yōu)質文檔、設計模式案例或者在可能的情況下使用機器人領域的代碼和文檔對開源LLM進行微調(diào)打造一個“機器人架構專家模型”。4. 動態(tài)與不確定性的挑戰(zhàn)機器人系統(tǒng)具有很強的動態(tài)性節(jié)點可能隨時啟停通信關系可能隨模式切換而變化。我們恢復的架構更像是系統(tǒng)在某個“穩(wěn)態(tài)”下的快照。未來的工作需要考慮如何捕捉和表示這種動態(tài)性例如恢復出系統(tǒng)的“模式”Mode以及不同模式下的架構視圖切換。展望未來這項工作可能沿著以下幾個方向深化從恢復走向協(xié)同設計工具不僅能恢復現(xiàn)有架構還能基于恢復結果和新的需求提出架構演進建議甚至輔助生成新模塊的代碼骨架成為“架構副駕駛”。實時架構監(jiān)控與偏差檢測將恢復出的“理想架構”作為藍圖與系統(tǒng)實時運行時的架構進行持續(xù)比對一旦發(fā)現(xiàn)嚴重偏離如出現(xiàn)了藍圖未定義的緊耦合通信立即向開發(fā)者告警。與形式化方法結合將LLM恢復出的架構用形式化語言如SysML、AADL進行描述進而可以進行性能分析、可靠性驗證等更深層次的工程活動。這個項目標題指向的不僅僅是一個具體的工具更是一種人機協(xié)同解決復雜軟件工程問題的新范式。它承認了完全自動化恢復完美架構的難度轉而尋求用LLM的強大認知能力來放大工程師的智慧將工程師從繁瑣的信息梳理中解放出來聚焦于更高層次的設計決策。對于任何正在與大型、遺留ROS 2系統(tǒng)搏斗的團隊來說這條探索之路無疑充滿了吸引力與實用價值。