เข้ากันได้ก็เฉพาะเวลาแบบนี้แหละ
OpenAI ที่เอาคำว่า Open ไปใส่ไว้ในชื่อบริษัทแล้วยังทำตัวหน้าด้าน ๆ
หรือ Anthropic ที่เดินออกมาโดยบอกว่า OpenAI เปลี่ยนไปแล้ว
ไม่รู้ว่าทำแบบนี้เพราะเงิน หรือเพราะมองว่า AI เป็นการแย่งชิงอำนาจ แล้วรัฐบาลก็เข้ามาแทรกแซงจนบงการผู้บริหารได้ตามใจ

อี๋...

การขายการศึกษาคุ้มค่าที่สุด ไม่มีความรับผิดชอบ มีแค่การเรียกเก็บเงินเท่านั้น AI จะเข้ามาครองส่วนแบ่งก้อนใหญ่ของธุรกิจแบบนี้

เหมือนเคยเห็นเมื่อหลายปีก่อนนะ

พอเข้าไปดูเว็บไซต์ต้นฉบับแล้ว อธิบายด้วยรูปภาพ เลยเข้าใจได้ง่ายแบบเป็นธรรมชาติมากครับ

ถ้าเพิ่มกิจกรรมออฟไลน์อย่างการเดินเล่นหรือการอ่านหนังสือ ก็จะดีขึ้นครับ haha

ข้อ 3 (การแยกความรับผิดชอบระหว่างเอเจนต์) น่าจะเป็นส่วนที่ยากที่สุดครับ/ค่ะ ผม/ฉันเคยลองไล่ดู public benchmark traces อยู่บ้าง เลยขอแชร์แพตเทิร์นหนึ่งที่เห็นจากตรงนั้นครับ/ค่ะ

สิ่งที่เจอบ่อยที่สุดไม่ใช่ "การตัดสินใจผิด" แต่เป็นการที่งานเดียวกันถูกรันซ้ำสองครั้ง เช่น ส่งอีเมลซ้ำด้วยพารามิเตอร์เดิม หรือเขียนไฟล์เดิมซ้ำอีกครั้ง โดยเฉพาะในช่วง retry หลัง timeout จะเจอบ่อยมาก คือจริง ๆ แล้วแค่การเรียกครั้งแรกช้า แต่ถูกตัดสินว่า fail เลยถูกเรียกซ้ำ

สาเหตุที่ตามแกะเรื่องนี้ยากคือมันไม่เกิด error ครับ/ค่ะ ทั้งสองครั้งเป็น 200 หมด และ log ก็สะอาด เลยดูไม่ออกถ้าย้อนมาดูแค่ log ทีหลัง

วิธีที่เราใช้คือจับกลุ่มด้วย (tool, normalized arguments, output hash) แล้วนับเชิงกลไกว่า combination เดิมถูกทำซ้ำหรือไม่ เพราะเป็นการคำนวณล้วน ๆ โดยไม่ต้องพึ่งการตัดสินของ LLM เลยทำซ้ำให้ได้เหมือนเดิมครับ/ค่ะ แต่ข้อจำกัดก็ชัดเจน คือรู้ได้แค่ว่า "มีการเรียกสองครั้ง" แต่ยืนยันไม่ได้จาก trace อย่างเดียวว่า "มีการ execute สองครั้งจริงหรือไม่" เครื่องมือที่ตอบกลับมาพร้อม entity ID (เช่น document creation API) ยังเทียบ ID เพื่อตรวจสอบได้ แต่เครื่องมือแบบอีเมลที่คืนมาแค่ว่า "ส่งสำเร็จ" นี่เหมือนจะไม่มีวิธีตรวจสอบครับ/ค่ะ

ส่วนที่คุณพูดในข้อ 2 ว่า "เพื่อความเร็วก็เลยปล่อยผ่านไปเลย" ก็เห็นด้วยมากครับ/ค่ะ ฝั่งเราก็เคยพิจารณาจะบล็อกแบบ real-time เหมือนกัน แต่ก่อน execute จะยังไม่เห็นผลลัพธ์ เลยต้องตัดสินจาก arguments อย่างเดียว ซึ่งความแม่นยำต่ำมาก สุดท้ายมีกรณีที่ไปบล็อกแม้แต่ retry ที่ปกติด้วย เลยพับเรื่องนี้ไปครับ/ค่ะ

