วิธีใช้ Jev ใน Agent จริง 10 ขั้น พร้อมตัวเลขที่ตรวจสอบได้

โดย Nokka (นก-กา) | 19 กันยายน 2026

บทความนี้เขียนโดย AI (โมเดล deepseek-v4.1-flash ของผู้ให้บริการ ollama-cloud) ผ่าน Hermes Agent จาก Nous Research ตรวจสอบและเรียบเรียงโดย Nokka ข้อความในเครื่องหมายคำพูดที่เป็นคำแปลเป็นคำแปลของผม ไม่ใช่สำเนาต้นฉบับ

มีคำถามหนึ่งที่คนสร้าง agent ทุกคนเจอเหมือนกัน คือเมื่อ agent ต้องเลือกทางเดินต่อไป มันควรถาม LLM ทุกครั้งหรือเปล่า [1]

LLM เขียนข้อความได้ทุกอย่าง ซึ่งเป็นข้อดีในงานสร้างสรรค์ แต่กลายเป็นข้อเสียเมื่อสิ่งที่โค้ดต้องการจริง ๆ คือ "เลือกทางใดทางหนึ่งจากสี่ทาง" [1][2]

Jev จาก TypeSafe AI คือโมเดลที่ออกแบบมาเพื่อคำถามแบบนั้นโดยเฉพาะ ไม่เขียนข้อความ ไม่ตอบเป็นบทสนทนา แต่คืนค่าที่มี type กำหนดไว้ พร้อมความน่าจะเป็นของแต่ละทางเลือก [1]

บทความนี้ไม่ใช่ข่าวเปิดตัว แต่เป็นคู่มือว่า ถ้าจะเอา Jev ไปวางในระบบ agent จริง ต้องคิดอะไรบ้าง และตัวเลขที่โพสต์กันในวงการมีตัวไหนยืนยันได้จริง

ภาพที่ 1: สี่ชั้นที่ควรแยกหน้าที่ออกจากกันในระบบ agent

หลักคิดเดียวที่ต้องเข้าใจก่อน

ทุกอย่างในบทความนี้มาจากประโยคเดียว แยกการตัดสินใจออกจากการลงมือทำ [3]

ชั้น	ใครทำ	หน้าที่
ตัดสินใจ	Jev	เลือกทาง ให้คะแนน ตอบใช่/ไม่ใช่
คิดและสร้าง	LLM	เขียนข้อความ สร้างโค้ด วิเคราะห์
ลงมือ	agent, tool, โค้ด	เรียก API กดปุ่ม เขียนไฟล์
ยืนยัน	โค้ด + state ใหม่	ตรวจว่าผลลัพธ์ที่ได้ตรงกับที่ตัดสินใจ

⇒ ประโยชน์ของโครงนี้คือ Jev ไม่ถือ policy และไม่ทำ side effect ใด ๆ โค้ดเป็นเจ้าของกฎทั้งหมด [3]

ถ้าลำดับความสำคัญเปลี่ยน แก้ตัวเลขในโค้ด ไม่ต้องรื้อ prompt [1]

ขั้นที่ 1 รู้ว่า Jev ถนัดงานแบบไหน

งานที่ Jev ให้ผลตอบแทนสูงสุดคืองานที่ ตัดสินใจบ่อย ซ้ำ ๆ และรู้คำตอบที่เป็นไปได้ล่วงหน้า [3]

ตัวอย่างในเอกสารทางการคือ การประเมินว่าข้อมูลชิ้นไหนน่าเชื่อถือ การเลือกว่าควรกดอะไรต่อใน browser และการตัดสินว่าควรส่งงานให้คนตรวจหรือไม่ [3]

ถ้างานนั้นต้องคิดยาว ๆ หลายชั้น หรือต้องเขียนข้อความออกมา Jev ไม่ใช่เครื่องมือที่ถูก [4]

ขั้นที่ 2 แปลงทางแยกให้เป็นสาม primitive

TypeSafe มีคำถามสามแบบที่ใช้ร่วมกันในคำขอเดียวได้ [1][5]

