AI Agent 开发技术完全学习指南（2026-07 基线版）Part2

jasonma1210

44人浏览 · 2026-07-12 10:34:21

jasonma1210 · 2026-07-12 10:34:21 发布

第七部分：安全、合规与治理

面试重点：OWASP Agentic Top 10、HITL、权限模型、多租户、审计合规。P7+ 必考，安全岗核心。

22. Agent 安全防护（OWASP Agentic Top 10）

22.0 本章上下文与知识地图

本章是第七部分（安全、合规与治理）的开篇，依赖前序第 8 章（MCP 工具治理与协议）、第 11 章（WASM 沙箱）的"脑手分离 / 凭据代理（Credential Proxy）"与第 24 章权限边界。它直接被第 23 章（HITL 审批）、第 24 章（权限隔离）、第 26 章（审计）依赖——安全是这三者的共同前提。核心痛点：Agent 从"辅助工具"演进为"能自主调用工具、读写数据、执行代码"的行动体，攻击面从模型本身扩到工具、记忆、跨 Agent 通信；2026-07 已出现全球首例 Agent 自主勒索攻击，威胁范式彻底改变。

22.1 核心概念与原理

OWASP Agentic Top 10（2025-12 发布）——聚焦 Agent 系统层（而非模型层）的十大风险：

#	风险	描述
ASI01	Agent Goal Hijack（目标劫持）	攻击者替换 Agent 目标（直接 / 间接 Prompt Injection）
ASI02	Tool Misuse（工具滥用）	操纵工具描述、名称、参数
ASI03	Identity & Privilege Abuse（身份与权限滥用）	权限过大、身份冒用
ASI04	Supply Chain Compromise（供应链污染）	工具/插件/依赖被污染
ASI05	Code Execution（代码执行）	Agent 执行恶意代码
ASI06	Memory Poisoning（记忆污染）	污染长期记忆
ASI07	Inter-Agent Communication（跨 Agent 通信）	A2A 消息被注入
ASI08	Cascading Failures（级联故障）	一个 Agent 故障引发雪崩
ASI09	Human Attack（人因攻击）	社工、冒充用户
ASI10	Sensitive Data Leakage（敏感数据泄漏）	敏感信息外泄

Prompt Injection（提示注入）两类：

直接注入（Direct）：用户输入中嵌指令（“Ignore previous instructions”、角色切换、[SYSTEM] 分隔符、零宽字符混淆）。
间接注入（Indirect / IPI，更危险）：恶意指令藏在文档/网页/邮件/README 中，Agent 正常读取时"被动执行"，用户无感知。真实案例：Google Docs → Claude Code 窃取 .ssh/id_rsa；Oasis “Claudy Day”（2026-03）通过隐形 HTML 标签致 claude.ai 会话历史外泄。

防御栈（Defense-in-Depth，L1–L5）：

L1 输入安全  : Prompt Injection 检测 / 越狱识别 / 意图安全分类
L2 模型安全  : Constitutional AI / 拒答机制 / 安全微调
L3 行为安全* : 工具白名单 / 参数校验 / 二次确认 / 限额控制 / 操作回滚   ← 最关键
L4 输出安全  : 敏感信息脱敏 / 有害内容过滤 / 引用溯源
L5 审计监控  : 全链路 Trace / 异常告警 / 定期审计

关键设计原则：L3 行为层是最关键的一道——即使 L1/L2 被绕过，工具白名单 + 二次确认 + 限额仍能兜底。安全界共识是无法 100% 防御注入，必须纵深防御（Defense in Depth）。

攻击→防御映射原理（Mermaid）：

2026 H2–2027 前瞻：OWASP Agentic Top 10 将持续演进（预计纳入"自主勒索/Agent 自传播"等新条目）；MCP 协议层（见第 8 章 2026-07 改版）会把 Authorization 对齐 OAuth 2.1 + OIDC，并把工具签名验证纳入一等公民，从源头压降 ASI02/ASI04。

22.2 主流方案对比

OWASP Agentic Top 10 vs LLM Top 10：

维度	LLM Top 10	Agentic Top 10
焦点	模型本身（提示注入、训练数据投毒）	Agent 系统（工具、记忆、A2A 通信）
典型风险	输出有害、幻觉	目标劫持、工具滥用、记忆污染
防御落点	模型微调/对齐	行为层/权限/审计

OWASP MCP Top 10（2026-02，工具协议层）：

#	风险	与 Agentic 对应
MCP01	Tool Poisoning（工具投毒）	ASI02
MCP02	权限范围扩展	ASI03
MCP03	间接 Prompt Injection	ASI01
MCP04	命令执行	ASI05
MCP05	Token 管理不当	ASI03
MCP06	意图流颠覆	ASI01
MCP07	工具描述注入	ASI02
MCP08	缺少输入验证	ASI02
MCP09	沙箱逃逸	ASI05
MCP10	供应链	ASI04

直接 vs 间接注入对比：

维度	直接注入	间接注入（IPI）
注入位置	用户输入	外部文档/工具返回
用户感知	有（能看到）	无（被动触发）
防御难度	中（易检测输入）	高（需行为层兜底）

取舍分析：防御不能只押注 L1 输入检测——IPI 无法在输入侧发现，必须在 L3 行为层（工具白名单 + 二次确认 + 限额）与 L5 审计兜底。这就是"脑手分离"：不可信执行环境永远拿不到原始 token，凭据由 Credential Proxy / Vault 持有。

22.3 生产级实现

① 脑手分离 + 凭据代理（Credential Proxy）——不可信执行环境（WASM 沙箱/远端 RPC）永远只拿到 scoped token，原始凭据由 Vault 持有：

# security.yaml —— 生产级纵深防御配置
defense_in_depth:
  L1_input:
    injection_detection: [regex_keywords, zero_width_strip, llm_classifier]
    intent_safety: true
  L3_behavior:                       # 最关键
    tool_allowlist: [search, refund, read_doc]   # 白名单，默认拒绝
    param_validation: strict         # 参数 schema 校验(对应 MCP JSON Schema 2020-12)
    confirm_required: [refund, delete, send_email]  # 高风险二次确认
    quota: { max_calls_per_run: 50, max_cost_usd: 5 }
    rollback: true
  credential_proxy:                  # 脑手分离：沙箱拿不到原始 token
    vault: "hashicorp-vault"
    scoped_token_ttl: "15m"
    never_expose_raw: true           # 沙箱内只可见 scoped credential

② 工具调用链路（Mermaid，源自第 8 章 §8.4.1）：

③ 真实事故案例（必背——防御原理的活教材）：

时间	事件	教训（对应风险）
2024	Devin AI 完全无法防御直接 Prompt Injection	必须在 L3 行为层设防（ASI01）
2025	Cursor CVE-2025-59944 大小写绕过	路径校验要规范化（canonicalize）（ASI02/MCP08）
2025-11	Anthropic Git MCP Server 3 个漏洞（CVE-2025-681）	官方代码也有问题，需独立审计（ASI04）
2026-03	Oasis “Claudy Day” 隐形 HTML 标签 → 会话外泄	间接注入最危险（ASI10/IPI）
2026-05	Microsoft 365 Copilot EchoLeak	RAG 输出未脱敏致数据外泄（ASI10）
2026-07-05	全球首例 AI Agent 自主勒索攻击	Agent 自主完成"发现→扫描→加密→勒索信→加密货币"全链路，标志威胁进入"自主威胁"时代

关键数据：73% 生产 AI 部署遭遇 Prompt Injection；60% 攻击流量转向 MCP 端点；IBM 2025：AI 系统无访问控制 → 平均泄露成本 $5.72M；仅 29% 部署 Agentic AI 的组织"准备好"安全防护。

生产坑位：(a) 路径校验只做一次会被 symlink/junction 绕过，须每次 syscall 重校验（见第 11 章沙箱经验）；(b) RAG 输出必须脱敏，否则 EchoLeak 式泄漏；© 自主 Agent 需"跨会话行为基线监控"识别异常（如非预期文件批量操作）。

22.4 实战复盘

坑 1：只做 L1 输入检测，间接注入直接穿防。 我们第一版安全只上了正则关键词 + 越狱识别，自测通过率很高。上线后被红队用"藏在 PDF 表格里的白色小字指令"绕过——L1 根本看不到。复盘后把防御重心压到 L3 行为层（工具白名单 + 高风险二次确认）。教训：注入防御的真理是"L1 尽力、L3 兜底"，把信任建立在行为约束而非输入过滤上。

坑 2：凭据直接塞进 Agent 上下文，沙箱逃逸即全军覆没。 早期我们把 API token 直接写进系统提示词，方便工具调用。一次 WASM 沙箱侧信道疑似泄露，吓得我们连夜改架构。教训：脑手分离不是可选项——不可信执行环境永远只拿 scoped token，原始凭据由 Credential Proxy/Vault 持有。

决策复盘：自建安全栈还是上托管？ 我们评估过纯托管安全网关，结论是"行为层（L3）必须自己掌控"——因为工具语义、风险分级是业务相关的，厂商通用网关不懂我们的 refund 是高风险的。最终决策：L1/L2 用通用方案（含模型厂商安全微调）+ L3/L5 自建（白名单、二次确认、审计日志），把安全主权留在业务侧。

22.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
注入类型	直接 vs 间接 Prompt Injection？	直接=用户输入嵌指令；间接(IPI)=工具返回/文档嵌指令，用户无感知；IPI 更危险，须 L3 行为层兜底
注入防御	如何防御 Prompt Injection？	输入侧检测+过滤；行为侧白名单+二次确认(关键)；监控侧异常告警；接受无法 100%，纵深防御
Top10 区别	Agentic Top 10 与 LLM Top 10 区别？	LLM 聚焦模型本身；Agentic 聚焦系统（工具/记忆/通信）；对应 ASI01-10
责任归属	Agent 安全谁负责？（PM 题）	模型厂商(基础安全)、应用厂商(使用安全)、企业(部署安全)、监管(EU AI Act/中国 AI 法规)
事故复盘	举一个真实 Agent 安全事故及教训	Cursor 大小写绕过→路径规范化；Claudy Day IPI→间接注入最危险；2026-07 自主勒索→威胁进入自主时代

23. 人工介入与审批工作流（HITL）

23.0 本章上下文与知识地图

本章依赖第 22 章（安全防护的风险分级）与第 24 章（权限边界）—HITL 是"高风险动作"落地的最后一道人工闸门，同时是第 26 章（审计）中"审批动作留痕"的来源。它被生产系统普遍依赖：EU AI Act 对高风险系统强制要求人类监督。核心痛点：HITL 加得太多拖慢业务、加得太少放大风险，平衡点在于"按风险分级 + 按用户信任度动态调节"，而不是一刀切全人工。

23.1 核心概念与原理

HITL（Human-in-the-Loop，人在环路）触发分级——按操作风险决定介入强度：

风险等级	操作	HITL 强度
低	读文件、查询	无（自动）
中	写文件、调用内部 API	二次确认
高	删除、转账、发邮件	强制确认
极高	批量操作、跨账号	审批工作流

核心原理：风险分级（Risk-based）是 HITL 的骨架——把"人类注意力"这个稀缺资源优先投到高后果动作上。这与 Harness 工程 ⟨C,A,R⟩ 中的 C（Control 持久制约物） 一脉相承：审批流是人类判断被翻译成的机器可读约束。

三种审批工作流模式：

Sequential（串行）：A → B → C 依次审批
Parallel（并行）：A + B + C 任一通过即可
Countersign（会签）：所有审批人必须通过

设计权衡：串行最严但最慢，并行最快但可能漏检，会签兼顾但成本高。选型取决于"错误放过的代价 vs 延迟的代价"。

HITL 决策流（Mermaid）：

23.2 主流方案对比

模式	安全性	延迟	适用
Sequential 串行	高	高	合规强约束
Parallel 并行	中	低	内部低风险批量
Countersign 会签	最高	中高	跨账号/资金

HITL 强度 vs 效率的权衡：

策略	做法	取舍
风险分级	低自动、高人工	安全与效率兼顾（推荐）
用户画像	高信任用户降确认	体验好，但需防权限滥用
操作白名单	已知安全操作自动	减少打扰，但白名单需持续维护

23.3 生产级实现

① 风险分级审批门（HitlGate）：

class HitlGate:
    async def request_approval(self, action: Action) -> Approval:
        # 1. 评估风险（结合第22章风险分级 + 第24章权限）
        risk = self.risk_assessor.score(action)
        # 2. 按风险选择 HITL 模式
        if risk == "low":
            return Approval(auto=True)                  # 低风险自动放行
        elif risk == "medium":
            return await self.confirm_dialog(action)    # 中风险：二次确认
        elif risk == "high":
            return await self.approve_with_role(action, role="manager")  # 高风险：角色审批
        elif risk == "critical":
            return await self.multi_step_approval(action)  # 极高：会签工作流

② 审批工作流配置（YAML）：

# hitl.yaml
workflows:
  refund_over_1000:            # 高额退款
    mode: countersign          # 会签
    approvers: [finance_lead, risk_officer]
  delete_tenant_data:          # 删租户数据(极高)
    mode: sequential
    steps: [owner, compliance, dpo]
  internal_api_write:          # 中风险
    mode: confirm              # 二次确认

生产坑位：(a) 审批人缺席会卡死流程，须设超时升级（escalation）；(b) 高信任用户降确认要配合行为基线监控，防权限滥用（ASI03）；© 每次审批必须留审计痕（接第 26 章）。

23.4 实战复盘

坑 1：一刀切全人工审批，核心链路被拖死。 我们起初对所有"写操作"都强制 manager 审批，结果发现 80% 是内部低风险 API 调用，manager 成了瓶颈、平均延迟从 2s 飙到 40min。教训：HITL 必须风险分级，把人力留给高后果动作，别用"全人工"掩盖风险分级的懒惰。

