最小 runtime 需要四类接口。 第一是 LLM Client。它隐藏不同模型供应商的请求格式，向 runtime 返回统一的 ModelResponse。 第二是 Message Store。它保存用户消息、模型消息、工具调用和工具结果。 第三是 Tool Registry。它告诉模型有哪些工
实现一个可取消的命令执行器： 支持 cwd； 支持 stdout/stderr 流式事件； 支持 timeout； 支持 AbortSignal； 支持最大输出限制； 返回 exit code、signal、duration； 中断后清理子进程。 用三个命令测试它：
从普通 LLM App 走向 Agent Runtime 工程化的系列教程导读，介绍学习路径、适合读者和全书实践闭环。
选择 Cline、Continue、aider、OpenHands、Codex CLI 中任意两个，用十问模板读源码。每个项目画一张执行链路图，并指出一个你认为可以改进的 runtime feature。
很多系统把重试当作可靠性的同义词。对 Agent Runtime 来说，重试之前先问一句：上一次有没有留下副作用？ 如果模型请求超时，重试通常安全。如果读文件失败，重试也通常安全。如果写文件执行到一半，重试可能覆盖用户改动。如果 npm install 被中断，重试前要检查 lockfile 和目录
写一个 miniagent： 支持 listfiles； 支持 readfile； 支持 shellreadonly； 支持最多 10 轮工具调用； 支持流式输出 runtime event； 非法 tool args 能被拦截并反馈给模型； 每次 run 输出一份简单 JSON trace。 任务
coding agent 迟早会执行 shell 命令。读目录、跑测试、安装依赖、生成文件、调用 CLI，都会经过子进程。这里必须谨慎，因为 shell 是副作用入口。 一个最低限度的命令执行器应当具备： 明确的工作目录； 环境变量白名单或脱敏策略； stdout/stderr 流式输出； 超时；
先把地基打准：Agent Runtime 到底比普通 LLM App 多负责了什么？ 很多团队第一次做 Agent，架构图都很相似：用户输入，调用模型，模型说要用工具，程序执行工具，再把结果塞回模型。这个图没有错，但它像把报社写成'记者采访，编辑发稿'。编辑部还要选题、核实、排版、审稿、撤稿、归档、
Eval 不只是测模型，也测 runtime 策略。例如： maxSteps=10 vs maxSteps=20； 工具描述短版 vs 长版； 旧历史保留 4 轮 vs 8 轮； 搜索结果返回 20 条 vs 50 条； 写入前是否强制计划； 工具失败后是否允许自动重试。 每次对比只改一个关键变量。
一个 Context Builder 至少接收： 它输出的不只是 messages，还应输出 debug report： debug report 很朴素，却能救命。没有它，你很难解释模型为什么没看见某个文件、为什么忘记用户刚才的限制、为什么把旧错误当成新事实。 debug report 建议保存到
模型 span： provider； model； prompt tokens； completion tokens； latency； finish reason； tool call 数量； 是否触发上下文降级； response id 或 continuation metadata。 工具 s
一个最小 Agent Loop 可以写成这样： 这段伪代码故意没有把逻辑藏进框架名里。runtime 的关键责任全在其中：构建上下文、调用模型、校验工具、审批权限、执行工具、记录观察、判断停止。如果其中任何一步被省略，demo 仍然可能成功，生产系统却会变脆。 图 12：Agent Runtime
Agent 失败常被粗暴归结为'模型不行'。这不专业。至少分成五类： 归因 典型现象 模型问题 推理错误、忽视观察结果、重复无效计划 工具问题 工具崩溃、返回格式错、输出不完整 权限问题 策略过严或过松，审批状态丢失 上下文问题 关键文件未注入，历史摘要误导 Runtime 问题 停止条件、重试、并
回看全书，我们走过了这条线： 1. 理解 Runtime 比 LLM App 多承担什么； 2. 补齐 Node 异步、取消、进程管理； 3. 写出最小 Agent Loop； 4. 把工具系统治理起来； 5. 给上下文建立预算和调试报告； 6. 接入 MCP 和 Provider Adapter；
