編譯 | 澤南

本文作者 Sebastian Raschka 是 AI 領(lǐng)域的知名學(xué)者，曾任威斯康星大學(xué)麥迪遜分校的統(tǒng)計(jì)學(xué)教授。

在本文中，我將探討編碼智能體（coding agents）及其智能體編排（agent harnesses）的整體設(shè)計(jì)：它們究竟是什么、工作原理如何，以及在實(shí)際應(yīng)用中各組件是如何協(xié)同運(yùn)作的。

廣泛地講，智能體之所以成為一個(gè)備受關(guān)注的重要議題，是因?yàn)榻趯?shí)用型大語言模型（LLM）系統(tǒng)所取得的諸多進(jìn)展，不僅僅歸功于模型本身的性能提升，更在于我們?nèi)绾稳ミ\(yùn)用這些模型。在許多實(shí)際應(yīng)用場景中，智能體周邊的支撐系統(tǒng) —— 例如工具調(diào)用、上下文管理及記憶機(jī)制 —— 所發(fā)揮的作用，其重要性絲毫不亞于模型本身。這也解釋了為何像 Claude Code 或 Codex 這類系統(tǒng)，往往給人的感覺要比單純在普通聊天界面中使用的同款基礎(chǔ)模型顯得更為強(qiáng)大、更具能力。

在本文中，我將詳細(xì)闡述構(gòu)成編碼智能體的六大核心構(gòu)建模塊。

Claude Code、Codex CLI 及其他編程智能體

如果你是開發(fā)者的話，你可能已經(jīng)很熟悉 Claude Code 或 Codex CLI 了，但為了鋪墊背景，不妨先說明一下：它們本質(zhì)上屬于「智能體式」編程工具，通過在應(yīng)用層 —— 即所謂的「智能體編排」（agentic harness）—— 中對大型語言模型（LLM）進(jìn)行封裝，從而使編程任務(wù)變得更加便捷且高效。

圖 1：Claude Code CLI、Codex CLI 和我自建的代碼智能體。

編程智能體（Coding agents）專為軟件開發(fā)工作而設(shè)計(jì)；在這一領(lǐng)域，關(guān)鍵要素不僅在于模型的選擇，更在于其周邊的系統(tǒng)架構(gòu) —— 包括代碼倉庫的上下文環(huán)境、工具的設(shè)計(jì)、提示緩存的穩(wěn)定性、記憶機(jī)制以及長會(huì)話的連續(xù)性。

這種區(qū)分至關(guān)重要，因?yàn)楫?dāng)我們探討大型語言模型（LLM）的編程能力時(shí)，人們往往會(huì)將模型本身、其推理行為以及作為產(chǎn)品的智能體混為一談。不過，在深入探討編程智能體的具體細(xì)節(jié)之前，請?jiān)试S我先簡要補(bǔ)充一些背景信息，闡明「大型語言模型」、「推理模型」和「智能體」這三個(gè)更宏觀概念之間的區(qū)別。

大模型、推理模型與智能體的關(guān)系

大型語言模型（LLM）本質(zhì)上是一種核心的「預(yù)測下一個(gè) token」的模型。而「推理模型」雖然仍屬于 LLM 的范疇，但通常經(jīng)過了專門的訓(xùn)練和 / 或提示工程優(yōu)化，使其在推理過程中投入更多的計(jì)算資源，用于執(zhí)行中間步驟的邏輯推理、結(jié)果驗(yàn)證，或在候選答案集合中進(jìn)行搜索。

智能體（Agent）則是一個(gè)構(gòu)建在模型之上的抽象層，可以將其理解為圍繞核心模型運(yùn)作的一個(gè)「控制回路」。通常情況下，當(dāng)接收到一個(gè)既定目標(biāo)后，智能體層（或稱「編排框架」）會(huì)負(fù)責(zé)決策下一步需要檢查哪些信息、應(yīng)當(dāng)調(diào)用哪些工具、如何更新自身的狀態(tài)，以及何時(shí)終止任務(wù)等一系列操作。