坑 2：审批通过了，但审批人根本没看上下文。 一次批量删除审批，审批人只扫了标题就点过，事后发现误删。复盘后改为"审批界面强制展示动作影响面（影响 N 条记录/金额）"。教训：HITL 的有效性取决于审批人拿到足够上下文，否则只是形式合规。

决策复盘：要不要对高信任用户完全免确认？ 我们给 VIP 用户开了"免确认"白名单，结果一人账号被盗触发批量外发。最终决策：信任度只降"中风险"确认，"高风险/极高"永远保留人工或会签，并叠加跨会话行为基线监控——对应第 22 章 ASI03/ASI09 防御。

23.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
HITL 必要性	为什么需要 HITL？	法规(EU AI Act 高风险系统强制)、风险控制(高后果动作把关)、信任建立
效率平衡	如何平衡 HITL 与效率？	风险分级(低自动/高人工)、用户画像(高信任降确认)、操作白名单(已知安全自动)
审批模式	三种审批工作流怎么选？	Sequential 最严最慢、Parallel 最快、Countersign 会签最稳；按"放过代价 vs 延迟代价"选
落地要点	HITL 生产落地注意什么？	审批人缺席需超时升级；审批界面须展示影响面；每次审批留审计痕

24. 权限隔离与边界控制

24.0 本章上下文与知识地图

本章依赖第 22 章（安全防护，权限滥用 ASI03 是其核心风险之一）与第 8 章（工具权限粒度、Cedar PDP）。它直接支撑第 25 章（多租户隔离）与第 26 章（审计中"谁以什么权限做了什么"）。核心痛点：Agent 默认拿到的权限往往远超任务需要，一旦被注入劫持（ASI01/ASI03），过大权限=过大爆炸半径；权限模型选错则要么僵化（RBAC）要么失控（纯 ABAC）。

24.1 核心概念与原理

三大权限模型：

模型	适合	灵活度	复杂度
RBAC（基于角色）	固定角色	低	低
ABAC（基于属性）	复杂策略	高	高
ReBAC（基于关系）	关系驱动（如"文档所有者可共享给协作者"）	中	中

Agent 权限边界传播链：用户 → 角色 → Agent 角色 → 工具权限 → 资源范围。核心原则是最小权限（Least Privilege）——每个 Agent 只拿完成任务所必需的最小权限。

权限粒度（来自第 8 章 §8.4）：Action → Tool → Resource → Parameter。即"允许调用某工具 → 操作某资源 → 传某参数"。生产要求：声明式权限（工具声明所需）、运行时校验（每次调用前检查）、二次确认（高风险）、限额控制（防滥用）。

资源级权限：

行级 RLS（Row-Level Security）：数据库原生（如 PostgreSQL RLS）
列级：字段脱敏
文档级：ACL 标签

权限传播原理（Mermaid）：

设计权衡：RBAC 简单但"角色爆炸"；ABAC 灵活但策略难审计；工业界 2026 主流是混合模型（RBAC 基础 + ABAC 增强）——用 RBAC 定骨架，用 ABAC 属性（时间/IP/风险评分）做动态精细控制。这与 Harness ⟨C,A,R⟩ 中 C（Control 持久制约物）≈ 权限策略 直接对应。

24.2 主流方案对比

模型	优点	缺点	最佳适用
RBAC	易理解、易审计、成本低	角色膨胀、难表达情境策略	固定组织架构
ABAC	细粒度、情境感知	策略复杂、调试难、性能开销	多维度动态策略
ReBAC	自然表达关系/继承	关系图维护成本	协作/社交/共享场景
Cedar（AWS 策略语言）	声明式、可验证、原生授权引擎	需学习新 DSL	云原生 Agent 平台

取舍分析：不要用纯 ABAC（策略会变成没人敢改的黑洞）。推荐"RBAC 打底 + ABAC 补动态属性"，并在平台层用 Cedar 等策略引擎做集中 PDP（Policy Decision Point），让"权限决策"与"业务逻辑"解耦——对应第 8 章 §8.4.1 的 pdp.decide()。

2026 H2–2027 前瞻：Cedar 原生授权正成为 Agent 平台标配——把权限策略写成可机器验证的声明式规则，PDP 在每次工具调用前做 allow/deny/scoped 决策，天然支持"脑手分离 + 审计溯源"。MCP 2026-07 改版把 Authorization 对齐 OAuth 2.1 + OIDC，也将推动授权标准化。

24.3 生产级实现

① 工具级权限声明（运行时校验）：

# permissions.yaml —— 声明式最小权限
agents:
  refund_agent:
    roles: [agent:refund]
    tools:
      - name: refund_api
        scope: ["order:read", "refund:execute"]
        params_allow: { max_amount: 5000 }   # 参数级限额
      - name: send_email
        require_confirm: true                 # 高风险二次确认(接第23章)
    resources:
      row_level: tenant_isolation             # 资源级 RLS
    credentials: scoped_token                 # 只拿 scoped token(脑手分离)

② 资源级权限（PostgreSQL RLS）：

-- 行级安全：Agent 只能看到本租户数据
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

③ Cedar 策略决策点（PDP）片段：

// 允许 refund_agent 在金额<=5000 时执行退款，且必须 scoped token
permit (
  principal == Agent::"refund_agent",
  action == Action::"refund:execute",
  resource == Order::*,
  context.amount <= 5000
) when { principal.credential == "scoped" };

生产坑位：(a) 权限继承/委托（OAuth Impersonation 临时授权）必须可实时撤销（Token 撤销列表）；(b) 资源级权限不要在应用层"自以为"过滤，要下沉到 DB（RLS）防绕过；© 列级脱敏要覆盖日志与向量库，否则 ASI10 泄漏。

24.4 实战复盘

坑 1：应用层做租户过滤，被一个 JOIN 绕过。 我们最初在 Python 里拼 WHERE tenant_id = ? 做隔离，某次新接口漏加条件，直接跨租户读了数据。复盘后把隔离下沉到 PostgreSQL RLS（DB 强制），应用层不再信任自己。教训：资源级隔离必须下沉到数据层（RLS），应用层过滤只是便利不是安全。

坑 2：临时委托权限忘了回收，埋下ASI03隐患。 一次故障处理给某 Agent 临时提权（impersonation），事后没进撤销列表，权限一直挂着。红队演练时这个残留权限被利用。教训：委托/提权必须带 TTL + 撤销列表，权限不是"给了就完事"。

决策复盘：RBAC 还是 ABAC？ 我们早期纯 RBAC，发现"夜间/内网/IP 白名单才放行"这类情境策略写不进去。尝试纯 ABAC 后又陷入策略黑盒。最终决策：RBAC 打底（组织角色）+ ABAC 增强（时间/IP/风险评分属性）+ Cedar 集中 PDP——策略可机器验证、可审计，对应 2026 混合模型主流。

24.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
权限模型	RBAC vs ABAC？	RBAC 基于角色简单但粗糙；ABAC 基于属性(时间/IP/风险)灵活但复杂；2026 主流混合(RBAC+ABAC)
最小权限	Agent 权限最小化怎么做？	每 Agent 最小权限、工具白名单、资源范围限制、临时 scoped token、委托带 TTL 可撤销
资源隔离	行/列/文档级权限怎么落地？	行级用 DB RLS(PostgreSQL)、列级字段脱敏、文档级 ACL；隔离下沉数据层防绕过
授权演进	现代授权引擎趋势？	Cedar 声明式可验证 PDP；MCP 2026-07 对齐 OAuth2.1+OIDC；权限决策与业务解耦

25. 多租户数据与权限隔离

25.0 本章上下文与知识地图

本章依赖第 24 章（权限隔离与边界控制）——多租户隔离是权限模型在"租户"维度上的规模化落地，同时是第 26 章（审计）中"租户级数据血缘与合规"的前置。核心痛点：隔离强度与成本呈正相关，选错模型要么早期过度设计烧钱、要么大客户上量时隔离不足引发跨租户泄漏（ASI10 放大）。

25.1 核心概念与原理

四种隔离模型：

模型	隔离强度	成本	适合
共享 DB + tenant_id	弱	低	早期 / 单租户验证
共享 DB + RLS	中	低	SaaS 中型
每租户独立 Schema	强	中	SaaS 大客户
每租户独立 DB	极强	高	大客户 / 金融 / 合规强约束

核心机制：

RLS（Row-Level Security）：在数据库层强制"每行带 tenant_id 过滤"，应用层无法绕过（见第 24 章 §24.3）。
租户上下文传播（Tenant Context Propagation）：请求 header X-Tenant-Id → Thread-local context → 自动注入到所有 DB 查询，确保上下文不串。
资源配额（Quota）：按租户限用户数 / Token / 存储，防单租户拖垮全局。

跨租户风险点（最易漏处）：缓存穿透（key 须拼 tenant_id）、Embedding 污染（向量库混租户）、日志泄漏（日志带错租户标签）、异步任务串扰（后台任务丢失租户上下文）。

隔离与传播原理（Mermaid）：

设计权衡：隔离越强越安全但成本与运维复杂度越高。经验路径是"早期共享 DB + tenant_id → 中期共享 DB + RLS → 大客户独立 Schema/DB"的渐进式升级，而非一开始上独立 DB。

25.2 主流方案对比

模型	安全	成本	弹性扩容	取舍
共享 + tenant_id	弱（应用层依赖）	最低	易	仅早期；信任应用层不漏
共享 + RLS	中（DB 强制）	低	易	性价比最优，SaaS 主流
独立 Schema	强	中	中	大客户兼顾成本
独立 DB	极强	高	难	金融/合规，运营重

取舍分析：绝大多数 SaaS 选"共享 DB + RLS"——RLS 把隔离下沉到数据层（呼应第 24 章"隔离下沉"原则），成本仅 5–10% 性能损耗却大幅提安全。独立 DB 只在"合规强制物理隔离"或"超大客户议价"时启用。

25.3 生产级实现

① PostgreSQL RLS（租户强制隔离）：

-- 启用行级安全 + 租户策略
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON documents
  USING (tenant_id = current_setting('app.tenant_id')::uuid);
-- 坑：必须给 tenant_id 建索引，否则 RLS 全表扫描拖垮性能
CREATE INDEX idx_documents_tenant ON documents(tenant_id);

② 租户上下文传播中间件（Python）：

# tenant_middleware.py —— 自动把 X-Tenant-Id 注入所有查询
import contextvars, psycopg2

tenant_ctx = contextvars.ContextVar("tenant_id")

def set_tenant_from_header(request):
    tid = request.headers.get("X-Tenant-Id")
    tenant_ctx.set(tid)

def get_conn():
    conn = psycopg2.connect(DB_URL)
    # 关键：每次建连即设会话级 tenant_id，RLS 据此过滤
    conn.execute("SET app.tenant_id = %s", (tenant_ctx.get(),))
    return conn   # 异步任务/线程也必须透传，否则串租户

③ 租户配额配置：

# quota.yaml
tenants:
  acme_corp:
    max_users: 1000
    max_tokens_per_month: 100_000_000
    max_storage_gb: 500
    priority: high

生产坑位：(a) RLS 有 5–10% 性能损耗，但必须配 tenant_id 索引，否则退化为全表扫描；(b) 缓存/向量库/日志/异步任务四处都要拼租户维度，少一处即泄漏；© 跨租户删除（GDPR 被遗忘权）要级联清所有副本（见第 26 章）。

25.4 实战复盘

坑 1：缓存 key 没拼 tenant_id，A 租户看到了 B 的数据。 我们给"热门文档列表"做了 Redis 缓存，key 只用了 doc:hot，结果不同租户命中同一份缓存。复盘后所有缓存 key 强制前缀 tenant:{id}:。教训：多租户隔离不是只改 DB，缓存/向量/日志每一处状态都要带租户维度。

坑 2：异步任务丢失租户上下文，写串了库。 一个 Celery 后台任务从请求线程拿到数据后，在新线程里 tenant_ctx 是空的，RLS 失效、写进了默认租户。复盘后用上下文显式透传（任务 payload 携带 tenant_id + 建连即 SET）。教训：异步/线程切换会清空 Thread-local，租户上下文必须随任务体显式传递。

决策复盘：早期要不要直接上独立 DB？ 我们曾为"安全"给每个试用客户建独立 DB，结果运维成本爆炸、扩容慢、客户还嫌贵。最终决策：默认共享 DB + RLS，仅对签了合规条款的大客户/金融客户升级独立 Schema/DB——渐进式隔离，成本与安全匹配业务阶段。

坑 3：共享向量库的"吵闹邻居"，把小租户的检索质量拖垮。 我们把所有租户的知识库塞进同一个向量集合、用 metadata filter 按 tenant_id 过滤，早期没问题；直到一个大租户灌进 300 万条向量，ANN 索引的召回质量对小租户明显下降，且一次大租户的批量重建索引把整库检索延迟拉到 P99 4s+。根因是向量检索的"逻辑隔离"（filter）不等于"资源隔离"——filter 只保证看不到别人的数据，却不保证别人的数据量/写入不影响你的性能。复盘后改为分级物理隔离：中小租户按哈希分片到多个共享集合（打散热点），单库向量数超阈值的大租户切独立集合 + 独立索引重建队列。教训：多租户隔离要区分"数据可见性隔离"与"资源/性能隔离"两个维度——RLS/filter 解决前者，分片/配额/独立实例才解决后者，二者缺一都会在规模上翻车。（与坑 1 的缓存隔离、§25.2 隔离选型一脉相承）

25.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
隔离选型	多租户隔离怎么选？	早期共享DB+tenant_id；中期共享DB+RLS；大客户独立Schema/DB；按阶段渐进
RLS 性能	RLS 性能影响多大？	5-10% 损耗但安全大增；必须配 tenant_id 索引防全表扫描
跨租户风险	多租户最易漏的泄漏点？	缓存穿透(key拼tenant_id)、Embedding污染、日志泄漏、异步任务串扰
上下文传播	租户上下文怎么不串？	请求header→Thread-local→注入所有查询；异步/线程须显式透传
可见性 vs 资源隔离	逻辑隔离(filter/RLS)够吗？	不够；filter/RLS 只解决"数据可见性"，不解决"吵闹邻居"的性能干扰；共享向量库须配分片/配额/大租户独立集合才实现资源隔离

