# Mastra: khi nào FDE nên chọn framework agent TypeScript có sẵn workflow, bộ nhớ và eval

> Nếu đội khách hàng viết TypeScript và sẽ tự bảo trì hệ thống sau khi bạn rời đi, Mastra cho bạn workflow có điểm dừng chờ người duyệt, bộ nhớ nhiều lớp và bộ chấm điểm chạy ngay trên production, tất cả trong cùng một codebase.

Bản gốc: https://fdetimes.net/vi/cong-cu/mastra-agent-typescript-workflow-memory-eval/

Backend của khách hàng chạy Node và TypeScript. Đội của họ sẽ tiếp quản hệ thống agent ngay khi bạn rời site. Lúc đó, câu hỏi chọn framework nào không còn là chuyện sở thích: nó quyết định ai sửa được code sáu tháng sau.

Mastra là một ứng viên đáng xét cho đúng tình huống này. Tài liệu chính thức định nghĩa nó là framework TypeScript để xây agent và ứng dụng AI. Repo chính thức gom vào một chỗ agent, workflow, bộ nhớ, eval và MCP.

Đứng sau là đội từng làm Gatsby, với ba đồng sáng lập Sam Bhagwat (CEO), Shane Thomas và Abhi Aiyer, khởi nghiệp năm 2024. Với bạn, câu hỏi đáng hỏi không phải Mastra có tốt hay không, mà là khi nào nó là lựa chọn đúng ở site khách hàng và phải học gì để dùng được ngay ngày đầu.

## Chọn theo người sẽ bảo trì, không theo bản demo

Một deployment chỉ thành công khi đội khách hàng còn sửa được nó sau khi bạn rời đi. Nếu backend của họ là TypeScript, đem vào một service Python để chạy agent nghĩa là thêm một runtime, một pipeline deploy và một nhóm người phải học thêm ngôn ngữ. Mastra tránh được chi phí đó vì agent nằm chung ngôn ngữ, chung repo với phần còn lại.

Lý do thứ hai là Mastra đã có sẵn bốn thứ mà một engagement agent thường phải tự dựng: điều phối các bước, nhớ người dùng, kết nối công cụ qua MCP, và chấm chất lượng đầu ra.

Tự ghép bốn thứ này từ bốn thư viện thì phần lớn thời gian onsite sẽ đi vào việc nối dây. Ngược lại, nếu đội khách hàng thuần Python, lợi thế này gần như mất hết, và bạn nên cân nhắc lại.

**Điểm mấu chốt:** Chọn framework theo ngôn ngữ của đội sẽ bảo trì hệ thống, không theo bản demo đẹp nhất.

## Workflow hay agent: ranh giới nằm ở đâu?

Tài liệu Mastra nói rõ: dùng workflow khi nhiệm vụ đã xác định từ đầu, có nhiều bước và phải chạy theo thứ tự cụ thể. Workflow chạy trên một engine dạng đồ thị, và mỗi lần chạy có sẵn khả năng tạm dừng, chạy tiếp và stream kết quả. Phần nào còn mơ hồ, cần model tự chọn bước tiếp theo, thì mới để agent xử lý.

Ranh giới này quan trọng với FDE khi khách hàng muốn biết bước nào chạy trước, bước nào cần người ký duyệt. Tính năng tạm dừng và chạy tiếp chính là chỗ để đặt người duyệt vào luồng mà không phải tự viết state machine.

## Thử hình dung một luồng hoàn tiền có người duyệt

Giả sử khách hàng là một công ty bán lẻ muốn tự động xử lý yêu cầu hoàn tiền. Bạn dựng một workflow bốn bước: phân loại yêu cầu, tra đơn hàng, quyết định, rồi soạn trả lời. Ở bước quyết định, nếu số tiền vượt ngưỡng do khách hàng đặt, workflow tạm dừng và chờ nhân viên bấm duyệt rồi mới chạy tiếp.

Phác thảo dưới đây chỉ minh hoạ logic của bước đó và một scorer đi kèm. Đây là giả mã, không phải cú pháp chính xác; hãy đối chiếu tên hàm thật trong tài liệu Mastra v1.

```ts
// Giả mã: minh hoạ logic, không phải API chính xác của Mastra v1
const decide = step(async ({ refund, suspend, resumeData }) => {
  if (refund.amount > APPROVAL_THRESHOLD && !resumeData) {
    // Run dừng ở đây cho tới khi nhân viên duyệt và resume
    return suspend({ orderId: refund.orderId, reason: "needs_approval" });
  }
  return { approved: resumeData ? resumeData.approved : true };
});

// Scorer dựa trên luật: câu trả lời có nhắc đúng mã đơn không
const mentionsOrderId = (output, refund) =>
  output.includes(refund.orderId) ? 1 : 0;
```

Lỗi hay gặp là nhét cả phần cần phán đoán vào chuỗi if-else cố định của workflow, chẳng hạn quyết định một lý do hoàn tiền mơ hồ có hợp lệ không. Theo đúng ranh giới tài liệu vạch ra, phần đó nên giao cho agent, còn workflow chỉ giữ các bước có thứ tự rõ và điểm dừng chờ duyệt.

Trộn hai thứ vào nhau, bạn sẽ có một workflow phình ra theo từng ngoại lệ mà khách hàng kể thêm. Việc đầu tiên nên làm ở site là ngồi với đội vận hành, vẽ các bước trên bảng trắng, đánh dấu bước bắt buộc có người duyệt và bước cần phán đoán. Bản vẽ đó gần như là bản thiết kế workflow.

## Agent nhớ gì, và nhớ ở lớp nào?

