ทุกคนพูดถึง loops แต่แทบไม่มีใครพูดถึงสิ่งที่ loop ทำงานบนนั้น 9 ใน 10 นักพัฒนารัน Claude Code บน harness เริ่มต้น - ไม่มี rules, ไม่มี subagents, ไม่มี hooks, ไม่มี memory
แล้วพวกเขาก็สงสัยว่าทำไม loop ของพวกเขาถึงสร้างผลลัพธ์ที่ห่วยแตก ความจริงมันง่ายดาย: loop จะดีได้เท่าที่ harness ข้างใต้มันดีเท่านั้น นี่คือแผนงาน 14 ขั้นตอนสู่ harness - จาก agent ตัวเดียว สู่ระบบที่พัฒนาตัวเองได้
ติดตาม Substack ของฉันเพื่อรับ AI alpha สดใหม่:
Loop engineering - การสร้างระบบที่กระตุ้น agent ของคุณตามตารางเวลา - ได้รับความสนใจทั้งหมดในเดือนนี้ แต่ Addy Osmani ผู้เขียนบทความขนาดยาวเกี่ยวกับ loops ก็ระมัดระวังที่จะชี้ไปที่สิ่งที่อยู่ข้างใต้มัน:
"Loop engineering อยู่สูงกว่า harness หนึ่งชั้น Harness คือสภาพแวดล้อมที่ agent ตัวเดียวทำงานอยู่ภายใน Loop คือ harness แต่มันทำงานบนตัวจับเวลา สร้างผู้ช่วย และป้อนข้อมูลให้ตัวเอง"
Harness engineering คือการออกแบบสภาพแวดล้อมนั้น: โมเดล, เครื่องมือ, สิทธิ์, บริบท, หน่วยความจำ
มันคือเลเยอร์ที่ไม่สวยงาม - และมันคือเลเยอร์ที่ตัดสินว่าทุกสิ่งที่อยู่เหนือมันจะทำงานได้หรือไม่ loop ที่ยอดเยี่ยมบน harness ที่ห่วยคือหนทางที่รวดเร็วในการผลิตขยะในปริมาณมาก

14 ขั้นตอน. 3 ระดับ. รากฐานที่ทุกสิ่งทุกอย่างยืนอยู่บนนั้น
ส่วนที่ 1 · Harness คืออะไร
01. Harness คือสภาพแวดล้อมที่ agent ตัวหนึ่งทำงานอยู่ภายใน
ตัดศัพท์เทคนิคออกไปแล้ว harness ก็คือสี่สิ่งนี้: โมเดล ที่ทำการคิด, เครื่องมือ ที่มันเข้าถึงได้, สิทธิ์ บนเครื่องมือเหล่านั้น, และ บริบท ที่มันอ่านเมื่อเริ่มต้นการทำงานแต่ละครั้ง
นั่นคือพื้นผิวทั้งหมด ทุกสิ่งอื่น - subagents, hooks, memory - เป็นวิธีในการปรับแต่งหนึ่งในสี่สิ่งนั้น

