Claude Code Harness Foundations
Built-in tools
ทำนายว่าคำขอหนึ่งต้องใช้ความสามารถชนิดใด โดยอ่านเครื่องมือเป็นชนิดของอำนาจที่ harness มอบให้โมเดลเลือกใช้ แล้วอ่านร่องรอยผลจริงที่ป้อนกลับเข้า context
1) จุดสับสน: คำขอแบบไหนที่ทำได้ และเรารู้ล่วงหน้าได้อย่างไร
ในโปรเจกต์ shop-api คุณขอ Claude Code ว่า "เพิ่ม validation ให้ `POST /orders` แล้วรันเทสต์ให้ผ่าน" ไม่กี่อึดใจต่อมา มันเปิดไฟล์ `src/routes/orders.ts` แก้ handler แล้วรายงานผลเทสต์จริงกลับมา แต่พอคุณขอว่า "ช่วยเช็คว่า dependency ตัวนี้มีช่องโหว่ที่เพิ่งประกาศไหม" มันกลับต้องค้นเว็บก่อนจะตอบ และพอขอให้ "รัน migration บนฐานข้อมูลจริง" มันกลับหยุดถามสิทธิ์ก่อนลงมือ คำถามที่ตามมาคือ: อะไรกำหนดว่าคำขอใดทำได้ คำขอใดทำไม่ได้ และทำไมบางคำขอจึงเปลี่ยนไฟล์ได้จริงขณะที่บางคำขอจบลงแค่ข้อความ
คำตอบไม่ได้อยู่ที่ "โมเดลเก่งแค่ไหน" แต่อยู่ที่ชุดความสามารถที่ชั้นห่อโมเดล — harness — ยื่นให้ใช้ โมเดลสร้างได้เพียงข้อความ เมื่ออยากลงมือมันต้อง "ขอใช้เครื่องมือ" (tool) ซึ่ง harness เป็นผู้ถือไว้ให้ เครื่องมือแต่ละตัวให้อำนาจคนละแบบ: อ่านไฟล์ แก้ไฟล์ ค้นหา รันคำสั่ง ต่ออินเทอร์เน็ต วิเคราะห์โค้ด บทนี้จึงสอนให้อ่านเครื่องมือเป็น **ชนิดของอำนาจ** ก่อนจะจำชื่อ เพราะชนิดของอำนาจนิ่ง แต่ชื่อและรายละเอียดของเครื่องมือเปลี่ยนได้ตามการพัฒนาผลิตภัณฑ์
2) Mental model: เครื่องมือคือมือของโมเดล และ harness เป็นเจ้าของมือนั้น
ย้อนกลไกจากสองบทก่อนหน้า: โมเดลมีหน้าที่ให้เหตุผลและสร้างข้อความ ส่วน harness เป็นชั้นที่ลงมือ ลำดับเหตุการณ์เมื่อ Claude Code ทำงานใน shop-api จึงมีสามจังหวะ: 1. โมเดลอ่าน context แล้ว **ขอ** ใช้เครื่องมือหนึ่งอย่าง เช่น ขออ่านไฟล์ หรือขอรันคำสั่ง 2. harness **ตรวจ** ว่าเครื่องมือนั้นพร้อมใช้ใน session นี้ และเทียบกับกฎสิทธิ์ก่อน 3. harness **ลงมือรันจริง** แล้วเอาผลลัพธ์จริงกลับเข้า context ของรอบถัดไป การ "ขอ" ของโมเดลคือการตัดสินใจ — จะใช้เครื่องมือใดและเมื่อใดเป็นเรื่องของโมเดล ไม่มีกฎตายตัวให้ทำนาย ส่วนการตรวจสิทธิ์ การรัน และการป้อนผลกลับเป็นของ harness ผลที่ตามมาคือประโยคสำคัญของบทนี้: **ความสามารถของ session ถูกจำกัดด้วยชุดเครื่องมือ ไม่ใช่ด้วยความฉลาดของโมเดล** ถ้าไม่มีความสามารถชนิดนั้นอยู่ในมือ คำขอที่ต้องใช้มันก็จบได้เพียงข้อความเสมอ
อ่านเครื่องมือหนึ่งตัวด้วยสามคำถาม
1. ให้อำนาจอะไร
เครื่องมือแต่ละตัวให้ความสามารถคนละชนิด มีทั้งชนิดที่เพียงสังเกต (อ่าน ค้นหา) และชนิดที่ลงมือเปลี่ยนสภาพจริง (แก้ไฟล์ รันคำสั่ง) ชนิดของอำนาจคือสิ่งที่บอกว่าคำขอใดทำได้
2. ใครเลือกใช้
โมเดลเป็นผู้เลือกว่าจะขอเครื่องมือใด ด้วย argument อะไร และเมื่อใด — เป็นการตัดสินใจของโมเดล จึงอธิบายได้ในเชิงแนวโน้ม แต่ไม่ใช่กฎที่ทำนายได้ตายตัว
3. ใครถือกุญแจ
harness เป็นเจ้าของเครื่องมือทั้งหมด: ตัดสินว่าตัวใดมีใน session นี้ ตรวจสิทธิ์ก่อนรัน ลงมือรันจริง และป้อนผลลัพธ์จริงกลับเข้า context
3) กลไก: หนึ่งคำขอเครื่องมือเดินครบวงอย่างไร
วงจรของเครื่องมือมีจังหวะที่เกิดซ้ำในทุกการลงมือ จังหวะแรกและจังหวะสุดท้ายเป็นการตัดสินใจของโมเดล ส่วนจังหวะกลางเป็นการทำงานของ harness
วงจรของหนึ่งคำขอเครื่องมือ
ทุกการลงมือใน session เดินตามลำดับนี้ ไม่ว่าจะเป็นเครื่องมือชนิดใด — ความต่างอยู่ที่ว่าเครื่องมือนั้นให้อำนาจอะไร
- 1
ขอใช้เครื่องมือ
โมเดลโมเดลสร้างคำขอว่าเครื่องมือใด พร้อม argument เช่น path ของไฟล์หรือคำสั่งที่จะรัน — จังหวะนี้ยังไม่มีอะไรเกิดขึ้นกับเครื่องของคุณ
- 2
ตรวจความพร้อมและสิทธิ์
harnessharness เช็คว่าเครื่องมือนั้นมีใน session นี้ และเทียบกับกฎว่า allow, ask หรือ deny ก่อนที่อะไรจะเกิดขึ้น
- 3
ลงมือรัน
harnessถ้าผ่าน harness รันเครื่องมือจริงบนเครื่องของคุณ ถ้าไม่ผ่าน การกระทำไม่เกิด และโมเดลได้รับผลนั้นเป็นข้อเท็จจริง
- 4
ป้อนผลกลับ
harnessoutput, error หรือสภาพที่เปลี่ยนไปของโปรเจกต์ถูกเพิ่มเข้า context ของรอบถัดไป — โมเดลเห็นผลจริง ไม่ใช่ความคาดเดาของตัวเอง
- 5
ตัดสินรอบใหม่
โมเดลโมเดลเห็นผลจริงแล้วเลือกว่าจะขอเครื่องมือถัดไป เปลี่ยนทาง หรือสรุป — จังหวะที่เครื่องมือหนึ่งนำไปสู่อีกเครื่องมือหนึ่ง
ความสามารถหลักของ harness จัดกลุ่มตามชนิดของอำนาจ ไม่ใช่ตามชื่อเครื่องมือ: กลุ่มที่แตะไฟล์ในโปรเจกต์ กลุ่มที่ค้นหาโดยไม่ต้องเปิดทุกไฟล์ กลุ่มที่รันคำสั่งบนเครื่อง กลุ่มที่ดึงข้อมูลจากอินเทอร์เน็ต และกลุ่มที่วิเคราะห์เชิงโค้ดจาก language server นอกจากนี้ยังมีกลุ่มเครื่องมือเชิง orchestration เช่น การมอบงานให้ agent ที่มี context แยก หรือการถามคำถามกลับมาที่คุณ สิ่งที่ต่างกันชัดที่สุดระหว่างกลุ่มคือ "ผลลัพธ์ของมันเปลี่ยนอะไร": กลุ่มสังเกต (อ่าน ค้นหา วิเคราะห์) ไม่แตะโปรเจกต์เลยแต่ป้อนข้อเท็จจริงเข้า context; กลุ่มลงมือ (แก้ไฟล์ รันคำสั่ง) เปลี่ยนสภาพจริงแล้วผลของการเปลี่ยนนั้นก็กลับเข้า context; กลุ่มเว็บนำข้อความจากภายนอกเข้ามา; และกลุ่ม orchestration ส่งงานไปทำใน context แยก แล้วนำเฉพาะผลสรุปกลับเข้ามา ไม่ว่ากลุ่มใด ผลลัพธ์สุดท้ายที่โมเดลเห็นคือข้อความที่ถูกเพิ่มเข้า context รอบถัดไป — บทถัดไปจะพาไปดูว่าพื้นที่นั้นมีขอบเขตเท่าไร และเกิดอะไรขึ้นเมื่อมันใกล้เต็ม
| กลุ่มความสามารถ | ให้อำนาจอะไร | ตัวอย่างชื่อเครื่องมือ |
|---|---|---|
| ไฟล์ในโปรเจกต์ (file operations) | อ่านเนื้อไฟล์ แก้ไขเฉพาะจุด สร้างหรือเขียนทับ และจัดการไฟล์ในโปรเจกต์ | `Read`, `Edit`, `Write`, `NotebookEdit` |
| ค้นหา (search) | หาไฟล์จาก pattern และค้นเนื้อหาด้วย regex โดยไม่ต้องเปิดทั้งไฟล์ | `Glob`, `Grep` |
| รันคำสั่ง (execution) | รันคำสั่งบนเครื่อง เช่น เทสต์ เซิร์ฟเวอร์ และ git | `Bash`, `PowerShell` |
| เว็บ (web) | ค้นเว็บและดึงเนื้อหาจาก URL | `WebFetch`, `WebSearch` |
| วิเคราะห์โค้ด (code intelligence) | อ่านผลวิเคราะห์จาก language server: type error นิยาม และการอ้างอิง | `LSP` |
| มอบหมายงาน (orchestration) | มอบงานให้ agent ที่มี context แยก และถามคำถามกลับมาที่คุณ | `Agent`, `AskUserQuestion` |
| ตรวจสอบล่าสุด: 2026-09-23 · https://code.claude.com/docs/en/tools-reference |
4) Contrast: ถ้อยคำที่อ้างว่าทำ กับร่องรอยที่ยืนยันว่าทำ
ความต่างระหว่างสองแบบด้านล่างไม่ได้อยู่ที่ความยาวหรือน้ำเสียงของคำตอบ แต่อยู่ที่ว่ามีคำขอเครื่องมือและผลลัพธ์จริงเกิดขึ้นหรือไม่
คำขอเดียวกัน สองกลไกที่ให้ผลต่างกัน
ฝั่งซ้ายตอบได้อย่างมั่นใจโดยไม่มีอะไรเกิดขึ้นจริง ฝั่งขวาแต่ละความสามารถเกิดจากเครื่องมือหนึ่งชนิด และทิ้งร่องรอยที่ตรวจสอบได้
คำตอบอาจฟังดูมั่นใจ แต่ความสามารถทั้งหมดเป็นเพียงข้อความที่ไม่มีหลักฐานรองรับ
โจทย์เดียวกันกลายเป็นการเปลี่ยนแปลงที่ตรวจสอบได้ เพราะทุกความสามารถมาจากเครื่องมือที่ harness รันจริง
5) ฝึก: ทำนายความสามารถที่โจทย์ต้องใช้ก่อนเปิดเฉลย
โจทย์ใน shop-api คือ: "เพิ่ม validation ให้ POST /orders แล้วรันเทสต์ให้ผ่าน" ก่อนเปิดเฉลย ให้เขียนคำตอบของคุณเองก่อน — บทนี้ไม่ให้เดาว่าโมเดลจะเลือกเครื่องมือตัวใด (การเลือกเป็นของโมเดล) แต่ให้ระบุชนิดของความสามารถที่โจทย์นี้ขาดไม่ได้ และร่องรอยที่จะยืนยันว่าจบงาน
งานที่ต้องทำ
- ทำนายก่อนดูเฉลย: เขียนคำตอบของคุณเองสามข้อ — โจทย์นี้ต้องใช้ความสามารถชนิดใดบ้าง, จังหวะใดเป็นของโมเดลและจังหวะใดเป็นของ harness, และร่องรอยอะไรที่จะพิสูจน์ว่างานจบจริง
- ระบุว่าถ้าขาดความสามารถชนิดใดชนิดหนึ่งไป งานจะค้างตรงไหน และเพราะเหตุใด
- เปิดเฉลย แล้วไล่ทีละบรรทัด: เทียบคำขอเครื่องมือแต่ละครั้งกับสิ่งที่คุณทำนายไว้ และจดว่าคุณลืมนึกถึงชนิดใด
- ปิดท้ายด้วยคำตอบเดียว: เพราะเหตุใด "คำตอบที่ฟังดูมั่นใจ" จึงไม่ใช่หลักฐานว่าความสามารถนั้นมีอยู่จริง
ลองทำด้วยตัวเองก่อน แล้วค่อยเปิดเฉลยเพื่อเทียบแนวคิดและรายละเอียด
6) ตรวจความเข้าใจและก้าวต่อไป
ทดสอบความเข้าใจ: เครื่องมือและความสามารถของ session
ตอบคำถามต่อไปนี้เพื่อยืนยันว่าคุณแยกได้ว่าความสามารถมาจากไหน และส่วนใดของวงจรเป็นของโมเดลหรือของ harness
ข้อใดอธิบายได้ว่าทำไม Claude Code จึงลงมือกับโปรเจกต์ได้ ไม่ใช่แค่ตอบข้อความ
ในการใช้เครื่องมือหนึ่งครั้ง ข้อใดเป็นเรื่องของโมเดล ไม่ใช่ของ harness
เมื่อคำตอบหนึ่งไม่มีร่องรอยว่ามีคำขอเครื่องมือเลย ข้อสรุปใดถูกต้องที่สุด
หลังเครื่องมือรันจบ ผลลัพธ์จริงจะถูกป้อนกลับเข้า ______ ของรอบถัดไป
ตอบเป็นคำภาษาอังกฤษคำเดียว
- ความสามารถของ session มาจากชุดเครื่องมือที่ harness มอบให้ ไม่ได้อยู่ในตัวโมเดล
- หนึ่งคำขอเครื่องมือเดินเป็นวงจร: ขอ → ตรวจความพร้อมและสิทธิ์ → รัน → ป้อนผลกลับ → ตัดสินรอบใหม่
- จังหวะ "ขอ" และ "ตัดสินรอบใหม่" เป็นของโมเดล ส่วน "ตรวจ–รัน–ป้อนกลับ" เป็นของ harness
- ก้าวต่อไป: บทถัดไปคือ The context window ซึ่งจะพาไปดูว่าทำไมพื้นที่ที่ผลลัพธ์ทุกอย่างไหลกลับเข้าไปจึงจำกัด และ harness ทำอะไรเมื่อมันใกล้เต็ม