Primitive	ถามว่าอะไร	ได้อะไรกลับมา
Choice	เลือกหนึ่งตัวจากรายการ	ตัวที่เลือก ความน่าจะเป็นทุกตัว และ confidence
Score	ให้คะแนนบนเกณฑ์ที่กำหนด	คะแนน การกระจาย และ confidence
Noul	ข้อความนี้จริงหรือไม่	ค่าความน่าจะเป็นว่าใช่ ระหว่าง 0 ถึง 1

⇒ จุดที่ต่างจาก structured output ของ LLM คือ ทุกคำถามถูกประเมินแยกจากกัน คำตอบของข้อหนึ่งไม่ขึ้นกับว่าคำขอเดียวกันมีคำถามอะไรอีก [5]

และคำถามทั้งหมดประเมินพร้อมกันในคำขอเดียว เพิ่มคำถามแล้วเวลาตอบแทบไม่เพิ่ม [1][5]

ขั้นที่ 3 ตั้ง state ให้เป็นข้อมูลที่ตัดสินใจได้

state คือก้อนข้อมูลที่ Jev ใช้ตอบทุกคำถาม เอกสารทางการแนะนำให้ state เน้น program state ไม่ใช่บทสนทนายาว [1]

สิ่งที่ควรอยู่ใน state คือ เป้าหมาย กติกา ข้อมูลบริบท และรายการสิ่งที่ทำไปแล้ว [3]

ข้อควรระวังคือ state เดียวกันนี้ถูกใช้ตอบทุกคำถาม ถ้าใส่ข้อมูลไม่ครบ คำถามทุกข้อจะได้คำตอบที่อ่อนลงพร้อมกัน

ขั้นที่ 4 ถามให้ atomic แล้วรวมด้วยโค้ด

นี่คือหลักที่ผมคิดว่าสำคัญที่สุด และเอกสารทางการเขียนไว้ชัดว่า อย่าถามคำถามที่ต้องใช้การคิดหลายชั้น [1]

⇒ ถ้าจะถามว่า "จัดอันดับข้อเสนอนี้" ให้แยกเป็น ตลาดใหญ่แค่ไหน เทคนิคทำได้จริงไหม และต่างจากเจ้าอื่นตรงไหน แล้วเอาโค้ดรวมคะแนนด้วยสูตรของเราเอง [1]

ข้อดีคือเวลา priorities เปลี่ยน แก้ค่าถ่วงน้ำหนักในโค้ด ไม่ต้องเขียน prompt ใหม่ [1]

TypeSafe เรียกวิธีนี้ว่า composite scoring และมีเอกสารแยกให้อ่าน [1]

ขั้นที่ 5 ยิงเป็นชุด อย่ายิงทีละคำถาม

นี่คือจุดที่ตัวเลขชัดที่สุด และเป็นตัวเลขที่ผมยืนยันจากเอกสารทางการเอง [6]

TypeSafe เปิด cookbook ที่ทดลองกับบทความ Wikipedia เรื่อง GDPR ความยาวประมาณ 53,777 ตัวอักษร แล้วถาม 13 คำถาม (Noul 8 · Choice 2 · Score 3) สองวิธี คือยิงรวมคำขอเดียว กับยิง 13 ครั้ง คำถามละครั้ง [6]

ผลที่ได้คือ

• ยิงรวมถูกกว่า 12.2 เท่า
• ยิงรวมเร็วกว่า 10.0 เท่า
• คำตอบเหมือนกันทั้งสองวิธี

เหตุผลไม่ใช่ความลึกลับ เพราะเอกสารชิ้นเดียวกันถูกส่งซ้ำ 13 รอบในวิธียิงทีละคำถาม วิธียิงรวมส่งครั้งเดียว [6]

และนี่คือตัวเลขที่โพสต์ในวงการอ้างถึง ผมตรวจต้นทางแล้วว่ามาจาก cookbook นี้จริง [6][7]

ภาพที่ 2: ตัวเลขจากการยิงคำถามเป็นชุด

ขั้นที่ 6 ใช้ confidence เป็นสวิตช์ ไม่ใช่ค่าตกแต่ง

ทุกคำตอบแบบ Choice และ Score มีค่า confidence ระหว่าง 0 ถึง 1 ติดมาด้วย [8]

เอกสารอธิบายว่า confidence คำนวณจากการกระจายความน่าจะเป็น ถ้ากระจุกอยู่ที่ตัวเดียวแปลว่ามั่นใจ ถ้ากระจายกว้างแปลว่าไม่มั่นใจ [8]

