AI Agent 不是一个”更聪明的 LLM 调用”,而是一种把”推理”和”行动”闭环起来的新型软件形态。直接调大模型 API 是”问一句答一句”,Agent 是”自己决定问什么、查什么、做什么、把结果再喂回去”。在做内容审核系统时,我第一版用 LLM API 直接判文本合规,遇到多步骤判定(比如先识别类别再查政策库再下结论)就频繁出错;把流程改成 Agent 后,模型自己规划”先调分类工具、再查文档库、最后生成结论”,准确率明显提升。下文把 Agent 的核心特征、与 LLM API 的差异、典型适用场景拆开讲清。
一、Agent 的核心特征
一个完整的 AI Agent 通常具备四个核心能力:
- 自主规划:能根据当前目标拆解任务,决定先做什么、后做什么。
- 工具使用:能调用外部工具(API、数据库、文件、代码解释器)完成任务。
- 记忆能力:能记住跨步骤、跨会话的关键信息,避免重复劳动。
- 循环执行:能在”推理—行动—观察”的循环里持续推进,直到目标达成或失败。
这四点缺一不可——缺规划,Agent 只能被动回答;缺工具,Agent 只能纸上谈兵;缺记忆,Agent 每次都从零开始;缺循环,Agent 只能跑单步。
二、与直接调 LLM API 的根本差异
把 LLM API 调用和 Agent 放在同一张表上对比,差异就一目了然:
| 维度 | LLM API 调用 | AI Agent |
|---|---|---|
| 输入输出 | 单次 prompt → 单次 response | 多轮循环,每次注入新观察 |
| 任务执行 | 一次性给答案 | 拆步执行,逐步逼近目标 |
| 工具使用 | 由外部代码封装调用 | 由模型自己决定调用哪个、何时调用 |
| 记忆 | 无(除非外部拼接历史) | 内置工作/短期/长期三层 |
| 错误恢复 | 重试 prompt 即可 | 能根据工具返回调整计划 |
| 适用场景 | 单步问答、文本生成 | 多步任务、自动化流程、外部交互 |
| 延迟 | 通常 1-5 秒 | 视循环次数,常 10 秒到几分钟 |
| 成本 | 按 token 计费 | 按 token × 循环次数计费,通常更高 |
关键差异在控制权归属:LLM API 调用时,流程控制权在外部代码;Agent 时,流程控制权在模型自己(虽然有边界约束)。
三、一个最小化 Agent 示例
下面这段代码展示了一个能”查天气并决定是否带伞”的极简 Agent:
from openai import OpenAI
import json
client = OpenAI()
tools = [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的天气",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"]
}
}
}
]
def get_weather(city):
# 真实场景会调 API,这里 mock
return f"{city}今天小雨,最高 22 度"
def run_agent(user_msg):
messages = [{"role": "user", "content": user_msg}]
while True:
resp = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=tools
)
msg = resp.choices[0].message
messages.append(msg)
if not msg.tool_calls:
return msg.content
for tc in msg.tool_calls:
args = json.loads(tc.function.arguments)
result = get_weather(**args)
messages.append({
"role": "tool",
"tool_call_id": tc.id,
"content": result
})
print(run_agent("明天我要去杭州出差,需要带伞吗?"))这个例子里,模型先决定要调用 get_weather("杭州"),拿到结果后再决定要不要带伞——这就是 Agent 的核心动作。
四、什么时候该用 Agent,什么时候不该
Agent 听起来强大,但不是所有场景都适合。用错场景的代价是:成本高、延迟长、不可预测。
适合用 Agent 的场景:
- 多步任务:需要 3 步以上推理或操作才能完成(如”查用户最近的订单、判断是否有物流异常、给客服生成回复”)。
- 需要外部数据:模型本身不知道的信息(实时数据、用户私有数据、外部系统状态)。
- 任务路径不可穷举:同样的目标可能有多种达成路径,需要动态选择。
- 容错重要:允许偶尔失败,可以重试或让人接管。
不适合用 Agent 的场景:
- 单步问答:查文档、生成文本、改写文案——直接调 LLM API 即可。
- 强实时性要求:循环调用会增加 1-3 秒,影响交互体验。
- 极高准确率要求:Agent 的多步决策有累积误差,关键决策路径仍需人审。
- 成本敏感:Agent 单次任务的 token 消耗通常是直接调用的 3-10 倍。
五、Agent 的常见变体
按”自主程度”从低到高,常见 Agent 形态有:
- 工具增强 LLM(Tool-Use LLM):LLM 决定调哪个工具,但流程控制权在外部代码。
- ReAct Agent:LLM 自己决定 Thought/Action/Observation 循环,直到完成或放弃。
- 规划型 Agent(Plan-and-Execute):先一次性生成完整计划,再逐步执行;每步可重规划。
- 多 Agent 协作:多个 Agent 各自负责子任务,互相通信协作。
- 自主 Agent(Auto-GPT 风格):给定高层目标,自己拆任务、自己执行、自己评估,无需人介入。
六、Agent 的工程挑战
把 Agent 落到生产环境,有几个绕不开的挑战:
- 成本控制:每步循环都调 LLM,长任务可能烧掉几毛到几块钱;需要”早停”、”摘要压缩”、”小模型分级”等策略。
- 延迟优化:循环调用 + 工具延迟,一个任务可能跑几分钟;需要异步执行、并行工具调用、缓存。
- 可观测性:每一步的 Thought/Action/Observation 都要记录,事后能回放和调试。
- 安全边界:Agent 自己调工具,必须严格限制可写操作;高风险操作走人工审批。
常见问题(FAQ)
Q1：Agent 会取代软件工程师吗?
Agent 是工具,会改变工程师的工作内容(从写逻辑变成设计 Agent + 监督 Agent),但不会取代人。
Q2：Agent 必须用 GPT-4 这种主流模型吗?
不一定。简单 Agent 用 7B/13B 开源模型就能跑,关键是工具设计和 prompt 质量。
Q3：Agent 和工作流(Workflow)的区别?
工作流是预设好的步骤序列(写死在代码里),Agent 是动态决定步骤;前者可控但僵硬,后者灵活但难调。
