AI 智能體到底應該如何構建？分享 Github 上收獲 4k stars 的 12 條原則 原創(chuàng)
編者按： AI 智能體到底應該如何構建？是追求復雜的端到端解決方案，還是回歸軟件工程的本質思維？
我們今天為大家?guī)淼奈恼拢髡叩挠^點是：智能體本質上就是軟件，應該用嚴謹?shù)能浖こ淘瓌t來構建，而非盲目追求“黑箱式”的復雜框架。
文章從智能體的發(fā)展歷程出發(fā)，深入剖析了從有向圖到 DAG 編排工具，再到今天 AI 智能體的技術演進脈絡。隨后，作者系統(tǒng)性地提出了構建可靠 LLM 應用的12個核心原則。
這篇文章為正在構建 AI 應用的開發(fā)者提供了一套完整而實用的方法論，特別適合那些希望擺脫框架束縛、追求技術本質的工程師。相信通過這12個原則的指導，我們能夠構建出更加可靠、可控、可擴展的智能體系統(tǒng)。
01 AI Agent 是如何走到今天的
1.1 我的觀點僅供參考
無論您是智能體領域的新手，還是像我這樣固執(zhí)的老兵，我都將試圖說服您摒棄對 AI Agent 的大部分固有認知，退一步，從第一性原理（first principles）出發(fā)重新思考它們。（如果你錯過了不久前 OpenAI 發(fā)布的內容，這里有個劇透預警：把更多智能體邏輯塞進 API 后面并非正解）
02 智能體本質上是軟件，讓我們簡要追溯其發(fā)展歷程
讓我們回溯智能體的發(fā)展脈絡。
2.1 60 年前
這個階段重點探討的是有向圖（DGs）及其無環(huán)版本 —— 有向無環(huán)圖(DAGs)。首先要指出的是...軟件本質上就是有向圖。這就是為什么我們過去常用流程圖表示程序的原因。
2.2 20 年前
約 20 年前，DAG 編排工具開始流行。我們開始談論 Airflow[1]、Prefect[2] 等經典工具，以及它們的前輩，還有 dagster[3]、inggest[4]、windmill[5] 等新秀。這些編排工具沿用了相同的圖模式，同時增加了可觀測性（observability）、模塊化（modularity）、重試機制（retries）、管理界面（administration）等功能優(yōu)勢。
2.3 10-15 年前
當機器學習模型開始展現(xiàn)出實用價值時，我們開始看到融入 ML 模型的 DAG 工作流。一些典型的步驟可能包括“將此列中的文本匯總到一個新列中”或“按嚴重程度/情感對支持工單進行分類”。
但歸根結底，這些軟件在很大程度上還是確定性軟件（deterministic software）。
2.4 智能體技術帶來的根本性變革
我并非第一個提出此觀點[6]的人，但當我開始研究智能體時，最深刻的領悟是：你可以徹底摒棄 DAG 架構。無需軟件工程師針對每個步驟和邊界條件進行編碼，只需賦予智能體一個目標和一組狀態(tài)轉移規(guī)則：
讓 LLM 實時做出決策，找出路徑。
這樣做的好處是可以減少代碼編寫量。你只需為 LLM 定義圖的"邊"，由其自主推導"節(jié)點"。借此，系統(tǒng)可具備錯誤自恢復能力，大幅減少代碼量，甚至可能發(fā)現(xiàn) LLM 獨創(chuàng)的問題解決方案。
2.5 智能體（Agents）的核心運行機制是一個循環(huán)體系
換個角度看，這是一個包含 3 個步驟的循環(huán)體系：
1）LLM 通過結構化 JSON 輸出確定工作流的下一步（"工具調用"）
2）由確定性代碼執(zhí)行工具調用
3）將工具運行結果追加至上下文窗口
4）不斷循環(huán)直至判定下一步為"完成"狀態(tài)
初始上下文僅是起始事件（可能是用戶消息、定時觸發(fā)任務或 webhook 等），然后我們要求 LLM 選擇下一步（工具）或判斷任務是否完成。
下面是一個多步驟示例：
而生成的“materialized” DAG 結構示例如下：
2.6 “循環(huán)往復，直至問題解決”模式的缺陷
該模式最顯著的弊端：
- 當上下文窗口過長時，智能體會迷失方向，他們陷入反復嘗試同一種錯誤方法的循環(huán)
- 字面意思就是這樣，僅此一項就足以使該方法失效
即使你沒有手動構建過智能體，在使用自動化編程工具時也應當遭遇過這種長上下文問題。系統(tǒng)往往在多次交互后陷入混亂，迫使您重啟對話。
我還想提出一個我經常聽到的觀點，你可能已深有體會：
即使模型支持的上下文窗口越來越大，精準、簡潔的提示詞始終能獲得更優(yōu)的結果
與我交流過的多數(shù)開發(fā)者都放棄了"工具調用循環(huán)（tool calling loop）"方案，皆因發(fā)現(xiàn)超過 10-20 次交互后，LLM 便無法恢復任務狀態(tài)。即便智能體準確率達 90%，這仍與"可交付客戶使用"的標準相去甚遠。試想一個網(wǎng)頁應用若在 10% 的訪問中崩潰，會是一種怎樣的用戶體驗？
2.7 真正有效的方法 —— 微智能體（micro agents）
我在實際應用中觀察到一種比較常見的方法，使用智能體架構并將其嵌入到更宏觀的、更具確定性的有向無環(huán)圖（DAG）系統(tǒng)中。
您可能會問："為什么在這種情況下還要使用智能體？"我們稍后會詳細解釋。簡而言之，讓語言模型管理限定范圍明確的任務集合，可以輕松整合實時的人類反饋，并將這些反饋轉化為工作流步驟，而不會陷入上下文錯誤循環(huán)（即后文所提到的 factor 1、factor 3、factor 7）。
2.8 現(xiàn)實生活中的微智能體案例
下面這個示例展示了如何使用確定性代碼運行微智能體，處理部署過程中的人工介入步驟：
- 人工將 PR 合并到 GitHub 主分支
- 使用確定性代碼將修改后的項目部署到預發(fā)布環(huán)境
- 使用確定性代碼運行預發(fā)布環(huán)境的端到端（e2e）測試
- 使用確定性代碼將初始上下文"將 SHA 4af9ec0 部署到生產環(huán)境"移交智能體進行生產環(huán)境的部署
- 智能體調用 deploy_frontend_to_prod(4af9ec0)
- 使用確定性代碼請求人工批準此操作
- 人工拒絕操作并反饋"能否先部署后端部分？"
- 智能體調用 deploy_backend_to_prod(4af9ec0)
- 使用確定性代碼請求人工批準此操作
- 人工批準進行操作
- 使用確定性代碼執(zhí)行后端部分的部署
- 智能體調用 deploy_frontend_to_prod(4af9ec0)
- 使用確定性代碼請求人工批準此操作
- 人工批準進行操作
- 使用確定性代碼執(zhí)行前端部分的部署
- 智能體判定任務成功完成，流程結束！
- 使用確定性代碼運行生產環(huán)境的端到端測試
- 確定性代碼任務完成后，若檢測到異常，則轉交回滾智能體進行故障審查，必要時執(zhí)行版本回退
這個示例基于我們?yōu)楣芾?Humanlayer 的部署流程而部署的一個開源智能體（OSS agent），以下是我上周與它的真實對話記錄：
我們沒有讓這個智能體擁有過多的功能或復雜的職責。LLM 的核心價值在于解析人類的自然語言反饋，并提出更新的行動方案。我們盡可能避免讓它同時處理過多無關的任務或記憶冗長的歷史記錄，使 LLM 專注于 5-10 步的小型工作流。
這里有另一個更經典的客戶支持/ chatbot 示例[7]。
2.9 那么，智能體的本質究竟是什么？
- prompt - 告訴 LLM 如何行動，以及它可以使用哪些“工具”。prompt 的輸出是一個 JSON 對象，用于描述工作流程中的下一步（"工具調用"或"函數(shù)調用"）。（factor 2）
- switch 語句 - 根據(jù) LLM 返回的 JSON 內容決定后續(xù)操作。（factor 8 的一部分）
- 累積的上下文 - 記錄已執(zhí)行的操作步驟及其運行結果（factor 3）
- for 循環(huán) - 循環(huán)執(zhí)行以下操作，直至大語言模型（LLM）返回終止信號（如標記為"Terminal"的工具調用或自然語言響應）：將 switch 語句的執(zhí)行結果加入上下文窗口，并讓 LLM 決定下一步動作。（factor 8）
以“deploybot”為例，我們通過自主掌控流程邏輯和上下文積累，獲得了以下優(yōu)勢：
- 在 switch 語句和 for 循環(huán)中，我們可以隨時攔截控制流來暫停等待人工輸入，或等待長時間運行的任務完成
- 我們能將上下文窗口輕松序列化存儲，實現(xiàn)「斷點續(xù)傳」式的任務暫停與恢復
- 在 prompt 的設計中，我們可以優(yōu)化任務指令的傳遞方式和“當前任務進度”的說明方式
03 factor 01：自然語言轉工具調用（Tool Calls）
智能體（agent）構建最常見的模式之一就是將自然語言轉換為結構化的工具調用。這是一種功能強大的模式，可以構建能夠推理任務并執(zhí)行任務的智能體。
這種模式的核心原理，就是實現(xiàn)從自然語言到結構化指令的精準轉換：
請為 Terri 生成 750 美元的贊助支付鏈接，用于支付二月份 AI 創(chuàng)客大會的贊助費用。
最終輸出一個結構化對象，用于描述 Stripe API 的調用參數(shù)，例如：
注：實際場景中 Stripe API 的調用更為復雜。一個成熟的智能體需要先獲取客戶列表、產品目錄和價目表等數(shù)據(jù)，通過關聯(lián) ID 構建有效請求參數(shù) —— 當然，這些 ID 也可以直接預置在提示詞/上下文窗口中（本質上這兩種方式是相通的，下文將具體說明）。
后續(xù)可由確定性代碼接管該請求參數(shù)，并執(zhí)行相應的業(yè)務邏輯。（更多細節(jié)將在 factor 3 中說明）
請注意：完整版的智能體在接收到 API 的調用結果后，會通過循環(huán)處理機制最終返回類似這樣的信息：
已成功為 Terri 創(chuàng)建 750 美元的支付鏈接，用于贊助二月份 AI 創(chuàng)客見面會。鏈接如下：??https://buy.stripe.com/test_1234567890??
但本節(jié)將跳過該環(huán)節(jié)，將其保留至后續(xù)章節(jié)實現(xiàn) —— 開發(fā)者可根據(jù)實際需求決定是否集成該功能。
04 factor 02：自主掌控提示詞
不要直接套用框架自動生成的提示詞。
某些框架會提供這種‘黑箱式’方案：
這種方案能幫你快速套用頂尖的提示詞模板上手，但后期很難精準調整或實施逆向工程，難以確保模型接收的指令完全符合預期。
相反，你要像對待核心業(yè)務代碼一樣對待提示詞：
雖然上面這個示例是用 BAML 工具生成提示詞的，但其實你可以根據(jù)自己的需求選擇任何提示詞設計工具，甚至完全不需要借助工具，直接按照模板格式手動編寫提示詞也是可行的。
自主掌控提示詞的核心優(yōu)勢：
- 完全的控制權：可以精準定制 AI Agent 所需的指令，徹底擺脫“黑箱操作”的束縛
- 可測試和可評估：像測試普通代碼一樣，為你的提示詞建立完整的測試評估體系
- 快速迭代：根據(jù)實際使用效果，隨時靈活調整優(yōu)化提示詞
- 透明可控：清楚掌握 AI Agent 執(zhí)行的具體指令內容，沒有隱藏邏輯
- 角色突破：利用那些支持自定義用戶/助手角色設定的 API 接口 —— 比如 OpenAI 已棄用的舊版 'completions' 非對話型 API，甚至可以實現(xiàn)一些特殊的模型引導技巧
請記?。禾崾驹~（prompts）是連接你的業(yè)務邏輯與大語言模型的主要接口。
完全掌控提示詞，才能提供生產級 AI Agent 所需的靈活性和提示詞控制能力。
雖然沒人能斷言什么是最佳提示詞，但有一點很明確 —— 你需要的是能自由嘗試各種可能性。
05 factor 03：自主掌控上下文窗口
與大語言模型交互時，上下文傳遞不必拘泥于標準消息格式。
在智能體（agent）中，每次向 LLM 提供輸入的實質是：“這是目前情況，接下來該干嘛？”
一切皆上下文工程。大語言模型本質上是無狀態(tài)函數(shù)（stateless functions）[8]，只負責將輸入轉化為輸出。想要獲得優(yōu)質輸出，就必須提供優(yōu)質輸入。
構建優(yōu)質上下文需包含以下要素：
- 提示詞與指令：給模型的明確操作指引
- 外部數(shù)據(jù)源：檢索到的文檔或知識（例如使用 RAG 技術）
- 歷史狀態(tài)：過往的工具調用記錄、執(zhí)行結果等操作痕跡
- 記憶系統(tǒng)：有關聯(lián)但獨立的對話/事件歷史記錄（Memory）
- 輸出結構化指令：規(guī)定模型返回數(shù)據(jù)的格式規(guī)范
本指南聚焦如何最大限度挖掘現(xiàn)有模型的潛力，以下內容不在討論范圍內：
- 調整模型參數(shù)（如 temperature、top_p、frequency_penalty、presence_penalty 等）
- 訓練自定義的生成模型（completion models）或嵌入模型
- 對現(xiàn)有模型進行微調
在此重申：雖然無法斷言最佳的上下文傳遞方式，但我知道你希望能夠靈活地嘗試各種方式。
5.1 標準上下文格式與自定義上下文格式
大多數(shù) LLM 客戶端采用如下這種標準消息格式：
雖然這種格式適用于大多數(shù)場景，但若想極致壓榨現(xiàn)有 LLM 的性能，就必須以最高效的 token 利用率和注意力分配機制來傳遞上下文。
若希望突破基于消息的標準格式限制，您可以創(chuàng)建專為你個人的應用場景優(yōu)化的上下文組織形式。例如，通過自定義數(shù)據(jù)結構將相關內容整合，根據(jù)實際需求打包或拆分到一個或多個用戶、系統(tǒng)、助手或工具消息中（具體組合視業(yè)務邏輯而定）。
以下示例演示了如何將完整的上下文信息封裝于單條用戶消息中：
雖然模型可能通過你提供的工具定義自動推導后續(xù)操作步驟，但我們仍建議在提示詞模板中明確聲明任務目標 —— 主動說明需求始終是更穩(wěn)妥的做法。
5.2 code example
我們可以采用如下方式構建：
上下文窗口示例
下面是使用這種方法后上下文窗口的樣子：
初始的 Slack 請求：
列出 Git 標簽后：
錯誤發(fā)生與恢復后：
此時你的下一步可能是：
上文那些 XML 格式的內容僅是一個參考示例 —— 您可以根據(jù)實際業(yè)務需求，自定義最合適的數(shù)據(jù)結構。通過靈活嘗試不同的上下文組織形式、存儲內容和輸入大模型的內容，最終輸出質量會顯著提升。
自主控制上下文窗口的好處：
- 信息密度：以最適配 LLM 認知的方式組織信息
- 錯誤處理：采用有助于 LLM 自主恢復的格式記錄錯誤信息（已修復的錯誤和失敗調用可從上下文中移除）
- 安全性：主動過濾敏感數(shù)據(jù)，精準控制輸入內容
- 靈活性：根據(jù)使用情況持續(xù)優(yōu)化調整上下文格式
- token 效率：優(yōu)化上下文格式，提高 token 效率與模型理解能力
上下文可包含： 提示詞（prompts）、指令（instructions）、RAG 文檔（RAG documents）、交互歷史（history）、工具調用記錄（tool calls）、記憶（memory）
請記住，上下文窗口是你與 LLM 交互的主要界面，其結構設計與信息呈現(xiàn)方式將直接決定智能體的效能。
示例 - 信息密度優(yōu)化（相同的語義信息，更少的 token 消耗量）：
雖然無法預知最優(yōu)方案，但必須確保系統(tǒng)具備無限試錯的可能性——任何可能的嘗試路徑都應向你開放。
06 factor 04：「工具」本質上只是 LLM 生成的結構化輸出
「工具」無需進行復雜設計。其本質是大語言模型生成的結構化輸出，用于觸發(fā)確定性代碼的執(zhí)行。
以 CreateIssue 和 SearchIssues 這兩個工具為例，讓大模型（LLM）“調用工具”，本質上就是讓它輸出一個可解析的 JSON 對象，該對象對應我們要執(zhí)行的具體工具操作。
這種模式很簡單：
1）LLM 生成結構化的 JSON 輸出
2）使用確定性代碼執(zhí)行對應操作（如調用外部 API）
3）捕獲執(zhí)行結果并反饋到上下文中
這種設計實現(xiàn)了 LLM 決策邏輯與應用程序執(zhí)行邏輯的清晰分離 —— LLM 負責決定『做什么』，而你的代碼掌控『怎么做』。即便 LLM 調用了某個工具，具體執(zhí)行方式也不必每次都嚴格對應單一函數(shù)。
如果你還記得前文提及的 switch 語句
注：關于“plain prompting" vs. "tool calling" vs. "JSON mode”的性能權衡已有諸多討論。在此附上相關資源鏈接（參見《Prompting vs JSON Mode vs Function Calling vs Constrained Generation vs SAP》[9]、《When should I use function calling, structured outputs, or JSON mode?》[10]及《OpenAI JSON vs Function Calling》[11]），此處不展開論述。
所謂的"下一步操作"未必只是簡單地"運行一個純函數(shù)并返回結果"。當你把"工具調用"單純視為模型輸出的一段 JSON 指令（用于描述確定性代碼該執(zhí)行什么）時，就能解鎖極大的靈活性。結合 factor 08 ，這種設計將帶來更強大的可能性。
07 factor 05：執(zhí)行狀態(tài)與業(yè)務狀態(tài)的統(tǒng)一
即便在 AI 領域之外，許多基礎設施系統(tǒng)也試圖將“執(zhí)行狀態(tài)”與“業(yè)務狀態(tài)”分離。對 AI 應用而言，這種分離可能涉及復雜的抽象機制來追蹤當前步驟、下一步驟、等待狀態(tài)、重試次數(shù)等。這種分離帶來的復雜性可能是值得的，但對你的使用場景而言可能是過度設計。
你可以自行決定什么最適合你的應用。但不要認為必須將這兩者分開管理。
更清晰的定義：
- 執(zhí)行狀態(tài)（Execution state）：當前步驟、下一步驟、等待狀態(tài)、重試次數(shù)等
- 業(yè)務狀態(tài)（Business state）：智能體工作流中已發(fā)生的事件（如 OpenAI 消息列表、工具調用及結果列表等）
如果可能，盡量簡化 —— 盡可能將它們統(tǒng)一起來。
實際上，你可以通過工程化設計，直接從上下文窗口推斷所有執(zhí)行狀態(tài)。多數(shù)情況下，執(zhí)行狀態(tài)（當前步驟、等待狀態(tài)等）不過是已發(fā)生事件的元數(shù)據(jù)（metadata）。
當然，有些內容無法放入上下文窗口（如會話 ID、密碼上下文等），但你的目標應該是盡量減少這類例外。通過遵循 factor 3，你可以精準控制哪些信息真正輸入給 LLM。
該方法具有以下優(yōu)勢：
- 簡潔性：所有狀態(tài)只有一個真實來源
- 序列化：工作流可輕松實現(xiàn)序列化/反序列化
- 調試便捷：完整的歷史記錄一目了然
- 擴展靈活：僅需新增事件類型即可擴展新的狀態(tài)
- 斷點續(xù)傳：通過加載工作流可從任意節(jié)點恢復執(zhí)行
- 流程復刻（Forking）：可以在任何時間點復制工作流子集至新上下文/狀態(tài)ID，實現(xiàn)在工作流的復刻（fork）
- 人機交互和可觀測性：工作流可輕松轉換為 Markdown 文檔或可視化 Web 界面
08 factor 06：通過簡單的 API 實現(xiàn)啟動/暫停/恢復
智能體的本質是程序，其生命周期管理應符合我們對常規(guī)程序的預期 —— 能夠便捷地啟動、查詢、恢復和終止。
需確保終端用戶、應用程序、業(yè)務管道及其他智能體均可通過輕量級 API 接口快速部署新智能體實例。
智能體及其編排的確定性代碼須具備長時操作自暫停能力。
需支持通過 Webhook 等外部觸發(fā)器實現(xiàn)智能體斷點續(xù)執(zhí)，且無需深度對接智能體編排系統(tǒng)。
factor 6 與 factor 5 和 factor 8 存在較強的關聯(lián)，但可獨立實現(xiàn)。
需特別注意，多數(shù)現(xiàn)有的 AI 編排系統(tǒng)雖支持暫?；謴凸δ?，但在『工具選定』與『工具執(zhí)行』兩個狀態(tài)節(jié)點之間的臨界區(qū)間，多數(shù)系統(tǒng)無法保持狀態(tài)持久化能力（詳見 factor 7 和 factor 11 的技術解析）。
09 factor 07：通過工具調用實現(xiàn)人機協(xié)同
默認情況下，LLM API 在生成模型響應時，首先會面臨一個關鍵的、高風險的詞元選擇：是返回純文本內容，還是返回結構化數(shù)據(jù)？
系統(tǒng)將大量決策權重放在首個詞元的選擇上。例如在查詢“東京天氣”時，首個詞元可能是：
"東京"
而在 fetch_weather（獲取天氣）功能中，則可能是表示 JSON 對象開頭的特殊詞元。
|JSON>
更優(yōu)方案是讓大語言模型始終輸出 JSON 結構化數(shù)據(jù)，然后通過自然語言詞元（如 request_human_input 或 done_for_now）來聲明意圖，而不是使用像 check_weather_in_city 這樣的"標準"工具。
需特別注意：此方案可能不會直接提升系統(tǒng)性能指標，但必須通過持續(xù)實驗驗證 —— 工程師應保留嘗試非常規(guī)手段的自由度，這是獲得最優(yōu)解的必經之路。
后續(xù)，您可能會收到來自處理 Slack、電子郵件、短信或其他事件的系統(tǒng)的 webhook 通知。
上文整合了 factor 3、4、5、8 的方案特征。
若采用 factor 3 中的類 XML 格式，那么經過數(shù)次交互后，上下文窗口可能會是這樣的：
優(yōu)勢亮點：
- 清晰的指令：針對不同人機交互場景的工具設計，可大幅提升大語言模型（LLM）輸出的精準度。
- 內循環(huán)與外循環(huán)機制：該機制使智能體工作流突破傳統(tǒng) ChatGPT 式交互框架，支持逆向流程觸發(fā) —— 控制流與上下文初始化可由智能體主動發(fā)起至用戶（例如：通過定時任務或事件自動激活的智能體服務）。
- 多用戶協(xié)同：依托結構化事件機制，可高效追蹤并協(xié)調多用戶輸入數(shù)據(jù)流。
- 多智能體協(xié)作：通過輕量級抽象層設計，快速擴展智能體間的請求與響應能力
- 持久化運行：結合 factor 6 的啟?？刂颇芰?，可構建高穩(wěn)定、可觀測的多角色持久化工作流。
有關外循環(huán)智能體（Outer Loop Agents）的更多信息，請點擊此處[12]。
與 factor 11 完美結合 —— 隨時隨地觸發(fā)，滿足用戶需求。
10 factor 08：掌控你的控制流
如果你能掌握你的控制流，就可以實現(xiàn)更靈活、強大的功能。
根據(jù)具體應用場景構建專屬控制邏輯，精準匹配業(yè)務場景。當特定類型的工具調用需要中斷循環(huán)等待人工響應或長時任務（如訓練流水線）時，您可設計靈活的中斷機制。建議集成以下自定義功能：
- 工具調用結果的摘要與緩存
- 使用 LLM 對結構化輸出進行校驗、評估
- 上下文窗口壓縮或其他內存管理方案
- 全鏈路日志追蹤與性能監(jiān)控
- 客戶端速率限制策略
- 持久化的休眠/暫停/事件等待機制
下方示例展示了三種典型的控制流模式：
- request_clarification：模型請求補充信息時，中斷當前循環(huán)流程，等待人工響應
- fetch_git_tags：當模型請求 Git 標簽列表時，系統(tǒng)會實時獲取標簽數(shù)據(jù)并更新上下文，直接將結果反饋給模型
- deploy_backend：模型發(fā)起后端部署請求時，因涉及高風險操作，中斷流程等待人工審核確認
這種模式允許你根據(jù)需要中斷和恢復智能體的工作流程，從而創(chuàng)建更自然的對話和工作流。
舉個例子，我對所有 AI 框架的首要功能需求就是：正在工作的智能體能夠中斷操作并在之后恢復運行，特別是在工具選擇和工具調用之間的時刻。
如果缺乏這種可恢復性/精細控制能力，就無法在工具調用執(zhí)行前進行審核（review/approve），這意味著您被迫只能選擇以下方案：
1）在等待長時間任務完成時，將任務及其上下文狀態(tài)（變量、堆棧等）保留在內存中（類似while...sleep），如果進程中斷則必須從頭開始
2）限制智能體只能執(zhí)行低風險、低影響的調用，如研究和摘要
3）允許智能體執(zhí)行更重要、更有用的操作，然后只能祈禱它不會搞砸
您可能會注意到，這一點與 factor 5 及 factor 6 密切相關，但也可以獨立實現(xiàn)。
11 factor 09：將錯誤信息壓縮至上下文窗口
這一點雖然簡短，但值得一提。智能體的優(yōu)勢之一在于“自我修復”——對于短任務，大語言模型（LLM）可能會調用某個失敗的工具。優(yōu)秀的 LLM 通常能夠讀取錯誤信息或 Stack Trace 信息，并在后續(xù)工具調用中調整策略。
大多數(shù)框架已實現(xiàn)這一功能，但你也可以只做到這一點，而無需實現(xiàn)其他 11 個 factor。例如：
你可能需要為特定的工具調用實現(xiàn)一個錯誤計數(shù)器（errorCounter），將單個工具的重試次數(shù)限制在 ~ 3次以內，或者根據(jù)實際需求調整業(yè)務邏輯。
當連續(xù)錯誤次數(shù)達到某個閾值時，無論是模型自主決策還是通過預編程規(guī)則強制接管控制流，都可以選擇升級至人工處理。
優(yōu)勢：
- 自我修復能力：大語言模型能夠解讀錯誤信息，并在后續(xù)工具調用中自動調整執(zhí)行策略
- 持久運行機制：單一工具調用失敗不會導致系統(tǒng)中斷，智能體程序可持續(xù)執(zhí)行任務
需要提醒的是，智能體過度依賴這種自我修復機制時，可能導致智能體在錯誤處理過程中無法有效突破現(xiàn)有邏輯框架，出現(xiàn)反復報錯的情況。
此時，factor 8 和 factor 3 就派上用場了 —— 你不必直接把原始錯誤丟回給系統(tǒng)，而是重構錯誤表達方式、從上下文窗口移除冗余的歷史記錄，避免干擾后續(xù)決策，或者采用其他有效的確定性策略（只要能確保智能體程序回歸正軌）。
防范陷入錯誤循環(huán)的最核心策略，是遵循 factor 10。
12 factor 10：小型化、功能聚焦的智能體
與其構建試圖包辦一切的大型智能體，不如開發(fā)專注于某一單一功能的小型智能體。智能體只是一個更大的、主要由確定性因素決定的系統(tǒng)中的基礎組件之一。
這里的關鍵之處在于大語言模型（LLM）的局限性：任務越龐大復雜，所需任務步驟就越多，就意味著需要更長的上下文窗口。隨著上下文增長，大語言模型更容易迷失方向或偏離重點。通過將智能體的功能限定在特定領域（3-10 個步驟，最多 20 個任務步驟），我們可以保持上下文窗口的可管理性，確保大語言模型的高效運行。
小型化、功能聚焦的智能體的優(yōu)勢：
1）可管理的上下文：更小的上下文窗口意味著更優(yōu)的大語言模型表現(xiàn)
2）職責明確：每個智能體都有清晰的功能邊界和設計目標
3）可靠性更高：在復雜的工作流程中迷失方向的可能性更低
4）更易于測試：更簡單地測試和驗證特定功能
5）調試優(yōu)化：問題發(fā)生時更容易定位和修復
12.1 如果 LLM 變得更聰明了呢？
如果大語言模型的智能程度足夠高，能處理 100+ 步驟的工作流，我們還需要這種設計嗎？
tl;dr：需要。雖然智能體和大模型進步后可能自然而然地擁有處理更長上下文的能力，這意味著能處理更多更大的 DAG。但采用小型化、功能聚焦的架構設計，既能確保你在第一時間獲得可靠的結果，又為未來大模型的上下文窗口擴容時逐步擴展智能體范圍做好準備。（如果你重構過大型的確定性代碼庫，此刻應該會心一笑）
有意識地確定智能體的規(guī)模/范圍，并且只在能夠保證質量的情況下擴展，這是關鍵所在。正如 NotebookLM 開發(fā)團隊所言[13]：
"在 AI 開發(fā)中，那些最驚艷的突破時刻往往發(fā)生在我將將觸及模型能力邊界的時候"
無論這個能力邊界在哪里，如果你能找到邊界并始終如一地把握住它，你就能打造出驚艷的用戶體驗。這個領域有很多技術護城河可以構建，但一如既往，這需要嚴謹?shù)墓こ虒嵺`。
13 factor 11：智能體系統(tǒng)支持多入口觸發(fā)，且響應與觸發(fā)渠道保持一致
當您已落實 factor 6 和 factor 7 后，便可無縫集成本原則方案。
支持用戶通過 Slack、郵件、短信等任意渠道喚醒智能體，并確保響應始終在原對話流中完成。
優(yōu)勢：
- 滿足用戶需求：打造擬人化的 AI 應用體驗，讓用戶感受如真人協(xié)作或至少達到數(shù)字同事般的自然交互
- 外循環(huán)智能體：支持非人工觸發(fā)（系統(tǒng)事件/定時任務/故障告警等），可自主運行5-90分鐘，關鍵決策節(jié)點自動請求人工介入（需審批/獲取反饋/請求協(xié)助）
- 高風險操作授權機制：通過快速人工復核機制，可授權智能體執(zhí)行高風險操作（如外發(fā)郵件、生產數(shù)據(jù)更新等）。明確、標準化的管控體系既保障操作可追溯，又能提升智能體執(zhí)行復雜任務的可靠性。
14 factor 12：將智能體設計為符合“無狀態(tài)歸約器”模式
END
本期互動內容 ??
?文中多次強調“沒人知道什么是最佳實踐，但必須保留試錯自由”。你最近在 AI Agent 項目中做過哪些不符常規(guī)但有效的技術決策？
文中鏈接
[1]??https://airflow.apache.org/??
[2]??https://www.prefect.io/??
[4]??https://www.inngest.com/??
[5]??https://www.windmill.dev/??
[6]??https://youtu.be/Dc99-zTMyMg?si=bcT0hIwWij2mR-40&t=73??
[7]??https://x.com/chainlit_io/status/1858613325921480922??
[8]??https://thedataexchange.media/baml-revolution-in-ai-engineering/??
[9]??https://www.boundaryml.com/blog/schema-aligned-parsing??
[10]??
[11]??https://docs.llamaindex.ai/en/stable/examples/llm/openai_json_vs_function_calling/??
[12]??https://theouterloop.substack.com/p/openais-realtime-api-is-a-step-towards??
原文鏈接：
