長篇 AI 對話如何設計可安全重試的交接協議

A Retry-Safe Handoff Contract for Long AI Chats

Long AI-assisted tasks often span more than one interaction. A response may be interrupted, a user may need to start a new conversation, or a tool call may finish while the interface is still waiting. The fragile point is not always the summary itself. It is the transition: what happens if a handoff is sent twice, acknowledged late, or resumed from incomplete context?

A useful design starts by treating a handoff as a small protocol, not as an unstructured paragraph that says “continue where we left off.”

Separate the work state from the transport

A handoff packet should describe only the state needed to resume responsibly. For example:

{
  "schema_version": 1,
  "conversation_id": "example-session",
  "revision": 17,
  "goal": "Complete the deployment review",
  "confirmed_facts": ["Tests passed locally"],
  "decisions": ["No production change without approval"],
  "open_items": [{"id": "T-12", "task": "Verify the live service"}],
  "unknowns": ["Whether the new version is serving traffic"],
  "last_completed_step": "Recorded the dry-run results"
}

The distinction between confirmed_facts and unknowns matters. A newly opened conversation should not silently promote a guess into a fact. Likewise, decisions and restrictions should survive even if older conversational details do not.

Avoid putting passwords, API keys, session cookies, personal identifiers, or confidential source material into the packet. A handoff is still data being copied into another context; minimization and redaction should happen before transfer.

Give the handoff a stable identity

Retries are normal in distributed workflows. Suppose a sender transfers a packet, receives no acknowledgment, and retries. Without a stable ID, the receiver may treat the retry as a new instruction.

A simple demonstration uses a content-derived ID:

import { createHash } from 'node:crypto';

function makePacket(state) {
  const payload = JSON.stringify(state);
  const id = createHash('sha256').update(payload).digest('hex');
  return { id, payload };
}

function acceptPacket(packet, receiptStore) {
  if (receiptStore.has(packet.id)) {
    return { duplicate: true, receipt: receiptStore.get(packet.id) };
  }
  const receipt = { id: packet.id, accepted: true };
  receiptStore.set(packet.id, receipt);
  return { duplicate: false, receipt };
}

const state = { conversation_id: 'example-session', revision: 17 };
const packet = makePacket(state);
const receipts = new Map();
console.log(acceptPacket(packet, receipts).duplicate); // false
console.log(acceptPacket(packet, receipts).duplicate); // true

This is an in-memory illustration, not production-grade exactly-once delivery. A real system needs durable storage, a unique constraint on the handoff ID, and an atomic relationship between recording the receipt and applying any consequential operation. Cross-language systems also need canonical serialization before hashing, because equivalent JSON objects can have different byte representations. A hash is an identifier here, not an authorization token.

Use an explicit state machine

A handoff can move through a few named states:

A timeout after PREPARED is not evidence of failure; the receiver might have accepted the packet before the acknowledgement was lost. The safe retry uses the same packet ID and first asks the receiver whether it has already been accepted.

A separate state transition should be required before any action with external effects: sending email, updating a database, deploying software, or publishing content. Resuming context is not permission to perform those actions.

Require a resume check

Before continuing, the destination should answer five questions:

1. Is the packet complete enough to understand the goal and current step?
2. Are the restrictions and unresolved uncertainties preserved?
3. Has this packet ID already been processed?
4. Does any requested action require fresh human authorization?
5. Can the next step be verified without relying on a claim from an older summary?

If the answer to an important question is unknown, the continuation should say so. “Needs verification” is a valid state; invented certainty is not.

Test failure paths, not just the happy path

At minimum, test duplicate delivery, dropped acknowledgments, stale revisions, malformed packets, missing restrictions, cancellation, and re-opening a conversation after the sender is gone. It is also worth checking that no hidden background action starts solely because a handoff arrives.

For browser-based tools, the user should be able to pause, inspect, copy a backup, and stop a transition. Visibility is not a substitute for permissions, but it makes failures easier to detect and recover from.

The practical takeaway

A summary helps another conversation understand the work. A handoff protocol helps it resume safely. The difference is an explicit record of what is known, what is not known, what has already happened, and which steps still require authorization.

AI disclosure: This article was drafted with generative AI. It must be checked and substantially reviewed by a human who understands the technical material before publication. It is not a report of firsthand testing or production experience.