ประสิทธิภาพ & ค่าใช้จ่าย

ล่าสุด: 2026-10-25.md

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

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 เท่าไร — ต้องวัดก่อน