Automation 3.0 Blueprint: จาก Prompt สู่ Business OS ที่รันได้จริง

By Data Espresso / 09/08/2026

Automation 3.0 — natural language becomes the automation layer

เนื้อหาในบทความนี้

Automation 3.0 คืออะไร และทำไมต้องมี Blueprint

Automation 3.0 คือกรอบออกแบบงานแบบ agent-first ที่ผมเสนอขึ้นเพื่อต่อยอดแนวคิด Software 3.0: ถ้าภาษาคนเริ่มใช้ program ระบบได้ ภาษาคนก็ควรเริ่มใช้กำหนด operation ที่ทำงานต่อเนื่องได้เช่นกัน แต่ prompt อย่างเดียวไม่พอครับ ระบบต้องมี context, tools, permission, approval, proof และ memory รองรับ จึงจะเปลี่ยนจาก AI ที่ผลิต output เป็น Business OS ที่ทำให้งานเดินจริง

หลังจากผมทำ เว็บไซต์ Automation 3.0 และเขียน eBook Business OS for the Agent-first Era จบ ผมกลับมาถามคำถามที่เข้มกว่าเดิมว่า ถ้าตัดคำเท่ ๆ อย่าง AI Agent, autonomy และ multi-agent ออกทั้งหมด สิ่งที่ต้องเหลืออยู่เพื่อให้ระบบใช้งานจริงคืออะไร?

บทความก่อนหน้าเรื่อง Software 3.0 และ Automation 3.0 วางภาพรวมของ paradigm ไว้แล้ว บทความนี้จึงไม่เล่าซ้ำ แต่ลงลึกเป็น implementation blueprint: อะไรควรเป็น deterministic workflow, อะไรควรให้ agent ตัดสินใจ, ต้องวาง control ไว้ตรงไหน และควรวัดผลอย่างไร

ก่อนเริ่ม ผมขอระบุให้ชัดว่า Automation 3.0 ในที่นี้เป็นกรอบแนวคิดที่ Data-Espresso เสนอ ไม่ใช่มาตรฐานอุตสาหกรรมหรือ version ทางการของ automation จุดประสงค์คือสร้างภาษากลางสำหรับออกแบบงานยุค agent-first และเปิดให้ทดสอบ โต้แย้ง และปรับปรุงได้

1. Automation 3.0 ไม่ได้แทน Automation 1.0 และ 2.0

จุดตั้งต้นของกรอบนี้มาจาก keynote Software Is Changing (Again) ของ Andrej Karpathy ที่อธิบายว่า LLM ทำให้ prompt และภาษาคนกลายเป็นวิธี program computer อีกรูปแบบหนึ่ง พร้อมย้ำเรื่อง partial autonomy, human verification และการเลือกระดับ autonomy ให้เหมาะกับงาน

ผมแปลงภาพนั้นมาเป็น automation สามชั้น:

Automation 1.0 — Trigger → Action: rule, script, cron และ workflow ที่ deterministic
Automation 2.0 — Trigger → AI Node → Action: workflow เดิมที่เพิ่ม LLM เพื่อสรุป แยกประเภท ดึงข้อมูล หรือสร้างข้อความ
Automation 3.0 — Goal → Context → Plan → Tools → Approval → Proof → Memory: agent เลือก next action ตาม state ของงาน ภายใต้ policy ที่มนุษย์กำหนด

ชั้นที่สามไม่ได้ทำให้สองชั้นแรกหมดค่า ตรงกันข้ามเลยครับ ระบบที่ดีมักเป็น hybrid: agent รับมือ ambiguity และ exception ส่วน code, scheduler, workflow engine และ database constraint รักษาส่วนที่ต้องแน่นอน

Anthropic แยก workflow กับ agent ไว้ชัดเจนว่า workflow เดินตาม code path ที่กำหนด ส่วน agent เป็นฝ่ายกำกับกระบวนการและการใช้ tools แบบ dynamic มากกว่า และแนะนำให้เริ่มจากวิธีที่ง่ายที่สุดก่อนเพิ่มความซับซ้อน OpenAI ก็เสนอเกณฑ์คล้ายกัน: ถ้างาน deterministic พอ ระบบแบบเดิมอาจเหมาะกว่า agent

Rule ที่ผมใช้: ถ้าเราวาดเส้นทางได้ครบและ exception มีน้อย ให้ใช้ workflow ถ้าจำนวน step, tool หรือ path ขึ้นกับ context ของแต่ละเคส จึงค่อยพิจารณา agent

