ການວິສະວະກຳ Harness ແມ່ນວິທີປະຕິບັດທີ່ສ້າງກົນໄກປ້ອງກັນການເກີດຂຶ້ນຄືນຂອງຄວາມຜິດພາດທີ່ AI Agent ໄດ້ກໍ່ຂຶ້ນ ໂດຍການອອກແບບໂຄງສ້າງຜ່ານ Document, ເຄື່ອງມື, ແລະ ຂໍ້ຈຳກັດດ້ານສະຖາປັດຕະຍະກຳ. ແນວຄິດດັ່ງກ່າວໄດ້ແຜ່ຂະຫຍາຍຢ່າງວ່ອງໄວ ເນື່ອງຈາກການເຜີຍແຜ່ຂອງ Mitchell Hashimoto ແລະ ກໍລະນີສຶກສາຈາກທີມວິສະວະກຳຂອງ OpenAI ທີ່ປາກົດຂຶ້ນໃນຊ່ວງເວລາໃກ້ຄຽງກັນ ລວມທັງການກ່າວເຖິງຂອງ Martin Fowler ອີກດ້ວຍ.

ບົດຄວາມນີ້ມຸ່ງອະທິບາຍແນວຄິດ, ອົງປະກອບ, ແລະ ຂັ້ນຕອນການປະຕິບັດຂອງການວິສະວະກຳ Harness ໃຫ້ແກ່ວິສະວະກອນ ແລະ ຜູ້ຈັດການທີ່ໄດ້ນຳໃຊ້ AI Agent ເຂົ້າໃນການດຳເນີນງານແລ້ວ ຫຼື ກຳລັງພິຈາລະນານຳໃຊ້. ສຳລັບຜູ້ທີ່ປະສົບກັບສິ່ງທ້າທາຍທີ່ວ່າ "Agent ເຮັດວຽກໄດ້ແຕ່ບໍ່ໝັ້ນຄົງ" ບົດຄວາມນີ້ຈະນຳສະເໜີວິທີການທີ່ເປັນຮູບປະທຳ ທີ່ສາມາດນຳໄປໃຊ້ໄດ້ທັນທີໃນມື້ອື່ນ.

ແທນທີ່ຈະຂຽນ Prompt ໃໝ່ແລ້ວອ້ອນວອນໃຫ້ມັນເຮັດວຽກ, ໃຫ້ສ້າງກົນໄກທີ່ປ້ອງກັນບໍ່ໃຫ້ຄວາມຜິດພາດດຽວກັນເກີດຂຶ້ນຊ້ຳໄດ້ຢ່າງເປັນລະບົບ——ນັ້ນຄືແກນຫຼັກຂອງ Harness Engineering.

ຖ້າຈະຢືມສຳນວນຂອງ OpenAI ມາໃຊ້ ກໍຄື ທ່າທີ "ບໍ່ແມ່ນການພະຍາຍາມໃຫ້ໜັກຂຶ້ນ (try harder), ແຕ່ແມ່ນການເພີ່ມຄວາມສາມາດທີ່ຍັງຂາດຢູ່". ເມື່ອ Output ຂອງ Agent ບໍ່ເປັນໄປຕາມທີ່ຄາດຫວັງ, ການໄປເພີ່ມຄຳອະທິບາຍໃສ່ Prompt ແມ່ນພຽງແຕ່ການແກ້ໄຂທີ່ປາຍເຫດເທົ່ານັ້ນ. Harness Engineering ມຸ່ງໝາຍທີ່ຈະປ່ຽນແປງຝ່າຍສະພາບແວດລ້ອມໃຫ້ເຖິງລະດັບທີ່ຄວາມລົ້ມເຫຼວນັ້ນບໍ່ສາມາດເກີດຂຶ້ນຊ້ຳໄດ້ໃນທາງຮູບປະທຳ.

ການວິສະວະກຳ Prompt ແມ່ນການປັບປຸງ "ສິ່ງທີ່ຕ້ອງການສື່ສານ" ໃຫ້ດີທີ່ສຸດ. ໂດຍການປັບໂຄງສ້າງຂໍ້ຄວາມນຳເຂົ້າ, ຄວາມຊັດເຈນຂອງຄຳສັ່ງ, ແລະ ການຍົກຕົວຢ່າງແບບ few-shot, ຈະຊ່ວຍເພີ່ມຄຸນນະພາບຂອງຜົນລັບທີ່ໄດ້ຈາກໂມເດລ. ໃນທາງກົງກັນຂ້າມ, ການວິສະວະກຳ Harness ແມ່ນການອອກແບບ "ສະພາບແວດລ້ອມທີ່ Agent ເຮັດວຽກຢູ່ນັ້ນເອງ". ນີ້ແມ່ນວິທີການທີ່ຄອບຄຸມທັງໝົດ ລວມທັງເອກະສານ, ເຄື່ອງມື, Linter, ການທົດສອບ, ແລະ ຂະບວນການ ຫຼື Pipeline ຂອງ CI/CD ໂດຍທີ່ Prompt ເປັນພຽງສ່ວນໜຶ່ງຂອງອົງປະກອບທັງໝົດນັ້ນ.

ທັງສອງຢ່າງບໍ່ໄດ້ຂັດແຍ່ງກັນ ແຕ່ເສີມຊຶ່ງກັນແລະກັນ. Prompt ທີ່ດີແມ່ນສ່ວນໜຶ່ງຂອງ Harness ທີ່ດີ, ແຕ່ຍັງມີຄວາມລົ້ມເຫຼວທີ່ Prompt ຢ່າງດຽວບໍ່ສາມາດປ້ອງກັນໄດ້. ຕົວຢ່າງເຊັ່ນ: ກົດລະບຽບທີ່ວ່າ "ຫ້າມ Execute DROP TABLE ກັບ DB ໃນລະບົບ Production" ນັ້ນ, ການຂຽນໄວ້ໃນ Prompt ຍັງໜ້ອຍກວ່າການໃຊ້ pre-commit hook ເພື່ອ Block ໂດຍອັດຕະໂນມັດ ຊຶ່ງໜ້າເຊື່ອຖືກວ່າຫຼາຍ.