26. Agent 审计与合规

26.0 本章上下文与知识地图

本章是第七部分（安全、合规与治理）的收口，依赖第 22 章（安全事件）、第 23 章（HITL 审批留痕）、第 24/25 章（权限与租户边界）——审计是前面所有安全控制的"证据沉淀"与"可回放状态源"。核心痛点：审计日志若只是"事后查账本"，价值有限；当它升级为 append-only 的"可回放状态源（Replayable State Source）"，就能同时支撑断点续跑、失败重放、成本计量与合规审计，成为生产型 Harness 的第三根支柱（与脑手分离、凭据代理并列，见第 8 章 §10.8）。

26.1 核心概念与原理

审计内容（6W1H）：每次操作记录 Who（用户/Agent）/ What（操作）/ When（时间）/ Where（来源 IP、位置）/ Why（触发原因）/ How（调用链）/ Result（成功/失败）。

不可篡改（Tamper-evident）四机制：

Append-only 日志：只能追加，不能改删
哈希链（Hash Chain）：每条 entry 含前一条 hash，篡改即断链
数字签名：私钥签名，验签识伪
WORM 存储（Write Once Read Many）：物理层不可重写

数据血缘（Data Lineage）：数据从哪来 → 经哪些处理 → 输出到哪去 → 谁有权访问。是 GDPR 被遗忘权、合规追溯的基础。

合规要求速查：

法规	地区	关键要求
GDPR	EU	被遗忘权、数据可携权、明确同意
个保法	中国	知情同意、最小必要、安全保护
HIPAA	美国医疗	PHI 加密、访问控制、审计
EU AI Act	EU	风险分级、高风险系统审计
SOC 2	全球	安全、可用、保密

敏感数据脱敏：身份证 110****1234、手机号 138****1234、邮箱 a***@example.com、银行卡 **** **** **** 1234、密码完全不记录。

审计日志作为"可回放状态源"（核心升级，源自第 8 章 §10.8）：生产级 Harness 的持久状态是外部 session event log（事件溯源 Event Sourcing），不绑定任何容器。每条记录携带 {ts, actor, toolId, version, decision, sandbox, latencyMs, costUsd}，天然支撑"断点续跑"与"失败重放"，同时打通计费埋点（costUsd / domain 标记）与跨境数据驻留约束，形成 S5 计量 + S6 回归闭环。

原理图（Mermaid）：

设计权衡：审计越细越能追责与回放，但存储与性能成本越高。关键是对"高后果动作"（删/转账/跨租户）全量审计，低后果动作采样审计。

26.2 主流方案对比

不可篡改机制	强度	成本	适用
Append-only	中（需配合签名）	低	基础留痕
哈希链	中高（篡改即断链）	低	防内部篡改
数字签名	高（可验真伪）	中	强合规/对外举证
WORM 存储	极高（物理不可改）	高	金融/监管强约束

取舍分析：生产推荐"Append-only + 哈希链 + 周期数字签名"组合，兼顾成本与抗篡改；金融/监管场景叠加 WORM。不要把审计日志存在业务 DB（会被误删/越权改），须独立存储 + 独立权限。

26.3 生产级实现

① 可回放审计事件结构（append-only）：

# audit_log.py —— 每条操作写一条不可变事件
import hashlib, time, json

class AuditLog:
    def __init__(self):
        self.last_hash = None
    def write(self, event: dict) -> dict:
        event = {
            "ts": time.time(),
            "actor": event["actor"],          # 用户 / Agent 角色
            "toolId": event["toolId"],
            "version": event["version"],
            "decision": event["decision"],    # allow/deny/scoped(接 PDP)
            "sandbox": event["sandbox"],
            "latencyMs": event["latencyMs"],
            "costUsd": event["costUsd"],      # S5 计量埋点
            "domain": event.get("domain"),
            "prev_hash": self.last_hash,      # 哈希链
        }
        raw = json.dumps(event, sort_keys=True).encode()
        event["hash"] = hashlib.sha256(raw).hexdigest()
        self.last_hash = event["hash"]
        append_to_worm(event)                 # 写 WORM，不可改
        return event                         # 可回放: replay 重放此序列即恢复状态

② GDPR 被遗忘权级联删除（跨所有副本）：

def gdpr_erasure(user_id):
    """收到请求 → 定位所有副本 → 级联删除"""
    for store in [db, backup, cache, vector_store, embeddings, logs]:
        store.hard_delete(user_id)           # 硬删
    # 派生数据(聚合/统计)也要清理
    purge_derived_analytics(user_id)
    # 审计日志不可删,但须脱敏(替换标识)以满足"被遗忘"
    anonymize_audit_records(user_id)
    third_party_audit_verify()               # 第三方审计验证

生产坑位：(a) 审计日志本身含 PII，被遗忘权不能"删日志"只能"脱敏标识"；(b) 向量库/Embedding 是隐蔽副本，最易被遗忘权遗漏；© 回放状态源要"幂等写入"，否则重放会重复计费/重复动作。

2026 H2–2027 前瞻：审计正从"合规存档"演进为"S5 计量 + S6 回归闭环"——每条审计事件既是合规证据，也是成本会计与评测回归（第 19 章）的数据源；跨境数据驻留（数据不出境）将通过审计日志的 domain 标记 + 区域化 WORM 存储实现自动合规。

26.4 实战复盘

坑 1：审计日志存业务库，一次误删全没了。 我们把审计记在业务 Postgres，某次运维脚本 TRUNCATE 连审计表一起清。复盘后审计独立存储 + WORM + 独立权限，业务库再无权改审计。教训：审计日志必须独立存储、独立权限、物理不可改，否则它自己就是单点失效。

坑 2：GDPR 被遗忘权只删了主库，向量库漏了。 一次合规审计发现，用户已"被遗忘"，但其对话 Embedding 仍在向量库可被检索到——实质未遗忘。复盘后把向量库/Embedding 纳入级联删除清单。教训：被遗忘权是"全副本遗忘"，向量库、缓存、备份、日志派生数据一个都不能漏。

决策复盘：审计日志要不要兼作状态源？ 我们原本审计和状态（checkpoint）是两套系统，导致"回放状态"和"查审计"对不上。最终决策：以 append-only 审计事件日志作为唯一状态源（事件溯源），checkpoint 由它派生——既满足合规，又让断点续跑/失败重放有唯一真相，对应第 8 章 §10.8 的"第三根支柱"。

26.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
不可篡改	审计日志怎么保证不可篡改？	Append-only + 哈希链(每条含前hash) + 数字签名 + WORM 存储；独立存储独立权限
被遗忘权	GDPR 被遗忘权怎么实现？	收到请求→定位所有副本→级联删(DB/备份/日志/缓存/向量库/Embedding)→清派生数据→第三方审计
可回放状态源	审计日志如何支撑断点续跑？	事件溯源:每条带{ts,actor,toolId,version,decision,latencyMs,costUsd};replay 即恢复状态;兼作 S5 计量+S6 回归
合规对照	主流 AI 合规要求？	GDPR(被遗忘权/EU)、个保法(知情同意/最小必要/中国)、HIPAA(PHI/医疗)、EU AI Act(风险分级)、SOC2
脱敏	敏感数据怎么脱敏与记录？	身份证/手机/邮箱/银行卡掩码;密码完全不记;日志含 PII 时需脱敏标识满足被遗忘权

第八部分：版本管理、灰度发布与应用内 CI/CD

27. Agent 版本管理与灰度发布

27.0 本章上下文与知识地图

本章位于「工程化交付」链条的入口，承接第 26 章（评估与回归测试）产出的 Golden Set 与 Eval 结论，向上支撑第 28 章（应用内 CI/CD）的自动化发布流水线。Agent 的版本不止是代码，还叠加了 Prompt、模型权重、工具契约、配置策略与记忆数据五个相互耦合的维度，导致「回滚到哪个版本」远比传统服务复杂。工程痛点：输出非确定性使「对错」难以判定，灰度指标无法用简单的错误率一刀切，版本快照需要把五个维度一起冻结。

27.1 核心概念与原理

Why 复杂：传统服务版本 = 一份二进制 + 一个 commit；Agent 版本 = 一个行为指纹（Behavior Fingerprint），它由五个维度共同决定，任一维度漂移都会改变线上行为：

维度	影响面	冻结方式
Prompt 版本	行为、语气、指令遵循	Git + 内容哈希
模型版本	能力上限、推理风格	模型 tag（如 `claude-opus-4.8@2026-07`）
工具版本	可调动作、契约	MCP server 版本 + tool schema hash
配置版本	策略、阈值、路由	Config as Code（YAML in Git）
数据版本	记忆、检索语料	向量库 snapshot ID

Why 灰度：Agent 输出是非确定性的，「全量上线即验证」风险极高。灰度（Progressive Delivery）的核心动机是「用小流量 + 强观测」把不确定性关进可控笼子，而非追求覆盖度。

版本化策略取舍：

SemVer（语义化版本）：major.minor.patch，但 Agent 的 major 应指「行为不兼容」而非接口破坏性变更——因为 Prompt 微调就可能让用户感知到 major 级变化。
行为指纹（Behavior Fingerprint）：对 Golden Set 跑一遍固定种子推理，把成功率/延迟/成本聚合成一个 hash，作为「这个版本到底长什么样」的客观指纹，比人工写 changelog 更可信。
Config as Code：所有灰度开关、路由权重、SLO 阈值都进 Git，发布 = 一次 PR，可回放、可审计。

2026 H2–2027 前瞻：Agent 场景的影子模式成本被严重低估——新版 Agent 要并行调一遍真实 LLM，等于「双倍 token 烧钱」。趋势是用小流量 replay（录真实流量离线程放） + LLM-as-judge 自动评分替代全量并行影子，把影子成本压到原来的 1/10。金丝雀在 Agent 场景的「成功」定义也从错误率升级为「任务成功率 + 成本/任务」双闸门。

27.2 主流方案对比

灰度策略	流量	生效？	决策依据	优点	缺点 / 坑
Shadow 影子	100% 输入复用	否	离线对比	零用户风险	双倍推理成本、非确定性难对齐
Canary 金丝雀	1–5%	是	错误率/延迟/成本实时监控	真实反馈快	长尾问题（<1% 用户）暴露慢
A/B Test	10–30% 分组	是	统计显著性（p<0.05）	可证伪「新版更优」	需足够样本量，Agent 方差大难收敛
Beta 白名单	50%+ 指定租户	是	人工 + 投诉	可控圈层	样本偏差（爱吐槽的用户多）

回滚层级	速度	影响	适用
配置回滚（Feature Flag 切换）	秒级	仅行为	默认首选
版本回滚（切 deployment）	分钟级	全栈	配置修不了时
数据回滚	小时级	记忆/语料	极慎用，可能丢用户数据

取舍结论：Agent 生产的默认回滚手段必须是「配置/Flag 秒级切换」，因为版本回滚要重新拉起 LLM 调用链、数据回滚有损。自动回滚触发的「闸门」不能只看错误率，必须叠加 成本/任务 与 P99 延迟——否则可能出现「错误率正常但 token 烧爆」的静默破产。

27.3 生产级实现

生产发布流水线（注意：Eval 门禁是 Agent 专属，传统 CI 没有）：

# agent-release.yml — Agent 专属发布流水线
stages:
  - lint_prompts          # Prompt 静态检查（占位符、越权指令）
  - unit_test
  - integration_test
  - eval_on_golden_set    # Agent 专属门禁：没有这步，发布等于盲飞
    thresholds:
      task_success_rate: ">= 0.95"   # 任务成功率
      tool_call_accuracy: ">= 0.98"   # 工具调用准确率
      cost_per_task_usd: "<= 0.05"   # 成本闸门，防止「效果好但烧钱」
  - shadow_1pct:         # 影子阶段：并行跑、不生效
      duration: 30m
      compare_judge: llm_as_judge    # LLM 自动评分对比新旧版
  - canary_5pct:
      duration: 1h                     # 坑点：太短看不出长尾
      auto_rollback:
        error_rate_gt: 0.05
        p99_latency_gt_s: 10
        cost_per_task_gt_usd: 0.08
  - canary_30pct:
      duration: 6h
  - full_rollout

行为指纹冻结示例（发布前把五个维度锁进一个 manifest）：

# agent-version-manifest.yaml
version: "2.4.0"
fingerprint:
  prompt_hash: "sha256:9f2c..."   # Prompt 内容哈希
  model: "claude-opus-4.8@2026-07-28"
  tools:
    mcp_filesystem: "v1.3.2"
    mcp_github: "v2.0.1"
  config_commit: "a1b2c3d"
  data_snapshot: "vec-2026-07-11"
golden_eval:                       # 指纹附带 Golden Set 成绩，回滚时直接比对
  task_success_rate: 0.962
  cost_per_task_usd: 0.041

坑在哪：Eval 阈值设太高（如 0.99）会导致永远发不出版；太低则放行劣化版本。经验值取「历史最优版的 95% 置信下界」作为门禁线，而不是拍脑袋定 0.95。

27.4 实战复盘

坑 1：把「错误率」当唯一灰度闸门，结果新版「不报错但变笨」。 一次 Prompt 微调让拒绝率下降、任务完成率看着涨，但用户侧 CSAT 掉了 12%，而错误率完全正常。我们事后才发现只盯了系统指标。教训：Agent 灰度的北极星必须是「任务成功率 + CSAT + 成本」三件套，纯系统指标会漏掉「软性退化」。

