刚开始做 Agent 的时候，我也很容易把它想成一个更聪明的函数：写一段 prompt，接几个 tool，模型自己判断下一步。
这个理解在 demo 里很顺。让它搜资料、读文件、写一段代码，都能跑出一个“像样”的结果。但一旦任务变长，问题就出来了：模型会想，系统却不会稳定地运行。
我现在越来越觉得，Agent 真正需要的不是再多一层 prompt 技巧，而是 Runtime。
Runtime 可以理解成 Agent 的运行环境。模型负责判断“我接下来想做什么”，Runtime 负责处理“这件事能不能做、怎么做、做失败了怎么办、做完之后怎么证明真的做了”。
Agent 不是一次请求
普通 LLM 调用是一次 request-response。输入进去，输出回来，请求结束。
但 Agent 不是。它可能要读文件、搜索代码、调用 API、等待用户确认、跑测试，再根据测试结果继续改。一个任务可能持续几分钟，也可能跨过几次会话。
这时候就会出现一些非常工程化的问题：什么时候算开始？什么时候该暂停？什么时候应该恢复？什么时候应该承认失败？
比如一个代码修复 Agent，跑测试失败之后，不应该只是把错误贴出来，然后继续凭感觉改。它要知道自己现在处在验证阶段，测试失败意味着要回到分析或修改阶段。这个阶段变化如果只靠上下文里的几句话维持，时间一长就会乱。
Runtime 做的就是把这些状态变成系统的一部分，而不是让模型自己“记得”。
上下文不是记忆
很多 Agent 原型会把上下文窗口当成记忆。用户说过什么、工具返回什么、模型想过什么，全都塞进去。
短任务里这样没问题。长任务里就麻烦了。上下文会膨胀，会被截断，会混进很多过期信息。模型可能把一次临时尝试当成长期事实，也可能忘记用户最开始说过的限制。
真正有用的状态应该更像任务记录：当前目标是什么，已经试过什么，哪些假设被推翻，哪些文件被改过，哪些操作有副作用，哪些结果已经被验证。
没有状态管理的 Agent，很像一个失忆但表达能力很强的人。它能把每一步解释得很合理，但你很难相信它真的知道自己做到哪了。
工具不是越多越好
Agent 的能力很大程度来自工具。它能读文件、跑命令、查数据库、访问浏览器、调用内部系统，甚至部署服务。
但工具越强，越不能只是简单暴露给模型。
读取文件和删除文件都是工具，但完全不是一类动作。查询订单和退款也都是 API，但一个只是观察，一个会改变现实。Runtime 必须知道这些动作的差别：哪些可以自动重试，哪些需要确认，哪些不能在当前权限下执行。
模型可以提出“我想调用这个工具”，但 Runtime 要负责判断“这件事能不能真的发生”。
失败恢复才是分水岭
很多 Agent demo 看起来聪明，是因为路径很顺。一旦中间失败，就容易开始胡乱补救。
工具会超时，网络会断，测试会失败，API 会返回奇怪的数据，用户也会中途改需求。这些都不是边缘情况，而是日常。
Runtime 需要知道失败发生在哪里。安装依赖失败，可以换镜像重试；测试断言失败，通常要回到代码；数据库迁移失败，可能应该立刻停下来等人确认。
如果这些全交给模型临场发挥，系统就会变得很像一个焦虑的新人：遇到错就继续试，试到自己也不知道改了什么。
可观测性决定能不能迭代
Agent 一旦能自主做多步任务，可观测性就变得非常重要。
你不只想知道最后成没成，还想知道它为什么这么做：读了哪些文件，调用了哪些工具，哪一步失败了，为什么重试，什么时候改变了计划，哪些操作需要用户确认。
没有这些记录，Agent 出错之后很难 debug。你只能看到它做错了，却不知道是模型判断错、工具返回错、权限放太宽，还是状态恢复出了问题。
对工程系统来说，不能复盘就不能改进。Agent 也一样。
最后
模型让 Agent 有了判断力，Runtime 让它具备工作能力。
没有 Runtime，Agent 很容易停留在“看起来会做事”的阶段。有了 Runtime，它才开始接近一个可靠的执行单元：有状态、有边界、能恢复、能审计、能被人接管。
这件事不炫酷，但很关键。因为真正的 Agent，不是偶尔聪明一下，而是能在复杂环境里持续把事情做完。