Agent học skill: tín hiệu không nằm ở lệnh /learn

Agent học skill: tín hiệu không nằm ở lệnh /learn

Hermes Agent có /learn, Fugu giấu orchestration sau một endpoint, FAPO tối ưu theo lỗi từng bước. Tín hiệu thật: agent production đang chuyển từ demo sang kỷ luật vận hành.

Có một kiểu demo agent rất dễ làm mình tỉnh ngủ: bạn gõ một lệnh, agent đọc tài liệu, tự viết lại workflow thành skill, rồi lần sau gọi bằng slash command như /plan hay /axolotl. Đẹp. Gọn. Rất dễ khiến cả team Slack reo lên: “Vậy từ nay khỏi viết hướng dẫn nội bộ nữa hả?”

Khoan đã. Tín hiệu thú vị không phải là Hermes Agent có thêm /learn. Tín hiệu nằm ở chỗ thị trường agent đang lùi dần khỏi câu chuyện “model nào thông minh hơn” để tiến vào câu hỏi khó chịu hơn: workflow nào được phép bén rễ trong hệ thống production, ai kiểm soát nó, và khi nó sai thì lần theo dấu kiểu gì?

Nói thẳng ra thì: agent chỉ đáng tin khi orchestration và guardrail rõ ràng. Còn agent biết tự học skill mà không có ranh giới vận hành thì giống gieo hạt rất nhanh trên một mảnh đất chưa kiểm tra độ ẩm — nhìn xanh lúc đầu, nhưng mùa sau mới biết có ăn được không.

Sơ đồ minh họa cho bài Agent học skill: tín hiệu không nằm ở lệnh /learn

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

Tín hiệu lạ: skill đang trở thành đơn vị vận hành

Hermes Agent thêm /learn: bạn đưa cho agent một trang tài liệu, SDK local, thư mục code, PDF, config, hoặc đoạn hội thoại cũ; agent đọc bằng các tool sẵn có rồi viết ra một SKILL.md. Trong hệ Hermes, skill là tài liệu hướng dẫn được nạp khi cần, không phải ký ức luôn nằm trong context. Mỗi skill nằm trong ~/.hermes/skills/, và mỗi skill được biến thành slash command.

Điểm này nhỏ mà không nhỏ.

Trước đây, nhiều team xây agent theo kiểu nhồi prompt dài: “khi gặp việc A thì làm B, nhớ kiểm tra C, nếu lỗi thì thử D”. Càng nhiều workflow, prompt càng phình. Context window — vùng ngữ cảnh model còn giữ được trong một lượt xử lý — bị chiếm bởi quá nhiều chỉ dẫn không phải lúc nào cũng cần.

Hermes đi theo hướng khác: workflow được đóng gói thành skill, chỉ nạp khi có liên quan. Đây là progressive disclosure — mở dần thông tin theo nhu cầu. Trong đời thường, nó giống việc bạn không bê cả kho hạt giống ra ruộng mỗi sáng; hôm nay trồng gì thì mang đúng túi hạt đó.

Nhưng thị trường không chỉ có Hermes. Sakana Fugu lại đẩy một tín hiệu khác: orchestration được giấu sau một API tương thích OpenAI. Bạn gọi một endpoint, bên trong hệ thống tự route task qua nhiều model. Cisco FAPO thì nhìn pipeline LLM như một chuỗi bước có thể gán lỗi: sai ở prompt, tham số, hay cấu trúc chain. LlamaIndex với LiteParse nhấn vào hướng eval, trace, rồi cải thiện skill dựa trên hành vi thật của agent.

Bốn mảnh ghép này nói cùng một chuyện: agent production đang cần lớp điều phối, skill, eval và trace như hạ tầng hạng nhất, không còn là phụ kiện sau demo.

Mổ xẻ: /learn tiện, nhưng cũng đổi incentive

Một lệnh tự tạo skill nghe như giảm việc tay chân. Đúng. Nhưng với builder, câu hỏi nên là: nó làm thay việc gì, và nó khiến rủi ro nào dễ bị bỏ qua?

