Agent Roundtable: Xây dựng hệ thống bàn tròn chuyên gia đa tác nhân cục bộ

Gần đây tôi đã triển khai một dự án chat nhiều Agent: agent_roundtable.

Ý tưởng của nó khá trực diện: tôi đưa ra một chủ đề, hệ thống mời vài “Agent chuyên gia” theo các hướng khác nhau phát biểu luân phiên, người dẫn chương trình chịu trách nhiệm đặt câu hỏi truy vấn, kết nối các ý và tổng kết, cuối cùng lưu toàn bộ cuộc thảo luận thành một báo cáo Markdown.

Đây không phải là một chatbot đơn thuần, mà là một quy trình làm việc Agent cục bộ có thể cấu hình vai trò, cấu hình mô hình, kết nối cơ sở kiến thức nội bộ và đóng gói toàn bộ quá trình thảo luận thành tài liệu.

Tôi thích hiểu nó như một “công cụ bàn tròn chuyên gia”: không phải để một mô hình trả lời tất cả cùng lúc, mà là tách câu hỏi theo nhiều góc nhìn cho các Agent khác nhau, để họ cùng thảo luận quanh cùng một chủ đề.

Một, vì sao tôi làm dự án này

Tôi đã lâu nghĩ về một câu hỏi: nếu tôi muốn xây một hệ thống AI Agent thật sự hữu ích, nó nên trông như thế nào?

Agent đơn lẻ rất dễ bắt đầu. Bạn đưa cho nó một prompt, nó trả lời câu hỏi, gọi tool, tạo tóm tắt — đã làm được nhiều việc. Nhưng khi câu hỏi trở nên phức tạp, hạn chế của một Agent lộ rõ:

• Nó dễ trộn lẫn nhiều góc nhìn.
• Khó duy trì việc nhập vai nhiều vai trò chuyên môn ổn định.
• Câu trả lời thường giống một bài văn tổng hợp, chứ không phải một cuộc thảo luận thực sự.
• Khó tách bạch rành mạch giữa “góc nhìn vĩ mô”, “góc nhìn đầu tư”, “góc nhìn công nghệ AI”, “góc nhìn triết học”, “góc nhìn chiến lược lịch sử”.

Vì vậy tôi muốn làm một bàn tròn đa Agent.

Một chủ đề có thể được giao cho các chuyên gia khác nhau thảo luận. Chuyên gia vĩ mô nhìn vào thể chế và chu kỳ, chuyên gia đầu tư nhìn dòng tiền và rủi ro, chuyên gia AI nhìn tiến hóa công nghệ, chuyên gia triết học nhìn khái niệm và phán đoán giá trị, chuyên gia chiến lược lịch sử nhìn cấu trúc dài hạn.

Làm như vậy, đầu ra không còn chỉ là “một câu trả lời của một mô hình”, mà giống một cuộc thảo luận có cấu trúc hơn.

Hai, dự án này hiện tại có thể làm gì

agent_roundtable hiện là một dự án Python chạy cục bộ, hỗ trợ cả dòng lệnh lẫn giao diện web nội bộ.

Nó hiện tại chủ yếu làm được vài việc:

• Khởi chạy bàn tròn đa Agent qua CLI hoặc Streamlit UI nội bộ.
• Mỗi Agent có thể cấu hình riêng provider, mô hình và tên biến môi trường API key.
• API key chỉ nằm trong .env, không được ghi vào JSON, YAML, log hoặc báo cáo.
• Chuyên gia chính có thể đọc tài liệu dài cục bộ riêng và lấy nội dung liên quan qua RAG.
• Kết quả chạy được tự động lưu vào logs/, sinh ra báo cáo Markdown.
• Trong báo cáo, mỗi phát biểu sẽ ghi rõ provider và model đã dùng.
• Khi chưa có API key, vẫn có thể chạy được toàn bộ quy trình bằng --mock.

Hiện tại dự án có sẵn hai bàn tròn:

Điều cần nhấn mạnh: persona_inspired chỉ là “cảm hứng phong cách”, không đóng giả cá nhân nào cả và cũng không đại diện cho quan điểm của họ. Nó dùng để tổ chức câu trả lời theo một lối tư duy nhất định.

Ba, cách tôi hiểu về Agent

Thuật ngữ Agent đang rất thịnh hành, nhưng nếu diễn giải quá “trừu tượng” thì lại khó hiểu.

