跨书章节优先级 · 70+ 章节 · 深度精读 vs 跳过

6 本书 · ADP + AM + AX + Team Topologies + DDIA + MDR · 共 70 章节 · 按 Solutions team lead(12 人 team)综合排序 · 每个 Tier 1 章节读完本页等于读完原章

这页是什么

6 本书速览

优先级方法论

Tier 1 · 15 章必读 · 深度精读

每章 300-400 字,读完等于学完原章。 按推荐阅读顺序排,不是按书序。

① ADP Ch.2 · Routing(路由模式)

核心概念: Routing 是 agent 系统的"分发逻辑层" — 给定一个输入,决定下一步交给哪个子 agent / tool / branch 处理。 看似简单,但 routing 的设计决定了系统的可观测性、可调试性、可解释性。

3 种 routing 范式 + 何时用:

• Rule-based routing: 用 keyword / regex / structured field 判断。 优点:确定性、零延迟、零 token 成本、可单元测试。 缺点:不能处理模糊语义。 适用: 输入有清晰 schema(API 调用、表单提交)或域窄(财务 vs 法务的明显分支)。
• LLM-based routing: 让 LLM 读 input + system prompt 选 branch。 优点:处理模糊语义、多语言、复杂意图。 缺点:不确定性、有 token 成本、有 latency、需要 fallback。 适用: 客户输入是自然语言 + 意图模糊(客服、研究助手)。
• Hybrid (rule-first, LLM-fallback): 90% 流量走 rule,10% 走 LLM 兜底。 生产环境默认选项 · 90% 流量零成本 + 边缘情况有保底。

关键判断准则: 如果一个 routing 决策的输出可以列举(<10 个 branch)且 input 有清晰特征,优先 rule。 LLM routing 的"灵活"在生产里更常表现为"不可调试"。

反 pattern: - 过度分层 routing: 4 层嵌套 router · 一个请求经 4 次 LLM call · 不仅慢,而且任何一层出错全链路崩。 上限 2 层。 - 没有 fallback branch: LLM 路由 99% 工作,但漏 1% 时整个系统沉默失败。 必须有 default branch + alerting。 - routing 决策不记录: 出 bug 时无法回溯"为什么这个 case 走到了 branch X"。 必须把 routing decision + reason 持久化。

Team 应用: routing 模式应该是 team 12 人共享词汇 — 任何新 agent 设计前,先问"这个 routing 是 rule 还是 LLM?为什么?" · 这一个问题就能避开 80% 的过度工程。

✍️ 你的实际标注 (reMarkable): 整章你只标了 p37 一处 — 黄色高亮 embedding-based routing 那段 "This is useful for semantic routing, where the decision is based on the meaning"。rule-based / ML-model-based 两种你都没标。说明你已经把 semantic 优先 作为默认选择,不需要复习对比维度了。

② TT Ch.5 · 四种基础团队拓扑

4 种基础团队类型:

• Stream-aligned team(主力 · 70% 团队应该是这种): 围绕单个"价值流"(client vertical / 产品 / 客户线)端到端负责。 自治、跨职能、流速优先。 你的 team 大部分成员应该归这里 — 每人/每对负责一条客户线或一个产品方向。
• Enabling team(2-3 人 · 教练角色): 不交付产品,而是帮助 stream-aligned team 提升能力。 短期介入(2-8 周)→ 留下方法论 → 撤出。 你 team 里写 SKILL / 内部文档 / 培训 / pattern 库的成员应该是这种 — 他们的产出不是 agent,是 team 内的能力升级。
• Complicated-subsystem team(0-1 人 · 罕见): 处理高度专业的部分(自研 LLM tuning、底层 inference 优化)。 大部分公司不需要。 你的 team 可能没有,也不应该刻意造。
• Platform team(可能不在你 team · 是平行团队): 提供内部产品/服务,降低其他团队的认知负担。 你的 team 不是 platform team,但你的工作平台是 platform team 在维护。

4 类团队的"认知边界"是底层逻辑: 每个团队应有"可管理的认知负载"。 一个团队同时管理 8 个不同产品 / 4 种技术栈 / 6 个客户 = 必然失效。 边界划分的标准是"这个团队能不能讲清楚自己的 mission"。

应用到你的 12 人 team: - 画一张图:每个成员现在属于哪类。 大概率会发现"有人是 stream-aligned 但被拉去做 enabling 工作" — 这是认知超载的根因。 - 明确 enabling team 的退出标准(2-8 周教会一个能力后撤出),否则会变成"长期支持组" · 价值下降。 - 不要让 stream-aligned team 之间 routine collaboration · 那叫"过度协作"消耗(详见 Ch.7)。

对应到 agent 设计: 这 4 种团队类型同时是 agent topology 的 metaphor。 stream-aligned agent = 处理客户端到端流程的主 agent · enabling agent = critic / evaluator · platform agent = 共享 tool 层 · complicated-subsystem agent = 专业模型调用。 同一套词汇可以同时描述 team 和 agent 集群 — 这是 TT 这本书对你的双重价值。

③ TT Ch.7 · 三种团队交互模式

3 种模式:

• Collaboration(高带宽 · 短期 · 探索阶段): 两个 team 紧密合作,边界模糊,频繁同步。 适合不确定性高的早期。 代价大: 上下文切换 + 双向阻塞。 必须有明确的"什么时候停止 collaboration"标志(POC 完成 / 接口稳定)。
• X-as-a-Service(低带宽 · 长期 · 稳定阶段): 一个 team 把自己的输出做成"产品",另一个 team 像调 API 一样用。 大部分团队关系应该是这种 · 双方都自治、可测试、可独立部署。
• Facilitating(临时 · enabling team 主导): 一个 team 短期辅导另一个 team。 类似于"教练介入" · 几周到几个月。

