AI Agent Memory Stack ที่ทุกคนต้องใช้ในปี 2026 (คู่มือสำหรับนักพัฒนา)

โมเดลและเครื่องมือที่คุณใช้ไม่สำคัญอีกต่อไปแล้ว

สิ่งที่สำคัญกว่าคือ.....

บริบทส่วนตัว/ความทรงจำร่วมของคุณต่างหาก

บทนำ

ผมจะแสดงวิธีสร้างความทรงจำร่วม (shared memory) ให้กับเอเจนต์เขียนโค้ดของคุณ... เพื่อให้เครื่องมือตัวต่อไปสามารถค้นหาการตัดสินใจที่คุณทำไว้แล้วได้

บทสนทนาเกี่ยวกับสถาปัตยกรรมใน Claude, การดีบักใน Codex, คำอธิบายที่ซ่อนอยู่ใน Cursor... งานที่มีประโยชน์ที่ควรจะยังคงเข้าถึงได้เมื่อคุณเปลี่ยนเครื่องมือ, เริ่มเซสชันใหม่, หรือกลับมาที่โปรเจกต์หลังจากหายไปหนึ่งเดือน

TLDR; ถ้าคุณไม่อยากอ่านทั้งหมด 3,845 คำ ก็แค่ให้ GitHub repo นี้กับเอเจนต์ของคุณ ➡️ https://github.com/codejunkie99/agentic-stack-desktop

ผมสร้างทั้งหมดนี้โดยใช้ Kimi K3 ใน Codex Harness วิดีโอถูกสร้างและตัดต่อโดยใช้ Kimi K3 ร่วมกับ Cua สำหรับ Computer Use

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

นี่คือสิ่งที่คุณจะได้รับ:

1. พื้นฐาน: สิ่งที่ยังคงอยู่เมื่อคุณเปลี่ยนเครื่องมือ
2. เส้นทางที่เร็วที่สุด: สร้างพื้นที่ทำงานที่คุณสามารถประเมินได้
3. การตั้งค่าที่ใช้งานได้: แยกการสืบสวนออกจากการนำไปปฏิบัติ
4. แบบฝึกหัดโปรเจกต์: นำบั๊กที่เกิดขึ้นซ้ำๆ ผ่านวงจรทั้งหมด
5. เลเยอร์ที่ใช้ร่วมกัน: นำการค้นคืน (retrieval) เข้าสู่เครื่องมืออื่นๆ ของคุณ
6. เลเยอร์ที่คงทน: สิ่งใดที่สมควรกลายเป็นบทเรียน
7. กฎการปฏิบัติงาน: สั้น, มีขอบเขต, ตรวจสอบได้
8. การสร้างแบบกำหนดเอง: เปลี่ยนพื้นที่ทำงานตามจุดเสียดสีจริง
9. การปรับขนาด: เพิ่มความครอบคลุมในจุดที่วงจรก่อนหน้าเผยให้เห็นช่องว่าง
10. แผนผังการสร้าง

1. พื้นฐาน: สิ่งที่ยังคงอยู่เมื่อคุณเปลี่ยนเครื่องมือ

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

การนำไปปฏิบัติถูกคอมมิต (commit) คำอธิบายยังคงอยู่ในบทสนทนา

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

ทำให้เหตุผลสามารถกู้คืนได้

เริ่มต้นที่นี่: ทำให้การอภิปรายนั้นสามารถกู้คืนได้, จากนั้นทำให้เอเจนต์ตัวถัดไปตรวจสอบก่อนที่จะลงมือทำ

Agentic Stack จัดเตรียมพื้นที่ทำงาน macOS ดั้งเดิมพร้อมประวัติที่ค้นหาได้และเลือกได้จาก Claude Code, Codex, OpenCode และ Cursor Claude Code และ Codex ยังทำงานผ่าน CLI อย่างเป็นทางการของพวกเขา; Cursor และ OpenCode ในปัจจุบันให้เฉพาะบริบทเท่านั้น ภาพรวม repo

เวิร์กโฟลว์ด้านล่างคือวิธีที่ผมจะใช้ความสามารถเหล่านั้น บรีฟ, การแบ่งหน้าที่รับผิดชอบ, และแบบฝึกหัดโปรเจกต์เป็นแนวทางปฏิบัติที่แนะนำซึ่งคุณสามารถปรับใช้ได้

