1. 從Agent-Reach這個名字說起它到底想解決什么問題第一次看到Agent-Reach這個項目名我的直覺是這大概率是一個讓 AI Agent 具備觸達(dá)能力的工具。Reach 這個詞在工程語境里通常有兩層含義——一是伸手夠到也就是讓 Agent 能夠訪問它原本訪問不到的資源二是覆蓋范圍也就是讓 Agent 的能力邊界往外擴(kuò)一圈。結(jié)合熱搜詞里高頻出現(xiàn)的AI Agent、CLI、Python、GitHub這幾個關(guān)鍵詞基本可以判斷這是一個圍繞命令行交互、用 Python 構(gòu)建、托管在 GitHub 上的 Agent 能力擴(kuò)展項目。那它到底解決什么問題我們先把場景擺出來?，F(xiàn)在大多數(shù)人用 AI Agent要么是在網(wǎng)頁對話框里聊天要么是在 IDE 插件里讓它補(bǔ)代碼。這兩種形態(tài)有個共同的毛病Agent 被關(guān)在一個玻璃房里它能思考、能生成文本但它夠不到你本地的文件系統(tǒng)、夠不到你的命令行工具鏈、夠不到你正在跑的服務(wù)。你想讓它幫你查一下某個目錄下最近修改的文件、想讓它跑一條構(gòu)建命令看看報錯、想讓它讀一下本地日志再給分析——對不起它做不到或者需要你手動復(fù)制粘貼。Agent-Reach 這類項目的核心價值就是把這個玻璃房拆掉。它通過 CLI 作為橋梁讓 Agent 能夠真正伸手到你的開發(fā)環(huán)境里。CLI 在這里不是隨便選的而是一個經(jīng)過權(quán)衡的決策GUI 太重、API 太散、而 CLI 是開發(fā)者和機(jī)器之間最通用、最可腳本化、最容易做權(quán)限控制的接口。你想想一個 Agent 要執(zhí)行操作最穩(wěn)妥的方式是什么不是讓它直接調(diào)用某個私有 SDK而是讓它生成一條命令、由外層程序去執(zhí)行、再把結(jié)果喂回來。這個模式的好處是命令是可見的、可審計的、可攔截的。適合誰來參考這個內(nèi)容三類人。第一類是正在做 AI Agent 應(yīng)用開發(fā)、卡在怎么讓 Agent 真正干活這一步的工程師第二類是想給自己的 CLI 工具加上 AI 能力的工具作者第三類是對 Agent 架構(gòu)感興趣、想找一個具體項目來拆解學(xué)習(xí)的技術(shù)愛好者。如果你屬于這三類中的任何一類接下來的內(nèi)容應(yīng)該能給你一些可以直接抄的思路。需要說明的是由于項目正文和關(guān)鍵詞字段為空本文的技術(shù)細(xì)節(jié)部分是基于一個典型的 CLI Python AI Agent 能力擴(kuò)展項目的常見工程實踐進(jìn)行合理補(bǔ)全的我會在涉及推測的地方明確標(biāo)注避免誤導(dǎo)。2. 為什么是 CLI 而不是 GUI 或純 API架構(gòu)選型的底層邏輯2.1 CLI 作為 Agent 與系統(tǒng)之間的最小可信接口很多人做 Agent 項目第一反應(yīng)是做一個漂亮的 Web 界面或者直接對接某個平臺的 API。但真做過一輪就會發(fā)現(xiàn)GUI 的維護(hù)成本極高而且它天然把 Agent 和真實環(huán)境隔開了。你在網(wǎng)頁上點一個按鈕背后還是要發(fā)一個請求到某個服務(wù)那個服務(wù)再去操作環(huán)境——多了一層就多了一層不確定。CLI 的優(yōu)勢在于它是薄的。一條命令就是一個明確的意圖輸入?yún)?shù)、輸出結(jié)果、退出碼三樣?xùn)|西構(gòu)成了一個完整的契約。Agent 生成命令、執(zhí)行、讀取 stdout 和 stderr、根據(jù)退出碼判斷成敗這個循環(huán)極其干凈。更重要的是CLI 天然支持管道和重定向這意味著 Agent 可以把一個命令的輸出直接喂給下一個命令形成鏈?zhǔn)讲僮?。這種組合能力是 GUI 很難提供的。從權(quán)限角度看CLI 也更好控制。你可以用一個白名單機(jī)制只允許 Agent 執(zhí)行預(yù)先批準(zhǔn)的命令集合你可以給 Agent 分配一個受限的用戶賬號讓它只能訪問特定目錄你可以在執(zhí)行前把命令打印出來讓人確認(rèn)。這些在 GUI 場景下要么做不了要么做起來很別扭。2.2 Python 在這個架構(gòu)里扮演的角色熱搜詞里Python、python安裝、python教程出現(xiàn)頻率很高說明這個項目的目標(biāo)用戶里有相當(dāng)一部分是 Python 使用者。Python 在 Agent 項目里通常承擔(dān)三個職責(zé)一是作為 CLI 的實現(xiàn)語言用argparse或click這類庫快速搭出命令結(jié)構(gòu)二是作為 Agent 邏輯的編排層負(fù)責(zé)調(diào)用大模型、解析返回、決定下一步動作三是作為工具函數(shù)的宿主把各種能力封裝成 Python 函數(shù)供 Agent 調(diào)用。Python 的優(yōu)勢是生態(tài)全、上手快、膠水能力強(qiáng)。你想調(diào)一個 HTTP 接口、想讀一個文件、想跑一個子進(jìn)程標(biāo)準(zhǔn)庫基本都覆蓋了。對于 Agent 這種需要頻繁和各種外部系統(tǒng)打交道的場景Python 的開發(fā)效率是實打?qū)嵉母?。?dāng)然它也有短板比如并發(fā)處理不如 Go 或 Rust 那么省心但對于大多數(shù) Agent 應(yīng)用來說瓶頸往往在模型推理而不是語言本身所以這個短板通常不致命。2.3 和 Rust、Go 方案的對比熱搜里出現(xiàn)了基于rust語言ai agent說明有人在做 Rust 版本的 Agent。Rust 的優(yōu)勢是性能和內(nèi)存安全適合做高并發(fā)、低延遲的 Agent 運行時。如果你的 Agent 需要同時處理成百上千個任務(wù)或者需要長時間穩(wěn)定運行不能有內(nèi)存泄漏Rust 是更好的選擇。但代價是開發(fā)周期長、生態(tài)相對沒那么成熟、招人難。Go 介于兩者之間并發(fā)模型優(yōu)雅部署簡單單二進(jìn)制適合做 Agent 的服務(wù)端。但 Go 在數(shù)據(jù)處理和快速原型方面不如 Python 靈活。我的建議是原型階段用 Python驗證想法如果確認(rèn)要上生產(chǎn)且并發(fā)壓力大再考慮把核心運行時用 Rust 或 Go 重寫。不要一上來就追求性能先把邏輯跑通更重要。維度PythonGoRust開發(fā)速度快中慢并發(fā)能力中強(qiáng)強(qiáng)生態(tài)豐富度高中中部署便利性中高高適合階段原型/中小規(guī)模服務(wù)端高性能運行時3. 一個 Agent-Reach 類項目的核心模塊拆解3.1 命令解析層Agent 意圖如何變成可執(zhí)行動作這一層是整個系統(tǒng)的入口。Agent 輸出的通常是一段自然語言或者結(jié)構(gòu)化文本比如幫我看看當(dāng)前目錄下有哪些 Python 文件。命令解析層的任務(wù)是把這段意圖翻譯成一條具體的 shell 命令比如find . -name *.py。翻譯的方式有兩種。一種是讓模型直接輸出命令然后做安全校驗另一種是讓模型輸出一個結(jié)構(gòu)化的動作描述比如 JSON再由程序映射到預(yù)定義命令。前者靈活但風(fēng)險高后者安全但能力受限。實際項目中常見的是混合模式高頻、安全的操作走預(yù)定義映射低頻、復(fù)雜的操作走模型直出加人工確認(rèn)。這里有個關(guān)鍵細(xì)節(jié)命令的構(gòu)造一定要做參數(shù)轉(zhuǎn)義。如果 Agent 生成的命令里包含了用戶輸入的內(nèi)容而你沒有做轉(zhuǎn)義就可能出現(xiàn)命令注入。比如用戶輸入了一個帶分號的文件名直接拼進(jìn)命令里就會變成兩條命令。這個坑我在早期項目里踩過后來統(tǒng)一用shlex.quote()處理才解決。3.2 執(zhí)行沙箱讓 Agent 干活但不讓它闖禍Agent 能執(zhí)行命令就意味著它能刪文件、能改配置、能發(fā)網(wǎng)絡(luò)請求。這是能力也是風(fēng)險。執(zhí)行沙箱要解決的就是給它自由但給它劃邊界。常見的邊界控制手段有幾種。第一是目錄限制用chroot或者容器把 Agent 的工作目錄限定在某個范圍內(nèi)它看不到也碰不到外面的東西。第二是命令白名單只允許執(zhí)行預(yù)先批準(zhǔn)的命令其他一律拒絕。第三是資源限制用ulimit或者 cgroup 限制 CPU、內(nèi)存、執(zhí)行時間防止一條命令把機(jī)器跑掛。第四是網(wǎng)絡(luò)隔離如果 Agent 不需要聯(lián)網(wǎng)直接斷掉它的網(wǎng)絡(luò)訪問。這幾種手段可以疊加使用。我的經(jīng)驗是至少要做到目錄限制加超時控制。超時控制特別重要因為 Agent 有時候會生成一條會卡住的命令比如等待輸入的交互式命令沒有超時的話整個流程就掛在那里了。3.3 結(jié)果回傳與上下文管理Agent 怎么看懂執(zhí)行結(jié)果命令執(zhí)行完了輸出一堆文本Agent 怎么理解這里有兩個問題要處理一是輸出可能很長直接塞給模型會超出上下文窗口二是輸出可能包含噪聲比如進(jìn)度條、警告信息會干擾模型判斷。處理長輸出的常見做法是截斷加摘要。截斷就是只取前 N 行和后 N 行中間省略摘要就是用另一個模型調(diào)用把輸出壓縮成幾句話。兩種方式各有適用場景前者快但可能丟信息后者慢但更準(zhǔn)。實際項目中我傾向于先截斷如果模型表示信息不足再觸發(fā)摘要。上下文管理是另一個容易被低估的模塊。Agent 執(zhí)行多步任務(wù)時每一步的輸出都會累積到上下文里很快就會撐爆窗口。解決辦法是維護(hù)一個工作記憶只保留最近幾步的詳細(xì)輸出更早的壓縮成一句話摘要。這個策略和人類做筆記的邏輯很像當(dāng)前正在處理的細(xì)節(jié)記詳細(xì)已經(jīng)完成的步驟記結(jié)論。3.4 工具注冊機(jī)制怎么讓 Agent 知道自己能干什么Agent 要調(diào)用工具首先得知道有哪些工具可用。工具注冊機(jī)制就是維護(hù)這份清單的地方。每個工具需要描述清楚名字是什么、干什么用的、需要什么參數(shù)、參數(shù)是什么類型、有沒有副作用。這份描述的質(zhì)量直接決定了 Agent 能不能正確使用工具。描述寫得太簡略模型會猜錯用途寫得太啰嗦又會占用寶貴的上下文。我的經(jīng)驗是工具描述要包含一個簡短的用途說明加一個使用示例參數(shù)說明要明確類型和是否必填。如果工具有副作用比如會修改文件一定要在描述里標(biāo)注出來讓模型知道這個操作不可逆。4. 從零跑通一個最小可用版本實操步驟與關(guān)鍵配置4.1 環(huán)境準(zhǔn)備Python 版本、依賴管理與常見安裝坑先把環(huán)境搭起來。Python 版本建議 3.10 以上因為很多現(xiàn)代 Agent 框架用到了 3.10 引入的match語法和更好的類型提示支持。安裝 Python 本身如果遇到問題Windows 用戶注意勾選Add to PATHMac 用戶建議用pyenv管理多版本Linux 用戶直接用系統(tǒng)包管理器或者源碼編譯都行。依賴管理我強(qiáng)烈建議用虛擬環(huán)境不要往全局環(huán)境里裝。venv是標(biāo)準(zhǔn)庫自帶的夠用如果你需要更快的依賴解析可以上uv或poetry。核心依賴通常包括一個 CLI 框架click或typer、一個模型調(diào)用庫openai或anthropic的 SDK、一個 HTTP 庫httpx或requests。如果要做異步再加asyncio相關(guān)的庫。這里有個常見的坑國內(nèi)網(wǎng)絡(luò)環(huán)境下裝包可能會很慢甚至失敗。解決辦法是配置鏡像源比如在pip.conf里指定一個國內(nèi)鏡像。這個配置是一次性的配好之后所有 pip 安裝都會走鏡像速度提升明顯。# 創(chuàng)建虛擬環(huán)境 python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate # 配置鏡像源示例 pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple # 安裝核心依賴 pip install click httpx openai4.2 最小命令循環(huán)讀入、執(zhí)行、回傳三步走最小可用版本不需要復(fù)雜的架構(gòu)把三步走通就行。第一步從標(biāo)準(zhǔn)輸入或者參數(shù)里拿到用戶意圖第二步調(diào)用模型生成命令第三步執(zhí)行命令并把結(jié)果打印出來。import subprocess import shlex def execute_command(cmd: str, timeout: int 30) - dict: 執(zhí)行命令并返回結(jié)構(gòu)化結(jié)果 try: result subprocess.run( cmd, shellTrue, capture_outputTrue, textTrue, timeouttimeout ) return { success: result.returncode 0, stdout: result.stdout, stderr: result.stderr, returncode: result.returncode } except subprocess.TimeoutExpired: return { success: False, stdout: , stderr: f命令執(zhí)行超時{timeout}秒, returncode: -1 }這段代碼有幾個細(xì)節(jié)值得說。capture_outputTrue把 stdout 和 stderr 分開捕獲方便后續(xù)區(qū)分正常輸出和錯誤信息。timeout參數(shù)防止命令卡死。返回結(jié)構(gòu)里帶上returncode因為有些命令即使成功也會返回非零碼需要根據(jù)具體情況判斷。注意shellTrue會帶來命令注入風(fēng)險生產(chǎn)環(huán)境務(wù)必配合白名單或參數(shù)校驗使用。如果命令是模型生成的建議先做一次安全審查。4.3 把模型接進(jìn)來提示詞設(shè)計與輸出格式約束模型這一環(huán)關(guān)鍵是提示詞要寫清楚你只能輸出命令不要輸出解釋。否則模型會給你一段你可以運行以下命令ls -la這條命令的作用是……你還得再寫代碼去提取命令很麻煩。更好的做法是要求模型輸出 JSON包含命令和簡短說明兩個字段。這樣解析起來穩(wěn)定也方便后續(xù)做審計。SYSTEM_PROMPT 你是一個命令行助手。用戶會用自然語言描述需求 你需要輸出一個 JSON 對象格式如下 {command: 要執(zhí)行的命令, explanation: 一句話說明這條命令做什么} 規(guī)則 1. 只輸出 JSON不要輸出其他內(nèi)容 2. 命令必須是單條不要用分號連接多條命令 3. 如果無法完成command 字段填空字符串explanation 說明原因 這個提示詞的關(guān)鍵約束是單條命令和只輸出 JSON。單條命令的限制是為了降低風(fēng)險多條命令串聯(lián)容易出問題。只輸出 JSON 是為了解析穩(wěn)定。實測下來加上這兩條約束后輸出格式的合規(guī)率能到 95% 以上。4.4 第一次跑通的驗證清單跑通之后用幾個測試用例驗證一下。我通常會測這幾類簡單查詢列出當(dāng)前目錄的文件、帶參數(shù)的操作查看 app.py 的前 20 行、需要判斷的操作找出所有大于 1MB 的文件、以及一個應(yīng)該被拒絕的操作刪除所有文件。最后一類特別重要它驗證的是你的安全邊界有沒有生效。如果 Agent 真的生成了rm -rf *并且被執(zhí)行了那說明你的防護(hù)完全沒起作用。這個測試一定要在隔離環(huán)境里做別拿自己的主力機(jī)器試。5. 并發(fā)、穩(wěn)定性與那些文檔里不會寫的坑5.1 Agent 扛并發(fā)到底難在哪熱搜里有個詞是ai agent 怎么扛并發(fā)這個問題問到了點子上。Agent 的并發(fā)難點和普通 Web 服務(wù)不一樣。普通 Web 服務(wù)的請求是獨立的處理完就結(jié)束Agent 的任務(wù)往往是有狀態(tài)的、多步的每一步都依賴上一步的結(jié)果。這就導(dǎo)致并發(fā)控制復(fù)雜很多。第一個瓶頸是模型調(diào)用。大多數(shù)模型 API 都有速率限制你并發(fā)開太高會被限流。解決辦法是加一個令牌桶或者信號量控制同時進(jìn)行的模型調(diào)用數(shù)量。第二個瓶頸是命令執(zhí)行。如果多個 Agent 同時跑重命令機(jī)器資源會被搶光。解決辦法是給命令執(zhí)行加一個隊列限制并發(fā)數(shù)。第三個瓶頸是上下文管理。并發(fā)任務(wù)各自的上下文要隔離不能串味這要求你的上下文存儲必須是任務(wù)級別的不能是全局的。我的經(jīng)驗是Agent 的并發(fā)數(shù)不要設(shè)太高通常 5 到 10 個并發(fā)就能跑滿單機(jī)的處理能力了。與其追求高并發(fā)不如先把單個任務(wù)的穩(wěn)定性做好。5.2 命令執(zhí)行超時與僵尸進(jìn)程處理超時處理看起來簡單實際有很多坑。subprocess.run的timeout參數(shù)在超時后會殺掉子進(jìn)程但如果子進(jìn)程又 fork 了孫進(jìn)程孫進(jìn)程可能不會被殺掉變成僵尸進(jìn)程。時間長了系統(tǒng)里會積累一堆僵尸最終導(dǎo)致資源耗盡。解決辦法是用進(jìn)程組。在 Unix 系統(tǒng)上可以用os.setsid()讓子進(jìn)程成為新進(jìn)程組的組長超時時對整個進(jìn)程組發(fā)信號。import os import signal import subprocess def run_with_process_group(cmd: str, timeout: int 30): process subprocess.Popen( cmd, shellTrue, stdoutsubprocess.PIPE, stderrsubprocess.PIPE, textTrue, preexec_fnos.setsid # 創(chuàng)建新進(jìn)程組 ) try: stdout, stderr process.communicate(timeouttimeout) return {success: process.returncode 0, stdout: stdout, stderr: stderr} except subprocess.TimeoutExpired: os.killpg(os.getpgid(process.pid), signal.SIGKILL) return {success: False, stdout: , stderr: 超時已強(qiáng)制終止進(jìn)程組}os.killpg會殺掉整個進(jìn)程組包括孫進(jìn)程。這個細(xì)節(jié)在文檔里通常不會強(qiáng)調(diào)但生產(chǎn)環(huán)境里非常關(guān)鍵。5.3 輸出編碼問題中文亂碼的根源與修復(fù)中文環(huán)境下跑命令經(jīng)常會遇到亂碼。根源是編碼不一致命令輸出可能是 GBK而 Python 默認(rèn)按 UTF-8 解碼。解決辦法是在subprocess調(diào)用時顯式指定編碼或者用errorsreplace容錯。result subprocess.run( cmd, shellTrue, capture_outputTrue, textTrue, encodingutf-8, errorsreplace )如果命令本身輸出的是 GBK那就把encoding改成gbk。更穩(wěn)妥的做法是先按字節(jié)捕獲然后嘗試多種編碼解碼哪個成功用哪個。這個處理邏輯稍微麻煩一點但能覆蓋絕大多數(shù)場景。5.4 模型幻覺命令的識別與攔截模型有時候會生成看起來合理但實際不存在的命令或者參數(shù)拼錯。這類幻覺命令執(zhí)行后會報錯浪費一輪交互。識別的方法有幾個一是維護(hù)一個常用命令的白名單不在白名單里的先警告二是執(zhí)行前用which或command -v檢查命令是否存在三是觀察錯誤輸出如果連續(xù)幾次都是command not found就提示模型換一種方式。攔截策略上我傾向于先警告后執(zhí)行。第一次遇到可疑命令時打印出來讓用戶確認(rèn)如果用戶確認(rèn)過幾次同類命令就加入白名單后續(xù)自動放行。這樣既安全又不至于每次都打斷。6. 把 Agent-Reach 用起來典型場景與擴(kuò)展思路6.1 本地開發(fā)輔助日志分析、構(gòu)建排錯、文件檢索最直接的應(yīng)用場景是本地開發(fā)輔助。比如你跑測試掛了把報錯日志丟給 Agent讓它分析可能的原因然后自己跑幾條命令去驗證?；蛘邩?gòu)建失敗時讓 Agent 讀一下構(gòu)建輸出定位到具體的文件和行號。文件檢索也很實用。你記得寫過某個函數(shù)但忘了在哪個文件用自然語言描述一下Agent 幫你grep出來。這類操作本身不難但省去了你回憶命令語法的時間累積起來效率提升可觀。6.2 和現(xiàn)有 CLI 工具鏈的集成方式Agent-Reach 不應(yīng)該是一個孤立的工具它應(yīng)該能和你現(xiàn)有的工具鏈配合。集成方式有幾種一是作為獨立命令你在終端里直接調(diào)用二是作為 shell 的補(bǔ)全插件你輸入自然語言它幫你轉(zhuǎn)成命令三是作為 CI/CD 流水線的一環(huán)自動分析構(gòu)建日志。第二種方式我覺得最有意思。想象一下你在終端里輸入# 找出所有未使用的導(dǎo)入回車后 Agent 幫你生成并執(zhí)行相應(yīng)的命令。這種交互方式比記命令語法自然多了。實現(xiàn)上可以用 shell 的command_not_found_handle鉤子或者做一個包裝腳本。6.3 從單機(jī)到服務(wù)化什么時候該考慮拆分單機(jī)版跑順了之后你可能會想把它服務(wù)化讓團(tuán)隊里其他人也能用。這時候要考慮幾個問題一是多用戶隔離每個人的工作目錄和上下文要分開二是權(quán)限管理不同的人能執(zhí)行的命令范圍可能不同三是審計日志誰在什么時候執(zhí)行了什么命令要記錄清楚。服務(wù)化的架構(gòu)通常是一個 API 網(wǎng)關(guān)接收請求一個任務(wù)隊列做調(diào)度多個 worker 執(zhí)行命令一個存儲層保存上下文和日志。這個架構(gòu)不復(fù)雜但要注意 worker 的隔離不能讓一個用戶的命令影響到另一個用戶。什么時候該拆分我的判斷標(biāo)準(zhǔn)是當(dāng)有超過 3 個人要用或者單機(jī)資源開始吃緊或者需要審計合規(guī)時就該考慮服務(wù)化了。否則單機(jī)版夠用別過度設(shè)計。6.4 后續(xù)可以往哪些方向擴(kuò)展幾個我覺得有價值的方向。第一是增加工具類型除了 shell 命令還可以接入數(shù)據(jù)庫查詢、HTTP 請求、文件編輯等能力。第二是增加記憶能力讓 Agent 記住之前的操作習(xí)慣下次遇到類似任務(wù)直接復(fù)用。第三是增加協(xié)作能力多個 Agent 分工合作完成復(fù)雜任務(wù)。第四是增加可視化把 Agent 的執(zhí)行過程用圖形展示出來方便調(diào)試和演示。這些擴(kuò)展不需要一次做完挑一個對你最有價值的先做。我的建議是先做記憶能力因為它對體驗的提升最直接實現(xiàn)起來也不算復(fù)雜。7. 我在實際折騰這類項目時的一些體會做 Agent 工具這幾年最大的體會是能力越強(qiáng)邊界越重要。一個只能聊天的 Agent 很安全因為它什么都做不了一個能執(zhí)行命令的 Agent 很危險因為它什么都可能做。所以每增加一項能力都要同步想清楚對應(yīng)的約束是什么。另一個體會是不要追求一步到位。我見過太多項目一開始就想做全功能平臺結(jié)果做了半年還在搭架子。正確的做法是先做一個能跑的最小閉環(huán)哪怕只能執(zhí)行一條ls先讓它跑起來然后再逐步加能力。每加一個能力就驗證一次這樣出問題的時候容易定位。最后一個體會是關(guān)于提示詞的。很多人把提示詞當(dāng)成一次性的東西寫完就不管了。實際上提示詞是需要持續(xù)迭代的你要收集模型輸出不合規(guī)的案例分析原因然后針對性地調(diào)整提示詞。這個過程和調(diào)參很像需要耐心和記錄。我通常會維護(hù)一個失敗案例庫每次遇到問題就記一筆定期回顧看看有沒有共性。如果你也在做類似的項目歡迎交流。這個領(lǐng)域變化很快今天的最佳實踐明天可能就過時了保持學(xué)習(xí)和迭代的心態(tài)比什么都重要。