- 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生命周期:
跟随 User2. 项目知识
例如:
TCAM 使用 traffic camera 做 PM2.5 预测 训练使用 Gemma/Qwen 评估指标包含 RMSE/StdRatio这些信息:
- 不属于某个 Agent
- 不属于某次推理
而是:
属于 Project Entity生命周期:
跟随 Project3. 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 CallAgent 只是执行单元。
真正稳定存在的是:
对象状态七、为什么现在很多框架还没完全走到这里?
我觉得原因是:
当前很多 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 GraphAgent 只是:
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