生产级 Agent 基础设施：协议、记忆、耐久执行与能力安全

有，而且如果继续沿着我们前面那条“Agent OS”思路往下看，我认为 2026 年真正有价值的新概念已经从“怎么写 Agent”转向“怎么让 Agent 成为可靠的软件基础设施”。

我会把值得关注的东西分成下面这张图：

协议、记忆、耐久执行与能力安全围绕 Agent Runtime — 原对话中的主架构图已重绘为 SVG；正文、代码与其余推导保持原貌。

其中我最建议你重点关注 10 个方向。

1. ACP：Agent Client Protocol

这个东西对你前面研究 Codex / Pi / Antigravity 特别重要。

我们之前有一个问题：

1. ACP：Agent Client Protocol的分层或流程图 — 1. ACP：Agent Client Protocol

每个 Agent 都有自己的：

这样最终变成：

1. ACP：Agent Client Protocol的架构或流程图 — 1. ACP：Agent Client Protocol

是一个典型的：

N × M integration problem

ACP 正在尝试解决这个问题。

ACP 的定位非常像：

Agent 世界的 LSP。

官方定义就是：标准化代码编辑器 / IDE 与 coding agent 之间的通信，使 Agent 和 Client 解耦。

于是变成：

这非常重要。

LSP 当年的作用

以前：

后来：

现在 Agent 世界正在出现类似结构：

截至 2026 年，ACP 已经有 Codex、Gemini CLI、Cursor、Hermes、OpenClaw、OpenCode、Pi 等一大批实现或 adapter。

甚至已经有：

这些能力稳定下来。

所以以后很可能出现：

这意味着：

TUI 本身可能不再是 Agent 的核心资产。

Agent UI 将逐渐 commoditize。

2. MCP + ACP + A2A：Agent 世界正在形成“三层协议栈”

这是我认为目前特别值得理解的一个概念。

现在至少可以看到三种非常不同的协议：

ACP
MCP
A2A

它们分别解决不同边界。

MCP

解决：

Agent
  ↓
Tool

例如：

ACP

解决：

Client
  ↓
Agent

例如：

A2A

解决：

Agent
  ↓
Agent

Google 发起的 Agent2Agent Protocol 当前明确把自己的定位定义为不同 Agent 之间的互操作标准，并且特别强调 MCP 与 A2A 是互补关系：

MCP = agent ↔ tool
A2A = agent ↔ agent

所以最终非常漂亮：

可以总结成：

我认为这是未来 Agent Infrastructure 最值得记住的一张图。

3. Durable Agent：Agent 不再等于一个 while loop

前面我们讲：

while (!done) {
  response = await llm();
  executeTools();
}

这是 demo agent。

工业 Agent 最大的问题是：

3. Durable Agent：Agent 不再等于一个 while loop的分层或流程图 — 3. Durable Agent：Agent 不再等于一个 while loop

于是出现一个极重要概念：

Durable Execution

也就是：

而不是：

crash
  ↓
从头再跑

4. LangGraph / Temporal：Agent 开始与 Workflow Engine 融合

LangGraph 当前明确把自己的核心能力定义为：

其 production Agent Server 已经是典型分布式工作流架构：

4. LangGraph / Temporal：Agent 开始与 Workflow Engine 融合的架构或流程图 — 4. LangGraph / Temporal：Agent 开始与 Workflow Engine 融合

如果 Worker 崩溃，可以从 checkpoint 恢复。

这已经不太像普通：

LLM framework

而更像：

Distributed workflow runtime

Temporal 则是从另一边进入 Agent

Temporal 原本解决：

例如：

Temporal 则是从另一边进入 Agent的架构或流程图 — Temporal 则是从另一边进入 Agent

哪一步挂了，都可以恢复。

现在 Agent 出现以后：

实际上和 workflow engine 的问题高度相似。

所以现在一个非常重要的架构趋势是：

Agent Engine
     +
Workflow Engine

LangChain 自己在比较 LangGraph 与 Temporal 时，也明确承认两者可以组合：

LangGraph → agent orchestration
Temporal → generic durable workflow

我认为大型生产 Agent 最终基本都会有：

Durable Task Runtime

这一层。

5. Agent 不应该是 Coroutine，而应该是 Durable Process

这是一个很重要的架构认知变化。

早期：

Agent = async function

未来：

Agent = durable process

也就是：

Agent {
  id
  state
  mailbox
  checkpoint
  permissions
  memory
  leases
  timers
}

它很接近 Erlang Actor：

5. Agent 不应该是 Coroutine，而应该是 Durable Process的架构或流程图 — 5. Agent 不应该是 Coroutine，而应该是 Durable Process

于是 Agent 架构会越来越像：

我甚至认为：

Actor Model 会重新在 Agent 世界里变得非常重要。

6. Memory OS：Memory 正在独立成一个基础设施层

前面我们把 memory 当：

AgentSession.messages

这是不够的。

真正长期 Agent 会遇到：

6. Memory OS：Memory 正在独立成一个基础设施层的分层或流程图 — 6. Memory OS：Memory 正在独立成一个基础设施层

所以：

Memory != Vector DB

这是非常关键的认知。

7. 现在 Memory 出现了三种主流哲学

Mem0：Fact Memory

例如：

适合：

preference
personalization
user facts

Zep / Graphiti：Temporal Knowledge Graph

它特别关注：

什么事情在什么时候成立？

例如：

Zep / Graphiti：Temporal Knowledge Graph的分层或流程图 — Zep / Graphiti：Temporal Knowledge Graph

普通 vector memory 很容易同时搜到：

Alice → Google
Alice → OpenAI

不知道谁过期。

Temporal Graph 会变成：

Zep / Graphiti：Temporal Knowledge Graph的架构或流程图 — Zep / Graphiti：Temporal Knowledge Graph

2026 年的很多 memory comparison 都已经把这个差异作为 Zep/Graphiti 的核心特征。

Letta：Memory Paging

Letta/MemGPT 的思路非常像：

Virtual Memory

把 context 看成：

RAM

长期存储看成：

Disk

Agent 自己管理：

哪些内容应该进入 working context
哪些内容应该换出去

所以：

Letta：Memory Paging的分层或流程图 — Letta：Memory Paging

这是一个非常“Agent OS”的设计。

8. Context Engineering 正在取代 Prompt Engineering

早期大家研究：

Prompt Engineering

例如：

你是一个优秀的程序员……
一步一步思考……

现在真正决定 Agent 效果的是：

Context Engineering

也就是决定：

这一轮模型到底看什么？

模型 context 可能包含：

8. Context Engineering 正在取代 Prompt Engineering的分层或流程图 — 8. Context Engineering 正在取代 Prompt Engineering

问题变成一个 optimization：

8. Context Engineering 正在取代 Prompt Engineering的架构或流程图 — 8. Context Engineering 正在取代 Prompt Engineering

所以未来很可能有专门的：

Context Engine

而不仅仅是：

messages.push(...)

9. Agent Sandbox 正在成为独立基础设施

以前 Coding Agent：

风险太高。

现在越来越多系统采用：

目前比较典型的一类产品：

9. Agent Sandbox 正在成为独立基础设施的分层或流程图 — 9. Agent Sandbox 正在成为独立基础设施

2026 年的比较通常已经围绕：

这些维度展开。

Agent execution 很可能最终变成：

而不是：

Agent → localhost

10. Workspace 本身正在成为 First-class Object

这又是一个很有意义的变化。

以前：

cwd = "/home/user/project"

未来：

Workspace {
  id
  repository
  filesystemSnapshot
  branch
  environment
  secrets
  permissions
  sandbox
}

然后：

Agent A ─────┐
Agent B ─────┼── Workspace #123
Agent C ─────┘

甚至：

fork workspace

变成：

10. Workspace 本身正在成为 First-class Object的架构或流程图 — 10. Workspace 本身正在成为 First-class Object

再：

compare
 ↓
merge best

这其实非常类似 Git branch + container snapshot。

对于 Coding Agent，我认为这个概念会越来越重要。

11. Agent Observability：不只是 Log

普通服务观察：

Agent 的问题不同：

所以出现：

Agent Trace

例如：

11. Agent Observability：不只是 Log的架构或流程图 — 11. Agent Observability：不只是 Log