ການວິສະວະກຳດ້ານ Context (Context Engineering) ແມ່ນຂົງເຂດດ້ານວິຊາການທີ່ເນັ້ນໃສ່ການປັບປຸງ Context (ຂໍ້ມູນອ້າງອີງ, ຄຳສັ່ງ, ແລະ ຄຳນິຍາມເຄື່ອງມືຕ່າງໆ) ທີ່ສົ່ງຂໍ້ມູນຕໍ່ໃຫ້ Model ໃຫ້ມີປະສິດທິພາບສູງສຸດ. Tobi Lutke, CEO ຂອງ Shopify ໄດ້ອະທິບາຍວ່ານີ້ຄື "ສິລະປະຂອງການຈັດຮຽງ Context ທັງໝົດ ເພື່ອໃຫ້ LLM ສາມາດແກ້ໄຂວຽກງານໄດ້". ການວິສະວະກຳດ້ານ Harness (Harness Engineering) ນັ້ນຄອບຄຸມຫຼັກການດັ່ງກ່າວ ແລະ ຍັງຂະຫຍາຍຂອບເຂດການອອກແບບໄປເຖິງສ່ວນທີ່ຢູ່ນອກ Context ອີກດ້ວຍ ໄດ້ແກ່: ການກຳນົດຂໍ້ຈຳກັດດ້ວຍ Linter, ການກວດສອບດ້ວຍ Test, ແລະ ການຄວບຄຸມຄຸນນະພາບດ້ວຍ CI/CD. ຖ້າການວິສະວະກຳດ້ານ Context ຄືການກຳນົດວ່າ "Agent ຈະເຫັນຫຍັງ", ການວິສະວະກຳດ້ານ Harness ກໍຄືການກຳນົດໃນລະດັບ Environment ວ່າ "Agent ສາມາດເຮັດຫຍັງໄດ້ ແລະ ເຮັດຫຍັງບໍ່ໄດ້".

ສິ່ງທີ່ຄວນລະວັງຄື Context Window ທີ່ໃຫຍ່ກວ່າ ບໍ່ໄດ້ໝາຍຄວາມວ່າປະສິດທິພາບຈະດີກວ່າສະເໝີໄປ. ຜົນການຄົ້ນຄວ້າຂອງ Chroma ຢືນຢັນວ່າ ເມື່ອ Context ຍາວຂຶ້ນ ປະສິດທິພາບຂອງ Model ມີແນວໂນ້ມຫຼຸດລົງ. ການສະສົມຄຳນິຍາມເຄື່ອງມືແລະຄຳສັ່ງຕ່າງໆ ກາຍເປັນ Noise ທີ່ເຮັດໃຫ້ Agent ຕົກຢູ່ໃນສະພາວະ "ຮູ້ທຸກຢ່າງ ແຕ່ເຮັດຫຍັງໄດ້ດີບໍ່ໄດ້ເລີຍ" ຊຶ່ງເອີ້ນວ່າ Dumb Zone. ໃນການອອກແບບ Harness ນັ້ນ ໃຫ້ຄວາມສຳຄັນກັບໂຄງສ້າງຂອງ Context ຫຼາຍກວ່າປະລິມານ, ໂດຍ Progressive Disclosure ທີ່ເປີດເຜີຍຂໍ້ມູນທີ່ຈຳເປັນຕາມຄວາມຕ້ອງການ ຖືວ່າເປັນວິທີທີ່ມີປະສິດທິຜົນ.

ຍິ່ງຄວາມສາມາດຂອງ AI Agent ສູງຂຶ້ນເທົ່າໃດ, ຄວາມສ່ຽງທີ່ "ອາດເກີດຄວາມຜິດພາດເປັນບາງຄັ້ງ" ກໍ່ຍິ່ງເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ. ການພັດທະນາຄວາມສາມາດ ແລະ ກົນໄກການຄວບຄຸມຈຳເປັນຕ້ອງໄດ້ວິວັດທະນາໄປພ້ອມກັນ.

ການສາທິດຂອງ AI Agent ນັ້ນໜ້າປະທັບໃຈ. ເມື່ອເຫັນຂະບວນການ ຫຼື Pipeline ທີ່ຂຽນໂຄດ, ລັນການທົດສອບ, ແລະສ້າງ PR ຕໍ່ເນື່ອງກັນ, ກໍຢາກນຳໃຊ້ທັນທີ. ແຕ່ເມື່ອເລີ່ມໃຊ້ງານຈິງໃນທີມ, 8 ໃນ 10 ຄັ້ງຈະເຮັດວຽກໄດ້ຕາມທີ່ຄາດຫວັງ, ແຕ່ 2 ຄັ້ງທີ່ເຫຼືອອາດລຶບໄຟລ໌ທີ່ບໍ່ຄາດຄິດ ຫຼື ເຮັດການປ່ຽນແປງທີ່ບໍ່ສົນໃຈ Architecture ທີ່ມີຢູ່ເດີມ.

ສະພາບ "ສຳເລັດ 80% · ທຳລາຍ 20%" ນີ້ ແກ້ໄຂໄດ້ຍາກດ້ວຍການປັບປຸງ Prompt ເທົ່ານັ້ນ. ເຫດຜົນຄືຮູບແບບຄວາມລົ້ມເຫຼວຂອງ Agent ນັ້ນແຕກຕ່າງກັນໃນແຕ່ລະ Session, ແລະການລະບຸສິ່ງຫ້າມຢ່າງຄົບຖ້ວນໃນ Prompt ນັ້ນບໍ່ແມ່ນເລື່ອງທີ່ເປັນໄປໄດ້ໃນທາງປະຕິບັດ.

