ซอฟต์แวร์หลังยุค AI: การเปิดฉากของยุค Harness

• จุดจบของยุคซอฟต์แวร์คือ จุดเริ่มต้นของยุคฮาร์เนส (harness) และ SaaS ที่ขับเคลื่อนด้วยเวิร์กโฟลว์แบบตายตัวและฐานข้อมูลแบบจัดการกำลังถูกแทนที่ด้วย AI ที่มีสติปัญญา
• AI มีพลังมาก แต่ยังไม่ถูกฝึกให้เชื่องเหมือนม้าป่า และเพื่อใช้พลังนั้นให้เกิดประโยชน์ จำเป็นต้องมี การควบคุมอย่างเป็นระบบ (domestication)
• ฮาร์เนสของ AI agent ถูกนิยามด้วย องค์ประกอบหลัก 7 ส่วน ที่ล้อมรอบ LLM ซึ่งเป็นศูนย์กลาง โดยแต่ละส่วนเป็นตัวกำหนดความน่าเชื่อถือและประสิทธิภาพระดับโปรดักชัน
• ในยุคที่ทุกบริษัทเข้าถึงโมเดลเดียวกันได้ ผู้ชนะจะไม่ใช่คนที่มีตัวโมเดล แต่เป็น ฝ่ายที่ออกแบบและใช้งานฮาร์เนสได้ดีกว่า (best rider)
• ตลาดย่อยที่แยกจากกันนับพันแห่ง ซึ่งแล็บใหญ่ไม่ได้ให้ความสำคัญเป็นลำดับแรก ยังคงเป็นโอกาสสำหรับสตาร์ตอัป

---

ความหมายของยุคฮาร์เนส

• AI กำลัง แทนที่ SaaS ที่อิงกับเวิร์กโฟลว์แบบตายตัวและฐานข้อมูลแบบจัดการด้วย สติปัญญา (intelligence) และกำลังกำหนดกระบวนทัศน์ซอฟต์แวร์ขึ้นใหม่
• มีการเปรียบ AI เป็นมัสแตง ซึ่งทรงพลังแต่ยังดิบและไม่สามารถนำไปใช้ได้ตรง ๆ ดังนั้น การฝึกให้เชื่องจึงคือฮาร์เนส
• แก่นของการฝึกให้เชื่องคือสถาปัตยกรรมที่วาง LLM ไว้ตรงกลาง และจัดวางองค์ประกอบ 7 ส่วนรอบ ๆ แบบรัศมี

7 องค์ประกอบของฮาร์เนสสำหรับ AI agent

• 1. Context & Memory (บริบทและหน่วยความจำ)

  • โมเดลทั่วไปจำเป็นต้องมี ระบบค้นคืนข้อมูลที่ปรับแต่งตามการใช้งาน (bespoke retrieval) โดยระบบค้นหาบริบทสำหรับรังสีแพทย์ย่อมไม่เหมือนกับระบบสำหรับผู้ช่วยงานกฎหมาย
  • ไม่ว่าจะเป็นหน่วยความจำระยะสั้น ("agent กำลังทำอะไรอยู่เมื่อ 45 วินาทีก่อน"), การค้นหารูปภาพขนาดใหญ่ (รังสีวิทยา·การสร้างภาพ), หรือการค้นหาคีย์เวิร์ดในเอกสารนับพันล้านฉบับ ระบบก็ต้องแตกต่างกันไปตามแต่ละกรณีใช้งาน
  • ถัดจากระบบค้นคืนข้อมูลจะมี ฐานข้อมูลบริบท (context database) ซึ่งทำหน้าที่เป็น "สมุดสูตร" ที่บันทึกว่าธุรกิจดำเนินงานจริงอย่างไร
    • ขั้นตอนปฏิบัติงานมาตรฐาน (SOP) ที่ผู้คนพกติดอยู่ในหัวเมื่อมาทำงาน ก็คือสูตรเหล่านั้น
    • การเก็บรวบรวมในช่วงแรกและการพัฒนาไปตามการเปลี่ยนแปลงของคนและกระบวนการ คือแก่นสำคัญของ context DB