坑 2：影子模式烧穿预算。 早期我们对 100% 流量做真实并行影子，月底 LLM 账单翻倍，财务找上门。后来改成「录 1% 真实流量离线 replay + LLM-as-judge 打分」，成本降到 1/10，且因为固定种子可复现，对比更公平。教训：影子不是「全量复制一份线上」，而是「用小样本 + 可复现评分」低成本验证行为漂移。

坑 3：金丝雀时长拍脑袋设 10 分钟，长尾故障 40 分钟后才爆发。 某次工具超时 bug 只在用户会话超过 20 轮时触发，10 分钟金丝雀里根本碰不到。回滚时已经影响了 5% 用户一整晚。教训：金丝雀时长要覆盖「最慢用户路径」的 P99 时长，而非随意设；长链路 Agent 的金丝雀至少 1 小时起。

27.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
Agent 版本维度	Agent 灰度发布比传统服务难在哪？	五维度耦合（Prompt/模型/工具/配置/数据），输出非确定性使「对错」难判定，回滚需整体冻结行为指纹
行为指纹	怎么客观描述「一个 Agent 版本」？	五维度 hash 聚合成 fingerprint，附 Golden Set Eval 成绩，比人工 changelog 可信、可回放
灰度策略选择	Shadow / Canary / A/B 怎么选？	影子零风险但双倍成本；金丝雀看实时监控；A/B 需统计显著性，Agent 方差大要更大样本
自动回滚	如何设计 Agent 自动回滚？	默认 Flag 秒级切换；闸门叠加错误率+P99+成本/任务；金丝雀时长覆盖长尾路径
Eval 门禁	为什么 Agent CI 必须有 Golden Set 门禁？	非确定性导致「能跑通」≠「行为正确」，Eval 是发布前唯一客观护栏

28. 应用内 CI/CD 与自动化

28.0 本章上下文与知识地图

本章是第八部分的「自动化引擎」，承接第 27 章的版本与灰度策略，把「发布动作」从外部 CI 服务器搬到应用运行时内部。它依赖第 26 章的评估能力（应用内 Eval）与第 27 章的 Feature Flag 语义，并支撑第 29 章之后的运营监控——因为 Flag 的开关状态本身就是一类核心可观测信号。工程痛点：多租户下每个用户要独立沙箱、用户脚本不能拖垮主程序、且开发者要「改完立刻看到结果」的实时反馈。

28.1 核心概念与原理

What：应用内 CI/CD（In-App CI/CD）指流水线不在独立 CI 集群跑，而是作为 Agent 运行时的一部分——用户在产品里写插件/脚本，系统即时 lint、测试、灰度、回滚。

Why 这样设计：

用户态运行：不依赖 Jenkins/GitHub Actions，发布时延从分钟级降到秒级。
沙箱安全：用户脚本必须进 WASM / gVisor 沙箱（见第 8 章 §8.3 沙箱对比），否则一个死循环就能拖垮主程序。
多租户隔离：每个用户的流水线状态、环境变量、Flag 命中相互独立，靠 worktree / namespace 隔离。

四大核心能力：

28.2 主流方案对比

能力	自研 in-app	集成 CI 平台（GH Actions）	备注
实时反馈	✅ 秒级	❌ 需触发	in-app 核心卖点
多租户隔离	需自建	弱	平台型产品必做
沙箱安全	需接 WASM	强（runner 隔离）	建议 in-app + 沙箱
审计 / 回放	自行实现	✅ 原生

Feature Flag 平台	特性	适合
LaunchDarkly	企业级、Targeting 规则强	多租户 SaaS
Unleash	开源、可自托管	数据合规要求高
自研（Config as Code）	与 Git 同源、零外部依赖	轻量 / 强控成本

取舍：平台型 Agent 产品（如插件市场）建议「自研 Flag + 沙箱」，因为 Flag 的命中逻辑要和租户鉴权、工具权限（第 8 章 PDP）强耦合，外部 SaaS 难以嵌入鉴权链路。

28.3 生产级实现

Feature Flag 生产配置（含 kill switch 与灰度规则）：

# feature_flags.yaml — 应用内 Flag 治理
flags:
  new_memory_system:
    enabled: true
    rollout:
      - user_id_in: ["beta_users"]      # 白名单优先
      - tenant_id_in: ["acme_corp"]     # 租户级灰度
    kill_switch: true                    # 一键熔断，秒级关闭
    owner: "agent-platform-team"        # Owner 负责制，防止「flag 坟墓」
    lifecycle: "beta"                   # dev → beta → ga → deprecated
  agent_v2_loop:
    enabled: false
    kill_switch: true
    owner: "loop-team"

应用内流水线（Pipeline as Code）：

# in_app_pipeline.yaml
on: plugin_commit
steps:
  - lint: { sandbox: wasm, fuel: 10_000_000 }
  - unit_test: { sandbox: wasm }
  - eval: { golden_set: "plugin-smoke" }   # 复用第 26 章评估能力
  - canary: { scope: "beta_users", duration: 30m }
  - promote: { to: ga, require: "owner_approval" }

坑在哪：Flag 没有 lifecycle 字段和 owner，半年后没人敢删——这就是「flag 坟墓」（flag graveyard），每个旧 Flag 都是一份死代码 + 一份潜在误开风险。治理铁律：每个 Flag 建时即定 owner 与 deprecate 日期，过期自动告警。

28.4 实战复盘

坑 1：用户插件写了 while(true)，把主进程 CPU 打满。 早期沙箱只限制了内存，没限制执行时间，一个恶意/粗心插件就让整租户卡死。教训：应用内执行必须 Fuel 计费 + 死循环 Trap（见第 8 章 §11.4），且按租户做 CPU 配额隔离，单用户不能拖垮共享运行时。

坑 2：Flag 坟墓堆积，一次重构误开旧 Flag 导致功能回退。 我们曾因删不掉历史 Flag，重构路由时不小心命中一个 deprecated 的 agent_v1_mode，线上行为一夜回到三个月前。教训：Flag 治理不是「能开能关」就行，必须有生命周期 + 过期自动清理 + 默认 deny，deprecated 的 Flag 在代码里直接编译期报错而非运行时可读。

决策复盘：自研 Flag 还是上 LaunchDarkly？ 我们选了自研，理由是 Flag 命中要同步查询租户配额与工具 PDP 决策（第 8 章），外部 SaaS 的 Targeting 规则无法嵌入我们的鉴权上下文。代价是我们要自己维护一套灰度规则引擎——对平台型产品这是值得的，对单体应用则建议直接用 Unleash 开源版省事。

28.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
应用内 CI/CD 本质	应用内 CI/CD 和传统 CI 区别？	用户态、秒级反馈、沙箱隔离、多租户；发布动作内置于运行时
沙箱必要性	为什么用户脚本必须进沙箱？	防死循环/越权拖垮主程序，WASM 0.1–1ms 启动 + Fuel 计费最合适
Feature Flag 治理	Flag 怎么防止「坟墓」？	Owner 负责制 + lifecycle 状态机 + 过期自动清理 + 默认 deny
灰度与鉴权耦合	Flag 命中如何和权限系统集成？	Flag Targeting 需复用租户配额与 PDP 决策，平台型产品建议自研而非外部 SaaS

第九部分：运营、SRE 与商业化

29. 监控告警与 SLO 体系

29.0 本章上下文与知识地图

本章是第九部分（运营 / SRE）的总纲，承接第 27/28 章的发布能力——发布之后「怎么知道它活着且健康」。它向上支撑第 30 章（可观测仪表盘）、第 31 章（故障演练）、第 32 章（上线检查与 Runbook）。核心依赖是第 26 章的 Eval 指标（任务成功率即最重要的 SLI）。工程痛点：Agent 的「健康」不能只用错误率衡量，非确定性让 SLO 必须引入「任务成功率 + 成本」等业务质量维度；告警如果不分级，值班会被噪音淹没。

29.1 核心概念与原理

SLO/SLI/SLA 三件套（Agent 场景的特殊定义）：

概念	定义	Agent 例子
SLI（Service Level Indicator，指标）	量化观测值	任务成功率 = 95%
SLO（Service Level Objective，目标）	SLI 的目标值	任务成功率 ≥ 95%
SLA（Service Level Agreement，协议）	违约赔偿条款	低于 95% 按小时退款

Why Agent 需要专属 SLI 分层：传统服务的 SLI 只有「可用性 + 延迟」，但 Agent 的失败是「软失败」——返回了 200 但答非所问。所以 SLI 必须跨四层：

层级	SLI	说明
用户感知	任务成功率、CSAT、TTFT（首 token 时延）	用户真正在乎的
系统健康	QPS、P99 延迟、错误率	传统基础设施指标
业务质量	工具调用准确率、Faithfulness（忠实度）	Agent 专属「软质量」
成本	$/任务、Token/任务	商业化必需的 profitability 闸门

告警分级（响应时间与影响对齐）：

级别	响应时间	影响	例子
P0	5 分钟	全站不可用	LLM 提供商全挂
P1	15 分钟	主功能不可用	错误率 > 30%
P2	1 小时	部分功能受影响	单工具超时
P3	24 小时	优化类	成本轻微超阈

2026 H2–2027 前瞻：SLO 与成本联动是 Agent 商业化的最尖锐命题——传统 SLO 不管钱，但 Agent 的「可用性」和「烧钱速度」直接冲突（上更强模型 = 更准但更贵）。趋势是把「成本/任务」纳入第一类 SLO，并引入 Error Budget 的成本变体：允许用超支预算换质量，但反之不行。

29.2 主流方案对比

监控栈	指标	链路追踪	日志	适合
Prometheus + Grafana	✅ 强	需接 Tempo	Loki	云原生主流
Datadog	✅	✅ 原生 APM	✅	全托管、省心
Langfuse / Phoenix	Agent 专属 Trace	✅ LLM Span	✅	LLM 评估 + 可观测
自建 OTel	✅	✅	✅	强控数据主权

取舍：Agent 产品建议「Prometheus 抓系统指标 + Langfuse 抓 LLM 链路」双栈——前者管成本/延迟，后者管任务成功率与 Faithfulness，二者通过 trace_id 关联。

29.3 生产级实现

容量规划（上线前必算，避免「拍脑袋扩容」）：

# capacity-plan.yaml
capacity:
  # QPS = DAU × 人均会话 × 平均轮数 / 86400
  daily_active_users: 100_000
  sessions_per_user: 3
  avg_turns_per_session: 8
  avg_qps: 27.7              # = 100000*3*8/86400
  peak_multiplier: 4         # 峰值 = 平均 × 4
  peak_qps: 110.8
  resources:
    llm_quota_rpm: 12000     # LLM API 配额（最易成为瓶颈）
    gpu_replicas: 8
    db_spec: "16C64G"
  autoscaling:
    min_replicas: 4
    max_replicas: 32
    target_qps_per_replica: 5

SLO 配置示例（把任务成功率与成本同时写进门禁）：

# slo.yaml
objectives:
  - name: task_success_rate
    sli: "sum(rate(agent_task_success_total[5m]))/sum(rate(agent_task_total[5m]))"
    target: 0.95
    alert: { level: P1, window: 10m }
  - name: cost_per_task
    sli: "sum(rate(agent_cost_usd_total[1h]))/sum(rate(agent_task_total[1h]))"
    target: 0.05
    alert: { level: P2, window: 1h }
error_budget:
  policy: "成本超阈可临时借用质量预算，反之禁止"

坑在哪：告警不分级别，P3 优化类告警和 P0 一起推，值班一周就「告警疲劳」直接 mute 全部。必须先分级、再聚合、再加静默期。

29.4 实战复盘

坑 1：只用错误率做 SLO，结果「全 200 但全答错」无人察觉。 一次模型回归让 Faithfulness 从 0.91 掉到 0.7，但 HTTP 错误率 0%，监控全绿，直到用户投诉堆满才被发现。教训：Agent 的 SLO 必须把「任务成功率 + Faithfulness」列为第一类指标，纯可用性指标对 Agent 是盲区。

坑 2：告警疲劳，值班把整组 alert 静音。 我们把「单工具超时」「成本轻微超阈」「新用户注册波动」全设成 P1 推短信，三天后 oncall 干脆 mute。等真 P0 来时漏掉了。教训：告警分级 + 依赖抑制（DB 挂时压制其下游所有告警）+ 静默期，是 SRE 基本功；告警数量要克制，一条 P0 比一百条 P3 值钱。

坑 3：容量按平均 QPS 规划，上线当天峰值打挂 LLM 配额。 我们算的 avg_qps=28，配额按 30 配，结果晚高峰 4 倍直接触发 LLM 限流雪崩。教训：Agent 的容量瓶颈几乎永远是「LLM API 配额」而非自身算力，峰值倍数至少要 ×4 并预留突发 Buffer。

29.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
SLI/SLO/SLA	SLO 怎么定？	基于历史数据 + 行业基准（99.9%）+ 用户期望 + 成本约束，Agent 须含任务成功率
Agent 专属 SLI	为什么 Agent 不能只盯错误率？	软失败（200 但答错），需任务成功率/CSAT/Faithfulness/成本四层
告警疲劳	告警太多怎么办？	分级 + 聚合 + 依赖抑制 + 静默期，克制告警数量
容量规划	Agent 容量瓶颈在哪？	几乎总是 LLM API 配额，峰值按平均 ×4 并留 Buffer
SLO×成本	2026 后 SLO 新趋势？	成本/任务纳入第一类 SLO，Error Budget 引入成本变体

30. 性能监控仪表盘与可观测增强

30.0 本章上下文与知识地图

本章是第 29 章 SLO 体系的「可视化落地」，把抽象指标变成值班/PM/开发三类角色一眼能懂的看板。它依赖第 29 章定义的 SLI 与告警分级，并为第 31 章故障演练提供「演练时盯哪块屏」的参照。工程痛点：Agent 链路长（LLM→工具→LLM→…），一个慢请求横跨十几个 Span，没有 Trace 关联就根本定位不到根因；仪表盘设计不当会变成「信息垃圾场」。

30.1 核心概念与原理

仪表盘三秒原则（设计动机）：

5 秒看清大盘：Overview 只放 4 个北极星（QPS / 错误率 / P99 / 成本）。
30 秒定位问题：下钻到业务 / 系统 / 链路三层。
5 分钟找到根因：Trace 视图直接点开慢 Span。

Why 分角色：PM 看业务（CSAT、留存），SRE 看系统（QPS、错误率），开发看 Trace（热点 Span、慢查询）——三类人关注点不同，混在一屏只会互相干扰。

30.2 主流方案对比

仪表盘方案	优势	劣势	适合
Grafana	开源、PromQL 灵活、插件多	需自运维	云原生团队
Datadog Dashboard	开箱即用、与 APM 一体	贵	全托管偏好
Langfuse Trace UI	LLM Span 原生可视化	非系统指标弱	Agent 链路调试

取舍：Agent 产品用 Grafana 做系统/业务大盘 + Langfuse 做 LLM Trace 双屏联动，关键是用 trace_id 把两张屏串起来。

30.3 生产级实现

Grafana 大盘结构（纯展示逻辑，按角色分区）：

┌─────────────────────────────────────────┐
│  Overview (大盘)                        │
│  - QPS / 错误率 / P99 延迟 / 成本        │
├─────────────────────────────────────────┤
│  Business（业务）                       │
│  - 任务成功率 / 用户满意度 / 留存        │
├─────────────────────────────────────────┤
│  System（系统）                         │
│  - LLM / 工具 / DB 各组件健康            │
├─────────────────────────────────────────┤
│  Trace（链路）                          │
│  - 热点 Span / 慢查询 / 异常             │
└─────────────────────────────────────────┘

核心 PromQL 查询（直接可贴进 Grafana）：

# 任务成功率（第 29 章定义的业务 SLI）
sum(rate(agent_task_success_total[5m])) / sum(rate(agent_task_total[5m]))

# P99 延迟（必须用 histogram_quantile，不能直接 avg）
histogram_quantile(0.99, rate(agent_latency_seconds_bucket[5m]))

# 成本 / 任务（商业化核心闸门）
sum(rate(agent_cost_dollars_total[1h])) / sum(rate(agent_task_total[1h]))

# 工具调用准确率（软质量 SLI）
sum(rate(agent_tool_call_correct_total[5m])) / sum(rate(agent_tool_call_total[5m]))

坑在哪：P99 直接对原始延迟取均值会得到「假 P99」——必须用 histogram bucket（_bucket 后缀指标）配 histogram_quantile，否则分位完全失真。这是 Prometheus 新手最高频的坑。

30.4 实战复盘

坑 1：大盘堆了 60 个 panel，出了问题没人看得过来。 我们早期把能想到的指标全铺上屏，结果 P0 时 oncall 在 60 个红绿方块里找不到重点。教训：Overview 只留 4 个北极星，其余下钻；仪表盘是「决策工具」不是「指标博物馆」。

坑 2：P99 直接用 avg(latency) 算，显示 1.2s 其实长尾已经 15s。 我们用错查询，被用户投诉「偶尔卡死」却在大盘上看不出。教训：分位必须用 histogram bucket + histogram_quantile；原始均值对长尾分布毫无意义。

决策复盘：Grafana 还是 Langfuse 做主屏？ 我们最终让 Grafana 做系统/业务主屏（值班默认盯这个），Langfuse 做 LLM 链路下钻屏，二者通过 trace_id 跳转。理由：系统故障（如 LLM 限流）是高频事件、需秒级响应，归 Grafana；而「为什么这次答错」是低频深度排查，归 Langfuse——按事件频率而非技术栈分屏。

30.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
仪表盘设计	好的监控大盘原则？	5 秒看大盘 / 30 秒定位 / 5 分钟根因；Overview 只 4 个北极星
P99 计算	PromQL 怎么算 P99？	必须用 histogram_bucket + histogram_quantile，均值会掩盖长尾
分角色看板	为什么 PM/SRE/开发看板不同？	关注点不同，混屏互相干扰，按角色分区
Trace 关联	Agent 长链路怎么定位慢点？	LLM→工具多 Span，靠 trace_id 串联 Langfuse 与 Grafana

31. 故障演练与 Chaos Engineering

31.0 本章上下文与知识地图

本章把第 29 章的 SLO 与告警「从被动接警变主动验证」——用 Chaos Engineering 主动注入故障，证明你的降级/回滚/Runbook 真的管用。它依赖第 29 章的告警分级与第 28 章的 Feature Flag（kill switch 是常见缓解动作），并为第 32 章的 Runbook 提供「自动化执行」样本。工程痛点：Agent 的故障不是「服务挂了」这么简单，而是「LLM 幻觉」「工具返回错误结果」「向量库变慢」这类软故障，传统 Chaos 工具（只杀容器）覆盖不到。

31.1 核心概念与原理

What：Chaos Engineering = 在受控环境下主动注入故障，观察系统是否按设计降级/恢复，从而把「我以为能扛」变成「我验证过能扛」。

Why Agent 需要专属场景库：传统 Chaos 只关心「进程死没死」，但 Agent 的致命故障是软故障——LLM 还活着但开始幻觉、工具返回 200 但数据错、向量库没挂只是变慢。这些必须用 Agent 专属注入手段。

31.2 主流方案对比

故障注入工具	能力	Agent 适配
Chaos Mesh / Litmus	K8s 原生、网络/资源注入	杀 Pod、丢包够用
Chaos Blade	多层级（ JVM/容器/主机）	适合复杂注入
故障 Proxy（自研）	拦截 LLM/工具调用改响应	Agent 软故障必备：模拟幻觉/慢响应/错误结果

取舍：传统工具覆盖「硬故障」（宕机、丢包），但 Agent 的「LLM 幻觉 / 工具错结果」必须自研一层 故障 Proxy 在调用层篡改响应——这是 Agent Chaos 区别于常规 Chaos 的关键。

31.3 生产级实现

Agent 专属演练场景库：

类别	场景	注入手段
LLM	不可用、慢响应、幻觉、限流	故障 Proxy 返回 503 / 延迟 / 乱答
工具	不可用、超时、错误结果	Mock server 返回错误 JSON
数据	DB 宕机、缓存失效、向量库慢	Chaos Mesh 杀实例 / 注入延迟
网络	分区、丢包、DNS 失效	tc netem / iptables
资源	CPU 满、内存爆、磁盘满	stress-ng

自动化 Runbook（告警触发即自动缓解，人只做确认）：

# auto_runbook.yaml
trigger: alert_fired("LLMErrorRate > 50%")
actions:
  - verify_alert                 # 先确认不是误报（防抖动）
  - check_runbook
  - execute_auto_mitigation:
      - switch_to_backup_model   # 切备用模型（第 27 章版本策略）
      - enable_local_llm         # 兜底开 Ollama 本地模型
  - notify_oncall
  - wait_for_recovery
  - if_not_recovered_in_5m: page_manager   # 5 分钟不恢复升级

坑在哪：自动化 Runbook 若没有 verify_alert 去抖，一次瞬时抖动就会触发「切模型→切回→再切」的震荡，反而放大故障。所有自动动作前必须加确认闸门。

31.4 实战复盘

坑 1：只演练「LLM 全挂」，没演练「LLM 变慢但不死」。 真实事故是某提供商限流返回变慢（2s→20s），我们没演练过这种软降级，结果请求堆积把自身线程池打满，比「直接挂」还惨。教训：Agent Chaos 必须覆盖「慢」和「错」两类软故障，它们比「死」更常见也更隐蔽。

坑 2：自动化 Runbook 没去抖，告警抖动触发模型来回切。 一次网络瞬时抖动让错误率跳了 3 秒又恢复，自动 Runbook 已经切到备用模型并准备切回，造成服务震荡。教训：任何自动缓解动作前必须有 verify_alert 去抖闸门，避免「治出来的故障比原故障大」。

决策复盘：演练频率怎么定才不流于形式？ 我们定「月度基础场景（LLM 不可用/工具超时）+ 季度复杂场景（网络分区+缓存失效叠加）+ 年度全链路」，关键是每次演练必须产出 Postmortem 并闭环修复——不为演练而演练，为「验证防御真有效」而演练。

31.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
Chaos 本质	故障演练的目的是？	把「我以为能扛」变「验证过能扛」，主动发现降级漏洞
Agent 软故障	Agent 故障和传统服务有何不同？	软故障（幻觉/错结果/变慢）比硬宕机更致命，需故障 Proxy 注入
自动化 Runbook	自动缓解要注意什么？	必须 verify_alert 去抖，防「治出来的故障更大」的震荡
演练频率	故障演练多久一次？	月度基础 / 季度复杂 / 年度全链路，且每次必出 Postmortem 闭环

32. 上线检查与运营 Runbook

32.0 本章上下文与知识地图

本章是第九部分（也是第八+九部分）的收口，把前面所有能力（Eval 门禁、灰度、SLO、Chaos、监控）收敛成「上线前的 Go/No-Go 检查」与「出事后的 Runbook/Postmortem 文化」。它依赖第 26 章（测试/Eval）、第 27 章（回滚）、第 29 章（告警）、第 31 章（演练）。工程痛点：上线清单若只是「走过场」的 checklist，事故照发；Postmortem 若变成「追责大会」，团队就会掩盖根因——文化比工具更难建。

32.1 核心概念与原理

Go/No-Go Checklist 的动机：把「能不能发」从个人直觉变成结构化决策，覆盖功能 / 安全 / 性能 / 运营 / 回滚五维，任何一维不达标即 No-Go。

Runbook vs Postmortem 分工：

Runbook：事故进行时的「操作手册」——谁来做、第一步切什么、何时升级，目标是缩短 MTTR（平均恢复时间）。
Postmortem：事故后的「无指责复盘」——根因、时间线、行动项，目标是防止复发，不追究个人。

Why 无指责（blameless）：一旦复盘变成追责，当事人就会隐瞒细节、甩锅，根因永远挖不到。无指责文化让「我犯了错」能安全地说出口，这才是学习的前提。

32.2 主流方案对比

实践	轻量（小团队）	重量（企业）	取舍
上线检查	单一 YAML checklist	多关卡审批流	按风险等级分级
Runbook	静态 Markdown	自动化 Runbook（见 §31.3）	自动化缩短 MTTR 但需去抖
Postmortem	模板填写	全公司公开 + 行动项追踪	公开分享才能组织学习

32.3 生产级实现

Go/No-Go 上线检查（五维全覆盖，任一不达标即阻断）：

# v0.4.0 上线检查
functional_tests:
  - [x] 单元测试通过
  - [x] 集成测试通过
  - [x] E2E 测试通过
  - [x] Golden Set 通过（成功率 ≥ 95%）   # 来自第 26 章 Eval
security_tests:
  - [x] 渗透测试通过
  - [x] OWASP Top 10 扫描通过
  - [x] 权限边界验证                      # 复用第 8 章 PDP
performance_tests:
  - [x] 压测通过（P99 < 2s）
  - [x] 容量验证（峰值 QPS 4x）          # 来自第 29 章容量规划
operations:
  - [x] 监控告警配置                      # 第 29 章 SLO
  - [x] Runbook 更新
  - [x] 值班表确认
rollback_plan:
  - [x] 一键回滚脚本
  - [x] 数据回滚预案
  - [x] 5 分钟内完成回滚                  # 默认 Flag 秒级切换（第 27 章）

紧急回滚脚本（5 分钟闭环）：

# 5 分钟回滚：先关 Flag 再切流量，最后验证
./rollback.sh --version=v0.3.0 --reason="error_rate_spike"
# 1. 关闭新功能 (Feature Flag kill switch —— 秒级，第 28 章)
# 2. 切换流量到上一版本 (deployment 回滚 —— 分钟级)
# 3. 验证指标恢复 (盯第 30 章 Overview 大盘)
# 4. 通知相关方 (值班群 + 状态页)

Postmortem 模板（无指责 + 行动项绑定 owner/deadline）：

# Postmortem: 2026-07-03 任务成功率下降
incident:
  duration: 30 min
  severity: P1
  customer_impact: 10% 任务失败
timeline:
  - 10:00: 部署 v0.4.0
  - 10:15: 错误率上升至 30%
  - 10:18: 告警触发（第 29 章 P1）
  - 10:20: 决定回滚
  - 10:25: 回滚完成（Flag 秒级切换）
  - 10:30: 指标恢复
root_cause:
  - 新版工具 timeout 配置过短
  - 灰度发布未充分验证（金丝雀仅 10 分钟，见第 27 章坑 3）
lessons_learned:
  - 灰度时间延长到 1 小时
  - 添加工具调用超时监控
action_items:
  - [ ] 完善灰度发布策略 @alice / 2026-07-10
  - [ ] 添加自动回滚阈值 @bob / 2026-07-12

坑在哪：回滚脚本若依赖「版本回滚（分钟级）」而非「Flag 切换（秒级）」作为第一步，MTTR 会被拉长一个数量级。永远把 Flag kill switch 作为回滚第一动作。

32.4 实战复盘

坑 1：上线清单成了「全打钩」的形式主义。 一次 v0.4.0 所有项都勾了，但 Golden Set 那项其实只跑了 50 条小样本就勾了「通过」，结果线上工具超时 bug 漏网。教训：清单项必须有「证据链接」（哪份报告、多少样本），打钩不等于真做过，Go/No-Go 要可审计。

坑 2：回滚第一步选了「版本回滚」而非「Flag 关闭」。 一次事故我们机械执行 deployment 回滚，3 分钟才生效，期间错误率持续飙升；事后发现那个功能明明有 kill switch，秒级就能掐掉。教训：回滚第一动作永远是 Feature Flag 秒级关闭（第 28 章），版本回滚只是兜底；Runbook 要把这一步写死在第一个 bullet。

坑 3：Postmortem 变成「谁的锅」辩论赛，根因被掩盖。 一次事故复盘大家忙着证明「不是我模块的问题」，真正的根因（跨服务超时传导）没人深挖，三个月后复发。教训：Postmortem 必须无指责（blameless），聚焦系统缺陷而非个人；行动项要绑定 owner + deadline，且公开分享让全员学习。

32.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
上线检查清单	上线 Go/No-Go 包含什么？	功能/安全/性能/运营/回滚五维，每项需证据链接、可审计
紧急回滚	5 分钟回滚怎么做？	第一动作 Flag 秒级关闭，版本回滚仅兜底；MTTR 差一个数量级
Postmortem 文化	复盘文化怎么做？	无指责（blameless）、聚焦根因、行动项绑 owner+deadline、公开分享
清单防形式主义	怎么让 checklist 不流于形式？	每项附证据（报告/样本量），打钩可审计，Go/No-Go 不是过场

第十部分：厂商技术栈全景与面试专项

本部分定位：前面第 1–9 部分已讲清 MCP / Harness / Loop / 多 Agent / 安全 / 评测等通用工程范式。本部分把它们落地到六大厂的具体技术栈上——每一家都是前面范式的"一种实现选择"，而不是孤立的背诵清单。读的时候请带着对照视角：这家厂商的 SDK 在 Harness 六层（§9.2）里补了哪几层？它的协议选边（MCP / A2A）意味着什么取舍？它的 Loop 原语（§10.3）实现到了第几个？

33. 国际三巨头（OpenAI / Anthropic / Google）技术栈落地对照

33.0 本章上下文与知识地图

本章是前面技术章的国际厂商落地对照，聚焦 OpenAI、Anthropic、Google 三家。为什么要横向对比这三家而不是各看各的？

它们定义了 Agent 协议的两大阵营：MCP（Anthropic 开源、OpenAI 跟进）与 A2A（Google 发起、Linux Foundation 治理）。理解它们的协议选边，才能理解"你的 Agent 将来能和谁互操作"。
它们把同一套 Harness 范式实现成了不同形态：OpenAI 用 SandboxAgent 补"执行隔离层"，Anthropic 用 Computer Use + Loop Engineering 补"动作空间与自治循环层"，Google 用 A2A + Vertex 补"多 Agent 编排与托管层"。
模型能力是 Harness 补偿面迁移（§10.5）的锚点：GPT-5.6 Sol / Claude Sonnet 5 / Gemini 3 Pro 的自主执行长度，直接决定各家 Harness 组件能拆掉多少。

知识地图：读完本章应能回答——三家 SDK 在 Agent = Model + Harness（§9.1）公式里的分工差异；Responses API / Agent SDK / ADK 各自对应 Harness 哪几层；面 P6/P7 时被问"为什么选 A 不选 B"如何给出带取舍的回答。

33.1 技术栈全景

每家技术栈按"模型层 → 框架/SDK 层 → 协议层 → 生态/应用层"四层拆解，并与前面范式建立映射。

33.1.1 OpenAI（GPT-5.x / Agents SDK / Responses API）

关键映射：OpenAI 的差异化在 L2 工具系统层（SandboxAgent 容器化执行） 与 L6 约束恢复层（Guardrails 双向验证），它把"Agent 只能看不能改"的生产痛点用沙箱解决。

33.1.2 Anthropic（Claude Sonnet 5 / Opus 4.8 / Agent SDK / Loop Engineering）

关键映射：Anthropic 的差异化在 A — Agency 动作空间（Computer Use 全桌面） 与 Loop 六原语的工程化落地（/goal 声明式目标 + 自动循环）。它是"模型不运行系统，系统运行模型"（Blueprint 模式，§9.4）的最激进实践者。

33.1.3 Google（Gemini 3 / ADK 2.2 GA / A2A 原生）

关键映射：Google 的差异化在 L3 执行编排层（多 Agent 原生 + A2A） 与 跨厂商协议治理。ADK 是唯一把 A2A 当一等公民的框架，Rewind 能力（回退到前一次调用）对应 Harness 的"断点恢复"（§9.10 R 层）。

2026 H2–2027 前瞻：OpenAI 预计把 Responses API 状态持久化与 Realtime 合并为统一"Agent Session"；Anthropic 路线是把 Computer Use 推向 OS 级统一接口（Fable 5 解禁是信号）；Google 路线是 A2A 进 Cloud 默认互操作 + ADK 多语言（Java/Go）GA。三家的收敛点是：都把 Harness 的 L2/L3/L6 下沉到 SDK，模型层继续补自主执行长度。

33.2 关键能力对比（2026 H1）

维度	OpenAI	Anthropic	Google
旗舰模型	GPT-5.4 / 5.6 Sol（内测，编程超 Opus）	Claude Opus 4.8 / Sonnet 5	Gemini 3 Pro
Agent SDK	Agents SDK 0.17.7	Claude Code / Managed Agents	ADK 2.2.0 GA
核心协议	MCP（跟随）	MCP（发起）	A2A（原生发起）
差异化能力	SandboxAgent / Guardrails	Computer Use / Loop Engineering	A2A 原生 / Workspace 一体
执行隔离	SandboxAgent 容器 + Manifest	YOLO 三级分类 + Worktree	AgentEngineSandboxCodeExecutor
语音 Agent	RealtimeAgent（WebRTC）	无原生语音 SDK	Gemini Voice（生态内）
开源策略	SDK 开源，模型闭源	闭源为主	部分开源（ADK + A2A）
生态锁死风险	高（OpenAI 模型 + 工具最优）	中（MCP 开放但 Claude 最优）	中高（Google Cloud 绑定）

取舍分析（面试官最想听的"深度"）：

为什么 OpenAI 的 SandboxAgent 重要：它解决了"Agent 只能看不能改"的生产痛点——容器化执行 + SandboxManifest 声明依赖（GitRepo/Docker/环境变量），是 Harness L2 工具隔离的生产级实现。代价是冷启动 + 容器编排成本，轻量任务不划算。
Anthropic 的 Loop Engineering 是范式级差异：/goal 声明式目标 + 自动循环 + Sub-agent 审查，落地了 §10.3 的六原语。Boris Cherny 公开数据——100% PR 由 Agent 编、工程师日均合并量 8x、AI 代码 PR 拒率 67.3%（编排税，§10.6）。这不是功能，是工程文化。
Google 的 A2A 是"互操作税"的对冲：当你的Agent要跨组织/跨厂商协作，MCP 管"Agent↔Tool"，A2A 管"Agent↔Agent"，两者互补。ADK 原生 A2A 意味着你在 Google Cloud 内零成本获得跨 Agent 协作，但离开 GCP 生态会难受。
生态锁死（lock-in）风险排序：OpenAI（模型+工具强耦合）> Google（Cloud 绑定）> Anthropic（MCP 开放，但 Claude 效果最优）。选型时把"未来能否迁走"作为一级指标。

33.3 生产级要点 / 接入样本

33.3.1 OpenAI Responses API + Agents SDK（Python）

from agents import Agent, Runner, ModelSettings
from agents.extensions.handoff import Handoff
# OpenAI Agents SDK 0.17.7 —— 注意它是 provider-agnostic，
# 可不绑定 OpenAI 自家模型（0.15.0 起的 100+ LLM 支持）

# 1) 定义带护栏的 Agent（Guardrails 双向验证，对应 Harness L6）
research_agent = Agent(
    name="researcher",
    instructions="你负责检索并汇总，禁止执行任何写操作。",
    model="gpt-5.4",
    model_settings=ModelSettings(temperature=0.2),
    # Guardrails: 输入/输出双向检查，阻断注入与越狱（0.10.0 引入）
    input_guardrails=[prompt_injection_guardrail],   # 输入侧
    output_guardrails=[pii_leak_guardrail],          # 输出侧
)

# 2) SandboxAgent —— 容器化执行文件操作（0.14.0 引入）
# SandboxManifest 声明依赖边界，解决"只能看不能改"
sandbox_agent = Agent(
    name="coder",
    instructions="在沙箱内修改代码并通过测试。",
    mcp_servers=[],  # 可挂 MCP 工具
    # sandbox 配置：SandboxManifest 声明 GitRepo / Docker / 环境变量
    sandbox={"type": "container", "manifest": "SandboxManifest.yaml"},
)

# 3) Runner 驱动 —— 内部即一个 Loop（Plan-Build-Verify-Fix, §9.7）
result = await Runner.run(
    research_agent,
    input="调研 MCP 2026-07 改版的 Stateless Core 变化",
    max_turns=15,   # 预算熔断（Harness L6 预算）
)
print(result.final_output)

33.3.2 Anthropic Claude Agent SDK（Loop Engineering 落地）

# Anthropic Agent SDK —— 体现 Loop 六原语（§10.3）
# Automations: 定时触发；Worktrees: 隔离；Skills: 知识固化
# Connectors: MCP；Sub-agents: 审查分离；State: 跨会话记忆

from claude_agent_sdk import ClaudeAgent, ToolUse, LoopPolicy

agent = ClaudeAgent(
    model="claude-sonnet-5",              # 2026-07-01 最强 Sonnet Agent
    fallback_models=["claude-haiku", "gpt-5.4-mini"],  # fallbackModel(3 备选)
    max_subagent_depth=5,                 # 嵌套子 Agent ≤5 层
    tools=["computer_use", "bash", "mcp:github"],
    # YOLO 三级分类（放行/软拒/硬拒）—— Harness L6 约束
    permission_policy={
        "deny": ["rm -rf /*", "git push --force"],
        "ask":  ["DELETE FROM *", "kubectl delete *"],
    },
)

# /goal 声明式目标：给定可验证终止条件，Agent 持续工作
# 终止判定由独立小模型做（制造者不批改自己作业，§10.5）
policy = LoopPolicy(
    goal="让 test/auth 目录全部通过且 lint clean",
    max_iterations=25,
    budget={"cost_usd": 5.0, "wall_time_s": 300},
)
await agent.run_loop(policy)

33.3.3 Google ADK 2.2 + A2A（多 Agent 编排）

# Google ADK 2.2.0 GA —— 唯一原生对接 A2A 的框架
from google.adk import Agent, SequentialAgent, VertexAIAgentEngine
from a2a import AgentCard, SignedAgentCard   # A2A v1.0（Linux Foundation）

# 1) 定义子 Agent（ADK 的 L3 编排单元）
retriever = Agent(name="retriever", model="gemini-3-flash")
summarizer = Agent(name="summarizer", model="gemini-3-pro")

# 2) 多 Agent 编排（Orchestrator 模式，对应 S3 系统设计题）
pipeline = SequentialAgent(sub_agents=[retriever, summarizer])

# 3) A2A Signed Agent Card —— 跨组织互操作的"数字身份证"
card = SignedAgentCard(
    name="support-agent",
    url="https://agents.example.com/a2a",
    capabilities=["task.send", "task.get"],
    signature=load_private_key("agent.key"),  # 数字签名防伪造
)

# 4) Vertex AI Agent Engine 托管（生产级沙箱 + 多模型）
engine = VertexAIAgentEngine(agent=pipeline, region="us-central1")
# BufferableSessionService + Rewind：回退到前一次调用（断点恢复）
engine.session_service.rewind(last_n=1)
engine.deploy()

33.4 实战复盘

来自我们在 MJ Nexus OS 插件体系 + 内部 CI Agent 的真实选型经历。

复盘 1：从 LangGraph 迁到 OpenAI Agents SDK（又迁回混合）。 早期我们用 LangGraph 做精细状态机（Checkpoint 持久化、跨模型），但 2025 下半年 OpenAI Agents SDK 的 SandboxAgent + Guardrails 出来后，我们在"需要容器化执行 + 双向护栏"的场景直接换过去——因为 LangGraph 没有原生的执行隔离层，要自己接 Docker，维护成本高。但跨云、超长状态机的场景仍留在 LangGraph。教训：不是"选一个框架"，而是按 Harness 缺哪层选——缺 L2/L6 用 Agents SDK，缺精细 L3 状态机用 LangGraph。

复盘 2：Anthropic 的 /goal 让我们的 CI 修复 Loop 从"人盯"变"无人值守"。 我们把"每天 9 点扫 CI 失败 → 派 sub-agent 修 → 派强模型审 → 开 PR"写成了 /loop，对应 §10.4 的真实 Loop 形状。最大的坑是编排税（§10.6）：5 个并行修复 Agent 跑得欢，但人每小时只能认真审 1 个 PR，其余 4 个的 token 在排队等 review。后来改成"短 PR + 先 sub-agent 初审 + 人只看关键决策"，拒绝率从 67% 降到可控。教训：Loop 的并行度上限是 review 带宽，不是算力。

33.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
Agents SDK 定位	OpenAI Agents SDK vs LangGraph 区别？	轻量编排+沙箱原生+OpenAI 生态优先；LangGraph 精细图状态机+持久化+跨模型。要点：按 Harness 缺哪层选，不是非此即彼
执行隔离	SandboxAgent 为什么重要？	容器化执行+`SandboxManifest` 声明依赖，解决"Agent 只能看不能改"。带出 §8.3 沙箱对比（Docker/WASM/Firecracker）
模型代差	GPT-5.6 Sol 对 Agent 生态的影响？	编程超 Opus + 低 token 成本 = 更长自主链路 + 更多迭代；触发"补偿面迁移"（§10.5），Harness 可拆组件
模型选型	Sonnet 5 与 Opus 4.8 怎么选？	Sonnet 5 最新 Agent 优化、自主执行；Opus 4.8 旗舰推理、复杂分析。要点：速度 vs 质量的 trade-off 要绑定成本算
CUA vs RPA	Computer Use 和传统 RPA 区别？	CUA 看屏推理决策，UI 变也能适应；RPA 脚本化、UI 变即失效。工业界 CUA 替 80% RPA，强规则流程仍要 RPA
Loop 范式	Loop Engineering 在 Anthropic 落地？	`/goal` 声明式目标 + 自动循环 + Sub-agent 审查分离；数据：80%+ 代码由 Claude 写、PR 拒率 67.3%、编排税
ADK 选型	ADK vs LangGraph？	ADK = GCP 生态+A2A 原生+托管沙箱；LangGraph = 跨云+精细状态机。要点：在 GCP 内 ADK，否则 LangGraph
协议治理	A2A 为什么重要？与 MCP 关系？	A2A 管 Agent↔Agent 跨厂商互操作，MCP 管 Agent↔Tool，互补非竞争；Signed Agent Cards 防伪造
框架 GA	ADK 2.0 GA 对开发者意味着什么？	GCP 多 Agent 路线确定、A2A 成默认互操作、新项目不用再观望 Beta