Theo tôi, Agent không phải là “mô hình biết chat”, mà là một đơn vị hệ thống thực thi mục tiêu. Nó thường gồm vài phần:

• Một vai trò hoặc mục tiêu.
• Một bộ prompt và ràng buộc hành vi.
• Một số công cụ có thể gọi.
• Một đoạn trạng thái có thể cập nhật.
• Khi cần, còn có thể có bộ nhớ, cơ sở tri thức và điều phối quy trình.

Chat thông thường là “hỏi một câu, đáp một câu”. Agent giống “để hoàn thành một việc, tự đánh giá bước tiếp theo mình cần làm gì”.

Nếu thêm Tool Use, Agent có thể gọi được công cụ tìm kiếm, file, cơ sở dữ liệu, thực thi code. Nếu thêm RAG, Agent có thể tìm tài liệu trước rồi mới trả lời. Nếu thêm workflow, nhiều Agent có thể phối hợp theo thứ tự nhất định.

Đây là lý do tôi làm agent_roundtable: tôi không muốn dừng ở lớp prompt, mà muốn chương trình hóa vai trò, tri thức, lời gọi mô hình và luồng thực thi. Nếu muốn bắt đầu hệ thống AI Agent có hệ thống từ nền tảng, ReAct, memory đến RAG, bạn có thể tham khảo 《Hello-Agents: Hướng dẫn xây dựng AI Agent mã nguồn mở từ con số 0》.

Bốn, vì sao là đa Agent, không phải một siêu Agent

Một siêu Agent thì vẫn có thể trả lời câu hỏi phức tạp, nhưng tôi thích hình thức đa Agent hơn.

Lý do rất đơn giản: phán đoán phức tạp trong thực tế vốn không thể chỉ do một tiếng nói duy nhất.

Ví dụ khi thảo luận “tác động dài hạn của AI đến đầu tư và việc làm”, tối thiểu có thể tách ra các góc nhìn:

Nếu để một mô hình trả lời một lần, nó có thể chạm đến cả các điểm này, nhưng khó tạo ra sự khác biệt thực chất giữa các góc nhìn.

Ưu điểm của đa Agent là: mỗi Agent có lá bài vai trò, phạm vi kiến thức, phong cách nói và “điểm mù” của riêng mình. Khi thảo luận, các vai trò đi vào vấn đề từ nhiều hướng, người dẫn chương trình sau đó liên kết các quan điểm.

Cách này bền vững hơn nhiều so với viết một prompt siêu dài, và dễ mở rộng hơn.

Năm, vai trò của RAG trong dự án này

RAG có thể hiểu giản đơn là “mở sách rồi làm bài thi”.

Mô hình LLM thông thường trả lời chủ yếu dựa vào tri thức đã có trong tham số. RAG thì trước khi sinh đáp án sẽ truy xuất tài liệu liên quan từ kho tri thức bên ngoài rồi đưa chúng cho mô hình tham chiếu.

Trong agent_roundtable, tôi để tài liệu dài cục bộ trong thư mục knowledge/. Mỗi chuyên gia có thể gắn với thư mục kiến thức riêng, ví dụ:

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

Rồi tạo chỉ mục bằng lệnh:

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

Hiện tại tôi ưu tiên hỗ trợ truy xuất keyword, vì không cần API key phụ, phù hợp cho test cục bộ và làm quen ban đầu. Sau này nếu muốn truy vấn ngữ nghĩa mạnh hơn có thể tiếp tục tích hợp embedding model.

Thiết kế này rất quan trọng với tôi.

Tôi không muốn Agent chuyên gia chỉ trả lời bằng “ấn tượng” của mô hình. Tôi muốn nó đọc trước các sách, bài báo, tài liệu dài mà tôi đã chuẩn bị, để dùng chúng làm nền tảng tri thức của mình.

Như vậy Agent không còn là một prompt nhập vai, mà là phác họa ban đầu của một hệ thống chuyên gia có nguồn tri thức nội bộ.

Sáu, cấu trúc dự án

Cấu trúc dự án nhìn chung như sau:

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

Vai trò của một số thư mục quan trọng:

Tôi thích cách tách lớp như vậy. Vai trò là vai trò, cấu hình mô hình là cấu hình mô hình, cơ sở tri thức là cơ sở tri thức, log chạy là log. Chúng không nên trộn vào nhau.

Bảy, cách thiết kế role card Agent

Trong dự án này, mỗi Agent có YAML role card riêng.