การแก้บั๊กเองก็มีต้นทุนถูกลงมาก และค่าใช้จ่ายในการอัปเดตซอฟต์แวร์ก็แทบจะเข้าใกล้ศูนย์ แถมถ้าไม่ใช่ระดับอุตสาหกรรมการเงิน หลายกรณีก็มักจะคิดว่าแค่แก้บั๊กทีหลังก็พอ...
แต่ถ้าแนวคิดแบบนี้สะสมไปเรื่อย ๆ สุดท้ายก็คงนำไปสู่อุบัติเหตุครั้งใหญ่ใช่ไหมล่ะครับ

ลองใช้งานแล้วถ้าเจอบทสนทนาที่ Jump Back ทำงานวนผิด ๆ หรือมีส่วนไหนที่รู้สึกว่า “อันนี้ไม่ค่อยสะดวก” ก็แสดงความคิดเห็นไว้ได้เลยครับ โครงสร้างบทสนทนาแต่ละไซต์ไม่เหมือนกัน กรณีใช้งานจริงจึงช่วยได้มากที่สุด ต่อไปผมกำลังดูเรื่องการรองรับ Perplexity และการส่งออกไปยัง Notion/Obsidian อยู่ แต่ถ้ามีอะไรที่เร่งด่วนกว่านั้นก็ว่าจะทำส่วนนั้นก่อนครับ haha

ขอบคุณครับ ลองใช้ดูนะครับ ถ้ามีบทสนทนาไหนที่ Jump Back จับไม่ได้ ก็บอกได้ตามสบายเลยครับ~
ผมเองก็ลองใช้อยู่เหมือนกัน แต่คิดว่าน่าจะดีถ้าได้ฟังปัญหาที่ผู้ใช้ท่านอื่น ๆ เจอด้วยครับ ฮ่า ๆ

ทุกครั้งที่เอเจนต์แก้ไข ถ้าคอยสังเกตบันทึก diff แล้วพบว่ามันก่อให้เกิดการผ่าตัดแบบลูกซองหรือการเปลี่ยนแปลงจำนวนมาก ก็น่าจะมองเป็นกลิ่นเหม็นทาง SE และอาจนำไปใช้กับการเสริมแรงเรียนรู้ได้เหมือนกันนะ...

[เผื่อว่าอ่านยาก ผมเลยเขียนคำแปลภาษาเกาหลีของ README ไว้ให้แล้ว!]
Clew
ตัวตรวจจับแบบกำหนดผลลัพธ์แน่นอนสำหรับค้นหางานที่สูญเปล่าใน agent trace

Clew จะอ่าน trace ของการรัน AI agent ที่เสร็จสมบูรณ์แล้ว แล้วค้นหาสต็ปที่ทำงานซ้ำกับที่ทำไปแล้ว — เรียกเครื่องมือเดิมซ้ำด้วยอาร์กิวเมนต์เดิม, ลองเรียกที่ล้มเหลวซ้ำด้วยอาร์กิวเมนต์เดิม, ดึงข้อมูลที่มีอยู่ในคอนเท็กซ์แล้วกลับมาอีกครั้ง — โดยทำงานได้โดยไม่ต้องมีการตัดสินจาก LLM ดังนั้นถ้าใส่ trace เดิมเข้าไป ก็จะได้ผลลัพธ์เดิมเสมอ

pip install "clew-custos[detect]"
python -m clew analyze ~/.claude/projects/<slug>/<uuid>.jsonl --out report.md

ตัวอย่างเอาต์พุตจริงจากการรันกับเซสชัน Claude Code แบบสาธารณะ:

Result: WASTE DETECTED

• wasted spans: 1
• category breakdown: 0 error_repeat, 0 side_effect, 1 idempotent, 0 unclassified

1. requery — Read on .../boot.ts

• turns: turn 50 → re-run at turn 58 (of 258 total)
• state: No modification of this file in between — re-read output is unchanged.
• re-consumed across 200 subsequent turns (≈439 tokens/turn → 87800 amplification tokens)
• estimated cost impact: $0.026340 ~ $0.263400 (cache-hit to cache-miss)

ทำไมเรื่องนี้จึงสำคัญ

