
《Agent Runtime 工程化》第二章 TypeScript / Node Runtime 基础:2.7 动手任务
实现一个可取消的命令执行器: 支持 cwd; 支持 stdout/stderr 流式事件; 支持 timeout; 支持 AbortSignal; 支持最大输出限制; 返回 exit code、signal、duration; 中断后清理子进程。 用三个命令测试它:

实现一个可取消的命令执行器: 支持 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 和目录

Agent Runtime Engineering v0.1 发布 今天把这个项目正式按 v0.1 的方式放出来。 仓库地址: https://github.com/zeeklog/agentruntimeengineering 先说清楚:

写一个 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 条; 写入前是否强制计划; 工具失败后是否允许自动重试。 每次对比只改一个关键变量。

为什么你的 Agent Demo 永远上不了生产? 写一个 Agent Demo 真的不难。 一个模型,几个 tools,再加一个 while loop。模型说要调用工具,你执行工具;工具返回结果,你再塞回模型。顺利的时候,二三百行代码就能

Production Agent Checklist v1.0 发布 前 21 天,我一直在讲一个判断: Agent Runtime 不是框架名。 它是一组工程责任。 今天把这组责任整理成第一版清单: 这不是最终版。 也不是'照着打勾就永远

一个 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;

一个 Production Agent Runtime 到底需要什么? 很多 Agent 架构图看起来都差不多。 这个图没错。它只是太薄了。 如果你的 Agent 只是演示'模型会调用工具',这张图够用。如果它要进生产环境,要读用户数据、改