• 2. Tools & Action (เครื่องมือและการลงมือทำ)

  • เครื่องมือคือวิธีที่ agent ใช้เพื่อส่งผลต่อโลกภายนอก และหากสูตรใน context DB คือ "ต้องทำอะไร" เครื่องมือก็คือ วัตถุดิบและอุปกรณ์ที่ใช้ลงมือทำสิ่งนั้นจริง
  • ฮาร์เนสสมัยใหม่เปิดเผยเครื่องมือผ่าน registry พร้อมตรวจสอบอาร์กิวเมนต์ที่โมเดลส่งมา, dispatch การเรียกใช้, ให้การทำงานที่อ่อนไหวผ่าน approval gate และ parse ผลลัพธ์กลับเข้าสู่ลูปของ agent
  • MCP กำลังก้าวขึ้นมาเป็น connective tissue สำหรับการเชื่อมต่อเครื่องมือ
  • คุณภาพของฮาร์เนสถูกกำหนดโดยจำนวนเครื่องมือที่สามารถเปิดให้ใช้งานได้อย่างปลอดภัย และความสามารถในการจัดการความล้มเหลวได้อย่างเรียบร้อย

• 3. Orchestration & Loop (ออร์เคสเตรชันและลูป)

  • ลูปของ agent มีโครงสร้างเป็น คิด (think) → ลงมือทำ (act) → สังเกต (observe) → ทำซ้ำ (repeat)
  • การวางแผน การแตกงาน การใช้ sub-agent การ retry และเงื่อนไขการหยุด เป็นสิ่งที่กำหนดวิธีการทำงาน
  • ระบบควรดีขึ้นเมื่อใช้งานไปเรื่อย ๆ และ รูปแบบ closed loop ที่เรียนรู้จากการรันแต่ละครั้งคือจุดสร้างความแตกต่างระหว่างผู้ให้บริการ

• 4. State & Persistence (สถานะและการคงอยู่ของข้อมูล)

  • ในองค์กรขนาดใหญ่ที่มีผู้ใช้จำนวนมากใช้ระบบพร้อมกัน ความสามารถในการ ยืดหยุ่นและกู้คืนได้ (resilient) เป็นสิ่งจำเป็น
  • หากฮาร์เนสล่มในขั้นตอนที่ 7 จากงาน 10 ขั้นตอน ก็ควร กลับมาทำต่อจากขั้นตอนที่ 8 แทนที่จะเริ่มใหม่ทั้งหมด
  • file system, checkpoint, session thread และ artifact store คือกลไกที่ช่วยป้องกันการสูญหายของงาน

• 5. Sandbox & Compute (แซนด์บ็อกซ์และคอมพิวต์)

  • agent แต่ละตัวต้องมี พื้นที่ทำงานแยกอิสระ (sandbox)
  • Unix workspace แบบแยกส่วน, การควบคุม network egress, และ credentials ที่เก็บไว้นอกตัวโมเดล คือสิ่งที่รับประกันความปลอดภัย ความลับ และความเร็วในระดับสเกลใหญ่

• 6. Observability & Governance (การสังเกตการณ์และการกำกับดูแล)

  • "สิ่งที่มองไม่เห็น ย่อมเชื่อถือไม่ได้" — การติดตามทุกขั้นตอน การบันทึกทุกการเรียกใช้เครื่องมือ การรัน evals ในฐานะ regression test และ human-in-the-loop สำหรับการตัดสินใจความเสี่ยงสูง คือสิ่งที่เปลี่ยนเดโมให้กลายเป็นระบบโปรดักชัน
  • Guardrails ใช้บังคับใช้นโยบาย และ Evals ช่วยจับ regression ได้ก่อนลูกค้า