ในเซสชัน AI coding agent ความสูญเปล่าจะโผล่มาให้เห็นแค่ในบิลเท่านั้น เครื่องมือทุกตัวคืนค่า 200 และไม่มีอะไรแจ้ง error เลย จึงมองไม่เห็นความสูญเปล่าด้วยตาเปล่า แต่ภายใน trace จะเห็นว่า agent อ่านไฟล์เดิมสองครั้ง, ลองเรียกที่ล้มเหลวซ้ำด้วยอาร์กิวเมนต์เดิม, และเรียกเครื่องมือเดิมซ้ำด้วย payload เดิม

เพราะงานอ่าน (read) ในเซสชัน coding agent กินโทเค็นถึง 65~90% ความสูญเปล่าแบบนี้จึงค่อย ๆ สะสมโดยไม่ทันสังเกต เครื่องมือ observability แสดง trace ให้ดูได้ แต่ไม่บอกว่าสเต็ปไหนเป็นงานซ้ำซ้อน

ตรวจจับอะไรบ้าง

Clew มองหารูปแบบความซ้ำซ้อน 3 แบบ:

repeat — เรียกเครื่องมือ/โหนดเดิมซ้ำ
requery — เรียกเครื่องมือเดิมซ้ำด้วยอินพุตเดิม (เอาต์พุตเหมือนเดิม)
pingpong — agent สองตัวส่งต่อเนื้อหาที่แทบจะเหมือนกัน (multi-agent)

แต่ละสิ่งที่พบจะถูกจัดเป็น 4 ประเภท:

error_repeat — เอาต์พุตเป็น error แต่ยังเรียกแบบเดิมซ้ำ
side_effect — รันเครื่องมือที่เปลี่ยนสถานะ (ส่ง/เขียน/สร้าง ฯลฯ) ซ้ำ
idempotent — ทำซ้ำกับเครื่องมือแบบอ่านอย่างเดียว/เชิงประกาศ (ไม่มีผลข้างเคียง แต่กินโทเค็น)
unclassified — เครื่องมือที่ไม่มีในแมปปิง ไม่อนุมานจากชื่อเครื่องมืออย่างเดียวเพราะผลลัพธ์ขึ้นกับ payload (เช่น Bash/PowerShell)

[ทำงานอย่างไร]
เป็นแคสเคด 2 ขั้น:

โครงสร้างเกต — จัดกลุ่มการเรียกเครื่องมือเดียวกันด้วยอาร์กิวเมนต์เดียวกัน (ที่ผ่านการทำ normalization แล้ว)
เกตความเหมือนกัน — ตรวจว่า sha256 ของเอาต์พุตตรงกันทุกประการหรือไม่ ถ้าไม่ตรงแปลว่าสถานะเปลี่ยน จึงไม่ถูกแฟล็ก

การตรวจโครงสร้างที่ต้นทุนต่ำจะคัดผู้ต้องสงสัยก่อน แล้วการตรวจเชิงความหมายที่แพงกว่า (embedding+cosine) จะรันเฉพาะเมื่อจำเป็น เนื่องจากไม่มีการตัดสินจาก LLM ผลลัพธ์จึงเป็นแบบกำหนดแน่นอน — จุดนี้สำคัญถ้าคุณอยากใส่มันเข้า CI

[รูปแบบอินพุต]
Claude Code — วิเคราะห์ session JSONL ได้โดยตรง
LangGraph — ตรวจจับ chain ซ้ำจาก trace
LangChain·CrewAI·AutoGen·LlamaIndex ฯลฯ — พาร์ส trace ที่ทำ instrumentation ตามฟอร์แมตมาตรฐาน OpenTelemetry/OpenInference (รองรับในระดับฟอร์แมต แต่การตรวจวัดจริงรายเฟรมเวิร์กยังอยู่ระหว่างดำเนินการ)
trace benchmark สาธารณะ (Toolathlon, RedundancyBench)

ตอนนี้ยังไม่รองรับเซสชัน Cursor และ Codex — กำลังตรวจดูฟอร์แมตภายในอยู่

[ผลการตรวจสอบ]

