Harness Engineering: วิธีสร้าง AI Agent ที่ทำงานได้จริง

คนส่วนใหญ่พยายามแก้ไข AI agent ในจุดที่ผิด

เมื่อ agent ทำงานผิดพลาด พวกเขาก็ไปแก้ prompt พอพลาดอีกก็เพิ่มคำสั่งเข้าไป เปลี่ยนโมเดล ขยาย context window หรือต่อเครื่องมือเพิ่ม

แล้วปัญหาเดิมก็วนกลับมาอีก

agent ลืมการตัดสินใจที่สำคัญ เลือกใช้เครื่องมือผิด จำไม่ได้ว่าเกิดอะไรขึ้นในสามขั้นตอนก่อนหน้า อ้างว่างานเสร็จแล้วโดยไม่ได้ตรวจผลลัพธ์ หรือลองทำซ้ำในสิ่งที่ล้มเหลวไปเรื่อยๆ จนงบหมด

ปัญหาไม่ได้อยู่ที่ตัวโมเดลเสมอไป

แต่อยู่ที่สภาพแวดล้อมรอบๆ มันต่างหาก

และสภาพแวดล้อมนั้นก็คือ harness

Harness Engineering คือการสร้างระบบล้อมรอบโมเดล เพื่อควบคุมว่ามันจะเห็นอะไรได้ ทำอะไรได้ จดจำอะไรได้ อะไรคือความสำเร็จ และจะเกิดอะไรขึ้นเมื่อมีข้อผิดพลาด

prompt ที่ดีขึ้นอาจช่วยปรับปรุงคำตอบได้แค่ครั้งเดียว

แต่ harness ที่ดีจะช่วยให้การทำงานทุกครั้งดีขึ้น

ติดตาม Substack ของผมเพื่ออ่านบทวิเคราะห์เชิงปฏิบัติเกี่ยวกับ AI agent, ระบบ automation และ production systems เพิ่มเติม:

substack.com/@lunarresearcher

1. โมเดลไม่ใช่ Agent

โมเดลสามารถให้เหตุผล สร้างเนื้อหา เปรียบเทียบ และเลือกได้

แต่นั่นไม่ได้ทำให้มันเป็น agent ที่ไว้ใจได้

agent จริงๆ ยังต้องค้นหา context ที่ถูกต้อง ใช้เครื่องมือ รักษา state เคารพสิทธิ์ ตรวจสอบงานของตัวเอง และกู้คืนระบบได้เมื่อสภาพแวดล้อมทำงานไม่เหมือนที่คาดไว้

โมเดลเป็นเพียงเครื่องยนต์ที่ใช้คิด

ส่วน harness คือทุกสิ่งที่เปลี่ยนความคิดนั้นให้กลายเป็นการลงมือทำจริง

1คำขอจากผู้ใช้ (USER REQUEST)
2      |
3      v
4+-----------------------------+
5|           HARNESS           |
6|                             |
7| contract      context       |
8| tools         state         |
9| policy        verification  |
10| traces        recovery      |
11+-----------------------------+
12      |
13      v
14    MODEL
15      |
16      v
17สภาพแวดล้อมจริง (REAL ENVIRONMENT)

เอาโมเดลเดียวกันไปใส่ในช่องแชท มันก็จะตอบคำถาม

แต่ถ้าเอาไปใส่ใน repository ที่มี terminal access, tests, เครื่องมือ browser, project memory, การควบคุมสิทธิ์ และ review loop มันจะทำงานจริงได้สำเร็จ

ตัวโมเดลไม่ได้เปลี่ยนไปเลย

แต่ harness ต่างหากที่เปลี่ยน

2. เปลี่ยนทุกคำขอให้เป็น Contract

ภาษาธรรมชาตินั้นยืดหยุ่น

แต่การทำงานแบบอัตโนมัติไม่ควรยืดหยุ่นตาม

คำขออย่างเช่น:

ปรับปรุง onboarding flow ให้ดีขึ้น

