我对生产级 Agent Runtime 的 10 条工程判断
写到第 21 天，可以把前面的问题收成一些判断。
这些不是金句。
金句没用。
真正有用的是：你在设计 Agent 系统、读开源项目、排线上事故时，能不能拿它们当检查项。
下面 10 条，是我目前对生产级 Agent Runtime 的基本判断。
1. Agent Demo 的终点，才是 Runtime 的起点
一个 Agent Demo 通常只证明三件事：
模型能接收上下文
模型能输出 tool call
程序能执行工具并返回结果
这已经够演示了。
但生产环境会继续问：
工具参数错了怎么办？
工具执行一半崩了怎么办？
用户拒绝权限后怎么办？
模型重复调用同一工具怎么办？
输出太大怎么办？
任务中断后能不能恢复？
这次失败到底是谁的责任？
如果这些问题没有答案，demo 越漂亮，上线越危险。
检查项：
你的系统有没有 runId、stepId、toolCallId？
每一步失败有没有结构化原因？
用户取消、权限拒绝、maxSteps、budget exhausted 是否能区分？
2. Tool Calling 是接口能力，不是安全边界
模型会 function calling，不等于工具系统安全。
模型返回：
{"name":"write_file","arguments":{"path":"src/a.ts","content":"..."}}
这只是行动计划。
Runtime 还要判断：
工具是否存在
schema 是否合法
path 是否越界
是否要 diff preview
用户是否批准
写入前是否 checkpoint
写入后如何 rollback
Tool call 不能直接等于 function call。
检查项：
所有工具是否经过 Tool Registry？
是否有 risk、timeout、outputPolicy、sideEffects？
模型返回非法参数时，是崩溃还是 observation？
3. Runtime 的主循环顺序不能乱
我现在很看重这条顺序：
context -> model -> validate -> permission -> execute -> observe -> checkpoint
它不是伪代码装饰。
先执行再审批，权限系统就是摆设。
先写消息再校验，模型幻觉工具会污染历史。
工具执行后不 checkpoint，恢复时不知道副作用发生到哪里。
只记录最终答案，trace 就没有排障价值。