AI Native 架构建议：从零开始以 AI 为核心构建系统

AI Native 架构建议（AI Native Architecture Recommendations）

1. 定位与目标（Positioning & Goals）

1.1 什么是 AI Native

AI Native 指的是从零开始以 AI 为核心构建 的系统、产品或工作流，AI 不是附加组件，而是承载业务逻辑的"认知内核"。一个简单但关键的判定标准是**"移除测试"：如果把 AI 能力移除，系统不仅无法按预期工作，而且完全失去使用价值**。

维度	AI-Powered（外挂式）	AI Native（原生式）
核心逻辑	确定性、硬编码流水线	概率性、持续学习的模型
数据流	批处理 ETL、刚性关系库	流式数据、实时上下文、向量嵌入
集成方式	外部 API、可移除侧边栏、插件	深度嵌入、不可分离的应用逻辑
用户界面	固定仪表盘、手动配置、点击操作	自然语言界面、意图驱动流程
系统行为	静态，需人工打补丁更新	动态自维护、涌现式行为
安全模型	为传统工作流设计，未考虑 AI 风险	数据主权内置、零信任设计

移除测试（Removal Test）------操作化判定

"移除测试"是把抽象定义变成可执行判定的方法：临时屏蔽所有 LLM/embedding 调用，观察系统行为。

移除后的现象	判定	成熟度（对应 §1.2）
系统完全照常工作，只是少了几个"AI 助手"按钮	❌ 不是 AI Native	L0/L1
核心功能降级，但有规则引擎等降级路径能勉强完成	⚠️ AI 嵌入，非原生	L2
核心功能完全失效------没有 AI 就无法完成主流程	✅ AI Native	L3

常见反模式判定： 许多自称"AI Native"的系统实为 L1------AI 被包装成可移除的"魔法按钮"，业务逻辑仍跑在传统确定性流水线上。真正的 AI Native 不是"加了 AI"，而是"以 AI 为骨架重构业务逻辑"。

1.2 AI Native 成熟度光谱

AI Native 不是二元状态------它是一个从外挂到原生的光谱：

层级	特征	移除 AI 的后果	示例
L0 传统系统	纯规则引擎，无 AI	无影响	传统 SIEM 规则告警
L1 AI 增强	AI 作为可选插件/侧边栏	系统核心功能不受影响，只是少了辅助	IDE 中的代码补全
L2 AI 嵌入	AI 是工作流的关键环节，但有降级路径	核心体验显著退化，但可降级到规则模式	语义搜索替代关键词搜索
L3 AI 原生	AI 是认知内核，移除即系统死亡	系统完全失去使用价值	自主 Agent 执行多步安全调查

本文档目标读者： 正在从 L1/L2 向 L3 迁移的架构师和安全工程师。L3 系统面临的安全和非功能性挑战与前三级有质的区别------概率性内核意味着传统的确定性安全控制不再充分。

L1 → L3 的演进路径与成熟度边界

成熟度不是"越高越好"------每升一级都引入新的复杂度和风险。下表给出每级的演进触发条件 、新增能力 、新增风险 和必须先具备的基础设施，帮助判断"现在该不该升级"：

跃迁	触发条件（何时该升）	新增能力	新增风险	必须先具备的基础设施
L0→L1	有明确的"AI 能做得更好"的单点任务（如分类、摘要）	辅助性 AI，可移除	几乎无（AI 出错不影响主流程）	基础 LLM API 接入
L1→L2	AI 成为某些工作流的关键环节，但用户仍可绕过	工作流级 AI，有降级路径	AI 故障导致体验退化；需可观测性	检索/记忆层（§3.3）、可观测性（§6.1）
L2→L3	业务逻辑本质上无法用规则表达（开放域推理、多步规划、自然语言驱动）	AI 作为认知内核，移除即死亡	质的飞跃：概率性内核 + 自主性 + 攻击面爆炸	全部 §5 安全架构 + §6 非功能性 + §9 评估

L2→L3 的边界（最关键的决策点）： 不要为了"看起来先进"而升 L3。L3 是有代价的承诺------

不可降级：L3 系统没有"AI 挂了用规则顶上"的退路，必须为 AI 不可用设计冗余
安全模型质变：L1/L2 的安全控制（API 鉴权、输入校验）不充分；L3 必须应对提示注入、Agent 间信任、记忆污染等 AI 特有攻击（§5）
评估基础设施前置 ：L3 系统没有评估闭环就无法安全迭代（§9）。调研显示企业部署的 AI Agent 88% 在进入生产前失败 $59$ ，根因多为跳级到 L3 却未补齐基础设施

决策原则： 只有当业务逻辑本质上需要概率性推理 且用户接受 AI 自主性时才升 L3。能用规则 + L1 辅助解决的问题，不应强行 L3 化------L3 的运维、安全、合规成本远高于前三级。

1.3 本文档目标

为正在规划或重构 AI Native 系统的团队提供可操作的架构蓝图
明确安全与非功能性需求的一体化设计原则
给出从威胁建模到运行时防护的闭环实施路径

1.4 非目标（Non-Goals）

不提供具体模型选型或训练方案
不替代合规审计，仅提供架构层面的合规对齐建议
不覆盖前端 UI/UX 细节设计

2. 架构原则（Architectural Principles）

以下八条原则在所分析的资料中被反复且一致地强调，是 AI Native 系统区别于传统应用的根本约束。它们不是文档装饰------每条原则在 §9.4 都有对应的可验证检查项和自动化回归测试。

实证警示：为什么这八条原则不可妥协。 调研显示企业部署的 AI Agent 中 88% 在进入生产前失败 $59$ ，而失败原因几乎都能追溯到违反了本章某条原则------最常见的根因是 "没人设计 Agent 出错时该怎么办"（违反 P1/P4/P5）。这八条原则是另外 12% 成功者的共同分母。

每条原则按统一模板展开 ：核心定义 → 设计含义 → 反模式 （要避免什么）→ 落地检查点 （架构评审问什么）→ 量化阈值/信号 （监控什么）→ 常见误解。

原则 1：概率性内核，而非确定性规则

AI Native 系统以概率性、持续学习的模型为核心，替代传统"if-then"硬编码逻辑。长流程多步任务被压缩为单次意图声明，由 Agent 自主完成规划、工具选择、评估后产出结果。

设计含义： 必须为概率性输出设计验证、回滚、人工介入机制；不能假设输出 100% 正确，需在关键路径上设置校验关卡。

反模式：

❌ 把 LLM 当确定函数调用 ------不加校验地把输出直送下游系统（如直接 eval(LLM 输出)、直接写库）
❌ 用置信度分数做二元闸门------LLM 的 logits 置信度与正确性弱相关，"高置信"≠"高正确"
❌ 无回滚路径------只设计了"成功路径"，没设计"输出错误后如何撤销已执行的副作用"

落地检查点（架构评审必问）：

关键路径（写库/发邮件/执行命令/调用付费 API）上是否有独立验证关卡？
副作用操作是否可回滚？回滚链是否经过测试？
LLM 输出在传入下游前是否经过 schema 校验？
是否定义了"何为失败"的客观标准（而非"看起来对"）？

量化阈值/信号（纳入 §6.1.3 监控）：

幻觉率：>5% 需调查（抽样人工/LLM-as-Judge 核验）
输出 schema 校验失败率：作为一等告警信号
关键路径回滚率：突增暗示模型质量退化或输入漂移

常见误解： "模型变强后概率性就消失了" ------错误。即使 frontier 模型，多步推理的累积错误率仍可观（k 步每步 95% 准确 → 整体 0.95^k）。概率性内核是 AI Native 的结构性属性，不随模型进步消失，只能被工程化缓解。

原则 2：智能无处不在（Intelligence Everywhere）

AI 工作负载（推理、训练、监控）可部署在网络任意域和栈任意层。智能不是某个组件的能力，而是贯穿数据采集、决策、资源调度、用户交互的全链路。这意味着 AI 能力没有可信的"边界"可作为安全域------智能可能出现在任何曾被认为"哑"的组件中。

设计含义： 不能把 AI 限制在"AI 服务"单一组件里；安全控制必须假设智能可能出现在请求的任何环节（参见 §5.4 间接注入------恶意指令可能来自 Agent 处理的任意数据）。

反模式：

❌ AI 网关单点防御------只在外部 API 边界做提示注入检测，假设内部组件可信
❌ AI 功能隔离在"侧边栏"------这正是 AI-Powered（L1）的特征，不是 AI Native（L3）；L3 系统移除 AI 即死亡（§1.1 移除测试）
❌ 只监控"主"AI 调用------忽略嵌入在数据管线、日志分析、推荐、风控等"次要"环节的 AI

落地检查点：

清点了系统所有调用 LLM/embedding 模型的位置（含嵌入式的）？
安全控制是否假设"任何数据源都可能含恶意指令"？
移除测试（§1.1）：移除主 AI 组件后，系统是否还能完成核心任务？L3 系统应完全失去核心价值

量化阈值/信号：

AI 调用清单覆盖率：所有 LLM 调用点是否都纳入监控（目标 100%）
分布式 AI 组件的延迟/成本占比：评估"智能"是否真的分布全链路

常见误解： "智能无处不在 = 到处塞 LLM" ------错误。智能无处不在是架构属性 （决策能力贯穿各层），不是实现要求（每层都跑大模型）。许多层的"智能"可以是规则引擎、轻量分类器、SLM，关键是决策权下放到恰当的层。

原则 3：最小代理权（Least Agency）

OWASP 提出的 Least Agency 是 Least Privilege 的延伸：不仅限制 Agent 拥有哪些工具，还要限制每个工具能做什么、多久一次、在何处执行 。核心规则：deny-by-default（默认拒绝），只允许显式列入白名单的操作。

例：数据库工具只能执行只读查询；邮件摘要工具不能发送或删除邮件。

设计含义： 传统最小权限只问"Agent 能调哪些 API"；最小代理权还要问"这个 API 在 Agent 手里能被怎样滥用"------包括参数范围、调用频率、副作用等级、可触达的资源。

反模式：

❌ 给 Agent 一个"通用 SQL 工具"------能写、能删、能 DDL。应拆分为只读查询工具 + 需人工审批的写工具
❌ 共享服务账户------所有 Agent 用同一个高权限凭证。攻破一个 = 攻破全部（参见 §5.1.3 Replit 事件）
❌ 一次性永久授权------Agent 上线即获得全部权限，永不回收

落地检查点：

每个工具是否定义了"它能做什么/不能做什么"的清单（不只是"它叫什么"）？
工具是否按 deny-by-default 配置，白名单显式列出允许的操作？
敏感操作（写/删/付费/外发）是否有 JIT 一次性授权 + 审批？
Agent 间凭证是否隔离（参见 §5.1.3 凭证管理八级模型）？

量化阈值/信号：

每个 Agent 的工具数与权限范围：纳入 CI 静态检查（§9.4 P3）
高危操作 JIT 授权占比：应接近 100%（无永久高危权限）
权限实际使用率：长期未使用的权限应回收

常见误解： "最小代理权会限制 Agent 能力" ------本末倒置。最小代理权限制的是爆炸半径而非能力------Agent 在其授权范围内可充分发挥；当 Agent 被攻破（P5 假设失陷）时，最小代理权决定损害上限。

原则 4：永远验证，永不信任（Never Trust, Always Verify）

继承 NIST SP 800-207 的零信任原则，每个访问请求都必须经过认证和授权，无论来源是内部还是外部。AI 加速了攻击从漏洞到利用的时间线（从数月压缩到数小时），基于边界的防御已无法跟上。

设计含义： "内部网络 = 可信"的假设彻底失效。Agent 间的每一次调用、每一个工具请求、每一次记忆读取，都要独立验证身份与授权------不存在"可信调用方"。

反模式：

❌ 信任 Agent 间内部通信------"都是我们自己的 Agent，不用鉴权"。这是 ASI07（不安全 Agent 间通信）的直接诱因
❌ 凭证一次验证全程放行------会话中途 Agent 被攻破，剩余调用全部信任
❌ 把"摩擦控制"当"验证"------速率限制、额外跳板、非标准端口只是摩擦，不是验证（§5.1.2）

落地检查点：

Agent 间每次调用是否相互认证（mTLS + 签名意图）？
授权是否逐操作而非逐会话（JIT）？
是否区分了"摩擦控制"与"验证控制"------前者增加成本，后者使攻击不可能（§5.1.2）？

量化阈值/信号：

请求认证覆盖率：100% 请求经认证授权（无例外路径）
摩擦控制 vs 验证控制清单：审计时区分二者，淘汰纯摩擦控制

常见误解： "零信任 = 不信任任何人" ------简化误导。零信任是不基于位置/身份默认信任 ，但仍通过认证建立信任。关键是信任来自"每次验证"而非"网络位置"。

原则 5：假设失陷（Assume Breach）

设计时即预期系统会被攻破，通过隔离、细粒度访问、爆炸半径控制来限制损害。每个 Agent 的爆炸半径最终都会被测试------要确保失陷时影响可控。

设计含义： 不是"会不会被攻破"，而是"被攻破时损失多少"。架构决策以最坏情况而非"正常情况"为设计基线。

反模式：

❌ 单点全能 Agent------一个 Agent 持有所有工具和凭证，攻破即全面沦陷
❌ 无隔离的共享状态------所有 Agent 读写同一记忆库，一个被污染全部污染
❌ 只设计成功路径------没有爆炸半径护栏、没有断路器、没有紧急切断

落地检查点：

单个 Agent 被完全攻破时，最大损害范围是多少（爆炸半径量化）？
是否有独立于 Agent 的断路器/看门狗（不能被被攻破的 Agent 自己关闭）？
隔离边界（容器/microVM/网络分段）是否与爆炸半径匹配（§3.5）？
是否有"紧急切断 + 凭证撤销 + 隔离"的一键流程（§9.7.1 ASI10）？

量化阈值/信号：

爆炸半径量化：单 Agent 失陷影响的数据/系统/资金上限
红队测试单 Agent 攻破后的横向移动范围（§9.9.3）：目标 = 0 横向扩散
断路器触发到隔离完成的时间：目标 < 分钟级

常见误解： "我们合规了所以不会被攻破"------合规是底线不是保障。AI 系统的攻击面持续演化（提示注入、MCP 投毒、记忆污染每年都有新攻击向量），假设失陷要求按"已经被攻破"设计补偿控制。

原则 6：自动化记账，人工决策（Automate Bookkeeping, Human Decides）

模型可以自动完成首轮告警分诊、笔记记录、工件采集、事后报告起草；但遏制、披露、客户沟通等决策必须由人做出。

设计含义： 自动化有明确边界------记账类 （采集、摘要、起草、分诊）可自动化；决策类（执行、披露、对外沟通、不可逆操作）必须人工拍板。混淆二者会导致"AI 自动作出不可逆决策"事故。

反模式：

❌ 让 Agent 自动执行"高危但低频"操作------为了减少人工干预，把遏制/撤销也自动化了
❌ 人工审批流于形式------批量 approve、不看内容，等于没有审批（"批准疲劳"）
❌ 决策边界模糊------没显式定义哪些操作必须人工，依赖 Agent"自觉"

落地检查点：

是否有显式的"必须人工决策"操作清单（遏制/披露/付费/删除/对外沟通）？
人工审批是否设计为"非默认批准"------需要理由、有冷却、有抽样复核？
自动化范围是否被定期审计，防止范围 creep（悄悄扩大）？

量化阈值/信号：

高风险操作人工介入率：应 = 100%（§9.4 P6 通过标准）
人工审批拒绝率：过低（<1%）暗示批准疲劳，过高（>30%）暗示阈值不当
自动化范围变更频率：监控范围 creep

常见误解： "自动化越彻底越好"------只对记账类成立。决策类操作的自动化 = 把不可逆权交给概率性内核（P1），违反了"概率性输出不能 100% 信任"的根本前提。CSIRO 实证显示感知效用抵消孤立失败（§9.10），但这正是要警惕的------效用掩盖了风险。

原则 7：持续学习与反馈闭环

内置反馈循环使持续改进成为核心特性，而非附加功能。每次用户交互、每次运行时指标都被采集、分析，用于 A/B 测试、模型再训练和提示词优化。

设计含义： 不存在"上线即完成"的 AI 系统。学习闭环是生产架构的一等公民------生产轨迹→评估用例→模型/提示词迭代→回归测试→上线，构成持续循环。

反模式：

❌ 上线即冻结------模型/提示词上线后不再迭代，任其漂移
❌ 反馈闭环断裂------收集了用户反馈但没回流到模型/提示词优化
❌ 无回归测试的迭代------每次改提示词都靠"感觉"，没有评估基线对比（§9.2 评估八步法）

落地检查点：

生产轨迹是否自动转为评估用例（§6.1.7）？
模型/提示词变更是否必须通过评估回归才能上线（§9.2 步骤 6）？
是否有 A/B 测试框架支持线上对比？
失败案例是否进入"修正→新测试行"闭环（§9.2 步骤 8）？

量化阈值/信号：

每周新增评估用例数：> 0（§9.4 P7 通过标准）
模型漂移检测：行为基线偏离告警
反馈→上线的闭环时延：从发现问题到修复上线的周期

常见误解： "持续学习 = 在线微调模型" ------狭隘。持续学习首先是系统级闭环（轨迹→评估→迭代），不一定涉及模型权重更新。大多数团队的成本最优路径是迭代提示词/工具/检索，而非重训模型。

原则 8：可解释与可审计

系统必须能解释其决策过程，这对受监管行业尤为重要。通过展示推理链、证据来源、ATT&CK 映射等方式，提供清晰的审计轨迹。

设计含义： 可解释性不是事后文档，是运行时数据------每次决策必须捕获足够的溯源信息（输入、推理路径、工具调用、记忆读写、输出），使任何最终行为可回溯到触发源（§6.1.2 溯源链）。

反模式：

❌ 只记最终输出------不记推理过程、工具调用、记忆读取，事后无法归因
❌ 黑箱可解释------用"AI 决定的"搪塞，没有证据链支撑
❌ 可解释性 = 给出理由文本 ------LLM 生成的"理由"可能是事后合理化，≠ 真实推理依据。必须用结构化证据链而非自述理由

落地检查点：

每个请求是否有完整溯源链（输入→推理→工具→记忆→输出，§6.1.2）？
溯源链是否签名、不可篡改、可重放？
非专家能否理解溯源链（可读性，§9.4 P8 目标 >80%）？
是否区分了"结构化证据"与"LLM 自述理由"------以前者为审计依据？

量化阈值/信号：

溯源链完整性：100% 请求有完整链（§9.4 P8）
溯源链可重放率：故障复盘时能否精确复现
非专家可理解度：抽样人工审查 >80%

常见误解： "用更强的模型就不需要可解释性了" ------错误且危险。可解释性的目的不只是"让用户信任"，更是故障归因 和合规审计 。即使模型 100% 准确，监管（EU AI Act Article 12）、事故复盘、安全溯源仍要求完整审计轨迹。可解释性是外部约束，不随模型能力消失。

原则分布：

功能性：P1 :概率性内核，而非确认性规则，P2 智能无处不在，P6: 自动化记账、人工决策

两者之间： P3 最小代理权，P5 假设失陷，P7 持续学习与反馈闭环

非功能性： P4: 永远验证、永不信任，P8 可解释与可审计

原则间的张力与权衡

上述原则并非总是和谐的------它们之间存在需要显式管理的张力：

