Repo-To-Skill: Khi repository trở thành “trí nhớ thao tác” của AI agent

Một AI agent có thể giải thích rất đúng về một thư viện machine learning nhưng vẫn mất hàng giờ chỉ để chạy nó sai cách.

Nó biết LoRA là gì, nhưng không biết phiên bản hiện tại của package mong đợi tham số nào. Nó hiểu một phương pháp đánh giá, nhưng bỏ sót bước chuẩn hóa dữ liệu khiến kết quả vô nghĩa. Nó đọc được README, rồi vẫn phải thử–sai qua những lỗi mà maintainer hoặc kỹ sư có kinh nghiệm đã giải quyết từ lâu.

Khoảng cách ấy không hẳn là thiếu thông minh. Đó là khoảng cách giữa biết một điều và biết cách làm cho điều đó hoạt động.

Paper mới Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills gọi phần còn thiếu này là operational knowledge — tri thức vận hành. Nhóm tác giả không chỉ đặt tên cho vấn đề; họ xây dựng DisCo, một hệ thống chưng cất repository và paper thành các skill ngắn gọn, có nguồn gốc, có thể kiểm tra và tái sử dụng. Ở quy mô lớn, pipeline tạo ra AREX-Skill Library gồm 5.353 skill từ 1.000 repository machine learning.

Ý tưởng này đáng chú ý vì nó đề xuất một lớp kiến trúc thứ ba cho agent: không chỉ có model và harness, mà còn có một kho “biết cách làm” nằm bên ngoài cả hai.

Luận điểm chính: Model cung cấp năng lực suy luận. Harness điều phối quá trình thực thi. Skill mang tới tri thức vận hành đúng lúc — để agent không phải tái khám phá cùng một bí quyết trong mỗi nhiệm vụ.

Một repository chứa nhiều hơn code

Khi con người nhìn vào một repository, chúng ta thường thấy source code, tài liệu, examples, tests và configuration. Nhưng ẩn bên dưới là một loại tài sản khác: những quyết định vận hành đã được tích lũy qua thời gian.

• Interface nào ổn định và nên dùng?
• Dữ liệu đầu vào phải được tổ chức ra sao?
• Cấu hình nào hợp với từng loại tác vụ?
• Output nào chứng minh quy trình đã chạy đúng?
• Lỗi phổ biến xuất hiện ở đâu và phục hồi thế nào?
• Khi nào không nên dùng phương pháp này?

README thường chỉ trả lời một phần. Tests có thể chứa hành vi thật nhưng viết cho maintainer. Source code chính xác hơn tài liệu, song quá lớn để nạp vào context mỗi lần. Issues chứa kinh nghiệm quý nhưng lẫn với lịch sử và tình huống riêng. Một kỹ sư giỏi tổng hợp tất cả những mảnh đó thành trực giác nghề nghiệp; một agent mới bước vào repository thì chưa có trực giác ấy.

Repo-To-Skill xem repository như một nguồn tri thức khai báo cần được chuyển thành tri thức có thể hành động. Thay vì đưa toàn bộ codebase cho agent rồi hy vọng nó tự tìm đúng đường, DisCo tạo ra một giao diện nhỏ hơn: skill nói rõ khi nào áp dụng, làm theo trình tự nào, dùng công cụ gì, kiểm tra kết quả ra sao và xử lý thất bại thế nào.

Đây không phải nén repository thành một bản tóm tắt. Một bản tóm tắt giúp hiểu. Một skill tốt phải giúp thực hiện.

Figure 1: AREX-Skill bổ sung lớp tri thức vận hành và kết quả trên bốn benchmark — nguồn: Repo-To-Skill, arXiv:2609.02749.

Lớp thứ ba: model, harness và operational knowledge

Cách nhìn phổ biến mô tả agent bằng hai thành phần:

Agent = Model + Harness

Model đảm nhiệm hiểu, suy luận, lập kế hoạch và sinh hành động. Harness cung cấp tool, memory, orchestration, verification và vòng lặp thực thi. Hai phần này rất quan trọng, nhưng theo nhóm tác giả, chúng vẫn để trống một câu hỏi: agent biết những gì cần cân nhắc trước khi bắt đầu?

Paper đề xuất:

Research Agent = Model + Harness + Operational Knowledge

Sự phân vai ở đây khá tinh tế:

• Model có prior rộng, nhưng kiến thức cố định và không bảo đảm hiểu đúng phiên bản phần mềm hiện tại.
• Harness quyết định agent làm việc như thế nào, nhưng không tự cung cấp chuyên môn của từng package hay phương pháp.
• Operational knowledge chỉ ra nên cân nhắc khả năng nào, khi nào dùng, dùng ra sao và bằng chứng nào xác nhận thành công.

Có thể hình dung model là người có năng lực tư duy, harness là xưởng làm việc, còn skill là quy trình nghề đã được kiểm chứng. Một xưởng tốt không tự biến người mới thành thợ lành nghề. Một bộ quy trình tốt cũng không thay thế tư duy. Ba lớp bổ sung cho nhau.

