บทเรียนที่เราได้รับจากการเปิดตัวผลิตภัณฑ์ด้วย ChatGPT Apps SDK

• Apps SDK เป็นตัวเลือกที่ตอบโจทย์ หากคุณต้องการสร้างเวิร์กโฟลว์ใน ChatGPT โดยเร็ว หรือต้องการทดลองใช้เครื่องมือของคุณใน ChatGPT ก่อนลงทุนสร้างสแต็กเอเจนต์แบบกำหนดเอง แต่หากคุณต้องการควบคุมพฤติกรรมของเอเจนต์ในทุกขั้นตอน Apps SDK มักไม่ใช่ตัวเลือกที่เหมาะสม

• หากต้องการให้ผู้ใช้ใช้งานผ่าน ChatGPT เป็นหลัก พร้อมมีเครื่องมือและ UI เล็กๆ บางส่วนโดยไม่ต้องพัฒนาผลิตภัณฑ์แชตทั้งระบบ ให้เลือก Apps SDK แต่หากต้องควบคุมโฟลว์ หน่วยความจำ พรอมต์ และการเขียนข้อมูลอย่างใกล้ชิด ให้สร้างสแต็กเอเจนต์ของคุณเอง

• Apps SDK ตอบโจทย์ผลิตภัณฑ์ที่ใช้แชตร่วมกับการโต้ตอบผ่าน UI สั้นๆ เพียงไม่กี่ขั้นตอน โดยช่วยให้คุณนำผลิตภัณฑ์ออกสู่ตลาดได้เร็วขึ้น แต่ต้องยอมสละการควบคุมบางส่วน

• สิ่งที่ได้ผลสำหรับเราคือ เครื่องมือที่มีหน้าที่ชัดเจน พฤติกรรมของวิดเจ็ตที่ชัดเจน และขั้นตอนถัดไปที่ชัดเจน เราอาศัยองค์ประกอบเหล่านี้ในการกำหนดโฟลว์ ไม่ได้ปล่อยให้ LLM เป็นผู้คิดโฟลว์เอง โมเดลมีประโยชน์มากที่สุดเมื่อนำมาใช้อธิบายผลลัพธ์ที่ระบบได้ตัดสินใจไว้แล้ว

• เนื้อหาต่อไปนี้จะอธิบายวิธีเลือก ตามด้วยสิ่งที่ได้ผลและไม่ได้ผล

ทีมส่วนใหญ่ยังคงทดลองใช้ AI ในโครงการนำร่อง หรือนำ AI ไปใช้กับงานส่วนเสริมที่มีทั้งความเสี่ยงและผลตอบแทนต่ำ มีเพียงไม่กี่ทีมที่เปิดตัวผลิตภัณฑ์สำคัญต่อการดำเนินธุรกิจซึ่งผู้ใช้ใช้งานทุกสัปดาห์ หากเป้าหมายของคุณคือการนำผลิตภัณฑ์เข้าไปอยู่ใน ChatGPT แทนที่จะสร้างผู้ช่วยขึ้นมาเองทั้งระบบ ChatGPT Apps SDK ก็เป็นหนึ่งในวิธีลดช่องว่างดังกล่าว

บทเรียนของเรามาจากงานที่ทำให้ลูกค้า ซึ่งข้อกำหนดชี้ว่า ChatGPT ควรเป็นช่องทางหลัก และควรใช้แนวทางที่รวดเร็วโดยลูกค้าไม่ต้องลงทุนสร้างผลิตภัณฑ์แชตเฉพาะทางเต็มรูปแบบ

เมื่อพิจารณาตามโจทย์ดังกล่าว Apps SDK จึงเหมาะกับสิ่งที่ลูกค้าต้องการ ได้แก่

• ไม่ต้องสร้างหรือดูแลโฮสต์สำหรับผลิตภัณฑ์แชตโดยเฉพาะ สิ่งที่ลูกค้าต้องการคือการเข้าถึงผู้ใช้ผ่าน ChatGPT ไม่ใช่ผู้ช่วยอีกตัวที่ทำงานแยกเป็นผลิตภัณฑ์ของตนเอง

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

• เปิดให้เรียกใช้การทำงานของแบ็กเอนด์ผ่านเครื่องมือ MCP โดยใช้การเรียกเครื่องมือตามมาตรฐาน ไม่ใช่รันไทม์เอเจนต์แบบกำหนดเองที่องค์กรเป็นเจ้าของและควบคุมตั้งแต่ต้นจนจบ