benchmark สาธารณะ (Toolathlon, 6,780 trace, 176,270 tool span):
ตรวจพบการเรียกซ้ำ 8,042 ครั้ง ในจำนวนนั้น 47% เป็นพื้นที่สีเทา (การทำงานแบบ idempotent, การประกาศว่าเสร็จแล้ว) เมื่อตัดส่วนนั้นออกจะเหลือ 4,251 ครั้ง (2.41% เทียบกับ tool span) สูงกว่าเซสชัน Claude Code (0.80%) ราว 3 เท่า

พบการรันซ้ำของเครื่องมือที่เปลี่ยนสถานะ 1,343 ครั้ง รวมถึงการส่งอีเมลซ้ำด้วยอาร์กิวเมนต์เดิม 459 ครั้ง อย่างไรก็ตาม นี่เป็นเพียงการตรวจพบว่ามีการเรียกเครื่องมือเดียวกันซ้ำด้วยอาร์กิวเมนต์เดิม ไม่ได้ยืนยันว่าเกิดผลข้างเคียงจริงหรือไม่

benchmark แบบติดป้ายกำกับ (RedundancyBench):
precision 0.826 (ค่าประมาณขอบล่างสำหรับความซ้ำภายในไฟล์) ป้ายกำกับ RB จำนวนมากเป็นความซ้ำข้ามไฟล์ (cross-file) ซึ่งอยู่นอกขอบเขตของการออกแบบที่วิเคราะห์ระดับเซสชัน recall อยู่ที่ 0.157 ซึ่งค่อนข้างต่ำ

[ขอบเขตความตรงไปตรงมา]
ยังไม่มีกรณีที่วัดการประหยัดได้จริง ตอนนี้ตรวจจับและประเมินได้ แต่ยังมีข้อมูล before/after จากผู้ใช้จริงที่แก้อะไรบางอย่างแล้วบิลลดลงจริงอยู่ 0 กรณี
47% ของสิ่งที่ถูกแฟล็กใน benchmark เป็นพื้นที่สีเทา (การรันซ้ำแบบ idempotent) มันกรองทิ้งไม่ได้ มีแค่จัดประเภทไว้ — เพราะการที่การรันซ้ำแบบอ่านอย่างเดียวจะถือว่าสูญเปล่าหรือไม่ ขึ้นอยู่กับบริบทที่มองไม่เห็น
เพราะกำหนดให้ sha256 ต้องตรงกันทุกประการ ถ้าเอาต์พุตต่างกันแม้เพียงเล็กน้อยก็จะไม่ถูกแฟล็ก นี่คือเหตุผลที่ recall ต่ำ และเป็นการออกแบบที่เอนเอียงไปทาง precision
Claude Code ถูกปรับแต่งมาดีเป็นพิเศษ ผมวัดรูปแบบความสูญเปล่าที่น่าจะเป็นไปได้ 6 แบบในเซสชัน CC จริง แต่ 5 แบบไม่พบในนั้น ความสูญเปล่าที่น่าสนใจกลับไปปรากฏในสภาพแวดล้อม MCP แบบหลายเครื่องมือ ไม่ใช่ใน CC เอง
การประเมินต้นทุน (amplification) เป็นการประมาณ ไม่ใช่การวัด และทำได้เฉพาะในฟอร์แมต Claude Code เท่านั้น
สิ่งที่ยังไม่ผ่านการตรวจสอบจะถูกทิ้ง

ผมเคยสร้างตัวตรวจจับการอ่านไฟล์ซ้ำ แต่จากการใส่คำอธิบายกำกับโดยมนุษย์กับตัวอย่าง 30 กรณี precision ต่ำกว่าเกณฑ์ที่ preregistered ไว้อย่างมาก (70%) — มองแบบผ่อนปรนก็แค่ 3.3% ถ้าเข้มงวดคือ 0% — จึงเลิกใช้ไปแล้ว ทั้งการคาดการณ์และผลลัพธ์ถูกเก็บไว้ด้วยกันในเอกสาร preregistration

อัปเดตจากผู้เขียนครับ ผมได้โพสต์บทความแยกที่สรุปส่วน MCP server ซึ่งในเนื้อหาหลักพูดถึงไว้เพียงบรรทัดเดียว — เป็นโครงสร้างที่แก้ปัญหาเวลาที่เอเจนต์เขียน migration แล้วตั้งชื่อคอลัมน์ตามใจตัวเอง โดยเปลี่ยนชื่อทางกายภาพจากการ “ป้อน” เป็นการ “คำนวณ” จากพจนานุกรมคำศัพท์:
https://sqemo.com/blog/erd-mcp-server

