智能体架构

如果每一步和每个分支都能在执行前写明，固定工作流就足够了。当下一项操作取决于尚未出现的信息时，智能体才真正有用，例如测试结果、搜索结果、用户决定或已经变化的环境。智能体架构就是那个封闭的决策循环：它把观测转化为下一个有边界的动作。

这个循环不只是一个模型加一份工具清单。它还需要控制器、整理后的上下文、动作接口、环境、状态转移和终止规则。工具调用只是动作接口的一种，可执行代码、图形界面操作、消息和环境原生命令也可以是动作接口。规划和记忆是循环中的设计选择，并不是每个智能体都必须具备的一组固定组件。

2023 年的两个重要系统分别展示了这片设计空间的一部分。ReAct 把显式的语言推理与特定任务的动作交错起来，让后续决定能够利用新观测 (Yao et al. 2023)。Toolformer 则生成、执行并筛选面向五个固定 API 的候选调用，再用保留下来的调用微调模型 (Schick et al. 2023)。它们证明模型可以学习并使用动作接口，但并不定义唯一正确的智能体架构。

一轮交互就是一次状态转移

在第 $t$ 轮，运行时构造模型输入，控制器提出决定，随后运行时更新持久状态：

$$\begin{aligned} x_t &= \mathcal{C}(g,u,s_t,A_t,b_t), \\ y_t &\sim \pi_\theta(\cdot\mid x_t), \\ d_t &= \mathcal{D}(y_t), \\ s_{t+1} &= \mathcal{U}(s_t,d_t,o_{t+1}). \end{aligned}$$

其中，$t$ 是轮次索引，$g$ 是任务目标，$u$ 包含用户指令与约束，$s_t$ 是本轮开始前的持久会话状态，$A_t$ 是本轮暴露的动作规范集合，$b_t$ 记录剩余的词元、动作次数、时间与成本预算，$\mathcal{C}$ 是上下文整理器。它输出有边界的控制器输入 $x_t$。参数为 $\theta$ 的控制器 $\pi_\theta$ 采样输出 $y_t$，解码器 $\mathcal{D}$ 把输出解析成决定 $d_t$。更新器 $\mathcal{U}$ 将旧状态、决定与观测 $o_{t+1}$ 合并，得到下一状态 $s_{t+1}$。方程中的每个符号都对应一项可以记录和测试的运行时对象。

解析后的决定必须有明确类型。一个实用的最小集合是：

$$d_t \in \{\operatorname{act}(a_t),\operatorname{ask}(q_t), \operatorname{final}(r_t),\operatorname{stop}(e_t)\}.$$

其中，$a_t$ 是请求执行动作或一批明确动作，$q_t$ 是向用户提问的问题，$r_t$ 是提交最终回答，$e_t$ 是结构化终止原因。动作产生的 $o_{t+1}$ 可以是工具结果、执行错误或策略拒绝，用户回复也可以成为观测。最终回答必须在完成条件通过后才能离开循环。终止原因应记录成功、终局失败、取消、预算耗尽或其他已声明的终止条件。

状态 $s_t$ 与模型上下文 $x_t$ 不是同一个对象。状态可以保存完整事件日志、审批记录、外部资源句柄，以及绝不能进入提示词的数据。上下文则是经过选择和格式化的状态视图。将二者分开后，脱敏、摘要、回放和更换模型都不需要改写会话记录。

图 38.2 中的控制器可以采用 ReAct。ReAct 在动作之间插入可见的语言推理 (Yao et al. 2023)，但通用循环并不要求展示这类轨迹。模型可以在内部推理，外部规划器可以提供计划，确定性工作流也可以决定部分状态转移。必须保持可观测的是决定记录，包括所选分支、动作参数、观测来源、审批结果、已消耗预算和完成证据。

架构是一组契约

规划、记忆和工具使用这些常见标签很有用，却混合了策略、状态与接口问题。把每项运行时角色写成契约，生产架构会清楚得多：

这种拆分也将架构与运行框架的实现分开。架构规定状态必须留存、动作必须经过防护；第 41 章 中的运行框架则用队列、租约、重试、检查点和崩溃恢复，让这些契约在故障后仍然成立。

