Claude Code เวิร์กโฟลว์ไดนามิก: รัน Subagents ขนานนับร้อยด้วย Opus 4.8

Claude Opus 4.8 มาพร้อมกับฟีเจอร์เด่นสำหรับ Claude Code: Dynamic Workflows ในหนึ่งเซสชัน เอเจนต์ผู้ควบคุมสามารถสร้างซับเอเจนต์แบบขนานได้หลายร้อยตัวเพื่อจัดการงานขนาดใหญ่ที่แตกแขนง เช่น การ refactor หลายสิบไฟล์ การรัน test matrix ขนาดใหญ่ หรือการสำรวจหลายแนวทางแก้ปัญหาพร้อมกัน เบื้องหลังไม่ใช่เวทมนตร์ แต่คือการรวมกันของกลไกสองส่วนใน Opus 4.8

ลองใช้ Apidog วันนี้

คู่มือนี้อธิบายว่า Dynamic Workflows ทำงานอย่างไร ควรใช้เมื่อใด และจะสร้างรูปแบบ orchestration แบบเดียวกันผ่าน API ดิบได้อย่างไร สำหรับตัวโมเดล ดู Claude Opus 4.8 คืออะไร และถ้าต้องการพื้นฐานสถาปัตยกรรมเอเจนต์ ให้อ่านคู่กับ การวิเคราะห์สถาปัตยกรรม Claude Code agent harness

Dynamic Workflows คืออะไรกันแน่

ใน Claude Code, Dynamic Workflows แสดงเป็นโหมด ultracode ในเมนู effort จุดสำคัญคือ ultracode ไม่ใช่ระดับ effort API ใหม่ แต่เป็นการใช้สองความสามารถของ Opus 4.8 ร่วมกัน:

1. ระดับ effort xhigh
2. ข้อความระบบระหว่างการสนทนา หรือ Mid-conversation system messages

เมื่อรวมกันแล้ว ผู้ควบคุมจะมีทั้งความสามารถในการวางแผนงานขนาดใหญ่ และสิทธิ์ในการเปิดตัว worker agents ระหว่างงานได้ นั่นคือกลไกหลัก ส่วนที่เหลือคือการ wiring ภายใน Claude Code

ส่วนประกอบที่ 1: xhigh effort

พารามิเตอร์ effort ควบคุมจำนวนโทเค็นที่ Opus 4.8 ใช้ในการตอบกลับ รวมถึงการเรียกใช้เครื่องมือ ระดับ xhigh เป็นระดับที่ Anthropic แนะนำสำหรับงานเขียนโค้ดและ agentic workloads ระยะยาว โดยออกแบบมาสำหรับงานที่กินเวลามากกว่า 30 นาทีและใช้งบประมาณโทเค็นระดับหลายล้าน

สำหรับ Dynamic Workflows, xhigh สำคัญเพราะผู้ควบคุมต้อง:

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

หากใช้ effort ต่ำเกินไป โมเดลมักมีพื้นที่ในการวางแผนน้อยลงและเรียกใช้เครื่องมือน้อยลง ซึ่งไม่เหมาะกับงาน orchestration

แนวทางเริ่มต้น:

max_tokens = 64000
effort = "xhigh"

ตั้ง max_tokens ให้ใหญ่พอ เช่น 64K เพื่อให้ผู้ควบคุมมีพื้นที่สำหรับคิด วางแผน และสรุปผลจาก worker หลายตัว

ส่วนประกอบที่ 2: ข้อความระบบระหว่างการสนทนา

ก่อน Opus 4.8, system prompt จะอยู่ต้นการสนทนาและคงที่ แต่ Messages API รุ่นใหม่รองรับการวาง system message ไว้กลางอาร์เรย์ messages ได้ ทำให้คุณแทรกคำสั่ง สิทธิ์ หรือข้อจำกัดใหม่ระหว่างงานได้

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

