เครื่องยนต์​ของ agent — Agent Harness & Loop

ความคืบหน้า0 / 8 บทเรียน

เส้น​ทางการ​เรียน

1. ●01loop คือเครื่องยนต์เริ่มตรงนี้
   • Agent Harnesscode scaffolding ที่ห่อรอบการเรียก model หนึ่งครั้ง — คือส่วนที่จัดการ tool dispatch, การรักษาประวัติข้อความ (message history), ตัว `while` ที่วนซ้ำ และการตรวจเงื่อนไขหยุด (stop check) Anthropic เรียกชื่อ 'agent harness' ไว้ (Claude Agent SDK) แต่การแยกส่วนออกเป็นสี่ชิ้นนี้คือกรอบสอนของคอร์สนี้ ต่างจาก #16 ที่ engineer 'สิ่งที่ป้อน' (context) — harness คือ runtime ที่ตอบว่า 'ป้อนอย่างไร' เทิร์นแล้วเทิร์นเล่า
   • Agent Loopวงจร runtime ที่ harness วนซ้ำ: gather context → take action → verify work → repeat (Claude Agent SDK) — เรียก model, dispatch tool ที่ถูกเรียก, ผนวกผลกลับเข้า context, ตรวจเงื่อนไขหยุด แล้ววนใหม่ ลึกกว่า loop ของ #15 บท6 ที่หยุดด้วย predicate เดียว ตรงที่เพิ่มเฟส verify — หลัง write action (เช่น issueRefund) อ่าน ground truth ซ้ำ (getOrder) ก่อนประกาศว่าเสร็จ
   • Augmented LLMอะตอมที่ harness ห่ออยู่: LLM ที่เสริมด้วย retrieval, tools และ memory (BEA — 'the basic building block of agentic systems') ผู้เรียนสร้างมันไว้แล้วใน #15 (tools) + #16 (retrieval/memory) — #17 คือ runtime ที่เรียกอะตอมตัวนี้ซ้ำ ๆ ใน loop; retrieval/memory คือ 'ส่วนเสริม' ส่วน #17 คือ 'ตัว runtime' ที่เรียกใช้มัน
2. ○02Workflow ต่างกับ Agent
   • Workflowตามนิยาม BEA: 'systems where LLMs and tools are orchestrated through predefined code paths' — เส้นทางถูกกำหนดไว้ใน code จึงคาดเดาได้และ test ได้ (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) เป็นที่มาของคุณค่าส่วนใหญ่ในโปรดักชัน และเป็นค่าเริ่มต้นที่ควรเอื้อมหาก่อน autonomous loop ตรงข้ามกับ Autonomous Agent
   • Autonomous Agentตามนิยาม BEA: 'systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks' — model กำหนดทิศทางของตัวเองแบบ dynamic; harness + loop ของบท1 คือสิ่งที่ทำให้ระบบเป็น agent ไม่ใช่ workflow แลกความยืดหยุ่นมาด้วย latency + cost + โอกาสสะสม error จึงต้องคุ้มค่าก่อนจึงจะใช้ (ประกอบจริงในบท8)
3. ○03Prompt chaining และ routing
   • Prompt Chainingworkflow ตาม BEA: 'decomposes a task into a sequence of steps, where each LLM call processes the output of the previous one' — หั่นงานเป็นลำดับตายตัว แต่ละ call ประมวลผล output ของ call ก่อนหน้า คั่นด้วย gate (ตรวจระหว่างขั้นแล้ว bail/escalate ได้) เหมาะเมื่องานหั่นเป็น subtask ตายตัวได้อย่างสะอาด
   • Routingworkflow ตาม BEA: 'classifies an input and directs it to a specialized followup task' — จัดหมวด input (มักด้วย structured output ราคาถูก1 call) แล้ว dispatch ไปยัง handler/prompt เฉพาะทาง (เช่น Refund / Delivery / General) เหมาะกับงานที่มีหมวดหมู่ชัดเจนซึ่งจัดการแยกกันได้ดีกว่า
