deer-workflow สร้างขึ้นจากความคิดที่ว่า แผนงานที่ยังลอยอยู่ในหน้าแชตกับ AI นั้นยังไม่ถือว่าเป็นแผนจริง โปรเจกต์นี้เป็นเครื่องมือโอเพนซอร์สภายใต้สัญญาอนุญาต MIT ที่ยกลำดับขั้นตอนทั้งหมดไปเขียนไว้ในโค้ด TypeScript ภาษาโปรแกรมที่พัฒนาต่อยอดมาจาก JavaScript ตัวโค้ดเป็นตัวกำหนดทิศทางการทำงานทั้งหมด แล้วค่อยเรียก coding agent มาช่วยทำเฉพาะขั้นตอนที่ต้องตีความภาษาเป็นจุดๆ ไป คำว่า coding agent หมายถึง AI ที่รับโจทย์แล้วไล่ค้นหาข้อมูล เขียนโค้ด และรันคำสั่งในเครื่องให้ได้เอง อย่าง Codex หรือ Claude Code ทางทีม deerwork-ai ระบุไว้ในไฟล์แนะนำโปรเจกต์ (README) ว่า นี่เป็นโปรเจกต์นำร่อง (pilot project) ของ DeerFlow 3.0 ที่มีอีกชื่อว่า DeerWork

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

แผนงานที่อยู่ในแชต เปิดรีวิวไม่ได้

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

เอกสาร README ของ deer-workflow อธิบายปัญหานี้ไว้อย่างตรงไปตรงมาว่า บทสนทนากับ agent คือสิ่งที่มองไม่ทะลุ พร้อมกำหนดแนวทางไว้ว่า ลำดับการทำงาน ขั้นตอน (phase) ข้อมูลนำเข้า และวิธีรับมือเมื่องานมีปัญหา ทั้งหมดนี้ควรย้ายไปอยู่ในโค้ดที่มนุษย์เปิดอ่านและตรวจสอบได้

แนวทางแก้ปัญหาก่อนหน้านี้คือการเข้าไปเสริมความสามารถที่ตัว agent โดยตรง เช่น COMPASS ชุดสกิลที่ทำให้ agent หยุดมาถามก่อนลงมือและไม่ลืมงานข้ามเซสชัน หรือ fable-method ที่เปลี่ยนวิธีสั่งจากการบอกให้ระวัง มาเป็นการเขียนขั้นตอนกับเกณฑ์ตัดสินให้ชัด แม้ทั้งสองวิธีจะช่วยได้จริง แต่ก็ยังทำงานอยู่บนโจทย์เดิม นั่นคือแผนงานยังคงฝากไว้ในบทสนทนา ส่วน deer-workflow เลือกแนวทางที่ต่างออกไป โดยไม่พยายามทำให้ agent จำเก่งขึ้น แต่ย้ายลำดับงานทั้งหมดออกมาไว้ในไฟล์เดียวชื่อ workflow.ts ซึ่งเขียนขึ้นจากคำสั่งพื้นฐานเพียงหกตัว เพียงเปิดอ่านครั้งเดียวก็เห็นชัดเจนว่างานมีกี่เฟส และมีการเรียกใช้ใครทำอะไรในจุดไหนบ้าง

โค้ดถือแผน ส่วน agent ถือวิจารณญาณ

แนวคิดหลักใน README มีอยู่สามข้อ ข้อแรกคือ "โค้ดคือแผน" ลำดับการทำงาน ขั้นตอน ข้อมูลเข้า และวิธีรับมือเมื่องานล้มเหลว เขียนไว้ในไฟล์ TypeScript ที่ตรวจทานได้ โดยไม่อาศัยบทสนทนาที่มองไม่ทะลุอีกต่อไป

ข้อสองคือ "agent ถอดเปลี่ยนได้" ตัวระบบมี Codex เป็นค่าเริ่มต้น และใส่ Claude Code มาให้ในตัวภายใต้ชื่อ ClaudeAgent โดยอินเทอร์เฟซสำหรับเรียกใช้งานออกแบบมาให้เป็นกลาง ไม่ผูกติดกับผู้ให้บริการรายใดรายหนึ่ง นอกจากนี้ใน README ยังระบุว่ายินดีรับการเชื่อมต่อกับ coding agent จากผู้พัฒนารายอื่นเพิ่มอีกด้วย

ข้อสามคือ "การทำงานที่มองเห็นได้" หากสั่งรันผ่านหน้าจอพิมพ์คำสั่ง (CLI) ระบบจะแสดงสถานะสดๆ ให้เห็นว่ากำลังทำงานอยู่ในเฟสไหน พร้อมแสดงล็อกในรูปแบบ Markdown แต่ถ้าต้องการนำไปเชื่อมต่อกับเซิร์ฟเวอร์หรือระบบอัตโนมัติ เพียงเติมพารามิเตอร์ --print หรือ -p ระบบจะส่งข้อมูลเหตุการณ์ออกมาทีละบรรทัดในรูปแบบ JSON ซึ่งเป็นรูปแบบข้อมูลมาตรฐานที่โปรแกรมอื่นสามารถนำไปประมวลผลต่อได้ทันที

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

หกคำสั่งที่ประกอบกันเป็นไฟล์ workflow.ts

เอกสารของ deer-workflow ได้นำคำสั่งทั้งหกตัวมาแสดงร่วมกันในตัวอย่างเดียวที่ชื่อ research-synthesis ซึ่งทั้งหมดอิมพอร์ตมาจากแพ็กเกจตัวเดียวกัน

import { agent, log, parallel, phase, pipeline } from "@deerwork-ai/deer-workflow";

export const meta = {
  name: "research-synthesis",
  description: "Researches and synthesizes a topic.",
  phases: [
    { title: "Plan" },
    { title: "Research" },
    { title: "Synthesize" },
  ],
  exampleArgs: { topic: "Agentic workflow design" },
};

meta ทำหน้าที่ประกาศชื่องาน คำอธิบาย รายการเฟสตามลำดับ และตัวอย่างข้อมูลนำเข้าที่หยิบไปทดลองรันได้จริง เพียงอ่านโค้ดส่วนนี้ส่วนเดียวก็เข้าใจได้ทันทีว่างานมีกี่ช่วงและมีชื่ออะไรบ้าง ซึ่งต่างจากบทสนทนายาวๆ ที่บอกสิ่งเหล่านี้ไม่ได้

phase("Plan") คือคำสั่งปักหมุดว่างานดำเนินมาถึงช่วงใด โดยใช้ชื่อตรงกับใน meta.phases ขณะที่ log(...) จะทำหน้าที่ส่งข้อความรายงานความคืบหน้าออกมาให้ผู้ใช้อ่านระหว่างทาง

agent(...) ถือเป็นหัวใจสำคัญของฝั่ง AI โดยเอกสารระบุว่าคำสั่งนี้จะเริ่มวงรอบการทำงานเต็มรูปแบบ ตั้งแต่การคิด เลือกใช้เครื่องมือ ตรวจสอบผลลัพธ์ แล้ววนกลับมาคิดต่ออย่างมีบริบทของตัวเอง ซึ่งไม่ใช่แค่การส่งคำถามหาโมเดลครั้งเดียวจบเหมือนพรอมป์ทั่วไป

คำสั่งอีกสองตัวที่เหลือคือ parallel(...) และ pipeline(...) ซึ่งในโค้ดตัวอย่างจะแสดงให้เห็นการทำงานต่อเนื่องกัน

phase("Research");
log(`Researching ${plan.angles.length} angles`);
const signals = await parallel(
  plan.angles.map((angle) => () => agent(`Research ${angle}`)),
);
const findings = await pipeline(
  signals.filter(Boolean),
  (signal) => agent(`Extract key facts:\n${signal}`),
);

parallel ในตัวอย่างนี้ทำหน้าที่รับรายการฟังก์ชันที่ห่อการเรียก agent เอาไว้ แล้วรอรับผลลัพธ์ของทั้งกลุ่มพร้อมกัน ส่งผลให้งานค้นหาข้อมูลในแต่ละแง่มุมสามารถเริ่มทำงานไปพร้อมๆ กันได้ ส่วน pipeline จะรับรายการข้อมูลที่จะนำมาประมวลผล พร้อมฟังก์ชันที่ระบุขั้นตอนการทำงาน ซึ่งในตัวอย่างนี้คือการสั่งให้ agent สกัดข้อเท็จจริงออกจากผลการค้นหาแต่ละชิ้น

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

รอยต่อระหว่างโค้ดกับ agent คือจุดที่ต้องตรวจ

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

deer-workflow แก้ปัญหานี้โดยเปิดให้คำสั่ง agent(...) รับตัวเลือก schema เพิ่มเติมได้ ซึ่งเมื่อระบุตัวเลือกนี้ ผลลัพธ์ที่ agent ส่งกลับมาจะผ่านการตรวจสอบรูปแบบก่อนส่งต่อไปยังขั้นตอนถัดไป เครื่องมือที่ใช้ตรวจสอบคือ JSON Schema ซึ่งทำหน้าที่อธิบายว่าข้อมูลก้อนนี้ต้องมีฟิลด์อะไรบ้าง เป็นข้อมูลชนิดไหน และมีฟิลด์เกินเข้ามาหรือไม่