2. จุดเปลี่ยนจริงคือ Outcome + Boundary

Automation แบบเดิมถามว่า “เมื่อ event นี้เกิด ต้องรัน step อะไรต่อ?” ส่วน Automation 3.0 ถามว่า “ผลลัพธ์ที่ต้องการคืออะไร และ agent เดินได้ไกลแค่ไหน?”

ตัวอย่างจาก demo ในโปรเจกต์คือ Weekday Support Brief เป้าหมายไม่ใช่แค่ดึง ticket แล้วส่งข้อความ แต่คือ:

อ่าน support ticket ใหม่ทุกวันทำงาน
สรุปเคสเร่งด่วนและเตรียม draft fix
ห้ามแก้ production
ต้องขอ approval ก่อนส่ง brief
จบงานด้วยจำนวน ticket, รายการ urgent, draft ที่สร้าง และสถานะ approval

สังเกตว่าคำสั่งนี้กำหนดทั้ง outcome และ boundary การมี boundary ไม่ได้ลดความสามารถของ agent แต่ทำให้ autonomy ใช้งานได้จริง เพราะทีมรู้ว่าระบบจะไม่ข้ามเส้นใด

3. Prompt ต้องกลายเป็น Versioned Operation Contract

ข้อผิดพลาดที่ผมเห็นบ่อยคือเอา prompt ใน chat ไปตั้ง schedule แล้วเรียกสิ่งนั้นว่า production automation ถ้าจะให้ instruction เป็น source of truth จริง มันต้องมีโครงสร้างที่ review, test, version และ rollback ได้

ตัวอย่าง contract ขั้นต่ำ:

name: weekday-support-brief
goal: สรุป ticket ใหม่และเตรียม draft fix ให้ทีมตัดสินใจ
trigger: weekdays 08:30 Asia/Bangkok
source_of_truth:
  - support_queue
  - customer_history
allowed_tools:
  - tickets.read
  - repo.read
  - patch.draft
denied_tools:
  - production.write
approval:
  - before: brief.send
stop_conditions:
  - missing_customer_consent
  - more_than_3_failed_tool_calls
  - budget_exceeded
proof:
  - ticket_ids
  - urgency_reasons
  - draft_diff
  - approval_record
memory_write:
  - validated_support_pattern
budget:
  max_turns: 20
  max_cost_usd: 2

Contract แบบนี้ไม่จำเป็นต้องใช้ YAML เสมอไป จะเป็น markdown, JSON, database record หรือ policy DSL ก็ได้ ประเด็นคือทีมต้องตอบได้ว่า instruction version ไหนเป็นตัวรัน ใครแก้ ผ่าน eval ชุดไหน และถ้าพังจะ rollback อย่างไร

4. Context Engineering สำคัญกว่า Prompt ที่ยาวขึ้น

Agent ที่เก่งแต่ได้รับ context ผิดก็ทำงานผิดได้อย่างมั่นใจ ปัญหาจึงไม่ใช่แค่ “เขียน prompt ยังไง” แต่คือ “ในแต่ละ step ระบบควรส่งข้อมูลอะไรให้ model เห็น”

Anthropic อธิบาย context engineering ว่าเป็นการ curate state ทั้งหมดที่ model ใช้ ไม่ว่าจะเป็น instruction, tools, MCP, external data และ message history พร้อมชี้ว่าบริบทเป็นทรัพยากรจำกัด ข้อมูลมากขึ้นอาจทำให้ focus ลดลงได้

ผมจึงออกแบบ context เป็นสี่ชั้น:

Stable policy: บทบาท ขอบเขต brand rule และสิ่งที่ห้ามทำ
Task state: goal, current step, pending approval และสิ่งที่ทำไปแล้ว
Just-in-time context: ข้อมูลที่ agent เรียกเมื่อจำเป็น เช่น customer record หรือ pricing rule
Source reference: URI, record ID, version และ timestamp ที่ย้อนกลับไปตรวจได้

อย่าเอา chat history มาแทน source of truth ครับ Customer state ควรอยู่ CRM, task state ควรอยู่ workflow store, policy ควรอยู่ versioned document และ memory ควรเก็บเฉพาะสิ่งที่ผ่าน validation แล้ว

5. Tools คือ Permission Surface