Bộ nhớ của Mastra có nhiều lớp, và luồng hoàn tiền cần cả ba. Message history giữ N tin nhắn gần nhất của cuộc hội thoại, đủ để agent không hỏi lại mã đơn vừa được đưa.

Working memory lưu dữ liệu có cấu trúc, bền vững về người dùng, như tên, sở thích, mục tiêu. Nhờ đó agent nhớ khách này muốn nhận tiền về thẻ chứ không phải ví, kể cả ở cuộc hội thoại sau.

Semantic recall truy lại tin nhắn cũ theo nghĩa thay vì từ khóa. Một câu như "lần trước giao sai màu" vẫn tìm ra khiếu nại tháng trước dù người dùng không dùng lại đúng chữ.

Sai lầm dễ mắc nhất là dồn mọi thứ vào một lớp. Nhét sở thích của khách vào message history thì chúng trôi mất khi cuộc hội thoại dài ra; trông cậy vào semantic recall cho dữ liệu có cấu trúc như phương thức nhận tiền thì kết quả phụ thuộc vào việc tìm theo nghĩa có trúng hay không.

Hãy quyết định trước: thông tin nào là hồ sơ cố định, thông tin nào chỉ là ngữ cảnh.

## Chấm điểm trước khi khách hàng chấm

Eval trong Mastra gọi là scorer: những bài test tự động chấm đầu ra của agent bằng ba cách, do model chấm, dựa trên luật, và dựa trên thống kê. Với luồng hoàn tiền, scorer dựa trên luật như trong phác thảo trên kiểm tra mã đơn. Một scorer do model chấm thì đánh giá giọng văn có lịch sự và đúng chính sách không.

Scorer chạy được ở hai chỗ. Trong CI/CD, chúng biến thành bài kiểm tra hồi quy: mỗi lần sửa prompt, bạn chạy lại trên một bộ hội thoại mẫu và chặn merge nếu điểm tụt. Trên production, chúng chạy live ở chế độ nền có lấy mẫu, không chặn câu trả lời của agent hay việc thực thi workflow.

Chính chế độ live là thứ giúp bạn có số liệu khi khách hàng hỏi agent tuần này có tệ hơn tuần trước không. Hãy thống nhất với họ hai hoặc ba scorer ngay từ tuần đầu, trước khi có ai phàn nàn.

## Giới hạn cần nói trước với khách hàng

Giấy phép của Mastra có hai lớp. Phần lõi theo Apache 2.0, còn code trong các thư mục ee/ theo Mastra Enterprise License, loại source-available. Pháp chế của khách hàng có thể hỏi chuyện này, nên hãy kiểm tra trước xem tính năng bạn định dùng nằm ở đâu.

Mốc phiên bản cũng có hệ quả thực tế. Mastra v1 ra mắt tháng 1/2026, tài liệu khuyên dự án mới bắt đầu thẳng trên v1 và có hẳn một mục hướng dẫn nâng cấp. Vì thế các bài hướng dẫn hay code mẫu viết trước mốc này có thể không còn khớp; khi tra cứu, ưu tiên tài liệu chính thức của v1.

## Học theo thứ tự nào, và tự kiểm tra ra sao?

Thứ tự hợp lý là đi theo luồng ví dụ ở trên. Bắt đầu với một workflow có bước tạm dừng chờ duyệt, vì đó là chỗ suspend/resume thể hiện rõ giá trị nhất khi khách hàng muốn giữ quyền ký duyệt. Sau đó thêm working memory cho một agent, rồi cuối cùng nối scorer vào CI.

Bài tập cuối: dựng lại luồng hoàn tiền với ngưỡng duyệt tuỳ chọn, lưu phương thức nhận tiền vào working memory, rồi viết một scorer dựa trên luật kiểm tra mã đơn. Đạt yêu cầu khi một yêu cầu vượt ngưỡng dừng lại đúng chỗ, chạy tiếp sau khi duyệt, và scorer trong CI báo đỏ nếu bạn cố tình xoá mã đơn khỏi câu trả lời.

Về mặt nghề nghiệp, một repo nhỏ thể hiện đủ ba thứ trên có sức nặng hơn nhiều so với một chatbot demo. Trên CV, hãy viết theo kết quả, ví dụ "thiết kế workflow agent TypeScript có bước duyệt thủ công, scorer chạy trong CI chặn hồi quy chất lượng".

Framework sẽ còn thay đổi, nhưng cách làm thì giữ được: tách phần có quy trình khỏi phần cần model suy luận, đặt người duyệt đúng chỗ, và đo chất lượng trước khi khách hàng phải đo hộ bạn.

**Thử ngay tuần này:**

- Dựng một workflow Mastra v1 gồm ba bước, trong đó bước thứ hai tạm dừng chờ người duyệt rồi chạy tiếp
- Viết hai scorer cho một agent mẫu, một scorer dựa trên luật và một scorer do model chấm, rồi chạy chúng trong CI trên 20 hội thoại mẫu
- Mở repo mastra-ai/mastra, liệt kê các thư mục ee/ và đối chiếu với các tính năng bạn định dùng

## Nguồn

- [Mastra Docs](https://mastra.ai/docs)

- [mastra-ai/mastra (GitHub)](https://github.com/mastra-ai/mastra)

- [Workflows | Mastra Docs](https://mastra.ai/docs/workflows/overview)

- [Memory | Mastra Docs](https://mastra.ai/docs/memory/overview)

- [Evals | Mastra Docs](https://mastra.ai/docs/evals/overview)

- [About | Mastra](https://mastra.ai/about)

- [Upgrade to Mastra v1](https://mastra.ai/reference/migrations/upgrade-to-v1/overview)