const plan = await agent<{ angles: string[] }>(
  `Plan independent research angles for ${args.topic}`,
  {
    schema: {
      type: "object",
      properties: { angles: { type: "array", items: { type: "string" } } },
      required: ["angles"],
      additionalProperties: false,
    },
  },
);

เมื่อพิจารณาโค้ดส่วนนี้ จะเห็นว่าฝั่งเราได้ประกาศไว้ล่วงหน้าว่าผลลัพธ์ angles ต้องเป็นรายการของข้อความเท่านั้น หาก agent ตอบกลับมาเป็นรูปแบบอื่น ระบบจะไม่อนุญาตให้ผ่านตั้งแต่แรก ทำให้ความไม่แน่นอนเหลืออยู่แค่ในส่วนเนื้อหาที่ agent คิดขึ้นมาเท่านั้น ส่วนโครงสร้างของข้อมูลเป็นเรื่องที่โค้ดกำหนดและตรวจสอบเอง

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

ติดตั้ง deer-workflow แล้วสั่งรันครั้งแรก

ก่อนเริ่มต้นใช้งาน ต้องติดตั้ง Bun สำหรับรันโค้ด TypeScript บนเครื่องไว้ก่อน จากนั้นติดตั้งและล็อกอินเข้าใช้งาน Codex CLI ซึ่งเป็นเครื่องมือสำหรับสั่งงาน AI ผ่านหน้าจอพิมพ์คำสั่ง (CLI) แล้วจึงทำการติดตั้งแพ็กเกจ deer-workflow แบบทั่วเครื่อง (global)

bun install --global @deerwork-ai/deer-workflow

ขั้นตอนถัดไปคือการพิมพ์คำสั่งอธิบายกระบวนการทำงานที่ต้องการประสานงาน แล้วบันทึกผลลัพธ์ออกมาเป็นไฟล์

deer-workflow create \
  "Create a Workflow that accepts a topics string array, researches each topic in parallel, and synthesizes a report" \
  > workflow.ts

เบื้องหลังคำสั่งนี้ ระบบจะส่งโจทย์ไปให้ Codex ดึงสกิลตัวที่ชื่อ workflow-creator ซึ่งติดมากับแพ็กเกจ ไปสร้างเป็นโมดูล TypeScript ที่สามารถสั่งรันได้จริงออกมาเป็นไฟล์ ไฟล์ที่ได้ออกมาจะเปิดอ่านและปรับแต่งแก้ไขได้ตามต้องการก่อนสั่งรันจริง ซึ่งต่างจากการพิมพ์คำสั่งในแชตแล้วต้องนั่งลุ้นผลลัพธ์เอาเอง

deer-workflow run ./workflow.ts \
  --input '{"topics":["Agent Skills","Dynamic Workflows"]}'

เมื่อส่งข้อมูลเข้าในรูปแบบ JSON ที่ชัดเจนประกอบกับมีไฟล์แผนงานระบุไว้อย่างเป็นระบบ เราจึงสั่งรันงานเดิมซ้ำด้วยลำดับขั้นตอนเดิมได้ทุกครั้ง และหากผลลัพธ์ออกมาไม่ตรงตามที่คาดไว้ ก็ยังมีไฟล์แผนงานให้เปิดเปรียบเทียบดูได้ว่า ลำดับที่เขียนไว้กับผลลัพธ์ที่เกิดขึ้นมีความแตกต่างกันในจุดใด

สองตัวอย่างในโปรเจกต์ที่โหลดมาดูได้

ใน repository ของโปรเจกต์มีตัวอย่างการใช้งานแนบมาสองชิ้น ชิ้นแรกชื่อ Deep Research มีขั้นตอนตั้งแต่การแตกแง่มุมของหัวข้อ การแยกไปค้นหาข้อมูลแต่ละมุมพร้อมกัน การตรวจสอบข้อเท็จจริง ไปจนถึงการสรุปผลออกมาเป็นรายงานไฟล์ HTML ที่เปิดดูได้ ส่วนชิ้นที่สองชื่อ Blog Writer จะเริ่มจากการวางโครงร่างบทความ แล้วค่อยไล่เขียนเนื้อหาทีละส่วนผ่าน pipeline ก่อนส่งไปรีวิวและคืนผลลัพธ์กลับมาเป็นข้อมูลที่มีโครงสร้างชัดเจน

