最近在做 AI Agent 工具鏈選型時我發(fā)現(xiàn)一個很明顯的變化大家不再滿足于“單個 Agent 對話生成代碼”而是開始追求“多個 Agent 協(xié)作完成一條完整任務流”。Herder 這個名字就是在這樣的背景下頻繁出現(xiàn)的。Herdr 是一個輕量級的多 Agent 協(xié)作 CLI 工具它把“多個智能體”和“終端命令”結合到一起。你可以把它理解成一個面向 AI Agent 的編排入口不需要打開復雜的 Web 控制臺也不需要寫大量后端服務直接在終端里定義角色、分配任務、收集結果。這篇文章我會從概念、原理、安裝配置、真實項目示例、以及 Codex CLI 集成時的路徑問題幾個維度展開思路偏向工程落地不是單純介紹概念。如果你正在學習 AI Agent 開發(fā)或者希望把手頭零散的 Agent 腳本整理成正式工作流那么這篇文章比較適合你。下面我會盡量把每一步操作和為什么這么做講清楚。1. 為什么需要多 Agent 協(xié)作 CLI1.1 從單 Agent 到多 Agent業(yè)務復雜度在倒逼現(xiàn)在很多團隊已經(jīng)熟練使用 Claude、ChatGPT、Codex CLI 這類編程助手。它們既能回答問題也能基于倉庫上下文生成代碼補丁。但真實業(yè)務往往不是“一個 Prompt 能解決的”代碼評審需要先讀取倉庫結構再定位改動文件最后給出評審意見。自動化測試生成需要先理解函數(shù)邏輯再設計用例再執(zhí)行測試?？缯Z言重構需要同時分析前后端代碼甚至還要同步修改文檔。這些場景如果用單 Agent 的“長對話”去完成對話上下文很容易被撐爆而且中間任何一個環(huán)節(jié)出錯整條鏈路都可能要重來。于是多 Agent 協(xié)作就成了一種很自然的設計思路。多 Agent 協(xié)作的核心不是“多聊幾句”而是讓不同 Agent 承擔不同角色例如負責讀取倉庫信息的 Reader Agent。負責生成代碼的 Coder Agent。負責審查代碼的 Reviewer Agent。這些 Agent 之間通過消息或文件交換結果每個 Agent 只關注自己擅長的部分。好處是職責清晰出問題時能快速定位到是哪個環(huán)節(jié)出現(xiàn)偏差。1.2 CLI 在 Agent 工作流中的特殊價值現(xiàn)在做 Agent 工具很多產(chǎn)品默認選擇 Web UI、桌面客戶端甚至 IDE 插件。CLI 看起來不夠“現(xiàn)代化”但對 Agent 工作流來說CLI 有三個不可替代的價值首先是腳本化。CLI 天然適合被 Shell、Python、CI 流水線調(diào)用。你可以在 Jenkins、GitHub Actions 或本地 cron 里直接運行 Agent 協(xié)作任務而不需要為每個任務打開一個圖形界面。其次是環(huán)境一致性。開發(fā)機、測試服務器、Docker 容器通常都沒有圖形界面但一定有終端。只要命令行工具能跑起來Agent 工作流就能復用同一套配置。最后是可組合性。CLI 可以把 Agent 的能力封裝成一個個獨立命令再由上層腳本組合出更復雜的工作流。Herdr 這類工具之所以被關注正是因為它踩中了這個方向。1.3 輕量協(xié)作工具的定位Herdr 的整體定位不是“重框架”而是“輕量協(xié)作層”。它不去重新實現(xiàn)大模型推理、向量檢索等底層能力而是專注于兩件事把多個可調(diào)用的 Agent CLI 編排成一條任務流。通過終端交互讓開發(fā)者快速觀察每個 Agent 的輸入輸出。這種定位和 Spring 生態(tài)里的消息隊列、工作流引擎思路有點類似但更輕、更面向開發(fā)者個體。1.4 易混淆概念Agent、Skill、Workflow、Orchestrator談 Herdr 時網(wǎng)上經(jīng)常把幾個概念混在一起。這里先做一個簡單區(qū)分Agent能獨立完成一個任務單元的智能體通常具備模型調(diào)用能力和工具調(diào)用能力。SkillAgent 可以調(diào)用的某個專項能力比如“讀取網(wǎng)頁”“執(zhí)行 Shell 命令”。Workflow一組有順序或條件的任務步驟。Orchestrator負責調(diào)度多個 Agent 的協(xié)調(diào)者。Herdr 更偏向 Orchestrator只是它用 CLI 的方式實現(xiàn)了 Orchestrator讓多個 Agent 像“命令行任務”一樣被啟動、監(jiān)控和終止。2. Herdr 核心概念與運行原理2.1 基礎運行模型Herdr 的運行模型可以簡化為終端用戶輸入任務 ↓ Herdr CLI 解析任務定義 ↓ 按順序/并行啟動多個 Agent 子任務 ↓ Agent 之間通過文件或消息傳遞臨時結果 ↓ 收集所有 Agent 輸出并呈現(xiàn)給用戶這種模型的好處是很容易理解用戶不需要理解復雜的分布式調(diào)度只要定義好“有哪些 Agent、任務怎么分發(fā)”剩下的交給 CLI。2.2 Agent 角色與會話在多 Agent 系統(tǒng)中最核心的概念是角色。每個角色包含一個唯一的名稱。一段系統(tǒng)提示詞用來約束 Agent 的行為。可用的命令或工具列表。輸出目錄或結果文件路徑。Herdr 的配置通常采用聲明式文件把角色信息和會話參數(shù)放在一起。啟動后CLI 會為每個 Agent 創(chuàng)建一個獨立的工作會話防止上下文互相污染。2.3 任務流模型Herdr 支持兩類基礎任務流一類是順序執(zhí)行。任務 A 完成后結果傳給任務 B。例如先分析代碼再生成建議最后執(zhí)行修改。順序模式適合有強依賴的場景。另一類是并行執(zhí)行。多個 Agent 可以同時對不同文件、不同目錄執(zhí)行任務。例如前端 Agent 修改 JS 文件后端 Agent 修改 Python 文件兩者互不依賴。并行模式可以顯著縮短總執(zhí)行時間但需要特別小心文件沖突。2.4 Skill 與 Agent 的關系較新版本的 Agent 框架都引入了 Skill 概念。Skill 比 Prompt 更結構化它通常是一個包含指令、示例代碼、元數(shù)據(jù)的文件夾。Agent 在執(zhí)行任務時會動態(tài)加載 Skill。Skill 和 Agent 的關系可以類比為“知識和執(zhí)行者”。Agent 決定什么時候用什么技能Skill 只提供方法論。Herdr 在編排時最好讓每個 Agent 明確知道自己掛載了哪些 Skill而不是在對話過程中臨時搜索。例如Reviewer Agent - Skill: code-review-guide - Skill: security-scan - 工作目錄: /repo - 輸出文件: review_result.md這樣定義后Agent 的執(zhí)行路徑會非常穩(wěn)定。3. 環(huán)境準備與安裝3.1 運行時環(huán)境Herdr 作為 CLI 工具對環(huán)境要求并不高。建議準備一個 64 位的 Linux、macOS 或 Windows 系統(tǒng)。終端環(huán)境Windows 用戶建議使用 PowerShell 7 或 Windows Terminal。已安裝 Node.js 18 或 Python 3.10具體取決于你的 Herdr 版本。Git用于拉取項目倉庫和示例代碼。由于 Herdr 項目迭代比較快版本需要根據(jù)你的項目實際情況調(diào)整。本文示例以常見環(huán)境為例重點演示配置思路。建議先查閱官方 README 獲取最新安裝方式避免命令過期。3.2 安裝 Herdr以 npm 安裝為例一個通用安裝命令如下npm install -g herdr如果你使用的是 Python 生態(tài)可能看到的是pip install herdr如果項目還處于源碼開發(fā)階段也可以通過 Git 克隆倉庫后手動鏈接git clone https://github.com/example/herdr.git cd herdr npm install npm link注意上面示例中的倉庫地址只是說明用法不能直接使用。真實地址請以項目官方倉庫為準。安裝完成后輸入herdr --version可以驗證是否安裝成功。3.3 安裝后的目錄作用Herdr 在首次運行后通常會在用戶主目錄下創(chuàng)建一個配置目錄~/.herdr/ ├── config.yaml ├── agents/ │ ├── coder.yaml │ └── reviewer.yaml ├── skills/ └── logs/其中config.yaml是全局配置agents目錄存放 Agent 角色定義logs目錄存放運行日志。在團隊協(xié)作中這份配置可以提交到 Git 倉庫統(tǒng)一管理但要注意不要把密鑰提交進去。3.4 與已有 CLI 工具共存實際開發(fā)中機器上可能已經(jīng)安裝了 Codex CLI、Cursor CLI、AWS CLI 等工具。Herdr 在設計上盡量不占用這些工具的名字以“指揮者”的方式調(diào)用外部命令。不過多 CLI 共存也會帶來問題最典型的就是環(huán)境變量 PATH 順序錯誤。如果你在執(zhí)行 Herdr 任務時發(fā)現(xiàn)找不到 Codex CLI通常需要檢查codex是否在 PATH 中或者代碼中是否設置了可執(zhí)行文件路徑。4. 快速上手配置與基礎命令4.1 初始化配置文件安裝完成后先初始化一個空項目herdr init my-agents執(zhí)行后Herdr 會在當前目錄生成一個類似下面的目錄結構my-agents/ ├── herdr.config.yaml └── agents/ └── example.yaml其中herdr.config.yaml是項目的總入口。如果你沒有執(zhí)行init也可以用手工方式手動創(chuàng)建目錄Herdr 一樣會讀取。4.2 定義第一個 Agent打開agents/example.yaml定義一個簡單的“代碼閱讀助手”name: repo-reader description: 讀取倉庫代碼并生成摘要 model: gpt-4.1 prompt: | 你是一個資深代碼分析師。請閱讀 {input_dir} 目錄下的代碼 輸出各模塊職責和關鍵函數(shù)說明保存為 summary.md。 tools: - read_file - list_dir output: dir: ./outputs file: summary.md字段解釋nameAgent 名稱在一個任務中必須唯一。model該 Agent 使用的大模型。prompt系統(tǒng)提示詞。{input_dir}是運行時傳入的變量。tools允許該 Agent 使用的工具白名單。output輸出文件的保存位置。定義完后可以用herdr agent validate校驗配置格式herdr agent validate agents/example.yaml如果配置正確終端會輸出類似 “config ok” 的消息。4.3 執(zhí)行單個 Agent運行單個 Agent 的基本命令如下herdr run agent --name repo-reader --input-dir ./src命令執(zhí)行期間Herdr 會把 Agent 的中間日志實時打印到終端。完成后去outputs/summary.md查看結果。這一步表現(xiàn)良好的話就可以嘗試把多個 Agent 串成一個任務。4.4 定義多 Agent 協(xié)作任務在herdr.config.yaml里增加一個任務定義tasks: review-and-fix: steps: - agent: repo-reader input: input_dir: ./src - agent: code-fixer input: input_dir: ./src review_file: ./outputs/summary.md mode: sequential執(zhí)行任務herdr run task --name review-and-fixHerdr 會先執(zhí)行 repo-reader等它生成summary.md后再把文件路徑傳給 code-fixer 作為輸入。這就是順序協(xié)作的基本流程。4.5 查看運行狀態(tài)復雜任務往往需要幾分鐘Herdr 提供了簡單的狀態(tài)查看命令herdr ps herdr logs task_id第一行顯示當前正在運行的任務 ID第二行查看指定任務的日志。這樣即使任務在后臺執(zhí)行你也能隨時觀察進度。5. 與主流 Agent CLI 集成以 Codex CLI 為例5.1 為什么把 Codex CLI 拉進來只靠 Herdr 自帶的基礎 Agent 能力往往不夠滿足日常開發(fā)。因為很多人已經(jīng)在用 Codex CLI 編寫和修改代碼Codex CLI 的背后已經(jīng)包含 OpenAI 的模型、代碼檢索、沙箱執(zhí)行等能力。與其在 Herdr 里重新實現(xiàn)一遍代碼生成不如讓 Herdr 調(diào)用 Codex CLI形成“編排層 執(zhí)行層”的架構。例如Herdr編排層 └── 調(diào)用 Codex CLI 完成任務 A └── 調(diào)用 Codex CLI 完成任務 B └── 收集結果做匯總這樣一來Herdr 能管理流程Codex CLI 能保證代碼生成質量分工明確。5.2 在 Herdr 中配置 Codex 執(zhí)行器假設你已經(jīng)在終端里通過codex命令正常運行 Codex CLI。接下來可以在 Herdr 的 Agent 配置里通過 shell 方式調(diào)用它name: codex-coder type: external command: | codex exec --skip-git-repo-check 請根據(jù) {input_dir} 下的架構文檔實現(xiàn)用戶登錄接口并補充單元測試 working_dir: {input_dir} output: dir: ./outputs file: codex_result.md執(zhí)行時Herdr 會把{input_dir}替換成真實目錄并在該目錄下啟動 Codex CLI。需要特別注意的是Codex CLI 在無頭環(huán)境中執(zhí)行需要確認認證狀態(tài)。建議先手動運行一次codex login再交給 Herdr 調(diào)度避免在任務流中間彈出交互式登錄界面。5.3 遇到 “unable to locate the codex cli binary” 怎么辦最近很多人在使用桌面端 Agent 工具時遇到了一個典型報錯ChatGPT failed to start. unable to locate the codex cli binary. set codex cli path or ensure the electron resources include bin/codex.這個現(xiàn)象也會在 Herdr 等工具調(diào)用 Codex CLI 時出現(xiàn)只不過表現(xiàn)形式可能不同。出現(xiàn)這類日志本質上是因為應用或腳本找不到codex可執(zhí)行文件。常見原因有這么幾種沒有安裝 Codex CLI只安裝了桌面客戶端。Codex CLI 不在當前 Shell 的 PATH 環(huán)境變量中。桌面應用安裝目錄里的bin/codex文件被刪除或被殺毒軟件隔離。你使用了 IDE 內(nèi)置的 Codex它只在 IDE 子進程中生效終端無法直接調(diào)用。排查思路可以按順序來先檢查是否能直接調(diào)用codex --version如果提示 command not found說明沒有安裝或沒有加入 PATH。再查找 codex 所在位置which codex在 macOS 上Codex CLI 可能安裝到了~/.codex/bin/codex在 Windows 上可能需要設置$env:CODEX_CLI_PATH C:\path\to\codex.exe最后在 Herdr 配置中顯式指定可執(zhí)行文件路徑而不是依賴 PATHname: codex-coder type: external executable: /Users/你的用戶名/.codex/bin/codex args: - exec - 請分析當前目錄代碼結構并生成測試設置executable可以繞開很多 PATH 相關的坑。但要避免把機器相關路徑提交到共享配置中建議通過環(huán)境變量注入export HERDR_CODEX_BIN/Users/你的用戶名/.codex/bin/codex5.4 多個 CLI 并發(fā)運行時的沖突當你用 Herdr 并行啟動多個 Codex CLI 任務時應特別關注兩個問題。第一個是工作目錄沖突。多個任務共享同一個工作目錄時可能同時創(chuàng)建同名臨時文件比如codex_patch.diff。解決辦法是給每個任務準備獨立子目錄workspace/ ├── task-001/ ├── task-002/ └── task-003/第二個是配置認證沖突。Codex CLI 的 auth.json 默認存放在用戶目錄如果多個任務同時刷新 token有可能出現(xiàn)文件鎖問題。目前建議不要在一個 Herdr 任務里啟動超過 5 個并發(fā) Codex CLI 子進程避免觸發(fā)限流或認證沖突。6. 完整實戰(zhàn)三 Agent 協(xié)作修改代碼并驗證6.1 業(yè)務場景假設我們有一個簡單的 Python 項目代碼倉庫里有幾個函數(shù)但缺少類型標注和異常處理。現(xiàn)在希望 Herdr 調(diào)度三個 Agentanalyzer讀取項目目錄生成問題清單。fixer根據(jù)問題清單使用 Codex CLI 修改代碼。validator運行測試輸出驗證結果。這個場景覆蓋了“讀取 → 修改 → 驗證”的完整閉環(huán)。6.2 項目結構先創(chuàng)建目錄結構herdr-demo/ ├── herdr.config.yaml ├── agents/ │ ├── analyzer.yaml │ ├── fixer.yaml │ └── validator.yaml ├── workspace/ │ ├── task-001/ │ └── task-002/ └── src/ ├── calculator.py └── test_calculator.py6.3 準備樣例代碼文件路徑src/calculator.pydef divide(a, b): return a / b def parse_int(value): return int(value)文件路徑src/test_calculator.pydef test_divide(): assert divide(10, 2) 5 def test_parse_int(): assert parse_int(42) 42這個樣例故意不處理除數(shù)為零的情況也缺少類型標注正好提供給 Agent 作為任務輸入。6.4 定義三個 Agent文件路徑agents/analyzer.yamlname: analyzer description: 掃描代碼并輸出問題清單 model: gpt-4.1-mini prompt: | 請分析 {input_dir} 目錄下的 Python 代碼從以下角度生成問題清單 1. 是否缺少類型標注 2. 是否存在潛在異常 3. 是否存在安全隱患 將結果保存為 {output_file} tools: - read_file - list_dir output: dir: workspace/task-001 file: analysis.md文件路徑agents/fixer.yamlname: fixer description: 根據(jù)評審意見修改代碼 type: external executable: ${HERDR_CODEX_BIN:-codex} args: - exec - --skip-git-repo-check - 請閱讀 workspace/task-001/analysis.md并修改 src/calculator.py要求保留原有函數(shù)行為并補充類型標注和異常處理。 working_dir: . output: dir: workspace/task-001 file: fix_result.md文件路徑agents/validator.yamlname: validator description: 運行測試并輸出驗證結果 prompt: | 請先運行 pytest src/test_calculator.py -v然后總結測試是否通過。 如果失敗請將失敗原因寫入 {output_file}。 tools: - run_shell output: dir: workspace/task-001 file: validation.md6.5 編寫任務編排配置文件路徑herdr.config.yamlprojects: demo: src_dir: ./src workspace_dir: ./workspace/task-001 tasks: auto-refactor: steps: - agent: analyzer input: input_dir: ./src output_file: workspace/task-001/analysis.md - agent: fixer input: input_dir: ./src analysis_file: workspace/task-001/analysis.md - agent: validator input: input_dir: ./src output_file: workspace/task-001/validation.md mode: sequential6.6 運行與驗證在項目根目錄執(zhí)行herdr run task --name auto-refactor預期流程如下analyzer 掃描 src 目錄在workspace/task-001/analysis.md中生成問題清單。fixer 調(diào)用 Codex CLI讀取問題清單并修改calculator.py。validator 執(zhí)行 pytest并把測試結果寫入validation.md。全部結束后查看結果cat workspace/task-001/analysis.md cat workspace/task-001/validation.md如果 validator 結果顯示測試失敗可以查看 Herdr 日志定位到具體失敗命令herdr logs --tail 1006.7 更進一步的并行協(xié)作如果項目包含多個互相不依賴的模塊可以把mode改成parallel。例如對前后端代碼分別修復tasks: parallel-fix: steps: - agent: fixer input: target: frontend - agent: fixer input: target: backend mode: parallel并行執(zhí)行時建議每個分支使用不同工作目錄避免多個 Agent 寫同一個文件。7. 常見問題與排查思路問題現(xiàn)象常見原因解決思路Herdr 命令不存在安裝失敗或 PATH 未生效重裝并檢查npm ls -g或pip show herdrAgent 找不到 Codex CLI未安裝 Codex 或 PATH 缺失在配置里指定executable路徑Codex 授權失效Token 過期重新執(zhí)行codex login任務一直卡住Agent 在等待用戶輸入使用--yes或非交互模式多個 Agent 并發(fā)寫同一文件缺少隔離機制為每個任務創(chuàng)建獨立子目錄輸出文件為空Prompt 中輸出路徑錯誤檢查 prompt 中的{output_file}是否被正確替換子任務執(zhí)行超時Agent 任務過長給 Agent 增加超時設置如timeout_seconds臨時文件殘留異常中斷在 Herdr 配置中啟用清理選項排查問題不必一上來就改代碼。使用herdr logs task_id查看日志通常能夠直接定位到是哪個 Agent、哪條命令出了問題。Agent 類問題往往不是配置語法錯誤而是 LLM 沒有按照預期的路徑寫文件因此日志中的工具調(diào)用記錄非常關鍵。8. 工程最佳實踐8.1 配置管理Agent 的配置建議全部納入版本控制同時把密鑰與配置分離。不要直接在 YAML 中寫 API Key。正確做法是使用環(huán)境變量注入export OPENAI_API_KEYsk-xxxx export HERDR_CODEX_BIN/usr/local/bin/codexHerdr 讀取配置時支持${VAR}形式的環(huán)境變量引用。這樣不同開發(fā)者的本機路徑、密鑰都能得到隔離。8.2 最小權限原則在配置 Agent 工具權限時必須遵守最小權限原則。不要讓 Agent 擁有無限制的 Shell 權限。應該只開放任務需要的工具例如只允許讀取指定目錄。只允許運行測試命令。不授予生產(chǎn)環(huán)境數(shù)據(jù)庫連接。不授予刪除文件權限。如果你需要通過 Herdr 調(diào)用外部服務務必確認服務允許這種自動化調(diào)用方式且已經(jīng)獲得項目負責人的授權。8.3 日志與可觀測性多 Agent 任務出問題時最怕的是“不知道哪一步出錯”。所以在項目配置中強烈建議開啟日志輸出。一個理想的 Agent 日志應包含當前執(zhí)行的 Agent 名稱。接收到的輸入文件路徑。實際執(zhí)行的命令行。返回結果或錯誤摘要。消耗的 Token 數(shù)量如果平臺支持。在 CI 系統(tǒng)中集成時可以把 Herdr 的日志輸出重定向到固定文件herdr run task --name auto-refactor logs/task-$(date %Y%m%d-%H%M%S).log 218.4 危險操作控制如果 Agent 的最終行為是修改代碼庫建議先讓 Agent 輸出 diff再由人工確認后應用。即使使用 Codex CLI也可以增加 dry-run 類參數(shù)。對于數(shù)據(jù)庫變更、刪除文件、發(fā)布操作等高風險指令嚴禁讓 Agent 在無人審核的情況下執(zhí)行。生產(chǎn)環(huán)境的任何變更都要經(jīng)過測試環(huán)境驗證并準備好回滾方案。8.5 文件命名與任務清理多 Agent 協(xié)作會產(chǎn)生大量中間文件。建議按任務 ID 建立獨立目錄workspace/ ├── 20250815-001/ ├── 20250815-002/任務結束后不要馬上刪除。保留原始日志可以幫助你復盤。只有當目錄空間明顯吃緊時再運行清理命令herdr cleanup --days 78.6 引入沙箱環(huán)境對于要執(zhí)行不可信代碼的 Agent建議在 Docker 容器中運行。Herdr 的 external 類型 Agent 可以配合 Docker 使用docker run --rm -v $(pwd):/workspace agent-image codex exec 修復代碼這樣即使 Agent 產(chǎn)生了誤操作影響范圍也被限制在容器內(nèi)。9. 總結與下一步學習路線Herdr 這個方向解決了一個現(xiàn)實問題單個 Agent 的能力邊界越來越明顯而多 Agent 的編排復雜度也需要工具去承接。通過 CLI 這種輕量入口來調(diào)度多個 Agent確實比搭建一套 Web 工作流平臺要快很多。我在這段時間的實踐里最大的體會有三點第一Agent CLI 工具之間的協(xié)作重點不是參數(shù)而是可執(zhí)行文件的位置和環(huán)境變量的傳遞。Codex CLI 報出的 binary 路徑問題未來會成為 Agent 編排工具鏈中一個高頻問題。第二任務目錄隔離是保證并行 Agent 穩(wěn)定運行的關鍵。多個 Agent 不寫同一個目錄大部分沖突都可以避免。第三日志比 Prompt 更重要。在多 Agent 工作流中每個 Agent 都是黑盒只有完整記錄工具調(diào)用和執(zhí)行結果才能讓你在異常發(fā)生時快速恢復現(xiàn)場。下一步如果你對 Agent 開發(fā)感興趣可以從這幾個方向繼續(xù)深入研究 Skill 機制看如何把團隊規(guī)范沉淀成 Agent 可加載的技能。了解 Agent 記憶和長期狀態(tài)管理。嘗試把 Herdr 接入 CI/CD 流水線讓代碼評審、自動化測試、文檔生成在提交代碼后自動執(zhí)行。關注主流 CLI Agent 工具的認證機制和沙箱機制這直接決定了你能否安全地大規(guī)模編排它們。動手永遠是學習 Agent 開發(fā)的最好方式。你可以先拿一個小項目練手定義兩個 Agent一個負責生成代碼一個負責審查代碼跑通后再逐步增加角色。如果能順手把自己的常用腳本封裝成 CLI Agent這套技能未來會非常值錢。