Agent 记忆、技能与 Multi-Agent ​

经过验证的经验

Memory Candidate
记忆候选

治理、范围与时效校验

Skill Candidate
技能候选

评测、发布与回滚

受控委托给 Worker

结果、证据与反馈

这是一条受治理的学习与协作闭环：经验不能直接成为长期记忆，记忆也不能未经评测直接升级成所有 Agent 共用的技能。

定位：这是七篇正式文档中的第 04 篇。
目标：把两个非常容易被“概念化”的主题讲成真正的生产系统问题：
Memory / Skill / Continuous Learning 解决“过去的经验怎样安全影响未来”；Multi-Agent / Workflow 解决“什么时候需要多个决策边界，以及多个 Agent 怎样协作才值得”。

整篇主线：

text
Run / Feedback
→ Candidate Memory
→ Governed Memory
→ Consolidation / Correction / Forgetting
→ Candidate Skill
→ Eval / Review / Release
→ Future Run

Single Agent
→ Workflow
→ Agent as Tool / Specialist
→ Parallel Workers
→ Supervisor / Handoff
→ Multi-Agent Runtime / Platform

**本篇不是“向量记忆教程”，也不是“多个 Agent 聊天教程”。**真正要回答的是：
什么值得长期保留、谁可以写、什么时候应该升级成 Skill、怎样避免越学越错；以及什么时候拆 Agent 真正产生净收益、怎样控制协调成本、错误传播和资源冲突。

回答原则：长期学习题重点讲 Semantic Promotion（语义升级）与 Governance（治理）；Multi-Agent 题重点讲 Boundary（边界）与 Net Benefit（净收益）。不要为了“更智能”而自动学习，也不要为了“更高级”而自动拆 Agent。

一、先建立整篇主线 ​

1.1 第一性问题：Agent 怎样“越用越好”，而不是“越用越乱” ​

一个没有长期学习能力的 Agent，每次 Run 都可能重复：

text
重新理解用户偏好
重新探索环境
重新踩同一个 Tool 坑
重新发现同一项目约束
重新尝试同一个失败方案

这会浪费：

text
Token / Tool / 时间
用户反复解释
组织经验无法沉淀

于是系统自然会想：

“把这次经验记下来，下次直接用。”

但从这一刻开始，风险也出现了：

text
一次错误
→ 被写入 Memory
→ 跨 Run 重复出现
→ 被多个 Agent 复用
→ 甚至升级为 Skill

所以：

Persistence（持久化）会把局部错误放大成时间维度上的系统性错误。

因此长期学习真正的第一问题不是：

“Memory 用什么数据库？”

而是：

什么值得获得影响未来行为的权力？

1.2 Memory Write 和 Memory → Skill 是两次不同的语义升级 ​

第一次：

text
Run 中的一条信息
→ Candidate Memory
→ Long-term Memory

这代表：

当前局部信息开始获得跨 Run 影响未来决策的权力。

第二次：

text
多个 Memory / 成功经验
→ Candidate Skill
→ Published Skill

这代表：

单次 / 局部经验开始获得影响一整类未来任务的权力。

所以：

Memory Write 是第一次 Semantic Promotion；Memory → Skill 是第二次 Semantic Promotion。

第二次治理门槛应该更高。

1.3 Continuous Learning 不等于模型在线训练 ​

企业里“Agent 在学习”至少可以分三层：

text
Level 1
→ Memory Update

Level 2
→ Skill / Policy Update

Level 3
→ Model Weight Update

本篇重点讨论前两层。

也就是说：

模型权重完全不变，Agent 仍然可以通过 Memory、Skill、Verifier、Routing Policy 的外部状态持续演进。

这也是为什么企业里的“持续学习”更接近：

text
Knowledge Governance
+
Release Governance

而不是浪漫化的“Agent 自动改自己”。

1.4 Multi-Agent 的第一性问题不是“怎么协作”，而是“为什么要拆” ​

一个 Single Agent 已经可以：

  • 调 Tool；
  • 规划；
  • 读写 Context；
  • 运行长任务。

所以拆成多个 Agent 前必须回答：

单一决策边界到底哪里开始失效？

真正合理的拆分原因通常只有：

text
Context Isolation
Capability Isolation
Permission Isolation
Parallelism
Model Specialization
Ownership / Service Boundary
Failure Containment

如果只是：

“产品经理 Agent + 开发 Agent + 测试 Agent 看起来很合理。”

这通常不构成架构理由。

1.5 Multi-Agent 为什么很快变成分布式系统问题 ​

一旦系统有多个独立决策主体，就会出现：

text
谁负责哪个任务
谁拥有哪个资源
状态怎么共享
消息是否重复
某个 Agent 失败怎么办
结果冲突怎么合并
整体什么时候完成

这些对应经典分布式系统问题：

text
Ownership
Coordination
Distributed State
Partial Failure
Consistency
Scheduling
Merge / Conflict Resolution
Failure Containment

不同之处是：

节点本身还是非确定性的决策主体。

所以可以记：

text
Multi-Agent
=
Distributed Systems Problems
+
Non-deterministic Decision Makers

1.6 读不懂时先记这张“Memory / Skill / Multi-Agent”速记表 ​

概念 它解决什么问题 危险点
Session 之前聊过什么 被误当长期事实
Memory 哪些过去值得跨 Run 继续影响未来 错误被长期放大
Knowledge 哪些外部事实有正式 Authority 被 Memory 覆盖
Skill 某类任务“应该怎么做” 错 Skill 放大到整类任务
Workflow 哪些步骤必须按确定性结构发生 被 Agent 自由跳过
Agent 哪些节点需要动态决策 拆得过多导致协调爆炸
Shared Artifact 多 Agent 共享可验证结果 Schema / Version
Shared Chat 多 Agent 互发自然语言 传话失真 / Context 爆炸

两个最关键的判断：

text
Memory
→ 跨时间复用

Multi-Agent
→ 跨决策主体协作

两者一旦扩大影响范围，都必须提高 Governance（治理）门槛。

二、Memory / Skill / Continuous Learning ​

2.1 Q1｜Session History、Memory、Knowledge、Skill 为什么不是同一个东西？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

我会先按“它解决什么问题”区分：

text
Session History
→ 之前聊了什么

Memory
→ 过去哪些信息值得跨 Run 继续影响未来

Knowledge
→ 企业 / 外部权威事实

Skill
→ 遇到某类任务应该怎么做

它们可能共享检索技术，但治理语义完全不同。

2～3 分钟高分回答 ​

Session History 主要服务当前连续对话，生命周期通常和 Thread / Session 绑定。

Memory 是从历史交互 / Run 中选择出来、值得未来继续使用的信息。

Knowledge 来自 Source of Truth，例如 Metric Registry、CMDB、Policy System。

Skill 是可复用的程序性知识，比如：

“做月度 BI 分析时，先校验时间范围，再查指标口径，再跑 SQL，再做 Evidence Check。”

真正危险的是把这些对象统一叫“Memory”，然后放一个 Vector DB。

因为它们在：

text
Authority
Scope
Retention
Correction
Version
Release
Deletion

上完全不同。

项目映射 ​

Data Agent：

text
SQL Result
→ Run Evidence

用户长期偏好
→ Memory

GMV 正式定义
→ Knowledge

标准分析流程
→ Skill

研发 Agent：

text
本次 Build Log
→ Run Evidence

Repo 常用测试习惯
→ Candidate Memory

公司发布规则
→ Policy / Knowledge

稳定 Debug 方法
→ Skill

高分亮点句 ​

相同的检索技术，不代表相同的数据语义。

面试官真正想听什么 ​

  • 是否把历史、知识、记忆、技能混在一起；
  • 是否理解长期信息的 Authority / Lifecycle。

典型追问 ​

  1. Skill 和 Workflow 有什么区别？
  2. Memory 和 RAG 有什么区别？
  3. Procedural Memory 什么时候应该升级成 Skill？
  4. Session Summary 算 Memory 吗？