ถือว่าโอเคถ้ามีคนนั่งประกบอยู่ข้างๆ โมเดล

แต่ห่วยแตกมากถ้านำมาใช้เป็นคำสั่งในระบบ production

ก่อนที่ agent จะลงมือทำ ให้แปลงคำขอนั้นเป็น task contract ที่มีขอบเขตชัดเจน

1objective: ลดอัตราการหลุดออกจากระหว่าง onboarding
2
3inputs:
4  - product brief
5  - analytics data
6  - repository
7
8constraints:
9  - เก็บระบบ authentication ไว้เหมือนเดิม
10  - ห้ามเปลี่ยน database schema
11  - รักษาพฤติกรรมบนมือถือแบบปัจจุบันไว้
12
13deliverable:
14  - pull request ที่พร้อมให้รีวิว
15
16done_when:
17  - tests ผ่าน
18  - analytics event ทำงานถูกต้อง
19  - desktop flow ผ่านการรีวิว
20  - mobile flow ผ่านการรีวิว
21
22approval_required:
23  - production deployment

ส่วนที่สำคัญที่สุดคือ done_when

ถ้าไม่มีสิ่งนี้ agent อาจแก้ปัญหาเวอร์ชันที่ง่ายกว่านิดหน่อย แล้วบอกอย่างมั่นใจว่างานเสร็จแล้วก็ได้

แต่ถ้ามี การวัดผลความสำเร็จจะเป็นรูปธรรมทันที

agent ไม่ควรถามว่า:

ฉันควรทำอะไรต่อไปดี?

แต่ควรถามว่า:

การกระทำใดที่จะพาสภาพแวดล้อมปัจจุบันเข้าใกล้ผลลัพธ์ตาม contract มากที่สุด?

นั่นคือลูปการทำงานที่แข็งแกร่งกว่ามาก

3. ให้แผนที่กับ Agent ไม่ใช่ Context Window ขนาดยักษ์

ปฏิกิริยาทั่วไปเวลา agent ทำพลาดคือการยัด context ให้โมเดลมากขึ้น

เอกสารมากขึ้น

ประวัติการสนทนามากขึ้น

ไฟล์มากขึ้น

ผลลัพธ์จากเครื่องมือมากขึ้น

สุดท้าย agent ได้รับทุกอย่าง แต่เข้าใจน้อยลง

context ไม่ใช่พื้นที่เก็บข้อมูล

แต่มันคืองบความสนใจ (attention budget)

แทนที่จะโยนทั้งโปรเจกต์ลงไปในการรันทุกครั้ง ควรให้แผนที่เล็กๆ แก่ agent เพื่อบอกว่าข้อมูลที่มีประโยชน์อยู่ที่ไหน

1PROJECT MAP
2
3product rules     -> docs/product/
4architecture      -> docs/architecture.md
5frontend          -> apps/web/
6backend           -> services/api/
7tests             -> tests/
8commands          -> docs/commands.md
9security          -> docs/security.md

แล้วค่อยขยายเฉพาะตอนที่จำเป็นจริงๆ

1TASK
2  |
3  v
4PROJECT MAP
5  |
6  v
7RELEVANT SYSTEM
8  |
9  v
10EXACT FILES
11  |
12  v
13LOCAL INSTRUCTIONS

แหล่งข้อมูลต้นฉบับเรียกสิ่งนี้ว่า progressive disclosure: harness ควรโหลดข้อมูลเพิ่มเติมเพราะงานต้องการมัน ไม่ใช่แค่เพราะข้อมูลนั้นมีอยู่

เป้าหมายไม่ใช่การยัด context ให้มากที่สุด

แต่คือการดึงสัญญาณที่มีประโยชน์ออกมาให้ได้มากที่สุด

4. วาง Gateway กั้นระหว่างโมเดลกับเครื่องมือ

โมเดลที่มีเครื่องมือ 20 ตัว ไม่ได้เก่งขึ้น 20 เท่าโดยอัตโนมัติ

