8.0
热点
AI SCORE
技术实践2026-08-29 22:50
AI Agent技术栈全解析：什么让Agent真正work
dev.to · AI#Agent#架构#LLM
Editor brief · 编辑速览
文章拆解了AI Agent的核心层次：LLM智能、上下文与工具、记忆、规划、状态、工作流、护栏和评估，指出工具+LLM不等于可靠Agent。
深入探讨现代 AI 智能体的实际架构——从 LLM 和上下文，到工具、记忆、规划、状态、护栏与评估。
AI 行业有一个习惯：几乎把所有东西都叫作"智能体"。
给 LLM 接入一个搜索功能就叫智能体？
连接数据库就叫智能体？
在工具调用外层加个循环就叫智能体？
但附带工具的 LLM 并不等于可靠的 AI 智能体。
理解 AI 智能体有一个实用的方式：
AI 智能体是一个能够理解目标、访问相关上下文、决定做什么、使用可用能力、维护状态并产生或执行结果的系统。
LLM 提供的是智能。
但仅有智能并不能让系统运作。
一个生产级别的 AI 智能体通常长这样：
USER / EVENT
│
▼
┌─────────────┐
│ AGENT │
│ RUNTIME │
└──────┬──────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
Context Memory Tools
│ │ │
└─────────────────┼─────────────────┘
▼
Planning / Routing
│
▼
State & Workflow
│
▼
Guardrails / Policies
│
▼
Action / Response
│
▼
Evaluation / Tracing
这就是 AI 智能体技术栈。
理解这些层次，往往比单纯学习如何写出更好的提示词更有价值。
大多数智能体的核心是一个 LLM。
模型提供的能力包括：
但这里有一个重要的区分：
LLM ≠ Agent（智能体）
LLM 并不会自动知道：
这些职责属于周围架构的范畴。
把 LLM 看作推理引擎。
仅有引擎不能称之为汽车。
每个智能体的决策都依赖上下文。
最简单的上下文形式是：
System Prompt
+
User Message
但真实系统需要的多得多。
Context =
User Query（用户查询）
+
Conversation History（对话历史）
+
Retrieved Knowledge（检索到的知识）
+
Current Workflow State（当前工作流状态）
+
Tool Results（工具返回结果）
+
User Permissions（用户权限）
"Can you approve my expense?"（"你能审批我的报销吗？"）
智能体仅凭这句话无法可靠地回答。
它需要知道当前审批状态。
这就是为什么上下文工程已成为 AI 工程领域的一门重要学科。
挑战不在于简单地添加更多信息。
挑战在于在正确的时机选择正确的信息。
上下文太少会导致错误决策。
上下文太多会产生噪音。
一个好的智能体架构将上下文视为一种被管理的资源。
这就是检索系统进入架构的地方。
智能体可能需要从以下来源获取信息：
一个基本的 RAG 流程如下：
User Question（用户问题）
│
▼
Retrieval（检索）
│
▼
Relevant Knowledge（相关知识）
│
▼
LLM
│
▼
Response（回复）
但在智能体内部，检索变得更加动态。
智能体可以决定：
Question（问题）
│
▼
Do I need external knowledge?（我需要外部知识吗？）
│
├── No → Continue reasoning（否 → 继续推理）
│
└── Yes（是）
│
▼
Retrieve（检索）
│
▼
Is the result sufficient?（结果足够吗？）
│
┌──┴──┐
Yes No
│ │
▼ ▼
Continue Search Again
这是一个重要的转变。
检索不再只是一个管道步骤，它成为了一种智能体能力。
知识让智能体能够回答问题。
工具让智能体能够执行操作。
考虑以下差异。
"Your meeting is scheduled for tomorrow."（"你的会议已安排在明天。"）
智能体实际上可以：
Check Calendar（检查日历）
│
▼
Find Available Slot（查找可用时段）
│
▼
Create Meeting（创建会议）
│
▼
Send Invitations（发送邀请）
│
▼
Verify Success（验证成功）
这就是从：
AI as Interface（AI 作为界面）
到
AI as System Participant（AI 作为系统参与者）
的转变。
然而，工具访问带来了严肃的工程挑战。
智能体不应该无限制地访问一切。
Agent（智能体）
│
├── Read Customer Data ✓（读取客户数据 ✓）
├── Search Documentation ✓（搜索文档 ✓）
├── Create Support Ticket ✓（创建工单 ✓）
├── Delete Production Database ✗（删除生产数据库 ✗）
└── Transfer Money → Requires Approval（转账 → 需审批）
工具需要权限、验证和边界。
记忆是 AI 智能体中最容易被误解的概念之一。
许多开发者认为：
"那就存储整个聊天历史吧。"
这不一定是真正有用的记忆。
生产级智能体可能需要多种类型的记忆。
短时记忆——用于当前交互。
User → Agent → Tool → Result → Agent
长时记忆——跨会话使用。
历史交互
任务记忆——用于跟踪任务进度。
Task: Laptop Replacement（任务：笔记本电脑更换）
Status（状态）：
✓ User verified（用户已验证）
✓ Warranty checked（保修已检查）
✓ Ticket created（工单已创建）
→ Manager approval pending（等待经理审批）
第三类尤为重要。
许多"记忆问题"实际上是状态管理问题。
想象一个处理工作流的智能体。
Step 1 → Collect Information（收集信息）
Step 2 → Validate Data（验证数据）
Step 3 → Request Approval（请求审批）
Step 4 → Execute Action（执行操作）
Step 5 → Notify User（通知用户）
如果系统在 Step 3 之后崩溃了怎么办？
没有状态管理，智能体可能会重新开始所有步骤。
导致工作流不一致。
一个可靠的系统应该知道：
{
"workflow_id": "REQ-1024",
"current_step": "approval_pending",
"ticket_created": true,
"notification_sent": false
}
这就是为什么 AI 智能体越来越像分布式软件系统。
智能体可能是有智能的。
但工作流仍然需要传统工程原则：
AI 不能消除软件工程。
它只是让好的软件工程变得更加重要。
智能体接收一个目标。
然后需要确定：
我接下来该做什么？
对于一个简单的请求：
User: "What's our refund policy?"（用户："我们的退款政策是什么？"）
Retrieve Policy → Answer（检索政策 → 回答）
"Find my last order, check whether it qualifies for a refund, and initiate the process."（"找出我上一个订单，检查它是否符合退款条件，然后启动流程。"）
现在智能体需要一个工作流。
Understand Request（理解请求）
│
▼
Find Customer Order（查找客户订单）
│
▼
Check Refund Policy（检查退款政策）
│
▼
Verify Eligibility（验证资格）
│
▼
Initiate Refund（启动退款）
│
▼
Confirm Result（确认结果）
规划并不总是需要复杂的自主推理循环。
有时候确定性路由更好。
Intent = "Order Status"（意图 = "订单状态"）
↓
Call Order API（调用订单 API）
Intent = "Refund Request"（意图 = "退款请求"）
↓
Run Refund Workflow（执行退款工作流）
Intent = "Technical Question"（意图 = "技术问题"）
↓
Use Knowledge Retrieval（使用知识检索）
一个实用的工程经验：
不要在确定性工作流更可靠的地方使用智能体循环。
自主性并不自动意味着架构改进。
能够执行操作的智能体必须在约束条件下运行。
护栏可以存在于多个层级。
指令层——防止恶意指令
数据层——保护敏感信息
执行规则，例如：
Refund > $1,000（退款 > $1,000）
↓
Human Approval Required（需人工审批）
重要的原则是：
永远不要完全依赖 LLM 来强制执行关键的安全边界。
如果用户不应该访问某条数据库记录，授权层应该在 LLM 接收到该信息之前就阻止访问。
关于智能体最大的误解之一是：成功意味着移除人类。
Low Risk（低风险）
↓
Automatic Execution（自动执行）
Medium Risk（中等风险）
↓
Confirmation Required（需要确认）
High Risk（高风险）
↓
Human Approval（人工审批）
Draft Email（起草邮件）
→ Autonomous（自主执行）
Send Email to Customer（发送邮件给客户）
→ Confirmation（需确认）
Delete Customer Account（删除客户账户）
→ Human Approval（需人工审批）
目标不是最大自主性。
目标是适当的自主性。
一个生产级 AI 智能体应该知道什么时候可以行动，什么时候应该停下来。
传统软件错误可能长这样：
HTTP 500
Database Connection Failed（数据库连接失败）
智能体失败往往更复杂。
"The agent gave the wrong answer."（"智能体给了一个错误的答案。"）
可能是：
错误的上下文 ↓ 错误的检索 ↓ 糟糕的工具选择 ↓ 错误的工具参数 ↓ 工具执行失败 ↓ 不正确的推理
没有可观测性，调试就变成了猜谜游戏。
生产环境中的智能体应该生成类似这样的追踪链路：
User Request
│
▼
Intent: Refund Request
│
▼
Tool: Order Lookup
Result: Order Found
│
▼
Retriever: Refund Policy
Result: Policy Retrieved
│
▼
Decision: Eligible
│
▼
Tool: Create Refund
Result: Success
如果你无法重构智能体的执行路径，你就无法可靠地改进它。
漂亮的响应并不意味着智能体成功了。
User:
"Cancel my subscription."
Agent:
"Your subscription has been successfully cancelled."
但如果取消 API 失败了呢？
响应在语言层面是正确的。
系统在操作层面是错误的。
因此，智能体评估应该包括：
正确的工具选择
从失败中恢复
最终问题应该是：
系统是否完成了预期目标？
模型是否生成了好的答案？
将 AI 智能体技术栈整合在一起
一个实用的 AI 智能体架构可以这样可视化：
USER
│
▼
┌──────────────┐
│ Agent Runtime│
└──────┬───────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
Context Knowledge Memory
│ │ │
└──────────────┼──────────────┘
▼
Planning / Routing
│
┌──────────┼──────────┐
▼ ▼ ▼
Tools State Guardrails
│ │ │
└──────────┼──────────┘
▼
LLM / Model
│
▼
Action / Response
│
▼
Tracing & Evaluation
每一层解决不同的问题。
Layer Primary Responsibility
------------------------------------------------------------
Model Reasoning and language
Context Relevant information
Knowledge External facts and documents
Tools Actions and system access
Memory Persistent information
State Workflow progress
Planning Deciding next steps
Guardrails Safety and policy
Observability Debugging and tracing
Evaluation Measuring success
错误在于期望某一层解决所有问题。
一个实际案例：构建支持智能体
假设你想构建一个企业 IT 支持智能体。
一个朴素的架构：
User → LLM → Answer
一个更好的架构：
User Request
│
▼
Intent Classification
│
├── Knowledge Question
│ ↓
│ RAG Search
│
├── Account Issue
│ ↓
│ Account API
│
└── Technical Problem
↓
Diagnostic Tool
│
▼
Create Support Ticket
Identity
+
Permissions
+
Workflow State
+
Tool Validation
+
Audit Logs
突然之间，你不再是在构建一个聊天机器人。
你在构建一个 AI 驱动的软件系统。
最重要的教训：并非所有事情都需要智能体
这在一篇关于 AI 智能体的文章中听起来可能自相矛盾。
但最重要的 AI 工程技能之一是知道什么时候不构建智能体。
Input
↓
Fixed Business Logic
↓
Output
使用传统软件。
如果工作流需要：
模糊的意图
+
动态上下文
+
多个信息源
+
灵活的决策
+
工具选择
那么智能体可能是合适的。
用自主智能体替换每一个工作流。
在每个有意义的地方将确定性软件与概率性智能结合。
从 AI Demo 到 AI 系统
大多数 AI Demo 都看似简单。
Prompt
↓
LLM
↓
Magic
生产系统则不同。
Context
+
Retrieval
+
Tools
+
State
+
Memory
+
Policies
+
Validation
+
Observability
+
Evaluation
这就是以下两者的区别：
"Look what the model can do."
"Can this system reliably do the job?"
前者创造 Demo。
后者创造基础设施。
没有一个单一组件能够神奇地将 LLM 变成 AI 智能体。
可靠的智能体从多层交互中涌现：
智能来自模型
决策的上下文
用于落地的事实知识
用于连续性的记忆
用于协调的规划
用于控制的护栏
用于调试的可观测性
用于可靠性的评估
这就是真正的 AI 智能体技术栈。
对于转入 AI 工程的开发者来说，也许最大的思维转变是：
模型不是产品。
模型只是一个组件。
真正的产品是围绕它构建的系统。
随着 AI 智能体从令人印象深刻的 Demo 走向真正的生产环境，差异化不再简单地取决于谁能访问最智能的模型。
而是在于谁能围绕它设计出最可靠的架构。
AI 智能体变得有用不是因为它们能思考。
它们变得有价值，是因为围绕它们思考的系统能够可靠地将决策转化为结果。
单独的 LLM 不是 AI 智能体。
上下文决定了许多智能体决策的质量。
检索提供知识，工具实现行动。
记忆和工作流状态解决不同的问题。
并非所有工作流都需要自主规划。
尽可能在 LLM 之外通过护栏来强制执行边界。
人工批准是特性，不是自主性的失败。
可观测性对于调试智能体行为至关重要。
智能体质量应该以任务完成度来衡量，而不仅仅是响应质量。
生产级 AI 智能体本质上是使用强软件工程原则构建的 AI 系统。