粗略地講，我們可以用這樣一個(gè)類比來理解它們之間的關(guān)系：LLM 相當(dāng)于引擎，推理模型則相當(dāng)于經(jīng)過強(qiáng)化的引擎（性能更強(qiáng)，但運(yùn)行成本也更高），而智能體編排框架則扮演著輔助我們操控這一引擎的角色。盡管這個(gè)類比并不完美 —— 畢竟我們也可以將常規(guī) LLM 和推理型 LLM 作為獨(dú)立的模型直接使用（例如在聊天界面或 Python 交互會(huì)話中）—— 但我希望它能有效地傳達(dá)出其中的核心要義。

圖 2：傳統(tǒng)大語言模型（LLM）、推理型大語言模型（或推理模型），以及封裝在智能體編排框架中的大語言模型之間的關(guān)系。

換句話說，智能體就是一個(gè)在特定環(huán)境中反復(fù)調(diào)用模型的系統(tǒng)。

因此，簡而言之，我們可以將其歸納如下：

• 大型語言模型：原始模型。
• 推理模型：一種經(jīng)過優(yōu)化的 LLM，旨在輸出中間推理過程（痕跡），并具備更強(qiáng)的自我驗(yàn)證能力。
• 智能體：一個(gè)循環(huán)執(zhí)行的實(shí)體，它結(jié)合使用了模型、工具、記憶模塊以及環(huán)境反饋。
• 智能體編排框架（Agent Harness）：圍繞智能體構(gòu)建的軟件支架，負(fù)責(zé)管理上下文、工具調(diào)用、提示詞、狀態(tài)以及控制流。
• 代碼編排框架（Coding Harness）：智能體框架的一種特例；即專用于軟件工程任務(wù)的框架，負(fù)責(zé)管理代碼上下文、工具、代碼執(zhí)行以及迭代反饋。

如上所述，在智能體和編碼工具的語境下，我們還會(huì)遇到兩個(gè)流行術(shù)語：智能體編排框架和（智能體驅(qū)動(dòng)的）代碼編排框架。后者是圍繞模型構(gòu)建的軟件支架，旨在輔助模型高效地編寫和編輯代碼。而智能體編排框架的范疇則更為廣泛，并不局限于代碼領(lǐng)域（例如，可以參考 OpenClaw 項(xiàng)目）。Codex 和 Claude Code 均可被視為代碼編排框架的實(shí)例。

總之，更優(yōu)秀的大模型能為推理模型（通常需要經(jīng)過額外的訓(xùn)練）奠定更堅(jiān)實(shí)的基礎(chǔ)；而智能體框架則能進(jìn)一步挖掘并充分發(fā)揮該推理模型的潛能。

誠然，LLM 和推理模型本身也具備獨(dú)立解決編碼任務(wù)的能力（即無需借助編排框架輔助）；但實(shí)際上，編碼工作遠(yuǎn)不止是單純的「下一個(gè) token 生成」（Next-token generation）。編碼工作很大程度上還涉及代碼倉庫導(dǎo)航、搜索、函數(shù)查找、代碼差異應(yīng)用（Diff）、測試執(zhí)行、錯(cuò)誤排查，以及在整個(gè)過程中維持所有相關(guān)信息的上下文連貫性。

程序員們想必深知這是一項(xiàng)極耗心力的腦力勞動(dòng) —— 這也正是我們在專心編碼時(shí)最不愿被打擾的原因所在 :））

圖 3。一個(gè)編碼編排框架由三個(gè)層級(jí)構(gòu)成：模型族、智能體循環(huán)以及運(yùn)行時(shí)支持。其中，模型充當(dāng)「引擎」；智能體循環(huán)驅(qū)動(dòng)迭代式的問題求解過程；而運(yùn)行時(shí)支持則提供底層的「管道」基礎(chǔ)設(shè)施。在循環(huán)內(nèi)部，「觀察」環(huán)節(jié)從環(huán)境中收集信息；「審視」環(huán)節(jié)對這些信息進(jìn)行分析；「決策」環(huán)節(jié)選定下一步行動(dòng)；最后由「執(zhí)行」環(huán)節(jié)付諸實(shí)施。