根据任务选择控制模式

智能体架构之所以有多种形态，是因为控制器不必对所有任务采用同一种模式。

工作流能够表达任务时，通常应优先使用工作流。它成本更低，更容易测试，也更容易授权。只有当系统只能在设计时尚不可见的观测出现后才能选择动作时，由模型控制的循环才值得承担额外成本。

规划不是开关，而是一种节奏

一份不可修改的计划可能很快过时，但这并不意味着规划无用。真正的设计问题是何时制定计划、计划覆盖多远，以及什么情况触发修改。ReAct 用显式推理和动作展示了逐步适应 (Yao et al. 2023)。Reason for Future, Act for Now 会规划未来轨迹，只执行第一个动作，纳入反馈后再次规划 (Liu et al. 2024)。Plan-and-Act 则把训练过的高层规划器与执行器分开，并报告了长时程网页任务上的结果 (Erdogan et al. 2025)。这些系统采用的是不同的规划节奏，并不是同一套正确架构的迭代版本。

写下来的计划属于状态，不代表权限。每一步仍需检查当前前置条件、权限和预算。常见的重新规划触发条件包括前置条件失败、意外观测、用户约束发生变化、动作被拒绝、超时、完成检查失败，或剩余预算达到阈值。计划还应记录支撑它的观测，否则摘要可能保留步骤，却删掉当初证明该步骤合理的假设。

自适应控制不要求展示推理轨迹。ReAct 等研究系统中，这类轨迹可能有用；但运行审查应依靠稳定的产物，例如计划版本、决定类型、动作参数、验证器输出和状态转移。Reflexion 是一种具体方案，它把任务反馈转成文本反思，留给后续尝试使用 (Shinn et al. 2023)。这说明无需更新模型权重也能更新上下文状态，却不构成通用的正确性保证。

选择动作表示方式

动作接口决定控制器能表达什么，也决定运行时能验证什么。三种常见表示方式有不同取舍：

Toolformer 研究模型如何学会在何时、以何种方式调用一小组固定 API (Schick et al. 2023)。CodeAct 研究另一种动作表示，也就是可执行 Python。作者在 API-Bank 和 M³ToolEval 上测试 17 个模型，与其比较的文本和 JSON 格式相比，报告成功率最高提高 20 个百分点 (Wang et al. 2024)。结果仅适用于这些模型、接口和基准，不能证明代码始终更安全或更便宜。

接口设计本身就会改变智能体表现。SWE-agent 为仓库浏览、编辑和测试设计了智能体与计算机之间的接口，再在软件工程任务上评测 (Yang et al. 2024)。更普遍的结论不是每个智能体都需要这套接口，而是动作名称、参数形状、观测格式和反馈延迟都属于架构，并非中性的连接层。

无论采用哪种表示，模型只负责提出动作，引用监视器决定是否允许执行。带副作用的请求需要稳定的幂等键，避免传输重试重复购买、发消息或写入。长期运行的工作需要持久句柄来标识，不能把一条仍然打开的连接当作身份。只有依赖关系和副作用互不冲突时，才能安全地并行动作。

让每一个分支都明确

最小循环不是“不断调用模型，直到它不再输出工具调用”。没有调用可能表示最终回答、澄清问题、拒绝、格式错误或模型故障。更安全的架构骨架如下：

state = initialize(task, user_constraints, permissions, budgets)

loop:
    stop = check_termination(state)
    if stop exists:
        return recorded_outcome(stop, state)

    context = assemble_context(state)
    raw = controller(context)
    decision = decode_typed_decision(raw)

    if decision is invalid:
        state = record_parse_error(state, raw)
        continue  # bounded by the parse-retry budget

    if decision is ask_user:
        suspend until reply or cancellation
        state = record_user_reply(state, reply)
        continue

    if decision is final_response:
        evidence = verify_completion(state, decision)
        if evidence passes:
            return recorded_outcome(success, state, evidence)
        state = record_failed_completion(state, evidence)
        continue

    if decision is requested_action:
        verdict = validate_authorize_and_budget(decision, state)
        if verdict denies:
            state = record_observation(state, verdict)
            continue
        request_id = idempotency_key(session_id, turn_id, decision)
        result = execute_with_timeout(decision, request_id)
        state = record_observation(state, normalize(result))

