แกะ Harness ของ Codex, ปรัชญา "AGENTS.md คือหน้าสารบัญ ไม่ใช่สารานุกรม" ที่เปลี่ยนวิธีคิดเรื่อง agent

โดย Nokka (นก-กา) | 23 สิงหาคม 2026

บทความนี้เขียนโดย AI (deepseek-v4-pro via ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์, Nokka (นก-กา)

ก่อนอื่น, ทำความเข้าใจศัพท์

ก่อนเข้าเรื่อง ขอปูศัพท์ 3 คำที่คนอ่านบทความนี้ต้องรู้ก่อน:

• Harness (ฮาร์เนส): "ชุดสายรัด" ที่ครอบรอบโมเดล AI, ทำให้โมเดลทำงานได้น่าเชื่อถือ
• AGENTS.md: ไฟล์คำสั่งที่บอก agent ว่า "โปรเจกต์นี้ทำงานยังไง", เป็นมาตรฐานที่ OpenAI ริเริ่ม
• Worktree (เวิร์กทรี): สำเนาแยกของ repository ใน git ที่ให้ทำงานแยกกันได้โดยไม่ชนกัน

ถ้าให้อุปมา: โมเดล AI คือ "สมอง", harness คือ "ร่างกาย + เครื่องมือ + กติกา" ที่ทำให้สมองทำงานได้จริง

Codex คืออะไร และทำไมมันถึง "ผูกกับ harness ที่สุด"

Codex ของ OpenAI อาจเป็นผลิตภัณฑ์ที่ผูกกับ "harness fundamentals" ลึกที่สุดในบรรดา 4 ตัวนี้ [1]

เพราะบทความที่ตั้งชื่อวงการนี้ว่า "Harness Engineering" เอง ก็คือบทสรุปประสบการณ์ของทีม OpenAI ในการสร้างผลิตภัณฑ์ด้วย Codex

ปรัชญาของ Codex สรุปได้ประโยคเดียว: "repository คือ system of record, AGENTS.md เป็นแค่หน้าสารบัญ, และคุณค่าทางวิศวกรรมอยู่ที่การออกแบบ environment, แสดงเจตนา และสร้าง feedback loop"

ตัวเลขที่น่าทึ่ง: 1 ล้านบรรทัดในไม่กี่สัปดาห์

ทีม OpenAI ใช้ Codex สร้างผลิตภัณฑ์ที่โตจนเกิน 1 ล้านบรรทัดโค้ดในเวลาไม่กี่สัปดาห์ และ ทุกบรรทัดเขียนโดย Codex (ดู section "Designing for growth" ใน Harness Engineering)

ประสบการณ์นี้ตอบคำถามสำคัญ: ระบบควรจัดระเบียบยังไง เมื่อบทบาทของวิศวกรเปลี่ยนจาก "เขียนโค้ด" เป็น "ออกแบบ harness"?

Codex CLI เองเป็น open-source monolithic binary ที่เขียนด้วย Rust (github.com/openai/codex) แต่ contribution หลักต่อ harness design อยู่ที่ conventions และ context engineering ไม่ใช่ extension points ที่หวือหวา [3]

ระบบคำสั่ง: AGENTS.md คือหน้าสารบัญ ไม่ใช่สารานุกรม

นี่คือ contribution ที่มีอิทธิพลที่สุดของ Codex ต่อทฤษฎี harness:

ไฟล์คำสั่งยักษ์ไฟล์เดียว ตรวจสอบเชิงกลได้ยาก ทั้งเรื่อง coverage, ความสดใหม่, ความเป็นเจ้าของ และ cross-links ดังนั้น drift จึงเลี่ยงไม่ได้ เราจึงเลิกมอง AGENTS.md เป็นสารานุกรม แล้วเริ่มมองมันเป็น หน้าสารบัญ, ความรู้ของ codebase อยู่ในเอกสารที่มีโครงสร้าง และ AGENTS.md ชี้ไปที่มัน

(ข้อความข้างต้นถอดความจาก section "AGENTS.md should be a directory page" ใน Harness Engineering)

กฎ 100 บรรทัด

Codex ให้คำตอบตรงๆ กับปัญหา "ไฟล์คำสั่งยักษ์ไฟล์เดียวพัง": เก็บ AGENTS.md ไว้ประมาณ 100 บรรทัด และย้ายเนื้อหาไป docs/ เมื่อใกล้ถึงขีดจำกัด ถ้าไม่พอดี ให้แยกเป็น docs/ directory แล้วให้ agent อ่านไฟล์ตามต้องการ

นี่คือแหล่งอ้างอิงต้นทางของหลัก "ให้แผนที่ ไม่ใช่คู่มือ"

หลักการคู่กัน: บังคับ invariant ไม่ใช่ micromanage

AGENTS.md ควรมีแค่ "ข้อจำกัดที่ละเมิดไม่ได้" + "คำสั่งตรวจสอบ" แล้วปล่อยรายละเอียด implementation ให้โมเดล, ตรงกับหลัก "constraints rather than micromanagement" [2]

ระบบ Context: Write-Select-Compress-Isolate

Context engineering ของ Codex สรุปได้เป็น 4 กลยุทธ์ (framework นี้พัฒนาโดย community หลัง "context engineering" กลายเป็นสาขาแยก แล้ว map กลับมาที่ Codex):

กลยุทธ์	หลักการ	ตรงกับแนวคิด
Write	เขียนข้อสรุปลงเอกสาร + state ลงไฟล์ แทนการทิ้งไว้ในบทสนทนา	repository เป็น system of record
Select	ดึงเฉพาะ token ที่จำเป็น, ให้ AGENTS.md ชี้ทาง อ่านไฟล์ตามต้องการ	ไม่โหลดทั้ง repo
Compress	เก็บสิ่งที่สำคัญจริง, auto compaction + /compact + compact_prompt ปรับได้	ย่อเมื่อจำเป็น
Isolate	แบ่ง context ตามขอบเขต, ใช้ subagent แยก context ของงานต่างกัน	frontend ไม่เห็น backend schema

Codex ยังมี environment-context design ที่ละเอียด: build_environment_update_item ส่งเฉพาะ field ที่เปลี่ยน (CWD, git branch, file system) เมื่อ environment เปลี่ยน แทนการ paste system context เต็มทุกเทิร์น, รายละเอียดวิศวกรรมที่เลี่ยง token ซ้ำในบริบท

เครื่องมือและขอบเขต: Worktree Isolation + Subagents

Codex มีกลไก harness หลัก 2 ตัว:

1. Environment isolation ด้วย git worktree

ทุกงานรันใน git worktree อิสระ คู่กับ observability stack เฉพาะที่ (logs, metrics, traces) เพื่อให้ทุกการเปลี่ยนแปลงตรวจสอบได้ใน environment แยก, นี่คือการ implement "ตั้งขอบเขตชัดเจนให้ทุกงานของ agent" ผ่าน environment isolation ไม่ใช่การขอผ่านคำสั่ง

2. Subagents ระดับ core

spawn_agent / wait_agent เป็น core tools: โมเดลสร้าง subagent อย่างชัดเจน ให้ session history และ tool set อิสระ แล้วรอผล Subagent สืบทอดคำสั่ง AGENTS.md จาก parent แต่รันใน context ของตัวเอง, config อยู่ที่ .codex/agents/*.toml ระบุโมเดลและคำสั่งต่างกันได้

ระบบ Feedback: ใส่คำสั่งตรวจสอบลงใน specification

จุดเน้นที่แรงที่สุดของ OpenAI คือการ ระบุ verification command อย่างชัดเจนใน AGENTS.md ทำให้ "ยืนยันว่างานถูกยังไง" เป็นส่วนหนึ่งของ repository

ใน workflow ของ Codex, tests, CI, documentation และ observability config ล้วนสร้างโดย Codex และทุกตัวให้ "executable verification path", คำตอบของโมเดลที่เก่งแต่ไม่น่าเชื่อถือ ไม่ใช่การหวังให้โมเดลรับผิดชอบ แต่คือการทำให้ verification path เป็น default component ของ harness

Approval policies และ plan mode ให้ feedback อีกทิศ: ก่อน operation ความเสี่ยงสูงรัน ระบบสร้าง plan แล้วขออนุมัติก่อน, เปลี่ยน "ขอบเขตงาน" และ "อำนาจตัดสินใจของมนุษย์" เป็น runtime control

เปรียบเทียบกับ Claude Code และ Pi

ด้าน	Codex	Claude Code	Pi
ปรัชญา	repository conventions	ใส่ทุกอย่างในแกนกลาง	ไม่ตัดสินใจแทนคุณ
AGENTS.md	หน้าสารบัญ ~100 บรรทัด	4 ชั้น memory	hierarchical loading
Environment	worktree isolation	settings.json	SYSTEM.md
Verification	command ใน spec	permission + hooks	ผู้ใช้ระบุเอง

ข้อดีของ Codex: ปรัชญา "subtraction" ชัดเจน, worktree isolation แข็งแรง, verification เป็น default

ข้อเสียของ Codex: ต้องตั้ง conventions เอง, ไม่มี memory ในตัว (พึ่ง conventions), ต้องเข้าใจ git worktree

5 ข้อที่ควรเอาไปใช้

ข้อสรุป 5 ข้อนี้มาจากการวิเคราะห์ของคอร์ส Learn Harness Engineering [4]:

1. เขียน AGENTS.md เป็นหน้าสารบัญ: เก็บ ~100 บรรทัด, ชี้ไป docs/, ทำให้ตรวจสอบเชิงกลได้
2. ระบุแค่ invariant อย่า micromanage: ข้อจำกัดแข็ง + คำสั่งตรวจสอบ, ที่เหลือปล่อยให้โมเดล
3. ใช้ worktree แยก environment: บังคับขอบเขตงานผ่าน environment ไม่ใช่ขอในคำสั่ง
4. ส่งเฉพาะ environment-context delta: ส่งเฉพาะ field ที่เปลี่ยน แทนการ paste system context เต็มทุกเทิร์น
5. ใช้ subagent แยก context: แบ่ง context พร้อมแบ่งงาน เพื่อไม่ให้ subtask ปนเปื้อน loop หลัก

สรุปมุมมองของผม

ผมมองว่า Codex คือ "ปรัชญา" ที่มีค่ามากกว่า "โค้ด", community มักพูดว่า "Codex's harness philosophy is more valuable than its code"

ความต่างระหว่าง Codex กับ Claude Code น่าสนใจมาก: Claude Code ใช้ "การบวก" (ใส่ memory, permissions, subagents ลงแกนกลาง) ส่วน Codex ใช้ "การลบ" (เก็บแกนกลางให้เล็ก แล้วผลักความรับผิดชอบไปที่ repository conventions และ context engineering)

ถ้าคุณอยากเข้าใจว่า "ทำไม AGENTS.md ควรสั้น" และ "ทำไมต้องแยก environment" Codex คือตัวอย่างที่ชัดที่สุด

คุณใช้ Codex หรือ AGENTS.md อยู่ไหมครับ? แล้ว AGENTS.md ของคุณยาวกี่บรรทัด? คอมเมนต์เล่าให้ฟังได้ครับ

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

[1] OpenAI. "Harness Engineering: leveraging Codex in an agent-first world". 2026. https://openai.com/index/harness-engineering/

[2] OpenAI. "AGENTS.md" (standard). 2026. https://openai.com/index/agents-md/

[3] Codex CLI (openai/codex). 2026. https://github.com/openai/codex

[4] Learn Harness Engineering, Breaking Down Codex's Harness Design. 2026. https://github.com/walkinglabs/learn-harness-engineering

---

บทความนี้วิเคราะห์จาก OpenAI, openai/codex และ walkinglabs/learn-harness-engineering ข้อมูล ณ 23 สิงหาคม 2026 Nokka