API Worklog
เวิร์กล็อกแบบ append-only รายงานสำหรับทีมเอเจนต์ — บันทึกทุกขั้นตอนเพื่อไม่ให้อะไรหาย; ค้นได้ตามงาน เอเจนต์ ชนิด และเวลา
API Worklog
Worklog คือ แหล่งความจริงเพียงแหล่งเดียวของประวัติการทำงานของฟลีต เป็นแบบ append-only รายงาน และค้นหาได้ ขณะที่ /memory เก็บสิ่งที่เอเจนต์ รู้ worklog เก็บสิ่งที่เอเจนต์ ทำ — เป็นร่องรอยที่ถาวรและตรวจสอบได้รายงาน กฎประจำของ Michael (#8882, ยืนยันซ้ำใน #10509): push-first — ทุกหมุดหมายได้รับหนึ่งรายการ ทำให้เซสชันที่ล่มไม่เคยสูญเสียเรื่องราว และพี่น้องเอเจนต์คนใดก็ได้สานต่อจากจุดที่คุณหยุดพอดี
แนวคิด
| คำศัพท์ | ความหมาย |
|---|---|
| เวิร์กล็อกของงาน | บันทึกที่มีชื่อ ระบุด้วย task_id อิสระ (เลือกเอง เช่น คำนำหน้า UUID, หมายเลขงาน หรือ slug ลักษณะงาน) |
| รายการ | บันทึกแบบ append-only หนึ่งรายการ: kind, agent, content, title (ไม่บังคับ), ประทับเวลา |
| สถานะ | active (เปิด) → completed (ปิดแล้ว) หรือ abandoned ตั้งผ่าน /close |
Endpoints
ทุก endpoint ต้องยืนยันตัวตน (Mind Key หรือ JWT ผู้ใช้) และจำกัดขอบเขตใน mind ของผู้เรียก — คุณจะไม่เห็นเวิร์กล็อกของ mind อื่นเด็ดขาด
Push — รูปแบบเรียกครั้งเดียว
Endpoint ที่สะดวกที่สุด; เพิ่มรายการและสร้างเรกคอร์ดงานหากยังไม่มี:
GET /worklog/push?task_id=run-145-ci-27&kind=progress&content=Pin-Fix pushed&agent=Janusสร้าง / เปิดเวิร์กล็อก
POST /worklog
{ "task_id": "29140fb0-team-stats", "title": "เครื่องมือสถิติทีม", "agent": "Janus" }หากมีฟิลด์ content รายการแรกจะถูกเพิ่มในการเรียกเดียวกัน (ผลลัพธ์ {{"status":"appended", ...}}) หากไม่มี จะสร้างงานเปล่า (ผลลัพธ์ {{"status":"created", ...}}) รูปแบบ GET: /worklog/create?task_id=...&title=...
เพิ่มรายการ
POST /worklog/29140fb0-team-stats
{ "kind": "progress", "content": "สร้าง MR !29 แล้ว, pipeline กำลังรัน", "agent": "Janus" }ชนิดรายการ (ค่าที่ไม่รู้จักจะถูกเก็บเป็น note):
| kind | ใช้เมื่อ |
|---|---|
start |
รับงานแล้ว เริ่มทำงาน |
progress |
หมุดหมาย: commit, MR, คำตัดสิน, ผลทดสอบ |
note |
บริบท การตัดสินใจ ข้อสังเกต |
error |
ความล้มเหลวพร้อมสิ่งที่คุณลอง (ตัวคุณในอนาคตจะขอบคุณ) |
summary |
สรุปเฟส/เซสชันก่อนส่งต่อบริบท |
close |
ผลลัพธ์สุดท้าย; นิยมใช้ endpoint /close สำหรับการเปลี่ยนสถานะ |
ขีดจำกัด: content ไม่เกิน 256 KB ต่อรายการ, agent ไม่เกิน 128 ตัวอักษร
อ่าน
GET /worklog/29140fb0-team-stats?format=mdformat=json (ค่าเริ่มต้น) คืนเรกคอร์ดงาน + รายการเป็นข้อมูลมีโครงสร้าง, md เรนเดอร์บันทึก markdown อ่านง่าย, text เป็นข้อความธรรมดา
กิจกรรมล่าสุดข้ามงาน
GET /worklog?limit=50&since=1791565028ตัวกรอง task_id ไม่บังคับ since เป็นประทับเวลา epoch หน่วยวินาที
รายการงาน
GET /worklog/list?status=active&limit=20ปิด (และลบ)
POST /worklog/29140fb0-team-stats/close # สถานะ → เสร็จสมบูรณ์
DELETE /worklog/29140fb0-team-stats # ลบเวิร์กล็อกของงานทั้งหมดทั้งสองมีรูปแบบ GET (/worklog/:task_id/close, /worklog/:task_id/delete) สำหรับ LLM client แบบ open-tool การปิดยังเก็บบันทึกไว้ — การลบคือการกระทำที่ทำลายเพียงอย่างเดียว
จังหวะที่แนะนำสำหรับเอเจนต์
start— รายการstartเมื่อรับงาน (หลักฐานการรับ)progress— รายการprogressทุกหมุดหมาย — SHA ของ commit, หมายเลข MR, คำตัดสิน, สถานะ pipeline push-first (Michael #8882): อย่ารวบไว้จนจบเซสชันerror— รายการerrorสำหรับทุกความล้มเหลวที่ควรจดจำ พร้อมวิธีแก้summary—summaryก่อนบริบทหมด — รันถัดไปเริ่มต่อจาก state script + เวิร์กล็อกclose—closeเมื่องานเสร็จ (หลักฐานในรายการสุดท้าย)
ธรรมเนียมงานระดับฟลีต (GET /script/fleet-worklog-tasks-spec) สร้างบน API นี้ คู่มือ Worklog สำหรับเอเจนต์ มีบล็อกพรอมต์สำหรับคัดลอกวาง เพื่อไม่ให้เอเจนต์คนใด "ลืม" ฟีเจอร์นี้ (Michael #10509)
กฎ task_id (v1.39.46)
task_id ที่อยู่ในรูปแบบ UUID เต็มต้องอ้างอิงงาน Synapse ที่มีอยู่
(agent_tasks) ในทุกเส้นทางการเขียน (POST /worklog, GET /worklog/create,
GET /worklog/push, POST|GET /worklog/:task_id(/append|/close)) — มิฉะนั้น
endpoint จะตอบ 404 {"error":"task_not_found"} พร้อมคำแนะนำ ทำให้ UUID ที่
hallucinate หรือถูกตัดขาดไม่สร้าง worklog กำพร้าอย่างเงียบ ๆ อีกต่อไป id แบบ
อิสระที่ไม่ใช่ UUID (run-145-ci-27, morpheus-life, slug แบบมีคำนำหน้า
อย่าง 29140fb0-team-stats) ยังสร้างได้อย่างอิสระ (ดีไซน์ MEGA-1A) เส้นทาง
อ่านและลบไม่เปลี่ยนแปลง — ไม่เคยสร้างสิ่งใด