Claude Code Dynamic Workflows: เมื่อ AI Agent ไม่ได้แค่ทำงาน แต่เริ่มสร้าง Harness ของงานเอง

Anthropic เพิ่งเผยแพร่บทความของ Thariq Shihipar และ Sid Bidasaria เรื่อง “A harness for every task: dynamic workflows in Claude Code”

ถ้าอ่านแบบผิวเผิน ข่าวนี้อาจดูเหมือนอีก feature หนึ่งของ Claude Code

แต่ผมว่าเรื่องนี้สำคัญกว่านั้นครับ

เพราะมันกำลังชี้ว่า AI Agent ที่ทำงานจริงในองค์กร ไม่ควรถูกมองเป็น “คนตอบ prompt ยาว ๆ” อีกต่อไป

มันเริ่มต้องมี harness

คำว่า harness ในที่นี้คือระบบรอบตัว agent:

วิธีแตกงาน วิธี spawn subagents วิธีแยก context วิธีเลือก model วิธีแยก worktree วิธีตรวจผลลัพธ์ วิธีวนซ้ำจนผ่านเงื่อนไข วิธีจำกัด token วิธีหยุดเมื่อพอ และวิธีส่ง proof กลับมาให้มนุษย์ตัดสิน

นี่คือคนละระดับกับการบอก AI ว่า “ช่วยทำงานนี้ให้หน่อย”

มันใกล้กับการบอกว่า “สร้างกระบวนการทำงานเล็ก ๆ สำหรับงานนี้ แล้วรันมันให้จบพร้อมหลักฐาน”

1) เกิดอะไรขึ้น

Dynamic workflows ใน Claude Code คือความสามารถที่ให้ Claude เขียน orchestration script แบบ JavaScript ขึ้นมาตามงานที่ผู้ใช้ต้องการ

script นี้ไม่ได้ทำงานแทน agent ทั้งหมด

มันทำหน้าที่คุมการประสานงาน:

แตกงานเป็น subtask spawn subagents เก็บผลลัพธ์กลางไว้ในตัวแปรของ script กำหนด loop และ branching ให้ agent แต่ละตัวทำงานใน context แยกกัน บางกรณีให้ทำงานใน worktree แยกกัน แล้วค่อย synthesize กลับมาเป็นคำตอบหรือผลลัพธ์เดียว

ในเอกสารของ Claude Code อธิบายไว้ชัดว่า workflow ต่างจาก subagents, skills และ agent teams ตรงที่ “แผน” ไม่ได้อยู่ใน context window ของ Claude เป็นหลัก

แผนถูกย้ายไปอยู่ใน code

นี่เป็นประโยคสำคัญมากครับ

เพราะปัญหาของ AI Agent ในงานใหญ่จำนวนมาก ไม่ใช่แค่มันฉลาดพอไหม

แต่คือมันถือแผนได้นานพอไหม มันจำ constraint ได้ครบไหม มันตรวจตัวเองอย่างเป็นกลางพอไหม มันรู้ไหมว่าควรหยุดเมื่อไร และมันไม่หลุดไปทำอย่างอื่นระหว่างทางไหม

Anthropic ระบุ failure modes ไว้ 3 แบบที่ dynamic workflows ช่วยลด:

1. agentic laziness

คือ agent ทำงานได้บางส่วน แล้วประกาศว่างานเสร็จ ทั้งที่งานใหญ่ยังเหลืออีกเยอะ

1. self-preferential bias

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

1. goal drift

คือเป้าหมายเริ่มเพี้ยนเมื่อคุยยาว ทำหลาย turn หรือผ่าน compaction แล้ว detail บางอย่างหายไป

ฟังดูเทคนิคมาก แต่คนที่เคยใช้ AI ทำงานจริงจะรู้ว่าเจอหมดครับ

สั่งให้ตรวจ 50 รายการ ตรวจได้ 23 รายการแล้วสรุปว่าเสร็จ ให้ verify claim ในบทความ แล้วมันเช็คแบบผิว ๆ ให้แก้ bug ยาว ๆ แล้วท้าย session ลืม constraint สำคัญที่เราบอกไว้ต้นทาง

Dynamic workflow คือวิธีบังคับให้ปัญหาเหล่านี้ถูกแก้ด้วยโครงสร้าง ไม่ใช่ด้วยการหวังว่า prompt จะดีพอ

2) ทำไมมันสำคัญกว่าการเพิ่ม subagents

หลายคนอาจอ่านแล้วสรุปว่า dynamic workflows คือการใช้ subagents เยอะขึ้น

ผมว่าไม่ใช่ครับ

ถ้ามี agent เยอะ แต่ไม่มี harness เราแค่ได้ความมั่วแบบขนาน

คุณอาจมี agent 20 ตัว แต่ไม่มีใครถือ rubric ไม่มีใครตรวจกันเอง ไม่มี stop condition ไม่มี budget ไม่มี quarantine สำหรับข้อมูล untrusted ไม่มี proof format ที่ชัด ไม่มีคนรวมผลลัพธ์ด้วยเกณฑ์เดียวกัน

แบบนั้นยิ่งขนาน ยิ่งเสี่ยง

สาระของ dynamic workflows คือ workflow script เป็นตัวถือโครงสร้าง

มันรู้ว่าอะไรต้อง fan out อะไรต้องรอ barrier อะไรต้องให้ verifier ตรวจ อะไรต้องใช้ tournament อะไรต้อง loop until done อะไรต้อง route model ตามความซับซ้อน และอะไรควรถูกหยุดเพราะ token หรือ scope เกิน

Thariq ยก pattern หลายแบบที่น่าสนใจ:

• classify-and-act: ใช้ classifier agent ตัดสินประเภทของ task แล้ว route ต่อ
• fan-out-and-synthesize: แตกงานย่อยจำนวนมาก แล้ว merge ผลลัพธ์กลับมา
• adversarial verification: ให้ agent อีกตัวท้าทายหรือตรวจผลลัพธ์ของ agent แรก
• generate-and-filter: สร้างหลายทางเลือก แล้วคัดด้วย rubric
• tournament: ให้หลาย agent แข่งกันทำงานเดียว แล้วตัดสินแบบ pairwise
• loop until done: วนซ้ำจนไม่มี finding ใหม่ หรือ error หมดจริง ๆ

นี่คือ operating patterns ไม่ใช่ prompt tricks

และถ้าแปลเป็นภาษาธุรกิจ มันคือวิธีเอา AI มาอยู่ใน process ที่วัดผลได้

3) ตัวอย่างที่ทำให้เห็นภาพ

ใน launch article ก่อนหน้า Anthropic บอกว่า dynamic workflows สามารถรัน tens to hundreds of parallel subagents ใน session เดียว

ตัวอย่างใหญ่คือกรณี Bun ที่ Jarred Sumner ใช้ dynamic workflows เพื่อ port Bun จาก Zig เป็น Rust

Anthropic ระบุว่าได้ Rust ประมาณ 750,000 lines, test suite เดิมผ่าน 99.8%, และใช้เวลา 11 วันจาก first commit ถึง merge

ต้องอ่านอย่างระวังนะครับ

Anthropic เองก็บอกว่างานนี้ยังไม่ production ดังนั้นอย่าเอาไปสรุปง่าย ๆ ว่า AI เขียนระบบใหญ่แทนทีมได้แล้ว

แต่มันเป็น proof ที่ดีมากว่า งาน migration ที่ใหญ่จนคนปกติไม่อยากแตะ สามารถถูกแตกเป็น workflow ที่มี agent หลายตัวทำงานพร้อมกันได้

workflow หนึ่ง map Rust lifetime ให้ struct field จาก Zig codebase workflow ต่อมาเขียน .rs file ให้ behavior เหมือน .zig counterpart มี reviewer สองตัวต่อไฟล์ แล้วมี fix loop รัน build และ test จนผ่าน

ถ้ามองในเชิงระบบ สิ่งที่สำคัญไม่ใช่จำนวนบรรทัด code

สิ่งที่สำคัญคือ pattern:

แตกพื้นที่ทำงาน แยก worktree ให้ agent ทำงานเฉพาะจุด มี reviewer มี build และ test เป็น proof วนจน stop condition ผ่าน แล้วค่อยให้มนุษย์ review ขั้นสุดท้าย

นี่คือ AI ในฐานะ workforce orchestration ไม่ใช่ autocomplete

4) ทำไมเรื่องนี้เกี่ยวกับ SME ไทย

หลายคนอาจบอกว่า “นี่เป็น feature ของ Claude Code สำหรับ engineer”

ใช่ครับ เริ่มจาก engineer

แต่ในบทความของ Thariq เขาพูดชัดว่า workflows มีประโยชน์กับ non-technical work ด้วย

ตัวอย่างที่เขาให้มีทั้ง:

ขุด Slack incidents หกเดือนเพื่อหา root cause ที่ยังไม่มี ticket เอา business plan ให้ agent หลาย persona วิจารณ์จากมุมนักลงทุน ลูกค้า และคู่แข่ง คัด resume 80 ใบสำหรับ backend role แล้ว double-check top ten brainstorm ชื่อ CLI tool แล้วใช้ tournament เลือก top 3 ตรวจ claim ใน blog post เทียบกับ codebase ก่อน publish

นี่คือจุดที่ Data-Espresso ควรสนใจ

เพราะ SME ไทยจำนวนมากไม่ได้ติดที่ “ไม่มี AI”

ติดที่ยังไม่รู้จะวาง AI เข้า workflow ไหน และยังไม่มี harness สำหรับให้ AI ทำงานอย่างปลอดภัย

ลองเอา pattern dynamic workflows มาแปลเป็นงานธุรกิจ:

งาน lead follow-up

• classifier agent แยกประเภท lead
• agent อีกตัวสรุปบริบทจากแชท
• verifier ตรวจว่าไม่มีคำตอบเกิน policy
• human approve ก่อนส่งข้อความสำคัญ
• proof คือ summary และ next action

งาน content operations

• agent ตัวหนึ่งหา source
• agent ตัวหนึ่งแตก claim
• agent หลายตัว verify claim ต่อ source
• editor agent ตรวจ tone และ fact risk
• human approve ก่อน publish
• proof คือ draft, sources, image QA, issue queue

งาน support triage

• agent อ่าน ticket แบบ quarantine
• classifier แยก severity
• dedupe เทียบกับ issue เดิม
• action agent ทำได้เฉพาะ ticket ที่ปลอดภัย
• escalate เคสเสี่ยงให้คน
• proof คือ ticket status, reason, link

งาน weekly business review

• agent ดึงยอดขาย
• agent ดึง campaign metrics
• agent ดึง customer issues
• analyst agent หา pattern
• verifier agent ตรวจตัวเลขกับ source
• owner ได้ report พร้อม decision options

นี่คือ dynamic workflow ในภาษาธุรกิจ

ไม่จำเป็นต้องเริ่มจากระบบใหญ่

เริ่มจากงานซ้ำ ๆ ที่ input ชัด output ชัด และมี proof ชัดก่อน

5) Harness ที่ดีต้องมีอะไร

ถ้าเราจะเอาแนวคิดนี้มาใช้จริง ผมจะไม่เริ่มจากคำว่า “ใช้ agent กี่ตัว”

ผมจะเริ่มจาก checklist นี้:

1. Outcome

งานนี้ต้องจบด้วยอะไร PR, report, ranked list, ticket, dashboard, draft, หรือ recommendation

1. Input boundary

ข้อมูลที่ agent อ่านได้คืออะไร ข้อมูลไหนเป็น public, internal, confidential, หรือ untrusted

1. Decomposition

งานนี้แตกเป็นกี่ส่วน แตกตามไฟล์ ตามลูกค้า ตาม ticket ตาม claim ตาม hypothesis หรือแบ่งตาม persona

1. Isolation

agent ต้องทำงานแยก context หรือแยก workspace ไหม ต้องใช้ worktree ไหม ต้องกันไม่ให้ context ปนกันไหม

1. Verification

ใครตรวจผลของใคร ตรวจด้วย rubric อะไร ตรวจด้วย source, test, log, metric, หรือ human review

1. Privilege

agent ที่อ่านข้อมูล untrusted ห้ามทำ action อะไร agent ตัวไหนเท่านั้นที่ส่งข้อความ, deploy, update CRM, หรือแตะข้อมูลลูกค้าได้

1. Stop condition