ຈາກປະສົບການພັດທະນາ Agent ຂອງຕົນເອງ, Hashimoto ໄດ້ເຜີຍແຜ່ຫຼັກການທີ່ວ່າ "ສ້າງກົນໄກທຸກຄັ້ງທີ່ເກີດຄວາມຜິດພາດ". ໃນຊ່ວງເວລາດຽວກັນເກືອບ, ທີມ Engineering ຂອງ OpenAI ກໍໄດ້ເປີດຕົວ ຫຼື Launch ຄວາມຮູ້ທີ່ໄດ້ຮັບຈາກການນຳໃຊ້ Agent ພາຍໃນອົງກອນ. ເຫດຜົນທີ່ທັງສອງຝ່າຍໄດ້ຂໍ້ສະຫຼຸບດຽວກັນຢ່າງເປັນເອກະລາດ ກໍຍ້ອນວ່າການນຳ Agent ໄປໃຊ້ງານຈິງໄດ້ຜ່ານຈຸດ Threshold ໜຶ່ງ ແລະ "ການສ້າງຄວາມໝັ້ນຄົງດ້ານຄຸນນະພາບ" ໄດ້ກາຍເປັນ Bottleneck ຮ່ວມກັນ. ການທີ່ Martin Fowler ໄດ້ກ່າວເຖິງເລື່ອງນີ້ ຈຶ່ງເຮັດໃຫ້ຊຸມຊົນ Software Engineering ທັງໝົດຮັບຮູ້ຢ່າງກວ້າງຂວາງ.

ອົງປະກອບຂອງ Harness Engineering ມີການຈັດໝວດໝູ່ທີ່ແຕກຕ່າງກັນໄປຕາມຜູ້ຊ່ຽວຊານແຕ່ລະຄົນ, ແຕ່ໂດຍທົ່ວໄປສາມາດຈັດລຽງໄດ້ເປັນ 3 ຊັ້ນຫຼັກ.

OpenAI ອະທິບາຍໂດຍໃຊ້ 4 ແກນຫຼັກ ຄື Context / Constraints / Feedback / Cleanup, ໃນຂະນະທີ່ຜູ້ປະຕິບັດງານຄົນອື່ນໆໃຊ້ແກນ Tools / Docs / Feedback loops ເປັນຕົ້ນ, ເຮັດໃຫ້ Framework ຍັງບໍ່ທັນເປັນມາດຕະຖານ ຫຼື Specification ດຽວກັນ. ໃນທີ່ນີ້, ຈະຂໍອະທິບາຍໂດຍຈັດລຽງເປັນ 3 ຊັ້ນທີ່ງ່າຍຕໍ່ການນຳໃຊ້ໃນພາກປະຕິບັດ ໄດ້ແກ່ ເອກະສານ (Documents), ເຄື່ອງມື (Tools), ແລະ ຂໍ້ຈຳກັດ (Constraints).

ໃນເອກະສານທີ່ Agent ອ້າງອີງ, ໃຫ້ລະບຸ Invariants ຂອງ Repository ແລະ ກົດລະບຽບການຂຽນໂຄດ. OpenAI ໃຊ້ AGENTS.md, ສ່ວນ Claude Code ໃຊ້ CLAUDE.md ເພື່ອທຳໜ້າທີ່ນີ້.

ຢ່າງໃດກໍ່ຕາມ, ດັ່ງທີ່ Martin Fowler ໄດ້ຊີ້ໃຫ້ເຫັນວ່າ "ການ Maintain Markdown ຈຳນວນຫຼວງຫຼາຍ" ບໍ່ແມ່ນເປົ້າໝາຍ. ໃນການປະຕິບັດຂອງ OpenAI, ໄຟລ໌ Index ປະມານ 100 ແຖວ ແລະ ເອກະສານລາຍລະອຽດທີ່ມີໂຄງສ້າງ (ເອກະສານການອອກແບບ, ເອກະສານ Specification, ແຜນການດຳເນີນງານ) ຖືກແຍກອອກຈາກກັນ. ສິ່ງທີ່ສຳຄັນຄືການສ້າງໂຄງສ້າງທີ່ຊ່ວຍໃຫ້ Agent ເຂົ້າເຖິງຂໍ້ມູນທີ່ຕ້ອງການໄດ້ດ້ວຍເສັ້ນທາງສັ້ນທີ່ສຸດ.

Ryan Lopopolo, Engineer ຂອງ OpenAI, ໄດ້ນຳສະເໜີແນວຄິດທີ່ເອີ້ນວ່າ "Taste Invariants (Invariants ດ້ານຄວາມຮູ້ສຶກ)". ແນວຄິດນີ້ຄືເມື່ອຮູ້ສຶກ "ບໍ່ຄ່ອຍຊອບ" ໃນລະຫວ່າງ Code Review, ຫາກສາມາດອະທິບາຍເຫດຜົນນັ້ນເປັນຄຳເວົ້າໄດ້, ກໍ່ສາມາດຂຽນລົງເປັນ Rule ໄດ້. ຕົວຢ່າງ, ຄວາມບໍ່ພໍໃຈທີ່ວ່າ "ຟັງຊັນ Helper ສຳລັບ Concurrent Processing ຖືກກຳນົດຊ້ຳຊ້ອນໃນຫຼາຍບ່ອນ" ສາມາດປ່ຽນເປັນ Custom ESLint Rule ທີ່ "ຫ້າມກຳນົດຟັງຊັນດັ່ງກ່າວໃນສະຖານທີ່ອື່ນນອກຈາກບ່ອນກຳນົດທາງການ". ການປ່ຽນຄວາມມັກສ່ວນຕົວໃຫ້ກາຍເປັນຂໍ້ຈຳກັດທີ່ຊັດເຈນ ຊ່ວຍໃຫ້ Agent ມີ "ຄວາມຮູ້ສຶກດ້ານຄຸນນະພາບ".

