过去 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
输出怎么回灌
失败怎么记录
副作用怎么恢复
成本怎么算
以前模型不会用工具,最多答错。