และ TypeSafe บอกตรง ๆ ว่าไม่ล็อกให้ใช้สูตรของเขา ส่ง probabilities มาให้ครบเพื่อให้เราเลือกคำนวณเองได้ [8]

⇒ วิธีใช้ที่ตรงไปตรงมาคือ ตั้ง threshold แล้วให้ระบบทำงานอัตโนมัติเฉพาะเคสที่มั่นใจพอ เคสที่ไม่ถึงก็ส่งต่อให้ LLM ตัวใหญ่ หรือส่งให้คนตรวจ [7]

ขั้นที่ 7 วาง Jev ตรงทุกทางแยกที่ไม่ต้องคิดยาว

ตำแหน่งที่ควรวางตามที่ผู้ใช้จริงรายงานและเอกสารแนะนำ คือ เลือก agent ตัวไหนทำงานต่อ เลือกโมเดล เลือก tool เลือกการกระทำบน browser และเลือกว่าจะส่งให้คน [7][9]

หัวใจคือ Jev ตัดสินใจจาก state ปัจจุบัน แล้วโค้ดอ่านผลไปทำ พอทำเสร็จ state เปลี่ยน แล้ววนกลับไปถามใหม่ [3]

ขั้นที่ 8 กรณีศึกษาจากของจริง 5 เคส

ส่วนนี้คือกรณีศึกษาที่ผมตั้งใจตรวจทีละตัว เพราะตัวเลขในวงการนี้ถูกพูดซ้ำบ่อยจนแยกไม่ออกว่าอันไหนยืนยันได้

เคส	ตัวเลข	สถานะการยืนยัน
Browser Use หาเที่ยวบิน	7 วินาที ราคา $0.0039	โพสต์ของผู้พัฒนาเอง มีวิดีโอ 1x speed [9]
Every ตรวจงานเขียน	37 เอกสาร 21 การตรวจ ได้ 777 คำตัดสิน ในเวลาไม่ถึง 0.7 วินาที ราคาราว 25 เซนต์ส่วน 4	บทความของ Every [10]
Mobile Jev บน Android	9 การกระทำในเวลาประมาณ 21 วินาที	README ของโปรเจกต์ ระบุชัดว่ายังไม่ได้สาธิตการจองสำเร็จ [11]
Re-ranking เอกสารกฎหมาย	top-10 จาก 38% เป็น 62% และ top-1 จาก 5% เป็น 18%	cookbook ทางการ บนชุดข้อมูล CLERC [12]
เทียบกับ Qwen บน Cerebras	Jev ถูกกว่ามากและเร็วกว่า แต่คุณภาพใกล้กัน	ผู้ทดสอบอิสระ มี source เปิด [13]

ตัวเลขของ Every มาจากการทดลองที่ทีมงานเขียนของ Every รันเอง แล้วรายงานผลในบทความของสำนักข่าวนั้น [10]

ตัวเลขของ Mobile Jev มาจาก README ของโปรเจกต์ ซึ่งเขียนกำกับไว้ตรง ๆ ว่ายังไม่ได้สาธิตการจองที่สำเร็จจริง [11]

และตัวเลข re-ranking มาจาก cookbook ทางการที่รันบนชุดข้อมูล CLERC เป็นผลของ TypeSafe เอง ไม่ใช่ผลของห้องแล็บอิสระ [12]

ทั้งห้าเคสเป็น การทดลองของผู้ใช้งานเองหรือของบริษัท ไม่ใช่การทดสอบโดยองค์กรอิสระ ตัวเลขใช้ได้ในฐานะสัญญาณ ไม่ใช่ข้อพิสูจน์ [7][13]

มีอีกเคสที่ผมตัดออก คือตัวเลขลดการโหลด skill ผิดจาก 16.8% เหลือ 7.3% ซึ่งอยู่ในโพสต์สรุปของผู้ใช้รายหนึ่ง แต่ไม่มีวิธีทดสอบเปิดเผย ใส่ไว้ตรงนี้เพื่อบอกว่า ผมเจอตัวเลขนี้และเลือกไม่ใช้ [7]

ขั้นที่ 9 อย่าใช้ Jev กับงานสามประเภท

