什么是 Agent
一句话定义：Agent 是以 LLM 为决策核心，通过感知、规划、工具调用与反馈循环，自主完成开放性目标的系统。
关键词是"自主"。拆开看，一个 Agent 需要同时具备三件事：
- 目标导向：接收一个目标而非一组步骤，"帮我分析这份报告并给出改进建议"而不是"执行第 3 步"。
- 动态决策：下一步做什么由 LLM 在运行时决定，而不是写死在代码里。
- 环境交互：能调用工具改变外部世界（搜索、读写文件、调用 API），并能观察行动的结果。
与 Chatbot、Workflow 的区别
| 形态 | 流程由谁决定 | 典型形态 | 确定性 |
|---|---|---|---|
| Chatbot | 用户（一问一答） | 聊天助手 | 无多步流程 |
| Workflow | 开发者（预先编排） | 固定管线 RAG、翻译流水线 | 高，路径可枚举 |
| Agent | LLM（运行时决策） | 自主研究助手、编码代理 | 低，路径动态生成 |
Workflow 与 Agent 的边界最重要：workflow 是开发者预先写好的代码路径，LLM 只在被调用的节点上工作；agent 是 LLM 自己指挥流程，代码只提供工具和护栏。这个区分直接决定了成本、延迟和测试策略——workflow 可以按管线测试，agent 必须按轨迹评测。
核心循环
所有 Agent 都收敛到同一个骨架，即 agentic loop：
┌─────────────────────────────────┐
↓ │
思考（LLM 推理）──→ 行动（调用工具）──→ 观察（读取结果）
│ │
└── 判断任务完成 / 需要修正 ←──────┘
每一轮循环：LLM 基于当前全部信息（目标、历史、观察）推理下一步，选择执行一个工具调用；系统执行并把结果追加回上下文；如此往复，直到 LLM 判断目标达成（或触发护栏终止）。
一个最小骨架只需几十行：
messages = [system_prompt, user_task]
for step in range(MAX_STEPS): # 护栏：步数上限
response = llm.chat(messages=messages, tools=tools)
if not response.tool_calls: # 模型不再调用工具 → 输出最终答案
return response.content
messages.append(response.message) # 记录决策
for call in response.tool_calls: # 执行全部工具调用
result = execute_tool(call.name, call.arguments)
messages.append({
"role": "tool",
"tool_call_id": call.id,
"content": result,
})
循环、终止、护栏——理解了这个骨架，就理解了所有 Agent 框架的本质；框架只是在这副骨架上提供状态管理、恢复、并行等工程能力。
自主性光谱
实践中"Agent"是一个光谱而非开关，按自主程度从低到高：
| 级别 | 形态 | 决策分布 |
|---|---|---|
| L0 | 单轮 LLM 调用 | 无决策 |
| L1 | LLM 链 / workflow | 决策在开发者 |
| L2 | 单 Agent + 工具 | 决策在 LLM，流程单一 |
| L3 | 反思 / 多步规划 Agent | LLM 自我修正 |
| L4 | 多 Agent 协作 | 决策分布到多个角色 |
自主性越高，能力上限越高，但可预测性、成本、调试难度也随之恶化。工程上的成熟做法是让自主性匹配问题复杂度，而不是追求最高级别。
何时需要 Agent
适合 Agent 的问题特征：
- 步骤数事先不可知（"调研 X 并写总结"需要几轮检索，取决于调研发现）；
- 解决路径存在分支与取舍，无法穷举为静态流程；
- 过程中需要根据中间结果调整策略。
不适合的场景：
- 流程确定（发票提取、固定格式转换）——用 workflow，便宜且可测试；
- 延迟敏感（搜索联想、实时风控）——agent 的多轮循环天然是秒级到分钟级；
- 错误代价极高且无法人工兜底——agent 的非确定性需要护栏与确认机制来驯服，见评测与安全。
检索是最早的 Agent 化场景
RAG 从固定管线走向 Agentic RAG（检索决策权交给模型）的过程，就是"workflow 升级为 agent"的典型案例，见 Agentic RAG。接下来先拆解 Agent 的核心组件，再讨论如何构建一个好的 Agent。