Đã đăng vào khoảng 13 giờ trước 28 phút đọc

Kimi 2.5, Agent Swarm và Strands Agent

1. Giới Thiệu về Kimi 2.5

Kimi K2.5 là một mô hình AI mở (open-source) được phát triển bởi Moonshot AI, ra mắt mới đây vào ngày 27 tháng 1 năm 2026, được định vị là một mô hình đa phương thức (multimodal) với khả năng xử lý văn bản, hình ảnh và video trong cùng một kiến trúc thay vì gắn thêm thị giác như “phần mở rộng” của mô hình chỉ chữ viết. Đoạn “Gắn thêm thị giác như phần mở rộng” hơi khó hiểu nên mình sẽ giải thích đơn giản là trong nhiều mô hình LLM trước đây, kiến trúc thực tế là: Text-LLM trước → Vision encoder gắn bên ngoài → nối vector → đưa vào LLM, ở đây tức là :

Lõi chính của mô hình được thiết kế cho text
Thị giác (image/video) là module phụ, làm nhiệm vụ:
1. Biến ảnh thành embedding
2. Gửi embedding đó cho LLM xử lý tiếp

Hệ quả là :

LLM không “nghĩ bằng hình ảnh”, nó chỉ nhận một chuỗi vector trừu tượng và coi ảnh như một đoạn text đặc biệt.
Reasoning chủ yếu vẫn xoay quanh text.
Vision lại thường yếu trong các task cần quan hệ không gian, chuỗi hành động theo thời gian (video) hay gắn logic trực tiếp với ảnh.

Một điểm cộng đáng chú ý là K2.5 cung cấp mã và trọng số mở, nên cộng đồng có thể tải về, chạy ở local hoặc tích hợp vào ứng dụng của riêng mình.

2. Benchmark

Theo như đội ngũ phát triển Kimi 2.5 thì họ đang tuyên bố "bố mày là nhất ở 2 hạng mục một là Global SOTA Agentic Benchmarks và Opensource SOTA on Vision and Coding" cái này thì mọi người có thể tự dùng và trải nghiệm 😅. Đi sâu vào từng cái thì có thể thấy ở tất cả từng hạng mục thì Kimi 2.5 đều cho con số vượt trột hơn tất cả các mô hình khác ngoài trừ phần Coding là thua Claude opus 😅 con số nghe thật kinh hoàng không biết như nào nhưng cá nhân mình thì vẫn đánh giá Claude Opus vẫn sẽ mô hình ngon nhất ở thời điểm hiện tại nhé 🫣. Thêm nữa một cái mình quan tâm hơn ở Kimi 2.5 này là chỉ số Agent Swarm có thể khởi tạo và điều phối tối đa 100 sub-agent và call tới 1500 tool calls. Cách tiếp cận Agent Swarm này khá hay ho và thú vị nên mình sẽ nói rõ hơn ở phía dưới. Dựa trên kiến trúc và bài báo về Kimi 2.5 thì có thể thấy mục tiêu chính của K2.5 không chỉ là trả lời câu hỏi, mà là hỗ trợ thực thi công việc thực tế — ví dụ tự động soạn tài liệu, tạo giao diện UI từ ảnh/video, viết code có cấu trúc, xử lý nhiều bước phức tạp và phối hợp nhiều tác vụ song song. Model cung cấp nhiều “chế độ” tương tác khác nhau: phản hồi nhanh, tư duy sâu, agent tự động và agent swarm chạy nhiều tác vụ song song.

3. Kiến Trúc

Thành phần	Mô tả
Kiến trúc chính	Sparse Mixture-of-Experts Transformer (~1T params)
Đa phương thức	Text + Vision + Video native
Vision Encoder	MoonViT ~400M params
Swarm Agent	100 agent song song, PARL orchestration

3. Agent Swarm & Parallel-Agent Reinforcement Learning (PARL)

3.1 Agent Swarm

Đây là một trong những điểm khác biệt lớn nhất của Kimi 2.5 so với các mô hình khác và đây cũng là cái mình cảm thấy thú vị nhất ở Kimi 2.5 bên dưới mình sẽ implement trực tiếp cái Agent Swarm này để cho mọi người thấy việc áp dụng Agent Swarm vào bài toán hiện tại mình đang làm nó hiệu quả như nào. Thay vì chỉ dùng một agent duy nhất thì Kimi 2.5:

