Thiết kế, tinh chỉnh và duy trì các kỹ năng tác nhân tại Perplexity

Các sản phẩm tác nhân tiên phong của Perplexity dựa trên nền tảng bí quyết và chuyên môn sâu rộng về lĩnh vực được đóng gói thành các Agent Skills mô-đun. Chúng tôi duy trì một thư viện các Skill được tuyển chọn cẩn thận trong các môi trường kỹ thuật của mình. Những Skill này bao gồm nhiều tiện ích đa năng cung cấp năng lực cho Perplexity Computer; các tính năng chuyên biệt theo lĩnh vực trong các lĩnh vực như tài chính, luật và y tế; và rất nhiều mô-đun dài hạn để giải quyết nhu cầu của người dùng. Một số Skill ít khi được gọi nhưng lại rất quan trọng khi được gọi. Để đảm bảo trải nghiệm người dùng luôn xuất sắc, nhóm Agents của Perplexity ưu tiên chất lượng của Skill ngang bằng với chất lượng mã nguồn.

Sự trực giác và các thực hành tốt nhất cần thiết để phát triển một Skill chất lượng cao khác biệt đáng kể so với những gì cần thiết để xây dựng phần mềm truyền thống. Nhóm Agents xem xét rất nhiều yêu cầu kéo từ các kỹ sư xuất sắc, những người phát triển Skill trong quá trình làm việc của họ. Kết quả hầu như luôn là rất nhiều nhận xét và đề xuất sửa đổi. Điều này là do nhiều mẫu hữu ích để viết mã nguồn lại trở thành phản mẫu trong việc tạo Skill.

Ví dụ, nếu bạn lấy một số châm ngôn từ PEP20 – Thiền định về Python, bạn sẽ nhanh chóng nhận ra rằng việc viết mã Python tốt khác với việc viết các Skill tốt. Trong số 20 dòng trí tuệ đó, ít nhất một nửa hoàn toàn sai hoặc gây hiểu lầm tích cực khi viết Skill. Dưới đây là năm trong số đó:

Năm điểm tương phản giữa Zen của Python và hướng dẫn của bài viết về cách viết Skills.

Hướng dẫn này là tài liệu mà các kỹ sư trên khắp Perplexity sử dụng khi phát triển và đánh giá các Skill. Chúng tôi cũng phát hành hướng dẫn này cho công chúng để những khám phá và bài học của chúng tôi có thể mang lại lợi ích cho cộng đồng rộng lớn hơn. Cho dù bạn là một kỹ sư thiết kế các Skill sản xuất trong công việc hàng ngày, một người dùng Computer muốn phát triển Skill của riêng mình trong lĩnh vực bạn am hiểu nhất, hay cả hai, hướng dẫn này dành cho bạn.

Skill là gì?

Khi bạn viết một Skill, bạn không chỉ viết phần mềm cũ đơn thuần (mặc dù các Skill hiện là một phần của các công cụ logic chính cho các hệ thống tác nhân). Thay vào đó, bạn đang xây dựng ngữ cảnh cho các mô hình và môi trường của chúng. Một Skill có các ràng buộc khác nhau và các nguyên tắc thiết kế khác nhau. Nếu bạn viết một Skill giống như cách bạn viết mã, bạn sẽ thất bại.

Một Skill bao gồm ít nhất bốn điều, đặc biệt là trong bối cảnh cách chúng tôi xây dựng chúng tại Perplexity.

Một Skill là một Thư mục

Một Skill không chỉ là một tệp SKILL.md đơn lẻ. Trong nhiều trường hợp, một Skill bao gồm vài tệp. Dưới thư mục được đặt tên theo Skill của bạn, bạn có thể có:

SKILL.md: phần thông tin mở đầu và hướng dẫn

scripts/: mã nguồn tác nhân chạy, không phải tạo lại

references/: tài liệu nặng, được tải có điều kiện

assets/: các mẫu, lược đồ và dữ liệu

config.json: thiết lập người dùng cho lần chạy đầu tiên

