วิธีใช้งานโมเดล Frontend โอเพนซอร์สอันดับ 1: คู่มือ Kimi K3 Harness

Prompt, context, loop และ graph engineering แต่ละอย่างกลับกลายเป็นเพียงชิ้นส่วนหนึ่งของเครื่องจักรเดียวกัน Harness คือจุดที่พวกมันมาบรรจบกันเป็นหนึ่งเดียวในที่สุด

ทุกยุคของการพัฒนาด้วย AI ต่างก็มีชื่อเรียกตำแหน่งงานของตัวเอง Prompt engineering มาเป็นอันดับแรก ในยุคที่ศิลปะทั้งหมดคือการหาประโยคที่ถูกต้อง

จากนั้นตามด้วย Context engineering เมื่อชัดเจนว่าตัวประโยคไม่สำคัญเท่าทุกอย่างที่ถูกโหลดเข้ามาล้อมรอบมัน ฤดูร้อนนี้คือเรื่อง Loops และอีกไม่กี่สัปดาห์ต่อมาคือ Graphs

ชื่อที่กำลังแพร่หลายตอนนี้คือ Harness engineering และเป็นชื่อแรกที่อธิบายสิ่งอื่นๆ ทั้งหมดได้

Harness คือทุกอย่างที่อยู่รอบโมเดล: เครื่องมือที่มันสามารถเรียกใช้ ไฟล์ที่มันอ่านก่อนสิ่งอื่นไดเรกทอรีที่มันอาจเขียนลงไปได้ การตรวจสอบที่ผลลัพธ์ต้องผ่าน ตารางเวลาที่ปลุกมันขึ้นมา และกฎที่ยุติการทำงาน

แต่ละศาสตร์ก่อนหน้า harness กลับกลายเป็นเพียงองค์ประกอบเดียวของเฟรมเวิร์กนี้ ซึ่งถูกสร้างแยกกันและตั้งชื่อให้ตัวเอง

ฉันเริ่มให้ความสำคัญกับเรื่องนี้ด้วยเหตุผลเชิงปฏิบัติ โมเดลพื้นฐานมีการเปลี่ยนแปลงตลอดเวลา บางครั้งกระโดดขึ้นถึง 17 อันดับบนลีดเดอร์บอร์ดในการอัปเดตเพียงครั้งเดียว และ harness คือส่วนเดียวของระบบที่เป็นของคุณอย่างแท้จริง

1/ เจ็ดศาสตร์วิศวกรรม หนึ่งเครื่องจักร

ศาสตร์

คำถามที่ตอบ

ตำแหน่งใน Harness

Prompt engineering

ฉันกำลังถามอะไรกันแน่

SKILL.md, สเปคงานที่โหลดมาเป็นอันดับแรก

Context engineering

โมเดลเห็นอะไรบ้างในแต่ละขั้นตอน

ตัวรวมบริบท (Context assembler): ข้อจำกัด, schemas, หน้าเว็บที่ดึงมา

Tool engineering

มันเข้าถึงอะไรได้บ้าง และในรูปแบบไหน

นิยามเครื่องมือที่มี input และ output แบบมีชนิดข้อมูล (typed)

Loop engineering

อะไรเริ่มการทำงานและอะไรรั้งมันไว้

ตัวรัน (Runner): ตัวกระตุ้น, เงื่อนไขการหยุด, งบประมาณ

Graph engineering

มันจำอะไรได้บ้างและสิ่งต่างๆ เชื่อมโยงกันอย่างไร

ชั้นความจำ (Memory layer): โหนด, ขอบแบบมีชนิดข้อมูล, นามแฝง

Eval engineering

ผลลัพธ์จะถูกปฏิเสธได้อย่างไร

ตัวตรวจสอบ (Verifier), อยู่นอกเหนือการควบคุมของเอเจนต์

Harness engineering

อะไรยึดทุกอย่างข้างต้นเข้าด้วยกัน

เฟรมเวิร์ก, สิทธิ์การเข้าถึง และ hooks

อ่านตารางจากบนลงล่าง มันคือประวัติศาสตร์ อ่านจากล่างขึ้นบน มันคือสถาปัตยกรรม: harness engineering คือหน้าที่ในการตัดสินใจว่าอีกหกศาสตร์ที่เหลือจะอยู่ที่ไหน เพื่อไม่ให้มีอันใดไปซ่อนอยู่ใน prompt

ประเด็นสุดท้ายนี่แหละที่สำคัญที่สุด

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

2/ กายวิภาคของ Harness