這里的關(guān)鍵要點(diǎn)在于，一套優(yōu)秀的「編碼輔助框架」能讓具備推理能力和不具備推理能力的模型，在實(shí)際表現(xiàn)上顯得比單純置于普通聊天框中強(qiáng)大得多 —— 因?yàn)樗兄谔幚砩舷挛墓芾淼纫幌盗嘘P(guān)鍵任務(wù)。

編碼輔助編排框架

正如上一節(jié)所提到的，當(dāng)我們提及「輔助編排框架」（Harness）時(shí)，通常是指圍繞在模型外部的那一層軟件層。這一層負(fù)責(zé)組裝提示詞（Prompts）、調(diào)用外部工具、追蹤文件狀態(tài)、應(yīng)用代碼修改、執(zhí)行終端命令、管理權(quán)限、緩存穩(wěn)定前綴、存儲(chǔ)記憶信息，以及處理更多其他任務(wù)。

如今，在使用大模型時(shí)，相比于直接向模型輸入提示詞，或是使用簡單的網(wǎng)頁聊天界面（后者更接近于「上傳文件后進(jìn)行對話」的模式），正是這一層輔助框架塑造了用戶體驗(yàn)的絕大部分。

在我看來，當(dāng)前各類大模型的「原生版本」在能力上已趨于同質(zhì)化（例如，GPT-5.4、Opus 4.6 和 GLM-5 等模型的原生版本之間），因此，這套輔助框架往往就成了決定某款大模型表現(xiàn)優(yōu)于另一款的關(guān)鍵差異化因素。

這純屬推測，但我猜想：如果我們把當(dāng)前最新、能力最強(qiáng)的開源權(quán)重大型語言模型之一（例如 GLM-5）置入一套類似的輔助框架之中，它的表現(xiàn)很可能就能與 Codex 環(huán)境下的 GPT-5.4，或是 Claude Code 環(huán)境下的 Claude Opus 4.6 達(dá)到同一水平。話雖如此，針對特定的輔助框架進(jìn)行一些「后訓(xùn)練」通常還是有益的。舉例來說，OpenAI 歷史上就曾針對 GPT-5.3 模型維護(hù)過兩個(gè)不同的變體版本：GPT-5.3 和 GPT-5.3-Codex。

在下一節(jié)中，我將深入探討具體細(xì)節(jié)，并以我開發(fā)的「Mini Coding Agent」項(xiàng)目為例（GitHub 鏈接：https://github.com/rasbt/mini-coding-agent），來詳細(xì)解析一套編碼輔助框架的核心組成部分。

圖 4：編碼智能體 / 編碼編排框架的主要特性，將在后續(xù)章節(jié)中討論。

順便一提，為了行文簡潔，本文中「編碼智能體」和「編碼編排框架」這兩個(gè)術(shù)語有時(shí)會(huì)互換使用。（嚴(yán)格來說，智能體是模型驅(qū)動(dòng)的決策循環(huán)，而框架是提供上下文、工具和執(zhí)行支持的外部軟件框架。）

圖 5：一個(gè)極簡但功能完備、從零構(gòu)建的「迷你編程智能體」（純 Python 實(shí)現(xiàn)）。

言歸正傳，下方列出了編程智能體的六大核心組件。你可以查閱我所構(gòu)建的那個(gè)極簡但功能完備、從零構(gòu)建的「迷你編程智能體」（純 Python 實(shí)現(xiàn)）的源代碼，以獲取更具體的代碼示例。在該代碼中，我已通過注釋對下文將要探討的這六大組件進(jìn)行了標(biāo)注

