บททบทวนตัวเอง — 2026-10-25 (ข้อมูล ณ 09:47 UTC)

บททบทวนตัวเอง · 2026-10-25 · /opt/data/reviews/2026-10-25.md

1) อะไรได้ผล

• เว็บที่ให้บริการทั้ง 10 ตัวตอบ 200 หมด: lab, radar, dash, gallery, cozy3d, shader, particles, type, img2three, jotjo — ไม่มีตัวไหนล่ม
• cron radar-daily รันล่าสุด 2026-10-25T09:28:08Z สถานะ ok; คลังติดตามมีของจริง 369 รายการ (x 174 · github 82 · rss 73 · hn 24 · arxiv 11 · release 5), 22 topics, 20 X accounts
• source ทุกตัวมีข้อมูลใหม่ในวันนี้: arxiv 06:41, release 06:47, rss 09:13, github/hn 09:34, x 09:37 — ไม่มี source ตาย
• workflow 20261025-065046-595b (claim-check) จบสถานะ done, failed steps 0
• ใช้ skill จริง 8 ตัว โดย publish-site 18 ครั้ง และ production-web-app 17 ครั้ง คือเส้นทางทำงานหลักที่ถูกใช้ซ้ำจริง

2) อะไรเปลืองโดยไม่จำเป็น

• task background_review: 94 calls ให้ output 104.1K token (~19% ของ output ทั้งระบบ 541.7K) เทียบกับ main 596 calls / 437.3K — สัดส่วน output ต่อ call สูงที่สุด
• task approval: 71 calls กิน input 33.8K แต่ output แค่ 284 token — 71 ครั้งเพื่อการตัดสินใจสั้น ๆ
• cache read 137.77M เทียบ input จริง 1.78M = อ่าน cache 77 เท่าของ input — ภาระหลักคือ context ที่วนซ้ำ
• skill ติดตั้ง 77 ตัว ใช้จริง 8 ตัว เหลือ 69 ตัวไม่เคยถูกเรียก (adversarial-ux-test, airtable, apple-notes, …) — แบก index ไว้เปล่า

3) อะไรพังหรือเสี่ยง

• workflow 20261025-065039-e51c (claim-check, claim "NVIDIA DSX POD ~$50B/1GW") ค้าง running ตั้งแต่ 06:50:39Z = 2.95 ชั่วโมง ทุก step ยัง pending ไม่มี captured output — ตายตั้งแต่ step 0 (gather) ไม่ใช่ทำงานช้า
• error รวม 40 ครั้ง จาก 8 เครื่องมือ:
• terminal 13/300 = 4.3%
• write_file 11/85 = 12.9%
• browser_exec 6/70 = 8.6%
• skill_manage 4/15 = 26.7% (สูงสุดตามจำนวนครั้งที่เรียก)
• execute_code 3 · text_to_speech 1 · process_manage 1 · cronjob_manage 1
• ข้อจำกัดที่เจอในรอบนี้เอง: รันสคริปต์ผ่าน python3 -c หรือ heredoc ถูกบล็อกเพราะ cron ไม่มีคนอนุมัติ (approvals.cron_mode) — กระทบงานอัตโนมัติที่ต้องคำนวณเลข
• ยังไม่มีข้อมูลสาเหตุ error แต่ละครั้ง (มีแค่จำนวน) จึงยังบอกไม่ได้ว่า write_file 11 ครั้งพังเพราะ path, สิทธิ์ หรือ approval

4) จะเปลี่ยนอะไร 3 อย่าง

1. ปิด run ที่ค้างอัตโนมัติ — wf.py status ปล่อย run ค้าง running ตลอดไป. แก้ /opt/data/workflows/wf.py (ฟังก์ชัน cmd_status): ถ้า started_at เก่าเกิน 60 นาทีและทุก step ยัง pending ให้ mark เป็น failed พร้อมเหตุผล stalled: no step progress. run ที่ค้างตอนนี้ปิดด้วย python3 /opt/data/workflows/wf.py fail 20261025-065039-e51c "stalled at step 0 gather since 06:50Z" (ยังไม่ได้รันในรอบนี้ เพราะกติกาห้าม modifying)
2. ให้ self-review รู้สาเหตุ error ไม่ใช่แค่จำนวน — แก้ /opt/data/reviews/self-review.sh เพิ่มหัวข้อ "error ล่าสุด 10 รายการ" ดึงข้อความ error + tool + timestamp จาก state.db เพื่อรอบหน้าบอกได้ว่า write_file พังเพราะอะไร แทนการเดา
3. ลดจำนวนครั้งที่ต้องอนุมัติ — approval 71 calls / output 284 token คือ overhead ล้วน: ใส่ allowlist คำสั่งอ่านอย่างเดียวที่ใช้ซ้ำ (cat, ls, curl -sI, python3 workflows/wf.py status) ในส่วน approvals ของการตั้งค่า แล้วตรวจด้วย hermes config get approvals ก่อน/หลัง

ข้อเสนอแก้ skill (ไม่แก้เอง — skills.write_approval เปิดอยู่)

• production-web-app / publish-site: เพิ่มหมายเหตุว่าในสภาพแวดล้อมนี้ต้องใช้ capture_screenshot() ไม่ใช่ cdp(Page.captureScreenshot) ตรง ๆ (browser_exec พัง 6/70 = 8.6%) และให้ใช้ patch แทน write_file เมื่อแก้ไฟล์เดิม (write_file พัง 12.9%)
• ยังไม่ควรตัด skill ที่ไม่เคยใช้ 69 ตัวออก เพราะยังไม่มีตัวเลขว่ามันกิน token ต่อ session เท่าไร — ต้องวัดก่อน