Mô hình trung tâm và nan hoa này cho phép bạn giữ cho các Skill rất tập trung và chặt chẽ, và người ta có thể sử dụng cấu trúc thư mục theo một cách rất sáng tạo. Đôi khi, các Skill đặc biệt phức tạp được hưởng lợi từ nhiều cấp độ phân cấp để giúp mô hình điều hướng tốt hơn. Giả sử một Skill yêu cầu kiến thức trên 300 chủ đề, có thể nhóm thành 20 lĩnh vực chủ đề. Việc chọn đáng tin cậy chủ đề phù hợp trong số 300 chủ đề là một thách thức chưa được giải quyết ngay cả đối với các mô hình tiên tiến nhất hiện nay. Vấn đề lựa chọn đối với một mô hình sẽ dễ dàng hơn nhiều khi tập trung vào một trong 20 lĩnh vực, thay vì trong số 15 chủ đề thuộc lĩnh vực đó.

Là một ví dụ về cách phân cấp đa tầng mang lại giá trị, nhóm của chúng tôi đã áp dụng ba cấp độ lồng nhau theo chủ đề trong các Skill hỗ trợ các tính năng thuế thu nhập tại Hoa Kỳ của Computer trong mùa thuế vừa qua. Hệ thống phân cấp này hoàn toàn không thể thiếu do sự phức tạp của luật thuế: trong các thử nghiệm ban đầu của chúng tôi, việc cung cấp cho mô hình một thư mục duy nhất chứa tất cả 1.945 phần của Bộ luật Thuế vụ Hoa Kỳ dẫn đến hiệu suất tồi tệ hơn so với việc không tải Skill đó chút nào. Việc tổ chức thông tin thành các phân khu logic là không thể thiếu để đảm bảo các thao tác đọc có độ chính xác cao.

Tuy nhiên, hệ thống phân cấp này không phải tự nhiên mà có. Việc tăng các cấp độ phân cấp đòi hỏi mức độ tuyển chọn ngày càng cao trong toàn bộ kiến trúc thông tin để quản lý sự chuyển hướng phát sinh. Chúng tôi đã nghĩ ra các hướng dẫn tham khảo nhanh, các tiện ích tìm kiếm tùy chỉnh và các công cụ khác để hỗ trợ mô hình định vị thông tin với mức độ chuyển hướng tối thiểu. Trong trường hợp này, việc thực hiện công việc tuyển chọn khó khăn cuối cùng đã mang lại kết quả cuối cùng tích cực: một Skill cho phép các mô hình thực hiện các tác vụ liên quan đến thuế có năng lực hơn nhiều so với việc chỉ sử dụng các công cụ chung chung.

Phóng to

Một Skill là một Định dạng

Một Skill là một định dạng. Tệp gốc cốt lõi SKILL.md phải có cả tên và mô tả. Hơn nữa, Skill cần phải khớp chính xác với tên thư mục nơi Skill được đặt. Tên phải toàn là ký tự chữ thường, không có Space, và có thể sử dụng dấu gạch ngang. Mô tả là tác nhân kích hoạt định tuyến. Đây là một điểm lỗi phổ biến: mô tả không phải là tài liệu nội bộ về những gì Skill làm. Nó tương đương với các hướng dẫn cho mô hình về thời điểm tải Skill. Vì vậy, bạn sẽ thường thấy "Tải khi", chứ không phải "Skill này làm". Điều này quan trọng vì cách mà hầu hết các triển khai chèn mô tả vào ngữ cảnh của mô hình.

Bên trong phần thông tin mở đầu, cũng có "depends:", cho phép bạn tạo các phụ thuộc Skill theo cấp độ, và "metadata:", được sử dụng cho việc đánh giá và thẩm định. Các hệ thống tác nhân khác nhau thậm chí có thể xác định các trường thông tin mở đầu của riêng chúng, được sử dụng theo cách cụ thể cho các hệ thống đó. Thay vào đó, siêu dữ liệu cụ thể của Skill có thể được đóng gói trong một tệp cấu hình JSON hoặc YAML phụ trợ. Điều này rất đáng mong đợi khi xây dựng các hệ thống tác nhân cần hỗ trợ các loại hành vi thời gian chạy khác nhau cho mỗi Skill mà không làm ô nhiễm ngữ cảnh của mô hình bằng những chi tiết vụn vặt. Cuối cùng, hành vi tương tự có thể đạt được thông qua việc loại bỏ phần thông tin mở đầu của Skill khi đọc. Computer áp dụng phương pháp luận này, cho phép bảo tồn cấu hình trong tệp gốc SKILL.md. Cần chú ý cẩn thận đến từng chi tiết trong logic phân tích cú pháp, và người ta có thể muốn triển khai việc loại bỏ có điều kiện nếu có một số trường nhất định hữu ích khi có mặt trong ngữ cảnh của mô hình.

