เริ่มต้นจากแนวคิดสำคัญว่า โมเดลภาษาขนาดใหญ่ในปัจจุบันพัฒนาไปไกลกว่าการเป็นแค่ chatbot มากแล้ว เพราะมีความสามารถด้าน reasoning, multimodality และการใช้ tools จึงทำให้เกิดระบบประเภทใหม่ที่เรียกว่า “agents” ขึ้นมา คู่มือนี้ถูกออกแบบมาเพื่อช่วยให้ทีมงานที่ยังไม่เคยสร้าง agent มาก่อน เข้าใจหลักคิดที่ถูกต้องก่อนลงมือจริง ไม่ใช่แค่ทำของเล่นทดลอง แต่ทำระบบที่ทำงานได้อย่างปลอดภัย คาดการณ์ได้ และสร้างคุณค่าทางธุรกิจได้จริง
ในมุมของ“agent” ไม่ได้หมายถึงระบบที่ตอบคำถามเก่งอย่างเดียว แต่หมายถึงระบบที่สามารถ “ลงมือทำงานแทนผู้ใช้” ได้อย่างอิสระพอสมควร กล่าวคือ agent ต้องสามารถขับเคลื่อน workflow ให้เดินหน้าต่อไปจนบรรลุเป้าหมาย เช่น แก้ปัญหางานบริการลูกค้า จองร้านอาหาร แก้โค้ด หรือสร้างรายงาน โดยตัว agent จะไม่ใช่เพียงผู้ตอบ แต่เป็นผู้ตัดสินใจว่าจะทำขั้นตอนใดต่อ ใช้เครื่องมือใด และเมื่อไรควรหยุดหรือส่งงานกลับให้มนุษย์เข้ามาจัดการต่อ
แยกให้ชัดว่า แอปที่แค่เอา LLM มาใส่ไว้ แต่ไม่ได้ให้มันควบคุมการไหลของงานจริง ๆ ยังไม่ถือว่าเป็น agent ตัวอย่างเช่น chatbot ง่าย ๆ, ระบบถาม-ตอบแบบ one-shot หรือโมเดลจัดหมวดหมู่อารมณ์ข้อความ สิ่งเหล่านี้อาจใช้ LLM แต่ยังไม่ถึงระดับ agent เพราะไม่ได้ “บริหาร workflow” ด้วยตัวเอง
คุณสมบัติหลักของ agent ตามเอกสารมี 2 แกนสำคัญ
แกนแรก คือใช้ LLM เป็นตัวบริหารการดำเนิน workflow และตัดสินใจระหว่างทาง มันต้องพอจะรู้ได้ว่าเมื่อไรงานเสร็จ เมื่อไรควรแก้ทางเอง และเมื่อไรควรหยุดเพราะไปต่ออย่างปลอดภัยไม่ได้
แกนที่สอง คือมันต้องเข้าถึง tools ภายนอกได้ เช่น ระบบฐานข้อมูล, CRM, อีเมล, API, หรือ UI ของโปรแกรมต่าง ๆ เพื่อดึงข้อมูลและลงมือทำ action ได้จริง โดยการใช้เครื่องมือต้องอยู่ภายใต้ guardrails ที่กำหนดไว้อย่างชัดเจน
เมื่อไรควรสร้าง agent
เพราะไม่ใช่ทุกปัญหาต้องใช้ agent เสมอไป OpenAI แนะนำว่า การสร้าง agent เหมาะเมื่อวิธีอัตโนมัติแบบเดิม เช่น rule-based หรือ deterministic automation เริ่มไม่ตอบโจทย์แล้ว โดยเฉพาะงานที่มีความกำกวมสูง ต้องใช้การตีความบริบท และต้องตัดสินใจจากข้อมูลที่ไม่เป็นระเบียบมากนัก เอกสารยกตัวอย่างเปรียบเทียบเรื่อง fraud analysis ว่า rules engine ทำงานเหมือนเช็กลิสต์ แต่ LLM agent ทำงานเหมือนนักสืบที่พิจารณาสัญญาณแวดล้อมและความผิดปกติแบบละเอียดได้ แม้กรณีนั้นจะไม่ได้ละเมิดกฎข้อใดตรง ๆ ก็ตาม
3 ข้อในการหา use case ที่เหมาะกับ agent
ข้อแรก คือ workflow ที่ต้องใช้ judgment สูง มีข้อยกเว้นเยอะ หรือการตัดสินใจขึ้นกับบริบท เช่น การอนุมัติคืนเงินในงาน customer service
ข้อสอง คือระบบที่มีกฎซับซ้อนเกินไปจนดูแลรักษายาก แก้ทีหนึ่งกระทบอีกหลายส่วน เช่น vendor security review
ข้อสาม คือกรณีที่ต้องพึ่งพาข้อมูลไม่เป็นโครงสร้างมาก เช่น ข้อความธรรมชาติ เอกสาร PDF หรือการสนทนากับมนุษย์ เช่น การประมวลผลเคลมประกันบ้าน
หาก use case ไม่เข้าเงื่อนไขเหล่านี้ชัดเจน ระบบ deterministic แบบเดิมอาจเพียงพอและคุ้มกว่าการสร้าง agent
รากฐานของการออกแบบ agent
โดยสรุปว่า agent ขั้นพื้นฐานที่สุดประกอบด้วย 3 ส่วน คือ model, tools และ instructions โมเดลคือสมองที่ใช้ reasoning และตัดสินใจ tools คือฟังก์ชันหรือ API ภายนอกที่ใช้ลงมือทำงาน ส่วน instructions คือกติกาและแนวทางปฏิบัติที่กำหนดว่าตัว agent ควรทำตัวอย่างไร พูดอย่างไร ตัดสินใจแบบไหน และมีข้อห้ามอะไรบ้าง
เรื่องการเลือกโมเดล
เอกสารไม่ได้บอกให้ใช้โมเดลใหญ่ที่สุดตลอดเวลา แต่เสนอวิธีคิดที่ค่อนข้างเป็นวิศวกรรม คือเริ่มจากใช้โมเดลที่เก่งที่สุดสำหรับทุกงานก่อน เพื่อสร้าง baseline ด้านคุณภาพให้ชัด หลังจากนั้นค่อยไล่เปลี่ยนบางส่วนเป็นโมเดลที่เล็กลง เร็วขึ้น หรือถูกลง เพื่อดูว่ายังรักษาระดับผลลัพธ์ได้หรือไม่ แนวทางนี้ช่วยให้ทีมไม่รีบ optimize จนเสียความสามารถหลักของระบบไปตั้งแต่แรก และยังช่วยให้รู้ด้วยว่า task ไหนต้องใช้โมเดลเก่งจริง ๆ และ task ไหนใช้โมเดลเล็กก็พอ หลักสำคัญที่เอกสารเน้นมี 3 อย่าง คือ ตั้ง evals เพื่อสร้าง baseline, โฟกัสที่ความแม่นยำให้ถึงเป้าก่อน, แล้วจึงค่อย optimize เรื่องต้นทุนและ latency ภายหลัง
เรื่อง tools
เอกสารอธิบายว่า tools คือสิ่งที่ขยายขีดความสามารถของ agent ให้ไปไกลกว่าการคิดและตอบข้อความ เพราะ agent ที่ดีต้อง “ทำงาน” ได้จริง สำหรับระบบที่มี API ก็ให้เชื่อมผ่าน API แต่ถ้าระบบเก่าไม่มี API ก็อาจใช้โมเดลประเภท computer use เพื่อให้ agent โต้ตอบกับ UI ของเว็บหรือแอปเหมือนมนุษย์ได้ เอกสารยังย้ำว่าเครื่องมือแต่ละตัวควรมีนิยามมาตรฐาน เอกสารประกอบชัดเจน ผ่านการทดสอบ และนำกลับมาใช้ซ้ำได้ เพื่อให้จัดการ version ง่าย ค้นหาเจอ และไม่เกิดการสร้าง tool ซ้ำซ้อนในระบบ
OpenAI แบ่ง tools ออกเป็น 3 ประเภทหลัก
ประเภทแรก คือ data tools ใช้ดึงบริบทและข้อมูลที่จำเป็นต่อการทำงาน เช่น query ฐานข้อมูลธุรกรรม อ่านเอกสาร PDF หรือค้นเว็บ
ประเภทที่สอง คือ action tools ใช้ลงมือทำ เช่น ส่งอีเมล ส่งข้อความ อัปเดต CRM หรือส่งต่อ ticket ให้เจ้าหน้าที่จริง
ประเภทที่สาม คือ orchestration tools ซึ่งก็คือการที่ “agent หนึ่งสามารถเป็นเครื่องมือของอีก agent หนึ่งได้” เช่น refund agent, research agent หรือ writing agent เพื่อให้ระบบใหญ่ประกอบจากความสามารถย่อยที่ชัดเจนได้
อีกหัวใจหนึ่งของ agent คือ instructions
เอกสารให้ความสำคัญกับเรื่องนี้มาก เพราะแม้จะมี model ดีและ tools ครบ แต่ถ้าคำสั่งกำกวม agent ก็จะทำงานพลาดได้ง่าย OpenAI แนะนำให้เอาเอกสารปฏิบัติงานจริงในองค์กร เช่น SOP, policy, help center, support script มาแปลงให้เป็นคำสั่งที่ LLM เข้าใจง่ายและปฏิบัติตามได้ชัดเจน โดยมีหลักปฏิบัติสำคัญคือ ใช้เอกสารเดิมเป็นฐาน, แยกงานใหญ่เป็นขั้นตอนย่อย, ระบุให้ชัดว่าแต่ละขั้นต้องทำ action อะไรหรือส่ง output แบบไหน, และต้องเก็บ edge cases ให้ครอบคลุม เช่น กรณีข้อมูลไม่ครบหรือผู้ใช้ถามนอกเส้นทางที่คาดไว้
แนวทางที่น่าสนใจ
สามารถใช้โมเดลที่เก่งขึ้นมาช่วย “เขียน instructions สำหรับ agent” ได้ โดยให้เอา help center document หรือ policy เดิมมาป้อน แล้วสั่งให้โมเดลแปลงออกมาเป็น numbered list ที่ชัดเจน ไม่กำกวม และเขียนในลักษณะคำสั่งสำหรับ agent โดยตรง แนวทางนี้ช่วยลดภาระการเขียน prompt จากศูนย์ และช่วยแปลงความรู้ภายในองค์กรให้กลายเป็น logic ที่ agent ใช้งานได้จริง
Orchestration
หรือการออกแบบว่า agent จะเดิน workflow อย่างไร โดย OpenAI เตือนว่า หลายทีมมักอยากสร้าง agent อัตโนมัติเต็มรูปแบบที่ซับซ้อนตั้งแต่วันแรก แต่จากประสบการณ์ลูกค้าจริง กลับพบว่าแนวทางที่ค่อย ๆ เพิ่มความสามารถแบบ incremental ให้ผลดีกว่า
orchestration ออกเป็น 2 แบบหลัก
1. single-agent system คือกรณีที่ใช้ agent ตัวเดียวแต่ติดอาวุธให้มันด้วย tools และ instructions ที่เหมาะสม จากนั้นปล่อยให้มันวิ่งเป็น loop ไปเรื่อย ๆ จนถึงเงื่อนไขการออกจากรอบ เช่น เรียก tool บางชนิดสำเร็จ, ได้ structured output ตามที่ต้องการ, เกิด error, หรือจำนวนรอบเกินกำหนด แนวคิดเรื่อง “run loop” นี้สำคัญมาก เพราะ agent ไม่ได้ตอบครั้งเดียวจบ แต่คิด-ทำ-ดูผล-คิดต่อเป็นรอบ ๆ จนกว่าจะถึงจุดหยุดที่ออกแบบไว้ เอกสารมองว่าแนวทางนี้ช่วยควบคุมความซับซ้อนได้ดี ประเมินผลได้ง่าย และดูแลรักษาได้สะดวก เหมาะมากสำหรับการเริ่มต้น
2.multi-agent systems ซึ่งเอกสารสรุปจากประสบการณ์ลูกค้าว่าโดยกว้าง ๆ มี 2 รูปแบบที่ใช้ได้จริง
รูปแบบแรกคือ manager pattern หรือการมี agent กลางทำหน้าที่เป็นผู้จัดการ คอยประสานงานและเรียกใช้ agent เฉพาะทางหลายตัวเหมือนเรียก tool แต่ละตัวรับผิดชอบงานเฉพาะด้าน เช่น แปลภาษา วิจัย หรือเขียนข้อความ รูปแบบนี้เหมาะกับงานที่ต้องการศูนย์กลางควบคุมหรือต้องการสังเคราะห์คำตอบสุดท้ายจากหลายผู้เชี่ยวชาญย่อย
รูปแบบสองคือ decentralized pattern หรือแบบกระจายศูนย์ ที่ agent หลายตัวทำงานในฐานะ “เพื่อนร่วมทีม” และส่งต่อภารกิจให้กันเองผ่าน handoff ตามความเชี่ยวชาญของแต่ละตัว เช่น เริ่มจาก triage agent แล้วส่งต่อไปยัง order agent, sales agent หรือ repair agent ตามปัญหาที่พบ รูปแบบนี้เหมาะเมื่อไม่จำเป็นต้องมี agent ตัวใดคุมภาพรวมตลอดเวลา และยอมให้แต่ละ agent รับไม้ต่อไปคุยกับผู้ใช้หรือดำเนินงานต่อได้เอง เอกสารอธิบายว่าหากมองเป็นกราฟ manager pattern จะใช้เส้นเชื่อมแบบ tool calls ส่วน decentralized pattern จะใช้เส้นเชื่อมแบบ handoff ระหว่าง agent โดยตรง
ประเด็นที่น่าสนใจ
คือ declarative vs non-declarative graphs บาง framework บังคับให้นักพัฒนากำหนด node, edge, branch, loop และเงื่อนไขทั้งหมดล่วงหน้าในรูปกราฟ ซึ่งมีข้อดีคือมองภาพรวมง่าย แต่เมื่อ workflow ซับซ้อนและเปลี่ยนบ่อย แนวทางนี้จะเริ่มเทอะทะ ดูแลยาก และต้องเรียนรู้ภาษาหรือกรอบงานเฉพาะทางเพิ่มขึ้น ในทางกลับกัน Agents SDK ถูกอธิบายว่าใช้แนวทาง code-first ที่ยืดหยุ่นกว่า นักพัฒนาจึงสามารถเขียนตรรกะ workflow ด้วยโครงสร้างโปรแกรมที่คุ้นเคย โดยไม่ต้องนิยามกราฟทั้งก้อนตั้งแต่ต้น ทำให้ระบบปรับเปลี่ยนได้คล่องกว่า
Guardrails
ซึ่งถือเป็นหนึ่งในหัวใจของ agent production จริง OpenAI อธิบายว่า guardrails ที่ออกแบบดีช่วยจัดการความเสี่ยงได้ทั้งด้านความเป็นส่วนตัวของข้อมูล เช่น การป้องกัน prompt leak และด้านชื่อเสียง เช่น การควบคุมให้พฤติกรรมของโมเดลสอดคล้องกับแบรนด์ อย่างไรก็ตาม guardrails เพียงอย่างเดียวไม่พอ ต้องทำงานร่วมกับมาตรการความปลอดภัยซอฟต์แวร์แบบดั้งเดิมด้วย เช่น authentication, authorization, access control และ security measures อื่น ๆ จึงจะปลอดภัยพอสำหรับการใช้งานจริง
ชวนให้คิดว่า guardrails ควรถูกมองเป็น “ระบบป้องกันหลายชั้น” ไม่ใช่โล่ชิ้นเดียว เพราะ guardrail ตัวเดียวแทบไม่มีทางป้องกันทุกอย่างได้ ต้องใช้หลายชั้นประกอบกัน เช่น LLM-based guardrails, rules-based guardrails อย่าง regex, และ moderation API เพื่อคัดกรอง input ของผู้ใช้ก่อนให้ agent ลงมือทำอะไรที่มีผลจริง แก่นของแนวคิดนี้คือความทนทานของระบบเกิดจากการซ้อนการป้องกันหลายระดับ ไม่ใช่การฝากความหวังไว้ที่กลไกเดียว
OpenAI แจกแจงประเภทของ guardrails ไว้หลายแบบ
เริ่มจาก relevance classifier ที่ช่วยกันไม่ให้ agent หลุดขอบเขตงาน เช่น ผู้ใช้มาถามคำถามที่ไม่เกี่ยวกับหน้าที่ของ agent ก็ต้องตรวจจับได้ ต่อมาคือ safety classifier ที่คอยหาการโจมตีอย่าง jailbreak หรือ prompt injection ที่พยายามหลอกให้ agent เผย system prompt หรือทำสิ่งที่ไม่ควรทำ ถัดมาคือ PII filter สำหรับกรองไม่ให้ข้อมูลระบุตัวตนส่วนบุคคลหลุดออกไปโดยไม่จำเป็น และ moderation สำหรับคัดกรองเนื้อหาที่เป็นอันตรายหรือไม่เหมาะสม เช่น ความเกลียดชัง การคุกคาม หรือความรุนแรง
Tool safeguards
ซึ่งมองว่าเป็นประเด็นสำคัญมากในเชิงธุรกิจ แนะนำให้ประเมินความเสี่ยงของเครื่องมือแต่ละตัวเป็นระดับต่ำ กลาง สูง โดยดูจากลักษณะการเข้าถึงว่าเป็น read-only หรือ write, ย้อนกลับได้ไหม, ต้องใช้สิทธิ์ระดับใด, และมีผลทางการเงินมากน้อยแค่ไหน จากนั้นใช้ระดับความเสี่ยงนี้กำหนดการควบคุมต่อ เช่น ถ้าเป็น action เสี่ยงสูงให้ต้องผ่าน guardrail check เพิ่ม หรือบังคับให้มนุษย์อนุมัติก่อน นี่ยังไม่รวม rules-based protections เช่น blocklist, limit ความยาว input, regex filters หรือ output validation เพื่อควบคุมให้ผลลัพธ์ไม่ขัดกับแบรนด์และไม่สร้างความเสียหายเชิงภาพลักษณ์
ในเชิงปฏิบัติเสนอ heuristic ง่าย ๆ สำหรับการสร้าง guardrails คือ หนึ่ง เริ่มจากโฟกัสเรื่อง data privacy และ content safety ก่อน สอง เพิ่ม guardrails ใหม่ตาม edge cases และความล้มเหลวที่เจอจากโลกจริง สาม ปรับสมดุลทั้งด้านความปลอดภัยและประสบการณ์ผู้ใช้ เพราะระบบที่ปลอดภัยเกินไปแต่ใช้งานจริงแล้วติดขัดทุกขั้น ก็อาจไม่เกิด adoption ได้เช่นกัน แนวทางนี้สะท้อนว่า guardrails ไม่ใช่ของที่ติดครั้งเดียวจบ แต่เป็นสิ่งที่ต้องปรับตามการเติบโตของ agent เสมอ
อีกแนวคิดหนึ่งที่น่าสนใจ
คือ Agents SDK ปฏิบัติต่อ guardrails เป็น “first-class concept” และใช้แนวทาง optimistic execution เป็นค่าเริ่มต้น หมายความว่าตัว agent หลักจะเริ่มทำงานไปก่อน ในขณะที่ guardrails ทำงานขนานกันอยู่เบื้องหลัง หากพบการละเมิดเงื่อนไขก็จะโยน exception เพื่อหยุดหรือเปลี่ยนเส้นทางการทำงาน แนวคิดนี้ช่วยให้ระบบไม่ต้องรอเช็กทุกอย่างทีละจุดจนช้าเกินไป แต่ก็ยังคงความปลอดภัยได้ในระดับที่ออกแบบไว้ โดย guardrail เองอาจถูกสร้างเป็น function ธรรมดาหรือแม้แต่เป็น agent อีกตัวหนึ่งก็ได้
เน้นชัดว่าการกระทำที่มีความเสี่ยงสูง เช่น การยกเลิกคำสั่งซื้อของลูกค้า การอนุมัติคืนเงินก้อนใหญ่ หรือการทำรายการจ่ายเงิน ควรมี human oversight เข้ามาเกี่ยวข้องก่อนอย่างน้อยในช่วงแรก จนกว่าจะมั่นใจได้ว่าระบบมีความน่าเชื่อถือมากพอ ประเด็นนี้สะท้อนหลักคิดสำคัญว่า agent ไม่จำเป็นต้องอัตโนมัติ 100% ตั้งแต่ต้น การออกแบบที่ดีคือรู้ว่า action ไหนปล่อยให้ agent ตัดสินใจเองได้ และ action ไหนต้องมีคนเป็นเบรกชั้นสุดท้าย
สรุปท้ายเอกสาร OpenAI
วางภาพใหญ่ว่า agents คือยุคใหม่ของ workflow automation เพราะมันสามารถ reason กับความกำกวม ใช้ tools เพื่อทำงานจริง และจัดการงานหลายขั้นตอนอย่างมี autonomy ได้ ต่างจากแอป LLM แบบง่ายที่แค่ตอบคำถาม Agent จึงเหมาะกับงานที่มีการตัดสินใจซับซ้อน ใช้ข้อมูลไม่เป็นโครงสร้าง หรือระบบกฎเดิมเริ่มเปราะจนดูแลไม่ไหว แต่ความสำเร็จของการสร้าง agent ไม่ได้มาจากการรีบทำให้ยิ่งใหญ่ที่สุดตั้งแต่วันแรก หากมาจากการเริ่มจากฐานที่แข็งแรง เลือก model ให้เหมาะ มี tools ที่ชัด มี instructions ที่ดี ใช้ orchestration เท่าที่จำเป็น และใส่ guardrails ครบถ้วน แล้วค่อย ๆ ขยายจากของเล็กที่ทดสอบกับผู้ใช้จริงได้ไปสู่ระบบที่ใหญ่ขึ้นในภายหลัง
ถ้าจะสรุปแก่นของคู่มือนี้แบบภาษาคนทำงาน คิดว่าใจความสำคัญคือ “อย่าเพิ่งหลงใหลความฉลาดของโมเดลจนลืมโครงสร้างระบบ” เพราะ agent ที่ใช้งานได้จริงไม่ได้ชนะด้วย prompt เด็ดเพียงอย่างเดียว แต่ชนะด้วยการออกแบบทั้งระบบให้มีเป้าหมายชัด มีขอบเขตชัด มีเครื่องมือที่เหมาะ มีวิธีหยุดเมื่อควรหยุด และมีชั้นป้องกันพอสำหรับโลกความจริง เอกสารนี้จึงไม่ใช่คู่มือสอนทำ agent แบบแฟนซี แต่เป็นคู่มือสอน “คิดแบบคนสร้างระบบที่เอาไปใช้จริง” มากกว่า
บทความจาก
https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