判断当前关系是哪种 = 诊断协作健康度: - "我们每周都开 2 个 30 分钟 sync 跟 X 团队" → 是 Collaboration · 问:还是 POC 阶段吗?如果不是,该 graduate 到 X-as-a-Service。 - "我提需求,他们 1 个月才回复" → 不是 X-as-a-Service,是隐性 dependency · 该明确合约 + SLA。 - "我们每次发布前都要找 X 团队 review" → 是 Facilitating 应该结束但没结束 · 该 internalize 那种能力或抽到 enabling team。

Conway's Law 角度: 你的 team 跟其它 team(产品 / 工程 / 销售 / 客户成功)的交互模式直接决定了你交付出来的客户 agent 长什么样。 如果你们跟工程 team 是 Collaboration,你的 agent 会是 "需要工程长期参与才能改" 那种 · 如果是 X-as-a-Service,你的 agent 会是 "自包含、可独立部署" 那种。 你想要哪种 agent,先把跟工程的交互模式调成对应的那种。

Team 应用: 在 12 人 team 里画一张"我们 team 跟外部各 team 当前的交互模式"图。 然后画一张"理想状态"图。 两图差异 = 接下来 6 个月组织重构的 backlog。 这比任何 OKR planning 都有用。

④ ADP Ch.7 · Multi-Agent Systems

核心命题: multi-agent 不是更"高级",而是 single agent 失败后的复杂度补偿。 默认应该 single,有具体理由才升 multi。

升 multi-agent 的 4 个合法理由:

1. 任务跨明显不同的领域 · 财务对账 + 法律审查 + 客户沟通 → 各域的 prompt / context / tool / 评估标准差异太大,塞一个 prompt 会让所有指令互相稀释。
2. 不同步骤需要不同 model 能力 · 总览阶段用 Claude Opus + 检索 + 推理 · 执行阶段用 Haiku + 单一任务 → 成本和速度差 10x。
3. 需要不同的人在不同步骤介入 · HITL review 在 step 3 · 客户审批在 step 5 → multi-agent 让 HITL 节点可单独配置。
4. 可观测性需求 · 系统重要,出错时要快速定位"哪一步出错"。 multi-agent 天然给你 stage-by-stage 日志。

反 4 个升 multi-agent 的理由(常见错误): - "看起来更现代" → 没用 - "其它公司这样做" → 没用 - "用户喜欢看到 agent 在协作" → 那是 UI 表演,不需要后端真的 multi-agent - "工程上挑战大,有趣" → 这是 anti-pattern,工程师常犯

协作模式 3 种: - Sequential: A 完成 → B 接手 → C 接手。 简单、可调试。 - Parallel: A、B、C 同时跑 → D 汇总。 快但要处理子 agent 失败。 - Hierarchical (orchestrator-worker): 主 agent 协调,子 agent 做具体任务。 灵活但难调试。

核心反 pattern: agents 之间过度沟通("我让 A 跟 B 商量一下")。 沟通成本 ≈ token 成本 ≈ 不可调试性。 沟通越少越好。 设计目标:每个子 agent 收到的输入是已经裁剪好的,不需要"理解全局再决定要不要做"。

Team 应用: 建立 team 共用的"升 multi-agent 决策卡":4 个 yes 才升。 这一个卡片能阻止 team 把 80% 客户 agent 过度复杂化。

✍️ 你的实际标注 (reMarkable): - p114 Critic-Reviewer 那条 bullet 旁标 "Dynamic context agent" — 你把 Critic 角色直接 = Dynamic Context Agent(命名串到 Ch.5 那串笔记) - p117 Supervisor-as-Tool 段标 "Dynamic context → Auto Return" + "monitor Task" — 你设想的 Supervisor 变种,把"监控任务 + 自动回流"作为新的协作模式

→ 这两处合并起来,加上 Ch.4 那张 Coach 框架图(p74)+ 工作笔记 PRS-Jack / Sol-Project 体系,就是你自己设计的 multi-agent 操作系统的草稿。值得整合成一份正式 spec。

⑤ ADP Ch.5 · Tool Use(全书最厚 · 20 页)

核心区分: Tool Use 不是"给 LLM 调用函数",而是"扩展 LLM 的行动空间"。 这两个理解差异决定了你设计 tool 的方式。

Tool 设计 5 条原则:

1. 每个 tool 一个清晰动词 · get_user_profile 比 user_operations 强 · LLM 选 tool 的准确率正比于 tool 描述的清晰度。
2. 参数尽量少 + 类型严格 · 3 个参数比 7 个准确率高得多 · 用 enum 而不是 string when possible。
3. 错误信息要可操作 · "User not found, did you mean user_id starting with U_?" 比 "404" 让 LLM 自我修复成功率高 5x。
4. 幂等 + 可重试 · LLM 会重复调用 · 确保第二次调用不会重复发邮件 / 重复扣款。
5. 返回值有结构 · 不要返回纯文本 · 返回 JSON 让下游 agent 可解析。

Tool 组合 3 种范式: - 单 tool task: 任务只需 1 个 tool · 直接调用。 - Tool 链: tool A 输出 → tool B 输入 · 用 prompt 引导 + memory 维护。 - Tool 树: agent 自主探索 tool 组合 · 高灵活性 + 高 token 成本。

