AI AGENT 开发 · 从入门到实战 · #01

从 Chatbot 到 Agent:一文搞懂 AI 智能体到底是什么

这个系列写给这样的人:会写 Python、用过 ChatGPT 或 Claude,看过一堆「Agent 改变世界」的发言,但真要自己动手时不知道从哪行代码开始。十篇之后,你会拥有一条从「知道 Agent」到「做出 Agent」的完整路线。第一篇,先把地基打牢——搞清它到底是什么,以及它不是什么。

一、从「接话」到「办事」:差别到底在哪

先把三个词摆正位置。大语言模型(Large Language Model, LLM)本质是一个「文本进、文本出」的函数;我们熟悉的 Chatbot 是包了一层对话界面的 LLM——你问,它答,仅此而已。而智能体(Agent)是另一回事。Anthropic 在《Building Effective Agents》里给过一个我认为最干净的定义:Agent 是「LLM 动态主导自身流程与工具使用的系统」——它自己掌控「怎么完成任务」这件事 [1]。

这个差别在真实任务里会立刻显形。你对 Chatbot 说「把 data/ 目录下 100 份 PDF 里的发票号和金额整理成 CSV」,它最优反应是给你一份操作教程;而对 Agent 说同样的话,它会真的去读目录、调解析工具、逐份抽取、写出文件,并在最后检查行数对不对。

一句话:Chatbot 负责「接话」,Agent 负责「办事」。从接话到办事,中间隔着三件东西,这也是我判断一个系统是不是 Agent 的三问:

• 它拿到的是目标(goal)还是步骤?——「整理成 CSV」是目标;「先打开 A,再点 B」是步骤;
• 它能不能动手(工具调用,Tool Calling)——读写文件、发请求、查数据库,而不是只会打字;
• 它有没有循环(feedback loop)——行动之后能看到结果,并根据结果决定下一步。

三问全是「是」,才配叫 Agent。这三问也是整个系列的骨架:第二篇拆组件,第三篇写循环。

二、Agent 的最小定义:目标、工具、循环

概念吵了两年,但工程上的最小内核其实只有二十来行代码。一个 Agent = LLM(大脑)+ tools(手脚)+ while 循环(心跳)+ 目标(输入)。下面是一个真的能跑起来的骨架(Python + OpenAI SDK;换 Anthropic 只是 SDK 名字和参数形式不同):

import json
from pathlib import Path
from openai import OpenAI   # pip install openai;需先设置环境变量 OPENAI_API_KEY

client = OpenAI()

# —— 工具:普通 Python 函数。给模型看的是「说明书」,真正执行的是实现 ——
def read_file(path: str) -> str:
    return Path(path).read_text(encoding="utf-8")[:5000]

def write_file(path: str, content: str) -> str:
    Path(path).write_text(content, encoding="utf-8")
    return f"已写入 {path}(共 {len(content)} 字符)"

TOOLS = {"read_file": read_file, "write_file": write_file}

TOOL_SCHEMAS = [   # 说明书:模型靠它决定何时、如何调用
    {"type": "function", "function": {
        "name": "read_file",
        "description": "读取本地文本文件,返回前 5000 字",
        "parameters": {"type": "object",
                       "properties": {"path": {"type": "string"}},
                       "required": ["path"]}}},
    {"type": "function", "function": {
        "name": "write_file",
        "description": "把文本内容写入本地文件",
        "parameters": {"type": "object",
                       "properties": {"path": {"type": "string"},
                                      "content": {"type": "string"}},
                       "required": ["path", "content"]}}},
]

def run_agent(goal: str, max_steps: int = 10) -> str:
    messages = [
        {"role": "system", "content": "你是一个能读写本地文件的助理,每次只做一小步,完成任务才输出最终答案。"},
        {"role": "user", "content": goal},
    ]
    for _ in range(max_steps):                    # 循环:Agent 的心脏
        resp = client.chat.completions.create(
            model="gpt-4o-mini", messages=messages, tools=TOOL_SCHEMAS)
        msg = resp.choices[0].message
        if not msg.tool_calls:                    # 停止条件一:模型宣布完成
            return msg.content
        messages.append(msg)
        for call in msg.tool_calls:               # 执行工具,回填观察结果
            result = TOOLS[call.function.name](**json.loads(call.function.arguments))
            messages.append({"role": "tool", "tool_call_id": call.id,
                             "content": str(result)})
    return "已达最大步数,任务未完成。"           # 停止条件二:防失控