เอกสารทางการไม่ได้เขียนเป็นข้อห้าม แต่ข้อจำกัดของตัวโมเดลบ่งชี้ชัด [4][5]

หนึ่ง งานคำนวณ เพราะ Jev ไม่ได้ทำเลข และโค้ดทำได้แม่นกว่า

สอง งานเขียน เพราะ Jev ไม่สร้างข้อความเลย LLM ยังเป็นเครื่องมือที่ถูกสำหรับงานนี้ [4]

สาม งานที่ย้อนกลับไม่ได้ การลบข้อมูล การจ่ายเงิน การส่งข้อความออกนอกองค์กร ให้ Jev ตัดสินว่า "ควรทำไหม" แต่ให้โค้ดตัดสินว่า "ทำได้จริงไหม"

⇒ หลักที่ใช้ได้คือ โค้ดคำนวณ LLM สร้าง Jev ตัดสิน และ state ใหม่เป็นตัวยืนยันผล [3]

ภาพที่ 3: สี่เรื่องที่โพสต์โฆษณาส่วนใหญ่ข้าม

ขั้นที่ 10 รู้ว่าอะไรยังพิสูจน์ไม่ได้

นี่คือขั้นที่ผมคิดว่าจำเป็นที่สุด และเป็นขั้นที่โพสต์โฆษณาส่วนใหญ่ข้าม

Jev ไม่เคยบอกว่าตัดสินใจถูก TypeSafe เขียนเองว่าไม่มีทางคืนค่าที่ผิด type ได้ เพราะขอบเขตถูกกำหนดล่วงหน้า แต่คอมเมนต์ใน Hacker News สรุปสั้นและตรงที่สุดว่า "การบอกว่ามัน hallucinate ไม่ได้นี้เกินไป มันยังส่งคำถามเรื่องบิลไปฝ่ายพัฒนาได้ผิด และยังตอบคำถามใช่/ไม่ใช่ที่ชัดเจนผิดได้" [4][14]

ราคาที่ยังพิสูจน์ไม่ได้ TypeSafe ยอมรับเองว่ายังพิสูจน์ไม่ได้ว่าราคา $0.042 ต่อล้านโทเคนยังไม่ได้อุดหนุน และต้องรอระยะยาว [4]

ยังไม่มี benchmark มาตรฐาน บริษัทประกาศเองว่าจะไม่ลงตาราง benchmark มาตรฐานในประกาศรุ่นโมเดล เพราะเชื่อว่า benchmark ถูกปรับจูนได้ และยกตัวอย่างว่า Artificial Analysis แก้ดัชนี Intelligence Index สองครั้งในสี่วัน [15]

แต่การเลือกแบบนี้มีราคา มีคอมเมนต์ใน Hacker News ที่อ่านแล้วเข้าใจความรู้สึกว่า "ผมเดิมพันเลยว่าถ้าคะแนน benchmark ของเขาดี เขาคงเผยแพร่" [14]

ความเร็วที่ทำได้อยู่แล้ว Sean Goedecke เขียนบทวิเคราะห์ว่า prefill คำตอบด้วย "choice": " แล้วให้ LLM สร้างแค่โทเคนเดียว โดยจำกัดตัวเลือก ก็ได้ความเร็วใกล้เคียง เขาระบุว่ามีคนทดสอบบน Qwen2.5 ได้ความเร็วเพิ่ม 2-3 เท่าในวันเดียวกัน [16]

⇒ ข้อโต้แย้งของเขาไม่ใช่ "Jev ไม่เร็ว" แต่คือความเร็วนั้นไม่ใช่ของใหม่ทั้งหมด [16]

สิ่งที่ผมเห็นจากคู่มือนี้

ถ้าอ่านทั้ง 10 ขั้นแล้วจะเห็นว่า Jev ไม่ได้แข่งกับ LLM ในเรื่องที่ LLM เก่ง มันเข้าไปอยู่ในช่องที่ก่อนหน้านี้ไม่มีเครื่องมือไหนทำได้ดี คือการตัดสินใจเล็ก ๆ ที่เกิดขึ้นบ่อยจนการเรียก LLM ทุกครั้งแพงเกินไป [1][3]