(ตอนนี้ยังรองรับเฉพาะ stdio local เท่านั้น จึงยังไม่รองรับ remote MCP, ตัวแอปหลักเป็นแบบปิด และเปิดเฉพาะ MCP server)

สามารถลองใช้ได้ทันทีโดยไม่ต้องสมัครสมาชิก (app.sqemo.com) ถ้ามีจุดไหนติดขัดช่วยคอมเมนต์บอกได้เลยครับ — ยังอยู่ช่วงเริ่มต้น เลยนำฟีดแบ็กไปปรับใช้ได้ทันที

บันทึกการอัปเดต (2026-07-25)

หลังจากโพสต์แรก ผมได้ขยาย Repolis ต่อเนื่องจากแค่เบราว์เซอร์ repo แบบ 3D ให้กลายเป็นหมู่บ้านเล็ก ๆ ที่มีเหตุผลให้กลับมาเยือนอีกครั้ง

• GitHub traffic และข้อมูล repo สาธารณะจะถูกสะท้อนในอาคารและแสงไฟยามค่ำคืนทุกวัน
• เพิ่ม Starlight Row ที่มีผู้อยู่อาศัย 8 คนพร้อมบ้านของแต่ละคน, รูทีนการใช้ชีวิตกลางวัน/กลางคืน และการเดินเล่นสั้น ๆ กับปฏิสัมพันธ์ระหว่างผู้อยู่อาศัย
• ด้วย Explorer Passport, Village Chronicle และ Town Gazette สามารถดูประวัติการเยี่ยมชม รวมถึง repo, release, push ใหม่ และการเปลี่ยนแปลงของตัวชี้วัดต่อเนื่องได้
• นำ procedural World Tree ที่สร้างด้วย threejs-sculpt-dna Copilot plugin ไปวางไว้ในเมือง Repolis จริงแล้ว
• โดยพื้นฐานยังคงเป็น zero-build static app ที่ไม่ต้องใช้แบ็กเอนด์หรือคีย์ ส่วนฟีเจอร์ grounded AI taxi/scholar เป็นตัวเลือกเท่านั้น

แทนที่จะเขียนโพสต์ใหม่ ผมจะบันทึกการเปลี่ยนแปลงต่อจากนี้ไว้ในคอมเมนต์ของโพสต์เดิมนี้ต่อไป

Live: https://hyeonsangjeon.github.io/Repolis/
Source: https://github.com/hyeonsangjeon/Repolis

บนคีย์บอร์ดเกาหลีของ Mac พิมพ์อีโมติคอนร้องไห้ไม่ได้เลย ใน Claude ตอนตอบก็มักจะใช้เครื่องหมายนี้บ่อยกว่ามาก แต่สำหรับผู้ใช้ภาษาเกาหลีแล้วไม่ค่อยคุ้นเคย...

ผมก็เห็นว่าเปิดให้ใช้แล้วเลยลองดูเหมือนกัน... อืม ภาษาไทยยัง T_T

ผมเป็นผู้เขียนครับ ขอเสริมบางอย่างที่ไม่ได้ใส่ไว้ในบทความ —

· วิดีโอเดโม (โฟลว์อนุมัติบนมือถือ, command center แบบแบ่ง 3 ส่วนบนเดสก์ท็อป) มีภาพจับหน้าจอจริงอยู่บนหน้า landing: adhf.dev
· การ self-host ใช้แค่คำสั่ง npm i -g adhdev บรรทัดเดียว แล้วแดชบอร์ดจะขึ้นที่ localhost:3847 (ไม่ต้องมีบัญชี)
· ยินดีรับคำถามเชิงออกแบบ เช่น การออกแบบ merge แบบ ff-only หรือการ cross-validation ของ MAGI จับอะไรได้จริงบ้าง

ถ้าให้ feedback มา ผมจะนำไปปรับปรุงทันทีครับ

ผมคาดหวังว่าจะได้เห็น gpt6... ในเมื่อ opus5 ออกมาแล้ว ไม่น่าจะต้องมีโมเดลใหม่ออกมาหรือครับ

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

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

ชอบบทความแบบนี้มากเลยครับ