这份骨架可以向用户提问、请求执行动作、提交最终回答或终止。解析错误、授权拒绝、超时和工具故障都成为带类型的观测，不再作为异常悄悄抹掉一轮交互。终止检查覆盖成功、失败、取消和预算耗尽。运行框架可以用不同方式实现重试与恢复，但必须保留这些结果。

区分自主性与权限

自主性描述由谁选择下一项操作，权限描述系统可以执行哪些操作。它们是两条彼此独立的轴。控制器可以自主搜索只读语料库，却只有很小权限；固定工作流也可能拥有部署软件或转移资金的广泛权限。

这个区别会改变架构审查。增加规划器、延长任务时程或动态发现工具，可能增加自主性，却不改变权限。挂载可写凭据、扩大文件系统范围或移除审批门，即使控制循环不变，也会扩大权限。影响范围取决于权限、可达范围与可逆性，不能由“智能体化”这样的模糊标签决定。安全与授权控制见 第 56 章；架构必须暴露这些控制可以介入的决定点。

下层约束：上下文是一笔共享预算

上下文窗口必须同时容纳指令、任务数据、工作状态、动作规范，以及留给输出的空间。其词元记账方式是：

$$B_{\mathrm{ctx}} = B_{\mathrm{fixed}} + B_{\mathrm{task}} + B_{\mathrm{state},t} + B_{\mathrm{tools},t} + B_{\mathrm{out},t} \le W, \qquad B_{\mathrm{tools},t}=\sum_{a\in A_t}s(a).$$

其中，$B_{\mathrm{ctx}}$ 是第 $t$ 轮预留的总词元数，$B_{\mathrm{fixed}}$ 用于系统与策略指令，$B_{\mathrm{task}}$ 用于用户目标和固定任务数据，$B_{\mathrm{state},t}$ 用于选中的会话状态，$B_{\mathrm{tools},t}$ 用于已挂载的动作规范，$B_{\mathrm{out},t}$ 为控制器输出预留空间，$W$ 是模型支持的上下文上限。集合 $A_t$ 包含第 $t$ 轮暴露的动作，$s(a)$ 是动作规范 $a$ 序列化后的词元长度。每一项都是第 $t$ 轮的实际词元预算。等式只是记账，并不表示每一份预算具有相同价值。

再挂载一个动作会产生确定的词元成本，但它对动作选择的影响需要实测，不是一条普遍成立的指数曲线，也不存在固定的工具数量阈值。结果取决于模型、任务、规范的相似程度、描述方式和提示词。BFCL 评测串行与并行调用、弃权，以及有状态的多轮行为 (Patil et al. 2025)。ACEBench 又加入含糊或不完整的指令和多轮智能体场景 (Chen et al. 2025)。这些基准揭示了多种故障，却没有给出一个适用于所有模型的目录规模上限。

应根据真实工作负载，在扁平目录、分阶段挂载、检索或显式发现之间选择。测量所需动作存在时的选择质量，加入无关工具和相似规范，测试没有动作适用时能否弃权，并在动态选择规范时报告检索召回率。工具检索可以节省上下文，也可能恰好隐藏解决任务所需的唯一动作。

把架构当作完整系统来验证

比较架构时，必须使用相同的模型检查点、任务分布、工具实现、权限和预算。否则，更强的模型、更宽的凭据或更多词元都可能被误认成更好的控制循环。

检查失败时，应按状态转移检查失败，而不只看最终分数。需要确定究竟是哪一环出了问题：所需事实从未进入上下文，控制器选错决定类型，动作规范含糊，授权拒绝了合法操作，环境返回误导性观测，状态更新器遗漏观测，还是完成检查器过早放行。它们属于不同的契约，需要不同的修复。

至此，架构已经明确了状态边界，却还没有决定哪些内容只保留一轮、一个会话，或跨越多个会话。下一章讨论 第 39 章。

延伸阅读