Anthropic อธิบายฟีเจอร์นี้ไว้ในเอกสาร ข้อความระบบระหว่างการสนทนา

ผลลัพธ์เชิงปฏิบัติ:

• ไม่ต้องกำหนดทุก permission ตั้งแต่ต้น
• เพิ่มคำสั่งเฉพาะช่วงงานได้
• เปลี่ยนโหมดการทำงานของ agent ตามบริบทที่ค้นพบระหว่างรัน

การเปิดใช้งานใน Claude Code

ใน Claude Code ให้เลือก ultracode จากเมนู effort ตัวเลือกนี้จะตั้งค่า xhigh effort และให้สิทธิ์เซสชันในการสร้าง subagents แบบขนานผ่านข้อความระบบระหว่างการสนทนา

ลำดับการใช้งานโดยทั่วไป:

1. เปิด Claude Code
2. เลือก effort เป็น ultracode
3. อธิบายงานขนาดใหญ่ให้ชัด เช่น scope, repository, ไฟล์ที่เกี่ยวข้อง และข้อจำกัด
4. ปล่อยให้ผู้ควบคุมแยกงานและกระจายไปยัง worker
5. ตรวจผลลัพธ์รวมก่อน merge หรือ deploy

ตัวอย่าง prompt ที่เหมาะกับ Dynamic Workflows:

Refactor authentication error handling across all services.

Goals:
- Keep public API behavior unchanged
- Standardize error codes
- Update tests for each affected service
- Report files changed and risks before final patch

เมื่อรันแล้ว Claude จะทำงานหลัก ๆ ดังนี้:

• วางแผนและแบ่งงาน
• เปิด worker agents แบบขนาน
• ให้ worker แต่ละตัวรับผิดชอบงานย่อย
• รวมผลลัพธ์กลับเข้าเซสชันหลัก

ถ้าคุณตั้งค่า Claude Code ด้วยแผนการทำงานแล้ว คู่มือการตั้งค่า Claude Agent SDK with Claude plan จะครอบคลุมการตั้งค่าที่เกี่ยวข้อง

ควรใช้ Dynamic Workflows เมื่อใด

ใช้ Dynamic Workflows เมื่องานมีขนาดใหญ่และแบ่งขนานได้จริง เช่น:

• Refactor pattern เดียวกันในหลายไฟล์
• สร้างและรัน test matrix ขนาดใหญ่
• ทดลองหลายแนวทาง implementation พร้อมกันแล้วเปรียบเทียบ
• วิเคราะห์ codebase ขนาดใหญ่ โดยแบ่ง worker ตาม module
• ตรวจ migration impact ในหลาย service

เกณฑ์ตัดสินใจง่าย ๆ:

ถ้างานย่อยทำพร้อมกันได้โดยไม่รอกัน -> เหมาะกับ Dynamic Workflows
ถ้าทุกขั้นต้องรอผลจากขั้นก่อนหน้า -> ไม่เหมาะ

ไม่ควรใช้ Dynamic Workflows เมื่อใด

หลีกเลี่ยง Dynamic Workflows กับงานที่เล็ก แคบ หรือเป็นลำดับชัดเจน เช่น:

• แก้บั๊กไฟล์เดียว
• เปลี่ยนชื่อ function เล็ก ๆ
• งานที่ต้องทำทีละขั้นแบบ strict dependency
• งานที่ยังไม่มี scope ชัดเจน

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

การสร้าง Dynamic Workflows ผ่าน API

คุณไม่จำเป็นต้องใช้ Claude Code เพื่อสร้าง orchestration แบบเดียวกัน ส่วนประกอบหลักมีอยู่ใน Messages API ดิบอยู่แล้ว Anthropic มีตัวอย่างในเอกสาร การสร้างโหมดการควบคุม

รูปแบบ implementation คือ:

1. เรียก orchestrator ด้วย xhigh effort
2. ให้ orchestrator วางแผนและแบ่งงาน
3. ใช้ข้อความระบบระหว่างการสนทนาเพื่อให้สิทธิ์ dispatch workers
4. เรียก worker หลายตัวแบบขนาน
5. ส่งผลลัพธ์กลับไปให้ orchestrator รวม

ตัวอย่าง orchestrator call:

import anthropic

client = anthropic.Anthropic()

orchestrator = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    thinking={"type": "adaptive"},
    messages=[
        {
            "role": "user",
            "content": "Plan a refactor of the auth module across all 14 services."
        },
    ],
)

จากนั้น worker แต่ละตัวคือ Messages API call แยกกัน ซึ่งคุณสามารถรันพร้อมกันได้ งานของ worker ควรมีขอบเขตแคบกว่า orchestrator และมักใช้ effort ต่ำกว่าได้

ตัวอย่างโครงสร้าง worker แบบง่าย:

worker = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=12000,
    output_config={"effort": "medium"},
    messages=[
        {
            "role": "user",
            "content": """
You are responsible for service: billing-api.

Task:
- Inspect auth error handling
- Propose required changes
- Return changed files, patch summary, and risks
"""
        }
    ],
)

ถ้าต้องการรันหลาย worker พร้อมกันใน Python สามารถห่อด้วย async/concurrent execution ตาม infrastructure ของคุณ แล้วรวมผลลัพธ์กลับไปยัง orchestrator

ตัวอย่าง payload สำหรับส่งผลลัพธ์กลับ:

worker_results = [
    {
        "service": "billing-api",
        "summary": "...",
        "changed_files": ["..."],
        "risks": ["..."]
    },
    {
        "service": "orders-api",
        "summary": "...",
        "changed_files": ["..."],
        "risks": ["..."]
    },
]

final = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": f"""
Merge these worker results into one implementation plan.
Identify conflicts, missing coverage, and final execution order.