และผมคิดว่าประเด็นจริง ๆ ไม่ได้อยู่ที่ตัวเลข 193 เท่าหรือ 444 เท่า แต่อยู่ที่คำถามว่า การตัดสินใจควรเป็นชั้นที่แยกออกมาต่างหากในสถาปัตยกรรมหรือเปล่า [3]

คำตอบที่ TypeSafe เสนอคือใช่ และให้เครื่องมือมาสามชิ้นพร้อมหลักการออกแบบ แต่คำตอบนั้นยังต้องผ่านการใช้งานจริงอีกมาก ก่อนจะรู้ว่าเป็นมาตรฐานของปี 2028 จริงหรือไม่ [4][7][13]

---

ถ้าคุณมีไปป์ไลน์ที่เรียก LLM ซ้ำ ๆ เพื่อจัดเส้นทาง ให้คะแนน หรือกรองข้อมูล ลองหยิบงานเหล่านั้นมาดูสักสองสามอย่าง แล้วถามว่าคำตอบที่เป็นไปได้ของแต่ละงานมีกี่แบบ ถ้าตอบได้ไม่เกินสิบแบบ งานนั้นคือจุดที่ควรลองย้ายไปใช้ Jev [3][5]

ตัวเลข 12.2 เท่าและ 10.0 เท่าจากการยิงเป็นชุด เป็นตัวเลขที่คุณทดลองเองได้ในหนึ่งบ่าย เพราะ cookbook ของ TypeSafe เปิดโค้ดไว้ให้รัน [6]

แหล่งอ้างอิง

[1] TypeSafe AI — "Introduction", เอกสารทางการ, กันยายน 2026 — https://docs.typesafe.ai/introduction

[2] TypeSafe AI — "How to build with TypeSafe", เอกสารทางการ, กันยายน 2026 — https://docs.typesafe.ai/concepts/how-to-build-with-system-one

[3] TypeSafe AI — "Patterns" (Speculative fan-out, Confidence-gated routing, Composite scoring, Intent routing), กันยายน 2026 — https://docs.typesafe.ai/patterns

[4] TypeSafe AI — "Introducing System One Models and Jev" (Diogo Almeida), 14 กันยายน 2026 — https://typesafe.ai/blog/introducing-system-one-models-and-jev

[5] TypeSafe AI — "Primitives (Questions)", เอกสารทางการ, กันยายน 2026 — https://docs.typesafe.ai/primitives

[6] TypeSafe AI — cookbook "Parallel questions", กันยายน 2026 — https://docs.typesafe.ai/cookbooks/parallel_questions

[7] codila (@0xCodila) — โพสต์บน X "Jev is a Internet moment for AI", 18 กันยายน 2026 — https://x.com/0xCodila/status/2101064040332054741

[8] TypeSafe AI — "Confidence", เอกสารทางการ, กันยายน 2026 — https://docs.typesafe.ai/confidence

[9] Gregor Zunic (@gregpr07) — โพสต์บน X เรื่อง Browser Use + Jev, 17 กันยายน 2026 — https://x.com/gregpr07/status/2100411066966749359

[10] Every — "Mini-Vibe Check: TypeSafe's Jev Judged Everything I've Written in 0.7 Seconds", กันยายน 2026 — https://every.to/also-true-for-humans/mini-vibe-check-typesafe-s-jev-judged-everything-i-ve-written-in-0-7-seconds

[11] Droidrun — "Mobile Jev" README, กันยายน 2026 — https://github.com/droidrun/mobile-jev

[12] TypeSafe AI — cookbook "Re-ranking", กันยายน 2026 — https://docs.typesafe.ai/cookbooks/rerank_typesafe

[13] Shannon (@iamMrDuncan) — โพสต์บน X เปรียบเทียบ Jev กับ Qwen บน Cerebras, 17 กันยายน 2026 — https://github.com/iammrduncan/typesafe-ai-benchmark

[14] Hacker News — "Introducing System One Models and Jev" (thread 49717558), 15-17 กันยายน 2026 — https://news.ycombinator.com/item?id=49717558

[15] TypeSafe AI — "Lies, Damned Lies, and Benchmarks", กันยายน 2026 — https://typesafe.ai/blog/antibenchmaxxing

[16] Sean Goedecke — "Jev means structured output is interesting again", กันยายน 2026 — https://www.seangoedecke.com/jev-means-structured-output-is-interesting-again/