LLM 智能體的「成功」為何可能只是錯覺

Your LLM agent just told you it published the document. HTTP 200, all tokens logged, latency normal. The framework says success. But when you check the real system, nothing is there.

This gap — between what an agent says it did and what actually happened in the real world — is where autonomous systems fail in ways that monitoring tools miss.

The Two Contracts

When an LLM agent runs, there are actually two success definitions happening at the same time, and they're almost never aligned:

1. Framework success: The agent was instantiated, the model was called, tokens were consumed, the API returned HTTP 200, and the agent produced some output. From the orchestration layer's perspective, the execution succeeded.

2. Business success: The consequence of that output — the document was actually published, the API request actually landed, the data was actually written to the target system.

Most monitoring tools watch contract #1 and declare victory. But contract #2 is what your business actually cares about.

Here's the trap: both can pass independently. An agent can fully satisfy the framework contract while completely failing the business contract. It generates valid-looking output, the LLM call succeeds, no errors are raised — and then your code tries to act on that output and finds the target system unchanged.

Why This Happens

Let me walk through a concrete scenario.

An agent is tasked with publishing a support ticket to Slack. Here's what success looks like at each layer:

• Agent layer: "I called the Slack API." ✓
• HTTP layer: "Slack returned 200 OK." ✓
• Agent output layer: "My output says 'ticket posted to #support.'" ✓
• Real world: The ticket never appeared in Slack. ✗

This isn't a hypothetical edge case. It happens when:

• The Slack token has the right format but insufficient permissions (Slack returns 200 but silently fails)
• The channel ID changed and your agent is using stale configuration
• A rate limit kicked in and Slack returned 200 but queued (then dropped) the message
• Network flakiness caused a partial send that the HTTP layer didn't catch

From the agent's perspective, every checkpoint passed. From the real system's perspective, nothing happened.

Why Monitoring Stays Blind

Token counters can't see this. Cost baselines can't see this. Even output parsing can't reliably see this — a well-formed response that happens to be wrong looks identical to a well-formed response that's correct.

And silent-failure detection for agents (checking whether an execution produced zero output tokens) can catch some of these — an agent that fails hard and returns nothing is detectable. But an agent that returns plausible output that describes an action that never actually landed? That's invisible to every layer except the one watching the real system.

The Missing Layer: Action Confirmation

This is where action confirmation comes in — a separate observability layer that asks a different question than the others.

The idea is simple: after your agent claims it took an action, your own code independently verifies whether the action actually landed. Not by trusting the agent's word. Not by checking the HTTP status code. By reading the target system back.

For publishing to Slack:

Did the message actually appear in the channel?

For writing to a database:

Can I query back what I just wrote?

For updating a CRM record:

Does the field now contain what the agent said it would write?

This requires your code to have independent visibility into the target system. But if you're building an agent that acts on real systems, you need that visibility anyway — for debugging, for audit, for confidence.

How Action Confirmation Actually Works

You structure it in two phases:

1. The agent runs and produces output — normal LLM execution. It says "I published the ticket to #support."
2. Your code verifies the consequence — you query Slack's API to check whether the message actually landed. You read the state of the target system independently, don't just trust the agent's output.

Then you report that verdict alongside the agent execution. This creates a structured record: "Agent said: published. Verified: yes" or "Agent said: published. Verified: no."

The verification can be strict or lenient:

• Strict: Alert unless the action is independently confirmed. Right for safety-critical operations.
• Lenient: Alert only if your code explicitly can't confirm. Right for operations that happen to not always take a real action, so absence of confirmation doesn't mean failure.

Why This Matters Now

LLM agents are starting to actually take actions — not just generating text for humans to review, but autonomously writing to databases, publishing to platforms, transferring funds, filing tickets. The moment your agent's output becomes a real-world action, the gap between framework success and business success becomes a liability.

Monitoring frameworks are built for observing LLM execution — tokens, latency, cost, whether the model responded. But they're not built for verifying consequences. That's a different problem, and it requires a different monitoring layer.

If you're building an agent that does real things, you need both:

• Framework monitoring to catch execution failures (token anomalies, model errors, cost spikes)
• Action confirmation to catch the agents that succeed at their own contract but fail at yours

One monitors the agent. The other monitors the world the agent acts on.

Further reading: The AI Agents Control Tower includes optional action confirmation (available in SDK 0.4.4+) — you call reportAction(note, confirmed) from your code after verifying the consequence, and it attaches to the execution record. But the principle is worth implementing even without tools: define what "success" means for each agent action, then instrument verification independently.

The hardest part isn't the monitoring — it's thinking clearly about what success actually means before you ship.