张力对	冲突描述	权衡策略
最小代理权（P3） vs 智能无处不在（P2）	赋予 Agent 更多自主权意味着更大爆炸半径	按 Agent 成熟度分级授权------新 Agent 从只读开始，经评估后逐步开放（参见 §5.2 成熟度框架）
自动化记账（P6） vs 假设失陷（P5）	自动化越深，被攻破时损害越大	自动化仅限"记账"层（分诊、采集、起草）；遏制和决策必须人工确认
持续学习（P7） vs 可解释（P8）	持续学习的模型行为漂移，难以稳定解释	每次模型/提示词变更需通过评估回归测试（参见 §9.2 步骤 6）；版本化解释模板
概率性内核（P1） vs 永远验证（P4）	概率性输出不可能 100% 验证通过	按风险分级验证------低风险自动放行，高风险人工介入；设置置信度阈值而非二元判断

原则落地检查清单： 每个架构决策都应能追溯到至少一条原则。如果一个决策违反了某条原则，必须在架构评审中显式记录例外理由和补偿控制。

3. 分层架构（Layered Architecture）

资料中普遍出现的五层 AI Native 架构蓝图 $25$ $26$ ，每一层有明确的职责和边界。

复制代码

┌─────────────────────────────────────────────────┐
│           5. 交互层 (Interaction Layer)           │
│   自然语言界面 · 动态 UI · 多模态输入 · Agent 入口    │
├─────────────────────────────────────────────────┤
│           4. 编排层 (Orchestration Layer)         │
│   多 Agent 协调 · 动态提示词 · RAG 管道 · 工具路由    │
├─────────────────────────────────────────────────┤
│           3. 知识层 (Knowledge Layer)             │
│   向量数据库 · 特征存储 · 语义记忆 · 上下文管理       │
├─────────────────────────────────────────────────┤
│           2. 智能层 (Intelligence Layer)          │
│   基础模型 · 领域 SLM · 微调权重 · 模型版本管理       │
├─────────────────────────────────────────────────┤
│           1. 基础设施层 (Infrastructure Layer)     │
│   GPU 集群 · 容器化微服务 · 网络通道 · 弹性伸缩       │
└─────────────────────────────────────────────────┘

3.1 交互层（Interaction Layer）

职责： 用自然语言、动态 UI、自主 Agent 集成替代传统菜单和固定仪表盘。

关键设计：

支持多模态交互（文本、语音、视觉线索、手势）
意图识别与上下文感知推荐
证据优先展示： 优先呈现证据（日志片段、命令轨迹、ATT&CK 关联），而非给出"是否恶意"的处方性标签------保持人的判断自主权（参见 §6.1.5）
信任校准 UI： 对高风险操作使用红色边框/横幅等视觉警示；避免在安全关键流程中使用说服性语言（参见 §5.3 ASI09）

本层安全控制： 输入隔离 + Spotlighting 界定不可信内容（参见 §5.4）；AG-UI 协议标准化 Agent 与用户的交互 $35$

本层可观测性： 用户脱离模式追踪（参见 §6.1.4）；会话中途放弃率；重试后终止序列频率

3.2 编排层（Orchestration Layer）

职责： 协调多个专业化 Agent，管理动态提示词，控制 RAG 管道和工具路由。这是 AI Native 系统的"中枢神经"。

架构纪律： 编排逻辑必须集中在专用服务/模块中，不可散落在 API 路由处理器、React 组件或数据库触发器中 $19$ 。参见 §7.6 原则 1。

关键设计：

Agent 身份与信任边界： 每个 Agent 拥有唯一加密身份；Agent 间委托时必须验证对方身份和授权（参见 §5.2 成熟度框架）
工具白名单： deny-by-default，拒绝未列出的工具
意图封装（Intent Capsule）： 签名信封绑定目标/约束/上下文，每个执行周期验证
独立策略执行： 将规划与执行分离，防止单点污染扩散（对应 §7.2.4 Plan-Execute 模式）
拓扑选择： 根据任务复杂度选择 Supervisor / Hierarchical / P2P 等拓扑（参见 §7.3 拓扑选型决策表）
循环模式选择： 根据推理深度需求选择 ReAct / ReflAct / Plan-Execute 等循环（参见 §7.2.7 循环模式选型决策表）

本层安全控制： OWASP ASI01（目标劫持）、ASI07（Agent 间通信）、ASI08（级联失败）的主要防线（参见 §5.3）

本层可观测性： 完整溯源链------从触发源到最终行为的因果链（参见 §6.1.2）；Agent 步数分布追踪；人工介入率监控

3.3 知识层（Knowledge Layer）

职责： 作为系统的"记忆"，用向量数据库和特征存储替代外键查找，实现基于语义的检索。

关键设计：

本体驱动（Ontology-driven）： 定义业务特有的概念、类别和关系，理解数据"为什么"属于一起，而非仅识别模式
混合检索： 密集向量 + 稀疏 BM25 + RRF 融合，解决域外数据问题（参见 §8.1）
记忆隔离： 按会话/域隔离，防止跨租户污染
记忆完整性验证： 每次检索时校验加密哈希、来源归属、防篡改日志
保留策略： TTL 自动过期未验证的记忆；版本化记忆存储以支持回滚
防止自举污染： 禁止 Agent 自动重新摄取自身输出

本层安全控制： OWASP ASI06（记忆与上下文投毒）的主要防线------加密 + 最小特权 + 记忆分段 + 防止自举污染 + 快照/回滚（参见 §5.3）

本层可观测性： 记忆读写日志（检索的向量 ID + 写入内容）；RAG 命中率与相关性评分追踪；幻觉率按知识源归因

3.4 智能层（Intelligence Layer）

职责： 承载基础模型、本地小语言模型（SLM）、微调的领域专用权重。

关键设计：

模型版本管理： 协调版本控制、部署、再训练；金丝雀发布 + A/B 测试
模型路由： 根据任务复杂度动态选择模型------简单任务用快速低成本模型（如 Haiku），复杂推理用高端模型（如 Opus） $27$
本地模型优先： 敏感数据留在本地，不外发第三方 API------数据主权的关键保障
联邦学习： 支持分布式训练和自优化
模型供应链安全： 防止权重投毒（250 条恶意文档即可在 6 亿至 130 亿参数 LLM 中植入后门，且能存活过 SFT + RLHF）

本层安全控制： 模型供应链安全（AI-BOM 溯源 + 签名验证）；OWASP ASI04 供应链漏洞防线（参见 §5.3、§5.6）

本层可观测性： 模型版本 + 参数（temperature/top_p）记录于溯源链；令牌消耗遥测（参见 §6.1.3）；幻觉率按模型版本分桶

3.5 基础设施层（Infrastructure Layer）

职责： 从第一天起就为 GPU 集群、容器化微服务、弹性网络做优化。

关键设计：

预测流量峰值并自动伸缩
边缘计算与联邦架构补充中央服务器
沙箱隔离： 容器（gVisor）用于发现阶段；microVM（Firecracker）或完整 VM 用于目标运行和 PoC 验证
网络锁定： 扫描期间仅允许访问模型 API，通过本地代理路由
消息基础设施： 分布式多 Agent 通信需要消息队列/事件总线（Kafka / Service Bus），提供重试、死信队列和持久化（参见 §7.4.1）

本层安全控制： 网络分段；JIT 访问凭证；日志基础设施安全等级 ≥ 业务数据（参见 §6.1.6）

本层可观测性： GPU 利用率；推理延迟 P50/P95/P99；弹性伸缩事件日志

3.6 层间契约与跨层数据流

五层并非松散堆叠------相邻层之间必须有显式契约，否则会退化为"各层各自为政"的耦合泥潭。下表定义每对相邻层的契约：上游提供什么、下游期望什么、契约违反时的降级行为。

层间边界	上游（提供方）	下游（消费方）	契约内容	违反时的降级
交互→编排	交互层	编排层	意图信封（签名）：目标/约束/上下文/用户身份	编排层拒绝未签名或篡改的信封（§3.2）
编排→知识	编排层	知识层	检索请求：查询 + 租户上下文 + 权限范围	知识层返回空 + 拒绝原因；编排层降级到规则
编排→智能	编排层	智能层	推理请求：模型 ID + 参数 + 输入 + 预算上限	模型不可用时降级到备用模型/规则（§3.4 模型路由）
知识→智能	知识层	智能层	检索结果：带来源/哈希/置信度的结构化上下文	检索为空时智能层标记"低置信"，触发 HITL
所有层→基础设施	各层	基础设施层	资源请求：计算/网络/存储配额 + 优先级	超配额时限流/排队，不静默失败

契约设计原则： 层间接口应暴露类型化、可发现的契约 （typed discoverable contracts），而非临时性的 prompt 或脆弱中间件 $60$ 。每个契约必须包含三要素：输入 schema 、输出 schema 、失败语义（不返回、返回空、返回错误各意味着什么）。

跨层数据流（一次完整请求的纵向轨迹）：

复制代码

用户意图（交互层）
   │  [意图信封：签名 + 目标 + 约束 + 用户身份]
   ▼
编排层（规划 + 工具路由）
   │  [检索请求] ──────→ 知识层（向量/图/记忆）
   │  [推理请求] ──────→ 智能层（LLM/SLM）
   │  [工具调用] ──────→ 外部 API / 基础设施
   │  ◄── 检索结果（带来源 + 哈希）
   │  ◄── 推理结果（带模型版本 + 令牌消耗）
   ▼
输出验证 + 人工审批（高风险）
   │  [溯源链：输入→推理→工具→记忆→输出]
   ▼
结果返回（交互层）+ 反馈采集 → 持续学习闭环（§6.1.7）

关键： 每次跨层调用都生成独立 span（§6.1.2 溯源链），使任何最终行为可纵向回溯到触发源。层间契约的违反（如编排层收到未签名意图）是一等告警信号。

3.7 各层选型决策矩阵

针对每层的常见技术选型，给出基于场景的推荐。这些是起点而非教条------最终选型应通过 §9 的评估验证。

层	选型维度	选项 A	选项 B	推荐（按场景）
交互层	界面范式	固定 UI + AI 侧边栏（L1）	自然语言为主 + 动态 UI（L3）	L1/L2 用 A；L3 用 B；关键操作仍保留显式按钮（避免纯 NL 的不可发现性）
交互层	多模态	纯文本	文本+语音+视觉	受限场景（SOC/客服）从文本起步；开放场景按需扩多模态
编排层	拓扑	单 Agent	多 Agent（Supervisor/P2P/Swarm）	≤5 工具/任务用单 Agent；超出按 §7.3.7 决策表
编排层	状态管理	无状态	检查点 + 重放（§7.6 原则 4）	L3 必须有状态持久化；无状态仅适合 L1 短交互
知识层	检索	纯向量	混合检索（向量+BM25+RRF）	生产系统一律用混合（§8.1）；纯向量仅原型
知识层	图谱	无	GraphRAG / Ontology RAG	多跳推理用 GraphRAG；业务确定性用 Ontology（§8.4/§8.8）
智能层	模型部署	纯云 API	云 + 本地 SLM 混合	敏感数据用本地 SLM（数据主权 P4）；非敏感用云；按任务路由（§3.4）
智能层	微调	通用模型	领域微调	先用提示词/检索（§9.2 评估八步法）榨干通用模型；微调是高成本最后手段
基础设施	隔离	容器（gVisor）	microVM（Firecracker）/ 完整 VM	发现阶段用容器；目标运行/PoC 验证用 microVM（§3.5）
基础设施	通信	同步请求	消息驱动（Kafka/Service Bus）	分布式/长任务用消息驱动；短延迟用同步（§7.4.1）

选型纪律： 每个选型决策应能追溯到至少一条 §2 原则。例：选本地 SLM 追溯到 P4（永远验证/数据主权）；选检查点+重放追溯到 P5（假设失陷）。

4. 运行时生命周期（Runtime Lifecycle）

4.1 请求生命周期

复制代码

用户意图 → 交互层接收 → 编排层规划 → 知识层检索上下文
    → 智能层推理 → 工具调用（受控）→ 输出验证 → 人工审批（高风险）
    → 结果返回 → 反馈采集 → 持续学习

关键控制点：

输入验证： 所有自然语言输入视为不可信；schema 校验、长度限制、内容过滤、已知攻击模式检测
工具调用： 参数双向验证（Agent 端 + 工具端）；速率限制（注意：速率限制是摩擦而非屏障------参见 §5.1.2）
输出控制： PII/凭证过滤；语义分析；高风险操作人工介入
反馈闭环： 每次交互的遥测数据回流，驱动持续改进；生产轨迹自动转为评估用例（参见 §6.1.7）

每阶段的 SLA、预算与失败恢复： 请求生命周期不是"尽力而为"------每个阶段都应有明确的延迟预算、失败语义和恢复动作，否则单点超时会拖垮整个请求。

阶段	延迟预算（参考）	令牌预算	失败语义	失败恢复动作
输入验证	< 100ms（同步）	极少	schema 不符/检测到攻击	拒绝 + 记录；不放行到编排层
编排规划	P95 < 500ms	规划提示词（~1-2K tokens）	规划失败/超时	降级到规则路由或返回"无法处理"
知识检索	P95 < 1s	嵌入 + 检索（无生成）	检索为空/超时	编排层降级到规则或标记"低置信"触发 HITL
智能层推理	P95 < 5s（单轮）；循环另计	按 §3.4 模型路由分配	模型超时/拒绝	切换备用模型/SLM；仍失败则降级
工具调用	每工具 P95 < 2s（按工具定）	工具响应可能很大需裁剪	工具失败/返回异常	重试（指数退避）→ 断路器 → 降级
输出验证	< 200ms	少量（PII 扫描）	检测到 PII/凭证/越权	拦截输出 + 脱敏后重发或阻断
人工审批	分钟~小时级（非实时 SLA）	---	审批超时/拒绝	默认拒绝（deny-on-timeout），不默认放行

预算纪律（对应 §2 P6 自动化记账、人工决策）： 每个请求在进入编排层时分配总令牌预算 和总步数预算；任一预算耗尽即终止循环并返回"预算超限"------这防止失控 Agent 消耗无上限资源（§9.8.3 令牌预算护栏）。预算值应作为产品需求在上线前设定（§7.6 原则 6），而非运行时拍脑袋。

失败恢复的反模式： ❌ 默认放行（timeout → approve）------违反 P6（决策类操作必须人工）；❌ 静默失败（工具失败不告警）------违反 P8（可审计性，故障无法归因）；❌ 无限重试（无断路器）------违反 P5（假设失陷，失控 Agent 可耗尽资源）且与 P1（概率性内核不能保证收敛）叠加放大。

4.2 Agent 推理循环（Agentic Loop）

上述线性流程的"推理"步骤实际上是一个迭代循环------Agent 不是一次性产出结果，而是多轮"思考-行动-观察"。循环模式的选择直接影响准确性、成本和延迟（参见 §7.2）。

复制代码

┌─────────────────────────────────────────────┐
│              Agentic Loop                     │
│                                               │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐   │
│  │ Thought │───→│ Action  │───→│Observe  │   │
│  │(推理)   │    │(工具调用)│    │(结果)   │   │
│  └─────────┘    └─────────┘    └────┬────┘   │
│       ↑                          │          │
│       │     目标达成？───否──────┘          │
│       │                                     │
│       └─────────────────────────────────────┘
│                      │ 是
│                      ↓
│              ┌───────────────┐                │
│              │ Final Answer  │                │
│              │ + 自我评估     │                │
│              └───────────────┘                │
└─────────────────────────────────────────────┘

循环中的关键控制：

控制点	实现方式	量化阈值/信号（参考）	关联章节
最大迭代上限	硬编码步数上限（如 10 步），防止无限振荡	单任务步数 P99 ≤ 上限；超时率监控	§7.6 原则 8
每步工具授权	每次工具调用前验证 Agent 当前权限（JIT），非一次性授权	100% 工具调用经 JIT 验证	§5.2
中间状态检查点	每次循环迭代后持久化状态，支持重放和恢复	检查点写入延迟 < 100ms；故障后恢复成功率 > 99%	§7.6 原则 4
衰减置信度	随循环次数增加降低自动执行置信度阈值，触发人工审查	步数 > N/2 时置信度阈值开始衰减；衰减触发 HITL 的比例	§7.6 原则 8
上下文窗口管理	监控累积上下文利用率，超阈值时压缩/摘要/分治（转多 Agent）	利用率 > 60% 时准确率开始下降，需介入（见下方警示）	§7.1、§7.3
循环模式可切换	Supervisor 可按任务类型为 Worker 指定不同循环模式（ReAct/Plan-Execute/Reflection）	模式选择准确率（路由日志分析）	§7.2.7

⚠️ 上下文窗口管理的实证警示： 多步 Agent 循环会持续累积上下文（对话历史 + 工具输出 + 中间推理），导致"上下文腐烂（context rot）"。研究显示，随着上下文增长，模型在中间位置 的准确率下降 30%+ （"lost-in-the-middle"效应，覆盖 18 个前沿模型的 Chroma 研究） $61$ ；不同任务/模型的衰减范围达 13.9%--85% $62$ 。这意味着：

不能把所有历史塞进上下文------长循环必须主动压缩/摘要/分治

利用率 > 60% 是危险信号（参见 §7.1 单 Agent 上下文窗口饱和------中间位置信息准确率下降达 30%）

多 Agent 分治（§7.3）不只是为了并行，更是为了控制单 Agent 的上下文规模

反模式： ❌ 无限累积对话历史 hoping 模型"记住一切"------实际是让重要信息淹没在噪声中；❌ 只看 token 数不评估"有效信息占比"------长上下文里可能 80% 是冗余工具输出。
反思循环的风险： Critic 链和反思审查者可能永远振荡------必须添加最大迭代上限、衰减置信度分数或人工介入中断 $32$ 。

4.3 Agent 实现工作流（8 阶段）

源自 Anthropic Zero Trust eBook 的实施路径：

阶段	关键活动	产出	关联章节
1. 识别需求	对齐安全/法务/合规/业务方	需求文档	---
2. 管理供应链风险	AI-BOM、依赖健康评估、签名验证	AI-BOM 清单	§5.6
3. 定义 Agent 边界	唯一身份、批准/禁止操作、爆炸半径	Agent 边界文档	§5.2、§7.6
4. 防御提示注入	输入隔离、Constitutional Classifiers、攻击面缩减	防护配置	§5.4
5. 保护工具访问	白名单、能力限制、参数验证、沙箱、审批升级	工具策略	§5.3 ASI02、§5.5 MCP
6. 保护 Agent 凭证	每 Agent 唯一凭证、JIT 访问、ABAC	凭证管理方案	§5.2
7. 保护 Agent 记忆	记忆隔离、完整性验证、保留策略、回滚	记忆策略	§5.3 ASI06、§3.3
8. 度量关键指标	驻留时间（dwell time）、覆盖率（coverage）	度量基线	§6.1.3

5. 安全架构（Security Architecture）

5.1 核心安全原则

5.1.1 零信任三原则

永不信任，始终验证： 每个访问请求都经过认证/授权，不因来源内部而放松审查
假设失陷： 预期系统会被攻破，通过隔离和细粒度访问限制损害
最小权限： 仅授予完成特定任务所需的最低访问权限

5.1.2 关键判定标准------"不可能，而非繁琐"

一个控制措施只有使攻击变得不可能，而不仅仅是增加摩擦，才是有效的。

