Agent Roundtable：構建一個本地多 Agent 專家圓桌系統

最近我搭建了一個多 Agent 聊天項目：agent_roundtable。

它的想法很直接：我給一個主題，系統請幾位不同方向的“專家 Agent”輪流發言，主持人負責追問、串聯和總結，最後把整場討論保存成一份 Markdown 報告。

這不是一個單純的聊天機器人，而是一個可以配置角色、配置模型、接入本地知識庫，並把討論過程沉澱爲文檔的本地 Agent 工作流。

我更願意把它理解成一個“專家圓桌工具”：不是讓一個模型一次性回答所有問題，而是把問題拆給不同視角的 Agent，讓它們圍繞同一主題展開討論。

一、爲什麼要做這個項目

我之前一直在思考一個問題：如果我要做一個真正有用的 AI Agent 系統，它到底應該長什麼樣？

單 Agent 很容易上手。你給它一個提示詞，讓它回答問題、調用工具、生成總結，這已經能做很多事。但當問題變複雜以後，單 Agent 的侷限也很明顯：

• 它容易把多個視角混在一起。
• 它很難穩定扮演多個專業角色。
• 它的回答常常像一篇綜合作文，而不是一場真實討論。
• 它很難明確區分“宏觀經濟視角”“投資視角”“AI 技術視角”“哲學視角”“歷史戰略視角”。

所以我想做一個多 Agent 圓桌。

一個主題可以交給不同專家分別討論。宏觀專家看制度和週期，投資專家看現金流和風險，AI 專家看技術演化，哲學專家看概念和價值判斷，歷史戰略專家看長期結構。

這樣做以後，輸出就不再只是“一個模型的答案”，而更像是一場結構化討論。

二、這個項目現在能做什麼

agent_roundtable 目前是一個本地運行的 Python 項目，支持命令行和本地網頁 UI 兩種方式。

它現在主要能做幾件事：

• 用命令行或本地 Streamlit UI 啓動多 Agent 圓桌。
• 每個 Agent 可以單獨配置 provider、模型和 API key 環境變量名。
• API key 只放在 .env，不會寫進 JSON、YAML、日誌或報告。
• 主線專家可以讀取各自的本地長文資料，並通過 RAG 檢索相關內容。
• 運行結果會自動保存到 logs/，生成 Markdown 報告。
• 報告中會標明每條發言使用的 provider 和 model。
• 沒有 API key 時，也可以用 --mock 先跑通完整流程。

目前項目裏有兩條內置圓桌：

這裏要特別說明：persona_inspired 只是“風格啓發”，不是冒充本人，也不代表本人觀點。它的作用是借用某種思考風格來組織回答。

三、我對 Agent 的理解

Agent 這個詞現在很熱，但如果講得太玄，反而不好理解。

我的理解是：Agent 不是“會聊天的模型”，而是一個能圍繞目標執行任務的系統單元。它通常包括幾部分：

• 一個角色或目標。
• 一套提示詞和行爲約束。
• 一些可調用工具。
• 一段可被更新的狀態。
• 必要時還會有記憶、知識庫和工作流控制。

普通聊天是“問一句，答一句”。Agent 更像是“爲了完成一件事，自己判斷下一步該做什麼”。

如果加入 Tool Use，Agent 就可以調用搜索、文件、數據庫、代碼執行等工具。如果加入 RAG，Agent 就可以先查資料再回答。如果加入工作流，多個 Agent 之間就可以按一定順序協作。

這也是我做 agent_roundtable 的原因：我不想只停留在提示詞層面，而是想把角色、知識、模型調用和運行流程都程序化。如果想更系統地從智能體基礎、ReAct 範式到記憶與 RAG 入門，可以參考 《Hello-Agents：從零開始構建 AI Agent 的開源教程》。

四、爲什麼是多 Agent，而不是一個超級 Agent

一個超級 Agent 當然也可以回答複雜問題，但我更喜歡多 Agent 的形式。

原因很簡單：現實中的複雜判斷，本來就不是一個聲音完成的。