เหตุผลที่ harness มีความสำคัญมากกว่าที่คนคิด: agent คือ while True loop ที่เลือกเครื่องมือ รันมัน ดูผลลัพธ์ และตัดสินใจขั้นตอนต่อไป
Harness กำหนดว่าเครื่องมือใดมีอยู่, agent ได้รับอนุญาตให้ทำอะไร, และมันรู้อะไรบ้างเมื่อมันเริ่มต้น โมเดลเดียวกัน, harness ต่างกัน, agent ที่แตกต่างกันโดยสิ้นเชิง
02. ทั้งหมดของ harness อยู่ในโฟลเดอร์เดียว .claude/
ทุกสิ่งที่กำหนดรูปร่าง agent ของคุณอยู่ในไดเรกทอรีเดียวที่ root ของโปรเจกต์คุณ เรียนรู้เค้าโครงนี้แล้วคุณจะสามารถอ่าน harness ของใครก็ได้ในพริบตา:
1.claude/2├─ CLAUDE.md # ข้อเท็จจริงประจำ — อ่านทุกเซสชัน3├─ settings.json # สิทธิ์, โมเดล, hooks4├─ .mcp.json # การเชื่อมต่อเครื่องมือภายนอก5├─ rules/ # พฤติกรรมตามเส้นทาง6│ ├─ tests.md7│ └─ python-types.md8├─ agents/ # นิยาม subagent (~30 บรรทัดต่ออัน)9│ ├─ reviewer.md10│ └─ eval-runner.md11├─ skills/ # เวิร์กโฟลว์ที่ใช้ซ้ำได้12│ └─ pr-checklist/13│ └─ SKILL.md14└─ agent-memory/ # สิ่งที่คงอยู่ระหว่างการรันแต่ละครั้ง15 └─ STATE.md
กฎข้อหนึ่งที่แยก harness ที่สะอาดออกจากความเละเทะ: ทำให้มันเล็กพอที่คุณจะอธิบายได้ว่าแต่ละไฟล์มีไว้ทำไม ถ้าคุณบอกไม่ได้ว่า rule, hook, หรือ subagent ไหนมีไว้เพื่ออะไร ให้ลบทิ้ง
03. Harness vs loop vs system สามชั้น อย่าผสมพวกมันเข้าด้วยกัน
ปัญหา "การตั้งค่า agent ของฉันมันยุ่งเหยิง" ส่วนใหญ่มาจากการสับสนระหว่างสามชั้นนี้ ให้แยกพวกมันให้ชัดเจน:
- Harness คือ runtime ที่ agent หนึ่ง ตัวอาศัยอยู่ การกำหนดค่าแบบคงที่: โมเดล, เครื่องมือ, สิทธิ์, บริบท ฉบับนี้
- Loop จะกระตุ้น agent ตามตัวจับเวลา สร้างผู้ช่วย ป้อนข้อมูลให้ตัวเอง มันทำงาน บน harness
- ระบบที่พัฒนาตัวเองได้ (self-improving system) คือ loop บวกกับ memory ที่ทบต้น - ทุกการรันจะทำให้การรันครั้งถัดไป sharp มากขึ้น
ในทางปฏิบัติให้: ใส่ข้อเท็จจริงประจำในบริบท, การบังคับใช้ใน hooks, ขั้นตอนการทำงานใน skills, และการแยกตัวใน subagents
การผสม这些东西ผิด - การบังคับใช้ใน CLAUDE.md, ขั้นตอนการทำงานที่ทำให้บริบทบวม - เป็นต้นเหตุของ agents ที่ไม่สอดคล้องและมีต้นทุนสูง
04. Harness เริ่มต้น. สิ่งที่คุณได้รับจากกล่อง
ติดตั้ง Claude Code, เปิดโฟลเดอร์, แล้วคุณก็มี harness แล้ว - แค่ว่างเปล่า ค่าเริ่มต้นให้คุณมีโมเดลที่มีความสามารถ, เครื่องมือในตัว (read, write, bash, search), และข้อความขออนุมัติในทุกสิ่งที่เสี่ยง ไม่มีบริบทของโปรเจกต์, ไม่มี subagents ที่กำหนดเอง, ไม่มี memory

สำหรับงานที่ทำครั้งเดียว ค่าเริ่มต้นก็ใช้ได้ สำหรับอะไรก็ตามที่คุณทำมากกว่าหนึ่งครั้ง ค่าเริ่มต้นจะทำให้ agent ต้อง推导โปรเจกต์ของคุณจากศูนย์ทุกเซสชัน ขออนุญาตสำหรับการดำเนินการที่ปลอดภัย และลืมทุกอย่างเมื่อคุณปิดเทอร์มินัล
สิบขั้นตอนถัดไป是关于การปิดช่องว่างนั้น
05. CLAUDE.md: ข้อเท็จจริงประจำ, เก็บให้สั้น
CLAUDE.md จะถูกอ่านเมื่อเริ่มต้นทุกเซสชัน มันคือความรู้ประจำของ agent เกี่ยวกับโปรเจกต์ของคุณ - ข้อตกลง, สถาปัตยกรรม, "เราไม่ทำแบบนี้เพราะเหตุการณ์นั้น"

