HomeArticle

Building an AI Agent System: Thoughts from the Core to Practice

王建峰2025-08-11 09:40
The Year of AI Agents in 2025: Comparison of Workflows and Autonomy and Production Challenges

I. Overview

Many people say that 2025 is the "Year of AI Agents." No one can agree on a definition of "AI agents", but most people would agree that the autonomy of AI agents is constantly evolving. On one hand, there are workflows (where each step is pre - planned). On the other hand, there are AI agents that decide what to do during execution. The difference between the two can be boiled down to one question: Who is in the driver's seat - the developer or the model?

This article details both of these aspects and then delves into the messy, beyond - tutorial parts you'll encounter when trying to deliver for production.

II. Workflows

1. Core Parts of a Workflow

You can implement workflows however you like, but conceptually, I think it's intuitive to view it as a simple diagram. The boxes and arrows in the diagram never improvise - every step is planned in advance.

Nodes: Each node is a task, which could be an LLM call, some mathematical operations, or simply "send this email."

Edges: The arrows that glue the boxes together. They indicate "go here next," "skip this block if X," or "run all of these in parallel and then converge here." Loops are allowed. Arrows can point back to previous boxes until an instruction to stop is given.

Shared State: A node can quietly send its results to the next node in the queue or place them on a common whiteboard accessible to the entire diagram.

2. Basic Workflow Patterns

Prompt Chaining: Feed the output of the first LLM directly into the next, and then into the next, and so on, like a conveyor belt where each station adds a sticker.

Routing: Read incoming requests and direct them to the path that knows how to answer.

Parallelization - Aggregation: Start several branches simultaneously, then collect and merge the results.

Coordinator - Worker: A central Large Language Model (LLM) is responsible for evaluating the work, breaking it down into clear subtasks, and assigning them to smaller LLMs. When all members are done, it integrates the parts. (This already looks a lot like an AI agent.)

Evaluator - Optimizer: One person writes, another scores, and the cycle continues until the score finally stays above the standard.

III. AI Agents

1. Core Elements of an AI Agent

In essence, an AI agent is just an LLM with an instruction indicating how it should act, plus a box of tools it can use when it needs an external system or data. Some other important parts keep the whole system running:

Execution Loop (AI Agent Runner): An LLM can only "talk" or communicate in other ways, such as through images; it can't click buttons. A continuous loop reads the generated text, determines the requested tool, triggers the call, and feeds the result back to the LLM. This loop repeats until the AI agent judges the task is complete or a stop condition is triggered.

Context: Context is the piece of information that the LLM can "see" when thinking. It covers everything from dry but useful content (e.g., today's date, the user's access level) to the chitchat in the conversation (e.g., previous messages, past tool calls). Although many LLMs now have long context windows, irrelevant information can pile up quickly in multi - round interactions, so streamlining is crucial.

Session State (Short - term Memory): A session covers a complete run - it could be five rounds or fifty. Everything the AI agent learns, decides, or generates is kept here until the session ends.

Long - term Memory: When something should persist after the session ends - user preferences, solved problems, half - written code - it is stored in a database, vector store, or plain text file.

Handover: If the task changes, for example, from booking a flight to submitting an expense report, the current agent can pass the baton to a teammate who is proficient in that area. The handover includes not only the original data but also the task context, chat history, and the current conversation leader.

Lifecycle Events: Even autonomous runs encounter predictable checkpoints: before a tool call, after the LLM returns, before the next prompt, etc. These moments are very useful for logging, permission checks, or terminating the run early if something goes wrong.

2. Basic Patterns of AI Agents

A single AI agent is just an LLM, its instruction, and a loop. When a user or another system places a task on its "desk," the AI agent starts. Inside the loop, the AI agent plans the next action, calls any required tools, and keeps executing until it thinks the task is complete or is terminated due to built - in limitations (e.g., a limit on the number of rounds or tokens).