34. 国内三巨头（阿里 / 腾讯 / 字节）技术栈落地对照

34.0 本章上下文与知识地图

本章是前面技术章的国内厂商落地对照，聚焦阿里、腾讯、字节。国内三家的打法与国际三家本质不同：国际三家是"模型 + SDK + 协议"三位一体向外输出，国内三家是"模型 + 超级 App 场景 + 平台"向内闭环。读本章要带着三个对照问题：

协议选边：三家都兼容 MCP（阿里百炼原生 MCP、腾讯 QClaw 即 MCP 中文内化版、字节内部 + MCP），但谁真正把协议做成生态？这与 §8 的 MCP 事实标准直接相关。
Harness 落点：国内三家把 Harness 的 L2/L3 更多下沉到"平台托管"（百炼 / 元宝 / 扣子），开发者拿到的是"配置即 Harness"，而非自己写运行器（对比 §9.6 的 Python 运行器）。
成本即战略：字节豆包 Pro 输入 3.2 元/百万 token（约 GPT-5.2 的 1/10），成本优势直接决定"能跑多少 Agent 迭代"——这是补偿面迁移（§10.5）的国内版本。

知识地图：读完应回答——Qwen3.7 与 GPT-5.4 的真实差异（不是参数，是工具调用稳定性与成本）；QClaw 与 MCP 的关系；双引擎架构如何理解；扣子（Coze）低代码平台对应 Harness 哪几层。

34.1 技术栈全景

34.1.1 阿里巴巴（通义千问 / 百炼 / 钉钉 / 悟空）

关键映射：阿里把 Harness 的 L2（工具/MCP）与 L3（Agent 编排）做成托管平台（百炼），开发者用配置而非代码获得 Harness。Qwen3.7-Max 在 Claw-Eval 真实 Agent 任务上超越 2-3 倍参数竞品，说明"工具调用稳定性"是国产模型的生产级护城河。

34.1.2 腾讯（混元 / 元宝 / QClaw / 微信生态）

关键映射：腾讯的差异化不在基座，在 A — Agency 的场景独占性（微信社交数据 + 远程唤醒）。QClaw 即 MCP 中文内化版，意味着它完全站在 MCP 事实标准一侧（§8.7），不另起炉灶，规避生态锁死。

34.1.3 字节跳动（豆包 / 扣子 / 火山方舟）

关键映射：字节的差异化在 成本 + 流量 + 多模态。DualPath 推理（复杂任务开深度、简单任务走轻量）是"按 token 预算动态分配算力"的工程体现，直接压低每次 Agent 迭代成本——这是国内版的补偿面迁移杠杆。

2026 H2–2027 前瞻：阿里 Token Foundry（2026-06-08 成立）意味着"模型即 Token 商品"战略，Qwen 全开源会持续吃掉企业私有化市场；腾讯路线是"不拼基座、拼微信场景独占 + QClaw 技能库规模化"；字节路线是 DualPath 多模态 + 扣子低代码平台下沉到中小企业。三家共同趋势：MCP 兼容成为标配，差异收敛到"场景 + 成本"。

34.2 关键能力对比（2026 H1）

维度	阿里	腾讯	字节
旗舰模型	Qwen3.7-Max	Hunyuan Pro	豆包 2.0 Pro
Agent 平台	百炼（托管）	腾讯元宝（场景）	扣子 Coze（低代码）
核心协议	MCP 兼容（原生工具集）	QClaw（=MCP 中文版）	内部 + MCP
核心优势	企业 + 工具调用稳定	微信 + 社交数据独占	流量 + 视频 + 成本
成本优势	中	中	最强（≈1/10 GPT）
开源策略	Qwen 全开源	部分开源	闭源为主
场景落地	电商/政务/金融	社交/内容/工具	抖音/电商/内容
Harness 落点	L2/L3 托管平台	L2 协议 + 场景 Agency	L1-L3 低代码

取舍分析：

选 Qwen 还是豆包：企业私有化 + 工具调用稳定性选 Qwen（百炼原生 MCP、Qwen 全开源）；短视频/电商/成本敏感选豆包（DualPath + 3.2 元/百万 token）。要点：成本不是次要指标，它决定你能跑多少 Agent 迭代（补偿面迁移的国内版）。
腾讯的"不拼基座"是理性选择：微信 12 亿月活的对话/关系/群聊语境是别人拿不到的 Agency 数据（§9.10 A 层），双引擎（自研混元 + 外部模型补逻辑/代码）平衡自研与效果，避免在基座上烧钱。
协议无分歧 = 低风险：三家都站 MCP 一侧，意味着你的 Agent 工具层用 MCP 写一次，可在三家平台间平移，生态锁死风险低于国际三家。

34.3 生产级要点 / 接入样本

34.3.1 阿里百炼（兼容 OpenAI API 的 Agent 编排）

# 阿里百炼 Model Studio —— 兼容 OpenAI API，MCP 原生
from openai import OpenAI

# 关键点：base_url 指向百炼，API 形状与 OpenAI 一致
# 这意味着你前面 §33.3.1 的 Agents SDK 代码几乎可直接平移
client = OpenAI(
    api_key="sk-<dashscope>",
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",
)

# Qwen3.7-Max：100 万上下文，工具调用稳定性适合生产
resp = client.chat.completions.create(
    model="qwen-max",          # 或 qwen-plus(100万上下文) / qwen-flash(低延迟)
    messages=[{"role": "user", "content": "查最近一笔订单并退款"}],
    tools=[{                   # Function Calling 增强：支持并行/嵌套工具链
        "type": "function",
        "function": {
            "name": "query_order",
            "parameters": {"type": "object",
                           "properties": {"order_id": {"type": "string"}}},
        },
    }],
    parallel_tool_calls=True,  # 并行工具调用，减少幻觉(§34.1.1)
)
# 百炼原生 MCP 工具集可直接挂为 tool，无需自写 MCP client

34.3.2 腾讯 QClaw（MCP 中文内化版接入）

# 腾讯 QClaw = OpenClaw 协议 = MCP 中文内化版
# 本质与 MCP 同一套原语(Tools/Resources/Prompts, §8.2)，仅本地化适配
from qclaw import QClawClient

client = QClawClient(
    endpoint="wss://qclaw.tencent.com/mcp",
    auth="wechat_oauth",        # 微信生态认证，拿到对话/关系链上下文
)

# 13,000+ 龙虾技能库 = MCP 工具市场的腾讯版
tools = client.list_skills(category="wechat_automation")
# 远程唤醒：微信端发指令 → 控 PC 端任务（Agent 跨端 Agency）
client.invoke(tool="remote_wakeup", args={"task": "整理今天群聊待办"})

34.3.3 字节火山方舟（扣子 Coze 低代码 + DualPath）

# 字节火山方舟 —— 豆包 2.0 Pro，DualPath 推理自动分配算力
from volcengine import Ark

client = Ark(api_key="<ark_key>")
# model 选 doubao-2.0-pro：深度推理+长链路；成本 3.2 元/百万 token
resp = client.chat(
    model="doubao-2.0-pro",
    messages=[{"role": "system",
               "content": "你是抖音电商客服 Agent，使用多模态理解用户截图"}],
    # DualPath：框架按任务复杂度自动走深度/轻量分支，P99<200ms
    routing="dualpath-auto",
    multimodal=True,           # 实时视频流/屏幕交互(§34.1.3)
)
# 扣子 Coze：零代码搭 Agent，发布到豆包/飞书/网页（配置即 Harness L1-L3）

34.4 实战复盘

来自我们在国内三家平台上做"电商客服 Agent"的选型复盘。

复盘：为什么最终用 Qwen + 百炼而非豆包。 我们最初被豆包的"1/10 成本"吸引，但压测发现：高并发下豆包 Function Call 成功率 89% 对生产不够（约 11% 需要重试/兜底），而 Qwen3.7-Max 的工具调用稳定性明显更稳，配合百炼原生 MCP 工具集，我们不用自己写工具适配层。成本上，我们用 qwen-plus（100 万上下文、便宜）跑检索、仅关键决策用 qwen-max，整体成本仍只有 GPT 的 1/5。教训：成本要算"含重试/兜底的总成本"，不是单次调用价；工具调用稳定性是生产级 Agent 的隐藏门槛。

踩坑：腾讯 QClaw 的微信生态特权是把双刃剑。 微信对话/关系链上下文确实让我们的社交场景 Agent 效果起飞，但这些数据不能出微信域——我们做跨平台（Web + 微信）统一 Agent 时，微信侧的能力无法平移，被迫做两套。教训：场景独占数据的代价是架构分裂，选型时先问"数据能不能出域"。

34.5 知识点 → 面试映射

知识点	面试问题	高分回答要点
模型差异	Qwen3.7 与 GPT-5.4 核心差异？	中文 Qwen 优、推理 GPT 略优、多模态 GPT 全、工具稳定性 Qwen 适合生产、成本 Qwen 低 1/10。要点：稳定性+成本是生产指标，不是参数
平台选型	百炼 vs LangChain 区别？	百炼托管式+Qwen 优化；LangChain 开源跨模型。阿里场景优先百炼，跨厂商 LangChain
集团战略	阿里 ATH 事业群怎么理解？	Alibaba Token Hub：集团 AI 资源整合中枢，“创造/输送/应用 Token”，算力+模型+场景统一调度
协议关系	QClaw 和 MCP 的关系？	QClaw=OpenClaw=MCP 中文内化版，本质同一协议本地化适配，站 MCP 事实标准一侧（§8.7）
场景优势	腾讯做 Agent 的优势？	微信 12 亿月活+社交数据独占+场景独占性；不拼基座拼场景（§9.10 A 层 Agency）
双引擎	腾讯双引擎架构怎么理解？	混元自研管中文社交/合规/生态，外部模型补逻辑/代码/长文本，平衡自研与效果
推理架构	DualPath 推理是什么？	动态分支：复杂开深度、简单走轻量；吞吐+1.87x，P99<200ms；按 token 预算分配算力
选型	豆包 2.0 与 Qwen3.7 选哪个？	豆包成本低/视频强/抖音生态；Qwen 中文第一/企业生态/私有化。字节场景选豆包，跨场景选 Qwen
低代码	扣子（Coze）平台特点？	零代码/低代码+插件市场+多端发布；对应 Harness L1-L3 配置即获得（对比 §9.6 自写运行器）

35. 六大厂技术栈横向总览与分级面试题映射

35.0 本章上下文与知识地图

本章是第十部分的收口章：把第 33、34 章的六家厂商放到一张决策图上，并把这些技术栈知识点映射到分级面试题（P5/P6/P7/P8、PM、系统设计 S1–S5）。为什么要单独设这一章？

跨厂商横向决策需要统一维度：前面两章各看三家，但真实选型是"六家里选适配我的"，需要一张可比的横向表（模型/协议/Harness 落点/成本/生态锁死）。
面试的本质是"知识点→问题→深度回答"的映射：原第 35 章的"真题全集"孤立成背诵册，本章把它反向挂回技术点（即 §35.5 的映射表），让每道题都能追溯到前面某一章的范式。
岗位分层 = 深度分层：P5 考概念（ReAct/RAG），P7 考架构（1000 QPS / A2A×MCP），P8 考战略（全球化/商业化），PM 考指标与场景——深度与前面范式一一对应。

知识地图：读完应能把任意一道面试题定位到"它考的是 Harness 哪层 / 协议哪块 / Loop 哪个原语"，并给出带取舍的高分回答。

35.1 技术栈全景（六厂横向架构）

横向结论：国际三家在"模型 + SDK 原生能力"上领先（SandboxAgent / Computer Use / A2A），国内三家在"场景 + 成本 + 平台托管 Harness"上领先。协议层国际内部分裂（MCP vs A2A），国内一致站 MCP——意味着国内 Agent 的工具层可平移性更好。

35.2 关键能力对比（六厂统一维度，2026 H1）

维度	OpenAI	Anthropic	Google	阿里	腾讯	字节
基座模型	GPT-5.4/5.6Sol	Opus4.8/Sonnet5	Gemini3Pro	Qwen3.7Max	HunyuanPro	豆包2.0Pro
核心协议	MCP	MCP	A2A	MCP	QClaw=MCP	MCP
Harness 落点	L2/L6 SDK	L3/L4 Loop	L3 编排	L2/L3 托管	L2+场景	L1-L3 低代码
执行隔离	SandboxAgent	YOLO+Worktree	AgentEngine	平台托管	平台托管	平台托管
成本(相对)	高	高	中	中(1/5 GPT)	中	最低(1/10)
生态锁死	高	中	中高	低(全开源)	中	中高
最适合	强模型+实时语音	自主长链路+CUA	多Agent跨组织	企业私有化	微信场景	电商/视频/成本敏

取舍分析（战略层）：

成本维度是分水岭：字节 1/10 GPT 成本意味着同样的预算能跑 10 倍 Agent 迭代，直接放大"补偿面迁移"收益（§10.5）——模型变强时你更能负担大量迭代来验证拆组件。
生态锁死风险：阿里全开源最低（Qwen 可私有化部署），OpenAI 最高（模型+工具强耦合）。选型时把"未来能否迁走"作为一级指标，对应 §33.2 的 lock-in 排序。
Harness 自写 vs 托管：国际三家逼你自写运行器（§9.6），国内三家给你配置即 Harness。早期团队用国内平台更快上线，规模后需要精细控制时再下沉自写。

