Agent 运行时不是聊天流，而是给 LLM 补操作系统

摘要：生产级 Agent 的难点不在单次回答，而在运行时。上下文要像工作内存一样管理，RAG 像换页，tool call 像系统调用，多 Agent 像多进程，LLM API 像不稳定下游。

运行时先补齐内存、调度和容错

把 Agent 做到生产环境后，最先暴露的问题通常是系统能不能稳定跑完任务。

图：Agent 运行时把上下文、工具和调度收束到同一执行平面

模型会回答，只是第一层。真正卡住任务的，往往是上下文爆掉、工具失败、多 Agent 互相等待、长任务中途忘掉早先判断。

很多团队一开始以为自己在做 prompt。做深以后才发现，要补的是内存、调度、协议和容错。

Karpathy 在 2023 年那句话后来反复被引用：LLM 像新操作系统里的内核进程。这个类比有价值，因为它把 Agent 工程里分散的问题放回了一张熟悉的系统图里。

可以把 LLM 视作一颗不确定、有状态、资源昂贵的 CPU。Agent harness 的职责，是在它外面补操作系统。

LLM 单次 forward 只负责计算。真正让 Agent 看起来能工作的是外层循环。

这个循环会读取当前状态，决定下一步，调用工具，拿回观察结果，再把新状态塞回上下文。

这听起来像推理链，工程上更像一个进程在事件循环里反复调度。差别在于，这个进程的执行单元不够稳定，工作内存又贵又小，还要通过自然语言和外部世界打交道。

可以把常见模块重新映射一遍：

Agent 工程对象	系统工程里的近似物	关键问题
LLM 单次推理	CPU 执行指令	计算结果不完全确定
Agent loop	进程 / 事件循环	状态读取、动作选择、结果回写
上下文窗口	RAM / 工作内存	快、贵、小、会随会话消失
RAG / 向量库 / 数据库	磁盘 / 外存	持久化与按需调入
摘要 / 压缩 / 裁剪	换出 / GC	工作集过大时回收空间
Tool call	syscall	让内核之外的系统产生副作用
MCP / A2A	驱动接口 / RPC / 服务发现	降低 Agent 与工具、Agent 与 Agent 的对接成本
多 Agent 编排	调度器 / IPC	任务拆分、协作和一致性
超时 / 重试 / 限流 / 熔断	远程依赖治理	防止不稳定下游拖垮系统

这张表不是为了把每个名词强行配对。它提醒我们：Agent 的多数工程问题早就有原型，只是对象从确定性的程序换成了概率模型。

上下文是工作内存

很多 Agent 失败，根因是工作内存管理太粗糙。

上下文窗口的性质很像 RAM：访问快，成本高，容量有限，任务结束后还会消失。长期知识、历史记录和用户状态不能长期堆在这里，只能放到向量库、数据库或文件系统里，需要时再检索回来。

RAG 在这个视角下是换页机制。检索把外存里的片段调进上下文。

摘要、裁剪和压缩负责把暂时不重要的内容换出去。checkpoint 则像事务快照，能在执行失败后恢复到可解释的中间状态。

这里最容易犯的错，是把长上下文当成无限内存。

上下文变长后，信息并不会像 RAM 一样等价可取。注意力会被稀释，关键约束会被淹没，模型在长任务中更容易漂移。长上下文解决的是容量问题，不自动解决访问质量问题。

MemGPT 当年用虚拟内存解释 LLM 记忆，AIOS 后来把调度器、内存管理、上下文管理和访问控制做成更完整的内核形态。到了 Letta、MemOS 这类工作，记忆已经被抽象成可管理、可迁移、可压缩的资源，而不是 prompt 里的补丁。

多 Agent 首先带来调度问题

单 Agent loop 已经像一个进程。多个 Agent 一起跑时，问题会从推理质量扩展到调度和通信。

不同协作结构，本质上对应不同的系统拓扑：

协作结构	适合场景	风险
中心化编排	主控拆任务、子 Agent 执行、结果回收	主控成为瓶颈，单点故障明显
去中心化网状	多个 Agent 平等协商，适合探索型任务	灵活，但一致性和收敛更难
层级化树形	任务边界清楚，适合分层拆解	中间层丢信息会影响下游
黑板 / 共享内存	多方共享状态，适合持续协作	共享状态会变脏，需要仲裁机制

多 Agent 不能作为默认答案。多进程能带来并行和专业分工，也会先引入通信成本、状态一致性、权限隔离和失败归因。

AIOS 把 Agent scheduler、上下文管理和访问控制显式放进系统里，正是因为多 Agent 的核心难点在于“谁何时拿什么状态去做什么”。

MAST 对多 Agent 故障的分析也指向同一件事：很多失败来自规范与协调，底座模型能力并不是唯一原因。

模型越能干，单个进程能撑起的任务越长。但只要任务需要跨角色、跨工具、跨状态协作，调度层的质量就会决定系统上限。

Tool call 是系统调用

LLM 自己只会计算 token。查数据库、写文件、调用 API、发消息，都是外部副作用。它们必须通过工具跳出模型边界，这就是 Agent 里的 syscall。

工具描述相当于接口定义。参数、返回值、错误码、幂等性、权限边界如果写不清，模型就会像拿到一份含糊 syscall 文档的程序：能猜，但猜错也不奇怪。

MCP 的意义在这里就很直接。没有标准协议时，每个 Agent 都要分别适配每个工具，复杂度是 N x M。有了统一接口，Agent 侧适配一次，工具侧适配一次，复杂度变成 N + M。

A2A 解决的是另一侧：Agent 之间如何发现彼此、如何发起请求、如何传递结果。把它类比成 RPC 或服务发现，比把它说成“智能体社交”更接近工程本质。

协议层做得好，模型少猜一点，系统就稳一点。

LLM API 要按不稳定下游治理

生产环境里调用 LLM API，不能按本地函数来想。它更像一个不稳定的远程依赖：有延迟抖动，会限流，会超时，也可能返回格式不合约的内容。

成熟后端治理手段可以直接搬过来：

超时：不要让一次模型调用无限占住任务
退避重试：处理偶发失败和短期限流，但要有上限
熔断：Agent 循环失控时必须断闸，尤其要控制 token、轮次和工具调用次数
降级：主模型不可用时，退到小模型、缓存、规则或人工确认路径
限流：保护上游配额，也保护自己的系统预算

这部分不需要包装成大模型专属概念。把 LLM 当成 flaky downstream，很多答案已经在后端系统里验证了几十年。

类比失效的地方才是新问题

操作系统类比有用，但不能过度使用。Agent 工程最难的部分，来自传统系统里没有等价物的问题。

第一，幻觉不同于硬件故障。硬件坏了，通常表现为可检测的错误。

模型幻觉更麻烦，它会用很顺的语言给出错误答案。重试、冗余、超时这些传统容错手段只能解决一部分问题，语义错误还需要校验、多视角投票、辩论、外部事实核验。

第二，记忆不同于随机访问。RAM 里每个地址都可以稳定读取。

上下文里的信息会受位置、长度和干扰项影响。Context Rot 说明，塞得更多不等于记得更好。

第三，接口是自然语言。传统 syscall 的签名固定，Agent 的任务描述和工具语义常常是模糊文本。

规范写得不准，协调层就会把错误放大。相关研究指出，生产环境里相当多失败来自协调缺陷，底座模型能力并不是唯一原因。

第四，长时程任务会漂移。《The Horizon Gap》把这个问题叫“时程鸿沟”：模型短步推理很强，但在数小时任务中可能忘掉早先决策、误判任务完成状态，或者偏离目标。METR 的测量显示，模型能独立完成任务的时间跨度大约每 7 个月翻一倍。单模型能力在增长，但这不会自动补齐状态管理、失败归因和过程监督。

结语

Agent 工程的重心正在从“怎么让模型回答”转向“怎么让一套围绕模型的运行时可靠工作”。

LLM-OS 类比最实用的地方，是把上下文当工作内存管理，把 RAG 当换页，把 tool call 当 syscall，把多 Agent 当多进程，把 LLM API 当不稳定下游。这样做不能解决全部问题，但能先把工程风险放回成熟框架里。

剩下那些类比解释不了的部分，才值得投入新的方法：幻觉校验、自然语言接口规范、长时程状态保持、协调失败归因。

先怀疑 harness，再怀疑模型。很多 Agent 失败的原因不是 CPU 不够强，而是外面那套操作系统还没写好。

AI小老六