/learn loại bỏ bước viết SKILL.md thủ công. Agent đọc nguồn, tóm lại thành chuẩn nội bộ, giữ mô tả ngắn, không bịa command không tồn tại, rồi lưu thành skill. Đây là thay đổi incentive rất rõ: việc tạo workflow tái sử dụng trở nên rẻ hơn.

Khi chi phí tạo skill giảm, team sẽ tạo nhiều skill hơn. Khi có nhiều skill hơn, vấn đề chuyển từ “làm sao viết skill” sang “làm sao quản skill”.

Với team Việt Nam quy mô 5-15 dev, đây là chỗ dễ trượt. Một bạn dev vừa fix xong quy trình deploy, bảo agent /learn từ đoạn chat debug hôm qua. Một bạn khác tạo skill cho review PR. Bạn tech lead thêm skill phân tích log. Sau vài tuần, thư mục skill nhìn rất chăm chỉ, nhưng không ai chắc skill nào còn đúng, skill nào gọi tool quá rộng, skill nào đụng policy khách hàng.

Hình dung thế này: team bạn có agent hỗ trợ xử lý ticket production. Một skill mới học từ tài liệu nội bộ cũ nói rằng khi gặp lỗi thanh toán thì chạy script A. Nhưng tuần trước script A đã bị thay bằng job B có bước xác nhận rollback. Nếu skill không có versioning, eval, hoặc owner, agent có thể làm đúng theo tài liệu sai. Lúc đó vấn đề không phải model kém, mà là đất trồng workflow bị lẫn hạt cũ.

Điều đáng giữ: framework “S-G-O-T” cho agent builder

Mình sẽ không nhìn /learn như một tính năng riêng lẻ. Mình nhìn nó như lời nhắc để team thiết kế lại vòng đời skill. Một framework gọn cho builder là S-G-O-T: Skill, Guardrail, Orchestration, Trace.

| Lớp | Câu hỏi cần chốt | Nếu bỏ qua sẽ ra sao |
|---|---|---|
| Skill | Workflow nào được đóng gói, ai là owner, nguồn nào đáng tin? | Skill mọc nhiều nhưng không ai dám xóa |
| Guardrail | Skill được phép gọi tool nào, đọc thư mục nào, ghi file nào? | Agent “làm đúng việc” nhưng vượt quyền |
| Orchestration | Khi nào gọi skill, khi nào route model, khi nào dừng? | Pipeline chạy lòng vòng, khó kiểm soát chi phí |
| Trace | Mỗi lần chạy lưu input, tool call, quyết định, output ở đâu? | Lỗi production thành buổi bói log tập thể |

Ở đây có vài thuật ngữ cần neo nhanh:

Cisco FAPO đáng để ý vì nó không chỉ “tối ưu prompt”. Nó phân loại lỗi theo bước, rồi mới quyết định sửa prompt, tham số, hay cấu trúc chain. LlamaIndex với LiteParse cũng đi cùng tinh thần: xem trace thật, chạy eval, rồi mới sửa skill. Đây là tư duy production: đừng chăm mỗi câu trả lời cuối; hãy chăm đường đi tạo ra câu trả lời đó.

Ai hưởng lợi, ai bị ép đổi cách làm?

Người hưởng lợi đầu tiên là các team muốn chuẩn hóa workflow lặp lại: support kỹ thuật, data ops, platform engineering, QA, security review. Nếu trước đây mỗi người có một “bí kíp” nằm trong đầu hoặc trong chat, /learn mở ra cách biến bí kíp đó thành skill có thể gọi lại.

Người bị ép đổi là tech lead thích để agent “tự xoay”. Khi skill tạo dễ hơn, quyền kiểm soát càng phải rõ hơn. Blank Slate Mode của Hermes là tín hiệu hay: khởi động với gần như mọi thứ tắt, chỉ bật provider/model, File Operations và Terminal; các toolset như web, browser, memory, delegation, cron, skills, plugins, MCP đều phải opt-in. Đây là tư duy ngược với onboarding phô trương: mặc định ít quyền, cần gì bật nấy.

Fugu lại ép team nghĩ về lock-in và routing. Khi orchestration nằm sau một endpoint, code của bạn đơn giản hơn, nhưng per-query model selection có thể bị che khuất. Với sản phẩm cần compliance, bạn phải hỏi: dữ liệu đi qua model nào, có opt-out được không, trace có đủ sâu không?