# 预期输出:形如「已完成整理,共 23 条记录,已写入 D:/notes/todo.csv」的汇报文本
print(run_agent("读取 D:/notes/todo.txt,把内容整理成 CSV,存为 D:/notes/todo.csv"))

逐行看这段代码,有三件事值得停下来想一想:

第一,「智能」全部来自模型,「结构」全部来自循环。循环里每轮只做三步:让模型看当前局势(messages),模型要么给出工具调用、要么宣布任务完成;我们执行工具,把观察结果(Observation)塞回对话,进入下一轮。

第二,两个停止条件缺一不可:模型自己说「做完了」,或者步数耗尽。没有 max_steps 的 Agent 就是一台可能永久空转的机器——这是新手最常踩的第一个坑。

第三,这个内核就是所有框架的内核。2025-2026 满地的 Agent 框架,拆开来看都是在这些行外面加东西:加记忆、加多角色、加评测、加审批。内核本身,三年来没有变过。

它甚至不是新发明。2022 年的 ReAct 论文已经把这套「推理(Reasoning)与行动(Action)交错」的范式跑通:仅用一两个示例的 ReAct,在 ALFWorld 具身任务上比模仿学习基线的绝对成功率高 34%,在 WebShop 购物环境上高 10% [2]。今天的模型比当年强得多,但「思考→行动→观察」这个节拍没有变。

三、边界辨析:工作流、RAG 和 Agent

技术语境里,这三个词经常被混着卖,值得专门掰开。

工作流(Workflow):LLM 和工具按「预先写定的代码路径」编排——这是 Anthropic 的原话定义 [1]。每一步做什么、顺序如何,都是工程师写代码时决定的。优点是确定、便宜、好测试;缺点是不会变通。

RAG(检索增强生成,Retrieval-Augmented Generation):回答之前先去知识库捞相关材料,再让 LLM 基于材料作答。它通常是一次性的「检索→生成」,没有行动,也没有循环。用 Anthropic 的分类,RAG 只是「增强型 LLM」里 retrieval 这一块积木 [1]。

Agent:路径由模型在运行时自己决定。给目标不给路径,过程中它自己选工具、自己纠错。

最容易混的是工作流和 Agent,用同一个任务对照着看:

# 写法 A:工作流——路径是工程师写死的,每次运行都走同一条路
def workflow(pdf_dir: str) -> str:
    texts  = [extract_pdf(p) for p in sorted(Path(pdf_dir).glob("*.pdf"))]  # 固定第 1 步
    fields = [llm_extract(t) for t in texts]                                # 固定第 2 步
    return save_csv(fields)                                                 # 固定第 3 步

# 写法 B:Agent——只给目标,路径由模型在循环里现场决定
# (extract_pdf / llm_extract / save_csv 为示意函数;把它们注册进
#  上文的 run_agent 工具表,下面这行就是完整调用)
run_agent("把 data/ 下所有 PDF 的发票号和金额整理成一个 CSV 文件")

写法 A 的每一步都是你写的,程序永远走同一条路;写法 B 只给目标,怎么拆步骤是模型的事。一个实用的判断法:试着把需求说成步骤——如果你能把流程画成一张没有分支悬念的流程图,它就该是工作流;如果「下一步取决于上一步发现了什么」,才需要 Agent。

还有一个混合形态值得点名:Agentic RAG。当检索不再是「生成前取一次」,而是 Agent 循环里可以反复调用的工具——搜、读、觉得不够再搜、最后综合——它就成了 Agentic RAG [1]。你见到的很多「智能问答助手」其实是它,而不是完整 Agent。

四、自主性是一条光谱,不是开关

「是不是 Agent」之外,更有用的问法是「它有多自主」。按人介入的粒度,可以排出一条光谱:

级别	人做什么	典型形态
L0	一切手动	直接用 ChatGPT / Claude 网页版
L1	人执行,AI 建议	Copilot 类:补全、草稿、建议下一步
L2	人批准每个动作	带审批的 Agent:每个工具调用等待确认
L3	人批准关键节点	子任务级自治:只在危险操作或提交前停下
L4	人只给目标	目标级自治:自动跑完并汇报