Một role card thường gồm:

• Tên.
• Vai trò.
• Tầm nhìn thế giới.
• Phong cách nói.
• Điểm mạnh.
• Điểm yếu.
• Thư mục kiến thức RAG tương ứng.
• Loại Agent.

Ví dụ, một chuyên gia năng lượng có thể được thiết kế như sau:

name: "Energy Expert"
role: "Chuyên gia chính sách năng lượng và công nghiệp"
worldview: "Phân tích vấn đề qua cung-cầu năng lượng, hạ tầng, địa chính trị và thay thế công nghệ"
speaking_style: "Rõ ràng, thận trọng: trước nói ràng buộc, sau mới nêu kết luận"
strengths:
  - "Phân tích cung cầu năng lượng"
  - "Phá vỡ chuỗi giá trị ngành"
weaknesses:
  - "Có thể đánh giá thấp dao động ngắn hạn của thị trường tài chính"
catchphrases:
  - "Nhìn trước hết ràng buộc năng lượng"
rag_expert_name: "energy_expert"
agent_type: "domain_expert"
profile:
  focus:
    - "An ninh năng lượng"
    - "Hệ thống điện"
    - "Dầu khí và năng lượng tái tạo"

Điểm mấu chốt ở đây không phải “viết giống truyện nhân vật”, mà là khóa cứng biên giới phân tích của Agent.

Một Agent chuyên gia tốt nên biết mình giỏi gì và cũng biết mình có thể bỏ sót gì. Nếu không, cuối cùng tất cả Agent sẽ thu về một giọng nói duy nhất.

Tám, vì sao đặt cấu hình mô hình riêng

Tôi đặt riêng cấu hình mô hình mà từng Agent dùng trong configs/agent_llms.json.

Cách này có lợi thế là tách rời vai trò và mô hình.

Role card chỉ mô tả “Agent này là ai”. JSON cấu hình chỉ mô tả “Agent này dùng provider nào, model nào, biến môi trường API key nào”.

Ví dụ:

{
  "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"
    }
  }
}

Lưu ý, api_key_env không phải là API key thực. Nó chỉ báo cho chương trình biết tìm biến nào trong .env.

API key thực không nên được ghi vào JSON, YAML, README, log hay ảnh chụp màn hình. Điểm này rất quan trọng.

Chín, ý nghĩa của UI cục bộ

Trong dự án tôi thêm một Streamlit UI cục bộ.

Nó không nhằm làm một sản phẩm thương mại bóng bẩy, mà để việc cấu hình trực quan hơn.

Trong UI có thể làm:

• Chọn bàn tròn.
• Đặt provider cho từng Agent.
• Đặt model cho từng Agent.
• Chọn API key nào trong .env cho từng Agent.
• Lưu cấu hình vào configs/agent_llms.json.
• Nhập chủ đề rồi chạy LLM thật.
• Xem tiến độ chạy, giai đoạn hiện tại và sự kiện gần nhất.
• Xem trước tổng kết cuối cùng và bản ghi hội thoại.

UI này rất hữu dụng với tôi.

Vì khi hệ thống đa Agent bắt đầu mở rộng, sửa cấu hình thủ công trong file sẽ ngày càng phiền phức. UI không cần phức tạp, nhưng đủ cho tôi nhanh chóng đổi mô hình, đổi bàn tròn, thử các tổ hợp khác nhau.

Mười, MCP và Tool Use: hướng tiếp cận tương lai

agent_roundtable hiện tập trung vào bàn tròn đa Agent cục bộ, RAG và tạo báo cáo. MCP chưa phải phần lõi thực thi hiện tại, nhưng là bước kế tiếp rất tự nhiên.

MCP viết tắt của Model Context Protocol, có thể hiểu là giao thức mở giúp ứng dụng AI kết nối với công cụ và nguồn dữ liệu bên ngoài. Nó cố gắng chuẩn hóa cách kết nối giữa mô hình với công cụ, cơ sở dữ liệu, hệ thống tệp và hệ thống nghiệp vụ.

Nếu RAG chủ yếu giải quyết “trước khi trả lời thì tra cứu tài liệu”, thì MCP nghiêng về “Agent kết nối công cụ bên ngoài theo chuẩn như thế nào và thực thi hành động ra sao”.

Vì vậy, trong bài này tôi không đóng gói agent_roundtable thành một dự án đã tích hợp MCP đầy đủ. Nói chính xác hơn, nó trước hết vận hành xong workflow đa Agent cục bộ, rồi dành giao diện mở cho việc tích hợp MCP và Tool Use về sau.