对应的工具生态有：

2026 年 Agent observability 已经明显从“记录 prompt”演进到 trace + eval + cost + latency + subagent/tool spans。

12. Evals 正在变成 Agent 的“测试系统”

这是另一个非常重要的变化。

以前：

expect(add(1,2)).toBe(3);

Agent 很难这么测。

例如：

Task:
修复这个 Bug

可能存在十种正确方案。

于是 Agent eval 通常会变成：

12. Evals 正在变成 Agent 的“测试系统”的架构或流程图 — 12. Evals 正在变成 Agent 的“测试系统”

对于 Coding Agent，最理想的是：

所以：

Agent 系统未来真正重要的竞争力，不只是 Agent 有多聪明，而是 Verifier 有多强。

13. Generator–Verifier Architecture

我非常建议你记住这个词。

不要设计：

LLM
 ↓
answer

而是：

13. Generator–Verifier Architecture的架构或流程图 — 13. Generator–Verifier Architecture

Coding Agent 特别适合：

这比让一个更大的模型：

“请认真检查”

可靠得多。

14. Agent Runtime 会越来越偏向“Deterministic Shell + Probabilistic Brain”

这是我认为架构上最重要的原则之一：

例如：

LLM 可以提议：

delete database

但是：

Policy Engine

决定能不能。

LLM 可以写代码：

foo()

但：

TypeScript compiler

决定是否类型正确。

LLM 可以说：

任务完成

但：

Test Runner

决定是否完成。

所以好的 Agent OS 应该遵循：

让模型负责探索和决策，让确定性软件负责约束和验证。

15. Agent Identity / Delegation

当 A Agent 调用 B Agent：

问题来了：

GitHub 看到谁？

Alice？
Agent A？
Agent B？

权限又应该是多少？

Alice：

repo admin

是否意味着：

Agent B = repo admin

显然不应该。

所以未来一个很重要的基础设施方向是：

Delegated Identity

类似：

例如：

这里会逐渐和：

15. Agent Identity / Delegation的分层或流程图 — 15. Agent Identity / Delegation

融合。

我认为 Agent IAM 会成为一个非常大的领域。

16. Capability Security 会比传统 RBAC 更适合 Agent

传统：

Role = Developer

权限：

read repo
write repo
deploy

Agent 更适合：

Capability Token

比如：

{
  "repo": "foo/bar",
  "permission": ["read", "edit"],
  "expires": "30m"
}

甚至：

16. Capability Security 会比传统 RBAC 更适合 Agent的分层或流程图 — 16. Capability Security 会比传统 RBAC 更适合 Agent

即：

这非常符合 Agent 特性。

17. Blackboard Architecture 会重新流行

Multi-Agent 最早很多框架喜欢：

Agent A talks to B
B talks to C
C talks to A

很快会变成：

conversation spaghetti

更好的架构之一是：

Blackboard

Agent 不一定互相聊天。

它们：

这比：

Agent Chatroom

更容易：

18. Artifact-centric Agent

另一个我非常看好的架构：

不要把 Agent 系统中心设计成：

Conversation

而是：

Artifact

例如 coding task：

18. Artifact-centric Agent的架构或流程图 — 18. Artifact-centric Agent

每一步都是结构化 artifact：

PatchArtifact
TestArtifact
ReviewArtifact
PlanArtifact

于是：

比：

一堆聊天消息

强得多。

19. Event-driven Agent

传统：

User Prompt
 ↓
Agent

未来 Agent 更多是：

Event
 ↓
Agent

例如：

19. Event-driven Agent的架构或流程图 — 19. Event-driven Agent

所以 Agent 系统越来越像：

这也是为什么以后：

19. Event-driven Agent的分层或流程图 — 19. Event-driven Agent

都会成为 Agent OS 标准能力。

20. Agent Mesh

如果这些东西继续发展，就会出现：

Service Mesh

对应物：

Agent Mesh

Service Mesh 今天解决：

Agent Mesh 将解决：

例如：

我认为这是非常自然的演进方向。

21. Agent Marketplace / Agent Registry

当 A2A 成熟以后：

Agent
 ↓
