Agent 迟早要接外部工具，也迟早要面对多个模型供应商。本章讨论怎么接，以及怎么避免 runtime 被某个协议或某个 SDK 绑死。 前面几章里，工具都在本地注册，模型调用也被简化成一个 ModelProvider。这对入门很好，但真实系统不会停在这里。企业内部有文档库、浏览器、数据库、工单系统、设计工具、代码托管平台；模型侧也会同时接 OpenAI、A
写 Agent Runtime 之前，先补一门不太体面的课：异步任务、流和进程控制。 Agent Runtime 表面上是在调用模型，实际上是在管理一串可能很慢、会失败、有副作用、需要取消的异步任务。模型请求会流式返回，shell 命令会持续输出，文件系统可能被修改，用户可能中途按下取消，工具可能超时，子进程可能留下孤儿进程。没有扎实的 Node runti
这一章开始给工具'上户口'。在 demo 里，工具是几个函数；在 Agent Runtime 里，工具是一套能力治理系统。 模型负责提出'我想调用哪个工具、传什么参数'。Runtime 负责判断这件事是否存在、参数是否合法、风险是否可接受、是否需要用户确认、怎样执行、输出怎样进入上下文、失败怎样反馈。把这些责任都塞进一个 execute() 函数，是很多 A
《Agent Runtime 工程化：生产级 AI Agent 架构、运行时与工程实践》 这是一套面向工程师、技术负责人和 AI 产品架构师的 Agent Runtime 工程化读本。全书按章发布，从最小工具调用循环开始，逐步进入工具系统、上下文工程、MCP、权限安全、可恢复执行、trace、eval 和产品级实战。 读者不需要把它当成零散教程。更好的读法是按章推进：先建立
为什么你的 Agent Demo 永远上不了生产？ 写一个 Agent Demo 真的不难。 一个模型，几个 tools，再加一个 while loop。模型说要调用工具，你执行工具；工具返回结果，你再塞回模型。顺利的时候，二三百行代码就能
第十二章 hermesagent 产品级实战 前面十一章讲的是方法。最后这一章，我们把方法放进一个真实开源项目里。 本章选择 NousResearch/hermesagent。原因不是它'功能多'这么简单，而是它已经把 Agent Runtime 从一个工具调用循环扩展成了产品系统：CLI/TUI、Desktop、messaging gateway、多 pr
长任务跑久了，问题会变成一句话：有限的 context window 里，到底该放什么？ Agent Runtime 的上下文不是聊天记录的简单拼接。它更像一份交给模型的案卷：用户当前目标、必须遵守的约束、最近进展、关键文件、工具观察、失败记录、可用工具、当前计划。案卷太薄，模型会失忆；案卷太厚，成本上升，关键事实还可能被噪声挤掉。 上下文工程不是塞更多东西
学习 Agent Runtime，第一件事不是选框架，也不是抄一个 tool calling 示例。要先弄清楚：当一个 Agent 从'能回答'走向'能行动'，系统到底多承担了哪些责任。 很多团队第一次做 Agent，架构图都很相似：用户输入，调用模型，模型说要用工具，程序执行工具，再把结果塞回模型。这个图没有错，但它太薄。它像把报社写成'记者采访，编辑发稿
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确认，或者直接拒绝。 安全不是最后加的一层'确认弹窗'。它应该
过去 30 天，我对 Agent Runtime 的理解变化 这 30 天，我一直在写同一个主题： 一开始，我以为要做的是'把 Agent Runtime 这个概念讲清楚'。 写到后面，我发现更重要的不是概念。 是证据。 一个 Agent
我为什么写《Agent Runtime 工程化》 过去几天，我连续写了 6 篇关于 Agent Runtime 的文章。 先讲 Demo 为什么上不了生产，再讲 Agent Loop、Harness、Runtime 的边界。然后写 Retr
现在可以动手了。把模型、工具和观察结果接成一个受控循环，这是 Agent Runtime 从'调用一次模型'走向'能执行任务'的第一步。 最小 Agent Loop 不追求复杂。它的目标很朴素：模型能根据当前上下文提出工具调用，runtime 能校验并执行工具，把观察结果写回消息历史，再决定继续还是停止。只要这个闭环清楚，后面的工具治理、上下文预算、权限审批
《Agent Runtime 工程化：从工具调用循环到可恢复执行系统》电子版系列完整目录，收录系列导读、12 章导读、全部小节与附录链接。
Agent 出错后，最怕只剩一句'模型没做好'。这句话既不能定位问题，也不能指导修复。可观测系统的任务，是把一次 Agent run 拆成可以追踪、可以复盘、可以转化为评测用例的证据链。 OpenTelemetry 的公开文档把 span 视为 trace 的基本操作单元：span 有名称、父 span、开始和结束时间、属性、事件、状态等信息。本书不要求读者
长任务一定会中断。问题是：失败后怎么继续，而不是重来？ Agent Runtime 一旦进入真实工程任务，就会遇到长运行：改多个文件、跑多轮测试、安装依赖、查文档、等待用户确认。浏览器刷新、进程崩溃、网络超时、模型失败、用户临时离开，都可能打断 run。如果没有 checkpoint，Agent 只能从头再来；从头再来又可能重复执行副作用。 可恢复执行系统要
A 术语表 Agent：根据目标和上下文选择下一步行动的执行体。 Agent Runtime：负责模型调用、工具调用、上下文、权限、状态、观测、恢复、评测和成本治理的运行系统。 Tool Calling：模型输出结构化工具调用，应用执行工具并把结果返回模型的接口能力。 Tool Registry：工具定义、schema、风险等级、执行器、输出策略和版本的注册
Production Agent Checklist v1.0 发布 前 21 天，我一直在讲一个判断： Agent Runtime 不是框架名。 它是一组工程责任。 今天把这组责任整理成第一版清单： 这不是最终版。 也不是'照着打勾就永远
从普通 LLM App 走向 Agent Runtime 工程化的系列教程导读，介绍学习路径、适合读者和全书实践闭环。
读到这里，读者不需要被带回课堂作业。商业化技术书应该把读者送到下一段真实工作的入口。本章要做的事，是把前面十章拆成几条可以长期深挖的能力路线，并说明每条路线怎样从学习样例走向真实项目。 这几条路线不是互斥选项。它们像 Runtime 的几根梁：评测、上下文、工具协议、权限安全、恢复、观测和产品化。你可以先从最贴近自己工作的问题开始，但最终要把它们连成一套系统
我对生产级 Agent Runtime 的 10 条工程判断 写到第 21 天，可以把前面的问题收成一些判断。 这些不是金句。 金句没用。 真正有用的是：你在设计 Agent 系统、读开源项目、排线上事故时，能不能拿它们当检查项。 下面 1