Một Skill có thể được gọi

Một Skill có thể được gọi. Tác nhân tải một Skill khi chạy. Quan trọng là, các Skill không phải lúc nào cũng được gói gọn trong ngữ cảnh. Theo mặc định, hầu hết các hệ thống tác nhân sẽ mở rộng các Skill một cách tiến triển theo nhu cầu cụ thể.

Có ít nhất ba bậc chi phí ngữ cảnh theo cách chúng tôi đã triển khai các Skill trong Computer. Quy trình như sau:

Computer gọi load_skill(name="...")

Computer sao chép thư mục Skill vào sandbox thực thi cô lập

Computer tự động tải đệ quy các phần phụ thuộc trong thẻ "depends:"

Computer sau đó loại bỏ phần thông tin mở đầu và do đó tác nhân chỉ nhìn thấy phần thân và các tệp bổ sung

Các hệ thống tác nhân khác nhau có thể chọn hiển thị nội dung Skill theo các cách khác nhau. Ví dụ, một số hệ thống có thể chọn không hiển thị hệ thống phân cấp tệp chút nào, để cho mô hình tự khám phá hệ thống phân cấp thông qua các thao tác trên hệ thống tệp. Các hệ thống khác có thể chọn cung cấp cho mô hình bản đồ của toàn bộ cây tệp đến một giới hạn cắt bớt và/hoặc độ sâu nhất định. Để giữ cho ngữ cảnh sạch sẽ, Computer bỏ qua các hệ thống phân cấp tệp đầy đủ khỏi ngữ cảnh gọi; tuy nhiên, điều này có thể ghi đè trên cơ sở từng Skill.

Một Skill có tính tiến triển

Các Skill có tính tiến triển. Trong Computer, có ba bậc chi phí ngữ cảnh khác nhau và chúng tôi chịu cả ba ở các giai đoạn khác nhau:

Ba cấp độ ngữ cảnh của Skill: chỉ mục, tải đầy đủ Skill và các tệp tham chiếu khi chạy.

Computer xây dựng một chỉ mục Skill có tên và mô tả cho mọi Skill có sẵn. Ngân sách cho việc này là khoảng 100 token cho mỗi Skill (ngắn hơn thậm chí còn tốt hơn). Nó rất chặt chẽ vì bạn đang phải trả chi phí này trong mọi phiên, cho mọi người dùng. Điều này được chèn vào lời nhắc hệ thống ngay từ đầu cuộc trò chuyện. Mô hình có quyền truy cập vào một loạt các Skill có tên và mô tả để nó có thể quyết định có gọi "load_skill()" hay không. Tiêu chuẩn để được đưa vào chỉ mục này cực kỳ cao. Skill của bạn cần phải rất hữu ích, và mô tả cần phải cực kỳ cô đọng và ngắn gọn vì mọi người đều phải trả chi phí mọi lúc.

Sau khi hệ thống tác nhân tải Skill, sẽ có toàn bộ phần thân SKILL.md. Lý tưởng nhất là văn bản thân không vượt quá 5.000 token. Ngay cả khi đó, bạn vẫn muốn mọi câu đều có giá trị vì một khi bạn đã tải một Skill, phần còn lại của cuộc trò chuyện phải trả chi phí đó cho đến khi bạn chạm đến ranh giới thu gọn. Nhiều chuỗi tải đâu đó từ ba đến năm Skill khác nhau, làm nhân lên chi phí này. Các Skill có quá nhiều nội dung rườm rà gần như chắc chắn sẽ làm giảm chất lượng của các Skill khác cũng như các khả năng tác nhân tổng体. Tóm lại, nếu Skill của bạn tải lên mà không làm đúng việc, đó là ngữ cảnh bị lãng phí.

