LangChain đã huy động được 160 triệu đô la. Ba năm phát triển. Định giá hàng tỷ đô la. LangSmith, nền tảng thử nghiệm của họ, thực sự tinh vi: đánh giá quỹ đạo, quy trình từ dấu vết đến tập dữ liệu, LLM làm giám khảo, bộ hồi quy, khung kiểm thử đơn vị cho các công cụ. Họ có đầy đủ các mảnh ghép. Công lao ở đâu thì nên được ghi nhận ở đó.
Nhưng các mảnh ghép không phải là một quy trình thực hành.
LangChain cung cấp cho bạn các công cụ kiểm thử. Nó không bao giờ cho bạn biết nên kiểm tra cái gì, theo thứ tự nào, hoặc khi nào thì hoàn thành.
Không có một quy trình làm việc có chủ kiến nào nói rằng, theo thứ tự:
- lỗi này đã xảy ra
- bây giờ hãy viết một kỹ năng
- bây giờ hãy viết mã xác định
- bây giờ hãy viết kiểm thử đơn vị
- bây giờ hãy viết đánh giá LLM
- bây giờ hãy thêm một trình kích hoạt giải quyết
- bây giờ hãy đánh giá trình giải quyết
- bây giờ hãy kiểm tra trùng lặp
- bây giờ hãy kiểm tra khói
- bây giờ hãy phân loại chính xác
Vòng lặp đó không tồn tại. Bạn phải tự phát minh ra nó từ các nguyên thủy rời rạc. Rất nhiều người dùng AI vẫn không kiểm thử các tác nhân của họ chút nào, bởi vì khuôn khổ họ chọn có thể đã cho họ một thẻ tập gym mà không có một kế hoạch tập luyện.
Hầu hết "độ tin cậy" của tác nhân AI đều dựa trên cảm tính. Chỉnh sửa lời nhắc. Tin nhắn hệ thống lớn hơn. Những câu thần chú "Làm ơn đừng ảo giác". Những thứ đó sẽ suy giảm ngay khi cuộc trò chuyện trở nên phức tạp. Các khuôn khổ đã huy động hàng trăm triệu đô la để giải quyết vấn đề này đã cho bạn bảng điều khiển giám sát và các trình trợ giúp kiểm thử đơn vị và nói "chúc may mắn."
Tác nhân của tôi đã mắc lỗi hai lần trong tuần này. Cả hai lỗi đều không thể xảy ra lần nữa. Không phải vì tôi đã yêu cầu một cách tử tế. Mà vì tôi đã biến mỗi lỗi thành một bản sửa lỗi cấu trúc vĩnh viễn: một kỹ năng với các bài kiểm tra chạy mỗi ngày, mãi mãi.
Tôi gọi quy trình thực hành này là "skillify." Một khi bạn sử dụng nó, các tác nhân của bạn sẽ không tiếp tục mắc những sai lầm giống nhau. Đây là cách nó hoạt động.
Lỗi 1: Chuyến Công Tác Đã Có Trong Cơ Sở Dữ Liệu
Tôi hỏi OpenClaw của tôi về một chuyến công tác cũ, gần mười năm trước, bị chôn vùi đâu đó trong lịch sử lịch. Một câu hỏi đơn giản. Lẽ ra chỉ mất một giây.
Thay vào đó, tác nhân đã làm điều này:
- Gọi API lịch trực tiếp → bị chặn (quá xa về quá khứ).
- Thử tìm kiếm email → kết quả nhiễu, không có gì kết luận được.
- Thử lại API lịch với các tham số khác → vẫn bị chặn.
- Năm phút sau, tìm kiếm cơ sở kiến thức cục bộ của tôi và tìm thấy nó ngay lập tức.
Câu trả lời đã nằm trong dữ liệu của chính tôi suốt thời gian qua. 3.146 tệp lịch trải dài từ 2013 đến 2026. Đã được lập chỉ mục. Đã ở cục bộ. Chỉ cần một lệnh grep.
Tác nhân chỉ đơn giản là không tìm ở đó trước.
Trong khuôn khổ mà tôi đã viết về (thin harness, fat skills), có một sự khác biệt chính giữa công việc đòi hỏi sự phán đoán và công việc đòi hỏi độ chính xác. Tôi gọi chúng là tiềm ẩn và xác định. Grep lịch là xác định. Cùng đầu vào, cùng đầu ra, mọi lúc. Không cần mô hình. Nhưng tác nhân đã làm điều đó trong không gian tiềm ẩn, khởi động suy luận, thực hiện các cuộc gọi API, diễn giải kết quả, trong khi một tập lệnh ba dòng sẽ trả về câu trả lời ngay lập tức.
Đó là lỗi. Không phải một câu trả lời sai. Mà là một khía cạnh sai.
Cách khắc phục: calendar-recall (Bước 1 + 2)
Trong thin harness / fat skills, một kỹ năng là một quy trình markdown dạy cho mô hình cách tiếp cận một nhiệm vụ. Không phải làm gì (người dùng cung cấp cái gì). Kỹ năng cung cấp quy trình. Hãy nghĩ về nó như một lệnh gọi phương thức: cùng một quy trình, đầu ra hoàn toàn khác nhau tùy thuộc vào những gì bạn truyền vào.
Đây là kỹ năng ra đời từ lỗi này:
tên: calendar-recall mô tả: "Tra cứu lịch sử lịch ưu tiên não bộ. LUÔN LUÔN sử dụng cái này trước bất kỳ API trực tiếp nào cho bất kỳ sự kiện nào không phải trong tương lai hoặc 48 giờ qua."
Và quy tắc cứng bên trong:
API lịch trực tiếp CHỈ dành cho các sự kiện trong TƯƠNG LAI hoặc 48 GIỜ QUA. Mọi thứ lịch sử đều phải thông qua cơ sở kiến thức cục bộ trước.
Đây là điều làm cho điều này hoạt động: chính tác nhân đã viết tập lệnh xác định. Tệp kỹ năng (markdown, sống trong không gian tiềm ẩn) đã nói cho tác nhân cách khắc phục sự cố. Tác nhân đọc kỹ năng, hiểu rằng tìm kiếm lịch là công việc xác định và tạo ra một tập lệnh để xử lý nó:
$ node scripts/calendar-recall.mjs search "Singapore"
Đã tìm thấy 2 ngày phù hợp: ── 2016-05-07 ── Chuyến bay đến Singapore, nhận phòng Mandarin Oriental ── 2016-05-08 ── Ăn trưa với các nhà đầu tư tại khách sạn Fullerton
Mã chạy trong vòng chưa đầy 100 mili giây (hầu hết là thời gian khởi động Bun; grep thực tế là dưới mili giây). Không có cuộc gọi LLM. Không có mạng. Chỉ là các tệp cục bộ.
Đây là vòng lặp làm cho toàn bộ kiến trúc hoạt động: không gian tiềm ẩn xây dựng công cụ xác định, sau đó công cụ xác định ràng buộc không gian tiềm ẩn. Tác nhân đã sử dụng phán đoán (tiềm ẩn) để viết calendar-recall.mjs. Bây giờ kỹ năng buộc tác nhân phải chạy tập lệnh đó thay vì suy luận về dữ liệu lịch. Trí thông minh của mô hình đã tạo ra ràng buộc ngăn mô hình trở nên ngu ngốc.
Đường dẫn lỗi cũ trở nên không thể truy cập được về mặt cấu trúc. Kỹ năng nói "tìm kiếm cục bộ trước." Tập lệnh thực hiện tìm kiếm. Tác nhân không bao giờ có cơ hội tỏ ra thông minh về nó hoặc mắc lỗi lần nữa.
Lỗi 2: "28 Phút" (Lại Bước 1 + 2)
Cùng ngày. Tác nhân nói: "Cuộc họp tiếp theo của bạn là trong 28 phút nữa."
Thực tế: Còn 88 phút nữa. Tác nhân đã tính toán múi giờ UTC→PT trong đầu và sai chính xác một giờ.
Vấn đề là, một tập lệnh đã tồn tại (context-now.mjs) xuất ra kết quả này:
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "Lập Kế Hoạch Sprint Ops Ứng Dụng", "minutesUntil": 88 }] }
Mã chạy trong khoảng 50 mili giây. Không có sự mơ hồ. Tác nhân chỉ đơn giản là không chạy nó.
Cùng hình dạng như trước: công việc xác định (trừ dấu thời gian) được thực hiện trong không gian tiềm ẩn. Mô hình đang làm toán trong đầu khi một tập lệnh đã có câu trả lời.
Cách khắc phục: context-now, kỹ năng:
tên: context-now mô tả: "Kỷ luật LUÔN BẬT: chạy context-now.mjs trước khi đưa ra BẤT KỲ tuyên bố nào nhạy cảm về thời gian. Không bao giờ thực hiện chuyển đổi UTC→PT trong đầu của bạn."
Đây là sự so sánh đơn giản trước và sau khi có và không có các kỹ năng đơn giản này:
Skillify: Mô hình sẽ cứu sự tỉnh táo của bạn
Hai lỗi. Cùng một hình dạng. Tác nhân có công cụ phù hợp và chọn sự thông minh thay vì kỷ luật. Điều sai đã xảy ra trong không gian máy móc sai.
Trong một thiết lập AI bình thường, AI sẽ xin lỗi, hứa sẽ làm tốt hơn, và hai tuần sau điều tương tự lại xảy ra với một truy vấn khác hoặc một múi giờ khác. Tác nhân không có bộ nhớ về lỗi, không có bài kiểm tra cho lỗi, không có gì ngăn nó tái diễn.
Skillify là cách khắc phục. Mọi lỗi đều trở thành một kỹ năng. Mọi kỹ năng đều có bài kiểm tra. Lỗi trở nên không thể lặp lại về mặt cấu trúc.
Đây là danh sách kiểm tra 10 mục tôi sử dụng khi một lỗi được thăng cấp:
□ 1. SKILL.md — hợp đồng (tên, trình kích hoạt, quy tắc) □ 2. Mã xác định — scripts/*.mjs (không có LLM cho những gì mã có thể làm) □ 3. Kiểm thử đơn vị — vitest □ 4. Kiểm thử tích hợp — điểm cuối trực tiếp □ 5. Đánh giá LLM — chất lượng + tính đúng đắn □ 6. Trình kích hoạt giải quyết — mục nhập trong AGENTS.md □ 7. Đánh giá trình giải quyết — xác minh trình kích hoạt thực sự định tuyến □ 8. Kiểm tra có thể giải quyết + kiểm tra DRY □ 9. Kiểm tra khói E2E □ 10. Quy tắc phân loại não bộ
Một tính năng không vượt qua tất cả mười mục không phải là một kỹ năng. Nó chỉ là mã tình cờ hoạt động hôm nay.
Hai lỗi trên đã đi qua các bước 1 và 2: viết SKILL.md (hợp đồng), sau đó viết mã xác định (tập lệnh mà tác nhân xây dựng và sau đó sử dụng). Nhưng trước khi tôi đi qua tám bước còn lại, tôi muốn cho bạn thấy skillify trông như thế nào trong sử dụng hàng ngày, bởi vì nó không chỉ là một phản ứng đối với thất bại. Nó đã trở thành một động từ.
Skillify như một động từ
Đối với tôi, khi xây dựng OpenClaw (và GBrain) của mình, danh sách kiểm tra bắt đầu như một giao thức phản ứng với lỗi. Sau đó, nó trở thành cách tôi xây dựng mọi thứ.
Đây là quy trình làm việc thực tế của tôi. Tôi đang nói chuyện với tác nhân của mình bằng ngôn ngữ tự nhiên. Chúng tôi cùng nhau xây dựng một thứ gì đó trong cuộc trò chuyện. Tôi thử nó. Nó hoạt động. Sau đó tôi nói một từ:
Garry:
tuyệt vời nó đã hoạt động. bạn có thể nhớ cái này như một kỹ năng webhook và skillify nó không, lần sau khi chúng ta cần làm một số webhook? tại sao cái này lại khó làm đúng như vậy? dù sao thì bây giờ nó tốt rồi. hãy DRY nó lên nữa
Đó là một tích hợp webhook OAuth. Chúng tôi đã dành một giờ để làm cho nó hoạt động. Sau đó "skillify nó" đã biến phiên ad-hoc thành một kỹ năng bền vững với các bài kiểm tra, một mục nhập giải quyết và tài liệu. Lần tới khi tôi cần một webhook, kỹ năng sẽ tồn tại. Tác nhân đọc nó. Kiến thức khó kiếm được từ giờ đó là vĩnh viễn.
Một cái khác. Chúng tôi phát hiện ra rằng container của chúng tôi cần một trình duyệt không đầu cho một số tác vụ nhất định và một trình duyệt có đầu trên máy tính để bàn của tôi cho những tác vụ khác:
Garry:
tuyệt vời! vậy chúng ta thực sự nên nhớ điều này như một kỹ năng bất cứ khi nào bất cứ thứ gì trong openclaw cần một trình duyệt không đầu! và cũng biết rằng nếu chúng ta cần một trình duyệt có đầu, chúng ta nên yêu cầu người dùng chạy gstack browser và cung cấp cho chúng tôi một mã đối tác. skillify nó!
Một tin nhắn. Tác nhân viết skills/browser/SKILL.md với cây quyết định, các tập lệnh xác định, các bài kiểm tra. Bây giờ mọi phiên trong tương lai cần một trình duyệt sẽ được định tuyến đến công cụ phù hợp một cách tự động.
Hoặc cái này. Tôi nhận thấy tác nhân liên tục gửi cho tôi các liên kết ngrok mà không kiểm tra xem chúng có thực sự hoạt động không:
Garry:
chúng ta có thể tạo một kỹ năng nói rằng bất cứ khi nào bạn gửi cho tôi một liên kết, bạn phải tự curl nó để đảm bảo điểm cuối đang mở và đường hầm hoạt động? skillify nó!
Hoặc việc đặt lịch trùng gần như khiến tôi lỡ một cuộc họp:
Garry:
Đây là một kỹ năng thông thường tôi cần bạn viết. Đó là kỹ năng kiểm tra lịch. Ngày mai tôi có một cuộc họp lúc 11 giờ sáng bị trùng lịch. Hãy tạo một kỹ năng, làm cho nó xác định để kiểm tra những loại điều này.
Một câu. Mã, kỹ năng, bài kiểm tra, mục nhập giải quyết, kiểm tra khả năng tiếp cận. Toàn bộ danh sách kiểm tra 10 bước trong một hơi thở. OpenClaw của tôi biết, làm điều đó, và bây giờ nó là một rãnh. Tôi đã làm điều đó hàng chục lần. Tôi không thể sống thiếu nó.
Mô hình luôn giống nhau: tạo nguyên mẫu trong cuộc trò chuyện, thấy nó hoạt động, nói "skillify," và nguyên mẫu trở thành cơ sở hạ tầng vĩnh viễn. Tôi không viết đặc tả. Tôi không gửi ticket. Tôi nói chuyện với tác nhân của mình, chúng tôi cùng nhau giải quyết vấn đề, và sau đó giải pháp trở thành một kỹ năng mà tác nhân có thể sử dụng mãi mãi mà không cần tôi.
Đây là những gì 160 triệu đô la tài trợ cho khuôn khổ đã bỏ lỡ. Không phải các nguyên thủy kiểm thử. Không phải công cụ đánh giá. Mà là quy trình làm việc. Khoảnh khắc một con người nói "cái đó đã hoạt động, bây giờ hãy làm cho nó vĩnh viễn" và hệ thống biết chính xác "vĩnh viễn" có nghĩa là gì: SKILL.md, mã xác định, kiểm thử đơn vị, kiểm thử tích hợp, đánh giá LLM, trình kích hoạt giải quyết, đánh giá trình giải quyết, kiểm tra DRY, kiểm tra khói, phân loại não bộ. Mười bước. Một từ.
Đây là những gì tám bước còn lại trông như thế nào trong thực tế.
Bước 3: Kiểm thử đơn vị
Vitest cổ điển. Các hàm xác định, các khẳng định xác định. calendar-recall.mjs xuất các hàm thuần túy như parseEventLine, eventMatchesKeyword, searchKeyword, formatJson. Mỗi hàm được kiểm tra với dữ liệu giả định: các tệp lịch tổng hợp trong một thư mục tạm thời, đầu vào đã biết, đầu ra đã biết.
Loại lỗi mà những bài kiểm tra này phát hiện: parseEventLine âm thầm loại bỏ các sự kiện có ký tự Unicode trong trường vị trí. dateFromPath trả về null cho các ngày trong năm nhuận. formatJson bỏ qua mảng attendees khi chỉ có một người. Nhỏ, nhàm chán, quan trọng. Nếu tập lệnh tạo ra đầu ra sai, kỹ năng tạo ra câu trả lời sai và tác nhân tự tin nói với tôi điều sai.
Đối với context-now, kiểm thử đơn vị xác minh định dạng múi giờ, phát hiện giờ yên tĩnh và tính toán minutesUntil qua các ranh giới DST. Một bài kiểm tra đưa vào một thời điểm 3 phút trước khi chuyển đổi DST và xác minh đầu ra không nhảy vọt 60 phút. Đó chính xác là lỗi đã gây ra sự cố "28 phút". Bây giờ nó không thể xảy ra về mặt cấu trúc.
Tôi có 179 bài kiểm thử đơn vị trên 5 bộ. Chúng chạy trong vòng chưa đầy 2 giây.
Bước 4: Kiểm thử tích hợp
Những bài kiểm tra này truy cập các điểm cuối trực tiếp và dữ liệu thực. calendar-recall.mjs có thực sự tìm thấy các sự kiện trong kho lưu trữ não bộ thực, không chỉ các dữ liệu giả định? context-now.mjs có tạo ra JSON hợp lệ khi bộ nhớ đệm lịch bị cũ hoặc bị thiếu không? Kiểm thử tích hợp phát hiện các lỗi mà kiểm thử đơn vị bỏ sót vì dữ liệu giả định quá sạch. Dữ liệu thực có các dòng sự kiện bị định dạng sai, các trường múi giờ bị thiếu, các tệp lịch có kết thúc dòng kiểu Windows, các sự kiện kéo dài qua nửa đêm.
Quy tắc: nếu bạn thấy mình đang kiểm tra thủ công xem tập lệnh đã làm đúng trên dữ liệu thực hay chưa, thì việc kiểm tra đó nên là một bài kiểm thử tích hợp.
Bước 5: Đánh giá LLM
Đây là nơi nó trở nên thú vị. Một số đầu ra đòi hỏi sự phán đoán để đánh giá. "Bản tóm tắt lịch này có hữu ích không?" không phải là một câu hỏi có/không mà một tập lệnh có thể trả lời. Vì vậy, tôi sử dụng LLM làm giám khảo: một mô hình đánh giá đầu ra của một mô hình khác dựa trên một tiêu chí.
Đối với context-now, 35 bài đánh giá chạy hàng ngày. Một trong số đó đưa cho tác nhân một tin nhắn như "này, chuyến bay của tôi khởi hành trong khoảng 45 phút nữa, liệu tôi có kịp đến SFO không?" và kiểm tra xem tác nhân có chạy context-now.mjs trước khi trả lời hay cố gắng tự tính toán trong đầu. Nếu tác nhân mắc bẫy và tự tính thời gian, bài đánh giá sẽ thất bại.
Một bài đánh giá khác đưa cho tác nhân một dấu thời gian UTC và hỏi "mấy giờ đó đối với tôi?" Hành vi đúng là chạy tập lệnh và trích dẫn kết quả. Hành vi sai là thực hiện chuyển đổi trong đầu. Bài đánh giá phát hiện cả câu trả lời sai VÀ quy trình sai, bởi vì ngay cả khi phép tính trong đầu tình cờ đúng lần này, nó sẽ sai vào lần sau.
Phương pháp phỏng đoán đánh giá trung thực nhất mà tôi tìm thấy: tìm kiếm lịch sử trò chuyện của bạn để biết khi nào bạn nói "mẹ kiếp" hoặc "wtf." Đó là những trường hợp kiểm tra bạn đang thiếu.
Bước 6: Trình kích hoạt giải quyết
Một trình giải quyết là một bảng định tuyến cho ngữ cảnh: khi loại nhiệm vụ X xuất hiện, hãy tải kỹ năng Y. Tôi đã viết chi tiết về các trình giải quyết tại đây. Mỗi kỹ năng cần một mục nhập kích hoạt trong AGENTS.md, tệp dạy cho tác nhân biết những kỹ năng nào tồn tại và khi nào sử dụng chúng.
Trình kích hoạt giải quyết chỉ là các hàng trong một bảng markdown:
Lỗi mà bước này phát hiện: bạn viết một kỹ năng mới nhưng quên thêm nó vào trình giải quyết. Kỹ năng tồn tại. Khả năng tồn tại. Hệ thống không thể truy cập nó. Giống như có một bác sĩ phẫu thuật trong đội ngũ nhân viên nhưng không liệt kê họ trong danh bạ bệnh viện. Tệ hơn cả việc không có kỹ năng, bởi vì bạn nghĩ hệ thống xử lý được nó.
Bước 7: Đánh giá trình giải quyết
Đây là lớp mà hầu hết mọi người bỏ lỡ hoàn toàn. Một trình kích hoạt giải quyết nói "cụm từ này sẽ định tuyến đến kỹ năng này." Một đánh giá trình giải quyết kiểm tra xem nó có thực sự làm như vậy không.
Bộ đánh giá trình giải quyết của tôi có hơn 50 trường hợp kiểm tra như thế này:
{ ý định: 'kiểm tra chữ ký của tôi', kỹ năng dự kiến: 'trợ-lý-điều-hành' }, { ý định: 'Pedro Franceschi là ai', kỹ năng dự kiến: 'vận-hành-não-bộ' }, { ý định: 'lưu bài viết này', kỹ năng dự kiến: 'tiếp-nhận-ý-tưởng' }, { ý định: 'cuộc họp của tôi lúc mấy giờ', kỹ năng dự kiến: 'ngữ-cảnh-ngay' }, { ý định: 'tìm chuyến đi năm 2016 của tôi', kỹ năng dự kiến: 'tra-cứu-lịch' },
Hai chế độ lỗi. Âm tính giả: kỹ năng lẽ ra phải kích hoạt nhưng không, vì mô tả kích hoạt sai hoặc bị thiếu. Dương tính giả: kỹ năng sai kích hoạt, vì hai trình kích hoạt chồng chéo. "Ngày mai có gì trong lịch của tôi" nên định tuyến đến kiểm-tra-lịch, không phải tra-cứu-lịch và không phải google-lịch. Ba kỹ năng, ba miền thời gian khác nhau, một cụm từ có thể khớp với bất kỳ cái nào trong số chúng. Đánh giá trình giải quyết phát hiện sự mơ hồ trước khi người dùng gặp phải.
Tôi chạy các đánh giá này vừa là kiểm tra cấu trúc xác định (bảng AGENTS.md có chứa ánh xạ chính xác không?) vừa là kiểm tra định tuyến LLM (với ý định này, mô hình có thực sự chọn đúng kỹ năng không?). Cả hai lớp đều quan trọng. Bảng có thể đúng và mô hình vẫn có thể định tuyến sai vì mô tả kích hoạt mơ hồ.
Bước 8: Kiểm tra có thể giải quyết + kiểm tra DRY
Sau một tháng xây dựng, tôi đã có hơn 40 kỹ năng. Một số được tạo ra để đáp ứng các sự cố cụ thể, những kỹ năng khác được sinh ra bởi các tác nhân phụ chạy cron. Không ai duy trì bảng giải quyết. Các kỹ năng đang được sinh ra nhưng không được đăng ký.
Vì vậy, tôi đã xây dựng check-resolvable. Một siêu kiểm tra đi qua toàn bộ chuỗi: AGENTS.md resolver → SKILL.md → script/cron. Nếu một tập lệnh tồn tại thực hiện công việc hữu ích nhưng không có đường dẫn từ trình giải quyết, nó không thể truy cập được. LLM sẽ không bao giờ biết để sử dụng nó.
Lần chạy đầu tiên tìm thấy 6 kỹ năng không thể truy cập trong số hơn 40+. Mười lăm phần trăm khả năng của hệ thống đã bị tối.
- Một trình theo dõi chuyến bay mà không ai có thể gọi bằng cách hỏi về các chuyến bay.
- Một trình tạo ý tưởng nội dung chỉ chạy trên cron nhưng không thể được kích hoạt thủ công.
- Một trình sửa trích dẫn tồn tại trong thư mục kỹ năng nhưng không được liệt kê trong trình giải quyết chút nào.
Đã sửa trong một giờ. Chỉ cần thêm các mục nhập kích hoạt vào AGENTS.md. Bây giờ check-resolvable chạy hàng tuần như một phần của gbrain doctor. Nó kiểm tra ba điều:
- Mọi thư mục kỹ năng có SKILL.md đều có một mục nhập tương ứng trong trình giải quyết.
- Mọi tập lệnh được tham chiếu bởi một kỹ năng đều có thể gọi được (tệp tồn tại, xuất các hàm chính xác).
- Không có hai kỹ năng nào có mô tả kích hoạt chồng chéo có thể gây ra định tuyến mơ hồ.
Kiểm tra DRY chạy song song. Bạn sẽ kết thúc với mười lăm kỹ năng đại loại làm cùng một việc nếu bạn không cẩn thận, và trình giải quyết sẽ chọn bất kỳ cái nào mà viên xúc xắc rơi trúng. Đối với calendar-recall:
Bốn kỹ năng trong cùng một miền. Không có sự chồng chéo. Mỗi cái có làn đường riêng. Ma trận đó không phải là một sơ đồ được vẽ cho bài đăng này. Nó nằm bên trong SKILL.md, và tập lệnh kiểm tra phân tích cú pháp nó. Xây dựng một kỹ năng lịch thứ sáu xâm phạm làn đường của kỹ năng khác và quá trình kiểm tra sẽ thất bại trước khi kỹ năng có thể được phát hành.
Bước 9: Kiểm tra khói E2E
Toàn bộ đường ống, từ đầu đến cuối.
- Hỏi tác nhân "khi nào tôi đã đi Singapore?" và xác minh rằng nó chạy calendar-recall.mjs, nhận được câu trả lời đúng và định dạng nó chính xác.
- Hỏi "cuộc họp tiếp theo của tôi lúc mấy giờ?" và xác minh nó chạy context-now.mjs thay vì làm toán trong đầu.
Kiểm tra khói là tuyến phòng thủ cuối cùng. Mọi thứ khác có thể vượt qua và hệ thống vẫn có thể thất bại nếu các mảnh ghép không kết nối với nhau. Kỹ năng có thể đúng, tập lệnh có thể đúng, trình giải quyết có thể đúng, và tác nhân vẫn có thể chọn bỏ qua tất cả và ứng biến. Kiểm tra khói phát hiện điều đó.
Bước 10: Quy tắc phân loại não bộ
Mọi kỹ năng ghi vào cơ sở kiến thức cần biết mọi thứ sẽ đi đâu. Một người đi vào people/. Một công ty đi vào companies/. Một phân tích chính sách đi vào civic/. Tôi đã phát hiện 10 trong số 13 kỹ năng viết não bộ đang phân loại sai thư mục vì mỗi kỹ năng đã tự mã hóa cứng đường dẫn của riêng chúng thay vì tham khảo trình giải quyết.
Tài liệu quy tắc phân loại lập danh mục các mẫu phân loại sai phổ biến. Nguồn so với bản gốc. Người so với công ty (khi ai đó LÀ một công ty). Kỹ năng đọc các quy tắc trước khi tạo bất kỳ trang nào. Không có phân loại sai nào kể từ đó.
GBrain: Nơi Skillify sống, và bạn nên áp dụng nó từ Gói Kỹ Năng GBrain của tôi
Mô hình skillify không dành riêng cho OpenClaw hoặc bất kỳ harness cụ thể nào. Nó được xây dựng trong GBrain. GBrain là công cụ kiến thức mã nguồn mở mà tôi đã viết nằm bên dưới bất kỳ harness nào bạn sử dụng. Nó quản lý kho lưu trữ não bộ của bạn, chạy các đánh giá của bạn và thực thi các cổng chất lượng làm cho các kỹ năng trở nên bền vững.
Một GBrain SkillPack là một gói di động gồm các kỹ năng, trình kích hoạt giải quyết, tập lệnh xác định và bài kiểm tra mà bạn có thể cài đặt vào bất kỳ thiết lập tác nhân nào chỉ bằng cách yêu cầu OpenClaw/Hermes Agent làm điều đó. Đó là cách các kỹ năng và khả năng tôi đã viết cho OpenClaw/Hermes Agent của tôi có thể được tự động thêm vào OpenClaw CỦA BẠN — bao gồm toàn bộ đầu ra skillify 10 bước, được đóng gói để bạn có thể thả nó vào OpenClaw/Hermes Agent của mình và nó hoạt động ngay lập tức.
Danh sách kiểm tra skillify từ trước đó không phải là một gợi ý. Đó là những gì gbrain doctor thực sự kiểm tra.
gbrain doctor --fix tự động sửa chữa các vi phạm DRY, thay thế các khối trùng lặp bằng các tham chiếu quy ước, tất cả đều được bảo vệ bởi các kiểm tra cây làm việc git để không có gì bị ghi đè.
Tại sao Hermes Agent một mình là không đủ
Hermes Agent từ Nous Research làm một điều thực sự tuyệt vời: nó có một công cụ skill_manage cho phép chính tác nhân tạo, vá và xóa các kỹ năng dựa trên những gì nó học được. Khi tác nhân hoàn thành một nhiệm vụ phức tạp hoặc phục hồi sau lỗi, nó đề xuất một kỹ năng và ghi nó vào đĩa. Đó là bộ nhớ thủ tục mà tác nhân tự kiếm được. Tiết lộ dần dần (tải một chỉ mục kỹ năng trước, kéo SKILL.md đầy đủ chỉ khi được chọn). Bộ nhớ có giới hạn (MEMORY.md giới hạn ở 2.200 ký tự). Kích hoạt có điều kiện (các kỹ năng tự động ẩn khi các công cụ cần thiết không có sẵn). Thiết kế thông minh.
Nhưng Hermes không kiểm tra các kỹ năng của nó. Không có kiểm thử đơn vị trên mã xác định. Không có đánh giá trình giải quyết để xác minh định tuyến. Không có check-resolvable để tìm các kỹ năng tối. Không có kiểm tra DRY để phát hiện trùng lặp. Không có kiểm tra sức khỏe hàng ngày chuyển sang màu đỏ khi có thứ gì đó trôi dạt.
Các chế độ lỗi mà tôi đã thấy tích lũy trong bất kỳ hệ thống kỹ năng chưa được kiểm tra nào:
- Tác nhân tạo deploy-k8s vào Thứ Hai. Thứ Năm, nó tạo kubernetes-deploy từ một cuộc trò chuyện khác. Cả hai đều tồn tại. Cả hai đều kích hoạt trên các cụm từ tương tự. Định tuyến mơ hồ, và không ai nhận ra cho đến khi cái sai kích hoạt vào sai thời điểm.
- Kỹ năng hoạt động hoàn hảo khi được viết. Sáu tuần sau, API thượng nguồn thay đổi hình dạng. Kỹ năng âm thầm trả về rác cho đến khi một con người phát hiện ra nó.
- Một kỹ năng được tạo tự động có một trình kích hoạt yếu không bao giờ khớp. Nó trở thành một đứa trẻ mồ côi, tiêu thụ token chỉ mục, không bao giờ chạy, từ từ mục nát.
Đây là vấn đề "không có kiểm tra, bất kỳ cơ sở mã nào cũng mục nát" mà kỹ thuật phần mềm đã giải quyết vào năm 2005. Các kỹ năng tác nhân cũng không khác. Hermes xử lý việc tạo ra một cách đẹp đẽ. GBrain xử lý việc xác minh. Bạn cần cả hai.
Ý tưởng lớn
Trong một nhóm kỹ thuật phần mềm lành mạnh, mọi lỗi đều có một bài kiểm tra. Bài kiểm tra đó tồn tại mãi mãi. Lỗi trở nên không thể tái diễn về mặt cấu trúc. Các tác nhân AI nên hoạt động theo cùng một cách.
Mọi lỗi đều trở thành một kỹ năng. Mọi kỹ năng đều có đánh giá. Mọi đánh giá đều chạy hàng ngày. Sự phán đoán của tác nhân được cải thiện vĩnh viễn, không chỉ cho phiên hiện tại, không chỉ trong khi cửa sổ ngữ cảnh còn giữ.
Lỗi chuyến đi sẽ không xảy ra nữa. Lỗi múi giờ sẽ không xảy ra nữa. Và khi lỗi tiếp theo xuất hiện (và nó sẽ xuất hiện, bởi vì đây là một trò chơi đối nghịch chống lại entropy và thị hiếu), nó cũng sẽ được skillified.
Tác nhân mà tôi làm việc cùng một năm kể từ bây giờ sẽ được định hình bởi mọi sai lầm nó đã mắc phải trong năm trước. Đó không phải là một thứ tốt để có. Đó là toàn bộ luận điểm.
Hãy làm mọi thứ. Làm cho tác nhân của bạn làm một cái gì đó, sau đó skillify nó. Bạn làm điều đó mỗi ngày và bạn có một OpenClaw thông minh chết tiệt làm mọi thứ bạn muốn nó làm.
Hoặc bạn có thể chỉ cần tải GBrain, sử dụng tất cả mã tôi đã viết và bỏ qua để đến Jarvis của riêng bạn từ Iron Man sớm hơn.
--
GStack để tăng tốc trong Claude Code github.com/garrytan/gstack
GBrain để xây dựng Jarvis của riêng bạn từ Iron Man trong OpenClaw/Hermes Agent github.com/garrytan/gbrain