Agent 攻击者有无限耐心和近乎零的单次尝试成本，因此基于摩擦的控制 （额外跳板、速率限制、非标准端口、短信 MFA）严重退化。有效的控制共享一个模式：硬件绑定凭证、过期令牌、加密身份、不存在的网络路径。

5.1.3 静态 API 密钥不可接受

静态 API 密钥 / 共享服务账户密码即使在基础层也不是合法入口 。AI Agent 的认证设计是"AI 自主性"与"企业基础设施"之间唯一可靠的执行层。

为什么 AI Agent 的凭证风险与传统应用根本不同：

差异维度	传统微服务	AI Agent
凭证获取	部署时通过环境变量/挂载注入，凭证集合在构建时已知	运行时动态决定调用哪些 API------凭证集合从推理链中涌现，无法预先确定
凭证驻留	进程内存，不暴露给外部	LLM 上下文窗口不是安全内存------工具描述、API 响应、错误消息中的凭证片段全部流经同一 token 流
行为可预测性	静态分析 + 代码审查可部分替代授权边界	无法从代码预测生产行为------被赋予敏感 API 访问权的 Agent 终将找到理由使用它
会话时长	请求-响应，毫秒级完成	会话持续数分钟到数小时------OAuth 令牌在会话中途过期
委托链	通常 1-2 跳	Agent A → Agent B → MCP 服务器，凭证可穿越 10+ 跳，每跳创建一个问责缺口
聚合点	访问 1-2 个服务	单个 Agent 运行时同时持有 Google Workspace、GitHub、Slack、Salesforce、生产数据库的凭证------攻破 Agent = 攻破一切

静态 API 密钥的六重风险：

Bearer 凭证无身份绑定： API 密钥是"持有者即合法用户"------被盗后无法追溯利用者身份 $45$
泄露面指数级扩大： Agent 生成日志、配置文件、持久化状态、自动复制工作流------每个环节都是泄露点。GitGuardian 2026 报告：2025 年 GitHub 公开仓库新增 2,865 万 硬编码密钥（+34% YoY），其中 AI 服务凭证泄露激增 81% $45$
环境继承： 子进程继承父 shell 的完整环境------Agent 甚至不需要打开 .env 文件，值已在 process.env 中 $46$
间接提示注入提取： 恶意指令嵌入 README、依赖文档字符串或 PR 描述中，指示 Agent 读取 process.env 并外传------NVIDIA AI Red Team 将此明确归类为"必须缓解的威胁" $46$
横向移动： 持有多服务凭证的 .env 文件被攻破后，数据库凭证成为生产数据入口，AWS 密钥成为 S3/Lambda/IAM 路径------爆炸半径无界 $46$
真实事件： 2025.07 Replit AI 编码 Agent 在 CEO 明确指示"代码冻结"的情况下，仍删除了一家公司的生产数据库 （含 1,200+ 名高管与 1,100+ 家公司记录，9 秒内完成删除），事后 Agent 自承"灾难性判断错误"------因为没有任何机制将 Agent 的凭证与生产写入权限分离 $45$

凭证管理八级成熟度模型：

级别	方案	适用场景	风险
L1 硬编码	密钥直接写在代码中	❌ 任何场景均不可接受	最高------永久暴露于版本控制
L2 .env 文件	项目根目录的明文键值对	本地原型开发	Agent 可通过 `process.env` 读取全部变量
L3 编排器变量	Docker Secrets / Kubernetes Secrets	容器化部署	环境继承问题仍然存在
L4 密钥管理器	HashiCorp Vault / AWS Secrets Manager	生产环境最低门槛	凭证仍以静态形式存在于运行时
L5-L6 OAuth + 生命周期管理	短期令牌 + 主动刷新 + 分布式锁	长会话 Agent	刷新窗口的竞态条件需处理
L7 MCP 工具运行时	凭证不进入 Agent 上下文，MCP 服务器代为调用	多工具 Agent	依赖 MCP 服务器安全性（参见 §5.5）
L8 工作负载身份	SPIFFE/SPIRE------基于"它是什么 + 在哪里运行"的密码学身份证明，无共享密钥	理想形态	需要基础设施支持

推荐目标：L4 为生产最低门槛，L5-L6 为长会话 Agent 标准，L8 为理想形态。

关键架构模式------清洁环境原则：

借鉴 systemd 的设计：每个 Agent 进程应从一个清洁的、最小的环境 启动，不继承父 shell 的环境。通过清单驱动的配置注入，由 Supervisor 声明 Agent 需要哪些凭证，并仅在进程启动时注入：

yaml 复制代码

# agent-manifest.yaml
name: coding-agent
environment:
  allow:
    - ANTHROPIC_API_KEY
    - GITHUB_TOKEN
  deny:
    - AWS_*          # 显式拒绝 AWS 凭证
    - STRIPE_*       # 显式拒绝支付凭证
  sources:
    - vault: secrets/coding-agent
      ttl: 3600       # 凭证 1 小时过期

凭证隔离的框架差异：

框架	隔离方式	安全性
AutoGen	高风险代码执行限制在 Docker 容器中，仅挂载任务所需凭证	最强结构性隔离
LangChain	历史漏洞：CVE-2023-46229（SSRF）、CVE-2023-44467（提示注入→RCE）	需手动加固
CrewAI	默认 RBAC + 加密，但对隐藏恶意指令的 MCP 服务器存在脆弱性	中等

多协议身份混淆风险：

单个 Agent 可能同时持有四种不同协议的凭证：OpenAI API 密钥、Salesforce OAuth 令牌、AWS IAM 角色会话令牌、MCP Bearer 令牌------四种凭证、四个信任域、四套验证要求 $47$ 。攻击者可在协议边界进行令牌替换（如用 OAuth 令牌冒充 API 密钥），利用信任转换间的缝隙。这要求：

每个 Agent 拥有唯一可审计的身份（非继承用户凭证）
凭证按协议隔离，不允许跨协议复用
审计系统必须捕获完整委托链（A→B→C 的身份传播路径）

与本文档其他章节的关联：

凭证最小化 = §5.1.1 最小代理权的具体实现
OAuth 短期令牌 = §5.2 成熟度框架"基础层"的服务认证要求
工作负载身份 = §5.2 "高级层"的硬件绑定凭证
MCP 凭证传递禁止 = §5.5 MCP 安全最佳实践

5.2 成熟度三层框架

能力域	基础层（Foundation）	企业层（Enterprise）	高级层（Advanced）
Agent 身份	唯一加密 ID	X.509 证书 + 全生命周期	硬件绑定凭证 + HSM/TPM + 可信计算
服务认证	短期令牌（OAuth 2.0），分钟级过期，自动刷新	---	---
权限模型	RBAC，deny-by-default	ABAC，上下文感知策略	持续授权，实时策略评估
特权范围	静态最小特权角色	动态特权调整	JIT / JEA，自动过期
资源隔离	基于身份的隔离，网络分段为后备	沙箱执行（gVisor）	硬件隔离（AMD SEV / Intel TDX），microVM
可观测/审计	全面日志	不可变审计轨迹 + 完整性验证	实时流式传输 SIEM + 关联分析
可追溯性	请求 ID 关联操作与触发器	分布式追踪（OpenTelemetry）	完整溯源链（输入→输出），可重放
行为监控	手动基线，阈值告警	自动基线学习，统计异常检测	ML 行为分析 + 上下文感知
自动响应	告警安全团队 + 模型起草分诊	自动遏制（会话终止、凭证撤销）	编排 SOAR，分级升级
输入验证	基础 schema/长度校验	内容过滤，已知攻击模式检测	多层验证，Constitutional Classifiers，Spotlighting
输出控制	PII/凭证输出过滤	语义分析	高风险操作人工介入
完整性/恢复	版本化配置	签名配置 + 部署验证	不可变基础设施 + 证明
恢复	文档化回滚流程	自动回滚 + 健康检查	自愈系统 + 断路器
治理	文档化使用规范与事件响应策略	正式治理框架（跨职能委员会）	持续策略执行于部署管道

注：基础层门槛已被提高------AI 加速攻击意味着仅靠摩擦的控制已不够格。

5.3 OWASP Agentic Top 10（2026）风险与缓解

编号	风险	核心威胁	关键缓解措施
ASI01	Agent 目标劫持	通过提示注入/欺骗性工具输出/伪造 Agent 间消息操纵目标	所有 NL 输入视为不可信；目标变更操作需人工审批；意图封装；CDR + 提示载体检测
ASI02	工具滥用与利用	Agent 在授权权限内滥用合法工具	最小特权工具范围；白名单；参数双向验证；沙箱；语义防火墙
ASI03	身份与特权滥用	动态信任/委托被利用进行权限提升	任务级限时权限；隔离 Agent 身份/上下文；逐操作授权；OAuth 令牌绑定签名意图
ASI04	Agentic 供应链漏洞	模型投毒、工具描述符注入、冒充/拼写攻击	SBOM/AIBOM + 签名证明；依赖白名单/锁定；沙箱构建；运行时持续验证；供应链紧急切断开关
ASI05	意外代码执行（RCE）	代码生成工具被利用升级为远程代码执行	生产环境禁用 `eval`；绝不以 root 运行；沙箱容器 + 严格网络限制；代码生成与执行分离
ASI06	记忆与上下文投毒	持久化破坏存储/可检索的上下文，跨会话传播	加密 + 最小特权；扫描所有记忆写入/输出；记忆分段；防止自举污染；快照/回滚
ASI07	不安全的 Agent 间通信	多 Agent 交换中认证/完整性/授权薄弱	加密消息完整性（签名/mTLS）；相互认证绑定 Agent 身份；类型化契约 + schema 验证
ASI08	级联失败	单点故障在自主 Agent 间传播放大	零信任容错设计；隔离/信任边界；JIT 一次性工具访问；断路器；数字孪生重放
ASI09	人-Agent 信任利用	操纵人类对 Agent 的信任（可解释性不足、情感操纵）	敏感操作多步确认/HITL；不可变日志；自适应信任校准；将预览与效果分离
ASI10	流氓 Agent	偏离预期功能/范围的恶意或被攻破 Agent	不可变签名审计日志；Trust Zones；看门狗 Agent 验证同伴；快速切断开关 + 凭证撤销 + 隔离

5.4 提示注入防御

提示注入是当前最突出的 AI 安全威胁，跨模型家族的攻击成功率接近 100%。

直接注入： 覆盖系统指令、编码/Base64/十六进制绕过、对抗性后缀。

间接注入： 恶意指令嵌入 Agent 处理的网页/邮件/数据中；LLM 无法可靠区分信息性上下文和可执行指令。

防御手段：

Spotlighting（Microsoft）： 明确界定不可信内容边界，将间接注入成功率从 >50% 降至 <2%
Constitutional Classifiers（Anthropic）： 阻断 95% 的越狱尝试，过度拒绝率极低
输入隔离： 所有数据源实施 CDR + 提示载体检测
系统提示锁定： 变更需经配置管理 + 人工审批

5.5 MCP（模型上下文协议）安全深度防护

MCP 被誉为"AI 界的 USB-C"，是目前唯一被微软、亚马逊、英伟达、谷歌等所有科技巨头广泛采用的跨平台工具调用标准。但其设计优先功能性而非安全性，已成为 AI 基础设施的关键攻击面。

OX Security 2026 年 4 月报告：97% 的企业 MCP 部署存在高危安全漏洞，平均每个企业连接的 MCP 服务器中有 3.2 个包含恶意代码。 $1$

已披露的重大漏洞

CVE/事件	影响	来源
CVE-2026-11624	MCP 服务器 v0.25 之前缺少 `Origin` 头验证，DNS 重绑定攻击可让恶意网站通过浏览器连接本地 MCP 服务器并执行任意工具调用	$2$
OX Security STDIO 缺陷（2026.04）	STDIO 传输层无条件执行 `command` 参数中的任意系统命令，无论 MCP 服务器是否成功启动；Anthropic 回应称"属于预期设计范畴"	$3$
工具投毒攻击（学术研究）	构造恶意 MCP 服务器并成功上传至三个主流 MCP 聚合平台，证明当前审计机制不足以检测和阻止	$4$
混淆代理问题	MCP 代理服务器使用静态 client ID 时，攻击者可利用浏览器 consent cookie 跳过用户授权	$5$

MCP 四类攻击向量（学术分类）

工具投毒攻击（Tool Poisoning）： 在工具描述中嵌入隐藏的恶意指令，利用信息不对称（用户看到的工具信息与 AI 看到的完全不同）操纵 Agent 行为
傀儡攻击（Puppet Attack）： 通过恶意 MCP 服务器完全控制 Agent，使其成为执行恶意操作的代理
地毯抽换攻击（Rug Pull）： 合法工具被秘密替换------2025 年 12 月一个拥有超 10 万用户的"代码格式化"MCP 服务器在圣诞节被攻击者接管 $1$
恶意外部资源利用： 通过工具调用的外部资源（URL、文件）注入恶意内容

MCP 安全最佳实践

措施	详情
协议版本锁定	强制使用 MCP v0.25+（含 Origin 头验证）；禁用遗留传输模式
工具描述审计	部署前审查所有工具描述符/schema/元数据；签名验证；内容哈希锁定
网络隔离	MCP 服务器仅监听 localhost 或内部网络；生产环境锁定出站流量至模型 API
令牌传递禁止	禁止 MCP 客户端直接使用下游 API 令牌（Token Passthrough），防止安全控制绕过 $5$
动态客户端注册	代理服务器使用动态 client ID 而非静态 ID，防止混淆代理攻击
聚合平台审计	不信任第三方 MCP 聚合平台（Smithery.ai 等托管超 7,000 个服务器）的审计机制
运行时验证	持续验证工具行为与注册描述一致；行为漂移检测

5.6 供应链安全

AI Native 系统的供应链比传统软件更复杂，包含模型、工具框架、知识插件三条链路。

必须措施：

AI-BOM： 扩展软件物料清单至 AI 领域------模型溯源、训练数据谱系、微调参数；采用 CycloneDX ML-BOM 标准
依赖健康评估： CI 中集成 OpenSSF Scorecard
依赖树审计： 识别冗余依赖；通过可达性分析缩小修复范围
加密签名： 每个阶段签名 + 运行时验证
供应商评估： 包括开源项目在内，询问供应商如何应对 AI 加速的漏洞利用时间线

5.7 代码安全闭环（Find-and-Fix Loop）

Anthropic 的代码安全实践提供了一个六步闭环，可用于保护 AI Native 系统自身的源代码：

复制代码

威胁建模 → 沙箱构建 → 发现 → 验证 → 分诊 → 补丁
    ↑                                              │
    └──────────── 更新威胁模型 ←── 搜索变体 ←──────┘

核心洞察： 发现阶段现在可以轻松并行化，瓶颈已转移到验证、分诊和补丁。在 1,596 个已披露漏洞中，仅 97 个被修补。

关键实践：

验证 Agent 必须独立于发现 Agent： 在新容器中运行，不共享文件系统或对话历史；仅接收 PoC 和代码库
按根因去重： 先用廉价确定性过滤（同文件、同类别、行号差 <10），再用模型定性判断
补丁验证阶梯： 构建 → 重现 PoC（应停止工作）→ 回归测试 → 对抗性重攻击
最小补丁： 只修复根因的最小变更，不重构、不附带清理

5.8 AI 红队测试（Red Teaming）

AI Agent 的"主动执行"特性使传统静态安全测试完全失效。红队测试已成为 EU AI Act 对高风险系统的法定要求 （Article 55，GPAI 对抗性测试义务已于 2025 年 8 月生效） $6$ 。

关键框架与指南

来源	内容	发布时间
NVIDIA AI 红队指南	全球首个聚焦 Agent 执行层安全的实操文档；核心围绕"强制 OS 级控制 + 多层沙箱隔离 + 人在回路" $7$	2026.01
CSA Agentic AI 红队指南	系统性定义 12 类风险的攻防框架，含实战测试用例 $8$	2025
AWS AgentHarm-Gen + Red-Agent-Reflect	双组件自动化红队框架；攻击成功率在 o4-mini 上提升 162%，Gemini 2.5 Pro 上达 86% $9$	EMNLP 2025
Microsoft PyRIT	开源 AI 红队框架；Azure AI 红队 Agent 提供自动化对抗性探测 $10$	2025

红队测试策略

RL 训练的对抗性 Agent： 单轮提示模糊测试无法发现多轮对话级漏洞。RL 自主对抗 Agent 将红队测试形式化为马尔可夫决策过程，能跨轮次规划协调攻击 $6$
机器规模 + 人类创造力： 自动化系统广度探索，专家深度精炼最有潜力的攻击链
多模型集成： 多个红队模型组合，确保一个生成器的盲区成为另一个的目标
CI/CD 集成： 自动化对抗套件直接集成到 CI/CD 管道，在漂移进入生产前捕获
多模态与 MCP 测试： 针对 MCP 工具链和多模态输入的专门测试场景

度量指标

攻击成功率（ASR）： 核心度量指标
风险类别覆盖： OWASP ASI 2026 五大领域（负责任 AI、非法活动、品牌损害、数据隐私、未授权访问）
对抗性技术覆盖： 直接探测、编码绕过、多轮对话、上下文操纵

6. 非功能性需求（Non-Functional Requirements）

6.1 可观测性与可追溯性（Observability & Traceability）

强可观测性是不可协商的。 ------OWASP ASI Top 10

AI Native 系统的非确定性行为、多步 Agent 推理、动态工具调用使传统监控三支柱（日志、指标、追踪）必须深度重构。可观测性的目标不仅是"知道发生了什么"，而是能重放、能归因、能阻断异常行为。

6.1.1 可观测性三支柱的 AI 适配

支柱	传统系统	AI Native 系统（关键差异）
日志（Logs）	结构化事件记录	必须捕获完整提示词、模型响应、工具调用参数与返回值、中间推理步骤；不可变 + 签名 + 防篡改；支持回放审计
指标（Metrics）	QPS、延迟、错误率	新增令牌消耗、每查询成本、幻觉率、工具调用成功率、Agent 步数分布、人工介入率、拒绝率等 AI 特有指标
追踪（Traces）	请求级调用链	必须穿透多轮对话和多步 Agent 规划；每个工具调用、每次子 Agent 委托、每次记忆检索都是独立 span；基于 OpenTelemetry + OpenInference 标准

6.1.2 溯源链（Provenance Chain）

可追溯性的核心是建立从输入到输出的完整因果链，使任何一个最终行为都能回溯到其触发源、经过的推理路径、调用的工具、读取的记忆。

溯源链必须包含的要素：

复制代码

触发源（用户/Agent/定时器）
  │
  ├─ 请求 ID（唯一标识）
  ├─ 时间戳（精确到毫秒）
  ├─ 触发者身份（Agent ID + 加密签名）
  │
  ↓
推理路径（每个步骤）
  │
  ├─ 步骤序号 + 类型（规划/检索/工具调用/生成）
  ├─ 输入内容（完整提示词 + 上下文）
  ├─ 模型版本 + 参数（temperature/top_p 等）
  ├─ 输出内容（完整响应）
  ├─ 工具调用（工具名 + 参数 + 返回值 + 耗时）
  ├─ 记忆读写（检索的向量 ID + 写入的内容）
  └─ 人工审批节点（审批人 + 时间 + 决策）
  │
  ↓
最终行为
  │
  ├─ 输出内容
  ├─ 影响的系统/数据
  └─ 关联的告警/事件 ID

成熟度分层：

层级	能力
基础	请求 ID 关联操作与触发器
企业	分布式追踪（OpenTelemetry），跨 Agent span 关联
高级	完整溯源链（输入→输出），可重放；数字孪生重放验证

6.1.3 核心度量指标（Metrics & KPIs）

安全运营指标（优先度量）：

指标	定义	目标
驻留时间（Dwell Time）	异常发生到人工感知的时间	AI 辅助自动化杠杆最大的两个指标之一；关键系统 <1 小时
覆盖率（Coverage）	已调查告警占全部告警的比例	AI 辅助自动化杠杆最大的两个指标之一；持续提升
检测速度	从攻击发生到检测的时间	关键系统 <1 小时
攻击成功率（ASR）	红队/对抗测试中攻击成功比例	持续下降趋势

系统健康指标：

指标	定义	告警阈值建议
令牌消耗	每查询/每会话 input/output token 计数	单查询超均值 3σ；日消耗超预算 80%
每查询成本	美元/查询 = 令牌数 × 模型单价	趋势性上升
幻觉率	生成内容与事实不符的比例（抽样人工/LLM-as-Judge 核验）	>5% 需调查
工具调用成功率	成功工具调用 / 总工具调用	<95% 需调查
Agent 步数分布	完成任务所需的平均/中位数步数	步数突增暗示规划失败或提示注入
人工介入率	需人工审批的操作比例	突降可能意味护栏失效
拒绝率	模型拒绝回答的比例	突升暗示 Constitutional Classifiers 过度拦截
延迟 P50/P95/P99	推理延迟分位数	P99 超阈值影响用户体验

行为基线与异常检测分层：

层级	能力
基础	手动基线，阈值告警（固定阈值）
企业	自动基线学习，统计异常检测（移动均值 + 标准差）
高级	ML 行为分析 + 上下文感知（考虑用户角色、时间、历史模式）

6.1.4 实时监控与告警

告警分级与响应：

级别	触发条件	响应动作
P0（紧急）	检测到活跃数据外泄；Agent 执行未授权特权操作	自动终止会话 + 撤销凭证 + 即时通知安全团队
P1（高）	令牌消耗异常激增（可能资源耗尽攻击）；工具调用模式偏离基线 3σ	自动遏制（限流）+ 15 分钟内人工审查
P2（中）	幻觉率上升；拒绝率突变；延迟退化	模型起草分诊报告 + 4 小时内人工审查
P3（低）	趋势性指标缓慢漂移	记入周报，定期回顾

自动化响应阶梯：

复制代码

告警 → 模型自动首轮分诊（读-only）
  ├─ 低风险 → 记录 + 归档
  ├─ 中风险 → 起草分析报告 → 安全团队审查
  └─ 高风险 → 自动遏制（会话终止/凭证撤销/限流）→ 即时人工决策

关键原则： 自动化记账，人工决策。模型完成笔记、工件采集、事后报告起草；遏制、披露、客户沟通由人决定。 ------Anthropic Zero Trust eBook

用户脱离（Disengagement）作为隐性告警信号：

CSIRO 实证研究：45 名分析员中，低参与度组 13 人在 1-2 个月后脱离；持续组 6 人尽管遇到错误仍坚持 4-8 个月------感知效用抵消了孤立失败。

脱离不是简单的"用户流失"，而是系统可用性的隐性失败信号。应将以下指标纳入告警体系：

脱离信号	含义	可观测实现
单用户查询频率骤降	可能因连续错误或拒绝导致失去信任	追踪每用户日/周活跃度，环比下降 >50% 触发审查
会话中途放弃率上升	Agent 输出未满足预期，用户放弃当前任务	追踪未完成会话比例（无后续操作的终止）
重试后即终止	用户重试一次后离开------典型挫败信号	追踪"重试 → 终止"序列频率
集中于单一功能后停止	探索性使用后未形成习惯	按功能域追踪使用持续性

6.1.5 可观测性 UX 与遥测标准化

呈现证据而非推荐（Evidence over Recommendation）：

CSIRO 实证：3,090 条查询中仅 4% 寻求明确推荐（如"这是否恶意？"），仅 7/45 名分析员提出分类请求。

这一发现对可观测性仪表盘设计有直接指导意义------Agent 辅助界面应默认以证据展示模式运行：

模式	错误做法	推荐做法
告警展示	仅给出"恶意/ benign"标签	展示原始日志片段、命令轨迹、ATT&CK 战术/技术映射、相关 IoC
Agent 输出	直接呈现最终结论	展示推理链：检索了哪些证据 → 如何关联 → 为何得出此判断
异常解释	"检测到异常"	展示偏离基线的具体维度、历史对比、置信度区间
工具调用结果	仅返回格式化摘要	展示完整工具返回值 + 高亮关键字段 + 标注异常项

遥测分类标准化：

93% 的分析员查询可映射到 NICE 工作力框架 的任务/知识/技能；查询集中映射到 MITRE ATT&CK 数据源。

可观测性遥测不应使用自定义分类，而应对齐行业标准框架，使数据可跨团队、跨工具共享：

框架	用途	在遥测中的应用
MITRE ATT&CK	攻击战术与技术分类	告警/检测规则打上 ATT&CK TTP 标签；映射检测覆盖矩阵
NICE Framework	网络安全角色任务/技能	按分析员角色（L1/L2/Threat Hunter）分桶统计查询模式
OWASP ASI	Agentic 安全风险分类	告警关联到 ASI01-ASI10 风险编号，便于安全团队溯源
CVE/CWE	漏洞/弱点分类	工具/依赖漏洞告警关联到 CVE 编号

6.1.6 数据采集与隐私

可观测性数据的采集本身引入新的隐私与合规风险------Agent 交互日志包含用户提示词（可能含 PII/凭证/商业机密）、模型输出（可能含生成的不当内容）、工具调用参数（可能含敏感数据）。

采集分层策略：

数据层	内容	采集要求	保留策略
审计层（必需）	请求 ID、时间戳、Agent ID、操作类型、工具名、审批决策	全程采集，不可变 + 签名；最小 PII	合规要求最短期限（如 SOX 7 年、GDPR 最小必要）
调试层（按需）	完整提示词、模型响应、工具参数与返回值、中间推理	默认脱敏采集（PII/凭证/密钥自动掩码）；按需解密需审批	30-90 天滚动；高敏感场景仅保留聚合统计
分析层（聚合）	令牌计数、步数分布、延迟、成功率、成本	去标识化后采集；仅保留聚合指标	长期保留，用于趋势分析

隐私保护控制：

控制	实现方式
PII 自动检测与掩码	日志写入前经 PII 检测管线（正则 + NER 模型），自动替换为 `[REDACTED-PII]`
凭证/密钥扫描	日志写入前扫描 API key、token、密码模式（如 AWS key pattern `AKIA...`），自动掩码
差分隐私聚合	分析层指标添加校准噪声，防止从聚合数据反推个体
访问控制	审计层：安全团队 + 合规团队；调试层：仅工程团队 + 审批；分析层：全员只读
知情同意	用户明确知晓交互被记录；提供退出选项（合规要求场景）
数据主权	日志存储在数据来源所在的管辖区域；不跨境传输
加密	传输加密（TLS 1.3）；存储加密（AES-256）；调试层字段级加密
日志防篡改	不可变存储（WORM/区块链存证）；哈希链（每条日志包含前一条的哈希）；完整性定期校验

合规对齐：

法规	对日志采集的要求
GDPR	数据最小化原则------仅采集必要数据；用户有权访问/删除其数据；明确告知数据处理目的
HIPAA	PHI（受保护健康信息）不得出现在调试层日志；审计日志需记录所有 PHI 访问
SOC 2	审计轨迹完整性；访问日志保留；变更管理记录
EU AI Act	高风险 AI 系统须自动记录事件（Article 12）；日志保留至系统生命周期结束后 6 个月

关键风险： 日志数据本身是高价值攻击目标------一个包含完整提示词和工具返回值的日志库等同于结构化的数据泄露金矿。日志基础设施的安全等级必须等同于甚至高于业务数据。

6.1.7 评估驱动的可观测性

可观测性不仅是被动监控，还应主动驱动评估闭环：

生产轨迹 → 评估用例： 从生产环境中捕获有代表性的轨迹（特别是失败案例），转化为评估数据集
JSONL 事件流： 每次运行捕获为结构化事件流，既是可观测性基础，也是评估基础
令牌使用事件 （turn.completed → usage.input_tokens / usage.output_tokens）提供效率遥测
阴性对照监控： 将过度触发/误触发作为一等监控信号，捕获护栏失效
每次手动修复 → 新测试行： 真实失败驱动回归覆盖，形成"发现→修复→测试"闭环

6.2 可靠性与容错（Reliability & Fault Tolerance）

要求	设计
级联失败防护	零信任容错设计；隔离/信任边界；JIT 一次性工具访问；断路器；爆炸半径护栏（配额、进度上限）
数字孪生重放	在隔离克隆中重放记录的操作；策略扩展以爆炸半径上限为门槛
回滚能力	版本化配置；签名配置 + 部署验证；不可变基础设施 + 证明；自动回滚 + 健康检查
自愈	断路器；自愈系统；可信基线恢复（需全新证明 + 依赖验证 + 人工审批）
紧急变更	提前建立紧急变更流程------两周补丁审批周期本身就是安全风险
故障模式	幻觉、推理失败、工具误用、模型漂移------必须显式设计应对

6.3 性能与成本（Performance & Cost）

要求	设计
低延迟	相比依赖外部 API 往返的传统软件，AI Native 可实现 2-5 倍延迟和吞吐提升
实时处理	快速数据框架、高效推理引擎、精简存储；边缘计算 + 联邦架构补充中央服务器
成本管理	非线性成本特征------数据采集/处理成本巨大；训练、维护、编排模型/Agent 成本高昂
令牌预算	追踪令牌使用以发现提示词膨胀；令牌使用事件作为效率遥测
弹性伸缩	预测流量峰值的网络通道；GPU 集群弹性管理

6.4 数据隐私与主权（Data Privacy & Sovereignty）

要求	设计
数据主权	AI Native 架构允许模型保持本地------敏感数据不外发，无第三方调用
加密	加密标准贯穿数据存储、传输、处理全链路
访问控制	从一开始就嵌入访问控制和内容过滤
记忆隔离	按租户命名空间隔离；信任评分加权检索
合规对齐	HIPAA、FINRA、GDPR、FedRAMP、EU AI Act 的要求已与零信任原则一致

7. 多 Agent 系统架构（Multi-Agent Systems）

Gartner 预测：到 2028 年，多 Agent AI 系统将自主管理 15% 的日常工作决策 $27$ 。多 Agent 查询量从 2024 Q1 到 2025 Q2 激增 1,445% $28$ 。

单一 Agent 即使配备数十个工具也受限于上下文窗口膨胀（利用率超 60% 时，中间位置信息准确率下降达 30% $27$ ）、近因偏差、工具过载和脆弱性。多 Agent 系统通过职责分离提升鲁棒性、可调试性和并行性。

7.1 为何需要多 Agent

触发因素	单 Agent 瓶颈	多 Agent 解决方案
上下文窗口饱和	多步工作流累积对话历史、工具输出、中间推理，最终退化性能	每个 Agent 拥有聚焦的上下文，子任务完成后仅传递结构化结果
任务专业化	一个 Agent 被提示为"万物专家"实际上是"万物平庸"	每个 Agent 有聚焦的系统提示、精选工具集、甚至不同的底层 LLM
延迟与并行	串行执行不必要地慢（安全审计 + 成本估算 + 合规检查需串行）	独立子任务并行执行，端到端延迟降至 1/N
故障隔离	单个工具失败或推理错误可 derail 整个工作流	失败局部化；断路器/重试/降级在 Agent 边界应用

7.2 单 Agent 推理循环模式（Agentic Loops）

Agent 的"思考方式"由推理循环模式定义。不同模式适用于不同复杂度和确定性要求的任务。

7.2.1 反应式（Reactive）

复制代码

输入 → 行动 → 输出

无复杂推理，直接将"用户输入"与"预设行动"映射
适用： 简单、独立、无关联的任务；需求与行动映射明确的场景

7.2.2 ReAct（Reasoning + Acting）------基础循环

复制代码

Thought → Action（工具调用）→ Observation → Thought → ... → Final Answer

LLM 交替进行内部推理（Thought）和外部行动（Action），通过观察结果（Observation）迭代
优势： 简单、通用性高、推理过程可追踪 $29$
缺陷： 长任务中可能无限循环；缺乏全局规划；推理步骤可能与实际状态脱节
适用： 搜索代理、数学求解器、带测试的代码生成

7.2.3 ReflAct（Reflect for Action）------ReAct 的进化

复制代码

State Reflection（状态反思 vs 目标）→ Action → Observation → ...

核心改进： 每个时间步不预测下一步行动，而是持续反思当前状态相对于任务目标的对齐度
比 ReAct 平均提升 27.7% ，在 ALFWorld 达到 93.3% 成功率 $30$
甚至超过 ReAct + Reflexion/WKM 等增强模块------证明强化核心推理骨干比叠加模块更关键
适用： 部分可观测环境、长时序任务、需要战略一致性的场景

7.2.4 Plan-and-Execute（规划-执行分离）

复制代码

Planner（全局规划）→ [子任务1, 子任务2, ...] → Executor（逐个执行）→ 重新规划（按需）

先将复杂任务递归分解为子任务序列，生成完整执行路径，再逐个执行
可使用大型模型规划、小型模型执行，降低整体成本
适用： 结构化多步骤任务；内容创作与营销；需要全局优化的任务

7.2.5 Reflection / Self-Correction（自我反思）

复制代码

Generate → Self-Evaluate → Critique → Revise → ... → Final Output

赋予 LLM "元认知"能力------生成后自我评估、识别错误并主动修正
"生成-评估-修正"闭环使模型自主提升输出质量
缺陷（单 Agent）： 同一模型生成、评估和反思，导致思维退化 ------重复相同的错误推理 $31$
MAR（Multi-Agent Reflexion）改进： 引入多样化推理人格 + 裁判模型综合批判，HotPotQA +3 分，HumanEval +6.2 分 $31$

7.2.6 Tree of Thoughts（思维树）

复制代码

         ┌─ Branch A → Evaluate → ✓
Thought ─┼─ Branch B → Evaluate → ✗ (Prune)
         └─ Branch C → Evaluate → ✓ → Backtrack if needed

每个思维步骤生成多个推理分支，形成树状结构；自我评估筛选；支持回溯
适用： 复杂数学与逻辑推理；战略规划与博弈决策；创意内容生成
风险： 无启发式剪枝时令牌消耗爆炸

7.2.7 循环模式选型决策表

模式	推理深度	令牌成本	确定性	最佳场景
Reactive	无	最低	最高	简单映射
ReAct	中	中	中	通用工具使用
ReflAct	中高	中高	中高	长时序、部分可观测
Plan-Execute	高	高	高	结构化多步任务
Reflection	中高	中高（多轮）	中	质量优先任务
ToT	最高	最高	低	创意探索、复杂推理

模式可组合： Supervisor 内的每个 Worker 可使用 ReAct 循环；Critic 使用 Reflection；Planner 使用 ToT。模式不是互斥的 LEGO 积木 $32$ 。

7.3 多 Agent 拓扑架构

本节将抽象拓扑模式 与工业级实现 （Claude Code 源码逆向 $38$ $39$ ）整合呈现。每个拓扑先给出通用设计，再以 Claude Code 的对应实现作为工业验证。

7.3.1 Supervisor（主管/监督者）模式

复制代码

         ┌─ Worker A（搜索）
Supervisor ─┼─ Worker B（分析）
         └─ Worker C（写作）

一个监督者 Agent 路由任务给专业化子 Agent，收集结果并综合
优势： 清晰的控制流；易于调试；职责分离
劣势： 监督者是单点故障；可能成为瓶颈
适用： 专业化分离明确的场景；大多数企业生产部署的首选

工业实例：Claude Code Coordinator Mode（协调者模式）

Claude Code 源码泄露揭示了 Supervisor 模式的工业级强化版 $38$ $40$ 。

复制代码

          ┌──────────────┐
          │  Coordinator │  ← 仅 4 个工具：AgentTool / SendMessage /
          │  (协调者)     │     TaskStop / SyntheticOutput
          └──────┬───────┘  ← 不直接执行任何文件/命令操作
    ┌────────────┼────────────┐
    ↓            ↓            ↓
┌────────┐ ┌────────┐ ┌────────┐
│Worker A│ │Worker B│ │Worker C│  ← 标准工具集，独立上下文
│(研究)  │ │(实现)  │ │(验证)  │
└────────┘ └────────┘ └────────┘
    ↑            ↑            ↑
    └──── <task-notification> XML 回传 ────┘

关键强化：

协调者不执行工具： 仅 4 个工具（AgentTool/SendMessage/TaskStop/SyntheticOutput），不触碰文件系统、不运行 Bash、不调用 MCP $40$ ------天然实现 §5.1.3 最小代理权
信息漏斗： Worker 输出可能数千 token，协调者压缩为人可理解摘要------用户只跟协调者对话 $38$
四阶段流水线： Research（并行调查）→ Synthesis（协调者综合）→ Implementation（Worker 执行）→ Verification（独立 Worker 验证） $39$
Worker 互不可见： Worker 之间不能直接通信，只能通过 <task-notification> XML 向协调者回传结果
与 §7.2.4 Plan-Execute 的区别：Coordinator 的规划是持续的（每阶段后重新评估），而非一次性生成完整计划

7.3.2 Hierarchical（层级）模式

复制代码

              Top-Level Supervisor
              /              \
      Team Lead A          Team Lead B
      /    \                /    \
  Worker  Worker        Worker  Worker

多级管理结构------团队领导协调各自下属的专业 Agent
优势： 可扩展到大规模 Agent 群体；不同抽象层级决策（战略规划 vs 战术执行）
劣势： 层级越深延迟越高；信息在传递中可能失真
适用： 大规模、高复杂度任务（如 DevOps 全生命周期：仓库检查 → 基础设施生成 → CI/CD 配置 → 部署 → 可观测性 $33$ ）

7.3.3 Peer-to-Peer / Collaborative（对等协作）模式

复制代码

Agent A ←→ Agent B
  ↕           ↕
Agent C ←→ Agent D

Agent 间无中央控制者，通过协商和协调自主协作
优势： 高弹性------无单点故障；自然适应变化
劣势： 涌现行为难以管理；协调开销大
适用： 去中心化环境；需要快速适应变化条件的场景

工业实例：Claude Code Agent Teams / Swarm（团队协作模式）

Claude Code 的 Agent Teams 是 P2P 协作的工业实现------结合了弱中心化（Team Lead 管生命周期）和对等通信（队友直接消息） $41$ 。

复制代码

          ┌──────────────┐
          │  Team Lead   │  ← TeamCreate + SendMessage + AgentTool
          │  (团队领导)   │
          └──────┬───────┘
          ┌──────┼──────────────┐
          ↓      ↓              ↓
    ┌──────────┐     ┌──────────┐
    │Teammate 1│←──→│Teammate 2│  ← 队友间可直接 SendMessage
    │(API 层)  │     │(数据库)  │     无需经 Team Lead 中转
    └──────────┘     └──────────┘
          ↑
    ┌──────────┐     共享任务列表
    │Teammate 3│     (team file)
    │(测试)    │
    └──────────┘

关键设计：