DisCo biến nguồn thành skill bằng bốn bước

Mỗi lượt chưng cất của DisCo đi qua bốn giai đoạn:

Scope → Ground → Construct → Verify

Scope — xác định phạm vi. Hệ thống trước tiên phải hiểu repository làm gì và những năng lực nào đáng được đóng gói. Cấu trúc skill nên phản ánh các tác vụ tương lai — như chuẩn bị dữ liệu, training, inference, evaluation, serving hoặc troubleshooting — chứ không đơn thuần sao chép cây thư mục.

Ground — neo vào bằng chứng. Claim trong skill được đối chiếu với source, docs, examples, tests, scripts và configuration. DisCo còn kiểm tra trực tiếp import name, version, public signature, CLI entry point và hành vi runtime nhỏ khi phù hợp.

Construct — xây giao diện vận hành. Một skill trong AREX có ba lớp: SKILL.md là giao diện tri thức và policy sử dụng; references/ chứa chi tiết chỉ mở khi cần; scripts/ cung cấp wrapper có input/output rõ ràng để agent không phải viết lại thao tác lặp.

Verify — kiểm chứng trước khi tiếp nhận. Hệ thống chạy usability case có assertion, test hoặc example an toàn của repository, CLI check, tiny fixture hay smoke script. Nếu lỗi do skill, DisCo sửa cục bộ rồi chạy lại phần liên quan. Static gate kiểm tra metadata, link, tính tự chứa, provenance, routing và rò rỉ đường dẫn local.

Câu quan trọng nhất trong paper là: verification phân biệt distillation với summarization. Nguồn có vẻ uy tín chưa đủ để biến nội dung được sinh ra thành hướng dẫn đáng tin. Skill chỉ được nhận sau kiểm tra; khoảng trống chưa giải quyết phải được ghi lại thay vì giấu đi.

Figure 2: DisCo tạo và sử dụng operational knowledge — nguồn: Repo-To-Skill, arXiv:2609.02749.

Hai con đường: chuẩn bị trước hoặc học theo nhiệm vụ

DisCo hỗ trợ hai kiểu chưng cất.

Task-agnostic: bắt đầu từ nguồn

Với một repository, paper hoặc tutorial, hệ thống hỏi: “Nguồn này giúp agent làm được những gì?”. Các skill được chuẩn bị trước và có thể tái sử dụng cho nhiều nhiệm vụ sau này.

Đây là cách nhóm tác giả xây AREX-Skill Library. Snapshot được báo cáo có 5.353 skill từ 1.000 repository, tổ chức trong 20 lĩnh vực và 178 nhóm năng lực. 700 repository xuất hiện ở nhiều hơn một nhóm vì một công cụ có thể phục vụ nhiều loại workflow.

Task-oriented: bắt đầu từ vấn đề

Với một nhiệm vụ cụ thể, hệ thống phân rã yêu cầu, tìm khoảng trống năng lực, khám phá nguồn liên quan rồi tạo skill theo nhu cầu. Skill hình thành theo task nhưng vẫn được viết để tái sử dụng cho cả lớp vấn đề tương tự.

Hai hướng này tương ứng với hai kiểu đầu tư tri thức: xây thư viện trước để dùng nhiều lần, hoặc học có mục tiêu khi gặp một bài toán mới. Trong cả hai trường hợp, chi phí creator mode được trả một lần; researcher mode chỉ mở nhánh skill cần thiết theo nguyên tắc progressive disclosure.

Đó là cách một agent có thể sở hữu hàng nghìn skill mà không nhét toàn bộ thư viện vào context.

Kết quả mạnh — nhưng phải đọc đúng

Nhóm tác giả giữ nguyên GPT-5.5, Codex harness và ngân sách chạy downstream, rồi so sánh cùng agent khi có và không có skill. Kết quả được báo cáo:

Ở MLE-bench, mức tăng lớn nhất nằm ở nhóm khó: từ 13,33% lên 62,22%. Trên PaperBench, skill cải thiện 18 trong 20 task. Trên PassNet, số sample thất bại giảm từ 14 xuống 5 và correctness tăng từ 81,35% lên 90,76%.

Những con số này ủng hộ mạnh giả thuyết rằng tri thức vận hành có thể tạo giá trị mà không cần đổi model hoặc control loop. Tuy nhiên, chúng không chứng minh skill luôn có lợi.

PaperBench có hai task giảm điểm khi thêm skill. Trên FrontierCS cũng tồn tại task bị giảm, dù tổng tác động là dương. Chính nhóm tác giả nêu một khả năng: retrieval thiếu chính xác có thể kéo agent khỏi chiến lược phù hợp mà nó vốn có thể tự tìm ra.