2. เส้นทางที่เร็วที่สุด: สร้างพื้นที่ทำงานที่คุณสามารถประเมินได้

เริ่มต้นด้วย repository ที่คุณเข้าใจ เลือกสิ่งที่คุณรู้จักไฟล์สำคัญ, จำการตัดสินใจล่าสุดได้, และสามารถรับรู้คำแนะนำที่ไม่ดีได้

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

สำหรับการสร้างจากซอร์ส (source build) ข้อกำหนดที่บันทึกไว้รวมถึง macOS 14+, Python 3.10+, Xcode Command Line Tools และ Swift 6 toolchain ติดตั้งและลงชื่อเข้าใช้ CLI การเขียนโค้ดที่คุณต้องการเรียกใช้ ข้อกำหนด

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

เปิด repository ของคุณในแอปและทำตามขั้นตอนการตั้งค่าแบบมีไกด์ (Guided setup) นี่คือพรีวิวที่มีการเซ็นชื่อแบบ ad hoc ดังนั้น macOS อาจต้องยืนยันในการเปิดครั้งแรก การตั้งค่า

ตั้งค่าการตรวจสอบการยอมรับครั้งแรก

ก่อนที่จะนำเข้าอะไร ให้เขียนคำถามที่คุณต้องการให้เอเจนต์ตัวแรกตอบ เช่น: ทำไมงานส่งออก (export job) ของเราถึงประมวลผลเรกคอร์ดเป็นชุดๆ และการใช้งานปัจจุบันยังจำเป็นต้องมีขีดจำกัดนั้นอยู่หรือไม่?

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

2.1 การนำเข้าครั้งแรก: ให้มันมีการตัดสินใจที่คุ้มค่าต่อการค้นหา

เปิด Knowledge Graph → Graph → Import memory, ดูตัวอย่างแหล่งที่มา, และเลือกเนื้อหาที่คุณต้องการรวม

กราฟใช้ SQLite full-text search, โดยมีการเชื่อมต่อตามหัวข้อ, ลิงก์ repository และที่มา; คลังแชทดั้งเดิมยังคงไม่เปลี่ยนแปลง พฤติกรรมการนำเข้า

ผมจะเริ่มต้นด้วยบทสนทนาที่เสร็จสมบูรณ์ซึ่งมีการตัดสินใจที่คุณจำได้ โดยเฉพาะอย่างยิ่งบทสนทนาที่คุณปฏิเสธสิ่งที่น่าสนใจเพราะข้อจำกัดที่จะไม่ชัดเจนจากโค้ดสุดท้าย

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

ทดสอบว่าคุณสามารถค้นหามันอีกครั้งได้หรือไม่

จากนั้นลองค้นหาครั้งที่สองโดยใช้คำศัพท์ที่คุณจะใช้ตามธรรมชาติในเดือนหน้า คุณอาจจำชื่อฟีเจอร์ได้ในขณะที่บทสนทนาใช้ชื่อโมดูลภายใน การพบความไม่ตรงกันนั้นตอนนี้จะช่วยให้คุณเข้าใจวิธีเรียกค้นเนื้อหาในภายหลัง

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

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

ขยายคอลเล็กชันเมื่อมีงานอื่นให้เหตุผลแก่คุณ

2.2 เซสชันการทำงานครั้งแรก: ทำให้การทดลองเล็กพอที่จะเสร็จ

ผมจะกำหนดเส้นชัยให้กับการตั้งค่าเริ่มต้นก่อนที่จะเปิดหน้าจอการกำหนดค่าอื่น เมื่อสิ้นสุดเซสชัน คุณควรจะสามารถกู้คืนการตัดสินใจที่รู้จัก, ตรวจสอบกับ repository, และสร้างรีวิวที่คุณสามารถอธิบายให้คนอื่นฟังได้

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

เก็บโน้ตสั้นๆ ไว้ข้างแบบฝึกหัด: คำถาม, แหล่งที่มาที่คาดหวัง, การใช้งานปัจจุบัน, และส่วนที่ต้องการการตัดสินใจ นี่คือข้อมูลอ้างอิงของคุณสำหรับการประเมินคำตอบ