MCP(Model Context Protocol)的本质: MCP 是 Tool Use 的协议标准化 — 客户端(agent runtime)和服务端(tool provider)解耦。 类比:HTTP 之于 web。 战略意义: 你 team 写的 tool 一次能给所有 MCP 兼容的 agent 用 · 反过来你的 agent 能用所有 MCP server。 生态杠杆巨大。

关键反 pattern: - God tool: 一个 tool 做 10 种事 → LLM 选不对 · 拆。 - 隐式 dependency: tool A 必须先 tool B 调用 → 把它合并成 tool C · 让顺序在 server 端固定。 - No timeout: tool 调用挂起 → agent 卡死 · 必须设 timeout + 兜底。

Team 应用: team 应该有"Tool Design 评审"环节 — 任何新 tool 上线前,5 条原则各检查一遍。 这一个 review 能减少 60% 生产 tool 失败案例。 同时把现有 tool 的 schema 重审一遍,top 3 最大 tool 大概率有 god-tool 问题。

✍️ 你的实际标注 (reMarkable) — 注意 ADP 把 Context Engineering 子节放在这章前后,这是全书你最在意的概念集中区: - p31 Context Engineering 章 Venn 图(RAG / Prompt Eng / Structured Outputs / Memory / State 五圆相交)— 你在右下角画箭头标 "Dynamic prompt" / "ready to use" / 指向 "system prompt" - p32 右侧三处叠加标注:"Dynamic prompt"(×2)+ "optimize context"(下划线)+ "Dynamic Context"(下划线)— 同一页标 4 次,这是全书最高频概念 - p80 tool calling vs function calling 段黄色 highlight "acknowledges that an agent's capabilities can extend far beyond simple function execution" — 你抓的是 tool ≠ function 这个抽象边界

→ Context Engineering / Dynamic Context / Dynamic Prompt 在 Ch.5、Ch.7 Critic-Reviewer、Ch.7 Supervisor-as-Tool 三处反复出现(全书 5+ 次),跟你工作笔记 07.10 那条 "Dynamic Prompt"(HR-Lucas 段)直接对应。强烈建议:整合成一份单独的 "Dynamic Context 主笔记",跨章把所有相关段落 + 自画图 + 工作落地点串成一篇 design doc。

⑥ AM Ch.7 · EventStorming

核心思想: 业务流程的最小不可分单元是 领域事件(Domain Event) — "已经发生的某件事",过去时态、不可变。 例如:"订单已支付" "对账已批准" "合同已签署"。 把流程按事件拆开,所有其它东西(命令、聚合、UI、人物角色)都围绕事件展开。

操作流程(big-picture EventStorming · 90 分钟):

1. 15 min · 头脑风暴事件 · 业务专家 + 你 + team 各拿橙色便利贴 · 不分顺序往墙上贴所有"已发生过的事" · 不评判 · 不讨论 · 越多越好。
2. 20 min · 时间线对齐 · 把橙色便利贴按时间从左到右排 · 重复的合并 · 此时会发现"原来这两个团队说的是同一件事" — EventStorming 价值的一半就来自这一步。
3. 15 min · 找出热点 · 蓝色便利贴标"问题区域"(数据矛盾、跨部门扯皮、谁负责不清)。 这些是 agent 设计的最大机会点。
4. 20 min · 划分子域边界 · 用红色线把事件分组 · 每组一个核心动名词("订单管理"、"对账"、"合规审批")。 边界对应 DDD 的 bounded context · 对应 agent 拆分。
5. 20 min · 加上 actors 和 systems · 黄色便利贴标"谁触发"(用户角色 / 系统)· 这一步开始接入 agent 设计的"actor → agent" 映射。

关键技巧: - 过去时态强制原则: 任何便利贴说出来必须是过去时 — "用户提交订单" 不行,要 "订单已提交"。 这强制具体化,避免抽象。 - 不画箭头: 流程图箭头是过早 commit · EventStorming 阶段只有事件 + 时间顺序 · 因果关系等下一轮 design-level EventStorming 再加。 - 5 米墙优先: 物理空间产生不同思考。 Zoom + Miro 也能做但效果折半。

输出物 → agent 设计输入: - 事件列表 → agent 的 trigger 列表 - Hot spots → POC 的最高 ROI 优先级 - 子域边界 → agent 拆分(配合 AM Ch.9 DDD) - Actors → HITL 节点位置

Team 应用: 每个新客户 onboarding 第一周做一次 90 分钟 EventStorming · 让客户业务专家 + 你 team 2-3 人共同参与。 输出物比任何 BRD / SOW 都准。 一年下来 team 12 人都能独立主持,新客户上手时间从 2 周降到 3 天。

⑦ ADP Ch.6 · Planning

核心问题: LLM 是"下一个 token 预测器",天然短视。 任何超过 3 步的任务直接让 LLM 一步步做,误差会指数累积。 Planning 是"先想再做"的强制结构。

3 种主流模式:

• Plan-and-Solve(也称 Plan-and-Execute): 第一阶段 plan agent 生成完整步骤列表 · 第二阶段 execute agent 按列表执行。 优点:可审计、可缓存、step 失败可重试。 缺点:计划期间没有执行反馈,可能 plan 不切实际。 适合: 步骤清晰、环境相对稳定的任务(订单处理、文档生成、数据迁移)。

• ReAct(Reason + Act): 每步循环 "thought → action → observation"。 LLM 边做边调整。 优点:适应不确定环境。 缺点:难调试、token 成本高、容易陷入循环。 适合: 需要探索 / 试错的任务(代码 debug、深度研究、客户支持复杂 case)。