ທາງບໍລິສັດຂອງພວກເຮົາກໍ່ໃຊ້ CLAUDE.md ເຊັ່ນກັນ, ແລະ ບໍ່ແມ່ນເລື່ອງຜິດປົກກະຕິທີ່ການເພີ່ມ Rule ພຽງ 1 ແຖວ ຈະຍົກລະດັບຄຸນນະພາບຂອງ Session ທັງໝົດຫຼັງຈາກນັ້ນ. ໃນທາງກົງກັນຂ້າມ, ພວກເຮົາກໍ່ເຄີຍມີປະສົບການທີ່ອັດຕາການປະຕິບັດຕາມ Rule ຂອງ Agent ເລີ່ມຫຼຸດລົງເມື່ອ Rule ເກີນ 500 ແຖວ, ຈຶ່ງຮູ້ສຶກໄດ້ວ່າ "ການອອກແບບໂຄງສ້າງ" ສຳຄັນກວ່າ "ປະລິມານທີ່ຂຽນ".

ແທນທີ່ຈະສັ່ງໃຫ້ Agent "ກວດສອບດ້ວຍຕາ", ໃຫ້ມອບເຄື່ອງມືທີ່ຊ່ວຍກວດສອບໂດຍອັດຕະໂນມັດແທນ. ຕົວຢ່າງໄດ້ແກ່: ການຖ່າຍ Screenshot, Test Runner, Linter, ແລະ MCP Server ເປັນຕົ້ນ.

MCP (Model Context Protocol) ແມ່ນມາດຕະຖານ ຫຼື Specification ໂປຣໂຕຄໍທີ່ໃຊ້ສຳລັບໃຫ້ Agent ເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນກັບເຄື່ອງມືພາຍນອກ ແລະ ແຫຼ່ງຂໍ້ມູນຕ່າງໆ, ແລະຈະກາຍເປັນເທັກໂນໂລຈີພື້ນຖານໃນການສ້າງຊັ້ນເຄື່ອງມື (Tool Layer) ຂອງ Harness. ຕົວຢ່າງເຊັ່ນ: ຫາກເຊື່ອມຕໍ່ Supabase MCP, Agent ຈະສາມາດກວດສອບ DB Schema ໂດຍກົງກ່ອນຂຽນ Query, ເຊິ່ງຊ່ວຍຫຼຸດຄວາມຜິດພາດປະເພດ "SELECT Column ທີ່ບໍ່ມີຢູ່" ໃນລະດັບໂຄງສ້າງໄດ້.

ໃນຊັ້ນເຄື່ອງມື (Tool Layer) ຍັງມີກົນໄກທີ່ເປັນປະໂຫຍດອີກ 3 ຢ່າງ. Hooks (ຟັງຊັນ Hook) ແມ່ນ Control Flow ທີ່ກຳນົດໄວ້ລ່ວງໜ້າ ສຳລັບແຊກເຂົ້າໃນ Lifecycle Event ຂອງ Agent (ເຊັ່ນ: ຫຼັງຈາກເອີ້ນໃຊ້ເຄື່ອງມື, ເມື່ອ Task ສຳເລັດ ເປັນຕົ້ນ) ໂດຍຈະບໍ່ສົ່ງຜົນລັບໃດໆ ເມື່ອສຳເລັດ (ເພື່ອບໍ່ໃຫ້ Context ສົກປົນ), ແລະຈະສະແດງ Error ຂຶ້ນມາສະເພາະເມື່ອລົ້ມເຫຼວເທົ່ານັ້ນ. Sub-Agents (Agent ລູກ) ແມ່ນການມອບໝາຍ Task ສະເພາະໃຫ້ Agent ລູກທີ່ຖືກແຍກອອກຕ່າງຫາກ, ເຮັດໜ້າທີ່ເປັນ "Context Firewall" ທີ່ປົກປ້ອງ Context ຂອງ Agent ແມ່. Back-Pressure (ກົນໄກ Back-Pressure) ແມ່ນກົນໄກທີ່ເສີມສ້າງຄວາມສາມາດໃນການກວດສອບຕົນເອງຂອງ Agent ໂດຍການກືນຜົນລັບໄວ້ເມື່ອ Test ຜ່ານ, ແລະສະແດງຜົນລັບສະເພາະເມື່ອລົ້ມເຫຼວ, ເຊິ່ງຊ່ວຍເພີ່ມປະສິດທິພາບຂອງ Context ໃຫ້ສູງສຸດ.

ການກວດສອບທິດທາງການເພິ່ງພາລະຫວ່າງ Layer ດ້ວຍ custom linter ແບບອັດຕະໂນມັດ ເພື່ອປ້ອງກັນບໍ່ໃຫ້ agent ສາມາດ commit ການປ່ຽນແປງທີ່ທຳລາຍໂຄງສ້າງໄດ້ຢ່າງເດັດຂາດ. ແນວທາງທີ່ອ່ານໄດ້ຈາກການປະຕິບັດຂອງ OpenAI ຄືການໃຫ້ຄວາມສຳຄັນກັບການລົງທຶນໃນ linter, test ແລະ pre-commit hook ທີ່ມີຄວາມແນ່ນອນ ແທນທີ່ຈະໃຊ້ຄຳສັ່ງ prompt ທີ່ບໍ່ແນ່ນອນ.

ແນວຄິດນີ້ສອດຄ່ອງກັບແນວຄິດຂອງ guardrail ເຊັ່ນດຽວກັນ. ໃນຂະນະທີ່ AI guardrail ໝາຍເຖິງ "ກົນໄກໃນການກວດສອບ ແລະ ຄວບຄຸມຜົນລັບຂອງ model" ແຕ່ຊັ້ນຂໍ້ຈຳກັດຂອງ harness ໝາຍເຖິງ "ກົນໄກໃນການກຳນົດຂອບເຂດການກະທຳຂອງ agent ລ່ວງໜ້າ". ການຈຳກັດການກະທຳລ່ວງໜ້ານັ້ນມີຕົ້ນທຶນຕ່ຳກວ່າການກວດສອບຜົນລັບຫຼັງຈາກນັ້ນ.

