Boris Tane ผมกำลังเดิมพันบริษัทของผมกับเอเจนต์เชิงรุก
Explore with AI
เอเจนต์ทำได้แทบทุกอย่างที่คุณขอให้ทำ และนั่นคือปัญหา: คุณยังต้องเป็นฝ่ายขอ
ผมได้ยินคนเรียกเอเจนต์ว่า “เพื่อนร่วมงานดิจิทัล” อยู่เรื่อย กรอบคิดนั้นผิด เพื่อนร่วมงานที่นั่งเงียบจนกว่าคุณจะยื่นงานที่กำหนดขอบเขตไว้อย่างสมบูรณ์ให้ ทำเสร็จ แล้วกลับไปนั่งรอ ไม่ใช่เพื่อนร่วมงาน เอเจนต์ทุกตัวที่คุณเคยใช้ทำงานแบบนี้ทั้งนั้น โมเดลฉลาดขึ้น harness ดีขึ้น การรันยาวขึ้น แต่อินเทอร์เฟซไม่เคยเปลี่ยน: คุณเป็นฝ่ายนำงานมา เอเจนต์เป็นฝ่ายลงแรง
และคนส่วนใหญ่ไม่ทันสังเกต เพราะกล่องพรอมต์ได้กลายเป็นสิ่งที่ AI เป็น ในหัวของเราอย่างเงียบ ๆ
ทุกอินเทอร์เฟซยังคงเป็นกล่องพรอมต์
กล่องรับข้อความคือจุดที่ยุคนี้ทั้งยุคเริ่มต้น ChatGPT วางกล่องนี้ไว้บนโมเดลแล้วกลายเป็นผลิตภัณฑ์ที่เติบโตเร็วที่สุดในประวัติศาสตร์ และเราทุกคนก็ลอกตาม ทุกผลิตภัณฑ์ AI ตั้งแต่นั้นมาคือรูปแบบต่าง ๆ ของการโต้ตอบเดียวกัน: มนุษย์พิมพ์ เครื่องตอบ เครื่องรอ
Claude Code คือวิวัฒนาการขั้นถัดมา เอเจนต์ย้ายเข้ามาในเทอร์มินัลของคุณ หยิบไฟล์ shell และประวัติ git ของคุณ แล้วเริ่มทำงานจริงแทนที่จะแค่พูดถึงมัน มันเปลี่ยนสิ่งที่เอเจนต์ทำได้ แต่ไม่ได้เปลี่ยนวิธีที่มันเริ่ม: คุณพิมพ์ มันทำงาน มันหยุด แล้วมันรอให้คุณพิมพ์อีกครั้ง
แล้วเอเจนต์ก็ย้ายขึ้นคลาวด์ Codex, Devin, Claude Code บนเว็บ พวกมันรันนานเป็นชั่วโมงแทนที่จะเป็นนาที แตก sub-agent เพื่อทำงานคู่ขนาน และไม่ตายเมื่อคุณปิดแล็ปท็อป คุณยื่นงานให้ตัวหนึ่งก่อนมื้อกลางวัน แล้วกลับมาพบ pull request
![graph TD
A[You write the task] --> B[Cloud agent]
B --> C[Sub-agent]
B --> D[Sub-agent]
B --> E[Sub-agent]
C --> F[Pull request]
D --> F
E --> F
style F fill:#d1fae5,stroke:#6ee7b7,color:#065f46](/diagrams/1a98d6cb.svg)
พรอมต์ถึงกับเลิกเป็นเรื่องของคีย์บอร์ดอย่างเดียวแล้ว เอเจนต์เบื้องหลังเริ่มทำงานได้จาก alert หรือ webhook และแพลตฟอร์มเอเจนต์ส่วนใหญ่ตอนนี้มี automation: เมื่อ event นี้เกิด หรือ cron นี้ถึงเวลา ให้รันเอเจนต์ด้วยคำสั่งเหล่านี้
- When
- a Sentry alert fires
- Do
- investigate, open an incident if it's real
- Then
- post the findings to #incidents
แต่ automation คืออะไร มันคือ พรอมต์ที่คุณเขียนไว้ล่วงหน้า คุณคาดการณ์รูปแบบความล้มเหลว เลือก event และเขียนว่าจะทำอย่างไรกับมัน trigger ปลุกเอเจนต์ แต่วิจารณญาณข้างในเป็นของคุณ แข็งค้างอยู่ ณ เวลาที่ตั้งค่า automation จับได้เฉพาะสิ่งที่คุณคาดไว้ และไม่มีอะไรมากกว่านั้น
คุณคือตัวจัดตาราง
ลอกเครื่องมือออกไป แล้วการแบ่งงานก็ไม่ได้ขยับไปไหนในสามปี เอเจนต์ทำงาน การตัดสินว่างานคืออะไรยังเป็นงานของคุณ
คุณอ่านแดชบอร์ด คุณฟังผู้ใช้ คุณหาว่าอะไรสำคัญ และคุณบีบอัดทุกอย่างที่เรียนรู้มาเป็นพรอมต์ ไม่ว่าจะสดที่คีย์บอร์ดหรือล่วงหน้าใน trigger เอเจนต์ลงมือได้ยอดเยี่ยม แต่ทุกชิ้นของวิจารณญาณในระบบมีต้นกำเนิดจากคุณ
![graph TD
A[Dashboards] --> D[You]
B[Alerts] --> D
C[User complaints] --> D
D --> E[The prompt you type today]
D --> F[The automation you configured last month]
E --> G[Agent]
F --> G
style D fill:#fee2e2,stroke:#fca5a5,color:#991b1b](/diagrams/b6e95276.svg)
วิวัฒนาการขั้นถัดไป: เอเจนต์ที่หางานเอง
ผมเดิมพันว่าวิวัฒนาการขั้นถัดไปคือเอเจนต์ที่หาเองว่างานที่ต้องทำคืออะไร ไม่มีพรอมต์ ไม่มี trigger ให้ตั้งค่า ไม่มีคำสั่งที่เขียนไว้ล่วงหน้า คุณเชื่อมต่อ stack ของคุณ แล้วเอเจนต์หางานด้วยตัวเอง: มันเฝ้าดูสัญญาณเดียวกับที่คุณเฝ้าดู สังเกตว่าอะไรผิดปกติ ตัดสินว่ามันสำคัญไหม และเริ่มลงมือทำโดยอัตโนมัติ
พูดง่าย แต่สร้างยากโหด เพราะการเป็นเชิงรุกคือปัญหาสามข้อซ้อนกัน และการข้ามข้อใดข้อหนึ่งให้สิ่งที่แย่กว่าเอเจนต์หลังกล่องรับข้อความ
บริบท แน่นอนว่าเอเจนต์ต้องมีโมเดลสดของโลกที่มันทำงานอยู่ ไม่ใช่ snapshot ที่คุณวางลงใน context window ตอนพิมพ์พรอมต์ เอเจนต์เชิงรับที่มีบริบทแย่ให้คำตอบแย่ เอเจนต์เชิงรุกที่มีบริบทแย่ลบฐานข้อมูล prod ของคุณเพราะคิดว่ามันคือ staging
วิจารณญาณ นี่คือสิ่งที่ทำให้ผมลำบากที่สุด ณ เวลาใดก็ตาม มีสิ่งเป็นพันในระบบ production ที่ผิดปกติเล็กน้อย เอเจนต์ที่ชี้ทั้งหมดคือเครื่องผลิตสัญญาณรบกวน เครื่องผลิตสัญญาณรบกวนถูกปิดเสียง และเอเจนต์ที่ถูกปิดเสียงคือเอเจนต์ที่ตายแล้ว คุณค่าทั้งหมดของการเป็นเชิงรุกอยู่ในช่องว่างระหว่าง “มีอะไรเปลี่ยนไป” กับ “มีอะไรสำคัญ”:
[
{
"signal": "memory up 3% on checkout-edge",
"verdict": "no anomaly",
"reasoning": "within the seasonal range for this hour on this worker"
},
{
"signal": "new error pattern, 2 minutes after deploy 9f3c2a1",
"verdict": "incident",
"reasoning": "error class never seen on this worker, tightly correlated with a deploy"
}
]การลงมือ การสังเกตโดยไม่ลงมือก็แค่ alert ที่ฉลาดขึ้น และ alert คือสิ่งที่ผมพยายามฆ่า เอเจนต์ต้องทำงานให้จบ ภายในขอบเขตที่ทำให้ความเป็นอิสระปลอดภัย: การกระทำที่ย้อนกลับได้ หลักฐานสำหรับทุกอย่าง และด่านที่แน่นหนาก่อนสิ่งที่ย้อนกลับไม่ได้จะเกิดขึ้น
ทั้งสามข้อนี้ไม่มีข้อใดให้เอเจนต์ตัดสินว่า ดีหน้าตาเป็นอย่างไร มันตัดสินว่าอะไรผิดปกติ สำคัญไหม และจะทำอย่างไร แค่นั้นคือรายการทั้งหมด เพราะใน production ไม่มีใครต้องนิยามคำว่าดี: error เป็นศูนย์ latency อยู่ที่ baseline คิวว่าง ใบรับรองใช้ได้ สภาวะที่ต้องการมากับพื้นที่นั้นอยู่แล้ว
ซึ่งหมายความว่าการเปลี่ยนแปลงที่แท้จริงไม่ใช่จาก “คุณพรอมต์” ไปเป็น “เอเจนต์พรอมต์ตัวเอง” แต่คือจาก การปฏิบัติการแบบสั่งเป็นขั้นตอน ไปสู่การปฏิบัติการแบบประกาศสภาวะที่ต้องการ automation คือแบบสั่งเป็นขั้นตอน: คุณไล่รูปแบบความล้มเหลวไว้ล่วงหน้าและเขียนสคริปต์ตอบสนองแต่ละแบบ เอเจนต์เชิงรุกคือลูป reconciliation: มันถือระบบที่คุณมีเทียบกับระบบที่คุณควรมี และทำงานเพื่อปิดช่องว่าง Kubernetes ทำแบบนี้กับโครงสร้างพื้นฐานเมื่อทศวรรษก่อน คุณเขียนว่าสาม replica แล้ว controller ทำทุกอย่างที่ต้องทำเพื่อให้สาม replica มีชีวิตอยู่ ยังไม่มีใครทำแบบนี้กับการดูแลตัวซอฟต์แวร์เอง และที่นี่ไม่มีแม้แต่ YAML ให้เขียน เพราะสภาวะที่ต้องการเป็นที่รู้กันอยู่แล้ว มันทำงานได้ตั้งแต่แกะกล่อง
ผมเริ่มจากงานปฏิบัติการ
ขอให้เอเจนต์เชิงรุกเลือก roadmap ผลิตภัณฑ์ให้คุณ แล้วคุณจะได้เด็กฝึกงานที่มีความเห็นแรง เพราะทิศทางผลิตภัณฑ์เป็นเรื่องของรสนิยม production ไม่ใช่ มันคือโดเมนเดียวที่ปัญหาทั้งสามข้อแก้ได้ในวันนี้
งานประกาศตัวเอง: อัตรา error ไต่ขึ้น deploy ผิดพลาด ใบรับรองหมดอายุ คิวสะสม งานนั่งอยู่ใน telemetry อยู่แล้ว รอให้ใครสักคนสังเกตเห็น และต่างจากโดเมนที่ขับด้วยรสนิยม ความจริงมีอยู่จริง: อัตรา error พุ่งขึ้นหรือไม่พุ่ง rollback คืน baseline หรือไม่คืน วิจารณญาณของเอเจนต์จึงถูกให้คะแนนโดยระบบเอง อย่างต่อเนื่อง โดยไม่มีที่ว่างสำหรับความรู้สึก
ที่สำคัญที่สุด เราจ้างคนทำงานนี้อยู่แล้ว เราเรียกมันว่า on-call: คนที่นอนข้างโทรศัพท์ รอให้เครื่องบอกว่าอีกเครื่องไม่พอใจ ผมใช้เวลาหลายปีใน observability ก่อตั้งบริษัท observability ที่ Cloudflare เข้าซื้อกิจการ และเขียน แถลงการณ์ ทั้งฉบับเรื่องการจัดโครงสร้าง telemetry เพื่อให้คำตอบอยู่ห่างแค่ query เดียว วิทยานิพนธ์ของมันคือเหตุผลที่บริษัทนี้มีอยู่: ในปี 2026 ไม่ควรมีใครต้องอยู่เวร on-call อีก
เพราะความจริงที่อึดอัดเกี่ยวกับทศวรรษที่ผ่านมาของ observability คือเราทำให้ระบบง่ายขึ้นสำหรับมนุษย์ที่จะสอบถามตอนตี 3 แล้วประกาศชัยชนะ ในขณะที่มนุษย์ยังคงเป็นฝ่ายถูกปลุก แดชบอร์ดสวยขึ้น และ pager ยังอยู่บนโต๊ะข้างเตียง observability ที่ไม่มีการลงมือก็แค่ที่เก็บข้อมูลราคาแพง
มันหน้าตาเป็นอย่างไร
นี่คือสิ่งที่ Polylane ทำ นี่คือวันอังคารวันหนึ่งแบบเป็นรูปธรรม:
![graph TD
A["02:14 — checkout p99 jumps from 180ms to 2.1s"] --> B["02:15 — agent flags it: new error pattern, right after the 01:52 deploy"]
B --> C["02:16 — incident opens, 3 hypotheses investigated in parallel"]
C --> D["02:31 — verdict: connection pool exhausted by a new N+1 query"]
D --> R["02:33 — the 01:52 deploy is rolled back, p99 back to 180ms. The incident is over."]
R --> E["02:38 — PR opened with the fix and the evidence attached"]
E --> F["08:30 — you wake up, read the investigation, merge"]
style A fill:#fee2e2,stroke:#fca5a5,color:#991b1b
style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style E fill:#d1fae5,stroke:#6ee7b7,color:#065f46](/diagrams/ff5bb4b7.svg)
ไม่มีใครตั้งค่า check สำหรับรูปแบบความล้มเหลวนี้ ไม่มีกฎให้เขียนและไม่มี threshold ให้ปรับ: เอเจนต์ประเมินทุกทรัพยากรที่เชื่อมต่อตามรอบเวลาอย่างต่อเนื่อง และแดชบอร์ดกับ query ที่คุณบันทึกไว้แล้วกลายเป็นเช็กลิสต์ของพวกมัน วิจารณญาณคือจุดที่ผมเข้มงวดที่สุด คำตัดสินเริ่มต้นคือ ไม่มีความผิดปกติ เพราะการพลาดปัญหาก้ำกึ่งดีกว่าการปลุกใครสักคนเพราะสัญญาณรบกวนมาก “deploy อาจนำบั๊กเข้ามา” เป็นจริงกับทุก deploy และไม่เคยเป็นเหตุให้ page ใคร
เมื่อมีอะไรเป็นของจริง การสืบสวนรันสมมติฐานที่แข่งกันหลายข้อคู่ขนาน และงานของแต่ละเอเจนต์คือหักล้างสมมติฐานของตัวเองแทนที่จะยืนยันมัน ความสัมพันธ์จึงไม่มีทางแอบอ้างเป็นสาเหตุ เมื่อสาเหตุที่แท้จริงที่ยืนยันแล้วคือการเปลี่ยนโค้ด การแก้ไขมาถึงเป็น pull request พร้อมแนบการสืบสวน:
coreplane/checkout-edge Opened by Polylane · gated on review and CI
เชิงรุกไม่ได้แปลว่าไร้การกำกับ
ความเป็นอิสระอยู่ในการสังเกต การ triage การขุดค้นตอนตี 3 และการบรรเทาปัญหา อะไรก็ตามที่คืนสภาวะที่ทราบว่าดี เอเจนต์ทำด้วยตัวเอง: rollback deploy ที่มีปัญหา ปิด flag กลับ การกระทำเหล่านั้นย้อนกลับได้โดยการออกแบบ และเป็นการกระทำที่ทำให้ pager เงียบจริง สิ่งที่ยังมีด่านคืออะไรก็ตามที่สร้างสภาวะใหม่: การเปลี่ยนโค้ดออกไปผ่านการรีวิวและ CI ของคุณ ไม่ใช่อ้อมพวกมัน
เส้นแบ่งไม่ใช่มนุษย์กับเอเจนต์ แต่คือ ย้อนกลับได้กับย้อนกลับไม่ได้ และนี่คือเหตุผลที่คุณไม่ได้แอบอยู่เวร on-call อยู่: rollback ยุติ incident ตอน 02:33 หกชั่วโมงก่อนที่คุณจะ merge pull request PR ไม่เคยเป็นสิ่งที่ห้ามเลือด มันคือสิ่งที่หยุดไม่ให้เกิดซ้ำ และนั่นรอกาแฟได้
และด่านนั้นคุณมอบหมายต่อได้ เอเจนต์รีวิวโค้ดอ่านทุก pull request ใน repo ของคุณอยู่แล้ว มีโลกใบหนึ่ง ไม่ไกลจากใบนี้ ที่เอเจนต์รีวิวของคุณอ่านการแก้ไขตอน 02:41 ตรวจเทียบกับการสืบสวน อนุมัติ และ CI ของคุณ deploy ขึ้น production ก่อนที่คุณจะตื่น ไม่มีอะไรในลูปเปลี่ยนเลยนอกจากใครถือปุ่มอนุมัติ นั่นคือจุดที่เรื่องนี้จบลง: ซอฟต์แวร์ที่แก้ไขตัวเอง โดยคุณเป็นคนเขียนนโยบายแทนการคลิก merge
![graph TD
A[Signals] --> B[Detection]
B --> C[Investigation]
C --> R[Rollback, on its own]
C --> D[Pull request]
D --> E[You or your agent review, it merges]
R --> F[Memory]
E --> F
F --> B
style R fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style D fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style F fill:#dbeafe,stroke:#93c5fd,color:#1e40af](/diagrams/b1056731.svg)
สังเกตว่าอะไรหายไปจากลูปนั้น:
กล่องพรอมต์เป็นวิธีที่ดีมากในการเรียนรู้ที่จะไว้ใจระบบเหล่านี้ และเป็นวิธีที่แย่มากในการดูแล production เอเจนต์ได้เห็นทุก deploy ทุกบรรทัด log และทุก metric ทั่วทุก service พร้อมกัน การเก็บมันไว้หลังพรอมต์หมายความว่าสมาชิกที่รู้ข้อมูลดีที่สุดในทีมของคุณพูดเฉพาะเมื่อถูกถาม
ในปี 2026 ไม่ควรมีใครต้องอยู่เวร on-call อีก