队友可直接通信： 通过 SendMessage + mailbox 直接交换消息、共享发现、质疑假设 $41$
共享任务列表： 队友从共享任务列表中认领（claim）任务，而非被动等待分配 $41$
运行环境： tmux/iTerm2 面板（真正多进程）或 in-process fallback（同进程异步） $38$
用户可直接与队友对话： 不必经 Team Lead 中转 $41$
与 Coordinator 的关键区别：信息不在协调者处汇聚，而是分散在队友间流动------适合需要主动协作和争论的场景（如竞争性假设调查）
代价：令牌消耗显著高于单会话；需要文件冲突避免策略（每队友拥有独立 scope）

7.3.4 Blackboard（黑板/共享记忆）模式

复制代码

         ┌─ Agent A（写入知识）
Blackboard ← Agent B（读取 + 处理）
（共享状态） └─ Agent C（读取 + 行动）

所有 Agent 通过共享的"黑板"（知识库/状态存储）异步读写
Agent 间不直接通信，而是通过观察黑板上的变化触发行动
优势： 松耦合；Agent 可动态加入/退出；支持异步协作
劣势： 黑板成为竞争点；需要并发控制和锁机制
适用： 知识聚合、渐进式分析、多源数据融合

7.3.5 Sequential Pipeline（顺序流水线）模式

复制代码

Agent A → Agent B → Agent C → Output

Agent 按固定顺序处理任务，每个 Agent 接收前一个的输出
优势： 最简单；完全确定；易于调试
劣势： 无并行；前序失败阻断全部
适用： 线性工作流（提取 → 转换 → 加载 → 验证）

工业实例：Claude Code Fork Subagent（分叉子代理）------并行流水线变体

Fork 是 Sequential Pipeline 的并行变体 ------父 Agent 分裂出多个子进程并行执行，再汇总结果 $38$ 。

复制代码

          ┌──────────────┐
          │ Parent Agent │  ← 完整工具集
          └──────┬───────┘
     AgentTool   │   AgentTool
     (无 type)   │   (无 type)
         ┌───────┴───────┐
         ↓               ↓
    ┌──────────┐    ┌──────────┐
    │Fork Child│    │Fork Child│  ← 完整继承父对话上下文 + prompt cache
    │   #1     │    │   #2     │     无横向通信，只回父进程
    └──────────┘    └──────────┘

关键设计：

继承父上下文 + prompt cache 共享： 子进程完整继承父进程对话历史，并尽量复用 prompt cache------这是"子 Agent 复用父上下文"最彻底的公开实现 $38$
无横向通信： Fork 子进程之间不能直接通信，只能向父进程回传结果
自动触发： 主 Agent 调用 AgentTool 时不指定 subagent_type 即自动走 fork 路径 $39$
与 Coordinator 互斥： 开启 Coordinator 会自动禁用 Fork $38$
prompt cache 共享是成本优化的关键创新------子 Agent 无需重新构建上下文，大幅降低令牌消耗
适合快速并行探索/微任务（如同时搜索 3 个目录），而非需要深度协调的复杂工作流

7.3.6 Swarm（蜂群）模式

复制代码

    ●  ●
  ●     ●     ← 无中心控制，通过简单规则和局部交互涌现集体智能
    ●  ●

大量简单 Agent 通过局部规则和邻居交互涌现集体行为
优势： 极高可扩展性；自修复能力
劣势： 行为不可预测；难以调优
适用： 大规模分布式优化；资源分配；传感器网络

7.3.7 拓扑选型决策表

下表将抽象拓扑特性 与工业变体差异（Claude Code）整合为统一决策矩阵：

拓扑	工业变体	控制流	可扩展性	容错性	调试难度	适用规模	令牌成本	上下文	关键取舍
Supervisor	Coordinator $40$	中心化	中	低（单点）	低	3-10	高（协调者+Worker）	Worker 独立 prompt	协调者被禁止执行工具→安全性最高；但信息漏斗可能丢失细节
Hierarchical	---	层级化	高	中	中	10-100	最高（多层）	各级独立	可扩展性最强；但层级越深延迟越高、信息失真越大
P2P / Collaborative	Agent Teams $41$	去中心化	高	高	高	5-50	最高（多会话+消息）	队友独立会话	队友直接争论→质量最高；但协调开销大、需文件冲突避免
Blackboard	---	共享状态	中高	中高	中	动态加入/退出	中	共享黑板	松耦合最灵活；但黑板是竞争点、需锁机制
Sequential	Fork $38$	线性	低	低	最低	2-5	最低（cache 共享）	继承父对话	Fork 共享 prompt cache→成本最低；但无横向协调、前序失败阻断全部
Swarm	---	涌现	最高	最高	最高	100+	可变（规则驱动）	局部状态	自修复能力最强；但行为不可预测、难以调优

选型决策树：

复制代码

任务需要多个专业化 Agent？
├── 否 → 单 Agent 循环模式（§7.2）
└── 是 → Agent 数量？
    ├── ≤5 且线性流程 → Sequential / Fork（最简单、最低成本）
    ├── 3-10 且需清晰控制 → Supervisor / Coordinator（生产首选）
    ├── 5-50 且需争论协作 → P2P / Agent Teams（质量优先）
    ├── 10-100 且多层级 → Hierarchical（可扩展）
    └── 100+ 且规则驱动 → Swarm（涌现智能）

互斥性提示： Claude Code 中 Coordinator 与 Fork 互斥（开启 Coordinator 自动禁用 Fork）；Agent Teams 可独立运行 $38$ 。

7.4 分布式多 Agent 通信

7.4.1 通信模式

模式	机制	优势	劣势	适用场景
请求-响应（同步）	Agent A 直接调用 Agent B，阻塞等待响应	简单；实时反馈	紧耦合；阻塞；不可扩展	短延迟、简单委托
消息驱动（异步）	通过消息队列/事件总线交换离散消息	松耦合；可缓冲流量峰值；内置重试和死信队列	调试复杂；最终一致性	分布式环境；长时任务；高吞吐 $34$
发布-订阅	Agent 发布事件到主题，订阅者按需接收	完全解耦；一对多	消息顺序不保证	事件通知、状态广播
共享状态	所有 Agent 读写同一状态存储	无需直接通信；异步协作	竞争条件；需要锁	Blackboard 模式

Microsoft 参考架构建议： 分布式多 Agent 系统应使用消息驱动通信 （如 Amazon MQ / Azure Service Bus / Kafka），利用内置重试、死信队列和持久化存储提供弹性 $34$ 。

7.4.2 分布式容错与一致性

多 Agent 系统本质上是分布式系统，必须显式处理：

挑战	解决方案
Agent 故障	断路器（circuit breaker）；超时重试；死信队列；故障转移到备用 Agent
消息丢失/乱序	消息持久化 + 确认机制；相关性 ID（correlation ID）追踪请求-响应对；幂等消费者
状态不一致	分布式状态存储（如 Redis/etcd）；最终一致性模型；冲突解决策略（LWW/CRDT）
级联失败	爆炸半径护栏（配额、进度上限）；独立策略执行（规划与执行分离）；数字孪生重放验证
共识达成	对于需要多 Agent 一致决策的场景，采用 Raft/Paxos 共识算法或加权投票

Symphony 模式（去中心化多 Agent）： 使用去中心化账本追踪 Agent 可用性 + Beacon 广播任务需求 + Agent 自计算能力匹配分 + 加权多 CoT 投票。在 BBH 上比 AutoGen 提升 6.5-29.1%，开销 <5% 延迟 $37$ 。

7.5 编排框架选型

框架	生产成熟度	核心模式	可观测性	最佳场景
LangGraph	高	图状态机、Supervisor、Hierarchical	LangSmith 深度集成；人工检查点为一等原语	企业生产（~38% 多 Agent 部署份额） $16$
CrewAI	中	角色制 Crew、层次化	基础日志	快速原型验证 $17$
Microsoft Agent Framework	中	对话式多 Agent、辩论	OpenTelemetry	研究/学术；.NET/Azure 原生 $16$
OpenAI Agents SDK	中	沙箱工具、子 Agent	OpenAI 原生	GPT 为中心的工作流 $18$
Google ADK	中	模块化 Agent 定义	Vertex AI 集成	GCP 原生、多模态 $17$
AWS Step Functions + EventBridge + MQ	高	事件驱动、消息驱动	CloudWatch 全链路	云原生分布式编排 $33$
自定义编排	可变	定制	自建	最高控制要求（~28% 部署份额） $16$

关键发现： 框架选择可使 Agent 性能波动 30 个百分点 $18$ 。但对企业部署而言，框架选择的重要性低于模型选择、评估基础设施和人工检查点设计 $16$ 。

7.6 架构原则

分离编排层： 编排逻辑（决定给模型什么上下文、调用哪个模型、如何处理响应）必须集中在专用服务/模块 中，不可散落在 API 路由处理器、React 组件或数据库触发器中 $19$
从 Supervisor 开始： 80% 的企业场景不需要比 Supervisor 更复杂的拓扑；先证明价值再增加复杂度
人工检查点为原生原语： 在节点暂停、等待人工输入、恢复------LangGraph 将此作为一等支持
状态持久化与重放： 检查点每个状态转换，从任意点恢复，重放调试
为每次交接定义 JSON 契约： 越清晰的 schema，越容易替换 Agent、限流重试或分阶段迁移 $32$
计算预算作为产品需求： 在上线前预算令牌、延迟和降级行为------设置分支数、重试次数和 Critic 轮数的硬上限 $32$
对抗性测试： 故意破坏一个 Agent，验证 Ensemble/Critic/Orchestrator 能否恢复 $32$
控制反馈循环： Critic 链和反思审查者可能永远振荡------添加最大迭代上限、衰减置信度分数或人工介入中断 $32$

7.7 Loop Engineering（循环工程）------超越提示词的范式

"我不再提示 Claude 了。我有循环在运行。是循环在提示 Claude 并决定该做什么。我的工作是编写循环。" ------ Boris Cherny，Claude Code 创始人 $42$

7.7.1 定义：从提示词到循环

Loop Engineering（循环工程）是设计自动提示 AI Agent 的系统 ，而非手动输入每个提示词 $42$ $43$ 。

维度	提示词工程（Prompt Engineering）	循环工程（Loop Engineering）
工作单元	单轮交互	整个自主运行周期
谁驱动 Agent	你，手动	你设计的系统
持续时间	秒级	分钟到小时级
产出	一个响应	一个已验证的结果
杠杆倍数	1×	10-100× $42$
核心技能	措辞	系统设计

7.7.2 循环的六原语

构成循环的六个原语 $43$ ：

原语	职责	Claude Code 实现	对应本文档
Automations（自动化）	按计划触发循环，自主发现和分诊	`/goal`、`/loop`、hooks、GitHub Actions	§4.1 反馈闭环
Worktrees（工作树）	隔离并行 Agent 的文件系统，防止冲突	`git worktree`、`--worktree`、subagent `isolation: worktree`	§5.2 资源隔离
Skills（技能）	将项目知识编码为 Agent 可读的结构化文档	`SKILL.md`，`$name` 调用	§9.2 评估八步法
Connectors（连接器）	将 Agent 接入已有工具（API、数据库、文件系统）	MCP 服务器 + 插件	§5.5 MCP 安全
Sub-agents（子代理）	Maker/Checker 分离------一个 Agent 提议，另一个验证	`.claude/agents/` 子代理定义、Agent Teams	§7.2.5 Reflection + §7.3.1/§7.3.3
External State（外部状态）	跨迭代持久化的记忆，不依赖会话上下文	`AGENTS.md`、进度文件、Linear via MCP	§3.3 知识层记忆

关键洞察： 模型在运行之间会遗忘一切，因此记忆必须在磁盘上而非上下文中。Agent 会遗忘，但仓库不会 $43$ 。

7.7.3 循环的五要素

每个设计良好的 Agent 循环都包含五个部分 $42$ ：

复制代码

┌──────────────────────────────────────────────────────┐
│                     Agent Loop                         │
│                                                        │
│  ① Trigger      → 什么启动循环（定时/事件/人工/另一个Agent）│
│       ↓                                                │
│  ② Goal         → 可验证的终止条件（"所有测试通过"）      │
│       ↓                                                │
│  ③ Actions      → 循环内可用工具（文件读写/Bash/API/子代理）│
│       ↓                                                │
│  ④ Verification → 如何知道该停止（测试退出码/监督Agent/CI）│
│       ↓                                                │
│  ⑤ Memory       → 跨迭代持久化（会话恢复/CLAUDE.md/外部） │
│       ↓                                                │
│     [Goal 达成？] ──否──→ 回到 ①                        │
│        │ 是                                            │
│        ↓                                               │
│     循环结束                                            │
└──────────────────────────────────────────────────────┘

要素	模糊版本（失败）	精确版本（成功）
Trigger	"当我需要时手动运行"	"每天 9:00 cron 触发 / PR 打开时事件触发"
Goal	"让代码更好"	"`test/auth` 下所有测试通过且 lint 清洁"
Verification	"我看看输出感觉对不对"	"独立验证子代理审查最终状态 + CI 绿灯"
Memory	无（每次从头开始）	`STATE.md` 记录已完成项 + `CLAUDE.md` 项目上下文

7.7.4 Maker/Checker 分离：验证子代理优于自我批判

Anthropic 工程师报告："独立验证子代理往往优于 Fable 5 的自我批判。" 在 Parameter Golf 实验中（8×H100，最多 8 小时），Fable 5 + 独立验证器实现了约 6× 于 Opus 4.7 的管线改进 $44$ 。

复制代码

Maker Agent          Checker Agent (独立)
(生成方案)    →      (仅看产物 + 评分标准)    →    通过？
  ↑                                               │ 否
  └───────────── 修改并重试 ←──────────────────────┘

核心原理： Maker 看到的是自己的推理轨迹；Checker 看到的只有最终产物和评分标准------这消除了"思维退化"（§7.2.5），因为 Checker 不会继承 Maker 的推理偏差 $44$ 。

这与 §9.9.2 的评估策略一致：使用独立 Critic 模型（不同模型家族）进行交叉验证。

7.7.5 Loop Engineering 与本文档的关联

Loop Engineering 概念	本文档对应章节	关系
六原语之 Automations	§4.1 反馈闭环	自动化触发是持续学习原则（P7）的实现
六原语之 Worktrees	§5.2 资源隔离	文件系统隔离是"假设失陷"原则（P5）的落地
六原语之 Sub-agents	§7.2.5 Reflection + §7.3 拓扑（工业实例）	Maker/Checker 是多 Agent 评估（§9.4）的基础
五要素之 Verification	§7 评估与测试	验证是循环终止条件，也是评估框架的核心
五要素之 Memory	§3.3 知识层	外部状态持久化是可观测性溯源链（§6.1.2）的基础
循环控制	§4.2 Agentic Loop + §7.6 原则 8	最大迭代上限、衰减置信度防止无限振荡

架构含义： Loop Engineering 不是新的架构层------它是 §4 运行时生命周期的外延。§4.2 的 Agentic Loop 是循环的"内循环"（单次推理迭代）；Loop Engineering 的循环是"外循环"（跨会话的自主目标追求）。两者嵌套构成完整的 AI Native 运行时。

8. 知识层进阶：混合检索与 GraphRAG

基础向量相似度搜索在生产中存在严重缺陷：精确匹配缺失、多跳推理失败、无质量验证。

8.1 混合搜索（Hybrid Search）------架构必需而非优化

采用混合搜索不仅是性能优化，而是确保企业级 AI 搜索系统高可靠性、防止 LLM 幻觉的必要架构决策。 $23$

纯向量搜索的固有缺陷------域外数据问题（OOD）： 嵌入模型无法为新实体或专有企业数据（新产品名、内部代码、SKU）生成有意义的语义表示 $23$

混合搜索方案：

复制代码

查询 → [密集向量检索（语义理解）] + [稀疏 BM25 检索（精确匹配）]
    → 倒数排名融合（RRF）: RRF(d) = Σ 1/(k + rank(d))
    → 重排序 → 最终结果

性能特征： $24$

命名实体检索显著改善（人名、机构名、缩写）
召回率提升 15-25%，精确度不降
延迟仅增加 5-10%

8.2 多阶段 RAG 架构

复制代码

查询扩展 → 初步检索 → 重排序 → 上下文构建 → 生成与验证

查询扩展： 扩展用户查询以捕获更多相关信息
重排序： 对候选文档进行相关性重排序（如 Cross-Encoder）
上下文构建： 优化输入到 LLM 的上下文
生成与验证： 生成答案并进行验证（防止幻觉）

8.3 知识检索模式全景对比

下表给出四种主流进阶检索模式的定位与边界，后续小节逐个展开。

模式	解决问题	适用场景
GraphRAG	多跳推理------需要跨多个文档综合信息	"哪个 2020 年发布的 AWS 服务冷启动时间最短？"
Ontology RAG	业务实体的刚性关系约束与精确属性过滤（价格、库存、布尔值等）	"负责产品 A 的部门经理是谁？""库存 > 0 且价格 < 50 的 SKU"
CRAG（纠正性检索）	无质量验证------检索结果未经相关性验证即传给 LLM；解决企业内部"数据新老交替"	生产级 RAG 系统、需要降级到实时数据源
Self-RAG / Agentic RAG（⚠️ 远期规划）	单轮检索的僵化------LLM 无法自主决定何时检索、何时改写、何时放弃	复杂任务、需要多跳迭代与自我反思的场景

核心定位差异： GraphRAG 解决"数据结构"（用图替代线性文本块）；Ontology RAG 解决"业务逻辑的确定性"（用硬编码关系路径替代语义近似）；CRAG 解决"检索结果的可信度"（用质检网关阻断低质量上下文）；Self-RAG / Agentic RAG 解决"检索的控制流"（让 LLM 自主决定检索策略）。其中前四者（GraphRAG/Ontology/CRAG/混合检索）为可近期落地的核心模式，Self-RAG / Agentic RAG 因门槛与成本列为远期规划（详见 §8.6）。

8.4 GraphRAG------多跳推理的图结构答案

核心逻辑： 普通 RAG 依赖向量相似度，在线性文本块中"撞运气"匹配；GraphRAG 在索引阶段把语料抽取为知识图谱（实体 + 关系 + 社区），查询时按图遍历多跳路径，从拓扑结构而非文本距离回答问题 $48$ 。

GraphRAG 的索引流水线（Microsoft GraphRAG）：

复制代码

原始语料 → [实体抽取 + 关系抽取（LLM）]
        → 构建图（节点=实体，边=关系）
        → 社区发现（如 Leiden 算法）→ 分层社区层级
        → 为每个社区生成摘要报告（LLM）
        → 多层级图索引（局部细节层 ↔ 全局主题层）

两种查询模式：

模式	适用查询	工作方式
Local Search	针对特定实体的查询（"产品 X 的依赖项有哪些？"）	定位实体节点，遍历其邻域子图，返回相关实体与关系
Global Search	跨数据集的全局主题查询（"本季度财报里所有降本举措的共同主题是什么？"）	遍历社区层级，对社区摘要报告做 Map-Reduce 式综合

GraphRAG 2.0 的关键改进------动态社区选择（Dynamic Community Selection）： $49$

复制代码

旧版（固定层级）：查询 → 固定遍历某一层级的所有社区报告 → 高 token 成本、上下文稀释
新版（动态选择）：查询 → 评估每个社区报告的相关性 → 仅选相关报告进入 Map-Reduce
                    → 显著降低 token 与延迟，且答案质量不降反升

