智能代理AI解析：从语言模型到自主智能体
详细阐述大语言模型如何通过工具、记忆机制、规划能力、多智能体架构以及MCP集成，逐步演变为智能代理系统。
大型语言模型彻底改变了我们使用软件的方式。
如今，你不必向计算机下达一串严格的指令，而是可以这样表述需求：
“查明这位客户的账单为何上涨，核实合同及使用情况，如果收费有误则创建工单。”
传统应用程序需要通过硬编码的工作流程来处理这些步骤。
而代理系统则能自行判断需要哪些数据、该调用哪些工具、下一步该做什么，以及何时任务完成。
这引出了一个自然的问题：
我们是如何从仅能生成文本的LLM发展到能够完成实际任务的系统？
要理解代理型人工智能，就需要逐阶段追溯这一发展过程。
从LLM到代理
这一发展过程分为几个不同的阶段。
LLM
User → Prompt → LLM → Response
从根本上说，该模型主要根据所给定的上下文来生成输出。
以这样的提示为例：
“解释一下什么是变换器。”
由于必要的知识已经存在于其训练参数中，并与提供的上下文结合在一起，LLM可以直接作出回应。
现在考虑另一个请求：
“班加罗尔当前的天气如何？”
在这种情况下，模型需要最新信息，而这些信息几乎可以肯定不在其训练数据中。这一缺口便引出了下一个阶段。
RAG
User → Retrieve Knowledge → LLM → Response
检索增强生成技术使模型在生成答案之前能够获取外部信息——如公司文档、政策手册、数据库等。
例如：
“我们公司的退款政策是什么？”
系统会获取相关的政策文本，并将其作为提示的一部分输入给大语言模型。
RAG技术解决了知识缺口问题。
然而仍存在一个限制：
当系统需要执行操作而非仅仅回答问题时该怎么办？
使用工具的大语言模型
User → LLM → Tool → Result → LLM → Response
在此阶段，模型具备了与外部系统交互的能力。
以ChatGPT为例：当你询问
“当前的天气如何？”
它可以调用天气工具获取实时数据，而无需完全依赖模型中预置的知识。
这些工具本质上为大型语言模型打开了通向外部世界的大门。
不过这里有一个重要的细微差别需要注意。
如果开发者明确地硬编码了处理流程，例如：
Question → Weather API → Response
各步骤的顺序会提前固定下来。
智能体则将这一理念进一步发展。
智能体
Goal
↓
Reason
↓
Choose Action
↓
Use Tool
↓
Observe Result
↓
Decide Next Action
↓
Repeat
↓
Complete Goal
两者的关键区别在于动态决策能力。工作流会遵循开发者事先设定的路径，而智能体则可以根据在过程中学到的信息自行规划路线。
这种能够动态选择下一步行动的能力，正是定义智能体行为的核心所在。
什么是人工智能智能体？
以下是一个可行的定义：
人工智能智能体是一种由大语言模型驱动的系统，它通过动态选择要执行的操作来追求目标，借助工具和上下文信息，观察这些操作产生的结果，并不断重复这一循环，直到目标达成或出现某种停止条件。
通常，一个智能体包含以下要素：
LLM + Instructions + Tools + State + Memory + Context + Orchestration + Guardrails
大语言模型负责推理和决策。
工具提供具体的功能支持。
状态用于记录当前正在发生的事情。
记忆功能确保时间上的连贯性。
约束规则为行为设定限制。
协调机制将所有这些部分整合在一起。
关键点在于：
智能体不仅仅生成响应，它还可以决定行动方案并付诸实施。
为什么我们需要智能体？
既然你已经有了智能体的明确定义，一个自然的问题随之而来：
为什么还要费心设计这些额外的机制？
事实是，并非每个任务都需要智能体。
当工作流程遵循固定且可预测的顺序时：
Receive request
↓
Validate
↓
Call API
↓
Return result
一个简单的确定性处理流程通常会更简单、更可靠。
现在再对比这样的请求：
“查明本月我们的云服务支出为何上升。”
这种情况下并没有预先确定的路径。系统可能需要按以下步骤处理：
Check billing
↓
Find Azure costs increased
↓
Check deployments
↓
Find new service
↓
Check service usage
↓
Find abnormal traffic
↓
Investigate logs
↓
Generate explanation
注意发生的情况：智能体在完成步骤2之前根本无法知道需要执行步骤5。每个操作的结果都会决定接下来的行动。
这正是代理方法因其复杂性而显得有价值的场景。
一个简单的规则
当步骤顺序事先已知时，使用工作流；而当下一步行动在很大程度上取决于过程中发现的线索时，则应采用代理。
代理循环
一旦将目标交给代理，其内部实际上会发生什么？
每个代理的核心都是代理循环。
┌─────────────┐
│ Goal │
└──────┬──────┘
↓
┌─────────────┐
│ Reason │
└──────┬──────┘
↓
┌─────────────┐
│ Choose Tool │
└──────┬──────┘
↓
┌─────────────┐
│ Execute │
└──────┬──────┘
↓
┌─────────────┐
│ Observe │
└──────┬──────┘
↓
Goal done?
/ \
No Yes
↓ ↓
Reason Finish
其核心模式可概括为：
推理 → 行动 → 观察 → 重复
举例说明：
User:
"Investigate this invoice."
Agent:
"I need invoice details." ↓get_invoice() ↓Tool returns invoice information. ↓Agent:
"The amount looks unusual. I need the contract." ↓get_contract() ↓Contract returned. ↓Agent:
"Now I can compare the two."
在整个交互过程中，随着代理从环境中获取新信息，它会不断修正对当前状况的理解。
实际的生产系统会叠加重试逻辑、验证机制、内存管理、授权检查、可观测性功能以及停止运行的规则——但这个循环才是所有这些功能背后的核心框架。
工具：赋予智能体行动能力
这个循环立刻引出了一个后续问题：
智能体究竟如何与现实世界进行交互并产生影响？
单独的LLM无法直接接入企业的系统。
工具正是让它具备这种连接能力的存在。
例如：
get_customer()
get_invoice()
search_policy()
query_database()
create_ticket()
send_email()
有了工具之后，流程如下所示：
Agent
↓
"I need the invoice"
↓
get_invoice()
↓
Invoice data
↓
Agent
↓
"I need the contract"
↓
get_contract()
↓
Contract data
工具为智能体接入各种外部系统提供了可能，这些系统包括：
- Web API
- 关系型或NoSQL数据库
- 搜索引擎
- 本地或基于云的文件存储系统
- GitHub之类的源代码托管平台
具备这样的能力后，大语言模型的功能本质就发生了变化。它不再仅仅是生成文本。
相反，它充当着通过一系列功能来做出决策的决策者。
但智能体应该记住什么？
一旦智能体开始将多个步骤串联起来，就会出现新的挑战。
想象一个已经执行过这一系列操作的智能体：
Retrieved the invoice
Checked the contract
Queried usage
Found an anomaly
它必须记录下这些结果，以便确定下一步该做什么。
如果同一用户在第二天再次咨询，智能体可能还需要之前对话的上下文信息。
这正是状态与记忆发挥作用的地方。
记忆：为智能体提供连贯性
任何需要在多次交互中工作的智能体都需要某种记忆系统。
将记忆分为两类会更有帮助：
短期记忆
它包含完成当前任务所需的所有信息。
User request + Conversation + Current plan + Tool results
例如，在调查账单问题时，智能体可能会保留如下细节：
Invoice = $14,000
Contract = $10,000
Usage = Normal
这些数据仅与当前次运行相关。
长期记忆
它包含在后续交互中可能派上用场的信息。
例如：
User prefers concise reports.
Customer uses Enterprise contract.
Previous incident was resolved using procedure X.
从这个意义上说，记忆让智能体在**不同任务之间保持连贯性**，而无需每次都从头重新学习一切。
该架构的简化版本如下：
Agent
↓
Memory Manager
/ | \
↓ ↓ ↓
Working Episodic Semantic
Memory Memory Memory
不过，内存并不意味着要无限期地保存所有内容。
生产级系统通常需要：
Store
↓
Index
↓
Retrieve
↓
Rank
↓
Inject relevant memory
目标并非尽可能多地存储信息。
目标是让内存中的内容保持相关性。
规划：决定下一步行动
在此阶段，智能体可以调用工具并调取过往的上下文信息。但涉及众多复杂环节的任务依然具有挑战性。
这时就需要另一项技能了：
规划。
以这个请求为例：
“分析账单上涨的原因并准备一份报告。”
智能体可以将其拆解为：
1. Retrieve current billing
2. Retrieve historical billing
3. Compare services
4. Identify anomalies
5. Investigate causes
6. Verify against policy
7. Generate report
规划可以以明确的形式呈现：
{
"steps": [
"fetch_billing",
"compare_history",
"investigate_anomaly",
"generate_report"
]
}
或者可以是隐式的，即模型在看到每个工具的输出后立即决定下一步行动。
例如：
Get billing
↓
Observe increase
↓
Investigate service
↓
Observe anomaly
↓
Check logs
↓
Generate conclusion
这一点很重要，因为规划不必由专门的规划代理来完成。
一个代理通常既能进行规划，又能亲自执行任务。
从单一代理到多种架构
此时，核心构建模块已经就位：
LLM
+
Tools
+
State
+
Memory
+
Planning
但当问题规模超出单个代理的处理能力时会发生什么？
单一代理并不总是最佳选择。
这便催生了用于构建代理系统的各种架构模式。
A. 单一代理
Agent
/ | \
↓ ↓ ↓
DB API Search
一个代理可同时管理多个工具。
以客户支持场景为例：一名客服人员可能需要同时访问客户记录、账单数据、政策文件以及工单系统。
从这里入手通常是合理的，因为这样能使整体设计保持简洁且易于理解。
B. 顺序工作流
Research
↓
Analysis
↓
Generation
↓
Validation
这种模式适用于步骤顺序事先已知的场景。
例如，文档处理流程往往总是经历相同的阶段：
Extract
↓
Analyze
↓
Generate
↓
Validate
严格来说，这更像是固定的工作流而非完全自主的智能体，不过大语言模型仍然可以处理每个单独阶段的工作。
C. 调度器-工作者模式
Orchestrator
/ | \
↓ ↓ ↓
Market Research Risk Investment
tool tool tool
在这种模式下，调度器会根据实际情况即时决定需要哪些工作者智能体。
以这样的请求为例：
“把我的1000卢比投资到股市里吧”
调度器可能会启动：
Financial Research Worker
Market Research Worker
Risk Analysis Worker
会创建哪些工作进程完全取决于请求的需求。
D. 评估优化器
有时提升智能体输出质量的最有效方法是将任务交给独立的评估步骤来处理。
Generator
↓
Output
↓
Evaluator
↓
Pass ─────→ Done
│
↓
Feedback
↓
Generator
例如：
Generate SQL
↓
Execute SQL
↓
Error
↓
Analyze error
↓
Correct SQL
↓
Execute again
在这种架构中，反馈直接来自智能体所处的环境。
这种方法在那些能够客观检查正确性的领域尤为有效——比如生成的代码、SQL查询、结构化数据或自动化测试等。
E. 多智能体系统
当某个领域变得足够复杂时，将任务分配给多个专业智能体来处理会很有帮助。
Supervisor
/ | \
↓ ↓ ↓
Market Research Risk Investment
Agent Agent Agent
每个智能体在以下方面可能存在差异：
- 指令
- 工具
- 知识
- 职责
- 评估标准
不过，增加智能体数量并不一定意味着改进。
提升智能体数量还会带来：
- 延迟增加
- 成本上升
- 智能体间通信增多
- 状态管理更为复杂
- 故障点增加
- 调试难度加大
一条实用的指导原则：
先从单个智能体开始，只有当专业化分工确实能带来优势时才将其拆分为多个智能体。
将智能体与外部世界连接：MCP
随着智能体功能的扩展，其所需的工具列表可能会迅速膨胀。
想象一下需要与外部系统交互的企业级智能体：
GitHub
Slack
Jira
PostgreSQL
Snowflake
Google Drive
AWS
Azure
Datadog
如果每个人工智能应用都必须为这些系统中的每一个单独构建集成方案，那么整个生态系统就会变成沉重的维护负担。
这正是模型上下文协议（MCP）所要填补的空白。
什么是MCP？
模型上下文协议（MCP）是一种开放型协议，旨在规范人工智能应用与外部工具、资源及提示语之间的交互方式。
简单来说：
MCP充当人工智能应用与外部功能之间的标准接口。
如果没有统一的标准，就会出现以下情况：
Agent
├── Custom GitHub integration
├── Custom Slack integration
├── Custom Database integration
└── Custom Jira integration
采用MCP之后，则会是这样的状况：
AI Application
↓
MCP Client
↓
┌─────────┼─────────┐
↓ ↓ ↓
GitHub Jira DB
MCP Server MCP Server MCP Server
MCP确立了主机-客户端-服务器架构，并提供了标准化的构建模块——即工具、资源及提示语。
MCP 工具
这些是模型被允许调用的操作：
create_issue()
search_repository()
execute_query()
MCP 资源
这些是可以传递给模型的上下文数据：
database schema
repository files
documents
configuration
MCP 提示词
这些是用于常见交互的可重复使用模板：
review_code()
generate_report()
debug_error()
需要记住的关键点是：
MCP 不会创建智能体。
它提供的是一种让智能体或任何 AI 应用接入外部功能的通用方式。MCP 是连接层，而智能体本身仍是决策层。
现在智能体可以行动了——但它能改进吗？
在此阶段，智能体能够：
Understand
↓
Plan
↓
Use tools
↓
Retrieve knowledge
↓
Remember information
↓
Take actions
然而，实际生产系统还会引发另一个问题：
当智能体出错时会发生什么？
假设它总是为某项任务选择错误的工具。
User:
Investigate invoice.
Agent:
Calls get_customer_profile()User:
Wrong tool. You should check invoice_details().
应该立即修复提示词吗？
大概不必。
用户给出的反馈本身可能也是错误的、恶意的、不完整的，或者仅对某一特定情况有效。这就是学习循环存在的理由。
学习循环
一个常见的误解是：
"如果我给智能体反馈，底层的LLM就会自动学习。"
实际上通常并非如此。
学习发生在不同的层面。
第1层——上下文内反馈
Agent:
I'll create a P2 ticket.
User:
No, this should be P1.Agent:
Understood. P1.
在这种情况下，智能体仅会调整其在当前对话中的行为。
底层的模型权重不会被改变。
第二级——记忆
该偏好设置也可以被保存：
User preference:
Incident priority should default to P1 for this category.
后续会话可以重新加载这些已保存的偏好设置。模型本身并未改变——只是智能体有了更多可参考的上下文。
第三级——系统改进
现在考虑一种反复出错的模式。
Production
↓
Trace
↓
Evaluation
↓
Failure detected
↓
Improve prompt/tool/model
↓
Deploy new version
在这一层级进行的修复可以同时涉及流程中的多个部分：
- 提示语的表述
- 工具的描述方式
- 选择路径的路由逻辑
- 检索步骤
- 展示给智能体的示例
- 模型的微调
- 完全更换为另一款模型
这类综合性的改进更接近人们所理解的智能体学习循环。
核心要点如下：
反馈通常应用于评估与系统改进，而非直接融入永久性行为中。
约束机制与安全性
一旦智能体开始采取行动，就会出现新的问题：
如何防止它做出有害行为？
智能体可能连接到数据库、生产基础设施、金融系统或客户数据。
这意味着架构必须对智能体的行为设置限制。
User
↓
Input Guardrail
↓
Agent
↓
Authorization
↓
Tool
↓
External System
↓
Output Validation
约束机制有助于发现以下问题：
- 提示注入
- 不安全的请求
- 敏感信息
- 无效的工具参数
- 政策违规行为
然而，仅靠约束机制还不够。
想象一下智能体试图执行以下操作：
DELETE production_database
你不希望系统依赖模型来进行推理：
“那听起来很危险。”
相反，授权逻辑应每次都以确定性的方式阻止这种行为。
这里的核心原则是：
大语言模型绝不应成为最终的安全屏障。
真正的身份验证、授权、访问控制、输入验证以及标准的应用安全措施都需要围绕智能体来实现。
智能体系统中的提示注入问题
一旦智能体能够从系统外部获取内容，提示注入就会变得尤为严重。
请考虑以下场景：
Agent
↓
Search document
↓
Document contains malicious instruction
↓
Agent interprets it as an instruction
↓
Tool call
↓
Potentially harmful action
需要牢记的关键区别是：
Instructions
≠
Retrieved Data
网页、邮件、支持工单、GitHub 问题或任何其他文档都可能包含看似指令的文本。智能体不应将获取到的所有内容都视为自动可信或权威的。这正是为什么智能体系统需要比普通问答工具更严格的安全措施。
评估：不要仅关注最终答案
一旦智能体被部署，就有一个核心问题需要不断解答：
该智能体是否真正出色地完成了任务？
对于传统软件，常见的问题是：
“输出结果正确吗？”
而对于智能体，还需要询问：
“智能体是否采用了合理的路径来达成目标？”
例如：
Request
↓
Wrong Tool
↓
Wrong Tool
↓
Correct Tool
↓
Correct Answer
即使智能体在获取最终答案的过程中浪费了精力，该答案仍可能是正确的。
正因如此，你应该评估整个过程轨迹，而不仅仅是最终结果：
Input
↓
Plan
↓
Tool Selection
↓
Arguments
↓
Tool Result
↓
Next Decision
↓
Final Answer
在设置评估标准时，需考虑诸多因素，比如任务是否完成、是否选择了正确的工具、参数是否填写正确、获取的上下文质量如何、通往答案的路径是否直接、耗时多少、成本如何、是否有安全规则被违反，以及需要人工干预的频率。
过程轨迹能让你了解智能体是如何得出该结果的，这一点与结果本身同样重要。
可观测性
评估能告诉你系统是否正常运行。而可观测性则能让你明白为何会出现问题。
有用的追踪信息可能如下所示：
Trace: 12345
User Request
↓
LLM Call #1
↓
search_customer()
↓
Result
↓
LLM Call #2
↓
get_invoice()
↓
Result
↓
LLM Call #3
↓
Final Answer
日志应记录每次模型调用、每次工具调用及其参数和结果、操作耗时、令牌使用情况、任何错误或重试行为、触发限制条件的因素，以及最终的处理结果。
如果没有如此详细的记录，几乎无法诊断智能体的行为。
例如，当智能体返回错误答案时，良好的追踪信息应能帮助你确定原因在于：
Wrong retrieval?
↓
Wrong tool?
↓
Wrong tool arguments?
↓
Incorrect reasoning?
↓
Bad final generation?
正因如此，可观测性才成为系统工程的核心部分，而非仅为监控而附加的次要功能。
整合所有要素：生产环境架构
我们逐步在原始大语言模型之上添加了新的功能：
LLM
↓
RAG
↓
Tools
↓
Agent Loop
↓
Memory
↓
Planning
↓
MCP
↓
Learning & Evaluation
↓
Security & Guardrails
一个真正的生产系统会将所有这些组件整合在一起：
USER
│
↓
API / Application
│
↓
Authentication
│
↓
┌─────────────┐
│ Agent │
│ Runtime │
└──────┬──────┘
│
┌────────────┼────────────┐
↓ ↓ ↓
Context Memory Tools
Manager │ │
│ ↓ ↓
↓ Vector DB MCP / APIs
RAG │
│ ┌──────────┼──────────┐
↓ ↓ ↓ ↓
Knowledge GitHub DB SaaS
│
↓
Tool Results
│
↓
Agent
│
┌──────┴──────┐
↓ ↓
Response Action
│
↓
External
System
再将整个系统封装起来：
Security
Guardrails
Observability
Evaluation
Human Approval
Cost Monitoring
正是这一层结构将一个有潜力的原型转变为可在实际生产环境中运行的智能体。
整体视角
回顾整个过程，它始于一个普通的大语言模型：
User → Prompt → LLM → Response
随后问题开始显现。
该模型无法获取外部知识。
于是RAG应运而生。
它需要一种与外部系统交互的方式。
因此我们为它提供了工具。
它需要能够在每一步选择最合适的操作。
于是便引入了智能体循环。
它需要保留之前的上下文信息。
因此我们加入了记忆机制。
更复杂的任务要求将工作分解为更小的步骤。
于是接下来出现了规划功能。
协调多种专业技能则需要更完善的架构。
因此我们引入了不同的智能体架构，在合适的情况下还采用了完整的多智能体系统。
随着集成数量的增加，新的问题出现了。
这时像MCP这样的标准化协议便派上用场，能够提供一致的连接层。
而一旦系统开始自主做出重要决策，它就需要：
安全性 → 评估 → 可观测性 → 反馈 → 持续改进
此时，它已不再仅仅是被提示语包裹的LLM。
它已经变成一个完整的智能体系统。
智能体AI心智模型
从核心层面来看，该模型可以简化为：
GOAL
↓
REASON
↓
PLAN
↓
ACT
↓
OBSERVE
↓
EVALUATE
↓
REMEMBER
│
└────────→ REASON
围绕这个循环的是：
Security
+
Guardrails
+
Authorization
+
Observability
+
Human Oversight
它记录了以下发展过程：
LLM
↓
LLM + RAG
↓
LLM + Tools
↓
Agent
↓
Agent + Memory
↓
Agent + MCP
↓
Multi-Agent / Agentic Systems
↓
Continuous Evaluation & Improvement
但目标并非尽可能提升自主性。
目标应是可靠的自主性。
结论
代理型人工智能常常被简化为一个朗朗上口的公式：
大语言模型 + 工具
不过那仅仅只是起点而已。
生产级代理需要整合以下要素：
- 推理能力，由大语言模型提供支持
- 知识储备，通过RAG技术获取
- 连贯性，依靠内存维持
- 行动执行，通过工具完成
- 连接性，借助MCP等协议实现
- 规划能力，用于处理多步骤问题
- 反馈机制，以推动持续改进
核心架构原则可以简洁地表述为：
在正确性至关重要的情况下，应依赖确定性代码；而将基于大语言模型的推理保留给那些需要灵活性和判断力才能创造价值的场景。
最优秀的智能体系统并非取决于其具备多少功能。
它们的优势在于能够明确知道需要完成的任务，选用合适的工具，掌握必要的上下文信息，检查自己的工作成果，认清自身局限，并懂得何时该暂停或寻求人工协助。
这正是代理型人工智能所代表的真正变革：
从仅能生成答案的系统，转向能够理解目标、依据目标采取行动、从结果中学习，并与人协作完成实际工作的系统。
相关阅读
- ReAct详解：AI代理如何将推理与现实世界行动相结合 — 了解ReAct框架如何通过结合推理与工具使用来为AI代理提供动力，以及它与思维链模型、强化学习模型及传统推理模型的区别。