Chapter 01 · Foundation

Agent 不是“会聊天的 LLM”,而是一个会观察、决策、行动并循环的系统

这一份只做一件事:把最容易混淆的 LLM、Chatbot、Workflow、Agent、Tool Calling 一次分清。后面的 ReAct、Memory、MCP、LangGraph 都建立在这里。

1 个核心循环
Observe → Decide → Act
4 个关键组件
LLM / Tools / State / Runtime
3 个易混概念
Chatbot / Workflow / Agent
1 个原则
LLM 选工具,Runtime 执行

1. 什么是 Agent?

最小定义:Agent 是一个能够感知环境、基于目标做决策,并采取行动影响环境的系统。

Agent ≈ LLM + Tools + Loop + State
🧠

LLM:决策器

理解任务、判断下一步做什么、选择工具、组织最终回答。

ReasoningDecision
🛠

Tools:行动能力

搜索网页、读文件、运行 Python、查询数据库、调用 API 等。

ActionExternal World
🔁

Loop:反复执行

不是“一问一答”,而是根据新观察继续决策,直到任务完成。

IterativeAdaptive
📦

State:当前状态

保存当前目标、消息、工具结果、计划、执行进度等运行信息。

ContextProgress
User Goal 任务目标 LLM 决定下一步 State 记录进度与结果 Runtime 执行与调度 Tools 搜索 / 文件 / API World 外部环境
关键判断:只要系统仍然只是“输入 → 模型 → 输出”,它更接近普通 LLM 应用;当系统开始根据环境结果反复选择动作,才真正出现 Agent 特征。

2. Agent Loop:全书最重要的骨架

以后无论看到 ReAct、LangGraph、Coding Agent、Browser Agent,第一件事都是问:它的循环在哪里?

Observe → Decide → Act → Observe → … → Finish
Observe 读取环境结果 Decide 选择下一步 Act 执行工具 Finish? 完成 / 继续

例子:今天青岛下雨时推荐室内景点

Observe:用户提出目标,但系统还不知道天气。
Decide:决定调用 get_weather("青岛")
Act:Runtime 真正执行天气工具。
Observe:收到“今天小雨”。
Decide:继续调用室内景点搜索工具。
Finish:信息足够后生成最终答案。

3. Workflow vs Agent

最核心的区别不是“有没有 LLM”,而是:谁控制执行路径。

🧩

Workflow

Developer controls flow

路径事先写好,系统按固定逻辑执行。

if amount < 100: refund() else: human_review()
🤖

Agent

Model controls flow

下一步取决于当前环境、状态和模型判断。

while not finished: action = llm.decide(state, tools) result = execute(action) state.update(result)
维度WorkflowAgent
执行路径预定义运行中动态决定
稳定性通常更高存在不确定性
成本通常更低通常更高
适合任务规则明确、步骤固定步骤未知、信息非结构化、需要动态决策
典型例子审批流、固定 ETL代码修复、网页研究、复杂搜索
工程原则:能用确定性 Workflow 解决的部分,不要为了“更像 Agent”而强行交给 LLM。真实系统通常是 Workflow + Agent 的混合。

4. LLM 在 Agent 里到底负责什么?

LLM 主要负责“判断”,而不是亲自执行系统操作。

🎯

理解目标

把自然语言需求转成任务意图和约束。

🧭

决定下一步

选择继续推理、调用工具、请求信息或结束。

🧱

结构化输出

生成 Tool Call、JSON、计划步骤或最终回答。

不要混淆:LLM 输出“我要调用 shell”并不等于 shell 已被执行。真正的执行权限属于 Runtime / Harness。

5. Tool Calling:模型选工具,Runtime 执行

这是进入现代 Agent 工程的关键分界线。

User “青岛天气?” LLM 选择 get_weather Runtime 解析并执行 Weather Tool 真实 API / 函数 Observation 18°C,小雨

工具定义包含什么?

{ "name": "get_weather", "description": "查询某个城市的天气", "parameters": { "city": "string" } }

模型输出什么?

{ "name": "get_weather", "arguments": { "city": "青岛" } }

谁真正执行?

tool = tools["get_weather"] result = tool.run(city="青岛")
LLM chooses the tool ≠ LLM executes the tool

6. Agent 发展路线:只看主线,不背历史

Rules符号/规则 Agent RL强化学习 Agent LLM语言模型 LLM + Tools可行动 Modern AgentPlanning / Memory / MCP
真正需要记住:现代 LLM Agent 的变化,不是“模型会聊天”,而是 LLM 开始充当 Controller / Decision Maker,负责调度工具与任务执行。

7. 常见误区

误区 1:用了 LLM 就是 Agent

错误。固定的 “Prompt → LLM → Answer” 更接近普通 LLM 应用。

误区 2:用了工具就是 Agent

错误。如果工具调用顺序完全写死,本质仍可能是 Workflow。

误区 3:Agent 越自主越高级

错误。自主性意味着更多不确定性、成本与安全风险。

误区 4:LLM 能直接执行系统命令

错误。是否真正执行取决于 Runtime、权限和工具层。

8. 快速验收

先自己判断,再展开答案。

Q1:系统固定执行“读取 PDF → 总结 → 翻译 → 保存 Markdown”,属于什么?
Workflow。路径由开发者提前写死,即使每一步调用 LLM,也不因此变成 Agent。
Q2:系统根据报错不断决定“读 README / 改环境 / 重跑测试”,属于什么?
Agent。下一步取决于环境观察结果,存在动态决策循环。
Q3:模型输出 {"name":"run_python","arguments":...} 后,代码已经执行了吗?
没有。这只是 Tool Call 决策;真正执行需要 Runtime / Harness 调用对应工具。

9. 一页总结

Agent = LLM + Tools + Loop + State
Workflow:Developer controls flow
Agent:Model controls flow
LLM chooses tool ≠ Runtime executes tool
Observe → Decide → Act → Observe → … → Finish
下一份建议:第 4~5 章——ReAct、Plan-and-Solve、Reflection,以及为什么它们应该组合成 “Plan → Act → Observe → Reflect → Replan”。