Agent Memory 应该放在 Runtime 还是 Application？ Agent Memory 是个很容易被讲乱的词。 有的人说 memory，就是把聊天记录存起来。 有的人说 memory，是向量库。 有的人说 memory
LangGraph 到底是不是 Agent Runtime？ 这个问题最近很容易吵起来。 有人说 LangGraph 就是 Agent Runtime。 有人说它只是 workflow graph。 也有人说 Runtime 这个词被框架营
Agent Runtime 和 Workflow Engine 有什么区别？ 很多人第一次做 Agent 系统，会问： 既然 Temporal、Step Functions、Airflow、Dagster 这类 workflow engin
生产级 Agent 上线前必须检查的 50 件事 前面我发布了 Production Agent Checklist v1.0。 那是一份模块级清单。 今天这篇更像上线门禁。 如果一个 Agent 要进入真实用户环境，尤其是能读文件、写文件
Sandbox 应该属于 Harness 还是 Runtime？ 这个问题看起来像架构洁癖。 其实不是。 你把 Sandbox 放错位置，后面权限、审批、恢复、trace 都会跟着乱。 我的答案是： Sandbox 的执行环境属于 Harn
Agent Framework 会被模型原生 Tool Use 淘汰吗？ 会。 但只会淘汰一部分。 更准确地说：模型原生 Tool Use 会淘汰很多薄薄的 Agent Framework 胶水代码。 它淘汰不了 Runtime 责任。 这
从 Agent Loop 重构成 Agent Runtime 写到第 14 天，可以把前面几篇收一下了。 前面写了 100 行 Agent Loop。 随后加了 max steps。 再往后加了 token budget。 接着处理了 re
MCP 解决了什么，又没有解决什么？ MCP 很容易被讲成一句话： AI 时代的 USBC。 这个比喻有用，但也有点危险。 它会让人误以为：只要插上 MCP Server，Agent 就自然拥有了一套安全、可靠、可治理的工具系统。 不是。
我对生产级 Agent Runtime 的 10 条工程判断 写到第 21 天，可以把前面的问题收成一些判断。 这些不是金句。 金句没用。 真正有用的是：你在设计 Agent 系统、读开源项目、排线上事故时，能不能拿它们当检查项。 下面 1
Production Agent Checklist v1.0 发布 前 21 天，我一直在讲一个判断： Agent Runtime 不是框架名。 它是一组工程责任。 今天把这组责任整理成第一版清单： 这不是最终版。 也不是'照着打勾就永远
Agent Runtime Engineering v0.1 发布 今天把这个项目正式按 v0.1 的方式放出来。 仓库地址： https://github.com/zeeklog/agentruntimeengineering 先说清楚：
一个 Production Agent Runtime 到底需要什么？ 很多 Agent 架构图看起来都差不多。 这个图没错。它只是太薄了。 如果你的 Agent 只是演示'模型会调用工具'，这张图够用。如果它要进生产环境，要读用户数据、改