################################## Six Agent Components ################################### 1) Live Repo Context -> WorkspaceContext# 2) Prompt Shape And Cache Reuse -> build_prefix, memory_text, prompt# 3) Structured Tools, Validation, And Permissions -> build_tools, run_tool, validate_tool, approve, parse, path, tool_*# 4) Context Reduction And Output Management -> clip, history_text# 5) Transcripts, Memory, And Resumption -> SessionStore, record, note_tool, ask, reset# 6) Delegation And Bounded Subagents -> tool_delegate

1、實(shí)時(shí)代碼庫上下文

這或許是最顯而易見的組件，但同時(shí)也是至關(guān)重要的組件之一。

當(dāng)用戶發(fā)出「修復(fù)測試」或「實(shí)現(xiàn) xyz 功能」之類的指令時(shí)，模型應(yīng)當(dāng)能夠識(shí)別當(dāng)前是否處于 Git 代碼庫環(huán)境中，正處于哪條分支上，哪些項(xiàng)目文檔可能包含相關(guān)指引，諸如此類。

之所以如此，是因?yàn)檫@些細(xì)節(jié)往往會(huì)改變或影響模型應(yīng)采取的正確行動(dòng)。例如，「修復(fù)測試」這一指令本身并非一條自足的指令。如果智能體能夠查閱諸如 AGENTS.md 或項(xiàng)目 README 之類的文檔，它便能獲知應(yīng)當(dāng)執(zhí)行哪條測試命令等具體信息。若能知曉代碼庫的根目錄位置及整體布局，它便能直奔目標(biāo)位置進(jìn)行查找，而非盲目猜測。

此外，Git 分支信息、當(dāng)前狀態(tài)及提交記錄等數(shù)據(jù)，也能提供更為豐富的上下文信息，幫助智能體了解當(dāng)前正在進(jìn)行哪些變更，以及應(yīng)當(dāng)將工作重心聚焦于何處。

圖 6：智能體運(yùn)行框架首先構(gòu)建一份簡要的「工作區(qū)摘要」，隨后將其與用戶請求合并，以此為項(xiàng)目提供額外的上下文信息。

核心要點(diǎn)在于：該編程代理在著手執(zhí)行任何任務(wù)之前，會(huì)預(yù)先收集相關(guān)信息（即作為工作區(qū)摘要的「穩(wěn)定事實(shí)」）；這樣一來，它就不必在處理每一個(gè)提示詞（Prompt）時(shí)都從零開始，陷入缺乏上下文的窘境。

2、提示詞結(jié)構(gòu)與緩存復(fù)用

一旦智能體獲得了代碼倉庫的概覽視圖，接下來的問題便是：如何將這些信息有效地輸入給語言模型？上一幅圖中展示了這一過程的簡化視圖（即「組合提示詞：前綴 + 請求」）；但在實(shí)際操作中，若針對用戶的每一次查詢都重新合并并處理一遍工作區(qū)摘要，將是相對低效且浪費(fèi)資源的做法。

換言之，編程會(huì)話往往具有重復(fù)性，且智能體所遵循的規(guī)則通常保持不變。各類工具的功能描述通常也維持原樣。甚至連工作區(qū)摘要的內(nèi)容，通常也（在很大程度上）保持穩(wěn)定。真正發(fā)生變化的主要因素，通常僅限于最新的用戶請求、近期的交互對話記錄，以及可能涉及的短期記憶信息。

如圖下方所示，「智能」運(yùn)行時(shí)環(huán)境并不會(huì)在每一個(gè)交互回合中，都將所有信息重新打包成一個(gè)龐大且未作區(qū)分的整體提示詞。

圖 7：智能體編排框架構(gòu)建一個(gè)「穩(wěn)定提示前綴」，隨后加入不斷變化的會(huì)話狀態(tài)，并將合并后的完整提示輸入給模型。

與第 1 節(jié)的主要區(qū)別在于：第 1 節(jié)側(cè)重于收集代碼倉庫的相關(guān)事實(shí)信息；而在本節(jié)中，我們的重點(diǎn)是如何高效地封裝并緩存這些事實(shí)，以便在后續(xù)對模型進(jìn)行反復(fù)調(diào)用時(shí)加以復(fù)用。