การต่อ API หรือ MCP ทำให้ agent “มีมือ” แต่ทุกมือคือสิทธิ์ที่ต้องออกแบบ เอกสาร MCP อธิบาย ว่า tools เป็น schema-defined operation ที่ model เลือกเรียกได้ และแนะนำกลไกอย่าง approval dialog, permission setting และ activity log เพื่อรักษาการควบคุมของผู้ใช้

หลักที่ผมใช้มีห้าข้อ:

แยก read ออกจาก write ให้ชัด
แยก draft ออกจาก send/publish
ให้ permission ต่ำสุดที่ทำให้งานสำเร็จ
Tool ต้องมี input/output แบบ typed และ description ที่ไม่กำกวม
Validation กับ approval ต้องวางติดกับ tool ที่สร้าง side effect

MCP ทำให้การเชื่อม tools เป็นมาตรฐานขึ้น แต่ไม่ได้ทำให้ระบบปลอดภัยโดยอัตโนมัติ MCP Security Best Practices ยังเตือนเรื่อง consent, token audience, token passthrough, SSRF และ audit trail ดังนั้น “ต่อ MCP ได้” กับ “พร้อมใช้ใน production” เป็นคนละประโยคครับ

6. Autonomy ต้องเป็น Slider ตามความเสี่ยง

ผมไม่ใช้คำว่า auto หรือ manual แบบ binary เพราะ action แต่ละชนิดมีความเสี่ยงไม่เท่ากัน ระดับที่ใช้งานง่ายมีห้าขั้น:

Suggest: วิเคราะห์และเสนอ next action
Draft: สร้าง artifact แต่ยังไม่ส่งออก
Act with proof: ทำ action ที่ย้อนกลับได้ พร้อมหลักฐาน
Ask before action: หยุดก่อน side effect สำคัญ
Never auto: ห้ามระบบทำเองในบริบทนี้

ตัวอย่างการ map:

อ่าน dashboard และจัดลำดับ lead → Suggest หรือ Act with proof
ร่าง follow-up email → Draft
อัปเดต tag ใน CRM → Act with proof หาก rollback ได้
ส่ง email, publish, refund, spend, delete หรือแก้ production → Ask before action
การตัดสินใจทางการแพทย์ กฎหมาย หรือ commitment ที่เกิน policy → Never auto หรือส่งต่อผู้เชี่ยวชาญ

NIST Generative AI Profile เสนอให้บริหารความเสี่ยงตาม use case ตลอด lifecycle และระบุความเสี่ยงอย่าง confabulation, data privacy, information security, human-AI configuration และการเชื่อม component ใน value chain ประเด็นสำคัญคือ autonomy ต้องอิงผลกระทบและความย้อนกลับได้ ไม่ใช่อิงความมั่นใจของ model เพียงอย่างเดียว

7. Approval Gate ต้องอยู่ก่อน Side Effect

ถ้าระบบส่ง email ไปแล้วค่อยให้คนตรวจ นั่นไม่ใช่ approval ครับ มันคือ incident review

OpenAI แยก guardrail กับ human review ไว้เป็นสองหน้าที่: guardrail ตรวจ input, output หรือ tool behavior อัตโนมัติ ส่วน human review ทำให้ run หยุดเพื่อ approve หรือ reject action ที่ละเอียดอ่อน จากนั้น resume state เดิมได้

Approval ที่ดีควรแสดงอย่างน้อย:

ระบบกำลังจะทำอะไร กับใคร หรือกับ record ไหน
ใช้ข้อมูลและ policy ใดตัดสินใจ
ผลกระทบและความย้อนกลับได้
preview หรือ diff ของสิ่งที่จะเปลี่ยน
ปุ่ม approve, reject และ request changes
อายุของ approval เพราะข้อมูลอาจเปลี่ยนระหว่างรอ

สำหรับ action เสี่ยง ผมชอบ policy ที่ fail closed: ถ้า approval service ล่ม ระบบต้องหยุด ไม่ใช่ตีความว่าอนุมัติ

8. Proof Standard: ถ้าไม่มีหลักฐาน ยังไม่ถือว่า Done

ประโยค “ทำเสร็จแล้วครับ” ไม่มีค่าเพียงพอในระบบ operation หลักฐานต้องผูกกับ success criterion ของงาน

Proof อาจเป็น:

source link และ record ID
diff หรือ before/after
test result และ validation result
preview URL
tool execution log
approval record
delivery receipt
rollback reference

