中文 EN

系统设计 Lab

LLM agent 本质上是一个 reason-act loop —— 它的成本、latency、影响半径，都随每个任务的 step 数一起涨。

调节并发 session 数、每个任务的 tool call 与 step 数、LLM latency、context 大小，以及注册了多少 tool。设计会从单次 tool call 演进成 reason-act loop，再加上 memory 和 planning、sandbox 后面的并行 tool execution，最后变成带全链路 tracing 的 multi-agent orchestration。

阅读完整教程

分步讲解

一步一步把它想清楚

每一步都会设定下方的 workload —— 看着 diagram、meter 和各项 decision 随之变化。

常规演进场景

从左到右点击，就是预设的演示路径。每张卡片都会改变 workload 输入。

Workload

这些是输入，不是预设好的架构阶段。

推荐形态

当前架构路径
LLM agent orchestration 架构图 一个 LLM agent 系统的白板风格架构图：clients、跑着 reason-act loop 和 planner 的 agent runtime、带 sandboxed execution 的 tool registry、short-term 与 long-term vector memory 加上 LLM gateway，以及一条异步的 tracing 和 observability pipeline。 Clients Agent runtime Tool execution Memory + LLM Observability Client 任务 + 流式 Agent loop reason + act Planner 拆解任务 Tool registry schemas + routing Sandbox 隔离执行 Conversation short-term Vector memory long-term LLM gateway 模型调用 Tracing async spans Guardrails retry + 限额
Clients
Client 提交一个任务，并随 agent run 推进把过程流式返回
Agent runtime
Agent loop 驱动 decide-call-observe 这个 loop，并对每个任务执行 step 预算
Planner 把一个目标拆成子步骤，再把活儿串行排开或 fan out 出去
Tool execution
Tool registry 存放 tool schema，并从一堆 tool 里把模型 route 到对的那个
Sandbox 在隔离的 worker pool 里跑不可信的 tool 代码和副作用
Memory + LLM
Conversation 保存工作 context，并做 summarization 或截断
Vector memory 把事实 embed 后跨任务取回，超出 context window 的范围
LLM gateway 对每个 step 发出的大量模型调用做 batch、rate-limit 和 retry
Observability
Tracing 在 hot path 之外记录每个 step、tool call 和 token 成本
Guardrails 校验输出、对失败做 retry，并强制执行成本和 loop 上限

瓶颈

LLM call 量

串行任务 latency

Sandbox execution 负载

Context window 压力

Tool selection 复杂度

为什么会变

    决策权衡

    Agent loop / planning

    Tool registry + routing

    Sandboxed execution

    Memory（short / long-term）

    Context management

    Observability + guardrails

    有出处支撑的规则

    这些是模型背后那些经得起时间考验的 system design 论断。而 slider 的具体阈值，则被刻意标注为教学用的假设。

    已验证的规则

    reason 和 act 交错，让 agent 去迭代，而不是只答一次

    ReAct 把 reasoning trace 和 action 交错起来，让模型决策、行动、观察、再重复 —— 所有按 step 数计的成本和 latency 都源自这个 loop 结构。

    ReAct (Yao et al.)
    已验证的规则

    模型可以被教会在 generation 过程中调用 tool/API

    Toolformer 展示了模型自己学会何时、如何调用外部 tool，这正是为什么要有一个让模型去选的 tool registry，而不是写死的调用。

    Toolformer (Schick et al.)
    已验证的规则

    Tool-use API 定义了一个 registry，模型从这些 tool schema 里挑选

    生产环境的 tool calling 会把 JSON tool schema 传给模型；一个 prompt 里塞太多会让选择变差，这就是为什么 registry 一变大 routing 就重要起来。

    Anthropic tool use docs
    已验证的规则

    多 step 的 agent run 需要在每个 LLM 和 tool span 上做 tracing

    orchestration 的指南把 per-step tracing、retry 和 guardrail 当作一等公民，因为多 step 的 run 比单个请求难调试得多。

    OpenAI Agents SDK docs

    教学用假设

    • 串行任务 latency 假设各 step 一个接一个跑；并行 tool 缩短的是 wall-clock，不是 LLM call 总数。
    • per-lane 的 LLM 预算和 per-worker 的 sandbox 预算是保守的教学数字，不是 provider 的真实上限。
    • Context 压力是拿当前工作窗口对比一个舒适的单任务预算；long-term 记忆被建模成一条独立的 vector 路径。