ข้อผิดพลาดที่พบบ่อยที่สุด: ปล่อยให้มันเติบโตเป็นเอกสารขั้นตอนการทำงานขนาดยักษ์ที่ทำให้ทุกเซสชันบวม
กฎจากผู้ปฏิบัติที่ใช้สิ่งนี้ทุกวัน: เก็บไฟล์ memory หลักให้ต่ำกว่า ~500 โทเค็น ข้อเท็จจริงประจำอยู่ที่นี่
ขั้นตอนการทำงานแบบหลายขั้นตอนไปอยู่ใน skills (ขั้นตอนที่ 8) พฤติกรรมเฉพาะเส้นทางไปอยู่ในไฟล์ rules/ ที่ขอบเขตจำกัดเฉพาะที่มันเกี่ยวข้อง ถ้าส่วนใดของ CLAUDE.md กลายเป็นขั้นตอนการทำงานมากกว่าข้อเท็จจริง มันควรอยู่ที่อื่น
อ่าน CLAUDE.md ของคุณออกมาดังๆ ทุกบรรทัดควรเป็น
ข้อเท็จจริง
ที่ agent ต้องการในทุกเซสชัน ("เราใช้ pnpm, ไม่ใช่ npm") ถ้าบรรทัดใดเป็น
ขั้นตอนการทำงาน
("ในการเพิ่มฟีเจอร์, ก่อนอื่น..."), ให้ย้ายมันไปที่ skill
ถ้ามันเป็น กฎสำหรับหนึ่งโฟลเดอร์ ให้ย้ายมันไปที่ rules/
06. settings.json: สิทธิ์และโมเดล, ตั้งค่าครั้งเดียว
Harness เริ่มต้นจะถามก่อนทุกการกระทำที่เสี่ยง นั่นถูกต้องเมื่อคุณกำลังดู และผิดเมื่อคุณไม่ได้ดู settings.json คือที่ที่คุณอนุมัติล่วงหน้าในสิ่งที่ปลอดภัย ปฏิเสธสิ่งที่อันตราย และเลือกว่าโมเดลใดจะทำงาน
1{2 "model": "claude-sonnet-4-6",3 "permissions": {4 "autoApprove": [5 "Read(*)", "Grep(*)",6 "Bash(npm test)", "Bash(git status)"7 ],8 "deny": [9 "Bash(rm -rf*)", "Bash(git push*)",10 "Edit(.env*)", "Edit(secrets/*)"11 ]12 }13}
การทดสอบว่าควร auto-approve อะไร: ถ้าสิ่งนี้ผิดพลาด มันยากแค่ไหนที่จะแก้ไข? แก้ไขถูก → auto-approve
แก้ไขแพง (force-push, ลบไฟล์, แตะต้อง secrets) → ปฏิเสธหรือถามเสมอ จุดกึ่งกลางก็ใช้ได้ที่จะ auto-approve ถ้า คุณบันทึกมันไว้
07. Subagents: บริบทที่แยกออกมาสำหรับงานสกปรก
Subagent คือเซสชัน Claude ที่เป็นอิสระซึ่งเปิดจากเซสชันหลัก - หน้าต่างบริบทของมันเอง, รายการเครื่องมือของมันเอง ประเด็นไม่ได้อยู่ที่การทำขนานเพื่อประโยชน์ของมันเอง มันคือ การเก็บ noise ออกจากบริบทหลัก
งานวิจัยที่อ่าน 40 ไฟล์, การ review รอบที่ต้องการมุมมองใหม่, การ eval run ที่สร้าง log เต็มกำแพง - สิ่งเหล่านั้นอยู่ใน subagent เพื่อไม่ให้มันปนเปื้อนเธรดหลัก
GIF
subagent ที่มีค่าที่สุดใน harness ใดๆ คือตัวที่ ตรวจสอบงานที่ agent หลักทำ โมเดลที่ review ผลลัพธ์ของตัวเองนั้นใจดีกับตัวเองเกินไป;
ผู้ตรวจสอบแยกต่างหากที่มีหน้าต่างบริบทใหม่จะจับสิ่งที่ผู้เขียน说服ตัวเองให้เชื่อ นี่คือการแบ่ง writer-vs-checker ที่ทำให้ทุก loop ที่อยู่เหนือ harness น่าเชื่อถือ
08. Skills: ขั้นตอนการทำงานที่ agent ใช้ซ้ำ
Skill คือไฟล์ SKILL.md ที่ agent รัน - ไม่ว่าจะเมื่อคุณเรียกมันด้วย /skill-name หรือโดยอัตโนมัติเมื่องานตรงกับคำอธิบายของมัน

