Blok Fakta Kasus dan Pemangkasan Keluaran
Tetapkan fakta di luar ringkasan; pangkas hasil alat yang terlalu panjang.
Blok Fakta Kasus dan Pemangkasan Keluaran adalah pelajaran Claude Architect gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar Claude Architect, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus Claude Architect mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
The Long-Conversation Problem
In a long agentic conversation, the full message history grows past what's comfortable to keep in context. The common fix is progressive summarization: compress older turns into a running summary so the window stays manageable.
But summarization has a quiet failure mode. It's great at preserving the gist of a conversation and terrible at preserving exact values. As you compress, the precise things a model needs to act correctly start to blur.
What Summarization Destroys
Progressive summarization makes numbers, percentages, and dates vague. A turn that said "order #88231 shipped 2026-03-14, refund of $412.50 approved" can degrade into "the customer's order shipped recently and a refund was approved."
That's fine for narrative flow, but catastrophic for a tool-calling agent that must pass order_id=88231 or reason about a $412.50 threshold. The model can't recover a value the summary already erased.
The Fix: A Case-Facts Block
The architectural pattern is to pull transactional facts into a separate "case facts" block kept verbatim, outside the summary. The summary handles the conversational narrative; the case-facts block holds the exact, load-bearing values.
Crucially, this block is never summarized or compressed. When you compact older turns, the case-facts block passes through unchanged. The summary can be lossy; the facts cannot.
What Belongs in Case-Facts
Put anything exact and consequential in the case-facts block:
- IDs: order numbers, customer IDs, ticket numbers, SKUs
- Amounts and thresholds: refund totals, balances, limits
- Dates and timestamps: ship dates, deadlines, SLA windows
- Verified identity state: e.g. "customer identity confirmed via get_customer"
Leave chit-chat, rephrasings, and explanatory prose in the summary. The test: would a wrong or vague value here cause a wrong action? If yes, it's a case-fact.
Structuring the Block
Keep the case-facts block as terse, structured key/value lines — easy for the model to scan and copy verbatim into tool inputs. Inject it into the system prompt or as a pinned context block that rides along every turn.
CASE_FACTS = """
<case_facts>
customer_id: CUST-77421 (identity: VERIFIED via get_customer)
order_id: 88231
ship_date: 2026-03-14
refund_requested: 412.50 USD
refund_policy_threshold: 500.00 USD
</case_facts>
"""
system = (
"You are a support agent. The values in <case_facts> are "
"authoritative and exact. Always copy IDs and amounts from "
"<case_facts> verbatim; never reconstruct them from the summary.\n\n"
+ CASE_FACTS
)Summary + Facts Working Together
The two pieces are complementary. On each turn you send: a compressed summary of older narrative, the verbatim case-facts block, and the recent raw turns. Remember the model keeps no state — you resend this whole assembly every request.
The summary keeps the window small; the case-facts block guarantees the exact values survive. Compress aggressively in the summary, knowing the facts that matter are safe elsewhere.
def build_messages(summary, recent_turns):
# case_facts lives in `system`; summary + recent turns in messages
return [
{"role": "user",
"content": f"<conversation_summary>{summary}</conversation_summary>"},
*recent_turns, # last few raw turns, uncompressed
]
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system=system, # contains the verbatim CASE_FACTS block
messages=build_messages(summary, recent_turns),
tools=tools,
)Lost in the Middle
There's a second reason placement matters. Models exhibit a lost-in-the-middle effect: they attend more strongly to the start and end of the context than to the middle.
So a critical fact buried in the middle of a huge tool dump or a long summary is the most likely thing to be overlooked. Position your case-facts block where attention is strongest — early in the system prompt or pinned near the end of the input.
The Other Half: Verbose Tool Output
Case-facts solve retention. The second discipline is controlling what enters the window in the first place. Tools — APIs, database queries, file reads — often return huge, deeply nested JSON payloads, most of which is irrelevant to the decision at hand.
Appending that raw blob to history bloats the window, pushes important content into the lost-in-the-middle zone, and dilutes the model's attention. The rule: trim verbose tool output to the relevant fields before the model sees it.
Trimming in Code
Do the trimming deterministically in your own code, between getting the raw result and appending it to the message history. Extract only the fields the model actually needs to reason or to fill the next tool call.
raw = lookup_order(order_id=88231)
# raw has 60+ fields: internal flags, audit log, warehouse meta, etc.
trimmed = {
"order_id": raw["order_id"],
"status": raw["status"],
"total": raw["total"],
"ship_date": raw["fulfillment"]["ship_date"],
}
messages.append({
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": tool_use_id,
"content": json.dumps(trimmed),
}],
})Trimming with a PostToolUse Hook
You can also enforce trimming with a PostToolUse hook, which intercepts a tool result before the model sees it. This makes trimming deterministic and centralized rather than relying on each tool's implementation to behave.
The hook is the right home for a strict, always-applied projection of fields — the same deterministic-enforcement logic you'd use for any policy that must run 100% of the time, not ~90% of the time as a prompt would.
# PostToolUse hook: keep only whitelisted fields per tool
KEEP = {
"lookup_order": ["order_id", "status", "total", "ship_date"],
}
def on_post_tool_use(tool_name, result):
keys = KEEP.get(tool_name)
if not keys:
return result
return {k: result[k] for k in keys if k in result}Trim, but Don't Lose Provenance
Trim for relevance — not so hard that you discard what you'll later need to act or to cite. If a value is going to drive a tool call or a customer-facing claim, promote it into the case-facts block instead of dropping it.
One clean division of labor: trim tool output going into the running history, and pin the exact values that must survive into the verbatim case-facts block. Lossy where it's safe, verbatim where it's not.
Quick Check
A support agent runs long multi-turn sessions. To stay in budget, older turns are progressively summarized. Testers report it sometimes refunds the wrong amount or passes a stale order number after the conversation has run a while. What's the best fix?
Recap
Key takeaways:
- Progressive summarization blurs exact values — numbers, percentages, and dates go vague.
- Pin transactional facts in a verbatim case-facts block outside the summary; the summary may be lossy, the facts must not be.
- Lost-in-the-middle: models attend most to the start and end — place critical facts there, not buried mid-context.
- Trim verbose tool output to relevant fields before appending to history; a PostToolUse hook makes this deterministic.
- Division of labor: trim what flows into history, pin what must survive verbatim. Lossy where safe, exact where it counts.
Belajar Python dengan tutor AI — gratis
Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.
- Kursus
- 26
- Pelajaran
- 104
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Blok Fakta Kasus dan Pemangkasan Keluaran” gratis?
Ya — teks lengkap “Blok Fakta Kasus dan Pemangkasan Keluaran” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus Claude Architect, upgrade ke CoddyKit PRO. Kursus Claude Architect mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Blok Fakta Kasus dan Pemangkasan Keluaran”?
Tetapkan fakta di luar ringkasan; pangkas hasil alat yang terlalu panjang. Kamu berlatih Claude Architect dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai Claude Architect?
Tidak diperlukan pengalaman sebelumnya. Claude Architect di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Blok Fakta Kasus dan Pemangkasan Keluaran” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran Claude Architect ini?
Ya. Setiap pelajaran Claude Architect menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Seluruh Riwayat Diperlukan
- Risiko Perangkuman Progresif
- Efek Hilang di Tengah
- Blok Fakta Kasus dan Pemangkasan Keluaran