Team 分享系列 · 提纲 + 重点

12 人 Solutions team 内部分享 · 6 个主题 · 每主题 30-60 min · 配套书目引用 + 重点 + 演示建议 Copy 到另一个 repo 后深度丰富。 这里只列结构 + 重点 + 书目锚点。

分享系列总览

建议节奏:每周 1 个主题 · 周五 60 min · 一个领读 + 一个互动 case · 9 周做完。

通用结构(每个主题都用): 1. 5 min · 一句话 + 一张图说清楚要解决什么问题 2. 15-20 min · 核心概念 + 决策框架(书里来 + team 内部经验) 3. 15-20 min · 真实 case 拆解(用 team 进行中或刚交付的案例) 4. 10-15 min · 反 pattern + 大家提问 5. 5 min · 1 条 SKILL 卡片 + 这周作业(每人在自己 case 上应用一次)

1 · 模型选择 + 优化(60 min · P0)

1.1 学习目标

读完这节,team 每个人能: - 在 5 分钟内判断一个新 agent task 该用哪个 model(Opus / Sonnet / Haiku / GPT-4.1 / Gemini) - 算清楚一个 agent 月度成本,知道 model 切换能省多少 - 给客户讲 "为什么我们这步用 X 这步用 Y" 时有标准说法

1.2 大纲

A. Model 维度(15 min)

• 5 个维度同时优化:质量 / 延迟 / 上下文 / 成本 / 可用性
• 单维优化 = 错的思维 · 必须 multi-objective trade-off
• 当前主流 model 在 5 维度上的相对位置(画一张 radar chart)
• ⚠️ Anthropic Economic Index 数据:API 上 coding 任务 +14% vs Web -18% → 行业在向 API + 高质量 model 倾斜

B. 任务分类(15 min)

• 4 类 agent task,每类对 model 的需求不同:
• Reasoning-heavy(规划、决策、复杂分析): Opus / GPT-4.1 · 不要省
• Routing / Classification: Haiku / Gemini Flash · 大幅省
• Generation(代码、文档、邮件): Sonnet 默认 · 看长度切 Opus
• Extraction / Formatting: Haiku · 几乎不出错的便宜选项
• Cascade pattern: Haiku 先跑 · 不确定时升级到 Sonnet · 仍不确定升 Opus · 平均成本下降 60-80%

C. 优化策略(20 min)

• Prompt caching(Anthropic / OpenAI 都支持): 长 system prompt + 历史 context 缓存 · 5-10x 成本下降 · agent 在多轮场景下默认开
• Batch API: 非实时任务走 batch · 50% 成本下降 · 对账 / 报告类适用
• Speculative decoding / 小 model preview: 实验性 · 让小 model 起草大 model 校验
• Multi-provider 备用: 1 个 provider down 时切换 · 不只是 cost,更是 reliability

D. 反 pattern(5 min)

• 全 Opus("用最好的肯定不出错"): 月底账单震惊老板
• 全 Haiku("反正能跑"): 关键 task 出错率 5x · 客户信任崩塌
• 不算单 task 成本: agent 跑了 3 个月才发现 1 单任务跑 100 次 Opus 调用,unit economics 算不过来

1.3 书目锚点

• ADP Ch.9 Learning and Adaptation: fine-tune 何时值得 vs prompt engineering 何时够
• Anthropic Economic Index 2026-01 + 2026-03: 行业渗透率数据 · API vs Web 趋势
• ADP Appendix C Agentic Frameworks Overview: 各 framework 对多 provider 的支持差异

1.4 一张图建议

2D 散点图: X 轴 = 任务复杂度 · Y 轴 = 月度调用量 · 4 象限对应 4 类 model 推荐。

1.5 演示建议

• 拿 team 当前进行中的某 agent · 现场用 cost calculator(Anthropic / OpenAI 官方)算 Opus vs Sonnet vs Haiku · 30 天 1000 次调用的差距(通常 $200 vs $20 vs $2)
• Demo prompt caching 开关前后 · 同一 agent 实际 token usage 对比

1.6 SKILL 卡片输出

"Beam 内部 model 选择 decision tree" — 给 team 共享 · 4 分支 + 切换条件 + cost 估算公式

1.7 Lightning(5 min)版本

只讲 Cascade pattern + Prompt caching 这 2 条 · 占 60 min 主题 80% 价值。

2 · Routing 逻辑设计 + 优化(60 min · P0)

2.1 学习目标

• 任何成员看到一个 routing 决策能立刻分类 rule / LLM / hybrid · 给出选型 reason
• 设计 routing 时 8 个反 pattern 不踩

2.2 大纲

A. Routing 三大范式(15 min)

• Rule-based: keyword / regex / structured field · 零延迟 / 零 token / 可单测 · 适合输入 schema 清晰
• LLM-based: 自然语言意图分类 · 适合输入模糊
• Hybrid(生产默认): 90% rule + 10% LLM 兜底 · 几乎免费 + 边缘场景有保底
• 决策 1-liner: 如果 branch 可列举(<10 个)且 input 有清晰特征 → 优先 rule

B. 多层 routing 设计(15 min)

• 顶层 router: intent classification(用户在做什么 task)
• 二层 router: capability matching(哪个 agent / tool 处理)
• 三层 router: parameter extraction(具体参数怎么填)
• 硬规则: 不超过 2 层。 4 层嵌套 router 是常见反 pattern(一个请求 4 次 LLM call · 任何一层错全链路崩)

C. Routing 可观测性(15 min)

• 每次 routing 决策必须记录:input / decision / reason / confidence / branch_id
• 没记录 = 出 bug 时无法回溯 = 你将永远在猜
• 关键 metric: routing accuracy(人工 sample 抽查)· latency · fallback 触发率
• Anomaly detection: fallback 突增 = 输入分布漂移 = 该重新训练 router

D. 8 个反 pattern(10 min · 用 team 内部真实案例)

• 没有 default branch: LLM 路由 99% 工作,1% 漏掉沉默失败
• Routing 决策不持久化: 不能 audit
• 过度分层: > 2 层嵌套
• Routing prompt 把全部 input 塞进去: token 浪费,大部分内容跟决策无关
• 不同 model 跑不同 branch 但 routing 自己用 Opus: routing 必须是最便宜 model
• Hard-coded confidence threshold: 看似科学其实拍脑袋 · 应该 calibration
• Routing 改了不灰度: 直接全量切 → 出问题没法回滚
• 没有 routing playback tool: 没法离线 replay 历史 decision

E. 5 min · 平台层 vs agent 层

• 我们的平台已经在节点 / edge 层提供条件路由能力 · 多数 routing 不需要 LLM
• "LLM 自主选 tool" vs "platform 显式分发" 的张力 · default 选后者 · LLM-routing 只用在 input 真正模糊时

2.3 书目锚点

• ADP Ch.2 Routing(最厚): LLM-based / Rule-based / Hybrid 详细对比
• AM Ch.7 EventStorming: 用 event-storm 找出 "天然的 routing 边界"
• DDIA Ch.6 Replication + Ch.7 Partitioning: routing 在数据层的对应概念(consistent hashing 等)

2.4 一张图建议

Routing 决策树流程图: 输入 → "branch 可列举吗?" → 是 → "规则可表达吗?" → 是 → Rule · 否 → Hybrid · 否 → LLM-only。 + observability 标注。

2.5 演示

• 用 team 当前 agent 中一个 routing 节点 · 跑 100 个真实 input · 统计 rule-only / LLM-only / hybrid 三种实现的 accuracy + cost + latency 对比
• 演示 routing replay tool(如果 team 还没有,这就是这次分享的产出)

2.6 SKILL 卡片

"Routing 选型 5 问 + 8 反 pattern 速查"

2.7 Lightning 版本

只讲 "Hybrid 90/10" 这一个 pattern + 必记 1 个反 pattern("没有 default branch") · 5 min · 80% 价值。

3 · Prompt 输入输出规范(60 min · P0 · 实操频率最高)

3.1 学习目标

• team 写 prompt 有统一 format · code review 时能客观判断 "这个 prompt 写得好吗"
• 知道何时该上 structured output / 何时该用自然语言

3.2 大纲

A. Prompt 输入侧(20 min)

• System / Developer / User 三段分工:
• System: 角色 + 目标 + 边界 + 不可逾越的硬约束(merged 全程不变)
• Developer / Tool definition: schemas + 业务规则
• User: 当下任务 input · 频繁变化
• 5 段标准结构(team 写 prompt 默认模板): 1. ROLE: 你是 ___ 2. CONTEXT: 当前业务背景 / 上游信息 3. TASK: 具体要做什么(动词清晰) 4. CONSTRAINTS: 必须满足 / 必须避免 5. OUTPUT FORMAT: 严格规定
• Pinker 风格(《风格感觉》): 主动语态 · 具体动词 · 删除模糊形容词 · 强制清晰
• 少即是多原则: 每多 100 token 就要回头问"这真的对结果有影响吗?"

B. Prompt 输出侧(20 min)

• 3 种 output 模式 + 何时用:
• 自然语言:user-facing output · 最终给人看
• JSON / structured:agent-to-agent 通信 · 必须 strict
• Hybrid(think section + structured):reasoning 透明 + parsing 容易
• Structured output 4 个 best practices:
• 用 JSON Schema 显式定义(不是 prompt 里描述)
• 提供 1-2 个 few-shot example(质量提升 30%)
• 强 model native structured output API(Anthropic tool use / OpenAI JSON mode)
• 输出后 validate · 失败 retry(不要相信 LLM 永远 output valid)
• Reasoning 透明化: think 段不是装饰,是 debug 救命稻草 · 强制 LLM 先 think 再答的 accuracy 提升 10-25%

C. Prompt 优化技术(15 min · ADP Appendix A 速通)

• Chain-of-Thought (CoT): "Let's think step by step" · 简单任务 +5%,复杂 +30%
• Few-shot: 2-5 个例子 · 例子质量决定一切
• Self-Consistency: 跑 5 次取多数票 · 关键决策用 · 成本 5x
• Chain-of-Verification: 输出后让 LLM 自检 · 减少 hallucination
• Constitutional AI / 自我校准: 用规则 prompt 让 LLM 检查自己是否违反原则
• ReAct(Reason + Act 循环): tool use 时的标准
• 决策: 默认 CoT + few-shot · 关键场景上 Self-Consistency · 高风险上 Chain-of-Verification + Constitutional

D. Prompt evolution(5 min)

• Prompt 不是写一次结束 · 是产品 artifact · 要 versioned · 要 A/B test
• 建议工具栈: Langfuse / Promptfoo / 自建 eval harness · 至少有一个

3.3 书目锚点

• ADP Appendix A · Advanced Prompting(28 页 · 最厚附录): CoT / Few-shot / Self-Consistency / ToT / ReAct / Reflexion / Constitutional / Chain-of-Verification 全套
• 风格感觉(Pinker): Classical Style 原则,跟 prompt 写作的对应
• 即兴沟通: "听众思维" 在 prompt 里 = "LLM 视角思维" · 想象 LLM 收到这个 prompt 它知道做什么吗
• better-doc: Smart Brevity 的 prompt 版

3.4 一张图

5 段 prompt 标准结构 · 5 颜色编码 · 跟 system / dev / user 角色映射

3.5 演示

• 拿 team 内部一个糟糕 prompt(可以匿名)· 现场重构 · A/B 跑 20 个 input · 显示 accuracy / token / latency 三维度提升
• Demo structured output 用 JSON Schema vs prompt 描述的差异(可能 30 → 95% valid rate)

3.6 SKILL 卡片

"team prompt 5 段模板" + "structured output 4 best practices" · 任何新 prompt 都该过这两个 checklist

3.7 Lightning 版本

只讲 5 段模板 + Chain-of-Thought 一句 · 5 min · 收益巨大。

4 · Agent 交互模式 · Chat / Task / Background(45 min · P1)

4.1 学习目标

• 给一个新 agent 需求,能判断该用 chat 还是 task 还是 background 模式 · 不再凭直觉
• 客户问 "为什么不做成聊天界面" 时有专业回答

4.2 大纲

A. 3 种基础交互模式(15 min)

• Chat-mode: 多轮对话 · 用户主导节奏 · agent 反应式 · 适合探索性 / 不确定意图 / 教练型 task
• 例:研究助手 / 客户支持 / 头脑风暴
• 特征:turn-based / context 累积 / 用户随时改方向
• Task-mode(one-shot or batch): 用户给完整 input · agent 一次性产出 · 不交互
• 例:报告生成 / 文档转换 / 对账批处理
• 特征:input 完整 / output 一次性 / 失败重跑
• Background-mode(autonomous): agent 自主跑 · 用户偶尔介入 · 长时间运行
• 例:监控 / 抓取 / 自动响应客户邮件 / scheduled 任务
• 特征:无明确开始结束 / 自主决策 / HITL escalation 必备

B. 3 模式选型决策树(10 min)

• 问 1: 用户在执行时在场吗? → 在 → Chat 或 Task · 不在 → Background
• 问 2: 用户在 input 时知道完整需求吗? → 是 → Task · 否 → Chat
• 问 3: agent 跑超过 30 秒吗? → 是 → 必须有 progress display(Chat 自然,Task 需加 progress UI)
• 问 4: agent 可能需要 mid-task escalate? → 是 → Background + escalation paths(see AX)
• 问 5: 客户对话频率高(>10 次/天/用户)? → 大概率适合 Chat · 否则 Task

C. AX 视角(10 min)

• AX 的 4 个 lever(disclosure / confirmation / reversibility / escalation)在 3 种模式里表现不同
• Chat 模式 disclosure 是自然的(turn-based 透露)· Background 模式 disclosure 难做 → 必须 design proactive notification
• Task 模式 confirmation 在 input 后 / output 前 · Background 模式 confirmation 在 escalation 触发时
• Reversibility 在 Background 最关键 · agent 跑了 3 小时改了 100 条数据 · 客户撤不了 = trust 崩
• Trial → Routine → Partnership 三阶段在 3 模式下的演化路径不同

D. 5 min · Hybrid 模式(高级)

• Chat-as-intake → Task-mode 执行 → Background-mode 监控 持续运行后果
• 例:客户开始聊几句澄清需求(Chat)· agent 跑批处理(Task)· 之后周期性监控(Background)
• 客户体验上"一个 agent",架构上 3 mode 协同

E. 反 pattern(5 min)

• Default 全部用 Chat: 大部分企业任务不需要对话 · Chat-mode UX 设计成本高 · 性能差 · 经常是技术债
• Background 没 escalation: agent 撑死自己也不 escalate · 静默失败
• Task 模式跑超过 60 秒没 progress: 用户以为挂了
• AI veneer: UI 装成 chat 但后端纯 if-else · 短期没事 · 长期信任崩

4.3 书目锚点

• ADP Ch.7 Multi-Agent: 多 agent 协作时的交互模式
• AX 核心 framework: disclosure / confirmation / reversibility / escalation 在 3 mode 下应用
• AM Ch.4 Listening Tours: 跟 chat-mode 的"听众思维"互通

4.4 一张图

3 mode × 4 AX lever 的 12 格 matrix · 每格 1 句 design tip

4.5 演示

• 用 team 当前 3 个 agent · 各属于哪种 mode · 是否最优 · 改 mode 能不能简化产品
• AX checklist 在某个 Background-mode agent 上跑一遍 · 找 disclosure / escalation gap

4.6 SKILL 卡片

"3 mode 选型 5 问 + 反 pattern 速查"

4.7 Lightning 版本

3 mode 一句话区分 + 决策树 5 问 · 5 min。

5 · Tool Use · 平台 integration vs 自定义(60 min · P1)

5.1 学习目标

• 给一个新需求,30 秒判断 "用平台内建 integration 还是自己写 tool"
• 设计自定义 tool 时 5 条原则不破

5.2 大纲

A. Tool 设计 5 条原则(15 min)

1. 每个 tool 一个清晰动词(get_customer_balance ≫ customer_ops)
2. 参数尽量少 + 类型严格(3 个比 7 个准确率高得多 · enum > string)
3. 错误信息可操作("customer_id not found, expected format CUST-XXXXX" ≫ "404")
4. 幂等 + 可重试(LLM 会重复调 · 第二次不能重复扣款发邮件)
5. 返回值结构化(JSON 严格 schema · 不要纯文本 · timeout 必设)

B. 平台内建 integration 的隐含价值(15 min)

我们的工作平台已经把高频客户系统(邮件 / 日历 / 表格 / 客服 / 行业 PMS)做成 native integration。 团队 90% 客户场景被这些覆盖。优先用 native 的 5 个理由: 1. Auth 平台帮你处理(OAuth2 token refresh / 第三方 API rotation) 2. Schema 稳定(integration 升级时不影响 agent) 3. 常见错误平台帮你 retry(rate limit · transient failure) 4. 观测自动接通(每次 integration call 自动进 trace · 不用自己埋点) 5. 降低 maintenance 成本(客户 API 改了不是你追)

反 pattern:看到客户有 API 就先想"我写个 Custom tool"· 多数时候 native integration 已经 cover。

C. 何时合法自己写 Custom tool(10 min)

• 客户内部系统(ERP / 自研 / SaaS niche)
• 行业 vertical 特殊操作(native 不覆盖)
• POC 阶段快速验证 · 后续考虑 promote 成 native(请求平台 team)

⚠️ Custom tool 是 maintenance 长期债 · 不要 default

D. Tool 组合 3 种范式(10 min)

• 单 tool task:直接
• Tool 链:A 输出 → B 输入(节点级 edge data 传递)
• Tool 树:agent 自主探索组合(高 token · 高 flexibility · 高 debug 难度 · 慎用)

E. 反 pattern + 客户系统视角(10 min)

• God tool: 1 个 tool 做 10 件事 · LLM 选不对 · 拆
• 隐式 dependency: tool A 必须先于 tool B · 合并成 tool C · 让顺序在 server 端固定
• No timeout: tool 调用挂起 · agent 卡死
• Custom tool 在客户内网没 health check: 客户 VPN / 防火墙变更后 tool 静默失败 · 必须 active monitoring + escalation
• 客户 API schema 改了我们才知道: 没有 contract test · 应该每天 ping 一次客户 API + 校验 schema

5.3 书目锚点

• ADP Ch.5 Tool Use(20 页 · 全书最厚): 设计原则 + 组合 pattern · 注意原书讨论协议层我们不必跟
• DDIA Ch.5 Encoding and Evolution: tool schema 演进的底层

5.4 一张图

决策树:新需求 → 平台 native 有吗?有 → 用 · 没 → 客户系统是 standard SaaS 吗?是 → 请求平台 team · 否 → Custom tool(5 原则 review)

5.5 演示

• 拿 team 当前一个 Custom tool · 用 5 原则审一遍 · 现场重构 schema · 跑 20 个 case 看 LLM 选 tool accuracy 变化
• 列 5 个客户 vertical 高频 API · 哪些已经 native 覆盖 · 哪些是 Custom tool 长期债

5.6 SKILL 卡片

• "Tool 选型决策树"(native → 请求 promote → Custom 三档)
• "Custom tool 5 原则 review checklist"
• "客户系统 contract test SOP"

5.7 Lightning 版本

"优先 native · Custom 是长期债 · 5 原则 review" · 5 min。

6 · Memory + State 管理(60 min · P2)

6.1 学习目标

• 设计 agent 时,memory 不是"事后想"的事,是 design phase 的 first-class section
• 给一个 agent 能立刻回答 4 个 memory 问题:Working / Short-term / Long-term / Episodic 各要不要 · 存哪 · 保多久 · 谁能读
• 理解 Memory 的两条价值线:跨 agent 共享 + agent 自我强化(self-improvement loop)

6.2 大纲

A. 4 种 memory(15 min)

• Working memory(within-task): context window 内的中间 state · 任务结束丢
• Short-term(within-session): 几分钟到几小时 · in-memory cache · 例:连续对话的话题
• Long-term(across-sessions): vector DB / structured DB · 几天到几年 · 例:用户偏好
• Episodic: 特定事件详细记忆 · 用于 reflection / 复盘 · 例:"上次出错的 case"

B. 4 个核心设计问题(10 min)

• 写入: 自动 vs 显式 · 谁决定记
• 读取: 一次性 vs 分层 retrieval · top-k by relevance
• 过期: TTL / decay function · 5 年前的 preference 还在影响今天?
• 隔离: user_id / tenant_id / case_id 作为 partition key · 防止数据串户

C. Memory 跟 event sourcing 的关系(10 min)

• DDIA Ch.12 Stream Processing 视角:memory 是 event log 的 derived view
• Event Sourcing 给 memory 带来的 3 个 superpower:
• 完美 audit trail(客户合规 GDPR / SOX 直接满足)
• Time travel debug(出 bug 时 replay 当时 events)
• 任意时间点 snapshot(对账 / 报告类天然 fit)
• 实操:CQRS · CDC · Kafka / Pulsar 等 stream 系统

D. Memory 的两条价值线(15 min · 重点)

Memory 不只是 "agent A 写 / agent B 读" 的存储层。 它有两条独立价值线,大部分 team 只用第一条:

线 1 · 跨 agent 共享(传统用法): - 同一系统内多个 agent 共享 long-term memory(用户档案 / 历史交互 / 知识库) - 跨会话连续性 · 用户在 agent A 说过的话,agent B 能用 - 效果: 系统从"各自孤岛" → "一致体验"

线 2 · Agent 自我强化(更深 · 大部分 team 没做): - 同一个 agent 读 自己过去的 episodic memory → 改进自己的下一次行为 - 这是 prompt-time learning,不是 weight-time(fine-tune)· 成本几乎免费 · 效果接近 fine-tune - 关键认知: agent day 30 比 day 1 准 — 不是模型变好了,是 episodic memory 累积了有用 case

自我强化的 4 个核心 pattern:

• Self-RAG over past attempts: agent 接到新 task 时,先 retrieve 自己过去类似 task 怎么做的 · 注入 prompt 前 N 行 · 几乎等于 "我看了 5 个类似前例再开干"
• Failure-driven self-correction: agent 失败后,把 (input, failed_output, root_cause, corrected_approach) 写入 episodic · 下次类似 input 来时优先 retrieve · 同一种错不犯第二次
• Style / preference learning(隐式 fine-tune): agent 跟同一用户多次交互后,从历史 retrieve 学到偏好(简洁 vs 详细 / 正式 vs 口语 / 时区 / 格式)· 不需要用户显式告诉
• Calibration learning: agent 每次给出 confidence(85% sure)+ 记录 actual outcome · 一段时间后用历史校准当前 confidence · 从"自信但常错"到"知道自己的边界"

实现要点(team 12 人共同 SOP): - Episodic 记录必须包括 outcome(success / failure / partial)· 不能只记 input/output · 否则 retrieval 无法分好坏 case - Failure case 必须标 root_cause 字段 · 不只是 "出错了" · 而是 "为什么" - Self-RAG 注入 prompt 时,显式标注这是 "过去的成功 / 失败 case" · 不能匿名注入 · 否则 agent 会把 failure 当作 best practice 重复 - Pruning policy:不是所有 episodic 都该长期保留 · 离群成功 + 重复失败 是高 ROI 留存对象,普通成功无价值 - Cold start:新 agent 没历史 · 第一阶段从同类 agent 的 episodic 借("transfer self-improvement")· 别让新 agent 从 0 学

自我强化反 pattern: - 不记录 outcome: 只记 input/output 没记"做对了吗" · retrieval 时无法区分 · 形同没有 self-improvement - 从来不 prune memory: 失败 + 噪音累积如山 · 污染未来 retrieval · agent 越久越差 - 没有 confidence calibration: retrieval 出 "上次也是这么做的" 就盲信 · 但上次本身就是错的 → 错误固化 - 跨用户 leak: user A 的 episodic 被 user B 的 agent retrieve 到 · 隐私 + 合规双重灾难 · partition key 必须严格 - 过强 self-correction: 一次失败后给 agent 注入 10 条 "上次错的" → 矫枉过正 · agent 不敢做事 · 应该 graceful + bounded(最多 3 条 cautionary case)

E. Memory 反 pattern(10 min)

• Context window overflow: working memory 撑爆 · 必须分段 summarize
• Memory pollution: episodic 记录大量无关失败 · retrieval 全是 noise
• State desync: agent 以为状态是 X · backend 已经变 · 必须有 verify
• Memory 跟 user identity 没绑定: reboot 后串户 · 必须 partition key
• No expiration: 5 年前数据还在影响今天 · 必须 TTL

