首页 > 基础资料 博客日记
Agent 的“上下文” 生命周期的思考
2026-05-13 17:30:02基础资料围观6次
从 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协助编写文章。
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！
标签：
相关文章
最新发布
点击排行
本站推荐