ການປ່ຽນແປງສະເພາະ Harness ໂດຍບໍ່ແຕະຕ້ອງ Model ຈະໃຫ້ຜົນດີພຽງໃດ? ຜົນການທົດສອບຂອງ LangChain ໃນ Terminal Bench 2.0 ນັ້ນໜ້າສົນໃຈຫຼາຍ. ໂດຍໃຊ້ Model ດຽວກັນ, ການປັບປຸງສະເພາະໃນຊັ້ນ Harness ເທົ່ານັ້ນ ໄດ້ແກ່: Loop Detection Middleware (ເມື່ອການແກ້ໄຂໄຟລ໌ດຽວກັນເກີນ N ຄັ້ງ ລະບົບຈະກະຕຸ້ນໃຫ້ທົບທວນວິທີການ), Pre-completion Checklist Middleware (ບັງຄັບໃຫ້ຜ່ານການກວດສອບກ່ອນທີ່ Agent ຈະສິ້ນສຸດການທຳງານ), ແລະ ການສະຫຼັບລະດັບຄວາມເຂັ້ມຂຸ້ນຂອງການໃຊ້ເຫດຜົນ (ໃຊ້ຕົ້ນທຶນການໃຊ້ເຫດຜົນສູງໃນຂັ້ນຕອນການວາງແຜນ, ລະດັບກາງໃນຂັ້ນຕອນການ Implement, ແລະ ສູງອີກຄັ້ງໃນຂັ້ນຕອນການກວດສອບ) — ສົ່ງຜົນໃຫ້ຄະແນນເພີ່ມຂຶ້ນຈາກ 52.8% ໄປເປັນ 66.5%. ໂດຍບໍ່ໄດ້ແຕະຕ້ອງ Model ເລີຍແມ່ນແຕ່ໜ້ອຍດຽວ.

Anthropic ກໍ່ໄດ້ສະເໜີອີກແນວທາງໜຶ່ງ. ໃນຮູບແບບ Generator-Evaluator Pattern ນັ້ນ, Agent ທີ່ຮັບຜິດຊອບການ Implement ແລະ Agent ທີ່ຮັບຜິດຊອບການປະເມີນຄຸນນະພາບຈະຖືກແຍກອອກຈາກກັນ. ໂຄງສ້າງນີ້ໄດ້ຮັບແຮງບັນດານໃຈຈາກ GAN (Generative Adversarial Network) ເນື່ອງຈາກເມື່ອ Agent ປະເມີນຜົນຜະລິດຂອງຕົນເອງ ມັກຈະເກີດ Bias ທີ່ "ຍ້ອງຍໍຜົນງານທີ່ທຳມະດາສາມັນຢ່າງໝັ້ນໃຈ", ດັ່ງນັ້ນການແຍກການປະເມີນໃຫ້ເປັນອິດສະຫຼະຈຶ່ງຊ່ວຍຮັບປະກັນຄວາມເປັນກາງໄດ້. ກ່ອນການ Implement, ລະບົບຈະກຳນົດ Sprint Contract (ເງື່ອນໄຂການຮັບຮອງທີ່ຊັດເຈນ) ໄວ້ລ່ວງໜ້າ, ແລະ Evaluation Agent ຈະໃຊ້ເງື່ອນໄຂດັ່ງກ່າວເປັນບ່ອນອ້າງອີງໃນການໃຫ້ຄະແນນ.

ການວິສະວະກຳ Harness ບໍ່ຈຳເປັນຕ້ອງເລີ່ມຕົ້ນຈາກການສ້າງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂະໜາດໃຫຍ່. ສາມາດຄ່ອຍໆສ້າງສົມທົບຂຶ້ນທີລະກ້າວ ໂດຍເລີ່ມຈາກການແກ້ໄຂຂໍ້ຜິດພາດທີລະອັນ.

ທຸກຄັ້ງທີ່ Agent ລົ້ມເຫລວ, ໃຫ້ບັນທຶກໄວ້ 1 ແຖວວ່າເກີດຫຍັງຂຶ້ນ, ເປັນຫຍັງຈຶ່ງເກີດຂຶ້ນ, ແລະ ຈະປ້ອງກັນໄດ້ແນວໃດ. ຮູບແບບບໍ່ສຳຄັນ — ຈະເປັນ GitHub Issue, Notion, ຫຼື ໄຟລ໌ຂໍ້ຄວາມກໍ່ໄດ້. ສິ່ງສຳຄັນຄືການມີເກນຕັດສິນໃຈວ່າ "ຖ້າສັງເກດເຫັນຄວາມຜິດພາດດຽວກັນ 2 ຄັ້ງ, ນັ້ນຄືບັນຫາທີ່ຕ້ອງແກ້ໄຂດ້ວຍລະບົບ".

ເລືອກຄວາມລົ້ມເຫຼວທີ່ເກີດຂຶ້ນເລື້ອຍທີ່ສຸດ 1 ລາຍການຈາກ error log ແລ້ວເພີ່ມເຂົ້າເປັນກົດລະບຽບໃນ CLAUDE.md (ຫຼື AGENTS.md):

ພຽງແຕ່ 1 ແຖວນີ້ ຈະຊ່ວຍຫຼຸດຄວາມເປັນໄປໄດ້ທີ່ agent ຈະເຮັດຜິດພາດດຽວກັນຊ້ຳໃນທຸກ session ຕໍ່ໄປໄດ້ຢ່າງຫຼວງຫຼາຍ. ການພະຍາຍາມອອກແບບລະບົບເອກະສານທີ່ສົມບູນແບບລ່ວງໜ້ານັ້ນ ສູ້ການສະສົມແບບ "1 ຄວາມຜິດພາດ 1 ກົດລະບຽບ" ບໍ່ໄດ້ ເພາະວິທີຫຼັງໃຫ້ຜົນໃນທາງປະຕິບັດສູງກວ່າ.