所謂「穩(wěn)定提示前綴」中的「穩(wěn)定」，意指其中包含的信息變動(dòng)極小。它通常涵蓋了通用指令、工具描述以及工作空間的概覽信息。如果其中未發(fā)生任何實(shí)質(zhì)性變化，我們便不希望在每一次交互過程中都耗費(fèi)計(jì)算資源將其從頭重建。

而其他組件的更新頻率則要高得多（通常是每一輪交互更新一次）。這些組件包括短期記憶、近期的對話記錄以及最新的用戶請求。

簡而言之，針對「穩(wěn)定提示前綴」所實(shí)施的緩存機(jī)制，其核心理念就在于：通過智能的運(yùn)行時(shí)環(huán)境，盡可能地對這部分內(nèi)容進(jìn)行復(fù)用。

3、工具訪問與使用

工具訪問與使用環(huán)節(jié)讓交互體驗(yàn)從聊天逐漸轉(zhuǎn)變?yōu)橹悄荏w。

普通模型可以生成文字形式的命令建議，但編碼框架中的大模型應(yīng)該執(zhí)行更精準(zhǔn)、更有用的任務(wù)，并能夠?qū)嶋H執(zhí)行命令并獲取結(jié)果（而不是讓我們手動(dòng)調(diào)用命令并將結(jié)果粘貼回聊天窗口）。

但編排框架通常不會(huì)讓模型隨意生成語法，而是提供一個(gè)預(yù)定義的、包含明確輸入和邊界的可用工具列表。（當(dāng)然，像 Python 的 subprocess.call 這樣的工具也可以包含在內(nèi)，這樣智能體就可以執(zhí)行任意范圍的 shell 命令。）

工具使用流程如下圖所示。

圖 8：模型發(fā)出一個(gè)結(jié)構(gòu)化操作，框架對其進(jìn)行驗(yàn)證，并可選擇性地請求批準(zhǔn)，然后執(zhí)行該操作，并將有界結(jié)果反饋回循環(huán)。

為了說明這一點(diǎn)，以下示例展示了用戶使用迷你編碼智能體時(shí)通?？吹降慕缑?。（由于它非常簡潔，并且使用純 Python 編寫，沒有任何外部依賴，因此不如 Claude Code 或 Codex 那樣美觀。）

圖 9：Mini Coding Agent 中工具調(diào)用審批請求的示意圖。

在此環(huán)節(jié)中，模型必須選擇一個(gè)編排框架（harness）能夠識(shí)別的動(dòng)作，例如列出文件、讀取文件、執(zhí)行搜索、運(yùn)行 Shell 命令、寫入文件等。同時(shí)，它還必須以一種編排框架能夠進(jìn)行校驗(yàn)的格式提供相應(yīng)的參數(shù)。

因此，當(dāng)模型請求執(zhí)行某項(xiàng)操作時(shí)，運(yùn)行時(shí)環(huán)境會(huì)暫停執(zhí)行，并運(yùn)行一系列程序化檢查，例如：

• 「這是一個(gè)已知的工具嗎？」
• 「提供的參數(shù)是否有效？」
• 「此操作是否需要用戶的審批？」
• 「請求訪問的路徑是否位于工作區(qū)（workspace）范圍之內(nèi)？」

只有在通過了上述所有檢查之后，實(shí)際的操作指令才會(huì)被真正執(zhí)行。

誠然，運(yùn)行編碼智能體確實(shí)伴隨著一定的風(fēng)險(xiǎn)；但得益于編排框架的這些檢查機(jī)制，系統(tǒng)的可靠性也得到了提升，因?yàn)槟Ｐ蜔o法執(zhí)行完全隨意、不受控的指令。

此外，除了能夠拒絕格式錯(cuò)誤的動(dòng)作請求并實(shí)施審批門控機(jī)制外，通過對文件路徑進(jìn)行校驗(yàn)，還可以確保文件訪問操作始終被限制在代碼倉庫（repo）的范圍之內(nèi)。