• 7. Cost & Workflow Optimization (ต้นทุนและการเพิ่มประสิทธิภาพเวิร์กโฟลว์)

  • องค์ประกอบที่เจ็ดคือ วิจารณญาณเชิงสถาปัตยกรรม (architectural judgment)
  • ต้องแยกให้ออกว่าส่วนใดควรทำแบบ deterministic หรือ non-deterministic, เลือกโมเดลที่เหมาะกับแต่ละขั้นตอน (ล้ำสมัย·ขนาดกลาง·ขนาดเล็ก·fine-tuning) และตัดสินใจว่าควรวางความรู้ไว้ใน skill หรือใน memory

สมรภูมิการแข่งขันแบบใหม่

• ผลลัพธ์คือพลวัตการแข่งขันรูปแบบใหม่ของซอฟต์แวร์ ซึ่งไม่ได้ใช้เหมือนกันในทุกหมวดหมู่
• ตลาดที่แล็บใหญ่ (สถาบันวิจัย AI รายใหญ่) ให้ความสำคัญก่อน จะได้ประโยชน์จาก ความเร็วในการลงมือทำและการควบคุมโมเดลโดยตรง
• แต่ขณะเดียวกัน ตลาดแยกย่อยอีกนับพันแห่ง ก็ยังเปิดกว้างสำหรับสตาร์ตอัป
• ในยุคที่ทุกบริษัทสามารถใช้โมเดลเดียวกันได้ "ผู้ที่ขี่ได้เก่งที่สุด (best riders)" จะเป็นฝ่ายชนะ — กล่าวคือ ความสามารถในการออกแบบและปฏิบัติการฮาร์เนสคือขีดความสามารถทางการแข่งขันที่สำคัญ

[junghan0611]

ผมชอบใช้ pi เป็นเครื่องมือเอเจนต์เพราะมันเบามาก เพิ่มเติมคือกำลังเชื่อมต่อ Claude Code กับ Gemini ด้วย เลยทำ pi-shell-acp ขึ้นมาแล้วใช้งานได้ดีอยู่ ผมสร้างสกิลไว้ใช้หลายตัว ยิ่งลองใช้ก็ยิ่งรู้สึกว่าการปรับให้เข้ากับสไตล์ตัวเองนี่ดีจริง ๆ เวลาใช้ Claude Code หรือ Codex ตรง ๆ ก็จะใช้โหมด YOLO แล้วปิดเครื่องมือบิลต์อินแทบทั้งหมดให้เหลือระดับเดียวกับ pi ฟีเจอร์ใหม่ ๆ ก็ปิดทันทีเหมือนตอกค้อนปุ๊กปิ๊กลงไปเลย

[runai]

ผมได้ลบการตั้งค่า harness ที่เคยมีอยู่ทั้งหมดออกไปแล้ว
harness ยิ่งทำงานเป็นปัจจัยที่จำกัดประสิทธิภาพของโมเดลมากขึ้น เมื่อโมเดลพัฒนาไปมากขึ้นเรื่อย ๆ
การตั้งค่า harness แบบครึ่ง ๆ กลาง ๆ กลับยิ่งสร้างผลลัพธ์ที่แย่ลงเสียอีก
การตั้งค่า harness ที่เคยมีความหมายในเวอร์ชัน 4.7 หรือต่ำกว่านั้น ใน 4.8 ก็ไม่มีความหมายอีกต่อไปแล้ว
และใน GPT 5.5 ก็มีแต่จะเกะกะเท่านั้น

[hanje3765]

องค์ประกอบของ harness ที่กล่าวถึงในบทความ ไม่ใช่สิ่งที่จะถูกแก้ไขได้เพียงแค่ความฉลาดของ LLM สูงขึ้น

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

[runai]