ກົດລະບຽບທີ່ຂຽນໄວ້ໃນເອກະສານ ທີ່ສາມາດກວດສອບໄດ້ດ້ວຍລະບົບອັດຕະໂນມັດ ໃຫ້ຍ້າຍໄປໃຊ້ pre-commit hook ຫຼື custom linter ແທນ. ກົດລະບຽບໃນເອກະສານແມ່ນ "ແນວທາງທີ່ຢາກໃຫ້ປະຕິບັດຕາມ" ແຕ່ linter ຄື "ກຳແພງທີ່ສະກັດການລະເມີດໄດ້ຢ່າງເປັນຮູບປະທຳ". ນີ້ແມ່ນແນວຄິດດຽວກັນກັບ "Shift Left" ໃນບໍລິບົດຂອງ DevOps ນັ້ນຄືການຍ້າຍຈຸດກວດພົບບັນຫາໄປສູ່ຂັ້ນຕອນທີ່ໄວທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້.

ເມື່ອ Agent ແຜ່ຫຼາຍຂຶ້ນ, ວຽກງານຂອງວິສະວະກອນກຳລັງປ່ຽນທິດທາງຈາກ "ການຂຽນໂຄດ" ໄປສູ່ "ການຈັດສະພາບແວດລ້ອມທີ່ເໝາະສົມໃຫ້ Agent ສາມາດເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ".

ຈາກການປະຕິບັດຂອງ OpenAI ສາມາດອ່ານທິດທາງໄດ້ວ່າ ວຽກງານຂອງວິສະວະກອນກຳລັງຍ້າຍຈຸດສຳຄັນໄປສູ່ການດູແລໃຫ້ໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂອງລະບົບ (CI/CD · Telemetry) ເຮັດວຽກໄດ້ຢ່າງໝັ້ນຄົງ, ການວາງໂຄງຮ່າງ Repository ແລະ ເອກະສານ, ລວມທັງການຂະຫຍາຍກຳລັງຄົນຜ່ານ AI. ອາດເວົ້າໄດ້ວ່ານີ້ຄືການປ່ຽນຜ່ານຈາກຍຸກທີ່ວັດຜົນຜະລິດດ້ວຍຈຳນວນແຖວໂຄດ ໄປສູ່ຍຸກທີ່ວັດດ້ວຍຄຸນນະພາບຂອງ Output ທີ່ Agent ສ້າງຂຶ້ນ.

Birgitta Bockeler ຜູ້ຮ່ວມຂຽນກັບ Martin Fowler ໄດ້ຈັດລະບຽບຮູບແບບການພົວພັນລະຫວ່າງມະນຸດກັບ Agent ອອກເປັນ 3 ຮູບແບບ. Outside the Loop (Vibe Coding) ແມ່ນຮູບແບບທີ່ລະບຸພຽງຜົນລັບແລ້ວມອບໃຫ້ Agent ຈັດການທັງໝົດ ຊຶ່ງມີຄວາມສ່ຽງທີ່ວິທີແກ້ໄຂທີ່ບໍ່ມີປະສິດທິພາບຈະສະສົມຕໍ່ກັນ. In the Loop ແມ່ນຮູບແບບທີ່ມະນຸດກວດທານ Output ທຸກຂັ້ນຕອນ ແຕ່ກໍ່ເກີດຄໍຄວດທີ່ການກວດທານຂອງມະນຸດຕາມບໍ່ທັນຄວາມໄວໃນການສ້າງຂອງ Agent. ຮູບແບບທີ່ແນະນຳຄື On the Loop — ຮູບແບບທີ່ສຸມໃສ່ການປັບປຸງ Harness ແທນທີ່ຈະສຸມໃສ່ Output ໂດຍກົງ. ເມື່ອຮູ້ສຶກບໍ່ພໍໃຈ ແທນທີ່ຈະແກ້ໄຂຜົນລັບໂດຍກົງ ໃຫ້ດັດແກ້ Harness ເພື່ອຍົກລະດັບ Output ທັງໝົດໃນຄັ້ງຕໍ່ໄປ. ການຮັກສາວິໄນນີ້ໄດ້ຫຼືບໍ່ ຈະເປັນຕົວກຳນົດວ່າ Harness Engineering ຈະຕິດຕັ້ງໄດ້ໝັ້ນຄົງຫຼືບໍ່.

ສິ່ງນີ້ສອດຄ່ອງກັບແນວຄິດ HITL (Human-in-the-Loop) ດ້ວຍ. ແທນທີ່ມະນຸດຈະດຳເນີນທຸກຂັ້ນຕອນດ້ວຍຕົນເອງ ກໍ່ຫັນໄປສູ່ບົດບາດການກຳກັບ, ກວດສອບ ແລະ ອະນຸມັດວຽກງານຂອງ Agent ແທນ. Harness Engineering ຄືການລົງທຶນເພື່ອຫຼຸດຕົ້ນທຶນໃນການກຳກັບດູແລນີ້.

ຖ້າປ່ອຍທິ້ງໄວ້ ຄຸນນະພາບຂອງຜົນງານທີ່ AI ສ້າງຂຶ້ນຈະຄ່ອຍໆເສື່ອມລົງເລື້ອຍໆ. OpenAI ແກ້ໄຂບັນຫານີ້ດ້ວຍການກຳນົດ Golden Principles (ຫຼັກການທີ່ຕ້ອງຍຶດຖື), ການໃຫ້ຄະແນນຢ່າງສະໝ່ຳສະເໝີ, ແລະ ການສ້າງ PR ສຳລັບການແກ້ໄຂອັດຕະໂນມັດ. ສິ່ງທີ່ໜ້າສົນໃຈຄືການທີ່ OpenAI ນຳ Harness Engineering ມາໃຊ້ ສົ່ງຜົນໃຫ້ຕ້ອງເພີ່ມຈຳນວນການປະຊຸມ Daily Standup ຂຶ້ນ. ຍິ່ງ Agent ສ້າງຜົນງານໄດ້ໄວຂຶ້ນເທົ່າໃດ, Architectural Pattern ກໍ່ອາດປ່ຽນແປງໄດ້ຫຼາຍຂຶ້ນລະຫວ່າງການ Check-in ແຕ່ລະຄັ້ງ, ດັ່ງນັ້ນຈຶ່ງໄດ້ກຳນົດໃຫ້ມີການເຊື່ອມຕໍ່ ຫຼື ຊິງຄ໌ຂໍ້ມູນລາຍວັນ 30 ນາທີ ເພື່ອກວດຈັບ Direction Drift ໄດ້ຕັ້ງແຕ່ຕົ້ນ. ດ້ວຍລະບົບນີ້ ໄດ້ດຳເນີນການ PR ກວ່າ 1,500 ລາຍການໃນໄລຍະ 5 ເດືອນ ແລະ ລາຍງານວ່າຜະລິດຕະພາບຕໍ່ຄົນເພີ່ມຂຶ້ນຈາກ 1/4 ຂອງ Engineer ໃນຕອນຕົ້ນ ໄປເຖິງ 3 ຫາ 10 ເທົ່າ.

