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

推荐订阅源

F
Fortinet All Blogs
S
Secure Thoughts
月光博客
月光博客
美团技术团队
雷峰网
雷峰网
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
N
News and Events Feed by Topic
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
Forbes - Security
Forbes - Security
W
WeLiveSecurity
P
Proofpoint News Feed
阮一峰的网络日志
阮一峰的网络日志
爱范儿
爱范儿
G
GRAHAM CLULEY
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
AI
AI
Last Week in AI
Last Week in AI
Google Online Security Blog
Google Online Security Blog
Schneier on Security
Schneier on Security
云风的 BLOG
云风的 BLOG
Threat Intelligence Blog | Flashpoint
Threat Intelligence Blog | Flashpoint
Recent Announcements
Recent Announcements
Webroot Blog
Webroot Blog
T
Tor Project blog
Cisco Talos Blog
Cisco Talos Blog
N
News and Events Feed by Topic
罗磊的独立博客
The Register - Security
The Register - Security
Blog — PlanetScale
Blog — PlanetScale
T
Threat Research - Cisco Blogs
博客园 - 【当耐特】
Apple Machine Learning Research
Apple Machine Learning Research
人人都是产品经理
人人都是产品经理
T
The Exploit Database - CXSecurity.com
www.infosecurity-magazine.com
www.infosecurity-magazine.com
B
Blog
腾讯CDC
Microsoft Azure Blog
Microsoft Azure Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
H
Hacker News: Front Page
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Engineering at Meta
Engineering at Meta
Latest news
Latest news
IT之家
IT之家
D
DataBreaches.Net
博客园 - 司徒正美
N
Netflix TechBlog - Medium
V
V2EX
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知

博客园 - 编写人生

企业级 Agent 架构的真实形态:Skill、A2A 与 MCP 的边界思考 如何更优雅地提供 MCP Resources 面向 AI Agent 的能力模型与多协议生成架构设计思考 从 LangGraph 回到 Model-Tool Loop:更聪明的模型,正在让 Agent 架构重新变简单 .NET GC设计的新想法 AI OS 海量 MCP 工具场景下的上下文隔离选择方案 Python 异步编程完全指南 软件架构设计模式全览 我花了一上午,帮一个 AI 找到了自己的"亲生父母" Agent构建:声明式优于硬编码 探索 Nim 中的 sequtils 与箭头语法 —— 立即计算与惰性计算的那些事 .NET Exception.Data 属性:上下文错误处理的架构深思 组合优于继承最佳实践指南 UI界面设计:继承 vs 组合 的架构思考 Nim 枚举类型 对性能的影响 Nim 概念 Concept 对性能的影响 C# 泛型编译特性对性能的影响 在AI大爆发的背景下,企业管理软件有什么冲击 c#使用内存映射像处理内存一样去快速处理文件 关于.net 和 JAVA 在内存处理(GC)设计上的差距(ChatGPT水文) 我与 ChatGPT 讨论了面向对象语言 中,关于动态调用的问题 寓言故事:超喜欢的玩具 关于 智能红绿灯 的简单探索 Nim 语言新的性能测试 Kotlin 实现类似 C# 的 Event 事件代码
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协助编写文章。