從某種意義上說，編排框架雖然限制了模型的自由度，卻顯著提升了其實(shí)用性。

4、最小化上下文膨脹

上下文膨脹并非編碼智能體所獨(dú)有的問題，而是大模型普遍面臨的一個(gè)難題。誠然，如今的 LLM 已能支持越來越長的上下文窗口，但長上下文依然成本高昂，且若其中夾雜大量無關(guān)信息，還可能引入額外的「噪聲」。

在多輪對話過程中，編碼智能體比普通 LLM 更易受上下文膨脹之苦 —— 這主要是由于頻繁的文件讀取、冗長的工具輸出、系統(tǒng)日志等因素所致。

如果運(yùn)行時(shí)環(huán)境對上述所有信息都采取「全保真」的存儲(chǔ)策略，那么可用的上下文 Token 額度很快就會(huì)被耗盡。因此，一套優(yōu)秀的代碼智能體編排框架（Coding Harness）通常會(huì)采取相當(dāng)精妙的策略來應(yīng)對上下文膨脹問題，其處理手段遠(yuǎn)比普通聊天界面那種單純的「截?cái)唷够颉刚共僮饕獜?fù)雜得多。

從概念層面來看，編碼智能體中的「上下文壓縮」機(jī)制大致可按下方圖示所概括的流程運(yùn)作。具體而言，我們在此將視角進(jìn)一步聚焦于上一節(jié)圖 8 中所展示的「截取」（Clip，即第 6 步）環(huán)節(jié)。

圖 10：在重新送入提示詞之前，系統(tǒng)會(huì)對大篇幅的輸出進(jìn)行截?cái)?，對較早的讀取內(nèi)容進(jìn)行去重，并對交互記錄（Transcript）進(jìn)行壓縮。

一個(gè)極簡的編排框架至少會(huì)采用兩種「緊湊化」策略來應(yīng)對這一問題。

第一種策略是「截?cái)唷梗–lipping），即縮短冗長的文檔片段、大型工具輸出、內(nèi)存筆記以及交互記錄條目。換言之，它能防止任何單段文本僅僅因?yàn)閮?nèi)容冗長，就獨(dú)占了大部分的提示詞預(yù)算。

第二種策略是「記錄縮減」或「摘要化」，即將完整的會(huì)話歷史（關(guān)于這一點(diǎn)，下一節(jié)會(huì)有更詳細(xì)的闡述）轉(zhuǎn)化為一段篇幅更小、更適合作為提示詞輸入的摘要。

這里的關(guān)鍵技巧在于：保留近期事件的更多細(xì)節(jié)，因?yàn)樗鼈兺c當(dāng)前步驟的關(guān)聯(lián)度更高；而對于較早期的事件，我們會(huì)采取更激進(jìn)的壓縮手段，因?yàn)樗鼈兊南嚓P(guān)性通常較低。

此外，我們還會(huì)對較早期的文件讀取操作進(jìn)行去重處理，從而避免模型因同一文件在會(huì)話早期被反復(fù)讀取，而不得不一遍又一遍地重復(fù)接收相同的文件內(nèi)容。

總而言之，我認(rèn)為這正是優(yōu)秀「編碼智能體」設(shè)計(jì)中那些往往被低估、看似枯燥乏味的關(guān)鍵環(huán)節(jié)之一。許多表面上歸功于「模型質(zhì)量」的優(yōu)異表現(xiàn)，實(shí)際上恰恰源自于「上下文質(zhì)量」的提升。

5、結(jié)構(gòu)化會(huì)話記憶

在實(shí)踐中，此處涵蓋的所有這 6 個(gè)核心概念都是高度交織在一起的；不同的章節(jié)和圖示會(huì)以不同的側(cè)重點(diǎn)或粒度來闡述這些概念。在上一節(jié)中，我們探討了在提示階段（prompt-time）如何利用歷史信息，以及如何構(gòu)建一份緊湊的會(huì)話記錄（transcript）。當(dāng)時(shí)的核心問題是：在下一輪交互中，究竟應(yīng)該將多少過往的歷史信息回傳給模型？因此，那一節(jié)的重點(diǎn)在于信息的壓縮、截?cái)?、去重以及時(shí)效性。