Harness ບໍ່ແມ່ນສ້າງຄັ້ງດຽວແລ້ວຈົບ, ແຕ່ຄວນອອກແບບໂດຍຕັ້ງໃຈໄວ້ວ່າຈະຕ້ອງສ້າງໃໝ່ທຸກຄັ້ງທີ່ຄວາມສາມາດຂອງ Agent ສູງຂຶ້ນ. ຈາກການກວດສອບຂອງ Anthropic ກໍ່ຢືນຢັນວ່າ ການ Upgrade Model (Sonnet → Opus) ເຮັດໃຫ້ Context Reset ທີ່ເຄີຍຈຳເປັນກ່ອນໜ້ານີ້ກາຍເປັນສິ່ງທີ່ບໍ່ຈຳເປັນອີກຕໍ່ໄປ, ສະແດງໃຫ້ເຫັນວ່າ ສົມມຸດຕິຖານຂອງ Harness ຈະປ່ຽນແປງໄປຕາມການພັດທະນາຂອງ Model.

ການນຳໃຊ້ Harness Engineering ເອງກໍ່ມີຈຸດອ່ອນທີ່ຕ້ອງລະວັງ. ການມີເອກະສານຫຼາຍເກີນໄປ ແລະ ການກຳນົດຂໍ້ຈຳກັດຫຼາຍເກີນໄປ ແມ່ນຮູບແບບຄວາມລົ້ມເຫຼວທີ່ພົບເຫັນຢູ່ເລື້ອຍໆ.

ເມື່ອ CLAUDE.md ມີຫຼາຍກວ່າ 1,000 ແຖວ, ມັນຈະກິນພື້ນທີ່ Context Window ຂອງ Agent ແລະ ກົງກັນຂ້າມ ກົດລະບຽບສຳຄັນກໍຈະຖືກຝັງໝົກໄປ. ໃນການປະຕິບັດຂອງ OpenAI ກໍໄດ້ແນະນຳໂຄງສ້າງທີ່ຄວນຈຳກັດ Index ໄວ້ປະມານ 100 ແຖວ ແລະ ແຍກລາຍລະອຽດໄປໄວ້ໃນໄຟລ໌ອື່ນ. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກຂອງການອອກແບບ ບໍ່ແມ່ນ "ຂຽນທຸກຢ່າງໄວ້ໃນໄຟລ໌ດຽວ" ແຕ່ຄືການ "ສ້າງໂຄງສ້າງທີ່ສາມາດເຂົ້າເຖິງຂໍ້ມູນທີ່ຕ້ອງການໄດ້ໄວທີ່ສຸດ".

ການເພີ່ມຂໍ້ຫ້າມໂດຍບໍ່ມີຂອບເຂດຈະເຮັດໃຫ້ Agent ບໍ່ສາມາດດຳເນີນການທີ່ປອດໄພໄດ້ເລີຍ. ຄວນຈຳກັດຂໍ້ບັງຄັບໄວ້ສະເພາະ "ຄວາມຜິດພາດທີ່ເກີດຂຶ້ນເລື້ອຍໆ ແລະ ມີຜົນກະທົບຫຼາຍ" ເທົ່ານັ້ນ, ສ່ວນທີ່ເຫຼືອໃຫ້ຄົງໄວ້ເປັນຄຳແນະນຳໃນເອກະສານ. ການແຍກແຍະລະຫວ່າງຂໍ້ບັງຄັບ ແລະ ຄຳແນະນຳແນວທາງແມ່ນສິ່ງສຳຄັນ, ໂດຍບໍ່ຈຳເປັນຕ້ອງເຮັດໃຫ້ທຸກຢ່າງເປັນ Hard Block.

ການວິສະວະກຳ Prompt ແມ່ນເຕັກນິກໃນການປັບປຸງ "ຂໍ້ມູນນຳເຂົ້າໃຫ້ກັບໂມເດວ" ໃຫ້ມີປະສິດທິພາບສູງສຸດ, ໃນຂະນະທີ່ການວິສະວະກຳ Harness ແມ່ນວິທີປະຕິບັດໃນການອອກແບບ "ສະພາບແວດລ້ອມທັງໝົດທີ່ Agent ເຮັດວຽກຢູ່". Prompt ແມ່ນສ່ວນໜຶ່ງຂອງ Harness, ແລະ ທັງສອງບໍ່ໄດ້ຂັດແຍ່ງກັນ ແຕ່ມີຄວາມສຳພັນເສີມເຕີມເຊິ່ງກັນແລະກັນ.

ໃນທາງກົງກັນຂ້າມ, ທີມຂະໜາດນ້ອຍກໍ່ເລີ່ມຕົ້ນໄດ້ງ່າຍກວ່າ. ສາມາດເລີ່ມຕົ້ນດ້ວຍການເພີ່ມກົດລະບຽບ 1 ບັນທັດໃນ CLAUDE.md ໂດຍບໍ່ຈຳເປັນຕ້ອງມີການຈັດຕັ້ງໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ຂະໜາດໃຫຍ່ແຕ່ຢ່າງໃດ. ທຸກຄັ້ງທີ່ເກີດຄວາມຜິດພາດ, ຄ່ອຍໆເພີ່ມກົນໄກທີລະອັນ, ແລ້ວ harness ກໍ່ຈະຄ່ອຍໆເຕີບໂຕຂຶ້ນເອງຕາມທຳມະຊາດ.

