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

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

trace 很敏感。它可能包含用户代码、命令输出、环境变量、文件路径、API 响应、模型输入输出。生产系统中,trace 需要: secret 脱敏; 访问控制; 保留期限; 采样策略; 用户可删除机制; 外部导出审计。 不要为了调试方便,把所有 trace 原样传到第三方系统。可观测追求的不是越多

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

工具结果、日志、文件片段进入模型上下文前,应经过 secret scanning。至少检查: API key; OAuth token; 私钥; .env; cloud credential; 数据库连接串; 内部域名和个人信息。 发现 secret 后,不要把原文注入模型。可以替换成 REDACT

回看全书,我们走过了这条线: 1. 理解 Runtime 比 LLM App 多承担什么; 2. 补齐 Node 异步、取消、进程管理; 3. 写出最小 Agent Loop; 4. 把工具系统治理起来; 5. 给上下文建立预算和调试报告; 6. 接入 MCP 和 Provider Adapter;

MCP 让工具接入变容易,也让工具信任问题变复杂。一个 Server 暴露的工具描述不应被 runtime 无条件信任。规范本身也提醒,工具描述等行为注解应被视为不可信,除非来自可信 Server。 因此,MCP 工具审批建议按 Server 信任级别分层: Server 类型 默认策略 官方可信、

Agent 出错后,最怕只剩一句'模型没做好'。这句话既不能定位问题,也不能指导修复。可观测系统的任务,是把一次 Agent run 拆成可以追踪、可以复盘、可以转化为评测用例的证据链。 OpenTelemetry 的公开文档把 span 视为 trace 的基本操作单元:span 有名称、父 span、开始和结束时间、属性、事件、状态等信息。本书不要求读者

试读章节:Agent Loop 的完整生命周期 这篇放一段《Agent Runtime 工程化》的试读。 不是整章原样贴。 我把第三章里最核心的部分抽出来,重新整理成一篇社区版:一次 Agent Loop 到底应该怎么跑。 很多 Agent

工具失败不应只有 error: string。至少分为: 类型 例子 Runtime 行为 INVALIDARGUMENTS 参数缺字段、类型错 反馈模型重新调用 NOTFOUND 文件不存在 提示可选路径或要求搜索 PERMISSIONDENIED 用户拒绝或策略拒绝 停止或让模型寻找低风险方案

日志不是 trace。日志多半给开发者看,trace 应能还原运行路径。读项目时找: 每次模型调用是否记录; token usage 是否记录; tool call args 是否脱敏; tool result 是否保存; latency 是否可见; 错误是否分类; 用户确认是否入 log; 是否能

我为什么写《Agent Runtime 工程化》 过去几天,我连续写了 6 篇关于 Agent Runtime 的文章。 先讲 Demo 为什么上不了生产,再讲 Agent Loop、Harness、Runtime 的边界。然后写 Retr

Agent 能根据用户请求读文件、总结、继续追问或停止。非法工具参数不会让程序崩溃;工具失败会变成模型可理解的 observation;超过最大步数会停止并给出原因。完成这一章,你已经有了 runtime 的胚胎。

状态包括聊天历史、任务状态、工具执行记录、文件变更、UI 状态、用户配置。读时问: 状态存在内存、文件、数据库,还是 git? 崩溃后能恢复到哪里? 工具执行是否有 ledger? 用户审批是否持久化? 文件变更是否可回滚? 长任务是否可以暂停和继续? 这部分最能区分 demo 和系统。

一次线上失败,如果不能转化为 eval,它就会再次发生。建议流程: 1. 从 trace 中提取用户目标、关键上下文、工具调用和失败结果; 2. 去除 secret 和用户隐私; 3. 固化 workspace fixture; 4. 写 expected behavior; 5. 加入 CI; 6

run 生命周期通常包括: 初始化 session; 构建上下文; 调用模型; 解析响应; 执行工具; 写状态; 输出 UI event; 进入下一步或停止。 你要找的不是某个函数名,而是状态怎样流动。很多项目不会把它叫 runAgent,可能叫 task、controller、orchestrat

恢复流程要保守: 1. 找到最新完整 checkpoint; 2. 校验 workspace 状态; 3. 恢复 message history 和 run state; 4. 检查最后一个 tool call 是否已完成; 5. 对不可重复工具禁止自动重放; 6. 给模型注入恢复说明; 7. 从下

Agent 迟早要接外部工具,也迟早要面对多个模型供应商。本章讨论怎么接,以及怎么避免 runtime 被某个协议或某个 SDK 绑死。 前面几章里,工具都在本地注册,模型调用也被简化成一个 ModelProvider。这对入门很好,但真实系统不会停在这里。企业内部有文档库、浏览器、数据库、工单系统、设计工具、代码托管平台;模型侧也会同时接 OpenAI、A

写 Agent Runtime 之前,先补一门不太体面的课:异步任务、流和进程控制。 Agent Runtime 表面上是在调用模型,实际上是在管理一串可能很慢、会失败、有副作用、需要取消的异步任务。模型请求会流式返回,shell 命令会持续输出,文件系统可能被修改,用户可能中途按下取消,工具可能超时,子进程可能留下孤儿进程。没有扎实的 Node runti

模型 span: provider; model; prompt tokens; completion tokens; latency; finish reason; tool call 数量; 是否触发上下文降级; response id 或 continuation metadata。 工具 s

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