1. 從“修水管”視頻到“自工程完結(jié)”一個被忽視的工程鐵律前幾天我在一個程序員社區(qū)里刷到一個挺火的短視頻標題大概是“程序員修水管結(jié)果修出個更大的Bug”。視頻里一個哥們兒家里的水管漏水他手忙腳亂地擰緊了某個閥門結(jié)果水是不漏了但整個樓層的供水壓力都出了問題鄰居家也跟著遭殃。評論區(qū)里一片“哈哈哈這很程序員”但笑過之后我心里卻咯噔一下。這不就是我們?nèi)粘ｉ_發(fā)中尤其是現(xiàn)在搞AI Agent這類復雜系統(tǒng)時每天都在上演的“經(jīng)典戲碼”嗎為了快速解決眼前的一個報錯比如某個API調(diào)用失敗我們可能隨手加個補丁、繞個彎子代碼是能跑了卻把更隱蔽、更棘手的問題比如資源泄漏、狀態(tài)不一致像“水壓異?！币粯忧臒o聲息地傳遞給了下游模塊甚至是最終用戶。這個場景完美地詮釋了TPS豐田生產(chǎn)方式里一個核心到不能再核心的理念——“自工程完結(jié)”。最近我在深度參與一個名為Agent Harness的開源項目時對這個理念有了近乎“刻骨銘心”的體會。Agent Harness你可以把它理解為一套專門為AI Agent打造的“腳手架”或“基礎設施層”。它不負責替代Agent本身的核心推理邏輯那是LLM和具體技能模塊的事而是專注于解決那些讓Agent能穩(wěn)定、可靠、可觀測地運行起來的“臟活累活”比如生命周期管理、工具調(diào)用編排、狀態(tài)持久化、異常處理和監(jiān)控等等。那么“自工程完結(jié)”到底是什么意思簡單粗暴地講就是**“別把Bug或者任何形式的問題、半成品留給下一道工序”**。在制造業(yè)的生產(chǎn)線上這意味著每個工位的工人必須確保自己經(jīng)手的零件是100%合格的才能流到下一個工位。在軟件工程特別是我們正在構(gòu)建的AI Agent系統(tǒng)中這意味著每一個模塊、每一次函數(shù)調(diào)用、每一個數(shù)據(jù)轉(zhuǎn)換都必須在其邊界內(nèi)盡最大可能處理掉所有它能預見的異常和問題輸出一個確定、可靠的結(jié)果給它的調(diào)用者而不是簡單地拋出一個錯誤或者傳遞一個模棱兩可的狀態(tài)。這聽起來像是常識對吧但現(xiàn)實是在追求快速迭代、功能上線的壓力下我們太容易妥協(xié)了。“先讓流程跑通回頭再優(yōu)化”、“這個異常概率很低先不管了”、“讓調(diào)用方去處理吧”……這些想法就是“Bug流水線”的開端。Agent Harness項目讓我意識到對于AI Agent這種高度動態(tài)、依賴外部服務、狀態(tài)復雜的系統(tǒng)如果不貫徹“自工程完結(jié)”整個系統(tǒng)就會像一個到處漏水的管道網(wǎng)絡運維成本和調(diào)試難度會呈指數(shù)級上升。今天我就結(jié)合Agent Harness開發(fā)中的具體案例跟你聊聊為什么這個來自傳統(tǒng)制造業(yè)的理念在AI時代反而成了我們最該撿起來的“工程利器”。2. 拆解“自工程完結(jié)”它遠不止是“不要拋出異?！焙芏嗳艘宦牭健皠e把Bug留給下一道工序”第一反應就是“哦就是要多做點異常捕獲別亂拋異常”。這理解得太淺了。在Agent Harness的語境下“自工程完結(jié)”有著更豐富、更嚴格的內(nèi)涵。我們可以把它分解為三個遞進的層次這恰恰對應了構(gòu)建穩(wěn)健AI Agent基礎設施的三個關(guān)鍵維度。2.1 第一層數(shù)據(jù)與狀態(tài)的“完結(jié)”這是最基礎的一層。任何一個函數(shù)或模塊對于其輸入必須有明確的契約和驗證對于其輸出必須有確定的格式和狀態(tài)。反面案例在早期版本的Agent Harness中我們有一個工具調(diào)用路由模塊。它的職責是根據(jù)Agent的意圖將調(diào)用分發(fā)給不同的工具Tool。最初的設計是如果找不到匹配的工具它就返回一個None。問題來了調(diào)用方拿到None后該怎么辦是重試是記錄日志后跳過還是向上拋出“工具未找到”錯誤每個調(diào)用方都要重復實現(xiàn)這套邏輯而且極易出錯。更糟糕的是有些工具調(diào)用后返回的數(shù)據(jù)結(jié)構(gòu)不一致有的返回字典有的返回字符串有的在出錯時返回一個包含error字段的字典。路由模塊只是簡單地透傳這些結(jié)果?！白怨こ掏杲Y(jié)”的改造輸入完結(jié)路由模塊強制要求所有注冊的工具必須提供統(tǒng)一的元數(shù)據(jù)描述名稱、描述、輸入?yún)?shù)schema。在路由前先根據(jù)schema校驗輸入?yún)?shù)的合法性和完整性不合法則立即在此模塊內(nèi)反饋“參數(shù)錯誤”并附上具體原因而不是把原始參數(shù)丟給工具去報錯。輸出完結(jié)我們定義了一個統(tǒng)一的ToolResponse對象。無論工具內(nèi)部執(zhí)行成功與否路由模塊都必須返回這個對象。這個對象包含幾個關(guān)鍵字段success: bool(成功/失敗)data: Any(成功時的標準化數(shù)據(jù)如將不同工具的原始輸出轉(zhuǎn)換為一個標準JSON結(jié)構(gòu))error: ToolError(失敗時的錯誤對象包含錯誤碼、錯誤信息、可選的原始異常)tool_name: str(調(diào)用的工具名)execution_id: str(本次執(zhí)行的唯一ID用于鏈路追蹤)這樣調(diào)用方通常是Agent的核心邏輯拿到ToolResponse后只需要檢查success字段就能做出確定性的下一步?jīng)Q策。數(shù)據(jù)的形態(tài)和狀態(tài)的語義在路由模塊這一“工序”就完結(jié)了。注意這里“完結(jié)”的不是可能性工具仍然可能因為網(wǎng)絡、權(quán)限等問題失敗而是信息表達的完備性和一致性。調(diào)用方無需猜測結(jié)果的含義。2.2 第二層邏輯與流程的“完結(jié)”這一層關(guān)注的是業(yè)務流程或控制流在一個模塊內(nèi)的完整性。一個模塊應該盡可能處理其業(yè)務邏輯范圍內(nèi)的所有分支避免將流程控制的復雜度暴露給上游。反面案例考慮Agent的“記憶”或“狀態(tài)持久化”模塊。假設Agent執(zhí)行到一半崩潰了重啟后需要恢復狀態(tài)。最初的簡單實現(xiàn)是提供一個save_state(state)和load_state(agent_id)函數(shù)。如果load_state時找不到數(shù)據(jù)就返回None。于是Agent的啟動邏輯里就需要寫一堆if-elseif state is None: 初始化新會話 else: 恢復舊會話。這看起來沒問題但把“狀態(tài)不存在時應初始化”這個業(yè)務決策從存儲模塊剝離到了核心邏輯模塊。如果未來我們想改變策略比如狀態(tài)不存在時從備份中加載就需要修改核心邏輯。“自工程完結(jié)”的改造 我們重構(gòu)了狀態(tài)管理模塊提供一個get_or_initialize_state(agent_id, initial_state_factory)方法。這個方法內(nèi)部封裝了完整的邏輯嘗試加載agent_id對應的狀態(tài)。如果加載成功直接返回。如果加載失敗文件不存在、數(shù)據(jù)損壞等它不會簡單返回None而是會 a. 首先嘗試記錄錯誤和進行可能的修復如讀取損壞文件的備份。 b. 如果最終確定狀態(tài)無法恢復則調(diào)用傳入的initial_state_factory函數(shù)創(chuàng)建一個新的初始狀態(tài)。 c.可選但強烈推薦將這個新創(chuàng)建的狀態(tài)立即持久化并記錄一條“狀態(tài)初始化”的審計日志。這樣對于Agent的核心邏輯來說它調(diào)用get_or_initialize_state后一定能拿到一個有效的、立即可用的狀態(tài)對象。至于這個狀態(tài)是舊的、新的、還是修復后的核心邏輯不關(guān)心也無需包含相關(guān)判斷代碼。整個“獲取可用狀態(tài)”的流程在狀態(tài)管理模塊內(nèi)部就“完結(jié)”了。2.3 第三層資源與副作用的“完結(jié)”這是最高級也最容易出問題的一層。它要求一個模塊必須管理好它申請的所有資源網(wǎng)絡連接、文件句柄、內(nèi)存、外部服務會話等并確保其操作產(chǎn)生的副作用如修改了全局配置、發(fā)送了通知在模塊邊界內(nèi)是可預測和可清理的。反面案例經(jīng)典Bug在集成一個外部知識庫查詢工具時該工具需要維護一個昂貴的數(shù)據(jù)庫連接池。最初的工具實現(xiàn)提供了一個query(sql)方法但連接池的初始化(init_pool)和關(guān)閉(close_pool)需要調(diào)用方顯式管理。于是Agent的生命周期管理代碼變得復雜要在合適的時候init_pool更要在Agent停止時或在異常發(fā)生時記得調(diào)用close_pool。一旦忘記就會導致連接泄漏。這就像打開了水龍頭沒關(guān)把“關(guān)水”的責任留給了房子里的下一個人?！白怨こ掏杲Y(jié)”的改造 我們利用Agent Harness提供的生命周期鉤子Lifecycle Hooks和上下文管理器Context Manager模式對這類工具進行了重構(gòu)。工具自身實現(xiàn)資源管理工具類實現(xiàn)__enter__和__exit__方法或者提供start()/stop()方法。在__enter__/start()中初始化連接池在__exit__/stop()中確保關(guān)閉所有連接。Harness框架負責調(diào)度Agent Harness在加載該工具時會識別其生命周期接口。當Agent啟動時Harness自動調(diào)用工具的start()當Agent停止無論是正常結(jié)束還是因異常崩潰Harness都會保證調(diào)用工具的stop()進行清理。對調(diào)用方透明Agent的核心邏輯在調(diào)用query(sql)時完全無需關(guān)心連接池是否存在、是否健康。它假設工具在任何時候都是“就緒”的。資源管理的責任從分散的、易忘的調(diào)用方收歸到了工具模塊內(nèi)部和Harness框架這個統(tǒng)一的“工序”中。這個改造直接避免了類似isAutoCloseConnection false這種配置錯誤導致的Bug。因為關(guān)閉連接不再是可選的而是框架強制保障的、在“工具使用”這個工序內(nèi)必須完結(jié)的操作。3. Agent Harness如何將“完結(jié)”理念工程化理解了理念我們來看看在Agent Harness這個具體項目中是如何通過設計和約定將“自工程完結(jié)”從口號落地的。這不僅僅是代碼風格更是一套嵌入到框架DNA里的約束和最佳實踐。3.1 通過強類型與契約定義邊界松散的類型是Bug的溫床。Agent Harness廣泛使用像Pydantic這樣的數(shù)據(jù)驗證庫為幾乎所有在模塊間傳遞的數(shù)據(jù)結(jié)構(gòu)定義嚴格的Schema。工具輸入/輸出契約每個工具都必須聲明其輸入?yún)?shù)的JSON Schema和輸出數(shù)據(jù)的類型。Harness在調(diào)用前進行校驗不符合契約的請求根本不會到達工具邏輯。這確保了工具接收到的輸入是“完結(jié)”的格式正確、類型匹配。Agent狀態(tài)契約Agent的長期記憶和短期狀態(tài)也被要求定義為一個Pydantic模型。任何對狀態(tài)的讀寫都經(jīng)過模型的序列化和反序列化自動過濾掉非法字段保證狀態(tài)結(jié)構(gòu)的完整性。當狀態(tài)從一個會話持久化到另一個會話時其結(jié)構(gòu)是確定無疑的。消息流契約Agent與用戶、Agent與工具之間的消息如ChatMessage, ToolCallMessage, ToolResultMessage都有明確的類型定義。這保證了在復雜的多輪對話和工具調(diào)用流水線中每個環(huán)節(jié)處理的數(shù)據(jù)對象都是已知的、可靠的。這種強類型約束就像給每個工序的輸入輸出都配備了標準的“夾具”和“量具”不合格的零件根本無法流入下一站。3.2 統(tǒng)一的錯誤處理與降級策略“完結(jié)”不是不允許出錯而是要求錯誤必須在當前環(huán)節(jié)被妥善封裝和處理并以一種對下游友好的方式呈現(xiàn)。Agent Harness定義了一個分層的錯誤體系ToolExecutionError工具執(zhí)行過程中發(fā)生的錯誤如網(wǎng)絡超時、API限額用完。工具本身應盡可能進行重試等補救措施。如果最終失敗它必須拋出一個信息豐富的ToolExecutionError而不是原始的requests.exceptions.Timeout。AgentRuntimeErrorAgent核心邏輯運行時的錯誤如狀態(tài)機進入非法狀態(tài)、決策邏輯矛盾。這部分錯誤通常意味著Agent邏輯有Bug需要開發(fā)介入。HarnessFatalError基礎設施層面的嚴重錯誤如配置加載失敗、關(guān)鍵資源無法初始化。這類錯誤通常會導致整個Agent實例無法啟動。關(guān)鍵在于Harness提供了一個全局的錯誤處理與轉(zhuǎn)換中間件。任何未捕獲的異常都會被這個中間件捕獲并嘗試轉(zhuǎn)換為對用戶友好的消息或者觸發(fā)預定義的降級策略例如當知識庫查詢失敗時自動降級為僅使用LLM的內(nèi)部知識生成回答并記錄告警。這樣即使最底層的模塊出了錯傳到用戶界面或上游調(diào)度系統(tǒng)的也是一個被“完結(jié)”處理過的、有明確后續(xù)行動建議的結(jié)果而不是一串令人崩潰的堆棧跟蹤。3.3 可觀測性作為“完結(jié)”的檢驗標準你怎么知道一個工序真的“完結(jié)”了在制造業(yè)靠質(zhì)檢。在軟件里靠可觀測性Observability。Agent Harness內(nèi)置了強大的日志、指標Metrics和追蹤Tracing能力這不是為了炫技而是為了給“自工程完結(jié)”提供驗證手段。鏈路追蹤Tracing為每一次用戶請求、每一個工具調(diào)用、甚至每一次LLM交互生成唯一的追蹤ID。你可以清晰地看到一個請求的生命周期精確定位到是哪個“工序”慢了、失敗了或者輸出了異常數(shù)據(jù)。如果某個模塊聲稱自己處理完了但追蹤鏈在此斷掉或出現(xiàn)了非預期的跳轉(zhuǎn)那它就沒真正“完結(jié)”。結(jié)構(gòu)化日志日志不是簡單的print而是帶有級別、模塊名、執(zhí)行ID、關(guān)鍵上下文的結(jié)構(gòu)化數(shù)據(jù)。例如工具模塊在返回ToolResponse時無論成功失敗都必須記錄一條包含execution_id、tool_name、duration和success字段的日志。這相當于該工序的“加工記錄”可供后續(xù)審計和分析。健康檢查與就緒探針每個管理資源的模塊如數(shù)據(jù)庫連接池、外部服務客戶端都需要提供health_check()方法。Harness會定期調(diào)用或在關(guān)鍵操作前調(diào)用。如果健康檢查失敗該模塊會被標記為“不健康”Harness可以阻止請求流入或切換到備用模塊。這確保了只有真正“就緒”即資源層面已完結(jié)的模塊才會被使用。通過這些可觀測性手段我們不僅能發(fā)現(xiàn)問題更能量化每個模塊“完結(jié)”的質(zhì)量比如工具調(diào)用的平均耗時、錯誤率、狀態(tài)恢復的成功率等為持續(xù)改進提供數(shù)據(jù)支撐。4. 實戰(zhàn)推演從“Bug流水線”到“完結(jié)流水線”讓我們通過一個更具體的、融合了多個熱詞的場景來看看貫徹“自工程完結(jié)”前后的巨大差異。假設我們正在開發(fā)一個“能碳管理AI Agent”它需要查詢數(shù)據(jù)庫、調(diào)用外部API進行計算并生成報告。場景Agent收到用戶請求“計算我司上季度碳排放總量”。“Bug流水線”模式舊做法Agent核心邏輯解析用戶意圖生成一個查詢對象{query: “碳排放總量”, period: “l(fā)ast_quarter”, company: “my_company”}調(diào)用“數(shù)據(jù)查詢工具”。數(shù)據(jù)查詢工具未完結(jié)接收查詢對象發(fā)現(xiàn)沒有company_id字段只有company名字。它嘗試用名字去查一個映射表但映射表連接失敗網(wǎng)絡抖動。工具內(nèi)部捕獲了連接異常但只是記錄了一條“映射表連接失敗”的日志然后返回了None。Agent核心邏輯收到None它判斷為“查詢無結(jié)果”于是決定調(diào)用“估算模型工具”進行估算。估算模型工具未完結(jié)它需要company_id和period作為輸入現(xiàn)在只有period。它嘗試使用一個默認的company_id但這個默認ID在模型里沒有對應數(shù)據(jù)。模型計算過程出現(xiàn)除零錯誤拋出一個原始的ZeroDivisionError。Agent核心邏輯沒有處理ZeroDivisionError的代碼異常向上拋出。最終結(jié)果用戶看到“內(nèi)部服務器錯誤”。開發(fā)者排查需要從最頂層的錯誤日志開始逆向追蹤經(jīng)過估算工具、Agent邏輯最后才發(fā)現(xiàn)根源是第一個工具里的映射表連接問題。排查鏈路長責任不清。“完結(jié)流水線”模式Agent Harness加持下的新做法Agent核心邏輯解析意圖生成查詢對象。在調(diào)用工具前Harness的輸入驗證中間件會根據(jù)“數(shù)據(jù)查詢工具”注冊的Schema自動校驗對象。發(fā)現(xiàn)缺少company_id但多了一個company它可能會嘗試補全或直接在此處返回一個驗證錯誤給用戶“請?zhí)峁┕綢D”。假設驗證通過。數(shù)據(jù)查詢工具已完結(jié)映射表連接失敗。工具內(nèi)部進行最多3次重試。重試均失敗后它不會返回None而是構(gòu)造一個明確的ToolResponse:success: falseerror: ToolExecutionError(codeDEPENDENCY_UNAVAILABLE, message公司名稱映射服務暫時不可用, details{retry_attempts: 3})data: null同時它通過Harness的日志系統(tǒng)記錄一條結(jié)構(gòu)化錯誤日志包含錯誤碼、重試次數(shù)和追蹤ID。Agent核心邏輯收到ToolResponse檢查success為false并讀取error.code。它配置了錯誤處理策略對于DEPENDENCY_UNAVAILABLE錯誤觸發(fā)降級策略——改為使用一個本地的、可能過時的靜態(tài)映射文件來獲取company_id。如果本地文件也沒有則在此處決定流程的終結(jié)向用戶返回一個友好的消息“暫時無法獲取精確的公司信息請稍后再試或直接提供公司ID”。流程在此明確結(jié)束不會進入不可控的估算環(huán)節(jié)?？捎^測性整個過程的追蹤鏈是完整的。運維人員可以在儀表板上看到請求失敗在“數(shù)據(jù)查詢工具”錯誤原因是依賴服務不可用并且看到了重試記錄。Agent核心邏輯的降級決策也被記錄。責任清晰定位迅速。對比之下高下立判。“完結(jié)流水線”模式下問題在最早可能的地方被識別、封裝、并給出了明確的后續(xù)路徑成功、失敗但友好提示、觸發(fā)降級。Bug沒有像擊鼓傳花一樣往下流而是在每個環(huán)節(jié)都被“消化”或“轉(zhuǎn)化”了。5. 開發(fā)者的思維轉(zhuǎn)變從“實現(xiàn)功能”到“完結(jié)工序”推行“自工程完結(jié)”最難的不是技術(shù)而是思維習慣的轉(zhuǎn)變。它要求我們以終為始從“工序輸出”的角度來設計每一個模塊。設計時自問我這個模塊/函數(shù)/類交付給調(diào)用方的“產(chǎn)品”是什么一個確定的數(shù)據(jù)結(jié)構(gòu)一個保證清理的資源句柄一個完整的業(yè)務流程結(jié)果調(diào)用方需要做什么樣的檢查才能使用它我能讓這個檢查變得更簡單甚至不需要嗎實現(xiàn)時牢記異常不是用來拋的是用來處理的。處理不了所有異常那就處理你能處理的然后把剩下的包裝成調(diào)用方能夠理解和應對的類型。資源不是用來申請的是用來管理生命周期的。誰申請誰就在其作用域內(nèi)負責釋放。測試時驗證不僅要測試正常路徑更要測試邊界和異常路徑。你的模塊在輸入非法、依賴失效、資源不足的情況下輸出是否依然符合“完結(jié)”的契約它會不會把爛攤子丟出去評審時關(guān)注代碼評審時除了看邏輯是否正確要特別關(guān)注模塊的“接口契約”和“錯誤處理”?？纯从袥]有把本該自己處理的判斷丟給了調(diào)用方有沒有“偷偷”改變了某些全局狀態(tài)而沒有交代。在Agent Harness社區(qū)里我們經(jīng)?；ハ郣eview代碼一個常見的評論就是“這個地方返回null/undefined/異常調(diào)用方不好處理能不能在你的模塊里就給它一個確定的結(jié)果” 或者 “這個資源只在try塊里開了有沒有在finally塊或者用with語句確保關(guān)閉”這個過程一開始會有點痛苦感覺像是給自己戴上了“枷鎖”。但當你習慣之后你會發(fā)現(xiàn)你寫的代碼模塊性更強依賴更清晰在復雜系統(tǒng)比如由多個AI Agent協(xié)作的場景中集成時調(diào)試和維護的難度會大大降低。你不再需要深入每一個下游模塊去理解它可能拋出的各種奇怪異常因為你信任它交給你的總是一個“完結(jié)”的、可預測的結(jié)果。6. 超越Agent通用軟件工程中的“完結(jié)”實踐雖然我們以AI Agent和Agent Harness為例但“自工程完結(jié)”的理念適用于幾乎所有軟件工程領域。微服務架構(gòu)每個微服務都應該對其領域內(nèi)的業(yè)務邏輯和數(shù)據(jù)做到“完結(jié)”。它應該通過API網(wǎng)關(guān)或服務網(wǎng)格處理好認證、限流、熔斷對外提供穩(wěn)定的接口。一個服務內(nèi)部的數(shù)據(jù)存儲或緩存掛了應該通過降級策略如返回緩存舊數(shù)據(jù)或默認值來響應而不是讓調(diào)用方看到“數(shù)據(jù)庫連接失敗”。前端開發(fā)一個UI組件應該自己管理好它的加載狀態(tài)、錯誤狀態(tài)。數(shù)據(jù)獲取失敗時它應該在組件內(nèi)部顯示錯誤提示而不是拋出一個異常讓整個頁面崩潰。它接收的props應該有明確的PropTypes或TypeScript接口定義對不合理的輸入進行早期警告或使用默認值。數(shù)據(jù)處理管道ETL抽取、轉(zhuǎn)換、加載中的每一個步驟都應該對數(shù)據(jù)的質(zhì)量負責。清洗步驟應該處理缺失值、異常值轉(zhuǎn)換步驟應該保證輸出格式的嚴格一致。一個步驟失敗整個管道應該有檢查點Checkpoint和重試或死信隊列Dead Letter Queue機制而不是讓錯誤數(shù)據(jù)污染下游。其核心思想是一致的通過強化模塊內(nèi)的內(nèi)聚性和對外的契約性降低模塊間的耦合度與認知負擔從而構(gòu)建出更加健壯、可維護的系統(tǒng)。在當今系統(tǒng)越來越復雜、依賴越來越多的環(huán)境下這種思維不再是“好習慣”而是“生存必需”?；氐介_頭的“修水管”視頻。那個程序員犯的錯就是把“止住自家漏水”這個局部問題“解決”了卻沒有考慮這個操作在整個供水系統(tǒng)全局中是否“完結(jié)”。他關(guān)閉的閥門可能影響了主管道的壓力平衡把問題傳遞給了整個系統(tǒng)。我們的代碼也是如此。每一次圖省事的try-catch后直接throw每一次返回含義模糊的null每一次忘記關(guān)閉的連接都是在給系統(tǒng)的“下一道工序”——可能是另一個模塊可能是運維同事也可能是最終用戶——埋下一顆顆定時炸彈。Agent Harness項目給我的最大啟示就是它把TPS這種經(jīng)過時間考驗的、樸素的工程智慧用現(xiàn)代軟件框架的形式固化了下來。它逼著我們?nèi)ニ伎歼吔?、契約和狀態(tài)讓構(gòu)建可靠的AI Agent不再僅僅依賴于LLM的強大更依賴于扎實的、可預測的工程基礎設施。所以下次當你寫下一行代碼時不妨問問自己我這個“工序”“完結(jié)”了嗎