Caty Agent Harness

🇺🇸 English ｜ 🇯🇵 日本語｜ 🇨🇳 简体中文｜ 🇹🇭 ไทย

ประกาศ (2026-08-24): เราพบความคลาดเคลื่อนบางส่วนระหว่าง README นี้กับพฤติกรรมจริงของระบบ (#144): ส่วนหนึ่งของลูปการเรียนรู้ที่อธิบายด้านล่าง — "วิธีนั้นถูกจดเป็นแค่ 'บทเรียน' ก่อน และเลื่อนขั้นเป็น 'กฎ' หลังผ่านการตรวจสอบอีกครั้งในงานอื่น ขั้นตอนที่โผล่มาบ่อยถูกตรวจโดย AI อีกตัวที่ไม่ใช่ผู้เขียน เฉพาะที่สอบผ่านจึงถูกเก็บเป็น 'สกิล'" — ได้รับการออกแบบแล้วแต่ยังไม่ได้ถูกพัฒนา ขณะนี้เรากำลังพัฒนาส่วนนี้ (#147, #148, #149) และจะปรับปรุงเอกสารแล้วเผยแพร่ใหม่เมื่อเสร็จสิ้น ติดตามได้ที่: #146

_{หลักฐาน CI (2026-08-15 UTC): เมทริกซ์ผ่าน 7/7 ・ รัน 60 ครั้งอย่างอิสระบน SHA เดียว ไม่มี flake รันรายสัปดาห์ — หาก repo ไม่มีความเคลื่อนไหว 60 วัน GitHub จะหยุด schedule อัตโนมัติ โปรดดูวันที่ของ run ด้วย}
_{* WSL2 เป็น tier ที่ยืนยันจากการวัดจริงแบบมีเงื่อนไขบน VM ที่ลงวันที่ไว้เพียงเครื่องเดียว ไม่ใช่ tier ที่ผ่าน CI; ดู WSL2 support note}

การอธิบายซ้ำแล้วซ้ำอีก บริบทที่หายไป และ "เสร็จแล้ว!" ที่ไม่มีหลักฐาน
Caty Agent Harness แก้ทั้งหมดนี้ด้วยไฟล์ข้อความธรรมดาและการตรวจสอบจริง
ไม่ใช่เวทมนตร์ — กลไกรับหน้าที่จดจำ เดินงาน และตรวจสอบ เพื่อให้ AI โฟกัสกับการคิด
เป็นกลไกเล็ก ๆ ที่ครอบรอบ AI ที่คุณใช้อยู่แล้ว

กลไกที่ไม่เชื่อคำว่า "เสร็จแล้ว!" ของ AI ง่าย ๆ — เดินงานเป็นขั้นตอน ตรวจกับหลักฐานก่อนจึงนับว่า "เสร็จ" และเผยแพร่สกอร์การ์ดของตัวเอง ทั้งชนะและแพ้

สิ่งที่ดีขึ้นจริง — วัดผลแล้ว ไม่ใช่แค่สัญญา:

การหลอกว่า "เสร็จ" หยุดทำงานบนโมเดลที่อ่อนกว่า — อัตราการทำงานสำเร็จที่ยืนยันแล้วเพิ่มเป็นสามเท่า บน Claude Haiku 4.5 (โมเดลที่มีความสามารถต่ำกว่า) การอ้างว่า "เสร็จ" ทั้งที่ยังอ่านงานไม่ครบ ลดลงจาก 98% เหลือ 8% ของการอ้างว่าเสร็จทั้งหมด (222/226 → 2/26; 30 รันต่อฝั่ง, งานขนาด M/L) — และอัตราการทำงานสำเร็จที่ยืนยันแล้วเพิ่มขึ้นจาก 13% เป็น 43% (ตัวเลขทั้งหมด)
โมเดลที่แข็งแกร่งยังคงความแม่นยำ — และลดการใช้ token ในงานใหญ่ลง 58% (sonnet) / 31% (opus) sonnet และ opus ได้คะแนนบนเฉลยลับเท่ากันทั้งแบบมีและไม่มี harness — ในงานขนาดใหญ่ การรันโดยไม่มี harness ใช้ token เป็น 2.40 เท่า (sonnet) / 1.46 เท่า (opus) ของแบบมี harness (เท่ากับว่าเมื่อมี harness ใช้น้อยลง 58% / 31%; ค่ามัธยฐานช่วง L — ตาราง P1) ในงานขนาดเล็กของ sonnet ในการทดสอบชุดนี้ harness กลับใช้ token มากกว่า ไม่ใช่น้อยกว่า — ควรใช้ในงานที่ใหญ่จริง ๆ และในงานที่ใหญ่ที่สุดที่วัดผล (≈2.4M token หรือประมาณ 2.4 เท่าของ context window) ซึ่ง opus แบบไม่มี harness อ่านไฟล์ได้แค่ 2–4% แล้วยังพยายามส่งงานต่อไป opus ภายใต้ harness กลับทำงานสำเร็จแบบยืนยันแล้วโดยอ่านไฟล์ครบ 100% (2/2 ในทั้งสองช่วง overflow; ทั้งสองฝั่งรันภายใต้ขอบเขตงบประมาณที่ไม่เท่ากัน)
ผลลัพธ์ยังแสดงข้อจำกัดของมันด้วย บนรันไทม์แบบ search (เช่น Codex) ตัวเฝ้าระวัง overflow ไม่เคยทำงานเลย — เป็นไปตามการออกแบบ เพราะไม่มีอะไรต้องช่วย — และมีรันไทม์หนึ่งที่มันทำงานแต่ใช้ token มากกว่าการรันโดยไม่มี harness (โปรไฟล์รายโมเดล) ส่วนเซลล์ overflow ของ sonnet หยุดที่ 0/2: ทั้งสี่รันส่งมอบงานครบ ถูกต้อง 20/20 และการอ้างอิงถูกต้องทั้งหมด แต่ข้ามไฟล์ไปประมาณ 10–12% — เกตการตรวจสอบปฏิเสธคำว่า "เสร็จ" ทุกครั้ง พร้อมระบุรายชื่อไฟล์ที่ยังไม่ได้อ่าน (สาขา honest-failure ที่ลงทะเบียนล่วงหน้าไว้) ทุกผลลัพธ์ที่แพ้ถูกเผยแพร่คู่กับผลลัพธ์ที่ชนะ

_{การทดลองแบบปิดผนึก ลงทะเบียนล่วงหน้า และให้คะแนนโดยเครื่อง 4 ชุด (2026-08) — ตัวเลข วิธีการ และข้อควรระวังทั้งหมด รวมถึงจุดที่ harness ใช้ token มากขึ้น: benchmark ・ ลองใช้ได้ใน 2 นาที — วางพรอมป์ต์เดียวที่คัดลอกมาได้เลย ลงในเครื่องมือ AI ที่คุณใช้อยู่แล้ว}

🔧 คู่มือวิศวกรรม (ภาษาอังกฤษ) ｜ 📘 ข้อมูลอ้างอิง (ภาษาอังกฤษ)

_{generation: ed18d59 (2026-09-18T11:26:53Z) · verify: API HEAD · status.json}

เคยเจอแบบนี้ไหม?
ทำอะไรได้บ้าง
สิ่งที่ต้องมี
เริ่มต้นใช้งาน
ทำไมจึงลองได้อย่างสบายใจ
โมเดลไหนได้ประโยชน์
อ่านเพิ่มเติม
ส่วนหนึ่งของ Family OS
สัญญาอนุญาต

เคยเจอแบบนี้ไหม?

ยิ่งมอบงานให้ AI มากเท่าไร สถานการณ์เหล่านี้ก็ยิ่งโผล่มาบ่อยขึ้น

ทุกเซสชันใหม่ต้องเริ่มอธิบายบริบทเดิมอีกครั้ง
AI บอกว่างานเสร็จแล้ว — แต่ผลลัพธ์ไม่มีอยู่ หรือคุณตรวจสอบไม่ได้
งานยาว ๆ หลงทางกลางคันแล้วหยุดไปเงียบ ๆ
วิธีแก้ที่ได้ผลเมื่อสัปดาห์ก่อน สัปดาห์นี้ AI ลืมไปแล้ว

ถ้าคุณพยักหน้าให้ข้อใดข้อหนึ่ง เครื่องมือนี้ถูกสร้างมาเพื่อคุณ ในทางกลับกัน ถ้าคุณใช้ AI แค่ถามคำถามสั้น ๆ เป็นครั้งคราว กลไกนี้ก็ใหญ่เกินความจำเป็น — แบบที่เป็นอยู่ก็ดีแล้ว

ปัญหาทั้งสี่ข้อนี้ คือสิ่งที่ Caty Agent Harness ถูกสร้างมาเพื่อบดขยี้ ด้วยกลไก ไม่ใช่คำสัญญา

ทำอะไรได้บ้าง

มันคือลูปเดียวที่ทำซ้ำ: จดจำ → ทำงาน → เก็บหลักฐาน → ส่งต่อ กลไกหมุนลูปนี้ต่อไปเรื่อย ๆ ดังนั้นแม้ AI จะลืม แต่ตัวงานจะไม่มีวันถูกลืม

flowchart LR
    A["จดจำ"] --> B["ทำงาน"]
    B --> C["เก็บหลักฐาน"]
    C --> D["ส่งต่อ"]
    D -. ครั้งถัดไป .-> A

🌱 ฉลาดขึ้นได้เอง

เมื่อทำพลาด เหตุผลและหลักฐานจะถูกจดทันทีลงสมุดโน้ต (ตัวจริงคือไฟล์ข้อความธรรมดา) การลองครั้งถัดไปจะได้รับความล้มเหลวครั้งก่อนเสมอ และกฎเชิงกลไกห้ามลองซ้ำด้วยวิธีเดิม — ความผิดพลาดเดิมจึงไม่เกิดซ้ำ คุณไม่ต้องพูดว่า "ช่วยจดไว้หน่อย" เลย
🏁 วิ่งจนถึงเส้นชัย

งานใหญ่ถูกแบ่งเป็นก้าวเล็ก ๆ ที่มีหมายเลขกำกับ และกลไกพาเดินหน้าทีละก้าว เซสชันจบ หน้าต่างปิด หรือเปลี่ยนโมเดล งานก็ยังเดินต่อจากจุดที่ค้างไว้
🔍 "เสร็จแล้ว" มาพร้อมหลักฐาน

"เสร็จ" ถูกตัดสินด้วยการตรวจเชิงกลไกกับผลลัพธ์จริง — ไม่ใช่คำกล่าวอ้างของ AI เอง ผู้ตรวจสอบอิสระจะเข้าร่วมเฉพาะเมื่อมีการตั้งค่าไว้ หากไม่ได้ตั้งค่า การตรวจเชิงกลไกยังคงเป็นแกนหลัก และไม่ว่ากรณีใดคำกล่าวอ้างของ AI ผู้ทำงานก็ไม่ถือเป็นหลักฐาน เมื่อไปต่อไม่ได้จริง ๆ มันไม่หมุนวนไม่รู้จบ: หยุดอย่างซื่อตรงพร้อมหลักฐาน และรายงานถึงคุณ

กลไกภายใน (เหตุผลที่ไม่ใช่เวทมนตร์)

เมื่อล้มเหลว — อะไรที่ผิดพลาด พร้อมหลักฐาน จะถูกบันทึกอัตโนมัติลงสมุดโน้ตในโปรเจกต์ของคุณ
เมื่อลองครั้งถัดไป — ความล้มเหลวครั้งก่อนถูกส่งมอบมาด้วยเสมอ และมีกฎเชิงกลไกห้ามลองซ้ำด้วยวิธีเดิม
เมื่อสำเร็จ — วิธีนั้นถูกจดเป็นแค่ "บทเรียน" ก่อน และเลื่อนขั้นเป็น "กฎ" หลังผ่านการตรวจสอบอีกครั้งในงานอื่น ขั้นตอนที่โผล่มาบ่อยถูกตรวจโดย AI อีกตัวที่ไม่ใช่ผู้เขียน เฉพาะที่สอบผ่านจึงถูกเก็บเป็น "สกิล"
ระหว่างทำงาน — ตัวจัดตารางเตะ "ก้าวถัดไป" ทุก ๆ ไม่กี่นาที ส่งให้ AI เพียงบริบทสั้นและสดใหม่ จำนวนครั้งและเวลาทำงานมีเพดานที่กลไกเป็นผู้นับ ลากยาวไม่รู้จบไม่ได้

→ เจาะลึก: เรียนรู้จากความล้มเหลวซ้ำ ๆ (ภาษาอังกฤษ) ／ รางแห่งการทำให้เสร็จ (ภาษาอังกฤษ)

จะใช้ได้หรือไม่ ขึ้นอยู่กับเครื่องมือที่คุณมีอยู่แล้ว — ดูตารางด้านล่าง

สิ่งที่ต้องมี

เครื่องมือ AI ที่รองรับล้วนทำงานในเทอร์มินัล — แต่คนพิมพ์ไม่ใช่คุณ AI ของคุณเป็นผู้ติดตั้งและดูแล คุณแค่คุยกับมัน

หมวด	รองรับ
ระบบปฏิบัติการ	macOS: ✅ ทดสอบผ่าน CI แล้ว (GitHub Actions `macos-latest`, Apple silicon) ／ Linux: ✅ ทดสอบผ่าน CI แล้ว (GitHub Actions `ubuntu-latest`)
Windows (native)	❌ ไม่รองรับ — กำแพงที่วัดได้มี 3 ข้อ: `chmod` จะกลายเป็น `644` แบบเงียบ ๆ, `ln -s` กลายเป็นการ copy และไม่มี `flock` ดู WSL2 support note
WSL2 (Ubuntu on Windows)	🟡 รองรับแบบมีเงื่อนไข — ยืนยันแล้วเมื่อ 2026-08-23 บน `win11-test-vm` (30/30 suites, `umask 0002`, non-root, Linux filesystem) แต่ยังไม่ใช่ tier ที่ผ่าน CI AI tool ของคุณ (Claude Code / Codex CLI) ต้องรันอยู่ใน WSL2 distro เดียวกัน; ถ้า agent รันอยู่ฝั่ง Windows การติดตั้งจะผ่าน แต่ hooks จะไม่ทำงานเลย repo ต้องอยู่บน Linux filesystem (`/home/...` ไม่ใช่ `/mnt/c/...`) เพื่อความถูกต้อง ไม่ใช่เรื่องความเร็ว, ใช้ `git 2.34+`, รันด้วยผู้ใช้ non-root และทำให้ไฟล์ประเภท wrapper ไม่เป็น group/world-writable (เช่น `chmod 0755`) ค่าใกล้เคียงใน CI คือ `ubuntu-wsl2-profile` (`umask 002`, non-root container) รายละเอียดการวัด
เครื่องมือ AI	Claude Code ✅ ／ Codex CLI ✅ ／ Kimi Code CLI ✅ ／ Hermes Agent ✅ ／ OpenClaw ✅
Shell	bash 3.2+ ✅ (ค่าเริ่มต้นของ macOS ใช้ได้เลย)
Python 3 (3.9+)	ใช้โดยระบบอัตโนมัติเบื้องหลัง (ในทางเทคนิคเรียกว่า hooks) — AI ของคุณจะตรวจให้เอง

ความลึกของการรองรับแต่ละเครื่องมือตั้งใจให้ต่างกัน — รายละเอียดอยู่ในคู่มือวิศวกรรม (ภาษาอังกฤษ)

ถ้าครบตามตาราง การติดตั้งใช้แค่ prompt เดียว

เริ่มต้นใช้งาน

ฝั่งคุณมีสิ่งที่ต้องทำแค่อย่างเดียว เปิดเครื่องมือ AI ที่คุณใช้อยู่ในโฟลเดอร์โปรเจกต์ที่ต้องการ แล้ววางข้อความนี้ — การติดตั้ง การตรวจสอบ และการรายงาน AI ของคุณจัดการให้ทั้งหมด:

ช่วยติดตั้ง https://github.com/caty-ai/caty-agent-harness.git ในโปรเจกต์นี้:
อ่าน docs/agent-guide.md ใน repository นั้นแล้วทำตาม — ติดตั้งโดยใช้โฟลเดอร์นี้
เป็น workspace, รันเช็กสุขภาพ แล้วเล่าให้ฟังด้วยภาษาง่าย ๆ ว่าตั้งค่าอะไรไปบ้าง
และฉันทำอะไรต่อได้บ้าง

แค่นั้นเลย คู่มือ Agent (ภาษาอังกฤษ) จะพา AI ของคุณผ่านทุกทางเลือก การตรวจสอบ และวิธีรายงานกลับมาหาคุณ

สำหรับเดโมแรกแบบเจาะจง AI ของคุณสามารถรันตัวอย่าง image pilot ที่ให้มาด้วย ซึ่งสร้างการ์ดภาพ SVG และใบรับการส่งมอบ JSON โดยใช้เฉพาะเครื่องมือในเครื่อง

อยากพิมพ์คำสั่งเองทุกขั้น? → คู่มือวิศวกรรม (ภาษาอังกฤษ) มีขั้นตอน manual ฉบับเต็ม

ถ้ารู้สึกว่ามีอะไรแปลก ๆ

AI ของคุณจะรันเช็กสุขภาพแบบอ่านอย่างเดียว (--check) แล้วให้คุณดูผล — ถ้าปกติ บรรทัดสุดท้ายคือ ok: required layout and STATE.md headers present
บางแถวอาจแสดง FAIL แม้แกนกลางจะปกติ: นั่นคือระบบอัตโนมัติเสริมที่ยังไม่ได้เดินสาย คู่มือ Agent จะบอก AI ของคุณเองว่าแถวไหนสำคัญ

ยังลังเลก่อนวางอยู่ไหม? หัวข้อถัดไปอธิบายว่าทำไมจะไม่มีอะไรพัง

ทำไมจึงลองได้อย่างสบายใจ

AI ของคุณยังเป็นของคุณเหมือนเดิม — บุคลิกและความทรงจำที่สั่งสมมายังคงเดิม เนื้อหาเดิมในไฟล์คำสั่งจะไม่ถูกเขียนทับ และเฉพาะเมื่อเลือก --append-bootstrap การติดตั้งจึงจะต่อท้ายบล็อก bootstrap ที่มีคำอธิบายในเอกสารลงในไฟล์คำสั่งที่เลือก ส่วนที่เหลือเป็นเพียงการเพิ่ม scaffold ของ harness ไว้รอบ ๆ
เลิกใช้ก็แค่คำสั่งเดียว — ติดตั้งหนึ่งคำสั่ง หยุดชั่วคราวก็หนึ่งคำสั่ง สิ่งที่เรียนรู้มาไม่หายไปไหน กลับมาทำต่อได้จากจุดที่หยุด
อ่านทุกอย่างได้ด้วยตาตัวเอง — บทเรียน ความคืบหน้า และหลักฐานอยู่ในไฟล์ข้อความธรรมดาทั้งหมด เกิดอะไรขึ้นคุณตรวจสอบเองได้

ถึงตรงนี้คือฉบับย่อ ความลึกทั้งหมดอยู่ด้านล่าง

โมเดลไหนได้ประโยชน์

overflow sentinel (design issue #159) เฝ้าดูระดับ context ต่อเทิร์นที่วัดได้จริง และเมื่อเกินเกณฑ์ จะหยุดการรันแล้วแตกงานออกเป็นส่วนย่อย แทนที่จะปล่อยให้ context ล้น — Sentinel v1 เผยแพร่แล้วแบบ opt-in สำหรับ claude-code runtime ใน v0.17.0 (#180 เป็นการ implement #159) เปิดใช้ด้วย OVF_SENTINEL=shadow|active และถ้าไม่ตั้งค่า = ปิดเต็มรูปแบบ (byte-identical passthrough) default-on ยังเป็นงานในอนาคต โดยตัดสินแยกตามโมเดลตามเงื่อนไขของ #159 ดูโปรไฟล์รายโมเดลในส่วนนี้ และ benchmark (ภาษาอังกฤษ) EV-008 ยังคงเป็นการวัดล่วงหน้าบน rig ก่อน implementation นี้ และยังไม่ได้วัดซ้ำบน implementation ที่เผยแพร่แล้ว EV-008 — เบนช์มาร์กแบบปิดผนึกและลงทะเบียนล่วงหน้า (2026-08) — วัดพฤติกรรมนี้แยกตามโมเดล ผลลัพธ์แบ่งตามวิธีที่รันไทม์ "อ่าน" context:

ประเภทรันไทม์	โมเดลที่วัดผล	พฤติกรรม	ข้อสรุป
Full-read — context เพิ่มขึ้นแบบ monotonic	claude-haiku-4.5 · claude-sonnet-5 · claude-opus-5	ทำงาน (fire) กลางงาน → แตกงาน → ทำสำเร็จ; ความถูกต้องรักษาไว้ (sonnet/opus= 20/20 ในทุกเซลล์ที่ทำงาน ・ haiku= 19–20/20)	นี่คือจุดที่ได้ประโยชน์จริง สำหรับ sonnet ยิ่งงานใหญ่ยิ่งประหยัดมาก (มากที่สุดในงานระดับ L) ค่ามัธยฐาน sentinel/bare ของ sonnet คือ 0.801 (เซลล์ที่ดีที่สุด token ลด −71%) ・ opus 0.923 ・ haiku 0.35 (descriptive มีปัจจัยกวน arm/phase ปนอยู่ — ดู benchmark)
Search-type — นิ่งเป็นที่ราบในช่วงที่สังเกตได้	gpt-5.6-luna (Codex) · qwen3.8-max	ทำงาน (fire) เป็นศูนย์ในทุกการรันที่วัดผล: codex 0/127 turns ・ qwen 0/4 เซลล์ (ค่าสูงสุดที่วัดได้ 79.7K จากเกณฑ์ 80K — ส่วนต่างเหลือน้อย ระบุไว้เฉพาะในฐานะช่วงที่สังเกตได้เท่านั้น)	การไม่ทำงานในช่วงที่สังเกตได้คือเจตนาของการออกแบบ — นี่คือเงื่อนไขความปลอดภัยของ default-on เอง หากทำงานที่นี่จะถือเป็น false positive และต้องส่งกลับไปแก้การออกแบบ
ทำงานแต่ไม่คุ้มค่า — context เพิ่มขึ้น แต่ bare ถูก	grok-4.6	ทำงาน 4/4 แตกงานและทำสำเร็จถูกต้อง (20/20) — แต่ bare รันถูกมากจนการแตกงานมีต้นทุนสูงกว่า (ค่ามัธยฐานของอัตราส่วน 2.145)	กลไกนี้พิสูจน์แล้วว่าใช้ได้บนรันไทม์นี้ แต่ไม่แนะนำให้ default-on ตัดสินจากความคุ้มค่าเทียบกับ bare ไม่ใช่จากว่ามันทำงานหรือไม่
ทำงานแต่ผลลัพธ์ผสม — ทำงานเร็ว (early onset) ・ full-read แบบหนัก	gemini-3.7-flash (descriptive — อยู่นอกเงื่อนไข GO ที่ลงทะเบียนล่วงหน้า)	ทำงาน 4/4 (เทิร์น 31–82); bare พังในงานระดับ L; การแตกงานช่วยกู้การทำสำเร็จได้ 1 เซลล์ระดับ L แต่ 2/4 เซลล์ของ sentinel (M-i3, L-i2) ได้คะแนน 0 (ขั้นตอนย่อยติดค้างเรื่อง permission ในโหมด headless)	เป็นการบันทึกเชิงพรรณนาเท่านั้น — ไม่อ้างประสิทธิภาพ ไม่ตัดสิน default-on ตัวเลขรายเซลล์

_{อัตราส่วนคือต้นทุน token ของ sentinel/bare (ยิ่งน้อยยิ่งถูก) ค่ามัธยฐานของ 4 เซลล์ที่ปิดผนึกต่อโมเดล วัดเมื่อ 2026-08-25 อ่านก่อนนำไปอ้างอิง: ① เงื่อนไขของ codex FAIL ในครั้งแรก (M4, n=1, ค่าเฉลี่ยเรขาคณิต 1.337) และผ่านเฉพาะในการทำซ้ำ n=3 — เป็นการออกแบบภายหลังจากเห็นข้อมูลแล้ว ที่ถูกปิดผนึกผ่านการรีวิว delta แบบ 3 ที่นั่ง (0.9944 ≤ 1.05) — FAIL คือประวัติที่ไม่ถูกลบทิ้ง; ② 0.801 ของ sonnet ผ่านเกณฑ์การตัดสินใจ (<1.0) แต่พลาดเป้าหมายที่ตั้งไว้สูงกว่า (<0.8) ไปเพียงเล็กน้อย; ③ อัตราส่วนต่อคู่ส่วนใหญ่เป็น n=1 — ความแปรปรวนระหว่างการรันมีอยู่จริง (SE ของค่าเฉลี่ย codex ≈25%); ส่วนเสริมจากการทำซ้ำ n=3 (2026-08-29) วัดปริมาณสิ่งนี้ไว้แล้ว — รวม log-ratio 12 ค่าต่อโมเดล: sonnet GM 0.617 [0.439, 0.867], opus 0.806 [0.651, 0.997] — ค่ามัธยฐานของการรันครั้งเดียวอยู่ในช่วงนี้ (แต่ละรอบอยู่ระหว่าง 0.28–1.50) และขอบบนของ opus คือ 0.997: ยืนยันว่าใช้ token น้อยลงจริง แม้จะเฉียดฉิว ทั้งนี้ตัว sentinel เองยังคงเป็น opt-in และยังไม่ได้วัดผลซ้ำบนการใช้งานเวอร์ชันที่เผยแพร่แล้ว ตัวเลข วิธีการ และข้อควรระวังฉบับเต็ม (ภาษาอังกฤษ) ・ ส่วนเสริม n=3 (ภาษาอังกฤษ)}

การทดลองแบบปิดผนึกชุดที่สาม P2-WIN เป็นการจับลักษณะของตัวงานเองบนโมเดลเปล่า — เป็นการวัดผลลัพธ์การทำสำเร็จในสามระดับขนาดงาน ไม่ใช่ผลของการแทรกแซง: ตารางและข้อจำกัด (ภาษาอังกฤษ)

อีกหนึ่งเลน EV-007 / EV-007b / EV-007c วัดอีกครึ่งหนึ่งของข้ออ้าง — วงจรการเรียนรู้ โดยรันแบบปิดผนึกทั้งหมดสามครั้ง EV-007 จบลงเมื่อการรีวิวข้ามโมเดล fail-close จากนั้น EV-007b จึงสร้างเครื่องมือวัดแบบฝังกับดัก (trap) ที่ทำให้ความผิดพลาดเกิดซ้ำได้จริง (ในแขนที่เรียนรู้ 8 จาก 8 คลาสความผิดพลาดเกิดซ้ำในทุกรอบบน v0.24.0) และรันการรันหลักที่ปิดผนึกไว้บนเครื่องมือนั้น — แต่การรีวิวปฏิเสธการอ้างอิงทุกรายการ เพราะการตรวจการอ้างอิงของตัวรีวิวไม่เข้ากับรูปแบบบรรทัด flush ที่ Stop hook เขียนออกมา ซึ่งคือสิ่งที่การรันนั้นค้นพบในตัวผลิตภัณฑ์ จำนวนการเลื่อนขั้นของสองเลนแรก: 0 EV-007c รันชุดลำดับที่ปิดผนึกชุดเดิมซ้ำบน v0.25.0 ซึ่งการรีวิวอ้างอิงได้แล้ว: ทั้ง 3 รอบเกิดการเลื่อนขั้น (เลื่อนขั้น 6 รายการ กฎที่อนุมัติ 2 ข้อ) และเส้นผ่านที่ปิดผนึกไว้ไม่ผ่าน — อัตราความผิดพลาดซ้ำของแขนที่เรียนรู้อยู่ที่ 0.667 เทียบกับ 0.727 ในแขนที่ไม่เรียนรู้ และ difference-in-differences เท่ากับ +0.050 คลาส T2 เพียงคลาสเดียวที่ขยับหลังจากกฎได้รับการอนุมัติ (การถูกแทนที่ของสถานะภายในไฟล์) ถูกแก้ได้ในรอบที่ 3 และเสียไปครึ่งหนึ่งในบล็อกสุดท้าย ส่วนคลาสไฟล์แก้คำผิด (erratum) ไม่ขยับเลยในทุกแขน และไม่เคยถูกบันทึกไว้ให้วงจรได้เห็น นี่คือ ผลการวัดหนึ่งครั้งที่ n = 1 บนเครื่องมือที่ให้ข้อมูลเพียงหนึ่งบิตต่อคลาส — เป็นการไม่ผ่านเส้นที่ลงทะเบียนไว้ล่วงหน้า ไม่ใช่คำตัดสินต่อตัววงจรเอง สิ่งที่เลนเหล่านี้ให้จริง ๆ คือการเปลี่ยนแปลงของผลิตภัณฑ์สองรายการที่เผยแพร่ใน v0.24.0 และ v0.25.0: วัดอะไรได้และวัดอะไรไม่ได้ (ภาษาอังกฤษ)

เส้นทาง telemetry แบบมองไม่เห็น — อย่าเปิดใช้โดยไม่วัดผลก่อน ผ่าน shim ปัจจุบัน glm / muse รายงาน usage ต่อเทิร์นเป็นศูนย์ทั้งหมด ส่วน kimi ไม่ส่ง usage ออกมาเลย รันไทม์ที่มองไม่เห็น telemetry แบบสด ต้องไม่เปิด sentinel เป็น default-on เพราะไม่มีระดับน้ำให้เฝ้าดูตั้งแต่แรก

ผู้จัดการระดับน้ำมีได้ทีละคนเท่านั้น ถ้าฝั่ง host มีการบีบอัดอัตโนมัติของตัวเอง (Hermes, OpenClaw, การบีบอัดในตัวของ agent CLI ...) ผู้จัดการระดับ context ต้องเป็น host หรือ sentinel เพียงฝ่ายเดียว — ห้ามเป็นทั้งสองฝ่าย การมีผู้จัดการสองคนหมายความว่า host บีบอัดก่อนแล้ว sentinel กลายเป็นแค่ของประดับ หรือทั้งสองเข้าแทรกแซง overflow เดียวกันพร้อมกัน เลือกทางใดทางหนึ่ง: ปิดการบีบอัดอัตโนมัติของ host เมื่อ sentinel เป็น default-on หรือลดระดับ sentinel ให้เป็นแค่ตัวบันทึกเมื่อ host เป็นผู้นำ event log ของ sentinel (บน rig ของ EV-008) บันทึก runtime_compaction / compaction_suspected (เป็น false ในทุกการรันของ EV-008) ไว้เป็นฐานของการตรวจจับอยู่แล้ว

วิธีทำโปรไฟล์โมเดลใหม่ (ก่อนตัดสินใจ default-on ใด ๆ):

รัน งาน live หนึ่งงานพร้อมเปิด telemetry แล้วยืนยันว่าทุกฟิลด์ usage มีค่าจริง — ผ่านแค่ mock ยังไม่พอ เส้นทางที่มองไม่เห็นจะดูปกติจนกว่าจะเจอของจริง
วัดกราฟ context ที่ถูกฉีดเข้าไปตามแต่ละ turn
นิ่งเป็นที่ราบ → search-type: ตรวจสอบว่าไม่ทำงาน (no-fire) ยังคงอยู่ (ถ้าทำงานคือการออกแบบต้องส่งกลับไปแก้) เพิ่มขึ้นแบบ monotonic → full-read: รันการเปรียบเทียบ 3 แขน (bare / always-on / sentinel)
เปรียบเทียบต้นทุน sentinel/bare ก่อนเปิดใช้งาน — sentinel ที่ทำงานจะคุ้มกับ default-on ก็ต่อเมื่อการแตกงานถูกกว่าการฝ่าไปตรง ๆ (grok คือตัวอย่างค้านที่วัดผลได้จริง)

อ่านเพิ่มเติม

หน้าที่คุณเพิ่งอ่านคือแผนที่ ของจริงอยู่ครบ และมีเอกสารทั้งหมด

เอกสาร	ข้างในมีอะไร
docs/agent-guide.md	บทละครของ AI ผู้ติดตั้ง — ทางเลือก คำสั่ง การตรวจสอบ และวิธีรายงาน เดินทางเดียวจบ (ภาษาอังกฤษ)
docs/benchmark.md	เบนช์มาร์กแบบปิดผนึก — ตัวเลขทั้งหมดเบื้องหลังคำกล่าวอ้างเปิดเรื่อง วิธีวัดผล และข้อจำกัดแบบตรงไปตรงมา (ภาษาอังกฤษ)
docs/engineering.md	คู่มือเทคนิคฉบับเต็ม — อะไรถูกบังคับใช้ที่ไหน ความลึกราย runtime ความหมายของ pause สถาปัตยกรรม แผนที่ไดเรกทอรี (ภาษาอังกฤษ)
docs/reference.md	สัญญาที่แม่นยำ — ทุกแฟล็ก ทุกสถานะ ดัชนีเอกสารการออกแบบ (ภาษาอังกฤษ)
ตั้งค่า runtime (ภาษาอังกฤษ)	การเดินสายรายเครื่องมือ — hooks, verifier และตารางเวลาของ AI ทั้ง 5 ตัว
CONTRIBUTING.md	วิธีเสนอการเปลี่ยนแปลง — เริ่มจาก issue และชุดทดสอบทั้งหมดภายใต้ `tests/` (รันทั้งหมดได้ด้วย `make test` คำสั่งเดียว, ภาษาอังกฤษ)
SECURITY.md	ช่องทางรายงานปัญหาอย่างปลอดภัย — การรายงานช่องโหว่แบบส่วนตัว (ภาษาอังกฤษ)

สถานะโปรเจกต์

CI: — รัน make test + make lint ในทุก pull request
สภาพแวดล้อมที่ตรวจสอบแล้ว: macOS (GitHub Actions macos-latest, Apple silicon), Linux (ubuntu-latest) และ WSL2 (Ubuntu on Windows; ยืนยันเมื่อ 2026-08-23 บน win11-test-vm, 30/30 suites, Linux filesystem, non-root, umask 0002; ยังไม่ผ่าน CI) — ดูตารางใน「สิ่งที่ต้องมี」และ WSL2 support note
ระดับความพร้อม: public preview — สัญญา output ของ CLI ที่ระบุเป็น FROZEN ใน docs/cli-conventions.md มีความเสถียร ส่วนอื่นอาจเปลี่ยนแปลงได้
ข้อจำกัดที่ทราบ: Native Windows ไม่รองรับ; เส้นทางฝั่ง Windows ที่ยืนยันจากการวัดมีเฉพาะแถว WSL2 ด้านบนเท่านั้น และชุดทดสอบ updater บางชุดต้องใช้ ssh-keygen (ดู Prerequisites ใน CONTRIBUTING)

สุดท้ายอีกเรื่องเดียว — ภาพใหญ่ที่เครื่องมือนี้สังกัดอยู่

ส่วนหนึ่งของ Family OS

รีโพนี้เป็นส่วนหนึ่งของ ครอบครัว Caty AI — ชุดเครื่องมือโอเพนซอร์สสำหรับดูแลครอบครัวเอเจนต์ AI แผนที่ฉบับเต็ม (รวมโมดูลที่กำลังเตรียมเปิด) อยู่ที่ Family OS

แกน	โมดูล	ทำอะไร	สถานะ
แผนที่	Family OS	แผนที่ของทั้งครอบครัว — โมดูล สถานะ และโครงสร้าง	เปิดแล้ว・MIT
กติกา	Family Dev Handbook	กติกากลางของการพัฒนา — Issue, PR, worktree, การส่งงานต่อ และการทำงานคู่ขนาน	เปิดแล้ว・MIT
แกนตั้ง · รากฐาน	Caty Agent Harness	แกนงานของเอเจนต์ AI — การลองใหม่ เช็คพอยต์ และการตัดสินว่าเสร็จจริง	เปิดแล้ว・MIT
แกนตั้ง	context-kit	ชุดดูแลคอนเท็กซ์ 6 ชิ้นสำหรับเอเจนต์หนึ่งตัว — จำกัดเอาต์พุตขนาดใหญ่, ตรวจ brief การมอบงาน, การ์ดความปลอดภัย, ค้นความทรงจำ, snapshot ของ worktree	เปิดแล้ว・MIT
แกนตั้ง	Persona Engine	ซ้อนเลเยอร์ความสัมพันธ์และอารมณ์บนบุคลิกเดิมของเอเจนต์	เปิดแล้ว・MIT
แกนตั้ง	Persona Growth Loop	พัฒนาบุคลิกของเอเจนต์ — สร้างข้อเสนอแบบน้อยที่สุดและทำซ้ำได้	เปิดแล้ว・MIT
แกนตั้ง	X Collector	รวบรวมข้อมูลจาก X และเว็บเป็นสรุปวันละฉบับ — สำหรับคนและเอเจนต์	เปิดแล้ว・MIT
แกนตั้ง	Self Growth Loop	วงจรให้เอเจนต์พัฒนาความสามารถของตัวเอง — ข้อเสนอ ธรรมาภิบาล และบันทึกการนำไปใช้	เปิดแล้ว・MIT
แกนนอน · รากฐาน	Family Memory Architecture	บัสความทรงจำ — ชั้นที่ครอบครัวใช้แบ่งปันสิ่งที่รู้	เปิดแล้ว・MIT
แกนนอน	Sitter	พี่เลี้ยงของงานที่มอบหมายให้เอเจนต์ — เฝ้าดู เก็บหลักฐาน และรีสตาร์ตเฉพาะในขอบเขตที่ประกาศไว้	เปิดแล้ว・MIT
แกนนอน	Alpha Nightshift	ลูปบำรุงรักษาอัตโนมัติยามค่ำคืน — เลนกลางคืนทำงานหลังการ์ดแบบปฏิเสธโดยปริยาย ตอนเช้ามนุษย์เลือก cherry-pick	เปิดแล้ว・MIT
แกนนอน	errmeter	รายงาน AI agent และงานตั้งเวลาที่ล้มเหลวหรือเงียบหายข้ามเครื่อง — emit, spool, บอร์ดกลาง, repair hook; เสียงตะโกนที่ไม่มีวันหายไป	เปิดแล้ว・MIT
แกนตั้ง	Caty Gateway	เกตเวย์ฝั่ง PC ของ CatyPhone — ติดตั้งด้วยคำสั่งบรรทัดเดียว เชื่อมโทรศัพท์กับเอเจนต์ที่รันบนเครื่องของคุณ (Claude Code / Codex CLI / OpenClaw / Hermes / OpenAI-compatible)	เปิดแล้ว・MIT

Caty Agent Harness เป็นเครื่องมือหนึ่งใน Family OS — พิมพ์เขียวของโปรเจกต์ Caty AI สำหรับดูแลเอเจนต์ AI หลายตัวเสมือนครอบครัวเดียว ใช้เดี่ยว ๆ ได้เต็มรูปแบบ และจะยิ่งทรงพลังเมื่อประกอบเข้ากับ:

family-os — พิมพ์เขียวที่ร้อยครอบครัวทั้งหมดเข้าด้วยกัน โดย Harness ตัวนี้รับผิดชอบ "แกนตั้ง = ปั้นเอเจนต์รายตัวให้เติบโตและพางานวิ่งจนเสร็จ"
sitter — ผู้เฝ้าดูที่คอยจับตางานเอเจนต์ที่รันยาว ๆ จากภายนอก และยกมือเตือนเมื่องานค้างหรือแข็งตาย

สัญญาอนุญาต

MIT — เลือกใบอนุญาตนี้เพื่อให้ใครก็ได้ใช้ ศึกษา และนำไปประกอบกับอะไรก็ได้อย่างอิสระ รวมถึงระบบ agent เชิงพาณิชย์ นั่นแหละคือจุดประสงค์

ไฟล์ข้อความธรรมดา ｜ ใช้ได้กับเครื่องมือ AI 5 ตัว ｜ คำสั่งเดียวหยุด/ทำต่อได้

FilesExpand file tree

README.th.md

Latest commit

History