摘要生产级 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 callsyscall让内核之外的系统产生副作用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 不够强而是外面那套操作系统还没写好。 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 callsyscall让内核之外的系统产生副作用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 不够强而是外面那套操作系统还没写好。