Sluke的夹生饭

欲生还熟

context infra 不会被 agent 吃掉，越是强的 agent，越依赖好的 context infra。

一、概念的梳理

1.1 什么是 context infra

Context Infra 指的是为 AI Agent 提供动态、结构化、可管理的上下文信息层的一整套基础设施，包括但不限于：

  • 上下文采集：从用户行为、业务系统、工具输出里持续收集信息
  • 融合与建模：把「历史对话、任务状态、环境状态、用户画像、文档知识」统一建模成可查询的记忆/图谱
  • 存储与检索：长期存放 + 相关性检索（可能结合向量库、图数据库、时序库等）
  • 生命周期管理：版本控制、冲突消解、遗忘策略、防上下文污染等
  • 对外接口：以 API / MCP / 内部中台的方式，向各类 Agent 暴露「取用上下文」的统一接口

我们可以把它粗暴理解成：

“Agent 的记忆中枢 + 世界状态服务”，而不仅是一个 RAG 或向量/图库。

1.2 什么是 agent

Agent 指的是「以大模型为大脑，叠加工具调用、记忆、规划等能力，可以自主拆解任务、循环感知-推理-行动的智能体」。
包括三大核心要素：

  • Model（LLM）：大脑 / 推理引擎
  • Tools：与外部世界交互的手脚
  • Context / Memory：对世界和用户的“理解 + 记忆”

1.3 什么是 Agent “吃掉” context infra

“吃掉”通常有两层含义：

  1. 被功能上替代，比如「90% 的 Agent 会被更强的大模型吃掉」——意思是：随着 base model/系统变强，很多薄包装的 agent 产品没必要存在了。
  2. 被整合进更大的平台/层，比如「Agent Infra 吃掉 Manus」这类说法，强调的是：底座 / 平台层会把原来上层做的事整合进来，应用层单独成公司会变难。

我们关心“context infra 是否会被 agent 吃掉”，是在问：

随着 Agent 变得越来越聪明、越来越「有记忆」，专门做上下文基础设施这一层，还有独立价值吗？会不会最后都被 Agent 自己“做掉”？

二、从技术结构看：Agent 是用 context，不是取代 context infra

Agent 的智能上限，与 context infra 质量强相关

几个关键事实：

  1. LLM 先天是无状态的

    • 每次调用只能看到「当前 context window 里的 token」
    • 再长的 window（几十万 token）也只是“更大的一次性记忆”，不是结构化的长期记忆
    • 没有外部 infra，Agent 完成多轮、多天、多工具的复杂任务，几乎必崩

  2. 上下文工程已经从“prompt 小技巧”演变为独立工程领域

    • Anthropic 直接把“Context Engineering for AI Agents”单列出来，提供一套完整实践：压缩（compaction）、note-taking、sub‑agents 等
    • AWS、各大云厂商都有专门一篇篇讲「Agent 场景下的上下文工程 / Context Layer / Memory 模块」

  3. 多 Agent 场景强依赖共享 Memory / Context Layer

    • 如果每个 Agent 各自维护自己的 context，就是“一个个数据孤岛”，会导致重复计算、状态不一致
    • 如果用 Context Infra 做「Shared Memory Graph + Context Broker」，多个 Agent 基于同一套记忆和上下文流协作，这本质上就是一个独立的 infra 层。

三、为什么 context infra 很难被“内嵌到单个 agent”里

context infra 也很难彻底被“吃进”单个 agent 中，原因主要有几类：

3.1 多 Agent / 多应用共享的需求决定了它更像“公共设施”

  • 企业场景里，典型是一堆 Agent + 一堆业务系统：客服 Agent、运维 Agent、财务分析 Agent、法务文书 Agent……，它们都要访问同一份「用户画像、订单历史、知识库、风控规则」。如果每个 Agent 自己带一套“私有 context 存储”，立刻遇到：
  • 数据一致性问题（谁是“主记忆”？）
  • 成本问题（多份冗余存储 & 多套向量库 / 图数据库）
  • 治理问题（审计、权限、删除权等一堆合规诉求）

因此，大厂和不少创业团队都在刻意把这一层单独抽出来做成：

企业级 Context OS / Context Platform / Memory Service

典型例子有：MineContext（字节内部上下文中台）、Zep（长记忆服务）、各种 “Context OS for Agentic Systems” 产品。

3.2 安全、权限、审计是“平台级问题”，不能塞进单一 Agent

  • 谁能看到/修改哪些上下文？
  • Agent 误调用敏感工具（转账、删库）时，事后怎么审计和追责？
  • GDPR / 数据出境 / 合规要求下，上下文如何「被遗忘」？

这些都更像是 基础设施/平台问题，需要：统一的权限模型（RBAC / ABAC）；统一的日志、审计、回放能力；独立于具体 Agent 的治理体系。不可能简单靠「在 agent 的 prompt 里多写两句“你要遵守安全政策”」解决。

3.3 成本与性能：token 不是白给的

盲目把所有上下文塞进 window，会让模型又贵又蠢。

真正可用的做法是：

  • 结构化存储
  • 按需检索（just‑in‑time context）
  • 总结压缩（compaction）
  • 上下文卸载 / Off‑loading（skill可以看作是一种方式）

这些都依赖一整套独立的 infra：存储层、检索层、压缩服务、治理策略，而不是一个 agent 自己做到的。

四、Context infra 未来趋势

Context infra 会越来越“agent‑native”，本质角色是 OS / 中间层，而不是上层应用。

可以预见的几个趋势：

  1. 从 “RAG 工具” 升级为 “Context OS / Context Platform”

    • 包括：Context Lake、Context Graph、Shared Memory Graph、Context Broker 等概念

  2. 与 Agent Runtime / Agent Infra 深度融合

    • 你会看到越来越多「一体化的 Agent Infra」，里面封装了：Runtime（调度/并发/沙箱）；Tools 管理（MCP 之类）；Context Infra（记忆图谱、上下文路由、压缩）。但这只是打包交付方式变了，不是说 context infra 这层逻辑被取消了。

  3. 对创业公司：从“独立 SaaS Agent”往“被调用的 Context 服务”迁移

    • 顶层 agent 公司会很卷
    • 做底层 context 平台、记忆服务、安全审计 等 infra 的公司，壁垒可能更稳

五、总结

context infra 不会被 agent 吃掉，它会被越来越多的 agent 共同“踩着用”，本质地位更像一个「为 agent 服务的 OS / 记忆中台」。真正被吃掉的，更可能是那些“把一点点上下文逻辑硬写在单个 agent 里、又没独立 infra 价值”的薄壳产品。

如果在技术或产品路线上做选择：

  • 做 Agent 应用：别自己在里边乱缝一堆 ad‑hoc 的小型上下文管理逻辑，优先考虑用/接入一个像样的 context infra（哪怕是自己内部实现的服务），否则后面很难演进成多 Agent、多业务协同。
  • 做 Infra / 平台：context infra 这一层，从目前产业讨论和大厂动作来看，是一个持续加重、而不是被吃掉的方向。

标签：infra, ai, agent

你的评论