A single agent can handle only a limited number of tools and instructions; otherwise, it will make mistakes due to its own environment. Spreading the load across multiple agents - each with a clearer task description and a lighter toolkit - is usually more concise and reliable in the end. Here are some multi - agent collaboration patterns:

Supervisor - Worker: The central AI agent continuously communicates with the user while assigning subtasks to specialized workers. The workers don't need to talk to the user. The supervisor has an overview and the final say.

Classification: It has the same shape as the supervisor - worker setup, but after classifying the request, the classification AI agent hands the caller over to the correct expert.

Hierarchy: A deeper stack where each expert may have its own sub - team, allowing the depth of the tree to grow according to the needs of the problem.

Sequential: AI agents are arranged in a line, and each AI agent takes over the handover task from the previous one. This is similar to an immediate chaining workflow, except that it uses full AI agents instead of single LLM calls.

Parallelization - Collection: Start multiple AI agents simultaneously, let them work in parallel, and then merge their results before proceeding.

Redundancy: Start multiple AI agents that perform the same task but in different ways, compare their answers, keep the best one, or synthesize a new answer. This method consumes extra resources but improves reliability.

Review - Criticism: One AI agent builds, another checks, and the cycle continues until the critic is satisfied. It's the same as the evaluation - optimization workflow but upgraded to full AI agents.

Escalation: Start with a low - cost, lightweight AI agent. If there's a problem, escalate the ticket to a heavier, more capable (usually more expensive) AI agent. This is a classification approach with built - in cost control.

Network: Each AI agent is on an open channel. Any of them can ping other AI agents, decide who will execute the next step, and then hand over the task - no central scheduling is required.

IV. Workflows vs. AI Agents

A comparison of the two methods is as follows:

Most people will eventually find a balance: give AI agents enough freedom to function, but also set fences to ensure they are safe, visible, and within budget. Workflow nodes can delegate messy corners to AI agents, and AI agents can join the workflow when stable subtasks are needed.

V. Considerations Beyond the Basics

Connect a few basic components, choose a pattern, and you have an AI agent system. With today's open - source frameworks, it actually only takes ten lines of code. Tutorials make it seem effortless, but the real - world production environment is very different. Here are the extra tools you need before actual users start using it.

1. Guardrails

LLMs still make mistakes, and hackers still find loopholes. You need technical and policy guardrails to ensure that agents operate within the boundaries of safety, legality, cost, and brand image. These guardrails are not a single gate but a multi - layer safety net. They can be alignment embedded in the model weights, plus input and output checks, and restrictions on agent operations.

Model - level alignment is usually handled by the provider (e.g., hate, self - harm, toxicity, etc.)

Input guardrails block unwanted messages before they reach the AI agent: - Enhanced auditing plus jailbreak/SQL injection filters - Topic restrictions (no irrelevant questions, no comments about competitors, no politics or religion) - Business rules (no PII fishing, no insider information probing)

Runtime guardrails monitor what the AI agent is about to do: – Limit tools by user role – High - risk operations require manual approval – Termination switch if spending, token count, or time exceeds the limit

Output guardrails catch mistakes during the output process: - Validate the expected output pattern - Hallucination check (source document validation in RAG settings) - Final content audit check

You can mix LLM - based checks, heuristic rules (regular expressions, allow lists), and third - party auditing APIs. Choose a combination that suits your budget and risk profile. Additionally, there are several off - the - shelf tools available, such as Guardrails.ai or Nemo Guardrails.

2. Observability

AI agent systems are non - deterministic, contain loops, and can fail for reasons that are difficult to identify. If you use a framework, sometimes a small piece of code (like twenty lines) can trigger dozens of underlying LLM calls or tool calls. Observability is like a flashlight that allows you to see inside these hidden layers, understand the system, troubleshoot, and steadily improve it. So, what do you need to "observe"?

Instructions and messages, especially templated ones.

The input and output of each step, even those the user never sees.