• Tree of Thoughts(ToT): 同时生成多条 plan 分支,评估后选最优。 优点:更全面。 缺点:成本 3-5x、生产环境难维护。 适合: 极少数高价值、可慢的任务(战略决策辅助、复杂规划) · 大部分场景用 Plan-and-Solve 或 ReAct 就够。

选择决策树: - 任务是否可预先列出步骤? → Yes:Plan-and-Solve · No:下一步。 - 任务是否需要边做边调整? → Yes:ReAct · No:可能根本不需要 Planning(直接 prompt chaining)。 - 错的成本极高 + 可以慢? → 上 ToT。

Plan 的 3 个失败模式: - 过度具体: plan 步骤精细到每行代码 · 改一步动 10 行 · 不如不 plan。 - 过度抽象: plan 步骤是"分析需求,设计方案,实施" · LLM 没法执行 · 必须可执行级别。 - 没有验证: plan 生成后直接 execute · 应该有 plan-validator 检查 plan 是否完整 / 步骤合理。

Team 应用: 给 team 规定 "agent 任务超过 5 步必须显式 plan"。 plan 不是 boilerplate · 是 debug 神器 — 出错时第一件事看 plan 而不是看 execution log。 同时把 plan 持久化(prompt cache + 数据库),客户提问 "为什么 agent 这样做" 时,把 plan 直接给客户看。

⑧ ADP Ch.4 · Reflection

核心思想: agent 的第一次输出往往不是最优。 Reflection 让 agent 在 finalize 前自己 critique 一次,质量平均提升 15-30%(任务复杂度越高提升越多)。

3 种 Reflection 模式:

• Self-Critique: 同一个 agent 用不同 prompt 评估自己刚刚的输出。 简单 + 便宜。 缺点:有"自我偏爱" — 同一模型容易认可自己输出。 适合: 低风险任务(文档生成、邮件初稿)。
• Critic-Actor: 两个 agent · 一个生成 · 一个评估 · 用不同 prompt 角色(甚至不同 model)。 优点:评估更客观。 缺点:token 成本 2x。 适合: 中等风险(代码生成、客户回复)。
• Multi-Critic: 多个 critic 各看一个维度(正确性 / tone / 完整性 / 合规)· 投票或 LLM judge 汇总。 成本 3-5x。 适合: 高风险任务(合同审查、医疗信息处理)。

Reflection 的关键设计: - Critique 必须可操作: "这个回答不够好" 没用 · "这个回答缺少了 X,建议加 Y 段" 才有用 · prompt critic 时强制给具体建议。 - 限制迭代次数: 默认 1 次 reflection · 极高风险 task 才 2-3 次 · 超过 3 次开销不值得。 - Reflection 跟 HITL 不是替代: reflection 处理"明显错误" · HITL 处理"判断模糊" · 两者串联用。

生产环境组合 pattern: - 客户 facing 输出 → agent generate → self-critique 1 次 → HITL review(高价值客户)or 直接发送(低风险) - 内部数据处理 → agent generate → critic-actor → 自动接受 - 合规检查 → agent generate → multi-critic(法务 + 安全 + 业务)→ 必 HITL

反 pattern: - 空 reflection: critic 总是说 "looks good" · 因为 prompt 太弱 · 必须 prompt 强制找 3 个改进点。 - Reflection 内卷: critic 总是要求重写 · 调整 prompt 让 critic 区分"必须改" vs "可以改" vs "完全 OK"。

Team 应用: 默认所有客户 facing agent 加 1 层 self-critique · 几乎免费的 15-30% 质量提升。 高价值任务才上 critic-actor。 同时把 critique 持久化 — 这是 team 内部"agent 失败模式库"的最便宜来源。

✍️ 你的实际标注 (reMarkable, 本章最重) — 4 处标注,加自画图: - p65 引言段右下角写 "another agent" 圈出来 — 抓住整章核心:Reflection 可以由独立 agent 来 critique(不只是自评) - p67 黄色高亮 "The intersection of reflection with goal setting and monitoring...a goal provides the ultimate benchmark" — 跨章连接 Ch.11 Goal Setting(但你 Ch.11 没读) - p68 顶部中文粗书法 "复杂问题评估" — 把整章 mantra 化,用粗笔反复抄 - p74 Reflection at-a-Glance 处自画三段框架图:

manual / manager → Auto coach → Agent
                                  ↓
                                 plan
                              (powered)

注解 "这中思考来自人的反馈"。这张图是你 PRS-Jack / Sol-Project 多智能体操作系统的种子(跟工作笔记 Daily / Todo 里反复出现的 Coach project 串成一脉)。

→ 整章读得最深。Producer-Critic 模式你不仅吸收,还抽象成自己的 "人工 → 自动教练 → 自治 agent" 演化框架,这是整本书你最重要的产出。

⑨ AM Ch.9 · DDD 子域识别

核心 3 类子域:

• Core domain: 公司差异化竞争力所在 · 必须自建 · 投入大部分资源。 例:Beam 的 agent orchestration 层是 core · 不外包 / 不买现成。
• Supporting domain: 重要但不差异化 · 可自建可外包 · 中等投入。 例:用户管理、权限、日志。
• Generic domain: 业界通用 · 必须用现成方案 · 不投入。 例:认证、邮件发送、PDF 生成。

应用到 agent 拆分(关键移植): - Core agent: 客户业务流程的核心 agent · 必须深度定制 · 投入大量 prompt engineering / pattern 设计。 - Supporting agent: 通用任务但有客户定制(content moderation、formatting)· 标准 pattern + 客户 specific override。 - Generic agent: 比如调 LLM API、调通用 tool — 不该被叫 agent · 应该是 utility / library。

识别子域的 3 个问题: 1. 客户愿意为这块单独付钱吗? → Yes:可能是 core · No:可能是 supporting/generic。 2. 市面上有便宜的现成产品吗? → Yes:generic · No:可能是 core/supporting。 3. 客户业务专家在这块花最多时间讨论吗? → Yes:这是 core。

反 pattern: - 所有事都叫 core: 团队过度自信导致 over-engineer 通用功能。 严格按"差异化竞争力"标准筛选。 - Core 用现成产品: 客户付钱的差异化部分用第三方组件 → 失去定制空间 + 单点依赖。 - Generic 自建: 浪费时间。

子域 → bounded context → agent 边界 的映射: - 每个 bounded context = 1 个 agent 或 1 组紧密协作的 agent - 不同 bounded context 之间用消息(event)通信 · 不直接调函数 - 同一 bounded context 内 agent 共享 memory + vocab · 跨 context 不共享

Team 应用: 跟每个新客户 onboarding 时,让 team 一起识别:这个客户的 core domain 在哪?这决定了我们投入哪里。 如果 team 自己说不清楚,你就有了一个明确的 discovery action: 去问客户。

⑩ ADP Ch.10 · Model Context Protocol (MCP)

核心架构: - MCP Client(agent runtime · 如 Claude Code / Cursor): 想用 tool。 - MCP Server(tool provider · 如 weread skill / GitHub MCP / Filesystem MCP): 提供 tool。 - Protocol(JSON-RPC over stdio/HTTP): 标准化的 list_tools / call_tool / read_resource 等。

为什么 MCP 改变游戏: 1. 写一次 tool,所有 MCP 客户端能用 — 你给 team 写的 internal tool,所有 team 成员的 Claude Code / Cursor / 其它 agent runtime 都能用 · 不需要 N x M 适配。 2. tool 跟 agent 解耦 — 换 model 不影响 tool · 换 agent runtime 不影响 tool · 软件工程的依赖反转原则在 agent 时代的具体化。 3. Resource 概念: tool 之外还有 "resource"(可读的 context)— file / database / API endpoint。 LLM 可以"加载 context" 而不只是"调用 action"。 这是 RAG 的协议化。

实操: - 自己写 MCP server 很简单 · Python SDK 100 行能跑通 · weread skill 就是个例子。 - 公开 MCP server 越来越多:Anthropic 官方 / GitHub / Filesystem / 各类 SaaS。 - agent runtime 之间 portability 提升 · "vendor lock-in" 在 tool 层被消解。

关键设计 trade-off: - stdio MCP vs HTTP MCP: stdio 简单、本地、安全;HTTP 跨网络、复杂、有认证。 大部分场景 stdio 足够。 - 同步 vs 异步 tool 调用: MCP 默认同步 · 长任务用 progress callback。 - Tool discovery: 客户端 list_tools 拿到所有 tool · 多了之后 LLM 选错率上升 · 需要 tool namespace 或 routing 层。

对你 team 的战略意义: - team 内部"标准 tool 库"应该是 MCP servers · 任何成员的 agent runtime 都能用。 - 对外:Beam 工作平台理论上可以暴露成 MCP server,让 Claude Code 等直接用 · 这是个产品机会。 - 客户 pitch:"我们的 agent 不锁死在某个 model · 因为我们用 MCP" · 直接化解客户对 vendor lock-in 的担心。

反 pattern: - 不暴露 resource,只暴露 tool: 错过了 LLM 主动 pull context 的能力 · 把 RAG 全做成 tool call 浪费。 - MCP server 没有 auth: 任何 agent 都能用 · 内部 tool 应该有 token-based auth。

Team 应用: 把当前 team 写的 internal scripts 全部考虑 MCP 化 · 6 个月后 team 共享一个 MCP server 仓库 · 每个成员的 daily Claude Code 工作效率 + 30%。

⑪ ADP Ch.8 · Memory Management

4 种 memory(从短到长):

• Working memory(within-task): 当前任务的中间状态 · 通常在 context window 内 · 任务结束就丢。 例:多轮对话内的话题。
• Short-term memory(within-session): 一个会话内多任务共享 · 几分钟到几小时 · 通常用 in-memory cache。 例:同一用户连续问几个问题,记住第一个问题的答案。
• Long-term memory(across-sessions): 跨会话持久化 · vector DB / structured DB · 几天到几年。 例:用户的偏好 / 历史交互记录。
• Episodic memory: 特定事件的"详细记忆" · 用于 reflection / 复盘 / 改进。 例:"上次客户对账时出过的错"。

设计 3 条核心原则:

1. 明确每类 memory 的写入策略: - Working: 自动 · 通过 prompt context 累积 - Short-term: agent 决定 · 跟 cache invalidation 一样难 - Long-term: 显式 · 必须有 "记录这个" 的指令 - Episodic: 失败 / 异常自动记录 · 成功不记录(避免 noise)

2. 读取要分层 retrieval: 不要一次给 LLM 所有 memory · 按相关度 + 时间 + 类型分层 · top-k 注入 prompt。

3. Memory 是 first-class citizen: 不是 "stuff into prompt as text" · 应该有专门的 memory layer with API · 跟 tool / model 同级。

