INTERACTIVE AGENT RUNTIME LAB

Agent Planning → Execution → Tool Calling 循环

用“查询北京明天天气并给出出行建议”的 Mock 任务，逐步观察 Agent 从输入结构化、规划、创建 Run、执行 Step、调用工具、写入 Observation、动态重规划，到生成最终答案的完整循环。

9 条职责泳道确定性状态机AgentRun JSON DiffPlan v1 → v2面试与架构学习

0 / 15

完整泳道交互图

等待开始

用户

01 · 用户提交问题北京明天天气如何？给出出行建议。

Agent API

02 · Agent API输入结构化生成 UserInput

15 · Agent API返回最终答案响应携带 runId

Planner

03 · Planner生成 ExecutionPlan v1创建 3 个稳定 Step

Workflow Runtime

04 · Workflow Runtime创建 Runcreated → running

14 · Workflow Runtime完成 Runrunning → completed

Executor

05 · Executor选择 step_weatherpending → running

09 · Executor完成 step_weatherrunning → completed

10 · Executor选择 step_advicepending → running

13 · Executor执行 step_answer汇总事实与建议

Tool Registry

06 · Tool Registry校验并路由工具weather.get_forecast

External Tool

07 · External Tool返回天气数据22–30°C，阵雨概率 60%

State Store

08 · State Store写入 Observationstep_weather.output 更新

12 · State Store写入建议结果step_advice completed

LLM

11 · LLM生成出行建议携伞、避开午后强降雨

当前步骤

idle

点击“下一步”开始

系统会同步高亮对应泳道，并展示执行状态与 AgentRun 数据变化。

为什么这样设计

将 Agent 的概率决策与 Runtime 的确定性控制分开，才能可靠地暂停、重试、恢复和审计。

运行状态

State Machine

run.statuscreated

step.status—

plan.versionv1

currentStepId—

events0

observations0

AgentRun 实时 JSON

变化字段高亮

{
  "runId": "run_20260727_001",
  "status": "created",
  "input": {
    "raw": "北京明天天气如何？给出出行建议。",
    "intent": "weather_travel_advice",
    "entities": {
      "location": "北京",
      "date": "tomorrow"
    }
  },
  "plan": {
    "goal": "获得天气并生成出行建议",
    "version": 1,
    "steps": [
      {
        "id": "step_weather",
        "type": "tool",
        "dependencies": [],
        "status": "pending",
        "input": {
          "tool": "weather.get_forecast",
          "location": "北京",
          "date": "tomorrow"
        }
      },
      {
        "id": "step_advice",
        "type": "llm",
        "dependencies": [
          "step_weather"
        ],
        "status": "pending"
      },
      {
        "id": "step_answer",
        "type": "llm",
        "dependencies": [
          "step_advice"
        ],
        "status": "pending"
      }
    ]
  },
  "context": {
    "location": "北京",
    "observations": []
  },
  "events": []
}

职责分层：LLM 决策，Runtime 控制

Planner提出结构化计划

Workflow Runtime维护状态机

Executor执行当前步骤

Tool Registry校验与路由

State Store持久化事实

六个关键设计问题

Interview Notes

问题核心解释不这样做的后果

Plan 为什么不能只是一段自然语言？

自然语言适合表达意图，不适合作为可执行协议。结构化 Plan 才能校验依赖、记录状态、调度、重试和版本化。

无法精确知道执行到哪一步，也无法安全恢复。

为什么 Step 需要稳定 ID？

稳定 ID 是事件、日志、输出、重试、依赖边和 checkpoint 的关联键。

重规划后无法判断哪个步骤被复用、替换或新增。

为什么工具结果必须写回 State？

Observation 是后续决策的事实输入，也是恢复、审计和最终答案的依据。

结果只停留在一次 LLM 上下文里，中断后即丢失。

为什么 Runtime 而不是 LLM 控制流程？

LLM 是概率决策器；Runtime 是确定性状态机，负责权限、超时、重试、幂等、并发和持久化。

流程不可预测，难以生产化。

为什么重规划要增加 plan.version？

版本号明确表示执行图变化，可追踪 v1 的失败原因和 v2 的替代策略。

历史计划被覆盖，无法解释系统为何改变路径。

为什么执行状态和业务结果必须分开？

completed 只表示执行结束，不代表 output 一定满足业务质量，结果仍需单独校验。

会把成功调用但返回空数据误判为业务成功。