Which branch the AI agent took and why.

The inference loop - are we really moving towards the goal?

Tool calls, passed parameters, and raw results.

For RAG settings, the exact blocks and scores returned.

Classic application metrics: latency, error rate, cost per run, etc.

Fortunately for many of us, there are several open - source observability libraries that support AI agent systems, so there's no need to hand - craft these logs.

Pydantic Logfire: Minimal observability for LLMs, databases, and web frameworks.

Mlflow, Arize Phoenix, Weights and Biases: They also have traditional machine learning operation support.

Langsmith, Langtrace: Specialized for GenAI applications.

You can also layer more advanced features on top of the observability data, such as running sentiment analysis on user interactions or using a separate AI agent system to evaluate production traces to find the cause of failures.

3. Evaluation

Developing traditional machine - learning models requires validation and test sets; developing classic software requires unit and integration tests. AI agent systems borrow from both camps. You need numerical and clear pass/fail signals, but these numbers aren't easy to obtain. You'll be judging a generated text without a clear standard. You'll be evaluating the path the AI agent decides to take when there's no objectively correct path. An AI agent system isn't a single model that produces a single output. It includes routing, retrieval, generation, tool use, inference chains, and a complete loop that connects them all. You have to test both the parts and the whole.

Although the metrics are still evolving, these core checks can take you a long way:

End - to - end success: Did it actually complete the work the user asked for?

Trajectory and tool use: Did it choose the correct branch and pass the correct parameters?

Retrieval quality: For RAG, did the retrieval return the needles you care about with appropriate precision and recall?

Answer quality: Once the context is understood, does the final answer answer the question without fabricating facts?

Inference trace: Does the planning and thinking reveal where the logic derailed?

Multi - round evaluation: Does the conversation still make sense after five or six rounds?

Cost, latency, token consumption: Application - level health checks.

To get scores in these areas, you can combine LLM - as - judge (automated) and human evaluation (resource - intensive). When building an evaluation set, you can:

Use LLM - synthesized data: Fast and cheap, but may not match real - user queries.

Bootstrap from legacy logs: Old queries from the system you're replacing provide a good starting point.

Real - user samples: Expensive to collect but most effective.

Create edge cases: Hand - craft strange corner inputs you hope will never happen.

Production consequences: After the system goes live, every run failure or user complaint becomes a new case to add.

Conduct an evaluation every time you adjust the prompt or add a tool. Fast, repeatable evaluation can turn "hoping it works" into a real engineering cycle. You can discover hidden errors early, keep spending predictable, and release safe updates daily instead of taking a big risk once a quarter. RAGAS, Trulens, or Mlflow evaluation are good starting points for evaluation.

4. Security

AI agent systems inherit all the security challenges that services face, such as token leakage or excessive role permissions, and add several new security issues. An AI agent is an inference engine that can be tricked into running commands, leaking data, or handing control to another AI agent. It can also start new subprocesses or call APIs not listed in the specification. Protocols like MCP (Model Context Protocol) give them super - powers, but each additional plugin means another door to guard. At the very least, it's best to start with all standard best practices: put secrets in a vault, grant minimum permissions, and rotate keys. Additionally:

Set up guardrails to prevent prompt attacks and treat all retrieved text as untrusted input and scan for adversarial patterns.

Ensure that the AI agent operates strictly within the user's permissions. Each tool call should carry the user's access token to ensure it doesn't access other users' data.

Treat each collaborating AI agent as a stranger and require it to provide the same identification as a human caller.

Run the AI agent in a sandbox, which starts with no network and disk access unless you explicitly grant permission.

Validate every input and output at the MCP boundary and sandbox the interpreter.

In short, never trust an AI agent to self - regulate - wrap each decision point with authorization checks, logging, and automatic revocation.

5. Deployment

AI agent systems can be deployed in several common ways. One is through short - lived serverless functions triggered by API calls or timers. For example, an AI agent workflow carefully