ทุกระบบเอเจนต์ต้องเผชิญกับข้อแลกเปลี่ยน (trade-off) ที่น่าลำบากใจแบบเดียวกัน คุณต้องการฐานความรู้ที่ลึกและมีการจัดระเบียบอย่างดี ซึ่งสามารถคงอยู่ผ่านการทำ code review และ git history แต่ในขณะเดียวกัน คุณก็ต้องการให้ runtime ทำงานได้อย่างรวดเร็วและมีสมาธิ (focused) ความต้องการทั้งสองอย่างนี้ขัดแย้งกันเอง ยิ่งคุณเก็บรักษาคำสั่ง (instructions) ไว้มากเท่าไหร่ มันก็ยิ่งเย้ายวนใจที่จะเทคำสั่งทั้งหมดลงไปใน prompt แล้วหวังว่าผลลัพธ์จะออกมาดี แต่ความหวังนั้นมีราคาแพง
ในระบบนิเวศของ Agent Project Context ความตึงเครียดนี้ถูกแบ่งออกเป็นสองเลเยอร์อย่างชัดเจน APC จัดการเรื่องความคงทน (durability) ส่วน APX จัดการเรื่องความเร็ว การทำความเข้าใจว่าพวกมันทำงานร่วมกันอย่างไร—และทำไม APX ถึงปฏิเสธที่จะโหลด (preload) คำจำกัดความของสกิล (skill definition) ทั้งหมดไว้ล่วงหน้า—จะช่วยให้คุณเข้าใจเรื่อง prompt engineering ได้มากกว่าที่คู่มือการปรับแต่ง (optimization guides) ส่วนใหญ่จะบอกคุณ
คลังเก็บข้อมูลและเอนจิน
หน้าที่ของ APC คือความคงทนถาวร มันจัดเก็บไฟล์สกิลที่นำกลับมาใช้ใหม่ได้ไว้ภายใต้ .apc/skills/ ในรูปแบบเอกสาร Markdown ธรรมดา เนื่องจากไฟล์เหล่านี้อยู่ใน repository ของคุณ พวกมันจึงถูกจัดการไปพร้อมกับ version control คุณสามารถเปิด pull request เพื่อเปลี่ยนขั้นตอนการ deployment ได้ คุณสามารถทำ diff เพื่อดูการ rollback นโยบายความปลอดภัยเมื่อหกสัปดาห์ก่อนได้ และคุณสามารถตรวจสอบ (audit) ได้อย่างแม่นยำว่าเอเจนต์ควรจะรู้อะไรและเมื่อใด ความสามารถในการตรวจสอบนี้มีความสำคัญอย่างยิ่งเมื่อการ deployment ที่ผิดพลาดถูกนำไปใช้งานจริง หรือเมื่อผู้ตรวจสอบการปฏิบัติตามกฎระเบียบ (compliance auditor) เริ่มตั้งคำถาม
ในทางกลับกัน APX ทำงานอยู่กับปัจจุบัน มันจัดการการสนทนาจริงระหว่างคุณและโมเดล เป้าหมายของมันไม่ใช่การจัดเก็บความรู้ แต่เป็นการนำความรู้นั้นมาใช้อย่างแม่นยำ เมื่อ APX ปฏิบัติต่อสกิลเหมือนเป็นภาระที่ต้องพกติดตัวไปตลอดเวลา ระบบทั้งหมดจะช้าลง context window จะเต็มขึ้น ค่าโทเคน (token costs) จะสูงขึ้น และที่แย่กว่านั้นคือ ความสนใจ (attention) ของโมเดลจะกระจัดกระจายไปยังคำสั่งที่ไม่มีความเกี่ยวข้องใดๆ กับคำขอในปัจจุบันเลย
นี่คือเหตุผลว่าทำไมเนื้อหาของสกิล (skill bodies) จึงถูกโหลดตามความต้องการ (on demand)
ราคาที่แท้จริงของ Prompt ที่บวมเกินไป
ทีมส่วนใหญ่เข้าใจว่าโทเคนมีต้นทุน แต่มีเพียงไม่กี่ทีมที่ตระหนักว่าโทเคนที่ไม่มีความเกี่ยวข้องนั้นมีต้นทุนเป็นความแม่นยำ
เมื่อ APX ฉีด (inject) ทุกสกิลที่มีเข้าไปในทุกรอบการสนทนา (turn) prompt จะเริ่มเต็มไปด้วยสัญญาณรบกวน (noisy) โมเดลจะได้รับทั้งคู่มือการ deployment, คู่มือความปลอดภัย, เอกสารอ้างอิงสไตล์ API, รายการตรวจสอบการทดสอบ (testing checklist) และคำถามที่พบบ่อย (FAQ) ในการเริ่มต้นใช้งาน ทั้งหมดนี้พร้อมกันในคราวเดียว แม้จะมี context window ขนาดใหญ่ แต่คุณภาพของการใช้เหตุผล (reasoning quality) จะลดลงเมื่อโมเดลต้องคัดกรองสัญญาณรบกวนเพื่อค้นหาสัญญาณที่สำคัญ (signal) โมเดลอาจไปยึดติดกับข้อกำหนดด้านความปลอดภัยที่ใช้สำหรับการ deployment บน production ในขณะที่กำลังตอบคำถามเกี่ยวกับการตั้งค่าการทดสอบในเครื่อง (local test setup) หรืออาจเกิดอาการหลอน (hallucinate) โดยนำขั้นตอนจากรายการตรวจสอบการปล่อยเวอร์ชัน (release checklist) มาปนกับขั้นตอนการแก้ไขบั๊กง่ายๆ ทุกย่อหน้าที่เป็นข้อความที่ไม่เกี่ยวข้องคือสิ่งเบี่ยงเบนความสนใจที่รอวันเกิดขึ้น
ตรรกะทางคณิตศาสตร์นั้นตรงไปตรงมา การสนทนาส่วนใหญ่ไม่จำเป็นต้องใช้สกิลส่วนใหญ่ หากคุณกำลังขอให้แก้ไข error log อย่างรวดเร็ว คุณไม่จำเป็นต้องใช้ข้อความฉบับเต็มของคู่มือการ deployment หรือคู่มือการเสริมความปลอดภัย (security hardening guide) สิ่งที่คุณต้องการคือให้โมเดลเห็นข้อผิดพลาด เข้าใจธรรมเนียมปฏิบัติ (conventions) ของโปรเจกต์คุณ และแก้ไขไฟล์ที่ถูกต้อง การโหลดเนื้อหาของสกิลที่ไม่เกี่ยวข้องไม่ได้ช่วยให้โมเดลทำสิ่งนี้ได้ แต่มันกลับบังคับให้โมเดลต้องกรองข้อมูลที่ไร้ประโยชน์ออกไปก่อนที่จะเริ่มทำงานกับปัญหาจริงๆ ของคุณเสียด้วยซ้ำ
การโหลดตามความต้องการ (On-Demand Loading) ทำงานอย่างไร
กลไกนี้เรียบง่ายแต่ผ่านการคิดมาอย่างดี APC ยังคงเป็นผู้ถือความจริงสูงสุด (ground truth) คำจำกัดความของสกิลของคุณยังคงอยู่ที่เดิมที่มันควรอยู่ นั่นคือใน .apc/skills/<name>.md
APX ไม่ได้คัดลอก (mirror) ไฟล์เหล่านั้นลงในหน่วยความจำที่ใช้งานอยู่ (active memory) แต่จะรวบรวมทะเบียนรายชื่อสกิล (registry) ที่กะทัดรัดขึ้นมาแทน โมเดลจะเห็นรายการนี้และเข้าใจว่ามีแคตตาล็อกอยู่ หากมันต้องการเรียกดูหรือยืนยันว่ามีความสามารถใดบ้างที่พร้อมใช้งาน มันสามารถเรียกใช้ list_skills ได้ วิธีนี้ช่วยให้โมเดลมองเห็นภาพรวมได้โดยไม่เพิ่มปริมาณข้อมูลที่มากเกินไป
เมื่อภารกิจนั้นต้องการไวยากรณ์ (syntax) ที่แม่นยำ ขั้นตอนโดยละเอียด หรือข้อจำกัดเฉพาะที่ถูกเข้ารหัสไว้ในไฟล์สกิล โมเดลจะเรียกใช้ load_skill ณ จุดนั้น และจุดนั้นเท่านั้นที่ APX จะไปดึงเนื้อหา Markdown ฉบับเต็มจาก APC และฉีดเข้าไปใน context คำสั่งจะถูกส่งมาแบบพร้อมใช้งานทันที (hot) ถูกใช้เพียงครั้งเดียวตามวัตถุประสงค์ที่ตั้งไว้ และระบบก็ไม่ต้องแบกมันไปมาเหมือนเป็นน้ำหนักส่วนเกินที่ไร้ประโยชน์
ลองนึกถึงความแตกต่างระหว่างการ import library กับการคัดลอกคำจำกัดความของทุกฟังก์ชันมาวางไว้ในไฟล์หลักของคุณ วิธีหนึ่งช่วยให้ codebase ของคุณยังคงสามารถไล่ดูได้ง่าย (navigable) ส่วนอีกวิธีหนึ่งจะสร้างความวุ่นวายที่อาจจะคอมไพล์ผ่านได้เพียงเพราะความบังเอิญเท่านั้น
ใครจะเป็นผู้ชนะเมื่อสกิลเกิดการขัดแย้งกัน
APX ยังบังคับใช้ลำดับความสำคัญที่ชัดเจนเมื่อมีการโหลดสกิล สภาพแวดล้อมแต่ละอย่างไม่เหมือนกัน และคำแนะนำทั่วไปไม่ควรมาแทนที่ความรู้เฉพาะส่วน (local knowledge)
Project skills take the top priority. These files live in your current repository under .apc/skills/. They capture your team’s specific conventions, your custom wrappers, your legacy naming standards, and your particular toolchain. If your project defines its own way of handling database migrations, that definition wins.
Global skills come next. These cover organization-wide patterns that apply when the project itself stays silent. They act as a standard library.
Built-in runtime skills sit at the bottom as the fallback. They handle generic capabilities that every agent should understand but that no specific project has bothered to redefine.
This layered approach means your repository keeps control over its own behavior. A global or built-in skill cannot accidentally hijack a workflow that your team has intentionally customized.
What This Looks Like in Practice
Picture a typical maintenance task. A teammate pastes an error log into the chat. The traceback points to a single null reference in a utility module. The fix is likely two lines of defensive coding.
In a system without on-demand loading, APX would stuff the context with every skill it knows. The model now has forty pages of text to consider before touching those two lines. It sees the release checklist and wonders if it should bump a version. It sees the security guide and contemplates input validation on a function that just needs a null check. It sees the deployment runbook and starts thinking about staging environments. The model drifts. The response takes longer. The token meter spins.
With APX’s on-demand design, the model sees only the names. It knows that [release-checklist], [security-guide], [deployment-runbook], and [error-handling] exist. It ignores the first three. It might load [error-handling] if your project’s conventions for null safety are specific. It fixes the bug. The unrelated skills never entered the context window. The model stayed focused because the prompt stayed clean.
The same logic holds when the task actually is complex. If you later ask the agent to prepare a production deployment, it can load the deployment runbook, consult the security guide, and follow the release checklist exactly when those steps become relevant. The knowledge was always there. It simply waited for the right moment.
Prompt Discipline as Architecture
The separation between APC and APX is not just an implementation detail. It is a philosophy of prompt discipline. APC preserves knowledge forever, making it reviewable, versioned, and safe. APX decides how much of that knowledge earns a place in the active context right now.
A rich skill catalog is an asset. A bloated prompt is a liability. The goal is to keep your context portable without making it always active. Your repository should contain every instruction your team has ever written, but the agent should read only the ones that help with the immediate task.
If your system forces the model to carry every skill body into every turn, you are not building an intelligent assistant. You are building a librarian who drags the entire archive to every reference desk question. Store everything. Load what matters. That is how you keep agents fast, context clean, and reasoning sharp.