Agent tự tiến hóa: chọn khi nào?

Agent tự tiến hóa: chọn khi nào?

Agent biết tái dùng skill nghe hấp dẫn, nhưng production chỉ đáng tin khi bạn quyết định rõ orchestration, guardrail và cách đo lỗi.

Ở nhiều team Việt Nam, cuộc họp chọn kiến trúc agent thường bắt đầu rất tỉnh: cần tự động hóa một quy trình lặp lại. Mười lăm phút sau, cả phòng đã trôi vào vùng áp thấp của những từ như MCP, self-evolving, skill registry, benchmark, lineage. Ai cũng gật, nhưng Jira vẫn chưa có ticket nào ghi rõ: nếu agent làm sai thì chặn ở đâu?

Mình muốn kéo câu chuyện về một quyết định cụ thể hơn: đừng hỏi agent có tự tiến hóa được không; hãy hỏi phần nào của hệ thống được phép tiến hóa, phần nào phải đóng băng.

OpenSpace là một ví dụ đáng mổ theo hướng đó. Workflow của nó xoay quanh việc agent chạy task, rút ra skill, lưu lại phiên bản và lineage trong SQLite, rồi tái dùng cho task gần giống. Kết hợp thêm MCP để phơi capability ra cho host agent, bạn có một mô hình khá hấp dẫn: agent không chỉ làm việc, mà còn tích lũy cách làm.

Nhưng trong production, tích lũy không kiểm soát là sương mù. Nhìn xa thì hay, đến lúc debug mới biết mình đang đứng ở đâu.

Sơ đồ minh họa cho bài Agent tự tiến hóa: chọn khi nào?

Sơ đồ tóm tắt ý chính của bài viết.

Quyết định đầu tiên: cho agent học skill hay chỉ dùng tool?

Dịch sang tiếng người: skill là một gói hướng dẫn có cấu trúc, thường là Markdown, mô tả quy trình, luật dùng tool, format output và lỗi hay gặp. Nó giống như sổ tay thao tác của agent, nhưng nằm ngoài model weights nên sửa được nhanh hơn fine-tuning.

Bạn thường có ba lựa chọn:

| Lựa chọn | Khi nào hợp | Rủi ro chính |
|---|---|---|
| Chỉ prompt + tool calling | Task đơn giản, ít biến thể | Prompt phình to, khó version |
| Skill viết tay | Quy trình ổn định, domain rõ | Dễ lỗi thời nếu không có feedback loop |
| Skill tự tiến hóa | Task lặp lại nhiều, có log và eval | Agent học nhầm nếu guardrail yếu |

Tool calling là khả năng model gọi API hoặc công cụ thay vì chỉ trả lời bằng chữ. Còn skill tự tiến hóa là khi hệ thống phân tích lần chạy trước để tạo, sửa hoặc dẫn xuất hướng dẫn mới cho lần sau.

Hình dung thế này: team bạn có agent tạo báo cáo payroll từ CSV. Lần đầu nó học được quy trình đọc cột, chuẩn hóa tên nhân sự, tính tổng và xuất Markdown. Lần sau gặp file payroll hơi khác, nó không bắt đầu từ số không mà tái dùng skill cũ, hoặc tạo skill dẫn xuất cho biến thể mới.

Nghe rất hợp lý. Nhưng câu hỏi production là: ai duyệt skill mới trước khi nó ảnh hưởng đến user thật?

Khung chọn nhanh: 3 lớp phải tách ra

Nếu là mình, mình sẽ không build agent tự tiến hóa như một khối liền. Mình tách thành ba lớp, mỗi lớp có quyền khác nhau.

1. Execution layer: nơi agent làm việc

Đây là lớp chạy task thật: đọc file, gọi API, tạo report, cập nhật ticket. Ở đây cần orchestration — cách điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành một việc.

Quy tắc của mình: execution layer chỉ được dùng skill đã được phê duyệt. Không tự ý lấy skill vừa sinh ra để chạy tiếp trên dữ liệu quan trọng.

2. Evolution layer: nơi agent đề xuất thay đổi

Lớp này đọc log, so lỗi, phát hiện pattern, rồi đề xuất skill mới hoặc sửa skill cũ. OpenSpace gợi ý một hướng thú vị khi lưu skill cùng version và lineage — dấu vết nguồn gốc cho biết skill này sinh từ đâu, dẫn xuất từ phiên bản nào.

Lineage không phải trang trí. Nó là thứ giúp bạn trả lời câu đau đầu nhất khi có incident: thay đổi nào làm kết quả lệch?

3. Approval layer: nơi con người hoặc eval quyết định

Đây là lớp nhiều demo hay bỏ qua. Skill mới không nên được promote chỉ vì agent thấy mình làm tốt. Cần evaluation harness — bộ kiểm thử có kịch bản, input, expected behavior và tiêu chí pass/fail.

Bài toán không phải làm agent thông minh hơn bằng mọi giá. Bài toán là giữ tâm bão nằm trong vùng quan sát được.

Làm trong một buổi: bản nháp có kiểm soát

Bạn không cần dựng cả platform để thử ý tưởng này. Một buổi chiều là đủ để biết team có nên đi tiếp hay không.

Bước 1: chọn một task lặp lại nhưng không nguy hiểm