• เปิดให้ผู้ใช้ค้นพบเวิร์กโฟลว์ใน ChatGPT เพื่อให้ผู้ใช้เริ่มใช้งานได้จากแพลตฟอร์มที่ตนทำงานอยู่เป็นประจำ

เราตรวจสอบความเหมาะสมของทางเลือกเหล่านี้ร่วมกับลูกค้าตลอดกระบวนการพัฒนา แต่ก็ยังมีสิ่งที่ต้องแลก เมื่อ ChatGPT เป็นผู้โฮสต์เซสชัน คุณจะไม่ได้เป็นเจ้าของรันไทม์ชั้นนอก คุณสามารถชี้แนวทางการทำงานได้ แต่ไม่สามารถควบคุมได้ทั้งหมด

แอปที่สร้างด้วย Apps SDK เชื่อมสามสิ่งเข้าด้วยกัน ได้แก่

1. รันไทม์เอเจนต์ของ ChatGPT

2. เครื่องมือ MCP ของคุณ

3. UI วิดเจ็ตของคุณ

โฟลว์ในการใช้งานจริง

1. ผู้ใช้ขอให้ ChatGPT ทำบางอย่าง

2. ChatGPT อาจเรียกใช้เครื่องมือ MCP รายการใดรายการหนึ่งของคุณ

3. เซิร์ฟเวอร์ของคุณส่งผลลัพธ์จากเครื่องมือในรูปแบบที่มีโครงสร้างกลับมา

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

5. ผู้ใช้โต้ตอบต่อผ่านแชตหรือวิดเจ็ต ซึ่งอาจเป็นข้อความติดตามผล การเลือกตัวเลือก หรือการเรียกใช้เครื่องมือจากวิดเจ็ต การดำเนินการนี้จะอัปเดตเธรด จากนั้น ChatGPT จะเริ่มการทำงานรอบใหม่ และทำขั้นตอนที่ 2–4 ซ้ำจนกว่างานจะเสร็จสิ้น

จุดเด่นของแนวทางนี้คือการทำงานร่วมกันระหว่างแชต การดำเนินการของแบ็กเอนด์ และขั้นตอนสั้นๆ ผ่าน UI ขณะเดียวกัน จุดที่เกิดข้อผิดพลาดได้ง่ายก็คือการส่งต่องานระหว่างแชต เครื่องมือ และ UI

คุณไม่จำเป็นต้องสร้าง UI สำหรับแชต ระบบเชื่อมต่อเครื่องมือ รูปแบบการยืนยันตัวตน หรือโครงวิดเจ็ตขึ้นใหม่ตั้งแต่ต้น สำหรับผลิตภัณฑ์จำนวนมาก วิธีนี้ช่วยลดเวลาในการพัฒนาได้อย่างมาก ทำให้คุณมุ่งเน้นไปที่ตรรกะเฉพาะด้านและมาตรการป้องกันได้

การสร้างผลิตภัณฑ์ภายใน ChatGPT ไม่เหมือนกับการใช้งานเอเจนต์ของคุณเอง ส่วนที่ยากของโปรเจกต์นี้ไม่ใช่เทคนิคการเขียนพรอมต์ แต่คือการกำหนดเครื่องมือ วิดเจ็ต และขั้นตอนถัดไปให้ชัดเจนเพียงพอ เพื่อให้โมเดลกับ UI ทำงานสอดคล้องกัน

Apps SDK ทำให้ผลิตภัณฑ์มีรูปแบบแตกต่างจากฟรอนต์เอนด์ที่คุณใช้อยู่โดยทั่วไป แต่สิ่งสำคัญคือต้องเข้าใจว่าสถานการณ์ใดเหมาะกับ Apps SDK มากที่สุด

ใช้ Apps SDK เมื่อคุณต้องการ

• เปิดตัวเวิร์กโฟลว์ใน ChatGPT อย่างรวดเร็ว

• ให้ ChatGPT เป็นโฮสต์ของการสนทนา

• ผสานภาษาธรรมดาทั่วไปเข้ากับขั้นตอนบน UI ที่มุ่งเน้นชัดเจนเพียงไม่กี่ขั้นตอน

• ไม่ต้องสร้างอินเทอร์เฟซแชต สภาพแวดล้อมสำหรับรันเอเจนต์ และช่องทางให้ผู้ใช้ค้นพบเวิร์กโฟลว์ด้วยตนเอง