Kimi 2.5 có thể tạo và tự điều phối tới ~100 sub-agent song song.
Mỗi sub-agent có thể phục vụ một phần nhỏ của bài toán (ví dụ: tra cứu dữ liệu, generate code, viết báo cáo, kiểm tra logic…).
Việc phối hợp các sub-agent này sử dụng một trainable orchestrator học qua chiến lược gọi là Parallel-Agent Reinforcement Learning (PARL), nhằm giảm “serial collapse” (tức là agent chạy tuần tự) và thúc đẩy xử lý song song thật sự. => Nhờ đó, mô hình tuyên bố tốc độ xử lý tác vụ phức tạp giảm tới ~4.5 lần so với chạy tuần tự một agent (tương đương giảm 80% thời gian chạy thực tế).

3.2 Cơ chế hoạt động: Orchestrator và Sub-agents

Hệ thống hoạt động dựa trên sự phân cấp giữa Orchestrator agent và các sub-agent

Orchestrator (Tác nhân điều phối): Đây là một tác nhân có thể huấn luyện, đóng vai trò "tổng chỉ huy" để phân rã các nhiệm vụ phức tạp thành các nhiệm vụ con có thể chạy song song. Nó có khả năng tạo ra các tác nhân phụ chuyên biệt một cách linh hoạt như: Nhà nghiên cứu Toán, Nhà nghiên cứu Vật lý, ....
Sub-agents (Tác nhân phụ): Đây là các tác nhân "đóng băng" (frozen) được khởi tạo động để thực hiện các nhiệm vụ con chuyên biệt. Việc chạy song song các tác nhân này giúp giảm đáng kể độ trễ so với việc thực hiện tuần tự. Để một "đàn" (swarm) lên đến 100 agents có thể hoạt động cùng lúc mà không hỗn loạn, nó cần một cấu trúc quản lý rõ ràng. Do đó, nó cần một Orchestrator như một bộ não giúp phân rã nhiệm vụ thành các nhiệm vụ con cho các sub-agent xử lý. Sau khi phân rã nhiệm vụ thì thay vì một Agent làm xong việc này mới đến việc kia (tuần tự), Orchestrator có thể tung ra cùng lúc hàng chục hoặc tối đa 100 Sub-agents để xử lý các mảng việc khác nhau. Chính cơ chế này mang lại một số ưu điểm :
1. Giảm độ trễ cực lớn: Nhờ khả năng chạy song song (parallel execution)
2. Tối ưu hóa qua chỉ số "Critical Steps": Hệ thống không chỉ đếm tổng số bước mà tập trung vào đường đi dài nhất trong các luồng chạy song song để đảm bảo hiệu quả cao nhất
3. Tránh sự kém hiệu quả: Thông qua huấn luyện PARL, Orchestrator học cách không "đẻ" ra quá nhiều tác nhân phụ vô ích (tránh hiện tượng song song giả tạo) mà chỉ tập trung vào những gì thực sự đẩy nhanh tiến độ công việc

Tóm lại : Orchestrator là người nhạc trưởng, còn 100 tác nhân phụ là dàn nhạc. Nhạc trưởng điều phối để 100 nhạc công có thể chơi các phần khác nhau của bản nhạc cùng một lúc (song song) thay vì từng người chơi lần lượt.

3.3 Parallel-Agent Reinforcement Learning (PARL)

Là phương pháp huấn luyện cốt lõi giúp Kimi K2.5 có khả năng tự điều phối "đàn" tác nhân (agent swarm) một cách hiệu quả. Công thức tổng quát của reward trong PARL được xác định như sau: $r_{\text{PARL}}(x,y)=\lambda_1 r_{\text{parallel}}+\lambda_2 r_{\text{finish}}+r_{\text{perf}}(x,y)$

Mình sẽ giải thích ý nghĩa chi tiết từng thành phần trong công thức này:

$r_{\text{perf}}(x,y)$ - Phần thưởng hiệu suất (Task-level outcome): Đây là phần thưởng quan trọng nhất, dùng để đánh giá sự thành công và chất lượng tổng thể của giải pháp cuối cùng (y) cho một nhiệm vụ cho trước (x). Nó tập trung vào kết quả cuối cùng mà hệ thống đạt được.
$r_{\text{parallel}}$ - Phần thưởng khởi tạo (Instantiation reward): Phần này là reward cho việc tạo ra nhiều parallel agent với giá trị được $\lambda_1$ khởi tạo là 0.1 và hướng dần về 0 (lý do hướng về 0 thì mình nói ở mục 4 bên dưới nhé ). Thành phần này được đưa vào để giải quyết lỗi "serial collapse" có nghĩa là trong quá trình huấn luyện, bộ điều phối (orchestrator) thường có xu hướng quay lại cách làm việc của một tác nhân đơn lẻ (làm việc tuần tự) thay vì tận dụng khả năng chạy song song. Trong học tăng cường, đây được coi là một "điểm tối ưu cục bộ" (local optimum). Do việc nhận phản hồi từ nhiều tác nhân phụ chạy độc lập thường bị trễ và không ổn định, mô hình có xu hướng chọn cách làm việc tuần tự đơn giản để đảm bảo tính an toàn thay vì mạo hiểm điều phối song song. Giải pháp Kimi 2.5 chính là sử dụng $r_{\text{parallel}}$ để đưa thêm một tham số thưởng vào công thức để khuyến khích bộ điều phối mạnh dạn khởi tạo các tác nhân phụ và khám phá các không gian lập lịch song song.
$r_{\text{finish}}$ - Tỷ lệ hoàn thành của tác nhân phụ (Sub-agent finish rate): Phần này là reward cho sub-agent có hoàn thành task hay không nó sẽ bằng 0 nếu Agent thất bại. Thành phần này giúp ngăn chặn hiện tượng "spurious parallelism" (song song giả tạo). Để "gian lận" điểm thưởng $r_{\text{parallel}}$ , bộ điều phối có thể tạo ra vô số tác nhân phụ một cách vô nghĩa mà không thực sự chia nhỏ nhiệm vụ một cách hiệu quả. Giải pháp $r_{\text{finish}}$ sẽ chỉ trao thưởng khi các nhiệm vụ con được giao cho tác nhân phụ thực sự được hoàn thành. Điều này buộc bộ điều phối phải phân rã nhiệm vụ một cách khả thi và có ý nghĩa.
Các tham số $\lambda_1$ và $\lambda_2$ : Đây là các siêu tham số điều chỉnh trọng số của hai phần thưởng phụ ( $r_{\text{parallel}}$ và $r_{\text{finish}}$ ). Trong quá trình huấn luyện, các tham số này sẽ được giảm dần về 0. Mục đích ở giai đoạn đầu, chúng khuyến khích mô hình học cách làm việc song song. Khi mô hình đã thành thục, hệ thống sẽ tập trung hoàn toàn vào kết quả công việc cuối cùng $r_{\text{perf}}$ .

Tóm lại: $r_{\text{parallel}}$ là "đòn bẩy" để tạo ra nhiều agent (incentivizing instantiation), còn $r_{\text{finish}}$ - đóng vai trò là "bộ lọc" để đảm bảo các agent đó thực sự hoàn thành việc. Sự kết hợp của cả hai giúp tạo ra một hệ thống song song vừa mạnh mẽ vừa hiệu quả.

3.4 CriticalSteps

Critical Steps là một thước đo hiệu suất tập trung vào độ trễ (latency) hiểu đơn giản là để tính xem khi chạy parrallel thì cái sub-agent chạy lâu nhất là bao nhiêu. Thay vì chỉ đếm tổng số bước thực hiện (cách làm này không phân biệt được việc làm tuần tự hay song song), Critical Steps tính toán dựa trên khái niệm "đường tới hạn" (critical path-là chuỗi các bước dài nhất từ lúc bắt đầu đến khi kết thúc nhiệm vụ) trong tính toán song song có công thức là: $\text{CriticalSteps}=\sum_{t=1}^{T}\left(S_{\text{main}}^{(t)}+\max_i S_{\text{sub}, i}^{(t)}\right)$ Trong đó:

$S_{\text{main}}^{(t)}$ Là chi phí điều phối của tác nhân chính (orchestration overhead). Đây là những bước mà Orchestrator phải thực hiện để phân chia nhiệm vụ hoặc tổng hợp kết quả.
$max_i S_{\text{sub}, i}^{(t)}$ Đây là phần quan trọng nhất. Nó chỉ tính số bước của tác nhân phụ chạy chậm nhất trong mỗi giai đoạn thực thi song song. Theo cách tính này, nếu bộ điều phối (orchestrator) tạo ra 100 tác nhân phụ hoạt động cùng lúc, hệ thống sẽ không cộng dồn tất cả các bước của 100 tác nhân đó. Nó chỉ tính thời gian của tác nhân nào hoàn thành công việc muộn nhất trong "đàn"

3.4.1 Tại sao CriticalSteps lại quan trọng trong Agent Swarm ?