Red Flags ​

  • “长期 Memory 就是长期 RAG。”
  • “所有历史做 Embedding 就是 Memory。”

为什么这样回答 / 本题套路 ​

这是总边界题。先按“它回答什么问题”拆对象，再用 Authority / Lifecycle 解释为什么不能共用一套治理。

2.2 Q2｜什么信息值得成为长期 Memory？什么信息绝对不应该写入？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我会用五个条件判断：

text
Future Reuse
Stability
Scope
Authority / Provenance
Retention Permission

只有未来有稳定复用价值、来源可信、Scope 清晰、允许长期保留的信息，才有资格进入 Memory。

2～3 分钟高分回答 ​

值得记的例子：

  • 用户明确长期偏好；
  • 已验证的稳定环境事实；
  • 重复出现且仍有效的经验；
  • 用户明确要求记住的信息。

不该直接写的：

  • 单次 Tool Result；
  • 临时 Error；
  • 模型未验证猜测；
  • 实时企业事实副本；
  • Secret / Credential；
  • 一次性的临时指令。

我会在写入前问：

text
未来会不会重复用？
多久会变化？
谁有资格定义它？
写错后 Blast Radius 多大？

如果是：

“当前服务 Owner 是 A。”

这种动态企业事实，更应该每次从权威系统回源，而不是长期复制到 Memory。

高分亮点句 ​

Memory 不是“值得保存的信息”，而是“值得获得未来决策影响权的信息”。

面试官真正想听什么 ​

  • 是否会无脑“记住更多”；
  • 是否理解长期错误放大；
  • 是否考虑敏感数据与生命周期。

典型追问 ​

  1. 用户说“以后都这样”是否直接写？
  2. 临时项目偏好保存多久？
  3. 高频重复事实就一定值得 Memory 吗？

Red Flags ​

  • “只要用户纠正过就永久记住。”
  • “所有历史都先保存，后面再筛。”

为什么这样回答 / 本题套路 ​

这是决策题。重点不是 Memory 类型，而是“什么条件让一条信息获得长期影响权”。

2.3 Q3｜为什么 Memory Write 是一次语义升级，而不是普通日志写入？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

日志记录过去，Memory 会影响未来。

所以把一条信息写进长期 Memory，相当于授予它：

跨 Run 影响未来行为的权限。

因此写入门槛应该显著高于普通 Log / Trace。

2～3 分钟高分回答 ​

例如一次 Run 里模型推断：

“这个用户似乎不喜欢审批。”

如果只是 Trace：

当前 Run 结束，影响结束。

如果写成 Memory：

text
用户不喜欢审批

未来生产变更时，Agent 可能继续引用它。

所以 Memory Write Pipeline 应至少有：

text
Candidate Extraction
→ Type
→ Scope
→ Provenance
→ Authority / Confidence
→ Security
→ Dedup / Conflict
→ Retention
→ Commit

这里“Agent 觉得重要”只能产生 Candidate，不能自动 Commit。

Hot-path 和 Background Write 怎么选 ​

不是所有 Memory 都要在用户请求主链路里立即写。

text
明确、低风险、用户直接声明
→ Hot-path Write
例如“以后默认用摄氏度”

需要 Consolidation / Conflict Check / 多 Run 归纳
→ Background Learning

Background 的优点是可以做更完整的去重、聚合和安全检查；代价是写入延迟和最终一致性。

所以：

写入时机也是 Memory Contract 的一部分。

高分亮点句 ​

把信息写进 Memory，本质上是在授予它影响未来行为的权力。

面试官真正想听什么 ​

  • 是否真正理解 Memory Governance；
  • 是否会把 Memory 写入做成简单 append。

典型追问 ​

  1. 哪些 Memory 可以 Hot-path 写？
  2. 谁来决定 Commit？
  3. 用户明确声明是否可以绕过 Review？

Red Flags ​

  • “每轮结束让 LLM 总结 5 条 Memory，然后直接写库。”

为什么这样回答 / 本题套路 ​

这是 Failure-first 题。用“临时判断被长期固化”的事故，解释为什么 Memory Write 是治理动作而不是存储动作。

2.4 Q4｜Memory Write Pipeline 至少应该做哪些检查？Authority 和 Confidence 为什么必须分开？ ​

复习优先级：P0｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我会按：

text
Type
Scope
Provenance
Authority
Confidence
Security
Conflict
Retention

做写入检查。

Authority 回答：

谁有资格定义事实？

Confidence 回答：

我们有多确定这次观察是对的？

两者不能混。

2～3 分钟高分回答 ​

例如：

text
模型连续 10 次猜到 GMV 定义

Confidence 可能越来越高。

但它的 Authority 仍然不能超过：

text
Metric Registry

反过来，用户本人说：

“我以后报表都用人民币。”

Authority 很高，因为用户有资格定义自己的偏好。

但如果语句含糊，Confidence 可能仍需要确认。

所以 Memory Item 至少需要：

text
memory_id
type
scope
owner
source_ref
authority
confidence
sensitivity
valid_from
expires_at
last_verified_at
supersedes
version
status

项目映射 ​

Data Agent：

  • 用户偏好 → User Authority；
  • Metric Definition → Knowledge Authority，不能由 Memory 覆盖。

高分亮点句 ​

High Confidence 不等于 High Authority。重复猜对很多次，也不能获得定义企业事实的资格。

面试官真正想听什么 ​

  • 是否把模型置信度当事实权威；
  • 是否有完整 Memory Metadata 思维。

典型追问 ​

  1. Authority Model 谁定义？
  2. Confidence 如何更新？
  3. Scope 与 Permission 区别是什么？

Red Flags ​

  • “模型越确定，这条 Memory 权重越高。”

为什么这样回答 / 本题套路 ​

这是概念边界题。用企业 Source of Truth 反例最容易把 Authority / Confidence 拆开。

2.5 Q5｜用户纠正一条旧 Memory，怎样保证旧事实、派生 Summary、Skill 不再继续影响未来任务？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

这不是 UPDATE memory SET value=... 能解决的，因为旧 Memory 可能已经派生到：

text
Summary
Embedding
Shared Memory
Skill
Cache

所以 Correction / Forget 必须有 Lineage（血缘）和 Invalidation（失效传播）。

2～3 分钟高分回答 ​

假设：

text
Memory M1
→ Consolidated Memory M2
→ Summary S1
→ Candidate Skill K1
→ Retrieval Cache

用户纠正 M1 后：

text
Mark M1 superseded
→ Write M1 v2
→ Invalidate Retrieval Cache
→ Re-evaluate M2 / S1
→ Revoke / Update K1 if derived

这里不要物理覆盖旧版本，否则 Audit / Debug 会失去历史。

真正需要的是：

text
Version
supersedes
derived_from
status

高分亮点句 ​

Memory Correction 是数据血缘问题，不是 CRUD 问题。

面试官真正想听什么 ​

  • 是否考虑派生对象；
  • 是否理解 Forget / Delete 的传播；
  • 是否有 Version / Lineage 思维。

典型追问 ​

  1. 已经进入 Trace / Eval 的旧 Memory 怎么办？
  2. Shared Memory 怎么更新？
  3. Skill 已发布怎么办？

Red Flags ​

  • “改数据库这一条就行。”
  • “重新生成 Embedding 即可。”

为什么这样回答 / 本题套路 ​

这是 Lifecycle 事故题。先画派生链，再推导 Correction Propagation。

2.6 Q6｜Memory Retrieval 为什么不能只有 Vector Similarity？Scope、Freshness、Authority 怎么参与排序？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

Memory 是否应该被使用，不只取决于“像不像当前 Query”。

我会先做：

text
Scope / Permission Eligibility
→ Semantic / Keyword Recall
→ Freshness
→ Authority
→ Confidence
→ Task Relevance

2～3 分钟高分回答 ​

一个旧项目里的用户偏好可能和当前 Query 高度相似，但当前 Project Scope 不匹配，不应该召回。

一条 Memory 也可能：

  • 内容相关； -来源可信； -但已经过期。

