讨论 Agent Runtime，很容易又回到模型：哪个模型更强，prompt 怎么写，tool calling 怎么接。
但如果真的要做一个能长期跑的 Agent，模型只是其中一层。
我理解的 Runtime，更像是把一堆不稳定的推理调用，包进一个可控、可追踪、可恢复的执行环境里。
模型层：先把模型当成可替换组件
不同模型在上下文长度、工具调用格式、结构化输出、价格、延迟、稳定性上差异很大。
如果业务代码直接依赖某个模型的私有协议，后面切模型、做降级、做 A/B 测试都会很痛。
更稳的做法，是把模型封装成能力接口：文本生成、结构化生成、工具调用、视觉理解、长上下文总结。上层只关心“我要一个符合 schema 的计划”，不应该关心底层是谁。
模型层还要处理一些脏活：重试、超时、限流、预算、token 统计，以及模型返回不合法时怎么修。
编排层：不要把流程交给 prompt
很多 Agent demo 都是一个简单循环：思考、调用工具、观察结果、继续思考。这个循环能展示概念，但不够支撑复杂任务。
真实 Runtime 需要更明确的编排模型：任务如何拆分？步骤之间如何传递结果？哪些步骤可以并行？失败后从哪里恢复？什么时候停止？
有些任务适合状态机，有些适合 DAG，有些适合 planner-executor，有些需要多个子 Agent 协作。关键不是选一个万能模式，而是让任务生命周期显式化。
一个我觉得很实用的原则是：把推理留给需要判断的地方，把流程交给确定性的代码。模型负责计划、解释、选择和补全；Runtime 负责顺序、重试、幂等、取消和恢复。
状态与记忆：区分上下文、状态和知识
Agent 的 memory 经常被说得很玄，但工程上可以拆得朴素一点。
最靠近模型的是上下文，也就是当前任务需要带给模型的信息，比如用户目标、最近操作、相关文件、工具结果。它是短期的，服务于这次推理。
再往下是运行状态，例如当前执行到第几步、哪些工具调用已经完成、生成了哪些中间产物、失败原因是什么。它应该可持久化，支持断点续跑。
最后才是长期知识，例如用户偏好、项目约定、历史决策、常见问题。它不应该无脑塞进 Prompt，而应该通过检索、摘要和权限控制按需注入。
记忆系统最重要的不是“记得多”，而是“在正确时间记起正确内容”。
工具层：把副作用说清楚
工具层决定 Agent 能否改变外部系统。文件、终端、浏览器、数据库、内部 API、CI、工单系统，都可以是工具。但工具越强，风险越高。
好的工具接口要小而清晰：输入有 schema，输出可解析，错误可分类，副作用可预期。
不要把一个巨大 shell 权限直接丢给模型，然后期待它永远做对。
更稳妥的方式是提供领域化工具，例如“读取文件”“运行测试”“创建 PR”“查询订单”，并在工具边界做参数校验、权限检查和审计记录。
工具结果也需要设计。返回一大段不可结构化日志，其实是把问题推回给模型。能返回 JSON、状态码、摘要和关键证据，就不要只返回原始文本。
策略与安全：不要只靠模型自觉
Agent Runtime 必须有 policy 层。它不是最后加上的审核器，而是贯穿模型调用、工具调用和人机交互的约束系统。
常见策略包括：哪些工具需要用户确认，哪些路径不可写，哪些命令属于危险操作，哪些数据不能发给外部模型，哪些任务必须走人工审批。
安全策略最好是分层的：静态规则挡住明显风险，运行时检查处理上下文风险，高风险动作交给人确认。
这里有一个很实际的判断：不要指望模型自己记住所有安全规则。模型可以提出动作，但能不能执行，要由系统决定。
可观测性：没有日志就没有 Agent
Agent 系统比普通后端更需要可观测性，因为它的错误往往不是简单异常，而是“看起来执行成功，但方向错了”。
Runtime 至少要记录：输入目标、模型版本、Prompt 摘要、工具调用链、关键中间状态、token 和成本、失败原因、人工介入点。
更进一步，可以把每次任务执行视为 trace。一次 Agent 运行包含多个 span：模型推理、工具调用、检索、等待用户、重试。
这样才能回答：慢在哪里？贵在哪里？错在哪里？是模型选择错了工具，还是工具返回的信息不够，还是策略层拦截太晚？
没有观测的 Agent，只能靠感觉调 Prompt。有观测的 Agent，才有机会像工程系统一样迭代。
人机界面：人不是异常路径
Agent Runtime 的人机界面不只是聊天框。人在系统里有多种角色：提出目标、补充上下文、批准高风险动作、纠正方向、接管执行、评价结果。
因此 Runtime 需要设计清楚交互点。什么时候应该继续自动执行？什么时候应该停下来问一个问题？什么时候应该给出多个方案？什么时候应该把控制权交还给用户？
优秀的 Agent 不会为了显得自动化而盲目往前跑，它知道在哪些地方让人参与会显著提高结果质量。
对个人博客、IDE Agent、内部运营工具来说，最好的体验通常不是“全自动”，而是“默认自动推进，在关键节点可解释、可暂停、可接管”。
云与边缘：提前给部署形态留空间
Agent Runtime 未来大概率会同时运行在云端和边缘。云端适合重任务、长流程、集中观测、权限管理和团队协作；边缘适合低延迟、本地文件操作、隐私数据处理和离线能力。
这要求架构从一开始就避免把运行环境写死。任务状态、工具能力、模型提供方、文件系统权限、网络访问，都应该通过环境能力声明来配置。
云端 Runtime 可以调度队列和沙箱，边缘 Runtime 可以接入本地 IDE、浏览器和私有模型。两者共享任务协议和事件模型，但拥有不同的工具实现。
成熟的 Agent Runtime，不是某个大模型 SDK 的薄包装，而是一套面向不确定性的工程操作系统。
它把模型的不稳定性限制在合理边界内，把工具的副作用纳入治理，把人的判断放在关键位置，并用可观测性支撑持续改进。
Agent 的能力上限来自模型，但可用性上限来自 Runtime。模型会继续变强，Runtime 的任务是让这种能力可靠地落到现实世界里。