05 · 怎样才算完整的 Agent System？ - Completeness & Maturity
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：系统完整性、成熟度评估与验证方法研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent System 的“完整”应如何定义？必要能力、任务适配性、工程成熟度与平台化程度如何区分？如何建立可操作的评估模型、证据标准和分阶段演进路径，避免把组件数量或多 Agent 架构误认为系统成熟？
专题导读
本篇属 Fundamentals。“存在一个 Agent System”“能够完成指定任务”“达到生产要求”和“具备平台化能力”是不同判断。一个本地单用户 Agent 可能在其目标范围内足够成熟，而具有众多服务和多个 Agent 的系统也可能缺少关键授权或恢复保障。
本篇将完整性追溯到任务契约，将成熟度追溯到风险与证据，并细化等级门槛、证据可信度和评估失败的判定方式。M0 - M3 是本知识库的工程评审模型，不是通行认证标准；任何成熟度结论都应附带任务范围、运行环境、证据版本和未覆盖风险。
一、首先区分四个经常混淆的判断
讨论“完整的 Agent System”时，至少要区分四种不同的命题。
| 命题 | 判断对象 | 核心问题 | 典型误判 |
|---|---|---|---|
| 定义成立（Validity） | 系统是否属于 Agent System | 是否存在可识别的 Agent 任务行为与承载其执行的系统机制？ | 把任何 LLM API 包装器都叫 Agent System |
| 任务完整性（Task Completeness） | 对指定任务是否足够完整 | 是否具备实现任务契约所需的全部功能与控制？ | 认为必须具备长期记忆、消息队列和多 Agent |
| 工程成熟度（Engineering Maturity） | 在目标环境中的运行质量 | 能否在故障、并发、成本和安全约束下持续满足要求？ | 演示一次成功就宣称生产可用 |
| 平台化程度（Platformization） | 可复用、可配置和多租户能力 | 能否支持多用户、多 Agent 的自助创建与统一管理？ | 把平台功能多少作为系统成熟度标准 |
四者不是一条从低到高的单向等级链。一个专用、单 Agent、单进程的系统，可能对其明确任务非常完整且工程成熟；一个拥有 Builder、Registry、几十个 Agent 和复杂微服务的产品，也可能在状态恢复或权限控制方面不成熟。
1.1 工作定义：什么是“完整”
本知识库采用相对于任务契约和运行环境的完整性定义：一个 Agent System 在指定使用场景中，如果能够提供完成目标任务所必需的 Agent 行为、执行支撑、状态与结果管理，以及与其风险相称的控制和验证机制，并能清楚说明不支持的边界，即可称为“对该场景功能完整”。
因此，“完整”不是固定的技术组件清单，而是一个带前提的判断：对什么任务、多少用户、什么风险等级、怎样的服务目标而言完整？ 如果缺少这些条件，声称系统“完整”几乎没有工程信息量。
1.2 工作定义：什么是“成熟”
成熟度指系统在目标运行环境中，以可重复、可审计的方式满足功能和非功能要求的程度。它关注的不只是能否执行，还包括失败时会发生什么、是否能被观察和恢复、变更是否受控、资源是否可预测，以及实际证据能否支持质量声明。
成熟度不能仅凭代码规模、框架品牌、Agent 数量、容器数量或演示效果判断。
二、完整性从任务契约推导，而非从组件目录反推
2.1 先定义任务契约
最小任务契约建议包含：任务输入和输出、成功与失败判据、允许的行动、数据和工具范围、执行时长、并发规模、预算、人工审批点、故障处理方式、结果保留期限和预期用户。并非所有任务都需要复杂的契约文档，但这些问题应有可追溯答案。
例如，同样是“研究助理生成技术报告”，以下两种场景要求明显不同：
- 个人离线研究工具： 单人使用，十分钟内完成，可重新运行，允许手动检查来源；本地进程、简单状态记录和明确错误提示可能已足够。
- 组织级研究服务： 多用户并发、任务持续数小时、需权限隔离、可暂停恢复、报告必须附证据、成本可核算；则需要更严格的持久化、执行身份、审批、追踪和故障恢复机制。
二者都可能是“完整的 Agent System”，但验收条件不同。
2.2 八项功能职责检查
以下八项是审查问题，不是要求每项必须对应独立微服务。
| 功能职责 | 必须回答的问题 | 最小实现示例 | 复杂场景扩展 |
|---|---|---|---|
| 任务契约 | 输入、输出、完成和失败如何定义？ | 输入校验、完成判据 | SLA、优先级、任务版本 |
| Agent 行为 | 哪个实体依据目标和状态选择行动？ | 单 Agent 决策循环 | 多 Agent 角色分工 |
| 执行控制 | 谁实际调用模型与工具并执行边界？ | Runtime、工具适配器 | Worker 池、沙箱、工具网关 |
| 状态与结果 | 如何知道执行到了哪里？ | 内存状态、结果文件 | 检查点、事务、持久化事件 |
| 资源接入 | 模型、工具和数据如何提供？ | API 客户端、凭据配置 | 模型网关、资源目录 |
| 异常与终止 | 超时、错误、取消和预算耗尽怎么办？ | 显式错误、步骤上限 | 重试策略、恢复编排 |
| 安全控制 | 谁能让系统做什么？ | 受限工具白名单 | 细粒度授权、审计、审批 |
| 结果验证 | 如何判断任务做对了？ | 断言、人工检查 | 自动评测、端到端回归 |
必要性判断规则： 某职责可以由外部系统承担，可以与其他职责合并，也可以在低风险场景中简化；但其缺失或外包必须被明确说明。比如，系统不一定需要持久化检查点，但必须说明进程崩溃后任务会丢失，且这是否满足使用要求。
2.3 三类能力的边界
- 成立所需的基础机制： 可识别的 Agent 行为、任务输入与执行路径、对结果或状态的处理、必要的行动边界。缺失时，系统可能只是固定模型调用或普通程序。
- 场景驱动的必要机制： 长任务的持久化、可写操作的审批、并发执行的隔离、涉及敏感数据时的访问控制。是否必要取决于任务契约。
- 可选的增强机制： 多 Agent 协作、长期记忆、分布式部署、复杂工作流编辑器、模型路由、自动伸缩。它们可以提高特定场景的能力，但不是“完整”的通用必要条件。
三、工程成熟度：采用多维评估，不采用单一组件等级
3.1 八个评估维度
| 维度 | 核心评价对象 | 可采集证据 | 常见失败模式 |
|---|---|---|---|
| D1 功能与任务质量 | 任务成功率、结果正确性、证据充分性 | 任务基准、人工复核、回归样本 | 工具调用成功但最终结果错误 |
| D2 执行与状态可靠性 | 中断、重试、幂等、恢复、一致性 | 故障注入、检查点、重复操作测试 | 恢复后重复发送或重复扣费 |
| D3 安全与授权 | 最小权限、隔离、审批、凭据保护 | 权限矩阵、拒绝测试、审计记录 | 模型输出绕过执行层权限 |
| D4 可观测与可诊断 | Trace、日志、指标、因果关联 | Task/Run/Step ID、告警演练 | 只能看到最终失败，无法定位原因 |
| D5 性能与资源效率 | 延迟、吞吐、并发、成本、预算 | 负载测试、调用账本、配额测试 | 并发增加后成本或等待时间失控 |
| D6 变更与可维护性 | 版本、配置、测试、回滚、兼容性 | CI 记录、发布记录、回滚演练 | Prompt 更新导致静默回归 |
| D7 数据与生命周期治理 | 数据边界、保留、删除、溯源 | 数据流图、保留策略、删除验证 | 任务结束后敏感数据长期滞留 |
| D8 人工监督与操作性 | 人工介入、取消、审批、异常处置 | 审批记录、操作手册、值班演练 | 系统已失控但无法停止 |
这八个维度是本知识库的研究性整合，不应称为官方统一成熟度标准。它们与后续 H1 - H12 专题形成映射，但不要求每个维度权重相同。
3.2 建议的四级成熟度描述
| 等级 | 名称 | 可观察特征 | 证据要求 |
|---|---|---|---|
| M0 | 概念验证（Prototype） | 核心路径可演示；手工运行；失败依赖人工处理 | 可重复的最小示例及已知限制 |
| M1 | 受控试运行（Controlled Pilot） | 任务契约清晰；基本权限、日志、错误处理和回归测试 | 代表性样本、测试记录、失败案例 |
| M2 | 目标场景生产可用（Production-ready for Scope） | 对目标风险和负载具备监控、恢复、发布控制及操作流程 | 故障演练、权限测试、负载数据、运维记录 |
| M3 | 可持续运营与改进（Operationally Mature） | 具备趋势监测、质量门禁、成本治理、持续评测和制度化复盘 | 多周期运行指标、事件复盘、持续改进证据 |
重要限制： 等级仅对某一任务范围、负载规模、风险等级和运行环境有效。M2 不代表系统能安全扩展到所有场景；M3 不代表零故障。不得用“拥有某项组件”直接推断成熟度等级。
3.3 避免平均分掩盖关键风险
如果需要量化，可按每维 0 - 3 分记录成熟证据，但不建议直接求平均分并作为上线结论。对涉及支付、删除、生产写入、个人数据或高风险外部操作的系统，权限、恢复、审计等维度可能属于一票否决门槛。
一个示例规则是：系统在 D1、D4、D5 得分很高，但 D3 授权测试未通过，则不能因平均分较高而进入允许高风险写操作的生产环境。评分只是沟通工具，最终判断应采用风险门槛 + 任务验收 + 运行证据。
四、怎样进行可复现的完整性与成熟度评估？
4.1 六步评估流程
步骤一：锁定评估范围。 明确系统版本、模型版本或模型别名、工具集合、部署环境、任务类型、并发范围、数据敏感性、用户角色和时间窗口。否则不同测试结果无法比较。
步骤二：建立任务契约与风险清单。 对每种任务定义输入、预期结果、失败判据、最大预算、允许的副作用与审批点。对外部写操作额外定义幂等键、撤销或补偿策略。
步骤三：绘制系统职责图。 标出任务入口、Agent Runtime、模型服务、工具执行器、状态存储、编排器、人工审批和观测链路，明确职责由本系统还是外部服务承担。
步骤四：形成可验证的验收矩阵。 将每个要求映射到测试用例、观察指标和证据位置。测试应覆盖成功路径、异常路径和边界条件。
步骤五：执行分层测试。 先做单元与契约测试，再做真实工具集成测试、端到端任务测试、故障注入、安全测试和负载测试。真实模型的不确定性应通过重复试验、任务样本分层和结果复核处理。
步骤六：形成结论和限制。 逐项写出“满足 / 部分满足 / 未满足 / 未验证”，附证据链接和适用条件。不得将“未验证”视为“满足”。
4.2 研究助理系统的验收矩阵示例
| 要求 ID | 验收目标 | 测试方法 | 合格判据示例 | 证据 |
|---|---|---|---|---|
| R-01 | 能生成有来源的技术报告 | 固定研究题集 + 人工复核 | 核心结论可追溯；不存在捏造引用 | 报告、来源清单、复核记录 |
| R-02 | 工具越权请求被拒绝 | 注入未授权工具调用 | 执行层拒绝；不产生外部副作用 | 拒绝日志、目标系统核验 |
| R-03 | 超预算任务终止 | 设定低预算阈值 | 停止后续调用；保留终止原因 | 调用账本、Run 事件 |
| R-04 | 进程崩溃后恢复 | 在检查点后终止 Worker | 按契约恢复；不重复已确认副作用 | 检查点、恢复 Trace |
| R-05 | 任务可取消 | 运行中发出取消请求 | 在规定时间内停止可中止的后续操作 | 状态迁移、取消日志 |
| R-06 | 多任务数据隔离 | 使用不同用户任务交叉访问 | 无未授权跨任务读取 | 权限测试记录 |
| R-07 | 可定位失败步骤 | 人为注入工具超时 | 通过 Task/Run/Step ID 定位故障 | Trace、指标、告警 |
| R-08 | 满足目标负载 | 按预计并发执行基准任务 | 延迟、失败率和成本低于预设阈值 | 压测报告 |
表中的合格判据是设计示例，不是已完成实验，也不是适用于所有研究系统的行业标准。具体数值阈值必须由真实服务目标和风险预算确定。
4.3 证据强度分级
为避免把宣传文案、源码存在和实际可靠性混为一谈，可使用以下证据标签：
- E0：设计声明。 架构图、需求说明或产品描述；只能证明设计意图。
- E1：静态证据。 代码、配置、接口定义；说明存在实现路径，但不能证明运行正确。
- E2：受控运行。 单元、集成或本地实验；证明指定条件下的行为。
- E3：故障与负载验证。 注入失败、并发、重试、恢复、安全负向测试；证明边界条件下的表现。
- E4：持续运营证据。 生产指标、事故记录、变更回滚、周期性回归；证明一段时间内的运行质量。
这些标签是本文提出的分析工具。证据强度与成熟度相关但不等价：例如某一模块具有 E4 证据，并不意味着整个系统已经达到 M3。
五、关键工程难点：为什么“能运行”不等于“能恢复”
5.1 状态机与恢复
一个异步任务可能具有 created → queued → running → waiting_approval → running → succeeded/failed/cancelled 等状态。系统必须定义合法状态迁移，以及重启后如何重建任务状态。仅记录 status=running 无法回答当前工具是否已经执行、结果是否已经写入、后续步骤是否可以重试。
5.2 外部副作用与幂等
Agent 可能调用邮件发送、数据库写入、支付、文件删除等工具。若工具成功但系统在记录成功前崩溃，恢复时重复调用可能产生重复副作用。成熟系统需要依据操作性质使用幂等键、去重、事务性 Outbox、结果核对、补偿操作或人工确认等手段。不能笼统保证跨外部服务的“恰好一次执行”；必须明确交付语义及可验证边界。
5.3 模型不确定性与质量回归
同一模型或同一 Prompt 在不同条件下可能产生不同路径。因而测试不能只断言逐字相同的输出，而应根据任务契约验证结构、事实依据、允许的行动、最终状态和结果质量。模型更新、工具变更和上下文策略变化，都可能导致回归。
5.4 权限必须在执行边界强制实施
Prompt 中写明“不要删除文件”不是可靠的权限边界。系统需要在工具执行层进行身份、资源、动作与上下文的授权检查，并对高风险操作设置审批或独立执行限制。模型的意图和系统的许可是两回事。
5.5 可观测性需要跨组件关联
只有模型请求日志，通常不足以诊断任务失败。应能够关联 Task、Run、Step、Agent、模型调用、工具调用、审批事件、状态变更与成本记录。对敏感输入和工具结果，还需要考虑脱敏、最小化采集和访问权限。
六、典型架构的完整性与成熟度比较
| 方案 | 可能具备的完整性 | 主要成熟度风险 | 何时适合 |
|---|---|---|---|
| 单进程单 Agent | 对短任务可能完全足够 | 进程崩溃导致状态丢失、难以并发 | 个人工具、低风险短任务 |
| 单 Agent + 持久化任务服务 | 可支持长任务与恢复 | 检查点和外部副作用不一致 | 长时间研究、异步任务 |
| 预定义工作流 + Agent 节点 | 适合流程稳定且需审计的任务 | 动态分支复杂、流程版本迁移 | 审批、文档处理、标准化业务 |
| 多 Agent + 中心编排 | 适合可拆分的专业协作任务 | 协作开销、状态同步、错误传播 | 多阶段研究、代码审查 |
| 分布式 Worker 系统 | 可扩展并发和资源隔离 | 重复消费、网络分区、故障恢复 | 高并发、多租户、大规模执行 |
关键结论： 架构复杂度和成熟度不是正相关关系。引入分布式组件会增加新的失败模式；只有当规模、隔离或可靠性要求足以抵消复杂性成本时，才应采用。
七、贯穿案例：研究助理 Agent System 的分阶段演进
假设要将“研究某项 AI 技术并生成带来源报告”的 Agent 从本地演示推进到多人使用的研究系统，可以采用以下演进路径。
阶段 A：最小闭环。 定义任务输入、可用搜索工具、报告输出与结束条件；实现受限 Agent Runtime；记录行动和错误；用小型题集验证结果。此时重点是任务契约和行为正确性，而不是多 Agent。
阶段 B：受控试运行。 增加用户身份、工具权限、结构化 Trace、预算限制、任务取消、失败分类和回归测试；对高风险操作设置人工审批。此时重点是可控性和诊断能力。
阶段 C：长任务与多用户。 引入持久化任务状态、检查点、后台 Worker、任务队列、租户数据隔离和故障恢复；验证重试是否产生重复副作用。此时重点是可靠性与隔离。
阶段 D：规模化协作。 仅当任务分工收益明确时，引入多个 Agent、任务图、消息传递和结果审核；在实际基准中比较单 Agent 与多 Agent 的质量、成本和延迟。此时重点是协作收益的证据，而非 Agent 数量。
阶段 E：持续运营。 建立发布门禁、版本管理、模型变更回归、资源预算、运营指标、事故复盘和策略审计。此时重点是长期质量控制。
上述阶段是建议的工程演进路径，并非所有系统必须依次经过。某些高风险项目从第一版起就必须满足严格的授权、审计和恢复要求。
八、与相邻专题的分工
| 关联专题 | 本篇只回答 | 后续专题深入回答 |
|---|---|---|
| 01 · Definition & Boundaries | 完整性判断以什么对象为前提 | Agent System 的成立条件与概念边界 |
| 02 · Core Components | 哪些职责需被覆盖 | 各组件的接口与实现机制 |
| 03 · Execution Mechanism | 执行证据如何纳入验收 | 任务状态机、执行事件与时序 |
| 04 · System Types | 不同架构为何不能按复杂度排序 | 多维系统分类与选型 |
| 06 · Architecture & Design Principles | 如何以成熟度要求约束设计 | 模块边界、架构原则与取舍 |
| L4 / L5 | Runtime 和编排需要验证什么 | 执行引擎、调度、协作的内部实现 |
| H1 / H3 / H10 | 观测、评价、测试分别提供何种证据 | 具体指标、评测设计与验证工具 |
| H2 / H4 / H7 | 安全、状态和可靠性是关键门槛 | 授权、检查点、幂等、恢复的工程机制 |
| H8 / H11 / H12 | 成本、运维、治理影响生产可用性 | 配额、部署、策略与持续运营 |
本篇不把各项工程机制的详细实现提前写成完整教程，而是建立后续专题共同使用的评估语言、证据规则与验收逻辑。
九、实践模板：Agent System 完整性评审卡
以下模板可直接复制到具体项目中。它是一份人工评审工件，不是自动评分程序。
system: research-agent-system
version: "0.1.0"
scope:
task: "生成具有可追溯来源的技术研究报告"
users: "内部研究团队"
deployment: "单区域、后台异步任务"
risk: "只读检索；发布报告需人工确认"
target_concurrency: "待实测确定"
contract:
success: "报告满足结构要求且关键结论有来源支持"
failure: "缺少关键证据、超时、越权或预算耗尽"
allowed_actions: ["search", "read", "draft"]
approval_required: ["publish"]
max_budget: "由项目配置，不在示例中假定数值"
requirements:
task_contract: required
runtime: required
state_persistence: required
cancellation: required
access_control: required
trace_correlation: required
recovery: required
multi_agent: optional
distributed_workers: conditional
verification:
functional: unverified
permission_denial: unverified
interruption_recovery: unverified
duplicate_side_effect: unverified
load: unverified
release_decision: "not_approved_until_required_evidence_passes"评审时应为每个 required 项增加负责人、实现位置、测试用例、证据路径和结论。unverified 必须保留为未验证，不得因为实现代码存在就自动改为通过。
9.1 一个可执行的门槛判断示例
可以使用以下规则辅助发布评审：
输入：任务范围 S、必需要求 R、测试证据 E、阻断风险 B
对每一项 r ∈ R：
若缺少实现或缺少达到约定强度的验证证据：标记 NOT_READY
若存在未解除的阻断风险 b ∈ B：标记 NOT_READY
否则：
若所有验收条件在范围 S 内满足：标记 READY_FOR_SCOPE
否则：标记 NOT_READY
输出必须包含：适用范围、版本、证据、限制与未解决风险该规则刻意避免将多个维度简单求和，因为真实上线判断通常具有不可折抵的风险门槛。它也不等同于自动证明系统安全；最终仍需要结合业务风险和工程审查。
十、常见误区与反例
误区一：有多个 Agent 才是完整系统。 反例：一个单 Agent 的编程工具，具备受限沙箱、明确权限、状态恢复和测试机制，可能比多个 Agent 互相聊天的演示更完整。
误区二：有数据库就有状态恢复。 数据持久化只解决部分问题；恢复还涉及执行位置、外部副作用、并发状态和重复执行。
误区三：使用成熟框架就自动具备生产可靠性。 框架提供能力，不替应用定义任务契约、权限策略、服务目标和实际验证。
误区四：一次任务成功证明系统可用。 单次成功无法证明稳定性、故障恢复、安全性和成本可控。
误区五：系统组件越多成熟度越高。 每个新增组件都带来配置、网络、权限、状态和运维负担；复杂性应服务于可测量需求。
误区六：模型遵守 Prompt 就意味着操作安全。 安全边界必须由可信执行层强制实施，尤其是外部写操作。
误区七：平台化是系统的最高成熟阶段。 平台化是产品复用和运营方向，不是每个 Agent System 的必要目标。
补充研究：成熟度门禁、证据等级与场景化判定
从等级描述到可审查的判定规则
成熟度应采用“目标环境＋关键门禁＋维度证据”的结构。建议将 M0 视为可演示原型、M1 视为限定场景可用、M2 视为可重复运维、M3 视为在目标风险条件下具备持续治理能力；这是本知识库的工作模型，等级不应被当作跨行业认证。等级的具体门槛由任务风险和运行环境决定，不以功能数量打分。
| 级别 | 参考验收焦点 | 不可跳过的检查 |
|---|---|---|
| M0 | 基本路径可演示 | 任务与终止可辨认 |
| M1 | 限定场景可交付 | 验收条件与权限边界 |
| M2 | 可重复运行和维护 | 故障、版本、回归证据 |
| M3 | 持续风险治理 | 漂移监测、审计、演练 |
这些是指导性焦点而非通用硬阈值。若系统能产出高质量报告，却可以未经授权向外部发布，不能通过要求授权的目标环境的验收；不允许用平均得分抵消高风险门禁失败。反之，本地离线个人 Agent 没有多租户管理，不应因此被扣除与其场景无关的成熟度分数。
证据可信度与结论强度
E0 设计声明只能说明意图；E1 静态审阅能检查配置和代码表面逻辑；E2 确定性单元测试能验证局部不变量；E3 集成与故障注入能检验组件协作；E4 真实场景抽样与运行监测才能支持目标环境下的表现判断。证据等级是本篇的评审工具，不是公认标准；E4 也不能证明未来所有输入永远安全。
可复用的评审记录
每项评审至少记录 requirement_id、目标环境、风险等级、验收条件、证据位置、执行日期、实际版本、结论、未覆盖情况和整改责任。若证据无法复现或缺少环境版本，应标为“证据不足”，不能默认通过。
防止重复计分
“工具调用失败被记录”主要属于可观测性；“工具失败后任务能够安全停止或恢复”属于可靠性；“工具调用在执行前被授权”属于安全。一次测试可以提供多个维度的证据，但评审时应说明每项独立断言，避免仅凭一条成功轨迹重复给分。
研究结论
- Agent System 的完整性是相对任务契约的充分性判断，不是固定组件数量。 应先定义任务、运行环境、风险和验收条件，再决定需要哪些能力。
- 成熟度是多维、基于证据的工程判断。 功能质量、可靠性、安全、可观测性、性能、变更、数据治理与人工控制不能互相简单替代。
- 系统成立、任务完整、工程成熟与平台化是四个不同命题。 不应把多 Agent、分布式或平台功能视为成熟度等级。
- 从“能运行”到“可生产运行”的关键跨越在失败路径。 检查点、重复副作用、权限拒绝、取消、恢复和故障定位，通常比成功路径演示更能暴露系统缺陷。
- 发布结论必须限定范围并附证据。 对于尚未验证的能力，应明确标记，而不是推断其可靠。
附录 A：参考文献与原始资料
十二、参考资料与核验说明
以下来源为进一步核查技术机制的官方入口。本篇没有进行实时联网或指定版本源码核验，因此它们不应被理解为“本文已验证这些框架具备全部上述能力”。文中的八维评估、M0 - M3 和 E0 - E4 是本知识库提出的研究框架，不是下列项目的官方标准。
- LangGraph 官方文档：持久化、检查点、Human-in-the-Loop 与工作流执行机制。docs.langchain.com/oss/python/langgraph/overview
- Temporal 官方文档：持久化执行、Workflow、Activity、重试与故障恢复。docs.temporal.io
- OpenTelemetry 官方文档：Trace、Metric、Log 与分布式可观测性。opentelemetry.io/docs
- NIST AI Risk Management Framework：AI 系统风险管理的治理与评估视角。www.nist.gov/itl/ai-risk-management-framework
- OWASP Top 10 for LLM Applications：LLM 应用风险与安全防护参考。genai.owasp.org/llm-top-10
- Google SRE Book：服务可靠性、服务目标、监控与运维工程。sre.google/sre-book/table-of-contents
- OpenAI Agents SDK 官方文档：Agent 执行、工具、追踪与相关工程接口。openai.github.io/openai-agents-python
核验状态： 本篇是概念、架构和评估方法研究，未包含声称已运行的外部框架实验、性能基准或生产运行数据。所有评审卡、门槛规则和验收矩阵均为设计示例；实际应用须结合明确版本和真实环境进行测试。
下一篇： 06 · 如何理解 Agent System 的架构？ - Architecture & Design Principles。
附录 B：研究证据与验证声明
- **研究基准日期：**2026 年 10 月 28 日。
- **本次修订检索状态：**未新增实时网页检索；保留原文来源及其原有核验声明，不将旧资料冒充重新核验的最新版本。
- **本次修订验证状态：**原文成熟度框架与评审卡属于知识库提出的方法。本次修订未执行真实生产评估；新增 E0 - E4 证据等级为建议性评审工具。
- **结论适用范围：**定义、组件划分、架构选型及成熟度分级均需结合任务目标、风险等级、实际框架版本与目标环境进行核验。
- **实验声明：**本次修订不宣称新增实验已经通过；历史文档中的运行或测试表述仅代表原文所述范围，需由独立可重现的执行记录支持。