ในเดือนกุมภาพันธ์ 2026 ทีมเล็กๆ ของ OpenAI ได้ส่งโค้ดสำหรับระบบ production จำนวน 1 ล้านบรรทัด
พวกเขาไม่ได้เขียนโค้ดแม้แต่บรรทัดเดียวด้วยมือ
AI agents เป็นคนเขียน
มนุษย์เป็นผู้ออกแบบระบบที่ทำให้ agents เหล่านั้นเชื่อถือได้
ระบบนั้นมีชื่อแล้ว
วิศวกรรม Harness (Harness Engineering)
ภายในไม่กี่สัปดาห์ Anthropic ตีพิมพ์บทความวิจัย 3 ฉบับเกี่ยวกับเรื่องนี้
ThoughtWorks ทำให้กรอบแนวคิดเป็นทางการ
Philipp Schmid จาก Hugging Face เรียกมันว่า "สาขาวิชาที่สำคัญที่สุดของปี 2026"
สาขาวิชาวิศวกรรมใหม่เกิดขึ้นภายใน 90 วัน
และแทบไม่มีใครนอกทีมโครงสร้างพื้นฐาน AI เข้าใจมัน
บทความนี้จะอธิบายทุกอย่าง
ไม่มีเนื้อหาฟุ่มเฟือย ไม่มีศัพท์วิชาการ แค่แนวคิดที่คุณต้องใช้จริง
บันทึกไว้เลย คุณจะอ่านมันสองรอบ
ส่วนที่ 1: HARNESS จริงๆ แล้วคืออะไร (แนวคิดที่เปลี่ยนวิธีคิดของคุณเกี่ยวกับ AI)
1. นิยามของ Harness
นิยามที่ง่ายที่สุดมาจาก ThoughtWorks:
→ Agent = Model + Harness
Harness คือทุกสิ่งที่ไม่ใช่ตัว model
ข้อจำกัดที่ทำให้ agent อยู่ในเส้นทาง วงจรป้อนกลับที่จับข้อผิดพลาด เอกสารที่บอก agent ว่ามันอยู่ตรงไหน เครื่องมือที่มันได้รับอนุญาตให้ใช้
ถอด Harness ออก → model ภาษาดิบๆ ที่เดาไปเรื่อยใน codebase ของคุณ
เพิ่ม Harness ที่เหมาะสม → ระบบที่ส่งโค้ด production ออกมาได้
ชื่อนี้มาจากอุปกรณ์บังคับม้า
Harness คือบังเหียน อานม้า และบิตที่ชักนำสัตว์ที่ทรงพลังแต่คาดเดาไม่ได้ให้ไปในทิศทางที่เป็นประโยชน์
คุณไม่ได้ทำให้ม้าฉลาดขึ้น คุณออกแบบอุปกรณ์ที่ทำให้พละกำลังของมันมีประโยชน์
2. การเปรียบเทียบกับระบบปฏิบัติการ
Philipp Schmid ให้กรอบแนวคิดทางเทคนิคที่ดีที่สุด:
ลองนึกถึงมันเหมือนคอมพิวเตอร์
→ Model = CPU (พลังการประมวลผลดิบ)
→ Context window = RAM (หน่วยความจำทำงานที่จำกัดและผันผวน)
→ Harness = ระบบปฏิบัติการ (จัดการสิ่งที่ CPU เห็นและเมื่อไหร่)
→ Agent = แอปพลิเคชัน ที่ทำงานอยู่บนนั้น
Model ของคุณทรงพลัง
แต่ถ้าไม่มี OS จัดการหน่วยความจำ จัดตารางงาน และบังคับใช้กฎ — มันก็แค่ซิลิคอน
คนส่วนใหญ่กำลังรันแอปที่ไม่มีระบบปฏิบัติการ
นั่นคือสาเหตุที่ agents ของพวกเขาล้มเหลวใน production
3. สิ่งที่เปลี่ยนไปในปี 2026
LangChain รัน model เดียวกันบน Terminal Bench 2.0 สองครั้ง
Model เดียวกัน Harning ต่างกัน
→ Harness เก่า: คะแนน 52.8%
→ Harness ใหม่: คะแนน 66.5%
Vercel ไปในทิศทางตรงกันข้าม
พวกเขาลบเครื่องมือของ agent ออกไป 80%
ผลลัพธ์? ประสิทธิภาพดีขึ้น
ไม่ใช่แย่ลง
ความจริงอันไม่สบายใจของปี 2026:
→ Agent ไม่เคยเป็นส่วนที่ยาก
→ Harness ต่างหาก
ถ้าปี 2025 เป็นปีที่ AI agents พิสูจน์ว่าพวกเขาเขียนโค้ดได้...
ปี 2026 คือปีที่เราค้นพบว่าสภาพแวดล้อมสำคัญกว่า model
ส่วนที่ 2: 5 สิ่งประดิษฐ์ของ HARNESS (Harness จริงๆ แล้วหน้าตาเป็นอย่างไรในทางปฏิบัติ)
4. ไฟล์ AGENT.md / CLAUDE.md
สิ่งประดิษฐ์ Harness ที่เป็นสากลที่สุด
ไฟล์ Markdown ที่กระจายอยู่ทั่ว codebase ของคุณ
Agent อ่านมันตอนเริ่มต้นทุกเซสชัน — เหมือนเอกสารปฐมนิเทศสำหรับวิศวกรใหม่ที่เข้าร่วมทีม
สิ่งที่อยู่ในนั้น:
→ บริบทของโปรเจกต์
→ หลักปฏิบัติในการเขียนโค้ด
→ การตัดสินใจเกี่ยวกับสถาปัตยกรรม
→ คำแนะนำ "วิธีที่เราทำสิ่งต่างๆ ที่นี่"
→ สิ่งที่กำลังดำเนินการอยู่
OpenAI เรียกมันว่า AGENT.md
Anthropic เรียกมันว่า CLAUDE.md
Cursor ใช้ .cursorrules
ชื่อต่างกัน หลักการเดียวกัน
หนึ่งไฟล์ต่อหนึ่งโมดูลหลัก อัปเดตเมื่อโปรเจกต์พัฒนาไป
หากไม่มี: agent เริ่มทุกเซสชันแบบไม่รู้อะไรเลย หากมี: agent เริ่มทุกเซสชันโดยมีข้อมูลพร้อม
5. รายการคุณสมบัติแบบ JSON (ตัวติดตามความคืบหน้า)
เมื่อ agent สร้างแอปทั้งตัวในหลายเซสชัน มันจะเริ่มแต่ละเซสชันด้วย context window ที่ว่างเปล่า
มันจะรู้ได้อย่างไรว่าอะไรเสร็จไปแล้ว?
ไฟล์ JSON
แต่ละรายการกำหนด:
→ คุณสมบัติ
→ วิธีตรวจสอบว่ามันทำงาน
→ สถานะ ผ่าน / ไม่ผ่าน
Agent อ่านสิ่งนี้เมื่อเริ่มเซสชัน เลือกคุณสมบัติที่ล้มเหลวที่มีลำดับความสำคัญสูงสุด นำไปใช้ ทำเครื่องหมายว่าผ่าน คอมมิต ทำซ้ำ
ทำไมต้อง JSON ไม่ใช่ Markdown?
Anthropic พบว่า agents มีแนวโน้มที่จะเขียนทับ JSON โดยไม่ได้ตั้งใจน้อยกว่า Markdown
รายละเอียดเล็กน้อย มีความสำคัญมากในการทำงานอัตโนมัติ 6 ชั่วโมง
6. กิจวัตรการเริ่มต้นเซสชัน
ทุกเซสชันเริ่มต้นในลักษณะเดียวกัน
ทุกครั้ง ทุกครั้ง
ลำดับการบูต 7 ขั้นตอนของ Anthropic:
- ยืนยันไดเรกทอรีทำงาน
- อ่าน git logs และไฟล์ความคืบหน้า
- ตรวจสอบรายการคุณสมบัติสำหรับรายการที่ยังไม่เสร็จสมบูรณ์ที่มีลำดับความสำคัญสูงสุด
- เริ่ม dev server
- รันการตรวจสอบ end-to-end ขั้นพื้นฐาน
- นำไปใช้หนึ่งคุณสมบัติ
- คอมมิตพร้อมข้อความอธิบาย + อัปเดตความคืบหน้า
หากไม่มี:
Agent เสียเวลา 20 นาทีแรกไปกับการหาว่ามีอะไรอยู่แล้ว
ทุกเซสชันคือการ reinvent the wheel
หากมี:
Agent เริ่มต้นทันทีโดยมีข้อมูลและดำเนินการทำงานทันที
7. สัญญา Sprint
ก่อนที่ agent จะเขียนโค้ดแม้แต่บรรทัดเดียว:
Agent สองตัวเจรจากัน
Agent ผู้สร้าง (Generator) เสนอ:
→ สิ่งที่จะสร้าง
→ จะตรวจสอบความสำเร็จได้อย่างไร
Agent ผู้ประเมิน (Evaluator) ตรวจสอบ:
→ ข้อเสนอครบถ้วนหรือไม่?
→ เกณฑ์ความสำเร็จชัดเจนหรือไม่?
หลังจากทั้งสองเห็นพ้องกันเท่านั้น การนำไปใช้จึงจะเริ่มต้นขึ้น
มันคือการทบทวนการออกแบบ
ยกเว้นว่าผู้เข้าร่วมทั้งสองคือ AI
ทำไมสิ่งนี้ถึงสำคัญ?
Agents ที่วางแผนและดำเนินการในรอบเดียวกันจะให้ผลลัพธ์ที่ไม่น่าเชื่อถือ
ขั้นตอนการวางแผน — แม้จะทำโดย AI — ช่วยปรับปรุงคุณภาพผลลัพธ์ได้อย่างมาก
8. เทมเพลตงานที่มีโครงสร้าง
ก่อนการเขียนโค้ดใดๆ:
Harness วิเคราะห์ codebase จริง
มันสร้างแผนที่ผลกระทบที่มีพื้นฐาน:
→ เส้นทางไฟล์จริง (ไม่ใช่ที่สร้างขึ้นเอง)
→ ชื่อสัญลักษณ์จริงที่มีอยู่จริง
→ รูปแบบที่มีอยู่ให้ปฏิบัติตาม
→ เกณฑ์การยอมรับที่เป็นรูปธรรม
จากนั้นการนำไปใช้จึงเริ่มต้นขึ้น
ฟังดูชัดเจน
แต่ทีมส่วนใหญ่ข้ามขั้นตอนนี้
Agent เดาโครงสร้างไฟล์ สร้าง API endpoints ที่ไม่มีอยู่จริง สร้างสิ่งที่ไม่เข้ากับ codebase
บริบทที่มีพื้นฐานก่อนการดำเนินการ → ผลลัพธ์ที่ดีกว่าอย่างมาก
ส่วนที่ 3: สามค่าย (สามทีมเจอกำแพงเดียวกัน — และสร้างบันไดที่แตกต่างกันสามแบบ)
9. OpenAI: สภาพแวดล้อมต้องมาก่อน
ทีม Codex ของ OpenAI มีปัญหาที่ไร้สาระ
โค้ด production 1 ล้านบรรทัด ไม่มีแม้แต่บรรทัดเดียวที่เขียนด้วยมือ
ในระดับนั้น คุณไม่สามารถตรวจสอบโค้ดทุกบรรทัดได้
พวกเขาจึงไม่ทำ
แต่พวกเขาออกแบบสภาพแวดล้อมอย่างละเอียดถี่ถ้วนจน agents สร้างผลลัพธ์ที่ตรวจสอบได้ตั้งแต่แรก
แนวทางของพวกเขา:
→ การไหลของ dependencies ที่เข้มงวด (Types → Config → Repo → Service → Runtime → UI)
→ ไฟล์ AGENT.md ทั่ว codebase
→ Agents เชื่อมต่อโดยตรงกับไปป์ไลน์ CI/CD
ปรัชญา: ออกแบบสภาพแวดล้อม จากนั้นปล่อย agent
ข้อพิสูจน์: แอป Sora Android วิศวกร 4 คน 28 วัน อันดับ 1 บน Play Store ปลอดการค้าง 99.9%
Codex จัดการคำขอ pull request ภายใน 70% ทุกสัปดาห์
10. Anthropic: แยกผู้ทำออกจากผู้ตัดสิน
Anthropic มีปัญหาที่แตกต่างออกไป
เมื่อพวกเขาขอให้ agent ประเมินผลลัพธ์ของตัวเอง:
มันจะชื่นชมงานอย่างมั่นใจ
แม้ว่าในสายตาของมนุษย์ คุณภาพจะดูธรรมดาอย่างเห็นได้ชัด
การประเมินตนเองใช้ไม่ได้ผล
Agent เป็นทั้งนักเรียนและครู
และมันให้เกรด A กับตัวเองตลอด
วิธีแก้ไขของพวกเขา: Agent เฉพาะทางสามตัว
→ นักวางแผน (Planner) — เปลี่ยนพรอมต์ 2 ประโยคเป็นสเปกผลิตภัณฑ์เต็มรูปแบบ
→ ผู้สร้าง (Generator) — นำไปใช้คุณสมบัติทีละ sprint
→ ผู้ประเมิน (Evaluator) — ใช้ระบบอัตโนมัติของเบราว์เซอร์เพื่อทดสอบแอปที่รันอยู่เหมือนผู้ใช้จริง
ข้อมูลเชิงลึก: การทำให้ผู้ประเมินอิสระมีท่าทีสงสัยนั้นง่ายกว่าการทำให้ผู้สร้างวิพากษ์วิจารณ์งานของตัวเองมาก
ผลลัพธ์: Agent เดี่ยว (ไม่มี harness): $9, 20 นาที → แอปที่พัง Harness เต็มรูปแบบ: $200, 6 ชั่วโมง → ซอฟต์แวร์ที่ทำงานได้พร้อม UI ที่สวยงาม
11. ThoughtWorks: กรอบแนวคิด 2×2
ThoughtWorks มาจากมุมที่แตกต่าง
พวกเขาไม่ได้สร้างผลิตภัณฑ์
พวกเขากำลังดูทีมวิศวกรรมกว่า 50 ทีมล้มเหลวในสิ่งเดียวกัน
ข้อมูลเชิงลึกของพวกเขา: จัดประเภทการควบคุม harness ทุกรายการตามสองแกน
แกนที่ 1: มันทำงานเมื่อไหร่?
→ Feedforward = ก่อนที่ agent จะกระทำ (คำแนะนำ)
→ Feedback = หลังจากที่ agent กระทำ (เซ็นเซอร์)
แกนที่ 2: มันทำงานอย่างไร?
→ Computational = แน่นอน, มิลลิวินาที (linters, type checkers, ชุดทดสอบ)
→ Inferential = ใช้ LLM, วินาที (agent ตรวจสอบโค้ด, การวิเคราะห์เชิงความหมาย)
2×2:
→ Computational Feedforward: ระบบ type, linters, กฎสถาปัตยกรรม
→ Computational Feedback: ชุดทดสอบ, การวิเคราะห์ความครอบคลุม, การทดสอบการกลายพันธุ์
→ Inferential Feedforward: เอกสารสเปก, คำอธิบายข้อจำกัด
→ Inferential Feedback: ผู้ตรวจสอบโค้ด LLM, ตัวตรวจสอบพฤติกรรม
ทั้ง feedforward หรือ feedback อย่างเดียวใช้ไม่ได้ผล
คุณต้องมีทั้งสองอย่าง
ส่วนที่ 4: 5 หลักการที่ทุกค่ายเห็นพ้องต้องกัน (สามทีมไม่เคยประสานงานกัน พวกเขามาถึงจุดนี้โดยอิสระ)
12. หลักการที่ 1: บริบทดีกว่าคำสั่ง
OpenAI: "ให้แผนที่ ไม่ใช่คู่มือ 1,000 หน้า"
Anthropic: รายการคุณสมบัติ JSON และไฟล์ความคืบหน้าเพื่อให้ agents รู้อยู่เสมอว่าพวกเขาอยู่ที่ไหน
Red Hat: วิเคราะห์ codebase จริงก่อนสร้างงานใดๆ
ThoughtWorks: "Feedforward"
คำต่างกัน การค้นพบเดียวกัน
การแสดงสถานะปัจจุบันของโลกให้ agent เห็นนั้นให้ผลลัพธ์ดีกว่าการบอกให้มันทำสิ่งที่เป็นนามธรรมอย่างสม่ำเสมอ
→ มีพื้นฐานในเส้นทางไฟล์จริง → โค้ดที่เข้ากับ codebase
→ ทำงานจากคำอธิบายที่คลุมเครือ → เส้นทางไฟล์ที่สร้างขึ้นเองและ API ที่ประดิษฐ์ขึ้น
บทเรียน: ก่อนที่ agent จะพิมพ์อะไร ตรวจสอบให้แน่ใจว่ามันรู้แน่ชัดว่ามันอยู่ที่ไหน
13. หลักการที่ 2: การวางแผนและการดำเนินการต้องแยกจากกัน
OpenAI: มนุษย์ออกแบบสภาพแวดล้อม agents ดำเนินการ
Anthropic: Agent นักวางแผนโดยเฉพาะทำงานก่อนที่ Generator จะแตะโค้ดใดๆ
ThoughtWorks: จุดตรวจสอบการทบทวนโดยมนุษย์ที่บังคับระหว่างการวางแผนและการนำไปใช้
Red Hat: เฟส 1 (แผนที่ผลกระทบ) และเฟส 2 (การนำไปใช้) โดยมีประตูกั้นที่เข้มงวดระหว่างกัน
ทุกค่ายค้นพบสิ่งนี้โดยอิสระ:
การปล่อยให้ agent วางแผนและดำเนินการในรอบเดียวกันทำให้เกิดผลลัพธ์ที่ไม่น่าเชื่อถือ
ขั้นตอนการวางแผนไม่จำเป็นต้องทำโดยมนุษย์
แต่มันต้องเป็นขั้นตอนที่แยกต่างหาก โดยมีผลลัพธ์ที่ได้รับการตรวจสอบก่อนเริ่มดำเนินการ
14. หลักการที่ 3: วงจรป้อนกลับเป็นสิ่งที่ขาดไม่ได้
OpenAI: agents เชื่อมต่อกับระบบ CI/CD และการสังเกตการณ์
Anthropic: Agent ผู้ประเมินโดยเฉพาะใช้ระบบอัตโนมัติของเบราว์เซอร์
ThoughtWorks: ทำให้เป็นทางการเป็น "เซ็นเซอร์" เตือนว่าแนวทางแบบ feedforward-only ไม่เคยยืนยันว่าคำแนะนำใช้ได้ผลจริงหรือไม่
สามแนวทางสำหรับหลักการเดียวกัน:
→ OpenAI ใช้การทดสอบอัตโนมัติและ CI
→ Anthropic ใช้ LLM อีกตัว
→ ThoughtWorks บอกให้ใช้ทั้งสองอย่าง ซ้อนกัน
พวกเขาไม่เห็นด้วยว่าใครเป็นผู้ให้ข้อเสนอแนะ
พวกเขาไม่เห็นด้วยว่าคุณต้องการมันหรือไม่
Harness ที่ไม่มี feedback ก็แค่พรอมต์ที่มีขั้นตอนเพิ่มเติม
15. หลักการที่ 4: ทีละอย่าง
OpenAI: แบ่งเป้าหมายเป็นบล็อก building blocks ที่เล็กลง ทำงานแบบ depth-first
Anthropic: บังคับหนึ่งคุณสมบัติต่อ sprint โดยมีการคอมมิตหลังจากแต่ละครั้ง
ThoughtWorks: วงจรชีวิตแบบแบ่งเฟส (ก่อนการรวม → หลังการรวม → การตรวจสอบอย่างต่อเนื่อง)
Agents ที่พยายามทำมากเกินไปในคราวเดียว:
→ ใช้ context หมด
→ สูญเสียความสอดคล้อง
→ ละทิ้งข้อกำหนดอย่างเงียบๆ
กิจวัตรของ Anthropic:
อ่านความคืบหน้า → เลือกหนึ่งคุณสมบัติ → นำไปใช้ → คอมมิต → ทำซ้ำ
การเพิ่มขึ้นทีละน้อยแบบบังคับเป็นสากลในทุก harness ที่ประสบความสำเร็จ
16. หลักการที่ 5: Codebase คือเอกสารประกอบ
OpenAI: ฝังไฟล์ AGENT.md ไว้ใน repo
Anthropic: จัดเก็บรายการคุณสมบัติ ไฟล์ความคืบหน้า และประวัติ git เป็นกลไกความต่อเนื่องของ agent
ThoughtWorks: วัด "ความสามารถในการใช้ harness" — ว่า codebase สามารถอ่านเข้าใจได้สำหรับ agents แค่ไหน
ไม่มีใครดูแลฐานความรู้แยกต่างหากสำหรับ agent
Repo คือแหล่งความจริงแหล่งเดียว
หากธรรมเนียมปฏิบัติ ข้อจำกัด หรือการตัดสินใจทางสถาปัตยกรรมไม่ได้อยู่ใน codebase — agent จะไม่รู้เกี่ยวกับมัน
นัยเชิงปฏิบัติ:
→ ทีมที่ลงทุนในการจัดระเบียบโค้ดจะได้รับประสิทธิภาพของ agent ที่ดีขึ้นโดยอัตโนมัติ
→ Repo ที่รก + AI agents = ความโกลาหล แต่ในระดับที่ใหญ่ขึ้น
ส่วนที่ 5: ข้อขัดแย้ง — สร้างเพื่อลบ (ความจริงที่ขัดกับสัญชาตญาณมากที่สุดในวิศวกรรม Harness)
17. การเสื่อมของ Harness เป็นเรื่องจริง
เมื่อ Anthropic อัปเกรดจาก Opus 4.5 เป็น Opus 4.6:
การแยกย่อย Sprint — ซึ่งเคยจำเป็น — กลายเป็นน้ำหนักที่ไร้ประโยชน์
ความสามารถในการวางแผนที่ดีขึ้นของ model ทำให้มันซ้ำซ้อน
ส่วนประกอบของ harness ที่รับน้ำหนักในเดือนมีนาคมกลายเป็นภาระในเดือนเมษายน
จากนั้น Opus 4.7 ก็มา
Model เริ่มตรวจสอบผลลัพธ์ของตัวเอง
รายละเอียดงานของ Agent ผู้ประเมินเริ่มหดเล็กลง
นี่คือ การเสื่อมของ Harness (Harness Decay)
ทุกส่วนประกอบใน harness เข้ารหัสสมมติฐานเกี่ยวกับสิ่งที่ model ไม่สามารถทำได้
เมื่อ models พัฒนาขึ้น → สมมติฐานเหล่านั้นหมดอายุ → ส่วนประกอบนั้นกลายเป็นภาระ
Opus 4.5: การแยกย่อย sprint + การประเมินต่อ sprint
Opus 4.6: ไม่มีการแยกย่อย sprint + การประเมินครั้งเดียว (ประหยัดต้นทุน 38%)
Opus 4.7: model เริ่มตรวจสอบตัวเอง → บทบาทผู้ประเมินหดเล็กลงอีก
18. สร้างเพื่อลบ
คำแนะนำของ Philipp Schmid:
"สร้างเพื่อลบ"
ออกแบบทุกส่วนประกอบของ harness ให้สามารถลบออกได้
ทดสอบแต่ละส่วนประกอบเป็นระยะโดยปิดมันและวัดว่าคุณภาพผลลัพธ์เปลี่ยนแปลงหรือไม่
ถ้าไม่เปลี่ยนแปลง: ลบทิ้ง
Manus ปรับโครงสร้าง harness ของพวกเขา 5 ครั้งใน 6 เดือน LangChain ปรับโครงสร้าง 3 ครั้งใน 1 ปี Vercel ลบเครื่องมือ 80% → ได้ประสิทธิภาพดีขึ้น
สิ่งเหล่านี้ไม่ใช่สัญญาณของวิศวกรรมที่ไม่ดี
มันเป็นผลตามธรรมชาติของการสร้างบน models ที่พัฒนาอย่างรวดเร็ว
การแบกส่วนประกอบ harness ที่ตายแล้วทำให้เสีย tokens ทุกครั้งที่รัน คุณภาพเพิ่มขึ้นเป็นศูนย์ สิ้นเปลืองล้วนๆ
19. ความเป็นจริงด้านต้นทุน
ตัวเลขที่ตรงไปตรงมาจากการทดสอบ A/B ของ Anthropic:
→ Agent เดี่ยว (ไม่มี harness): $9, 20 นาที
→ UI ที่ใช้งานได้, ฟังก์ชันหลักพัง
→ Harness เต็มรูปแบบ (Opus 4.5): $200, 6 ชั่วโมง
→ ซอฟต์แวร์ที่ทำงานได้, UI ที่สวยงาม, ฟิสิกส์ที่ถูกต้อง
นั่นคือต้นทุนที่เพิ่มขึ้น 22 เท่า
สำหรับผลิตภัณฑ์ที่ใช้งานได้ เทียบกับเดโมที่ดูดีเฉพาะในภาพหน้าจอ
ว่ามันแพงหรือถูกนั้นขึ้นอยู่กับว่าการปล่อยเวอร์ชันที่พังนั้นมีต้นทุนเท่าไหร่สำหรับทีมของคุณ
แต่นี่คือสิ่งที่ไม่มีใครพูดถึง:
การผสมผสานระหว่าง harness + model นั้นพัฒนาไป
Harness มูลค่า $200 กลายเป็น $124 ด้วยการอัปเกรด model เพียงครั้งเดียว
แนวโน้ม:
→ Model ที่ดีกว่า = Harness ที่เรียบง่ายกว่า = การรันที่ถูกกว่า = ผลลัพธ์ที่เร็วกว่า
วิศวกรที่ชนะในปี 2026 ไม่ได้เขียนโค้ดที่ดีที่สุด
พวกเขากำลังออกแบบข้อจำกัดที่ดีที่สุด
และจากนั้นก็เต็มใจที่จะทิ้งข้อจำกัดเหล่านั้นทันทีที่มันหยุดสร้างคุณค่า
บทสรุป
ทุกสิ่งที่คุณเพิ่งเรียนรู้:
Harness คืออะไร:
→ 1. Agent = Model + Harness
→ 2. Model = CPU Harness = ระบบปฏิบัติการ
→ 3. Model เดียวกัน, Harness ที่ดีกว่า = ประสิทธิภาพเพิ่มขึ้น +13%
5 สิ่งประดิษฐ์ของ Harness:
→ 4. CLAUDE.md / AGENT.md — เอกสารปฐมนิเทศสำหรับ agents
→ 5. รายการคุณสมบัติ JSON — ตัวติดตามความคืบหน้า + ชุดทดสอบในที่เดียว
→ 6. กิจวัตรการเริ่มต้นเซสชัน — ลำดับการบูต 7 ขั้นตอนเดิมทุกครั้ง
→ 7. สัญญา Sprint — agents เจรจาก่อนเขียนโค้ด
→ 8. เทมเพลตงานที่มีโครงสร้าง — เส้นทางไฟล์จริง, รูปแบบจริง
สามค่าย:
→ 9. OpenAI: ออกแบบสภาพแวดล้อม, ปล่อย agent
→ 10. Anthropic: แยกผู้ทำออกจากผู้ตัดสิน
→ 11. ThoughtWorks: กรอบแนวคิด feedforward/feedback 2×2
5 หลักการสากล:
→ 12. บริบทดีกว่าคำสั่ง
→ 13. การวางแผนและการดำเนินการต้องแยกจากกัน
→ 14. วงจรป้อนกลับเป็นสิ่งที่ขาดไม่ได้
→ 15. ทีละอย่าง
→ 16. Codebase คือเอกสารประกอบ
ข้อขัดแย้ง:
→ 17. การเสื่อมของ Harness — สิ่งที่ใช้ได้ผลเมื่อเดือนที่แล้วกลับเป็นอุปสรรคในเดือนนี้
→ 18. สร้างเพื่อลบ — ทดสอบและลบส่วนประกอบที่ตายแล้ว
→ 19. ความเป็นจริงด้านต้นทุน — Model ที่ดีกว่า = Harness ที่เรียบง่ายกว่า = การรันที่ถูกกว่า
วิศวกรที่ชนะในปี 2026 ไม่ได้เขียนโค้ดที่ดีที่สุด
พวกเขากำลังออกแบบข้อจำกัดที่ดีที่สุด
และเต็มใจที่จะทิ้งข้อจำกัดเหล่านั้นทันทีที่มันหยุดสร้างคุณค่า
ถ้าสิ่งนี้มีประโยชน์:
→ แชร์ต่อเพื่อเข้าถึงผู้สร้างในเครือข่ายของคุณ
→ ติดตาม @sairahul1 สำหรับเนื้อหาแบบนี้ทุกสัปดาห์
→ บุ๊กมาร์กไว้ — คุณจะกลับมาอ้างอิงเมื่อ agents ของคุณเริ่มทำงานผิดปกติ
ฉันเขียนเกี่ยวกับ AI, การสร้างผลิตภัณฑ์, และสิ่งที่ใช้ได้ผลจริงในปี 2026