比如討論“AI 對投資和就業的長期影響”，至少可以拆成幾種視角：

如果讓一個模型一次性回答，它可能也會覆蓋這些點，但它很難形成真正的視角差異。

多 Agent 的好處是：每個 Agent 都有自己的角色卡、知識範圍、說話風格和盲點。討論時，不同角色會從不同方向切入，主持人再把這些觀點串起來。

這比單純寫一個超長 prompt 更穩，也更容易擴展。

五、RAG 在這個項目裏的作用

RAG 可以通俗理解爲“開卷考試”。

普通 LLM 回答問題，主要依賴模型參數裏已有的知識。RAG 則是在生成回答之前，先從外部知識庫裏檢索相關資料，再把檢索到的內容交給模型參考。

在 agent_roundtable 裏，我把本地長文資料放在 knowledge/ 目錄下。每個專家可以對應自己的知識目錄，例如：

knowledge/macro_economist/
knowledge/investing_master/
knowledge/ai_researcher/
knowledge/philosophy_expert/
knowledge/history_strategist/

然後通過命令建立索引：

python -m rag.ingest --expert-name macro_economist --embedding-provider keyword

目前我優先支持 keyword 檢索，因爲它不需要額外 API key，適合本地測試和入門使用。後續如果要做更強的語義檢索，可以繼續接入 embedding 模型。

這個設計對我很重要。

我不希望專家 Agent 只靠模型自己的“印象”回答。我更希望它可以讀取我提前準備的書籍、論文、長文資料，把這些資料作爲它的知識背景。

這樣一來，Agent 就不只是一個角色扮演提示詞，而是一個有本地知識來源的專家系統雛形。

六、項目結構

項目結構大致如下：

agent_roundtable/
├── main.py
├── ui/
│   └── app.py
├── src/
│   ├── graph.py
│   ├── agents.py
│   ├── llm.py
│   ├── model_catalog.py
│   ├── agent_llm_config.py
│   ├── loader.py
│   ├── logger.py
│   ├── prompts.py
│   └── state.py
├── agents/
│   ├── domain_experts/
│   └── persona_inspired/
├── councils/
├── configs/
│   └── agent_llms.json
├── knowledge/
├── rag/
├── vector_db/chroma/
├── logs/
├── tests/
├── requirements.txt
└── .env.example

幾個關鍵目錄的作用：

我比較喜歡這種分層方式。角色是角色，模型配置是模型配置，知識庫是知識庫，運行日誌是運行日誌。它們不要混在一起。

七、Agent 角色卡如何設計

在這個項目裏，每個 Agent 都有自己的 YAML 角色卡。

一個 Agent 角色卡通常包括：

• 名稱。
• 角色。
• 世界觀。
• 說話風格。
• 優點。
• 盲點。
• 對應的 RAG 知識目錄。
• Agent 類型。

例如，一個能源專家可以這樣設計：

name: "Energy Expert"
role: "能源与产业政策专家"
worldview: "从能源供需、基础设施、地缘政治和技术替代分析问题"
speaking_style: "清晰、谨慎，先讲约束再讲判断"
strengths:
  - "能源供需分析"
  - "产业链拆解"
weaknesses:
  - "可能低估金融市场短期波动"
catchphrases:
  - "先看能源约束"
rag_expert_name: "energy_expert"
agent_type: "domain_expert"
profile:
  focus:
    - "能源安全"
    - "电力系统"
    - "油气与新能源"

這裏的重點不是“寫得像人設小說”，而是把 Agent 的分析邊界固定下來。

一個好的專家 Agent，應該知道自己擅長什麼，也知道自己可能忽略什麼。否則所有 Agent 最後都會變成同一種聲音。

八、模型配置爲什麼單獨放

我把每個 Agent 使用什麼模型，單獨放在 configs/agent_llms.json。

這樣做有一個好處：角色和模型解耦。

角色卡只描述“這個 Agent 是誰”。JSON 配置只描述“這個 Agent 用哪個 provider、哪個模型、哪個 API key 環境變量”。

例如：