ເມື່ອຄວາມສາມາດຂອງ Agent ສູງຂຶ້ນ, ບາງສ່ວນຂອງ Harness ກໍອາດຈະບໍ່ຈຳເປັນອີກຕໍ່ໄປ. ແຕ່ຍິ່ງຄວາມສາມາດສູງຂຶ້ນ, ຂອບເຂດການກະທຳກໍຂະຫຍາຍກວ້າງຂຶ້ນຕາມ, ແລະ ຄວາມຜິດພາດປະເພດໃໝ່ໆ ກໍຈະເກີດຂຶ້ນ. ເນື້ອຫາຂອງ Harness ອາດປ່ຽນແປງໄປ, ແຕ່ເປັນເລື່ອງຍາກທີ່ຈະຄິດວ່າແນວຄິດດ້ານການອອກແບບທີ່ວ່າ "ປ້ອງກັນຄວາມຜິດພາດດ້ວຍກົນໄກ" ຈະກາຍເປັນສິ່ງທີ່ບໍ່ຈຳເປັນ.

ໃນການທົດສອບຂອງ Anthropic, ການສ້າງ Full Harness (Generator-Evaluator Pattern + Sprint Contract + ການປະເມີນຜົນທີ່ມີ Calibration) ໃຊ້ເວລາປະມານ 6 ຊົ່ວໂມງ ແລະ ມີຄ່າໃຊ້ຈ່າຍ 200 ໂດລາ, ໃນຂະນະທີ່ Agent ດຽວທີ່ບໍ່ມີ Harness ສາມາດສຳເລັດໄດ້ພາຍໃນ 20 ນາທີ ດ້ວຍຄ່າໃຊ້ຈ່າຍ 9 ໂດລາ. ຢ່າງໃດກໍ່ຕາມ, ຄຸນນະພາບຂອງຜົນໄດ້ຮັບມີຄວາມແຕກຕ່າງກັນຢ່າງຫຼວງຫຼາຍ. ການຕັດສິນໃຈດ້ານຄ່າໃຊ້ຈ່າຍຈະຂຶ້ນຢູ່ກັບຄວາມສຳຄັນຂອງ "ສິ່ງທີ່ຈະມອບໝາຍໃຫ້ Agent ດຳເນີນການ". Full Harness ບໍ່ຈຳເປັນສຳລັບ Script ທີ່ໃຊ້ຄັ້ງດຽວທິ້ງ, ແຕ່ສຳລັບການສ້າງ Code ສຳລັບ Production ຢ່າງຕໍ່ເນື່ອງນັ້ນ, ການລົງທຶນດັ່ງກ່າວຖືວ່າຄຸ້ມຄ່າ.

ການວິສະວະກຳ Harness ແມ່ນວິທີປະຕິບັດເພື່ອສ້າງຄວາມໝັ້ນຄົງໃຫ້ກັບຄຸນນະພາບຂອງ AI Agent ດ້ວຍ "ໂຄງສ້າງ" ແທນທີ່ຈະ "ອ້ອນວອນ". ໂດຍຄ່ອຍໆ ສ້າງຂຶ້ນເປັນຂັ້ນຕອນ ໄດ້ແກ່: ຖານຄວາມຮູ້ຈາກເອກະສານ, ການກວດສອບອັດຕະໂນມັດດ້ວຍເຄື່ອງມືຕ່າງໆ (ລວມທັງ Hooks, Sub-Agents ແລະ Back-Pressure), ແລະ ການຈຳກັດພຶດຕິກຳດ້ວຍຂໍ້ຈຳກັດດ້ານສະຖາປັດຕະຍະກຳ. ຈາກການກວດສອບຂອງ LangChain, ການປັບປຸງ Harness ພຽງຢ່າງດຽວສາມາດເພີ່ມຄະແນນຈາກ 52.8% ໄປເຖິງ 66.5% ໄດ້, ຊຶ່ງສະແດງໃຫ້ເຫັນວ່າ ການອອກແບບສະພາບແວດລ້ອມສາມາດປ່ຽນແປງຄຸນນະພາບໄດ້ຢ່າງຫຼວງຫຼາຍ ໂດຍບໍ່ຕ້ອງປ່ຽນ Model ເລີຍ.

ກ້າວທຳອິດນັ້ນນ້ອຍຫຼາຍ. ພຽງແຕ່ບັນທຶກຄວາມຜິດພາດຂອງ Agent ໜຶ່ງລາຍການ, ແລ້ວເພີ່ມກົດລະບຽບໜຶ່ງແຖວໃສ່ໃນ CLAUDE.md ກໍພໍ. ເລີ່ມຈາກຈຸດນັ້ນ, ແລ້ວຄ່ອຍໆ ປ່ຽນຄວາມລົ້ມເຫຼວທີ່ເກີດຂຶ້ນເລື້ອຍໆ ໃຫ້ເປັນລະບົບອັດຕະໂນມັດດ້ວຍ Linter ຫຼື Pre-commit Hook, ຄຸນນະພາບການດຳເນີນງານ Agent ຂອງທີມງານທັງໝົດກໍຈະດີຂຶ້ນຢ່າງຕໍ່ເນື່ອງ. ສິ່ງທີ່ສຳຄັນຄືການຮັກສາທ່າທີ "On the Loop" ທີ່ທ່ານ Fowler ແລະ ຄະນະແນະນຳ ນັ້ນຄື: ແທນທີ່ຈະແກ້ໄຂຜົນລັບໂດຍກົງ, ໃຫ້ປັບປຸງ Harness ເພື່ອຍົກລະດັບຜົນຜະລິດທັງໝົດທີ່ຈະຕາມມາໃນອະນາຄົດ.