Một caveat khác rất quan trọng: ngân sách xây skill được tách khỏi ngân sách chạy benchmark. Với collection repository, paper báo cáo chi phí xây dựng trung bình khoảng 40 USD mỗi repository bằng GPT-5.5 và GPT-5.6-sol ở mức reasoning cao. So sánh runtime là công bằng giữa hai điều kiện, nhưng tổng chi phí vòng đời chỉ có lợi khi skill được tái sử dụng đủ nhiều.

Vì vậy, cách đọc đúng không phải “thêm SKILL.md là tăng 134%”. Kết luận hợp lý hơn là: trong thiết lập của nghiên cứu, operational knowledge được chưng cất và kiểm chứng tốt giúp cùng một agent dùng ngân sách thực thi hiệu quả hơn đáng kể.

Điều mới không nằm ở file SKILL.md

Reusable skill không xuất hiện từ hư không. Voyager từng học code skill qua tương tác; Agent Workflow Memory trích workflow từ trajectory; ExpeL chưng cất insight từ kinh nghiệm. Bản thân agent skill cũng đã được Claude Code, Codex và nhiều hệ thống hỗ trợ.

Điểm đáng chú ý của Repo-To-Skill nằm ở tổ hợp:

1. Nguồn tĩnh có phiên bản: repository và paper, thay vì chỉ học từ trajectory.
2. Provenance rõ: claim phải quay về bằng chứng trong nguồn.
3. Artifact có thể kiểm tra: skill là file, reference và script có thể đọc, sửa, version và thu hồi.
4. Verification có record: không đánh đồng văn bản hợp lý với quy trình đã hoạt động.
5. Routing theo năng lực: chỉ tải nhánh liên quan thay vì đổ cả thư viện vào context.
6. Quy mô và benchmark: ý tưởng được triển khai trên 1.000 repository và thử trong bốn môi trường nghiên cứu.

Nói cách khác, đóng góp lớn không phải “phát minh ra skill”, mà là đối xử với skill như một chuỗi cung ứng tri thức.

Từ thư viện skill đến hạ tầng quản trị tri thức

Nếu áp dụng vào production, pipeline không nên dừng ở bước “generate skill”. Repository thay đổi; API bị deprecate; test cũ có thể vẫn pass trong khi business requirement đã khác. Một skill đúng hôm nay có thể thành lời khuyên nguy hiểm sau sáu tháng.

Em cho rằng lớp operational knowledge cần thêm vòng đời quản trị:

Source + version
→ Candidate skill
→ Evidence and sandbox checks
→ Human or policy approval
→ Scoped runtime use
→ Outcome monitoring
→ Keep, revise, quarantine, or revoke

Mỗi skill production nên trả lời được:

• Nó được tạo từ commit hoặc phiên bản nào?
• Claim nào dựa vào file, test hay hành vi runtime nào?
• Điều kiện kích hoạt và điều kiện từ chối là gì?
• Quyền nào cần thiết để chạy scripts đi kèm?
• Check nào đã pass, check nào bị skip và vì sao?
• Lần cuối skill được xác nhận còn đúng là khi nào?
• Ai hoặc policy nào có quyền sửa, duyệt và thu hồi?

Đây là nơi ý tưởng Repo-To-Skill chạm tới một bài toán lớn hơn: agent không chỉ cần memory để nhớ chuyện đã xảy ra; nó cần operational memory có quản trị để tái sử dụng điều đã học mà không biến kinh nghiệm cũ thành luật bất biến.

Góc nhìn của Bé Mi: tương lai của agent có thể là “AI dùng tri thức do AI đóng gói”

Tên gọi AI4AI trong paper rất đắt. Repository vốn được con người viết để con người và máy tính sử dụng. DisCo thêm một tầng chuyển đổi: AI đọc nguồn, đóng gói thành giao diện cho AI khác, rồi agent dùng giao diện đó để làm nghiên cứu tốt hơn.

Nếu mô hình này mở rộng, repository sẽ không chỉ phát hành code và docs. Một release có thể đi kèm operational package cho agent: skill mô tả use case, scripts cung cấp thao tác ổn định, references giữ bằng chứng, tests xác nhận hành vi và metadata chỉ rõ compatibility.

Nhưng em không nghĩ điều đó loại bỏ chuyên gia. Ngược lại, nó làm tri thức của chuyên gia trở nên quan trọng hơn. AI có thể giúp khai thác, đóng gói và kiểm tra ở quy mô lớn; con người vẫn phải quyết định mục tiêu, phạm vi rủi ro, tiêu chuẩn chấp nhận và lúc nào một quy trình không còn phù hợp.

Repo-To-Skill vì thế không chỉ là một paper về tăng benchmark. Nó gợi ý cách agent trưởng thành: không phải mỗi lần gặp việc lại thông minh từ đầu, mà biết kế thừa những gì đã được chứng minh — có nguồn, có kiểm tra và có quyền quên khi kiến thức hết hạn.

Nguồn chính: Repo-To-Skill: Distilling GitHub Repositories Into AI4AI Skills — arXiv:2609.02749 · AREX-Skill Library — GitHub