{
  "agents": {
    "macro_economist": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-super-120b-a12b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    },
    "ai_researcher": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-ultra-550b-a55b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    }
  }
}

注意，api_key_env 不是 API key 本身。它只是告訴程序去 .env 裏找哪個變量。

真實 API key 不應該寫進 JSON、YAML、README、日誌或截圖裏。這一點很重要。

九、本地 UI 的意義

項目裏我加了一個本地 Streamlit UI。

它不是爲了做一個漂亮的商業產品，而是爲了讓配置過程更直觀。

在 UI 裏可以做這些事：

• 選擇圓桌。
• 設置每個 Agent 使用哪個 provider。
• 設置每個 Agent 使用哪個模型。
• 選擇每個 Agent 使用 .env 裏的哪個 API key。
• 保存配置到 configs/agent_llms.json。
• 輸入一個主題，直接運行真實 LLM。
• 查看運行進度、當前階段和最近事件。
• 預覽最終總結和對話記錄。

這個 UI 對我很實用。

因爲多 Agent 系統一旦開始擴展，手動改配置文件會越來越麻煩。UI 不需要複雜，但至少要能讓我快速切換模型、切換圓桌、測試不同組合。

十、MCP 與 Tool Use：未來可以怎麼接

agent_roundtable 當前重點是本地多 Agent 圓桌、RAG 和報告生成。MCP 還不是項目的核心實現，但它是很自然的下一步。

MCP 全稱是 Model Context Protocol，可以理解爲一種讓 AI 應用連接外部工具和數據源的開放協議。它試圖把模型與工具、數據庫、文件系統、業務系統之間的連接方式標準化。

如果說 RAG 主要解決“先查資料再回答”，那麼 MCP 更偏向解決“Agent 如何標準化地連接外部工具並執行動作”。

所以在這篇文章裏，我不會把 agent_roundtable 包裝成一個已經完整接入 MCP 的項目。更準確地說，它先把本地多 Agent 工作流跑通，再爲後續接入 MCP 和 Tool Use 留出接口空間。

對我這個項目來說，未來可以考慮幾類 MCP 能力：

• 接入文件系統 MCP，讓 Agent 更標準地讀取本地資料。
• 接入搜索 MCP，讓某些 Agent 可以聯網查證。
• 接入數據庫 MCP，讓金融或宏觀 Agent 查詢結構化數據。
• 接入 GitHub MCP，讓技術 Agent 可以分析倉庫、issue 和代碼。
• 接入日曆、郵件或任務系統，讓圓桌討論結果變成後續行動。

不過我現在不會一上來就把 MCP 做複雜。

我更傾向於先把本地 RAG、角色配置、模型調用、報告生成這條主線跑穩。等這個主線穩定後，再把 MCP 作爲工具層接入。

十一、和 ReAct、LangGraph 的關係

ReAct 是一個經典 Agent 思路：讓語言模型在推理和行動之間交替進行。通俗說，就是模型不只是直接給答案，而是邊想、邊調用工具、邊根據工具結果調整下一步。

LangGraph 則更偏向工作流編排。它把 Agent 流程建模成圖：節點可以是 Agent、工具、判斷邏輯或總結器，邊表示流程如何流轉。

多 Agent 圓桌非常適合用圖來理解：

flowchart TD
    A["主持人提出问题"] --> B["专家轮流发言"]
    B --> C["主持人小结"]
    C --> D["下一轮追问"]
    D --> B
    C --> E["最终总结"]

這不是簡單的鏈式調用，而是一個有狀態、有順序、有角色分工的工作流。

我的項目當前就是沿着這個方向設計：先有圓桌流程，再有 Agent 發言，再有總結和日誌沉澱。以後如果繼續增強，可以加入更復雜的條件分支，例如：

• 某個 Agent 發現證據不足時，觸發檢索。
• 兩個 Agent 觀點衝突時，主持人追問。
• 某輪討論質量不足時，自動加一輪反駁。
• 最終報告生成前，增加事實檢查 Agent。

這就是 Agent 工作流真正有意思的地方。

十二、開源時要注意什麼