Với dự án này, tôi nghĩ có thể xem xét một số năng lực MCP như sau:

• Tích hợp file system MCP để Agent đọc tài liệu cục bộ theo chuẩn hơn.
• Tích hợp search MCP để một số Agent có thể kiểm chứng thông tin trực tuyến.
• Tích hợp database MCP để Agent tài chính hoặc vĩ mô truy vấn dữ liệu có cấu trúc.
• Tích hợp GitHub MCP để Agent kỹ thuật có thể phân tích repo, issue, code.
• Tích hợp lịch, email hoặc hệ thống nhiệm vụ để kết quả bàn tròn chuyển thành hành động tiếp theo.

Nhưng tôi không vội phức tạp hóa MCP ngay từ đầu.

Tôi ưu tiên trước hết chạy chắc quy trình chính: RAG cục bộ, cấu hình vai trò, gọi mô hình, sinh báo cáo. Khi trục này ổn định, mới đưa MCP vào như một lớp công cụ.

Mười một, mối liên hệ với ReAct và LangGraph

ReAct là một tư duy Agent kinh điển: để mô hình ngôn ngữ luân phiên giữa suy luận và hành động. Nói nôm na, model không chỉ đưa đáp án ngay, mà sẽ vừa nghĩ, vừa gọi công cụ, vừa điều chỉnh bước kế tiếp theo kết quả từ công cụ.

LangGraph thiên về điều phối workflow. Nó mô hình hóa quá trình Agent thành đồ thị: nút có thể là Agent, công cụ, logic rẽ nhánh hoặc bộ tổng hợp; cạnh cho biết luồng đi như thế nào.

Bàn tròn đa Agent rất hợp để nhìn theo đồ thị:

flowchart TD
    A["Người dẫn chương trình nêu vấn đề"] --> B["Chuyên gia phát biểu luân phiên"]
    B --> C["Người dẫn chương trình tóm tắt"]
    C --> D["Lượt tiếp theo: đặt câu hỏi tiếp"]
    D --> B
    C --> E["Tổng kết cuối cùng"]

Đây không phải gọi chuỗi đơn giản, mà là một workflow có trạng thái, có thứ tự, có phân công vai trò.

Dự án hiện tại của tôi đang thiết kế theo hướng này: trước hết có quy trình bàn tròn, rồi phát biểu của Agent, rồi tổng kết và lưu log. Sau này nếu mở rộng tiếp, có thể thêm nhánh điều kiện phức tạp hơn, chẳng hạn:

• Khi một Agent phát hiện bằng chứng thiếu, kích hoạt truy xuất.
• Khi hai Agent mâu thuẫn, người dẫn chương trình truy vấn lại.
• Khi chất lượng một vòng thảo luận chưa đủ, tự động thêm một vòng phản biện.
• Trước khi sinh báo cáo cuối, thêm Agent kiểm chứng thực tế.

Đây là điểm thú vị thật sự của workflow Agent.

Mười hai, lưu ý khi mở mã nguồn

Dự án này liên quan đến cơ sở tri thức cục bộ, API key và log chạy, nên khi mở nguồn phải rất cẩn thận.

Trong .gitignore mặc định, tôi đã loại trừ một số loại:

• .env: API key thực.
• knowledge/**/*.md: sách, bài báo, bài viết dài cục bộ.
• logs/**: báo cáo chạy.
• vector_db/chroma/**: chỉ mục vector cục bộ.
• file tạm như __pycache__/, .pytest_cache/ và tương tự.

Những thứ thường có thể đẩy lên GitHub là:

• Mã nguồn.
• README.
• agents/*.yaml.
• councils/*.yaml.
• configs/agent_llms.json.
• knowledge/README.md.
• file .gitkeep.

Đặc biệt là thư mục knowledge/ cần đặc biệt thận trọng.

Nếu bên trong có sách bản quyền, toàn văn luận văn, tài liệu riêng tư hoặc nội dung trả phí thì không nên đưa lên repo công khai. Dự án mã nguồn mở có thể hiển thị cấu trúc thư mục và cách dùng, nhưng không nên đẩy kèm tài liệu không phù hợp để công bố.

Mười ba, ý nghĩa của dự án này với tôi

Với tôi, agent_roundtable không phải một dự án chơi.

Nó gom lại nhiều hướng tôi đã muốn rèn lâu nay:

• AI Agent.
• Hợp tác đa tác nhân.
• Kho tri thức RAG.
• Tool Use.
• Workflow cục bộ.
• Quản trị cấu hình mô hình.
• Sinh báo cáo Markdown.
• UI dùng được trong tình huống thực tế.

Nó cũng rất dễ mở rộng thêm.

Sau này tôi có thể tạo các hệ thống chuyên gia riêng theo chủ đề vĩ mô, đầu tư, AI, lịch sử, triết học, huyền thuật, lập trình... Mỗi chuyên gia có kho dữ liệu, role card và cấu hình mô hình riêng. Người dùng chỉ cần nhập câu hỏi để các chuyên gia khác nhau cùng thảo luận quanh một chủ đề.

So với việc viết vài prompt, cách này giống một hệ thống hơn.

Dự án hiện hoàn toàn triển khai bằng Python, thiên về giai đoạn nghiên cứu và thử nghiệm. Nếu sau này biến thành sản phẩm hướng người dùng, câu chuyện ngôn ngữ sẽ trở thành một vấn đề mới, tôi đã thảo luận ở 《AI Agent nên dùng ngôn ngữ gì: Python, TypeScript và kỹ thuật sản phẩm thế hệ kế tiếp》.

Hiện tại tôi ngày càng cảm thấy, nhiều ứng dụng AI tương lai không phải là “một hộp chat giải quyết mọi thứ”, mà là tổ hợp nhiều vai trò, công cụ, cơ sở tri thức và workflow.

agent_roundtable là một lần thực hành của tôi theo hướng đó.

Câu hỏi thường gặp

agent_roundtable là gì?

Đây là một dự án bàn tròn chuyên gia đa Agent chạy cục bộ. Bạn đưa ra một chủ đề, hệ thống sẽ mời vài Agent chuyên gia theo hướng khác nhau phát biểu luân phiên, người dẫn chương trình chịu trách nhiệm đặt câu hỏi tiếp theo, liên kết và tổng kết, cuối cùng lưu toàn bộ cuộc thảo luận thành báo cáo Markdown. Nó hỗ trợ CLI và Streamlit UI cục bộ, mỗi Agent có thể cấu hình riêng provider, mô hình và biến môi trường API key.

Vì sao dùng đa Agent thay vì một siêu Agent?

Phán đoán phức tạp trong thực tế không thể hoàn tất bởi một tiếng nói duy nhất. Ưu điểm của đa Agent là mỗi Agent có role card, phạm vi tri thức, phong cách nói và điểm mù riêng; khi thảo luận sẽ tiếp cận từ nhiều hướng, rồi người dẫn chương trình nối các ý lại. Cách này ổn định hơn việc viết một prompt siêu dài và dễ mở rộng hơn.

Không có API key vẫn chạy được không?

Có. Dự án hỗ trợ chế độ --mock, khi không có API key vẫn có thể chạy thông suốt toàn bộ quy trình; truy xuất RAG cũng mặc định ưu tiên keyword, không cần API key embedding phụ, phù hợp cho test cục bộ và làm quen ban đầu.

Dự án này đã tích hợp MCP chưa?

Hiện tại thì chưa. agent_roundtable hiện tập trung vào bàn tròn đa Agent cục bộ, RAG và sinh báo cáo; MCP và Tool Use là hướng tiếp theo rất tự nhiên, và dự án đã giữ sẵn không gian giao diện cho việc tích hợp sau, nhưng chưa phải phần cốt lõi hiện tại.

Mở mã nguồn để tránh rò rỉ API key và tài liệu riêng tư bằng cách nào?

API key thực chỉ nằm trong .env, trong file cấu hình chỉ ghi tên biến api_key_env, không ghi key thật. .gitignore mặc định loại trừ .env, tài liệu cục bộ dưới knowledge/, báo cáo chạy trong logs/ và chỉ mục vector tại vector_db/chroma/; repo công khai chỉ nên commit mã, README, role card, configs/agent_llms.json và file placeholder.

Tài liệu tham khảo

• Kho lưu trữ GitHub Random-Walk2026/agent_roundtable
• Tài liệu chính thức Model Context Protocol
• Anthropic: Introducing the Model Context Protocol
• Trang chính thức LangGraph
• LangGraph: Multi-Agent Workflows
• ReAct: Synergizing Reasoning and Acting in Language Models
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks