许多大语言模型智能体的设计，仍然默认这样一个简单流程：模型提出工具调用，工具执行完毕，返回结果，模型再继续推理。这个流程把交互想成一次同步函数调用，输入是参数，输出是文本、图片或某个固定对象。它适合简单查询，却很难描述真实系统中的交互。
真实工具往往不是一次性返回结果。它可能持续输出日志，逐步生成中间产物，等待外部服务完成，甚至长期运行而没有明确的结束时刻。用户也不是只在开头输入一次需求，而是会不断操作界面、触发服务、改变环境。与此同时，智能体的回应也不只是文字，还可能是语音、自动化任务、定时提醒、外部服务操作，甚至机器人动作。
因此，智能体运行时（agent runtime）不应被理解为“模型调用工具”的线性链条，而应被理解为一个事件驱动的控制系统。大语言模型在其中不是唯一的主程序，而是负责解释状态、更新判断和选择行动的规划器（planner）。工具、日志、用户行为、定时任务和机器人传感器，都是事件来源。系统真正要解决的问题，不是让模型更频繁地调用工具，而是把这些连续、异步、带噪声的变化组织成可供决策的状态。
工具调用不是一次函数返回
传统工具调用默认一个固定形式：模型发起请求，工具执行，返回结果，模型继续推理。这种结构的问题在于，它把工具看成一个短暂函数，而许多工具本质上是一个过程。
代码执行会持续打印输出。网页自动化会经历加载、等待、失败和重试。模型训练、数据处理、文献总结、服务部署，都可能需要很长时间。机器人执行动作时也不会一次性给出结果，而是在环境中持续变化，并不断产生反馈。
如果系统仍然让规划器一直等待工具结束，智能体就会失去对过程的控制。它无法及时发现卡死、错误、偏离目标或新的决策机会。相反，如果每出现一行输出就让规划器重新推理，系统又会被噪声拖垮，上下文会被日志占满，计算资源也会被浪费。
更合理的方式是把工具执行看成一个可观察的任务。任务启动后，会持续产生事件：开始、进度更新、阶段完成、错误、等待、完成、取消。规划器不直接读取所有原始事件，而是通过观察层接收被筛选和压缩后的状态变化。
这种结构包含三种策略。第一，优先采用事件驱动：当工具产生有意义的新状态时，系统立即感知。第二，对高频输出做节流和压缩：不是每个片段都值得唤醒规划器。第三，保留低频轮询作为兜底：现实系统可能丢失回调、日志延迟或连接中断，定时检查可以避免静默失联。
因此，问题不是“固定时间观察”还是“有更新就响应”二选一，而是事件驱动优先、观察层过滤、轮询兜底。
观察器（observer）不是缩小版规划器（planner）
在这种架构中，需要引入观察器。观察器可以由规则系统、小模型承担，也可以在复杂场景下使用语言模型，但它不应被设计成一个自由发挥的小型规划器。它的职责应当很窄：判断任务是否仍在运行，是否出现错误，是否达到阶段性节点，是否需要规划器介入，并把连续输出压缩成结构化状态。
规划器负责目标、策略和重规划。观察器负责感知、监测、告警和摘要。二者的边界越清晰，系统越稳定。
合格的观察器不应把大量日志原样交给规划器，而应形成类似这样的状态包：当前阶段是什么；自上次上报以来发生了哪些关键变化；有没有异常；是否需要规划器决策；如果需要，候选动作是什么；支持判断的最小必要证据是什么。
原始流仍然需要保留，便于审计和回溯。但规划器平时不应直接消费原始流，而应消费结构化状态和语义摘要。只有在需要深入排查时，才回看原始记录。
这和人的感知系统有相似之处。人在走路或开车时，可以一边思考别的事情，一边依靠视觉和低层反应机制避开障碍。高层认知不需要逐帧处理所有视觉输入，只有重要变化才会进入注意力中心。智能体系统也应如此：低层负责持续感知和快速筛选，高层只处理真正影响目标的变化。
不过，这个类比只能作为启发，不能替代工程设计。人类低层反应系统有大量长期形成的先验，而智能体系统必须显式规定什么算异常、什么算进展、什么算需要升级。越靠近底层，越应使用清晰规则、状态机、格式校验和阈值判断；越靠近高层，才适合开放式推理。
长任务需要决策节点，而不是盲等
对于长时间任务，关键不是等多久，而是什么时候重新决策。一个任务在运行过程中大致可以归纳为四种状态。
第一种是正常推进。任务有输出、有进展，也没有异常。这时规划器不应频繁介入，只需要观察器维护心跳和阶段摘要。
第二种是局部更新。工具产生了新的日志、中间图像或部分结果，但这些信息不足以改变计划。此时系统只更新任务状态，不进入完整推理。
第三种是决策点。任务到达了一个分支，例如出现多种结果、需要额外参数、发现新的约束、进入检查点，或者当前证据不足以继续自动推进。此时观察器应把相关上下文压缩后交给规划器，由规划器决定下一步。
第四种是异常点。任务卡死、超时、反复失败、资源消耗异常、结果明显偏离目标，或者出现安全风险。这时系统需要中断、重试、回滚、切换工具、请求用户确认，或者终止任务。
长任务管理的核心，是把连续过程离散化成少数有决策价值的节点。没有这种离散化，规划器要么盲目等待，要么被低价值信号反复打断。
观察频率也不应固定不变。任务刚启动时变化较快，可以观察得更密；进入稳定运行期后，观察频率可以降低；接近超时、出现异常征兆或临近关键节点时，再提高注意力。这种基于风险和变化率的观察方式，比简单定时轮询更接近真实系统的需求。
持续服务的日志要按用户动作切片
另一类重要场景是启动一个持续运行的服务。服务不断产生日志，其中一部分对应用户的操作。规划器需要在用户行动后理解相关日志，形成判断，并规划后续动作。
这里的核心不是“让模型读日志”，而是在用户动作、服务状态、日志片段和后续规划之间建立因果关联。如果缺少关联，规划器会看到很多日志，却无法判断哪些是本次用户操作导致的，哪些只是背景噪声。
因此，每次用户操作都应先形成一个动作记录。这个记录应包含动作编号、时间、用户意图、目标服务、预期影响范围，以及可能关联的请求编号、会话编号或跟踪编号。随后，系统围绕这个动作创建一个观察回合。
观察回合有明确边界。它不是无限期盯住整个日志流，而是在用户动作发生后，截取相关时间窗和相关组件的日志。例如，用户点击“部署”后，系统重点观察部署服务、调度器、依赖拉取、健康检查，而不是读取所有后台心跳。观察回合可以在出现成功或失败信号时结束，也可以在超过等待上限时结束，还可以在连续一段时间没有相关新信息出现后结束。
这样，持续日志就被切成一个个与用户动作相关的小片段。规划器面对的不再是无边界的日志海洋，而是一个有起点、有证据、有当前状态的局部回合。
观察器在这里承担四项职责：选择相关日志，判断观察何时结束，压缩证据，决定是否升级给规划器。它输出的不是长篇日志，而是结论：这次用户动作是否生效，当前状态是成功、失败、进行中还是不确定，异常最可能发生在哪个阶段，还缺少什么证据，下一步有哪些可选行动。
需要注意的是，日志不是唯一真相。日志可能不完整，可能延迟，可能顺序错乱，也可能显示成功但用户实际没有看到效果。因此，稳健的系统不应只依赖日志，还应结合指标、状态查询、界面观察、数据库读回或接口返回结果交叉验证。更可靠的链条是：用户动作触发观察回合，系统收集日志和其他证据，形成状态假设，再验证关键假设，最后让规划器规划下一步。
除动作触发的观察外，还需要背景健康监视。有些问题不是某次用户操作直接导致的，而是系统逐渐积累出来的，例如队列堆积、资源耗尽、会话失效、后台任务失败。动作观察器解释“刚刚发生了什么”，背景观察器提示“接下来可能出现什么问题”。两者结合，智能体才不会只对显性操作做反应，而能保持对运行环境的持续理解。
回应用户不只是输出文本
智能体的回应也不能只被理解为“回复一句话”。文本只是行动的一种。系统可能需要向用户解释、播放语音、生成报告、调用外部服务、创建定时任务、下单、控制设备或指挥机器人。
更统一的设计，是把所有回应建模为行动。行动可以是消息、语音、接口调用、一次性任务、定时任务、持续行为或机器人动作。它们的共同点是：系统根据当前目标和环境状态，选择某种方式改变用户理解、软件状态或物理世界。
信息型回应改变的是用户的理解，例如原始文本、格式化文本、表格、报告、进度说明。语音回应可以看成信息型回应的一种呈现方式：模型决定表达的内容，系统再把它转换成声音。数字操作则会改变外部系统状态，例如发送邮件、修改文档、调用服务、生成资料或执行脚本。物理行为更进一步，会改变现实环境，例如移动机器人、拿取物品、控制设备。
因此，规划器输出的最好不是一段自由文本，而是一组行动计划。一个计划中可以同时包含多种行动：先生成文献总结，再把总结发给用户，同时创建每天晚上的阅读提醒。它们属于同一个目标，却由不同执行器完成。
这里还必须有权限和风险控制。总结文献通常可以自动执行；创建提醒可能需要较低级别确认；购物下单、支付、删除数据、控制设备等操作，则应要求明确授权。智能体越能改变世界，越需要清晰的审批策略。否则，系统虽然看似强大，却会变得不可信。
更稳妥的分工是：规划器决定行动的语义，系统策略层决定是否允许执行，执行层负责把行动转化为具体操作，观察层再把执行结果反馈给规划器。
从实现上看，运行时（runtime）更接近事件驱动并发系统
这套运行时从实现上更接近事件驱动的并发系统，而不是一条同步调用链。用户、工具、观察器、调度器和执行器都可以产生事件，也都可以消费事件。大语言模型不是唯一主程序，而是处在上层的规划器：它在关键事件到来时解释状态、调整目标、选择下一步行动。
在这里，事件驱动并发系统只是对运行时结构的一种概括。它说明了为什么工具、观察器、调度器和执行器都不应被压进一条同步调用链。至于在这样的系统里，谁发起、谁等待、谁让出控制权，则需要从通信过程和协程的角度进一步展开。
换句话说，事件驱动运行时回答的是系统应该如何组成；通信过程和协程模型回答的是系统如何运行。前者是架构转向，后者是解释模型。
统一的运行时结构
把前面的内容合在一起，可以得到一个较完整的大语言模型智能体运行时。
底层是环境和工具。它们包括外部服务、日志系统、文档系统、网页、机器人、数据库和各种自动化接口。它们不断产生事件，也接收行动请求。
中间层是执行器和观察器。执行器负责把行动计划转化为具体操作。观察器负责从日志、工具输出、状态查询和环境反馈中提取有意义的变化。调度器负责一次性或周期性任务。它们共同维持系统的运行状态。
上层是规划器。规划器不直接盯住所有原始输出，也不承担低层监控。它接收经过压缩的观察结果，维护对目标和环境的判断，决定下一步行动。它只在目标受到影响、计划出现分支、异常需要处理或信息价值明显升高时介入。
用户既是输入来源，也是被行动影响的对象。智能体可以向用户解释当前状态，也可以请求确认、报告进度、展示结果、播放语音，或根据授权执行外部操作。用户不是系统之外的旁观者，而是整个交互环境的一部分。
这种结构可以概括为一个双环系统。内环是快速感知与执行环，负责持续观察、错误检测、任务推进和低风险反应。外环是慢速认知与规划环，负责目标解释、策略调整、复杂判断和高风险决策。内环让系统保持稳定，外环让系统保持方向。
结论
大语言模型智能体的关键，不只是让模型更会调用工具，而是重新设计工具、观察、行动和规划之间的关系。
工具不应只是同步函数，而应是可观察的任务。日志不应直接塞进上下文，而应围绕用户动作形成观察回合和证据包。回应不应只被看作文本，而应被统一建模为行动。大语言模型不应承担所有控制权，而应作为规划器，运行在一个由观察器、执行器、调度器和外部环境共同构成的事件系统中。
这种架构的意义在于，它承认现实交互的连续性和不确定性。智能体面对的不是一个一次输入、一次输出的静态问题，而是一个不断变化的环境。它必须观察、判断、行动，再观察。只有当系统能够把连续事件组织成可决策的状态，把多种输出统一成可控制的行动，大语言模型智能体才真正从聊天程序走向运行时系统。
事件驱动运行时回答的是智能体系统应该如何组织。进一步的问题是：在这样的系统里，究竟是谁在调用谁？这个问题需要从通信过程和协程的角度重新理解。