而本節(jié) —— 即「結(jié)構(gòu)化會(huì)話記憶」—— 所探討的則是歷史信息在存儲(chǔ)階段（storage-time）的內(nèi)部結(jié)構(gòu)。本節(jié)的核心問題在于：作為智能體，它應(yīng)當(dāng)隨著時(shí)間的推移保留哪些信息，并將其作為永久性的記錄？因此，本節(jié)的重點(diǎn)在于：運(yùn)行時(shí)環(huán)境應(yīng)維護(hù)一份更為完整的會(huì)話記錄作為「持久化狀態(tài)」；與此同時(shí)，它還應(yīng)維護(hù)一個(gè)更為輕量級(jí)的「記憶層」—— 該記憶層體積較小，且其內(nèi)容會(huì)經(jīng)歷修改與壓縮處理，而非僅僅進(jìn)行簡單的追加。

綜上所述，一個(gè)編程智能體會(huì)將其狀態(tài)拆分為（至少）兩個(gè)層級(jí)：

• 工作記憶（Working Memory）：即智能體顯式維護(hù)的一份經(jīng)過高度提煉、體積較小的狀態(tài)信息。
• 完整會(huì)話記錄（Full Transcript）：這份記錄涵蓋了所有的用戶請求、工具輸出結(jié)果以及大模型的響應(yīng)內(nèi)容。

圖 11：新事件會(huì)被追加到「完整對話記錄」中，并被歸納總結(jié)至「工作記憶」里。磁盤上的會(huì)話文件通常以 JSON 格式存儲(chǔ)。

上圖展示了兩個(gè)主要的會(huì)話文件 ——「完整對話記錄」和「工作記憶」—— 它們通常以 JSON 文件的形式存儲(chǔ)在硬盤上。正如前文所述，「完整對話記錄」保存了完整的歷史信息，即使智能體程序被關(guān)閉，該記錄也能支持后續(xù)的會(huì)話恢復(fù)?！腹ぷ饔洃洝箘t更像是一個(gè)經(jīng)過提煉的精簡版本，其中包含了當(dāng)前最重要的信息；這一點(diǎn)在功能上與「精簡對話記錄」有著一定的關(guān)聯(lián)。

不過，「精簡對話記錄」與「工作記憶」各自承擔(dān)的職責(zé)略有不同?！妇唽υ捰涗洝怪饕糜谔崾驹~的重構(gòu)。其作用是向模型提供近期歷史信息的壓縮視圖，從而使模型無需在每一輪對話中都查閱完整的對話記錄，便能順暢地延續(xù)對話?！腹ぷ饔洃洝箘t更側(cè)重于保障任務(wù)的連續(xù)性。其作用是維護(hù)一份小巧且經(jīng)過顯式管理的摘要，專門用于記錄跨輪次對話中那些至關(guān)重要的信息，例如當(dāng)前正在執(zhí)行的任務(wù)、重要的相關(guān)文件以及近期的備忘記錄等。

參照上圖中的第 4 步，在隨后的下一輪對話中（為避免上圖顯得過于繁雜，該輪次并未在圖中展示），最新的用戶請求 —— 連同大模型的響應(yīng)及工具的輸出 —— 將被作為一條「新事件」，同時(shí)記錄并追加到「完整對話記錄」與「工作記憶」之中。

6、使用（有界）子智能體進(jìn)行任務(wù)委托

一旦智能體擁有了工具和狀態(tài)，下一個(gè)有用的功能之一就是任務(wù)委托。

原因在于，它允許我們通過子智能體將某些工作并行化為子任務(wù)，從而加速主任務(wù)的執(zhí)行。例如，主智能體可能正在執(zhí)行某個(gè)任務(wù)，但仍然需要一些輔助信息，例如哪個(gè)文件定義了某個(gè)符號(hào)、某個(gè)配置的含義是什么，或者某個(gè)測試失敗的原因。將這些信息拆分成一個(gè)有界子任務(wù)會(huì)很有用，而不是強(qiáng)制一個(gè)循環(huán)同時(shí)處理所有線程的工作。

