模型调用失败时，runtime 可以重试；但要分清失败类型。 网络抖动可以重试；限流需要退避；上下文超限需要重新构建上下文；模型不支持某个 schema 特性，需要 schema 降级；工具调用格式不合法，可以让模型重试一次；安全策略拒绝，不应换模型绕过。 一个清晰的模型错误分类： 类型 处理 RA
Agent 迟早要接外部工具。本章讨论怎么接，以及怎么避免被某个供应商或协议绑死。 Agent Runtime 不能永远只使用本地写死的工具。它需要连接数据库、浏览器、设计工具、代码托管平台、内部系统、文档库和企业权限系统。MCP 的出现，正是为了解决 LLM 应用与外部数据、工具之间缺少统一连接方
MCP Tools 规范里，Client 通过 tools/list 发现可用工具，通过 tools/call 调用工具。工具包含名称、描述和输入 schema。Server 声明 tools capability 后，必须响应 tools/list；工具列表可以为空，也可以随时间变化。 对 run
模型供应商的工具调用接口并不完全一致。Runtime 应有自己的 provider adapter： 这样做的好处是： 可切换 OpenAI、Anthropic、本地模型或 Vercel AI SDK； 可统一 stream event； 可把 provider 原生 tool call 转成本地
MCP 让工具接入变容易，也让工具信任问题变复杂。一个 Server 暴露的工具描述不应被 runtime 无条件信任。规范本身也提醒，工具描述等行为注解应被视为不可信，除非来自可信 Server。 因此，MCP 工具审批建议按 Server 信任级别分层： Server 类型 默认策略 官方可信、
Agent Loop、Harness、Runtime 到底是什么关系？ 这几年 Agent 讨论里，有几个词特别容易搅在一起：Agent Loop、Harness、Runtime。 很多文章会这么写： 或者反过来： 再或者： 我不太赞同。
Agent 迟早要接外部工具，也迟早要面对多个模型供应商。本章讨论怎么接，以及怎么避免 runtime 被某个协议或某个 SDK 绑死。 前面几章里，工具都在本地注册，模型调用也被简化成一个 ModelProvider。这对入门很好，但真实系统不会停在这里。企业内部有文档库、浏览器、数据库、工单系统、设计工具、代码托管平台；模型侧也会同时接 OpenAI、A
MCP 解决了什么，又没有解决什么？ MCP 很容易被讲成一句话： AI 时代的 USBC。 这个比喻有用，但也有点危险。 它会让人误以为：只要插上 MCP Server，Agent 就自然拥有了一套安全、可靠、可治理的工具系统。 不是。
目标：给 MCP 工具接入增加风险分类和审批层。 功能范围： MCP 工具 discovery 后先做 risk classification； 高风险工具需要用户确认； 非交互模式使用 policy 自动裁决； 所有审批写入 audit log； 工具列表变化时更新模型上下文。 适合证明： MCP
MCP 不是模型协议，也不是 Agent Runtime 的替代品。它解决'工具和上下文如何被发现、描述和调用'。权限、调度、上下文预算、trace、checkpoint 和 eval，仍然是 runtime 的活。 可以这样理解： MCP Server 把能力暴露出来，Runtime 决定这些能力
Agent 可以动态接入和移除工具；工具 schema 改变不会把 Agent 弄崩；MCP 工具仍然经过本地权限审批；模型供应商替换不影响 runtime 主循环。完成这一章，你的 miniagent 已经具备生态接入能力。
一个实际做法是把 MCP 工具包装成本地统一 ToolDefinition： 注意命名空间。不要让两个 MCP Server 的 search 工具互相覆盖。也不要直接相信工具描述里的'safe''read only'等文字；风险等级应由本地策略、Server 信任级别、工具名称、输入 schema
用 MCP TypeScript SDK 写一个本地 MCP Server，提供两个工具： readprojectfile； searchprojecttext。 然后让 miniagent： 启动时发现 MCP 工具； 将 MCP 工具映射到本地 Tool Registry； 为 MCP 工具加风
