มาสร้างระบบโครงสร้างพื้นฐานสำหรับ Claude Code กัน (แบบทีละขั้นตอน)

เราจะครอบคลุมทุกอย่างที่เกี่ยวข้องกับการสร้าง coding harness, agent loop, การวางแผน, subagents, sandboxing, หน่วยความจำ และ checkpointing ซึ่งสร้างขึ้นทีละขั้นตอน

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

มันอ่านไฟล์ผิด เป้าหมายหายไปกลางทาง และเติม context ด้วย output ที่ไม่จำเป็นอีกต่อไป

จากนั้นงานเดียวกันก็ผ่าน Claude Code และเสร็จเรียบร้อย ข้อสรุปง่ายๆ คือ Anthropic มีโมเดลที่ดีกว่า และข้อสรุปนั้นพลาดจุดที่งานจริงๆ เกิดขึ้น

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

นี่คือหน้าตาของ agent ที่มีฮาร์เนสเต็มรูปแบบเมื่อคุณวาดออกมา:

GIF

ภาพดูยุ่ง แต่แบ่งออกเป็นสี่กลุ่ม:

• Memory ป้อน context ทำงานให้โมเดล รวมถึงข้อเท็จจริงที่เรียนรู้ข้ามเซสชัน
• Skills เข้ารหัสว่า agent ควรทำงานอย่างไร หมายถึง ขั้นตอน ข้อจำกัด และฮิวริสติกที่มันปฏิบัติตาม
• Protocols เชื่อมต่อ agent กับผู้ใช้ เครื่องมือ และ agent อื่นๆ
• Harness core เชื่อมทุกอย่างเข้าด้วยกันด้วยการจัดระเบียบ sub-agent, แซนด์บ็อกซ์, ตัวประเมินผล, วงอนุมัติ, การสังเกตการณ์ และการบีบอัดบริบท

Anthropic อธิบายการแบ่งนี้ว่าเป็นสมองและมือ โมเดลคือสมองที่เลือกแต่ละการกระทำ และฮาร์เนสคือมือที่ดำเนินการและทำให้รันต่อไปได้

ดังนั้นช่องว่างระหว่าง agent ของคุณกับ Claude Code ไม่ใช่โมเดล แต่เป็นกลไกรอบๆ โมเดลต่างหาก

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

มันจับคู่กับฟีเจอร์ในตัวมากกว่าที่ฉันคิดไว้ และส่วนที่จับคู่ไม่ได้คือที่ที่วิศวกรรมจริงๆ อยู่

มาสร้างมันทีละเลเยอร์ เริ่มจาก core loop แล้ววาง planning, subagents, sandboxing และ memory ทับลงไป ในแต่ละขั้นตอนเราจะทำเครื่องหมายว่าเฟรมเวิร์กสิ้นสุดที่ไหนและงานของคุณเริ่มต้นที่ไหน

วิธีการทำงานของฮาร์เนสของ Claude Code

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

สิ่งนี้จะทำซ้ำจนกว่าโมเดลจะส่งคืนคำตอบสุดท้ายโดยไม่มีการเรียกใช้เครื่องมือเพิ่มเติม

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

อย่างไรก็ตาม loop เพียงอย่างเดียวไม่เพียงพอสำหรับ coding agent ที่เชื่อถือได้ Claude Code เพิ่มการวางแผน เครื่องมือไฟล์ subagents หน่วยความจำ และระบบสิทธิ์และแซนด์บ็อกซ์รอบๆ เลเยอร์เหล่านี้ไม่ได้แทนที่ loop แต่ทำให้มันปลอดภัยและเชื่อถือได้พอสำหรับงานจริง

นั่นคือสถาปัตยกรรมที่เราจะสร้างใหม่ เริ่มจาก core loop ก่อน จากนั้นแต่ละเลเยอร์ทับลงไป โดยจับคู่ทุกเลเยอร์กับฟีเจอร์ของ CrewAI ที่จัดการมัน

Core agent loop

loop จะรันลำดับเดียวกันจนกว่างานจะเสร็จ:

1. ขอให้โมเดลทำงาน
2. โมเดลตอบกลับโดยตรงหรือขอใช้เครื่องมือหนึ่งตัวขึ้นไป
3. ถ้ามีการขอเครื่องมือ ให้รันเครื่องมือนั้นและส่งคืนผลลัพธ์ให้โมเดล
4. ทำซ้ำกับการสนทนาที่อัปเดตแล้ว
5. เมื่อโมเดลตอบกลับโดยไม่ขอใช้เครื่องมือใดๆ งานก็เสร็จสมบูรณ์

1while True:
2    reply = model(messages, tools)
3    calls = [b for b in reply if b.type == "tool_use"]
4    if not calls:            # plain text, no tool call: the job is done
5        return reply.text
6    messages += [reply, run_all(calls)]

การเรียกเครื่องมือแต่ละครั้งจะเสร็จหนึ่งขั้นตอน ให้ข้อมูลใหม่แก่โมเดล และป้อนเข้าสู่การตัดสินใจครั้งต่อไป คำถามง่ายๆ อาจเสร็จในหนึ่ง iteration ในขณะที่การแก้ไขบั๊กที่ซับซ้อนหรือการปรับโครงสร้าง codebase ขนาดใหญ่อาจต้องใช้หลายสิบ iteration ก่อนที่โมเดลจะมีข้อมูลเพียงพอที่จะสร้างคำตอบสุดท้าย

CrewAI จัดหา execution loop นี้โดยอัตโนมัติทันทีที่คุณสร้าง agent คุณไม่ต้อง implement while loop เอง คุณแค่กำหนด agent และกำหนดงานให้มัน

การสร้าง agent ตัวแรก

มาสร้าง agent Bug Fixer ง่ายๆ กัน

1from crewai import LLM, Agent, Crew, Task
2
3bug_fixer = Agent(
4    role="Bug Fixer",
5    goal="Find and describe the fix for the reported bug in the codebase.",
6    backstory="You read directories and files to build an accurate picture of the code.",
7    llm="claude-sonnet-4-6",
8)
9
10task = Task(
11    description="Find the fix for {objective}.",
12    expected_output="A short description of the fix and which file it belongs in.",
13)
14
15result = Crew(agents=[bug_fixer], tasks=[task]).kickoff(
16    inputs={"objective": "the overdraft bug in account.py"}
17)

สามแนวคิดที่ต้องเข้าใจที่นี่:

• Agent กำหนดว่าใครเป็นคนทำงาน ผ่านบทบาท เป้าหมาย LLM และเครื่องมือ
• Task อธิบายงานที่มอบหมาย
• Crew นำ agent และ task มารวมกัน การเรียก kickoff() จะรัน execution loop เดียวกันตามที่อธิบายไว้ข้างต้น ไม่ว่าโมเดลพื้นฐานจะเป็น Anthropic, OpenAI, Google หรืออื่นๆ

การให้เครื่องมือแก่ agent

เครื่องมือคือสิ่งที่ทำให้โมเดลที่สร้างแค่ข้อความสามารถทำงานกับ codebase จริงได้ พวกมันอ่านไฟล์ เขียนไฟล์ รันคำสั่ง shell และเรียก API ภายนอก

CrewAI มีเครื่องมือระบบไฟล์ในตัว:

• FileReadTool อ่านไฟล์
• DirectoryReadTool แสดงรายการไดเรกทอรี
• FileWriterTool เขียนไฟล์

1from crewai_tools import DirectoryReadTool, FileReadTool, FileWriterTool
2
3read_file = FileReadTool()
4write_file = FileWriterTool()
5list_dir = DirectoryReadTool()
6
7filesystem_tools = [read_file, write_file, list_dir]

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

ซึ่งทำให้ context window เล็กลงและโมเดลมีสมาธิมากขึ้น ซึ่งเป็นสิ่งที่ Anthropic เรียกว่า context engineering

เครื่องมือในตัวครอบคลุมเฉพาะเวิร์กโฟลว์ทั่วไปเท่านั้น สำหรับสิ่งที่เฉพาะเจาะจงกว่านั้น คุณสามารถเปิดเผยฟังก์ชัน Python เป็นเครื่องมือด้วย @tool

docstring ทำหน้าที่เป็นคู่มือการใช้งาน บอกโมเดลว่าเครื่องมือทำอะไร ควรใช้เมื่อไหร่ และคาดหวังอะไรเป็นอินพุต

1from crewai.tools import tool
2import subprocess
3
4@tool("run_tests")
5def run_tests(path: str = "tests/") -> str:
6    """Run the pytest suite at the given path and return the result."""
7    result = subprocess.run(
8        ["pytest", path, "-q"], capture_output=True, text=True, timeout=120
9    )
10    output = result.stdout + result.stderr
11    return output[-4000:] if len(output) > 4000 else output

การวางแผนสำหรับงานที่ใช้เวลานาน

เมื่องานซับซ้อนขึ้น execution loop ธรรมดาจะเริ่มสูญเสียเป้าหมายเดิม หลังจาก tool calls, อ่านไฟล์ และผลลัพธ์ระหว่างกลางมากพอ context จะเต็ม และเป้าหมายจะถูกบดบังด้วยทุกสิ่งที่ตามมา

การเสื่อมสภาพอย่างช้าๆ นี้คือสิ่งที่เรียกกันว่า context rot

การวางแผนแก้ไขปัญหานี้โดยตรง agent จะสร้างแผนทีละขั้นตอนก่อนเริ่มทำงาน และเก็บแผนนั้นไว้ใน context ตลอดการดำเนินการ

แผนไม่ได้ทำงาน มันเป็นแผนที่ที่ทำให้โมเดลเชื่อมต่อกับเป้าหมายเดิม ซึ่งเป็นงานเดียวกับที่ to-do list ของ Claude Code ทำ

CrewAI เพิ่มสิ่งนี้ในระดับ crew ด้วย planning=True มันจะสร้างแผนก่อนการดำเนินการและเก็บไว้ให้พร้อมเมื่องานดำเนินไป

1from crewai import Crew, LLM
2
3crew = Crew(
4    agents=self.agents,
5    tasks=self.tasks,
6    planning=True,
7    planning_llm=LLM(model="gpt-4o-mini"),
8)

หมายเหตุ: โดยค่าเริ่มต้น CrewAI ใช้ gpt-4o-mini สำหรับการวางแผน และคุณสามารถเปลี่ยนเป็น LLM ใดก็ได้ที่คุณต้องการสำหรับขั้นตอนนั้น

agent แต่ละตัวยังสามารถใช้เหตุผลเกี่ยวกับงานของตัวเองด้วย reasoning=True:

1from crewai import Agent
2
3bug_fixer = Agent(
4    role="Bug Fixer",
5    goal="Find and describe the fix for the reported bug in the codebase.",
6    backstory="You read directories and files to build an accurate picture of the code.",
7    tools=[FileReadTool()],
8    reasoning=True,
9    max_reasoning_attempts=3  # Optional: Set a maximum number of reasoning attempts
10)

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

เมื่อเปิดใช้งาน reasoning agent จะ:

1. ไตร่ตรองงานและร่างแผนการดำเนินการ
2. ประเมินว่าแผนพร้อมหรือยัง
3. ปรับปรุงแผนถ้าจำเป็น จนกว่าจะพอใจหรือถึง max_reasoning_attempts
4. แทรกแผนการใช้เหตุผลที่เสร็จแล้วลงในงานก่อนดำเนินการ

ทั้งสองอย่างร่วมกันทำให้ agent ยึดติดกับงานที่ใช้เวลานานและลดการเบี่ยงเบนจากเป้าหมายเดิม

การมอบหมายงานด้วย subagents

การวางแผนทำให้ agent มีสมาธิ แต่ไม่ได้ลดปริมาณข้อมูลที่โมเดลต้องเก็บ ใน codebase ขนาดใหญ่ แม้แต่งานที่วางแผนมาอย่างดีก็อาจเกิน context window เดียว

การหาบั๊กหนึ่งตัวอาจต้องอ่านไฟล์หลายสิบไฟล์ และ agent หลักไม่จำเป็นต้องเก็บทั้งหมดไว้ในหน่วยความจำ

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

CrewAI รองรับสิ่งนี้ผ่านเวิร์กโฟลว์แบบลำดับชั้น (hierarchical) ซึ่ง manager agent มอบหมายให้ specialist agent และรวมผลลัพธ์ของพวกมัน

ในการตั้งค่าก่อนหน้านี้ agent Bug Fixer ตัวเดียวทำงานหนักทั้งหมด มาถ่ายโอนงานไปยัง manager และ specialist สามคน:

• Codebase Explorer สำรวจโค้ดและทำแผนที่ repository
• Software Engineer ดำเนินการเปลี่ยนแปลงตามที่ร้องขอ
• Test Runner รันการทดสอบในแซนด์บ็อกซ์และรายงานว่าผ่านหรือไม่ผ่าน
• Engineering Lead ดูแล specialist ทั้งสามคน

1from crewai import Crew, Agent, Task, Process
2
3explorer = Agent(
4    role="Codebase Explorer",
5    goal="Map the repository and surface the files relevant to the task.",
6    backstory="You read directories and files to build a picture of the code.",
7    tools=[read_file, list_dir],
8    llm=llm,
9)  # Same for other two specialist agents
10
11manager = Agent(
12    role="Engineering Lead",
13    goal="Break the request into steps and delegate each to the right specialist.",
14    backstory="You decide who does what, review tests, finish once change is done.",
15    llm=llm,
16    allow_delegation=True,
17)
18
19crew = Crew(
20    agents=[explorer, coder, tester],
21    tasks=[task],
22    manager_agent=manager,
23    process=Process.hierarchical,
24)

สิ่งหนึ่งที่ควรสังเกตคือ allow_delegation ถูกปิดไว้โดยค่าเริ่มต้น ดังนั้นต้องเปิดใช้งานอย่างชัดเจนบน manager

Sandboxing: การรักษาความปลอดภัยในการทำงานของ agent

agent ที่สามารถเข้าถึง shell สามารถรันคำสั่งที่ทำลายล้างได้ และการบอกโมเดลว่าอย่าทำอะไรไม่ใช่การป้องกัน

การป้องกันที่แท้จริงมาจากสองชั้น:

1. ระบบสิทธิ์ ที่ต้องได้รับการอนุมัติสำหรับการกระทำที่ละเอียดอ่อน
2. แซนด์บ็อกซ์ ที่แยกการทำงาน เพื่อให้แม้แต่คำสั่งที่ได้รับการอนุมัติก็ไม่สามารถสัมผัสเครื่องโฮสต์ได้

Anthropic ใช้แนวทางเดียวกัน การย้ายการทำงานของโค้ดไปยังแซนด์บ็อกซ์ช่วยลดความถี่ที่ผู้ใช้ต้องอนุมัติการกระทำ ในขณะที่ยังคงปกป้องระบบโฮสต์

Sandboxing ใน CrewAI

การรันโค้ดภายในแซนด์บ็อกซ์แทนที่จะเป็นเครื่องโฮสต์เป็นการใช้ชั้นที่สอง ในการตั้งค่านี้ โค้ดจะทำงานภายใน E2B ซึ่งจะสร้าง VM ใหม่ต่อเซสชันและทำลายทิ้งหลังจากนั้น

คำสั่ง shell และ Python ทำงานภายในสภาพแวดล้อมที่แยกออกมานี้อย่างสมบูรณ์

1from crewai_tools import E2BExecTool, E2BPythonTool
2sandbox_tools = [E2BExecTool(), E2BPythonTool()]  # run tests / run code

การอนุมัติแบบ Human-in-the-loop

การตั้งค่า human_input=True บน Task จะหยุด crew หลังจากที่มันสร้างคำตอบ คุณตรวจสอบผลลัพธ์ จากนั้นอนุมัติหรือส่งกลับไปทำซ้ำอีกครั้ง

เมื่อการทำงานถึง task นั้น CrewAI จะรอ feedback จากคุณผ่าน standard input

1from crewai import Task
2
3task = Task(
4    description=(
5        "In the working directory ./workspace, {objective}. "
6        "Explore the code first, make the change, then run the tests and report."
7    ),
8    expected_output="A summary of the files changed and the final test output.",
9    human_input=True,
10)

ถ้า crew ของคุณทำงานเบื้องหลังเว็บแอปหรืออินเทอร์เฟซแชทแทนเทอร์มินัล ระบบ human-in-the-loop ที่ใช้เว็บฮุคของ CrewAI จะจัดการขั้นตอนการตรวจสอบเดียวกัน

Memory และ checkpointing

โดยค่าเริ่มต้น agent จะลืมทุกอย่างเมื่อการรันสิ้นสุดลง กลับมาพรุ่งนี้เพื่อแก้บั๊กอื่นในโปรเจกต์เดียวกัน มันก็จะเริ่มจากศูนย์

กลไกสองอย่างช่วยให้ agent นำข้อมูลข้ามการรันได้ และแต่ละอย่างมีวัตถุประสงค์ต่างกัน:

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

Memory ใน CrewAI

CrewAI มีอินเทอร์เฟซ Memory แบบรวม แทนที่จะแยกเป็น short-term, long-term, entity และ external memory เมื่อบันทึก มันจะใช้ LLM เพื่อระบุรายละเอียดสำคัญ จัดระเบียบ และทำให้สามารถเรียกค้นได้ในภายหลัง

การตั้งค่า memory=True บน crew จะทำให้มีหน่วยความจำข้ามการรัน หลังจากแต่ละ task CrewAI จะดึงข้อเท็จจริงที่เป็นประโยชน์จาก output และเก็บไว้ และในการรันในอนาคต มันจะเรียกค้นความทรงจำที่เกี่ยวข้องและเพิ่มลงใน prompt ของ task

1from crewai import Crew
2
3crew = Crew(
4    agents=[explorer, coder, tester],
5    tasks=[task],
6    memory=True,
7)

agent ทั้งหมดใน crew แชร์หน่วยความจำร่วมกัน เว้นแต่ agent ตัวใดจะได้รับหน่วยความจำของตัวเอง

Checkpointing ใน CrewAI

checkpoint คือภาพรวมของความคืบหน้าของ agent รวมถึงการกำหนดค่า สถานะของ task หน่วยความจำ ผลลัพธ์ระหว่างกลาง อินพุต และประวัติการดำเนินการ

โดยค่าเริ่มต้น CrewAI จะสร้าง checkpoint ทุกครั้งที่ task เสร็จสมบูรณ์ ทำให้เวิร์กโฟลว์สามารถดำเนินการต่อจากจุดนั้นได้หากถูกขัดจังหวะ

checkpoint สามารถอยู่ในที่เก็บในตัวสองแห่ง:

• JsonProvider บันทึกแต่ละ checkpoint เป็นไฟล์ JSON แยกต่างหาก ซึ่งอ่านและตรวจสอบด้วยตนเองได้ง่าย
• SqliteProvider เก็บ checkpoint ทั้งหมดในฐานข้อมูล SQLite เดียว ซึ่งทำงานได้ดีกว่าภายใต้การทำ checkpoint บ่อยครั้งและภาระงานที่ใหญ่ขึ้น

1from crewai import Crew
2
3crew = Crew(
4    agents=[explorer, coder, tester],
5    tasks=[task],
6    checkpoint=True,
7)

Crew, Flow และ Agent ทั้งหมดยอมรับอาร์กิวเมนต์ checkpoint และ child จะสืบทอดจาก parent เว้นแต่จะตั้งค่าของตัวเอง

รวมทุกอย่างเข้าด้วยกัน

นี่คือฮาร์เนสเต็มรูปแบบในงานเดียว โดยมี execution loop, เครื่องมือ, การวางแผน, subagents, sandboxing และหน่วยความจำทำงานร่วมกัน:

1from crewai import Agent, Crew, LLM, Process, Task
2from crewai.tools import tool
3from crewai_tools import (DirectoryReadTool, FileReadTool, FileWriterTool,
4E2BExecTool, E2BPythonTool)
5
6llm = LLM(model="anthropic/claude-sonnet-4.6")
7
8list_dir = DirectoryReadTool(directory="./workspace")
9filesystem_tools = [FileReadTool(), FileWriterTool(), list_dir]
10sandbox_tools = [exec_tool, E2BPythonTool()]
11
12@tool("run_tests")
13def run_tests(path: str = "tests/") -> str:
14    """Sync ./workspace into the sandbox, then run pytest there."""
15    return E2BExecTool().run(command=sync_and_test_command(path))
16
17explorer = Agent(role="Codebase Explorer", goal="Map repo, surface relevant files.",
18    tools=[read_file, list_dir], llm=llm)
19coder = Agent(role="Software Engineer", goal="Implement requested change.",
20    tools=filesystem_tools, reasoning=True, llm=llm)
21tester = Agent(role="Test Runner", goal="Run tests in sandbox, report pass/fail.",
22    tools=sandbox_tools + [read_file] + [run_tests], llm=llm)
23manager = Agent(role="Engineering Lead", goal="Delegate steps, finish once tests pass.",
24    allow_delegation=True, llm=llm)
25
26task = Task(
27    description="In ./workspace, {objective}. Explore, edit, test, report.",
28    expected_output="Summary of changes and test output.", human_input=True,
29)
30crew = Crew(
31    agents=[explorer, coder, tester], tasks=[task],
32    manager_agent=manager, process=Process.hierarchical,
33    planning=True, memory=True, checkpoint=True,
34)
35result = crew.kickoff(inputs={"objective": "fix failing tests in account.py"})

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

ดังนั้นสิ่งนี้จึงถูกทดสอบกับ codebase ขนาดเล็ก ซึ่งเป็นคลาส BankAccount ที่มีบั๊กจริงสองตัวและการทดสอบห้าตัว ซึ่งสามตัวล้มเหลว กฎคือแก้ไขเฉพาะการนำไปใช้ ไม่ใช่การทดสอบ

สิ่งนี้สะท้อนถึงวิธีที่ Anthropic ประเมิน coding agent ภายใน ตัวอย่างที่เผยแพร่หนึ่งตัวอย่างคือการให้ Claude สร้างโคลนของ claude.ai ขึ้นมาใหม่โดยเทียบกับชุดทดสอบที่ล้มเหลวจำนวนมาก

ที่นี่ ฮาร์เนสพาโปรเจกต์จาก 3 ล้มเหลวและ 2 ผ่าน ไปเป็นทั้งหมด 5 ผ่าน โดยกฎการแก้ไขเฉพาะการนำไปใช้จะปิดทางลัดในการแก้ไขหรือลบการทดสอบที่ล้มเหลว

สิ่งที่ยังคงเป็นงานของคุณ

บางส่วนของระบบที่เฟรมเวิร์กไม่ได้สร้างให้คุณ:

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

นอกจากนี้ยังมีค่าใช้จ่ายของฮาร์เนสเองด้วย การวางแผน, subagents และการวนซ้ำทั้งหมดเพิ่มการเรียก API ดังนั้นการตั้งค่า agent ที่ซับซ้อนอาจมีค่าใช้จ่ายสูงกว่างานที่การเรียกโมเดลครั้งเดียวจะแก้ได้โดยตรง

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

Anthropic เดิมใช้ context resets เพื่อป้องกันไม่ให้ Claude Sonnet 4.5 จบงานเร็วเกินไป และไม่จำเป็นอีกต่อไปเมื่อมี Claude Opus 4.5 ที่มีความสามารถมากขึ้น

สรุป

นั่นคือข้อค้นพบทั้งหมด ความสามารถของ coding agent ส่วนใหญ่อยู่ในฮาร์เนส และเฟรมเวิร์กการจัดระเบียบมอบฮาร์เนสให้คุณมากกว่าที่คุณคิด

loop, การวางแผน, การมอบหมาย, sandboxing และหน่วยความจำทั้งหมดมาเป็น configuration ในขณะที่ prompts, สภาพแวดล้อมการทำงาน และการเลือกเครื่องมือยังคงเป็นของคุณ

ถ้าคุณต้องการรันสิ่งนี้กับ codebase ของคุณเอง เอกสารของ CrewAI ครอบคลุมทุกฟีเจอร์ที่ใช้ที่นี่ และเฟรมเวิร์กเป็นโอเพนซอร์สเต็มรูปแบบ

ดูเอกสาร CrewAI →

ค้นหาโค้ดทั้งหมดที่นี่ →

ขอบคุณที่อ่าน!

ขอให้มีความสุข! :)