AI Agent 技术知多少
·
AI Agent 技术
0. 定位声明
适用版本：不依赖特定软件版本；示例代码基于 Python 3.11+、LangChain 0.2+、OpenAI API (2024 版)
前置知识：
- 了解大语言模型（LLM）基本原理（Transformer、Prompt/Response 范式）
- 理解 REST API 基础调用
- 具备 Python 基础编程能力
不适用范围：
- 本文不覆盖模型训练与微调（LoRA、RLHF）
- 不适用于无 LLM 的传统规则 Agent（专家系统）
- 不涵盖多模态 Agent 的视觉感知子系统细节
1. 一句话本质
不含术语版：
普通 AI 只能回答你的问题；AI Agent 更像一个能自己"做事"的助手——你告诉它一个目标，它会自己想步骤、自己调工具、自己检查结果，直到把任务完成。
稍正式版：
AI Agent 是以大语言模型为"大脑"，通过感知环境、规划行动、调用外部工具、反馈结果来迭代完成复杂任务的自主系统。它把 LLM 从"问答机器"升级为"任务执行者"。
2. 背景与根本矛盾
2.1 历史背景
| 时期 | 技术状态 | 核心痛点 |
|---|---|---|
| 2020 前 | GPT-2 时代，LLM 只能生成文本 | 无法与外部系统交互，知识有截止日期 |
| 2022–2023 | ChatGPT 爆发，Prompt Engineering 兴起 | 单轮问答无法完成多步复杂任务 |
| 2023–2024 | Function Calling、ReAct 论文、AutoGPT 出现 | 探索让 LLM "主动行动"的可能性 |
| 2024–今 | Agentic Framework 成熟（LangGraph、CrewAI、AutoGen） | 多 Agent 协作、长任务可靠性成为核心挑战 |
诞生的根本驱动：LLM 拥有强大的推理能力，但被困在"输入→输出"的单次调用范式中。现实任务往往需要多步、动态决策和与外部世界交互——Agent 架构正是为了打破这一封闭性而生。
2.2 根本矛盾（核心 Trade-off）
自主性（Autonomy） vs 可靠性（Reliability）
- 自主性越高：Agent 可以自己决策、自己规划，减少人工干预，但错误会级联放大，难以 debug，行为不可预测
- 可靠性越高：需要更多人工检查点（Human-in-the-loop），更保守的执行策略，但会牺牲自动化程度
其他关键 Trade-off：
| 决策 | 左侧选择 | 右侧选择 |
|---|---|---|
| 工具数量 | 工具越多，能力越强 | 工具越多，LLM 选错工具概率越高 |
| 记忆方式 | 全上下文（精确但昂贵） | 摘要压缩（便宜但可能丢失关键信息） |
| 单 Agent vs 多 Agent | 简单可控 | 强大但协调复杂度指数增长 |
| 规划策略 | 预先规划（Plan-then-Execute） | 边做边规划（ReAct：动态调整） |
3. 核心概念与领域模型
3.1 关键术语表
| 术语 | 费曼式解释 | 正式定义 |
|---|---|---|
| Agent | 一个"有目标、会行动、能反省"的 AI 程序 | 以 LLM 为核心推理引擎，能感知状态、选择动作、执行工具并迭代完成任务的自主系统 |
| Tool（工具） | Agent 能调用的"手"，比如能搜索网页、写代码、查数据库 | Agent 可调用的外部函数或 API，用于获取信息或执行操作 |
| Memory（记忆） | Agent 的"笔记本"，记住之前说过什么、做过什么 | 存储 Agent 历史交互信息的机制，分为短期（上下文窗口）和长期（向量数据库） |
| Planning（规划） | Agent 把大目标拆成小步骤的能力 | LLM 将复杂任务分解为可执行子任务序列的推理过程 |
| ReAct | "想一步、做一步、看结果、再想"的循环 | Reasoning + Acting 的交替模式：Thought→Action→Observation 循环 |
| Orchestrator | 多 Agent 场景中的"项目经理" | 负责分配任务给其他 Agent 并汇总结果的协调 Agent |
| Human-in-the-loop | 让人在关键步骤插手确认 | 在 Agent 执行过程中设置人工审批节点以保证安全性 |
3.2 领域模型
┌──────────────────────────────────────────────────────────┐
│ AI Agent │
│ │
│ ┌────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ Perceive │───▶│ Planning │───▶│ Act │ │
│ │ (感知) │ │ (规划推理) │ │ (执行工具) │ │
│ └────────────┘ └──────────────┘ └─────────────┘ │
│ ▲ │ │
│ │ Observe (观察) │ │
│ └──────────────────────────────────────┘ │
│ │
│ ┌─────────────────────┐ ┌────────────────────────────┐ │
│ │ Memory（记忆） │ │ Tools（工具库） │ │
│ │ - Short-term:上下文│ │ - 搜索引擎 - 代码执行 │ │
│ │ - Long-term:向量DB │ │ - 数据库 - 文件系统 │ │
│ └─────────────────────┘ │ - 外部 API - 浏览器 │ │
│ └────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
核心流程（ReAct 模式）：
用户输入目标
│
▼
[Thought] LLM 推理：当前状态是什么？下一步应该做什么？
│
▼
[Action] 选择工具 + 生成参数
│
▼
[Observation] 执行工具，获取结果
│
▼
判断：任务完成？ ──是──▶ 返回最终答案
│否
└──────────────▶ 继续下一轮 Thought
4. 对比与选型决策
4.1 主流 Agent 框架横向对比
| 维度 | LangChain/LangGraph | AutoGen (Microsoft) | CrewAI | OpenAI Assistants |
|---|---|---|---|---|
| 定位 | 通用 Agent 编排框架 | 多 Agent 对话框架 | 角色扮演多 Agent | 平台托管 Agent |
| 上手难度 | 中（概念多） | 中高（需理解对话协议） | 低（角色定义直观） | 低（托管，API 简单） |
| 灵活性 | 高（图结构可定制） | 高 | 中 | 低（受平台限制） |
| 生产成熟度 | 高（社区最大） | 中高 | 中 | 高（但绑定 OpenAI） |
| 多 Agent 支持 | ✅ LangGraph | ✅ 原生支持 | ✅ 核心特性 | ⚠️ 有限 |
| 长任务可靠性 | 中（需自行处理错误重试） | 中 | 中 | 中 |
| 向量记忆集成 | ✅ 原生 | 需手动配置 | 需手动配置 | ✅ 内置 |
| 开源 | ✅ | ✅ | ✅ | ❌ 商业托管 |
4.2 选型决策树
你的需求是什么？
│
├── 只需要简单的工具调用（搜索+回答）
│ └──▶ OpenAI Assistants API 或 LangChain Agent（最快上手）
│
├── 需要多个 AI 角色协作（如：研究员+写手+审核员）
│ ├── 任务流程固定 ──▶ CrewAI（角色定义直观）
│ └── 任务流程动态 ──▶ AutoGen 或 LangGraph
│
├── 需要高度定制的状态机/工作流
│ └──▶ LangGraph（图结构，精确控制节点跳转）
│
├── 不想管基础设施，快速 POC
│ └──▶ OpenAI Assistants API（但要接受厂商锁定）
│
└── 企业级生产，需要最大灵活性和可观测性
└──▶ LangGraph + LangSmith（可观测）
什么时候不用 Agent 架构：
- 任务是固定的单步问答 → 直接用 LLM API，Agent 架构增加无谓复杂度
- 对响应延迟要求 < 1s → Agent 多步推理通常需要 3-30s
- 成本敏感场景 → Agent 每次任务可能消耗 5-50 次 LLM 调用
4.3 技术栈位置
用户界面层
↕
Agent Orchestration Layer（LangGraph / CrewAI） ◀── 本文主题
↕ ↕
LLM Provider Tool Ecosystem
(OpenAI/Claude (搜索/代码执行/
/本地模型) 数据库/外部API)
↕
Memory Layer（向量数据库：Pinecone/Chroma/pgvector）
5. 工作原理与实现机制
5.1 静态结构：核心组件
AI Agent 系统
├── LLM Core（推理核心）
│ ├── System Prompt（角色定义 + 工具说明）
│ └── Context Window（工作记忆，有限容量：4K-128K tokens）
│
├── Tool Registry（工具注册表）
│ ├── Tool 定义（名称、描述、参数 Schema）
│ └── Tool 执行器（实际调用逻辑）
│
├── Memory System（记忆系统）
│ ├── Short-term：对话历史（存于上下文窗口）
│ ├── Long-term：向量数据库（语义检索历史信息）
│ └── Episodic：任务执行记录（用于反思）
│
├── Planning Module（规划模块）
│ ├── Task Decomposition（任务分解）
│ └── Step Sequencing（步骤排序）
│
└── Execution Loop（执行循环）
├── Action Parser（解析 LLM 输出的工具调用）
├── Tool Executor（执行工具并捕获异常）
└── Observation Formatter（格式化结果回传 LLM）
为什么用 JSON Schema 定义工具？
LLM 需要"看懂"工具的作用和参数格式，JSON Schema 提供了结构化、机器可读的描述，让 LLM 能生成正确的函数调用参数。相比自然语言描述，Schema 约束显著降低 LLM 参数格式错误率。
5.2 动态行为：关键流程
ReAct 单步执行时序：
时间轴 →
User Agent Core LLM Tool
│ │ │ │
│──[Task]───────▶│ │ │
│ │──[Prompt]────▶│ │
│ │ │──[推理] │
│ │ │ Thought:... │
│ │ │ Action: search │
│ │ │ Input: "..." │
│ │◀──[Response]──│ │
│ │──[Parse Tool Call] │
│ │────────────────────[call]──────▶│
│ │◀───────────────────[result]─────│
│ │──[Observation=result]──▶│ │
│ │ │──[继续推理] │
│ │ │ 判断是否完成 │
│ │◀──[Final Answer]──│ │
│◀──[Answer]─────│ │ │
多 Agent 协作流程（Orchestrator 模式）：
用户目标
│
▼
Orchestrator Agent
├──▶ Research Agent（负责信息收集）
│ └── 使用：搜索工具、爬虫工具
├──▶ Analysis Agent（负责数据分析）
│ └── 使用：代码执行工具、计算工具
└──▶ Writer Agent（负责生成报告）
└── 使用：文件工具
│
▼
汇总结果 → 返回用户
5.3 关键设计决策
决策 1：为什么用 ReAct 而不是纯 Chain-of-Thought？
- CoT（思维链）：LLM 一次性生成完整推理链，无法在过程中获取外部信息
- ReAct：每步推理后可以执行工具，将真实世界反馈注入后续推理
- 代价：多次 LLM 调用，延迟增加；收益：任务准确率对于需要外部信息的任务提升 20-40%（⚠️ 存疑：数值来自 ReAct 原论文，实际场景差异较大）
决策 2：工具描述的重要性超过工具数量
- 错误认知：工具越多 Agent 越强大
- 实际：工具描述模糊时，LLM 选错工具概率随工具数量线性增长
- 生产经验：单个 Agent 工具数量建议控制在 5-10 个以内，超过后需要工具路由层
决策 3：记忆的层级设计
- 全量历史放上下文：精确但 token 消耗随对话线性增长，成本不可控
- 只用摘要：便宜但关键细节丢失导致任务失败
- 最优实践：近期 N 轮保留完整（Short-term）+ 重要事实存向量库（Long-term）+ 摘要压缩中间历史
6. 高可靠性保障
6.1 高可用机制
Agent 执行的主要失败模式及应对：
| 失败类型 | 发生原因 | 应对机制 |
|---|---|---|
| LLM 幻觉 | 模型生成错误的工具参数或虚假结论 | 工具参数 Schema 强校验 + 结果验证 Agent |
| 工具调用失败 | 外部 API 超时或错误 | 指数退避重试（最多 3 次，间隔 1s/2s/4s） |
| 无限循环 | Agent 陷入循环无法完成任务 | 设置最大步骤数（通常 15-30 步）硬截断 |
| 上下文溢出 | 长任务超出 context window | 动态摘要压缩 + 滑动窗口 |
| 工具选择错误 | LLM 选了错误工具 | 工具描述优化 + 错误结果触发重规划 |
6.2 容灾策略
# 生产级 Agent 重试配置示例（Python 3.11+，LangChain 0.2+）
from tenacity import retry, stop_after_attempt, wait_exponential
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=1, max=10),
reraise=True
)
async def execute_tool_with_retry(tool, input_data):
"""带指数退避重试的工具执行"""
return await tool.arun(input_data)
降级策略：
- 主 LLM 不可用时降级到备用模型（如 GPT-4o → GPT-4o-mini）
- 工具调用失败时，允许 Agent 仅凭已有知识给出"最佳努力"答案，并标注不确定性
6.3 可观测性：关键监控指标
| 指标 | 说明 | 正常阈值 | 告警阈值 |
|---|---|---|---|
agent_steps_per_task |
每任务平均步骤数 | 3-8 步 | > 20 步（可能陷入循环） |
task_success_rate |
任务成功完成率 | > 85% | < 70% |
tool_call_error_rate |
工具调用失败率 | < 5% | > 15% |
avg_latency_per_task |
任务平均延迟 | 5-15s | > 60s |
llm_token_per_task |
每任务消耗 token | 依任务类型 | 超出预算 2x |
context_window_usage |
上下文使用率 | < 70% | > 90%（临近溢出） |
**推荐观测工具：**LangSmith（LangChain 生态）、Langfuse（开源）、Arize Phoenix
6.4 SLA 保障手段
- Human-in-the-loop 检查点：对于不可逆操作（删除数据、发邮件、调用付费 API）必须设置人工确认
- Sandbox 执行：代码执行类工具在隔离容器中运行，防止系统破坏
- 输出验证层：关键任务输出由另一个验证 Agent 或规则引擎进行二次检查
7. 使用实践与故障手册
7.1 典型生产级实现
基础 ReAct Agent（Python 3.11+，LangChain 0.2+，OpenAI API）：
from langchain_openai import ChatOpenAI
from langchain.agents import AgentExecutor, create_react_agent
from langchain_community.tools import DuckDuckGoSearchRun
from langchain_core.prompts import PromptTemplate
from langchain_core.tools import tool
# 1. 定义工具
@tool
def search_web(query: str) -> str:
"""搜索互联网获取最新信息。输入搜索关键词。"""
return DuckDuckGoSearchRun().run(query)
@tool
def calculate(expression: str) -> str:
"""计算数学表达式。输入合法的 Python 数学表达式，如 '2 + 3 * 4'"""
try:
result = eval(expression, {"__builtins__": {}}) # 生产中应用沙箱
return str(result)
except Exception as e:
return f"计算错误: {e}"
# 2. 配置 LLM
llm = ChatOpenAI(
model="gpt-4o", # 推荐：推理能力强
temperature=0, # 关键：设为 0 保证确定性输出
timeout=30, # 超时保护
max_retries=2,
)
# 3. 构建 Agent
tools = [search_web, calculate]
prompt = PromptTemplate.from_template("""
你是一个有用的助手。你可以使用以下工具：
{tools}
工具名称列表：{tool_names}
使用以下格式：
Thought: 我需要思考该怎么做
Action: 工具名称
Action Input: 工具输入
Observation: 工具返回结果
...（重复以上步骤）
Thought: 我现在知道最终答案了
Final Answer: 最终答案
开始！
问题：{input}
{agent_scratchpad}
""")
agent = create_react_agent(llm, tools, prompt)
# 4. 生产级执行器配置
executor = AgentExecutor(
agent=agent,
tools=tools,
max_iterations=15, # 防止无限循环
max_execution_time=120, # 秒，任务超时保护
handle_parsing_errors=True, # 容错：LLM 输出格式错误时继续
verbose=True, # 生产中可改为 False，接 LangSmith
)
# 5. 执行
result = executor.invoke({"input": "今天北京的天气怎么样？用摄氏度告诉我温度。"})
print(result["output"])
关键配置项说明：
| 参数 | 默认值 | 推荐生产值 | 风险说明 |
|---|---|---|---|
temperature |
1.0 | 0 | 过高导致工具参数不确定，Agent 行为随机 |
max_iterations |
15 | 10-20 | 过低任务无法完成；过高成本和延迟增加 |
max_execution_time |
None | 60-300s | 不设置可能导致任务挂起消耗大量资源 |
handle_parsing_errors |
False | True | 不处理则 LLM 格式错误直接抛异常 |
7.2 故障模式手册
【故障 1：Agent 无限循环】
- 现象：Agent 步骤数持续增加，任务无法结束，token 消耗异常
- 根本原因：工具始终返回不符合预期的结果，或任务目标表达模糊
- 预防措施：设置 max_iterations（建议 15-20）；任务描述要具体明确
- 应急处理：增加强制终止逻辑；在 System Prompt 中加入"若 5 步内无法推进，请主动声明无法完成"
【故障 2：LLM 幻觉导致错误工具参数】
- 现象：工具调用返回参数校验错误，或工具接收到无意义输入
- 根本原因：LLM 未能正确理解工具的参数要求
- 预防措施：工具 docstring 用明确格式要求描述参数；使用 Pydantic 做参数 Schema 强校验
- 应急处理：开启 handle_parsing_errors=True；在 Observation 中包含报错信息让 Agent 自我修正
【故障 3：上下文窗口溢出】
- 现象：长任务报 context length exceeded 错误，任务中断
- 根本原因：对话历史 + 工具输出 + Prompt 总 token 超过模型限制
- 预防措施：工具输出截断（如搜索结果限制 500 字符）；启用记忆摘要压缩
- 应急处理：清理中间 Observation 记录，只保留最终结论
【故障 4：工具调用成本失控】
- 现象：单次任务消耗 token 超预算 5x 以上
- 根本原因：Agent 反复调用高 token 消耗工具，或任务拆解粒度过细
- 预防措施：设置 token budget 硬限制；监控 llm_token_per_task 指标
- 应急处理：降级到小模型处理；限制每类工具单任务调用次数上限
【故障 5：多 Agent 死锁/循环依赖】
- 现象：Orchestrator 等待 Sub-agent，Sub-agent 等待 Orchestrator
- 根本原因：Agent 间任务依赖设计有环路；缺乏超时机制
- 预防措施：任务依赖 DAG 化，确保无环；所有 Agent 调用设置超时
- 应急处理：引入任务 ID 追踪，超时强制中断并上报失败
7.3 边界条件与局限性
- 任务步骤 > 20 步时：成功率显著下降（每步误差累积），建议拆分为子任务
- 工具返回非结构化大文本（> 2000 字符）时：LLM 关键信息提取能力下降，建议在工具层做摘要预处理
- 并发任务共享状态时：需要外部状态管理（如 Redis），Agent 框架本身通常不提供分布式状态支持
- 低质量工具描述是最常见的生产问题：工具描述不清导致的选择错误占 Agent 失败案例的约 40%（⚠️ 存疑：来自社区经验，无严谨统计数据）
- Agent 不适合强一致性要求的场景：如银行转账，Agent 的非确定性不可接受
8. 性能调优指南
8.1 性能瓶颈定位
延迟分解：
总延迟 = LLM 推理时间 × 步骤数 + 工具执行时间 × 步骤数 + 网络 RTT × 调用次数
通常瓶颈层：
├── LLM 推理慢 → 换小模型/减少 prompt 长度
├── 工具执行慢 → 工具异步并行化
├── 步骤数多 → 优化 prompt 提升单步决策质量，或预规划减少探索步
└── 上下文过长 → 压缩历史，减少 token 数
8.2 调优步骤（按优先级）
P0：减少 LLM 调用次数（最高收益）
- 目标：从平均 10 步 → 6 步完成相同任务
- 方法：在 System Prompt 中给出任务分解示例（few-shot），引导 Agent 更高效规划
- 验证：统计
agent_steps_per_task均值变化
P1：工具并行执行
- 目标：将串行工具调用改为并行，延迟从 15s → 8s
- 方法：识别无依赖的工具调用，使用
asyncio.gather并发执行 - 验证：对比并行前后的 P90 延迟
P2：模型分级
- 目标：降低成本 50% 同时保持 85%+ 成功率
- 方法：简单步骤（格式化、摘要）用小模型（GPT-4o-mini），复杂推理步骤用大模型（GPT-4o）
- 验证：按任务类型统计成功率和成本的 Pareto 曲线
P3：Prompt 长度优化
- 目标：System Prompt < 500 tokens，工具描述精简至核心信息
- 方法：删除冗余说明，用 Schema 替代自然语言描述工具参数
- 验证：token 消耗对比（使用 tiktoken 计数）
8.3 调优参数速查
| 参数/策略 | 默认/常见值 | 推荐优化值 | 调整风险 |
|---|---|---|---|
| LLM temperature | 1.0 | 0（确定性任务） | 设太低影响创造性任务 |
| max_iterations | 15 | 10-15 | 过低导致复杂任务截断 |
| 工具返回截断长度 | 无限制 | 500-1000 chars | 过短丢失关键信息 |
| 并发工具调用 | 串行 | asyncio 并行 | 需确认工具是否线程安全 |
| 上下文保留轮数 | 全量 | 最近 5-10 轮 | 过少丢失任务上下文 |
9. 演进方向与未来趋势
9.1 长任务可靠性（Long-Horizon Reliability）
当前 Agent 在超过 20 步的任务中成功率急剧下降。社区正在探索的方向：
- Memory OS：将 Agent 记忆系统类比操作系统内存管理（Working Memory / Episodic Memory / Semantic Memory 分层）
- 任务检查点（Checkpointing）：LangGraph 已支持持久化 Agent 状态到数据库，允许中断后恢复
- Tree-of-Thought + MCTS：在规划层引入树搜索，避免错误路径的代价
9.2 多 Agent 系统（Multi-Agent Systems）
为什么重要： 单 Agent 的上下文窗口和能力有限，复杂任务需要多专业 Agent 协作。
近期进展：
- Google 的 Agent2Agent（A2A）协议（2025 年发布）：定义 Agent 间通信标准，类似 Agent 的"HTTP"
- Anthropic 的 Model Context Protocol（MCP）：标准化工具调用接口，降低工具集成成本
- 对使用者的影响：未来 Agent 将像微服务一样，可以跨框架、跨厂商互相调用，减少厂商锁定
9.3 Agent 安全（Agentic Security）
随着 Agent 权限增大（可以写文件、发邮件、调用生产 API），提示注入攻击（Prompt Injection） 成为核心安全威胁：恶意网页内容可能诱导 Agent 执行攻击者期望的操作。
趋势：Agent 沙箱化、权限最小化原则、工具调用审计日志，预计 2025-2026 年会出现专门的 Agent 安全标准。
10. 面试高频题
【基础理解层】
Q：什么是 AI Agent？它和普通 LLM 调用有什么区别？
A：普通 LLM 调用是单次"输入→输出"；Agent 是以 LLM 为核心，能多轮迭代、
调用外部工具、感知反馈结果，并持续执行直到完成复杂目标的自主系统。
关键区别：Agent 有"行动-观察"循环，能与外部世界交互。
考察意图：考察对 Agent 本质的理解，区分"生成式 AI"和"自主 AI"
Q：什么是 ReAct 模式？为什么它比纯 Chain-of-Thought 更适合 Agent？
A：ReAct = Reasoning + Acting。CoT 在推理过程中无法获取外部信息；
ReAct 每步推理后可执行工具（如搜索），将真实结果注入后续推理，
解决了知识截止和需要实时数据的问题。
考察意图：考察对 Agent 核心执行范式的掌握
【原理深挖层】
Q：Agent 的 Memory 系统如何设计？短期记忆和长期记忆分别怎么实现？
A：短期记忆 = LLM 上下文窗口，存储近期对话历史，容量有限（4K-128K tokens）；
长期记忆 = 向量数据库（如 Pinecone、Chroma），将历史信息向量化存储，
通过语义检索在需要时取回。生产中通常组合使用：近 N 轮完整保留 +
历史摘要压缩 + 关键事实存向量库。
考察意图：考察记忆层次设计，以及是否理解 token 成本和信息保真度的 Trade-off
Q：如何防止 Agent 陷入无限循环？有哪些工程手段？
A：① max_iterations 硬截断（最常用，建议 15-20）；
② max_execution_time 时间截断；
③ 在 Prompt 中引导 Agent："若 N 步内无进展，主动声明失败"；
④ 工具调用去重检测（同一工具同一参数连续调用 3 次则强制停止）；
⑤ 观测 agent_steps_per_task 指标，超阈值告警。
考察意图：考察对 Agent 核心工程问题的实际处理经验
【生产实战层】
Q：你在生产中遇到过哪些 Agent 可靠性问题？如何解决？
A（参考角度）：
① 幻觉工具参数问题：用 Pydantic Schema 强校验 + few-shot 示例纠正
② 成本失控问题：设置 token budget + 小模型降级 + 工具输出截断
③ 长任务成功率低：引入检查点机制 + 任务拆分 + Human-in-the-loop
④ 多 Agent 死锁：DAG 任务依赖 + 超时强制中断
考察意图：考察真实工程经验，是否经历过生产挑战并有系统性解决思路
Q：如何评估一个 Agent 系统的质量？用什么指标？
A：关键指标：
① 任务成功率（Task Success Rate）：最核心，通常需要人工标注或自动评估
② 步骤效率（Steps per Task）：衡量规划质量
③ 工具调用准确率（Tool Call Accuracy）：工具选择和参数正确性
④ 成本（Token per Task）：经济可行性
⑤ P90 延迟：用户体验
评估方法：构建 Benchmark 任务集（建议 50-100 条覆盖不同复杂度），
用 LLM-as-Judge 或人工评估打分。
考察意图：考察是否具备 Agent 系统工程化思维，而非只会跑 demo
11. 文档元信息
验证声明
本文档内容经过以下验证：
✅ 与官方文档一致性核查：
- LangChain 文档：https://python.langchain.com/docs/
- OpenAI Function Calling：https://platform.openai.com/docs/guides/function-calling
- ReAct 原论文：https://arxiv.org/abs/2210.03629
⚠️ 以下内容未经本地环境完整验证，仅基于文档和社区经验推断：
- 第 6.3 节"工具描述错误占 40% 失败案例"（来自社区分享，无严谨统计）
- 第 5.3 节 ReAct vs CoT 准确率提升"20-40%"（来自原论文特定任务，实际场景差异大）
- 第 8 节具体延迟数值（依赖模型、网络、工具不同而差异显著）
知识边界声明
本文档适用范围：
- 基于 LLM 的 AI Agent 架构（GPT-4/Claude 等大模型驱动）
- 使用 LangChain 0.2+、LangGraph、AutoGen 等主流框架
- Python 3.11+，部署于云端或本地服务器
不适用场景：
- 传统强化学习 Agent（无 LLM，基于奖励函数训练）
- 嵌入式/边缘端轻量 Agent（资源受限环境）
- 实时性要求 < 1s 的场景
- Confluent、Azure AI 等商业托管平台的特有功能细节
参考资料
【官方文档】
- LangChain Agent 文档：https://python.langchain.com/docs/modules/agents/
- OpenAI Assistants API：https://platform.openai.com/docs/assistants/overview
- Anthropic MCP 协议：https://modelcontextprotocol.io/
【核心论文】
- ReAct：Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)
https://arxiv.org/abs/2210.03629
- Toolformer: Language Models Can Teach Themselves to Use Tools (Schick et al., 2023)
https://arxiv.org/abs/2302.04761
- HuggingGPT / TaskMatrix：工具调用与多模型协作经典论文
【延伸阅读】
- LangGraph 官方教程（最佳状态机 Agent 实现）：https://langchain-ai.github.io/langgraph/
- Lilian Weng 的 Agent 综述博客（强烈推荐）：
https://lilianweng.github.io/posts/2023-06-23-agent/
- AutoGen 论文：https://arxiv.org/abs/2308.08155
- LangSmith 可观测性文档：https://docs.smith.langchain.com/
Agent 垂直技术社区，欢迎活跃、内容共建。
更多推荐
10
0- 0
已为社区贡献8条内容
所有评论(0)