ข้อสุดท้ายนี้สำคัญเมื่อผู้ใช้ของคุณทำงานอยู่ใน ChatGPT เป็นประจำแล้ว

สร้างเอเจนต์ของคุณเองเมื่อคุณต้องการ

• โฟลว์แบบทีละขั้นตอนที่ตายตัวและบังคับใช้ได้ด้วยโค้ด

• UI และเส้นทางการยืนยันแบบเฉพาะที่คุณควบคุมเองตั้งแต่ต้นจนจบ

• โมเดลหน่วยความจำและสถานะของคุณเอง

• พฤติกรรมที่ต้องคาดการณ์ได้ทุกครั้งที่ทำงาน

• ข้อมูลการติดตามการทำงาน บันทึกระบบ และตัวชี้วัดของเอเจนต์

หากผลิตภัณฑ์ของคุณประกอบขึ้นจากระบบวางแผน พรอมต์ระบบ และเวิร์กโฟลว์แบบครบวงจร โดยทั่วไปสแต็กที่สร้างขึ้นเองจะตอบโจทย์มากกว่า

ประเด็นสำคัญที่เราพูดถึงอยู่เสมอระหว่างการทำงานกับลูกค้าคือการควบคุม ด้านหนึ่งมีความเร็วและแพลตฟอร์มหลักที่คุ้นเคย ขณะที่อีกด้านคือการมีสิทธิ์ควบคุมรันไทม์เพียงบางส่วน นี่เป็นสิ่งที่ลูกค้ายินดีแลก เมื่อเลือกนำผลิตภัณฑ์ไปเข้าถึงผู้ใช้ภายใน ChatGPT แทนการเป็นเจ้าของสแต็กทั้งหมด

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

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

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

ทำให้การส่งต่องานแต่ละครั้งชัดเจน

เราไม่ได้ปฏิบัติต่อผลลัพธ์ของเครื่องมือเสมือนเป็นข้อมูลดิบจากแบ็กเอนด์อีกต่อไป แต่ถือว่าผลลัพธ์ที่ส่งกลับแต่ละครั้งคือการส่งต่องานไปยังขั้นตอนถัดไป

ผลลัพธ์จากเครื่องมือที่ออกแบบมาอย่างดีควรมีลักษณะดังนี้

• มอบข้อมูลที่วิดเจ็ตต้องใช้ในการแสดงผล

• มอบข้อเท็จจริงที่มีโครงสร้างให้ ChatGPT ใช้เป็นพื้นฐานในการตอบ

• บอกขั้นตอนถัดไปอย่างชัดเจนเมื่อจำเป็น เพื่อไม่ให้โมเดลต้องตัดสินใจด้วยการคาดเดา

การดำเนินการจากวิดเจ็ตไม่ควรส่งข้อความคลุมเครือกลับเข้าไปในเธรด แต่ควรระบุว่าผู้ใช้ทำอะไรและระบบควรดำเนินการอย่างไรต่อ

ความน่าเชื่อถือเพิ่มขึ้นเมื่อการส่งต่องานมีความชัดเจน

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

ด้านล่างคือโครงสร้าง Pydantic ขนาดเล็กที่เราใช้ ฟิลด์ output เก็บข้อมูลแบบมีโครงสร้างที่วิดเจ็ตต้องใช้เมื่อแสดงวิดเจ็ต รวมถึงข้อเท็จจริงที่ ChatGPT ควรใช้ในเซสชัน ส่วนฟิลด์ agent_directions เก็บข้อความสั้นๆ ที่ระบุว่าผู้ช่วยควรทำอะไรต่อ ขณะที่ฟิลด์ reason จะใส่หรือไม่ก็ได้

1from typing import Generic, TypeVar2
3from pydantic import BaseModel4
5T = TypeVar("T")6
7class AgentDirections(BaseModel):8 assistant_instruction: str9 reason: str | None = None10
11class ToolResults(BaseModel, Generic[T]):12 agent_directions: AgentDirections13 output: T

ทำวิดเจ็ตให้เล็กและกระชับ

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

การใช้สรรพนามบุรุษที่สามในข้อความจากวิดเจ็ต

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

ดำเนินการโดยตรงเมื่อขั้นตอนถัดไปชัดเจน

หากปุ่มสื่ออย่างชัดเจนว่าต้องเรียกใช้เครื่องมือใดต่อ การให้วิดเจ็ตดำเนินการเรียกเครื่องมือนั้นทันทีจะมีประสิทธิภาพกว่าการเพิ่มรอบแชตอีกหนึ่งรอบ อย่างไรก็ตาม วิธีนี้ใช้ได้เฉพาะเมื่อการเรียกเครื่องมือครั้งถัดไปไม่ต้องรับข้อมูลจาก ChatGPT