长流程 agent 的 memory 失败模式: - Context window overflow: working memory 撑爆 context · agent "忘了任务开头" · 必须分段 summarize 压缩。 - Memory pollution: episodic memory 记录了大量无关失败 · 之后 retrieval 全是 noise · 定期清理 + 加 relevance scoring。 - State desync: agent 以为状态是 X,实际 backend 已经变 · 必须有 "memory + reality reconciliation" 机制(每次开始 task 前 verify state)。

实操: - 简单场景:用 LangGraph 或 Beam Platform 的 state 机制就够。 - 中等场景:加一个 Redis + vector DB 双层 · Redis 存 session state · vector DB 存 long-term。 - 复杂场景:event sourcing(详见 DDIA Ch.12) · 所有 memory change 都是 event · agent state 是 event reduce 的结果 · 完美可审计。

反 pattern: - Memory 跟 user identity 没绑定: 系统 reboot 后 user A 的 memory 跑到 user B · 必须 user_id 作为 partition key。 - 没有 memory 过期机制: 5 年前的 user preference 还在影响今天的回答 · 必须有 TTL 或 decay function。

Team 应用: 让 team 在所有客户 agent 设计中,memory 作为单独的 design section · 4 种 memory 各回答"我们用不用?用什么存?保多久?谁能读?"。 4 个问题 16 个 yes/no answer · 把模糊的"agent 要不要记忆" 变成具体的设计决策。

✍️ 你的实际标注 (reMarkable): - p132 边批 "save and use" — 标在 short-term contextual vs long-term persistent memory 的分界处(你抓的是动作动词) - p148 LangGraph 长期 memory 实现章节顶部书法 "Beam Bid us / Memory → open" — 直接落地决策:这套 LangGraph Memory pattern 用到 Beam BID 客户工作

→ 你只读到 LangGraph Memory(p148),后面 ChatMessageHistory / ConversationBufferMemory / Procedural Memory(Reflection 改 prompt 自学的那段)没标。Procedural Memory 那段值得补:跟 Ch.4 Reflection + Ch.9 Learning 的 SICA "NOT Tune BUT Test" 思想完全对接。

⑫ AX · 核心 framework(Tabah & Landon)

AX 的核心命题: UX 是为 GUI 设计的 · 用户主动点击 · 界面响应。 AX 是为 agent 设计的 · agent 主动做事 · 用户审批 / 介入 / 委托。 设计原则完全不同。

AX vs UX 核心差异:

• Agency(自主权): UX 默认用户决策 · AX 需要明确 agent 决策边界。 哪些 agent 自己做?哪些需要用户审批?哪些需要 escalate? — 这是 AX 设计的核心。
• Trust(信任): UX 信任建立靠"可预测的交互"。 AX 需要新机制 — transparency(让用户看到 agent 的推理)+ accountability(出错时谁负责)+ reversibility(能撤销)。
• Velocity(速度感): UX 优化 perceived performance · AX 必须设计"等待体验" — agent 后台跑 5 分钟时用户在干嘛?
• Affinity(情感连接): UX 是工具感 · AX 像"工作伙伴"感 · 但不能过头变假人格。

4 个 AX 设计 lever:

1. Disclosure(披露): agent 主动告诉用户它在做什么 / 想做什么 / 为什么。 默认开 · 越简单越好。 反 pattern: 隐瞒 agent 行为让用户觉得"魔法" — 短期惊艳长期失信。
2. Confirmation gates(确认门): 关键决策前停下来等用户。 不是"是不是 OK"这种废问 · 而是"我要做 X,影响 Y,允许吗?"的有信息确认。
3. Reversibility(可撤销): agent 做的事必须可撤销 · 不可撤销动作必须前置 confirmation gate。 这是 agent 信任的最强抵押。
4. Escalation paths(升级路径): agent 卡住时不要硬干 · 明确 escalate 给谁(用户 / 同事 / 客服) · 如何 escalate · 上下文怎么交接。

Trust 建立的 3 阶段(对应客户使用 agent 的旅程): - Trial(试用 · 怀疑期): 大量 disclosure + 高 confirmation gate · 用户像监工 · 验证可靠性。 - Routine(常规 · 委托期): disclosure 简化 · confirmation 减少 · 用户开始放权。 - Partnership(伙伴 · 信赖期): agent 主动 propose · 用户 review · 类似跟 senior 同事协作。

反 pattern(你 team 大概率正在做的): - All-or-nothing automation: 要么全自动要么全人工 · 没有中间档 · 用户不敢用 · 必须有 "agent 做 80% + 人 review 20%" 的 mode。 - AI veneer: UI 上写 "AI Powered" · 但内部是 if-else · 短期没事 · 长期信任崩塌。 - No undo: agent 自动发了邮件 / 自动批了订单 · 用户没法撤 · 一次出错信任永远失去。

Team 应用: 给 team 制定 "AX checklist" · 任何 agent 上线前过 8 条:disclosure 有没有?confirmation gate 在关键决策有没有?reversibility 有没有?escalation path 有没有?trial-routine-partnership 哪一阶段?... 这一个 checklist 比任何 user research 都防 60% 的 UX 灾难。

✍️ 你的实际标注 (reMarkable) — 整本 AX 你只标了 p2(THE AX MANIFESTO) 一页,但标得极集中,5 个绿色 highlight 把 manifesto 的 5 个论点开头一次性划出:

1. Things are changing.
2. From context-less to context-rich. — Memory + behavioral learning 是 AX 基础
3. From static UI to adaptive UI. — Dynamic interfaces 才能体现 agent 当下感知
4. From explicit commands to proactive collaboration. — 不等指令、主动出手
5. traditional User Experience (UX) to Agentic Experience (AX) — 核心命题