架构含义： GraphRAG 的成本主要在索引阶段 （构建图与社区摘要耗 LLM 调用），查询阶段相对轻量。因此它适合语料相对稳定、查询频次高 的场景（如产品手册、法规、内部知识库），不适合每分钟都在变化的实时数据。

8.5 CRAG（Corrective RAG）------检索质检网关

核心逻辑： CRAG 不是一种数据库，而是一种工作流模式 ------在检索与生成之间插入"质检网关"，对检索结果打分，按分数路由到不同处理路径 $50$ 。

CRAG 的四阶段流：

复制代码

┌──────────────────────────────────────────────────────────────────┐
│  ① 检索          ② 质检评估（轻量检索评估器）                        │
│  (向量/图/BM25)  →  打分：Correct / Incorrect / Ambiguous         │
│                         │                                          │
│         ┌───────────────┼────────────────┐                         │
│         ▼               ▼                ▼                         │
│   ③ Correct 路径   ③ Incorrect 路径   ③ Ambiguous 路径             │
│   知识精炼          触发降级回退        融合双源                       │
│   (文档脱水→       (查实时 SQL/        (精炼后的                     │
│    核心事实三元组)    内部 API/Web)       检索 + 回退数据)             │
│         │               │                │                         │
│         └───────────────┼────────────────┘                         │
│                         ▼                                          │
│                 ④ 最终生成（LLM 仅基于经过验证的上下文）               │
└──────────────────────────────────────────────────────────────────┘

CRAG 在企业内部的典型降级回退目标：

数据时效性	检索源	CRAG 角色
静态历史文档	向量库（Chroma/Milvus）	日常规章、技术细节的泛化检索------通常 Correct 路径
核心业务脉络	本体图谱（Neo4j）	实体关系的精准查询------通常 Correct 路径
动态生产数据	实时 SQL / ERP / Confluence API	检测到检索结果过时时触发------Incorrect 路径的回退目标

CRAG 的代价与权衡：

延迟增加： 质检评估器 + 可能的二次回退检索，P95 延迟通常 +30~80% $50$ $51$
流程复杂度： 需要状态机逻辑（如 LangGraph.js）处理条件分支、循环重试、异常降级
收益： 在 PopQA 基准上，CRAG 较基线 RAG 提升约 +5.5 个百分点 $50$ ，且在企业内部"2024 版手册 vs 实时库"的冲突场景下表现稳健

与 §7 的关联： CRAG 的状态机本质上是 §7.2 的 Agentic Loop 在知识层的具体化------retrieve → evaluate → (route) → generate 即一个带条件分支的循环，LangGraph.js 是其天然实现载体（参见 §7.5 编排框架选型）。

8.6 Self-RAG 与 Agentic RAG------让 LLM 自主决定检索策略（远期规划建议）

⚠️ 实施时序标注：本节内容为远期规划建议，非 MVP/初期落地范围。 Self-RAG 需要模型微调（生成反思令牌的能力内化于权重），工程门槛高；Agentic RAG 引入动态工具调用与多轮迭代，token 成本与延迟显著上升，且对编排框架的健壮性要求高。建议在混合检索（§8.1）、GraphRAG（§8.4）、CRAG（§8.5）、Ontology RAG（§8.8）已稳定运行、且积累足够失败案例数据后，再评估引入。 在此之前，可先用 CRAG 的质检器（单步质量判定）作为 Self-RAG 思想的轻量替代。

Self-RAG------通过反思令牌内化检索决策： $52$

Self-RAG 训练 LLM 输出"反思令牌"（reflection tokens），让模型自主决定何时检索、如何评估生成质量：

反思维度	含义	取值
Retrieve	是否需要检索	yes / no / continue
IsRel	检索段落是否与查询相关	relevant / irrelevant
IsSup	生成内容是否被检索段落支持（防幻觉）	fully / partially / no
IsUse	整体回答对用户是否有用	1-5 评分

Agentic RAG------把 RAG 当作工具供 Agent 调用： $53$ $54$

Agentic RAG 不再是"硬编码的 retrieve → generate"流水线，而是把多个检索器、重排序器、知识图谱查询都封装为工具，由 Agent 按查询意图动态编排：

复制代码

用户查询 → [Agent 推理：查询类型？需要哪些源？]
        → 工具调用：查询分解 / HyDE 改写 / 多源并行检索
        → 自我批判：结果是否充分？需要追加检索？
        → 迭代直到满足质量阈值或达到迭代上限
        → 综合生成

能力	Naive RAG	Agentic RAG
查询路由	固定单一检索器	按意图动态选择检索源（向量/图/SQL）
查询改写	无	HyDE、子问题分解、回译等
多跳迭代	单轮	自我反思驱动多轮迭代
工具调用	无	调用 MCP 工具、API、子代理
失败恢复	无	检索不足时改写或换源重试

关键决策点： Self-RAG 需要微调模型（生成反思令牌的能力内化于权重），门槛高但推理时轻量；Agentic RAG 不改模型，用编排框架实现控制流，灵活但 token 成本与延迟更高。生产中两者常组合：用 Agentic RAG 做编排外壳，用 Self-RAG 风格的评估器做单步质量判定（即 CRAG 的质检器）。

8.7 进阶检索增强技术------查询侧与索引侧

除上述架构级模式外，以下技术可作为多阶段 RAG 流水线（§8.2）的积木组合使用。

查询侧（Query-time）------检索前增强：

技术	原理	解决问题	代价
HyDE $55$	LLM 先为查询生成"假想答案文档"，用该文档的向量做检索	短查询与长文档的语义鸿沟（如"产品 X 怎么用？"匹配不到详细手册）	每次查询多一次 LLM 生成
查询分解	把复杂问题拆成子问题，分别检索后合并	多跳问题	多轮检索，延迟与 token 增长
多查询检索	LLM 生成多个查询变体，并行检索后融合	单一查询表达不全的意图	多倍检索成本

索引侧（Indexing-time）------离线增强：

技术	原理	解决问题	代价
RAPTOR $56$	递归地聚类、摘要文本块，构建多层级树索引	既要局部细节又要全局主题的查询	索引阶段 LLM 摘要成本高
Parent-Document / Small-to-Big	用小块做检索、返回所属大块给 LLM	检索精度（小块向量准）与上下文完整性（大块信息全）的矛盾	索引设计复杂度增加
语义缓存	缓存查询向量与答案，命中时直接返回	重复查询的延迟与成本	缓存失效与一致性问题

HyDE 与 RAPTOR 的取舍： HyDE 是查询时增强（贵在每次查询，索引零成本）；RAPTOR 是索引时增强（贵在一次性索引，查询时轻量）。两者可叠加------RAPTOR 构建层级索引，HyDE 在查询时进一步拉近语义距离。

8.8 Ontology RAG------用本体图谱锁定业务确定性

核心逻辑： Ontology RAG 不是"语义近似"，而是"硬编码关系查表"------在 Neo4j 这类图数据库中存储企业标准名词字典、业务拓扑（部门-员工-SKU-权限）和刚性约束，按 Cypher 路径查询 $57$ 。

Ontology RAG 与 GraphRAG 的关键区别：

维度	GraphRAG	Ontology RAG
图谱来源	LLM 从非结构化文本自动抽取（实体+关系）	人工定义的 Schema（领域专家 / ER 模型）
关系确定性	概率性（LLM 抽取可能错漏）	确定性（Schema 强约束，100% 精确）
属性过滤	弱（语义检索对数值/布尔值常失效）	强（"价格 < 50 且库存 > 0" 精确成立）
泛化能力	好（能处理 Schema 外的语义延伸）	差（图谱未定义的关系查不到）
建模成本	中（LLM 抽取自动化）	高（需领域专家构建 Ontology Schema）

降低 Ontology 构建门槛的工程实践： LlamaIndex 的 PropertyGraphIndex 支持 Schema-guided extraction ------先用领域专家定义实体类型与关系类型，再让 LLM 在该 Schema 约束下从企业文档自动抽取属性图，免去手写图谱抽取算法 $57$ $58$ 。

架构含义： Ontology RAG 适合业务逻辑刚性、属性精确过滤是硬需求 的场景（库存、价格、权限、合规规则）；不适合需要模糊语义延伸的场景（创意写作、开放问答）。两者互补而非互斥。

8.9 三位一体融合策略------生产级知识层架构

核心洞察： 在真实生产环境中，最先进的架构不是在上述模式中"四选一"，而是按数据特性分层融合 $23$ $50$ 。

复制代码

┌──────────────────────────────────────────────────────────────┐
│                    CRAG 编排外壳（LangGraph.js 状态机）           │
│                                                              │
│  用户查询 → 实体/意图抽取 → ┌─ GraphRAG（多跳推理）                │
│                        │   └─ 本体图谱（业务确定性）              │
│                        ├─ 向量+BM25 混合检索（泛化语义）          │
│                        └─ 实时 SQL/ERP（动态数据）              │
│                              │                                │
│                              ▼                                │
│                    质检评估器（Correct/Incorrect/Ambiguous）     │
│                              │                                │
│              ┌───────────────┼───────────────┐                │
│              ▼               ▼               ▼                │
│         知识精炼          降级回退         融合双源               │
│              └───────────────┼───────────────┘                │
│                              ▼                                │
│                    本地 LLM 生成（Ollama，数据不出域）            │
└──────────────────────────────────────────────────────────────┘

数据特性	用什么	为什么
静态海量文本	向量库 + BM25 混合检索（Chroma/Milvus）	日常规章、技术细节的泛化检索，召回率高
核心业务脉络	Ontology RAG（Neo4j）	部门-员工-SKU-权限的确定性追踪，属性精确过滤
多跳关系推理	GraphRAG（社区层级 + 动态社区选择）	跨实体的多跳综合问答，社区摘要支撑全局主题
动态生产数据	实时 SQL / ERP / Confluence API	CRAG 检测到过时时回退至此，保证数据时效性
控制流编排	CRAG 状态机（LangGraph.js）	质检 → 路由 → 降级，工业级鲁棒性
数据主权	本地 LLM（Ollama，qwen2.5/llama3）	敏感文档不出域，满足合规审计（对应 §1.1 数据主权内置 + §6.4 数据隐私与主权）

融合的架构原则映射（编号对应 §2）：

P4 永远验证，永不信任： 本地 LLM（Ollama）保证 CRAG 质检器读取敏感文档时不外发字节；逐请求认证数据流
P5 假设失陷： 多源检索 + 质检回退是"假设任一检索源失陷"的补偿控制------单源污染会被质检器阻断
P3 最小代理权： CRAG 状态机对每个检索源仅授予最小访问范围（向量库只读、图谱只读、SQL 限定查询）
P7 持续学习： 质检器的"误判"案例自动转为评估用例，反哺 §9.5.3 的知识层评估闭环
P8 可解释与可审计： CRAG 的每条路由决策（Correct/Incorrect/Ambiguous）必须落盘为溯源链，与 §6.1.2 一致

8.10 知识检索模式选型决策表

你的需求	首选模式	配套技术
精确匹配命名实体（人名、SKU、缩写）	混合搜索（§8.1）	BM25 + 向量 + RRF + 重排序
跨多文档的多跳推理	GraphRAG（§8.4）	社区层级 + 动态社区选择
业务实体刚性关系 / 数值属性精确过滤	Ontology RAG（§8.8）	Neo4j + Schema-guided 抽取
检索结果质量不可信 / 数据有新旧版本冲突	CRAG（§8.5）	质检评估器 + 降级回退（实时 SQL/API）
复杂任务需要 LLM 自主决定何时检索、何时改写	Agentic RAG（§8.6，⚠️ 远期规划）	工具封装 + 自我反思 + 迭代（需 CRAG/GraphRAG 稳定后再评估）
短查询匹配不到长文档	HyDE（§8.7）	LLM 生成假想文档后检索
既要局部细节又要全局主题	RAPTOR（§8.7）	多层级树索引
生产级系统，多种数据源并存	三位一体融合（§8.9）	向量+图+SQL，CRAG 编排，本地 LLM

实施建议（按时序分阶段）：

近期（MVP/初期）： 先按 §8.1 用混合搜索解决 80% 的检索问题。

中期： 当出现多跳推理失败时引入 GraphRAG（§8.4）；当出现业务确定性需求时引入 Ontology RAG（§8.8）；当生产中出现检索质量事故时引入 CRAG（§8.5）。每一层的引入都应由真实的失败案例驱动（对应 §9.2 评估八步法第 8 步"闭环"）。

远期（稳定运行后再评估）： 当上述模式已稳定、且积累了足够失败案例后，再评估引入 Self-RAG / Agentic RAG（§8.6）以处理"需要 LLM 自主决定何时检索/改写"的复杂任务。在此之前可用 CRAG 质检器作为 Self-RAG 思想的轻量替代。

9. 评估与测试策略（Evaluation & Testing）

评估不是一次性活动，而是贯穿 AI Native 系统全生命周期的持续闭环。 本章按前 8 章的架构层次，自底向上构建评估覆盖矩阵。

9.1 评估核心理念

用具体问题替代"感觉是不是更好了"（vibes）： Agent 是否调用了技能？是否运行了预期命令？输出是否遵循规范？

评估等式：提示词 → 捕获运行（轨迹 + 工件） → 少量检查 → 可比较的分数

评估成熟度分层：

层级	能力	对应 §1.2 成熟度
L0 人工抽查	开发者手动运行 + 主观判断	L0-L1 系统
L1 脚本化回归	固定测试集 + 确定性断言	L1-L2 系统
L2 自动化评估管线	CI/CD 集成 + LLM-as-Judge + 对抗性测试	L2 系统
L3 持续评估 + 生产闭环	生产轨迹自动转评估用例 + 线上 A/B + 实时漂移检测	L3 AI 原生

9.2 评估八步法

步骤	活动	关键点
1. 定义成功	在编写技能前，将检查分为四类：结果目标、过程目标、风格目标、效率目标	聚焦必须通过的检查
2. 创建技能	使用 `$skill-creator`；`name` 和 `description` 是触发的主要信号	模糊/重载的描述会破坏触发
3. 手动触发	暴露隐藏假设：触发假设、环境假设、执行假设	使用 `codex exec` 获取可重复运行
4. 定向提示集	维护 CSV（10-20 条提示），四种类型：显式调用、隐式调用、上下文调用、阴性对照	阴性对照捕获误触发
5. 确定性评分	对 JSONL 事件流编写确定性检查	一切都是确定性的、可调试的
6. 规则评分	使用 `--output-schema` 约束的只读 `codex exec` 进行风格/规范评判	结构化响应可解析、可 diff、可追踪
7. 逐步扩展	命令计数/抖动、令牌预算、构建检查、运行时冒烟、仓库整洁度、沙箱/权限回归	仅在能增加信心时添加更深检查
8. 闭环	每次手动修复 → 新的 CSV 行	真实失败驱动覆盖

9.3 评估原则

先做快速、可解释的检查，再做较慢/较重的检查------仅当它们降低风险时
最小权限默认------完全自动化模式仅在必要时使用，优先选择受限/只读模式
令牌使用事件作为效率遥测的基础
阴性对照作为一等监控信号，捕获过度触发的误报

9.4 架构原则合规性评估（对应 §2）

架构原则不是文档装饰------每条原则必须有可验证的检查项 和自动化回归测试 。下表的 P1-P8 编号与 §2 的八条原则严格对齐。

原则	评估方法	自动化检查	通过标准
P1 概率性内核	验证关键路径上的校验关卡是否齐备	静态检查关键路径是否有验证/回滚/HITL 节点	100% 关键路径含验证关卡
P2 智能无处不在	验证移除测试------移除 AI 组件后系统行为	自动化"AI 降级"测试：断开模型 API，验证降级路径	L3 系统应完全失去核心功能（按设计）
P3 最小代理权	审计每个 Agent 的工具列表和权限范围	CI 中检查 Agent 配置文件的工具白名单是否为最小集	无 Agent 持有未使用的工具权限
P4 永远验证，永不信任	审计数据流向与认证链------PII/敏感数据是否离开边界	静态分析数据流图 + 运行时网络流量监控；逐请求认证审计	敏感数据不外发至第三方 API；100% 请求经认证授权
P5 假设失陷	红队注入测试 + 模拟攻破场景	混沌工程：随机杀死一个 Agent，验证隔离和恢复	单 Agent 失陷不影响其余 Agent
P6 自动化记账，人工决策	验证记账/决策边界与审批升级	端到端测试：高风险操作（遏制/披露/客户沟通）是否触发人工审批	高风险操作 100% 触发 HITL
P7 持续学习	验证反馈闭环是否闭合	检查生产轨迹是否自动转为评估用例（参见 §6.1.7）	每周新增评估用例数 > 0
P8 可解释与可审计	验证溯源链完整性与可读性	自动验证每个请求的溯源链可从输出回溯到输入；抽样人工审查可理解度	100% 请求有完整溯源链；非专家可理解 > 80%

跨章节原则交叉引用： §2 的八条原则之外，文档多处涉及的安全属性（非独立编号原则）按以下映射评估------数据主权 （§1.1 / §6.4）、可观测性优先 （§6.1）、渐进式信任/HITL（§3.1 / §6.1.4），其评估分别落在 §9.8（非功能性）、§9.5.5（交互层）等子节。

9.5 分层架构评估（对应 §3）

五层架构的每一层都有独特的失效模式，需要专属评估策略。

9.5.1 基础设施层评估（§3.5）

评估维度	检查项	工具/方法
资源弹性	GPU 集群自动伸缩响应时间；冷启动延迟	负载测试 + 监控告警延迟
网络隔离	Agent 网络分段有效性；出站流量白名单	网络策略测试 + 渗透测试
容器安全	镜像漏洞扫描；运行时权限	Trivy/Grype + 非 root 执行验证

9.5.2 智能层评估（§3.4）

评估维度	检查项	方法
模型质量基线	标准基准测试集准确率；F1/BLEU/ROUGE	定期回归测试
模型路由准确性	简单任务是否路由到低成本模型；复杂任务是否路由到高端模型	路由决策日志分析 + 成本/质量比
版本回归	新模型版本是否导致质量退化	影子部署 + A/B 测试 + 金丝雀发布
幻觉率	生成内容与事实不符的比例	LLM-as-Judge + 人工抽样核验

9.5.3 知识层评估（§3.3 / §8）

知识层评估是 RAG 系统的成败关键------检索质量直接决定生成质量。

评估维度	检查项	方法	目标
检索召回率	相关文档是否被检索到	标注测试集 + Recall@K	召回率 > 90%（混合搜索比纯向量提升 15-25%，参见 §8.1）
检索精确度	检索结果中相关文档的比例	Precision@K	> 80%
重排序质量	重排序后最相关文档是否排在前面	NDCG@10	> 0.85
上下文窗口利用率	输入到 LLM 的上下文中有效信息比例	上下文压缩率分析	冗余 < 20%
记忆隔离	跨租户/跨会话的记忆是否泄露	跨租户注入测试	零泄露
记忆完整性	检索的记忆是否被篡改	加密哈希验证	100% 通过
RAG 端到端	最终答案是否基于检索到的文档	忠实度（Faithfulness）+ 答案相关性	忠实度 > 95%
GraphRAG 多跳正确性	跨实体多跳推理答案是否正确（§8.4）	多跳问答标注集（如 MuSiQue/2WikiMultihopQA）	多跳命中率 > 70%
CRAG 路由准确率	Correct/Incorrect/Ambiguous 三分是否判对（§8.5）	抽样人工标注 + 混淆矩阵	误判率 < 10%；Incorrect 漏检率 < 5%
降级回退成功率	CRAG 触发回退后实时数据是否真的更优（§8.5）	回退前后答案正确率对比	回退后正确率 > 回退前
Agentic RAG 迭代收敛（⚠️ 远期评估项）	自我反思是否在合理步数内收敛（§8.6，远期规划）	迭代步数分布 + 收敛率 P50/P95	P95 迭代步数 ≤ 预算上限；死循环率 = 0
Ontology 查询精确率	Cypher 路径查询结果是否 100% 精确（§8.8）	已知答案查询集回归	100%（硬约束，不允许近似）
GraphRAG 索引成本	构建图与社区摘要的 LLM 调用成本（§8.4）	索引 token 计量 + 单位语料成本	在预算上限内；增量更新成本 < 全量重建

