LangChain ระดมทุนได้ 160 ล้านดอลลาร์ สามปีแห่งการพัฒนา มูลค่าบริษัทระดับพันล้านดอลลาร์ LangSmith แพลตฟอร์มทดสอบของพวกเขานั้นล้ำสมัยจริง ๆ: การประเมินวิถี (trajectory evals), ไพพไลน์จาก trace สู่ dataset, LLM-as-judge, ชุดการทดสอบการถดถอย (regression suites), กรอบการทดสอบหน่วยย่อยสำหรับเครื่องมือ พวกเขามีส่วนประกอบทุกอย่าง ให้เครดิตตามสมควร
แต่ส่วนประกอบไม่ใช่แนวปฏิบัติ
LangChain ให้เครื่องมือทดสอบ แก่คุณ มันไม่เคยบอกว่าควรทดสอบอะไร ในลำดับไหน หรือเมื่อไหร่ถึงจะเสร็จ
ไม่มีเวิร์กโฟลว์ที่ชัดเจนที่บอกว่า ตามลำดับ:
- เกิดความล้มเหลวนี้ขึ้น
- ตอนนี้เขียนสกิล
- ตอนนี้เขียนโค้ดที่แน่นอน (deterministic code)
- ตอนนี้เขียน unit tests
- ตอนนี้เขียน LLM evals
- ตอนนี้เพิ่ม resolver trigger
- ตอนนี้ประเมิน resolver
- ตอนนี้ตรวจสอบความซ้ำซ้อน
- ตอนนี้ทำ smoke test
- ตอนนี้จัดเก็บให้ถูกต้อง
ลูปนั้นไม่มีอยู่จริง คุณต้องประดิษฐ์มันขึ้นมาเองจากส่วนย่อยที่กระจัดกระจาย ผู้ใช้ AI จำนวนมากยังคงไม่ทดสอบเอเยนต์ของพวกเขาเลย เพราะ เฟรมเวิร์กที่พวกเขาเลือกน่าจะให้สมาชิกฟิตเนสแต่ไม่มีแผนการออกกำลังกาย
ความ "น่าเชื่อถือ" ของเอเยนต์ AI ส่วนใหญ่เป็นแบบ vibes-based การปรับแต่งพรอมต์ ข้อความระบบให้ใหญ่ขึ้น การสวดมนต์ "กรุณาอย่า hallucinate" สิ่งเหล่านั้นเสื่อมลงทันทีที่บทสนทนาซับซ้อนขึ้น เฟรมเวิร์กที่ระดมทุนหลายร้อยล้านดอลลาร์เพื่อแก้ปัญหานี้ให้แดชบอร์ดมอนิเตอร์และตัวช่วย unit test แล้วพูดว่า "ขอให้โชคดี"
เอเยนต์ของฉันทำพลาดสองครั้งในสัปดาห์นี้ ความล้มเหลวทั้งสองครั้งจะไม่เกิดขึ้นอีก ไม่ใช่เพราะฉันขอร้องอย่างสุภาพ แต่เพราะฉันเปลี่ยนความล้มเหลวแต่ละครั้งให้เป็นการแก้ไขเชิงโครงสร้างแบบถาวร: สกิลที่มีการทดสอบที่ทำงานทุกวันตลอดไป
ฉันเรียกแนวปฏิบัตินี้ว่า "skillify" เมื่อคุณใช้มัน เอเยนต์ของคุณจะไม่ทำผิดซ้ำเดิมอีกต่อไป มาดูกันว่ามันทำงานอย่างไร
ความล้มเหลวครั้งที่ 1: การเดินทางที่มีอยู่ในฐานข้อมูลแล้ว
ฉันถาม OpenClaw เกี่ยวกับการเดินทางเพื่อธุรกิจเก่า ๆ เมื่อเกือบสิบปีก่อน ที่ซ่อนอยู่ในประวัติปฏิทิน คำถามง่าย ๆ ควรใช้เวลาแค่วินาทีเดียว
แต่เอเยนต์กลับทำแบบนี้:
- เรียก live calendar API → ถูกบล็อก (ย้อนไปไกลเกินไป)
- ลองค้นหาอีเมล → ผลลัพธ์รก, ไม่ชัดเจน
- ลองเรียก calendar API อีกครั้งด้วยพารามิเตอร์อื่น → ยังถูกบล็อก
- ห้านาทีต่อมา ค้นหาฐานความรู้ท้องถิ่นของฉัน และพบมันทันที
คำตอบอยู่ในข้อมูลของฉันเองมาตลอด ไฟล์ปฏิทิน 3,146 ไฟล์ตั้งแต่ปี 2013 ถึง 2026 ถูกจัดทำดัชนีแล้ว อยู่ในเครื่องแล้ว แค่ grep ครั้งเดียว
เอเยนต์แค่ไม่ได้ค้นหาที่นั่นก่อน
ในเฟรมเวิร์กที่ฉันเขียนถึง (thin harness, fat skills) มีความแตกต่างสำคัญระหว่างงานที่ต้องใช้ดุลยพินิจ (judgment) กับงานที่ต้องการความแม่นยำ (precision) ฉันเรียกมันว่า latent และ deterministic การ grep ปฏิทินเป็น deterministic input เดียวกัน output เดียวกัน ทุกครั้ง ไม่ต้องใช้โมเดล แต่เอเยนต์กลับทำใน latent space อยู่ดี สร้าง reasoning, เรียก API, ตีความผลลัพธ์ ทั้งที่สคริปต์สามบรรทัดจะคืนคำตอบทันที
นั่นคือบัก ไม่ใช่คำตอบที่ผิด แต่เป็น ด้าน ที่ผิด
การแก้ไข: calendar-recall (ขั้นตอนที่ 1 + 2)
ใน thin harness / fat skills สกิล คือขั้นตอนในรูปแบบ markdown ที่สอนโมเดลว่าควรเข้าหางานอย่างไร ไม่ใช่จะทำอะไร (ผู้ใช้ระบุ what) สกิลให้ process ลองนึกถึงการเรียก method: ขั้นตอนเดียวกัน แต่ output แตกต่างอย่างสิ้นเชิงขึ้นอยู่กับสิ่งที่คุณส่งเข้าไป
นี่คือสกิลที่เกิดจากความล้มเหลวนี้:
name: calendar-recall description: "Brain-first historical calendar lookup. ALWAYS use this before any live API for any event not in the future or the last 48 hours."
และกฎตายตัวภายใน:
Live calendar APIs are ONLY for events in the FUTURE or the LAST 48 HOURS. Everything historical goes through the local knowledge base first.
สิ่งที่ทำให้สิ่งนี้ทำงานได้: ตัวเอเยนต์เองเขียนสคริปต์ deterministic ไฟล์สกิล (markdown, อยู่ใน latent space) บอกเอเยนต์ วิธีการ แก้ปัญหา เอเยนต์อ่านสกิล เข้าใจว่าการค้นหาปฏิทินเป็นงาน deterministic และสร้างสคริปต์ขึ้นมาจัดการ:
$ node scripts/calendar-recall.mjs search "Singapore"
Found 2 matching day(s): ── 2016-05-07 ── Flight to Singapore, Mandarin Oriental check-in ── 2016-05-08 ── Lunch with investors at Fullerton Hotel
โค้ดที่ทำงานในเวลาไม่ถึง 100 มิลลิวินาที (ส่วนใหญ่เป็น Bun startup; จริง ๆ แล้ว grep ใช้เวลาไม่ถึงมิลลิวินาที) ไม่มีการเรียก LLM เลย ไม่มีเน็ตเวิร์ก แค่ไฟล์ในเครื่อง
นี่คือลูปที่ทำให้สถาปัตยกรรมทั้งหมดทำงาน: latent space สร้างเครื่องมือ deterministic จากนั้นเครื่องมือ deterministic จะจำกัด latent space เอเยนต์ใช้ดุลยพินิจ (latent) เพื่อเขียน calendar-recall.mjs ตอนนี้สกิลบังคับให้เอเยนต์ รัน สคริปต์นั้นแทนที่จะใช้เหตุผลเกี่ยวกับข้อมูลปฏิทิน ความฉลาดของโมเดลสร้างข้อจำกัดที่ป้องกันไม่ให้โมเดลทำสิ่งโง่เขลา
เส้นทางความล้มเหลวเดิมกลายเป็นสิ่งที่ไม่สามารถเข้าถึงได้ในเชิงโครงสร้าง สกิลบอกว่า "ค้นหาในเครื่องก่อน" สคริปต์ทำการค้นหา เอเยนต์ไม่มีโอกาสที่จะฉลาดเกินไปหรือทำผิดอีก
ความล้มเหลวครั้งที่ 2: "28 นาที" (ขั้นตอนที่ 1 + 2 อีกครั้ง)
วันเดียวกัน เอเยนต์พูดว่า: "การประชุมครั้งต่อไปของคุณอยู่ในอีก 28 นาที"
ความจริง: อีก 88 นาที เอเยนต์คำนวณเวลา UTC→PT ในหัวและคลาดเคลื่อนไปหนึ่งชั่วโมงพอดี
ปัญหาคือ มีสคริปต์อยู่แล้ว (context-now.mjs) ที่ให้ผลลัพธ์นี้:
{ "now": "2026-04-21T07:38:12-07:00", "upcomingEvents": [{ "summary": "App Ops Sprint Planning", "minutesUntil": 88 }] }
โค้ดที่ทำงานในประมาณ 50 มิลลิวินาที ไม่มีความคลุมเครือ เอเยนต์แค่ไม่ได้รันมัน
รูปแบบเดียวกันกับก่อนหน้า: งาน deterministic (การลบ timestamp) ทำใน latent space โมเดลคำนวณเลขในใจในขณะที่สคริปต์มีคำตอบ
การแก้ไข: context-now, สกิล:
name: context-now description: "ALWAYS-ON discipline: run context-now.mjs before making ANY time-sensitive claim. Never do UTC→PT conversion in your head."
นี่คือการเปรียบเทียบแบบง่าย ๆ ก่อนและหลังด้วยสกิลง่าย ๆ เหล่านี้:
Skillify: รูปแบบที่จะช่วยรักษาสติคุณ
สองความล้มเหลว รูปแบบเดียวกัน เอเยนต์มีเครื่องมือที่ถูกต้อง แต่เลือกใช้ความฉลาดแทนวินัย สิ่งที่ผิดเกิดขึ้นในพื้นที่เครื่องจักรที่ผิด
ในการตั้งค่า AI ปกติ AI จะขอโทษ สัญญาว่าจะทำดีขึ้น และสองสัปดาห์ต่อมาสิ่งเดียวกันก็เกิดขึ้นกับคำถามอื่นหรือเขตเวลาอื่น เอเยนต์ไม่มีความทรงจำเกี่ยวกับบัก ไม่มีการทดสอบสำหรับบัก ไม่มีอะไรหยุดมันไม่ให้เกิดขึ้นซ้ำ
Skillify คือการแก้ไข ทุกความล้มเหลวกลายเป็นสกิล ทุกสกิลมีการทดสอบ บักกลายเป็นสิ่งที่ไม่สามารถเกิดขึ้นซ้ำได้ในเชิงโครงสร้าง
นี่คือรายการตรวจสอบ 10 ข้อที่ฉันใช้เมื่อความล้มเหลวได้รับการเลื่อนระดับ:
□ 1. SKILL.md — สัญญา (ชื่อ, ตัวกระตุ้น, กฎ) □ 2. Deterministic code — scripts/*.mjs (ไม่ใช้ LLM สำหรับสิ่งที่โค้ดทำได้) □ 3. Unit tests — vitest □ 4. Integration tests — live endpoints □ 5. LLM evals — คุณภาพ + ความถูกต้อง □ 6. Resolver trigger — รายการใน AGENTS.md □ 7. Resolver eval — ตรวจสอบว่า trigger ส่งผ่านจริง □ 8. ตรวจสอบ resolvable + DRY audit □ 9. E2E smoke test □ 10. กฎการจัดเก็บใน brain
ฟีเจอร์ที่ไม่ผ่านทั้งสิบข้อไม่ใช่สกิล มันเป็นแค่โค้ดที่ทำงานได้ในวันนี้
ความล้มเหลวสองครั้งข้างต้นได้ผ่านขั้นตอนที่ 1 และ 2 แล้ว: เขียน SKILL.md (สัญญา) จากนั้นเขียนโค้ด deterministic (สคริปต์ที่เอเยนต์สร้างและใช้) แต่ก่อนที่ฉันจะอธิบายอีกแปดขั้นตอนที่เหลือ ฉันอยากแสดงให้คุณเห็นว่า skillify เป็นอย่างไรในการใช้งานประจำวัน เพราะมันไม่ใช่แค่การตอบสนองต่อความล้มเหลวมันกลายเป็นคำกริยา
Skillify ในฐานะคำกริยา
สำหรับฉัน การสร้าง OpenClaw (และ GBrain) ของฉัน รายการตรวจสอบเริ่มต้นเป็นโปรโตคอลตอบสนองต่อความล้มเหลว จากนั้นมันกลายเป็นวิธีที่ฉันสร้างทุกสิ่ง
นี่คือเวิร์กโฟลว์จริงของฉัน ฉันกำลังคุยกับเอเยนต์ด้วยภาษาธรรมชาติ เราสร้างสิ่งต่าง ๆ ร่วมกันในการสนทนา ฉันลอง มันใช้งานได้ จากนั้นฉันพูดคำเดียว:
Garry:
เยี่ยมมาก! ฉันขอให้คุณจำสิ่งนี้เป็นสกิล webhook และ skillify มัน ครั้งหน้าเราต้องทำ webhooks บ้าง? ทำไมมันถึงยากขนาดนี้กว่าจะได้? อย่างไรก็ตามตอนนี้มันดีแล้ว ทำ DRY ด้วย
นั่นคือการรวมระบบ OAuth webhook เราใช้เวลาหนึ่งชั่วโมงเพื่อทำให้มันทำงาน จากนั้น "skillify it" ก็เปลี่ยนเซสชั่นเฉพาะกิจให้เป็นสกิลที่คงทนพร้อมการทดสอบ รายการใน resolver และเอกสาร ครั้งหน้าที่ฉันต้องการ webhook สกิลนั้นมีอยู่ เอเยนต์อ่านมัน ความรู้ที่หามาอย่างยากลำบากในชั่วโมงนั้นจะคงอยู่ถาวร
อีกอันหนึ่ง เราค้นพบว่าคอนเทนเนอร์ของเราต้องการเบราว์เซอร์แบบ headless สำหรับงานบางอย่าง และเบราว์เซอร์แบบ headed บนเดสก์ท็อปของฉันสำหรับงานอื่น:
Garry:
เยี่ยม! ดังนั้นเราควรจำสิ่งนี้เป็นสกิลเมื่อใดก็ตามที่ openclaw ต้องการ headless browser! และยังรู้ด้วยว่าถ้าเราต้องการ headed browser เราควรขอให้ผู้ใช้รัน gstack browser และให้ pair-agent code แก่เรา skillify it!
ข้อความเดียว เอเยนต์เขียน skills/browser/SKILL.md พร้อมแผนผังการตัดสินใจ สคริปต์ deterministic การทดสอบ ตอนนี้ทุกเซสชั่นในอนาคตที่ต้องการเบราว์เซอร์จะถูกส่งไปยังเครื่องมือที่ถูกต้องโดยอัตโนมัติ
หรืออันนี้ ฉันสังเกตว่าเอเยนต์ส่งลิงก์ ngrok ให้ฉันโดยไม่ตรวจสอบว่ามันใช้งานได้จริง:
Garry:
เราสร้างสกิลที่บอกว่าเมื่อใดก็ตามที่คุณส่งลิงก์ให้ฉัน คุณต้อง curl มันเองเพื่อให้แน่ใจว่า endpoint เปิดอยู่และ tunnel ทำงานได้ไหม? skillify it!
หรือการจองซ้ำในปฏิทินที่เกือบทำให้ฉันพลาดการประชุม:
Garry:
นี่คือสกิลปกติหนึ่งอย่างที่ฉันต้องการให้คุณเขียน มันคือสกิลตรวจสอบปฏิทิน พรุ่งนี้ฉันมีการจองซ้ำเวลา 11.00 น. สร้างสกิล ทำให้มัน deterministic เพื่อตรวจสอบสิ่งเหล่านี้
หนึ่งประโยค โค้ด, สกิล, การทดสอบ, รายการใน resolver, การตรวจสอบการเข้าถึง ทั้ง 10 ขั้นตอนในหนึ่งลมหายใจ OpenClaw ของฉันรู้จัก ทำมัน และตอนนี้มันเป็นจังหวะที่คุ้นเคย ฉันทำมันหลายสิบครั้งแล้ว ฉันอยู่ไม่ได้ถ้าไม่มีมัน
รูปแบบมักจะเหมือนเดิม: สร้างต้นแบบในการสนทนา เห็นว่ามันใช้งานได้ พูดว่า "skillify" และต้นแบบกลายเป็นโครงสร้างพื้นฐานถาวร ฉันไม่เขียน spec ฉันไม่สร้าง ticket ฉันคุยกับเอเยนต์ เราช่วยกันแก้ปัญหา จากนั้นวิธีแก้ก็กลายเป็นสกิลที่เอเยนต์สามารถใช้ตลอดไปโดยไม่ต้องมีฉัน
นี่คือสิ่งที่เงินทุน 160 ล้านดอลลาร์ของเฟรมเวิร์กพลาดไป ไม่ใช่ส่วนประกอบการทดสอบ ไม่ใช่เครื่องมือ eval แต่เป็นเวิร์กโฟลว์ ช่วงเวลาที่มนุษย์พูดว่า "ใช้ได้แล้ว ตอนนี้ทำให้มันถาวร" และระบบรู้ว่า "ถาวร" หมายถึงอะไร: SKILL.md, โค้ด deterministic, unit tests, integration tests, LLM evals, resolver trigger, resolver eval, DRY audit, smoke test, brain filing สิบขั้นตอน หนึ่งคำ
นี่คือลักษณะของอีกแปดขั้นตอนที่เหลือในทางปฏิบัติ
ขั้นตอนที่ 3: Unit tests
vitest แบบคลาสสิก ฟังก์ชัน deterministic การยืนยัน deterministic calendar-recall.mjs ส่งออกฟังก์ชันบริสุทธิ์ เช่น parseEventLine, eventMatchesKeyword, searchKeyword, formatJson แต่ละฟังก์ชันถูกทดสอบกับข้อมูล fixture: ไฟล์ปฏิทินสังเคราะห์ในไดเรกทอรีชั่วคราว input ที่รู้จัก output ที่รู้จัก
ประเภทบักที่สิ่งเหล่านี้จับได้: parseEventLine ละเว้นอีเวนต์ที่มีอักขระ Unicode ในฟิลด์ตำแหน่งอย่างเงียบ ๆ dateFromPath คืนค่า null สำหรับวันที่ในปีอธิกสุรทิน formatJson ละเว้นอาร์เรย์ attendees เมื่อมีคนเดียว เล็ก น่าเบื่อ แต่สำคัญ ถ้าสคริปต์สร้าง output ผิด สกิลจะสร้างคำตอบผิด และเอเยนต์จะบอกสิ่งที่ผิดอย่างมั่นใจ
สำหรับ context-now unit tests ตรวจสอบการจัดรูปแบบเขตเวลา การตรวจจับช่วงเวลาที่เงียบ (quiet-hours) และการคำนวณ minutesUntil ข้ามขอบเขต DST หนึ่งการทดสอบป้อนเวลาก่อนการเปลี่ยน DST 3 นาทีและตรวจสอบว่า output ไม่กระโดด 60 นาที นั่นคือบักที่ทำให้เกิดความล้มเหลว "28 นาที" ตอนนี้มันเป็นไปไม่ได้ในเชิงโครงสร้าง
ฉันมี unit tests 179 ชุดใน 5 suites ทำงานในเวลาไม่ถึง 2 วินาที
ขั้นตอนที่ 4: Integration tests
การทดสอบเหล่านี้เข้าถึง live endpoints และข้อมูลจริง calendar-recall.mjs ค้นหาอีเวนต์ใน brain repo จริงหรือไม่ ไม่ใช่แค่ fixtures ทดสอบ? context-now.mjs สร้าง JSON ที่ถูกต้องเมื่อแคชปฏิทินเก่าหรือหายไปหรือไม่? Integration tests จับบักที่ unit tests พลาดเพราะข้อมูล fixture สะอาดเกินไป ข้อมูลจริงมีบรรทัดอีเวนต์ที่ผิดรูปแบบ, ฟิลด์เขตเวลาที่หายไป, ไฟล์ปฏิทินที่มีการขึ้นบรรทัดใหม่แบบ Windows, อีเวนต์ที่ข้ามเที่ยงคืน
กฎ: ถ้าคุณพบว่าตัวเองกำลังตรวจสอบด้วยตนเองว่าสคริปต์ทำสิ่งที่ถูกต้องบนข้อมูลจริงหรือไม่ การตรวจสอบนั้นควรเป็น integration test
ขั้นตอนที่ 5: LLM evals
นี่คือจุดที่น่าสนใจ output บางอย่างต้องใช้ดุลยพินิจในการประเมิน "สรุปปฏิทินนี้มีประโยชน์ไหม?" ไม่ใช่คำถามใช่/ไม่ใช่ที่สคริปต์สามารถตอบได้ ดังนั้นฉันใช้ LLM-as-judge: โมเดลหนึ่งประเมิน output ของอีกโมเดลหนึ่งเทียบกับเกณฑ์
สำหรับ context-now มี 35 evals ทำงานทุกวัน หนึ่งในนั้นป้อนข้อความให้เอเยนต์เช่น "เฮ้ เที่ยวบินของฉันออกในอีกประมาณ 45 นาที ฉันจะไปถึง SFO ทันไหม?" และตรวจสอบว่าเอเยนต์รัน context-now.mjs ก่อนตอบหรือพยายามคำนวณในหัว ถ้าเอเยนต์หลงกลและคำนวณเวลาเอง eval จะล้มเหลว
อีก eval ให้ timestamp UTC กับเอเยนต์และถาม "เวลานั้นสำหรับฉันคือเท่าไหร่?" พฤติกรรมที่ถูกต้องคือรันสคริปต์และอ้างอิงผลลัพธ์ พฤติกรรมที่ไม่ถูกต้องคือทำการแปลงในใจ eval จับทั้งคำตอบผิดและ กระบวนการผิด เพราะแม้ว่าการคำนวณในใจจะบังเอิญถูกในครั้งนี้ มันจะผิดในครั้งหน้า
ฮิวริสติก eval ที่ซื่อสัตย์ที่สุดที่ฉันพบ: ค้นหาประวัติการสนทนาของคุณเมื่อคุณพูดว่า "fucking shit" หรือ "wtf" นั่นคือกรณีทดสอบที่คุณพลาด
ขั้นตอนที่ 6: Resolver trigger
resolver คือตารางเส้นทางสำหรับบริบท: เมื่องานประเภท X ปรากฏ ให้โหลดสกิล Y ฉันเขียนเกี่ยวกับ resolver โดยละเอียด ที่นี่ แต่ละสกิลต้องการรายการ trigger ใน AGENTS.md ไฟล์ที่สอนเอเยนต์ว่ามีสกิลอะไรบ้างและควรใช้เมื่อใด
Resolver triggers เป็นเพียงแถวในตาราง markdown:
บักที่ขั้นตอนนี้จับได้: คุณเขียนสกิลใหม่แต่ลืมเพิ่มใน resolver สกิลมีอยู่ ความสามารถมีอยู่ ระบบไม่สามารถเข้าถึงมันได้ เหมือนมีศัลยแพทย์อยู่ในทีมแต่ไม่ได้ลงทะเบียนในสารบบของโรงพยาบาล แย่กว่าการไม่มีสกิลเสียอีก เพราะคุณ คิดว่า ระบบจัดการได้
ขั้นตอนที่ 7: Resolver eval
นี่คือชั้นที่คนส่วนใหญ่พลาดไปโดยสิ้นเชิง Resolver trigger บอกว่า "วลีนี้ควรส่งไปที่สกิลนี้" Resolver eval ทดสอบ ว่ามันทำจริงหรือไม่
ชุด resolver eval ของฉันมีกว่า 50 กรณีทดสอบเช่นนี้:
{ intent: 'check my signatures', expectedSkill: 'executive-assistant' }, { intent: 'who is Pedro Franceschi', expectedSkill: 'brain-ops' }, { intent: 'save this article', expectedSkill: 'idea-ingest' }, { intent: 'what time is my meeting', expectedSkill: 'context-now' }, { intent: 'find my 2016 trip', expectedSkill: 'calendar-recall' },
สองโหมดความล้มเหลว False negative: สกิลควรทำงานแต่ไม่ทำงาน เพราะคำอธิบาย trigger ผิดหรือขาดหาย False positive: สกิลผิดทำงานเพราะสอง trigger ซ้อนทับกัน "พรุ่งนี้มีอะไรในปฏิทินของฉันบ้าง" ควรส่งไปที่ calendar-check ไม่ใช่ calendar-recall หรือ google-calendar สามสกิล สามโดเมนเวลาที่แตกต่าง หนึ่งวลีที่อาจตรงกับหลายตัว Resolver eval จับความคลุมเครือก่อนที่ผู้ใช้จะเจอ
ฉันรัน evals เหล่านี้ทั้งในรูปแบบการทดสอบโครงสร้าง deterministic (ตาราง AGENTS.md มีการแมปที่ถูกต้องหรือไม่) และในรูปแบบการทดสอบการเส้นทาง LLM (ด้วย intent นี้ โมเดลเลือกสกิลที่ถูกต้องจริงหรือไม่) ทั้งสองชั้นสำคัญ ตารางอาจถูกต้อง แต่โมเดลยังสามารถเส้นทางผิดได้เพราะคำอธิบาย trigger คลุมเครือ
ขั้นตอนที่ 8: Check-resolvable + DRY audit
หลังจากหนึ่งเดือนของการสร้าง ฉันมีกว่า 40 สกิล บางส่วนสร้างขึ้นเพื่อตอบสนองต่อเหตุการณ์เฉพาะ บางส่วนเกิดจาก sub-agents ที่รัน crons ไม่มีใครดูแลตาราง resolver สกิลถูกสร้างขึ้นแต่ไม่ได้ลงทะเบียน
ดังนั้นฉันจึงสร้าง check-resolvable เมตาทดสอบที่เดินทั้ง chain: AGENTS.md resolver → SKILL.md → script/cron ถ้ามีสคริปต์ที่ทำงานที่มีประโยชน์แต่ไม่มีเส้นทางจาก resolver มันจะไม่สามารถเข้าถึงได้ LLM จะไม่มีทางรู้ว่าจะใช้มัน
รันครั้งแรกพบสกิลที่เข้าถึงไม่ได้ 6 ตัวจากกว่า 40 ความสามารถของระบบสิบห้าเปอร์เซ็นต์อยู่ในความมืด
- ตัวติดตามเที่ยวบินที่ไม่มีใครเรียกใช้โดยถามเกี่ยวกับเที่ยวบิน
- เครื่องสร้างไอเดียเนื้อหาที่รันบน cron เท่านั้นแต่ไม่สามารถเรียกด้วยตนเอง
- ตัวแก้ไขการอ้างอิงที่มีอยู่ในไดเรกทอรีสกิลแต่ไม่ได้อยู่ใน resolver เลย
แก้ไขในหนึ่งชั่วโมง แค่เพิ่มรายการ trigger ใน AGENTS.md ตอนนี้ check-resolvable รันทุกสัปดาห์เป็นส่วนหนึ่งของ gbrain doctor มันตรวจสอบสามสิ่ง:
- ทุกไดเรกทอรีสกิลที่มี SKILL.md มีรายการที่สอดคล้องใน resolver
- ทุกสคริปต์ที่อ้างถึงโดยสกิลสามารถเรียกได้จริง (ไฟล์มีอยู่, ส่งออกฟังก์ชันที่ถูกต้อง)
- ไม่มีสกิลสองตัวที่มีคำอธิบาย trigger ซ้อนทับกันที่จะทำให้การเส้นทางคลุมเครือ
DRY audit รันควบคู่กัน คุณจะจบลงด้วยสกิลสิบห้าตัวที่ทำสิ่งเดียวกันโดยประมาณถ้าคุณไม่ระวัง และ resolver ก็เลือกตัวที่ลูกเต๋าตก สำหรับ calendar-recall:
สี่สกิลในโดเมนเดียวกัน ไม่มีการซ้อนทับ แต่ละตัวมีช่องทาง เมทริกซ์นั้นไม่ใช่แผนภาพที่วาดสำหรับโพสต์นี้ มันอยู่ใน SKILL.md และสคริปต์ตรวจสอบวิเคราะห์มัน สร้างสกิลปฏิทินตัวที่หกที่ก้าวก่ายช่องทางของตัวอื่น การตรวจสอบจะล้มเหลวก่อนที่สกิลจะถูกส่งออก
ขั้นตอนที่ 9: E2E smoke test
ไพพไลน์เต็ม ตั้งแต่ต้นจนจบ
- ถามเอเยนต์ "ฉันไปสิงคโปร์เมื่อไหร่?" และตรวจสอบว่ามันรัน calendar-recall.mjs, ได้คำตอบที่ถูกต้อง, และจัดรูปแบบถูกต้อง
- ถาม "การประชุมครั้งต่อไปของฉันกี่โมง?" และตรวจสอบว่ามันรัน context-now.mjs แทนที่จะคำนวณในใจ
Smoke tests เป็นแนวป้องกันสุดท้าย ทุกอย่างอื่นผ่านได้ แต่ระบบยังสามารถล้มเหลวได้ถ้าชิ้นส่วนไม่เชื่อมต่อกัน สกิลอาจถูกต้อง สคริปต์อาจถูกต้อง resolver อาจถูกต้อง และเอเยนต์ยังสามารถเลือกที่จะเพิกเฉยทั้งหมดและทำตามใจ Smoke test จับสิ่งนั้น
ขั้นตอนที่ 10: กฎการจัดเก็บใน brain (Brain filing rules)
ทุกสกิลที่เขียนไปยังฐานความรู้ต้องรู้ว่าสิ่งต่าง ๆ ไปที่ไหน บุคคลไปที่ people/ บริษัทไปที่ companies/ การวิเคราะห์นโยบายไปที่ civic/ ฉันพบว่า 10 จาก 13 สกิลที่เขียนไปยัง brain ใส่ไฟล์ผิดไดเรกทอรีเพราะแต่ละตัว hardcode เส้นทางของตัวเองแทนที่จะปรึกษา resolver
เอกสารกฎการจัดเก็บ (filing rules) รวบรวมรูปแบบการจัดเก็บผิดที่พบบ่อย Sources vs. originals. People vs. companies (เมื่อบางคนเป็นบริษัท) สกิลอ่านกฎก่อนสร้างหน้าใด ๆ ตั้งแต่ใช้กฎนี้มาไม่มีการจัดเก็บผิดอีกเลย
GBrain: ที่ที่ Skillify อยู่ และคุณควรนำมาใช้จาก GBrain Skill Pack ของฉัน
รูปแบบ skillify ไม่เฉพาะเจาะจงกับ OpenClaw หรือ harness ใด ๆ มันถูกสร้างใน GBrain GBrain คือเครื่องมือความรู้โอเพนซอร์สที่ฉันเขียนซึ่งอยู่ภายใต้ harness ที่คุณใช้ จัดการ brain repo ของคุณ, รัน evals ของคุณ, และบังคับใช้ประตูคุณภาพที่ทำให้สกิลคงทน
GBrain SkillPack คือชุดสกิล, resolver triggers, สคริปต์ deterministic, และการทดสอบที่พกพาได้ซึ่งคุณสามารถติดตั้งในการตั้งค่าเอเยนต์ใดก็ได้โดยเพียงแค่ขอให้ OpenClaw/Hermes Agent ทำ นี่คือวิธีที่สกิลและความสามารถที่ฉันเขียนสำหรับ OpenClaw/Hermes Agent ของฉันสามารถถูกเพิ่มไปยัง OpenClaw ของคุณ โดยอัตโนมัติ — รวมถึง output ทั้ง 10 ขั้นตอนของ skillify ที่ถูกบรรจุเพื่อให้คุณวางใน OpenClaw/Hermes Agent ของคุณและมันทำงานได้ทันที
รายการตรวจสอบ skillify จากก่อนหน้านี้ไม่ใช่คำแนะนำ มันคือสิ่งที่ gbrain doctor ตรวจสอบจริง ๆ *
gbrain doctor --fix ซ่อมแซมการละเมิด DRY โดยอัตโนมัติ แทนที่บล็อกที่ซ้ำกันด้วยการอ้างอิงตามข้อตกลง ทั้งหมดนี้มีการป้องกันโดย git working-tree checks เพื่อไม่ให้อะไรถูกเขียนทับ
ทำไม Hermes Agent ถึงไม่เพียงพอตามลำพัง
Hermes Agent จาก Nous Research ทำสิ่งที่ยอดเยี่ยมจริง ๆ: มันมีเครื่องมือ skill_manage ที่ให้เอเยนต์สร้าง, แก้ไข, และลบสกิลได้เองตามสิ่งที่เรียนรู้ เมื่อเอเยนต์ทำงานที่ซับซ้อนเสร็จหรือกู้คืนจากข้อผิดพลาด มันจะเสนอสกิลและเขียนลงดิสก์ นั่นคือความจำเชิงกระบวนวิธีที่เอเยนต์ได้รับด้วยตัวเอง การเปิดเผยแบบก้าวหน้า (โหลด index สกิลก่อน ดึง SKILL.md เต็มเมื่อถูกเลือกเท่านั้น) หน่วยความจำแบบมีขอบเขต (MEMORY.md จำกัดที่ 2,200 ตัวอักษร) การเปิดใช้งานตามเงื่อนไข (สกิลซ่อนอัตโนมัติเมื่อเครื่องมือที่ต้องการไม่พร้อม) การออกแบบที่ชาญฉลาด
แต่ Hermes ไม่ได้ทดสอบสกิลของมัน ไม่มี unit tests สำหรับโค้ด deterministic ไม่มี resolver evals เพื่อตรวจสอบการเส้นทาง ไม่มี check-resolvable เพื่อหาสกิลที่มืด ไม่มี DRY audit เพื่อจับความซ้ำซ้อน ไม่มีการตรวจสอบสุขภาพรายวันที่เปลี่ยนเป็นสีแดงเมื่อมีอะไรเบี่ยงเบน
โหมดความล้มเหลวที่ฉันเห็นสะสมในระบบสกิลที่ไม่มีการทดสอบ:
- เอเยนต์สร้าง deploy-k8s ในวันจันทร์ วันพฤหัสสร้าง kubernetes-deploy จากการสนทนาอื่น ทั้งสองมีอยู่ ทั้งสอง trigger ด้วยวลีที่คล้ายกัน การเส้นทางคลุมเครือ และไม่มีใครสังเกตจนกระทั่งตัวผิดทำงานผิดเวลา
- สกิลทำงานได้อย่างสมบูรณ์เมื่อเขียน หกสัปดาห์ต่อมา upstream API เปลี่ยนรูปร่าง สกิลคืนค่า garbage อย่างเงียบ ๆ จนกว่ามนุษย์จะสังเกตเห็น
- สกิลที่สร้างโดยอัตโนมัติมี trigger ที่อ่อนแอซึ่งไม่เคยตรงกัน มันกลายเป็นสกิลกำพร้า กิน token index, ไม่เคยรัน, ค่อย ๆ เสื่อม
นี่คือปัญหาที่ "หากไม่มีการทดสอบ โค้ดเบสใด ๆ ก็จะเน่า" ซึ่งวิศวกรรมซอฟต์แวร์แก้ไขในปี 2005 สกิลของเอเยนต์ก็ไม่แตกต่าง Hermes จัดการการสร้างได้อย่างสวยงาม GBrain จัดการการตรวจสอบ คุณต้องการทั้งสอง
แนวคิดใหญ่
ในทีมวิศวกรรมซอฟต์แวร์ที่ดี ทุกบักมีการทดสอบ การทดสอบนั้นอยู่ตลอดไป บักกลายเป็นสิ่งที่ไม่สามารถเกิดขึ้นซ้ำได้ในเชิงโครงสร้าง เอเยนต์ AI ควรทำงานในลักษณะเดียวกัน
ทุกความล้มเหลวกลายเป็นสกิล ทุกสกิลมี evals ทุก eval ทำงานทุกวัน ดุลยพินิจของเอเยนต์ดีขึ้น อย่างถาวร ไม่ใช่แค่สำหรับเซสชั่นปัจจุบัน ไม่ใช่แค่ตราบเท่าที่ context window ยังคงอยู่
ความล้มเหลวเรื่องการเดินทางจะไม่เกิดขึ้นอีก ความล้มเหลวเรื่องเขตเวลาจะไม่เกิดขึ้นอีก และเมื่อความล้มเหลวครั้งต่อไปปรากฏขึ้น (และมันจะเกิดขึ้น เพราะนี่คือเกมที่เป็นปฏิปักษ์ต่อเอนโทรปีและรสนิยม) มันก็จะถูก skillify เช่นกัน
เอเยนต์ที่ฉันทำงานด้วยในอีกหนึ่งปีนับจากนี้จะถูกหล่อหลอมโดยทุกความผิดพลาดที่มันทำในปีก่อนหน้า นั่นไม่ใช่สิ่งที่ดีถ้ามี แต่เป็นวิทยานิพนธ์ทั้งหมด
ทำให้ทะเลเดือดพล่าน ทำให้เอเยนต์ของคุณทำบางอย่าง จากนั้น skillify มัน คุณทำแบบนั้นทุกวันและคุณจะมี OpenClaw ที่ฉลาดสุด ๆ ที่ทำทุกอย่างที่คุณต้องการ
หรือคุณสามารถโหลด GBrain ใช้โค้ดทั้งหมดที่ฉันเขียนแล้ว และข้ามไปยัง Jarvis ส่วนตัวของคุณจาก Iron Man ได้เร็วขึ้น
--
GStack เพื่อความเร็วใน Claude Code github.com/garrytan/gstack
GBrain เพื่อสร้าง Jarvis ส่วนตัวของคุณจาก Iron Man ใน OpenClaw/Hermes Agent github.com/garrytan/gbrain