ต่างจาก subagent, มันทำงานในหน้าต่างบริบท เดียวกัน มันเป็นแค่คำแนะนำที่ใช้ซ้ำได้ซึ่งกลายเป็นส่วนหนึ่งของเซสชัน
สิ่งกระตุ้นให้สร้างหนึ่งอัน: คุณสังเกตว่าตัวเองกำลังวางคำแนะนำเดิมๆ ลงในทุกการสนทนาใหม่ นั่นคือ skill ที่รอจะเกิดขึ้น รายการตรวจสอบ PR, ขั้นตอนการ eval, กระบวนการปล่อย - เขียนครั้งเดียว, เรียกใช้ตลอดไป
และเพราะ skills คือหน่วยที่ใช้ซ้ำได้ พวกมันคือสิ่งที่ทำให้ harness พัฒนาขึ้นเมื่อเวลาผ่านไป: ทุกครั้งที่ขั้นตอนการทำงานล้มเหลวในวิธีใหม่ คุณเพิ่มบทเรียนลงใน skill, และการรันครั้งถัดไปจะสืบทอดมันมา
09. Hooks: กฎที่แน่นอนซึ่งโมเดลไม่สามารถ hallucinate ได้
ทุกอย่างจนถึงตอนนี้ขึ้นอยู่กับโมเดล ที่เข้าใจ คำแนะนำของคุณ Hooks ไม่ได้เป็นอย่างนั้น
Hook คือคำสั่ง shell ที่ยิง ณ จุดตายตัวในวงจรชีวิตของ agent - ก่อนที่เครื่องมือจะทำงาน, หลังจากไฟล์เปลี่ยนแปลง, เมื่อเซสชันสิ้นสุด - และรหัสออก (exit code) ของมันสามารถ block การกระทำได้ Hooks คือการบังคับใช้, CLAUDE.md คือคำแนะนำ

