过去 30 天，我对 Agent Runtime 的理解变化
这 30 天，我一直在写同一个主题：
Agent Runtime 工程化。
一开始，我以为要做的是'把 Agent Runtime 这个概念讲清楚'。
写到后面，我发现更重要的不是概念。
是证据。
一个 Agent 系统出了问题，如果你只能说：
模型不稳定。
上下文太长。
工具没调好。
可能是框架问题。
那说明 Runtime 还不够硬。
这 30 天最大的变化，就是我越来越不想用抽象词解释抽象词。
我更关心：
trace 里能不能看到？
checkpoint 里有没有记录？
eval 能不能复现？
用户能不能理解？
发布前能不能检查？
变化一：不再争'谁第一个讲 Runtime'
最开始做路线设计时，有个判断很重要：
中文技术社区里，Agent Runtime 已经不是没人讲的概念。
所以这本书不能打：
国内第一本讲 Agent Runtime 的书。
这个说法风险高，也没必要。
更准确的位置是：
系统讲清楚一个 Agent 如何从 Demo 进入生产环境。
这句话后面变成整套内容的主线：
Agent Loop → Harness → Runtime → Sandbox → Production
现在回头看，这个定位是对的。
概念可以被很多人讲。
但工程路线要能连续讲 30 天，还不能散。
变化二：Runtime 不是'更大的 Loop'
从 100 行 Agent Loop 写到重构成 Agent Runtime 时，我的重点变了。
这里有个关键转变：
Loop 是控制流。
Runtime 是执行系统。
一开始你会觉得：
while loop
tool calls
max steps
messages
这就是 Agent。
但只要往里加：
token budget
retry
idempotency
checkpoint
permission
trace
eval
那个 while loop 很快就会变成一团东西。
现在我更愿意把 Runtime 看成一组责任边界：
ContextBuilder
ModelProvider
ToolRegistry
PermissionGate
ToolExecutor
CheckpointStore
TraceSink
EvalHarness
BudgetPolicy
Loop 还在。
但它不应该吞掉一切。
变化三：Tool Calling 越强，Runtime 越重要
写'Agent Framework 会不会被模型原生 Tool Use 淘汰'时，我的判断变清楚了。
模型会越来越会调用工具。
官方 SDK 会越来越好用。
很多薄框架会被压缩。
但这不会削弱 Runtime。
恰好相反。
模型越会行动，边界越重要。
因为 tool call 只是行动计划。
Runtime 要决定：
这个行动能不能执行
谁批准
在哪个 sandbox
输出怎么回灌
失败怎么记录
副作用怎么恢复
成本怎么算
以前模型不会用工具，最多答错。