มันอาจจะมีวิธีพังเพิ่มขึ้นอีก 20 แบบต่างหาก

เครื่องมือทุกตัวควรมี contract ของตัวเอง

1TOOL: edit_file
2
3INPUTS
4path
5patch
6
7PRECONDITIONS
8path ต้องมีอยู่จริง
9path ต้องอยู่ใน workspace
10
11SUCCESS
12patch ถูกนำไปใช้แล้ว
13ส่ง diff กลับมา
14
15FAILURE
16error แบบมีโครงสร้าง
17ห้ามเขียนทับบางส่วน
18
19RISK
20ย้อนกลับได้

จากนั้นเส้นทางการทำงานจะกลายเป็น:

1MODEL PROPOSES
2      |
3      v
4GATEWAY VALIDATES
5      |
6      v
7POLICY AUTHORIZES
8      |
9      v
10TOOL EXECUTES
11      |
12      v
13HARNESS RECORDS RESULT

โมเดลเป็นคนตัดสินใจว่าจะทำอะไร

ส่วน harness เป็นคนตัดสินว่าการกระทำนั้นถูกต้อง อนุญาต และปลอดภัยหรือไม่

ความแตกต่างนี้สำคัญมากเมื่อเครื่องมือสามารถส่งข้อความ แก้ไขระบบ production ใช้เงิน หรือลบข้อมูลได้

tool gateway ที่ดียังช่วยเพิ่ม timeout, ตรวจสอบ arguments, จำกัด file path, จัดรูปแบบ error ให้เป็นมาตรฐาน และทำให้การ retry ปลอดภัยขึ้นด้วย

เครื่องมือที่ดีช่วยลดจำนวนสิ่งที่โมเดลต้องเดา

5. ย้าย Memory ออกไปจากการสนทนา

การสนทนาไม่ควรเป็นที่เก็บข้อมูลหลักของระบบ

agent ที่ทำงานนานๆ จะชนขีดจำกัด context, คราช, รีสตาร์ท หรือส่งงานต่อให้ session อื่นในที่สุด

ถ้าการตัดสินใจสำคัญทุกอย่างอยู่แค่ใน transcript ระบบงานจะเปราะบางมาก

ให้แยกเก็บ state ถาวรไว้ต่างหาก

1{
2  "task_id": "feature_042",
3  "status": "verifying",
4  "current_step": "mobile_check",
5
6  "completed": [
7    "implementation",
8    "unit_tests",
9    "desktop_check"
10  ],
11
12  "decisions": [
13    "reuse existing export endpoint",
14    "preserve current date format"
15  ],
16
17  "artifacts": [
18    "export.csv",
19    "desktop-after.png"
20  ],
21
22  "open_risks": [
23    "mobile toolbar may overflow"
24  ],
25
26  "next_action": "render mobile viewport"
27}

ระบบที่มีประโยชน์จะแบ่ง memory ออกเป็น 4 หมวด:

1FACTS
2ความรู้ที่คงที่
3
4DECISIONS
5สิ่งที่เลือกไปแล้วและเหตุผล
6
7STATE
8ตอนนี้การรันไปถึงไหนแล้ว
9
10LESSONS
11ความล้มเหลวที่ควรส่งผลต่อการรันครั้งถัดไป

agent session ถัดไปควรสืบทอด state ของงาน ไม่ใช่เรื่องย่อของการสนทนาก่อนหน้า

6. ใช้หลักฐานเป็นด่านสุดท้ายก่อนจบงาน

การที่ agent บอกว่า "เสร็จแล้ว" ไม่ได้แปลว่างานเสร็จจริง

มันก็เป็นแค่อีกหนึ่งผลลัพธ์จากโมเดล

harness ต้องการหลักฐานที่สังเกตได้

1CLAIM                     EVIDENCE
2
3"แก้บั๊กแล้ว"            test ที่เคยตกตอนนี้ผ่าน
4
5"หน้าเว็บใช้งานได้"              browser flow ทำงานจนจบ
6
7"ข้อมูลถูกต้อง"         ค่าตรงกับ source
8
9"migration ปลอดภัย"       dry run + rollback ผ่าน
10
11"งานเสร็จแล้ว"        ทุก acceptance check ผ่าน

