Agentic AI
with Lauren Tan
ถอดบทเรียนจาก pstack: ให้ AI เข้าใจเป้าหมาย เลือกวิธีทำ ลงมือ ตรวจพฤติกรรมจริง และนำข้อผิดพลาดกลับไปปรับระบบ พร้อมแบบแปลน Agentic Work OS สำหรับ Marketing, Sales, HR, Accounting และงานโครงการ
Lauren Tan กับ pstack
จากระบบช่วย Coding Agent ทำงานอย่างเข้มงวด สู่หลักคิดสำหรับงานที่ต้องตรวจสอบผลลัพธ์
Lauren Tan ใช้ชื่อ GitHub ว่า poteto ตัวอย่างที่ศึกษาคือ pstack ใน repository ของ Cursor, poteto/how และ verification-skill-example โครงการต้นทางมุ่งงานวิศวกรรมซอฟต์แวร์ ส่วน Agentic Work OS ในบทความนี้คือข้อเสนอของ Skill360 ที่ดัดแปลงสู่งานธุรกิจ
แนวคิดแกนกลางคือ Skill ทำหน้าที่เฉพาะอย่าง, Playbook กำหนดลำดับงาน, Router เลือกเส้นทางตามโจทย์, Principle กำกับการตัดสินใจ, Verification ตรวจผลที่เกิดจริง และ Learning Loop เปลี่ยนวิธีทำงานเมื่อพบข้อผิดพลาดซ้ำ
Skill คือความสามารถ
กติกาและวิธีทำสำหรับงานหนึ่งประเภท เช่น สืบค้น อธิบาย ทดสอบ หรือส่งต่อ
Playbook คือลำดับ
ร้อยหลายความสามารถตามสถานการณ์ เช่น การตัดสินใจ สร้างฟีเจอร์ หรือรับช่วงโครงการ
Router คือผู้เลือก
ตีความเป้าหมาย ความเสี่ยง ขอบเขต และหลักฐาน ก่อนเลือก Playbook ที่คุ้มค่า
Principle คือหลักกำกับ
หลักที่ใช้ข้ามงาน เช่น พิสูจน์พฤติกรรมจริง แก้ต้นเหตุ และรักษาบริบทให้กระชับ
/poteto-mode, /how, /arena เป็นส่วนของ pstack; /agentic-mode, /aumnuay-mode และ Agentic Work OS เป็นแบบแปลนที่เราเสนอ ยังไม่ได้หมายความว่าติดตั้งใช้งานแล้วกลไกสำคัญของ pstack
/poteto-mode เป็นทางเข้าหลักที่เลือก Playbook แล้วเรียก Skill และ Principle ตามลักษณะงาน
เมื่อรับโจทย์ pstack จะจับงานเข้ากับ Playbook กำหนดรายการขั้นตอน แล้ว route ไปยังความสามารถที่เกี่ยวข้อง เช่น /how, /why, /architect, /arena, /interrogate, /reflect และ /correct โครงสร้างพัฒนาอยู่เสมอ จำนวน Skill หรือ Principle จึงควรตรวจจาก repository ปัจจุบันก่อนนำไปอ้างเป็นตัวเลขตายตัว
| ความสามารถ | หน้าที่ใน pstack | แนวทางใช้กับงานธุรกิจ |
|---|---|---|
| /recall | รื้อฟื้นบริบทจากประวัติงาน | ทำ Current State Brief ก่อนเริ่มต่อ |
| /how และ /why | อธิบายระบบและเหตุผลเดิม | แยก process ที่ทำอยู่จาก rationale ที่เลือกมัน |
| /architect | ทำความเข้าใจ ร่างทางเลือกและขอบเขตก่อนลงมือ | ออกแบบ Data, Process, Role, Interface และจุดรับผิดชอบ |
| /arena | สร้างหลายคำตอบต่อโจทย์เดียว แล้วเลือกและผสมข้อดี | ทดลองแนว Campaign หรือ Offer บนเกณฑ์เดียวกัน |
| /interrogate | ให้ reviewer พยายามหาจุดบกพร่อง | ตรวจ Accuracy, Customer, Risk, Business |
| /reflect และ /correct | เรียนรู้จากงานจริงและแก้ข้อผิดพลาดซ้ำในโครงสร้าง | ปรับ template, rule, checker ไม่เพิ่มเพียงข้อความเตือน |
/how: เข้าใจระบบก่อนเสนอทางแก้
Repository poteto/how มี prompt สำหรับผู้สำรวจและ rubric วิจารณ์งาน ถ้าต้องเข้าใจระบบ Lead จาก Facebook ไป LINE ให้สำรวจ Process, Data, Technology และ People จากหลักฐานที่มี แล้วสังเคราะห์ mental model เดียว การใช้หลาย Agent เหมาะกับโจทย์ใหญ่ที่แยกการสำรวจได้จริง งานเล็กอาจใช้คนเดียว
/arena: แข่งขันคำตอบ ไม่ใช่เพียงแบ่งงาน
Arena ให้ผู้เข้าร่วมหลายรายแก้โจทย์เดียวกัน จากนั้นใช้เกณฑ์ตัดสิน เลือกคำตอบฐาน นำส่วนที่ดีกว่าจากคำตอบอื่นมาผสม และตรวจผลใหม่ ต่างจาก Swarm ซึ่งแบ่งคนละส่วนของงาน เช่น คนหนึ่งดู Data อีกคนดู Process
/architect: เลือกโครงสร้างก่อนผูกมัด
Skill ต้นทางใช้ Ground → Sketch → Agree → Implement → Scrap และกำหนดให้ร่างอย่างน้อยสองทางเลือกที่ต่างกันเชิงโครงสร้าง สำหรับงานธุรกิจแปลเป็นทำแผนที่สภาพจริง → ออกแบบ operating model หลายแบบ → ประเมินความเป็นไปได้ → ลงมือ → ปรับหรือรื้อแบบเมื่อหลักฐานใหม่พิสูจน์ว่าโครงเดิมผิด
Verification ต้องมี Evidence
ไฟล์ถูกสร้างหรือ test ผ่าน ไม่ได้ตอบทุกครั้งว่าผู้ใช้ทำสิ่งที่ตั้งใจได้จริง
verification-skill-example เป็นตัวอย่างแอปสมมติ มี Skill และ Feature Map ที่แยกหนึ่งพื้นที่ของผลิตภัณฑ์ต่อหนึ่งไฟล์: สิ่งนั้นคืออะไร ผู้ใช้เข้าถึงอย่างไร ขับทดสอบอย่างไร และจุดไหนมักทำให้ Agent หลงเชื่อเหตุการณ์ที่ไม่ได้เกิดขึ้นจริง Agent จึงอ่านเฉพาะ feature ที่เกี่ยว โดยไม่ต้องรับเอกสารทั้งระบบเข้าบริบท
เส้นทางที่เกี่ยวอาจรวม success, cancel, error, empty และ persistence หลัง reload หลักฐานเป็น screenshot, DOM assertion, clipboard, network หรือผลการเปิดอีกครั้ง ขอบเขตของข้อสรุปต้องตรงกับสิ่งที่ตรวจจริง
| งาน | การดูผิวเผิน | การตรวจพฤติกรรมจริง |
|---|---|---|
| Landing Page | ข้อความดูดี | CTA, link, form, mobile, pixel/event ทำงาน |
| รายงาน | กราฟสมเหตุสมผล | Source, date range, นิยาม, สูตร และ reconciliation ตรงกัน |
| Automation | Flow มีทุกกล่อง | ข้อมูลปกติ ว่าง ซ้ำ ผิดรูปแบบ retry และ handoff |
| คอนเทนต์ | อ่านลื่น | ตรวจ claim กับแหล่งข้อมูล ลิงก์ ข้อความบังคับ และรูปแบบจริง |
| Training | สไลด์สวย | ผู้เรียนทำงานเป้าหมายได้ และ rubric ให้คะแนนสอดคล้อง |
Definition of Done
ต้องตอบว่า “คาดให้เกิดอะไร”, “เกิดอะไรจริง”, “ตรวจอย่างไร”, “หลักฐานอยู่ที่ไหน” และ “ยังไม่ทราบอะไร” ถ้าตรวจจริงไม่ได้ ให้ระบุ Not Tested ตรง ๆ
แบบแปลน Agentic Work OS
8 Layer ที่เลือกใช้ตามความจำเป็น งานเล็กเดินทางสั้น งานใหญ่เพิ่มการสำรวจ การตรวจ และการส่งต่อ
| Layer | คำถามหลัก | ผลที่ต้องได้ |
|---|---|---|
| 1 Intent | Goal, outcome, constraint, risk คืออะไร? | เกณฑ์สำเร็จและ evidence required |
| 2 Context | รู้อะไรอยู่และเคยตัดสินใจเพราะอะไร? | Current State Brief พร้อมแหล่ง |
| 3 Exploration | มีทางเลือกต่างกันจริงไหม? | Prototype, Arena, Architecture |
| 4 Execution | แบ่งเป็นหน่วยตรวจได้อย่างไร? | Artifact และสถานะรายหน่วย |
| 5 Verification | สิ่งที่สร้างทำงานจริงไหม? | Evidence เทียบเกณฑ์ |
| 6 Review | ผิด เสี่ยง หรือมองข้ามอะไร? | ข้อท้วงติงและการแก้ |
| 7 Learning | รอบหน้าจะดีขึ้นอย่างไร? | Rule, checker, template ที่เปลี่ยน |
| 8 Continuity | ส่งต่อโดยไม่เริ่มใหม่อย่างไร? | Handoff พร้อม next action |
Intent และ Context
/understand แยกเป้าหมาย ผลที่ผู้ใช้ต้องการ ข้อจำกัด หลักฐานและความเสี่ยง /recall ค้นงานเดิม /how ทำความเข้าใจกระบวนการ /why ค้นเหตุผลของการตัดสินใจ ส่วน /research ตรวจข้อมูลภายนอก ถ้าผู้ใช้ขอแผนการตลาด Probiotic ต้องรู้สินค้า กลุ่มเป้าหมาย งบ ช่องทาง ข้อมูลแคมเปญเก่า และตัวชี้วัด หากขาดข้อมูล ให้ระบุสมมติฐานและทำส่วนที่ทำได้ก่อน
Exploration และ Execution
/prototype สร้างตัวอย่างที่ทดลองได้ /arena เสนอหลายทางเลือกที่แก้โจทย์เดียว /architect ออกแบบ Data, Process, Role และ Interface ก่อนผูกมัด ส่วน /execute แบ่ง Campaign เป็น Audience → Offer → Creative → Landing → Tracking → Reporting พร้อมตรวจแต่ละหน่วย
Verification และ Review
/verify ตรวจผลที่เกิดและแนบหลักฐาน /judge เปรียบเทียบทางเลือกด้วย rubric เดียวกัน /review หรือ /interrogate ตรวจความถูกต้อง ประสบการณ์ลูกค้า ความเสี่ยง และผลธุรกิจ ผู้สร้างตรวจตนเองเบื้องต้นได้ แต่ชิ้นงานสำคัญควรมีผู้ตรวจอิสระเห็นหลักฐานต้นทาง
Learning และ Continuity
/reflect เก็บบทเรียน /correct เปลี่ยนข้อผิดพลาดซ้ำเป็นกฎที่บังคับใช้จริง เช่น claim ไม่มีแหล่งให้แสดง “Unknown” /handoff บันทึก Project, Status, Goal, Done, Evidence, Decisions, Why, Files, Open Issues และ Next Action
ระบบที่ดีทำให้คำตอบมีเส้นทางตัดสินใจและหลักฐาน และทำให้ข้อผิดพลาดรอบนี้เปลี่ยนวิธีทำงานรอบหน้าหลักการสังเคราะห์ของ Agentic Work OS
Master Router และ Playbook
ให้ผู้ใช้บอกเป้าหมาย แล้ว /agentic-mode เลือกเส้นทางตามชนิดงานและต้นทุน
| ประเภทงาน | เส้นทางตัวอย่าง | หลักฐาน |
|---|---|---|
| อธิบาย | Recall → How → Why → Explain | ที่มาและสิ่งที่ยังไม่ทราบ |
| ตัดสินใจ | Understand → Research → Options → Judge | เกณฑ์ น้ำหนัก Trade-offs |
| Campaign | Understand → Recall → Research → Arena → Execute → Verify | Brief, ชิ้นงาน, Link/Tracking |
| ปัญหา | Reproduce → Root Cause → Fix → Verify | ก่อน/หลังแก้ |
| โครงการใหญ่ | Architect → Decompose → Execute → Verify → Handoff | สถานะรายหน่วยและชุดรับช่วง |
| ผิดซ้ำ | Correct → Enforce → Retest | Rule ที่แก้และผลทดสอบ |
ลองเลือกโจทย์หนึ่งประเภท
ตัวอย่างนี้แสดง Playbook ที่เหมาะกับโจทย์ โดยยังไม่เรียก Agent หรือเชื่อมข้อมูลจริง
หลักฐาน: ที่มาของข้อมูล และสิ่งที่ยังไม่ทราบ
Skill Set รุ่นแรก
แบบแปลนที่เคยร่างร่วมกันมี 16 ความสามารถ เมื่อนับรวม Router: Core — agentic-mode, understand, recall, research, how, why; Design — prototype, arena, architect; Execution — execute, orchestrate, handoff; Quality — verify, judge, correct; Learning — reflect ทั้งหมดนี้เป็นข้อเสนอที่จะต้องสร้างและทดสอบ
Playbook 12 แบบที่เสนอคือ Investigation, Decision Making, Research, Content Creation, Campaign Creation, Problem Solving, Process Design, Project Execution, Data Analysis, Automation, Long-running Project และ Continuous Improvement งานหนึ่งไม่จำเป็นต้องเรียกทุก Skill
ตัวอย่าง Routing Rule
request:
campaign:
route: [understand, recall, research, arena, execute, verify, judge]
require: [brief, sources, artifacts, link_check, measurement]
decision:
route: [understand, research, options, judge]
require: [criteria, tradeoffs, recommendation]
recurring_error:
route: [correct, enforce, retest]
require: [failure_class, changed_rule, proof]
policy:
parallel_agents: "ใช้เมื่อการเปรียบเทียบหรือแบ่งงานอิสระช่วยจริง"
verified: "ต้องมีหลักฐานจาก outcome ที่ตรวจได้"
handoff: "ใช้กับงานยาวหรือมีผู้รับช่วง"4 ตัวอย่าง งานจริง
สิ่งที่ต่างกันคือข้อมูลตั้งต้น เส้นทาง และหลักฐานที่ต้องเก็บ
Marketing: เปิดตัวสินค้า
ตรวจข้อมูลลูกค้า → Arena เสนอ 2–3 แนวทาง → เลือก Offer → ทำ Creative/Landing → ตรวจ CTA, Form, Pixel → ติดตามผลหลังเปิด
Sales: LINE CRM
แมป Lead และ tag → ออกแบบคำตอบ → ทดลองบทสนทนาปกติและกรณีหลุด → ตรวจ handoff คนและการบันทึก CRM
HR: หลักสูตร AI
ระบุทักษะที่ผู้เรียนต้องทำ → สร้างบทเรียนและแบบฝึก → rubric → ทดลองกับกลุ่มเล็ก → ปรับตามจุดที่ทำไม่ได้
Accounting: กระทบยอด
ระบุแหล่งและรอบบัญชี → ตรวจคุณภาพข้อมูล → จับคู่ → แยก exception → ย้อนกลับเอกสารต้นทาง → ให้ผู้รับผิดชอบอนุมัติ
Campaign Creation แบบละเอียด
- Understand: ระบุผลธุรกิจ กลุ่มเป้าหมาย งบ ช่องทาง Deadline และข้อกำกับ
- Recall + Research: รวบรวมแคมเปญเดิม Customer Evidence และแหล่งอ้างอิง แยก Fact กับสมมติฐาน
- Arena: แนวทาง A เน้นปัญหา B เน้นหลักฐาน C เน้นข้อเสนอ โดยใช้บรีฟและเกณฑ์เดียวกัน
- Judge: เปรียบเทียบ Message Clarity, Differentiation, Feasibility, Risk และ Measurement เลือกฐานและนำจุดเด่นอื่นมารวม
- Execute: ทำ Audience, Offer, Creative, Landing, Tracking และ Reporting เป็นหน่วยที่ตรวจได้
- Verify: เปิดมือถือ คลิก CTA ส่งฟอร์ม ตรวจ Event และตรวจนิยามตัวเลขในรายงาน
- Handoff + Reflect: ส่ง Artifact หลักฐาน สิ่งค้าง ผู้รับผิดชอบ และบทเรียนที่จะเปลี่ยนระบบ
Roadmap 5 ระยะ
เริ่มจากชุดเล็กที่ใช้ได้จริง แล้วเพิ่มความสามารถจากปัญหาที่พบ
แกนหลัก
สร้าง agentic-mode, understand, verify, handoff กำหนด output schema และลองกับงานจริง 2–3 ประเภท
- เกณฑ์ผ่าน: เลือกเส้นทางได้ ส่งผลลัพธ์ หลักฐาน และ next action
บริบท
เพิ่ม recall, research, how, why ระบุแหล่งข้อมูล สิทธิ์ และความใหม่ของข้อมูล
- เกณฑ์ผ่าน: แยกสิ่งที่รู้ สิ่งที่อนุมาน และเหตุผลเดิมได้
ทางเลือก
เพิ่ม arena, architect, judge และ rubric ตามงาน
- เกณฑ์ผ่าน: ทางเลือกต่างกันจริง เหตุผลเลือกตรวจย้อนกลับได้
เรียนรู้
เพิ่ม orchestrate, correct, reflect จากเหตุการณ์จริง
- เกณฑ์ผ่าน: ข้อผิดพลาดซ้ำถูกแก้ด้วย rule หรือ checker และ retest
สไตล์ของคุณ
สร้าง /aumnuay-mode เก็บรูปแบบงานและการตัดสินใจที่ต้องการ แล้ว route ผ่าน Work OS
- เกณฑ์ผ่าน: คุณภาพและหลักฐานสม่ำเสมอข้ามงานโดยผู้ใช้แก้ทิศได้ง่าย
โครงสร้าง Project ที่เสนอ
โครงสร้างนี้เป็นตัวอย่าง ยังต้องปรับตำแหน่ง Skill และคำสั่งให้ตรงกับเครื่องมือที่ติดตั้งจริง
10 หลักการ ทำงาน
หลักที่มีประโยชน์ต้องแปลงเป็นพฤติกรรมที่สังเกตและตรวจได้
| หลักการ | การนำไปใช้ |
|---|---|
| Context Before Action | อ่านข้อมูลเกี่ยวก่อนออกแบบคำตอบ |
| Evidence Before Opinion | แยก Claim, Source, Assumption, Unknown |
| Prototype Before Preference | สร้างตัวอย่างเปรียบเทียบเมื่อทดสอบได้ |
| Explore Before Commit | งานซับซ้อนมีทางเลือกต่างโครงสร้าง |
| Builder ≠ Sole Judge | งานสำคัญมีผู้ตรวจอิสระจากคำสรุปของผู้สร้าง |
| Verify Before Done | สถานะ Done ต้องมี Evidence ตรงเกณฑ์ |
| Fix Root Cause | แก้ต้นเหตุที่ทำให้ผิดซ้ำ |
| Small Verifiable Units | แบ่งงานให้ตรวจระหว่างทาง |
| Guard the Context | ส่งเฉพาะบริบทที่จำเป็นพร้อมที่มา |
| Encode Lessons | เปลี่ยนข้อผิดพลาดซ้ำเป็น rule หรือ checker |
สิบข้อนี้เป็นการเรียบเรียงสำหรับงานทั่วไป บางข้อเชื่อมกับ Principle ของ pstack โดยตรง และบางข้อเป็นข้อสังเคราะห์ของเรา ตัวอย่าง: หาก AI ชอบแต่งข้อมูลลูกค้า อย่าเพิ่มคำว่า “ห้ามเดา” ทุกครั้ง ให้กำหนดสถานะ claim เป็น verified / inferred / unknown และไม่ให้เผยแพร่ claim สำคัญที่ไม่มี source
Prompt เริ่มต้น พร้อมคัดลอก
ใช้ทดลองแนวคิดก่อนสร้าง Skill จริง เครื่องมือจะเรียก Agent หรือ Skill อัตโนมัติได้ต่อเมื่อมีการติดตั้งและสิทธิ์รองรับ
Agentic Work OS
คุณเป็น Master Router ของ Agentic Work OS โจทย์: [ใส่โจทย์] | บริบท: [ไฟล์และข้อมูล] | Outcome: [ผลที่ต้องการ] | ข้อจำกัด: [เวลา/งบ/สิทธิ์] 1. สรุป Goal, เกณฑ์สำเร็จ, Risk และสิ่งที่ยังไม่รู้ 2. เลือก Playbook ให้เหมาะและอธิบายเหตุผลสั้น ๆ 3. ใช้เฉพาะขั้นที่จำเป็น: recall, research, how, why, arena, architect, execute, verify, review, handoff 4. แยก fact, inference, assumption และ unknown ทุก claim สำคัญ 5. ลงมือทำส่วนที่ทำได้ แบ่งงานเป็นหน่วยตรวจได้ 6. ตรวจ outcome จริงและแนบหลักฐาน; อย่าอ้างว่า verified หากไม่ได้ตรวจ 7. ส่ง Artifact, Evidence, Decisions, Open Issues, Next Action 8. ข้อผิดพลาดซ้ำให้เสนอการแก้ rule หรือโครงสร้าง
Campaign Creation
สร้าง Campaign สำหรับ [สินค้า] เป้าหมาย [ยอด/Lead] กลุ่ม [ระบุ] งบ [ระบุ] จากข้อมูล [แหล่ง] เริ่ม Goal และ Customer Evidence; ห้ามสร้างข้อเท็จจริงขึ้นเอง เสนอ 2–3 แนวทางที่ต่างกันจริง เปรียบเทียบ Message Clarity, Differentiation, Feasibility, Risk, Measurement เลือกฐานและผสานข้อดี แล้วทำ Audience, Offer, Creative, Landing, Tracking, Reporting ทีละหน่วย ตรวจ CTA, Link, Form, Event, Mobile และข้อมูลหลังเปิดจริง ส่ง Campaign Brief, Artifact, Evidence Log, Open Issues และ Next Action
Verify Outcome
ตรวจ [Artifact/URL] เทียบกับ [ข้อกำหนด] ระบุสิ่งที่คาดและสิ่งที่เกิดจริง ทดสอบ success, cancel, error, empty, persistence เฉพาะที่เกี่ยวข้อง บันทึกวิธีตรวจ ผล หลักฐาน และสิ่งที่ตรวจไม่ได้ พบข้อผิดพลาดให้แก้และตรวจซ้ำ สรุป Passed / Failed / Not Tested โดยไม่กล่าวเกินหลักฐาน
Handoff Brief
ทำ Handoff โครงการ [ชื่อ] ให้รับช่วงต่อได้ทันที PROJECT: GOAL / SUCCESS CRITERIA: STATUS: DONE + EVIDENCE: DECISIONS + WHY: FILES / URL / VERSION: OPEN ISSUES / RISKS: WHAT HAS NOT BEEN TESTED: NEXT ACTION + OWNER: ใช้ข้อมูลจริงเท่านั้น ระบุ Unknown หากหาไม่พบ
แหล่งอ้างอิงและ ข้อจำกัด
แยกสิ่งที่ repository ระบุจากข้อเสนอของบทความ
- pstack README — ภาพรวม Router, Skills, Principles และ Automations
- poteto-mode SKILL.md — การ route และ Playbook
- poteto/how — Skill อธิบายสถาปัตยกรรมและ prompt/rubric
- verification-skill-example — Feature Map ของแอปสมมติ
- arena SKILL.md — แนวทางแข่งขันและสังเคราะห์คำตอบ
- architect SKILL.md — Ground, Sketch, Agree, Implement, Scrap
- chid/pstack — ตัวอย่าง community port ไปยังเครื่องมืออื่น