findAgent("legal-review")

可能和今天：

npm install
docker pull

很像。

例如：

21. Agent Marketplace / Agent Registry的分层或流程图 — 21. Agent Marketplace / Agent Registry

然后：

21. Agent Marketplace / Agent Registry的架构或流程图 — 21. Agent Marketplace / Agent Registry

ACP 已经出现 Agent Registry，用于让 clients 发现、安装和配置 agent。

未来 A2A 世界也很可能出现更加普遍的：

Agent Discovery

22. Computer Use 会变成一种特殊 Tool Runtime

现在很多 Agent：

API-first

但大量现实软件根本没有：

MCP
API

只能：

browser
desktop
GUI

所以：

Computer Use

其实是在创造一个：

Universal Human-Compatible API

架构：

相当于：

如果软件不给 Agent API，那 Agent 就使用人类的 API —— UI。

这个方向长期意义非常大。

23. Browser Agent 和 Browser Automation 也会逐渐分层

不要把：

Playwright

和：

Browser Agent

认为是一回事。

未来可能是：

23. Browser Agent 和 Browser Automation 也会逐渐分层的架构或流程图 — 23. Browser Agent 和 Browser Automation 也会逐渐分层

Agent说：

购买这张机票

Runtime 负责：

23. Browser Agent 和 Browser Automation 也会逐渐分层的分层或流程图 — 23. Browser Agent 和 Browser Automation 也会逐渐分层

也就是说 browser agent 也会重复我们前面：

Agent vs Runtime

的分层。

24. 我认为最值得长期跟踪的架构其实是这张

最终 Agent Infra 很可能长这样：

这比单纯：

LLM + tools

已经复杂了一个数量级。

如果让我选“现在最值得你深入研究”的 8 个

考虑到你已经在研究 Codex、Pi、OpenClaw、Hermes，我不会再让你去研究十几个类似 Agent Framework。

我建议按这个顺序：

优先级	概念	建议看的东西	为什么
⭐⭐⭐⭐⭐	ACP	Agent Client Protocol	理解 Agent/UI 解耦
⭐⭐⭐⭐⭐	A2A	Agent2Agent Protocol	理解 Agent 间互操作
⭐⭐⭐⭐⭐	Durable Execution	LangGraph + Temporal	从 demo agent 跨到生产系统
⭐⭐⭐⭐⭐	Memory Architecture	Letta + Zep/Graphiti + Mem0	真正理解长期 Agent
⭐⭐⭐⭐	Agent Sandbox	E2B / Daytona / Modal	Agent 与计算环境解耦
⭐⭐⭐⭐	Agent Observability	Langfuse / Phoenix / LangSmith	学会 debug Agent
⭐⭐⭐⭐	Artifact Architecture	多 Agent workflow 思路	比聊天式 multi-agent 更工程化
⭐⭐⭐⭐	Capability Security / Agent IAM	OAuth + capability-based security 思路	未来 Agent 系统的安全基础

其中前三个尤其重要。

如果你把我们前面聊的东西串起来，实际上已经可以形成一个非常完整的学习路径：

如果让我选“现在最值得你深入研究”的 8 个的架构或流程图 — 如果让我选“现在最值得你深入研究”的 8 个

到第五阶段以后，你学的其实已经不再是所谓的 “AI Agent 开发”。

而是在学：

Distributed Systems + Operating Systems + Security + Workflow Engines + LLM。

这也是为什么我认为 Agent 这个领域最有意思的一点，不是又多了多少个 xxx-agent npm 包，而是过去几十年的很多经典计算机体系结构——Actor、事件溯源、工作流引擎、Capability Security、OS 调度、IPC、Service Mesh、知识图谱、分布式系统——正在以一种新的形式重新组合。

如果你的目标最终是自己做一套类似 Pi/Codex，但架构更完整的 Agent Runtime / Mini Agent OS，下一步最合适的就是直接把这些概念收敛成一份 “Agent OS 系统设计图”，然后我们从 AgentProcess → Scheduler → Tool syscall → MCP → ACP → A2A → Memory → Sandbox → Event Store 一层一层设计接口；这个过程会比继续横向看项目更有收获。