第 21 章 AI Agent 运行时 on Go 语言原本

21.1 Agent 控制循环

Mon, 01 Jan 0001 00:00:00 +0000

21.1 Agent 控制循环

第 20 章讲的是 Go 服务一个模型,请求进、token 流出。可当下的系统往往更进一步:让模型不只回答，还能调用工具、连成多步、自主推进,直到把一个任务办完。这就是 AI Agent。Agent 听起来很玄,本书的立场一以贯之:把模型的智能搁在一边，只看运行时那一面。这样看，一个 Agent 不过是一个 控制循环,而控制循环正是计算机科学最古老、最朴素的结构之一。这一章就用这个视角，把 Agent 还原成一个 Go 程序员熟悉的并发问题。

21.1.1 把 Agent 还原成一个控制循环

剥掉所有花哨的说法，一个 Agent 的核心是一个循环:

flowchart TD
 start["收到任务"] --> ctx["把对话历史 + 可用工具<br/>发给模型"]
 ctx --> model["模型回应"]
 model --> branch{"要调用工具吗？"}
 branch -->|"否：给出最终答案"| done["返回结果"]
 branch -->|"是：请求调用某工具"| tool["执行工具"]
 tool --> append["把工具结果<br/>追加进对话历史"]
 append --> ctx

把这张图读一遍:把上下文（对话历史加可用工具的描述)发给模型;模型要么给出最终答案（循环结束），要么请求调用某个工具;若是后者，就执行那个工具，把结果追加回上下文，再发给模型,如此往复。所谓「自主」「智能体」，机制上就是这个带工具调用的循环。模型负责在每一步决定「下一步做什么」, 而 Agent 运行时负责忠实地执行这个循环:维护上下文、调度工具、把结果喂回去。

这个认识是解魅的，也是解放的。它告诉我们:写一个 Agent 框架，不需要任何机器学习,需要的是把一个循环、一组工具、一份不断增长的上下文，组织得正确、并发、可靠,而这些全是本书前面讲过的东西。

21.1.2 它是一台状态机

把这个循环看得再细一点，它其实是一台状态机。每一轮，Agent 处在某个明确的状态里:

思考中:等模型返回（一次第 20 章意义上的推理请求，往往是流式的)。
待执行工具:模型已决定调用某工具，正准备或正在执行它。
整合中:工具有了结果，正把它追加进上下文。
完成 / 失败:循环终止。

把这些状态显式地写出来，而不是让它们隐式地散落在控制流里，在工程上有实打实的好处。其一， 可观测:任一时刻都能报告「这个 Agent 卡在哪一步」,对调试和监控至关重要。其二，可持久化与可恢复:一个长跑的 Agent 任务可能要数分钟、调几十个工具，把状态显式化，就能把它存盘、在崩溃后从断点续跑，而不是从头再来。其三，可控:超时、重试、人工介入，都更容易挂在显式的状态转移上。 Go 没有花哨的状态机框架，但一个带 state 字段的结构体加一个 for 加一个 switch, 朴素得正好:

21.2 工具调用与 MCP

Mon, 01 Jan 0001 00:00:00 +0000

21.2 工具调用与 MCP

21.1 把 Agent 还原成了一个控制循环，而循环里最关键的那个动作是「执行工具」。这一节就专讲工具:一个工具在机制上是什么，模型怎么决定调用它，运行时怎么把调用分发到真正的代码，以及当工具的数量与来源爆炸式增长时，Model Context Protocol(MCP)如何用一套协议把这件事标准化。看清这一层，会发现工具调用本质上就是一次结构化的远程过程调用,而 RPC 正是 Go 的老本行。

21.2.1 工具是什么：一个带 schema 的函数