Proof ทำหน้าที่สองอย่างพร้อมกัน อย่างแรกคือช่วยให้คน review เร็วขึ้น อย่างที่สองคือเป็น dataset สำหรับ eval รอบถัดไป เช่น ถ้า agent รายงานว่าส่ง brief สำเร็จ แต่ไม่มี delivery receipt เราสามารถนับเป็น false completion ได้ทันที

Karpathy เน้นว่าระบบที่มี autonomy บางส่วนต้องทำให้มนุษย์ verify งานได้เร็ว Automation 3.0 จึงไม่ควรพยายามเอาคนออกจาก loop ทุกจุด แต่ควรลดต้นทุนของ verification จนคนกำกับงานจำนวนมากขึ้นได้โดยไม่กลายเป็นคอขวด

9. Production ต้องมี State, Trace, Budget และ Eval

Agent demo มักสวยเพราะเห็น happy path เพียงครั้งเดียว ส่วน production ต้องรับมือ timeout, partial failure, duplicate event, stale context, model change และ tool ที่ล่มกลางงาน

อย่างน้อยระบบควรมี:

Durable state: pause/resume ได้ และรู้ว่า step ไหนเสร็จแล้ว
Idempotency: retry แล้วไม่ส่งซ้ำหรือหักเงินซ้ำ
Stop conditions: maximum turns, timeout, cost budget และ failure threshold
Tracing: เห็น model call, tool call, handoff, guardrail และ approval
Eval: ทดสอบ outcome และ policy compliance ด้วยเคสจริง
Incident path: escalate, rollback และบันทึก lesson learned

OpenAI แนะนำ tracing เพื่อดู run, model call, tool call, handoff และ guardrail แบบ end-to-end แล้วนำ trace ที่มีสัญญาณดีไปสร้าง eval ต่อ

Metric ที่ผมอยากเห็นไม่ใช่แค่ token หรือจำนวนงานที่ agent รับ แต่คือ:

Successful completion rate
Proof completeness rate
Human override และ rejection rate
Unsafe tool attempt rate
Cost per successful run
Median cycle time เทียบ baseline เดิม
Rework และ rollback rate
Context freshness incident

ถ้าเร็วขึ้นแต่คนต้องตามแก้มากขึ้น นั่นไม่ใช่ automation ที่ดีครับ มันแค่ย้ายงานไปซ่อนหลังหน้าจอ AI

10. วิธีเริ่ม Automation 3.0 Pilot ภายใน 4 สัปดาห์

อย่าเริ่มด้วยโจทย์ “สร้าง AI ให้ทำทุกอย่าง” เลือกหนึ่ง workflow ที่ volume พอ มี success criterion ชัด และความเสี่ยงไม่สูงก่อน

สัปดาห์ 1 — Map งานและตั้ง Baseline

ระบุ owner, goal, input, source of truth และ definition of done
แยก deterministic step ออกจาก judgment step
วัด cycle time, error, rework และ handoff ปัจจุบัน
ระบุ action ที่ย้อนกลับยากและข้อมูลอ่อนไหว

สัปดาห์ 2 — ทำ Draft-only Sandbox

ให้ agent อ่านข้อมูลจำลองหรือข้อมูลที่จำกัด scope
อนุญาตเฉพาะ read และ draft tools
บันทึก trace ทุก run
สร้าง eval จากเคสปกติ, edge case และ malicious input

สัปดาห์ 3 — Pilot กับทีมเล็ก

ใช้ข้อมูลจริงเฉพาะส่วนที่จำเป็น
ให้ approval ทุก write/send action
บังคับ proof ก่อนปิดงาน
เก็บเหตุผลที่คน reject หรือแก้ output

สัปดาห์ 4 — Review ก่อนเพิ่ม Autonomy

เทียบ metric กับ baseline
แก้ failure ที่เกิดซ้ำก่อนเพิ่ม tool
เลื่อนเฉพาะ action ความเสี่ยงต่ำจาก approval ไป act with proof
กำหนด rollback, incident owner และรอบ review ถัดไป

เกณฑ์ผ่าน pilot ของผมไม่ใช่ “agent ทำงานได้หนึ่งครั้ง” แต่คือ “ทีมอธิบายได้ว่ามันพลาดตรงไหน หยุดอย่างไร ตรวจอย่างไร และคุ้มกว่าวิธีเดิมหรือไม่”