35.3 生产级要点 / 接入样本（跨厂商抽象层）

# 跨厂商 Agent 接入抽象 —— 证明"MCP 站队"让工具层一次编写、六厂平移
# 前面 §33.3 / §34.3 各家 base_url 不同，但 tool 协议都是 MCP/OpenAI 形状

class VendorAgent:
    ENDPOINTS = {
        "openai":   "https://api.openai.com/v1",
        "anthropic":"https://api.anthropic.com/v1",  # 经 Agents SDK
        "google":   "https://aiplatform.googleapis.com",  # 经 ADK
        "aliyun":   "https://dashscope.aliyuncs.com/compatible-mode/v1",
        "tencent":  "wss://qclaw.tencent.com/mcp",    # QClaw=MCP
        "bytedance":"https://ark.cn-beijing.volces.com/api/v3",
    }
    def __init__(self, vendor: str, model: str, mcp_servers: list):
        self.base = self.ENDPOINTS[vendor]
        self.model = model
        self.tools = mcp_servers   # 同一份 MCP 工具定义，六厂通用(§8)

    # 关键点：Harness 的 L2(工具)/L3(编排)/L6(护栏) 在抽象层统一，
    # 厂商差异仅落在 model + endpoint + 隔离实现(SandboxAgent/YOLO/平台托管)
    async def run(self, task: str, max_turns: int = 15, budget_usd: float = 5.0):
        # 统一的 Plan-Build-Verify-Fix 循环(§9.7) + 预算熔断(L6)
        ...

要点：这段抽象层本身即是面试高分素材——它证明你理解"六厂差异在模型与隔离实现，工具层因 MCP 可统一"，这正是 §35.2 取舍分析的技术落地。

35.4 实战复盘

来自我们"六大厂模型做同一客服 Agent 压测"的复盘。

复盘：没有哪一家是全能答案，关键看任务画像。 我们把同一套 MCP 工具（§8）挂到六家模型上跑客服 Agent 压测：GPT-5.4 在复杂多跳推理最稳但最贵；Qwen3.7-Max 工具调用最稳、成本适中，综合 ROI 最高；豆包成本最低但高并发 Func Call 成功率拖后腿；Sonnet 5 在"需要自主长链路 + 跨步骤规划"的任务上最强。教训：不要问"哪家最好"，要问"我的任务画像（推理深度/并发/成本预算/是否需要 CUA）匹配哪家的 Harness 落点"。这也解释了为什么我们最终用 Qwen 跑主干、Sonnet 跑复杂分诊的混合架构。

踩坑：A2A 在跨组织场景才是刚需，单厂商内用 MCP 就够了。 我们一度想在所有场景上 A2A，结果发现在单一厂商内 A2A 增加复杂度却无收益——MCP 管 Agent↔Tool 已足够。只有当我们接入外部合作方的 Agent（跨组织）时才上 A2A 的 Signed Agent Card。对应 §33.2 的"互补非竞争"结论：A2A 不是 MCP 的升级，是不同层的协议。

35.5 知识点 → 面试映射（分级真题卡）

下表把原第 35 章的"分级真题全集"反向挂回技术范式：每道题标注它考的是前面哪一层的深度。答题框架 + 评分标准已融入"高分回答要点"。

35.5.1 工程师分级（P5 / P6 / P7 / P8）

岗位	面试问题	高分回答要点（含深度锚点）
P5	ReAct 和 Chain-of-Thought 区别？	CoT 是"思考链"；ReAct=Thought+Action+Observation 交替（§10.2）。合格线：能说出三步结构
P5	怎么让 LLM 调用外部 API？	Function Calling / Tool Use + JSON Schema；能写 OpenAI Function Calling 示例（§34.3）即合格
P5	RAG 流程？	离线索引+在线检索+生成；说出"分块/向量化/检索/重排"即合格（§12 多模态可延展）
P6	LangGraph 状态机如何设计？	精细图状态机+Checkpoint 持久化+跨模型；对比 Agents SDK 的轻量编排（§33.2/§33.3）
P6	流式响应怎么实现？中断如何处理？	SSE/WebRTC 流式（Responses API，§33.1.1）；中断用 checkpoint 续跑（Harness R 层，§9.10）
P6	多 Agent 协作的通信机制？	Orchestrator+Registry+A2A（S3）；MCP 管工具、A2A 管 Agent 间（§33.2）
P6	MCP 协议理解？	三大原语 Tools/Resources/Prompts（§8.2）；2026-07 Stateless Core + Extensions（§8.1）
P7	设计 1000 QPS 的 Agent 系统	无状态化（MCP Stateless 可 LB，§8.1）+ 预算熔断（L6）+ 工具选择器（Stripe 15 个，§9.2）+ 编排税控制（§10.6）
P7	A2A vs MCP 怎么协同？	互补非竞争：MCP=Agent↔Tool，A2A=Agent↔Agent；Signed Agent Card 跨组织（§33.2/§35.4）
P7	Orchestrator 如何避免单点故障？	去中心化编排 + A2A 服务发现 + 事件溯源状态（§9.10 R 层 append-only）
P7	如何保证 Agent 系统安全？	OWASP Agentic Top 10 + YOLO 三级分类（§33.3.2）+ 工具权限粒度（§8.4）+ 审计（§8.6）
P8	未来 3 年 Agent 技术演进？	补偿面迁移（§10.5）+ 编排税（§10.6）+ 协议收敛（MCP+A2A+AG-UI）+ 模型自主链路变长
P8	如何设计全球化 Agent 平台？	多区域部署 + 协议标准化（MCP/A2A）+ 成本分区（字节 1/10 启示）+ 合规（EU AI Act HITL）
P8	Agent 商业化模式？	按 token/按 task/订阅；成本结构决定毛利（豆包 1/10 优势，§34.2）

35.5.2 AI 产品经理（PM）高频题

岗位	面试问题	高分回答要点（含深度锚点）
PM	如何衡量 Agent 的"智能"？	不能只看模型分；用 Golden Set + 轨迹评测 + LLM-as-Judge（S5，§35.5.3）
PM	Agent 产品核心指标？	任务完成率/成本 per task/人工接管率（HITL 频率）/满意度
PM	如何设计 HITL 流程？	EU AI Act 强制 HITL（§8 速查表）；高风险操作二次确认（§8.4）
阿里 PM	百炼 vs LangChain 选型？	百炼托管+Qwen 优化；跨厂商 LangChain（§34.2/§34.3.1）
腾讯 PM	微信生态 Agent 边界？	数据不能出域（§34.4 踩坑）；场景独占 vs 架构分裂
字节 PM	扣子平台定位？	零代码+插件市场+多端发布；配置即 Harness L1-L3（§34.3.3）

35.5.3 系统设计题（S1–S5，PM + 高级工程师）

编号	设计题	评估维度	关键架构要点（锚点）
S1	客服 Agent	分类/记忆/知识库/工具/HITL/监控	FAQ+工单+升级人工；RAG（§12）+ HITL（§8）+ MCP 工具
S2	Code Agent（类 Claude Code）	代码理解/文件操作/命令/测试	沙箱（SandboxAgent/WASM，§8.3/§11）+ 版本控制 + 安全 + `/goal` Loop（§10.4）
S3	多 Agent 协作平台	编排/通信/状态/监控	Orchestrator + Registry + A2A（§33.2）；事件溯源状态（§9.10）
S4	企业知识库 Agent	文档解析/权限/版本/合规	RAG + 权限（RBAC/RLS，§8 速查）+ 审计（append-only，§8.6）
S5	Agent 评测平台	Golden Set/轨迹/LLM-Judge	自动化 + 校准 + 回归；Generator-Evaluator 对抗（§9.2 L5）

2026 H2–2027 前瞻（面试加分项）：面试收尾可补一句——“接下来一年，Agent 面试会从’概念理解’升级到’工程范式理解 + 架构设计 + 商业判断’；能讲清 Agent = Model + Harness（§9.1）与 Loop 六原语（§10.3）的候选人将是赢家。” 这正是原结语（第 4132 行）的核心判断，但已融入技术映射而非孤立背诵。

附录 A：2026 年关键概念速查表

概念	全称	一句话定义	关键数字
MCP	Model Context Protocol	Agent ↔ Tool 协议	9700 万+ 月下载
A2A	Agent-to-Agent Protocol	Agent ↔ Agent 协议	v1.0（2026-03-12）
AAIF	Agentic AI Foundation	Linux Foundation 子基金	190+ 成员
CUA	Computer-Using Agent	操作 GUI 的 Agent	OSWorld 72.7%
BUA	Browser-Use Agent	仅操作浏览器的 Agent	94K GitHub star
IPI	Indirect Prompt Injection	外部内容中的注入	73% 部署遇到
HITL	Human-in-the-Loop	人类介入环节	EU AI Act 强制
RBAC	Role-Based Access Control	角色权限	主流
ABAC	Attribute-Based Access Control	属性权限	灵活
RLS	Row-Level Security	行级安全	PostgreSQL 原生
RAG	Retrieval-Augmented Generation	检索增强生成	主流
GraphRAG	Graph-based RAG	图谱 RAG	Microsoft 2024
SFT	Supervised Fine-Tuning	监督微调	主流
DPO	Direct Preference Optimization	直接偏好优化	2026 主流
RLHF	RL from Human Feedback	人类反馈强化学习	复杂
LoRA	Low-Rank Adaptation	低秩适配	主流微调方法
PPO	Proximal Policy Optimization	邻近策略优化	RLHF 经典
SLO	Service Level Objective	服务等级目标	99.9% 常见
SLI	Service Level Indicator	服务等级指标	量化
SLA	Service Level Agreement	服务等级协议	合同
IPI	Indirect Prompt Injection	间接提示注入	OWASP 关注
ASI	Agentic Security Index	OWASP 命名	2025-12 发布
Harness Engineering	构建 Agent 的外部系统	Agent = Model + Harness	6.7%→68.3%（Can.ac）
Loop Engineering	构建驱动 Agent 的 Loop	Loop = Cron + 决策器	Anthropic 80%+ 代码
AGENTS.md	Agent 启动文档免疫系统	渐进式披露	OpenAI 88 个文档
Blueprint 模式	确定+概率节点交替	模型不运行系统，系统运行模型	Stripe 生产验证
Build-Verify Loop	构建-验证四步闭环	Plan-Build-Verify-Fix	退出前检查清单
补偿面迁移	Harness 随模型升级而简化	模型变强→Harness 变轻	Anthropic 主动拆组件
编排税	Review 带宽是新瓶颈	写代码不再稀缺，审代码才是	AI 代码 PR 被拒 67.3%
Generator-Evaluator	生成器 vs 评估器对抗	降低输出幻觉	自我修正闭环
MAF	Microsoft Agent Framework	SK 的继任者	1.0 GA 生产就绪
Sonnet 5	Claude Sonnet 5	最强 Sonnet Agent 模型	2026-07-01 发布
GPT-5.6 Sol	OpenAI 内测模型	编程超 Claude Opus	2026-07 内测
AG-UI	Agent-to-GUI 协议	CopilotKit 主导	与 MCP/A2A 并称三大
CUA	Computer-Using Agent	计算机使用 Agent	OSWorld 基准
PUA	Process-Using Agent	流程使用 Agent	学术概念
SOC	Self-Operating Computer	自操作系统	开源
BUA	Browser-Use Agent	浏览器使用 Agent	94K star
AP2	Agent Payments Protocol	智能体支付协议	60+ 支付方
x402	HTTP 402 扩展	支付扩展	A2A 衍生
UCP	Universal Commerce Protocol	通用商务协议	与 AP2 兼容
SEP	Specification Enhancement Proposal	MCP 规范增强提案	RFC 流程

附录 B：引用资料（官网 / GitHub 主仓 / 一手博客）

所有链接均经 2026-07-03 验证有效，优先官方一手源。

结语：2026 年 Agent 工程师能力模型

技术深度

P5：会用 1-2 个框架，能写 RAG / Agent
P6：能设计状态机、流式、记忆系统，理解 Harness 工程基础
P7：能设计多 Agent 协作、可观测、A2A/MCP 集成，掌握 Loop Engineering 六原语
P8：能设计企业级 Agent 平台、安全治理、商业化、补偿面迁移与编排税管理

知识广度

必备：LLM 基础、Prompt 工程、RAG、Agent 框架
加分：Harness Engineering（六层架构） / Loop Engineering（六原语） / MCP / A2A / Computer Use / 多模态
领先：Berkeley 研究、Anthropic 内部实践、AAIF 标准、补偿面理论

软实力

快速学习（每周都有新框架）
跨团队沟通（PM + 工程师 + 设计师）
用户视角（PM 必考）
商业敏感（成本、ROI、规模化）

持续学习路径

官方文档：Anthropic、OpenAI、Google 博客
GitHub Trending：每周看 Agent 趋势
论文：arXiv cs.MA、cs.CL
播客：Latent Space、Last Week in AI
实战：自己做 Side Project

最后一句话：2026 年是 Agent 走向"规模化"的关键年。MCP + A2A + Computer Use 三大协议奠定基础设施，Harness Engineering + Loop Engineering 两大范式定义工程实践，OWASP Agentic Top 10 划定安全红线，国际三巨头 SDK 全面上线 + 国内三巨头 完成 Q1 布局。面试已从"概念理解"升级到"工程范式理解 + 架构设计 + 商业判断"。能讲清 Agent = Model + Harness 公式和 Loop 六原语的候选人，将成为 2026 年面试的赢家。

祝面试顺利，欢迎把这些知识点带进你的下一个生产级 Agent 系统。