已部署 AI 智能體的監控最佳實踐

Best Practices for Monitoring Deployed AI Agents

Your agent can be confidently wrong while every health check stays green — and that is the whole problem with monitoring it like an API. An agent does not just answer requests; it makes decisions, calls tools, and changes state on its own. If you only watch HTTP status and latency, you will miss the failure that matters most: the run that completed, reported success, and did the wrong thing.

Green dashboards lie about agents

Agents rarely fail by throwing an exception. They fail by doing the plausible thing badly — the right tool with the wrong arguments, a stale document treated as current, a loop retrying a dead query until the budget is gone. That is why this guide insists on four dimensions, not one: behaviour (did it do the right thing), reliability (did it finish), cost (what did it spend), and safety (did it stay inside its bounds). Watch only one and you are flying blind; Gartner's warning that 40% of agentic AI projects will be cancelled by the end of 2027, driven by cost, unclear ROI, and inadequate risk management, is what that blindness costs.

Traces first, or you have nothing to monitor

Without a trace per run — one span per model call, tool call, retrieval, and decision point — there is nothing to aggregate, alert on, or debug. OpenTelemetry's gen_ai conventions give that trace a standard shape, with token counts riding on each span and one run ID tying traces, metrics, and evals together. The vendor-neutral point matters: the instrumentation survives a change of backend, which is more than can be said for most agent frameworks. Redact secrets and personal data before anything is stored — prompts routinely contain confidential data, and raw capture without retention rules is a leak waiting for an audit.

Measure ratios, not totals

Total spend rising with volume is fine. Cost per successful outcome rising is the regression. The same logic applies across the board: step count against its ceiling, tool-call error and retry rate per tool, and — the highest-signal metric in the piece — the rate at which the agent's self-reported success disagrees with an independent outcome check. That disagreement rate is how you catch silent partial success, the agent that reports completion after a failed step. A dashboard with task success rate, latency, token cost, tool success, and step count is a starting point, not a finish line.

Evals are not a launch gate, they are a vital sign

A golden set of representative tasks, re-run on every model, prompt, or tool change, is the only thing that stops a change that passes unit tests but degrades real work from shipping. Live, sample runs for scoring — scoring everything is usually too expensive — and treat a falling eval score as a deploy-blocking signal. And calibrate the LLM judge before trusting it: in Zheng and colleagues' 2023 study, GPT-4 as a judge agreed with humans over 80% of the time, about the same as two humans agreed with each other. That sounds reassuring until you realise average agreement is not agreement on your failures — a judge can match the average human while missing every hallucination in your test set, and it carries known biases toward longer answers and its own model family. Calibrate, then re-check on a schedule. An uncalibrated judge is a hypothesis, not a measurement.

Loops and prompt injection are not edge cases

The recurring production failures — tool misuse, context exhaustion, silent partial success, unbounded loops, stale data from unmonitored integrations — are the job, not the exception. The fix for loops is a deterministic circuit breaker at the orchestrator level: hard step caps, per-tool retry counters, cost caps enforced in code. You cannot rely on a probabilistic model to enforce deterministic rules, and a system prompt is not a circuit breaker. The same goes for security: prompt injection, excessive agency, and improper output handling are directly observable as patterns in the trace stream. Monitor them as patterns, not one-off alerts.

Alert on rates, page on danger

Monitoring without an alerting path is a dashboard nobody reads. Alert on rates over a rolling window — error rate, loop rate, cost per task, eval-score drops — but keep a sharper path for events that should never wait: a safety violation, a prompt-injection attempt reaching a privileged tool, a run breaching its cost cap. Those page a human immediately and trip a circuit breaker. Every alert needs a runbook with the trace attached, and every production failure that reaches a human should become a structured case in the golden set. That is how the monitoring stack gets smarter instead of just louder.

Go deeper

The full guide walks the whole stack — tracing, metrics, evals, alerting, and cost governance — with the worked examples and controls behind each claim:

Best Practices for Monitoring Deployed AI Agents

Originally published on Agentic Affairs (https://agentic-affairs.com)