Vậy sau bài này, bạn nên nghĩ khác điều gì? Đừng đánh giá agent framework bằng độ “tự động” của demo; hãy đánh giá bằng độ kiểm soát của vòng đời workflow.

Điều nên bỏ qua: FOMO slash command và benchmark đẹp

Có ba thứ mình sẽ không vội chạy theo.

Thứ nhất, đừng xem slash command là bằng chứng production-ready. Slash command chỉ là giao diện gọi skill. Cái quyết định độ tin cậy là skill có nguồn rõ, có test, có quyền hạn hẹp, có trace khi sai.

Thứ hai, đừng mặc định routing ẩn là tốt hơn routing tự làm. Sakana Fugu cho một hướng hấp dẫn: một API, bên trong nhiều model. Nhưng nếu team bạn đang xử lý dữ liệu khách hàng nhạy cảm, khả năng audit có thể quan trọng hơn việc endpoint gọn.

Thứ ba, đừng để eval thành nghi thức trang trí. Eval không chỉ là điểm số cuối. Với agent, eval phải soi được từng đoạn: skill nào được nạp, tool nào được gọi, bước nào làm lệch kết quả. Nếu không, bạn chỉ đang cân cả bó rau rồi đoán cây nào bị sâu.

Một buổi chiều để kiểm tra agent của bạn

Nếu đang build agent nội bộ, bạn không cần đập đi làm lại. Dành một buổi chiều audit theo cách này:

  1. Liệt kê 5 workflow agent đang làm nhiều nhất

Ví dụ: đọc log lỗi, tạo PR summary, phân loại ticket, trích xuất PDF, viết query SQL.

  1. Chọn 1 workflow để đóng gói thành skill

Viết hoặc để agent tạo bản nháp, nhưng bắt buộc có: mục tiêu, input hợp lệ, tool được phép dùng, điều kiện dừng, ví dụ đúng/sai.

  1. Thêm guardrail tối thiểu

Với workflow có ghi file, chạy terminal, gọi web hoặc đụng dữ liệu khách hàng, đặt bước xác nhận thủ công. Đừng bật cả vườn chỉ vì cần tưới một luống.

  1. Ghi trace cho 10 lần chạy gần nhất

Không cần hệ thống hoành tráng. Lưu JSONL cũng được: timestamp, skill, input rút gọn, tool calls, output, trạng thái pass/fail.

  1. Gán lỗi theo bước

Nếu output sai, đừng sửa prompt ngay. Hỏi trước: sai vì chọn nhầm skill, thiếu tài liệu, tool trả lỗi, prompt mơ hồ, hay bước tổng hợp làm mất chi tiết?

Một ví dụ minh họa: giả sử team bạn có agent đọc PDF hợp đồng rồi trích điều khoản thanh toán. Nếu agent sai, bạn cần biết lỗi nằm ở parser, retrieval, prompt trích xuất, hay bước format JSON. Sửa prompt ở cuối pipeline trong khi parser đã nuốt mất bảng dữ liệu thì chỉ là chăm lá mà quên rễ.

Chốt lại: agent tự học không thay thế kỷ luật vận hành

/learn của Hermes đáng chú ý vì nó làm workflow dễ được tái sử dụng hơn. Blank Slate đáng chú ý vì nó nhắc ta bắt đầu từ quyền tối thiểu. FAPO đáng chú ý vì nó kéo việc tối ưu xuống từng bước. Fugu đáng chú ý vì nó biến orchestration thành một sản phẩm có thể mua.

Nhưng quyết định thật sự của builder không phải “dùng tool nào đang ồn ào nhất”. Quyết định là: workflow nào đủ quan trọng để thành skill, và skill đó được kiểm soát như một phần của production system hay chỉ là ghi chú biết chạy?

Agent có thể học nhanh hơn team viết tài liệu, nhưng nếu không ai làm người giữ vườn, đến mùa thu hoạch bạn sẽ không biết mình đang hái quả hay nhổ cỏ.

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

Nguồn tham khảo