Mức độ tiến triển cuối cùng là các tập lệnh hoặc các trường hợp đặc biệt, như tiểu kỹ năng (subskills) hoặc định dạng. Đây là nơi bạn muốn đặt logic rẽ nhánh có điều kiện không giới hạn. Tác nhân sẽ chỉ sử dụng nó khi cần, nghĩa là có tiêu chuẩn thấp hơn nhiều cho những gì bạn muốn đặt vào đây.

Trong chỉ mục, mọi token đều quan trọng. Thân Skill đã tải sẽ thoải mái hơn, và thời gian chạy là thoải mái nhất. Điều này có thể là 20.000 token hoặc không có token nào. Đây là cấp độ mà bạn có thể cân nhắc mở rộng ngữ cảnh của mô hình theo cách tiến triển.

Khi nào bạn cần một Skill?

Nhóm Agents thường được yêu cầu đưa ra ý kiến về việc liệu một Skill có thực sự cần thiết cho một miền hoặc trường hợp sử dụng nhất định hay không. Rất hiếm khi chúng tôi có câu trả lời dứt khoát chỉ từ các nguyên lý đầu tiên. Cách duy nhất để thực sự tìm ra điều này là bắt đầu với tác nhân của bạn mà không có Skill, chạy một số truy vấn mẫu nổi bật, sau đó tìm hiểu xem tác nhân có đang làm tốt công việc hay không.

Khi bạn cần một Skill

Có rất nhiều tác vụ nằm trong phân phối cho các mô hình đã được đào tạo. Bạn chỉ cần áp dụng một Skill nếu bạn muốn thay đổi hành vi đó theo một cách cụ thể nào đó mà bạn không thể làm được với ví dụ như, một câu trong lời nhắc của mình. Vì vậy, bạn cần một Skill khi tác nhân sẽ làm sai nếu không có ngữ cảnh đặc biệt, hoặc nếu có sự thiếu nhất định quán hoặc tính không xác định mà bạn cần phải cực kỳ nhất quán qua các lần chạy.

Có thể kiến thức của bạn là bền vững nhưng không có trong dữ liệu huấn luyện. Có thể có các mốc thời gian hoặc quy trình làm việc cụ thể của doanh nghiệp, hoặc đó có thể là vấn đề sở thích. Ví dụ, chúng tôi có một số Skill liên quan đến thiết kế trong Computer do Henry Modisett (trưởng bộ phận thiết kế của chúng tôi) viết. Lý do mọi token tồn tại trong các Skill đó là vì Henry có gu thẩm mỹ rất tốt khi thiết kế trang web và PDF. Henry chỉ định phông chữ nào nên sử dụng và phông chữ nào không nên sử dụng, các phông chữ đó cảm giác thế nào, và các vấn đề phán đoán khác mà mô hình không thể học chỉ từ dữ liệu huấn luyện.

Khi bạn không cần một Skill

Chúng tôi thấy nhiều Skill trong đó các kỹ sư đã viết một loạt các lệnh git cần được thực thi theo thứ tự. Điều đó là không cần thiết vì mô hình đã biết cách làm điều đó, có nghĩa là nó tạo ra tài liệu tuyệt vời nhưng lại là một Skill kém.

Chúng tôi thấy các ví dụ trong đó các Skill lặp lại các hướng dẫn từ lời nhắc hệ thống. Bạn không cần một Skill cho việc đó. Kiến thức liên quan đến phần lớn các yêu cầu nên được bao gồm trong ngữ cảnh toàn cục, không phải trong một Skill được tải có điều kiện

Nếu có thứ gì đó thay đổi nhanh hơn khả năng duy trì của bạn, bạn không cần một Skill. Ví dụ, nếu bạn đang truy cập vào một điểm cuối MCP từ xa nào đó và các công cụ của nó hoặc các phiên bản của các công cụ đó thay đổi thường xuyên, bạn không nên chèn chúng vào một Skill. Nếu bạn làm vậy, cuối cùng bạn sẽ chỉ gặp phải tình trạng lệch hướng và mô hình sẽ mắc lỗi.