วินิจฉัยความล้มเหลวที่ถูกต้อง

• ถ้าผู้ตรวจสอบกู้คืนบทสนทนาที่ผิด ให้ปรับปรุงการเรียกค้น
• ถ้ามันพบบทสนทนาที่ถูกต้องแต่อ่านโค้ดผิด ให้ปรับปรุงการสืบสวน
• ถ้าผลการตรวจสอบถูกต้องแต่การนำไปปฏิบัติพลาดข้อกำหนด ให้ปรับปรุงการส่งมอบงาน (handoff)

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

ทำให้วงจรที่สมบูรณ์ที่เล็กที่สุดเสร็จ, บันทึกสิ่งที่ล้มเหลว, และใช้หลักฐานนั้นเพื่อเลือกการปรับปรุงครั้งต่อไป

3. การตั้งค่าที่ใช้งานได้: แยกการสืบสวนออกจากการนำไปปฏิบัติ

การตั้งค่าแรกที่ผมแนะนำมีผู้ตรวจสอบแบบอ่านอย่างเดียว (read-only reviewer) และผู้ดำเนินการ (implementer) ที่มีสิทธิ์แก้ไขโปรเจกต์ ให้แต่ละคนมีสิ่งที่ส่งมอบที่ชัดเจน และทำให้การส่งมอบงานเป็นสิ่งที่คุณสามารถอ่านได้ก่อนที่จะเริ่มการเปลี่ยนแปลงใดๆ

โปรไฟล์เอเจนต์รองรับ runner, model, effort, คำแนะนำ และการเข้าถึงไฟล์ บทสนทนาเป็นของโปรเจกต์ และการติดตามผลจะดำเนินการต่อเซสชัน CLI พื้นฐาน โมเดลบทสนทนา

1. เอเจนต์ 1: ผู้ตรวจสอบ ได้รับคำถามแรก: เราตัดสินใจอะไร, โค้ดตอนนี้ทำอะไร, และมีช่องว่างที่ควรจัดการหรือไม่?
2. เอเจนต์ 2: ผู้ดำเนินการ ได้รับคำตอบที่ตรวจสอบแล้วพร้อมกับคำขอที่มีขอบเขต: ทำการเปลี่ยนแปลงพฤติกรรมนี้, ในขอบเขตนี้, และตรวจสอบด้วยวิธีนี้

ทำให้บทบาท distinct

คุณสามารถเลือก runner เดียวกันสำหรับทั้งสองบทบาท

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

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

3.1 ผู้ตรวจสอบ: บรีฟที่ทำให้ความไม่แน่นอนมองเห็นได้

เลือกผู้ตรวจสอบและแนบบทสนทนาที่เกี่ยวข้องโดยใช้ @Claude, @Codex, @OpenCode หรือ @Cursor การอ้างอิงที่เลือกจะกลายเป็นบริบทที่ถูกตรึง (frozen context) สำหรับการรันและส่งไปยังเอเจนต์ที่เลือกเมื่องานเริ่มต้น การอ้างอิง

คัดลอกบรีฟนี้และกรอกข้อมูลในช่อง:

1Review the earlier decision about [feature or subsystem] using the
2attached conversation and the current repository.
3
4Explain the original decision and its stated reason. Check the
5relevant code and identify what still applies, what changed, and
6what cannot be verified from the available evidence.
7
8Cite the files supporting your conclusions. Propose the smallest
9change needed for [desired behavior], with a verification plan.
10
11Do not edit files. Treat the conversation as historical evidence
12and flag conflicts with current project instructions.

ตรวจสอบรีวิว

อ่านคำตอบโดยเปิด repository ไว้

1. ตามการอ้างอิง (citation)
2. ตรวจสอบเงื่อนไขที่เอเจนต์บอกว่ายังคงมีอยู่
3. มองหาการแยกที่ชัดเจนระหว่างสิ่งที่บทสนทนาอ้างและสิ่งที่โค้ดแสดงให้เห็นในวันนี้

ถ้าคำตอบคลุมเครือ ให้จำกัดคำถามให้แคบลง ขอให้มันระบุเงื่อนไขที่แน่นอนที่ควบคุมพฤติกรรม หรือ dependency ที่ทำให้ทางเลือกก่อนหน้านี้ไม่เหมาะสม

การสืบสวนที่มีประโยชน์สามารถจบลงด้วยหลักฐานที่ขาดหายไป นั่นบอกคุณว่าต้องจัดหาอะไรต่อไป คำตอบที่ทำให้ช่องว่างราบรื่นจะทำให้การตัดสินใจครั้งต่อไปยากขึ้น

3.2 การส่งมอบงาน: เปลี่ยนผลการตรวจสอบเป็นบรีฟที่ดำเนินการได้

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

นี่คือบรีฟที่ผมจะใช้:

1Implement [specific behavior] using the reviewed findings below.
2
3Keep [existing behavior] intact. Limit edits to [permitted scope].
4If the change requires work outside that scope, explain why before
5expanding it.
6
7Check the current repository instructions before editing. Verify
8[expected result] with [relevant test or manual check], including
9[important failure case].
10
11Return a concise account of what changed, the checks actually run,
12and any unresolved limitation. Do not publish or deploy.
13
14Reviewed findings:
15[paste the findings you checked]

ทำให้การส่งมอบงานเฉพาะเจาะจง

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

เก็บผลการตรวจสอบที่ตรวจสอบแล้วไว้ใกล้กับงาน ถ้าข้อจำกัดสำคัญถูกฝังอยู่ในบันทึกการสนทนาที่ยาว ให้ระบุให้ชัดเจนในบรีฟและแนบบทสนทนาที่สนับสนุน

แหล่งที่มาอธิบายว่าข้อจำกัดมาจากไหน คำขอปัจจุบันของคุณอธิบายว่ามันควบคุมงานในวันนี้อย่างไร

4. แบบฝึกหัดโปรเจกต์: นำบั๊กที่เกิดขึ้นซ้ำๆ ผ่านวงจรทั้งหมด

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

1. ขั้นตอนที่ 1: ขั้นแรก, ดึงบทสนทนานั้นมา ขอให้ผู้ตรวจสอบระบุว่าการสืบสวนก่อนหน้านี้ระบุอะไรไว้ จากนั้นตรวจสอบเส้นทางการลองใหม่ปัจจุบันกับสิ่งนั้น
2. ขั้นตอนที่ 2: สมมติว่าการอภิปรายเก่าบอกว่าคำขอสามารถทำซ้ำได้หลังจากได้รับการตอบสนองที่ไม่แน่นอน ผู้ตรวจสอบควรระบุว่าการใช้งานปัจจุบันยังอนุญาตให้ทำเช่นนั้นหรือไม่, โค้ดใดควบคุมมัน, และมีกลไกที่มีอยู่แล้วที่ตั้งใจจะป้องกันการซ้ำซ้อนหรือไม่
3. ขั้นตอนที่ 3: ถ้าหลักฐานสนับสนุนการเปลี่ยนแปลง ให้บรีฟผู้ดำเนินการเกี่ยวกับกรณีความล้มเหลว ระบุว่าคำขอที่ทำซ้ำควรทำอะไร, พฤติกรรมการส่งออกที่มีอยู่ใดที่ต้องคงไว้, และคุณจะตรวจสอบการตอบสนองที่ถูกขัดจังหวะอย่างไร
4. ขั้นตอนที่ 4: จากนั้นตรวจสอบการเปลี่ยนแปลงและทดสอบเส้นทางที่เกี่ยวข้อง ตรวจสอบทั้งการส่งออกที่สำเร็จและการลองใหม่หลังจากความไม่แน่นอน ถ้าสภาพแวดล้อมไม่สามารถจำลองการขัดจังหวะได้ ให้บันทึกข้อจำกัดนั้นและตัดสินใจว่าต้องการการตรวจสอบเพิ่มเติมอะไร
5. ขั้นตอนที่ 5: สุดท้าย, ทบทวนบทเรียนที่คุณอาจเก็บไว้: เงื่อนไขที่ทำให้เกิดการซ้ำซ้อน, กลไกที่จัดการกับมัน, และหลักฐานที่สนับสนุนการแก้ไข

ตัวอย่างนี้เป็นแบบฝึกหัดที่เสนอ ไม่ใช่การอ้างว่ามีบั๊กใน Agentic Stack แทนที่ด้วยความล้มเหลวจริงจากโปรเจกต์ของคุณเองและรักษาลำดับเดียวกัน

5. เลเยอร์ที่ใช้ร่วมกัน: นำการค้นคืนเข้าสู่เครื่องมืออื่นๆ ของคุณ

เดสก์ท็อปสามารถติดตั้งการผสานรวมผ่าน Tools → Connections → Use @ in tools → Enable in all four tools คำสั่งที่เทียบเท่าคือ:

1agentic-stack context install

รีสตาร์ทเครื่องมือหลังจากนั้น จุดเข้า MCP เผยให้เห็นการค้นหาบทสนทนา, การอ่านแชทที่เลือก และการค้นหาความทรงจำที่ใช้ร่วมกัน การผสานรวม

พฤติกรรมของ Picker ขึ้นอยู่กับไคลเอนต์; ในกรณีที่ไม่มีการเติมทรัพยากรให้สมบูรณ์ (resource completion) เอเจนต์สามารถค้นหาและนำเสนอบทสนทนาที่ตรงกัน พฤติกรรมไคลเอนต์

ทดสอบความต่อเนื่องข้ามเครื่องมือ

การตรวจสอบครั้งแรกของผมคือขอให้เครื่องมืออื่นค้นหาการตัดสินใจเดียวกับที่คุณเพิ่งตรวจสอบ ให้หัวข้อแก่เครื่องมือ, ขอให้นำเสนอแหล่งที่มาที่ตรงกัน, และยืนยันการเลือกก่อนที่จะขอการวิเคราะห์

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

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

6. เลเยอร์ที่คงทน: สิ่งใดที่สมควรกลายเป็นบทเรียน

การค้นคืนนำเนื้อหาเก่ากลับมามองเห็น คุณยังคงต้องตัดสินใจว่าเนื้อหานั้นควรมีอำนาจเท่าใด

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

Tasks เก็บบันทึกการดำเนินการ Knowledge → Lessons รองรับการจัดเตรียม, การยอมรับ, การปฏิเสธ และการทบทวนบทเรียนพร้อมเหตุผล ในขณะที่ประวัติที่นำเข้ายังคงแยกจากบทเรียนที่ยอมรับ วงจรชีวิตการตรวจสอบ

เขียนบทเรียนที่คุณสามารถท้าทายได้

ผมจะเขียนบทเรียนที่เสนอพร้อมรายละเอียดเพียงพอที่จะถูกท้าทาย: เงื่อนไขที่ใช้, พฤติกรรมที่แนะนำ, เหตุผล, และหลักฐาน

สำหรับบั๊กการส่งออกสมมติ "ลองใหม่อย่างปลอดภัยเสมอ" คลุมเครือเกินไปที่จะช่วยได้ โน้ตที่มีประโยชน์ระบุว่าอะไรทำให้การลองใหม่ไม่แน่นอน และการใช้งานโปรเจกต์นี้ควรรับรู้งานที่ทำซ้ำได้อย่างไร

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

นี่คือวิธีที่ผมจะเก็บการแก้ไขที่มีประโยชน์ไม่ให้กลายเป็นกฎที่มีอายุยืนกว่าเหตุผลของมัน

6.1 โครงสร้างความทรงจำ: ใส่ความรู้แต่ละประเภทในที่ของมัน

ภายใต้เดสก์ท็อป สถาปัตยกรรม .agent/ แบบพกพาจะแยกสถานะการทำงาน, เหตุการณ์ก่อนหน้า, รูปแบบที่คงทน และความชอบส่วนบุคคล Skills จัดเตรียมขั้นตอนที่ใช้ซ้ำได้ ในขณะที่ Protocols อธิบายสิทธิ์และการมอบหมาย สถาปัตยกรรม

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

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

เปลี่ยนขั้นตอนที่ตรวจสอบแล้วเป็น Skill

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

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

7. กฎการปฏิบัติงาน: สั้น, มีขอบเขต, ตรวจสอบได้

นี่คือกฎที่ผมจะวางไว้รอบๆ เวิร์กโฟลว์ตั้งแต่โปรเจกต์แรก

1. กฎข้อที่ 1: ทุกบรีฟระบุสิ่งที่ส่งมอบ รีวิวส่งคืนผลการตรวจสอบพร้อมหลักฐาน การนำไปปฏิบัติส่งคืนการเปลี่ยนแปลงพฤติกรรมพร้อมการตรวจสอบ ข้อเสนอบทเรียนส่งคืนข้อกล่าวอ้างที่คุณสามารถยอมรับหรือปฏิเสธได้
2. กฎข้อที่ 2: การเข้าถึงเป็นไปตามงาน การสืบสวนเริ่มต้นด้วยการเข้าถึงแบบอ่านอย่างเดียว; การนำไปปฏิบัติได้รับขอบเขตที่จำเป็นสำหรับการเปลี่ยนแปลงที่ตกลงกันไว้ ให้การเผยแพร่, การปรับใช้ และการดำเนินการอื่นๆ ที่มีผลตามมาชัดเจนในคำขอ
3. กฎข้อที่ 3: ขอการตรวจสอบจริง รายงานควรบอกว่าสิ่งใดทำงานและเกิดอะไรขึ้น ถ้าการตรวจสอบไม่พร้อมใช้งาน ให้ทำให้มองเห็นได้แทนที่จะถือว่าผลลัพธ์ที่ขาดหายไปเป็นความสำเร็จอย่างเงียบๆ
4. กฎข้อที่ 4: ทำให้บริบททางประวัติศาสตร์อยู่ภายใต้หลักฐานปัจจุบันและคำแนะนำโปรเจกต์ที่เกี่ยวข้อง บทสนทนาที่ดึงมาสามารถอธิบายการตัดสินใจก่อนหน้านี้ในขณะที่ยังล้าสมัยได้
5. กฎข้อที่ 5: ตรวจสอบผลลัพธ์ก่อนที่จะเก็บข้อสรุป คำอธิบายของเอเจนต์เกี่ยวกับงานของตัวเองเป็นสิ่งที่ต้องตรวจสอบควบคู่ไปกับ diff และพฤติกรรมที่สังเกตได้

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

7.1 คิวตรวจสอบ: ทำให้งานง่ายต่อการยอมรับหรือส่งกลับ

ผมจะขอให้ทุกการนำไปปฏิบัติเสร็จในรูปแบบเดียวกัน:

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

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

เมื่อคุณส่งบางอย่างกลับ ให้แนบการแก้ไขกับข้อกำหนดที่มันพลาดไป "นี่ผิด" เริ่มต้นการเดารอบอื่น "การลองใหม่สร้างการส่งออกครั้งที่สองภายใต้เงื่อนไขนี้; รักษาเอกลักษณ์คำขอเดิมและรันการตรวจสอบนี้อีกครั้ง" ระบุช่องว่าง

ตัดสินใจว่าสิ่งใดสมควรอยู่รอด

หลังจากที่การแก้ไขผ่านไป ให้ตัดสินใจว่ามันแสดงถึงข้อจำกัดที่เกิดขึ้นซ้ำๆ หรือรายละเอียดของงานนั้น บันทึกสิ่งแรกเมื่อมันมีหลักฐานสนับสนุน สิ่งหลังสามารถอยู่ในประวัติของงานได้

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

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

7.2 ระเบียบวินัยด้านต้นทุน: ให้ทุกการรันมีเงื่อนไขการหยุด

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

ถ้าเอเจนต์ค้นพบปัญหาที่ใหญ่กว่า ให้ขอให้มันอธิบายสิ่งที่ค้นพบและความสัมพันธ์กับงานเดิมก่อนที่จะรวมงานนั้นเข้ากับการเปลี่ยนแปลงปัจจุบัน

ตัดสินใจว่าสิ่งนี้เป็นของงานปัจจุบันหรือไม่

เปรียบเทียบผลลัพธ์และบังคับใช้ขีดจำกัด

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

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

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

8. การสร้างแบบกำหนดเอง: เปลี่ยนพื้นที่ทำงานตามจุดเสียดสีจริง

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

เขียนจุดเสียดสีลงไปก่อนที่จะเสนอฟีเจอร์ อธิบายการกระทำที่คุณพยายามทำ, คุณเสียเวลาที่ไหน, และพฤติกรรมที่ปรับปรุงแล้วจะช่วยให้คุณทำอะไรได้บ้าง

จากนั้นเปิด repository ต้นทางและให้คำขอการเปลี่ยนแปลงที่มีขอบเขตแก่เอเจนต์ของคุณ รวมถึงวิธีที่คุณตั้งใจจะตรวจสอบผลลัพธ์ในแอป

สร้างและตรวจสอบการเปลี่ยนแปลง

repository บันทึกคำสั่งการพัฒนาและแพ็คเกจเหล่านี้:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

คำสั่งการพัฒนา

การเปลี่ยนแปลง SwiftUI ต้องการการ rebuild และ restart เพื่อตรวจสอบ เวิร์กโฟลว์เดสก์ท็อป

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

ใช้มาตรฐานเดียวกับที่คุณใช้กับแบบฝึกหัดการส่งออก: ก่อนที่เป็นรูปธรรม, การเปลี่ยนแปลงที่มีขอบเขต, และหลังที่สังเกตได้

8.1 ตัวเลือกระยะไกล: ตัดสินใจว่างานควรอยู่ที่ไหน

หลังจากที่เวิร์กโฟลว์ในเครื่องทำงานแล้ว คุณอาจต้องการให้ดำเนินการบนเซิร์ฟเวอร์ถาวร เส้นทางการโฮสต์ด้วยตนเอง (self-hosting) เชื่อมต่อแอปเนทีฟกับบริการเจ้าของคนเดียวที่เป็นเจ้าของโปรเจกต์, ความทรงจำ, ประวัติงาน และการลงชื่อเข้าใช้ CLI ของมัน; การเปลี่ยนโฮสต์จะไม่ถ่ายโอนข้อมูลหรือข้อมูลประจำตัวของ Mac ของคุณโดยอัตโนมัติ คู่มือการโฮสต์

แปลจากภาษาอังกฤษเป็นภาษาไทย

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

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

ตรวจสอบสภาพแวดล้อมที่เลือก

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

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

การทำงานในเครื่องท้องถิ่นก็เพียงพอที่จะเรียนรู้รูปแบบหลัก ขยายโครงสร้างพื้นฐานเมื่องานให้เหตุผลแก่คุณ

9. การขยายขนาด: เพิ่มความครอบคลุมในจุดที่วงจรก่อนหน้าเผยให้เห็นช่องว่าง

ฉันจะขยายการตั้งค่านี้ตามบริบทที่ขาดหายไปซึ่งคุณพบเจอระหว่างงานจริง

• หากการตรวจสอบต้องการการอภิปรายสถาปัตยกรรมก่อนหน้านี้ ให้นำเข้าการอภิปรายนั้น
• หากการนำไปใช้ต้องใช้ขั้นตอนเดิมซ้ำๆ ให้พัฒนาและตรวจสอบทักษะ
• หากการตัดสินใจถูกเปิดขึ้นมาอีกครั้ง ให้เขียนบทเรียนที่มีขอบเขตพร้อมหลักฐานที่สนับสนุน

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

ขยายเมื่องานเป็นตัวกำหนด

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

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

9.1 นิสัยการบำรุงรักษา: ทบทวนความรู้เมื่อระบบเปลี่ยนแปลง

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

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

ส่วนสำคัญคือการรักษาคำอธิบายไว้ ผู้สร้างในอนาคตควรสามารถเข้าใจได้ว่าทำไมกฎก่อนหน้านี้จึงมีอยู่ และอะไรเปลี่ยนแปลงมากพอที่จะแทนที่มัน

รีเฟรชขั้นตอนและแก้ไขข้อขัดแย้ง

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

สิ่งนี้ช่วยให้การบำรุงรักษาเชื่อมโยงกับเหตุการณ์จริงในโปรเจกต์ คุณกำลังตรวจสอบความรู้ที่มีแนวโน้มจะล้าสมัยมากที่สุด โดยมีหลักฐานปัจจุบันอยู่ตรงหน้าคุณแล้ว

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

ทิ้งการส่งมอบที่เป็นประโยชน์

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

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

10. แผนงานสร้าง

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

เริ่มต้นด้วยการตัดสินใจหนึ่งครั้งในสัปดาห์นี้ และดำเนินการผ่านวงจรทั้งหมดก่อนที่จะนำเข้าประวัติทั้งหมดของคุณ

เอเจนต์ถัดไปควรสืบทอดวิจารณญาณของคุณ