Anthropic《Building effective agents》系统解读：从基本概念到 PPT Master 实践
原文：Building effective agents
实践项目：PPT Master
系统学习一篇工程文章，不能只记住结论，也不能一开始就跳到自己的项目上寻找对应关系。更合适的顺序是：
基本概念 → 架构模式 → 选择方法 → 项目应用 → 形成观点Anthropic 的这篇文章首先提供了一套理解 Agentic System 的基础语言，然后介绍常见工作流模式，最后才讨论自主 Agent 的适用场景和工程原则。
原文当前页面也明确提示：自 2024 年 12 月发布以来，Agent 工具生态已经变化，并将读者引向后续的 Managed Agents。因而本文把这五种模式当作仍然有效的架构词汇和选择框架，而不把它们误写成 Anthropic 当前托管运行时的完整蓝图。
本文也按照这个顺序展开。前半部分先回答“这些概念分别是什么”，后半部分再用 PPT Master 说明它们如何进入真实系统。
一、基本概念：什么是 Agentic System
Anthropic 使用 Agentic System 统称那些由 LLM 与工具共同完成任务的系统，并在其中区分 Workflow 和 Agent。
Workflow：执行路径由代码预先确定
Workflow 是通过预定义代码路径组织 LLM 和工具的系统。
开发者提前决定：
- 先执行哪一步；
- 上一步的结果交给谁；
- 什么条件进入下一步；
- 失败时回到哪里；
- 哪些节点必须停止等待确认。
LLM 可以参与每一步的内容生成和判断，但它不能随意改变整个流程。
Agent：执行路径由模型动态决定
Agent 则由 LLM 根据当前目标和环境反馈，动态决定：
- 下一步做什么；
- 使用哪个工具；
- 是否需要继续搜索；
- 是否调整计划；
- 什么时候完成或请求人类帮助。
因此，Workflow 与 Agent 最本质的区别不是有没有工具，也不是调用了几次模型，而是：
核心判断
任务执行过程的控制权主要在代码中，还是在模型中。
| 维度 | Workflow | Agent |
|---|---|---|
| 路径 | 预先定义 | 运行时动态形成 |
| 控制者 | 代码 | LLM |
| 优势 | 稳定、可预测、易测试 | 灵活、能处理开放问题 |
| 代价 | 难以适应未知路径 | 成本更高，错误可能累积 |
| 适用任务 | 步骤清晰、结构稳定 | 步骤难以预判、需要动态决策 |
两者没有高低之分。Agent 不是 Workflow 的“高级版本”，而是适用于另一类不确定性的问题。
二、基础构建块：Augmented LLM
在讨论多步骤系统之前，需要先理解 Augmented LLM。
它是在普通 LLM 基础上增加三类能力：
| 能力 | 作用 |
|---|---|
| Retrieval | 从外部资料中取得当前任务需要的信息 |
| Tools | 调用 API、代码、文件系统或其他服务采取行动 |
| Memory | 保留跨步骤或跨会话需要的信息 |
Augmented LLM 是 Workflow 和 Agent 的共同基础。
“模型能够使用工具”并不自动意味着它已经是 Agent。只有当模型开始动态决定流程和工具使用方式时，系统才更接近 Agent。
这一点很重要，因为许多任务并不需要完整的自主循环。一次经过良好设计的 LLM 调用，再配合检索、工具和上下文示例，可能已经足够。
三、实现方式：直接调用 API，还是使用框架
有了构建块之后，下一个现实问题是用什么实现。Anthropic 列举了几类常见选择：Claude Agent SDK、AWS 的 Strands Agents SDK，以及 Rivet、Vellum 这类图形化的工作流构建与测试工具。
这些框架简化了重复性的底层工作：调用 LLM、定义和解析工具、把多次调用串联起来。但原文同时给出了一个明确的警告：
They often create extra layers of abstraction that can obscure the underlying prompts and responses, making them harder to debug.
因此原文的建议是先直接使用 LLM API：许多模式只需要几行代码就能实现。如果确实要引入框架，则必须理解框架内部的实现，因为"对底层行为的错误假设"是最常见的问题来源。
这条建议与后面的透明性原则是同一件事的两面。抽象层带来的便利，代价往往是你不再清楚模型实际收到了什么、返回了什么。当系统出错时，能否读到真实的 prompt 和 response，决定了你是在调试还是在猜测。
四、什么时候不应该使用 Agent
Anthropic 的建议不是“尽量构建 Agent”，而是从最简单的可行方案开始。
Agentic System 通常以更高的成本和延迟，换取更好的任务表现或更强的灵活性。多一次调用、多一个角色、多一轮反馈，都会引入新的成本和失败点。
因此，选择架构前应依次判断。原文以文字给出这组建议，下面的决策树是笔者按同样逻辑整理的，便于在实际选型时逐条对照：
这个决策树背后的原则是：
复杂度边界
- 能用单次调用解决，就不增加流程；
- 能用固定流程解决，就不交出动态控制权；
- 只有在步骤无法预判、且过程能够持续验证时，才使用 Agent。
五、五种常见 Workflow 模式
Anthropic 总结了五种常见模式。它们不是必须全部使用的组件，而是面向不同问题结构的选择。
1. Prompt Chaining：把复杂任务拆成顺序步骤
Prompt Chaining 将一个任务拆成多个固定步骤，前一步输出成为后一步输入。
生成大纲 → 检查大纲 → 生成正文 → 检查正文它适合：
- 任务可以稳定分解；
- 每一步都比原任务更容易完成；
- 可以在中间加入 gate 检查质量。
它的主要风险是错误传播。上游输出错误，下游可能在错误基础上继续生成。因此，提示链的关键不是“多调用几次”，而是设置有效的中间检查点。
2. Routing：先分类，再交给专门流程
Routing 先判断输入属于哪一类，再交给相应的 Prompt、模型或工具处理。
例如：
- 退款请求进入退款流程；
- 技术问题进入技术支持流程；
- 简单任务交给小模型；
- 复杂任务交给更强模型。
Routing 适合类别明确、且分类本身能够可靠完成的任务。
它的价值在于分离关注点，避免一个通用 Prompt 同时处理差异很大的输入。
3. Parallelization：并行分块或多次投票
Parallelization 有两种不同目的。
Sectioning：拆分独立子任务
将彼此独立的部分并行处理，最后汇总，主要用于提高速度或分离关注点。
Voting：对同一任务进行多次判断
让多个模型或多组 Prompt 独立处理同一问题，再通过投票或阈值提高置信度。
两种方式虽然都使用并行调用，但优化目标不同：
- Sectioning 优化吞吐；
- Voting 优化可靠性。
只有子任务真正独立时，并行化才不会破坏共享上下文和整体一致性。
4. Orchestrator-Workers：动态决定子任务
Orchestrator-Workers 使用一个中央 LLM 分析任务、动态拆解子任务、分配给 Worker，最后综合结果。
它与 Parallelization Sectioning 的关键区别是：
| 模式 | 子任务如何产生 |
|---|---|
| Sectioning | 运行前已经定义 |
| Orchestrator-Workers | 由 Orchestrator 根据输入动态决定 |
例如，一个复杂代码修改任务需要调整哪些文件，通常只有读完需求和代码仓库后才能确定，因此更适合动态编排。
5. Evaluator-Optimizer：在反馈中迭代
Evaluator-Optimizer 由一个模型生成结果，另一个模型或评估机制提供反馈，再根据反馈进行改进。
它适合满足两个条件的任务：
- 输出在收到反馈后能够明显改善；
- 系统能够提供具体、有效的反馈。
如果没有清晰标准，Evaluator 只会输出听起来合理的批评。
原文没有展开循环终止的问题，但这是工程实现中绕不开的一步。笔者在实践中使用的停止条件有三类：
- 达到质量阈值；
- 达到最大迭代次数；
- 连续多轮没有可测量改进。
六、自主 Agent：基于环境反馈持续行动
当任务步骤无法预先确定时，系统才需要更高程度的自主 Agent。
下面这张最小 Agent 循环图是笔者归纳的简化版本，原文的示意图画法不同，但要素一致：
这里最关键的不是“循环”，而是环境反馈。
测试输出、文件状态、API 返回值和用户确认都是 ground truth。没有这些反馈时，模型只是根据自己的文字继续生成，错误也会在循环中不断累积。
原文给出的两个落地领域
这个判断不是抽象推论。原文在附录中列举了两个已经跑通的应用领域，它们能说明什么样的任务真正适合 Agent。
客户支持：这类任务天然沿着对话流程推进，同时需要访问外部信息并采取行动。Agent 可以通过工具调取客户资料、订单历史和知识库文章，也可以执行退款、更新工单这类可编程操作。关键在于成功与否有明确定义——问题是否被解决，是可以判定的。
编码：原文认为这个领域展现出的潜力尤其显著，理由是代码方案"verifiable through automated tests"，Agent 能够把测试结果当作反馈来迭代，问题空间结构清晰，产出质量可以被客观衡量。Anthropic 自己的实践是让 Agent 依据 pull request 描述解决真实的 GitHub issue。
两个领域的共同点很清楚：存在一个 Agent 自己无法伪造的成功信号。工单是否解决、测试是否通过，都不由模型的自我陈述决定。
因此，一个可靠 Agent 至少需要（以下为笔者据此归纳的检查项）：
- 能够验证行动结果；
- 能够识别失败状态；
- 能够在必要时修改计划；
- 能够在歧义或高风险处请求人类判断；
- 有明确的完成条件和停止条件。
七、ACI：Agent 与工具之间的接口
ACI（Agent-Computer Interface）是 Agent 使用工具时面对的接口，包括：
- 工具名称与职责；
- 参数设计；
- 输入输出格式；
- 使用示例；
- 错误信息；
- 工具之间的边界。
ACI 对 Agent 的意义，类似 HCI 对人的意义。一个功能强大但难以理解的工具，并不会自动带来可靠性。
设计 ACI 时应重点检查：
- 模型是否能从名称和描述中理解工具用途？
- 相似工具的职责边界是否明确？
- 参数名和说明是否足够具体？
- 是否提供常见用法和边界情况？
- 输入格式是否接近模型熟悉的自然格式？
- 是否给模型留出了足够的思考空间？
- 格式本身是否引入了额外负担？
- 能否通过参数约束让错误更难发生？
- 失败输出是否能帮助模型采取下一步行动？
其中第 5 到第 8 条来自原文的具体建议，值得单独说明。
留出思考空间。原文的表述是 "give the model enough tokens to 'think' before it writes itself into a corner"。如果工具要求模型直接输出最终结果，它就没有机会在中途发现自己走错了方向。
避免格式开销。格式应当接近模型在互联网文本中自然见过的样子，同时不要制造额外负担。原文举了两个例子：要求模型精确维护数千行的行号计数，或者要求它对写出的代码做字符串转义。同样一段代码，写在 Markdown 代码块里是自然的，塞进 JSON 字符串则要处理引号和换行——后者把模型的注意力从任务本身转移到了格式正确性上。
Poka-yoke（防呆）。原文的建议是 "change the arguments so that it is harder to make mistakes"。Anthropic 在 SWE-bench Agent 中发现，Agent 离开根目录后相对路径容易被误用，于是工具直接要求绝对路径。这个案例说明，可靠性不一定来自更长的 Prompt，也可以来自让错误路径在接口上不可选。
八、从基本概念得到的工程原则
学习完以上概念后，可以把 Anthropic 的建议归纳成三个原则。
简洁性
先使用单次调用，再使用固定 Workflow，最后才考虑自主 Agent。复杂度必须由可验证的效果提升来证明。
透明性
系统的计划、关键制品和执行状态应当可见。开发者需要知道 Agent 为什么选择某一步，也需要能够定位错误发生在哪个阶段。第三节关于框架的讨论是这条原则的直接推论：任何遮蔽底层 prompt 和 response 的抽象，都在削弱透明性。
工具设计与测试
工具描述、参数、返回值和测试方式直接影响 Agent 的表现。不能只优化模型 Prompt，而忽略 Agent 实际行动所依赖的接口。
在建立这些概念之后，才适合进入具体项目，判断每一种模式放在什么位置。
从概念转入实践
以上八节是对原文的梳理。从这里开始转入第二部分：用 PPT Master 检验这些概念在真实系统中的位置，包括哪些模式被采用、哪些被有意回避，以及原文没有回答而工程必须回答的问题。
九、PPT Master 是 Workflow 与 Agent 的组合
PPT Master 是一个运行在编程 Agent 环境中的演示文稿系统。它先根据请求选择制品路线，再执行该路线自己的生命周期；下面的流程图描述的是功能最完整的 Default Generate，不能代表另外三条顶层路线，也不能代表 Generate 下的 Quick profile。
Default Generate 主流程可以简化为：
这个流程不是单一的自主 Agent，而是由确定性 Workflow、模型判断、人工确认和工具校验共同构成的 Agentic System。
Quick 是 Generate 的显式执行 profile，而不是第五条顶层路线。它会跳过 Strategist、Confirm UI、design_spec.md、spec_lock.md 和第一页门，直接准备必要资源、手工生成 SVG，并通过无锁的最终检查后导出。因此，不能把 Default Generate 的角色链和确认制品写成 PPT Master 的普遍前置条件。
十、Routing 决定制品生命周期
PPT Master 将请求划分为四种顶层路线：
| 路线 | 目标 |
|---|---|
| Generate PPTX | 从材料或主题生成新的演示文稿 |
| Create Template | 创建可复用的 Brand、Style、Layout 或 Deck 工作区 |
| Fill Native PPTX | 填充现有 PPTX 的原生页面结构 |
| Enhance Native PPTX | 保持页面视觉不变，增加旁白、音频或转场 |
当请求已经满足某条路线的条件时，系统直接进入对应 Workflow，不再让模型随意创造其他实现方式。
这个设计让我进一步理解了 Routing：
Routing 的工程含义
能用明确规则可靠判断的路由，就不需要消耗 LLM 的不确定性。
模型适合处理语义灰区，但不应替代已经可以稳定表达的业务规则。
十一、Strategist 承担 Default Generate 的动态编排
进入 Default Generate 后，演示文稿的内容和设计仍然是开放问题：
- 面向谁沟通？
- 需要听众理解、相信或决定什么？
- 材料应如何重组？
- 应采用什么叙事方式和页面节奏？
- 哪些页面需要图片、图表或公式？
这些问题无法提前写成固定答案，因此由 Strategist 动态处理。
Strategist 分两阶段提出并确认关键决策：
- Stage 1 同时确认沟通契约，以及自由设计或模板选择；只有确认使用模板后才读取、校验并安装所选工作区；
- Stage 2 在模板交接完成后确认完整 deck 方案，包括叙事主线、页面预算、视觉与图像方向和生产机制。
精确的 design_spec.md §IX ordered roster 在最终确认后才写入 Design Spec。只有启用 refine_spec 时，这份规格才会进入额外的用户细化审阅门。
如果用户启用了 refine_spec，Design Spec Gate 1 后还会出现一次条件式规格细化门；它不是固定的第三个 Strategist 确认阶段。用户也可以明确委托 Agent 完成相应决策，但委托本身仍来自用户授权。
这接近 Orchestrator-Workers：Strategist 根据具体材料动态拆解任务，并把资源取得和页面实现交给后续角色。
但角色划分首先是职责边界，不一定意味着运行时必须启动多个并行 Agent。
十二、Prompt Chaining 通过制品连接 Default Generate
Default Generate 的主要制品链是：
源材料 → 最终确认状态 → design_spec.md → spec_lock.md → SVG 页面 → PPTX其中：
| 制品 | 作用 |
|---|---|
design_spec.md | 承接最终确认状态，保存完整设计叙事、沟通目标、内容大纲和资源计划 |
spec_lock.md | 从 Design Spec 派生的 Executor 执行投影，保存其需要稳定执行的跨页约束和资源锚点 |
svg_output/ | 每页视觉设计的完整真值 |
exports/ | 最终导出的演示文稿 |
这是一种 Prompt Chaining，但每一步不是简单传递文本，而是生成有明确消费者和验证规则的中间制品。
这条链的权威顺序是“最终确认状态 → 经审计的 Design Spec → spec_lock.md”。spec_lock.md 是面向 Executor 的紧凑投影，不是独立权威来源，也不是穷举所有合法局部实现的白名单。
design_spec.md 与 spec_lock.md 有部分信息重叠，这种重复是有意的：
- 前者是人可以审阅的完整设计说明，也是模型思考的草稿纸；
- 后者是 Executor 使用的紧凑执行契约。
如果两个制品服务于不同消费者，必要重复是在降低耦合，而不是单纯违反 DRY。Quick 以及原生 PPTX 路线采用不同的制品链，不能机械套用这一组中间文件。
十三、Default Generate 的角色分权，而不是重复决策
PPT Master 的三个主要角色具有不同权限：
| 角色 | 负责什么 | 不负责什么 |
|---|---|---|
| Strategist | 内容选择、页面规划、资源计划、设计方向 | 逐页绘制 |
| Image Generator（条件触发） | 仅在资源计划需要时，按确认后的计划取得或派生图像资源 | 重新选择内容和页面用途 |
| Executor | 构图、层级、排版、形状和视觉实现 | 搜索资源、改变页面清单、重做上游决策 |
这里的核心区别是 selection 与 realization：
- Strategist 决定选择什么；
- Executor 决定如何实现。
如果 Executor 发现资源缺失，恢复动作取决于资源 provenance：用户提供的必需文件要等待原件恢复，模板资源要恢复已选工作区，AI、web、公式或切片资源则回到各自取得流程；只有页面计划本身不可执行时才修复 Design Spec 与相关 lock。共同原则不是“一律改上游计划”，而是回到拥有该事实或制品的来源，绝不静默替换目标。
这种边界减少了多角色系统中最常见的问题：每个角色都根据自己的理解重新做一次决定。
十四、为什么页面生成不使用 Parallelization
从技术上看，一份 20 页的演示文稿似乎很适合把每页分给不同 Agent 并行生成。
PPT Master 的核心页面生产刻意没有这样做。Executor 在同一个连续上下文中顺序生成页面，并保留此前页面的 SVG。
原因是跨页一致性不仅由颜色、字体和字号决定，还包括：
- 留白节奏；
- 页面密度变化；
- 装饰元素呼应；
- 图形语言；
- 难以枚举的视觉连续性。
spec_lock.md 可以保存离散参数，却不能完整描述这些关系。模型需要看到前面的页面，才能延续整体设计。
这个案例说明：
任务能够并行，不代表并行化符合最重要的质量目标。
Parallelization 应当用于真正独立的子任务。共享上下文本身就是质量来源时，顺序执行可能更正确。当前系统也并非完全排斥并行：主题事实研究在宿主允许时由一个隔离 worker 执行，可选的视觉审查也可以分批并行；保持串行的是共享视觉上下文的核心页面生成。
需要说明的是，这目前仍是一个设计判断，而不是已经量化的结论。要把它变成可复现的经验，需要一组对照实验：
| 变量 | 对照方式 |
|---|---|
| 生成策略 | 顺序生成（保留前序页面 SVG）对比并行生成（仅共享 spec_lock.md） |
| 输入 | 同一份 design_spec.md，同一套素材 |
| 判定 | 留白节奏、页面密度、装饰呼应等连续性指标由人工盲评；现有检查器负责 SVG/profile/package 合规，§IX 与实际 SVG roster 的通用交叉比较需要单独的最小 grader |
如果并行版本在盲评中无法被区分，说明 spec_lock.md 的表达能力已经足够，顺序执行的约束可以放松；如果差异明显，则说明连续视觉上下文确实承载了无法离散化的信息。这个实验尚未进行，结论有待验证。
十五、Evaluator 不一定是另一个 LLM
Default Generate 的页面生成包含多层反馈：
- 第一页完成后运行质量检查；
- 根据第一页面暴露的问题校准后续方法；
- 剩余页面连续生成；
- 全部完成后运行最终检查；
- Default Generate 自动启动实时预览；如需应用批注，则在导出后按用户请求进入相应阶段；
- 导出后读取 postflight 回执。
这里的 Evaluator 不完全由 LLM 承担。许多事实由确定性工具验证；同时必须区分硬工作流纪律与已自动化的检查：
- SVG 是否符合结构要求；
- 是否存在阻断导出的错误；
- 输出文件是否真实存在；
- 导出报告是否通过。
design_spec.md §IX 要求 Executor 按精确 roster 一一生成，这是硬工作流纪律；但当前普通 flat Generate 尚无把 §IX ordered roster 与实际 SVG 集合做通用交叉比较的代码门。不能把“规则要求一一对应”写成“现有检查器已经自动证明一一对应”。
这让我形成了一个明确判断：
验证原则
凡是机器能够直接验证的事实，就不要让 LLM 用自然语言宣布成功。
LLM 可以评价视觉表达是否合适，但文件是否生成、Schema 是否有效、导出是否完成，应当让环境回答。
十六、PPT Master 的 ACI
PPT Master 中的 ACI 不只是函数签名，还包括命令、目录、状态文件、错误等级和恢复指针。
例如：
project_manager.py validate <project_path>校验现有 Design Spec 与 Spec Lock 的结构、枚举和条件字段合同，但不证明最终确认到规格、规格到 lock 的语义忠实度；- 图像生成使用 manifest 描述资源计划；
- SVG 检查器输出结构化 JSON 报告；
- Confirm UI 保存分阶段确认结果；
- 导出命令返回包含状态、页数和警告分类的回执；
- 失败恢复规则指明应修复哪个上游制品。
这些接口的共同特点是：
- 输入明确；
- 输出可检查；
- 失败能够定位；
- Agent 能据此采取下一步行动。
Prompt 决定模型想做什么，ACI 决定模型是否真的能把事情做对。
十七、自主性的停止边界
PPT Master 的产品定位不是替用户包办全部演示文稿工作，而是完成大部分耗时的材料整理、设计与生产工作：
- 整理材料和表达逻辑；
- 形成设计方案；
- 生成完整页面；
- 导出可继续编辑的 PPTX；
- 提供预览和验证结果。
最后的选择、归档和细节精修仍然交给用户。
这也是 Agent 的停止条件。为了自动完成最后一次文件移动、自动选择“最好”的版本或替用户做最终审美判断，系统可能需要增加远高于收益的新权限和风险。
一个能够持续行动的 Agent 不一定有效。知道何时停止并交还控制权，才是可靠工具的一部分。
十八、从 PPT Master 重新理解五种模式
| Anthropic 模式 | PPT Master 中的应用 |
|---|---|
| Prompt Chaining | Default Generate 以最终确认状态、Design Spec、Spec Lock、SVG 和 PPTX 组成制品链 |
| Routing | 四种顶层路线决定不同制品生命周期 |
| Parallelization | 不作为核心页面生成策略；用于可隔离的主题研究和可选视觉审查 |
| Orchestrator-Workers | Default Generate 由 Strategist 动态规划，后续角色按职责实现 |
| Evaluator-Optimizer | Default Generate 使用第一页门、最终检查、实时预览和修复 |
真实系统通常不会只选择一种模式，而是把不同模式放在不同层次，并明确哪些位置不适合使用某种模式。
十九、我的最终理解：有效 Agent 是分层自治
从基本概念到 PPT Master 的应用，我对有效 Agent 的理解可以概括为三层：
第一层：Workflow 管理确定性
路线、顺序、前置条件、制品结构、阻断点和导出流程应当显式化。
第二层：模型处理开放判断
内容取舍、叙事结构、视觉设计、动态拆解和异常恢复需要模型能力。
第三层：环境验证真实结果
文件、测试、Schema、状态和导出报告应由工具提供 ground truth。
三层之间通过清晰的 ACI 和中间制品连接，并在价值判断、高风险操作和最终取舍处保留人工控制。
因此：
最终观点
有效 Agent 不是最大化自主性，而是把确定性留给 Workflow，把开放判断交给模型，把成败交给可验证环境。
二十、后续学习 Anthropic Engineering 的方法
这篇文章也让我形成了一个学习后续 Anthropic Engineering 文章的结构：
- 先定义基本概念，建立共同语言；
- 再理解机制，明确每种方法解决什么问题；
- 分析适用条件、代价和失败方式；
- 用 PPT Master 寻找真实对应，而不是生硬套用；
- 比较项目现状与文章方法，形成自己的判断；
- 最后设计可以验证观点的小实验。
按照这个顺序，学习结果才会从”知道一个概念”逐步变成”能够在项目中做架构决策”。
本系列的后续篇目
| 篇目 | 回答的问题 |
|---|---|
| Agent Skills：渐进式披露与分层加载 | 知识如何分层存放 |
| Effective context engineering：注意力预算与上下文纪律 | 运行时上下文如何管理 |
| Effective harnesses：跨会话交接与制品化 | 如何跨会话保持连续 |
| Writing effective tools：非确定性契约与脚本接口 | Agent 与环境的接口如何设计 |
| Demystifying evals：三类评估器与最小评估集 | 如何证明改动确实有效 |
本文第十三节留下的对照实验（顺序生成 vs 并行生成），在评估篇中被纳入了统一的验证方案。