→ 你抓的是 AX 的 5 个"从 X 到 Y"对立。两个直接落地: - "static UI → adaptive UI" + "explicit commands → proactive collaboration" = 你副 idea Echo Mind(p156 标注:"customize page content / popup")的核心 - "context-less → context-rich" = 你 ADP 全书反复标的 "Dynamic Context" 概念的设计端表达

整本 AX 剩 ~10 章你都没读 — 优先补 trust 那 4 lever(disclosure / confirmation gate / reversibility / escalation paths)那一章,是你 team checklist 的直接来源。

⑬ DDIA Ch.8 · Transactions

核心问题: 当多个操作必须"一起成功或一起失败"时,需要 transaction。 但 transaction 不是免费的 — 有性能 / 复杂度 / 分布式系统的代价。

ACID 4 个属性 + agent 场景: - Atomicity(原子性): 全部成功或全部失败,没有中间态。 对 agent: "扣库存 + 发邮件 + 更新状态" 三件事必须 atomic · 否则会有"库存扣了但邮件没发"的鬼魂状态。 - Consistency(一致性): 数据库约束永远满足。 对 agent: "user balance ≥ 0" 这种约束不能让 agent 写坏。 - Isolation(隔离性): 并发事务互不影响。 对 agent: 两个 agent 同时处理同一客户 · 必须有隔离机制。 - Durability(持久性): 已提交的数据不丢失。 对 agent: agent 说"完成了" · backend 必须真的存了。

4 种隔离级别(从弱到强 + 何时用):

• Read Committed: 只能读到 committed data · 但读 2 次同一数据可能不一样。 性能高。 适合: 大部分 OLTP · agent 一次性读取的报告。
• Repeatable Read / Snapshot Isolation: 一个事务内多次读同一数据看到一致 snapshot。 适合: agent 需要 "consistent view" 做决策(比如对账)。
• Serializable: 所有事务结果跟"串行执行"等价。 最强 · 性能最低。 适合: 金融转账 / 库存扣减 / 极高风险的 agent action。
• Read Uncommitted: 不要用。 几乎所有数据库都有这个但生产场景几乎用不到。

关键陷阱: - Lost update: 两个 agent 同时更新同一个 field · 后写的覆盖前写的。 解法:select for update / compare-and-set / serializable。 - Write skew: 两个 agent 各自的 invariant 看起来 OK · 但 combined 后违反系统约束。 例:两个医生同时把自己设为 off-duty · 结果科室没人。 必须 serializable 或显式锁。 - Phantom: 在事务中插入新行 · 影响其它事务的范围查询结果。 高隔离级别能防。

分布式 transaction(2PC、Saga · 高阶): - 跨多个 service 的事务 · ACID 不再天然成立。 - 2PC(two-phase commit): 强一致但慢且脆弱 · 大多场景避免。 - Saga: 长事务分解为多个 local transaction + 每步有 compensation · 失败时 reverse 之前的步骤。 大部分 agent multi-step 场景该用这个。

对 agent 的具体决策: - agent 在内存中操作 → 用 Working memory · 没有 ACID 需求。 - agent 改 1 个 table → 用 DB transaction · Read Committed 默认够。 - agent 改 2+ tables 或 cross-service → 用 Saga · 或聚合到一个 service 用 transaction。 - agent 跟客户系统交互 → 通常不能拿 ACID · 用 idempotent + retry + reconciliation 兜底。

Team 应用: team 12 人里大概率有几个不深刻理解 isolation level · 一次内部 30 分钟分享 · 把"我们在哪里需要 serializable 哪里 OK 用 read committed" 列出来。 跟客户对话时,这层是体现 team 专业度的关键。

⑭ DDIA Ch.12 · Stream Processing + Event Sourcing

核心思想转换: 传统系统存 "current state" · stream 系统存 "events that led to state"。 current state 是 events 的 derived data · 可以重新 compute · 可以从任何时间点 rewind。

Event Sourcing 的本质: - 一切 state change 都是 event(append-only log) - current state = fold(events) - 系统的 source of truth 是 event log,不是 mutable database

3 个 agent 时代的关键应用:

• 完美 audit trail: agent 做了什么 / 什么时间 / 基于什么 input / 输出什么 — 全部是 events。 客户合规要求(SOX / GDPR / HIPAA / MDR)直接满足。
• Time travel debug: agent 出 bug 时,replay 当时的 events · 重现问题 · 这是普通 mutable DB 做不到的。
• Memory layer 的实现基础: agent memory(尤其 episodic / long-term)如果用 event sourcing,就有了完美 history + auditability + rollback 能力 · 是 ADP Ch.8 Memory 的工程实现答案。

3 个核心 pattern:

• CQRS(Command-Query Responsibility Segregation): write 走 event log · read 走 derived view · 两边可独立 scale。 read view 可以多份(给 LLM 的 view / 给 UI 的 view / 给 analytics 的 view)。
• CDC(Change Data Capture): 现有 mutable DB 通过 CDC 把 changes 输出为 event stream · 不用重写系统也能享受 event sourcing 的一半好处。 (Debezium / Postgres logical replication / Kafka Connect)
• Event-driven architecture: services 之间用 event 通信(Kafka / Pulsar / Redpanda)· 替代直接 API call · 解耦 + 可重放 + 可观察。