ใช้ deterministic checks ก่อนเสมอ

1syntax
2  |
3  v
4types
5  |
6  v
7focused tests
8  |
9  v
10integration tests
11  |
12  v
13visual / semantic review
14  |
15  v
16human approval

อย่าไปถามโมเดลอีกตัวในเรื่องที่ compiler, test, schema หรือ database query พิสูจน์ได้แล้ว

ใช้โมเดลสำหรับการตัดสิน

ใช้ระบบ deterministic สำหรับข้อเท็จจริง

โมเดลสร้าง artifact ขึ้นมา

สภาพแวดล้อมสร้างหลักฐานเกี่ยวกับ artifact นั้น

ส่วน harness ตัดสินว่าหลักฐานนั้นเพียงพอหรือไม่

7. แยกคนสร้างออกจากคนตรวจสอบ

การรีวิวงานตัวเองยังมีอีกปัญหาหนึ่ง

agent ที่สร้างข้อผิดพลาด มักจะพกสมมติฐานชุดเดิมเข้ามาใช้ในการรีวิวด้วย

สถาปัตยกรรมที่แข็งแกร่งกว่าจะแยก worker กับ verifier ออกจากกัน

1BUILDER
2   |
3   v
4creates candidate
5   |
6   v
7VERIFIER
8   |
9   +-- checks contract
10   +-- searches for missing cases
11   +-- tests unsupported claims
12   +-- tries to break result
13   |
14   +------ PASS ------> ACCEPT
15   |
16   +------ FAIL ------> RETURN EVIDENCE

verifier ไม่ควรถามว่า:

อันนี้ดูดีไหม?

แต่ควรถามว่า:

อะไรที่จะทำให้สิ่งนี้ยอมรับไม่ได้?

นั่นจะเปลี่ยนการรีวิวจากการยืนยัน เป็นการพยายามหาข้อพิสูจน์หักล้าง

แหล่งข้อมูลต้นฉบับแนะนำอย่างชัดเจนว่าควรให้กระบวนการ verify มีเกณฑ์การปฏิเสธเป็นของตัวเอง และมีอิสระมากพอที่จะตั้งคำถามกับสมมติฐานที่สร้างผลลัพธ์แรกขึ้นมา

8. ย้าย Permissions ออกไปจากโมเดล

กฎบางอย่างไม่ควรพึ่งพาความจำของโมเดลเด็ดขาด

1ห้าม publish โดยไม่ได้รับอนุมัติ
2ห้ามเปิดเผย secrets
3ห้ามใช้งบเกินที่กำหนด
4ห้ามเขียนไฟล์นอก workspace
5ห้ามอ้างว่า tests ผ่านถ้ายังไม่ได้รัน

สิ่งเหล่านี้ไม่ใช่คำแนะนำใน prompt

แต่มันคือนโยบาย

ลำดับขั้นสิทธิ์แบบง่ายๆ:

1LOW RISK
2
3read
4search
5inspect
6
7-> automatic
8
9REVERSIBLE
10
11edit workspace
12run tests
13create draft
14
15-> automatic + trace
16
17EXTERNAL EFFECT
18
19send
20deploy
21purchase
22
23-> approval required
24
25IRREVERSIBLE / SENSITIVE
26
27delete data
28rotate credentials
29publish globally
30
31-> hard gate or prohibited

ผลกระทบยิ่งรุนแรง การควบคุมก็ต้องยิ่งเข้มงวด

โมเดลสามารถแนะนำการกระทำได้

แต่ harness เป็นผู้อนุมัติ

และเครื่องมือเป็นผู้ลงมือทำ

ความเป็นอิสระไม่ได้แปลว่าไร้การควบคุม

แต่มันคือเสรีภาพภายในขอบเขตที่ถูกบังคับใช้

