《Agent 架构的诚实评估》读书笔记

1. 主文章在讲什么（30 秒）

一句话主线：我的五层 agent 架构是 40% 业界综合 + 30% 短期实践 + 30% 经验判断——不是”最佳实践”。能扛模型升级和框架变化、需要适应多模态和自主 agent、新 paradigm 出现会过时。写这一篇的意义在于”诚实评估自己架构”本身就是最稀缺的架构能力。

反对什么观点：

• 反对架构文章以”作者被自己说服”结尾
• 反对”面向未来”的营销表述——所有架构都会过时
• 反对”找到了最佳实践”——大多数”最佳实践”是当前最优归纳

如果只能记一句话：

真正的护城河不是架构本身，是持续评估和演进架构的纪律。

2. 关键概念词典

三种”架构正确性”

三种来源

四个变化维度

三种抽象稳定性

3. 完整脉络（主文章每节展开）

为什么大多数架构文章误导

架构文章的标准结构：问题 → 设计 → 为什么对。作者被自己说服。

这个结构有两个隐藏假设：

1. 作者已经知道答案——但好架构是迭代出来的，不是一次写对的
2. 读者只需被说服——但读者真正需要的是判断它在哪成立

好架构 ≠ 让人信服的架构。好架构 = 让人能判断”什么时候用什么时候不用”的架构。

三个来源的重要性

为什么必须坦白来源结构？

业界综合的部分（如 LangGraph、Reflexion）→ 我可以指向论文/文档/框架作为证据。读者可以独立验证。

个人实践的部分（如 Persona/Specialist 拆分、反谄媚规则）→ 我只能指向茶会的 6 周经验——样本太小，可能特例。读者应该警惕。

工程判断的部分（如 TS vs Python、迁移路径）→ 我只能给理由，没有数据。读者应该当观点，不当事实。

坦白这个结构 = 给读者权重信息。不坦白 = 把所有论点都包装成同等可信——这是营销，不是工程。

四个维度的演进性，深度

为什么模型升级”能扛”：5 层架构的接口是模型无关的。每层调 LLM 都是 abstract call，换 GPT-5 / Claude 5 / 任何模型只是配置改动。

为什么框架变化”可换但有成本”：抽象层（SkillRunner 等）隔离了框架细节。但写过的 LangGraph 节点要重新移植——这是 abstraction leak 的代价。没有零成本切换，只有 mitigated cost。

为什么新 paradigm “可能过时”：5 层架构假设 “agent = LLM + 编排”。如果未来出现：

• 真正的 neural-symbolic agent（不需要外部编排）
• Ambient computing（不需要 chat 入口）
• Brain-like memory（不需要分层 memory）

那时不是改一层就能适应——是整套架构假设错了。

为什么 ambient computing “应对不了”：我的架构假设有 user → input → agent → output 的循环。ambient 是 agent 主动 + 多用户 + 没明显边界——根本不是同一个范式。

哪些抽象会留下，深度

为什么 “Memory 是底座” 会留 5-10 年：因为 AI 产品的差异化趋势已经明确——模型层在收敛（前三家差距小），差异化往应用层移动。Memory 是应用层最大的杠杆，这个趋势不会逆转。

为什么 “思考-执行分离” 会留：这不是 agent 特定问题——是任何决策系统的本质。人类组织里，“董事会决策 + 团队执行”的二分已经存在数百年。AI 系统重新发现这个二分，反映了底层组织规律，不是技术 fad。

为什么 “5 层” 数字可能变：5 是当前归纳的结果。可能未来发现：

• Conceptual layer 应该独立成第 6 层（现在归在 Memory 里）
• Trace 应该独立成层（现在归在可观测性里）
• Rules 和 Hooks 可以合并

5 不是定理，是经验值。

“面向未来”的真正含义

这个词被滥用。真正的”面向未来” = 抽象边界稳到值得绑定。

具体的工程实践：

1. 接口比实现稳——绑接口
2. 协议比框架稳——绑协议
3. 原则比模式稳——理解原则

举例：

• LangGraph API 不稳 → 包在 SkillRunner 里 → 业务代码绑 SkillRunner
• A2A 协议比 LangGraph 稳 → 直接绑 A2A 状态值
• “Memory 是底座” 比 “6 子层” 稳 → 把这条原则当指南，6 子层当当前实现

真正的护城河

如果架构本身不是护城河，什么是？

评估 + 演进的纪律。

具体表现：

• 每 6 个月做一次架构复盘——还成立吗？
• 每次新需求来时问——这要在哪一层加？要不要重新分层？
• 每次踩坑时追问——是实现 bug，还是抽象 bug？

这些是不会被复制的能力——它需要多年的持续注意力。

4. 真实代码 / 数据

三个来源的真实拆解

我的五层架构里，每个抽象的具体来源：

任何抽象我都能说出来源。这是诚实的最低标准。

评估纪律的具体实施

我建议（也是给自己的）：

## 架构季度复盘 (2026 Q3)

日期：YYYY-MM-DD
评审者：自己

### 1. 5 层划分还成立吗？
- Memory 层是否需要拆？
- 是否有新层应该加？
- 是否有层应该合？

### 2. 哪些抽象出现了 leak？
- 哪个产品代码不得不知道底座的实现细节？
- 这是 SDK bug 还是抽象不对？

### 3. 哪些预测错了？
- 之前认为"会留下"的，过时了吗？
- 之前认为"会过时"的，反而稳了吗？

### 4. 哪些新趋势没纳入？
- 业界出了什么新东西我应该评估？

每季度跑一次。不跑这个复盘 = 架构开始僵化的开始。

数据：6 周内已经修正的判断

我自己写文章时被发现的”判断错误”：

6 周内 4 次自我修正——这本身是”评估纪律”的证据，但也证明 I’m not infallible。没有评估纪律会有更多没被发现的错误。

5. 架构图

图 1：三种”架构正确性”的位置

   ←──── 越往左越权威 ──── 越往右越主观 ────→
   
   ┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
   │  被验证的最佳实践  │  │   当前最优归纳    │  │    个人偏好       │
   │  (validated)       │  │   (current best   │  │    (preference)   │
   │                    │  │    induction)     │  │                   │
   │  TCP/IP            │  │  我的 5 层架构    │  │  tab vs space     │
   │  ACID 数据库        │  │  Reflexion 模式   │  │  编辑器选择       │
   │  HTTP              │  │  LangGraph 用法   │  │  CSS 框架偏好     │
   └──────────────────┘  └──────────────────┘  └──────────────────┘
   
   多年 + 多团队 +         基于现有信息的       没数据，只有审美
   严格 benchmark          有判断设计
   
   大多数 AI 架构文章
   把第二格自称第一格 ←── 这是诚实问题的根源

图 2：四个变化维度的应对

   维度          应对                            预期成本
   
   模型能力     ✅ 接口模型无关，免维护             零
   ↓
   框架/协议    ⚠️ 抽象层隔离，换实现要重写         数周
   ↓
   产品形态     ⚠️ 输入/输出层适配                  数周
   ↓
   新 paradigm  ❌ 整套假设可能错，需重新评估       数月-重写

图 3：抽象的稳定性梯度

                        稳定性
   
   高 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 高
   │                                       │
   │  原则                                  │
   │  - 分层思考                            │
   │  - 思考-执行分离                       │
   │  - Memory 是底座                       │
   │                                       │
   │  协议                                  │
   │  - A2A 状态值                          │
   │  - MCP 接口                            │
   │                                       │
   │  接口（自己定义的抽象）                 │
   │  - SkillRunner                         │
   │  - Persona / Specialist 类             │
   │                                       │
   │  实现细节                               │
   │  - LangGraph API                       │
   │  - 具体 storage（D1 / R2）              │
   │  - 6 子层数字                           │
   │                                       │
   低 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 低
   
   绑定原则 → 不会过时
   绑定协议 → 演进缓慢
   绑定接口 → 自己控制
   绑定实现 → 一年内大改

6. 我的批注

我和我以前的想法的冲突

以前：我以为”写出好架构”就够了。 现在：写出好架构 ≠ 让架构持续好。第一天的好不等于第三年的好。演进纪律比设计本身更重要。

以前：我把”被自己说服”当成”想清楚了”的标志。 现在：被自己说服是危险信号——它意味着停止了批判。好的架构师对自己的架构永远有 30% 的怀疑。

以前：我把”承认局限”当成示弱。 现在：承认局限是力量——它让我能听到反对意见、能调整、能演进。装作没局限的架构师，被现实教训时损失更大。

反复想过的部分

“40% / 30% / 30%” 是真实数字吗——不是。我没法精确量化。这是直觉估算。但给一个数字让讨论变具体——比”主要来自业界 + 一些自己的”模糊得多。精确的错比模糊的对更有用——前者可以被反驳和修正。

为什么不直接说”这是我的当前归纳”而要写整篇评估——因为说这一句不够。读者听到”当前归纳”会自动忽略这个 caveat，继续当成最佳实践。只有详细列出”哪里成立、哪里不成立”，caveat 才有真实力量。

为什么强调”演进纪律是护城河”——这听起来像鸡汤——确实有鸡汤味。但具体化之后是可执行的：每季度做架构复盘、每次踩坑追问抽象 bug、每次新需求问”重新分层吗”。鸡汤变成 checklist 就是工程方法。

