APX 為遭中斷的工具呼叫加入明確結束標記

An Interrupted Tool Call Needs an Explicit Ending

An agent can begin a tool call and lose its turn before receiving a result. A browser closes, a provider times out, a runtime restarts, or a person stops the work. That gap is ordinary. Pretending it never happened is not.

The useful rule is small: an interrupted tool call needs an explicit ending in conversation history. APX follows that rule when it repairs chat history. Rather than leaving an unanswered request dangling, it records that the tool was not run because the turn was interrupted.

Why a dangling call is a problem

Tool-using model APIs expect a strict sequence. An assistant message requests a tool, then a corresponding tool result returns. If history contains the first half but not the second, the next turn inherits an ambiguous state.

Did the browser search happen? Did a file get written? Is a retry safe? A model should not have to guess. Nor should a later reader infer success from an assistant message that only asked for an action.

Consider a short history:

User: Check the deployment dashboard.
Assistant: calls browser_text({ url: ... })
[process interrupted]
User: What did it find?

Without repair, the last question invites invention. A plausible answer may sound like a dashboard summary even though no result exists. That is worse than a visible interruption because it turns missing evidence into a claim.

Repair the structure, not the story

APX's runtime-history repair logic starts at a real user item, ignores orphaned tool results, and checks each assistant tool call for its matching result. When a new non-tool item arrives—or history ends—any unanswered call is closed with this explicit record:

not run: the turn was interrupted

The repaired version becomes:

User: Check the deployment dashboard.
Assistant: calls browser_text({ url: ... })
Tool: not run: the turn was interrupted
User: What did it find?

That line is deliberately narrow. It does not claim the action failed in the outside world. A request might have reached an external service before the runtime lost contact. It only says APX has no completed tool result for this turn.

This distinction matters for retries. A safe next step may be to inspect current state, ask the user, or run an idempotent check. It is not automatically “do it again.”

Keep portable context out of the repair

This is runtime work, not a change to project context. APC keeps the portable contract: AGENTS.md, .apc/ metadata, agent definitions, skills, and safe shared guidance in a repository. A compatible tool can read that contract from another checkout.

APX is the daily-use runtime. Its chat history, tool-call records, sessions, and interruption markers are local execution state. They must describe what happened in a particular conversation, but they do not belong in a portable project contract.

The boundary makes recovery easier to reason about. APC still tells an agent what project rules and skills apply after a restart. APX separately tells it whether the last tool call produced evidence. One layer supplies durable intent; the other preserves honest operational facts.

A practical recovery habit

When a tool-backed turn is interrupted, keep three questions separate:

1. Was a tool requested?
2. Did APX receive a matching result?
3. What check is safe before continuing?

Only the second question has a certain answer from the repaired history. The third depends on the operation: inspect a read-only dashboard, check a task status, or ask before repeating a write.

An explicit interruption marker is not glamorous, but it prevents a subtle class of agent mistakes. APC keeps project context portable. APX keeps execution history accountable. The next turn can then continue from evidence instead of from a gap that looks like success.