6.3 书目锚点

• ADP Ch.8 Memory Management: 4 种 memory 详解
• DDIA Ch.12 Stream Processing: event sourcing 实现 memory layer
• DDIA Ch.8 Transactions · 快照隔离 + MVCC: memory 跨事务读一致性
• TT Ch.7 Interaction Modes: memory 边界 = team 边界 = agent 边界(Conway's Law 在 memory 层)

6.4 一张图

4 mem 类型 × 4 设计问题 = 16 格 matrix · 每格 1 句 best practice

6.5 演示

• 用 team 当前长流程 agent · 画出 memory 4 层用了哪些 · TTL 是多少 · audit trail 怎么做
• 大概率会发现 "我们其实没有 long-term memory,都是每次重新拉" — 这是发现差距的 moment

6.6 SKILL 卡片

• "Agent memory design 4 问 checklist"
• "Memory-as-Reinforcement 4 step setup"(self-RAG / failure-correction / preference-learning / calibration)
• "Episodic schema 必填字段"(input / output / outcome / root_cause / confidence_at_time / actual_outcome)

6.7 Lightning 版本

4 种 memory + "两条价值线"(共享 + 自我强化)+ Self-RAG 一个 pattern · 5 min。

7 · 分享与协作 · 内部 + 外部(60 min · P0)

7.1 学习目标

读完这节,team 每个人能: - 给任意一对协作关系(内部 / 外部)立刻分类 3 种模式(Collaboration / X-as-a-Service / Facilitating) - 诊断当前 team 的协作健康度 · 找出"该升级 / 该降级 / 该终止"的关系 - 知道 team 12 人内部知识沉淀有什么 system · 不靠个人记忆 - 给客户协作时按 4 个 trust 阶段调整自己行为

7.2 大纲

A. 协作 5 维度(10 min)

任何协作场景都能用这 5 维度组合分类: - 内向 vs 外向(team 内 / 跨 team / 跟客户 / 跟社区) - 同步 vs 异步(会议 / 文档 / 异步 review) - 一次性 vs 持续(POC / 长期支持) - 创造 vs 维护(写新东西 / 维护现有) - 一对一 vs 一对多(pair / share / publish) → 5 维度组合 = 协作场景。 选错维度组合 = 浪费 30-50% 协作成本。

B. 内部协作 4 种模式(15 min)

TT Ch.7 的 3 mode 应用到 team 内部: - Team Reading Club(Collaboration)· 6-12 周共读 + 讨论 · 短期高带宽 · 产生共享词汇 - SKILL 卡片库(X-as-a-Service)· 异步沉淀 · 每个成员都能写 / 调 · 不靠个人记忆 · team 长期资产 - 每月 Show & Tell(Facilitating)· 1 人讲 case · team 互问 · 1 小时 / 月 · 跨成员经验扩散 - Pair work / Shadow(Collaboration)· 新人 onboarding 时 · 老成员带教 · 退出时机:新人能独立交付 1 个 case

→ 何时升降级: - 全 Collaboration = 12 人都拉一起每天对齐 = 上限被会议吃完 · 必须把成熟领域降到 X-as-a-Service - 全 X-as-a-Service = 知识异步但不流动 · 必须周期性 Show & Tell 触发碰撞 - 没 SKILL 库 = 个人知识资产 · 离职 = 团队失血 · 这是 team lead 的 first-class 责任

C. 跨 team 协作(产品 / 工程 / 销售 / 客户成功)(15 min)

逐对诊断 + 健康 default: - 跟产品 team: 你们的 agent 设计 vs 他们 backlog · 健康 default = X-as-a-Service(他们提需求 / 你们交付 spec)· 现状若是 Collaboration 常驻 → 关系不稳定 - 跟工程 / 平台 team: 你做应用设计 / 他们做基础平台 · 健康 default = X-as-a-Service(平台暴露稳定 API · 你 self-serve)· 现状若需要工程长期参与改 agent → 应该 internalize 能力或抽到 enabling layer - 跟销售 / GTM team: 他们带客户 / 你做 SE pitch · 健康 default = 短期 Collaboration(单 deal cycle 内紧密)+ 回到 Facilitating(deal 闭环后你教他们独立 pitch) - 跟客户成功 / 实施 team: 他们 ongoing / 你做 enablement · 健康 default = Facilitating + X-as-a-Service(你给 SOP · 他们自主跑 · 异常时 escalate)

→ 诊断方法: 画两张图 · "当前所有跨 team 关系的 mode" + "理想 mode" · 差距 = 接下来 6 个月组织 refactor 的 backlog · 比任何 OKR 都准。

D. 外部协作 · 客户 + 合作伙伴 + 公开社区(15 min)

客户协作 4 阶段(AX trust stage 应用到 team-客户关系): - Trial 阶段(怀疑期): 高带宽 Collaboration · 你 team 主导 · 客户像监工 · 验证可靠性 · disclosure 拉满 · confirmation gate 多 · 时长目标:2-4 周,不能拖 - Routine 阶段(常规期): X-as-a-Service · 客户自服务 · disclosure 简化 · confirmation 减少 · 你 team 偶尔 escalate-supported · 占客户生命周期 70% - Judgment 阶段(信赖期): 客户开始问"你怎么看" · 你从"交付方"升级到"建议方" - Partnership / Advocacy 阶段(伙伴期): 客户成为推荐人 + co-create · 你 team 拿 advisory role · 这是 enterprise GTM 的最高境界

合作伙伴(集成商 / SI / consulting partner): - 多数关系该 X-as-a-Service · 你给方法论 + tooling · 他们做规模化交付 - 不要陷入 "我也帮你交付" → 容量被吃光 + 没差异化 - 一个 partner 该 Facilitating 介入 + 退出 · 不该 long-term Collaboration

公开社区(blog / talk / open source / 行业大会): - 投入产出比最高的 enabling 输出 · 1 份内容 N 个客户看到 · 12 人 team 永远是 capacity-bottleneck,公开内容是 leverage - 公开内容 3 种 ROI: - 招聘磁铁: 候选人主动来 · 节省 recruiter cost - 客户预热: 销售 cycle 缩短 · 客户来开会前已读 3 篇你的东西 - 行业声誉: 5 年后变成 thought leader · 不可替代 asset - 节奏建议: team 12 人 · 每月 2 篇公开内容(blog / linkedin / talk) · 1 人主导 + 1 人 review · 1 年累计 24 篇 = thought leadership 体量

客户技术分享 / 联合 white paper: 高 ROI 双赢 · 客户获得行业可见度 · 你拿 case study + reference

E. 反 pattern(5 min)

• All-Collaboration team: 跟所有人 / 内外都开周会 · 没有 X-as-a-Service · 12 人 capacity 上限被会议吃光
• Knowledge stays in heads: team 12 人各有专长 · 1 人离职即丢半年经验 · SKILL 库不是 nice-to-have,是 risk mitigation
• 客户依赖单个 team 成员: 某客户只认某成员 = 该 person 是 SPOF · 必须强制 rotation / shadow
• Public 分享只发 LinkedIn 不出 SOP: 短期影响 · 无长期复利 · 必须每篇都进入 team 内部 SKILL 库
• Open source 但不维护: 假 open source · 损 reputation · 不如不做 · 决定开源前评估 6 个月维护投入
• Trial 阶段拖超过 6 周: 客户 trust 没起来 · 关系会停留在监工模式 · 该升级时不升级 → 你 team 一直消耗 · 客户也累
• 跨 team 关系从未明确 mode: 暗号协作 · 出问题时双方都觉得对方该负责

F. 5 min · 文化层

• 分享文化不是规定出来的 · 是领头人示范 + 奖励机制 + 去除惩罚(失败 case 也能分享)三件事一起做
• 你作为 team lead 的最大杠杆动作:自己每月公开分享 1 次 · team 12 人会跟着学

7.3 书目锚点

• TT Ch.5 4 种基础团队拓扑: enabling team 是 sharing 的载体
• TT Ch.7 3 种交互模式(核心): Collaboration / X-as-a-Service / Facilitating · 何时升降级
• AM Ch.4 Listening Tours: 跟客户 / 跨 team 访谈的标准 tool · "don't push agenda"
• AM Ch.3 Impact Mapping: 跟外部 stakeholder 对齐 WHY
• AX 4 trust stage(Trial / Contextual / Judgment / Advocacy): 客户协作的进阶 framework
• AX 4 lever(disclosure / confirmation / reversibility / escalation): 客户 trust 建立的具体动作
• 即兴沟通 + 风格感觉: 对外表达的语言层

7.4 一张图建议

2D 矩阵:X 轴 = 内部 → 外部(4 列:team 内 / 跨 team / 客户 / 公开社区)· Y 轴 = 3 种模式(Collaboration / X-as-a-Service / Facilitating)· 12 格内填 "健康 default + 何时升降级"。

7.5 演示

• 现场诊断: team 当前所有协作关系(team 内 4 种模式 + 跨 4 team + 当前 3-5 客户 + 公开社区)· 用 5 维度 + 3 mode 分类 · 哪些 mode 错了 / 哪些没明确
• 客户 trust 阶段定位: 选 2-3 个当前客户 · 按 AX 4 stage 定位 · 跟客户当前 deliverable 对照 · 应该升级 / 维持 / 还是降回 Routine
• 公开内容投入估算: 12 人 × 平均每月 0.5 篇 = 6 篇 / 月 · 全年 72 篇 · 投入 vs 招聘 + 客户预热 + 行业声誉 ROI

7.6 SKILL 卡片输出

• "5 维 × 3 mode 协作选型表"(team 内 / 跨 team / 客户 / 公开)
• "客户 4 trust stage 行为 checklist"(每阶段你 team 该做 / 不该做的)
• "公开内容月度节奏 SOP"(谁负责 / review 流程 / 入 SKILL 库)

7.7 Lightning 5 min 版本

3 mode + AX 4 trust stage · 这两个 framework 就是 80% 价值 · 1 张图能讲完。

8 · Audit Log · 合规 + Debug + 客户信任(60 min · P0)

8.1 学习目标

• 理解 audit log 是 first-class 不是 nice-to-have(三重必需:合规 / debug / 客户信任)
• 给一个客户能立刻列出 audit log 要求 + 实现策略
• 区分平台自带的执行 trace vs 我们必须自造的业务 audit

8.2 大纲

A. Audit log 三重必需(10 min)

• 合规: SOX(financial 7 年)· HIPAA / MDR(medical · REMATIQ 类客户必需)· GDPR(全行业)
• Debug: 客户说 "上周三 agent 给错了答案" — 没 audit 你两眼一抹黑 · 大部分长 UAT 项目跑偏都跟这相关
• 客户信任(AX trust 阶段进阶必备): Trial → Routine 升级的硬条件之一是"我能看到 agent 做了什么决策"

B. 平台自带 vs 我们必须自造(15 min)

平台 / 观测层自带: - Task execution log(每次 run · input/output · state transition) - Workspace audit trail(谁改了 agent 配置 · 何时) - Per-instance 观测 trace(token / latency / error · 短期保留)

我们必须自造: - Decision log: agent 为什么这样决策 · routing reason · model 选择 reason · 该写哪步该 escalate - Business event log: 客户业务语义(订单已批准 / 发票已发出 / 投诉已升级)— 不是技术 event - Cross-system audit trail: 一个客户业务流程跨多个 agent + 客户系统 · 需要 unified trail - 客户 facing audit UI: 客户能自己查 · 不是 escalate 来问你

C. Audit log 4 层结构(15 min)

D. 客户 vertical × audit 要求速查(10 min)

E. Audit log 设计 6 原则(5 min)

1. Immutable: 写入后不能改 · append-only(WORM)
2. Identifiable: 每条溯源到 user / agent / version
3. Timestamped: UTC ISO8601 · 不要本地时区
4. Schema versioned: log schema 演进时能向后兼容 read
5. Encrypted at rest + access logged(log 谁读了 log)
6. Retention policy explicit: 法规保留 vs GDPR 删除权 矛盾 → 用 crypto-shredding 调和(数据保留 · key 删除 = 可读但读不出来)

F. 反 pattern(5 min)

• PII 明文 + 长保留 → GDPR 被罚 · 必须 hash / pseudonymize
• Audit log 跟 application log 混在一起 → app log 30 天滚动 · audit 要 7 年 · 必须分两 storage
• 没结构化 search → 客户问 "上月 > $10k 被拒多少笔" · 你需要 1 周 grep · 该 Elasticsearch / structured event store
• 观测层当唯一 audit → 观测工具默认短期 retention · 客户合规 7 年 → 必须 export + 长期存
• No decision log → 客户问 "为什么 agent 这样决定" · 你只能猜 · 必须每个 LLM 决策点写 decision log

8.3 书目锚点

• DDIA Ch.12 Stream / Event Sourcing: audit trail 是 event log 的视角 · "完美 audit" 是 event sourcing 的 superpower
• DDIA Ch.8 Transactions: audit log 写入必须 atomic with business state(否则有"业务做了但 audit 漏写"的鬼魂状态)
• AX 4 trust stage: 客户能看 audit = Trust Stage 2 → 3 的硬条件
• MDR Rule 11 + GDPR: 法规层底层

8.4 一张图

4 层结构 × 6 原则 = 24 格 matrix · 每客户 vertical 标"必须 / 可选 / 不要"

8.5 演示

• 列 team 当前进行中客户 · 各属于哪个 vertical · audit 要求是什么 · 我们当前实现到哪 · gap 在哪
• 演示一次 "decision log + replay" — 当客户问"为什么这个 case agent 这样做",你能 30 秒回答

8.6 SKILL 卡片

• "Audit log 4 层结构"(Tool call / State / Decision / HITL)
• "客户 vertical × audit 要求速查"
• "Audit log 设计 6 原则"
• "观测层 vs 自造 audit 边界"(default / extend / replace 决策)

8.7 Lightning 5 min 版本

"4 层结构 + 客户 vertical 速查" · 一张图。

9 · AI Native · 4 阶段 framework + 3 surfaces(60 min · P0)

9.1 学习目标

• 理解 Anthropic Founder's Playbook(2026-05-14)的核心 framework · 把"founder 视角"翻译成"12 人 Solutions team lead 视角"
• 用 4 阶段(Idea / MVP / Launch / Scale)诊断当前每个客户 engagement 处于哪一阶段 + 该做什么
• 区分 3 个 Claude surface · 给团队成员日常工作选对工具

9.2 大纲

A. AI Native 的核心命题(10 min)

• Anthropic 的 thesis:AI 移除了过去 startup 必经的 3 个 bottleneck — capital · headcount · technical skill
• 我们的延伸:同一个 thesis 适用于 enterprise team — 12 人 team 在 2026 能交付 2024 年 30 人 team 的 throughput,如果内化 playbook 的 framework
• Founder 的角色变了:从"individual contributor"变成"orchestrator of agents"
• 我们的角色也变了:每个团队成员不只是 SE,是 客户 agent 项目的 orchestrator
• 关键 reframe:每个客户 engagement 是一个"startup" · 我们是帮客户走过 4 阶段的合伙人,不是单纯 deliverable 供应商

B. 4 阶段 framework 应用到客户 engagement(15 min)

逐阶段对应 + 我们现有 delivery 流程的接口:

关键判断 protocol:任何客户对话开始前 30 秒回答 "他们在哪个阶段?" — 阶段不对会导致工具不对(给 Idea 阶段客户做 MVP architecture 是浪费)。

C. 3 个 Claude surface · 选型(10 min)

playbook 明确区分 3 个工具(p.11 原图表):

default 规则:3 个 surface 共享同 Claude underneath · workspace 不同 · 选 surface ≠ 选 model · 选 task 的 envelope。

D. 6 个具体 framework 直接拿来用(20 min)

playbook 里抽出来 · 我们 team 直接可执行:

1. CLAUDE.md 持久化 context(p.16 / p.18) - 每个客户项目 / 每个 agent 设计 · 必须有一个 CLAUDE.md 写下"架构决策 + 不要做什么 + 关键约束" - 每次 session 开始读 · 每次 session 结束写一笔(本次做了什么 / 假设了什么) - 5 min/session 文档成本 = 防 architectural drift compounding 的最便宜保险

2. Session template(p.18) - 每次 Claude Code session 开场固定 3 件事:revisit scope doc · 加载 CLAUDE.md · 声明本次 task + 约束 - 结束 2 件事:更新 CLAUDE.md · log entry(做了什么 / 决定了什么 / 引入什么假设) - 这是给 team 12 人的强 SOP · 不是"建议"

3. 结构化 devil's advocate(p.10 + p.12) - 任何客户假设 / 任何 idea · 必须让 Claude 反面论证(找 disconfirming evidence) - AI 跟 confirmation bias 同向时给你 powerup · 反向时是最便宜的 pressure-test - team SOP:每个客户 Idea 阶段必跑 1 次 devil's advocate · output 进 discovery doc

4. Sean Ellis 40% 测试(p.19) - 给真客户用了的 agent · 问 active users:"如果这个 agent 不能用了你会感觉怎样?" - ≥ 40% 答"非常失望" = 有 PMF 信号 - < 40% = 客户也许"满意"但不依赖 = 假 PMF - 用在每个 production agent 上线 30/60/90 天 checkin

5. Architectural audit + 优先级(p.23-24) - Launch 阶段必跑:Claude Code 全 codebase audit · output prioritized list(必须先修 / 可并行 / 可等) - 把 audit 结果 feed 给 Claude 做 sequencing · 不要靠人脑排 - team 应用:每个 production agent 在 launch 后 30 天做一次 audit

6. Workflow lock-in 通过 integration(p.30) - Scale 阶段建 moat 的具体方式:让客户在你的 agent 之上建他们自己的 workflow(integration · webhook · API) - 越多 integration 越难 switch · 这是 Scale 阶段的真 moat - team 战略:任何 production agent 6 月后必问 "客户在这上面建了什么?" — 那些 build-on-top 的 workflow 是续约的真原因

E. AI Native 时代的 5 个反 pattern(5 min)

playbook 用 founder 视角 · 我们用 team 视角:

• Mistaking building for validating(p.10): "客户兴奋同意做 POC" ≠ "客户真有问题" · 42% startups 失败因为做了没人要的东西 · 我们 team 风险同等 · 必须在 Spec Sign-Off 前 validate 问题真实
• Premature scaling(p.10): 客户问题没 validate 就上 multi-agent / 复杂架构 · 跟 founder 错误同构
• Falling for false PMF(p.17): 客户 month-1 enthusiasm 不等于 retention · 我们做 DoD gate 时要看 30/60/90 天行为 · 不是 launch 当周
• Zero-friction scope creep(p.17): "再加一个 edge case" 单次都合理 · 累加摧毁项目 · 必须有 written scope + 每次新需求过 gate
• Loss of objectivity(p.10): 用 AI 验证你已经相信的东西 · 必跑 devil's advocate 抵消

F. 5 min · 给团队成员的 mental model 升级

playbook 关键句(写进 team SKILL 卡片): "The bottlenecks are no longer what you can build, but what you choose to build."

• 过去 12 个月:能不能技术上做 X · 你的瓶颈
• 接下来 12 个月:该不该做 X · 怎么 sequence X · 是不是 X 在客户那真有价值 · 这是新瓶颈
• team 12 人最该练的不是"会用 Claude Code" — 大家都会了 — 是 "判断什么不做" + "sequence 决定 ROI"

9.3 书目锚点

• Anthropic Founder's Playbook(2026-05-14 · 32 页 · PDF 本地在 04-reading-notes/sources/anthropic-founders-playbook-2026-05.pdf)
• 章节锚点:Idea p.8-14 · MVP p.15-20 · Launch p.21-24 · Scale p.25-30 · Same job new rules p.31-32
• 跟 AX 的关系:playbook 讲 founder 怎么用 AI · AX 讲产品怎么对用户体现 AI native — 互补
• 跟 ADP 的关系:playbook 是 high-level lifecycle · ADP 是 pattern level — 4 阶段决定用哪些 pattern

9.4 一张图建议

2D matrix:X = 4 阶段(Idea / MVP / Launch / Scale)· Y = 3 surface(Chat / Cowork / Code)= 12 格 · 每格 1-2 句"此阶段此 surface 该做的事"。 一页纸贴墙。

9.5 演示

• 列 team 当前 3-5 个客户 · 各自定位在哪个阶段(就用 playbook 的 exit criteria 客观判断)· 大概率发现 1-2 个客户实际比 team 自我感觉早 1 阶段(POC 阶段时还在 Idea 阶段没真 validate)
• 拿一个进行中客户 · 跑一次 devil's advocate 演示(15 分钟 · output 实际改了项目方向是常见的)
• 给一个新 customer engagement · 现场写一个 CLAUDE.md template(给 team 之后复用)

9.6 SKILL 卡片输出

• "4 阶段客户定位 5 问 checklist"(每客户对话开始前 30 秒判断)
• "3 surface 选型 12 格 matrix"(贴墙)
• "Session template · 开 3 + 结 2"(强 SOP)
• "5 个 AI native 反 pattern speed scan"(任何项目 review 时 5 分钟过一遍)

9.7 Lightning 5 min 版本

"AI 移除 3 个 bottleneck · 4 阶段 / 3 surface 速查 · 新瓶颈是'选什么不做'" · 一张图。

附录:可扩展的下一批主题(后续 6 周可继续)

通用 SKILL 卡片清单(系列结束 team 应该有的)

每个分享出 1-3 张 · 9 次后 team 共享 25+ 张: 1. Model 选择决策树 2. Cost 估算公式 3. Routing 选型 5 问 + 8 反 pattern 4. Prompt 5 段模板 5. Structured output 4 best practices 6. 3 交互 mode 选型 5 问 7. Tool 设计 5 原则 8. Tool 选型决策树 + Custom tool review checklist 9. Memory 4 问 checklist 10. Memory-as-Reinforcement 4 step setup(self-RAG / failure-correction / preference-learning / calibration) 11. Episodic schema 必填字段(input/output/outcome/root_cause/confidence) 12. 5 维 × 3 mode 协作选型表 13. 客户 4 trust stage 行为 checklist 14. 公开内容月度节奏 SOP 15. AX 设计 8 项 checklist 16. EventStorming 90 min 流程 17. DDD 子域 3 类判断 18. Audit log 4 层结构(Tool call / State / Decision / HITL) 19. 客户 vertical × audit 要求速查 20. Audit log 设计 6 原则 21. 观测层 vs 自造 audit 边界 22. 4 阶段客户定位 5 问 checklist(Idea / MVP / Launch / Scale) 23. 3 surface 选型 12 格 matrix(Chat / Cowork / Code × 4 阶段) 24. Session template · 开 3 + 结 2(CLAUDE.md 维护 SOP) 25. 5 个 AI native 反 pattern speed scan

跨主题的统一原则(写在每次分享开头)

时间安排建议

前 6 周(密集期): 每周 1 个主题 60 min · 周五同步 · 必有领读 + case · 每人本周作业是把 SKILL 卡片用在自己 case 上 · 下周开场 5 min review。

第 7-12 周(延伸): 同节奏继续做附录的 6 个主题。

12 周后: team 12 人共享 12 张 SKILL 卡片 + 6 张反 pattern 速查 · 新人 onboarding 时间从 3 周降到 1 周 · 客户 deck 质量统一。

长期(每季度): 1 次"复盘 + 升级"分享 · 把过去 3 个月真实 case 抽出来 · 更新 SKILL 卡片 · 形成 team 的 institutional knowledge。

写作建议(给你在另一个 repo 深度丰富时用)

每个主题最终写完应该包含: - ✅ Hero(5 min 一句话 + 一张图) - ✅ 学习目标(3-5 条 outcome) - ✅ 大纲(4-5 个 section · 各 10-20 min) - ✅ 反 pattern(team 真实案例,匿名) - ✅ 演示脚本(具体 input / 预期 output / 时间) - ✅ SKILL 卡片输出物 - ✅ Lightning 5 min 版本 - ✅ 书目锚点(精确到章节) - ✅ Q&A 预设(3-5 个 team 大概率会问的问题 + 准备答案)

每篇预计 1500-2500 字 · 6 篇就是 1-1.5 万字 · 等于一份小书 · 团队内部可独立分发。