Mọi Skill đều là một khoản thuế

Dưới đây là một bài kiểm tra hữu ích bạn có thể áp dụng cho mọi câu trong Skill của mình: "Liệu tác nhân có làm sai điều này nếu không có hướng dẫn này không?" Nếu câu đó không cần phải có ở đó, nó không thể đủ khả năng để ở đó vì mọi người đều đang trả chi phí này mỗi lần. Khi bạn đang quyết định có thêm một Skill hay không, hãy ghi nhớ khoản thuế này trong đó mọi phiên và mọi người dùng đều tốn token.

Câu nói nổi tiếng sau đây, nghe hay hơn nhiều bằng tiếng Pháp, dịch đại khái là “Tôi chỉ viết bức thư này dài hơn vì tôi không có thời gian để làm cho nó ngắn hơn.”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Giống như Pascal, bạn cần đầu tư thời gian vào mọi Skill. Thật khó để viết một Skill ngắn. Nếu Skill của bạn dễ viết, nó có thể quá dài hoặc không nên tồn tại. Một Skill tốt phải ngắn nhất có thể.

Nếu bạn thấy mình đang cố gắng tạo Skill một lần (one-shot) và đưa ra các PR trong năm phút, kết quả hầu như chắc chắn sẽ kém chất lượng. Trên thực tế, nghiên cứu ban đầu đã cho thấy rằng nếu bạn đang sử dụng LLM để viết các Skill, LLM có thể sẽ không đạt được lợi ích từ việc đó: “Các Skill tự tạo không mang lại lợi ích gì trung bình, cho thấy các mô hình không thể tác giả một cách đáng tin cậy kiến thức thủ tục mà chúng được hưởng lợi khi sử dụng.”

Cách xây dựng một Skill

Nói cách khác, bạn cần chèn quan điểm của mình vào bất kỳ Skill nào bạn viết. Hãy thực hiện các bước sau.

Bước 0: Viết các bài đánh giá (Evals)

Viết một số bài đánh giá trước tiên. Bạn có thể lấy các trường hợp đánh giá từ:

Truy vấn người dùng thực: lấy mẫu từ môi trường sản xuất hoặc bộ não tin cậy của bạn

Lỗi đã biết: Tác nhân thất bại vì Skill không tồn tại

Nhầm lẫn với lân cận: Gần với ranh giới miền của bạn nhưng định tuyến đến một Skill khác

Ít nhất, bạn nên đảm bảo rằng bạn đang kiểm tra xem Skill có tải khi cần hay không. Lý tưởng nhất là bạn lấy mẫu một số trong số này, có lẽ từ môi trường sản xuất. Bạn cũng có thể xem xét các trường hợp lỗi đã biết: có thể toàn bộ lý do bạn bắt đầu viết Skill là vì một lỗi cụ thể mà bạn nhận thấy hoặc có thể bạn đang tái cấu trúc và có một số nhầm lẫn ở hai miền gần nhau được bao phủ bởi một Skill.

Bắt đầu với các ví dụ tích cực và tiêu cực tương tự. Các ví dụ tiêu cực cực kỳ mạnh mẽ và có thể quan trọng hơn các ví dụ tích cực.

Bước 1: Mô tả

Đây là dòng khó nhất trong Skill. Nó là một tác nhân kích hoạt định tuyến, không phải tài liệu. Để làm cho tên và mô tả chính xác, bạn không quan tâm đến nội dung của Skill. Bạn chỉ quan tâm đến việc liệu Skill có được tải và chèn đúng điểm hay không và không có các tác dụng phụ ngoài mục tiêu, đó là chế độ lỗi số một. Mỗi khi bạn thêm một Skill bổ sung, bạn có nguy cơ làm cho mọi Skill khác kém đi một chút, vì vậy bạn cần đảm bảo rằng bạn đang giảm thiểu sự hồi quy.

