解码 AI：智能体循环架构与供应商经济学

文章背景与核心概要

近期研究（包括 LangChain 的 Terminal-Bench 实验）表明，围绕大语言模型（LLM）构建的“架构框架”（Harness）对智能体性能的影响远超模型本身。本文基于 Decoding AI 开源课程的视角，深入探讨了智能体循环的三种主要运行模式。

文章核心在于分析不同运行模式如何决定基础设施需求及成本优化策略。通过对比交互式、离线式和异步式三种模式，作者阐述了在“按 Token 付费”的 API 模式与“按 GPU 小时计费”的服务器模式之间进行权衡的逻辑，为开发者提供了构建高效、经济的智能体系统的实践指南。

一个无头核心，三种运行形态

每个智能体的核心都是一个无头框架（headless harness）：这是一个轻量级的循环，LLM 在其中选择动作，工具执行任务，并将观察结果反馈回上下文窗口。虽然核心逻辑非常精简（通常不到 150 行代码），但其周围的基础设施——内存、沙箱和权限管理——才是决定智能体实用性的关键。

At the heart of every agent is a headless harness: a lightweight loop where an LLM selects an action, a tool executes, and the observation is fed back into the context window. While the core logic is minimal (often under 150 lines), the surrounding infrastructure—memory, sandboxing, and permissions—defines the agent's utility.

模式 1：交互式，在线（Interactive, Online）

在这种模式下，终端 UI 直接连接到实时、内存中的会话。 * 挑战： 引导控制。在工具调用执行期间，人类的输入可能会破坏当前的执行轮次。 * 解决方案： 使用优先级队列缓冲输入，仅在安全边界（如 MODEL_REQUEST 或 WOULD_STOP）注入。 * 经济性： 由于人类处于主动等待状态，该模式受延迟限制（latency-bound），因此低延迟的托管 API 是最高效的选择。

In this mode, a terminal UI is wired directly to a live, in-memory session. * The Challenge: Steering. Human input during a tool-call execution can corrupt the turn. * The Solution: A priority queue that buffers input, injecting it only at safe boundaries (MODEL_REQUEST or WOULD_STOP). * Economics: Because a human is actively waiting, this mode is latency-bound, making low-latency hosted APIs the most efficient choice.

模式 2：远程，离线（Remote, Offline）

在此模式下，框架运行在服务器上（例如通过 ZenML 的 Kitaru），智能体在 Modal 等远程基础设施上执行任务。 * 工作流： 任务积压队列被并行处理。由于运行时会记录进度，沙箱可以在失败时从上一个成功步骤恢复。 * 经济性： 该模式受吞吐量限制（throughput-bound）。目标是降低单任务成本而非首字延迟，这使得 GPU 小时计费比按 Token 计费的 API 经济得多。

Here, the harness runs on a server (e.g., via ZenML’s Kitaru) with agents executing on remote infrastructure like Modal. * The Workflow: A backlog of tasks is processed in parallel. Because the runtime records progress, sandboxes can resume from the last successful step if they fail. * Economics: This is throughput-bound. The goal is cost-per-task rather than time-to-first-token, making GPU-hour billing significantly more economical than per-token API pricing.

模式 3：异步，在线（Async, Online）

这种混合方法允许实时会话将工作卸载到后台队列。用户发起任务，但无需实时监控。 * 优势： 进程生命周期独立于客户端，非常适合 Slack 触发的智能体或后台 PR 审查。 * 经济性： 遵循批量计费模型，将用户体验与计算成本解耦。

This hybrid approach allows a live session to offload work to a background queue. The user initiates the task but does not watch it in real-time. * The Benefit: The process outlives the client, making it ideal for Slack-triggered agents or background PR reviews. * Economics: It follows the batch-billing model, decoupling the user experience from the compute cost.

为什么供应商选择取决于运行模式

在按 Token 付费的 API 与按 GPU 小时计费的基础设施之间进行选择，完全取决于工作负载的性质：

吞吐量案例： 处理 1,000 份文档时，前沿 API 的费用可能约为 97 美元，而使用无服务器 GPU 进行批量处理的成本可能低至 13 美元左右。
空闲成本案例： 相反，在预留的 GPU 容量上运行交互式智能体效率低下。如果智能体在等待人工确认时处于空闲状态，GPU 的每小时成本很快就会超过自托管带来的节省。

The choice between per-token API pricing and per-GPU-hour infrastructure depends entirely on the workload's nature:

The Throughput Case: For 1,000 documents, frontier API rates might cost ~\(97**, whereas batch-processing on a serverless GPU could cost as little as **~\)13.

The Idle Cost Case: Conversely, running an interactive agent on reserved GPU capacity is inefficient. If an agent sits idle waiting for human confirmation, the hourly cost of the GPU quickly eclipses the savings of self-hosting.

无服务器 vs. 预留容量

选择无服务器基础设施还是预留容量，归根结底取决于峰均比（peak-to-average ratio）。 * 无服务器： 在需求波动较大时更便宜。 * 预留： 仅在利用率持续保持高位时才具有成本效益。行业数据显示，对于大多数智能体开发而言，峰均比（5–10 倍）远超典型的预留折扣（2–5 倍），这使得无服务器模式在大多数用例中成为明显的赢家。

The decision to use serverless infrastructure versus reserved capacity comes down to the peak-to-average ratio. * Serverless is cheaper when demand fluctuates significantly. * Reserved capacity is only cost-effective if utilization is consistently high. Industry data suggests that for most agentic development, peak-to-average ratios (5–10×) far exceed the typical reservation discounts (2–5×), making serverless the clear winner for most use cases.

关键要点

架构重于模型： 架构是智能体质量的主要驱动因素；更换框架可以将智能体从排行榜末尾提升至榜首。
延迟 vs. 吞吐量： 交互式智能体需要低延迟 API（按 Token），而离线/异步智能体需要高吞吐量 GPU 环境（按小时）。
成本优化： 当工作负载具有突发性时，使用无服务器基础设施；仅在能保证高且持续的利用率时，才选择预留容量。

Harness Over Model: Architecture is the primary driver of agent quality; swapping the harness can move an agent from the bottom of the leaderboard to the top.

Latency vs. Throughput: Interactive agents require low-latency APIs (per-token), while offline/async agents require high-throughput GPU environments (per-hour).

Cost Optimization: Use serverless infrastructure when your workload is bursty; reserve capacity only when you can guarantee high, consistent utilization.

参考资料

内容最初发布于 MarkTechPost。