4. ○04Parallelization — หั่นขนาน แล้วรวมผล
   • Parallelizationworkflow ตาม BEA: LLM หลายตัวทำงานพร้อมกันแล้วรวมผลด้วย code — สองแบบ: sectioning (หั่นเป็น subtask อิสระ รันขนานด้วย `Task.WhenAll`) และ voting (รันงานเดิม N ครั้งแล้วเอาเสียงข้างมาก) ⚠️ เป็นข้อยกเว้นที่ต้อง 'ได้มา' ไม่ใช่ค่าเริ่มต้น: ใช้ได้ต่อเมื่อ subtask เป็นอิสระต่อกันจริง ๆ ถ้า share context หรือพึ่งพากันให้ยุบกลับเป็น loop เดียว (#12) และพึงจำว่ามันคูณ token ตามจำนวน call
   • Workflowตามนิยาม BEA: 'systems where LLMs and tools are orchestrated through predefined code paths' — เส้นทางถูกกำหนดไว้ใน code จึงคาดเดาได้และ test ได้ (prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer) เป็นที่มาของคุณค่าส่วนใหญ่ในโปรดักชัน และเป็นค่าเริ่มต้นที่ควรเอื้อมหาก่อน autonomous loop ตรงข้ามกับ Autonomous Agent
5. ○05Orchestrator-workers: โครงสร้างที่ต้องหาเงินจ่ายค่า token ให้ตัวเองได้
   • Orchestrator-Workersworkflow ตาม BEA: 'a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results' — ต่างจาก parallelization ตรงที่ subtask ไม่ได้กำหนดล่วงหน้า ('you can't predict the subtasks needed') ⚠️ เป็นบทที่เสี่ยงอ่านเป็น pro-multi-agent ที่สุด: MARS วัดว่า multi-agent กิน token ~15 เท่าของแชท ต้องแปะป้ายราคานี้ทุกครั้งที่ pattern ปรากฏ — structure earns its place ไม่ใช่การอัปเกรดที่เอื้อมหา ใช้ต่อเมื่อคุณค่าของงานคุ้มค่า token ที่เพิ่มขึ้นเท่านั้น
   • Cost Budgetเพดาน token/เงินที่สะสมข้ามเทิร์น (จาก UsageDetails) แล้วหยุดเมื่อ runCost ถึงเพดาน — มีไว้เพราะ error สะสมแบบทวีคูณ (95%^N: 10 ขั้น ≈ 60%, 100 ขั้น ≈ 0.6% — Huyen, ตัวเลขประกอบ) และ multi-actor กิน token มาก (MARS 15×) จึงต้อง bound loop ให้แน่น ⚠️ `ChatResponse.Usage` เป็น connector-populated/beta-mapped — งานระดับบิลต้อง cross-check `RawRepresentation`
6. ○06Evaluator-optimizer: generate → evaluate → refine — และเมื่อไรไม่ควร reflect
   • Evaluator-Optimizerworkflow ตาม BEA: 'one LLM call generates a response while another provides evaluation and feedback in a loop' — คือรูปแบบ workflow ของ reflection: draft → ประเมินกับ rubric → revise โดย cap จำนวนรอบและหยุดทันทีเมื่อ evaluator ตอบ pass เหมาะเมื่อมีเกณฑ์ประเมินชัดและการขัดเกลาซ้ำมีคุณค่าที่วัดได้ evaluator call คือ eval-at-runtime (เชื่อมไป #13 ไม่สอนซ้ำ)
   • Reflectionการที่ model สะท้อนบน feedback แล้ววางแผนใหม่ (Reflexion, Self-Refine) — ⚠️ ไม่ใช่ชนะเสมอไป: ช่วยเป็นสัดส่วนกับความ grounded ของสัญญาณ reflection บนสัญญาณจริงจาก tool/oracle (เช่น unit test) เชื่อถือได้ แต่ intrinsic self-correction ล้วน ๆ บน reasoning มักไม่ดีขึ้นและบางครั้งแย่ลง (Huang et al., 'LLMs cannot self-correct reasoning yet') รู้ว่า 'เมื่อไรไม่ควร reflect' สำคัญพอ ๆ กับรู้วิธี reflect และทุกรอบคือ ≥1 model call เต็ม ๆ จึงต้อง cap เสมอ
7. ○07ความทนทาน: เมื่อ tool พัง loop ต้องไม่ล้ม
   • Tool-error Recoverymodel ต้อง 'เห็น' error — คืน error result (raw: `tool_result` ที่ `is_error: true`; ใต้ IChatClient: string จาก catch ป้อนกลับเป็น FunctionResultContent) ไม่ใช่ปล่อยให้ crash ป้อน error ที่ 'สอนได้' (บอกว่าเกิดอะไรและควรลองอะไรต่อ ไม่ใช่ 'failed' เปล่า ๆ) กลับเข้า loop ให้ model retry/re-route เอง — Claude retry tool call ที่ผิด 2–3 ครั้งเมื่อได้ error กลับไป (Anthropic)
   • Retryการลองใหม่เมื่อ call ล้มเหลว ด้วย exponential backoff + jitter และเพดานจำนวนครั้ง — เฉพาะ fault ชั่วคราว (transient) เท่านั้น; ยกเลิกทันทีถ้าเป็นถาวรหรือ error จาก business logic (ไม่ควร retry) ⚠️ 2 layer ทับกัน: SDK `Anthropic` retry ระดับ transport ให้อยู่แล้ว (`MaxRetries`) ส่วน Polly คือระดับ agent-loop (retry ทั้งเทิร์น, per-turn timeout) — อย่า double-retry transport
   • Idempotencyคุณสมบัติที่ทำให้ retry ปลอดภัย — tool ที่มี side effect (issueRefund) ต้องไม่ทำซ้ำเมื่อถูก retry มิฉะนั้น refund สำเร็จ แต่ response หาย แล้ว retry ยิงซ้ำ → refund สองครั้ง วิธีแก้: สร้าง idempotency key 'ก่อน' เข้า retry loop server เช็ค key แล้วคืนผลที่เก็บไว้แทนการประมวลซ้ำ ⚠️ (แปลความ) key ไม่ใช่หลักประกันเต็ม — side effect (event, email, external call) รั่วได้ รูปที่ทนทานคือเขียน intent + ledger ใน transaction เดียวแล้วส่งผ่าน outbox (โยง #10 ledger + #8 outbox)
8. ○08ประกอบร่าง: autonomous agent กับเงื่อนไขหยุดแบบประกอบ
   • Autonomous Agentตามนิยาม BEA: 'systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks' — model กำหนดทิศทางของตัวเองแบบ dynamic; harness + loop ของบท1 คือสิ่งที่ทำให้ระบบเป็น agent ไม่ใช่ workflow แลกความยืดหยุ่นมาด้วย latency + cost + โอกาสสะสม error จึงต้องคุ้มค่าก่อนจึงจะใช้ (ประกอบจริงในบท8)
   • Stopping Conditionเงื่อนไขหยุด loop — เป็น 'นโยบายประกอบ' (compound policy) ไม่ใช่ predicate เดียว: task-complete ∨ max-iterations ∨ token/cost-budget ∨ unrecoverable-error ∨ human-checkpoint (BEA + Huyen) `stop_reason != tool_use` ของ #15 คือเคส degenerate ของนโยบายนี้ ทุกบทลงมือแทนที่ทีละ clause; loop ออกทันทีที่ clause แรก trip และ log เหตุผลที่ออก (ตั้งไว้บท1 จ่ายคืนบท8)
   • Cost Budgetเพดาน token/เงินที่สะสมข้ามเทิร์น (จาก UsageDetails) แล้วหยุดเมื่อ runCost ถึงเพดาน — มีไว้เพราะ error สะสมแบบทวีคูณ (95%^N: 10 ขั้น ≈ 60%, 100 ขั้น ≈ 0.6% — Huyen, ตัวเลขประกอบ) และ multi-actor กิน token มาก (MARS 15×) จึงต้อง bound loop ให้แน่น ⚠️ `ChatResponse.Usage` เป็น connector-populated/beta-mapped — งานระดับบิลต้อง cross-check `RawRepresentation`