ทรัพยากรและความสามารถ
ขอบเขตเวอร์ชัน: หน้านี้เรียบเรียงเอกสารเชิงบรรทัดฐานสี่ฉบับของมาตรฐานปัจจุบัน DWP 7.0.0 ในรุ่น
v7.9.0:V6_CONTEXT.md,V6_RESOURCES.md,CONFIG.mdและV7_ABILITIES.mdหากหน้านี้กับไฟล์เหล่านั้นแตกต่างกัน ให้ยึดไฟล์เป็นหลัก
สถานะ: เสถียร (บริบทและทรัพยากรตั้งแต่ 6.0.0 การกำหนดค่าและความสามารถตั้งแต่ 7.0.0) กฎเหล่านี้ผูกพันแผนสาย v6 (ชั้นบันทึก) มาตรฐาน v5 ไม่ได้รับผลกระทบ คำสำคัญ MUST, MUST NOT, SHOULD, SHOULD NOT และ MAY ให้ตีความตามที่อธิบายไว้ใน RFC 2119
Context manifest ต่อหนึ่งงาน
ก่อนแต่ละงาน เอเจนต์อนุมาน context manifest จากสัญญาและ journal ทั้งหมด (context_manifest.py) มันเป็น view ที่ได้รับมา ไม่เคยถูกเก็บเป็นสถานะ: การอนุมานสองครั้งจากบันทึกชุดเดียวกัน MUST ให้ไบต์ที่เหมือนกัน และ manifest MUST NOT อ่านนอกแผนและ repository ของมัน รูปแบบของมันเผยแพร่เป็น context-manifest/v6
| ส่วน | อนุมานจาก |
|---|---|
identity |
ชื่อแผน contract id ที่ใช้งานอยู่ และ revision |
authorization |
เหตุการณ์การอนุมัติแบบคำต่อคำ รวมถึงจุดตรวจความยินยอม |
repository_rules |
ขอบเขตของสัญญาและ invariant พร้อมสถานะการประเมินปัจจุบัน |
acceptance |
เกณฑ์ของงานพร้อมสถานะการปิด |
touched_surface |
ไฟล์ที่ประกาศไว้พร้อม hash ของเนื้อหาปัจจุบัน ไฟล์ที่หายไปแสดงเป็นหายไป |
evidence |
ตัวชี้หลักฐานภายในช่วงที่แปลงค่าได้บนดิสก์ |
dead_ends |
gate ที่ล้มเหลว การปฏิเสธ การปรับเปลี่ยนที่ถูกปฏิเสธ และการควบคุมที่ไม่จำแนก |
freshness |
fingerprint ของอินพุตที่ manifest สรุปไว้ |
next_action |
ขั้นตอนถัดไปเพียงหนึ่งขั้นพร้อมคำสั่งที่เป็นรูปธรรม |
authorization, repository_rules และ acceptance เป็น ส่วนบังคับ: การตัดทอนบริบทไม่สามารถซ่อนขอบเขตของการยอมรับหรือการอนุญาตได้เลย ลำดับขั้นของการกระทำถัดไปเรียงตายตัว (approval, start, authority, control, evidence, complete) และไม่เคยแสดง gate ที่ผ่านตามปกติว่าเป็นการปิดเกณฑ์แบบมีการควบคุม
ทางตันถูกเก็บไว้ รายการหนึ่งจะออกจาก digest ได้เฉพาะเมื่อมีข้อเท็จจริงที่พิสูจน์ได้ในบันทึก (fingerprint เดียวกันผ่านในภายหลัง การปฏิเสธซ้ำที่ใหม่กว่ามาแทนที่ หรือ revision ของสัญญาทำให้มันหมดอายุ) การที่พื้นผิวเปลี่ยนเพียงอย่างเดียว MUST NOT ทำให้มันหลุดไป ความสดใหม่ถูกตรวจสอบ: สรุปที่ fingerprint อินพุตที่บันทึกไว้ไม่ตรงกันอีกต่อไปถือว่าล้าสมัย และสรุปที่ไม่มี fingerprint ถือว่าล้าสมัยโดยโครงสร้าง ประวัติถูกโหลดเมื่อมีตัวกระตุ้นเท่านั้น — handoff ที่ถูกบันทึกหรือการแก้ไขสัญญาที่กระทบงานนั้น มิฉะนั้น manifest เพียงอย่างเดียวคือบริบทของงาน
การบัญชีสี่ปริมาณ
ภาระคำสั่งและต้นทุนถูกรายงานเป็นสี่ปริมาณที่แยกจากกัน: instruction bytes แบบคงที่ provider tokens (เฉพาะเมื่อมิเตอร์ของโฮสต์บันทึกไว้) ต้นทุนเป็นเงิน (เฉพาะจากตัวอย่างอัตราจริงที่บันทึกไว้) และ เวลาจริง (จาก timestamp ของเหตุการณ์) ปริมาณที่ขาดหายถูกรายงานว่าขาดหายพร้อมเหตุผล ไม่เคยถูกประมาณแทน และไบต์ไม่เคยถูกแปลงเป็นโทเค็นหรือเงิน
ความสามารถของโฮสต์
โฮสต์ runtime ประกาศ ความสามารถ ของตนจากเซตปิด: stop_agent, meter_spend, meter_tokens, meter_wall_clock, cancel_children, model_routing, subagents, telemetry ความสามารถที่ไม่รู้จัก MUST ถูกปฏิเสธ และความสามารถที่ไม่ได้ประกาศถือเป็น false โฮสต์ขั้นต่ำ — ไม่สลับโมเดล ไม่มี subagent ไม่มี telemetry ไม่มีการหยุด — เป็นท่าทีที่รองรับ ไม่ใช่ข้อผิดพลาด ทุกขีดจำกัดที่ต้องใช้ความสามารถที่ขาดหายจะลดระดับเป็นเชิงแนะนำ พร้อมระบุชื่อความสามารถที่ขาดหาย
ความสามารถไม่ใช่สิทธิ์ สิทธิ์ในสัญญาคืออำนาจ ความสามารถคือสิ่งที่สภาพแวดล้อมทำได้จริง ทุกท่าทีที่ต้องใช้ความสามารถยังคงต้องมีสิทธิ์ของมันด้วย
ขอบเขตทรัพยากร
สัญญา MAY ประกาศขีดจำกัดไว้ในขอบเขตทรัพยากร ขีดจำกัดจะ ถูกบังคับใช้ เฉพาะเมื่อระบุแหล่งวัดจริง มิฉะนั้นจะเป็น เชิงแนะนำ และไม่เคยอ้างว่าการบังคับใช้เท่าเทียมกันในทุกโฮสต์
- แหล่งของตัวนับ ตัวนับที่สังเกตได้จาก journal (ช่วงเวลาจริง การลอง gate ซ้ำ การเรียกส่งงาน) คำนวณจากบันทึกของแผนเอง ตัวนับเฉพาะโฮสต์ (การใช้จ่าย provider tokens) ต้องมีความสามารถมิเตอร์ที่ตรงกันและตัวอย่าง observed จาก host adapter ตัวนับที่ขาดหายไม่ได้หมายความว่าใช้ฟรี
- ทุนสำรอง ขีดจำกัด MAY ประกาศ
reserveเพื่อไม่ให้งานปกติแย่งทรัพยากรจนการตรวจสอบ การลองซ้ำ และการดำเนินต่อขาดแคลน: การส่งงานถูกปฏิเสธเมื่อยอดใช้แล้วรวมยอดที่รอดำเนินการจะเกินขีดจำกัดลบทุนสำรอง - การใช้จนหมด การถึงขีดจำกัดจะบันทึก checkpoint ที่ยังไม่สมบูรณ์ไว้ บันทึก
LIMIT: exhausted <id>: <detail>และระงับการส่งงานจนกว่าจะมีบันทึกLIMIT: recovered <id>ที่ระบุชัด การใช้จนหมดไม่สามารถทำให้เกณฑ์การยอมรับผ่านได้เลย - การชำระเมื่อยกเลิก การจองที่กำลังดำเนินอยู่ถูกชำระเพียงครั้งเดียวพอดี เป็นแบบปล่อยคืนหรือแบบยืนยัน การชำระครั้งที่สองที่ขัดแย้งถูกปฏิเสธ ไม่เคยถูกตัดสินชี้ขาด
- ท่าทีการกำหนดเส้นทาง ค่าเริ่มต้นคือโมเดลตายตัว การสลับระดับโมเดลต้องมีทั้งสิทธิ์
model_routingและความสามารถชื่อเดียวกัน การส่งงานแบบขนานต้องมีทั้งสิทธิ์agent_delegationและความสามารถsubagentsท่าทีการกำหนดเส้นทางคือข้อความเรื่องสิทธิ์ ไม่ใช่การอ้างประสิทธิผล
ไฟล์กำหนดค่าและทะเบียน addon
.dwp/config.json (repository) และ ~/.dwp/config.json (ผู้ใช้) ใช้รูปแบบเดียวกัน ซึ่งเผยแพร่เป็น dwp-config/v1 และใช้ parser ตัวเดียวกัน (config.py) ระเบียบวิธีทำงานได้โดยไม่มีไฟล์กำหนดค่าและไม่มี addon ไม่มีสิ่งใดในไฟล์ที่ทำให้แผน flow หรือความสอดคล้องต้องพึ่งพา addon ได้
- ติดตามใน git โดยค่าเริ่มต้น ไฟล์ของ repository เก็บการตัดสินใจ ไม่เคยเก็บ secret และถูกติดตามใน git เพื่อให้เพื่อนร่วมทีมและ CI อ่านทะเบียนเดียวกัน: onboarding เขียนกฎ
.gitignoreคือ.dwp/*บวก!.dwp/config.jsonแผนและบันทึก benchmark ยังคงถูก ignore - ลำดับความสำคัญ ไฟล์ของ repository ชนะไฟล์ของผู้ใช้ และไฟล์ที่ไม่มีอยู่หมายถึงปิดใช้ทุกอย่าง คีย์
addonsแปลงค่าทีละคีย์ addon ส่วนคีย์benchmarkแปลงค่าทั้งก้อน - คีย์ทะเบียน คือชื่อไดเรกทอรี addon ภายในแพ็ก:
ai-diff-reviewer,agentkit,dailybot,dependency-upgrade,design-system,devcontainer,herdr,vimแต่ละรายการมีenabled(เฉพาะtrueเท่านั้นที่เปิดใช้)versionแบบเลือกได้ และnoteหนึ่งบรรทัดแบบเลือกได้ คีย์ที่ไม่รู้จักถูกละเว้นพร้อมคำเตือนหนึ่งครั้ง - ไม่มีหมายถึงไม่ได้เปิดใช้ มีเพียง onboarding ที่ได้รับความยินยอมจากนักพัฒนา ขั้นตอนติดตั้งของ addon เอง หรือมนุษย์เท่านั้นที่เปิดใช้สิ่งใดได้ addon ที่เปิดใช้แต่ตรวจไม่พบและมี note จะถูกรายงานว่าเลื่อนออกไป
- การอ่านแบบปิดเมื่อล้มเหลว ไฟล์ที่อ่านไม่ได้หรือค่าที่ผิดรูปแบบไม่มีผลใด ๆ และสร้างคำเตือนเพียงหนึ่งครั้งพอดี ตัวอ่านไม่เคยยกเลิก flow และไม่เคยเงียบเกี่ยวกับสิ่งที่ตนทิ้งไป ตัวเขียนกระทบยอดแบบ atomic และปฏิเสธที่จะเขียนทับไฟล์ที่ตน parse ไม่ได้
- บันทึกโฮสต์ คีย์
hostแบบเลือกได้บันทึกความสามารถที่เครื่องประกาศไว้ (ค่า boolean จากเซตปิด)telemetry: trueยังคงต้องได้รับความยินยอมจากนักพัฒนา - พื้นฐานไม่เปลี่ยนแปลง การรีวิวในเครื่องของ AI Diff Reviewer ยังคงเป็นส่วนหนึ่งของทุก Final Review ไม่ว่าทะเบียนจะระบุชื่อมันหรือไม่
ความสามารถที่ addon มอบให้
ตั้งแต่ 7.0.0 addon ที่เปิดใช้สามารถเพิ่มความสามารถขณะ runtime ได้
effective abilities = host-declared abilities ∪ abilities provided by every addon that is enabled, described by a valid addon.json, detected, and on a compatible interface version
- Descriptor addon แต่ละตัวภายในแพ็กจัดส่ง
addon.json(addon-descriptor/v1) ที่ประกาศคีย์ของมัน สิ่งที่มันมอบให้ และวิธีตรวจจับมัน - การตรวจจับเป็นแบบอ่านอย่างเดียว คำสั่ง detect รันโดยไม่มี shell ปิด stdin และมี timeout 10 วินาที และไม่มีสิ่งใดที่มันพิมพ์ออกมาถูกนำไปรัน ผลิตภัณฑ์ที่รายงาน interface major ต่างจากที่ปักหมุดไว้ถือว่าใช้งานไม่ได้ พร้อมคำเตือนหนึ่งครั้ง
- ไม่เปิดใช้หมายถึงไม่ถูกปรึกษา descriptor ของ addon ที่ปิดใช้ไม่ถูกเปิดอ่าน และคำสั่ง detect ของมันไม่ถูกรัน การรวมเป็นแบบทางเดียว: การเปิดใช้ addon ทำได้เพียงเพิ่มความสามารถ
- ไม่เคยถูกบันทึกถาวร ความสามารถที่มีผลถูกคำนวณใหม่ทุกครั้งที่เรียกใช้ และ MUST NOT ถูกเขียนลงในแผน แผนบันทึกสิ่งที่มันใช้ — เหตุการณ์การมอบหมายงานระบุ transport และ addon ของมัน — ไม่ใช่สิ่งที่มีให้ใช้
- ความสามารถไม่ใช่อำนาจ addon agentkit สามารถมอบ
subagents,cancel_childrenและmodel_routingได้ addon Herdr สามารถมอบsubagentsและcancel_childrenได้ การมอบหมายงานยังคงต้องมีสิทธิ์agent_delegationของสัญญา (การมอบหมายงาน)
resources.py abilities พิมพ์เซตที่มีผลและแหล่งที่มาของแต่ละความสามารถ โดยเป็นแบบอ่านอย่างเดียว
ที่เกี่ยวข้อง
- ชั้นบันทึก — สัญญา journal และหลักฐาน
- การมอบหมายงาน — วิธีที่แผนใช้ความสามารถ
subagents - Add-on — ตัว addon แบบเลือกใช้เอง