9. เลิก Retry แบบหลับหูหลับตา

หนึ่งในนโยบายการกู้คืนที่แย่ที่สุดคือ:

มีอะไรผิดพลาด ลองใหม่สิ

ถ้าไม่มีอะไรเปลี่ยนไป ระบบก็แค่จ่ายเงินเพื่อสร้างความล้มเหลวเดิมซ้ำๆ

ควรจัดประเภทความล้มเหลวก่อนเสมอ

1TOOL TIMEOUT
2-> retry ด้วย backoff
3
4INVALID ARGUMENTS
5-> ซ่อม tool call
6
7MISSING CONTEXT
8-> ดึง source ที่หายไปมา
9
10FAILED TEST
11-> ตรวจสอบพฤติกรรมที่ทำให้ตก
12
13PERMISSION DENIED
14-> ขอการอนุมัติ
15
16CONFLICTING REQUIREMENTS
17-> escalate
18
19UNCHANGED REPEATED FAILURE
20-> หยุด

ลูปการทำงานของ agent ที่ดีควรหน้าตาแบบนี้:

1OBSERVE
2   |
3   v
4DECIDE
5   |
6   v
7ACT
8   |
9   v
10MEASURE
11   |
12   +---- ACCEPT
13   |
14   +---- REPAIR
15   |
16   +---- ESCALATE
17   |
18   +---- STOP

ทุกลูปควรมีขีดจำกัดจำนวนครั้ง เวลา งบประมาณ และขอบเขตการทำลายล้าง

agent ที่เชื่อถือได้ต้องรู้ว่าควรไปต่ออย่างไร

และต้องรู้ด้วยว่าเมื่อไหร่ที่ไม่คุ้มจะลองอีกแล้ว

10. เปลี่ยนคำสั่งที่ต้องพูดซ้ำให้เป็น Infrastructure

สมมติว่าใน prompt เขียนว่า:

รัน formatter ทุกครั้ง

กฎนี้จะแข็งแกร่งขึ้นมากถ้า formatter รันอัตโนมัติ

หรือสมมติว่าคำสั่งบอกว่า:

โค้ด UI ห้ามเข้าถึง database โดยตรง

สิ่งนี้จะแข็งแกร่งกว่าถ้าทำเป็น architecture test ที่ fail ทันทีเมื่อมีการละเมิดกฎ

ลำดับการพัฒนาจะเป็นแบบนี้:

1EXPLANATION
2      |
3      v
4CHECKLIST
5      |
6      v
7TEMPLATE
8      |
9      v
10AUTOMATED CHECK
11      |
12      v
13ENFORCED POLICY

prompt ควรอธิบายเรื่องการตัดสิน

ส่วน harness ควรบังคับใช้เงื่อนไขที่ต้องเป็นจริงเสมอ

ความผิดพลาดที่เกิดซ้ำๆ ทุกครั้งควรถูกเลื่อนลงมาตามบันไดนี้ทีละนิด

จนสุดท้ายโมเดลไม่ต้องจดจำบทเรียนนั้นอีกต่อไป

เพราะสภาพแวดล้อมจะจำไว้ให้มันเอง

11. บันทึกการรันทุกครั้ง

artifact สุดท้ายที่สมบูรณ์แบบอาจซ่อนเส้นทางการทำงานที่เลวร้ายไว้ก็ได้

บางที agent อาจไปดึงข้อมูลจาก source ผิด

บางทีมันอาจเพิกเฉยต่อคำสั่งที่ล้มเหลว

บางทีมันอาจสั่งการภายนอกซ้ำสองรอบ

บางทีมันอาจใช้งบไปสิบเท่าของที่คาดไว้

หรือบางทีมันอาจได้คำตอบที่ถูก ด้วยเหตุผลที่ผิด

จงบันทึกข้อมูลให้มากพอที่จะประกอบร่างเหตุการณ์ที่เกิดขึ้นใหม่ได้

