LangGraph 到底是不是 Agent Runtime？ 这个问题最近很容易吵起来。 有人说 LangGraph 就是 Agent Runtime。 有人说它只是 workflow graph。 也有人说 Runtime 这个词被框架营
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确认，或者直接拒绝。 安全不是最后加的一层'确认弹窗'。它应该
现在可以动手了。把模型、工具和观察结果接成一个受控循环，这是 Agent Runtime 从'调用一次模型'走向'能执行任务'的第一步。 最小 Agent Loop 不追求复杂。它的目标很朴素：模型能根据当前上下文提出工具调用，runtime 能校验并执行工具，把观察结果写回消息历史，再决定继续还是停止。只要这个闭环清楚，后面的工具治理、上下文预算、权限审批
Agent 迟早要接外部工具，也迟早要面对多个模型供应商。本章讨论怎么接，以及怎么避免 runtime 被某个协议或某个 SDK 绑死。 前面几章里，工具都在本地注册，模型调用也被简化成一个 ModelProvider。这对入门很好，但真实系统不会停在这里。企业内部有文档库、浏览器、数据库、工单系统、设计工具、代码托管平台；模型侧也会同时接 OpenAI、A
这一章开始给工具'上户口'。在 demo 里，工具是几个函数；在 Agent Runtime 里，工具是一套能力治理系统。 模型负责提出'我想调用哪个工具、传什么参数'。Runtime 负责判断这件事是否存在、参数是否合法、风险是否可接受、是否需要用户确认、怎样执行、输出怎样进入上下文、失败怎样反馈。把这些责任都塞进一个 execute() 函数，是很多 A
写 Agent Runtime 之前，先补一门不太体面的课：异步任务、流和进程控制。 Agent Runtime 表面上是在调用模型，实际上是在管理一串可能很慢、会失败、有副作用、需要取消的异步任务。模型请求会流式返回，shell 命令会持续输出，文件系统可能被修改，用户可能中途按下取消，工具可能超时，子进程可能留下孤儿进程。没有扎实的 Node runti
《Agent Runtime 工程化：生产级 AI Agent 架构、运行时与工程实践》 这是一套面向工程师、技术负责人和 AI 产品架构师的 Agent Runtime 工程化读本。全书按章发布，从最小工具调用循环开始，逐步进入工具系统、上下文工程、MCP、权限安全、可恢复执行、trace、eval 和产品级实战。 读者不需要把它当成零散教程。更好的读法是按章推进：先建立
Agent 为什么必须有 Token Budget？ 上一篇我们给 Agent Loop 加了 maxSteps。 很多人做到这里，会松一口气：至少 Agent 不会无限跑了。 但只靠 maxSteps，控不住成本，也控不住上下文质量。 原
Agent Memory 越做越乱，本质上是 Runtime 问题 很多 Agent 项目做到第二个月，会开始加 memory。 一开始理由很正当： 然后大家很自然地做了一件事：把对话、文档、工具结果、用户偏好、项目摘要丢进向量库。 前几天
Agent 出错后，最怕只剩一句'模型没做好'。这句话既不能定位问题，也不能指导修复。可观测系统的任务，是把一次 Agent run 拆成可以追踪、可以复盘、可以转化为评测用例的证据链。 OpenTelemetry 的公开文档把 span 视为 trace 的基本操作单元：span 有名称、父 span、开始和结束时间、属性、事件、状态等信息。本书不要求读者
目标：实现可恢复执行。 功能范围： 每轮工具执行前创建 checkpoint； 文件修改保存 patch； 支持恢复文件状态； 支持恢复 session 状态； 进程崩溃后继续 run； 恢复后不重复执行高风险工具。 适合证明： 状态管理； 可恢复执行； 可靠性工程； coding agent 长任
我对生产级 Agent Runtime 的 10 条工程判断 写到第 21 天，可以把前面的问题收成一些判断。 这些不是金句。 金句没用。 真正有用的是：你在设计 Agent 系统、读开源项目、排线上事故时，能不能拿它们当检查项。 下面 1
学习 Agent Runtime，第一件事不是选框架，也不是抄一个 tool calling 示例。要先弄清楚：当一个 Agent 从'能回答'走向'能行动'，系统到底多承担了哪些责任。 很多团队第一次做 Agent，架构图都很相似：用户输入，调用模型，模型说要用工具，程序执行工具，再把结果塞回模型。这个图没有错，但它太薄。它像把报社写成'记者采访，编辑发稿
用户说'回滚'时，可能有三种意思： 回滚文件到某个 checkpoint； 回滚对话状态，让 Agent 忘记某段计划； 回滚外部副作用，例如撤销 API 操作。 Runtime 必须区分这三件事。文件 patch 可以回滚，对话状态可以恢复，外部副作用通常只能补偿，不能直接撤销。比如创建了 Git
读完本章，你应该能清楚解释 Agent、Workflow、Tool、Runtime 的边界；能说出 step、turn、run、trace、session、checkpoint 的区别；能解释一个 Agent 为什么会卡死、乱调工具、爆 token；也能看懂本书后续所有章节围绕的是同一个运行闭环，而
如何实现 Agent Checkpoint？ 长任务一定会中断。 浏览器刷新。进程崩溃。网络断开。模型请求失败。用户临时离开。工具超时。机器重启。 这些都不稀奇。 真正危险的是：Agent 中断后从头再来。 从头再来听起来只是浪费时间。实际
工具一旦进入 trace 和 eval，就不能随意改语义。比如 readfile 原来默认返回全文，后来默认只返回前 200 行；这会影响模型行为，也会影响 replay 结果。 版本演进的策略： 工具名稳定时，小改动写入 version 和 changelog； 输入 schema 增加可选字段通
写一个能演示的 Agent 很快。写一个能稳定跑的 Agent 很慢。慢在三件事上。 第一，模型输出不是普通函数返回值。它可能少字段、多字段、把 JSON 写坏、重复调用工具、误解工具描述，或者在工具失败后编一个像真的观察结果。Runtime 要把模型输出当作不可信输入处理。 第二，工具不是纯计算。
目标：给一个开源 coding agent 或你的 miniagent 增加 Eval Harness。 功能范围： 录制真实任务 trace； 从 trace 生成 eval case 草稿； 支持本地 replay； 输出成功率、失败类型、平均 token、平均耗时； CI 中设置回归门禁。 适
背压是很多 Agent Demo 不谈、生产系统绕不开的问题。工具输出可能非常大，例如 npm test 打出几万行日志，grep 搜索整个仓库，构建工具输出长堆栈。Runtime 不能把所有内容原样塞进模型上下文。 正确做法是分两层处理： 第一层是执行层限流。命令执行器记录完整日志到文件或 tra