นิสัยที่มีประโยชน์ที่สุดที่ฉันเรียนรู้คือ การเขียน harness ทั้งหมดลงในไฟล์ config เดียว เพื่อให้ไม่มีสิ่งสำคัญใดๆ ที่ยังคลุมเครือ:

1# harness.yaml
2model:        kimi-k3          # บรรทัดเดียว ทุกอย่างด้านล่างอยู่รอดได้แม้เปลี่ยนโมเดล
3tools:        [browser, fs, shell, search]
4permissions:
5  write:      [./10-returns, ./20-graph, ./40-runs]
6  ask_first:  [send, publish, pay, delete]
7context:
8  always:     [SKILL.md, CONSTRAINTS.md, SCHEMA.md]
9  per_agent:  return_schema
10runner:
11  trigger:    cron "0 2 * * *"   # ทำงานทุกคืน ขณะคุณหลับ
12  stop:       40 verified nodes OR 3 passes with nothing new
13  budget:     { agents: 300, minutes: 45, retries: 2 }
14memory:
15  graph:      ./20-graph
16  aliases:    ./aliases.csv
17verify:
18  - script:   checks/schema.py
19  - agent:    reviewer, fresh context
20hooks:
21  pre_tool:   hooks/pre_tool.sh
22  post_run:   append 40-runs/

สามบรรทัดในไฟล์นั้นทำหน้าที่ส่วนใหญ่

model: ถูกออกแบบให้เป็นบรรทัดเดียวโดยเจตนา ทุกอย่างอื่นถูกเขียนโดยไม่สนใจว่าบรรทัดนั้นจะระบุอะไร นี่คือหัวใจสำคัญของความสามารถในการพกพา (portability)

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

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

บนดิสก์, harness คือโฟลเดอร์เดียว และทุกศาสตร์ในตารางจะมีที่อยู่ของตัวเองภายในนั้น

3/ ทำไม Kimi K3 ถึงเป็นเครื่องยนต์ที่ฉันเลือกใส่

สิ่งที่ Harness ต้องการ

สิ่งที่ Kimi K3 มอบให้

ตัวรันที่สามารถกระจายงานได้กว้าง

Agent Swarm: เอเจนต์สูงสุด 300 ตัวแก้ปัญหาเดียวกันพร้อมกัน โดยไม่ต้องเขียนตัวประสานงาน (orchestrator) เอง

โค้ดที่แข็งแรงพอที่จะเขียนตัวตรวจสอบเอง

อันดับ 1 ใน Frontend Code Arena ด้วยคะแนน 1,679 นำหน้า Fable 5 (1,631) และ GPT-5.6 Sol (1,618), เป็นผู้นำใน 6 จาก 7 ด้าน

เครื่องยนต์ที่พัฒนาขึ้นภายใต้คุณ

จากอันดับ 18 ขึ้นเป็นอันดับ 1 ในการอัปเดตเดือนกรกฎาคมเพียงครั้งเดียว

แถวแรกมีความสำคัญมากกว่าที่เห็น เกือบทุก harness ที่ทำเองจะเติบโตจนต้องมีตัวประสานงานที่สร้างเองในสักวันหนึ่ง และมักจะเป็นไฟล์ที่เปราะบางที่สุดในโฟลเดอร์ ด้วย swarm การกระจายงานกลายเป็นแค่บรรทัดงบประมาณ agents: 300 และ harness แค่ต้องจัดการกับสิ่งที่ส่งกลับมา

แถวที่สองสำคัญเพราะ harness ส่วนใหญ่คือโค้ดที่โมเดลเขียนให้คุณ: สคริปต์ hook, การตรวจสอบ schema, แดชบอร์ดเล็กๆ ที่อ่านค่าจาก 40-runs เครื่องยนต์ที่เป็นผู้นำด้าน frontend arena จะทำให้สิ่งเหล่านี้ถูกต้องตั้งแต่ครั้งแรกบ่อยกว่ามาก

แถวที่สามคือเหตุผลสนับสนุนสำหรับ harness engineering ในข้อมูลจุดเดียว เมื่อโมเดลกระโดดขึ้น 17 อันดับในชั่วข้ามคืน harness จะนำการกระโดดนั้นมาใช้ประโยชน์ในวันเดียวกันทันที เพราะบรรทัดเดียวที่ต้องเปลี่ยนคือ model

4/ Hooks: ปฏิกิริยาตอบสนองอัตโนมัติ

Hook คือสคริปต์สั้นๆ ที่ harness รันในช่วงเวลาตายตัว ไม่ว่าโมเดลจะตัดสินใจทำอะไรก็ตาม Hooks คือจุดที่ harness เลิกเป็นแค่การจัดโครงสร้างโฟลเดอร์ และเริ่มทำงานเหมือนระบบความปลอดภัย

