我对生产级 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 就没有排障价值。
检查项：
你的代码里 validate 在 execute 前吗？
permission decision 是否持久化？
tool result 是否同时进入 message store 和 trace？
checkpoint 是否覆盖 tool started / succeeded / uncertain？
4. Context Builder 比 prompt 更像生产模块
很多人把上下文问题当 prompt 问题。
我更愿意把它当 Runtime 问题。
Context Builder 决定本轮模型看见什么：
当前目标
安全策略
最近状态
相关文件
工具结果
历史摘要
可用工具
预算报告
它每次都应该输出 debug report。
否则模型没看见关键文件时，你只能说'它忘了'。
检查项：
每次 context build 有没有 estimated tokens？
有没有 included / summarized / dropped？
有没有 reasons？
用户显式约束是否永远高优先级？
5. Memory 不能做成垃圾桶
Agent Memory 最容易从'聪明'变成'污染'。
短期任务状态、checkpoint、用户偏好、业务事实、模型推断，不能塞进一张表。
我的分法是：
Run state：Runtime 管
Tool ledger：Runtime 管
Checkpoint：Runtime 管
User preference：Application 管
Business fact：业务系统管
进入上下文：Context Builder 管
长期 memory 的写入必须有来源、范围、置信度、过期和删除机制。
检查项：
模型推断的偏好是否需要用户确认？
业务事实是否来自权威系统？
影响行动的 memory 是否进 trace？
用户能否删除长期 memory？
6. MCP 解决连接，不解决治理
MCP 是好东西。
它把外部工具、资源、prompt 的发现和调用标准化了。
但 MCP Server 不是 Agent，MCP Client 也不是 Runtime。
MCP 工具进入系统后，仍然要过：
namespace
trust level
Tool Registry
Permission Gate
output policy
schema hash
tool ledger
trace
checkpoint
工具越容易接入，越要统一治理。
检查项：
未知 MCP Server 默认策略是什么？
两个 server 都叫 search 时如何命名？
tools/list 变化是否进入 trace？
非幂等 MCP 工具是否禁止自动重放？
7. Sandbox 不是'开了就安全'
Sandbox 至少有多层：
文件读写
网络
环境变量
进程隔离
资源限制
容器 / VM
审计日志
artifact export
我的分工是：
Harness 提供执行隔离。
Runtime 选择 sandbox profile。
Permission 决定能不能做。
Trace 记录在哪个边界里做。
Checkpoint 保证做完还能恢复。
如果团队只说'sandbox enabled'，但说不清隔离了什么，那还不够。
检查项：
是否禁止 workspace 外路径？
是否过滤环境变量？
网络默认是 deny 还是 open？
shell 是否只有只读白名单？
sandbox profile 是否进入 trace？
8. Checkpoint 不是保存聊天记录
聊天记录只能告诉模型刚才说了什么。
Checkpoint 要告诉 Runtime：
run 到哪个 step
哪些工具 planned / started / succeeded / failed / uncertain
哪些工具不可重放
哪些文件被改过
base hash / after hash 是什么
用户批准或拒绝了什么
budget 还剩多少
trace 写到哪里
长任务中断后，从头再来不是'浪费一点时间'。
可能是重复发邮件、重复下单、重复写文件、覆盖用户改动。
检查项：
工具 started 时是否写 ledger？
uncertain 状态有没有表示？
rollback 前是否校验当前文件 hash？
外部副作用是否有 compensation，而不是假装 undo？
9. Trace 不是日志，是事故证据链
聊天记录回答'说了什么'。
Trace 回答'系统做了什么'。
一次 Agent run 里，至少要能看到：
context.build
model.generate
tool.plan
permission.request
tool.execute
checkpoint.write
eval.replay
Trace 不应该只给平台看。
它应该能变成事故 replay 和 eval case。
检查项：
失败能否定位到模型、工具、上下文、权限、checkpoint？
完整工具输出是否用 artifact ref，而不是塞进 trace？
线上失败能否半自动转 eval 草稿？
10. Eval 要看行为，不只看最终回答
Agent 很会写漂亮总结。
但漂亮总结不能证明它真的完成任务。
Eval 要看：
读了哪些文件
调用了哪些工具
有没有 forbidden tool
是否请求了不该请求的权限
文件 diff 是否合理
测试是否通过
token / step / cost 是否超限
resume 是否重复副作用
真实模型 eval 会波动，所以 Runtime 逻辑要先用 mock provider 测。
检查项：
有没有 deterministic mock model？
有没有 must-not-call？
有没有 cost budget？
线上 trace 能否进入回归集？
PR 是否必须附 eval 结果？
最后：Runtime 不是框架名，是责任清单
你可以用 LangGraph。
可以用 OpenAI Agents SDK。
可以用 Vercel AI SDK。
可以用 MCP。
也可以自研。
这些都不是问题。
真正的问题是：
上下文谁管？
工具谁管？
权限谁管？
状态谁管？
恢复谁管？
trace 谁管？
eval 谁管？
成本谁管？
如果这些责任落地了，你就在写 Runtime。
如果这些责任没落地，框架名字再新，也只是 demo 套壳。
