从 Agents Course 理解 Agent 基本闭环

课程定义：Agent 是一个利用 AI 模型与环境交互、以完成用户目标的系统。它结合推理、规划，以及（通常通过外部 Tool 执行的）动作。

可以拆成两块：Brain 是 AI 模型，负责推理与规划、决定下一步动作；Body 是能力与工具，决定它实际能对环境做什么。LLM 本身只能吃文本、吐文本；能查天气、发邮件、检索资料，是因为系统给了它 Tool，并由 Agent 运行时去执行。

课程用 Alfred 点咖啡作类比：听懂自然语言 → 规划步骤 → 使用咖啡机这类工具 → 把结果交回。agency 指的是与环境交互的能力，而不只是生成一段好看的回复。

Agents Course 把工作流写成连续循环：Thought（思考）→ Act（行动）→ Observe（观察）。

• Thought：根据当前对话与目标做推理、规划
• Action：按计划调用工具并传入参数
• Observation：把工具返回放回上下文，再决定继续行动还是结束

多步 Agent 的关键不只是“会调一次函数”，而是模型输出是否继续控制迭代。课程引用的 agency 光谱里，从简单后处理、路由，到 tool caller，再到 while 循环式多步与 multi-agent，能力逐步增强。

Tool 是交给 LLM 的函数，目标要清晰。常见例子：网页搜索、图像生成、检索、外部 API。好的 Tool 补的是模型短板——算术、实时数据、私有系统——而不是重复模型已经擅长的纯文本生成。

LLM 不会自己“伸手”调工具。系统通过 system prompt（或等价描述）告诉它有哪些工具、参数是什么；模型生成的是工具调用文本/结构，由 Agent 运行时真正执行，再把结果塞回消息。

def calculator(a: int, b: int) -> int:
    """Multiply two integers."""
    return a * b

# 课程后续用 @tool 等机制，把名字、说明、参数类型暴露给模型
# @tool
# def calculator(a: int, b: int) -> int:
#     """Multiply two integers."""
#     return a * b

描述里要写清：做什么、输入类型、输出是什么。模糊的 Tool 说明会直接拉低 Agent 质量。

Observation 不是给用户看的装饰，而是下一轮 Thought 的输入。工具返回后，Agent 把它追加进对话，再问模型：还要不要调用工具？能否给出最终答复？

因此一次失败或空结果，理想情况下会触发改参数、换工具或承认不知道，而不是无视观察继续编造。没有 Observe 这一环，所谓 Agent 就退化成“模型说要调工具”的一次性脚本。

课程里的 Alfred（天气 Agent）是完整闭环的概念示例：用户问纽约天气 → Thought 判断需要实时数据 → Act 调用 get_weather 一类工具 → Observe 收到 API 原始数据 → 再 Thought 一次，组织成最终自然语言回答。

{
  "tool_name": "get_weather",
  "tool_arguments": { "location": "New York" }
}

用户通常看不到中间的 tool 消息；他们只看到最终天气说明。对实现者来说，中间消息才是闭环是否成立的证据。

• 单次 Chat Completion：没有对环境的动作循环
• 固定 prompt 模板 + 一次函数调用：更像脚本，缺少多步观察与再决策
• 只有检索、没有“是否再搜/是否结束”决策的 RAG 管线：是增强生成，不一定是 Agent
• 带“Agent”字样的产品包装：仍要看它是否具备工具执行与迭代控制

课程强调 agency 是光谱。Router 或单次 tool caller 可以很有用，但不必全部称为“自主 Agent”。把术语收紧，后面选框架时更不容易走偏。

概念清楚后，按 Unit 1 后续章节进入 smolagents，创建 Alfred 并（可选）发到 Hugging Face Spaces；章末 quiz 通过可拿 Fundamentals of Agents 证书。

若你要先把“工具”做成可被多种宿主调用的标准服务，看 构建你的第一个 MCP Server。若更关心在真实仓库里改代码的 coding agent，看 用 Claude Code 开始一个真实项目。