跪拜 Guibai
← All articles
Frontend · AI Programming · Artificial Intelligence

The Engineering Boundaries That Make AI Agents Controllable

By 恋猫de小郭 ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

The difference between a demo and a production agent is the engineering that enforces boundaries. Without explicit state management, tool contracts, and trajectory evaluation, an agent will hallucinate actions in high-stakes domains like contracts or finance, causing irreversible damage.

Summary

Building a reliable AI agent for business tasks like contract review requires far more than connecting a model to a few APIs. The core challenge is controllability, which is solved by external engineering, not the model itself. A complete agent architecture spans intent recognition with confidence-based routing, a persistent state machine with checkpoints for long-running tasks, and a tool system where every function is a strict contract with risk ratings, idempotency keys, and structured error handling.

Structured output demands a robust pipeline that goes beyond JSON parsing to include semantic validation and safe repair strategies. Retrieval-augmented generation (RAG) must be treated as a multi-stage process of recall, reranking, and context assembly to prevent evidence loss or hallucination. Memory is split into four distinct layers—working, summary, semantic, and structured—each with its own storage and lifecycle to avoid pollution and conflicts.

Evaluation and observability form the final critical layer. Success isn't just a correct final answer; the entire execution trajectory must be audited for safety, efficiency, and budget adherence. A complete trace, from tool selection to every retry, is the only way to debug failures and prove the system is production-ready.

Takeaways
A production agent's reliability is determined by external engineering boundaries, not the core LLM's intelligence.
Intent recognition should use a layered approach: deterministic rules for high-frequency commands, context-based routing for ambiguous follow-ups, and LLM classification only for complex tasks.
Every agent task needs an explicit state machine with checkpoints to support pausing, resuming, and preventing duplicate execution of side effects.
Tools must be defined as strict contracts including risk level, idempotency requirements, and structured error codes, not just function signatures.
Structured output from LLMs requires a pipeline that handles syntax, schema, and semantic validation separately, with limited, safe repair attempts.
RAG in an agent context is a full pipeline of parsing, multi-path recall, reranking, and context assembly; it fails if any single stage is treated as an afterthought.
Agent memory should be split into four layers (working, summary, semantic, structured) with distinct storage and write policies to prevent pollution and version conflicts.
Evaluation must cover the entire execution trajectory, not just the final answer, checking for unnecessary tool calls, budget overruns, and unsafe recovery paths.
Complete tracing of every agent run—including tool calls, retries, and authorization checks—is non-negotiable for debugging failures in production.
Conclusions

Treating the LLM as the brain and the surrounding engineering as the autonomic nervous system is a useful model; the brain decides, but the nervous system keeps the organism from harming itself.

The insistence on idempotency for all side-effect tools highlights a key difference from coding agents: re-running a compiler is safe, but re-sending an email or refund is a catastrophe.

Risk-rating tools into five levels (from pure reasoning to forbidden actions) creates a clear, auditable policy that prevents the model from ever being in a position to make a catastrophic decision on its own.

Structured output repair is a double-edged sword; the article rightly warns against guessing truncated enums or contradictory fields, as silent data corruption is worse than a hard failure.

The four-layer memory model solves a common anti-pattern where teams dump everything into a single vector store, mixing transient state with long-term facts and creating unmanageable recall noise.

Concepts & terms
Agent State Machine
A structured data object that tracks an agent's current step, collected information, tool history, and budget. It is essential for pausing, resuming, and recovering long-running tasks, unlike a simple chat history.
Idempotency Key
A unique identifier attached to a tool execution request. It ensures that if an operation with side effects (like sending an email) is retried due to a network error, the action is only performed once.
Tool Risk Rating
A classification system for agent tools (e.g., R0 for pure reasoning, R3 for high-risk writes like refunds) that dictates the required confirmation and authorization level before execution.
Trajectory Evaluation
An evaluation method that judges an agent not just by its final answer, but by the entire sequence of steps it took. It checks for unnecessary tool calls, safety violations, loops, and budget adherence.
Parent-Child Retrieval
A RAG strategy where documents are split into small chunks for precise matching (child) and larger chunks for providing full context (parent). The small chunk triggers the retrieval, but the larger chunk is sent to the LLM.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