Một lần nữa, một mô tả tồi sẽ mô tả những gì Skill làm hoặc tại sao nó hữu ích. Một mô tả tốt sẽ cho biết khi nào tác nhân nên tải Skill. Ví dụ, giả sử bạn có thứ gì đó để giám sát các yêu cầu kéo. Đừng viết những gì Skill làm. Hãy viết những gì các kỹ sư nói khi họ thất vọng và họ muốn bạn đảm bảo rằng PR của họ hoạt động, như "giám sát" (babysit) hoặc "theo dõi CI" (watch CI) hoặc "đảm bảo cái này được thông qua" (make sure this lands).

Dưới đây là một danh sách kiểm tra nhanh:

Bắt đầu bằng "Tải khi..." ("Load when...")

Nhắm mục tiêu 50 từ trở xuống

Mô tả ý định của người dùng, lý tưởng nhất là từ các truy vấn thực tế

Không tóm tắt quy trình làm việc

Các truy vấn thực tế là những gì bạn có thể bao gồm trong quy tắc 80-20. Thường thì hai hoặc ba ví dụ hoạt động tốt. Không dễ để thêm chính xác và chỉ vừa đủ những gì bạn cần.

Bước 2: Viết phần thân

Tiếp theo, viết nội dung của bản thân Skill. Lưu ý đây không phải là Bước 0 hay Bước 1.

Truyền đạt các quy trình làm việc cho LLM hoàn toàn khác với việc truyền đạt các quy trình làm việc cho đồng nghiệp, hoặc thậm chí cho hệ thống thời gian chạy của bạn. Khi học một công cụ phần mềm mới, một kỹ sư có thể cần đọc tài liệu, nhận hướng dẫn từ người có kinh nghiệm và tìm hiểu cách sử dụng công cụ. Trong khi đó, đối với hầu hết mọi công cụ phần mềm đã tồn tại ít nhất một năm, bạn chỉ cần đề cập đến tên của nó và LLM có tất cả thông tin nó cần.

Khi bạn viết phần thân, hãy bỏ qua những điều hiển nhiên. Nhiều kỹ sư có nhiều kinh nghiệm viết các tệp readme.md liệt kê mọi lệnh mà ai đó cần chạy. Thật dễ dàng để quay lại điều đó khi bạn đang viết một Skill vì có cảm giác như bạn đang viết tài liệu, nhưng nếu bạn làm vậy, Skill của bạn sẽ là đồ bỏ đi. Vì vậy, đừng viết ra một loạt các lệnh.

Ví dụ, bạn không cần phải viết, “git log # tìm commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

Thay vào đó, hãy viết, “Cherry-pick commit sang nhánh sạch. Giải quyết xung đột bảo toàn ý định. Nếu không thể đưa vào sạch sẽ, hãy giải thích tại sao.”

Mô hình sẽ làm tốt hơn nhiều với cách sau so với chuỗi lệnh quá mức quy định của cách trước, đặc biệt là khi có sự cố xảy ra. Đừng ép buộc, hoặc quá mức quy định, vốn rất dễ vỡ, thay vào đó hãy linh hoạt nơi nhiều phương pháp có thể hoạt động. Một lần nữa, tài liệu tốt cho con người hầu hết thời gian lại là tài liệu tồi cho các mô hình.

Tiếp theo, tập trung vào các cạm bẫy hoặc các ví dụ tiêu cực. Đây là nội dung có tín hiệu cực kỳ cao vì chúng thường hướng dẫn mô hình về những việc không nên làm. Nếu bạn thêm một dòng mỗi khi tác nhân vấp ngã, bạn sẽ học bằng cách chạy nó và các cạm bẫy sẽ phát triển một cách tự nhiên.

Cuối cùng, nếu có bất kỳ phần nào mang tính điều kiện hoặc cực kỳ nặng về nội dung, hãy đưa nó ra khỏi SKILL.md, vốn là trung tâm, và đặt nó vào một trong các nan hoa. Đặt nó vào một tệp phụ kiện có thể được tải tiến triển, mà chúng ta sẽ đi sâu vào tiếp theo.

Bước 3: Sử dụng Hệ thống phân cấp

