01 - 基础组件

零件仓库

在讨论 Agent 的运行时架构之前，我们需要先清点一下构建它的基础组件。如果把 Agent 比作一台自动驾驶汽车，那么这些组件就是它的引擎、燃油、传动轴和操作面板。

理解这些组件的物理特性，是进行后续架构设计的前提。

LLM：预测序列的引擎

大语言模型（LLM）在本质上是一个概率预测引擎。

输入序列 → [LLM] → 下一个 Token 的概率分布

当你输入“人工智能是”，模型并不是在“思考”什么是人工智能，而是在计算在“人工智能是”之后，接哪个词的概率最高。

对 Agent 工程的意义：

无状态性：模型本身不记得过去。所有的“记忆”都必须通过重新输入来维持。
幻觉的必然性：由于是概率预测，它永远可能生成一个逻辑自洽但事实错误的序列。
推理成本：生成每一个 Token 都需要消耗计算能。这意味着“思考”是有代价的。

提示词（Prompt）：隐喻与约束

提示词不是简单的“指令”，它是运行时的配置（Runtime Configuration）。

在 Agent 系统中，提示词通常分为两类：

系统提示词（System Prompt）：定义模型的角色、能力边界、输出格式和必须遵守的硬规则（如“你必须使用工具来获取事实”）。
用户提示词（User Prompt）：具体任务的描述和当前的输入数据。

对 Agent 工程的意义：

隐喻驱动：通过告诉模型“你是一个资深的 Linux 运维工程师”，可以激发模型在特定领域的概率分布，使其输出更符合该角色的行为模式。
格式约束：通过提示词强制模型输出 JSON 或特定 XML 标签，是将模糊的文本转化为结构化数据的关键手段。

工具调用（Tool Call）：结构化的意图

模型只能输出文本，但现实世界需要执行。工具调用是从文本意图到程序执行的桥梁。

一个工具调用通常包含：

Schema：定义工具的名称、描述和参数结构（通常是 JSON Schema）。
意图表达：模型在生成的文本中包含一个特殊的标识，表示它想要调用某个工具。
执行结果回填：外部系统执行该工具，并将结果（Observation）转回文本送给模型。

| 环节 | 格式 | 处理者 | | -------- | ---------------------------------------------- | ------------------- | | 定义工具 | JSON Schema | 开发者 | | 声明调用 | {"name": "search", "args": {"q": "weather"}} | LLM | | 返回结果 | {"temp": 25, "unit": "C"} | 环境（Environment） |

Bash：通用的操作界面

在软件工程领域的 Agent 中，Bash（或类似的 Shell 环境）是最强大的工具。

为什么不是 Python API 或特定的 SDK？因为 Bash 是计算机系统的“通用文本接口”。

高带宽：通过一行命令，可以调动编译器、文件系统、网络工具和云端资源。
组合性：管道符（|）允许将任意工具的输出作为另一个工具的输入，这非常符合 Agent 逐步处理信息的逻辑。
环境隔离：通过容器（Docker），我们可以给 Agent 一个可以随意折腾、坏了也能瞬间恢复的物理世界镜像。

总结

LLM 是动力源。
Prompt 是方向盘和限制器。
Tool Call 是传动装置。
Bash 是 Agent 接触最广的外部世界。

当我们把这些组件拼装在一起，并让它们循环运行起来，就得到了下一章要讨论的：对话循环。