วิธีนี้ช่วยบังคับให้โฟลว์เป็นไปตามที่กำหนด และลดเวลาแฝงได้เพราะไม่ต้องโต้ตอบผ่านแชตอีกรอบ

การจัดการข้อผิดพลาด

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

การจัดการบริบทของเครื่องมือ

เราเก็บสถานะของเซสชันไว้บนเซิร์ฟเวอร์ของเรา ChatGPT จะส่งบริบทเฉพาะเซสชันมาพร้อมกับการเรียกใช้เครื่องมือ ส่วนใน FastMCP เรากำหนดพารามิเตอร์ Context ให้กับเครื่องมือแต่ละรายการ เพื่อให้ตัวจัดการสามารถอ่านและอัปเดตสถานะดังกล่าวได้

• เราเก็บ ID ที่ไม่เปลี่ยนแปลงและผลลัพธ์จากขั้นตอนก่อนหน้าไว้ในเซสชัน จึงไม่ต้องให้ ChatGPT ส่งข้อมูลเดิมไปยังเครื่องมือทุกครั้งที่เรียกใช้

• หากระบบเริ่มเรียกเครื่องมือแบบวนซ้ำ เราจะตรวจจับคำขอที่ซ้ำกันและส่งข้อความแสดงข้อผิดพลาดที่ชัดเจนผ่านผลลัพธ์ของเครื่องมือ

• บันทึกของเซสชันจะถูกเก็บไว้ฝั่งเราเพื่อใช้วิเคราะห์ปัญหาและสนับสนุนผู้ใช้

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

หากไม่มีการส่งต่องานที่ชัดเจน ChatGPT อาจสรุปข้อมูลทั้งที่เราต้องการให้ดำเนินการ ขอให้ผู้ใช้เลือกซ้ำ หรือวางแผนต่อทั้งที่ควรหยุดแล้ว

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

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

เอกสาร Apps SDK ระบุว่าเราสามารถซ่อนเครื่องมือบางรายการไม่ให้ปรากฏในรายการเครื่องมือของเอเจนต์ เพื่อป้องกันไม่ให้เอเจนต์เลือกใช้ แต่ยังคงเรียกเครื่องมือเหล่านั้นผ่านวิดเจ็ตได้ อย่างไรก็ตาม เมื่อเราตั้งค่าการมองเห็นเป็น app-only วิดเจ็ตก็ไม่สามารถเรียกใช้เครื่องมือเหล่านั้นได้เช่นกัน ไม่ใช่แค่เอเจนต์เท่านั้นที่เข้าไม่ถึง สุดท้ายเราไม่สามารถตั้งค่าให้เอเจนต์มองไม่เห็นเครื่องมือ แต่ยังให้วิดเจ็ตเรียกใช้ได้

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

หากเป้าหมายของคุณคือการสร้างเวิร์กโฟลว์ใน ChatGPT โดยลดภาระการพัฒนาแพลตฟอร์มแบบกำหนดเอง Apps SDK ถือเป็นทางเลือกที่ใช้งานได้จริง โดยคุณจะเปิดตัวได้เร็วและเข้าถึงผู้ใช้จากพื้นที่ทำงานเดิม แต่ต้องแลกกับการควบคุมที่ลดลงบางส่วน

หากคุณต้องการเป็นผู้ควบคุมทุกเส้นทางของโฟลว์ UI และเป็นผู้ที่มีหน้าที่ตัดสินใจในแต่ละขั้นตอน ก็ควรวางแผนสร้างสแต็กเอเจนต์ของตนเองตั้งแต่ต้น เพราะเมื่อผลิตภัณฑ์เติบโตขึ้น การพัฒนาภายใน ChatGPT เพียงอย่างเดียวมีแนวโน้มว่าจะไม่เพียงพออีกต่อไป

คุณยังสามารถใช้ Apps SDK เพื่อรันเซิร์ฟเวอร์ MCP ภายใน ChatGPT ก่อนที่จะสร้างระบบแชต การยืนยันตัวตน และโครงสร้างเชื่อมต่อเอเจนต์ด้วยตนเอง แล้วจึงย้ายไปใช้สแต็กของคุณเองเมื่อผลิตภัณฑ์มีความต้องการเพิ่มขึ้น

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