Worker results:
{worker_results}
"""
        }
    ],
)

หากกำลังเปรียบเทียบกับโครงสร้างพื้นฐานเอเจนต์ที่โฮสต์ของ Anthropic อ่าน คู่มือ managed agents vs Agent SDK เพื่อดูข้อดีข้อเสีย

ค่าใช้จ่ายและการควบคุม

Dynamic Workflows ใช้โทเค็นเพิ่มขึ้นตามจำนวน worker โดยตรง ตัวอย่างเช่น 200 workers ที่แต่ละตัวใช้โทเค็นหลายหมื่นที่ xhigh อาจกลายเป็นโทเค็นระดับหลายล้านได้

แนวทางควบคุมค่าใช้จ่าย:

• จำกัด scope ของ worker ให้เล็กที่สุด
  
  ให้ worker รับผิดชอบแค่ module, service หรือไฟล์ชุดหนึ่ง

• ลด effort ของ worker เมื่อทำได้
  
  ใช้ medium หรือ low สำหรับงานที่แคบและไม่ต้อง reasoning ลึก

• ตั้ง max_tokens ต่อ worker
  
  ป้องกัน worker ใช้งบประมาณเกินควบคุม

• แคชบริบทที่ใช้ร่วมกัน
  
  ลดการส่ง prompt/system context ซ้ำในทุก worker

• กำหนด output schema ให้ชัด
  
  ทำให้ขั้นตอนรวมผลลัพธ์ง่ายขึ้นและลดการ retry

ตัวอย่าง schema ที่ควรกำหนดให้ worker ตอบ:

{
  "service": "string",
  "status": "ok | blocked | needs_review",
  "changed_files": ["string"],
  "summary": "string",
  "risks": ["string"],
  "test_recommendations": ["string"]
}

อ่านรายละเอียดค่าใช้จ่ายเพิ่มเติมได้ที่ รายละเอียดราคาของ Opus 4.8 สรุปสั้น ๆ คือ orchestration ทรงพลัง แต่ต้นทุนจะเพิ่มตามจำนวนเอเจนต์ จึงควรใช้กับงานที่ขนานได้จริง

การทดสอบ orchestration ด้วย Apidog

เมื่อสร้าง orchestration ผ่าน API จุดที่ดีบักยากที่สุดคือการกระจายงาน:

• worker ได้รับ context ที่ถูกต้องหรือไม่
• output ของ worker ตรงกับ schema ที่ orchestrator คาดหวังหรือไม่
• mid-conversation system message ทำงานตามต้องการหรือไม่
• aggregation logic รองรับผลลัพธ์ที่ไม่สมบูรณ์หรือไม่

คุณไม่ควรรอให้ worker จริง 200 ตัวรันเสร็จแล้วค่อยพบว่า payload ผิดรูปแบบ

Apidog ช่วยทดสอบแต่ละส่วนแยกกันได้:

• บันทึก request ของ orchestrator และตรวจแผนการแบ่งงานก่อน dispatch
• mock endpoint ของ worker เพื่อทดสอบ dispatch และ aggregation โดยไม่ใช้โทเค็นจริงจำนวนมาก
• เพิ่ม assertion เพื่อตรวจ response shape ของ worker
• replay worker call เดียวด้วยระดับ effort ต่างกันเพื่อปรับต้นทุนต่อ worker

แนวทางทดสอบที่แนะนำ:

1. สร้าง request สำหรับ orchestrator ไปที่ https://api.anthropic.com/v1/messages
2. สร้าง mock response สำหรับ worker หลายแบบ เช่น ok, blocked, needs_review
3. ทดสอบ aggregation logic กับ mock ก่อน
4. เพิ่ม assertion สำหรับฟิลด์สำคัญ เช่น service, changed_files, summary, risks
5. เมื่อ flow เสถียรแล้วจึงเปลี่ยนจาก mock ไปใช้ live endpoint

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

Dynamic Workflows ใน Claude Code คืออะไร?

ฟีเจอร์ที่ช่วยให้เซสชันเดียวสามารถสร้าง subagents แบบขนานได้หลายร้อยตัวเพื่อจัดการงานขนาดใหญ่ที่แตกแขนง ขับเคลื่อนโดย xhigh effort ร่วมกับข้อความระบบระหว่างการสนทนาใน Opus 4.8

ultracode เป็นระดับ effort แยกต่างหากหรือไม่?

ไม่ใช่ ultracode เป็นชื่อใน Claude Code สำหรับการใช้ xhigh effort ร่วมกับสิทธิ์ในการเปิด workflow แบบหลายเอเจนต์ ระดับ effort API ยังคงเป็น low, medium, high, xhigh และ max

ข้อความระบบระหว่างการสนทนาคืออะไร?

เป็นความสามารถของ Messages API ใน Opus 4.8 ที่ให้คุณวาง system message ไว้กลางการสนทนาได้ เพื่อแทรกคำสั่งหรือ permission ใหม่ระหว่างงาน

สร้าง Dynamic Workflows โดยไม่ใช้ Claude Code ได้ไหม?

ได้ ใช้ xhigh effort และข้อความระบบระหว่างการสนทนาใน Messages API ดิบ แล้วจัดการ worker dispatch และ aggregation ในระบบของคุณเอง

Dynamic Workflows มีค่าใช้จ่ายสูงหรือไม่?

อาจสูงได้ โดยเฉพาะเมื่อมี subagents จำนวนมากและแต่ละตัวใช้ xhigh จำกัดขอบเขต worker ลด effort เมื่อทำได้ ตั้ง max_tokens และใช้ context caching เพื่อควบคุมค่าใช้จ่าย

ควรหลีกเลี่ยง Dynamic Workflows เมื่อใด?

หลีกเลี่ยงกับงานเล็ก งานแคบ หรืองานที่ต้องทำเป็นลำดับ strict เพราะ worker แบบขนานจะไม่เพิ่มคุณค่าและอาจสิ้นเปลืองโทเค็นโดยไม่จำเป็น