反 pattern: - All events, no snapshots: 100M events 算一次 current state 太慢 · 必须定期 snapshot(每 1000 events 或每天一次)。 - Events 是 implementation detail: 把 internal data structure dump 成 event · schema 一变全坏 · events 应该是 domain language("订单已支付")而不是"orders 表第 5 行更新"。 - No event schema versioning: 5 年后 schema 变了,旧 events 读不了。 events 必须有 version + backward compatibility。

Stream processing 系统的基本词汇: - Producer / Consumer: 写入 / 读取 stream 的端 - Partition: stream 按 key 分片 · 并发处理 + 顺序保证(同 key 同 partition 顺序保证) - Offset: consumer 读到 stream 哪里了 · checkpoint - Windowing: tumbling / sliding / session window · 在无限流上做有限聚合 - Exactly-once: 处理"刚好一次"的语义 · 工程上很难真正做到 · 大多生产是 at-least-once + idempotent。

对 agent 系统的设计影响: - agent 内部 state change 全部 emit event → 天然 audit + replay - agent 之间用 event 通信(不直接 API call)→ 解耦 + 可重放 - agent 失败 recovery = 从 last checkpoint replay events → 比 retry 鲁棒

Team 应用: 当客户要 "audit 每个 agent 决策" 时,直接答 "我们的系统是 event sourced,完整 audit trail 是 first-class"。 这是 team 在合规/金融/医疗 vertical 谈判的 trump card。 让 team 12 人都至少会画 CQRS 简图 + 解释为什么 event sourcing 比 mutable DB 适合 agent。

⑮ MDR konkret · SaMD 分类规则(Rule 11)

MDR 概念基础(快速): - MDR(Medical Device Regulation 2017/745)2021-05-26 强制执行 · 取代旧的 MDD。 - 适用任何在欧盟 sold 或 used 的医疗器械(物理设备 + 软件)。 - 比旧 MDD 严格得多 · 大量原先 Class I 升到 Class IIa+。

4 个 Class · 风险递增: - Class I: 低风险(听诊器、绷带)· 自我声明即可。 - Class IIa: 中低风险(注射器、大部分软件)· 需要 Notified Body 审。 - Class IIb: 中高风险(影像设备某些)· 严格审。 - Class III: 高风险(植入物、生命支持)· 最严格 · 临床试验。

Rule 11(软件分类) — 你必须懂的核心:

Software intended to provide information used to take decisions with diagnosis or therapeutic purposes is classified as Class IIa, except if such decisions have an impact that may cause: death or irreversible deterioration of state of health → Class III; or serious deterioration of state of health or surgical intervention → Class IIb. All other software is classified as Class I.

翻译成大白话: - 软件提供"诊断或治疗决策信息" → 至少 Class IIa(需要 Notified Body) - 决策错误可能致死 / 不可逆健康损害 → Class III(最高) - 决策错误可能严重健康损害或需要手术 → Class IIb - 仅做监测 / 不参与诊断治疗决策 → Class I

对 REMATIQ / agent 类产品的具体含义: - 几乎任何"AI assists doctor decision" 都 ≥ Class IIa · 不能逃。 - "AI categorizes patient data for review" 也可能踩 Class IIa 线 · 看输出是否影响诊疗。 - 纯 administrative tool(预约 / 计费)→ Class I。 - LLM-based "AI doctor" 推荐用药 → 大概率 Class IIb 或 III。

Class IIa+ 意味着什么(implementation cost 视角): - Technical documentation(Annex II)· 厚厚一份(可能 500+ 页) - Clinical evaluation(Annex XIV)· 必须有临床证据 · 文献综述或临床试验 - Quality Management System(QMS): ISO 13485 cert · 全公司 process 受管 - Post-market surveillance(PMS): 上线后持续监控 + 报告 - CE marking + Notified Body: 一年起步的审核流程 - CER(Clinical Evaluation Report)+ SSCP(对 IIb/III) - 总时间:18-24 个月 才能拿到 first CE mark

对 REMATIQ 决策的 3 个具体问题(必须问出答案才能 commit): 1. 产品 intended use 是什么?Class 是什么? 2. 已经有 CE mark 了吗?还是 pre-market? 3. team 里有 RA(Regulatory Affairs)专家吗?ISO 13485 cert 有吗?

反 pattern(初创医疗 AI 公司常见): - 认为 "we're just an LLM wrapper, not a medical device": 几乎一定是 wrong · Rule 11 涵盖广。 - 拖到 launch 才考虑 MDR: 18 月 lead time 没准备 · launch delay 12+ 月。 - AI/ML 的"持续学习" model: MDR 默认 model 是 frozen · 持续更新需要专门的 Change Control(MDCG 2019-11 + AI Act 接口) · 复杂度极高。

给你看 REMATIQ 时的具体 checklist: - Founder 能用 30 秒说清楚 Rule 11 应用?如不能,red flag。 - 有 RA 顾问 / ISO 13485 路线图? - 客户(医院 / 制药)能签 "non-medical-device disclaimer" 还是必须 CE mark? - AI 部分是 frozen 还是 learning?

这章读完你的位置: 跟 REMATIQ founder 聊 30 分钟时 · 你不再是"听不懂"的 BD 角色 · 而是能问出关键风险问题的合伙人 candidate。

Tier 2 · 12 章重要 · 中度分析

每章 100-150 字,核心要点 + 何时回头精读

Tier 3 · 8 章扫读 · 一句话定位

Tier 4 · 25+ 章跳过 / 当字典

12 个月综合学习路径

如果只读 5 章 · 终极清单

采购清单 · 微读中文版优先 / Amazon 英文版 fallback