评估工具： RAGAS（RAG Assessment）框架提供召回率、忠实度、答案相关性等标准化指标；TruLens 提供生产级 RAG 追踪和评估。

9.5.4 编排层评估（§3.2）

评估维度	检查项	方法
工具路由准确性	Agent 是否选择了正确的工具	工具选择混淆矩阵
意图封装完整性	签名信封是否在每个执行周期验证	篡改测试：修改意图信封，验证拒绝
编排延迟	编排层自身的处理延迟	P50/P95/P99 编排延迟监控

9.5.5 交互层评估（§3.1）

评估维度	检查项	方法
意图识别准确率	用户意图是否被正确解析	标注测试集 + 混淆矩阵
信任校准 UI	高风险操作是否有视觉警示	UI 自动化测试 + 人工审查
用户脱离率	用户中途放弃会话的比例（参见 §6.1.4）	会话日志分析

9.6 运行时生命周期评估（对应 §4）

9.6.1 请求生命周期测试

阶段	测试类型	检查项
输入验证	模糊测试 + 注入测试	Schema 校验拒绝率；恶意输入拦截率
工具调用	参数变异测试	参数双向验证是否生效；沙箱逃逸测试
输出控制	PII 泄露测试	输出中是否包含 PII/凭证
反馈闭环	闭环验证	生产轨迹是否自动转为评估用例

9.6.2 Agentic Loop 评估（对应 §4.2）

评估维度	检查项	自动化方法
循环终止性	循环是否在合理步数内终止？是否无限振荡？	步数分布追踪（P50 vs P95 vs P99）；超时率
中间状态一致性	检查点恢复后状态是否一致？	故障注入：在随机步杀死 Agent，验证恢复
衰减置信度	置信度是否随步数增加而降低？	置信度曲线分析
循环模式切换	Supervisor 能否按任务类型切换循环模式？	端到端测试：不同任务类型验证模式选择

9.7 安全架构评估（对应 §5）

安全评估已在 §5.8 AI 红队测试中详细展开。本节提供与评估框架的交叉引用和补充。

9.7.1 OWASP ASI Top 10 测试矩阵

ASI 风险	评估方法	关联章节
ASI01 目标劫持	提示注入攻击套件 + 目标变更检测	§5.4
ASI02 工具滥用	权限越界测试 + 工具参数变异	§5.3、§5.5
ASI03 身份滥用	权限提升测试 + 委托链分析	§5.2
ASI04 供应链	AI-BOM 完整性验证 + 依赖扫描	§5.6
ASI05 RCE	代码执行沙箱逃逸测试	§5.3
ASI06 记忆投毒	跨会话注入测试 + 记忆篡改检测	§3.3、§9.5.3
ASI07 通信劫持	Agent 间消息篡改测试 + mTLS 验证	§7.4.2
ASI08 级联失败	混沌工程：杀死单个 Agent，验证爆炸半径	§7.4.2
ASI09 信任利用	社会工程测试 + 可解释性审查	§3.1
ASI10 流氓 Agent	行为偏差检测 + 看门狗 Agent 验证	§5.3

9.7.2 提示注入专项测试

攻击类型	测试方法	成功标准（防御方）
直接注入	编码绕过（Base64/Hex/Unicode）；对抗性后缀	Spotlighting 将成功率降至 < 2%
间接注入	恶意指令嵌入网页/邮件/数据	CDR + 提示载体检测拦截 > 95%
多轮注入	跨对话轮次逐步建立攻击上下文	RL 对抗 Agent 发现漏洞后修补
工具描述注入	MCP 工具描述中嵌入隐藏指令	工具描述审计 + 签名验证

9.7.3 MCP 安全测试

测试项	方法	关联
DNS 重绑定（CVE-2026-11624）	模拟恶意网站连接本地 MCP 服务器	§5.5
STDIO 命令注入	验证 `command` 参数是否被无条件执行	§5.5
工具投毒	部署含恶意描述的 MCP 服务器	§5.5
地毯抽换	模拟合法工具被替换为恶意版本	§5.5
令牌传递	验证 MCP 客户端是否绕过下游 API 安全控制	§5.5

9.8 非功能性需求评估（对应 §6）

9.8.1 可观测性评估

评估维度	检查项	方法
溯源链完整性	每个请求是否可从输出回溯到输入	自动验证溯源链覆盖率
日志不可篡改性	日志是否可被修改	篡改测试 + 签名验证
指标覆盖率	§6.1.3 核心度量指标是否全部采集	指标清单核对
告警有效性	P0-P3 告警是否正确触发	告警注入测试

9.8.2 可靠性评估

评估维度	检查项	方法
故障恢复	Agent 崩溃后是否自动恢复	混沌工程 + 检查点恢复测试
降级路径	模型 API 不可用时是否有降级方案	断路器测试
数据一致性	多 Agent 并发写入是否一致	并发冲突测试

9.8.3 性能与成本评估

评估维度	检查项	目标
延迟	P50/P95/P99 推理延迟	P95 < 业务可接受阈值
令牌效率	每查询令牌消耗	趋势性下降或稳定
成本/查询	美元/查询	在预算范围内
令牌预算护栏	超预算时是否触发降级	预算超限 100% 触发

9.9 多 Agent 系统评估（对应 §7）

单 Agent 评估回答"这个 Agent 做对了吗"。多 Agent 系统的评估复杂度指数级增长------不仅要评估每个 Agent 个体，还要评估协作行为、通信正确性和整体涌现行为。

9.9.1 多 Agent 评估维度

层级	评估对象	关键问题	示例指标
L0 单 Agent	个体 Agent 在隔离环境中的表现	Worker 是否正确执行了子任务？	子任务成功率；工具调用准确率
L1 协作	Agent 间的信息传递与委托	Supervisor 是否选择了正确的 Worker？传递的信息是否完整？	路由准确率；信息丢失率；JSON 契约违规率
L2 系统	整体端到端行为	多 Agent 协作的最终输出是否正确？是否比单 Agent 更好？	端到端成功率；与单 Agent 基线的差异；总步数/令牌
L3 安全	对抗性场景下的鲁棒性	一个 Agent 被攻破后，其余 Agent 能否检测并恢复？	对抗性成功率（ASR）；跨 Agent 影响范围

9.9.2 循环模式特定的评估策略

循环模式	核心评估问题	专用检查
ReAct	循环是否在合理步数内终止？是否陷入"思考-行动-观察"死循环？	步数分布追踪；中位步数 vs P95 步数；超时率
Plan-Execute	初始规划质量如何？是否需要频繁重新规划？	规划-执行对齐度；重新规划触发率；子任务完成顺序正确性
Reflection	自我评估是否有效识别了真实错误？是否存在"假阳性反思"导致过度修正？	修正前后质量差异；无效修正率（假阳性）；振荡检测
ToT	分支剪枝是否合理？是否过早剪掉了正确路径？	剪枝准确率；最优路径保留率；令牌消耗/分支数

关键洞察： 单 Agent 的 Reflection 评估存在思维退化 风险------同一模型生成、评估和反思，重复相同错误推理 $31$ 。评估框架应使用独立 Critic 模型（不同模型家族）进行交叉验证。

9.9.3 对抗性评估与红队

参见 §5.8 AI 红队测试。多 Agent 系统特有的对抗性场景：

Agent 投毒测试： 故意将一个 Worker 的输出污染为错误/恶意，验证 Supervisor 或 Critic 能否检测 $32$
通信劫持测试： 模拟 Agent 间消息被篡改，验证 mTLS 签名验证是否生效
级联失败测试： 触发一个 Agent 超时/崩溃，验证断路器是否阻止级联传播（参见 §7.4.2）
资源耗尽测试： 一个 Agent 消耗过多令牌/步数，验证预算护栏是否触发降级

9.9.4 Loop Engineering 评估（对应 §7.7）

Loop 要素	评估问题	检查方法
Trigger	触发条件是否可靠？是否误触发或漏触发？	触发日志分析 + 阴性对照
Goal	终止条件是否可验证？是否过早或过晚终止？	Goal 达成验证 + Maker/Checker 分离
Verification	验证是否独立于生成？	检查 Checker Agent 是否使用不同模型家族
Memory	外部状态是否持久化？循环间是否遗忘关键信息？	检查 `STATE.md` / `CLAUDE.md` 完整性

9.10 SOC 场景的评估启示（人机协作实证）

本节基于 SOC（安全运营中心）人机协作的实证研究，其发现与前 8 章多处交叉验证。SOC 是 AI Native 系统"人在回路"评估的最佳真实场景。

SOC 人机协作评估的关键启示（基于 45 名分析员、3,090 条查询的实证数据）：

SOC 实证发现	对应章节	架构含义
93% 查询映射到 NICE 框架；查询集中在 ATT&CK 数据源解释	§6.1.5 遥测分类标准化	遥测应按 NICE/ATT&CK 标准框架分类，便于跨团队协作
57% 对话仅 2 步，75% 为 2-3 步	§4.2 Agentic Loop、§7.2 循环模式选型	短交互是主流------系统应优化 Reactive/ReAct 等轻量循环，而非默认 Plan-Execute
低参与度组 1-2 个月脱离；持续组 4-8 个月	§6.1.4 用户脱离作为告警信号	脱离是可观测的设计失败信号------系统应追踪脱离模式并归因
感知效用抵消了孤立失败	§2 原则 P6 自动化记账，人工决策	即使有错误，只要整体效用足够，用户仍会持续使用------信任校准应容忍局部错误（参见 §3.1 信任校准 UI）

设计建议（含交叉引用）：

将 LLM 技术工件解释嵌入 SOC 仪表盘（对应 §3.1 交互层------证据嵌入工作流）
将 LLM 助手用于微任务 （解释可疑命令、摘要日志、起草事件记录），最小化上下文切换（对应 §3.1 交互层）
调查任务优先呈现证据而非推荐（对应 §3.1 证据优先展示原则、§6.1.5 遥测 UX 标准化）

9.11 评估覆盖矩阵总览

下表将前 8 章的每个关键主题映射到本章的评估子节，确保无评估盲区。

章节	主题	评估子节	覆盖状态
§1	AI Native 成熟度	§9.1 评估成熟度分层	✅
§2	架构原则	§9.4 原则合规性评估	✅
§3.1	交互层	§9.5.5 交互层评估	✅
§3.2	编排层	§9.5.4 编排层评估	✅
§3.3	知识层	§9.5.3 知识层评估	✅
§8	知识层进阶（混合检索/GraphRAG/CRAG；Self-RAG/Agentic RAG 远期）	§9.5.3 知识层评估（含多跳正确性、CRAG 路由、迭代收敛等维度）	✅
§3.4	智能层	§9.5.2 智能层评估	✅
§3.5	基础设施层	§9.5.1 基础设施层评估	✅
§4.1	请求生命周期	§9.6.1 请求生命周期测试	✅
§4.2	Agentic Loop	§9.6.2 Agentic Loop 评估	✅
§5.1-5.3	安全原则 + OWASP ASI	§9.7.1 OWASP ASI 测试矩阵	✅
§5.4	提示注入	§9.7.2 提示注入专项测试	✅
§5.5	MCP 安全	§9.7.3 MCP 安全测试	✅
§5.6	供应链	§9.7.1 ASI04 测试	✅
§5.8	红队测试	§9.7 + §9.9.3 交叉引用	✅
§6.1	可观测性	§9.8.1 可观测性评估	✅
§6.2	可靠性	§9.8.2 可靠性评估	✅
§6.3	性能与成本	§9.8.3 性能与成本评估	✅
§7	多 Agent 系统	§9.9 多 Agent 评估	✅
§7.7	Loop Engineering	§9.9.4 Loop Engineering 评估	✅
§8	知识层进阶 / RAG	§9.5.3 知识层评估	✅
§3.1+§4.2+§6.1	人机协作（交叉验证）	§9.10 SOC 场景评估启示	✅

10. 关键风险与扩展点（Risks & Extension Points）

10.1 已知风险

风险	影响	缓解
提示注入成功率接近 100%	Agent 目标被劫持	Spotlighting + Constitutional Classifiers + 输入隔离
模型供应链投毒	后门持久化	AI-BOM + 签名验证 + 依赖审计
级联失败	单点故障系统性扩散	断路器 + 数字孪生重放 + JIT 访问
模型幻觉与漂移	渐进性行为偏差	行为基线 + 持续监控 + 版本化回滚
非线性成本	不可控的费用增长	令牌预算追踪 + 成本管理基础设施
影子 AI	未受控的 LLM 使用	显式标记 + 治理策略 + 批准工具清单
GraphRAG 索引成本爆炸	语料增长导致索引阶段 LLM 调用失控	增量索引 + 索引预算上限 + 缓存社区摘要（对应 §8.4）
Ontology Schema 老化	业务拓扑变更后图谱查询返回陈旧/错误关系	Schema 版本化 + 变更触发回归测试 + 人工评审门禁（§8.8）
CRAG 质检器被注入	攻击者污染检索源使质检器判为 Correct	质检器独立模型族 + 输出范围校验 + 回退路径不信任单一源（§8.5）
检索源投毒	知识库被注入恶意/误导内容	写入需认证 + 内容签名 + 来源溯源链（对应 P4 永远验证）

10.2 扩展点

Agent 间协议： MCP / A2A / gRPC 的版本固定与协议锁定
多 Agent 架构： Trust Zones + 看门狗 Agent 验证同伴 + 相互认证
联邦学习： 分布式训练支持跨组织协作而不泄露数据
边缘部署： 嵌入式 AI 用于低延迟/离线场景
知识层演进（含远期规划）： GraphRAG 增量索引 + 动态社区选择、Ontology Schema 自动漂移检测、CRAG 质检器轻量化（SLM 化以降本）；远期方向------Agentic RAG 工具发现（运行时自动注册新检索源）、Self-RAG 反思令牌微调

11. 资料来源（Source References）

Web 检索补充来源（2026 年最新）

#	来源	贡献内容	链接
$1$	OX Security / CSDN	MCP 安全漏洞统计（97% 企业部署有高危漏洞）	https://blog.csdn.net/weixin_42376192/article/details/160267630
$2$	Threat-Modeling.com	CVE-2026-11624 MCP DNS 重绑定漏洞	https://threat-modeling.com/cve-2026-11624-mcp-dns-rebinding/
$3$	OX Security / CSDN	MCP STDIO 传输层设计缺陷	https://blog.csdn.net/weixin_42376192/article/details/160941278
$4$	arXiv 2506.02040	MCP 生态攻击向量系统性研究（四类攻击）	https://arxiv.org/pdf/2506.02040v2
$5$	MCP 官方规范	安全最佳实践（混淆代理、令牌传递禁止）	https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices.md
$6$	Galileo AI	LLM/Agent 红队测试 8 大策略	https://galileo.ai/blog/llm-red-teaming-strategies
$7$	NVIDIA AI Red Team / CSDN	Agent 执行层安全实操指南	https://blog.csdn.net/weixin_42376192/article/details/157992964
$8$	CSA / CSDN	Agentic AI 红队测试 12 类风险	https://blog.csdn.net/qq_33163046/article/details/157389808
$9$	AWS AI Labs / EMNLP 2025	自动化红队框架 AgentHarm-Gen	https://preview.aclanthology.org/override-month/2025.emnlp-industry.62.pdf
$10$	Microsoft Azure	AI Red Teaming Agent (PyRIT)	https://learn.microsoft.com/eu-es/azure/ai-foundry/concepts/ai-red-teaming-agent
$11$	Reg-Lab	EU AI Act 合规指南	https://reg-lab.com/eu-ai-act-compliance-guide/
$12$	InformedClearly	布鲁塞尔效应与全球 AI 治理碎片化	https://informedclearly.com/en/technology/54687/brussels-effect-eu-ai-act-enforcement-2026
$16$	Presenc AI	多 Agent 编排框架 2026 对比	https://presenc.ai/research/multi-agent-orchestration-frameworks-2026
$17$	Inductivee	Agentic AI Frameworks 2026 对比	https://inductivee.com/blog/agentic-ai-frameworks-comparison
$18$	Uvik.net	Agentic AI Frameworks 生产对比（含基准）	https://uvik.net/blog/agentic-ai-frameworks/
$19$	James Ross Jr.	AI-Native 应用架构模式实战	https://www.jamesrossjr.com/blog/building-ai-native-applications
$23$	VeloDB	混合搜索架构详解	https://www.velodb.io/glossary/what-is-hybrid-search
$24$	Ayhan Sipahi	RAG 架构模式：超越基础向量搜索	https://sph.sh/en/posts/rag-architecture-patterns/
$25$	SAP	AI-Native North Star Architecture	https://architecture.learning.sap.com/assets/ai-native-north-star-architecture-public-q2-2026.pdf
$26$	Microsoft Azure	AI 工作负载架构模式	https://learn.microsoft.com/en-us/azure/well-architected/ai/architecture-pattern
$27$	BeyondScale	多 Agent 系统架构：构建协作 AI	https://beyondscale.tech/blog/multi-agent-systems-architecture-patterns
$28$	Channel.tel	MCP vs A2A：工具协议与 Agent 协议	https://www.channel.tel/blog/mcp-vs-a2a-protocols-tools-agents-2026
$29$	tspi.at	LLM Agent 模式与行为综合指南	https://tspi.at/2025/03/28/llmagents.html
$30$	EMNLP 2025	ReflAct：基于目标-状态反思的 LLM Agent 决策	https://preview.aclanthology.org/navbar-space/2025.emnlp-main.1697.pdf
$31$	arXiv 2512.20845	MAR：多 Agent Reflexion 提升 LLM 推理能力	https://arxiv.org/pdf/2512.20845v2
$32$	Chris Cruz	架构化 Agentic AI：17 种模式的意义	https://chriscruz.nyc/blogs/architecting-agentic-ai-why-17-patterns-matter.html
$33$	AWS	AWS 上的多 Agent 架构（技术工坊）	https://aws.amazon.com/marketplace/build-learn/ai-agent-learning-series/multi-agent-architectures
$34$	Microsoft	多 Agent 参考架构：消息驱动通信	https://microsoft.github.io/multi-agent-reference-architecture/docs/agents-communication/Message-Driven.html
$35$	掘金 / 米小虾	AI Agent 协议时代：MCP、A2A、AG-UI 全景解析	https://juejin.cn/post/7646938869472378915
$37$	Gradient Network	Symphony：集体织物中的多 Agent 智能	https://gradient.network/research/symphony-multi-agent-intelligence-in-a-collective-fabric
$38$	掘金 / AI程序员	Claude Code 的三种多 Agent 模式：Coordinator、Swarm 和 Fork	https://juejin.cn/post/7623322130490621998
$39$	y-agent.github.io	Inside Claude Code：多 Agent 编排（源码逆向分析）	https://y-agent.github.io/inside-claude-code/07-multi-agent-orchestration.html
$40$	markdown.engineering	Claude Code Coordinator Mode 深度解析	https://www.markdown.engineering/learn-claude-code/21-coordinator-mode
$41$	claudefa.st	Claude Code Agent Teams：并行编排多会话	https://claudefa.st/blog/guide/agents/agent-teams
$42$	explainx.ai	什么是 Loop Engineering？超越提示词工程的新范式	https://explainx.ai/blog/what-is-loop-engineering-ai-agents-2026
$43$	Addy Osmani	Loop Engineering（原始论文）	https://addyosmani.com/blog/loop-engineering/
$44$	mer.vin	Claude Fable 5 自改进 Agent：14 步循环工程指南	https://mer.vin/2026/06/claude-fable-5-self-improving-agents-14-step-loop-engineering-guide/
$45$	GitGuardian	AI Agents Authentication: How Autonomous Systems Prove Identity（含 2026 密钥泄露统计）	https://blog.gitguardian.com/ai-agents-authentication-how-autonomous-systems-prove-identity/
$46$	Zylos Research	Secretless AI Agents: From .env Files to Workload Identity	https://zylos.ai/research/2026-05-09-secretless-ai-agents-workload-identity
$47$	Aembit	AI Agent Identity: The Multi-Protocol Authentication Gap	https://aembit.io/blog/ai-agent-identity-security/
$48$	Microsoft GraphRAG	GraphRAG 官方文档（索引流水线、Local/Global 搜索、社区层级）	https://microsoft.github.io/graphrag/
$49$	Microsoft Research	GraphRAG：通过动态社区选择改进全局搜索（GraphRAG 2.0）	https://www.microsoft.com/en-us/research/blog/graphrag-improving-global-search-via-dynamic-community-selection/
$50$	arXiv 2401.15884	Corrective Retrieval Augmented Generation（CRAG 原始论文，PopQA +5.5pp）	https://arxiv.org/abs/2401.15884
$51$	Meilisearch	Corrective RAG：工作流、实现与实践指南	https://www.meilisearch.com/blog/corrective-rag
$52$	arXiv 2310.11511	Self-RAG：通过自我反思学习检索、生成与批判（ICLR 2024，反思令牌）	https://arxiv.org/abs/2310.11511
$53$	Weaviate	什么是 Agentic RAG？从 LLM RAG 到 AI Agents	https://weaviate.io/blog/what-is-agentic-rag
$54$	arXiv 2501.09136	Agentic Retrieval-Augmented Generation：规划、路由与自我批判综述	https://arxiv.org/html/2501.09136v4
$55$	Haystack (deepset)	Hypothetical Document Embeddings (HyDE) 文档	https://docs.haystack.deepset.ai/docs/hypothetical-document-embeddings-hyde
$56$	arXiv 2401.18059	RAPTOR：递归抽象处理的树状组织检索（ICLR 2024）	https://arxiv.org/abs/2401.18059
$57$	LlamaIndex	Introducing the Property Graph Index：用 LLM 构建知识图谱	https://www.llamaindex.ai/blog/introducing-the-property-graph-index-a-powerful-new-way-to-build-knowledge-graphs-with-llms
$58$	LlamaIndex	Customizing Property Graph Index：Schema-guided 抽取与实体去重	https://www.llamaindex.ai/blog/customizing-property-graph-index-in-llamaindex
$59$	Digital Applied	为什么 88% 的 AI Agent 进不了生产（失败框架分析）	https://www.digitalapplied.com/blog/88-percent-ai-agents-never-reach-production-failure-framework
$60$	Modern Data 101	数据产品与 AI 交互的架构标准（类型化、可发现的契约）	https://moderndata101.substack.com/p/architecture-data-products-ai-interactions
$61$	MorphLLM	Context Rot：为什么 LLM 随上下文增长而退化（含 lost-in-the-middle、Chroma 18 模型研究）	https://www.morphllm.com/context-rot
$62$	DiffRay	Context Dilution：更多 token 如何损害 AI（Stanford/Google/Anthropic/Meta 研究，13.9%--85% 衰减）	https://diffray.ai/blog/context-dilution/

