> For the complete documentation index, see [llms.txt](https://levon.gitbook.io/agent-engineering/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://levon.gitbook.io/agent-engineering/01agent-ji-chu.md).

# 第 1 课：Agent 基础——从语言模型到行动系统

你对纯语言模型说：“查一下明天上海的天气。如果下雨，早上八点在日历里添加一条带伞提醒。”

它回答得无比温情且确定：“没问题！我已经为你查好了天气，并成功在明早八点设置了日历提醒，祝你拥有美好的一天！”

第二天早晨你在暴雨中淋成了落汤鸡，翻开手机日历，里面空空如也。模型没有欺骗你的恶意，它只是根本没有手。它说出的“已为你设置”，本质上和小说家在稿纸上写下“勇士拔出了石中剑”没有任何区别——石中剑还在石头里，你的日历也从来没有人碰过。

这不是一句写得不够像承诺的话。真正的问题是：到目前为止，系统只生成了文字，没有查询天气，也没有创建提醒。

## 1. 一句回答为什么没有变成动作？

单独的大语言模型接收输入，再生成输出。它可以写出 `read_file`、`send_email` 或 `create_reminder`，却不会因此自动获得文件、邮箱和日历权限。

要让天气提醒真的发生，Model 外面至少还要有一段程序：把可用工具告诉它，接住它提出的调用，执行真实动作，再把结果送回来。下一课会把这段程序和其他组成部分逐一拆开。

这一课先记住最小边界：

```
Model 生成“准备做什么”
外部程序决定并完成“实际做了什么”
```

因此，Model 回答“我会提醒你”，最多证明它生成了这句话，不能证明日历中已经出现一条提醒。

## 2. 路线写死，还是让 Model 临场决定？

天气提醒可以写成一条固定路线：

```
查询天气
-> 判断是否下雨
-> 下雨就创建提醒
-> 返回结果
```

每一步都由代码提前规定。LLM 可以参与，例如把天气说明整理成结构化数据，但它不能改变路线。这种“程序提前编排好步骤”的系统叫 Workflow。

另一种写法只给 Model 一个目标和几个工具。Model 查完天气后，自己判断是否缺少城市、是否需要查看日历冲突、应该调用哪个工具，以及什么时候结束。这才是本文所说的 Agent。

| 系统       | 谁决定下一步              |
| -------- | ------------------- |
| Workflow | 预先写好的代码             |
| Agent    | Model 根据目标和刚得到的结果决定 |

两者可以放在同一个系统里。付款和发布适合让 Workflow 控制固定步骤；遇到失败以后“接下来查日志、看配置还是问用户”，可以交给 Agent 决定。

判断时只看两件事：下一步由谁决定？刚得到的结果会不会改变后续路线？有没有 LLM、有没有工具，都不是分界线。

## 3. Agent Loop 一定是 ReAct 吗？

Agent 要根据真实结果继续选择动作，就需要让“选择、执行、观察”反复发生。这个来回过程叫 Agent Loop：

```
Model 选择动作
-> 外部程序执行
-> 结果返回
-> Model 再选下一步
```

例如命令返回 `403 Forbidden`，Model 看到错误后改用另一种请求。它利用了环境反馈，但这还不能证明系统使用了 ReAct。

ReAct 是一种更具体的组织方法。原论文让推理、行动和环境观察交错出现：先想一步，再做一步，看见结果后继续调整。[ReAct v3](https://arxiv.org/abs/2210.03629v3)

现代 Agent 可以直接生成结构化的工具申请，这种申请叫 Tool Call。外部程序据此驱动循环，不必公开或保存论文形式的 Thought。Agent Loop 是外层运行方式，ReAct 只是其中一种推理和行动组织方法。

## 4. 什么时候根本不该使用 Agent？

Agent 会增加模型请求次数、等待时间和出错路径。它用这些成本换取“Model 可以根据现场改变路线”。如果路线本来就固定，这笔交换通常不划算。

| 任务                 | 最小选择      | 原因              |
| ------------------ | --------- | --------------- |
| 翻译一句话              | 一次 LLM 调用 | 没有外部动作，也不需要循环   |
| 查询数据库、生成日报、人工确认后发送 | Workflow  | 步骤固定，代码更容易预测    |
| 调查一个从未见过的线上故障      | Agent     | 下一步取决于刚拿到的日志和错误 |

固定日报即使使用 LLM 和邮件工具，也不一定是 Agent。提示词里写着“你是 Agent”，也不会让一次普通文本生成自动变成行动系统。

## 5. 先画路线，再决定要不要写 Agent

拿出一个具体需求，先画出每一步由谁决定。只要业务路线可以提前列完，优先选择单次调用或 Workflow；只有当外部结果会不断迫使系统重选动作时，才引入 Agent Loop。

例如“部署前依次运行格式检查、测试和发布”适合 Workflow。“测试失败后，根据错误决定改代码、查依赖还是请求人工帮助”才适合把调查部分交给 Agent。

这一课不要求写完整 Runtime。你只需要能判断：这个任务是否真的需要把下一步交给 Model。下一课再沿一次 `read_file`，认识[Agent Runtime 中各部分的职责](/agent-engineering/02agent-yun-xing-shi.md)。

## 主动回忆

1. Model 为什么答应“会提醒”，第二天却可能什么都没有发生？
2. Workflow 与 Agent 的分界为什么不是“有没有 LLM 或工具”？
3. Agent Loop 与 ReAct 有什么区别？
4. 固定日报为什么更适合 Workflow？
5. 付款流程和开放式故障调查可以怎样组合？
6. 一个任务具有什么特征时，才值得为它引入 Agent？

<details>

<summary>检查简答</summary>

1. Model 只生成了文字；没有外部程序和工具，天气查询与日历提醒不会真实执行。
2. Workflow 的路线由代码预设；Agent 的下一步由 Model 根据新结果决定。
3. Agent Loop 是 Model 根据执行结果继续选择动作的外层循环；ReAct 是其中一种具体组织方法。
4. 它的步骤可以提前写死，使用 Agent 只会增加成本和不确定性。
5. Workflow 控制付款和审批，Agent 只负责无法提前列完步骤的调查部分。
6. 外部环境不确定，而且新结果会反复改变下一步路线。

</details>

## 参考资料

> 资料最后核验于 2026-09-03；会变化的项目状态收录在下面的一手资料复核中。

* [本批章节一手资料复核](https://github.com/unix2dos/agent-engineering-book/tree/main/research/01-05-chapter-promotion-sources.md)
* [Anthropic：Building Effective AI Agents](https://www.anthropic.com/research/building-effective-agents)
* [ReAct v3](https://arxiv.org/abs/2210.03629v3)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://levon.gitbook.io/agent-engineering/01agent-ji-chu.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.