一个 Production Agent Runtime 到底需要什么？
很多 Agent 架构图看起来都差不多。
User
↓
LLM
↓
Tools
↓
Result
这个图没错。它只是太薄了。
如果你的 Agent 只是演示'模型会调用工具'，这张图够用。如果它要进生产环境，要读用户数据、改代码、查数据库、发请求、执行命令、处理权限、控制成本、支持恢复和事故复盘，这张图就会把真正的问题藏起来。
我更愿意把生产级 Agent Runtime 画成这样：
User / Product / Workflow
↓
┌──────────────────────────────────────────────────┐
│ Agent Runtime │
│ │
│ Router / Session / Run State │
│ Loop Controller │
│ Context Builder │
│ Model Provider Adapter │
│ Tool Registry / Tool Executor │
│ Permission Gate / Policy Engine │
│ Message Store / Memory │
│ Checkpoint / Recovery / Rollback │
│ Trace / Metrics / Cost │
│ Eval Harness / Replay / CI │
└──────────────────────────────────────────────────┘
↓ ↑
MCP / 外部工具 人工审批 / 证据面板
这不是为了把架构图画复杂。是因为生产环境真的会问这些问题。
先说一句实话：框架不是答案
LangGraph 官方文档会强调 durable execution、human-in-the-loop、persistence、streaming 这些能力。OpenAI Agents SDK 也提供 tracing、sessions、guardrails、handoffs 和 human approval flows。MCP 规范把工具暴露、工具调用和用户授权放进协议讨论里。OWASP 在 LLM 应用安全风险里也把 Excessive Agency 列成问题：Agent 被授予过多权限、动作过宽、缺少确认，都会出事。
这些材料说明一件事：社区已经不再只讨论'怎么让模型调用函数'。真正的焦点在执行系统。
但你不能把某个框架的功能列表直接当成自己的架构。生产级 Runtime 的设计要从责任出发。
下面这 10 个模块，是我认为最小可讨论的生产级骨架。
1. Router / Session / Run State
Agent 不是一次函数调用。
你需要知道这次请求属于哪个用户、哪个 session、哪个 run、哪个 turn、哪个 step。没有这些 id，后面的 trace、checkpoint、permission、eval 都串不起来。
最小结构可以是：
type RuntimeIds = {
sessionId: string;
runId: string;
turnId: string;
stepId: string;
traceId: string;
?: ;
};