Ví dụ có 100 sub-agents chạy song song thì 99 sub-agents chạy trong 10 giây còn 1 cái chạy trong 1 tiếng lúc này nó bị bottleneck và vô nghĩa nên là đội ngũ Kimi 2.5 đề cập đến một thuật ngữ là Serial Collapse cái này mình đã nói ở phần 3.3 . Serial Collapse là một "lỗi hành vi" khi bộ điều phối (orchestrator) có năng lực chạy song song nhưng lại mặc định quay về cách làm việc tuần tự (từng bước một như tác nhân đơn lẻ). Tại sao nó xảy ra? Do việc nhận phản hồi từ các tác nhân phụ chạy độc lập thường bị trễ và không ổn định, nên mô hình chọn cách làm tuần tự cho "an toàn" .

Nhờ tối ưu hóa theo Critical Steps, Kimi K2.5 Agent Swarm có thể giảm số bước tới hạn cần thiết lên đến 4,5 lần so với khi chạy đơn tác nhân trong các tình huống tìm kiếm trên diện rộng (wide search). Điều này trực tiếp giúp giảm đến 80% thời gian chạy thực tế (wall-clock time).

Nếu $r_{\text{parallel}}$ "phần thưởng" để định hướng hành vi, thì Critical Steps lại chính là "thước đo" để ép buộc hệ thống phải làm việc nhanh hơn bằng cách tận dụng tối đa sức mạnh của 100 tác nhân chạy song song thay vì làm việc lần lượt từng bước một.

3.4.2 CriticalSteps giúp giải quyết Serial Collapse như thế nào?

Chỉ số Critical Steps cực kỳ quan trọng vì nó chuyển đổi cách đánh giá từ "tổng khối lượng công việc" sang "thời gian hoàn thành thực tế". Nếu 99 tác nhân xong trong 10 giây nhưng 1 tác nhân mất 1 giờ, thì giá trị $max_i S_{\text{sub}, i}^{(t)}$ sẽ là 1 giờ. Nó minh họa cho việc nếu không quản lý tốt "đường tới hạn" (critical path) thì việc song song hóa trở nên vô nghĩa. Lúc này Kimi 2.5 dùng thước đo Critical Steps để phạt hành vi Serial Collapse, từ đó buộc mô hình phải học cách lãnh đạo 100 tác nhân sao cho critical path là ngắn nhất có thể. Cơ chế phạt của Critical Steps lúc này thay vì đếm tổng số bước thực hiện, hệ thống sử dụng thước đo Critical Steps. Nếu bộ điều phối (orchestrator) chọn làm việc tuần tự, mỗi bước đi sẽ được cộng dồn trực tiếp vào tổng thời gian, khiến "chi phí" về bước tới hạn tăng vọt. Hậu quả việc thực thi tuần tự trở nên không khả thi (impractical) vì nó tạo ra một con số Critical Steps rất cao. Điều này ép buộc mô hình phải tìm cách chạy song song để "ép" con số này xuống thấp nhất có thể.

4. Strands Agent SDK

Strands Agents là một agent framework được thiết kế trong hệ sinh thái AWS. Là một SDK mã nguồn mở tiếp cận theo hướng model-driven (dẫn dắt bởi mô hình), được thiết kế để tối ưu hóa việc xây dựng và vận hành AI agent trên hạ tầng cloud, đặc biệt là các môi trường serverless như AWS Lambda. Điểm khác biệt của Strands Agent so với các framework agent khác đó là tối ưu hóa cho hệ sinh thái AWS và Lambda:

Phân tách trách nhiệm (Separation of Concerns): Strands cho phép tách biệt môi trường chạy vòng lặp agent (agentic loop) và môi trường thực thi công cụ (tool execution). Bạn có thể vận hành agent trong một container và để nó gọi các công cụ được đóng gói dưới dạng các AWS Lambda functions riêng biệt qua API.
Kiến trúc linh hoạt: SDK cung cấp các bản tham chiếu triển khai chính thức cho AWS Lambda, giúp hiện thực hóa các agent phản ứng theo sự kiện (event-triggered agents) hoặc microservices một cách dễ dàng

4.1 Xây dựng Orchestrator Agent với Swarm Agent bằng Strands

Mình sẽ hướng dẫn cách tạo Agent với Strands:

Đầu tiên là install strands sdk bằng : pip install strands-agents

rồi khởi tạo Agent như code bên dưới của mình là được cũng khá là dễ nên mình không nói gì thêm nhé, như vậy là bạn đã tạo được 1 agent với Strands rồi :