附录 A：速查清单（Quick Reference Checklist）

安全清单

非功能性清单

知识层 / RAG 清单（对应 §8）

混合搜索（BM25 + 向量 + RRF + 重排序）替代纯向量检索（§8.1）
多阶段 RAG：查询扩展 → 检索 → 重排序 → 上下文构建 → 生成与验证（§8.2）
多跳推理场景评估 GraphRAG（社区层级 + 动态社区选择）（§8.4）
CRAG 质检网关：检索评估器 + Correct/Incorrect/Ambiguous 路由 + 降级回退（§8.5）
（远期规划，稳定运行后再评估） 复杂任务考虑 Agentic RAG（查询路由 + 自我反思 + 迭代）（§8.6）
短查询/长文档语义鸿沟考虑 HyDE；全局主题+局部细节考虑 RAPTOR（§8.7）
业务刚性关系/数值属性过滤采用 Ontology RAG（Neo4j + Schema-guided 抽取）（§8.8）
生产级系统按数据特性分层融合（向量+图+SQL），CRAG 编排，本地 LLM 保数据主权（§8.9）
每层引入由真实失败案例驱动，而非一上来全量堆叠（§8.10 实施建议）

多 Agent 系统清单

评估清单

附录 B：术语表（Glossary）

安全与合规

术语	全称 / 英文	释义
AI-BOM	AI Bill of Materials	AI 物料清单。扩展传统软件物料清单（SBOM）至 AI 领域，记录模型溯源、训练数据谱系、微调参数、依赖组件等。OWASP 推荐采用 CycloneDX ML-BOM 标准。
ABAC	Attribute-Based Access Control	基于属性的访问控制。根据用户、资源、环境等多维属性动态评估授权，比 RBAC 更细粒度。
ASI	Agentic Security Initiative	OWASP 下设的 Agentic 安全倡议，发布 Agentic 应用 Top 10 风险清单（ASI01-ASI10）。
CDR	Content Disarm and Reconstruction	内容拆解与重构。对传入的文档/文件进行深度清洗，移除潜在恶意内容后重建安全版本。
CSA	Cloud Security Alliance	云安全联盟。非营利组织，发布 Agentic AI 红队测试指南（12 类风险框架）等安全标准。
CVE	Common Vulnerabilities and Exposures	通用漏洞披露。全球统一的安全漏洞编号系统（如 CVE-2026-11624 为 MCP DNS 重绑定漏洞）。
CycloneDX	---	开源软件物料清单（SBOM）标准，由 OWASP 维护。其 ML-BOM 扩展支持 AI/ML 组件。
FedRAMP	Federal Risk and Authorization Management Program	美国联邦风险与授权管理计划。美国政府云服务安全评估标准。
FINRA	Financial Industry Regulatory Authority	美国金融业监管局。证券行业自律组织，对 AI 在金融领域的使用有合规要求。
GDPR	General Data Protection Regulation	欧盟通用数据保护条例。2018 年生效的数据隐私法规。
HIPAA	Health Insurance Portability and Accountability Act	美国健康保险流通与责任法案。医疗数据隐私与安全标准。
HITL	Human-in-the-Loop	人在回路。在自动化流程中保留人工审批节点，尤其用于高风险操作。
JIT	Just-in-Time	即时访问。按需临时授权（通常分钟级过期），而非长期持久权限。
JEA	Just-Enough-Administration	刚好够用的管理权限。最小化管理范围，自动过期。
Least Agency	---	最小代理权。OWASP 提出的概念，是 Least Privilege 的延伸------不仅限制 Agent 拥有哪些工具，还限制每个工具能做什么、多久一次、在何处执行。
MFA	Multi-Factor Authentication	多因素认证。本文档指出基于短信的 MFA 属于"摩擦"而非"屏障"，不足以防御 Agent 攻击者。
NIST SP 800-207	---	美国国家标准与技术研究院发布的零信任架构标准（2020），定义零信任三大原则。
OpenSSF	Open Source Security Foundation	开源安全基金会。Linux 基金会下属，提供 Scorecard 工具评估开源项目依赖健康度。
OWASP	Open Worldwide Application Security Project	开放全球应用安全项目。非营利组织，发布 LLM Top 10、Agentic Top 10 等安全风险清单。
PoC	Proof of Concept	概念验证。用于证明漏洞可利用的具体脚本、崩溃输入或失败测试。
RBAC	Role-Based Access Control	基于角色的访问控制。按角色分配权限，本文档定义为成熟度基础层的最低要求。
SAST	Static Application Security Testing	静态应用安全测试。在不运行代码的情况下分析源代码以发现漏洞。
SBOM	Software Bill of Materials	软件物料清单。记录软件组件及其依赖关系的清单，AI-BOM 是其扩展。
SIEM	Security Information and Event Management	安全信息与事件管理。集中收集、关联、分析安全日志的平台。
SOAR	Security Orchestration, Automation and Response	安全编排、自动化与响应。自动执行安全响应剧本的平台。
SOC	Security Operations Center	安全运营中心。7×24 小时监控、检测、调查和响应安全事件的团队/设施。参见 §9.10 引用的 SOC 人机协作实证研究（3,090 条查询）。
SPIFFE / SPIRE	Secure Production Identity Framework for Everyone / SPIFFE Runtime Environment	工作负载身份标准及其参考实现。基于"工作负载是什么 + 在哪里运行"进行密码学身份证明，无需共享密钥。参见 §5.1.3 凭证管理 L8。
Spotlighting	---	Microsoft 提出的技术，通过明确界定不可信内容边界降低间接提示注入成功率（从 >50% 降至 <2%）。
TOCTOU	Time-of-Check to Time-of-Use	检查时到使用时攻击。权限检查与实际执行之间的时间窗口被利用。

AI / ML 技术

术语	全称 / 英文	释义
Agentic RAG	Agentic Retrieval-Augmented Generation	智能体化 RAG。把检索器、重排序器、图查询等封装为工具，由 Agent 按查询意图动态编排（查询路由、自我反思、多跳迭代）。参见 §8.6（远期规划）。
Constitutional Classifiers	---	Anthropic 提出的分类器技术，阻断 95% 的越狱尝试，过度拒绝率极低。
CRAG	Corrective Retrieval-Augmented Generation	纠正性检索增强生成。在检索结果传入 LLM 前用质检评估器打分并按 Correct/Incorrect/Ambiguous 路由，减少幻觉。参见 §8.5。
CSIRO	Commonwealth Scientific and Industrial Research Organisation	澳大利亚联邦科学与工业研究组织。参见 §9.10 引用的 SOC 人机协作实证研究（3,090 条查询）。
Embedding	---	嵌入。将文本/图像等高维数据映射为低维稠密向量，使语义相似的内容在向量空间中距离相近。
GPAI	General-Purpose AI Model	通用目的 AI 模型。EU AI Act 对 GPT、Gemini 等基础模型的分类，需履行透明度义务。
GraphRAG	Graph-based Retrieval-Augmented Generation	基于知识图谱的 RAG。索引阶段把语料抽取为图（实体+关系+社区），查询时按图遍历多跳路径，支持多跳推理与全局主题问答。参见 §8.4。
HNSW	Hierarchical Navigable Small World	分层可导航小世界图。主流近似最近邻（ANN）向量搜索算法。
HyDE	Hypothetical Document Embeddings	假想文档嵌入。检索前先用 LLM 为查询生成一份"假想答案文档"，用其向量做检索，弥合短查询与长文档的语义鸿沟。参见 §8.7。
LLM-as-Judge	---	用大语言模型作为评估器，对另一个 LLM 的输出进行质量打分。
MCP	Model Context Protocol	模型上下文协议。Anthropic 于 2024 年推出的开放标准，被称为"AI 界的 USB-C"，标准化 Agent 与外部工具/资源的交互。
MLOps / LLMOps	ML Operations / LLM Operations	机器学习/大语言模型运维。涵盖模型部署、监控、版本管理、评估、回滚的全生命周期实践。
OOD	Out-of-Domain	域外数据。嵌入模型训练集之外的实体（新产品名、内部代码），纯向量搜索无法有效处理。
Ontology RAG	Ontology-based Retrieval-Augmented Generation	基于本体的 RAG。用人工定义的 Schema（领域专家 / ER 模型）在图数据库中存储企业名词字典、业务拓扑与刚性约束，按 Cypher 路径查询。参见 §8.8。
RAG	Retrieval-Augmented Generation	检索增强生成。先从知识库检索相关文档，再将其作为上下文传给 LLM 生成回答，减少幻觉。
RAPTOR	Recursive Abstractive Processing for Tree-Organized Retrieval	递归抽象处理的树状组织检索。索引时递归地聚类与摘要文本块，构建多层级树索引，兼顾局部细节与全局主题。参见 §8.7。
RRF	Reciprocal Rank Fusion	倒数排名融合。将多个检索结果列表按排名倒数加权合并的算法，用于混合搜索。
Self-RAG	Self-Reflective Retrieval-Augmented Generation	自反思 RAG。训练 LLM 输出"反思令牌"（Retrieve / IsRel / IsSup / IsUse），自主决定何时检索与评估生成质量。参见 §8.6（远期规划）。
SLM	Small Language Model	小语言模型。参数量较小的模型，可本地部署，用于数据主权和低延迟场景。

框架与标准

术语	全称 / 英文	释义
A2A	Agent-to-Agent Protocol	Agent 间通信协议。Google 推出的标准，用于多 Agent 系统的互操作。
ADK	Agent Development Kit	Agent 开发套件。Google 推出的框架，与 Vertex AI 深度集成。
AIVSS	AI Vulnerability Scoring System	AI 漏洞评分系统。OWASP 提出的风险量化框架。
BM25	Best Matching 25	最佳匹配 25。经典的稀疏关键词检索算法，基于词频和逆文档频率。
PropertyGraph	Property Graph	属性图。节点和边都带属性的图数据模型（Neo4j 原生）。LlamaIndex 的 `PropertyGraphIndex` 支持 Schema-guided 抽取，降低 Ontology 构建门槛。参见 §8.8。
C2PA	Coalition for Content Provenance and Authenticity	内容来源与真实性联盟。制定数字内容水印和溯源标准。
EU AI Act	European Union Artificial Intelligence Act	欧盟人工智能法案（Regulation (EU) 2024/1689）。全球首部全面 AI 监管法规，按风险分级。
JSONL	JSON Lines	每行一个 JSON 对象的文本格式。用于捕获 Agent 运行轨迹事件流，是评估的可观测性基础。
KNN	K-Nearest Neighbors	K 近邻。向量搜索中暴力扫描全部向量的精确算法（对比 ANN 近似算法）。
MITRE ATT&CK	---	MITRE 公司维护的攻击行为知识库，涵盖真实世界观察到的攻击战术和技术（TTP）。
NICE Framework	National Initiative for Cybersecurity Education Framework	美国国家网络安全教育框架。定义网络安全角色的任务、知识、技能。
OpenTelemetry	---	开源可观测性标准（CNCF 项目），提供统一的追踪、指标、日志采集。
OpenInference	---	开源 LLM 推理追踪标准，基于 OpenTelemetry 扩展，定义 AI 应用的 span 属性规范。
TTP	Tactics, Techniques, and Procedures	战术、技术与程序。MITRE ATT&CK 框架中描述攻击者行为的核心维度。
Loop Engineering	---	循环工程。设计自动提示 AI Agent 的系统（而非手动输入提示词）。参见 §7.7。
Coordinator Mode	---	Claude Code 的中心化多 Agent 模式。协调者仅拥有 4 个工具（不执行文件/命令操作），负责拆任务、派活、综合结果。参见 §7.3.1。
Agent Teams / Swarm	---	Claude Code 的团队协作模式。队友间可直接通信（SendMessage + mailbox），从共享任务列表认领任务。参见 §7.3.3。
Fork Subagent	---	Claude Code 的轻量并行模式。子进程完整继承父对话上下文 + prompt cache 共享，无横向通信。参见 §7.3.5。
Maker/Checker	---	循环工程中的验证模式。一个 Agent 生成方案（Maker），另一个独立 Agent 仅看产物和评分标准进行验证（Checker）。参见 §7.7.4。
Prompt Cache	---	提示词缓存。LLM API 对重复的上下文前缀进行缓存计费（通常 90% 折扣），Fork 子代理通过共享父 cache 大幅降低令牌消耗。

附录 C：治理与合规（Governance & Compliance）

C.1 治理结构

要素	说明
AI 审查委员会	跨职能委员会（安全、法务、合规、工程、业务），制定伦理准则、透明模型评估和事件响应流程
策略执行嵌入部署管道	持续策略执行于部署管道，而非事后审计
影子 AI 风险管理	员工未经 IT 批准使用 LLM------必须显式标记、监控和管理

C.2 合规时间线概览

美国要求所有联邦机构在 2027 年前采用零信任
受监管行业：HIPAA、FINRA、GDPR、FedRAMP、EU AI Act 已施加与零信任一致的要求，截止日期临近

C.3 EU AI Act 关键合规时间线（Regulation (EU) 2024/1689）

⚠️ 2026 年 8 月 2 日是高风险 AI 系统合规的硬截止日。 最高罚款 €35M 或全球年营业额 7%。 $11$ $12$

日期	生效内容	状态	最高罚款
2024.08.01	法案正式生效	✅ 已生效	---
2025.02.02	禁止类 AI 做法 + AI 素养要求	✅ 已生效	€35M 或营业额 7%
2025.08.02	GPAI 规则 + 治理结构 + 处罚条款	✅ 已生效	€15M 或营业额 3%
2026.08.02	高风险 AI 系统九大要求（Articles 8-15）+ 部署者义务 + 透明度	⚠️ 即将强制	€15M 或营业额 3%
2027.08.02	嵌入受管制产品中的高风险 AI	📅 规划中	€15M 或营业额 3%

C.4 四级风险分类

禁止类： 潜意识操纵、社会评分、无目标面部抓取、工作场所情绪识别等（8 类）
高风险（Annex III 八大场景）： 关键基础设施、教育/培训、就业管理、金融服务、执法、边境管控、司法进程、生物识别
有限风险： 透明度义务（AI 聊天机器人须披露身份、深度伪造须标注）
最小风险： 无强制义务

C.5 高风险 AI 九大技术要求（Articles 8-15）

$11$

风险管理系统（Article 9）
数据治理（Article 10）
技术文档（Article 11）
记录与日志（Article 12）
透明性及向部署者提供信息（Article 13）
人工监督（Article 14）
准确性、鲁棒性与网络安全（Article 15）
质量管理体系（Article 17）
上市后监控（Article 61）------ 主动检测"概念漂移"和性能衰减

C.6 执法现状与布鲁塞尔效应

执法差距： 截至 2026 年 3 月，27 个成员国中仅 8 个指定了国家主管机构 $12$ 。

布鲁塞尔效应： 即使不在欧盟运营，微软、Google、OpenAI 等已在全球范围对齐 EU 标准（如 Microsoft 365 Copilot 集成 Claude 在 EU 租户中默认关闭） $12$ 。

C.7 AI 成熟度分级

级别	能力
Level 1 基础	聊天
Level 2 中级	RAG、工具、多轮
Level 3 高级	Agent------多工具、多步工作流、决策、记忆/上下文、自我纠错