AI Agent可观测性：从系统健康到认知健康的监控范式转移

The '200 OK' Fallacy: Why Traditional Telemetry Fails AI Agents

Why do your current monitors miss the most critical AI failures? Because traditional observability was built for deterministic software. In a standard microservice, a specific input leads to a predictable output. If the service returns a 500 error, it's broken. If it returns a 200, it's working.

AI agents break this contract. They're non-deterministic. An agent can fail while every single network call succeeds. Consider the "Black Box" Loop. An agent is tasked with updating a client's portfolio. It calls a get_balance tool, receives the data, decides it needs more context, calls get_balance again, and repeats this for 50 iterations. To your Prometheus dashboard, this looks like a healthy, high-throughput service. To your customer, it's a frozen UI and a wasted API quota.

Then there's the silent hallucination. An agent in a regulated financial environment might execute a trade based on a hallucinated interpretation of a policy document. It doesn't throw an exception. It doesn't timeout. It simply makes a logically incorrect decision that bypasses keyword-based monitors because the language looks professional and confident.

We can't rely on logs to catch this. Logs tell us what happened (e.g., Tool Call: execute_trade(amount=10000)). They don't tell us why it happened. To fix this, we need to move beyond metrics and into behavioral observability.

System Health vs. Cognitive Health Observability. Contrasts traditional infrastructure telemetry with behavioral observability required to debug non-deterministic AI agent failures.

If you want to stop these silent failures, you need to integrate behavioral checks into your testing AI agent workflows.

Intent Tracing: Mapping the Delta Between Goal and Plan

Can you prove your agent actually understood the user? Most teams treat the prompt and the final answer as the only data points. This is a mistake. The most critical point of failure is the "Intent Delta": the gap between the user's objective and the agent's interpreted plan.

When a user says, "Fix my billing issue," the agent might interpret this as "Refund the last transaction." If the actual issue was a wrong address, the agent's plan is fundamentally flawed from step one. If you only monitor the output, you won't know the agent deviated until the customer complains.

Intent tracing requires capturing the reasoning chain as a first-class citizen. You shouldn't just log the tool call; you must log the internal monologue that led to it.

But there's a technical ceiling here: Context Window Saturation. As an agent performs more intermediate reasoning steps, the original intent often gets pushed out of the active context window or diluted by "noise" from tool outputs. We've seen agents start a task, execute five successful tool calls, and then completely forget the original goal, spending the next ten steps trying to figure out why they're calling tools in the first place.

To implement intent tracing, you should wrap your agent's planning phase in a trace span that includes:

• The agent's decomposed plan (the "To-Do" list).
• The mapping of each tool call back to a specific step in that plan.

The Behavioral Trace Lifecycle

This allows you to detect when an agent has "drifted" from the goal. When the plan changes mid-stream without a corresponding change in user input, you've found a cognitive failure. This is essential for scaling agentic workflows in the enterprise.

Decision Provenance and the Immutable Audit Trail

How do you explain a privileged operation to a compliance auditor? In a traditional system, you'd show a permission check and a log entry. In an agentic system, "the AI decided it was necessary" isn't an acceptable answer.

Decision provenance is the practice of creating an immutable audit trail of why a specific tool was selected over another. If an agent has access to both a read_only_policy tool and a bypass_security_check tool, you need to know the exact logic used to justify the latter.

We've seen scenarios where agents call the correct tool but with logically inconsistent parameters. For example, an agent might call update_record(id=123, status='active') when the record is already active, or worse, use a parameter that contradicts a previous step in the reasoning chain. This isn't a tool failure; it's a logic failure.

To build a provenance trail, your telemetry must capture:

• The candidate tools the agent considered.
• The reasoning for rejecting the alternatives.
• The specific evidence from the context window used to justify the choice.

{
    "trace_id": "agent-778-x9",
    "decision_point": "tool_selection",
    "selected_tool": "execute_privileged_write",
    "reasoning": "User is authenticated as Admin; policy_doc_v2 section 4.2 allows override for emergency maintenance.",
    "evidence": {
        "context_snippet": "Emergency maintenance may bypass standard approval if ticket_id is present.",
        "ticket_id": "INC-9901"
    },
    "rejected_alternatives": [
        {
            "tool": "request_approval",
            "reason": "Too slow for emergency window"
        }
    ]
}

This level of detail is non-negotiable for those navigating the EU AI Act. Without it, you're running a black box that's a liability, not an asset.

Detecting State Drift and Behavioral Anomalies

Is your agent's internal world-model actually reflecting reality? This is the problem of State Drift. State drift occurs when the agent's internal context (what it thinks is true) diverges from the actual system state.

Imagine an agent managing a cloud environment. It calls list_instances and sees instance-a is running. It then calls a script to stop instance-a. While the script is running, an external autoscaler restarts instance-a. The agent's internal state still says "Stopping instance-a," and it proceeds to the next step, "Delete instance-a," based on a false premise.

And then there's Reasoning Regression. You update your underlying LLM from version 1.2 to 1.3. Your unit tests pass. Your latency is lower. But suddenly, the agent starts skipping a critical validation step in a complex workflow. It's not a "bug" in the traditional sense; the model's reasoning pattern has shifted.

To catch this, you need Behavioral Baselines. You can't use static thresholds. Instead, you must establish "normal" reasoning patterns for specific tasks.