所以 Retrieval 不应该是：

text
Vector TopK

而应该是：

text
Eligible Memory Set
→ Recall
→ Rank
→ Revalidate
→ Context

这里和 Knowledge Retrieval 有相似机制，但 Authority 语义不同：

  • Knowledge 强调 Source of Truth；
  • Memory 强调历史经验 / 偏好的可信与适用范围。

高分亮点句 ​

相似度决定“像不像”，Memory Governance 决定“现在还该不该用”。

面试官真正想听什么 ​

  • 是否把 Memory 等价 Vector Search；
  • 是否考虑 Staleness / Scope；
  • 是否会在 Context 前 Revalidate。

典型追问 ​

  1. Freshness 怎么定义？
  2. Memory Ranking 用 LLM 还是规则？
  3. Retrieval 以后需要 Verification 吗？

Red Flags ​

  • “Memory 就是 TopK 相似历史。”

为什么这样回答 / 本题套路 ​

这是 Retrieval 机制题。先构造“高相似但不适用”的反例，再说明 Eligibility 优先于 Similarity。

2.7 Q7｜多个 Agent 并发写 Shared Memory 导致相互覆盖，怎样设计版本和一致性？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

Shared Memory 不能当普通共享文本。

我更倾向：

text
Read-mostly
+ Single Writer / Consolidator

如果允许并发写，至少要有 Version、CAS、Conflict Policy 和 Merge Semantics。

2～3 分钟高分回答 ​

最简单的并发保护：

text
read version=10
→ update
→ CAS write version=11

如果两个 Agent 同时基于 v10 写：

一个成功，另一个进入 Conflict Resolution。

更稳妥的组织方式通常是：

text
很多 Agent Read
少数 Agent / Consolidator Write

或者使用 Append-only Event，再由 Consolidator 生成稳定 Memory。

为什么？

因为 Shared Memory 写错以后，影响从：

text
一个 Agent

扩散成：

text
多个 Agent / 整个组织

高分亮点句 ​

Shared Memory 的写权限应该比读权限更严格。

面试官真正想听什么 ​

  • 是否意识到 Shared Memory 是并发数据系统；
  • 是否会让所有 Agent 自由写。

典型追问 ​

  1. Merge 用 LLM 可以吗？
  2. 多 Region Shared Memory 怎么办？
  3. Org Memory 谁拥有？

Red Flags ​

  • “大家都写同一个共享向量库，最后去重。”

为什么这样回答 / 本题套路 ​

这是 Multi-Agent + Memory 的交叉题。高分点是从“智能共享”切回经典并发与错误广播问题。

2.8 Q8｜Memory Poisoning 和 Skill Supply Chain Attack 有什么区别？ ​

复习优先级：P1｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

Memory Poisoning（记忆投毒）污染的是：

长期事实 / 经验。

Skill Supply Chain Attack（技能供应链攻击）污染的是：

可执行 / 可复用的方法、脚本和 Tool 组合。

Skill 的 Blast Radius 通常更大。

2～3 分钟高分回答 ​

Memory Poisoning 典型链：

text
恶意 Web / Repo / Email
→ Agent 读取
→ 被误判成“值得学习”
→ 写入长期 Memory
→ 几天后重新召回
→ 影响高风险任务

Skill Attack 可能包含：

text
恶意 Script
危险 Tool
过宽 allowed-tools
隐蔽 Network
错误 Workflow

所以 Skill 上线应该至少有：

text
Source Verification
Static Scan
Sandbox
Permission
Eval
Version
Release
Rollback

Microsoft 当前 Agent Skills 明确把 Skill 定义成“instructions + scripts + resources”的可移植包，并支持 Tool Approval、Caching、Security Best Practices，这说明 Skill 已经很接近软件供应链资产，而不是一段 Prompt。[R1]

高分亮点句 ​

Memory 错一条可能影响若干任务，Skill 错一个可能改变一整类任务的默认行为。

面试官真正想听什么 ​

  • 是否理解 Persistent Prompt Injection；
  • 是否把 Skill 当简单 Prompt；
  • 是否有 Supply Chain 思维。

典型追问 ​

  1. Skill 是否允许自动生成？
  2. 第三方 Skill 能直接安装吗？
  3. Skill Script 用什么权限执行？

Red Flags ​

  • “Skill 就是 Markdown，所以风险不高。”
  • “Memory 做内容审核就足够。”

为什么这样回答 / 本题套路 ​

这是安全边界题。先比较 Blast Radius，再推导为什么 Skill 需要比 Memory 更严格的发布治理。

2.9 Q9｜一个经验什么时候应该升级成 Skill？为什么 Candidate Skill 不能直接上线？ ​

复习优先级：P0｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

只有当经验满足：

text
Recurring
Stable
Reusable
Clear Trigger
Verifiable
Positive ROI

才值得从 Memory / Lesson 升级成 Skill。

Candidate Skill 不能直接上线，因为这是第二次 Semantic Promotion。

2～3 分钟高分回答 ​

一次任务成功：

不代表方法稳定。

我会先看：

text
是否多次出现？
是否跨任务有效？
适用边界是否清楚？
能不能自动验证？
失败时 Blast Radius 多大？

然后：

text
Candidate Lesson
→ Candidate Skill
→ Offline Eval
→ Security Review
→ Version
→ Canary
→ Monitor
→ Release / Rollback

比如 Coding Agent 发现：

“某类 Repo 修复前先运行特定 Test。”

如果只是某次偶然，不能升级。

只有多次任务证明：

  • 稳定有效； -触发条件清楚； -没有严重副作用；

才适合成为 Skill。

高分亮点句 ​

成功一次是经验，稳定复用并可验证，才有资格变成 Skill。

面试官真正想听什么 ​

  • 是否会自动把 Reflection 变生产行为；
  • 是否理解 Skill Release。

典型追问 ​

  1. Skill 的 Trigger 怎么 Eval？
  2. Skill 需要人工 Review 吗？
  3. Skill 与 Workflow 什么时候互相替代？

Red Flags ​

  • “Agent 每次失败后自动修改 Skill，下次立即生效。”

为什么这样回答 / 本题套路 ​

这是学习发布题。核心是“候选 ≠ 正式能力”，要像软件发布一样建立 Release Boundary。

2.10 Q10｜Skill（技能）从 20 个增长到 500 个以后，Discovery（发现）、Trigger（触发）、Lazy Loading（按需加载）怎么治理？ ​

复习优先级：P1｜题型：S4 Architecture Evolution

30 秒核心回答 ​

Skill Explosion 和 Tool Explosion 很像。

不能把 500 个 Skill 全量塞进 Context，而应该：

text
Metadata Index
→ Discovery
→ Applicability Filter
→ Lazy Load
→ Execute

2～3 分钟高分回答 ​

Skill Registry 里至少维护：

text
name
description
domain
owner
version
trigger metadata
required tools
risk
permission
status

Agent 首先只看到较轻量 Metadata。

匹配后再加载完整 Skill。

Microsoft 当前 Agent Skills 采用四阶段 Progressive Disclosure：

text
Advertise
→ Load
→ Read Resource
→ Run Script

并明确建议完整 Skill 只在任务匹配时加载。[R1]

OpenAI Agents SDK 当前也提供 Skills Capability 与 LazySkillSource，可按运行时 / Workspace Scope 挂载和按需发现 Skill。[R2]

指标 ​

text
Discovery Recall
Wrong Trigger Rate
Load Rate
Conflict Rate
Metadata Token
Cache Stale

高分亮点句 ​

Skill Registry 要解决的不只是“存技能”，更重要的是“什么时候不应该加载某个 Skill”。

面试官真正想听什么 ​

  • 是否理解 Skill Explosion；
  • 是否会做 Trigger Eval；
  • 是否知道 Progressive Disclosure。

典型追问 ​

  1. 两个 Skill 同时匹配怎么办？
  2. Skill Cache 怎么失效？
  3. Skill Description 谁维护？