下次会改的

• 加一个”我已经验证错的预测”列表——这一篇说”哪些可能过时”是预测。6 个月后应该回来看哪些预测准了哪些错了——这是元评估的元评估。
• 架构复盘的产出沉淀——每季度复盘后产生的”修正”应该成为 episodic record 的一种 type，进入 Memory 层。这样未来的复盘能基于过去的复盘——meta-learning。
• 跨架构师的对照评估——目前所有判断都是我自己的。应该找另一个 senior 工程师做”红队评估”——挑战我的每个假设。单人复盘不如对抗复盘。

7. 面试话术（按时长背三档）

30 秒电梯版

2 分钟白板版

10 分钟深入版

8. 可能被问到的 5 个问题 + 回应

问题 1：你说”40% / 30% / 30%“——这个数字是怎么算的？

回应：

不是精确量化的——是直觉估算。我没办法严格测量”这个抽象有多少来自业界、多少来自实践”。

但给一个数字让讨论变具体。“主要来自业界，一些来自实践”是模糊的。“40/30/30”是可以被反驳和修正的——你可以说”我觉得业界部分应该是 50%“，然后我们可以具体讨论。

精确的错比模糊的对更有用——前者推动思考，后者结束思考。

问题 2：你说”会过时”——那为什么还推荐人用？

回应：

“会过时”和”现在没用”不是一回事。

类比：所有数据库都会过时（5 年前用 MongoDB 现在用 Postgres 用 Cloud Spanner），但当前选 Postgres 仍然是好决策。

我的架构是当前最优归纳——基于 2026 年信息的最好选择。3 年后可能不是最好——那时换。

关键是不要把”当前最优”当成”永恒真理”——保留换的能力。这就是抽象边界存在的理由。

问题 3：你怎么知道哪些抽象会留下？这本身就是预测。

回应：

对，这是预测。预测可能错。

所以我显式标注预测的时间窗口（5-10 年 / 2-5 年 / 1-3 年）。这让我未来能验证——6 个月后回来看哪些预测准了。

预测不带时间窗口 = 不可证伪 = 没有信息量。预测带时间窗口 = 可验证 = 有信息量。

我不假装我能预测未来——我假装我愿意把预测写下来让未来验证。这是诚实的最低标准。

问题 4：你这种”诚实评估”会不会让招聘方觉得你不自信？

回应：

取决于招聘方的判断力。

如果对方是优秀工程师/架构师——他们见过太多过度自信的候选人，诚实评估让你脱颖而出。这是稀缺信号。

如果对方是只看 confidence 不看 substance 的招聘方——他们可能扣分。但这种公司不是你想去的——他们会买”自信”，结果买到糟糕设计。

真正想雇你的公司，会被诚实吸引，不是被自信吸引。这是个 selector，不是 bug。

问题 5：每 6 个月架构复盘——具体怎么做？

回应：

我提议的格式：

1. 重读上次复盘 —— 上次预测了什么？
2. 5 层划分还成立吗 —— 是否需要拆/合？
3. 哪些抽象出现 leak —— 产品代码不得不知道底座细节的地方？
4. 哪些预测错了 —— 之前认为留下的过时了？反过来呢？
5. 业界新趋势 —— 这 6 个月出了什么应该评估？
6. 修正决策 —— 基于以上，要改什么？

每次约 2-4 小时。写成 markdown，存到 episodic record（type=architecture-review）。

关键：复盘必须产生具体修正动作，不能只是 “everything is fine”。如果连续两次复盘没动作，说明架构没在演进——这本身是问题信号。

9. 相关链接

内部（其他主文章）

• Five Layers of an Agent System — 这一篇评估的架构
• Reference Architecture for Cross-Product Agent Systems — 跨产品应用
• Memory as Foundation — 评估中的 Memory 层
• Persona vs Specialist Split — 评估中的 Agent 层
• Anti-Sycophancy Rule — 评估中的稀缺贡献
• Agent Framework Landscape — 业界对比

外部参考

• MemGPT (Packer et al., 2023) — Memory 6 子层灵感来源
• Reflexion (Shinn et al., 2023) — Episodic memory 学术起源
• Sycophancy in RLHF Models (Anthropic, 2023) — 反谄媚规则的科学基础
• Voyager (Wang et al., 2023) — 模式提炼的灵感

相关概念

• Antifragility (Taleb) ≈ “演进纪律 > 架构本身” 的哲学根基
• Falsifiability (Popper) ≈ “预测带时间窗口” 的认识论基础
• Architecture Review ≈ 每 6 个月复盘的成熟实践