企业官网建设流程全解析

运行时先补齐内存、调度和容错
把 Agent 做到生产环境后，最先暴露的问题通常是系统能不能稳定跑完任务。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多 Agent 首先带来调度问题
单 Agent loop 已经像一个进程。多个 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大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。