AI Agent 开发技术完全学习指南（2026-07 基线版）Part2
第七部分：安全、合规与治理
面试重点：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 | |
|---|---|---|---|
| 旗舰模型 | 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 | 阿里 | 腾讯 | 字节 | |
|---|---|---|---|---|---|---|
| 基座模型 | 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 验证有效，优先官方一手源。
B.1 协议与标准
- A2A 协议：https://a2a-protocol.org/latest/
- A2A v1.0 发布：https://a2a-protocol.org/latest/announcing-1.0/
- A2A GitHub：https://github.com/a2aproject/A2A
- MCP 协议：https://modelcontextprotocol.io
- MCP GitHub：https://github.com/modelcontextprotocol
- MCP 2026-07 RC Blog：https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
- MCP Registry：https://registry.modelcontextprotocol.io
- AP2 协议：https://ap2-protocol.org/
- Linux Foundation AAIF：https://www.linuxfoundation.org/
- OWASP Agentic Top 10：https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
B.2 厂商一手
- Anthropic Agent SDK：https://platform.claude.com/docs/en/agent-sdk/overview
- Anthropic Computer Use：https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use
- Anthropic Building Effective Agents：https://www.anthropic.com/research/building-effective-agents
- Anthropic When AI builds itself（2026-06）：https://www.anthropic.com/institute/recursive-self-improvement
- Claude Sonnet 5 发布（2026-07-01）：https://www.anthropic.com/news/claude-sonnet-5
- OpenAI Agents SDK：https://openai.github.io/openai-agents-python/
- OpenAI Agents SDK 演进（2026-04-15）：https://openai.com/zh-Hans-CN/index/the-next-evolution-of-the-agents-sdk/
- Microsoft GraphRAG：http://microsoft.github.io/graphrag/
- Microsoft Copilot Studio CUA GA：https://www.digitalapplied.com/blog/copilot-studio-computer-use-agents-ga-deep-dive
- Microsoft Agent Framework (MAF)：https://learn.microsoft.com/zh-cn/agent-framework/
- Google ADK 2.0 GA（2026-06-18）：https://github.com/google/adk-python/releases
- Google A2A 公告：https://developers.googleblog.com/
B.3 框架 GitHub
- LangGraph：https://github.com/langchain-ai/langgraph
- AutoGen / AG2：https://github.com/microsoft/autogen
- CrewAI：https://github.com/crewAIInc/crewAI
- Mem0：https://github.com/mem0ai/mem0
- Zep / Graphiti：https://github.com/getzep/graphiti
- Letta：https://github.com/letta-ai/letta
- browser-use：https://github.com/browser-use/browser-use
- Cognee：https://github.com/topoteretes/cognee
- Langfuse：https://github.com/langfuse/langfuse
- OpenAgents：https://github.com/openagents-org/openagents
- OpenAI Agents SDK (JS)：https://github.com/openai/openai-agents-js
- Microsoft Agent Framework (MAF)：https://github.com/microsoft/agent-framework
- Google ADK：https://github.com/google/adk-python
- LoopEngineer.ai：https://loopengineer.ai/
- skills.sh（Vercel）：https://skills.sh/
B.4 评测工具
- DeepEval：https://github.com/confident-ai/deepeval
- Braintrust：https://github.com/braintrustdata/braintrust
- Phoenix：https://github.com/Arize-ai/phoenix
- Galileo：https://galileo.ai
B.5 国内厂商
- 阿里通义千问：https://qianwen.aliyun.com/
- 阿里百炼 Model Studio：https://bailian.console.aliyun.com
- 腾讯混元：https://hunyuan.tencent.com
- 腾讯元宝：https://yuanbao.tencent.com
- 字节豆包：https://www.doubao.com
- 字节扣子 Coze：https://www.coze.cn
- 字节火山方舟：https://www.volcengine.com/product/ark
B.6 关键研究报告
- Berkeley 2026-04 Agent Reward Hacking：arxiv.org/abs/2606.31498
- Anthropic 2026-04 Sub-Agents Whitepaper：https://www.archorizon.uk/downloads/Claude_Agents_Data_Management_Whitepaper.pdf
- Anthropic Building Effective Agents：https://www.anthropic.com/research/building-effective-agents
- Anthropic When AI builds itself（2026-06）：https://www.anthropic.com/institute/recursive-self-improvement
- A2A 一周年公告（Linux Foundation 2026-04-09）：https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
- Agent Interoperability Governance Gaps（arXiv 2026-06-30）：https://arxiv.org/pdf/2606.31498
- Loop Engineering 深度综述（2026-06-14）：https://www.daoyuly.cn/2026/2026-06-14-loop-engineering-deep-review/
- Harness Engineering 实践指南（2026-03）：https://edison-a-n.github.io/2026/03/14/harness-engineering-practical-guide/
- Addy Osmani Loop Engineering（六原语）：https://addyosmani.com/blog/loop-engineering/
B.7 安全与合规
- Oasis Security “Claudy Day”（2026-03）：https://www.oasis.security/blog/claude-ai-prompt-injection-data-exfiltration-vulnerability
- 全球首例 AI Agent 自主勒索攻击（2026-07-05）：https://iaipie.com/2026年7月5日ai行业资讯速览/
- Anthropic Git MCP Server CVE 公告：https://www.anthropic.com/security
- OWASP MCP Top 10：https://owasp.org/www-project-mcp-top-10/
B.8 评测与对比报告
- 8 AI Agent Evaluation Frameworks Compared（2026-05）：https://growthengineer.ai/blog/ai-agent-evaluation-frameworks-compared
- The Agent Evaluation Stack 2026：https://callsphere.ai/blog/agent-evaluation-stack-2026-trace-to-eval-score
- AI Browser Automation 2026：https://ztabs.co/blog/ai-browser-automation-2026
结语：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 系统。
中国智能体开发者社区，聚焦智能体与大模型开发，提供前沿资讯、实用工具链、开源项目及行业案例。通过技术沙龙、开发者大赛等活动，促进经验交流与协作，助力开发者快速构建创新智能应用。
更多推荐
7
0- 0
已为社区贡献1条内容
所有评论(0)