一行指令組好自己的 AI 代理團隊

📌 本文重點

• 把每個 Agent 當成可版本控制的 Git repo
• 用 AGENTS.md 與 skills/ 拆開角色與能力
• .agentlas/ 管理記憶與設定，輕鬆切換模型
• 用一行 CLI 指令生成並維護多代理 AI 團隊

只用一行指令，你就能建立一個「像程式專案一樣可版本控制」的多代理 AI 團隊，解決長期記憶混亂、每次對話都要重講一遍的痛點。

參考架構原文（作者在 Reddit 分享）：https://www.reddit.com/r/artificial/comments/1twmhya/an_opensource_agent_architecture_that_solves_the/

---

核心功能：把 Agent 當成一個 repo，而不是一段 prompt

這套開源架構的關鍵想法：每個 Agent 是一個 Git 倉庫，而不是存在聊天框裡的一段系統 prompt。

💡 關鍵： 把 Agent 轉成可版控的 Git repo，可以用熟悉的軟體開發流程（PR、review、版本管理）來調整 AI 行為，而不是每次重寫 prompt。

1. AGENTS.md：把「人設 + 任務範圍」寫成文件，而不是憑記憶

AGENTS.md 是這個架構的核心說明書，裡面通常會包含：

• 每個代理的角色定位
• 能做什麼（scope） / 不能做什麼（限制）
• 彼此如何協作（誰丟任務給誰、輸出長什麼樣）

你可以做的事：

1. 在任意資料夾新增 AGENTS.md，用這樣的格式寫第一個代理：

“`markdown
# Agents

## doc_assistant
– 角色：技術文件整理員
– 任務：整理長篇文件、產生摘要與目錄
– 輸出格式：Markdown，必須包含「摘要」「重點條列」「待釐清問題」三段

## code_reviewer
– 角色：程式碼審查員
– 任務：針對 Pull Request 提出具體修改建議
– 限制：不直接改動程式，只提出建議與風險說明
“`

1. 把這個 repo 推上 Git（GitHub / GitLab），之後團隊改需求只改這份文件。

2. skills/：把「能力」拆成工具，而不是糊在一大段 prompt 裡

傳統代理常見問題是：所有指令、規則、流程都揉在一段很長的系統 prompt 中，改一行就怕爆。

在這個架構裡，每個能力是一個 skill 檔案，放在 skills/ 資料夾，例如：

• skills/summarize_docs.md：怎麼讀、怎麼切段、輸出格式
• skills/review_pr.md：審查步驟、要檢查的細項
• skills/fetch_urls.md：如何抓網頁、處理錯誤

你可以做的事：

1. 新增資料夾 skills/，寫一個最小可用的 skill：

“`markdown
# summarize_docs

步驟：
1. 讀取輸入文件
2. 把文件拆成 3–7 個主題
3. 每個主題用 3 行內說清楚

輸出格式（Markdown）：
– 一句總結
– 主題列表（子彈點）
“`

1. 在 AGENTS.md 裡指定某個 agent 可以使用 summarize_docs 這個 skill。

3. .agentlas/：把「記憶和設定」存在檔案，而不是模型腦袋

.agentlas/ 是這套系統自己的設定與記憶資料夾，用來存：

• 各代理的偏好設定（語氣、輸出格式）
• 長期記憶索引（不是直接塞進模型，而是存成檔、用時再讀）
• 已完成任務的 metadata（方便日後追蹤與再訓練）

這樣的好處是：

• 不會把所有對話硬塞進「長期記憶」變成噪音
• 每次執行前可以用規則選擇要載入哪一段內容

你可以做的事：

• 在 .agentlas/config.yaml 加上最基本設定（示意）：

yaml
default_model: claude
memory:
enabled: true
strategy: recent-and-related
max_items: 50

---

適合誰用：3 個具體場景

1. 文件整理 + 程式碼審查：建立雙代理 pipeline

目標：

• 代理 A 整理設計文件
• 代理 B 以文件為準則，審查 PR 是否符合設計

你可以怎麼做：

1. 在 AGENTS.md 定義兩個代理：

“`markdown
## doc_assistant
– skills: [summarize_docs]

## code_reviewer
– skills: [review_pr]
– 會先讀 doc_assistant 的輸出再開始審查
“`

1. 把專案文件放在 docs/、程式碼在 src/，PR diff 存到 pr/123.patch。

2. 在終端機執行（以架構作者的描述為例）：

bash
agentlas run doc_assistant "整理 docs/ 裡的文件，產出開發規範摘要"
agentlas run code_reviewer "根據最新開發規範，審查 pr/123.patch"

1. 審查邏輯日後有變，就更新 skills/review_pr.md，而不是重新教一次模型。

2. 資料抓取 + 報表生成：自動化情報小幫手

目標：

• 代理 C 負責抓網站、清洗文字
• 代理 D 讀整理後資料，輸出報表（例如每週競品動態）

步驟：