งานหยุดเมื่อไร เจอ no new findings, test ผ่าน, reviewer เห็นด้วย, budget หมด, หรือ human approve

1. Budget

ใช้ token ได้เท่าไร ใช้เวลาได้เท่าไร spawn agent ได้กี่ตัว ใช้ model ไหนกับ stage ไหน

1. Proof artifact

หลักฐานสุดท้ายคืออะไร link, screenshot, log, diff, test result, citation, queue issue, หรือ decision memo

ถ้ายังตอบ 9 ข้อนี้ไม่ได้ การใช้ agent หลายตัวอาจจะยังเร็วไป

แต่ถ้าตอบได้ AI จะเริ่มกลายเป็นทีมงานย่อยที่ทำงานในระบบ ไม่ใช่ chatbot ที่เราต้องคุมทุกนาที

6) จุดที่ต้องระวัง

Dynamic workflows น่าตื่นเต้น แต่ไม่ใช่คำตอบของทุกอย่าง

Anthropic เตือนเองว่า workflows ใช้ token มากขึ้น และควรเริ่มจากงาน scope แคบก่อน

เอกสารยังบอกด้วยว่า workflow มีข้อจำกัด เช่นไม่มี mid-run user input โดยตรง และ workflow script เองไม่ได้เข้าถึง filesystem หรือ shell โดยตรง แต่ให้ agents เป็นคน read, write, run commands ส่วน script ทำหน้าที่ coordinate

แปลว่าองค์กรต้องคิดเรื่อง permission ให้ดี

ถ้าปล่อย workflow อ่าน public content แล้วให้ agent ตัวเดียวกันมีสิทธิ์ส่ง email, update CRM, delete file, หรือ deploy production ได้เลย แบบนี้อันตราย

pattern ที่ Thariq พูดถึงในส่วน triage คือ quarantine

agent ที่อ่านข้อมูล public หรือ untrusted ควรถูกกันออกจาก high-privilege actions

อีกชุดหนึ่งที่ scope ชัดกว่าและผ่าน approval แล้วเท่านั้นจึงลงมือทำ action สำคัญ

นี่เป็นบทเรียนที่ควรเอามาใช้กับทุกระบบ AI Agent ในธุรกิจ

โดยเฉพาะธุรกิจที่เริ่มเอา AI ไปแตะลูกค้า เงิน เอกสาร หรือข้อมูลส่วนตัว

7) มุมมองของผม

ผมคิดว่า dynamic workflows เป็นสัญญาณที่ชัดมากว่า AI Agent กำลังเปลี่ยนจาก “model capability” ไปเป็น “work design”

ที่ผ่านมาเราแข่งกันถามว่า model ไหนฉลาดกว่า context window ยาวแค่ไหน เขียน code ได้ดีแค่ไหน

แต่พอ agent เริ่มทำงานหลายชั่วโมง หลายไฟล์ หลายแหล่งข้อมูล หลาย approval point คำถามจะเปลี่ยนเป็น:

ใครถือแผน ใครตรวจงาน ใครมีสิทธิ์ทำ action งานหยุดเมื่อไร หลักฐานอยู่ตรงไหน และ pattern ที่เวิร์กถูกเก็บไว้ใช้ซ้ำอย่างไร

นี่คือเหตุผลที่ผมชอบคำว่า harness มากกว่า prompt

prompt คือคำสั่ง harness คือระบบที่ทำให้คำสั่งกลายเป็นงานที่จบได้ ตรวจได้ และปลอดภัยพอ

สำหรับทีมไทยและ SME ที่เริ่มสนใจ AI Agent ผมจึงอยากให้เริ่มจากคำถามเดียว:

งานนี้ต้องการ prompt หรือ workflow?

ถ้าเป็นงานเล็ก prompt ก็พอ

แต่ถ้าเป็นงานที่ต้องแตกหลายส่วน ตรวจหลายรอบ หรือมีความเสี่ยงตอนลงมือทำ อย่าพยายามยัดทุกอย่างลง prompt เดียว

ออกแบบ harness ก่อน

แล้วค่อยให้ AI Agent วิ่งอยู่ในนั้น

นั่นคือจุดที่ AI เริ่มกลายเป็น coworker จริง ๆ ครับ