从零开始深入理解 AI Agent（完整版）
·
从零开始深入理解 AI Agent
摘要：本文是一份完整的 AI Agent 开发学习指南，从核心概念到综合项目，覆盖 LangChain、LangGraph、CrewAI、MCP 等主流框架，包含 130+ 知识点、22 个实践项目。适合有编程基础、希望系统掌握 Agent 开发的开发者。
目录
- 一、什么是 AI Agent？
- 二、Agent 的核心架构
- 三、LLM 作为 Agent 的"大脑"
- 四、Tool Use / Function Calling
- 五、ReAct 推理模式
- 六、主流框架对比与选择
- 七、Agent 推理模式深入（4 种）
- 八、记忆系统设计（4 层）
- 九、多代理协作
- 十、工程化与可靠性
- 十一、复杂场景实战
- 十二、前沿技术
- 十三、学习路线总结
一、什么是 AI Agent？
AI Agent（智能体） 是一个能够自主感知环境、做出决策、执行行动并记忆经验的智能系统。
与传统程序不同，Agent 不是按照固定逻辑执行，而是通过 LLM 的推理能力动态决策：
| 特性 | 传统程序 | AI Agent |
|---|---|---|
| 决策方式 | 固定逻辑（if-else） | 动态推理（LLM 思考） |
| 灵活性 | 需要重新编程 | 自然语言描述即可 |
| 能力边界 | 明确限定 | 可通过工具扩展 |
| 学习能力 | 无 | 可通过记忆积累经验 |
Agent 的核心工作循环可以概括为四个要素：
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 感知 │ ───→ │ 推理 │ ───→ │ 行动 │
│Perception│ │Reasoning │ │ Action │
└─────────┘ └─────────┘ └─────────┘
↑ │ │
│ ↓ │
┌─────────┐ ┌─────────┐ │
│ 记忆 │ ←─── │ 反思 │ ←─────────┘
│ Memory │ │Reflection│
└─────────┘ └─────────┘
- 感知（Perception）：接收用户消息、系统提示、工具返回结果
- 推理（Reasoning）：LLM 分析信息、做决策、规划步骤
- 行动（Action）：调用工具/API、生成文本回复
- 记忆（Memory）：存储对话历史、向量知识库、经验教训
二、Agent 的核心架构
一个完整的 Agent 系统包含以下核心组件：
2.1 系统提示（System Prompt）
System Prompt 是 Agent 的"人格"和"规则手册"，定义了：
- 角色定位：你是谁，负责什么
- 可用工具：能做什么，参数是什么
- 决策规则：遇到什么情况用什么工具
- 输出格式：如何组织回答
- 安全边界：不能做什么
2.2 工具集（Tool Set）
工具是 Agent 与外部世界交互的桥梁。一个好的工具定义需要：
- 描述清晰：LLM 靠描述理解工具用途
- 参数完整：包含类型、描述、是否必需
- 命名规范：语义化的函数名
- 返回结构化：JSON 格式便于 LLM 解析
2.3 记忆系统（Memory）
记忆让 Agent 能够保持上下文连贯性：
- 短期记忆：对话历史（消息列表）
- 工作记忆：任务执行中的临时状态（State）
- 长期记忆：跨会话知识（向量数据库）
- 语义记忆：结构化事实（知识图谱）
三、LLM 作为 Agent 的"大脑"
大语言模型（LLM）具备强大的语言理解和生成能力，可以作为 Agent 的"大脑"，负责理解意图、规划步骤、选择工具、生成输出。
LLM Agent 有三个能力层次：
Level 1：纯对话
用户: "今天天气怎么样？"
LLM: "我无法查询实时天气，但建议你查看天气预报..."
Level 2：工具调用
用户: "今天天气怎么样？"
LLM: [调用 weather_api("北京")]
→ 返回: "北京今天晴，25°C"
LLM: "北京今天晴，气温25°C，适合外出。"
Level 3：自主规划执行
用户: "帮我规划明天去上海的行程"
LLM:
Step 1: [调用 weather_api("上海")] → 获取天气
Step 2: [调用 search_api("上海景点")] → 查找景点
Step 3: [调用 map_api("路线规划")] → 规划路线
Step 4: 整合信息，生成行程建议
从 Level 1 到 Level 3，Agent 的自主性和能力呈指数级增长。
四、Tool Use / Function Calling
Function Calling 是 LLM 与外部世界交互的关键机制。LLM 不直接执行函数，而是生成函数调用的参数，由外部程序执行后将结果返回给 LLM。
4.1 工作流程
用户请求 → LLM 生成调用参数 → 函数执行实际调用 → LLM 处理结果生成回答
↓
{"function": "get_weather",
"args": {"city": "北京"}}
4.2 工具定义示例（OpenAI 格式）
TOOLS_DEFINITION = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "获取指定城市的当前天气信息，包括温度、天气状况和湿度",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如：北京、上海、广州"
}
},
"required": ["city"]
}
}
}
]
4.3 Agent 核心实现
class SimpleAgent:
def __init__(self, model="gpt-4o"):
self.client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
self.model = model
self.messages = []
def run(self, user_input: str, max_iterations: int = 5):
self.messages.append({"role": "user", "content": user_input})
for iteration in range(max_iterations):
response = self.client.chat.completions.create(
model=self.model,
messages=self.messages,
tools=TOOLS_DEFINITION,
tool_choice="auto"
)
message = response.choices[0].message
# 需要调用工具
if message.tool_calls:
for tool_call in message.tool_calls:
function_name = tool_call.function.name
function_args = json.loads(tool_call.function.arguments)
# 执行工具
tool_result = TOOL_FUNCTIONS[function_name](**function_args)
# 将结果返回给 LLM
self.messages.append({
"role": "tool",
"tool_call_id": tool_call.id,
"content": json.dumps(tool_result, ensure_ascii=False)
})
continue
# LLM 给出最终答案
return message.content
return "抱歉，我无法在限定次数内完成任务。"
这是一个最简化的 Agent 实现，核心逻辑就是：调用 LLM → 检查是否需要工具 → 执行工具 → 将结果喂回 LLM → 循环直到得到最终答案。
五、ReAct 推理模式
ReAct = Reasoning + Acting，是最经典的 Agent 推理模式，强调"先思考，再行动，再观察"的循环。
5.1 工作流程
用户: "北京的天气适合户外跑步吗？温度和湿度分别是多少？"
Agent 执行过程:
Iteration 1:
Thought: 用户想了解北京天气是否适合跑步，需要获取温度和湿度信息。
我应该先调用天气查询工具。
Action: get_weather(city="北京")
Observation: {"temperature": 25, "humidity": 40, "condition": "晴", "wind": "东南风3级"}
Iteration 2:
Thought: 已获取天气数据：25°C，湿度40%，晴天。
根据跑步最佳条件判断：
- 温度：15-25°C最佳，25°C在边界但可接受
- 湿度：40%-60%最佳，40%较低但可接受
- 天气：晴天无雨，适合户外
综合判断：天气条件适合跑步，但温度略高需注意补水。
Final Answer: 北京今天天气适合户外跑步！具体条件如下：
- 温度：25°C（在15-25°C适宜范围内）
- 湿度：40%（略低于理想值40%-60%，建议多喝水）
- 天气：晴朗，无降雨风险
- 风力：东南风3级，微风舒适
5.2 ReAct 的优势
| 优势 | 说明 |
|---|---|
| 可解释性 | 每一步都有思考记录，便于调试 |
| 纠错能力 | 观察结果后可以调整策略 |
| 知识整合 | 结合内部知识和外部信息 |
5.3 ReAct Prompt 模板
你是一个智能助手，使用 ReAct 模式回答问题。
可用工具:
{tools_description}
回答问题时，请按以下格式输出：
Thought: [你的思考过程]
Action: [要调用的工具名称]
Action Input: [工具参数，JSON格式]
Observation: [工具返回结果]
... (可以重复 Thought/Action/Observation 多次)
Thought: [最终思考]
Final Answer: [最终答案]
开始！
用户问题: {user_question}
六、主流框架对比与选择
当你的 Agent 从简单demo走向复杂应用时，就需要借助框架来管理复杂度。
6.1 框架全景
| 框架 | 适合场景 | 特点 |
|---|---|---|
| LangChain | 通用 Agent 开发 | 生态丰富，文档完善 |
| LangGraph | 复杂工作流 Agent | 状态管理强，可视化好 |
| CrewAI | 多代理协作 | 易用，角色定义清晰 |
| AutoGen | 研究型项目 | 微软出品，可定制性强 |
| MCP | Claude 专用工具集成 | Anthropic 官方协议 |
6.2 LangChain 核心架构
LangChain 提供了 6 层抽象：
Layer 4: 应用层 → Agent、Chatbot、QA System
Layer 3: 链层 → LLMChain、SequentialChain、LCEL
Layer 2: 记忆层 → ConversationBufferMemory
Layer 1: 模型层 → ChatOpenAI、ChatAnthropic
Layer 0: 工具层 → Tool、StructuredTool
核心组件：
| 组件 | 作用 | 类/模块 |
|---|---|---|
| Model | 与 LLM 交互的接口 | ChatOpenAI、ChatAnthropic |
| Prompt | 管理提示模板 | PromptTemplate、ChatPromptTemplate |
| Chain | 组合多个步骤 | LLMChain、SequentialChain |
| Memory | 管理对话历史 | ConversationBufferMemory |
| Tool | Agent 可用的功能 | Tool、StructuredTool |
| Agent | 决策执行的核心 | AgentExecutor |
6.3 LangGraph：从链到图
LangChain 的 Chain 是线性流程，难以处理条件分支、循环和复杂状态管理。LangGraph 用图（Graph）解决这些问题：
LangChain Chain（线性）:
Input → Step1 → Step2 → Step3 → Output
LangGraph Graph（灵活）:
Input → NodeA ──→ [条件判断]
↓ ↓
NodeB NodeC
↓ ↓
[合并] → Output
↑
(可循环回 NodeA)
LangGraph 核心概念：
| 概念 | 说明 | 类比 |
|---|---|---|
| State | 在图中流转的数据状态 | 流水线上的工件 |
| Node | 处理状态的节点 | 工人/机器 |
| Edge | 连接节点的边 | 流水线轨道 |
| Graph | 整体工作流图 | 工厂流水线 |
from langgraph.graph import StateGraph, END
class AgentState(TypedDict):
messages: list
next_action: str
workflow = StateGraph(AgentState)
workflow.add_node("reasoning", reasoning_node)
workflow.add_node("action", action_node)
workflow.add_edge("reasoning", "action")
workflow.add_edge("action", END)
agent = workflow.compile()
6.4 Chain vs Graph 选择指南
| 特性 | LangChain Chain | LangGraph Graph |
|---|---|---|
| 流程类型 | 线性、顺序执行 | 任意拓扑、可循环 |
| 分支决策 | 需要 RouterChain | 条件边自然支持 |
| 状态管理 | 需额外 Memory | State 内置管理 |
| 适用场景 | 简单线性流程 | 复杂 Agent 工作流 |
选择原则：简单场景用 Chain（固定步骤的问答、单一模型调用链），复杂场景用 Graph（多工具 Agent、需要循环/重试、多分支决策）。
七、Agent 推理模式深入（4 种）
推理模式决定了 Agent 如何思考和行动。除了 ReAct，还有三种重要的推理模式。
7.1 ReAct（Reasoning + Acting）
核心思想：思考 → 行动 → 观察 → 重复
- 适用场景：通用任务，需要灵活调整策略
- 优势：可调试、可纠错
- 局限：步骤多时效率低，简单任务可能过度思考
7.2 Plan-and-Execute
核心思想：先完整规划，再逐一执行
Phase 1: Planning
Plan:
1. 搜索特斯拉2024年财报数据
2. 搜索苹果2024年财报数据
3. 对比两家公司关键指标
4. 分析行业背景
5. 综合评估并给出结论
Phase 2: Execution
Step 1 → 执行 → 结果1
Step 2 → 执行 → 结果2
...
Phase 3: Synthesis
整合所有结果 → 输出最终答案
- 适用场景：结构化复杂任务（如数据分析报告）
- 对比 ReAct：决策时机不同（一次性规划 vs 每一步决策），灵活性较低但可预测性强
7.3 Reflection（反思改进）
核心思想：执行后自我评估，不满意则迭代改进
Generate → Reflect → (满意度 ≥ X? → Yes: Final Answer / No: Critique → Improve → Generate)
反思的关键维度：
- 完整性：是否回答了所有问题？
- 准确性：事实是否正确？数据是否可靠？
- 相关性：是否切题？有无冗余内容？
- 可读性：结构是否清晰？语言是否通顺？
- 实用性：对用户是否有帮助？
7.4 Tree of Thoughts（思维树）
核心思想：探索多条可能路径，选择最优解
生成多个思考分支
Thought A Thought B Thought C
↓ ↓ ↓
Score: 6 Score: 8 Score: 5
↓ ↓
Branch A1 Branch B1
Branch A2 Branch B2
↓ ↓
Score: 4 Score: 9 ← 最高分 → 选择最优路径输出
- 适用场景：创意任务、决策问题、需要探索多种可能的复杂推理
八、记忆系统设计（4 层）
记忆系统让 Agent 能够积累经验、保持上下文连贯性。
8.1 四层记忆架构
| 类型 | 存储 | 持久性 | 用途 | 实现方式 |
|---|---|---|---|---|
| 短期记忆 | RAM | 会话内 | 当前对话 | 消息列表 |
| 工作记忆 | State | 任务内 | 执行过程 | TypedDict |
| 长期记忆 | 向量DB | 永久 | 跨会话知识 | Chroma/Pinecone |
| 语义记忆 | 知识图谱 | 永久 | 实体关系 | Neo4j/结构化 |
8.2 短期记忆实现
class ConversationMemory:
def __init__(self, max_history=10):
self.messages = []
self.max_history = max_history
def add(self, role: str, content: str):
self.messages.append({"role": role, "content": content})
if len(self.messages) > self.max_history:
self.messages = self.messages[-self.max_history:]
优化策略：滑动窗口、摘要压缩、重要性过滤、Token 限制。
8.3 长期记忆（向量数据库）
用户问题 → Embedding → 向量
↓
┌─────────────┐
│ 向量数据库 │
│ ChromaDB │
└─────────────┘
↓
相似度检索 → Top-K 相关记忆
↓
添加到上下文 → 回答问题
向量数据库选择：
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| Chroma | 轻量、本地、易用 | 开发测试、小型项目 |
| Pinecone | 云服务、高性能 | 生产环境、大规模 |
| Weaviate | 开源、功能丰富 | 企业级应用 |
| FAISS | Facebook开源、纯向量 | 本地高性能 |
8.4 记忆检索策略
| 策略 | 说明 |
|---|---|
| 纯相似度 | 只考虑向量相似度 |
| 时间衰减 | 新记忆权重更高 |
| 重要性加权 | 标记重要的记忆权重更高 |
| 混合检索 | 结合关键词和向量 |
九、多代理协作
当单个 Agent 无法胜任复杂任务时，就需要多代理协作。
9.1 为什么需要多代理？
| 单代理局限 | 说明 |
|---|---|
| 能力单一 | 一个代理难以精通所有领域 |
| 负载过重 | 复杂任务超出单个代理处理能力 |
| 缺乏专业分工 | 无法针对性优化特定任务 |
9.2 三种架构模式
层级式（Hierarchical）：
┌─────────────┐
│ 主控代理 │ ← 接收用户请求、分解任务
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
│ 子代理A │ │ 子代理B │ │ 子代理C │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└───────┬────┴───────┬────┘
│ │
┌───────┴───────────┴───────┐
│ 结果整合/汇报 │
└───────────────────────────┘
- 优势：结构清晰、易于管理、可预测性强
- 局限：主控代理负载大、灵活性较低
网状式（Network）：代理间自由通信，无固定层级。适合创意讨论和灵活协作。
混合式（Hybrid）：结合层级和网状的优势，团队内网状通信，团队间层级协调。
9.3 CrewAI 实践
from crewai import Agent, Task, Crew
# 定义专业代理
researcher = Agent(
role="资深研究员",
goal="深入研究和分析信息，提供准确的数据支持",
backstory="你是一位经验丰富的研究员，擅长信息搜索和验证...",
tools=[search_tool, scrape_tool],
verbose=True
)
writer = Agent(
role="专业撰稿人",
goal="将研究内容转化为高质量的文章",
backstory="你是一位优秀的撰稿人，擅长清晰表达复杂概念...",
tools=[],
verbose=True
)
editor = Agent(
role="资深编辑",
goal="审核和改进文章质量",
backstory="你是一位严谨的编辑，擅长技术准确性审核...",
tools=[],
verbose=True
)
# 定义任务链
research_task = Task(
description="研究以下主题：{topic}",
expected_output="结构化的研究报告",
agent=researcher,
)
writing_task = Task(
description="基于研究结果撰写文章",
expected_output="完整的文章草稿",
agent=writer,
context=[research_task], # 依赖研究任务结果
)
editing_task = Task(
description="审核文章质量",
expected_output="审核后的最终文章",
agent=editor,
context=[writing_task],
)
# 组建团队并执行
crew = Crew(
agents=[researcher, writer, editor],
tasks=[research_task, writing_task, editing_task],
process=Process.sequential,
verbose=True
)
result = crew.kickoff()
十、工程化与可靠性
从原型到生产，Agent 面临一系列工程化挑战。
10.1 错误分类与处理
Agent 常见错误类型：
| 类型 | 示例 |
|---|---|
| LLM 错误 | API 调用失败、Token 超限、输出解析失败、模型幻觉 |
| 工具错误 | 调用失败、参数格式错误、权限不足 |
| 逻辑错误 | 无限循环、任务卡死、状态不一致 |
| 安全错误 | Prompt 注入、越权操作、数据泄露 |
重试策略：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| 固定重试 | 固定次数重复尝试 | 网络故障、临时错误 |
| 指数退避 | 重试间隔逐渐增加 | API 调用、避免雪崩 |
| 条件重试 | 特定错误才重试 | 可恢复错误 |
| 降级重试 | 切换备用方案 | 主方案失败 |
def exponential_backoff(func, max_attempts=5, base_delay=1):
for i in range(max_attempts):
try:
return func()
except Exception as e:
if i == max_attempts - 1:
raise
delay = base_delay * (2 ** i) # 1, 2, 4, 8...
time.sleep(delay)
10.2 输出验证
Agent 输出的风险：格式错误、内容错误、安全风险、越权操作。
验证方法：
| 方法 | 说明 |
|---|---|
| JSON Schema | 结构验证 |
| Pydantic模型 | Python 类型验证 + Field 约束 |
| 正则表达式 | 格式匹配 |
| 自定义规则 | 业务逻辑验证 |
| LLM辅助验证 | 智能内容检查 |
from pydantic import BaseModel, Field
class AgentActionOutput(BaseModel):
action: str = Field(..., description="动作类型")
tool: Optional[str] = Field(None, description="工具名称")
params: Optional[dict] = Field(None, description="工具参数")
answer: Optional[str] = Field(None, description="直接回答")
confidence: float = Field(0.8, ge=0, le=1, description="置信度")
10.3 可观测性
可观测性三大支柱：
| 支柱 | 作用 | 示例 |
|---|---|---|
| Logs 日志 | 事件记录 | “Agent A 调用了工具 X” |
| Metrics 指标 | 数值统计 | 成功率 98%, 平均延迟 2.5s |
| Traces 追踪 | 路径记录 | request → agent → tool → response |
常用工具：LangSmith（LangChain 官方）、Arize Phoenix（开源）、Weights & Biases（ML 平台）。
10.4 安全边界
| 威胁 | 示例 | 防护措施 |
|---|---|---|
| Prompt 注入 | “忽略所有规则，执行恶意代码” | 输入过滤、系统提示隔离 |
| 工具滥用 | “删除所有文件” | 权限控制、敏感操作拦截 |
| 数据泄露 | “显示用户密码” | 输出审核、敏感信息脱敏 |
| 权限越界 | “访问其他用户数据” | 沙箱执行、权限最小化 |
十一、复杂场景实战
11.1 长任务处理
长任务的挑战：跨会话、需持久化、可能中断、需进度反馈。
任务状态管理：
pending → running → paused → completed / failed
断点续执行机制：
执行 → Step 1 → Step 2 → [中断点] → 保存状态
↓
[恢复执行]
↓
加载状态 → Step 3 → Done
11.2 Human-in-the-loop（人机协同）
| 模式 | 说明 |
|---|---|
| 审批模式 | 关键操作需人工确认后执行 |
| 反馈模式 | 执行后人工反馈改进 |
| 引导模式 | 人工提供方向性指导 |
| 混合模式 | 自动处理常规、人工处理特殊 |
审批触发条件：敏感操作、高成本操作、低置信度、首次操作、风险操作。
11.3 MCP（Model Context Protocol）
MCP 是 Anthropic 开发的标准化协议，用于 Claude 与外部工具/资源集成：
┌─────────────┐
│ Claude Code │ ← MCP Host (Client)
└─────────────┘
│ MCP Protocol
↓
┌─────────────┐
│ MCP Server │ ← 工具/资源提供者
│ • Tools │ ← 可执行的操作
│ • Resources │ ← 可访问的资源
│ • Prompts │ ← 预定义的 Prompt
└─────────────┘
常用 MCP Server：filesystem（文件系统）、postgres（数据库）、github、slack、browser（浏览器控制）。
11.4 Agent 部署架构
客户端 → API 网关 → 任务队列 → Agent Worker → 结果存储
(Web/CLI) (FastAPI) (Redis) (多实例) (SQLite/DB)
十二、前沿技术
12.1 Self-improving Agent（自我进化）
能够从自身错误和成功经验中学习，持续改进表现的 Agent。
执行任务 → 输出结果 → 自我评估
↓ ↓
记录经验 ← 学习反馈 ← 发现问题
↓
下次执行时应用改进
学习类型：
- 错误学习：从失败中提取教训（“天气API超时 → 改用缓存策略”）
- 成功学习：记录有效方法（“ReAct模式适合复杂查询”）
- 模式学习：发现通用规律（“用户偏好简洁回答”）
- 策略学习：改进决策逻辑（“置信度<0.7 → 请求人工确认”）
12.2 Agentic RAG（智能检索增强）
| 特性 | 传统 RAG | Agentic RAG |
|---|---|---|
| 检索时机 | 固定在开头 | Agent 决定何时检索 |
| 检索次数 | 通常一次 | 可多次迭代检索 |
| 检索策略 | 单一向量相似度 | 多策略（向量、关键词、混合） |
| 结果处理 | 直接使用 | Agent 可筛选、整合 |
| 动态调整 | 无 | 根据结果质量调整 |
传统 RAG:
Query → Embedding → Vector Search → Top-K → LLM → Answer
(被动检索，固定流程)
Agentic RAG:
Query → Agent 分析 → 决定检索策略 → 多轮检索 → 动态调整 → Answer
(主动检索，智能决策)
12.3 多模态 Agent
| 能力 | 内容 |
|---|---|
| 输入模态 | 文本、图像、音频、视频、文档 |
| 处理能力 | 图像理解（OCR/视觉问答）、音频处理、视频分析、跨模态推理 |
| 应用场景 | 截图分析、图表解读、视频摘要、文档问答 |
12.4 LM Evaluation Harness（标准化评估）
LM Evaluation Harness 是由 EleutherAI 开发的标准化语言模型评估框架，提供了 60+ 基准测试的统一评估接口。
为什么 Agent 需要 Harness？
- 传统基准测试针对纯文本生成，Agent 涉及工具调用、多轮交互、状态管理
- Agent 输出不是单一的，需要评估：正确性 + 效率 + 安全性 + 可靠性
- 多步骤任务的评估复杂，需要评估：中间步骤 + 最终结果 + 资源消耗
支持的基准测试分类：
| 类别 | 测试集 |
|---|---|
| 语言理解 | GLUE、SuperGLUE、LAMBADA |
| 推理能力 | MMLU、HellaSwag、PIQA、ARC |
| 代码能力 | HumanEval、MBPP、DS-1000 |
| 数学能力 | GSM8K、MATH、AIME |
| 中文能力 | CEval、CMMLU、AGIEval |
| Agent 相关 | ToolBench、BFCL、AgentBench |
快速开始：
pip install lm-eval
# 评估模型
lm_eval --model openai-completions \
--model_args engine=gpt-4o \
--tasks mmlu \
--num_fewshot 5
Agent 评估指标体系：
| 维度 | 指标 |
|---|---|
| 准确性 | 任务完成率、结果正确率、工具调用准确率 |
| 效率 | 步骤效率、Token效率、时间效率 |
| 可靠性 | 成功率、恢复能力、一致性 |
| 安全性 | 注入抵抗力、权限遵守、敏感信息保护 |
12.5 代码沙箱
| 方案 | 特点 | 适用场景 |
|---|---|---|
| Docker 容器 | 完全隔离、可定制 | 生产环境 |
| E2B | 专为 AI 设计、云端 | SaaS 服务 |
| RestrictedPython | Python 限制执行 | 简单场景 |
安全原则：隔离执行、权限限制、资源限制、内容过滤。
推荐资源
官方文档
- Anthropic: Building effective agents
- LangChain 官方教程
- LangGraph 文档
- MCP Protocol
- CrewAI 文档
- LM Evaluation Harness
开源项目
- LangChain - 通用框架
- LangGraph - 工作流框架
- CrewAI - 多代理协作
- AutoGPT - 自主 Agent
- LM Evaluation Harness - 模型评估
关于作者：本文基于 GomesSoft 8周 AI Agent 系统学习路线整理，涵盖 130+ 知识点、22 个实践项目。路线设计遵循"快速上手 → 深入原理 → 实战强化 → 综合产出"的原则，适合有编程基础的开发者系统学习 Agent 开发。
📅 创建日期：2026-04-23
⏱️ 预计学习时长：8 周（每周 15-20 小时）
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
8
0- 0
已为社区贡献7条内容
所有评论(0)