一个 Agent 架构的诚实评估：哪些会留下、哪些不会
大多数架构文章以"作者被自己说服"结尾。这一篇相反：我自己的五层 agent 架构是什么、不是什么、能吸收什么、哪些假设我认为活不过下一次 paradigm shift。
30 秒电梯版
我的五层 agent 架构是 40% 业界综合 + 30% 短期个人实践 + 30% 工程 判断——不是”被验证的最佳实践”。它能吸收模型升级和框架变化、 多模态和自主 agent 演进需要适应、如果真有新 paradigm 出现会 过时。写这一篇的意义在于展示”诚实评估自己架构的局限”本身就是 最重要的架构能力——也是面试场景里最稀缺的。
为什么大多数架构文章误导人
读任何框架对比或架构提案。结构几乎都是：这是问题；这是设计；这是 为什么有效。作者被自己说服。读者也被说服。
两边都错——因为**“被说服”是错的目标**。正确的目标是诚实意识到 这个设计在哪成立、在哪不成立。这才是能扛住未来需求的东西。
我描述了一个五层 agent 架构 和一个跨产品的参考实现。 这一篇做我应该一开始就做的事：诚实评估它。
这套架构从哪来
我想精确说明来源——因为答案影响应该给它多少权重。
| 来源 | 占比 | 具体什么 | 可信度 |
|---|---|---|---|
| 业界综合 | ~40% | LangGraph、LangFuse、MCP、A2A、Reflexion、Generator-Evaluator、MemGPT 的概念、论文、文档 | 高（公开、可验证） |
| 茶会实践 | ~30% | Persona/Specialist 拆分、反谄媚规则、Rules/Hooks 分层、Episodic 工程化 | 中（只有 ~6 周个人使用，不是生产规模） |
| 工程判断 | ~30% | TS 优于 Python、LangFuse 优于 LangSmith、“先迁茶会”、5 层命名本身 | 中-低（基于经验，未经严格验证） |
这意味着：
- 业界综合 部分是 信息聚合，不是创新
- 实践 部分是 真实但样本小——一个人六周的 dogfood 不是生产 测试
- 判断 部分是 经验加逻辑，不是被验证的最佳实践
所以这是”基于当前可见信息的有判断的设计”，不是”被验证的最佳实践”。 这个区分在面试场景里至关重要。
它会扛住未来变化吗？四个维度。
我对四种变化逐个评估，每个给一个判断。
维度 1：模型能力变化
| 变化 | 判断 |
|---|---|
| LLM 升级（GPT-5、Claude 5） | ✅ 扛得住 — 五层栈模型无关 |
| 上下文窗口扩大（200k → 2M+） | ✅ 扛得住 — 概念层加载更轻松 |
| 推理模型成为默认 | ⚠️ 需调整 — Sprint 编排可能简化 |
| 多模态融合（图/视频/语音） | ⚠️ 需扩展 — Memory 层要加多模态字段 |
维度 2：框架/协议变化
| 变化 | 判断 |
|---|---|
| LangGraph 失败或被收购 | ⚠️ 可换但有成本 — 抽象层缓解，但写过的节点要重新移植 |
| OpenAI/Anthropic 出新 SDK 灭 LangGraph | ⚠️ 可换 — 同上 |
| MCP/A2A 协议演进 | ✅ 扛得住 — 接口已经预留 |
| 新 paradigm 出现（如全自主 neural-symbolic agent） | ❌ 大概率落伍 — 五层假设 “agent = LLM + 编排” |
维度 3：产品形态变化
| 变化 | 判断 |
|---|---|
| chat → voice | ✅ 扛得住 — 输入层换 |
| 单 agent → multi-agent | ✅ 已扛 — 这正是设计 |
| 半自主 → 全自主 | ⚠️ 需扩展 — Persona/Specialist 假设有人类决策点 |
| Ambient computing（无屏幕） | ❌ 应对不了 — 架构假设有 UI |
维度 4：部署形态变化
| 变化 | 判断 |
|---|---|
| 云 → edge | ✅ 已扛 — Cloudflare 原生 |
| API → 本地模型 | ⚠️ 需适应 — Memory 假设云端持久化 |
| 推理 → 个性化训练 | ❌ 不在范围 — 完全不同的层 |
哪些抽象会留下、哪些不会
比”会扛吗”更有意思的问题：哪些具体抽象是耐久的？
大概率留 5-10 年
- Memory 是底座不是功能 — AI 产品的差异化正向记忆层移动，不是 模型层
- 思考 vs 执行作为不同角色 — 名字（Persona/Specialist）可能换， 但这个区分本身会留下
- 可观测性是必须 — trace、recovery、time-travel 是工业标准
- 跨 agent 协议通信 — A2A 类协议会演进，但概念会持续
可能留不到 2-5 年
- 具体的”5 层”数字 — 可能变成 4 或 7
- Persona 用 markdown、Specialist 用 YAML — 格式可能变
- 5 行反谄媚规则 — 如果 RLHF 训练范式变了，这个具体战术可能 不需要
- DAG 编排 — 全自主 agent 可能让 DAG 让位给 emergent behavior
- 6 子层 Memory — MemGPT 系演进可能塌缩这个分层
几乎确定 1-3 年内过时
- 具体框架选择（LangGraph vs Mastra vs 其他）
- 具体协议版本（MCP v1 → v2）
- 具体存储（D1 / R2 / Vectorize）
- 具体提供商（Cloudflare / Anthropic / OpenAI 格局变化）
“面向未来”实际意味着什么
“面向未来的架构”是营销词。诚实版本是：哪些抽象稳到值得写代码绑定它。
这套架构里最稳的抽象：
- 分层这个动作本身（不是具体的 5 层）
- 思考-执行分离（不是具体名字）
- Memory 作为架构而非功能（不是具体 6 子层）
- 运行时纪律 > 训练层依赖（反谄媚规则的精神）
最不稳的：
- 具体框架/协议/存储选择
- 具体层数
- 具体格式选择（markdown / YAML）
对原则写代码，不对框架写代码。
让架构更耐久的工程实践
四个具体实践，都值得提前承诺：
1. 每一层加抽象边界
// 错
const result = await langGraphInvoke(...)
// 对
const result = await skillRunner.execute(...)
// skillRunner 内部用 LangGraph；换框架时不动业务代码2. 把协议和实现分清
- A2A 状态值 → 协议 — 写到代码契约里
- LangGraph reducer API → 实现 — 藏在 skillRunner 里
3. 留 paradigm-shift 应急接口
- Memory 暴露 MCP server → 如果 agent 框架范式变了，新框架直接消费
- Skills 暴露 A2A 端点 → 跨系统协作免迁移
4. 每 6 个月重审架构
- 每 6 个月跑一次”5 层划分还成立吗”评审
- 如果某层应该拆/合，做了——不要把当前设计当教条
- 架构是当前最优归纳，不是教条
真正的护城河不是架构
如果你从这一篇带走一件事：架构本身不是耐久的优势。耐久的优势是 持续评估和演进架构的纪律。
架构可以被复制。判断 + 复盘 + 调整的循环更难复制——因为它需要 多年的持续注意力。
一个交付更差但持续演进的团队，三年后会赢一个交付更好但冻结的团队。 冻结的团队有更好的 day-1 设计和更糟的 year-3 系统。
这一篇怎么用在面试
标准架构问题：“走一遍你的 agent 系统设计”。
标准候选人回应：这是我的系统，这是为什么对。被说服。
更好的回应，按这一篇为模型：
这是架构。现在让我告诉你它是什么、不是什么。底座是业界综合的； personas/specialists 拆分是我自己的观察；工程选择是判断而非严格 验证。它扛得住模型升级和协议演进。多模态和全自主需要适应。如果 真出现新 agent paradigm 会过时。我预期 5-10 年留下的抽象是 X、Y、Z； 预期 2-3 年过时的是 A、B、C。真正的护城河是持续评估的纪律，不是 设计本身。
这个答案罕见。大多数面试官从没听过候选人主动列出自己设计里 他认为可能错的假设。做这件事让你进入另一个候选人类别。
那个类别是 “有架构判断力的工程师”，而不是 “会交付架构的工程师”。
这一篇评估的架构，见 跨产品 Agent 系统的参考架构 和 五层 Agent 系统。