Tận dụng hệ thống phân cấp Skill khi bạn có tập lệnh, tài liệu tham khảo hoặc bạn đang sử dụng một công cụ cụ thể nào đó:

Các cách sử dụng được đề xuất cho script, tài liệu tham khảo, tài sản và cấu hình trong một Skill.

Đối với bất cứ thứ gì có điều kiện hoặc rẽ nhánh từ Skill chính, hãy tách nó thành một thư mục. Hãy nhớ rằng, hệ thống phân cấp đa tầng cũng có thể được sử dụng cho các Skill đặc biệt phức tạp. Đối với những Skill này, bạn sẽ muốn suy nghĩ cẩn thận về việc liệu chức năng này nên được thực hiện theo kiểu nguyên khối hay như một bộ sưu tập các Skill (có thể với các mối quan hệ tải dựa trên depends:).

Bước 4: Lặp lại

Tiếp theo, thực hiện một loạt các lần lặp trên một nhánh. Bắt đầu trên nhánh chính không có Skill, thực hiện một số lần lặp, xây dựng tập truy vấn nổi bật của bạn và chạy một loạt các bài đánh giá. Bất kỳ ai xem xét mã Skill của bạn sẽ cảm ơn bạn vì đã gửi một bộ thay đổi duy nhất hoàn chỉnh với một bộ đánh giá. Việc xem xét các thay đổi gia tăng liên tiếp (ngoại trừ một cạm bẫy mới) rất khó khăn, vì vậy hãy cố gắng giảm thiểu điều đó.

Bạn có thể sẽ thực hiện nhiều thay đổi từ nhỏ. Các thay đổi từ nhỏ trong phần mô tả có thể có tác động lớn đến định tuyến (bao gồm cả hiệu ứng lan sang các Skill khác), vì vậy hãy thực hiện tất cả công việc đó trước Bước 5.

Bước 5: Phát hành

Phát hành nó.

Cách duy trì một Skill

Bây giờ bạn đã viết một Skill, bạn phải duy trì nó.

Bánh đà cạm bẫy (Gotchas Flywheel)

Từ thời điểm này trở đi, danh sách các cạm bẫy của bạn có xu hướng phát triển hoặc thay đổi rất nhiều. Chúng tôi thường thấy các kỹ sư tạo các PR chưa được đánh giá, ví dụ, thay đổi mô tả. Nếu bạn đang thay đổi mô tả sau khi Skill của bạn đã được hợp nhất, bạn đang đi sai hướng. Nếu bạn đang thực hiện các thay đổi đối với thứ quyết định có định tuyến Skill của bạn hay không, bạn cần viết một số bài đánh giá hỗ trợ các thay đổi đó.

Các Skill chủ yếu mang tính chất nối thêm. Phần cạm bẫy tích lũy nhiều giá trị nhất theo thời gian:

Tác nhân gặp sự cố ở điểm nào đó → Thêm cạm bẫy

Tác nhân tải Skill chệch hướng → Thắt chặt mô tả và thêm các đánh giá tiêu cực

Tác nhân không tải Skill khi nên tải → Thêm từ khóa và các đánh giá tích cực

Thay đổi lời nhắc hệ thống → Kiểm tra tranh chấp hoặc trùng lặp

Thật dễ dàng để nhận thấy một trường hợp lỗi duy nhất trong thử nghiệm nội bộ hoặc trong sản xuất và thêm một cạm bẫy. Đó là một ví dụ tiêu cực nên nó không thực sự thay đổi hướng dẫn rõ ràng, nhưng nó cho mô hình biết, "Này, có lỗi đã biết này."

Khi bạn chuyển từ quy tắc 80-20 sang đạt tỷ lệ thành công 99,9% hoặc 99,99%, rất dễ để phát triển danh sách cạm bẫy này. Khi bạn thấy các ví dụ tiêu cực này, bạn nên nối thêm chủ yếu vào phần cạm bẫy. Bạn không nên thêm các hướng dẫn dài hơn hoặc thay đổi mô tả.

Bộ đánh giá (Eval Suites)

