
《Agent Runtime 工程化》第九章 可观测与 Trace:9.5 本地 trace JSON
入门阶段可先用本地 JSONL: 每个 run 写入: 后续再接 OpenTelemetry、LangSmith 或自建 UI。先把语义记对,再追求漂亮 dashboard。

入门阶段可先用本地 JSONL: 每个 run 写入: 后续再接 OpenTelemetry、LangSmith 或自建 UI。先把语义记对,再追求漂亮 dashboard。

用户审批不能只当 UI 事件。对 runtime 来说,它是一条系统事实,每次都应写入 audit log: 恢复执行时,这些记录尤其重要。已经被拒绝的危险工具,不能因为进程重启就再次自动执行。已经批准的一次性操作,也不应无限期复用授权。

用户说'回滚'时,可能有三种意思: 回滚文件到某个 checkpoint; 回滚对话状态,让 Agent 忘记某段计划; 回滚外部副作用,例如撤销 API 操作。 Runtime 必须区分这三件事。文件 patch 可以回滚,对话状态可以恢复,外部副作用通常只能补偿,不能直接撤销。比如创建了 Git

coding agent 迟早会执行 shell 命令。读目录、跑测试、安装依赖、生成文件、调用 CLI,都会经过子进程。这里必须谨慎,因为 shell 是副作用入口。 一个最低限度的命令执行器应当具备: 明确的工作目录; 环境变量白名单或脱敏策略; stdout/stderr 流式输出; 超时;

长任务一定会中断。问题是:失败后怎么继续,而不是重来? Agent Runtime 一旦进入真实工程任务,就会遇到长运行:改多个文件、跑多轮测试、安装依赖、查文档、等待用户确认。浏览器刷新、进程崩溃、网络超时、模型失败、用户临时离开,都可能打断 run。如果没有 checkpoint,Agent 只能从头再来;从头再来又可能重复执行副作用。 可恢复执行系统要

第八章 Checkpoint、Resume、Rollback:8.2 patchbased checkpoint 对 coding agent 来说,文件系统状态是第一等公民。最轻量的做法是 patchbased checkpoint:每次工具执行前后记录 diff。 优点: 存储小; 容易审计;

说 Agent '变好了'很容易。证明它变好了,要靠 eval。 Agent 产品很容易陷入'今天试了几个问题,感觉不错'的幻觉。工程系统不能靠感觉上线。Eval Harness 要把真实任务变成可重复的测试,把 trace 变成回归样本,把 prompt、工具和 runtime 策略的变化变成可比

说 Agent '变好了'很容易。证明它变好了,要靠 eval。 Agent 产品很容易陷入'今天试了几个问题,感觉不错'的幻觉。工程系统不能靠感觉上线。Eval Harness 的任务,是把真实任务变成可重复的测试,把 trace 变成回归样本,把 prompt、工具、上下文、权限和 runtime 策略的变化变成可比较的数据。 截至 2026 年 8 月

第八章 Checkpoint、Resume、Rollback:8.3 gitbased checkpoint 另一种做法是借助 git。每个 step 或关键写入点创建临时 commit、stash、worktree 或 patch 文件。 gitbased 的优点是成熟、可审计、适合代码项目。缺点

本书统一使用以下术语。 turn 是一次用户与系统的交互轮次。用户提出一个任务,是一个 turn 的开始。 step 是 runtime 在一个 turn 内的一次模型决策或工具执行推进。一次 turn 可以有很多 step。 run 是一次完整执行,从收到用户请求到最终回答、失败或取消。长任务中,

读开源 Agent 项目,别一上来就钻进细节。本章给一套追主线的方法。 读开源 Agent 项目,最怕两种读法。一种是从 README 兴奋到插件列表,最后只记住产品功能;另一种是一头扎进代码细节,三天后迷失在 UI、配置和历史兼容里。Runtime 工程师读源码,要带着问题读,尤其要追执行链路。

工具结果进入上下文前,应先问: 这是事实结果,还是日志噪声? 后续步骤是否需要逐字引用? 是否有结构化字段可提取? 是否超过预算? 是否包含 secret 或隐私数据? 例如测试失败日志,模型通常需要失败用例、断言信息、文件路径、行号、错误堆栈顶部,而不是全部构建输出。搜索结果通常需要文件路径和匹配

Agent 失败常被粗暴归结为'模型不行'。这不专业。至少分成五类: 归因 典型现象 模型问题 推理错误、忽视观察结果、重复无效计划 工具问题 工具崩溃、返回格式错、输出不完整 权限问题 策略过严或过松,审批状态丢失 上下文问题 关键文件未注入,历史摘要误导 Runtime 问题 停止条件、重试、并

一个 Agent trace 至少包含: span 至少包含: 不要把 trace 做成聊天 transcript。聊天记录回答'说了什么',trace 回答'系统做了什么'。

从普通 LLM App 走向 Agent Runtime 工程化的系列教程导读,介绍学习路径、适合读者和全书实践闭环。

Eval 不只是测模型,也测 runtime 策略。例如: maxSteps=10 vs maxSteps=20; 工具描述短版 vs 长版; 旧历史保留 4 轮 vs 8 轮; 搜索结果返回 20 条 vs 50 条; 写入前是否强制计划; 工具失败后是否允许自动重试。 每次对比只改一个关键变量。

目标:给 Agent 增加上下文预算分配器。 功能范围: 对历史消息、文件片段、工具结果、repo map 分配 token; 超限时按优先级降级; 生成 context debug report; 在 UI 或日志中解释'为什么包含/丢弃某项'。 适合证明: 上下文工程; token 成本治理;

最后要交一件能拿得出手的东西:一个可展示、可维护、可验收的 runtime feature。 毕业项目不能只是再写一个 demo。它应该证明你理解 Agent Runtime 的工程闭环:需求从真实问题来,方案能解释权衡,代码能集成现有系统,行为可观测,效果可评测,失败可恢复,文档能让别人维护。 本

回滚不丢对话上下文;恢复不重复执行高风险工具;文件状态和 session 状态能对应到同一个 checkpoint;trace 可以说明恢复从哪一步开始。做到这里,runtime 才从脚本接近系统。

Agent 为什么必须有 Token Budget? 上一篇我们给 Agent Loop 加了 maxSteps。 很多人做到这里,会松一口气:至少 Agent 不会无限跑了。 但只靠 maxSteps,控不住成本,也控不住上下文质量。 原