Hook

เมื่อไหร่ที่ทำงาน

ทำอะไร

pre_tool

ก่อนการเรียกใช้เครื่องมือใดๆ

บล็อกการเขียนนอกเหนือจากรายการสิทธิ์

post_tool

หลังจากได้รับผลลัพธ์ทุกครั้ง

รันการตรวจสอบ schema และปฏิเสธผลลัพธ์ที่มีรูปแบบผิดทันที

pre_send

ก่อนที่อะไรก็ตามจะออกจากเครื่อง

เก็บไว้ในคิวจนกว่าคุณจะอนุมัติ

on_fail

หลังจากผลลัพธ์ถูกปฏิเสธ

แนบเหตุผลของความล้มเหลวไปยังการลองใหม่

post_run

เมื่อเงื่อนไขการหยุดเกิดขึ้น

เพิ่มบันทึกการทำงานลงใน 40-runs และเปรียบเทียบความแตกต่างของกราฟ

Hook pre_tool จากแถวแรกพอดีในห้าบรรทัด:

1# hooks/pre_tool.sh
2case "$TARGET" in
3  ./10-returns/*|./20-graph/*|./40-runs/*) exit 0 ;;
4  *) echo "blocked: $TARGET is outside the write list"; exit 1 ;;
5esac

Hook on_fail เพียงอย่างเดียวเปลี่ยนเศรษฐศาสตร์ของ loop การลองใหม่ที่นำเหตุผลของความล้มเหลวจากการพยายามครั้งก่อนติดไปด้วย ถือเป็นการแก้ไข แต่ถ้าไม่มีเหตุผลนั้น loop ก็จ่ายค่าความผิดพลาดเดิมซ้ำอีกครั้ง

5/ คืนหนึ่งหน้าตาเป็นอย่างไร

เมื่อนำทุกชิ้นส่วนมารวมกัน harness จะทำงานเหมือนกะกลางคืนที่ปฏิบัติตามกฎ ณ เวลา 02:00 ตัวกระตุ้นจะทำงานและคำสั่งเริ่มต้นจะเลือกทุกโหนดที่ต้องการการแก้ไข Swarm จะกระจายงานออกมา เอเจนต์หนึ่งตัวต่อหนึ่งโหนด

ผลลัพธ์ที่ไม่ตรงตาม schema จะถูกปฏิเสธโดย post_tool ก่อนที่จะไปถึงกราฟ และแต่ละโหนดที่ถูกปฏิเสธจะลองใหม่อีกครั้งโดยมีเหตุผลความล้มเหลวแนบไปด้วย เมื่อเอเจนต์ตัวหนึ่งพยายามเขียนนอกโฟลเดอร์ของมัน pre_tool จะหยุดมันไว้โดยไม่ต้องปลุกใคร

โหนดที่รวมเสร็จแล้วและขอบแบบมีชนิดข้อมูลจะลงหลักปักฐานใน 20-graph อีเมลร่างฉบับหนึ่งจะมาถึง pre_send และรอคอย post_run จะเพิ่มบันทึก และ loop จะหยุดด้วยเงื่อนไขของมันเอง ภายในงบเวลา 45 นาทีที่กำหนดไว้ใน config

ตอน 07:30 คุณอ่านไฟล์เดียวและตัดสินใจสองเรื่อง นั่นคือต้นทุนทั้งหมดของเช้าวันนั้นสำหรับการรัน loop engineering และ graph engineering ด้วยวิธีนี้ และนั่นคือจุดประสงค์ทั้งหมดของ harness: ทุกอย่างที่รันได้โดยไม่มีคุณก็ได้รันไปแล้ว และสิ่งเล็กน้อยที่ต้องการคุณกำลังรออยู่ในที่เดียว

6/ การทดสอบเปลี่ยนโมเดล (Swap Test)

การตรวจสอบที่เร็วที่สุดสำหรับชุดเอเจนต์ใดๆ: เปลี่ยนบรรทัดโมเดลแล้วรันอีกครั้ง สิ่งใดก็ตามที่พังทลายลงมา คือ harness ที่อาศัยอยู่ในตำแหน่งที่ผิด

สิ่งที่พังหลังเปลี่ยนโมเดล

มันซ่อนอยู่ที่ไหน

มันควรอยู่ที่ไหน

รูปแบบผลลัพธ์เบี่ยงเบน

"always answer as JSON" ใน prompt

Return schema บวกกับสคริปต์ที่ปฏิเสธทุกอย่างที่ไม่ใช่

Run หยุดทำงานเองไม่ได้

"keep going until it's thorough"

เงื่อนไขการหยุดที่สร้างจากจำนวนนับ

คำแก้ไขจากสัปดาห์ก่อนหายไป

ประวัติแชท

CONSTRAINTS.md, โหลดทุกครั้งเมื่อรัน

บริษัทเดิมปรากฏขึ้นสามครั้ง

การใช้วิจารณญาณของโมเดล

aliases.csv, ตรวจสอบก่อนการรวม

มันเขียนลงในที่ที่ไม่ควร

ประโยคสุภาพใน prompt

รายการสิทธิ์และ hook pre_tool

ชุดค่าผสมที่ผ่านการทดสอบ Swap Test คือชุดค่าผสมที่พกพาได้ และความพกพาคือสิ่งที่ทำให้มันคุ้มค่าเงิน

ต้นทุนและผลตอบแทน

บริษัทต่างๆ ลงทุนทั้งไตรมาสไปกับแพลตฟอร์มเอเจนต์ภายในองค์กร Harness ที่ใช้งานได้จริงคือโฟลเดอร์เดียว ไฟล์ config เดียว และสคริปต์สั้นๆ ห้าตัว และมันรันได้ด้วยสมาชิกภาพ Kimi ช่องว่างนี้คือโอกาส

ช่องทาง

ผลตอบแทน

สิ่งที่คุณต้องมีก่อน

ติดตั้ง Harness สำหรับทีมเล็ก

ค่าธรรมเนียมครั้งเดียวระดับสี่หลักสำหรับ config, hooks และ verifier รอบๆ workflow ของพวกเขา

Harness ของคุณเองหนึ่งตัว ที่รันตามตารางเวลา

Retainer วันเปิดตัวโมเดล

ค่าธรรมเนียมรายเดือนเพื่อรัน Swap Test ทุกครั้งที่มีการปล่อยโมเดลรุ่นใหญ่ออกมา และย้ายทีมไปใช้โมเดลที่เป็นผู้นำ

ลูกค้าที่มีการรันซึ่งบันทึกไปยัง 40-runs อยู่แล้ว

เทมเพลต Harness เฉพาะทาง

โฟลเดอร์และ yaml ที่แพ็กเกจสำหรับอุตสาหกรรมเดียว: วิจัย, จัดหางาน, ปฏิบัติตามข้อกำหนด

Harness เดิมที่ได้รับการพิสูจน์แล้วในตลาดที่แตกต่างกันสองแห่ง

ช่องทางที่สองคือช่องทางที่ฉันจะสร้างเป็นอันดับแรก การปล่อยโมเดลรุ่นใหญ่ทุกครั้งจะสลับตำแหน่งบนลีดเดอร์บอร์ด K3 เพียงตัวเดียวกระโดดขึ้น 17 อันดับในการอัปเดตครั้งเดียว และทุกทีมที่มี harness ต้องการคนที่หน้าที่ของเขาคือการรัน Swap Test ในวันเปิดตัวโมเดล

สรุปสั้นๆ

Prompt, context, tool, loop, graph และ eval engineering ทั้งหมดกลับกลายเป็นองค์ประกอบของเครื่องจักรเดียวกัน และ harness engineering คือการตัดสินใจว่าแต่ละองค์ประกอบเหล่านั้นจะอยู่ที่ไหน

วางโมเดลไว้หลังบรรทัดเดียว วาง permissions ไว้หน้า tools และวาง verifier ไว้ภายนอกเอเจนต์ จากนั้นการกระโดดขึ้นของลีดเดอร์บอร์ดครั้งต่อไปก็จะกลายเป็นแค่การเปลี่ยน config แทนที่จะเป็นการรื้อสร้างใหม่

และหากคุณพบว่าบทความนี้มีประโยชน์:

• บุ๊กมาร์กบทความนี้ ลิงก์มีการเปลี่ยนแปลงและรีโปใหม่ๆ ผุดขึ้นมาทุกสัปดาห์ คุณจะต้องการสิ่งนี้เป็นแหล่งอ้างอิง
• สำหรับการเจาะลึกประจำสัปดาห์เกี่ยวกับสถาปัตยกรรม AI, การเทรดเชิงปริมาณ และเศรษฐกิจเอเจนต์ ติดตามฉันได้ที่: @polydao
• เข้าร่วม TG Channel: Buzzoni Notes - ที่นี่ฉันแชร์ prompts ดิบๆ, skills ที่ปรับแต่งเอง และ alpha ที่ยังเร็วเกินไปสำหรับ X