惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
腾讯CDC
爱范儿
爱范儿
Google DeepMind News
Google DeepMind News
V
V2EX
Blog — PlanetScale
Blog — PlanetScale
Engineering at Meta
Engineering at Meta
GbyAI
GbyAI
量子位
F
Fortinet All Blogs
G
Google Developers Blog
T
The Blog of Author Tim Ferriss
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
Hugging Face - Blog
Hugging Face - Blog
Last Week in AI
Last Week in AI
T
Tailwind CSS Blog
J
Java Code Geeks
S
SegmentFault 最新的问题
D
Docker
博客园 - 司徒正美
The GitHub Blog
The GitHub Blog
Jina AI
Jina AI
M
MIT News - Artificial intelligence
博客园 - 【当耐特】

博客园_首页

Plist 二进制格式 Milvus 和 PGVector,哪个更好? OpenClaw 已过时?在 VS Code 中运行 Hermes Agent! 第30篇文章:一个大三计科生的自白 Manim如何在数学公式中完美显示中文? Docker 部署 RocketMQ 5 并发编程核心概念辨析 C#事务处理最佳实践:别再让“主表存了、明细丢了”的破事发生 CLI 是什么?为什么大厂突然集体卷命令行? 【从0到1构建一个ClaudeAgent】协作-自主Agent UIImageView 设置图片不生效的原因排查 最小二乘问题详解20:无先验约束下的增量式SFM自由网平差 痞子衡嵌入式:大话双核i.MXRT1180之XIP应用里借助MU实现可靠Flash IAP的方法 AI Chat 封装, SemanticKerne.AiProvider.Unified 已发布 Windows下右键编辑js文件无法打开记事本——在注册表中使用环境变量 在后台服务中使用 Scoped 服务,为什么总是报错? H200 安装驱动并使用sglang启动模型 wireshark 抓包Trap上报告警内容 我用 AI 辅助开发了一系列小工具(2):图片压缩工具 [A Primer On MC and CC] 2.1 Memory Consistency 1 - 指令重排序和 SC 模型 Oracle数据库SCN推进技术详解与实践指南 玩转控件:封装个带图片的Label控件 Claude Code 4.7 真正该升级的不是模型,而是你的工作流 前端小白一句话,AI 帮我做了个颜值拉满的桌面媒体播放器。当代码不再是门槛,一句话编程就是现实。 5. WorkBuddy: 小龙虾的灵魂三件套,让你的小龙虾不只是工具 SQLite 分片方案实战:三种分片策略的深度对比 告别简陋 UI!一款基于 Fluent Design 和基于 WinUI 的开源免费、现代化的 Avalonia UI 控件库 关于二进制排列组合枚举的总结 AI开发-python-LangGraph框架(3-27-LangGraph从零实现大模型智能决策工作流) ElasticSearch主分片和副本分片概念详解
Agent 的“上下文” 生命周期的思考
编写人生 · 2026-05-13 · via 博客园_首页

从 Agent Memory 到 Object-Scoped Context 的思考

当前大多数 AI Agent Framework 都在强调:

  • Memory
  • Context
  • Multi-Agent
  • Workflow
  • Shared State
  • Long-term Memory

但我越来越觉得:

业界很多框架,其实还没有真正抓住 “上下文(Context)” 的本质。

它们正在朝正确方向前进,但很多设计仍然默认:

Context ≈ Agent 的记忆

而我认为:

Context 本质上不是 Agent 的。
Context 是“对象相关知识(Object-Associated Knowledge)”。

也就是说:

Context 的生命周期,应该跟随“对象”而不是“Agent”。


一、现在很多 Agent Framework 的隐含模型

当前很多 Agent 系统,本质上是这样的:

User → Main Agent → SubAgent

而上下文通常这样流动:

Prompt
+ Conversation History
+ Agent Scratchpad
+ Memory

于是:

  • Agent 持有 Memory
  • Agent 持有 Context
  • SubAgent 拷贝部分 Context
  • Workflow 再拼接 Context

这种设计的问题是:

Context 被“人格化”了

仿佛:

“Agent 在记忆”

但实际上:

真正长期存在的,
往往不是 Agent,
而是任务、项目、用户、文件、环境。

二、真正长期存在的是什么?

举几个例子。


1. 用户偏好

例如:

用户喜欢英文回复
用户偏好 Linux
用户正在研究 TCAM 项目

这些信息:

  • 不属于某个 Agent
  • 不属于某次对话
  • 更不属于某个 Prompt

而是:

属于 User Entity

生命周期:

跟随 User

2. 项目知识

例如:

TCAM 使用 traffic camera 做 PM2.5 预测
训练使用 Gemma/Qwen
评估指标包含 RMSE/StdRatio

这些信息:

  • 不属于某个 Agent
  • 不属于某次推理

而是:

属于 Project Entity

生命周期:

跟随 Project

3. Workflow 状态

例如:

当前步骤做到哪里
哪些文件已经生成
哪些节点执行失败
等待人工审批

这些也不是 Agent 的记忆。

而是:

属于 Workflow / Task

生命周期:

跟随 Workflow

三、Agent 本质上应该很“轻”

我越来越觉得:

Agent 更像 Process(进程)
而不是 Brain(大脑)

Agent 应该只持有:

- 当前角色
- 当前目标
- 当前权限
- 当前工具
- 当前执行状态

也就是说:

Agent Context 应该很轻

真正重的 Context:

应该在外部对象系统中。


四、我认为更合理的模型

我认为应该这样建模:

Context != Agent Memory

而是:

Context = Scoped Object State

例如:

UserContext(user_id)
ProjectContext(project_id)
TaskContext(task_id)
WorkflowContext(workflow_id)
FileContext(file_id)
SandboxContext(sandbox_id)
OrganizationContext(org_id)

Agent 只是:

读取/修改这些对象

而不是“拥有”这些 Context。


五、为什么这更合理?

1. 生命周期正确

Agent 是临时的:

Agent 可以销毁
可以替换
可以扩缩容

但:

Task / Project / User 是长期存在的

所以:

Context 跟对象绑定
比跟 Agent 绑定更符合现实

2. Multi-Agent 更自然

如果 Context 属于 Agent:

Agent A → Agent B

就必须:

  • 拷贝
  • 压缩
  • 翻译
  • 转发

非常混乱。

但如果:

多个 Agent 访问同一个 TaskContext

问题立刻简单很多。

这其实就是:

共享状态模型(Shared State)

3. 更容易 Checkpoint / Resume

如果状态在 Agent 内部:

Agent 崩了 → 状态丢失

但如果:

状态在 TaskContext

那么:

任意 Agent 都能恢复执行

这更像:

工作流引擎

而不是聊天机器人。


4. 权限模型更清晰

很多系统现在很难解释:

“这个 Agent 为什么知道这些?”

因为 Context 是拼 Prompt 拼出来的。

但如果:

Context 属于对象

那么权限模型就变成:

Agent 是否有权限访问这个对象?

这会变得非常像:

  • OS
  • Database
  • Cloud IAM
  • Capability System

六、这其实更接近操作系统

我越来越觉得:

未来的 AI OS 会更像:

Agent = Process
Context = Addressable State Objects
Workflow = Directed Graph
Memory = Object Store
Tool = System Call

Agent 只是执行单元。

真正稳定存在的是:

对象状态

七、为什么现在很多框架还没完全走到这里?

我觉得原因是:

当前很多 Agent Framework:

本质上还是:

Prompt Engineering Framework

它们从:

Chatbot

演化而来。

因此天然倾向于:

“Agent 在思考”
“Agent 在记忆”

而不是:

“系统在维护对象状态”

但随着:

  • Multi-Agent
  • Workflow
  • Long-running Tasks
  • Human-in-the-loop
  • Checkpointing
  • Distributed Agents

越来越复杂,

业界已经开始“感觉”到:

Context 不应该属于 Agent

只是很多框架:

还没有把它系统化。


八、我认为未来会走向什么?

我认为未来成熟的 Agent System:

核心一定不是:

Agent

而是:

State Graph

Agent 只是:

Graph 上的执行节点

真正重要的是:

- State Ownership
- Context Scope
- Lifecycle
- Permissions
- Persistence
- Routing

换句话说:

AI Agent 的核心问题,
最终不是 Prompt Engineering,
而是:

“状态管理(State Management)”。


九、总结

我现在越来越相信一句话:

Memory is not agent memory.

Memory is object-associated state.

以及:

Context should follow the lifecycle of objects,
not the lifecycle of agents.

如果这个方向是对的,

那么未来 Agent Framework 的核心竞争力,

可能不是:

  • Prompt 模板
  • Tool Calling
  • SubAgent 数量

而是:

谁最先建立:
面向对象生命周期的 Context Operating System

本文由本人提出观点,AI协助编写文章。