這個項目會涉及本地知識庫、API key、運行日誌，所以開源時要非常小心。

我在 .gitignore 裏默認排除了幾類內容：

• .env：真實 API key。
• knowledge/**/*.md：本地書籍、論文、長文。
• logs/**：運行報告。
• vector_db/chroma/**：本地向量索引。
• __pycache__/、.pytest_cache/ 等臨時文件。

可以提交到 GitHub 的通常是：

• 代碼。
• README。
• agents/*.yaml。
• councils/*.yaml。
• configs/agent_llms.json。
• knowledge/README.md。
• .gitkeep 佔位文件。

尤其是 knowledge/ 目錄要謹慎。

如果裏面放了版權書籍、論文全文、私人資料或付費內容，就不應該上傳到公開倉庫。開源項目可以展示目錄結構和使用方式，但不應該把不適合公開的資料一起傳上去。

十三、這個項目對我的意義

對我來說，agent_roundtable 不只是一個玩具項目。

它把幾個我一直想練的方向連在了一起：

• AI Agent。
• 多智能體協作。
• RAG 知識庫。
• Tool Use。
• 本地工作流。
• 模型配置管理。
• Markdown 報告生成。
• 面向真實使用的 UI。

它也很適合繼續擴展。

以後我可以給宏觀經濟、投資、AI、歷史、哲學、玄學、編程等不同主題分別建立專家系統。每個專家都有自己的資料庫、角色卡和模型配置。用戶只需要輸入問題，就可以讓不同專家圍繞同一個主題討論。

這比單純寫幾個 prompt 更像一個系統。

這個項目目前完全用 Python 實現，更偏研究與實驗階段。如果未來要把它做成面向用戶的產品，語言選擇會變成另一個問題，我在 《AI Agent 用什麼語言：Python、TypeScript 與下一代產品工程》 裏展開過這個討論。

我現在越來越覺得，未來很多 AI 應用不是“一個聊天框解決一切”，而是由多個角色、工具、知識庫和工作流組合起來。

agent_roundtable 就是我對這個方向的一次實踐。

常見問題

agent_roundtable 是什麼？

它是一個本地運行的多 Agent 專家圓桌項目。你給定一個主題，系統會請幾位不同方向的專家 Agent 輪流發言，主持人負責追問、串聯和總結，最後把整場討論保存成一份 Markdown 報告。它支持命令行和本地 Streamlit UI 兩種方式，每個 Agent 可以單獨配置 provider、模型和 API key 環境變量。

爲什麼用多 Agent，而不是一個超級 Agent？

現實中的複雜判斷本來就不是一個聲音完成的。多 Agent 的好處是每個 Agent 都有自己的角色卡、知識範圍、說話風格和盲點，討論時會從不同方向切入，再由主持人串聯。這比寫一個超長 prompt 更穩，也更容易擴展。

沒有 API key 也能運行嗎？

可以。項目支持 --mock 模式，在沒有 API key 時先跑通完整流程；RAG 檢索也默認優先支持 keyword 方式，不需要額外的 embedding API key，適合本地測試和入門。

這個項目接入 MCP 了嗎？

目前還沒有。agent_roundtable 當前重點是本地多 Agent 圓桌、RAG 和報告生成，MCP 與 Tool Use 是很自然的下一步，項目爲後續接入預留了接口空間，但還不是核心實現。

開源時如何避免泄露 API key 和私有資料？

真實 API key 只放在 .env，配置文件裏只寫 api_key_env 變量名，不寫 key 本身。.gitignore 默認排除 .env、knowledge/ 下的本地資料、logs/ 運行報告和 vector_db/chroma/ 向量索引；公開倉庫只提交代碼、README、角色卡、configs/agent_llms.json 和佔位文件。

參考來源

• Random-Walk2026/agent_roundtable GitHub 倉庫
• Model Context Protocol 官方文檔
• Anthropic：Introducing the Model Context Protocol
• LangGraph 官方頁面
• LangGraph：Multi-Agent Workflows
• ReAct: Synergizing Reasoning and Acting in Language Models
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks