Bagaimana Agen yang Berjalan Lama Melampaui Jendela Konteks: 3 Pertanyaan Desain untuk Pola Ringkasan Serah Terima + Penelusuran Arsip

Catatan penulis: Artikel ini menggunakan mekanisme perpindahan konteks openJiuwen WorkSwarm sebagai contoh untuk membahas pola “ringkasan serah terima + penelusuran arsip”, serta pilihan desain dan trade-off bagi agen yang berjalan dalam waktu lama saat mendekati batas jendela konteks.

Komunitas agen sumber terbuka openJiuwen yang didukung Huawei baru-baru ini merilis arsitektur klaster Hyper-Agent. Ada satu detail yang patut diperhatikan developer: ketika jendela konteks agen mendekati batas, agen akan beralih ke jendela baru dengan membawa ringkasan serah terima berisi tujuan, progres, dan langkah berikutnya, lalu menelusuri riwayat arsip saat membutuhkan detail. Mekanisme ini bisa dijelaskan dalam satu kalimat, tetapi di baliknya ada persoalan rekayasa yang harus dihadapi semua agen yang berjalan dalam jangka panjang.

Ini bukan sekadar rumor. Kemampuan tersebut sudah dirilis bersama openJiuwen WorkSwarm, dan kodenya tersedia secara sumber terbuka di GitHub dengan nama JiuwenSwarm. Dengan mekanisme ini sebagai contoh, artikel ini membahas tiga persoalan desain: apa yang perlu dimuat dalam ringkasan serah terima, kapan perpindahan harus dipicu, dan kapan arsip perlu diperiksa kembali. Kita juga akan membandingkan trade-off antara dua pendekatan: “mengandalkan konteks yang lebih panjang” dan “ringkasan serah terima + penelusuran”.

Manfaat utama: Setelah membaca artikel ini, Anda dapat meninjau pilihan untuk menangani batas jendela konteks dalam aplikasi agen Anda, beserta risiko masing-masing.

Ringkasan serah terima + penelusuran arsip: informasi inti sekilas

Mari kita rapikan dulu fakta yang bisa dipastikan dari sumber yang tersedia, lalu lihat artinya bagi developer. Informasi dalam tabel berikut berasal dari laporan publik. Detail implementasi yang belum dikonfirmasi dalam laporan akan ditandai secara terpisah di bagian selanjutnya.

Mengapa agen persisten harus mengatasi batas jendela konteks

WorkSwarm dirancang agar agen tidak terikat pada satu sesi obrolan, melainkan bisa terus hadir sebagai “karyawan digital” di grup kerja seperti Feishu dan DingTalk. Agen yang sama dapat menangani beberapa tugas di berbagai grup obrolan pihak ketiga, menerima permintaan di satu kanal, lalu mengirimkan hasilnya di kanal lain. Sistem menggunakan gateway untuk menghubungkan aplikasi pesan instan dan antarmuka Web, sementara AgentServer mengelola agen dan sesi kerja.

Dalam bentuk seperti ini, batas jendela konteks bukan lagi masalah yang sesekali muncul, melainkan sesuatu yang pasti terjadi. Chatbot yang hanya menjawab satu pertanyaan dalam satu giliran jarang memenuhi jendela konteks. Namun, bagi agen yang mengikuti proyek selama berhari-hari, riwayat percakapan, hasil pemanggilan alat, dan isi file akan terus menumpuk. Laporan juga menyebutkan bahwa panel aktivitas WorkSwarm menampilkan penggunaan token setiap agen. Artinya, konsumsi konteks merupakan metrik operasional yang perlu terus dipantau dalam sistem seperti ini.

Sesi sebagai sumber daya: dasar dari ringkasan serah terima

Kunci untuk memahami mekanisme ringkasan serah terima adalah pemisahan antara “agen” dan “sesi” di WorkSwarm. Identitas dan status agen tetap ada, sedangkan sesi hanyalah sumber daya yang dialokasikan dan dikelola sistem secara bersamaan, serta dapat dipulihkan beserta konteksnya. Karena sesi bisa diganti, “beralih ke jendela baru saat jendela penuh” menjadi pilihan desain yang masuk akal.

Ringkasan serah terima berfungsi membawa informasi status kerja yang ringkas tetapi cukup dari sesi lama ke sesi baru. Sementara itu, riwayat arsip memastikan detail dari sesi lama tidak benar-benar hilang, melainkan berubah dari “selalu tersedia dalam konteks” menjadi “diambil saat diperlukan”.

Masalah desain ringkasan serah terima pertama: apa saja yang perlu disertakan?

Tiga unsur yang disebutkan dalam laporan adalah tujuan, progres, dan langkah selanjutnya. Strukturnya ringkas, tetapi setiap unsur perlu dirinci lebih lanjut saat diterapkan. Tabel berikut mengembangkan ketiga unsur tersebut sebagai referensi desain. Ini adalah saran teknis, bukan implementasi JiuwenSwarm yang sudah dikonfirmasi.

“Batasan” dan “indeks” adalah dua unsur tambahan dari kami. Batasan penting karena preferensi yang disampaikan pengguna secara tersebar dalam percakapan panjang—misalnya, “laporan jangan lebih dari satu halaman”—paling mudah hilang saat ringkasan dipadatkan. Sementara itu, indeks menjembatani ringkasan serah terima dan pencarian arsip: semakin singkat ringkasannya, semakin penting memberi tahu jendela baru “di mana detailnya berada”.

Dalam skenario WorkSwarm, perlu juga diperhatikan kompleksitas yang muncul dari banyaknya grup dan kanal. Laporan menyebutkan bahwa berbagi lintas grup memerlukan persetujuan pengguna. Izin dapat diberikan untuk satu kali atau secara permanen, dan dapat dicabut. Jika status izin seperti ini tidak dicantumkan dalam ringkasan serah terima, agen di jendela baru bisa salah menilai status tersebut. Informasi semacam ini lebih cocok disimpan sebagai bidang terstruktur daripada teks bebas.

Masalah desain ringkasan serah terima kedua: kapan memicu pergantian konteks

Laporan tersebut hanya menyebutkan bahwa pergantian dilakukan “saat mendekati batas”. Informasi publik saat ini belum menjelaskan ambang batas pastinya maupun apakah ringkasan dibuat oleh model atau berdasarkan aturan. Untuk memastikannya, perlu memeriksa kode sumber atau dokumentasi JiuwenSwarm. Dari sudut pandang rekayasa, ada beberapa pilihan waktu pemicu yang umum digunakan.

Perlu diperhatikan bahwa pembuatan ringkasan serah terima juga menggunakan ruang konteks. Jika pemicunya baru aktif saat jendela benar-benar penuh, model mungkin sudah tidak punya cukup ruang untuk membaca seluruh riwayat dan menulis ringkasan berkualitas. Karena itu, apa pun strateginya, selalu sisakan ruang untuk membuat ringkasan.

Untuk cara pembuatannya, ringkasan yang dihasilkan model lebih fleksibel dan mampu memahami makna tugas. Sementara itu, ringkasan berbasis aturan—misalnya dengan langsung mengambil bidang status dari daftar tugas—lebih stabil, tetapi sulit menangkap keputusan tersirat dalam percakapan. Dalam praktiknya, keduanya sering digabungkan: program mengelola status terstruktur, sedangkan model melengkapi penjelasan perkembangan dalam bahasa alami.

Cara membuat ringkasan serah terima + pencarian arsip: prototipe minimalis

Berikut prototipe minimalis untuk mendemonstrasikan pola ini, bukan implementasi JiuwenSwarm. Saat perkiraan penggunaan token mendekati ambang batas, model membuat ringkasan serah terima dan menyimpan pesan lama ke arsip.

import openai

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"  # Antarmuka APIYI yang kompatibel dengan OpenAI
)

HANDOFF_PROMPT = "请将以上工作记录整理为交接摘要，包含：目标、进展、下一步、约束、关键信息索引。"

def make_handoff(messages, model="gpt-4o-mini"):
    resp = client.chat.completions.create(
        model=model,
        messages=messages + [{"role": "user", "content": HANDOFF_PROMPT}]
    )
    return resp.choices[0].message.content

import openai
from typing import List, Dict

client = openai.OpenAI(
    api_key="YOUR_API_KEY",
    base_url="https://api.apiyi.com/v1"
)

MODEL = "gpt-4o-mini"
CONTEXT_LIMIT = 100_000      # Nilai contoh, sesuaikan dengan jendela konteks model yang digunakan
SWITCH_RATIO = 0.7           # Sisakan ruang untuk pembuatan ringkasan
HANDOFF_PROMPT = (
    "请将以上工作记录整理为交接摘要，分为五部分："
    "1.目标 2.进展（含关键决策及理由）3.下一步 4.用户约束 5.关键信息索引（关键词列表）"
)

class LongRunningAgent:
    def __init__(self, system_prompt: str):
        self.system_prompt = system_prompt
        self.messages: List[Dict] = [{"role": "system", "content": system_prompt}]
        self.archive: List[Dict] = []   # Riwayat arsip; di lingkungan produksi bisa diganti dengan database atau database vektor

    def estimate_tokens(self) -> int:
        # Perkiraan kasar; di lingkungan produksi gunakan tokenizer model yang sesuai
        return sum(len(m["content"]) for m in self.messages)

    def maybe_switch(self):
        if self.estimate_tokens() < CONTEXT_LIMIT * SWITCH_RATIO:
            return
        resp = client.chat.completions.create(
            model=MODEL,
            messages=self.messages + [{"role": "user", "content": HANDOFF_PROMPT}]
        )
        summary = resp.choices[0].message.content
        self.archive.extend(self.messages[1:])      # Simpan percakapan lama ke arsip
        self.messages = [
            {"role": "system", "content": self.system_prompt},
            {"role": "system", "content": f"【交接摘要】\n{summary}"}
        ]

    def search_archive(self, keyword: str, top_k: int = 5) -> str:
        hits = [m["content"] for m in self.archive if keyword in m["content"]]
        return "\n---\n".join(hits[-top_k:]) or "归档中未找到相关记录"

    def chat(self, user_input: str) -> str:
        self.maybe_switch()
        self.messages.append({"role": "user", "content": user_input})
        resp = client.chat.completions.create(model=MODEL, messages=self.messages)
        answer = resp.choices[0].message.content
        self.messages.append({"role": "assistant", "content": answer})
        return answer

agent = LongRunningAgent("你是负责跟进项目周报的数字员工。")
print(agent.chat("请记录：本周报告不要超过一页。"))

Pencarian arsip dalam prototipe ini hanya menggunakan pencocokan kata kunci sederhana. Laporan tersebut tidak menjelaskan apakah JiuwenSwarm menggunakan pencarian vektor atau metode lain. Dalam proyek nyata, kamu bisa memilih pencarian teks lengkap, pencarian vektor, atau gabungan keduanya sesuai ukuran arsip. Kamu juga bisa mendaftarkan search_archive sebagai alat agar model menentukan sendiri kapan harus memanggilnya.

🚀 Mulai cepat: Saat membangun prototipe seperti ini, kamu bisa menggunakan model berbeda untuk membuat ringkasan dan menangani tugas utama. Misalnya, gunakan model ringan untuk ringkasan dan model yang lebih kuat untuk tugas utama. Melalui APIYI apiyi.com, satu kunci API bisa digunakan untuk memanggil model OpenAI, Claude, Gemini, dan lainnya, sehingga mudah beralih dan membandingkannya dalam kode yang sama. Pengguna baru mendapat kuota uji coba gratis.

Masalah desain ringkasan serah terima ketiga: kapan memeriksa kembali riwayat arsip

Penelusuran arsip menjawab masalah mendasar bahwa “ringkasan pasti kehilangan sebagian informasi”. Setiap pemadatan menghilangkan informasi; yang penting adalah apakah informasi itu bisa ditemukan kembali. Ada tiga pendekatan utama untuk menentukan kapan arsip perlu diperiksa kembali:

• Pemanggilan mandiri oleh model: Penelusuran disediakan sebagai alat yang bisa digunakan model saat merasa informasinya kurang. Pendekatan ini fleksibel, tetapi bergantung pada kemampuan model untuk mengenali apa yang tidak diketahuinya.
• Pemicu berbasis aturan: Ketika pengguna menyebut entitas, nama file, atau waktu yang tidak ada dalam ringkasan, program otomatis melakukan penelusuran dan menyisipkan hasilnya. Pendekatan ini mudah dikendalikan, tetapi cakupan aturannya terbatas.
• Panduan indeks: Ringkasan serah terima menyimpan indeks informasi penting, sehingga jendela baru dapat mengambil informasi yang tepat saat topik terkait muncul. Pendekatan ini bergantung pada kualitas indeks yang dibuat saat peringkasan.

Menurut kami, risiko terbesarnya adalah “tidak mengetahui apa yang terlewat”. Jika ringkasan melewatkan preferensi pengguna dan tidak ada petunjuk tentang preferensi tersebut di jendela baru, model tidak akan terpikir untuk menelusurinya. Inilah alasan kami menyarankan penambahan kolom “batasan” dan “indeks” dalam ringkasan: keduanya menjadi titik awal untuk memeriksa kembali arsip.

Mengandalkan konteks yang lebih panjang vs ringkasan serah terima: analisis dampak

Saat mencapai batas jendela konteks, alternatif lain adalah beralih ke model dengan konteks yang lebih panjang. Kedua pendekatan ini bisa digunakan bersama, tetapi cocok untuk kondisi yang berbeda. Tabel berikut merupakan analisis pertimbangan tanpa disertai data performa.

💡 Saran memilih: Jika tugas biasanya bisa diselesaikan dalam satu jendela panjang, beralih ke model dengan konteks panjang lebih praktis. Jika agen perlu bekerja dalam jangka panjang seperti karyawan digital WorkSwarm, ringkasan serah terima hampir menjadi keharusan. Coba jalankan tugas yang sama menggunakan model dengan berbagai ukuran konteks di APIYI apiyi.com, lalu amati penggunaan aktual sebelum memutuskan apakah perlu mengembangkan mekanisme ringkasan.

Dampak bagi pengembang

• Manajemen konteks menjadi persoalan arsitektur: WorkSwarm memperlakukan sesi sebagai sumber daya yang dapat dijadwalkan. Artinya, pergantian konteks menjadi bagian dari desain sistem, bukan sekadar solusi setelah terjadi kesalahan.
• Status perlu dimodelkan secara eksplisit: Kualitas ringkasan serah terima bergantung pada kejelasan catatan agen tentang tujuan, keputusan, dan tugas yang belum selesai. Karena itu, pengembang perlu merencanakan struktur status sejak tahap desain.
• Observabilitas menjadi lebih penting: WorkSwarm menampilkan penggunaan token dan waktu respons di panel aktivitas. Agen yang bekerja dalam jangka panjang juga perlu memantau frekuensi pergantian konteks dan keberhasilan penelusuran.

Dampak bagi industri

• Dari berbasis sesi menjadi selalu aktif: Agen berkembang dari pola “tanya jawab” menjadi “kelompok kerja yang aktif dalam jangka panjang”. Kemampuan mempertahankan konteks lintas jendela akan menjadi infrastruktur dasar bagi produk semacam ini.
• Implementasi sumber terbuka menjadi referensi: Setelah JiuwenSwarm dirilis sebagai sumber terbuka, pengembang dapat langsung mempelajari ambang pergantian, pembuatan ringkasan, dan implementasi penelusurannya tanpa harus mencari solusi dari nol.

Pertanyaan Umum FAQ

Poin Penting Ringkasan Serah Terima dan Jendela Konteks

• Mekanisme utama: Saat jendela hampir penuh, beralih ke jendela baru dengan membawa ringkasan serah terima yang berisi tujuan, progres, dan langkah berikutnya.
• Prasyarat: Identitas agen dipisahkan dari sesi, sehingga sesi menjadi sumber daya yang dapat dijadwalkan dan dipulihkan.
• Desain ringkasan: Tambahkan batasan pengguna dan indeks arsip di luar tiga elemen utama untuk mengurangi risiko informasi terlewat.
• Waktu pemicu: Sisakan ruang untuk membuat ringkasan dan utamakan peralihan pada batas antar-tugas.
• Penelusuran arsip: Ringkasan pasti kehilangan sebagian informasi; akses pencarian menentukan apakah informasi tersebut bisa ditemukan kembali.
• Pilihan pendekatan: Untuk tugas berukuran sedang, model dengan konteks panjang bisa menjadi pilihan. Untuk tugas yang berjalan dalam jangka panjang, ringkasan serah terima lebih dibutuhkan.
• Validasi cepat: Buat prototipe untuk perbandingan melalui antarmuka terpadu multimodel APIYI apiyi.com.

Kesimpulan

Mekanisme peralihan konteks openJiuwen WorkSwarm menawarkan pola yang jelas untuk agen yang berjalan dalam waktu lama:

1. Ringkasan serah terima menyimpan status pekerjaan: Tujuan, progres, dan langkah berikutnya adalah informasi minimal; batasan dan indeks menjadi tambahan yang berguna.
2. Waktu peralihan perlu menyisakan ruang: Pembuatan ringkasan juga menggunakan konteks, jadi jangan menunggu hingga jendela benar-benar penuh.
3. Pencarian arsip mengatasi kehilangan informasi: Ringkasan cukup “mengingat poin penting”, sedangkan detail dapat dicari saat dibutuhkan.

Jika agen Anda mulai beralih dari sesi sekali jalan ke operasi jangka panjang, petakan dulu struktur statusnya. Setelah itu, tentukan apakah perlu menggunakan model dengan konteks panjang atau menerapkan ringkasan serah terima. Coba buat prototipe melalui APIYI apiyi.com untuk membandingkan kualitas ringkasan dan penggunaan konteks di berbagai model.

📚 Referensi

1. Laporan Pandaily: Arsitektur klaster openJiuwen Hyper-Agent dan karyawan digital WorkSwarm
2. Tautan: pandaily.com/openjiuwen-hyper-agent-swarm-architecture-persistent-agents-workswarm-digital-employees

3. Keterangan: Laporan berbahasa Inggris yang membahas agen persisten, peralihan konteks, dan mekanisme ringkasan serah terima

4. Kode sumber terbuka JiuwenSwarm: Implementasi sumber terbuka openJiuwen WorkSwarm

5. Tautan: github.com (cari JiuwenSwarm)
6. Keterangan: Lihat implementasi ambang batas peralihan, pembuatan ringkasan, dan pencarian arsip

Penulis: Tim teknis APIYI
Diskusi teknis: Hubungi kami melalui halaman utama APIYI di apiyi.com. Untuk informasi lebih lanjut, kunjungi pusat dokumentasi di docs.apiyi.com

Artikel terkait

• Satu orang maksimal memantau 5 sesi? Mengupas lima modul utama agen super DeepSeek: Mengulas artikel arsitektur agen super (Super-agent) tim DeepSeek Harness: lima modul utama, kondisi dan data eksperimen, empat pertanyaan terbuka, daftar penerapan untuk tim kecil, serta kombinasi model Router dan Worker dan estimasi biayanya.
• Bangun Agen Ringkasan Pemantauan yang Berjalan Terjadwal: Panduan 4 Komponen dan Pemilihan Antarmuka: Uraikan 4 komponen Agen ringkasan pemantauan terjadwal, jelaskan bagaimana lapisan pemanggilan model dipisahkan dari SDK tertentu melalui antarmuka yang kompatibel dengan OpenAI, dan berikan contoh Python yang dapat dijalankan.