109:14  สร้าง task contract แล้ว
209:15  โหลด architecture.md แล้ว
309:17  แก้ไข checkout.ts แล้ว
409:18  focused test ตก
509:21  ซ่อม implementation แล้ว
609:22  focused test ผ่าน
709:24  integration test ผ่าน
809:25  deployment ถูกบล็อก: ต้องรอการอนุมัติ

trace ที่มีประโยชน์ควรประกอบด้วย context sources, tool calls, state changes, verification results, retry reasons, approval decisions, cost และ latency

จุดประสงค์ไม่ใช่การเก็บ log เล่นๆ

แต่เพื่อให้จับจุดที่ล้มเหลวได้เฉพาะเจาะจง

ถ้าขั้นตอนที่ 18 พัง คุณควรซ่อมได้แค่ขั้นตอนที่ 18

โดยไม่ต้องย้อนกลับไปรันใหม่ทั้งหมด

12. ออกใบเสร็จให้ทุกการรัน

อย่าบังคับให้คนมานั่งอ่าน transcript ยาวสี่สิบข้อความ

ให้สรุปผลลัพธ์ออกมาเป็นใบเสร็จสั้นๆ

1OBJECTIVE
2
3แก้ไขปัญหาคูปองถูกใช้ซ้ำ
4
5CHANGED
6
7checkout validation
8regression test
9
10VERIFIED
11
12lint passed
13unit tests passed
14integration test passed
15
16NOT VERIFIED
17
18production payment provider
19
20RISKS
21
22legacy mobile client unavailable
23
24APPROVAL NEEDED
25
26deploy to staging

นี่ไม่ใช่สรุปเรื่องที่โมเดลอ้างว่าเกิดขึ้น

แต่เป็นสรุปสิ่งที่ harness พิสูจน์ได้ว่าเกิดขึ้นจริง

ความแตกต่างนี้ทำให้ใบเสร็จมีประโยชน์ต่อการรีวิว การส่งต่องาน และ agent sessions ในอนาคต

13. ทำให้ทุกความล้มเหลวช่วยพัฒนา Harness

ทีมส่วนใหญ่มักไปแก้ที่ผลลัพธ์ที่ผิดพลาด

แต่วิธีที่ดีกว่าคือการแก้ระบบที่เปิดช่องให้เกิดความผิดพลาดนั้น

1MISSING CONTEXT
2-> ปรับปรุง project map
3
4WRONG TOOL
5-> ปรับปรุง routing หรือ tool contract
6
7BAD OUTPUT
8-> เพิ่ม validator
9
10REPEATED LOOP
11-> เพิ่ม retry cap
12
13UNSAFE ACTION
14-> เพิ่ม permission gate
15
16LOST DECISION
17-> persist state
18
19UNKNOWN FAILURE
20-> ปรับปรุง tracing

นี่คือจุดที่ harness engineering เริ่มทวีคูณคุณค่า

การแก้ผลลัพธ์หนึ่งชิ้นช่วยได้แค่การรันครั้งเดียว

แต่การแก้ harness หนึ่งจุดจะช่วยปรับปรุงการรันทุกครั้งหลังจากนั้น

ระบบ agent ที่ดีที่สุดจะเชื่อถือได้มากขึ้นเรื่อยๆ เพราะความผิดพลาดทิ้ง infrastructure เอาไว้เบื้องหลัง

14. เริ่มจาก Harness ที่เล็กที่สุดแต่ใช้ได้จริง

คุณไม่จำเป็นต้องมี orchestration platform ขนาดใหญ่ตั้งแต่แรก

ให้สร้างเป็นชั้นๆ ไป

1LEVEL 0
2
3prompt
4model
5
6LEVEL 1
7
8task contract
9project map
10tools
11
12LEVEL 2
13
14structured state
15verification
16bounded loop
17
18LEVEL 3
19
20permissions
21traces
22recovery
23human gates

งาน research สั้นๆ อาจต้องการแค่ prompt กับการรีวิวครั้งเดียว