4.1.2 Orchestrator Agents vs Swarm Agent

Trong lĩnh vực phát triển hệ thống trí tuệ nhân tạo (AI) hiện đại, việc chuyển dịch từ các mô hình đơn lẻ sang các hệ thống đa tác vụ (multi-agent systems) là một xu thế tất yếu nhằm giải quyết các bài toán phức tạp. Hai mô hình kiến trúc nổi bật được hỗ trợ bởi Strands Agents SDK là Agents as Tools (AaT) và Swarm. MÌnh sẽ phân tích chi tiết về bản chất kỹ thuật, cơ chế vận hành và sự khác biệt cốt lõi giữa hai phương pháp này.

Kiến trúc Agents as Tools (Orchestrator-Agent): Kiến trúc Phân cấp và Điều phối

"Agents as Tools" dựa trên nguyên lý cấu trúc phân cấp, trong đó các tác vụ chuyên biệt được đóng gói dưới dạng các hàm có thể gọi (tools).
Nguyên lý vận hành: Hệ thống bao gồm một "tác vụ điều phối" (orchestrator agent) đóng vai trò trung tâm, chịu trách nhiệm tương tác với người dùng và quyết định khi nào cần triệu gọi các "tác vụ công cụ" (tool agents) chuyên biệt. Quá trình này được thực hiện thông qua decorator @tool, cho phép biến một tác vụ hoàn chỉnh thành một công cụ chức năng
Nguyên tắc cốt lõi: Kiến trúc này tập trung vào việc chia tách các mối quan tâm (separation of concerns), trong đó mỗi tác vụ chỉ tập trung vào một phạm vi chuyên môn hẹp, giúp hệ thống dễ bảo trì và mở rộng. Nhìn đơn giản như hình minh hoạ bên trên thì Orchestrator sẽ quyết định agent nào (tool) nào đảm nhận việc response output về cho user, các agent (tool) này riêng biệt không có sự tương hỗ cho nhau đây chính là sự khác biệt so với kiến trúc Swarm agent.

Kiến trúc Swarm Agent: Sự cộng tác và Trí tuệ tập thể

Ngược lại với cấu trúc phân cấp, Swarm là một hệ thống điều phối cộng tác, nơi nhiều tác vụ làm việc cùng nhau như một đội ngũ để giải quyết vấn đề mà không cần một sự kiểm soát trung tâm tuyệt đối.
Nguyên lý vận hành: Swarm hoạt động dựa trên nguyên lý thay vì bị điều khiển bởi một orchestrator, các tác vụ trong Swarm tự điều phối thông qua cơ chế "bàn giao" (handoff). Mỗi tác vụ có quyền tự quyết định khi nào cần chuyển giao công việc cho một tác vụ khác có chuyên môn phù hợp hơn.
Bộ nhớ chung và ngữ cảnh chia sẻ: Một đặc điểm quan trọng của Swarm là khả năng truy cập vào ngữ cảnh nhiệm vụ đầy đủ và bộ nhớ làm việc chung. Điều này bao gồm lịch sử các tác vụ đã thực hiện, kiến thức được đóng góp bởi các thành viên trước đó và danh sách các tác vụ sẵn có để cộng tác.
Cơ chế an toàn: Để đảm bảo tính ổn định, Swarm tích hợp các cơ chế như giới hạn số lần bàn giao tối đa (max handoffs), thời gian chờ (timeouts) và phát hiện bàn giao lặp lại (repetitive handoff detection) để tránh các vòng lặp vô hạn.

4.1.3 So Sánh Orchestrator Agents (Agent as tools) với Swarm Agent

Đặc Tính	Agent as Tools	Swarm
Kiến trúc	Phân cấp (Hierarchical)	Cộng tác/Ngang hàng (Collaborative/Peer-to-peer)
Quyền kiểm soát	Tập trung vào Orchestrator	Tự trị và phi tập trung
Cơ chế tương tác	Gọi thông qua công cụ (tools)	Bàn giao (Handoff) dựa trên sự tự nguyện
Quản lý trạng thái	Trạng thái thường được cô lập hoặc trả về cho orchestrator	Chia sẻ ngữ cảnh (Shared Context) và trạng thái (Shared State) xuyên suốt
Khả năng phối hợp	Theo quy trình được lập trình sẵn hoặc hướng dẫn bởi hệ thống	Linh hoạt, tùy biến theo diễn biến thực tế của nhiệm vụ