แทนที่จะเป็นปัญหาเรื่องสติปัญญาอย่างเดียว โมเดลต่างๆ ก็กำลังพัฒนาความสามารถในการใช้งานอย่างการ orchestration หรือการใช้เครื่องมือควบคู่ไปด้วย โดยไม่ขึ้นกับความฉลาดของมันเอง ตอนนี้ฝั่ง orchestration ซึ่งเดิมก็เป็นหนึ่งในแกนหลักของ Harness นั้น ถูกทำให้รองรับได้แล้วเช่นกัน ถ้าอย่างนั้น ณ เวลานี้ หากมีทั้ง orchestration แบบประกอบเองกับ orchestration แบบสำเร็จรูป เราควรเลือกใช้อะไรถึงจะเหมาะ?

[kaydash]

เห็นด้วยครับ/ค่ะ เราต้องพัฒนาตอบสนองไปด้วยกัน

[emptybynature]

มีโพสต์เกี่ยวกับ Harnessing ที่ประกาศอย่างเป็นทางการบนเว็บไซต์ OpenAI โดยเล่าประสบการณ์และแบ่งปันเคล็ดลับว่า OpenAI ใช้ Harnessing ภายในองค์กรอย่างไร นั่นหมายความว่าแม้แต่ OpenAI เองก็ยังใช้ Harnessing กับโปรเจ็กต์ภายในของพวกเขา Harnessing เป็นสิ่งที่จำเป็นอย่างชัดเจน และส่งผลโดยตรงต่อคุณภาพของการทำระบบขั้นสุดท้าย เหนือสิ่งอื่นใด มันยังช่วยลดจำนวนโทเคนที่ต้องใช้ในการสร้างผลลัพธ์ที่มีคุณภาพเท่ากันได้ถึงครึ่งหนึ่ง คุณได้ทั้งประสิทธิภาพและราคาแบบครบ แล้วจะมีเหตุผลอะไรที่ไม่ใช้ล่ะ

[runai]

ใน Opus 4.8 มีการเพิ่ม ultracode effort เข้ามา และสิ่งนี้แก้ปัญหาสิ่งที่โหมด harness แบบทำมือของนักพัฒนาเคยทำได้ดีกว่าเดิม ดังนั้น ณ ตอนนี้ ผมคิดว่าควรลบส่วน orchestration ออกจากโหมด harness ที่คุณใช้อยู่จะดีกว่า

[gulbi135]

เห็นด้วยครับ/ค่ะ ผม/ฉันก็เอาพวก orchestration แบบทำมือสำหรับ 4.7 กับการบังคับวางแผนที่ยืดยาวออกไปแล้ว เพราะใน 4.8 มันกลับเป็นตัวถ่วง
แต่สำหรับ codebase ระดับหลายแสนบรรทัดที่บำรุงรักษามาหลายปี คุณค่าที่แท้จริงของ harness ไม่ได้อยู่ที่ orchestration แต่อยู่ที่ชั้นที่ ultracode ยังแทนไม่ได้ (knowledge graph, domain convention, validation invariant) ดังนั้นผม/ฉันเลยคงชั้น context นั้นไว้ แล้วทำให้ขนานกันด้วย workflow เฉพาะส่วนที่เป็นอิสระจริง ๆ
ในทางกลับกัน ถ้าเป็นโปรเจกต์ใหม่ ผม/ฉันก็มองว่าใช้ ultracode ตรง ๆ โดยไม่ต้องมี harness ก็น่าจะเหมาะกว่า สุดท้ายแล้วมันไม่ใช่เรื่อง "จะลบทิ้ง vs จะเก็บไว้" แต่เป็นประเด็นที่ขึ้นอยู่กับอายุของ codebase และระดับการ coupling มากกว่าครับ/ค่ะ

[runai]

ใช่ครับ เป็นความเห็นที่ถูกต้อง ส่วนที่ตัดเรื่อง orchestration ออกไปก็ยังคงมีคุณค่าอยู่