Automation 3.0 Stack ไม่ใช่ Tool เดียว

ของจริงมักประกอบจากหลายชั้น:

Intent และ policy
Trigger และ durable workflow
Agent runtime และ model
Context retrieval และ memory
APIs, MCP, browser หรือ computer-use tools
Permission และ approval service
Trace, eval และ proof store

ผมรวบรวม open-source building blocks แยกตามชั้นไว้ใน Awesome Automation 3.0 ตั้งแต่ agent runtime, orchestration, durable execution, MCP, sandbox, memory ไปจนถึง observability และ human approval จุดประสงค์ไม่ใช่ให้ติดตั้งทุกอย่าง แต่ช่วยเลือกส่วนประกอบที่พอดีกับ loop แรก

สรุป: Automate the Outcome, Not the Diagram

Automation 3.0 ไม่ได้ชนะเพราะ prompt เขียนง่ายกว่า workflow diagram มันจะมีค่าก็ต่อเมื่อทำให้งานที่มี ambiguity เดินต่อได้ โดยมนุษย์ยังควบคุมความเสี่ยง ตรวจสอบผลลัพธ์ และสะสมความรู้กลับเข้าระบบได้

แกนของ Business OS จึงไม่ใช่ model ตัวไหนเก่งที่สุด แต่คือ loop นี้:

Goal → Context → Plan → Tools → Approval → Proof → Memory

ถ้าจะเริ่มพรุ่งนี้ อย่าถามก่อนว่า “ควรใช้ agent framework ตัวไหน?” ให้ถามว่า “workflow ไหนมี outcome ชัด, context ชัด, gate ชัด และ proof ชัดพอที่จะเป็น Business OS loop แรก?”

ทดลอง concept, interactive demo และอ่าน eBook ภาษาไทยฟรีได้ที่ automation-3.com ส่วนคนที่อยากลงรายละเอียดกรอบ Business OS เปิดอ่านได้ตรงที่ eBook

คำถามที่พบบ่อย (FAQ)

Q: Automation 3.0 เป็นมาตรฐานใหม่ของวงการหรือไม่?

A: ไม่ใช่ครับ ในบทความนี้ Automation 3.0 เป็นกรอบแนวคิดที่ Data-Espresso เสนอเพื่อต่อยอด Software 3.0 ไปสู่การออกแบบงานแบบ agent-first เป้าหมายคือสร้าง mental model ที่นำไปทดลองและปรับปรุงได้

Q: Automation 3.0 จะมาแทน n8n, Make, Zapier หรือ RPA หรือไม่?

A: ไม่แทน งานที่มี path ชัดยังเหมาะกับ deterministic workflow มากกว่า Agent ควรเข้ามารับส่วนที่ต้องอ่าน context, ใช้ judgment หรือจัดการ exception และสามารถใช้ n8n หรือ workflow engine เป็น trigger และ durable runtime ได้

Q: ธุรกิจ SME ควรเริ่มจาก workflow แบบไหน?

A: เริ่มจากงานที่เกิดซ้ำ มีข้อมูลพร้อม วัดผลได้ และ side effect ต่ำ เช่น daily lead brief, support triage หรือ proposal draft หลีกเลี่ยงการเริ่มจาก payment, deletion, production change หรือคำแนะนำความเสี่ยงสูง

Q: ต้องใช้ multi-agent ตั้งแต่แรกหรือไม่?

A: ไม่จำเป็น Agent เดียวที่มี tools ชัดและ eval ดีมักเริ่มได้เร็วกว่า เพิ่มหลาย agent เมื่อ prompt ซับซ้อนเกินดูแล, tool overlap ทำให้เลือกผิดบ่อย หรือมี domain boundary ที่ควรแยกจริง

Q: จะรู้ได้อย่างไรว่าควรเพิ่ม autonomy?

A: เพิ่มเมื่อ trace และ eval แสดงว่า action เดิมสำเร็จสม่ำเสมอ, proof ครบ, human rejection ต่ำ และ rollback ทำได้ โดยเลื่อนทีละ action ไม่ใช่เปิด autonomy ให้ทั้งระบบพร้อมกัน

แหล่งอ้างอิงสำหรับศึกษาต่อ

อ่านแล้ว: 37

Leave a Comment Cancel Reply

คุณต้องเข้าสู่ระบบ เพื่อจะพิมพ์ความเห็น

สอบถามข้อมูล