
《Agent Runtime 工程化》我对生产级 Agent Runtime 的 10 条工程判断
我对生产级 Agent Runtime 的 10 条工程判断 写到第 21 天,可以把前面的问题收成一些判断。 这些不是金句。 金句没用。 真正有用的是:你在设计 Agent 系统、读开源项目、排线上事故时,能不能拿它们当检查项。 下面 1

我对生产级 Agent Runtime 的 10 条工程判断 写到第 21 天,可以把前面的问题收成一些判断。 这些不是金句。 金句没用。 真正有用的是:你在设计 Agent 系统、读开源项目、排线上事故时,能不能拿它们当检查项。 下面 1

从 Agent Loop 重构成 Agent Runtime 写到第 14 天,可以把前面几篇收一下了。 前面写了 100 行 Agent Loop。 随后加了 max steps。 再往后加了 token budget。 接着处理了 re

A 术语表 Agent:根据目标和上下文选择下一步行动的执行体。 Agent Runtime:负责模型调用、工具调用、上下文、权限、状态、观测、恢复、评测和成本治理的运行系统。 Tool Calling:模型输出结构化工具调用,应用执行工具并把结果返回模型的接口能力。 Tool Registry:工具定义、schema、风险等级、执行器、输出策略和版本的注册

第一类失败是非法参数。模型传了不存在的路径、错误类型、缺字段。处理方式是 schema 校验 + observation 反馈。 第二类失败是工具不存在。模型调用了没注册的工具。处理方式是返回 UNKNOWNTOOL,并把可用工具列表简短提示给模型。 第三类失败是输出过大。处理方式是截断、摘要、引用

试读章节:Tool Runtime 与权限审批 这篇继续放《Agent Runtime 工程化》的试读。 上一篇讲 Agent Loop 的生命周期。 这一篇讲工具。 更准确地说,是 Tool Runtime。 因为在生产级 Agent 里

章节 代码主题 第 1 章 Agent Loop 伪代码 第 2 章 timeout、AbortSignal、子进程执行器 第 3 章 ModelResponse、ToolCall、最小工具 第 4 章 ToolDefinition、风险等级、审批请求 第 5 章 Context Builder 输

能力越大,边界越要清楚。本章谈权限和安全。 Agent 的能力来自工具,风险也来自工具。一个不会调用工具的模型,最多说错话;一个能执行命令、写文件、联网、访问数据库的 Agent,可能造成真实损失。Runtime 的安全目标不是把 Agent 绑住,而是让它在明确边界内做事;越过边界时,停下来请人确

Agent Runtime 和 Workflow Engine 有什么区别? 很多人第一次做 Agent 系统,会问: 既然 Temporal、Step Functions、Airflow、Dagster 这类 workflow engin

模型调用失败时,runtime 可以重试;但要分清失败类型。 网络抖动可以重试;限流需要退避;上下文超限需要重新构建上下文;模型不支持某个 schema 特性,需要 schema 降级;工具调用格式不合法,可以让模型重试一次;安全策略拒绝,不应换模型绕过。 一个清晰的模型错误分类: 类型 处理 RA

MCP 解决了什么,又没有解决什么? MCP 很容易被讲成一句话: AI 时代的 USBC。 这个比喻有用,但也有点危险。 它会让人误以为:只要插上 MCP Server,Agent 就自然拥有了一套安全、可靠、可治理的工具系统。 不是。

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

Agent 出错后,最怕只剩一句'模型没做好'。这一章讲怎么查清楚。 没有 trace 的 Agent Runtime,就像没有采访记录的新闻调查。出错后只能凭印象复盘:模型好像看过文件,好像调用过工具,好像测试失败了,好像用户批准过。工程系统不能靠'好像'。 OpenTelemetry 把 tra

选三个项目:Cline、Codex CLI、aider。分别画出一次用户请求如何走到工具调用的链路图。你不需要读完整个仓库,但要回答: 1. 用户输入进入哪里? 2. 模型调用在哪里发生? 3. 工具在哪里注册? 4. 工具调用结果如何回到模型? 5. 权限审批或确认在哪里发生? 6. 日志或 tr

token budget 不只是技术限制,也是产品预算。一次 run 里,token 影响延迟、成本和可靠性。越长的上下文越不一定越好,因为模型注意力会被稀释,缓存命中也可能下降。 可以把上下文分为六层: 1. 系统与开发者指令; 2. 用户当前意图; 3. 近期完整对话; 4. 当前任务状态和计划

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

项目 重点 Cline TS Agent Runtime、IDE/CLI 产品形态、工具审批、MCP Continue IDE 集成、上下文 provider、模型配置 aider repo map、git diff、命令行结对编程体验 OpenHands sandbox、任务自动化、agent 平

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

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

写一个能演示的 Agent 很快。写一个能稳定跑的 Agent 很慢。慢在三件事上。 第一,模型输出不是普通函数返回值。它可能少字段、多字段、把 JSON 写坏、重复调用工具、误解工具描述,或者在工具失败后编一个像真的观察结果。Runtime 要把模型输出当作不可信输入处理。 第二,工具不是纯计算。

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