一个 Production Agent Runtime 到底需要什么？ 很多 Agent 架构图看起来都差不多。 这个图没错。它只是太薄了。 如果你的 Agent 只是演示'模型会调用工具'，这张图够用。如果它要进生产环境，要读用户数据、改
这一章开始给工具'上户口'：它们不能只是函数列表。 在 demo 里，工具是几个函数。在生产 Agent Runtime 里，工具是一套能力治理系统。它既要让模型知道'能做什么'，也要让 runtime 知道'什么能做、什么不能做、怎么做、失败了算什么、谁批准过、结果能不能进上下文'。
长任务跑久了，问题会变成一句话：有限的 context window 里，到底该放什么？ Agent Runtime 的上下文不是聊天记录的简单拼接。它更像一份交给模型的案卷：用户当前目标、必须遵守的约束、最近进展、关键文件、工具观察、失败记录、可用工具、当前计划。案卷太薄，模型会失忆；案卷太厚，成本上升，关键事实还可能被噪声挤掉。 上下文工程不是塞更多东西
入口包括 CLI 入口、IDE extension 激活入口、Web server 入口、worker 入口。入口读法： 找 package.json scripts 和 bin； 找 extension manifest； 找 server bootstrap； 找主 command handle
你不只是会 await，而是能解释异步任务如何取消、如何防泄漏、如何处理流式输出、如何把长日志变成模型可用的观察结果。做到这里，才有资格写第三章的最小 Agent Loop。
长对话中，不能无限保留全部消息。常用策略是： 最近 N 轮完整保留； 更早历史压缩成 session summary； 用户显式约束永久置顶； 已完成任务结果写入 memory； 失败原因和决策记录保留为 run notes。 滚动摘要有一个风险：摘要会丢细节，甚至引入轻微偏差。因此摘要应该标注来源
Agent Framework 会被模型原生 Tool Use 淘汰吗？ 会。 但只会淘汰一部分。 更准确地说：模型原生 Tool Use 会淘汰很多薄薄的 Agent Framework 胶水代码。 它淘汰不了 Runtime 责任。 这
token budget 不只是技术限制，也是产品预算。一次 run 里，token 影响延迟、成本和可靠性。越长的上下文越不一定越好，因为模型注意力会被稀释，缓存命中也可能下降。 可以把上下文分为六层： 1. 系统与开发者指令； 2. 用户当前意图； 3. 近期完整对话； 4. 当前任务状态和计划
你应该能解释为什么 Agent 不能直接执行任意 shell；能为 MCP 工具设计权限审批策略；能区分 schema 校验、权限策略和用户确认；能保证恢复执行后不会重复越权。
回滚不丢对话上下文；恢复不重复执行高风险工具；文件状态和 session 状态能对应到同一个 checkpoint；trace 可以说明恢复从哪一步开始。做到这里，runtime 才从脚本接近系统。
从 Agent Loop 重构成 Agent Runtime 写到第 14 天，可以把前面几篇收一下了。 前面写了 100 行 Agent Loop。 随后加了 max steps。 再往后加了 token budget。 接着处理了 re
高风险工具执行前，应给用户看到 preview。 写文件要给 diff preview；执行命令要给 command preview；联网请求要给域名、方法、数据范围；安装依赖要给包名、版本、lockfile 影响；数据库操作要给目标库、表、迁移摘要。 图 42：工具系统的风险矩阵。风险来自能力、参
学习 Agent Runtime，第一件事不是选框架，也不是抄一个 tool calling 示例。要先弄清楚：当一个 Agent 从'能回答'走向'能行动'，系统到底多承担了哪些责任。 很多团队第一次做 Agent，架构图都很相似：用户输入，调用模型，模型说要用工具，程序执行工具，再把结果塞回模型。这个图没有错，但它太薄。它像把报社写成'记者采访，编辑发稿
这一章开始给工具'上户口'。在 demo 里，工具是几个函数；在 Agent Runtime 里，工具是一套能力治理系统。 模型负责提出'我想调用哪个工具、传什么参数'。Runtime 负责判断这件事是否存在、参数是否合法、风险是否可接受、是否需要用户确认、怎样执行、输出怎样进入上下文、失败怎样反馈。把这些责任都塞进一个 execute() 函数，是很多 A
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确认，或者直接拒绝。 安全不是最后加的一层'确认弹窗'。它应该
为 miniagent 增加四个工具： editfile：写文件，但执行前必须生成 diff preview； applypatch：应用 patch，只允许 workspace 内路径； runcommand：执行命令，先做风险分类； searchcode：基于 rg 的只读搜索。 给每个工具加
没有最大步数的 Agent Loop 是一个事故邀请函。模型可能重复读同一个文件，也可能在工具失败后不断尝试相同参数。最小 runtime 必须有 maxSteps。 但 maxSteps 只是硬刹车，还需要软停止条件： 模型返回 final answer； 模型没有工具调用； 连续 N 次工具调用
用户审批不能只当 UI 事件。对 runtime 来说，它是一条系统事实，每次都应写入 audit log： 恢复执行时，这些记录尤其重要。已经被拒绝的危险工具，不能因为进程重启就再次自动执行。已经批准的一次性操作，也不应无限期复用授权。
工具通常分散在文件系统、终端、浏览器、搜索、编辑、MCP 等模块里。读工具时问： 工具 schema 在哪里定义？ 描述如何送给模型？ 参数在哪里校验？ 执行前是否有 preview？ 用户确认如何表达？ 失败如何反馈给模型？ 输出如何截断？ 如果一个项目有 MCP，继续问： MCP Server
能力越大，边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具，风险也来自工具。一个不会调用工具的模型，最多说错话；一个能执行命令、写文件、联网、访问数据库的 Agent，可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住，而是让它在明确边界内做事；越过边界时，停下来请人确