工程上的反直觉之处在于:自主性每升一级,难度不是线性涨,而是指数涨——你要回答的问题从「模型答得好不好」变成「它错一步会怎样、我怎么知道它错了、错了怎么兜底」。所以 2025-2026 年真正大规模落地的形态集中在 L2-L3:Claude Agent SDK 把工具审批(permissions)做成内置能力 [6];OpenAI Agents SDK 把与执行并行的输入输出校验(护栏,Guardrails)做成一等原语 [3];LangGraph 干脆支持在状态图的任意节点插入人在回路(Human-in-the-loop)检查点 [4]。

给动作加审批不是「不先进」,恰恰是工程成熟度的标志。这个判断会在第 9 篇《评测与护栏》里展开成一套方法。

五、它现在真的能干什么:场景与共同规律

不画大饼,只说我观察到的、已经跑出价值的场景:

• 编程:目前最成熟的落地点。原因是反馈信号极其干净——代码要么通过测试、要么不通过,SWE-bench 类任务天然适合 Agent 循环 [1]。Claude Code 系与 Codex 系产品都验证了这条路 [6];
• 客服与工单:查订单、查知识库、执行退款、更新工单——「对话 + 工具集成」的标准组合。它还有个独特的经济信号:按「成功解决」计费而不是按 token,与 Agent 的结果导向天然匹配 [1];
• 深度研究:多来源检索、交叉验证、产出带引用的报告。官方模板就是 orchestrator-workers(编排者拆任务给多个工作者)加 evaluator-optimizer(评价者决定要不要再搜一轮)[1]——这也是第 8 篇多智能体的预告;
• 浏览器 / GUI 操作:让模型直接操作屏幕,本质是 RPA 的 AI 化。能干,但脆——界面一改就「失明」,目前适合低风险、高频的小任务 [1]。

这些场景背后的共同规律只有一条,值得抄在笔记本第一页:验证反馈越清晰的任务,Agent 越可靠。代码有测试、客服有工单状态、研究有引用可查;反过来,「帮我写个走心的文案」这种没有判据的任务,Agent 的循环转起来也只是在放大不确定性。

六、生态速览(2025-2026):四个名字,一张决策树

入门者会被框架数量吓到,但当前真正值得记住的是「两官两社」:

• Claude Agent SDK(Anthropic):定位是「把 Claude Code 变成一个库」,自带子代理、工具审批、会话恢复,原生支持 MCP [6];
• OpenAI Agents SDK(OpenAI):实验项目 Swarm 的生产化升级,三大原语是 agents / handoffs(任务移交)/ guardrails,内置会话与追踪(tracing)[3];
• LangGraph(LangChain):低层编排框架,主打持久执行、跨会话记忆与人在回路,适合长流程、可审计的业务系统,官方采用名单里有 Klarna、Uber、J.P. Morgan [4];
• AutoGen(Microsoft):微软开源的多智能体协作框架,研究向,适合做多角色协作实验 [5]。

选型建议压缩成一句话:任务能写成固定流程 → 普通 LLM 调用或工作流;需要动态决策但单角色够用 → 任一官方 SDK;需要长流程状态机或强审计 → LangGraph;想研究多角色协作 → AutoGen。最后提醒一句:框架换血不换骨,它们全都是第二节那二十行循环的扩大版——先把内核吃透,框架只是它的方言。

---

小结

• Agent = 目标导向 + 工具调用 + 循环反馈;三问全「是」才叫 Agent,否则它是 Chatbot 或工作流;
• 工作流的路径人写死,RAG 是一次性检索增强,Agent 的路径模型现场决定;能用简单方案就别上 Agent;
• 自主性是光谱,落地主力在 L2-L3;护栏与审批是自主性的前提,不是它的对立面;
• 场景的共同规律:验证反馈越清晰,Agent 越可靠。

下一篇预告:知道了 Agent 是什么,下一篇《解剖一个 Agent:LLM 大脑、工具、记忆与规划四大件》把这二十行内核拆开——四大件各自负责什么、怎么取舍,以及为什么大多数项目根本用不上记忆和规划。

参考来源

1. Building Effective Agents, Anthropic, 2024,anthropic.com
2. ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023,arxiv.org
3. OpenAI Agents SDK 官方文档, OpenAI, 2025,openai.github.io
4. LangGraph Overview, LangChain, 2025-2026,docs.langchain.com
5. AutoGen 官方文档, Microsoft, 2025,microsoft.github.io
6. Claude Agent SDK Overview, Anthropic, 2025-2026,code.claude.com