Claude Cookbook: ตั้งแต่เอเจนต์ไปจนถึง RAG, มัลติโมดัล และการดำเนินงาน

 (platform.claude.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • รวบรวม คู่มือเชิงปฏิบัติและตัวอย่าง สำหรับการพัฒนาแอปพลิเคชัน Claude ครอบคลุมตั้งแต่การสร้างเอเจนต์ ไปจนถึง RAG, การใช้เครื่องมือ, มัลติโมดัล และการประเมินผล
  • ตัวอย่าง Claude Agent SDK และ Managed Agents มีแพตเทิร์นการดำเนินงาน เช่น การประสานงานหลายเอเจนต์ การจัดการเซสชัน การดีพลอย การรับมือเหตุขัดข้อง การตรวจหาช่องโหว่ และหน่วยความจำผู้ใช้
  • มีเทคนิค หน่วยความจำและการบีบอัดคอนเท็กซ์ สำหรับเอเจนต์ที่ทำงานระยะยาว, การเรียกใช้เครื่องมือแบบโปรแกรม, การค้นหาเครื่องมือด้วย embedding และซับเอเจนต์แบบอะซิงโครนัส
  • สามารถดูตัวอย่างการพัฒนาได้ตั้งแต่ RAG, การสร้าง SQL, knowledge graph, การสรุปเอกสาร, การประมวลผลภาพและเสียง ไปจนถึง การประเมินผล ต้นทุน observability และกลไกความปลอดภัย
  • ครอบคลุมการดีพลอยด้วย Docker, Modal, Kubernetes, การจัดการเวอร์ชันพรอมป์และการ rollback, การอนุมัติจากมนุษย์ และการวิเคราะห์ต้นทุน จึงใช้ได้ตลอดทั้ง การพัฒนาและการดำเนินงานในโปรดักชัน

การประเมินเอเจนต์และกลไกความปลอดภัย

หลายเอเจนต์และแพตเทิร์นเวิร์กโฟลว์

  • การประสานงานหลายเอเจนต์แบบอะซิงโครนัส: ครอบคลุมโครงสร้าง messaging และ lifecycle ของทีมเอเจนต์จำนวน N ตัวแบบคงที่ที่แลกเปลี่ยนข้อความกับเพื่อนร่วมงานในฮับร่วมกัน และ ซับเอเจนต์แบบอะซิงโครนัส ที่สร้างแบบไดนามิก
  • หลายเอเจนต์: ประสานงานทีมผู้เชี่ยวชาญ: ผู้ประสานงานนำทีมนักวิจัยค้นเว็บ ผู้รับผิดชอบอ่านไฟล์ และผู้ดูแลราคาตามกฎ เพื่อจัดทำข้อเสนอการขาย
    • รวมฟิลด์ multiagent, อีเวนต์ thread_created และ thread_message_received และ การจำกัดขอบเขตเครื่องมือตามบทบาท
  • Outcomes: เอเจนต์ที่ตรวจสอบงานของตัวเอง: สร้าง ลูปให้คะแนนและปรับปรุง โดยผู้เขียนสร้างสรุปงานวิจัยพร้อมอ้างอิง แล้วตัวให้คะแนนแบบไร้สถานะตรวจ URL และคำอ้างอิง จากนั้นแก้ไขจนกว่าจะผ่าน
    • ครอบคลุมอีเวนต์ user.define_outcome, span.outcome_evaluation_* และวิธีเขียนเกณฑ์ประเมินที่ตัวให้คะแนนนำไปใช้ได้
  • เวิร์กโฟลว์พื้นฐาน: มี แพตเทิร์นหลาย LLM สามแบบ ที่แลกต้นทุนหรือ latency กับประสิทธิภาพ
  • Evaluator-Optimizer: โครงสร้างแบบวนซ้ำที่ LLM หนึ่งสร้างผลลัพธ์ และอีก LLM ให้ฟีดแบ็กการประเมิน
  • Orchestrator-Workers: LLM ส่วนกลางมอบหมายงานแบบไดนามิกและสังเคราะห์ผลลัพธ์จาก worker LLM
  • ใช้ Haiku เป็นซับเอเจนต์: ซับเอเจนต์ Haiku ดึงข้อมูลรายงานการเงิน และ Opus สังเคราะห์ผลลัพธ์

Claude Agent SDK

  • เอเจนต์วิจัยแบบบรรทัดเดียว: สร้างเอเจนต์วิจัยอัตโนมัติด้วย Claude Code SDK และ WebSearch
  • เอเจนต์หัวหน้าฝ่ายเลขานุการ: สร้าง ระบบหลายเอเจนต์ ด้วยซับเอเจนต์, hook, รูปแบบเอาต์พุต และโหมดวางแผน
  • เอเจนต์ observability: เชื่อมต่อเอเจนต์กับระบบภายนอกผ่านเซิร์ฟเวอร์ MCP เพื่อจัดการการมอนิเตอร์ GitHub และเวิร์กโฟลว์ CI
  • เอเจนต์ Site Reliability: วินิจฉัยและกู้คืนเหตุขัดข้องด้วยเครื่องมือ MCP แบบอ่าน/เขียน และเขียนรายงานหลังเหตุการณ์
  • ย้ายจาก OpenAI Agents SDK: ใช้เอเจนต์อนุมัติค่าใช้จ่ายเป็นตัวอย่าง เพื่อจับคู่เครื่องมือ guardrail เซสชัน และ handoff กับ องค์ประกอบพื้นฐานของ Claude Agent SDK
  • สร้าง session browser: แสดงรายการและเปิดดูเซสชัน Agent SDK บนดิสก์ รวมถึงเปลี่ยนชื่อ ติดแท็ก และ fork เพื่อสร้าง sidebar โดยไม่ต้องมี parser ประวัติสนทนาแยกต่างหาก
  • เอเจนต์ตรวจหาช่องโหว่: ทำ threat modeling ให้เป้าหมายภาษา C และใช้เครื่องมือไฟล์ในตัวเพื่อหา บั๊กด้านความปลอดภัยของหน่วยความจำ จากนั้นจัดหมวดหมู่เป็นรายงานแบบมีโครงสร้าง
  • โฮสต์เอเจนต์: ดีพลอยเอเจนต์วิจัยเป็นสามขั้นตอนบน Docker, Modal และ Kubernetes โดยคง image ของคอนเทนเนอร์และอินเทอร์เฟซ HTTP เดิมไว้

Claude Managed Agents

การจัดการหน่วยความจำและบริบท

การใช้เครื่องมือและการเชื่อมต่อภายนอก

การค้นหา·RAG·การประมวลผลความรู้

มัลติโมดัล·เสียง·เอกสาร

การตอบสนอง·การให้เหตุผล·พรอมป์ต์

Skills และแอปพลิเคชันงาน

รูปแบบเอเจนต์ LlamaIndex และการมีส่วนร่วมจากชุมชน

  • เอเจนต์ ReAct: สร้างเอเจนต์ ReAct ที่ทำเวิร์กโฟลว์การให้เหตุผลและการกระทำโดยใช้เครื่องมือด้วย LlamaIndex
  • เปิดรับ การมีส่วนร่วมจากชุมชน สำหรับไอเดีย Cookbook ใหม่ ๆ และมี คู่มือการมีส่วนร่วม ให้ใช้งาน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • พูดตามตรง เอกสารแทบทุกอย่างเกี่ยวกับ วิธีใช้ AI ดูไม่มีความหมายเลย วิธีการก็แค่ถาม AI ตรงๆ ก็ได้ และถ้าเป็นเรื่องวิธีใช้งาน AI ก็ควรฝังไว้ในฮาร์เนสหรือปล่อยให้ Anthropic/OpenAI ทำเป็นฟีเจอร์เล็กๆ มาให้
    พวก agent workflow, การจัดการ memory, harness engineering ก็ให้ความรู้สึกว่าเป็นการโชว์เสียมากกว่า

    • ในปี 2023 คนบอกว่า prompt engineering จะกลายเป็น software engineering แบบใหม่ เลยขยันเรียน CoT, ReAct ฯลฯ กันมาก แต่พอปี 2024 ส่วนใหญ่ก็ไม่จำเป็นแล้วเพราะ โมเดล reasoning และการอัปเดตฮาร์เนส
      เทคนิคหรือเฟรมเวิร์ก AI ใหม่ๆ ก็ถูกดูดซึมหรือถูกแทนที่ทุก 3 เดือน เลยดูไม่ค่อยคุ้มที่จะลงทุนเวลา
    • เมื่อความสามารถของโมเดลสูงขึ้น มันก็จะดูดซับเครื่องมือรอบข้างเข้าไปเอง ทำให้เครื่องมือพวกนี้ อายุสั้นเกินไป. เราเห็นแพตเทิร์นเดิมแบบนี้ซ้ำมาแล้ว
    • Vercel บอกว่า Markdown ไฟล์เดียวที่มีคำสั่งชัดเจนอาจได้ผลดีกว่าการเรียกใช้ tool และยังแนะนำวิธีใช้ compressed index ด้วย ฉันเองก็เสียเวลาหลายชั่วโมงพยายามทำ tool calling ให้สมบูรณ์ แต่ก็เจอผลคล้ายกัน และหลังจากนั้นก็ใช้แค่ Claude.md, Agents.md และถ้าจำเป็นก็ Project.md
    • LLM ดูเหมือนจะใช้ LLM อื่นภายในฮาร์เนสได้แย่มาก ถ้าปล่อยไว้ก็มักจะยัดสารพัดอย่างลงในไฟล์ .md จน ทำให้ context ปนเปื้อน
      สุดท้ายก็ต้องทำให้ LLM เป็นฝ่ายค้นหาเอกสารพวกนี้เอง ดังนั้นมันอาจเป็นเอกสารสำหรับ LLM มากกว่าสำหรับคน
    • ตอนที่ทุกคนกำลังอวย MCP กันอยู่นั้น skills กลับกลายเป็นทางเลือกที่มีประสิทธิภาพกว่า และการจัดการ context แบบเข้มข้นก็สำคัญน้อยลงเพราะมี context window ที่ยาวและความสามารถแบบ agent แล้ว ถ้าเป็นเทคนิคที่ดีจริง ก็น่าจะถูกฝังมาในเวอร์ชันถัดไป
      เพราะงั้นถ้าไม่จำเป็นจริงๆ ฉันจะเลี่ยง plugin กับ MCP แล้วใช้ prompt ที่ครบถ้วน แทน แบบนี้ช่วยเลี่ยงการบังคับใช้ optimization เก่าๆ กับ LLM จนไปขัดขวางพัฒนาการของมัน

  • ภาพก่อนและหลังใน frontend aesthetics prompting ชวนขำมาก เหมือนไม่มีใครตรวจเลยว่า skill นี้ช่วยให้ดีไซน์ดีขึ้นจริงหรือเปล่า

    • ผลลัพธ์ที่ยกมาทั้งหมดดูเป็น การถอยหลัง ไม่ใช่การพัฒนา
    • ไกด์จำนวนมากแนะนำ frontend design skill แบบตามน้ำสไตล์ LLM cargo cult แต่เนื้อหาจริงกลับไม่เหมือนที่คนส่วนใหญ่คิด
    • เว็บไซต์ที่ใส่ aesthetics แล้วดูเหมือน keygen ยุคต้นทศวรรษ 2000 แค่เพิ่มเพลงเทคโนเข้าไปก็ใช่เลย
    • เอาจริงๆ คือผลลัพธ์น่าอายพอสมควร แทบจะเป็นระดับ “ใช้พื้นหลังสีดำกับฟอนต์ที่กว้างจนน่ากลัว”
    • สงสัยว่าเขาตั้งใจเลือกตัวอย่างที่ทำให้ความต่างก่อนและหลังดูมากที่สุดเพื่อสร้างความรู้สึกว่ามันได้ผลหรือเปล่า สำหรับฉันแล้ว ดีไซน์ก่อนใช้ ดูดีกว่าทุกตัวอย่าง

  • ผลลัพธ์ของ frontend aesthetics prompting คือก่อนใช้ก็ดูจืดๆ พอใช้แล้วก็กลายเป็น ความจืดที่เพิ่ม gradient

    • บางตัวอย่างก่อนใช้ดูดีกว่า และตัวอย่างเดียวที่พอจะเรียกว่าเป็นการปรับปรุงจริงๆ ได้ก็คือตัวอย่างบล็อก
    • กลับกัน ฉันชอบเวอร์ชันที่ไม่ใส่ aesthetics มากกว่า
    • ยังเพิ่ม label ตัวพิมพ์ใหญ่ทั้งหมด ซึ่งเป็นลักษณะประจำของหน้าเว็บที่ AI ออกแบบอีกด้วย

  • ที่บ้านฉันใช้ skills ของ Matt Pocock อยู่ และมันดีมาก ถูกออกแบบมาให้ ผู้ใช้เรียกเอง ไม่ใช่เรียกอัตโนมัติ เลยไม่กิน context มากเพียงเพราะมีมันอยู่
    แทนที่จะกันโปรแกรมเมอร์ออกจากผลลัพธ์สุดท้าย มันกลับช่วยให้คิดกับผลลัพธ์ได้ลึกขึ้น grill skills ช่วยทำให้ requirement ที่แท้จริงชัดเจนขึ้น ส่วน prototype skill ช่วยสำรวจจุดที่ต้องลองใช้เองถึงจะตัดสินใจเรื่องยากๆ ได้

  • OpenAI Cookbook ก็มีประโยชน์เช่นกัน ห้องวิจัย AI อื่นๆ ก็มักปล่อยตัวอย่างและ cookbook บน GitHub กับ Hugging Face อยู่เรื่อยๆ เลยยังคุ้มที่จะคอยดูต่อไป

  • coding agent ทำบั๊กในฝั่ง frontend มากกว่า backend มาก และปล่อยฟีเจอร์ที่พัง ไม่สมบูรณ์ หรือดูแปลกๆ ออกมาบ่อยกว่ามาก สาเหตุน่าจะมาจาก ความต่างด้านการตรวจสอบความถูกต้อง ระหว่างสองฝั่ง และแค่ชุดทดสอบพื้นฐานก็ไม่พอ
    แนวทางแบบ gstack ของ Garry Tan ดูเหมาะสม แต่ยังไม่แน่ใจว่ามันโตพอจะนำมาใช้หรือยัง มีคนประเมินด้วยว่า Gemini 3.5 Flash ทำงาน frontend ได้ดีกว่า Opus หรือ GPT-5.5 ด้วย เลยอยากรู้ว่ามาจากความสามารถแบบ multimodal, ความเข้าใจ Chrome หรือเป็นแค่ผลประเมินจากผู้ใช้จริง

    • อาจมีทางเลือกที่ผสานกับ agent แบบ Claude Front End Design skill ด้วย แต่ฉันยังไม่เคยลองเอง Magic Patterns เด่นมากในการ สร้าง prototype ระยะแรก เมื่อมี agent ที่เข้าใจฟังก์ชันและข้อจำกัดคอยควบคุม
      ถ้าอยากได้ผลลัพธ์ที่สร้างสรรค์ก็ต้องสั่งอย่างจริงจัง แต่สำหรับดีไซน์ frontend มาตรฐานถือว่าใช้ได้ดี อย่างไรก็ตาม ฉันใช้มันแค่เพื่อทดสอบไอเดีย ไม่ใช่ให้มันเพิ่มหรือแก้ฟีเจอร์แบบสุ่ม
    • agent จัดการ การอัปเดตสถานะแบบ asynchronous ที่ซับซ้อนได้ไม่ดี เพราะแสดงสิ่งนั้นใน context ได้ยาก แต่ถ้าเป็นการสร้างคอมโพเนนต์ซับซ้อนแบบแยกเดี่ยว หรือทำฟีเจอร์ที่ coupling ต่ำอย่าง animation ก็พอใช้ได้

  • ตอนแรกนึกว่าเป็น cookbook ของจริง สำหรับใช้ LLM สร้างสูตรอาหารที่ดูดีและทำกินได้จริง แต่ดูเหมือนยังไม่ถึงขั้นนั้น

    • กว่าหนึ่งปีแล้วที่ฉันทำอาหารโดยมี LLM ช่วยเดือนละหลายครั้ง และเก้าในสิบครั้งก็ออกมาดี สูตรอาหารแบบเฉลี่ยๆ ที่อยู่ในน้ำหนักโมเดลก็ค่อนข้างแข็งแรงอยู่แล้ว และมันยังเก่งเรื่อง การแทนที่วัตถุดิบ อย่างเช่น “ไม่มีวัตถุดิบ X” หรือ “ช่วยเปลี่ยนให้เป็นมังสวิรัติ”
      หลังได้สูตรมาแล้วจะลองขอว่า “ช่วยทำให้อร่อยขึ้นอีก” สักหนึ่งสองรอบแล้วดูผลก็สนุกดี
    • ฉันกำลังเรียนทำอาหารอิตาเลียนกับ ChatGPT อยู่ และนอกจากลองผิดลองถูกอยู่บ้างไม่กี่ครั้งแล้ว มันทำงานได้ดีอย่างน่าประหลาดใจ
    • ปีนี้ฉันลองทำอาหารกับ Gemini อยู่สองสามครั้ง และมันดีกว่าที่คาดไว้มาก สามารถบอกว่า “ในตู้มีวัตถุดิบพวกนี้และฉันอยากได้ อาหารแบบคีโต” แล้วค่อยคุยกันเพื่อคัดตัวเลือกให้แคบลงได้
    • ฉันเองก็คาดหวัง เครื่องมือวางแผนมื้ออาหารดิจิทัล เหมือนกัน

  • นึกว่าเป็นผลิตภัณฑ์ใหม่สำหรับสร้างสูตรอาหารด้วย Claude

    • ฉันใช้ Claude project กับเรื่องสูตรอาหารอยู่ และมันยอดเยี่ยมมากในการแนะนำเมนูและ ปรับสูตร ให้เข้ากับวัตถุดิบที่มีในตู้ เลยหวังว่าจะมีผลิตภัณฑ์แบบนั้นจริงๆ
    • ที่จริงก็เอาไปใช้แบบนั้นได้เหมือนกัน

  • ดีไซน์ก่อนและหลังใช้ cookbook ทั้งสองฝั่งดูเหมือนทำด้วย vibe coding เหมือนกันหมด ฉันไม่ใช่นักออกแบบพอจะชี้สาเหตุได้แม่น แต่ช่วงสไตล์ที่ Claude ทำได้ดูค่อนข้างจำกัด
    ถ้าระบุสิ่งที่ต้องการเปลี่ยนให้เฉพาะเจาะจงกว่านี้ อาจช่วยกดแนวโน้มแบบนั้นลงได้

  • อย่างน้อยก็น่าจะมีการรีวิว UI สักครั้ง มันจัด ระยะห่างของตาราง พื้นฐานยังไม่ดีเลย