Red Flags ​

  • “所有 Skill 直接加进 System Prompt。”

为什么这样回答 / 本题套路 ​

这是 Scale 题。和 Tool Explosion 类似，但重点从 Action Selection 变成 Procedure Selection。

2.11 Q11｜Memory / Skill 的收益怎样做 Ablation，证明不是模型本身变强？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我会固定：

text
Model
Prompt
Tool
Runtime
Eval Set

只切：

text
Memory / Skill Policy

通过 Ablation（消融实验）和 Counterfactual（反事实测试）做因果归因。

2～3 分钟高分回答 ​

最基本：

text
No Memory
vs
Memory

No Skill
vs
Skill

Skill v1
vs
Skill v2

看：

  • Task Success；
  • Human Correction；
  • Token / Tool Cost；
  • Latency；
  • Trigger Precision；
  • Failure Mix。

还要构造反事实：

text
Stale Memory
Wrong Memory
Poisoned Memory
Missing Memory
Wrong Skill Trigger
Old Skill Version

看系统是否：

  • 能拒绝错误写入；
  • 能选择正确版本；
  • 能 Forget / Correct；
  • 能 Rollback。

LangGraph / LangMem 当前也区分 Short-term / Long-term Memory，以及 Semantic / Episodic / Procedural Memory，说明 Memory 质量不能只看“召回到多少历史”，而要看它对未来任务有没有实际帮助。[R3][R4]

高分亮点句 ​

Learning ROI 不是“记住多少”，而是未来任务在同等模型能力下到底改善多少。

面试官真正想听什么 ​

  • 是否会做因果实验；
  • 是否能避免把 Model Upgrade 误归因给 Memory。

典型追问 ​

  1. Forgetting 怎么 Eval？
  2. Memory 太多导致效果变差怎么办？
  3. Skill Trigger Precision 怎么测？

Red Flags ​

  • “上线 Memory 后总体成功率涨了，所以 Memory 有效。”

为什么这样回答 / 本题套路 ​

这是 Experimentation 题。要控制变量并加入负面 / 过期 / 投毒反事实，不只做正向 Benchmark。

2.12 Q12｜Memory Control Plane、Skill Registry、Learning Release Pipeline 分别应该统一什么？ ​

复习优先级：P2｜题型：S6 Engineering Implementation

30 秒核心回答 ​

三个层次分别治理：

text
Memory
→ 过去哪些信息能长期影响未来

Skill
→ 哪些程序性方法可被发现和调用

Learning Release
→ 新经验怎样经过 Eval / Review 安全进入生产

平台统一的是 Contract 和治理，不是所有业务内容。

2～3 分钟高分回答 ​

Memory Control Plane

text
Write Policy
Scope
Authority
Retention
Correction
Delete
Audit

Skill Registry

text
Discovery
Version
Owner
Permission
Trigger
Dependency
Deprecation

Learning Release Pipeline

text
Candidate
→ Eval
→ Security Review
→ Canary
→ Release
→ Monitor
→ Rollback

Domain 仍然拥有：

  • Memory Meaning；
  • Skill Content；
  • Verification Criteria。

平台不应该统一：

“所有 Agent 应该记什么、学什么。”

高分亮点句 ​

平台统一“学习怎样被治理”，不统一“业务应该学什么”。

面试官真正想听什么 ​

  • 是否理解平台 / Domain Ownership；
  • 是否有 Continuous Learning Governance。

典型追问 ​

  1. Shared Org Memory 谁负责？
  2. Learning Policy 如何版本化？
  3. Skill Rollback 影响正在运行的 Run 吗？

Red Flags ​

  • “平台自动从所有 Run 学习并更新全部 Agent。”

为什么这样回答 / 本题套路 ​

这是平台边界题。P8 高分点是把长期学习从“模型能力”提升成治理 / 发布系统。

2.13 Q13｜单用户 Memory → 团队 Shared Memory → 组织级 Learning 后，什么会先坏？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

最先坏的通常不是存储容量，而是：

text
Scope
Authority
Conflict
Permission
Version
Blast Radius

共享范围越大，错误传播越快，所以治理强度必须同步上升。

2～3 分钟高分回答 ​

单用户

简单 Profile / Collection 就能工作。

团队 Shared Memory

开始出现：

  • 谁能写；
  • Concurrent Update；
  • 同一事实冲突；
  • 谁负责纠错。

需要：

text
Namespace
ACL
Version
CAS / Consolidator

组织级

进一步出现：

  • Tenant / Org Scope；
  • Authority Model；
  • Lineage；
  • Audit；
  • Release；
  • Retention；
  • Data Residency；
  • Cross-agent Error Propagation。

所以 Architecture Evolution 是：

text
Local Memory
→ Governed Shared Memory
→ Skill / Learning Release
→ Organization Knowledge Governance

高分亮点句 ​

共享范围越大，Memory 就越不像“记忆功能”，越像企业数据治理系统。

面试官真正想听什么 ​

  • 是否能从 Personal Assistant 视角升级到 Enterprise；
  • 是否理解共享错误的 Blast Radius。

典型追问 ​

  1. Org Memory 和 Knowledge Base 边界是什么？
  2. Shared Memory 默认读写权限怎么设计？
  3. 什么时候干脆不要 Shared Memory？

Red Flags ​

  • “用户级 Memory 方案直接加 tenant_id 就能组织级复用。”

为什么这样回答 / 本题套路 ​

这是架构演进题。要突出问题从 Retrieval Scale 转为 Governance Scale。

2.14 Memory / Skill 阶段性总结 ​

真正要记住的主线：

text
Run / Feedback
→ Candidate
→ Governed Memory
→ Retrieval / Revalidation
→ Correction / Forgetting
→ Candidate Skill
→ Eval / Review / Release
→ Future Run

只记五句话：

  1. Memory Write 是第一次 Semantic Promotion。
  2. Persistence 会把局部错误放大成时间维度的系统性错误。
  3. Feedback ≠ Learning Signal。
  4. Memory → Skill 是第二次 Semantic Promotion。
  5. 企业 Continuous Learning 的本质是 Knowledge Governance + Release Governance。

三、Multi-Agent 多智能体与 Workflow Orchestration 工作流编排 ​

3.1 Q14｜什么时候应该使用 Multi-Agent？为什么 Multi-Agent 不是系统成熟度等级？ ​

复习优先级：P0｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我的默认选择是：

先 Single Agent，只有拆分收益明确大于协调成本时才用 Multi-Agent。

真正合理的拆分 Trigger 通常只有：

text
Context
Capability
Permission
Parallelism
Model Specialization
Ownership
Failure Containment

不是因为角色多、流程长，就一定要拆多个 Agent。

2～3 分钟高分回答 ​

我会先问：

单一决策边界哪里开始失效？

如果一个 Agent 已经能在同一 Context、同一权限、同一 Workspace 下稳定完成，就没有必要拆。

值得拆的典型情况：

Context Isolation

Research Worker 各自搜索不同方向，避免主 Context 被大量原始资料淹没。

Permission Isolation

Review Agent 只读；Coding Agent 可写 Workspace；Deploy Agent 才有高风险发布权限。

Parallelism

多个真正独立子任务可以同时执行。

Specialization

不同模型 / Tool / Domain 的专业化收益明显。

Ownership

跨服务 / 跨团队边界需要独立 Agent Service。

但是拆完会新增：

text
Delegation
Context Duplication
Coordination
Merge
Partial Failure
Error Propagation
Runtime Cost

所以我会用一个概念式判断：

text
Multi-Agent Net Benefit
=
Parallelism / Isolation / Specialization Gain
-
Coordination / Duplication / Merge / Runtime Cost

真实项目怎么带 ​

研发 AI Workflow 很适合讲：

“我们不是因为研发流程里有开发、测试、Review 三种角色就拆三个 Agent，而是看它们是否真的有独立 Context、Permission、Workspace 或并行收益。”

高分亮点句 ​

Multi-Agent 不是从 Single Agent ‘升级’来的，而是从真实边界问题里拆出来的。

面试官真正想听什么 ​

  • 是否为了 Multi-Agent 而 Multi-Agent；
  • 是否理解 Coordination Cost；
  • 是否会从 Trigger 推导拆分。

典型追问 ​

  1. 强模型越来越强后 Multi-Agent 会变少吗？
  2. 什么时候 Workflow 比 Multi-Agent 更合适？
  3. 如何证明拆 Agent 值得？

Red Flags ​

  • “Agent 越多越专业。”
  • “高级系统最终都会走 Multi-Agent。”

为什么这样回答 / 本题套路 ​

这是总判断题。必须先给默认偏好 Single Agent，再明确拆分理由和成本，避免把 Multi-Agent 当成熟度。

3.2 Q15｜Agent as Tool、Handoff、Router、Supervisor、Workflow 分别适合什么控制权模型？ ​

复习优先级：P0｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我主要看：

下一步控制权到底在谁手里。

text
Agent as Tool
→ Parent 保留控制权

Handoff
→ 控制权转给 Specialist

Router
→ 一次性分流

Supervisor
→ 持续协调多个 Worker

Workflow
→ 系统代码主导控制流

2～3 分钟高分回答 ​

Agent as Tool

适合：

  • 子任务边界明确；
  • Parent 还要负责最终回答；
  • 需要统一 Guardrail / Budget / Merge。

OpenAI Agents SDK 当前明确区分 Agents as Tools 与 Handoffs：前者 Manager 保留对话和最终结果控制权，后者 Specialist 接管后续控制。[R5]

Handoff

适合：

  • 责任主体真正变化；
  • Specialist 后续直接负责用户交互。

Router

通常只做：

text
classify
→ route once

不持续管理全过程。

Supervisor

适合：

  • 多 Worker；
  • 需要动态分配；
  • 需要汇总结果。

但风险是 Supervisor 变成 Context / Coordination Bottleneck。

Workflow

适合确定性结构，比如：

text
需求
→ 编码
→ CI
→ Review
→ Approval

其中某些 Decision Node 再调用 Agent。

高分亮点句 ​

多 Agent 模式的本质差异，不是角色名字，而是谁拥有下一步控制权。

面试官真正想听什么 ​

  • 是否能区分 Handoff / Agent-as-Tool；
  • 是否会把所有编排都叫 Supervisor。

典型追问 ​

  1. Handoff 可以再 Handoff 吗？
  2. Router 和 Supervisor 的边界？
  3. 一个 Workflow 里可以有多个 Agent 吗？
  4. 为什么不全用 Agent as Tool？

Red Flags ​

  • “这些模式只是不同 Prompt 写法。”
  • “Handoff 和 Agent as Tool 没区别。”

为什么这样回答 / 本题套路 ​

这是模式边界题。用 Control Ownership 作为统一坐标系，比按框架 API 背诵更稳定。

3.3 Q16｜Delegation Contract 应该包含哪些内容？为什么不能只说“你去帮我查一下”？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

Subagent 不是另一个 Chat，而是一个受控计算单元。

委托至少要明确五类边界：

text
Task
Context
Capability / Permission
Budget
Completion

否则 Worker 很容易重复工作、越权或交付不可合并的结果。

2～3 分钟高分回答 ​

一个 Delegation Contract 可以表达：

text
task_id
goal
input_refs
context_scope
allowed_tools
resource_scope
budget
deadline
expected_output_schema
verification
return_evidence
failure_policy

例如不要只说：

“研究一下这个问题。”

而应该说：

“只研究 2025～2026 的汽车芯片供给，排除 GPU，输出 5 条 Finding，每条带 Source、Date、Confidence，不访问内部客户数据，预算 10 次 Search。”

这样 Parent / Worker 对：

  • 负责什么；
  • 能看什么；
  • 能做什么；
  • 花多少资源；
  • 什么算完成；

都有共同语义。

项目映射 ​

研发 Agent：

Review Agent 的 Delegation 可以明确：

text
只读
只检查支付模块并发问题
输出 finding + file + line + evidence
不修改代码

高分亮点句 ​

Delegation 的本质不是“把任务交出去”，而是把边界一起交出去。

面试官真正想听什么 ​

  • 是否把 Subagent 当受治理单元；
  • 是否理解权限 / Budget / Completion。

典型追问 ​

  1. Contract 谁生成？
  2. Worker 能修改 Task Scope 吗？
  3. Parent 如何验证 Completion？

Red Flags ​

  • “给 Worker 一段自然语言说明就行。”
  • “Subagent 默认继承 Parent 全部 Tool。”

为什么这样回答 / 本题套路 ​

这是工程契约题。重点不是字段清单，而是五类边界。

3.4 Q17｜Context Isolation 为什么既是 Multi-Agent 的收益，也是协调成本来源？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

Context Isolation 的收益是：

每个 Worker 只看到自己真正需要的信息。

但隔离以后，Worker 之间共享事实就必须通过显式 Contract / Artifact 传递，否则会出现信息丢失、重复搜索和错误传话。

2～3 分钟高分回答 ​

收益：

  • 主 Agent Context 不被原始细节污染；
  • Worker Prompt 更聚焦；
  • Tool / Permission 可独立；
  • Failure 可隔离。

成本：

  • Parent 不知道 Worker 中间状态；
  • Worker 可能重复读取同一 Source；
  • 结果需要 Serialize / Merge；
  • Context 在多个 Worker 之间复制，Token 成本增加。

Anthropic 的 Multi-Agent Research 公开复盘里就提到：并行 Agent 对开放式 Research 有 Coverage / Parallelism 收益，但也需要控制 Delegation、重复搜索、工具设计和协调成本。[R6]

所以我更倾向：

Shared Artifact > Shared Chat。

Worker 返回：

text
claim
evidence
source
confidence
open_questions

而不是把整段聊天 History 全部交给 Supervisor。

高分亮点句 ​

Context Isolation 减少单个 Agent 的噪声，但会把复杂度转移到信息交换和 Merge。

面试官真正想听什么 ​

  • 是否只看到“子 Agent 更专注”的好处；
  • 是否理解 Context Duplication / Merge Cost。

典型追问 ​

  1. Parent 应该给 Worker 多少 Context？
  2. Worker 结果是否重新塞回主 Context？
  3. Shared Memory 能不能替代 Artifact？

Red Flags ​

  • “每个 Worker 都复制 Parent 全量 Context。”
  • “所有 Agent 共享同一聊天记录最简单。”

为什么这样回答 / 本题套路 ​

这是 Trade-off 题。高分点是说明收益和复杂度转移，而不是只夸 Context Isolation。

3.5 Q18｜8 个 Research Worker 并行后重复搜索、成本暴涨但 Coverage 没提升，怎么治理？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

这不是“模型不够聪明”，而是 Task Partition（任务划分）失败。

我会治理：

text
Unique Scope
Exclusion
Shared Coverage Map
Worker Budget
Dedup
Early Stop
Dynamic Fan-out

2～3 分钟高分回答 ​

先看 Supervisor 的 Delegation。

如果 8 个 Worker 都拿到：

“研究 AI Agent 市场。”

重复搜索几乎必然发生。

更好的委托：

text
Worker A
→ Enterprise Agent Platform

Worker B
→ Coding Agent

Worker C
→ Data Agent

Worker D
→ Agent Security

再明确：

  • 时间范围；
  • Source 类型；
  • 排除项；
  • Evidence Format。

运行时还要记录：

text
Unique Source Coverage
Duplicate Query Rate
Worker Contribution
Cost per Useful Finding

如果新增 Worker 已经没有边际 Coverage 增益，应停止 Fan-out。

高分亮点句 ​

并行度不是越高越好，真正应该扩的是独立信息增益，而不是 Agent 数量。

面试官真正想听什么 ​

  • 是否理解重复工作；
  • 是否有 Coordination Economics；
  • 是否能动态控制 Fan-out。

典型追问 ​

  1. Coverage Map 谁维护？
  2. Worker 会不会需要互相通信？
  3. 如何衡量边际收益？

Red Flags ​

  • “多开几个 Agent，总能搜得更全。”

为什么这样回答 / 本题套路 ​

这是生产事故题。先归因 Delegation / Task Partition，而不是直接换模型或加 Prompt。

3.6 Q19｜两个 Coding Worker 同时改同一文件，为什么任务看起来不同仍会冲突？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

并行边界应该按：

Resource Ownership。

而不是按自然语言任务名称。

两个语义不同的任务可能都修改同一文件、同一依赖、同一 DB Row。

2～3 分钟高分回答 ​

例如：

text
Worker A
→ 修改 login retry

Worker B
→ 修改 token refresh

两个任务都可能改：

text
auth.ts
package.json
shared config

所以：

text
Task Independence
≠
Resource Independence

我更倾向：

text
Independent Worktree / Workspace
→ File / Module Ownership
→ Test
→ Merge Queue
→ Integration Verification

如果两个 Worker 必须写同一个资源：

  • Serial Critical Section；
  • Explicit Lock；
  • 或重新拆任务。

项目映射 ​

这和你的研发 AI Workflow 很贴：

多 Coding Agent 并行真正的瓶颈不是“模型会不会写代码”，而是 Workspace / Branch / Merge / Dependency Ownership。

高分亮点句 ​

真正可并行的不是“任务描述”，而是资源冲突图。

面试官真正想听什么 ​

  • 是否有 Workspace / Merge 生产经验；
  • 是否把并行理解成开更多 Agent。

典型追问 ​

  1. 文件不冲突但逻辑冲突怎么办？
  2. Merge 后谁负责 Integration Test？
  3. Agent 能动态申请 Ownership 吗？

Red Flags ​

  • “每个 Agent 一个 Branch 就完全不会冲突。”

为什么这样回答 / 本题套路 ​

这是资源冲突题。关键是把并行问题从 Prompt 层拉回资源 Ownership。

3.7 Q20｜Subagent 为什么不能默认继承 Parent 的全量权限和 Tool Surface？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Delegation 应该缩小权限，而不是复制权限。

默认原则：

text
Child Permission
=
Parent Permission
∩
Task Required Permission

2～3 分钟高分回答 ​

Parent 可能拥有：

text
Web
Repo Write
Deploy
Production DB
Customer Data

但 Research Worker 只需要：

text
Web Read

如果默认全继承，拆 Agent 反而扩大攻击面。

真正的 Delegation Contract 应携带：

text
allowed_tools
resource_scope
data_scope
network_scope
budget

研发 Agent：

  • Review Agent → Read-only；
  • Coding Worker → 只写自己的 Worktree；
  • Deploy Agent → 只有经过 Gate 才拿发布权限。

高分亮点句 ​

Subagent 是一个新的信任边界，不是 Parent 的影子进程。

面试官真正想听什么 ​

  • 是否理解 Permission Compartmentalization；
  • 是否会最小权限委托。

典型追问 ​

  1. Parent 能否动态提权 Worker？
  2. Tool Visibility 和 Authorization 谁先？
  3. Child 调另一个 Child 怎么算权限？

Red Flags ​

  • “Parent 有权限，Child 当然也有。”

为什么这样回答 / 本题套路 ​

这是安全边界题。用权限交集表达最清楚，也能自然连接 03 Execution / Identity。

3.8 Q21｜Handoff A↔B 形成死循环、Fan-out 递归膨胀，系统应该有哪些预算和终止机制？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

Multi-Agent 必须有图级 Budget，不能只靠单 Agent max_turns。

至少限制：

text
max_handoff_depth
max_total_agents
max_fanout
max_tokens
max_wall_time
max_tool_calls

并检测 No-progress / Repeated Delegation。

2～3 分钟高分回答 ​

Handoff Loop：

text
A → B → A → B

每个 Agent 单独看都“合理”，但系统整体没有进展。

要记录：

text
handoff_graph
visited_agents
task_signature
evidence_delta
progress_state

Fan-out 同样：

text
Parent
→ 5 workers
→ each creates 5
→ 25
→ 125

所以 Fan-out Count 必须是 Budget Variable，不允许模型无限递归。

触发阈值后：

text
Re-plan
Escalate to Parent
Ask Human
Stop

高分亮点句 ​

Multi-Agent 需要的是全局 Coordination Budget，不是每个 Agent 各自“自律”。

面试官真正想听什么 ​

  • 是否考虑 Handoff Loop；
  • 是否有全局预算；
  • 是否有 Progress Detection。

典型追问 ​

  1. Task Signature 怎么做？
  2. Handoff Graph 需要持久化吗？
  3. 哪些任务允许动态 Fan-out？

Red Flags ​

  • “每个 Agent max_turns=10 就够了。”

为什么这样回答 / 本题套路 ​

这是 Loop Control 题。把局部 Agent Budget 升级成全局图级 Budget，是 P7/P8 的关键视角。

3.9 Q22｜Worker Result 为什么应该是 Claim / Artifact，而不是自动成为 Global Truth？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为 Worker 本身仍是非确定性的 Agent。

它的输出应该先被视为：

Claim（主张）+ Evidence。

只有经过 Parent / Verifier 接受后，才有资格升级成 Shared Truth。

2～3 分钟高分回答 ​

典型事故：

text
Worker A
→ “Service X 是根因”

Supervisor
→ 直接当成事实

Worker B / C
→ 围绕 X 继续分析

最终整个系统跑偏

正确链路：

text
Worker Result
→ claim
→ evidence
→ confidence / provenance
→ Parent / Verifier
→ accepted_fact

Research 场景看 Source；

Coding 场景看 Test / Diff；

Diagnosis 场景看 Log / Metric / Trace。

高分亮点句 ​

多个 Agent 的共识不是事实，Evidence 才有机会把 Claim 升级成事实。

面试官真正想听什么 ​

  • 是否理解错误传播；
  • 是否会让 Supervisor 自动相信 Worker。

典型追问 ​

  1. 多 Worker 投票有用吗？
  2. Verifier 也是 LLM 怎么办？
  3. Shared Memory 能否直接接 Worker Result？

Red Flags ​

  • “三个 Agent 都同意就算正确。”

为什么这样回答 / 本题套路 ​

这是 Verification / Trust 题。核心是定义 Semantic Promotion：Worker Text → Claim → Verified Fact。

3.10 Q23｜Merge / Aggregation 本身为什么需要 Contract 和 Verification？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

Merge 不是简单拼文本。

它要定义：

text
Input Schema
Dedup
Conflict Rule
Completeness
Ordering
Evidence
Output Contract

否则 Worker 都正确，最终 Merge 仍可能错误。

2～3 分钟高分回答 ​

Research Workers 返回：

  • 重复公司； -不同别名； -相互冲突数据； -不同时间版本； -不同 Evidence Quality。

Aggregation 要做：

text
Entity Resolution
Dedup
Conflict Handling
Evidence Selection
Completeness Check

Coding 场景更明显：

text
Worker A patch
+
Worker B patch

单独测试都通过，Merge 后仍可能失败。

所以：

text
Worker Success
≠
System Success

最终还需要 Integration Verification。

高分亮点句 ​

Multi-Agent 的最后一个 Agent 往往不是“总结者”，而是一个真正的 Integration Stage。

面试官真正想听什么 ​

  • 是否把 Merge 当文本总结；
  • 是否理解整体成功和局部成功区别。

典型追问 ​

  1. Conflict Resolver 用 LLM 吗？
  2. Partial Result 怎么聚合？
  3. Quorum 什么时候适用？

Red Flags ​

  • “让 Supervisor 把结果总结一下。”

为什么这样回答 / 本题套路 ​

这是 Aggregation Contract 题。高分点是把 Merge 从语言任务提升成系统集成 / 验证阶段。

3.11 Q24｜怎样量化 Multi-Agent Net Benefit（多智能体净收益），并给 Coordination Cost（协调成本）做归因？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