Tại Perplexity, chúng tôi chạy nhiều bộ đánh giá để kiểm tra các thứ khác nhau. Có việc tải Skill và đọc tệp Skill, kiểm tra độ chính xác, độ nhớt và kiểm tra cấm của việc tải Skill. Liệu tác nhân có định tuyến Skill của bạn khi nó phải làm vậy không? Những điều này đảm bảo các Skill mới không phá vỡ các ranh giới hiện có.

Cũng có các đánh giá có thể kiểm tra việc tải tiến triển thích hợp. Tác nhân có thể tải Skill, nhưng nó có đọc tệp hoặc các tệp phụ kiện không? Ví dụ, nếu bạn có một Skill tài chính cho các truy vấn tài chính, nó có đọc tệp FORMATTING.md đặc biệt không?

Cũng có các đánh giá cho các Skill kiểm tra việc hoàn thành tác vụ đầu cuối trong các miền. Chúng tôi chạy vòng lặp tác nhân đầy đủ và sử dụng trọng tài LLM để chấm điểm kết quả dựa trên một tiêu chí được xác định rõ ràng.

Cuối cùng, điều quan trọng là chạy các bài đánh giá này đối với các mô hình khác nhau. Computer hỗ trợ ít nhất ba họ mô hình điều phối khác nhau: GPT, Claude Opus và Claude Sonnet. Bạn muốn chạy việc tải Skill và các Skill miền đối lập với các bộ điều phối tác nhân này để đảm bảo rằng bạn không nhận được hành vi khác nhau. Sonnet và GPT hành xử khá khác nhau khi nói đến các Skill.

Suy nghĩ cuối cùng và bài học rút ra

Càng xây dựng nhiều Skill, bạn càng trở nên giỏi hơn trong việc xây dựng chúng. Nếu bạn không tự động hóa hoặc cố gắng làm cho các tác vụ bạn đang làm hàng ngày có thể tái tạo nhiều hơn bằng cách sử dụng các Skill, hãy bắt đầu ngay lập tức.

Hành động xây dựng các Skill giúp bạn giỏi hơn trong việc xây dựng nhiều Skill hơn, ngoài ra, chúng cực kỳ tốt trong việc tự động hóa các quy trình kinh doanh. Nếu bạn có thể mô tả một việc gì đó bạn làm mỗi tuần trước buổi họp đứng (standup), vào cuối mỗi sprint, hoặc bất kỳ việc gì bạn làm với tư cách là một kỹ sư hàng ngày, hàng tuần hoặc thậm chí hàng quý, bạn nên viết một Skill để mua lại thời gian của chính mình.

Bạn có thể tự động hóa việc phân tích nguyên nhân sự cố sau khi kết thúc (postmortems)? Bạn có thể xem xét các yêu cầu kéo không? Bất kỳ tác vụ nào bạn có thể làm, bạn ít nhất có thể có lượt đầu tiên là một Agent Skill. Nó sẽ giúp bạn tiết kiệm thời gian đáng kể.

Điều đó nói lên rằng, hãy nhớ rằng một Skill không hề dễ dàng hoặc thậm chí không phải lúc nào cũng cần thiết. Ít hơn là nhiều hơn. Một số bài học rút ra khác:

Viết các bài đánh giá trước Skill. Bao gồm các ví dụ tiêu cực và các lượt tải bị cấm đối với các kỹ năng liền kề nhưng khác biệt.

Mô tả là phần khó. "Tải khi..." (mọi từ đều tốn sự chú ý).

Cạm bẫy là nội dung có giá trị cực cao. Bắt đầu mỏng, phát triển khi tác nhân thất bại.

Hãy nhớ rằng rất dễ phá vỡ các Skill có từ trước bằng cách thêm một Skill mới, mặc dù bạn không chạm vào nó (hãy cẩn thận với tác động từ xa).

Sử dụng tất cả các công cụ có sẵn mỗi khi bạn viết và duy trì một Skill. Nếu bạn muốn tìm hiểu thêm, trang web Agent Skills có rất nhiều ví dụ hay, và cả kho lưu trữ nội bộ của chúng tôi lẫn hệ sinh thái công cộng đều chứa nhiều ví dụ về các Skill được thiết kế tốt.

Trích dẫn

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}