（在我的迷你編碼代理中，實(shí)現(xiàn)更簡單，子智能體仍然同步運(yùn)行，但基本思想是相同的。）

子智能體只有在繼承足夠的上下文來執(zhí)行實(shí)際工作時(shí)才有用。但如果我們不加以限制，就會(huì)出現(xiàn)多個(gè)智能體重復(fù)工作、訪問相同文件或生成更多子智能體等問題。

所以，棘手的設(shè)計(jì)問題不僅在于如何生成子智能體，還在于如何綁定子智能體。

圖 12：子智能體繼承了足以使其發(fā)揮作用的上下文，但其運(yùn)行邊界比主智能體更為嚴(yán)格。

這里的關(guān)鍵在于：子智能體既繼承了足夠的上下文以確保其有效性，同時(shí)也受到了一定的限制（例如，被設(shè)定為只讀模式，且遞歸深度受到限制）。

Claude Code 早在很久以前便已支持子智能體功能，而 Codex 則是近期才引入這一特性的。通常情況下，Codex 并不會(huì)強(qiáng)制將子智能體設(shè)定為只讀模式；相反，它們往往會(huì)繼承主智能體的大部分沙箱環(huán)境與審批配置。因此，這里的「邊界」更多是指任務(wù)的范圍界定、上下文環(huán)境以及執(zhí)行深度等方面的限制。

總結(jié)

上一節(jié)旨在概述編碼智能體系統(tǒng)的主要組成部分。正如前文所述，從實(shí)現(xiàn)層面來看，這些組件之間或多或少都存在著深度交織與耦合。不過，我仍希望通過逐一剖析這些組件的方式，能有助于讀者構(gòu)建起一套關(guān)于編碼智能體編排框架運(yùn)作機(jī)制的整體心智模型，并理解為何相比于簡單的多輪對話模式，代碼智能體能夠顯著提升大語言模型的實(shí)用價(jià)值。

圖 13：前文討論過的編碼編排框架（Coding Harness）的六大主要特征。

如果你有興趣看到這些特征是如何通過簡潔、極簡風(fēng)格的 Python 代碼實(shí)現(xiàn)的，不妨看看「Mini Coding Agent」。

它與 OpenClaw 相比有何不同？

OpenClaw 確實(shí)是一個(gè)值得拿來對比的有趣案例，但它與本文所探討的系統(tǒng)并非完全屬于同一類型。

OpenClaw 更像是一個(gè)運(yùn)行于本地的通用型智能體平臺(tái) —— 盡管它也具備編碼能力 —— 而非一款專精于（終端環(huán)境下的）編碼輔助工具。

不過，它與編碼輔助框架之間仍存在諸多重疊之處：

• 它會(huì)在工作區(qū)內(nèi)利用提示詞和指令文件，例如 AGENTS.md、SOUL.md 和 TOOLS.md；
• 它會(huì)保存 JSONL 格式的會(huì)話記錄文件，并具備會(huì)話記錄壓縮與會(huì)話管理功能；
• 它能夠衍生出輔助會(huì)話及子智能體；
• 等等。

然而，正如上文所述，兩者的側(cè)重點(diǎn)截然不同。編碼智能體的設(shè)計(jì)初衷，是為了優(yōu)化個(gè)人開發(fā)者在代碼倉庫中工作時(shí)的體驗(yàn) —— 即高效地指揮輔助工具去檢查文件、修改代碼并執(zhí)行本地工具。相比之下，OpenClaw 的設(shè)計(jì)重心則在于跨聊天窗口、頻道及工作區(qū)運(yùn)行大量「長生命周期」的本地智能體，而編碼工作僅僅是其眾多重要任務(wù)負(fù)載之一。

參考原文：

https://magazine.sebastianraschka.com/p/components-of-a-coding-agent