โค้ดตัวอย่างทั้งสองชุดอยู่ในหน้าโปรเจกต์บน GitHub (แพลตฟอร์มสำหรับเก็บและแบ่งปันซอร์สโค้ด) ซึ่งผู้ใช้งานต้องโคลน (clone) หรือดาวน์โหลดลงมาที่เครื่องก่อน จึงจะสั่งรันตามที่เอกสารเขียนไว้ได้

จุดสำคัญอีกประการที่โปรเจกต์เน้นย้ำคือ ไฟล์แผนงานเดียวกันนี้สามารถนำไปสั่งรันได้ในหลายสภาพแวดล้อม ตั้งแต่การรันบนระบบคลาวด์ ระบบอัตโนมัติของทีม แอปพลิเคชันบนเครื่องคอมพิวเตอร์ ไปจนถึงการสั่งงานผ่านหน้าจอ CLI เนื่องจากสิ่งที่ย้ายไปมาคือไฟล์โค้ด ไม่ใช่บทสนทนาที่ยึดติดอยู่กับหน้าต่างแชต

ของยังใหม่ และทำมาให้คนที่เขียนโค้ดเป็น

สถิติบนหน้าโปรเจกต์ ณ วันที่ 29 กรกฎาคม 2026 บันทึกไว้ที่ 319 ดาว · ผู้ร่วมพัฒนา 5 คน · 3 รีลีส (เวอร์ชันล่าสุดคือ v0.2.0) · และมีการแก้ไขโค้ด 44 ครั้งบนสาขาหลัก อย่างไรก็ตาม จำนวนดาวบอกได้เพียงว่ามีผู้ให้ความสนใจ แต่ไม่ได้หมายความว่าตัวระบบเสถียรแล้ว ยิ่ง README ระบุไว้ชัดเจนว่าเป็นโปรเจกต์นำร่อง ก็ยิ่งต้องเผื่อใจว่ารูปแบบคำสั่งและอินเทอร์เฟซจะเปลี่ยนได้อีก

ในความเป็นจริง เครื่องมือนี้ไม่ได้ออกแบบมาให้ผู้ที่ไม่เคยเขียนโค้ดเปิดใช้งานได้ทันที เพราะผู้ใช้ต้องติดตั้ง Bun และล็อกอิน Codex CLI ให้เรียบร้อย ทั้งยังต้องมีความเข้าใจในภาษา TypeScript เพื่ออ่านและแก้ไขไฟล์แผนงานที่สร้างขึ้น แม้ผู้ไม่ได้เขียนโค้ดจะนำแนวคิดการแยกแผนงานไปปรับใช้ได้ แต่ตัวเครื่องมือโดยตรงยังไม่ได้ทำมาเพื่อรองรับกรณีนั้น

แยกให้ออกว่าอะไรต้องแน่นอน อะไรต้องใช้วิจารณญาณ

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

สิ่งที่นำไปใช้ได้ทันทีโดยไม่ต้องติดตั้งเครื่องมือนี้ คือแนวทางการมองและจัดสรรงานแบบใหม่ งานหนึ่งชิ้นแบ่งออกได้เป็นสองส่วน ส่วนแรกคือส่วนที่ต้องการความแน่นอนสูง เช่น ลำดับก่อนหลัง จำนวนรอบการทำงาน และเงื่อนไขการหยุด ส่วนนี้ควรบันทึกไว้เป็นโค้ดหรืออย่างน้อยเป็นเอกสารที่เปิดตรวจสอบได้ อีกส่วนคือส่วนที่ต้องใช้วิจารณญาณ เช่น การเลือกประเด็น การตีความข้อมูล และการเรียบเรียงภาษา ส่วนนี้ค่อยมอบหมายให้ AI ทำ ที่ผ่านมาเรามักรวมสองส่วนนี้ไว้ในข้อความคำสั่งเดียว แล้วคาดหวังให้โมเดลแยกแยะเอาเอง

หากลองหยิบงานที่ต้องทำซ้ำมาหนึ่งงาน แล้วลงมือเขียนลำดับขั้นตอนลงในไฟล์ก่อนสั่งงาน AI เราจะพบว่า ขั้นตอนที่ไม่สามารถเขียนออกมาได้นั้น ก็คือขั้นตอนที่เรายังไม่เคยตัดสินใจเอง แล้วปล่อยให้ agent คาดเดาแทนเรามาโดยตลอด

ที่มา:

• โปรเจกต์ deer-workflow บน GitHub
• เอกสารทางการของ deer-workflow