Agent Runtime 是什么：Agent 真正开始工作的执行引擎
这篇文章解决什么问题
很多人理解 Agent 时，只看到一条链路：
用户输入 → LLM → 工具调用 → 返回结果
但复杂 Agent 系统并不是一次性调用链，而是一个持续执行、可恢复、可追踪、可评估的任务过程。用户提出一个问题，Agent 可能需要调用多次模型、执行多个工具、判断中间状态、处理异常、生成最终结果——这一切不是模型自己完成的，而是由一个执行引擎在背后组织的。
这篇文章要回答的核心问题是：Agent Runtime 到底是什么？它在 Agent 系统中承担什么职责？它和 LLM、Workflow、Agent Loop 有什么区别？
核心观点：Agent Runtime 不是模型本身，而是 Agent 的任务执行引擎。 它负责把 LLM、Tools、Memory、Workspace、Trace、Evaluation 等能力组织起来，让 Agent 真正完成任务。
为什么只靠 LLM 不够
LLM 是 Agent 的推理核心，但它本身有几个天然限制：
LLM 不管理任务状态。 模型每次调用都是无状态的——它不知道上一步做了什么，不知道任务进行到哪一步，不知道还有哪些步骤没完成。你需要一个外部组件来维护任务状态。
LLM 不能控制工具执行。 模型可以输出"我要调用某个工具"，但工具的权限校验、参数验证、执行调度、错误处理都不是模型能做的。这些需要工程系统来承接。
LLM 输出不稳定。 模型可能输出格式错误、参数异常、幻觉内容。需要 Runtime 做结构化解析、校验和约束，而不是直接信任模型输出。
多步骤任务需要状态推进。 真实任务往往不是一次模型调用能完成的——检索文档、分析内容、生成草稿、校对修改、返回结果，每一步都需要 Runtime 来编排。
长任务需要生命周期管理。 重试、暂停、恢复、超时、结束判断，这些都需要 Runtime 来处理。模型不知道什么时候该停，不知道失败了该怎么办。
所以，LLM 是 Agent 的"大脑"，但 Runtime 是 Agent 的"神经系统"——它让大脑的指令真正落地执行。
Agent Runtime 在系统中的位置
在生产级 Agent 系统中，Runtime 位于任务执行的中心位置，向上接收请求和上下文，向下调度工具、工作区、Trace 和评测。
| 模块 | 作用 | 与 Runtime 的关系 |
|---|---|---|
| User Request | 用户发起的任务请求 | Runtime 接收并解析用户请求，启动任务执行 |
| Session | 当前会话容器，管理对话上下文 | Runtime 从 Session 读取上下文，把执行结果写回 Session |
| Memory | 长期记忆，存储用户偏好和历史经验 | Runtime 在需要时读取 Memory，把重要信息沉淀为长期记忆 |
| Agent Runtime | 任务执行引擎，组织模型调用、工具调用和状态推进 | 位于系统中心，协调所有其他模块 |
| Tool System | 工具注册、调用和执行 | Runtime 调用工具系统执行具体操作，记录调用结果 |
| Workspace | 任务工作区，管理文件和中间产物 | Runtime 在 Workspace 中读写任务相关的文件和数据 |
| Trace | 执行轨迹记录 | Runtime 每推进一步，都向 Trace 写入执行记录 |
| Evaluation | 效果评估 | Runtime 完成任务后，Evaluation 对结果进行质量评估 |
| Security | 权限控制和安全审计 | Runtime 在调用工具和访问资源前，检查安全策略 |
从这个表可以看出，Runtime 不是孤立存在的——它需要和 Session、Memory、Tools、Workspace、Trace、Evaluation、Security 协同工作。单独一个 LLM 或一个 while loop，都不构成完整的 Runtime。
Runtime 的核心职责
4.1 接管任务
Runtime 的第一步是接管任务。当用户发起请求时，Runtime 需要：
- 接收任务目标，理解用户想要什么。
- 解析任务类型，判断这是查询任务、生成任务还是操作任务。
- 读取上下文，包括 Session 中的对话历史、Memory 中的用户偏好。
- 初始化
run_id，为这次任务执行创建唯一标识。 - 记录任务状态为"运行中"，写入 Trace。
这一步看起来简单，但它是后续所有步骤的基础——没有正确的任务初始化，后面的模型调用、工具调度、状态推进都会出问题。
4.2 组织模型调用
Runtime 不是直接把用户问题丢给模型，而是要精心组织每次模型调用：
- 决定什么时候调用模型。是用户提问后立即调用，还是先检索再调用？
- 选择传入哪些上下文。是全部对话历史，还是压缩后的摘要？是所有工具结果，还是最新的几个？
- 控制模型输出格式。要求模型输出结构化的工具调用指令，还是自然语言回答？
- 对模型输出做解析和校验。模型说要调用某个工具，参数格式对不对？有没有幻觉？
Runtime 对模型调用的组织，决定了 Agent 的执行质量。
4.3 选择和调用工具
当模型输出包含工具调用意图时，Runtime 需要：
- 根据模型输出或任务状态选择工具。模型说要调用搜索，但当前任务可能需要的是数据库查询。
- 校验工具参数。模型生成的参数类型是否正确？必填字段是否齐全？
- 检查权限。当前用户是否有权限调用这个工具？这个工具是否需要审批？
- 调用工具。把参数传给工具系统，执行具体操作。
- 记录工具结果。把工具返回的结构化结果写入 Trace 和状态。
工具调用是 Agent "做事"的核心环节，也是安全风险最高的环节。
4.4 推进任务步骤
复杂任务需要拆成多个步骤，Runtime 负责管理这个过程：
- 将任务拆成 Step。例如：解析输入 → 检索文档 → 生成答案 → 校对修改 → 返回结果。
- 管理 Step 状态。每个 Step 是待执行、执行中、已完成还是失败？
- 判断是否继续、等待、重试或结束。当前步骤成功了，继续下一步；失败了，是重试还是降级？
- 把中间结果写入 Trace。每个步骤的输入、输出、耗时、状态都要记录。
步骤管理让复杂任务变得可控——你知道任务进行到哪一步，每一步的结果是什么。
4.5 处理错误和异常
真实环境中，各种错误都可能发生：
- 工具失败。 外部服务不可用、超时、返回错误。
- 模型输出格式错误。 模型没有按要求输出结构化结果。
- 权限不足。 用户没有权限访问某个资源或调用某个工具。
- 任务超时。 任务执行时间超过限制。
- 依赖服务失败。 数据库、向量搜索、API 网关等依赖不可用。
- 用户输入不完整。 缺少必要信息，需要追问用户。
Runtime 需要根据错误类型决定：重试、换工具、降级、询问用户、人工接管还是结束任务。不能只靠模型重新回答——模型不知道工具为什么失败了。
4.6 生成最终结果
任务完成后，Runtime 需要：
- 整理模型输出。从多次模型调用的结果中提取最终答案。
- 合并工具结果。把多个工具的返回结果整合成完整信息。
- 生成用户可读结果。把结构化数据转换成用户能理解的回答。
- 返回引用、执行轨迹 ID 或状态信息。让用户知道答案的来源，让系统可以追踪这次任务。
最终结果不是模型最后一次输出那么简单——它可能是多次模型调用、多次工具调用的综合产物。
Runtime 执行链路
把 Runtime 的职责串起来，一条完整的执行链路是这样的：
外部请求 → Session 上下文 → Runtime 接管 → 模型调用 → 工具选择 → 工具执行 → 状态更新 → Trace 记录 → 结果生成 → Evaluation
每一步的作用：
- 外部请求：用户通过 API 或界面发起任务请求。
- Session 上下文：Runtime 从 Session 中读取对话历史、用户偏好等上下文信息。
- Runtime 接管：Runtime 初始化任务，创建
run_id，设置初始状态。 - 模型调用：Runtime 组织上下文，调用 LLM 生成下一步行动。
- 工具选择：根据模型输出，Runtime 决定调用哪个工具、传什么参数。
- 工具执行：Runtime 通过工具系统执行具体操作，获取结构化结果。
- 状态更新：Runtime 根据工具结果更新任务状态，判断下一步行动。
- Trace 记录：每一步的执行信息都被记录到 Trace 中。
- 结果生成：任务完成后，Runtime 整理所有信息，生成最终结果。
- Evaluation：评估系统对结果进行质量检查，判断任务是否达标。
这条链路不是线性的——它可能循环多次（模型调用 → 工具执行 → 状态更新 → 再次模型调用），直到任务完成或触发终止条件。
Runtime 和 Workflow 的区别
Workflow 和 Runtime 都涉及任务执行，但它们的设计理念不同。
| 对比项 | Workflow | Agent Runtime |
|---|---|---|
| 执行方式 | 预定义流程，按固定节点顺序执行 | 动态任务执行，根据模型输出和状态决定下一步 |
| 状态管理 | 状态在流程节点间传递 | Runtime 维护完整的任务状态，支持暂停、恢复、重试 |
| 工具调用 | 工具调用是流程中的固定节点 | 工具调用由模型动态决定，Runtime 负责校验和执行 |
| 错误处理 | 通常在流程层面定义错误分支 | Runtime 根据错误类型动态决定重试、降级或终止 |
| 动态决策 | 流程逻辑在设计时确定 | Runtime 在执行时根据模型输出和状态动态决策 |
| 可观测性 | 流程执行日志 | Trace 记录每次模型调用、工具调用、状态变化 |
| 适用场景 | 确定性高的业务流程 | 需要动态推理和决策的 Agent 任务 |
简单说：Workflow 更偏预定义流程，Runtime 更偏动态任务执行引擎。 在复杂系统里，二者可以结合——用 Workflow 定义大的流程框架，用 Runtime 处理每个节点内的动态 Agent 逻辑。
Runtime 和 Agent Loop 的区别
你可能见过最简单的 Agent Loop 伪代码：
while not done:
call_model()
call_tool()
update_context()这个循环确实是 Agent 的核心逻辑，但生产级 Runtime 还需要处理更多事情：
- 权限控制。 工具调用前要检查用户权限，不能让 Agent 随意执行高风险操作。
- Trace。 每次模型调用、工具调用、状态变化都要记录，方便调试和审计。
- 任务状态。 管理任务的生命周期——创建、运行、暂停、恢复、完成、失败。
- 错误恢复。 工具失败了怎么办？模型输出格式错了怎么办？超时了怎么办？
- 成本统计。 记录每次模型调用的 token 消耗、工具调用的延迟和成本。
- 人工审批。 高风险操作需要人工确认，不能全自动执行。
- Evaluation。 任务完成后评估结果质量，积累失败案例。
- 运行隔离。 多个任务并发执行时，要保证状态互不干扰。
所以，Agent Loop 是 Runtime 的核心逻辑，但 Runtime 是一个更完整的工程系统。
最小 Runtime 伪代码
下面是一个最小 Runtime 的伪代码，展示核心执行逻辑：
def run_agent(task):
# 1. 初始化任务执行
run_id = create_run(task_id=task.id)
state = initialize_state(task)
# 2. 主执行循环
while not state.finished:
step_id = create_step(run_id, state)
# 3. 调用模型
model_output = call_model(
task=task,
state=state,
context=build_context(state),
)
# 4. 解析模型输出
action = parse_action(model_output)
# 5. 根据行动类型处理
if action.type == "tool_call":
# 5a. 工具调用：校验权限、执行工具、记录结果
check_permission(action.tool_name, task.user)
tool_result = call_tool(action.tool_name, action.arguments)
record_tool_call(run_id, step_id, action, tool_result)
state = update_state(state, tool_result)
elif action.type == "final_answer":
# 5b. 最终回答：标记任务完成
state.finished = True
state.result = action.content
else:
# 5c. 无效输出：处理异常
handle_invalid_action(action, state)
# 6. 完成当前步骤
finish_step(step_id, state)
# 7. 完成任务
finish_run(run_id, state.result)
return state.result每一步的作用：
- 初始化任务执行：创建
run_id，设置初始状态，记录任务开始。 - 主执行循环：只要任务没完成，就继续执行。
- 调用模型：把当前状态和上下文传给模型，获取下一步行动。
- 解析模型输出：把模型的文本输出转换成结构化的行动指令。
- 根据行动类型处理：如果是工具调用，执行工具；如果是最终回答，结束任务；否则处理异常。
- 完成当前步骤：记录步骤结果，更新状态。
- 完成任务：生成最终结果，记录任务完成。
注意，这只是一个最小版本——生产级 Runtime 还需要加上权限控制、错误恢复、成本统计、Trace 记录、人工审批等能力。
Runtime 与 Trace 的关系
Runtime 负责执行，Trace 负责记录执行。它们是"做事"和"记录做了什么"的关系。
Runtime 每推进一步，都应该向 Trace 写入记录：
run_id：这次任务执行的唯一标识。step_id：当前步骤的唯一标识。model_call：模型调用的输入、输出和耗时。tool_call：工具调用的名称、参数、结果和状态。state_change：任务状态的变化。error_event：发生的错误和处理方式。latency：每步的执行耗时。cost：token 消耗和工具调用成本。final_result：最终任务结果。
没有 Trace，Runtime 就是一个黑盒——你知道任务完成了，但不知道中间发生了什么。有了 Trace，你可以回溯每次决策、每次工具调用、每次状态变化，这对调试、审计和优化都至关重要。
Runtime 与 Evaluation 的关系
Runtime 产出任务结果，Evaluation 判断结果是否达标。
Evaluation 可以从多个维度评估 Runtime 的执行质量：
- 任务是否成功。 用户的问题是否被正确回答？操作是否被正确执行？
- 工具是否正确调用。 是否调用了正确的工具？参数是否正确？结果是否被正确使用？
- 步骤是否完整。 是否遗漏了必要步骤？是否有多余的步骤？
- 错误是否恢复。 遇到错误时是否正确处理？重试策略是否合理？
- 成本是否过高。 token 消耗、工具调用次数、执行时间是否在预期范围内？
- 是否触发安全风险。 是否越权访问了资源？是否执行了高风险操作？
Evaluation 的结果可以反馈给 Runtime，用于优化后续任务的执行策略。
常见误区
把 Runtime 理解成 LLM 本身。 Runtime 是执行引擎，LLM 是推理组件。Runtime 调用 LLM，但 LLM 不等于 Runtime。
只写一个 while loop 就认为是 Agent Runtime。 一个 while loop 是 Agent Loop，但不是完整的 Runtime。Runtime 还需要权限控制、Trace、错误恢复、成本统计等能力。
不记录 run_id 和 step_id。 没有唯一标识，你无法追踪任务执行过程，无法调试问题，无法做 Evaluation。
工具调用没有权限控制。 Agent 可能调用删除数据、发送邮件等高风险操作，必须有权限校验。
错误处理只靠模型重新回答。 模型不知道工具为什么失败了，Runtime 需要根据错误类型做出工程决策。
没有停止条件。 任务可能陷入无限循环——模型一直输出工具调用，但任务永远完不成。Runtime 必须有最大步骤数、超时等停止条件。
不统计成本和耗时。 每次模型调用都有 token 成本，每个工具调用都有延迟。不统计就无法优化。
不做 Evaluation。 Runtime 产出的结果是否达标？不评估就不知道质量如何，无法持续改进。
对个人项目的启发
项目 A（RAG 工单系统）：
RAG 查询可以看作一次 Run。从用户提问开始，到返回答案结束，整个过程可以用 Runtime 的思路来管理。文档检索、Rerank、答案生成、引用返回都可以记录为 Step。每个 Step 的输入、输出、耗时、状态都记录到 Trace 中。Runtime 思路可以帮助后续接入 Trace 和 Evaluation——当你知道每次查询经过了哪些步骤、每步的结果是什么，评估和优化就有了依据。
项目 B（多 Agent 运营中台 Copilot）：
多 Agent Copilot 更需要 Runtime 管理任务分派、工具调用、状态推进和结果聚合。每个 Agent 的执行过程都应该可追踪——哪个 Agent 做了什么决策、调用了什么工具、产出了什么结果，都需要记录。Runtime 设计决定系统是否可控：没有 Runtime，多 Agent 系统就是一堆模型在乱跑；有了 Runtime，每个 Agent 的行为都有边界、有记录、可评估。
面试表达
我理解 Agent Runtime 不是模型，而是 Agent 任务执行引擎。在面试中，我会这样表达：
Agent Runtime 负责组织模型调用、工具调用、状态推进、错误处理、Trace 和结果生成。它位于系统中心，向上接收用户请求和会话上下文，向下调度工具系统、工作区、Trace 和评测。和普通 LLM 应用相比，Agent Runtime 更关注任务是否持续推进、失败是否可恢复、过程是否可观测、结果是否可评估。
在生产级 Agent 中，Runtime 是连接 LLM 能力和工程系统的核心层。LLM 负责推理和生成，但任务的状态管理、工具的权限控制、错误的恢复策略、执行的成本统计，都是 Runtime 的职责。一个没有 Runtime 的 Agent 系统，只是一个能调用工具的 chatbot；有了 Runtime，它才是一个可控、可观测、可评估的任务执行系统。
如果面试官追问 Runtime 和 Workflow 的区别，我会说：Workflow 更偏预定义流程，适合确定性高的业务场景；Runtime 更偏动态任务执行引擎，适合需要模型动态推理和决策的 Agent 任务。在复杂系统里，二者可以结合——用 Workflow 定义大框架，用 Runtime 处理动态逻辑。
后续 TODO
- 补充 Runtime 状态机示例，展示任务状态的完整生命周期。
- 补充 Runtime 与 LangGraph 的关系，说明 LangGraph 如何实现 Runtime 的部分能力。
- 补充 Runtime 与 Agent Trace 的联动，展示 Trace 如何记录 Runtime 的每一步执行。
- 补充多 Agent Runtime 的任务调度示例，说明多个 Agent 如何共享和协调执行。