1. Kết luận và Ứng dụng thực tiễn

Việc lựa chọn giữa Agents as Tools và Swarm phụ thuộc vào bản chất của bài toán cần giải quyết.
Mô hình Agents as Tools phù hợp cho các quy trình có cấu trúc rõ ràng, nơi cần một sự kiểm soát chặt chẽ từ phía tác vụ điều phối để đảm bảo tính nhất quán của kết quả cuối cùng. Ví dụ: Một hệ thống chăm sóc khách hàng cần phân loại yêu cầu vào các phòng ban cụ thể.
Mô hình Swarm ưu việt hơn trong các kịch bản đòi hỏi sự linh hoạt cao, giải quyết các vấn đề đa ngành phức tạp mà một luồng thực thi tuyến tính không thể bao quát hết. Ví dụ: Một quy trình thiết kế hệ thống bao gồm nghiên cứu, kiến trúc, lập trình và kiểm thử, nơi các chuyên gia cần trao đổi qua lại liên tục.

2. Demo

Mình đã thử làm một Chatbot system về tư vấn tâm lý bằng cả 2 Kiến trúc Agent as Tool và Swarm thì mình thấy Swarm đã cho độ hiệu quả hơn hẳn việc sử dụng 1 Orchestrator điều phối. Với version dùng Agent as Tool mình sử dụng 1 Orchestrator đóng vai trò quyết định với mỗi user input nào thì nên chọn phương pháp điều trị nào. Ví dụ khi user nhập vào một câu có tính chất đang âm thầm chịu đựng hoặc cố gắng một mình thì sử dụng Recognition agent, khi user tự trách hoặc cảm thấy mình “không bình thường” thì dùng Normalizing agent, ... ( Recognition, Normalizing, Psyeducation đây là cách kỹ thuật dùng trong tư vấn tâm lý nhé mình sẽ không đi sâu vào cái này).

Vậy vấn đề ở đây là nếu gặp phải một câu input có 2 ý vừa là tự trách bản thân vừa là đang âm thầm chịu đựng thì Orchestrator sẽ chỉ chọn 1 Agent tool là Normalizing hoặc Recognition lúc này bài toán của mình sẽ bị sai và không còn tính đúng đắn trong y khoa. Hơn nữa một bác sĩ tâm lý là phải kết hợp các kĩ thuật khác nhau để trả lời bệnh nhân mới cho kết quả tối nhất. Lúc này Swarm chính là cứu cánh cho bài toán của mình, mình cần một Chatbot có nhiều góc nhìn/chuyên môn và Cần tổng hợp thông tin từ các agent khác nhau. Dưới đây là mô hình hoá flow tương tác giữa các Agent technique trị liệu sau khi dùng Swarm, hình hơi mờ nhưng các bạn có thể hiển là giờ đây các Agent technique trị liệu của mình đã tương tác giao tiếp với nhau rồi cho ra output.

2.1 Output của Kiến trúc Agent as Tool

Ở lần chat đầu tiên và thứ hai khi chat "i feel sad", Orchestrator đều chọn cho mình Undersanding Agent ( agent này để thấu hiểu và thông cảm với bệnh nhân). Ở lần cuối khi mình chat "how can i feel better and overcome this burden ?" thì lúc này Orchestrator đã chọn cho mình Providing solutions Agent ( agent này đưa ra giải pháp giải quyết vấn đề). Tuy việc chọn các Agent technique trị liệu này là đúng nhưng mà có thể thấy các câu response đều thật sự chưa đủ giống một bác sĩ tư vấn tâm lý thực thụ.

2.2 Output của Kiến trúc Swarm Agent

Mình lười code lại UI cho đồng nhất quá với cả viết đến đây mình cũng muốn buông bàn phím lắm rồi 😪 nên các bạn xem tạm nhé Khác biệt rõ ràng so với lần response thứ hai khi dùng kiến trúc Swarm đó chính là ngay ở step thứ 2 đã sử dụng cả Understanding và Recognition Agent. Và hơn hết các câu văn đã trở thật và giống người hơn hẳn so với khi dùng Agent as Tool.

Tóm lại: Việc sử dụng kiến trúc nào khá quan trọng khi các bạn làm chatbot không phải lúc nào Swarm cũng tốt nhất, cũng không phải lúc nào Orchestrator Agent cũng là đúng với system của bạn, mình viết bài này để cho các bạn có thêm một góc nhìn mới khi xây dựng Chatbot system.

5. Tham khảo