我会至少同时看：

text
Verified Success
Coverage
Latency
Token / Tool Cost
Duplicate Work
Merge Cost
Human Intervention

并且一定要拿 Single Agent 做基线。

2～3 分钟高分回答 ​

实验：

text
Single Agent
vs
2 Workers
vs
4 Workers
vs
8 Workers

固定：

text
Task Set
Model
Tool
Context Policy

看：

Quality

text
Verified Success Delta
Coverage Delta

Latency

text
max(worker_time)
+ delegation
+ coordination
+ merge

Cost

text
Parent Context
+ Delegation
+ Worker Context Duplication
+ Worker Output
+ Merge
+ Verification
+ Retry

Coordination

text
Duplicate Work Rate
Handoff Count
Merge Conflict
Worker Contribution Rate

Anthropic 的 Multi-Agent Research 也明确指出，多 Agent 对开放式研究可以带来并行探索收益，但成本、协调、重复搜索和汇总是主要工程问题。[R6]

高分亮点句 ​

Multi-Agent 的北极星不是 Agent 数量，而是单位成本下的 Verified Outcome 是否真的改善。

面试官真正想听什么 ​

  • 是否会用实验而非感觉决定 Multi-Agent；
  • 是否理解成本超线性。

典型追问 ​

  1. 成功率升 2%、成本升 5 倍值不值？
  2. 怎样归因是 Parallelism 还是模型多样性带来的收益？
  3. Tail Latency 怎么看？

Red Flags ​

  • “多 Agent 比 Single Agent 效果更好，因为探索更多。”

为什么这样回答 / 本题套路 ​

这是 Experimentation / Economics 题。控制变量 + Single Agent baseline 是核心。

3.12 Q25｜什么时候应该把 Multi-Agent 重新合并成 Single Agent？规模上升时 Coordination Topology 怎么版本化？ ​

复习优先级：P1｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

如果拆分后没有形成真正的：

text
Context
Permission
Parallelism
Specialization
Ownership

收益，就应该合并。

而且 Multi-Agent 拓扑本身也应该版本化，否则回归无法归因。

2～3 分钟高分回答 ​

应该合并的信号：

  • Worker 大量重复读取同样 Context；
  • Merge 成本高；
  • Parent 最后仍拿回全部原始信息；
  • Latency 变慢；
  • Success 没有稳定提升；
  • 权限其实完全相同。

强模型能力提升后，也可能让原来需要 Specialist 的任务重新适合 Single Agent。

如果继续保留 Multi-Agent，Run 至少要绑定：

text
topology_version
worker_count
worker_model
routing_policy
delegation_contract_version
merge_strategy
verification_policy

否则：

“新版本变差了。”

你不知道是 Worker 数、Router、Merge 还是 Model 变化。

高分亮点句 ​

架构成熟不只会“拆”，也应该会在收益消失时重新“合”。

面试官真正想听什么 ​

  • 是否敢删复杂度；
  • 是否理解 Topology 是 Release Artifact；
  • 是否会做 Architecture Ablation。

典型追问 ​

  1. 强模型升级后怎么判断是否合并？
  2. Topology Canary 怎么做？
  3. 正在运行的 Multi-Agent Run 如何升级？

Red Flags ​

  • “一旦拆成 Multi-Agent，就不会再回去。”

为什么这样回答 / 本题套路 ​

这是 Architecture Evolution 题。P8 的重要能力不是只会增加架构，而是会删除不再产生收益的复杂度。

3.13 Q26｜Skill 和 Workflow 到底什么时候用哪个？为什么 Skill 不能替代确定性 Workflow？ ​

复习优先级：P0｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我会用一句话区分：

Skill 教 Agent“怎么做”；Workflow 规定系统“必须按什么顺序做”。

如果需要模型根据上下文自适应决定步骤，用 Skill；如果需要确定性顺序、Checkpoint、审批和副作用恢复，用 Workflow。

2～3 分钟高分回答 ​

Skill 更适合：

  • focused domain task； -执行路径可以有弹性； -操作低风险或幂等； -一个 Agent 能在一次或少量 Turn 内完成。

Workflow 更适合：

  • 多步骤业务流程； -顺序必须可预测； -需要 Checkpoint / Resume； -有 Human Approval； -有非幂等副作用； -需要跨 Agent / 外部系统协调。

例如：

“如何分析一个月度报表？”

可以是 Data Analysis Skill。

但：

text
生成报表
→ 审批
→ 发给客户
→ 写归档系统

更适合 Workflow。

Microsoft 当前 Agent Skills 官方文档也明确给出类似边界：Skill 让 AI 决定如何执行；Workflow 显式定义执行路径，并在 Resilience、Side Effect、Human-in-the-loop 上更强。[R7]

项目映射 ​

研发 AI Workflow：

  • “如何做 Code Review”可以是 Skill；
  • “需求 → Coding → Test → CR → Approval → Deploy”应该是 Workflow。

高分亮点句 ​

Skill 管方法，Workflow 管控制流；需要保证步骤和副作用语义时，不要把它交给 Skill 自由发挥。

面试官真正想听什么 ​

  • 是否把 Skill 当万能 Workflow；
  • 是否理解确定性控制和模型自治的边界。

典型追问 ​

  1. 一个 Workflow 节点里能不能加载 Skill？
  2. Skill 失败后如何恢复？
  3. Skill 什么时候应该升级成 Workflow？
  4. Workflow 里什么时候还需要 Agent？

Red Flags ​

  • “Skill 就是一段 Workflow Prompt。”
  • “有 Skill 后就不需要 Workflow Engine。”

为什么这样回答 / 本题套路 ​

这是非常关键的边界题。用“谁拥有控制流”做统一坐标系，可以同时连接 Harness、Runtime 和 Multi-Agent。

3.14 Q27｜5 个 Worker 成功 4 个、1 个超时，Multi-Agent 任务到底算成功还是失败？怎样设计 Partial Failure 和 Completion Contract？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

Multi-Agent Completion 不能简单定义成：

“所有 Agent 都 Done。”

它必须由业务级 Aggregation Contract（聚合契约）决定。

不同任务可能是：

text
All Required
Quorum
Best Effort
First Successful
Top-K Evidence
Human Resolve

2～3 分钟高分回答 ​

例如 Research：

text
5 个 Source Worker
4 个成功
1 个超时

如果 Evidence Coverage 已经达到要求，可以继续生成结果。

Coding：

text
5 个模块 Worker
关键支付模块 Worker 失败

即使 4 个成功，也不能 Merge。

Approval：

text
3 个强制 Approver

通常是 All Required。

所以 Delegation / Aggregation Contract 应显式定义：

text
required_workers / required_capabilities
minimum_evidence
deadline
partial_result_policy
retry_policy
merge_policy
completion_rule

同时要处理：

text
late result
duplicate result
conflicting result
cancel remaining workers

高分亮点句 ​

Multi-Agent 的完成语义属于业务聚合层，不属于“所有 Worker 状态都变 Done”的技术状态机。

面试官真正想听什么 ​

  • 是否理解 Partial Failure 是默认情况；
  • 是否能定义业务 Completion；
  • 是否会把 Worker 状态和整体结果混在一起。

典型追问 ​

  1. 超时 Worker 后来返回怎么办？
  2. Quorum 适合 Agent 吗？
  3. Partial Result 是否要标记置信度？
  4. 什么时候应该 Cancel 剩余 Worker？

Red Flags ​

  • “只要一个 Worker 失败，整个任务失败。”
  • “只要多数 Agent 同意就成功。”

为什么这样回答 / 本题套路 ​

这是分布式系统 + 业务语义题。高分点在于把 Partial Failure 从技术状态提升成 Aggregation Contract 和业务 Completion。

3.15 Multi-Agent / Workflow 阶段性总结 ​

主线可以压缩成：

text
Single Agent
↓
确定性步骤很多
→ Workflow

出现明确独立边界
→ Agent as Tool / Specialist

独立子任务并行收益明确
→ Parallel Workers