1. 在 skills/fetch_urls.md 寫清楚：怎麼從列表讀網址、輸出 JSON 或 Markdown 表格。

2. 定義兩個 agent：

“`markdown
## data_collector
– skills: [fetch_urls]

## report_writer
– skills: [summarize_docs]
– 輸出格式：週報（含「本週重點」「風險」「下週觀察」）
“`

1. 每週只需要：

bash
agentlas run data_collector "從 urls.txt 抓內容，輸出到 data/this_week.md"
agentlas run report_writer "讀 data/this_week.md，生成 weekly_report.md"

1. 週報模板要改，就改 skills/summarize_docs.md 或另開 skills/weekly_report.md。

3. 多人團隊：把「AI 同事」當成共同維護的 repo

你可以把這個代理倉庫當成一個共享 AI SOP：

• PM 改 AGENTS.md 描述角色與流程
• 開發者在 skills/ 補上新的工具使用說明（例如專案腳本、內部 API）
• 新同事只要 clone 下來，就能直接用同一套 AI 工作流

實際做法：

1. 建一個 GitHub repo：company-ai-agents。

2. 定一條規則：

3. 改 Agent 行為 = 改 AGENTS.md / skills/，必須走 PR 流程

4. 不再使用的 Agent 要標記 deprecated，避免沒人知道它還在跑

5. 在 README 裡寫清楚「如何在本機執行 agentlas、如何切換模型」。

---

怎麼開始：一行指令 + 接上你習慣的模型

這個架構的一大好處是：不綁特定模型，可以跑在 Claude Code、Codex、Gemini CLI 等環境。

💡 關鍵： 架構與模型解耦，讓你能在不改 AGENTS.md 和 skills/ 的情況下，自由切換到成本更低或能力更強的模型。

1. 安裝指令（假設已提供 CLI：agentlas）

作者在 Reddit 說明，整套系統可以透過一行安裝：

pip install agentlas  # 或作者實際提供的套件名稱

接著在任意資料夾初始化：

agentlas init

這通常會自動產生：

• AGENTS.md
• skills/
• .agentlas/

你可以做的事：

• 直接在一個新資料夾跑 agentlas init，把它當成「AI 同事模板專案」。

2. 接上常見模型：Claude / Codex / Gemini CLI

根據作者說明，這個架構支援多個 runtime，不鎖在某一家：

• 想用 Claude：在 .agentlas/config.yaml 設定 runtime: claude_code
• 想用 OpenAI / Codex：設為 runtime: codex
• 想用 Gemini CLI：設為 runtime: gemini_cli

範例設定：

runtime: claude_code
model: claude-3-5-sonnet
api_key_env: ANTHROPIC_API_KEY

你可以做的事：

1. 先用你現在線上付費的模型（例如 Claude）跑通第一個 agent。

2. 之後想切換模型，只改 config，不改 AGENTS.md 和 skills/ 的內容。

3. 一句描述，讓系統自動幫你生出代理團隊

根據 Reddit 原文描述，你可以直接用一句話生成整個代理團隊，例如：

agentlas new "幫我建立一個：整理產品需求文件 + 產出技術任務清單的雙代理工作流"

CLI 會：

• 生成初版 AGENTS.md（定義 2 個代理）
• 建好對應的 skills 檔案
• 幫你填入基本步驟和輸出格式，之後你再微調

你可以做的事：

• 先讓工具幫你生一個「80 分」版本，再用 Git 慢慢調整到「95 分」。

---

延伸閱讀：為什麼要從「串 prompt」升級到「Agent 專案」？

如果你還在用 LangChain 式的「串 prompt + 自己管工具 schema」，可以參考這兩篇：

• MCP 架構介紹：https://pub.towardsai.net/langchain-was-my-first-love-mcp-is-who-i-actually-married-42d6645afa08
• 深度 agent 工作流實戰：https://pub.towardsai.net/ultimate-guide-for-deep-agents-b2d7a1b5c3da

這套開源架構跟 MCP 的共通點是：都把 Agent 當成一個長期維護的系統，而不是當場臨時寫的 prompt。

差別在於，這裡用「實際檔案 + repo」把行為和記憶拆開，讓你可以用熟悉的 Git 流程維護整套 AI 工作流。

現在你可以做的最後一件事：

• 開一個新 repo，跑一次 agentlas init，寫一個最小的 AGENTS.md
• 選一個你每天真的會用到的小流程（例如「整理會議紀錄」）
• 把它做成第一個可版本控制的 AI 代理

之後，每次你覺得「這件事好像可以交給 AI」，就把需求寫進 AGENTS.md 和 skills/，你自己的多代理 AI 團隊就會越長越完整。

🚀 你現在可以做的事

• 在本機建立新資料夾，執行 agentlas init，產出第一版 AGENTS.md 與 skills/
• 選一個日常流程（如整理會議紀錄），寫進 AGENTS.md 並建立對應的 skills/xxx.md
• 建一個 company-ai-agents repo，推上 GitHub，讓團隊透過 PR 共同維護你的 AI 代理 SOP