แต่งาน coding หกชั่วโมงที่ต้องเข้าถึงไฟล์ เข้าถึงเครือข่าย และ deploy ได้ ต้องการอะไรมากกว่านั้นเยอะ

เพิ่มความซับซ้อนเมื่อขอบเขตของความล้มเหลวเรียกร้องให้ทำ

ไม่ใช่เพราะสถาปัตยกรรม agent มันดูเท่

Checklist สำหรับ Harness Engineering

ก่อนจะให้สิทธิ์ agent ทำงานได้อย่างอิสระ ลองถามตัวเองว่า:

1[ ] นิยามความสำเร็จไว้ก่อนเริ่มทำงานหรือยัง?
2
3[ ] agent หา context ที่ถูกต้องได้ไหม
4    โดยไม่ต้องโหลดทุกอย่าง?
5
6[ ] เครื่องมือทุกตัวมีจุดประสงค์
7    schema และ failure state ชัดเจนไหม?
8
9[ ] การตัดสินใจสำคัญถูกเก็บไว้
10    นอกการสนทนาหรือไม่?
11
12[ ] การจบงานต้องมีหลักฐานประกอบไหม?
13
14[ ] การกระทำที่มีความเสี่ยงถูกปกป้องด้วยนโยบายหรือเปล่า?
15
16[ ] ทุกลูปมีขีดจำกัดการ retry หรือไม่?
17
18[ ] การรันสามารถทำต่อหลังถูกขัดจังหวะได้ไหม?
19
20[ ] คุณสามารถประกอบร่างการกระทำสำคัญทุกอย่างใหม่ได้หรือไม่?
21
22[ ] ความล้มเหลวช่วยพัฒนากฎ เครื่องมือ
23    test map หรือ permission ไหม?
24
25[ ] การเปลี่ยนแปลงสุดท้ายสามารถ rollback ได้หรือไม่?

ถ้าหลายข้อตอบว่าไม่ โมเดลที่เก่งขึ้นก็ไม่ได้ทำให้ agent เชื่อถือได้ขึ้นมาโดยอัตโนมัติ

มันอาจแค่ทำให้ระบบพังเร็วขึ้นและแพงขึ้นเท่านั้น

การเปลี่ยนแปลงที่แท้จริง

Prompt engineering ถามว่า:

ฉันควรบอกอะไรกับโมเดล?

Context engineering ถามว่า:

ตอนนี้โมเดลควรรู้อะไร?

ส่วน Harness engineering ถามว่า:

ระบบแบบไหนที่จะปล่อยให้โมเดลลงมือทำ ตรวจสอบงานตัวเอง กู้คืนจากความล้มเหลว และทำงานได้อย่างปลอดภัย?

1PROMPT
2-> instruction
3
4CONTEXT
5-> working view
6
7HARNESS
8-> operating environment
9
10LOOP
11-> local correction
12
13GRAPH
14-> coordination

โมเดลจะเปลี่ยนไปเรื่อยๆ

แต่ความได้เปรียบที่ยั่งยืนอยู่รอบๆ ตัวมัน

contract ของคุณจะดีขึ้น

เครื่องมือของคุณจะดีขึ้น

test ของคุณจะดีขึ้น

state ของคุณจะสะอาดขึ้น

permission ของคุณจะปลอดภัยขึ้น

logic การกู้คืนของคุณจะฉลาดขึ้น

ความล้มเหลวของคุณจะกลายเป็น infrastructure

นี่คือวิธีที่โมเดลเก่งๆ จะกลายเป็น agent ที่เชื่อถือได้

และนี่คือ Harness Engineering

ถ้าคุณอ่านมาถึงตรงนี้

บุ๊กมาร์กไกด์นี้ไว้เลย

ติดตามผมบน X: x.com/0xjmori

สมัครรับข่าวสารทาง Substack ของผม: substack.com/@lunarresearcher

ส่งบทความนี้ไปให้คนที่กำลังพยายามแก้ agent พังด้วยการเขียน prompt ให้ยาวขึ้นอ่านดู