hooks สองตัวที่สมควรได้รับตำแหน่งในแทบทุก harness:
- ประตู PreToolUse ที่ block คำสั่งอันตรายอย่างแน่นอน — rm -rf, อ่าน .env, push ไปที่ main รหัสออก 2 หยุดการเรียกก่อนที่มันจะเกิดขึ้น โมเดลไม่สามารถพูดเพื่อ绕过มันได้
- ตัวจัดรูปแบบ PostToolUse ที่รัน linter หรือ formatter ของคุณหลังทุกการแก้ไข Agent ไม่เคยส่งโค้ดที่ไม่ได้จัดรูปแบบเพราะว่า harness จัดรูปแบบให้โดยอัตโนมัติ
1"hooks": {2 "PreToolUse": [{3 "matcher": "Bash",4 "command": "./.claude/hooks/block-dangerous.sh"5 // exit 2 = block การเรียกก่อนที่มันจะทำงาน6 }],7 "PostToolUse": [{8 "matcher": "Edit|Write",9 "command": "prettier --write \"$CLAUDE_FILE_PATH\""10 }]11}
ใช้ hooks สำหรับอะไรก็ตามที่ ต้อง เกิดขึ้นหรือ ต้องไม่ เกิดขึ้น - ความปลอดภัย, การจัดรูปแบบ, การบันทึกตรวจสอบ
อย่าใช้มันสำหรับการตัดสินใจที่ต้องใช้ดุลยพินิจ; นั่นคือสิ่งที่โมเดลมีไว้ Harness ที่ดีมี hooks ที่คมกริบหนึ่งหรือสองอัน, ไม่ใช่ยี่สิบอัน
ส่วนที่ 3 · ทำให้มันทบต้น
10. เพิ่ม loop. ตอนนี้ harness ทำงานบนตัวจับเวลา
Harness ที่กำหนดค่าแล้วยังคงรอให้คุณพิมพ์คำสั่ง Loop ทำให้มันทำงานด้วยตัวเอง เวอร์ชันที่ง่ายที่สุดคือ /loop ใน Claude Code - การแจ้งเตือนที่เกิดขึ้นซ้ำตามช่วงเวลา

จับคู่กับ /goal แล้ว loop จะดำเนินต่อไปจนกว่าเงื่อนไขวัตถุประสงค์จะเป็นจริง โดยตรวจสอบโดยผู้ให้คะแนนอิสระ มากกว่าให้ agent ให้คะแนนตัวเอง
1> /loop 30m /goal การทดสอบทั้งหมดผ่านและ lint สะอาด2 จัดการความล้มเหลวใหม่, ร่างการแก้ไขในสาขา claude/34▲ Claude ใช้ harness ที่คุณสร้าง:5 - rules/ สำหรับข้อตกลง6 - reviewer subagent เพื่อตรวจสอบการแก้ไขแต่ละครั้ง7 - PreToolUse hook block การ push ไปที่ main8✓ กำลังวนซ้ำ ผู้ให้คะแนนอิสระตัดสิน "เสร็จ"
สังเกตสิ่งที่เพิ่งเกิดขึ้น: loop ไม่ได้เพิ่มความฉลาด มันใช้ทุกอย่างใน harness ซ้ำ - rules, reviewer subagent, safety hook Harness ที่ดีทำให้ loop กลายเป็นเรื่องเล็กน้อย นั่นคือประเด็นทั้งหมดของการสร้างรากฐานก่อน
11. เพิ่มเวิร์กโฟลว์แบบไดนามิก. Harness เขียน orchestration ของตัวเอง
สำหรับงานที่ซับซ้อนเกินไปสำหรับ loop เดียว - ขนานกันเป็นจำนวนมาก, มีโครงสร้างสูง, เป็นปฏิปักษ์ - Claude สามารถเขียน JavaScript harness ของตัวเองได้ทันที
นั่นคือเวิร์กโฟลว์แบบไดนามิก: agent() เพื่อสร้าง, parallel() เพื่อกระจาย, pipeline() เพื่อสตรีม มันประกอบ subagents ที่ harness ของคุณกำหนดเป็นรูปแบบต่างๆ เช่น fan-out-and-synthesize หรือ adversarial verification

ความเชื่อมโยงกับวิศวกรรม harness: เวิร์กโฟลว์แบบไดนามิกจะดีได้เท่ากับ subagents และ skills ที่มันสามารถเรียกใช้ได้เท่านั้น
ถ้า harness ของคุณมี reviewer subagent ที่เฉียบคมและ eval skill ที่เขียนดี เวิร์กโฟลว์ก็มีชิ้นส่วนที่ดีในการ orchestrate ถ้า harness ว่างเปล่า เวิร์กโฟลว์ก็ไม่มีอะไรให้ทำงานด้วย
เวิร์กโฟลว์คือวาทยกร, harness ของคุณคือวงออเคสตรา
12. เพิ่ม memory. สิ่งที่ agent ลืม, harness จดจำ
นี่คือขั้นตอนที่เปลี่ยน harness ที่กำหนดค่าแล้วให้เป็นระบบที่พัฒนาขึ้นจริงๆ Agent ลืมทุกอย่างระหว่างการรัน Harness ไม่จำเป็นต้องเป็นเช่นนั้น
ไฟล์ state - ไฟล์ markdown ใน agent-memory/, หรือบอร์ด Linear - บันทึกสิ่งที่ลองแล้ว, สิ่งที่ใช้ได้, สิ่งที่ล้มเหลว, กฎอะไรที่รอดมา

รูปแบบที่ทำให้ memory ทบต้น, ดึงมาจากวิธีที่ agents ที่แข็งแกร่งที่สุดใช้มัน:
- เขียนก่อนเดินออกไป. ทุกการรันจบลงด้วยการอัปเดตไฟล์ state - บทเรียนที่เรียนรู้, ข้อเท็จจริงที่ตรวจสอบแล้ว, สิ่งที่ต้องทำต่อไป
- อ่านเมื่อเริ่มต้น. ทุกการรันเริ่มต้นด้วยการอ่านไฟล์ state และ skills ที่เกี่ยวข้อง, ดังนั้นมันจะ繼續而不是重新開始
- กลั่นเป็น skills. เมื่อบทเรียนเป็นเรื่องทั่วไป ("Windows runners ต้องการ bash, ไม่ใช่ PowerShell"), มันจะเลื่อนชั้นจากไฟล์ state ไปเป็น skill, ที่ซึ่งมันใช้ได้กับทุกโปรเจกต์ในอนาคต
1# Project memory23## Verified facts # หยุดเดาเกี่ยวกับสิ่งเหล่านี้4- prc อยู่ในหน่วยดอลลาร์ ไม่ใช่เซนต์ (ตรวจสอบผ่าน SELECT MIN/MAX)5- ลำดับ auth middleware: rate_limit -> jwt -> rbac67## Lessons learned # กลั่นสิ่งทั่วไปเป็น skills8- Windows CI runners ล้มเหลว TLS 1.2 ใน PowerShell — ใช้ bash9- การ migration บนตาราง >1M แถวต้อง batch ในชุดละ 10k1011## Last session # ต่อ, อย่าเริ่มใหม่122026-06-11 · 3 การแก้ไขถูก merge, 2 ถูกส่งต่อ ขั้นตอนถัดไป: ตรวจสอบ rate-limit fix
13. ปิด loop. ผลลัพธ์ → บทเรียน → skill → ผลลัพธ์ที่ดีขึ้น
นี่คือจุดที่สามชั้นล็อคเข้าด้วยกันเป็นสิ่งที่พัฒนาตัวเองได้ แต่ละการรันสร้างผลลัพธ์ reviewer subagent (ขั้นตอนที่ 7) ตรวจสอบมัน
ผลลัพธ์ - อะไรผ่าน, อะไรล้มเหลว, อะไรที่เรียนรู้ - ถูกเขียนไปยัง memory (ขั้นตอนที่ 12) บทเรียนทั่วไปถูกกลั่นเป็น skills (ขั้นตอนที่ 8)
การรันครั้งถัดไปจะสืบทอด skills ที่เฉียบคมขึ้นและ memory ที่สมบูรณ์ขึ้น
นั่นคือ self-improving loop ทั้งหมด, และสังเกตว่ามันสร้างขึ้นจากส่วนประกอบของ harness ทั้งหมด:
- Subagent ให้คะแนนงาน - การตรวจสอบตามวัตถุประสงค์, บริบทใหม่
- Memory บันทึกคำตัดสิน - คงอยู่ระหว่างการรัน
- Skills ทำให้มันใช้งานได้ในทุกโปรเจกต์
- Loop รันมันอีกครั้ง - ตอนนี้กับทุกสิ่งที่การรันครั้งก่อนเรียนรู้มา
โมเดลไม่เคยเปลี่ยนแปลง Harness รอบๆ มันเฉียบคมขึ้น นั่นคือสิ่งที่ "self-improving" หมายถึงอย่างแท้จริง - ไม่ใช่โมเดลที่เรียนรู้, แต่ harness ที่สะสม
14. ส่งมอบ harness. 打包มัน. แบ่งปันมัน. ใช้มันซ้ำ
Harness ที่ใช้ได้กับโปรเจกต์หนึ่งคือสินทรัพย์
รวม skills, subagents, และ rules เป็นปลั๊กอิน แล้วทั้งทีมของคุณติดตั้งการตั้งค่าเดียวกันในขั้นตอนเดียว - ข้อตกลงเดียวกัน, safety hooks เดียวกัน, reviewer เดียวกัน

Harness หยุดเป็นแค่การตั้งค่าส่วนตัวของคุณ และกลายเป็นโครงสร้างพื้นฐานที่ใช้ร่วมกัน
ลำดับในการสร้าง, อีกครั้งหนึ่ง, เพราะลำดับคือบทเรียน: ทำให้การรันด้วยตนเองครั้งหนึ่งเชื่อถือได้บน harness ที่สะอาด
เพิ่มบริบทและสิทธิ์ เพิ่ม reviewer subagent เพิ่ม memory จากนั้น และเมื่อนั้นเท่านั้น ค่อยครอบมันด้วย loop Loop บน harness ที่ดีจะทบต้น Loop บน harness ที่ห่วยแค่ทำให้เลือดไหลเร็วขึ้น
§ ข้อผิดพลาดของ harness ที่ทำให้ทุก loop แย่ลง
- รันบนค่าเริ่มต้น. ไม่มีบริบท, ไม่มี rules, ไม่มี memory - agent 推导โปรเจกต์ของคุณใหม่ทุกเซสชัน
- CLAUDE.md ที่บวม. ขั้นตอนการทำงานถูกยัดเยียดในบริบทประจำ, ทำให้ทุกการรันบวม ย้าย它们ไปที่ skills
- การบังคับใช้ใน CLAUDE.md แทนที่จะเป็น hooks. โมเดลสามารถละเว้นคำแนะนำได้ มันไม่สามารถละเว้น hook ที่ exit 2 ได้
- Agent ตัวเดียวเขียนและให้คะแนนงานของตัวเอง. เพิ่ม reviewer subagent ที่มีหน้าต่างบริบทใหม่
- ไม่มี memory. ทุกการรันเริ่มจากศูนย์ ไฟล์ state คือสิ่งที่ทำให้พรุ่งนี้继续
- ครอบ loop รอบ harness ที่ห่วย. Loop แค่ผลิตขยะได้เร็วขึ้น สร้างรากฐานก่อน
- ยี่สิบ hooks. หนึ่งหรือสองอันที่คมกริบ ดีกว่ากองที่ไม่มีใครเข้าใจ
- ส่งมอบ harness โดยไม่สแกนมัน. ความลับที่รั่วไหลและสิทธิ์ที่กว้างเกินไปจะแพร่กระจายไปยังทุกคนที่ติดตั้งมัน
สรุป:
Loop ได้รับเกียรติยศ Harness ทำงานหนัก
Loop engineering คือส่วนที่น่าตื่นเต้น - agent ที่แจ้งเตือนตัวเอง, ทำงานในขณะที่คุณหลับ แต่ loop ก็แค่ harness ที่มีตัวจับเวลา
ทุกสิ่งที่ตัดสินว่าผลลัพธ์จะดีหรือห่วยนั้นอยู่ต่ำกว่าหนึ่งชั้น, ในโมเดลที่คุณเลือก, เครื่องมือที่คุณอนุญาต, บริบทที่คุณเขียน, ผู้ตรวจสอบที่คุณเพิ่ม, memory ที่คุณเก็บไว้
สร้างชั้นนั้นให้ดี แล้วทุกสิ่งที่อยู่เหนือมันจะทบต้น: loop ใช้ subagents ของคุณซ้ำ, เวิร์กโฟลว์ orchestrate skills ของคุณ, memory ทำให้แต่ละการรันเฉียบคมกว่าครั้งก่อน
การพัฒนาตนเองไม่เคยเป็นคุณสมบัติของโมเดล มันคือคุณสมบัติของ harness ที่คุณสร้างรอบๆ มัน
เลือกสิ่งหนึ่งที่คุณยังไม่ได้ทำ - อาจจะเป็น reviewer subagent, safety hook, หรือไฟล์ state — และเพิ่มมันวันนี้ ทำให้ harness เล็กพอที่จะอธิบายได้ แล้ววาง loop ทับลงไป, และดูรากฐานทำงาน