剥开「工具」这个词，它不过是一个带类型描述的函数,由三部分组成:一个名字、一段给模型看的自然语言描述、一份参数的结构化 schema(通常是 JSON Schema)。模型在每一步看到的，就是这样一组工具的名字、描述与参数格式;它据此决定要不要调、调哪个、传什么参数，然后输出一个结构化的调用请求:工具名加一组 JSON 参数。运行时接到这个请求，查到对应的函数，反序列化参数，执行，再把结果序列化回去。

把这个流程念一遍，它的形状就是 RPC:名字 + 序列化参数 → 执行 → 序列化结果。在 Go 里，工具最自然地落成一个接口:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


type Tool interface {
 Name() string // 分发用的键
 Description() string // 给模型看的说明
 Schema() json.RawMessage // 参数的 JSON Schema
 Invoke(ctx context.Context, args json.RawMessage) (json.RawMessage, error)
}

// 分发就是一次 map 查找加一次反序列化
func (a *Agent) callTool(ctx context.Context, call ToolCall) (json.RawMessage, error) {
 tool, ok := a.tools[call.Name]
 if !ok {
 return nil, fmt.Errorf("unknown tool: %s", call.Name)
 }
 return tool.Invoke(ctx, call.Args) // ctx 一路透传，为 21.3 的取消埋好线
}

注意 Invoke 的签名带着 context.Context,这不是摆设:工具可能要发 HTTP、查数据库、读文件，都是可能阻塞的 I/O,把 ctx 透传进去，21.3 讲的超时与取消才能一路抵达最底层。一个工具调用框架的运行时核心，基本就是这个接口加这次 map 分发,又一次，没有一行机器学习。

21.3 流式、背压与取消

Mon, 01 Jan 0001 00:00:00 +0000

21.3 流式、背压与取消

21.1 立起了 Agent 的控制循环，21.2 讲清了循环里的工具调用。这最后一节，把第 7 章的 context 与第 10、11 章的并发原语请上台做全书的谢幕演出,因为一个生产级的 Agent，真正的难处不在循环的骨架，而在贯穿整条链路的三件事:流式、背压、取消。它们彼此缠绕，而把它们统一起来的，是一个 Go 程序员再熟悉不过的形状,一棵由 context 绑定的 goroutine 树。

21.3.1 整条链路都是流式的

先看清数据在 Agent 里怎么流。一个请求从客户端进来，落到 Agent 的控制循环;循环每一步向模型发起一次推理，而那次推理是 20.3 讲的流式 token 流;循环还会调用工具，工具自身也可能慢、可能流式返回。于是流式不是某一层的特性，而是贯穿整条链路的常态。

这带来一个体验上的要求:用户不该盯着空白等 Agent 默默跑完几十步。模型在想什么、正调用哪个工具、工具回了什么，都应当边发生边呈现。这意味着 Agent 不只是消费下层的流，它还要再生产一条自己的事件流向上吐:把「模型正在输出的 token」「开始调用工具 X」「工具 X 返回了」这些事件，实时地流给客户端。一条流进、一条流出，中间是控制循环,这又是第 10 章「goroutine 经通道把事件逐个传出」的句式，只是这次传的是 Agent 的执行事件。

21.3.2 取消必须穿透每一层

流式之外，最硬的需求是取消。用户随时可能点「停止」、可能关掉连接;一个上层任务失败，正在并行跑的兄弟任务就该立刻停手。一次取消，必须能穿透 Agent 那一整摞调用层,而这正是第 7 章 context 被设计出来要做的事。

把一个 ctx 从最顶端（客户端请求）一路透传下去:进入控制循环，传给每一次 model.Infer, 传给每一次 tool.Invoke,再传进工具内部的每一次 HTTP、每一次数据库查询。这样，顶端一个 cancel(),ctx.Done() 的信号就会同时抵达每一层:模型停止生成（释放 20.1 那块每请求的 KV cache),在飞的工具 I/O 当即中止。整摞调用栈像多米诺一样干净地倒下，没有泄漏的 goroutine、没有继续空转烧钱的推理。