动态控制权需要转移
→ Supervisor / Handoff

规模继续增长
→ Delegation / Budget / State / Merge / Runtime 平台化

真正只记五句话：

  1. Multi-Agent 不是成熟度，Net Benefit > 0 才值得。
  2. Agent as Tool 保留 Parent 控制权，Handoff 转移控制权。
  3. Delegation 必须同时传递 Task、Context、Permission、Budget、Completion 边界。
  4. Worker Output 是 Claim，不是 Global Truth。
  5. Shared Artifact 比 Shared Chat 更适合生产协作。

四、把 Memory / Skill 与 Multi-Agent 真正连起来 ​

4.1 两个主题为什么放在同一篇 ​

它们表面不同，但都在解决：

一个 Agent 之外的“跨边界复用”问题。

Memory / Skill：

text
跨时间复用

Multi-Agent：

text
跨决策主体复用

一旦跨边界，治理问题都会快速出现：

text
Authority
Scope
Permission
Version
Conflict
Error Propagation
Verification

4.2 Shared Memory 为什么是 Multi-Agent 的高风险点 ​

错误架构：

text
所有 Agent
↕
一个可自由读写的 Shared Memory

很容易变成：

text
Local Error
→ Shared Memory
→ Multiple Agents
→ Global Error

更稳的模式：

text
Worker
→ Claim / Artifact

Verifier / Consolidator
→ Accepted Knowledge / Memory

即：

不要让每个 Subagent 都拥有把自己的局部判断升级成组织长期事实的权力。

4.3 Skill 和 Specialist Agent 什么时候选哪个 ​

如果能力本质是：

“同一个 Agent 遇到某类任务应该知道怎么做。”

优先 Skill。

如果需要：

  • 独立 Context； -独立 Permission； -独立 Model； -独立 Service Ownership； -真正 Parallelism；

才更适合 Specialist Agent。

所以：

text
Reusable Procedure
→ Skill

Independent Decision Boundary
→ Agent

这能避免一个常见过度设计：

为每一种“技能”都创建一个 Agent。

4.4 研发 AI Workflow 的一个完整案例 ​

text
主 Agent
→ 接需求

Planning / Workflow
→ 确定任务结构

Coding Skill
→ 提供 Repo 修改方法

Coding Agent
→ 独立 Workspace 写代码

Test Workflow
→ 确定性执行测试

Review Agent
→ Read-only Finding

Diagnosis Agent
→ 如果失败，收集 Evidence

Shared Artifact
→ Diff / Test / Finding

Supervisor / Workflow
→ Merge / Approval

Release
→ Verified Result

Run Feedback
→ Candidate Memory / Skill
→ Eval / Release

这里最关键的是：

不能因为某一次 Coding Agent 成功，就自动把整个轨迹变成新 Skill；也不能因为 Worker 得出一个判断，就自动写 Shared Memory。

五、P7+～P8 面试里怎样讲好这一篇 ​

5.1 Memory 问题先谈“长期影响权”，不要先谈 Vector DB ​

低质量：

“我们 Memory 用了向量库。”

高质量：

“我会先判断这条信息有没有资格跨 Run 影响未来。只有 Scope、Authority、Freshness、Retention 都明确以后，才讨论存储和 Retrieval。”

5.2 Multi-Agent 问题先谈“拆分理由”，不要先谈拓扑图 ​

低质量：

text
Supervisor
→ Planner
→ Coder
→ Reviewer

高质量：

“我们先判断单一决策边界为什么失效。只有 Context / Permission / Parallelism 等真实边界出现后才拆 Agent。”

5.3 最值得准备的三个真实故事 ​

故事 A：Memory / Skill 演进 ​

text
重复经验
→ 是否值得记
→ 如何验证
→ 是否升级 Skill

故事 B：Multi-Agent 拆分 / 合并 ​

text
Single Agent 为什么开始失效
→ 为什么拆
→ 拆后成本
→ 如何证明值得

故事 C：错误传播 ​

text
Worker / Memory 局部错误
→ 被共享
→ 影响其他 Agent
→ 如何引入 Evidence / Gate

六、本篇 2～3 分钟总复述 ​

如果面试官让你整体讲：

“你怎么理解 Agent Memory、Skill 和 Multi-Agent？”

可以这样回答：

“我会把这几个能力都理解成‘跨边界复用’，但边界不同。Memory 是过去哪些信息值得跨 Run 继续影响未来；Skill 是哪些稳定、可验证的方法值得升级成可复用能力；Multi-Agent 是什么时候一个决策边界不够，需要拆成多个独立 Agent。

对 Memory 来说，最重要的不是存储，而是 Write Governance，因为一条局部信息被写成长 Memory 就获得了未来影响权；从 Memory 再升级成 Skill，是第二次语义升级，所以必须经过 Eval、Review、Version、Canary 和 Rollback。

对 Multi-Agent 来说，我默认 Single Agent，只有 Context、Permission、Parallelism、Specialization 或 Ownership 等边界真正出现时才拆。拆以后系统会引入 Delegation、Context Duplication、Merge、Partial Failure 和 Error Propagation，所以 Multi-Agent 不是成熟度，只有净收益为正才值得。

两者共同的企业原则是：Candidate 不等于 Published Truth，局部经验和局部 Agent 结果都必须经过 Evidence、Scope、Permission 和 Verification，才有资格扩大影响范围。”

七、业界实现证据与边界 ​

本篇引用官方实现，只用于证明这些问题已经进入生产工程，不要求背产品 Feature。

产品实现会继续变化，真正稳定的机制是：

text
Memory Write Governance
Scope / Authority / Freshness
Correction / Forgetting
Skill Release
Delegation Contract
Context / Permission Isolation
Coordination Budget
Artifact / Verification
Multi-Agent Net Benefit

八、本篇最终记忆锚点 ​

如果只记 16 句话：

  1. Session、Memory、Knowledge、Skill 是四种不同语义。
  2. Memory Write 是第一次 Semantic Promotion。
  3. Persistence 会把局部错误放大成时间维度的系统性错误。
  4. High Confidence ≠ High Authority。
  5. Memory Correction 是 Lineage 问题，不是 CRUD 问题。
  6. Memory → Skill 是第二次 Semantic Promotion。
  7. Candidate Skill ≠ Published Skill。
  8. Continuous Learning 的企业本质是 Knowledge Governance + Release Governance。
  9. Multi-Agent 不是成熟度，Net Benefit > 0 才值得。
  10. 真正合理的拆分理由是 Context / Permission / Parallelism / Specialization / Ownership 等边界。
  11. Agent as Tool 保留 Parent 控制权，Handoff 转移控制权。
  12. Delegation Contract 必须同时定义 Task / Context / Permission / Budget / Completion。
  13. Worker Output 是 Claim，不是 Global Truth。
  14. Shared Artifact > Shared Chat。
  15. Skill 管方法，Workflow 管控制流。
  16. Multi-Agent Completion 是业务级 Aggregation Contract，不是所有 Worker 都 Done。

九、本篇最容易拉开候选人差距的专家判断 ​

  1. Memory Write 是一次 Semantic Promotion：日志只是记录过去，Memory 获得了影响未来的权力。
  2. Persistence 会把一次局部错误放大成跨时间系统性错误，所以“记得更多”不是目标。
  3. Feedback ≠ Learning Signal；用户一次纠正不自动等于长期偏好。
  4. Memory → Skill 是第二次 Semantic Promotion，Blast Radius 更大，必须经过 Eval / Release / Rollback。
  5. Skill 管“怎么做”，Workflow 管“必须怎么走”；确定性副作用流程不能交给 Skill 自由发挥。
  6. Multi-Agent 的收益来自真实 Boundary，不来自角色数量；拆完后复杂度被转移到 Coordination / State / Merge。
  7. Worker Output 是 Claim，不是 Global Truth；多个 Agent 一致也不能替代 Evidence。
  8. 架构成熟不仅会拆 Agent，也应该在净收益消失时重新合并。