If a standard "Refund Request" usually takes 3 tool calls and 2 reasoning steps, an agent that suddenly takes 15 tool calls is anomalous, even if it eventually reaches the correct answer. This is a signal of inefficiency or an emerging loop.

When these anomalies hit a critical threshold, you can't just alert an SRE. You need a deterministic failover. This is where you trigger an SOS mode for deterministic recovery, stripping the agent of autonomy and forcing it into a hard-coded script.

Closing the Loop: HITL as a Telemetry Source

Why are we treating Human-in-the-Loop (HITL) only as a safety mechanism? We're missing a massive opportunity. Every time a human operator corrects an agent, they're providing a labeled example of a behavioral failure.

When a human overrides an agent's decision, that's not just a "fix"; it's a high-signal telemetry event. You should be capturing the state of the agent at the moment of intervention and the specific change the human made.

These overrides become "Golden Traces." By comparing a failed agent trace with the corrected human trace, you can identify exactly where the reasoning diverged. This data should feed directly back into your system prompts and guardrails.

HITL Behavioral Correction Loop

To make this operational, integrate these behavioral traces into OpenTelemetry (OTel). Don't build a separate "AI monitoring" silo. Use OTel attributes to tag spans with cognitive.intent, cognitive.reasoning_step, and cognitive.provenance. This allows you to correlate behavioral anomalies with infrastructure spikes. For example, you might find that reasoning regressions increase when token latency spikes, suggesting the model is "rushing" or hitting timeout-induced truncation.

This approach turns your operational overhead into a flywheel for reliability. It's the same logic used in deterministic governance for food safety recalls, where the cost of a "silent failure" is too high to ignore.

Stop monitoring your agents as if they're web servers. They're not. They're reasoning engines. Start monitoring the reasoning, and you'll finally stop being surprised by the "200 OK" failures.

Include a detailed code block showing a 'failed' 200 OK response vs. a behavioral trace

// Traditional monitoring: looks healthy
{
  "status": 200,
  "latency_p99": 145,
  "error_rate": 0.001,
  "cpu_usage": 0.42
}

// But the agent is looping...
// Tool call 47: get_balance(account_id="usr_8821")
// Tool call 48: get_balance(account_id="usr_8821")
// Tool call 49: get_balance(account_id="usr_8821")
// ... (repeats 50 times)

// Behavioral trace: reveals the failure
{
  "trace_id": "agent-778-x9",
  "intent": "Update client portfolio",
  "reasoning_chain": [
    {"step": 1, "action": "call get_balance", "reasoning": "Need current balance to calculate new allocation"},
    {"step": 2, "action": "call get_balance", "reasoning": "Previous result unclear, retrying"},
    {"step": 3, "action": "call get_balance", "reasoning": "Still unclear, retrying again"}
    // ... 47 more identical steps
  ],
  "anomaly_detected": "Intent drift",
  "deviation": "Goal (update portfolio) never reached after 50 iterations"
}

Add a section on how to implement behavioral assertions in a CI/CD pipeline

Behavioral Assertions in CI/CD

Integrating behavioral observability into your CI/CD pipeline ensures agent failures are caught before production deployment.

Step 1: Define Behavioral Baselines

Create baseline expectations for each agent workflow:

# behavioral-baselines.yaml
workflows:
  refund_request:
    expected_tool_calls: [3, 5]  # range
    expected_reasoning_steps: [2, 4]
    max_iterations: 10
    forbidden_patterns:
      - repeated_tool_calls: {tool: "get_balance", threshold: 3}
      - intent_forgetting: true

  portfolio_update:
    expected_tool_calls: [5, 8]
    expected_reasoning_steps: [3, 6]
    max_iterations: 15
    forbidden_patterns:
      - same_tool_repeated: {threshold: 5}
      - context_window_saturation: true

Step 2: Run Behavioral Tests in CI

async function behavioralAssertion(agent, workflow, baseline) {
  const trace = await agent.run(workflow);
  
  // Check tool call count
  const toolCallCount = trace.toolCalls.length;
  if (toolCallCount < baseline.expected_tool_calls[0] || 
      toolCallCount > baseline.expected_tool_calls[1]) {
    throw new BehavioralViolation(
      `Tool calls ${toolCallCount} outside baseline range ${baseline.expected_tool_calls}`
    );
  }
  
  // Check for forbidden patterns
  for (const pattern of baseline.forbidden_patterns) {
    if (pattern.repeated_tool_calls) {
      const repeats = countRepeatedCalls(trace, pattern.repeated_tool_calls.tool);
      if (repeats > pattern.repeated_tool_calls.threshold) {
        throw new BehavioralViolation(
          `Repeated tool call detected: ${pattern.repeated_tool_calls.tool} called ${repeats} times`
        );
      }
    }
  }
  
  // Verify intent preservation
  if (trace.finalState.goalAchieved !== true) {
    throw new BehavioralViolation(
      `Goal not achieved: expected ${workflow.goal}, got ${trace.finalState.achievedGoal}`
    );
  }
}

Step 3: Integrate with Deployment Gates

# .github/workflows/agent-deploy.yml
- name: Behavioral Assertion
  run: |
    npx behavioral-test --workflows ./baselines.yaml --threshold 0.95
  env:
    AGENT_ENV: staging
    OTEL_EXPORTER_OTLP_ENDPOINT: ${{ secrets.OTEL_ENDPOINT }}

Only deploy when behavioral test pass rate exceeds 95% and no critical anomalies are detected.