Đừng bắt đầu bằng thanh toán, xóa dữ liệu, gửi email hàng loạt. Chọn task như:

Điều kiện chọn task: có input mẫu, có output mong muốn, và có thể kiểm tra sai đúng tương đối rõ.

Bước 2: định nghĩa skill như artifact, không phải prompt rơi vãi

Tạo một file SKILL.md tối thiểu:

# csv_report_skill

## Khi dùng
Dùng khi input là file CSV và yêu cầu là báo cáo Markdown có số liệu tổng hợp.

## Quy trình
1. Kiểm tra header bắt buộc.
2. Chuẩn hóa tên cột về snake_case.
3. Tính tổng, trung bình, ngoại lệ.
4. Xuất báo cáo theo format bên dưới.

## Không được làm
- Không tự suy đoán cột bị thiếu.
- Không ghi kết luận nếu dữ liệu không đủ.

## Output format
- Summary
- Key numbers
- Anomalies
- Questions for human

Điểm quan trọng: skill phải có phần không được làm. Nhiều team chỉ viết đường nắng, quên dự báo mưa.

Bước 3: lưu version và lineage ngay từ đầu

Dù dùng SQLite, Postgres hay file JSON, hãy lưu tối thiểu:

CREATE TABLE skills (
  id TEXT PRIMARY KEY,
  name TEXT,
  version INTEGER,
  parent_id TEXT,
  status TEXT,
  created_from_task TEXT,
  eval_score TEXT,
  content TEXT,
  created_at TEXT
);

status nên có các trạng thái như draft, candidate, approved, retired. Đừng để mọi skill vừa sinh ra đã được dùng như production config.

Bước 4: chạy warm-task reuse có kiểm thử

Warm-task reuse là tái dùng năng lực đã học cho task gần giống, thay vì chạy như lần đầu. Đây là chỗ tiết kiệm chi phí và giảm độ trễ có thể xuất hiện, nhưng chỉ đáng tin nếu bạn đo được.

Tạo 10 input mẫu. Chạy một vòng bằng skill gốc. Sau đó cho evolution layer đề xuất sửa. Chỉ promote nếu bản mới qua test tốt hơn hoặc ít nhất không phá các case cũ.

Ví dụ cụ thể: giả sử team bạn có 10 file CSV từ 10 khách hàng. Skill mới xử lý tốt file khách hàng A vì thêm alias cho cột employee_id, nhưng làm hỏng file khách hàng B vì đổi nhầm gross_pay. Nếu không có regression test, bạn sẽ gọi đó là cải tiến cho đến khi khách hàng B nhắn Slack lúc 6 giờ tối.

Bước 5: nếu dùng MCP, giới hạn capability

MCP là giao thức để agent kết nối với tool và tài nguyên bên ngoài theo cách chuẩn hóa hơn. Khi phơi skill qua MCP server, đừng đưa cả kho tool cho agent.

Một cấu hình hợp lý nên ghi rõ:

agent: payroll_reporter
allowed_skills:
  - csv_report_skill:v3
allowed_tools:
  - read_workspace_file
  - write_markdown_report
blocked_tools:
  - send_email
  - update_database
approval_required:
  - new_skill
  - derived_skill
  - external_api_call

Mục tiêu không phải làm agent bị trói tay. Mục tiêu là biết nó đang được phép làm gì khi trời chuyển gió.

Bẫy production: benchmark không thay cho quan sát thật

EdgeBench và các hướng benchmark agent rất hữu ích vì chúng ép mình nhìn agent theo task, runtime, budget tương tác và cơ chế chấm điểm. Nhưng leaderboard chỉ trả lời một phần: agent có thể làm tốt trong bài thi nào đó.

Production cần thêm câu hỏi khác:

Các case agent trong môi trường có tiền thật, như trade assistant hoặc search agent cho marketplace, đều nhắc mình một chuyện: đánh giá agent không phải bước cuối. Nó là đường ống chạy song song với sản phẩm.

Với builder, mình sẽ đặt tối thiểu ba guardrail:

  1. Input guardrail: chặn dữ liệu thiếu schema, file quá lớn, quyền truy cập sai.
  2. Action guardrail: giới hạn tool theo role, task và trạng thái skill.
  3. Output guardrail: kiểm tra format, nguồn dữ liệu, câu kết luận và confidence trước khi trả cho user.

Guardrail ở đây là rào kiểm soát hành vi, không phải một prompt nhắc agent ngoan hơn.

Ai nên dùng, ai nên bỏ qua?

Nên thử hướng skill tự tiến hóa nếu bạn có đủ bốn điều kiện:

Nên bỏ qua, hoặc chỉ dùng skill viết tay, nếu:

Điều kiện đổi quyết định rất rõ: khi số lượng task cùng họ tăng lên, lỗi lặp lại xuất hiện, và bạn đã có regression set đủ đại diện, lúc đó self-evolving skill mới đáng đưa vào backlog nghiêm túc.

Sau bài này, mình mong bạn đổi một cách nghĩ: agent tự tiến hóa không phải tính năng để bật, mà là một quy trình release artifact mới. Skill cũng cần version, review, eval, rollout và rollback như code.

Còn nếu ai đó bảo cứ để agent học dần rồi hệ thống sẽ tự tốt lên, mình chỉ xin hỏi nhẹ: bạn đã chuẩn bị áo mưa cho production chưa?

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo