过去 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
输出怎么回灌
失败怎么记录
副作用怎么恢复
成本怎么算
以前模型不会用工具，最多答错。
现在模型会用工具，就可能改错文件、发错请求、重复下单、烧掉预算。
能力变强之后，治理需求不会消失。
变化四：MCP 的价值和边界都要讲
写 MCP 时，我刻意没有把它写成'万能标准'。
MCP 很有价值。
它解决连接问题：
Host
Client
Server
resources
prompts
tools/list
tools/call
但它不自动解决治理问题：
trust level
namespace
tool exposure
permission
sandbox
schema drift
tool ledger
checkpoint
trace
eval
这个边界越讲越重要。
工具越容易接入，Runtime 越要统一治理。
否则 MCP 会把工具接入成本降下来，也把误调用和越权风险一起带进来。
变化五：Memory 最怕'聪明地记错'
写 Memory 时，我对'Agent Memory'的警惕更强了。
失忆很烦。
但记错更危险。
一条被模型错误总结出来的长期偏好，可能影响很多次后续行动。
所以 memory 不能做成垃圾桶。
我现在会先分：
Run state：Runtime 管
Tool ledger：Runtime 管
Checkpoint：Runtime 管
User preference：Application 管
Business fact：业务系统管
进入上下文：Context Builder 管
向量库只是索引。
不是 memory 架构本身。
变化六：Sandbox 不是一个勾选框
写 Sandbox 时，我越来越不喜欢这句话：
我们开了 sandbox。
它听起来让人放心。
但不够。
要继续问：
文件能读哪里？
能写哪里？
网络默认开还是关？
环境变量怎么过滤？
是否允许子进程？
是否容器隔离？
是否能导出 patch？
sandbox profile 有没有进 trace？
现在我的分工更明确：
执行环境属于 Harness。
策略决策属于 Runtime。
Permission 决定能不能做。
Sandbox 限制最多能做什么。
Trace 记录当时在哪个边界里做。
变化七：Trace 是这本书的硬骨头
写失败 trace 案例时，我感觉这本书的真正骨头出来了。
如果一篇文章能把'模型不稳定'拆成：
Context Builder 没带测试文件
模型过度泛化
shell 工具正常返回失败
Runtime 没有阻止失败测试后的成功 final
eval 缺少 mustReadFiles 断言
那它就不是概念文章了。
它开始接近工程。
Trace 的价值是把失败变成资产。
没有 trace，事故只会变成争论。
有 trace，事故可以变成 eval。
变化八：Checklist 不是形式主义，前提是会影响发布
前面写了两份清单。
一份是模块级 checklist。
一份是 50 项 release gate。
写完后我更确定：清单不是为了显得专业。
清单只有在会影响发布时才有用。
如果某一项永远不会阻止上线，那它就是装饰。
真正的 checklist 应该进入：
README
PR 模板
release note
eval report
incident review
上线审批
生产级 Agent 不是永不失败。
是失败后能被理解、被停止、被恢复。
变化九：这本书不能只写'我的理解'
招募 Early Reader 时，我其实是在承认一件事：
Agent Runtime 不适合闭门造车。
它一定要从真实任务里长出来。
我一个人能写书稿和 demo。
但真实的坑来自读者：
你们的 Agent 为什么重复调工具？
你们的 MCP 接入在哪里失控？
你们的审批弹窗用户看不看？
你们的 trace 能不能定位根因？
你们的 eval 怎么处理 flaky？
这些反馈会比我自己多写十篇概念文更重要。
变化十：冷启动不是每天发文，是连续建立信任
这 30 天的内容大概经历了四段：
第一阶段：先让读者相信这是一个真实工程问题。
第二阶段：用小代码讲 Loop、预算、重试、幂等、checkpoint。
第三阶段：处理框架、MCP、Memory、Sandbox、Workflow 等争议边界。
第四阶段：收成判断、清单、试读、trace 案例、v0.1、Early Reader。
如果只看单篇，可能就是一篇文章。
连起来看，它在做一件事：
让读者逐渐相信，这不是一个空概念。
它有问题、有代码、有事故、有清单、有发布路线。
这才是技术书冷启动该做的事。
接下来
下一阶段要少写一点'观点'，多补一点'工程资产'。
优先级大概是：
1. 仓库 README 第一版
2. Production Agent Checklist 文档
3. Agent Loop 示例代码
4. Tool Runtime 示例代码
5. Trace Writer + Evidence Panel 示例
6. Early Reader 反馈入口
文章可以继续写。
但不能只写文章。
仓库要开始长出东西。
最后
过去 30 天，我对 Agent Runtime 的理解从一句话变成了一组检查：
能不能控制行动？
能不能解释失败？
能不能恢复状态？
能不能验证改动？
能不能让用户理解边界？
如果不能，那就还只是 demo。
如果能，才开始接近 production。
