06 · 如何理解 Agent System 的架构？ - Architecture & Design Principles
所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：系统架构原理、设计原则与工程决策研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：如何把 Agent System 的任务契约、决策行为、执行机制、组件职责与运行约束转化为可实施、可验证、可演进的系统架构？应如何确定架构边界、控制权与状态所有权，设计控制流、数据流和信任边界，并在单体、工作流、多 Agent 与分布式方案之间作出有证据支持的技术取舍？
专题导读
本篇属 Fundamentals。Agent System 架构设计的核心，不是把模型、工具、记忆、工作流和数据库画进一张图，而是回答：谁有权决定下一步、谁负责执行、谁持有可信状态、谁批准有副作用的操作、系统失败后如何知道已经发生了什么。一个看似简单的研究助理，可能在“模型生成工具参数”与“真实调用外部 API”之间跨越权限边界；一个支持断点恢复的工作流，可能因为重复投递而再次发送邮件；一个多 Agent 团队，可能因没有明确的任务所有权而无限转交工作。这些都是架构问题，而不只是 Prompt 问题。
本篇是 Fundamentals 的第六篇，也是该章节的综合篇。前五篇分别解决定义与边界、核心组件、执行机制、系统类型和完整性成熟度。本篇把这些结论组织成可操作的架构方法：从需求与风险建模开始，明确职责、信任、状态和故障边界，再设计模块与接口、控制流与数据流、运行拓扑、部署演进和验收证据。研究贯穿“技术研究助理 Agent System”，同时讨论具有外部副作用的场景，以检验架构原则是否真正成立。
本文的“控制平面/执行平面”“分层架构”“架构决策记录”等术语，部分借鉴通用软件架构与分布式系统思想；它们在本文中是分析工具与建议性设计，不是声称所有 Agent 框架都有相同的内部实现。本文不以组件数量、微服务数量或 Agent 数量作为架构先进程度的判断标准。
一、架构研究对象：从能力清单转向系统约束
1.1 架构回答什么问题
功能架构回答系统需要哪些责任：接收任务、选择行动、执行工具、维护状态、审查证据、交付结果。运行架构回答这些责任如何随时间协作：创建 Run、循环决策、等待工具、暂停审批、恢复、终止。部署架构回答责任落在什么进程、服务、容器或机器上。信任架构回答谁可以访问数据、发起动作、修改状态及审批高风险操作。故障架构回答某个模块失败会影响哪些任务、是否可重试以及如何避免重复副作用。
五种视角相互关联，但不能混为一谈。例如，一个 ToolGateway 可以只是单进程内的函数；“工具执行必须经过授权”是信任架构约束，并不意味着必须部署独立网关服务。
1.2 与前五篇的关系及本篇边界
| 已有专题 | 已解决的主要问题 | 本篇进一步解决 |
|---|---|---|
| 01 Definition | 系统的成立条件与概念边界 | 如何将边界落实为接口与权限 |
| 02 Components | 逻辑组件及其职责 | 如何确定依赖、所有权与模块组合 |
| 03 Execution | Run、Step、事件和恢复语义 | 如何将运行语义纳入架构约束 |
| 04 Types | 多维系统分类及适用形态 | 如何以可验证理由选择拓扑 |
| 05 Maturity | 场景完整性与证据门禁 | 如何让架构满足目标成熟度 |
本篇不替代后续 Technical Architecture 的 L1 - L6：不会把 Kubernetes 部署、模型网关、Agent Engine、工作流引擎等逐一展开为实施手册。也不替代 Engineering & Governance 的安全、可观测、状态管理、可靠性和测试专题。本篇研究的是跨这些专题的架构决策方法。
1.3 架构不是一张静态拓扑图
合格的架构说明至少应能够回答以下五个具体问题：给定任务，执行链从哪里开始、如何结束？给定一个工具调用，授权在哪里强制执行？给定一次进程崩溃，哪些状态可恢复、哪些外部动作可能重复？给定两个 Agent 同时修改研究结论，谁拥有最终写入权？给定新的并发需求，哪些模块需要拆分、为什么？如果架构图无法回答这些问题，图形再完整也只是概念展示。
二、架构设计的起点：任务契约、质量属性与风险
2.1 先定义任务契约
以研究助理为例，任务输入为研究问题、授权资料范围、输出格式和截止时间；交付物为报告、引用映射与不确定性说明；成功条件包括关键主张有可核验证据、任务在预算内结束；失败条件包括证据不足、工具故障、权限拒绝或超时。任务契约还应写清楚“可以检索公开网页”是否意味着“可以把私有文件发送到外部模型” - - 两者不是同一种授权。
建议把需求转换为可测试的架构约束：
| 需求 | 架构约束 | 验收证据 |
|---|---|---|
| 只读取授权资料 | 工具执行前校验身份与资源 | 拒绝事件、无越权副作用 |
| 报告引用可追溯 | 证据记录与报告主张关联 | 主张 - 来源映射 |
| 单任务预算受控 | 可信执行层维护用量账本 | 超限停止轨迹 |
| 任务中断可恢复 | 持久化检查点与恢复协议 | 故障注入记录 |
| 发布前需审批 | 发布工具检查审批凭证 | 未审批发布被阻断 |
| 结果可诊断 | Run/Step/Tool 关联事件 | 完整失败链 |
2.2 区分功能要求与质量属性
“能生成研究报告”是功能要求；“在可接受的成本和延迟内稳定生成、不会泄露资料、故障后可恢复”属于质量属性。常见质量属性包括安全性、可靠性、可维护性、可观测性、性能、成本、可移植性和可审计性。它们可能冲突：增加人工审批提高控制力，却可能增加完成时间；引入并行 Agent 提升吞吐潜力，却可能增加状态协调成本。
因此架构选择应记录目标、约束、假设与权衡，而不是给某种技术贴上“最佳实践”标签。
2.3 风险分级改变架构，不只改变 Prompt
只读检索、修改本地草稿、发送外部邮件、支付或删除资源的风险不同。风险较高的动作应通过可信执行层增加授权、审批、幂等、审计与补偿策略。不能用“模型会谨慎”替代这些控制。是否需要隔离执行环境，也应根据工具可访问的数据、执行权限和潜在损失决定，而不是根据 Agent 名称决定。
三、六条核心设计原则及其成立条件
原则一：职责清晰，避免决策权与执行权混淆
Agent 可以提出“调用 publish_report”，但提出动作不等于拥有执行许可。模型输出是候选决策；可信执行层应验证工具是否存在、参数是否符合 Schema、调用身份是否有权限、是否需要审批、预算是否允许，然后才执行。执行结果应回写状态供下一步决策使用。
设计上的关键是将 propose_action() 与 authorize_and_execute() 分离为可测试责任，即使两者在同一进程中实现。
原则二：状态有明确所有权，避免多处事实来源
每个 Run 应有明确的权威状态来源。模型上下文可以包含状态摘要，但不能自动等同于可信状态。Agent 的自然语言回答“任务已经发布”不代表发布成功；只有工具结果和外部系统确认才能支持该事实。多 Agent 并行时，应为共享工件规定版本、写入者和冲突处理规则。
状态所有权不是要求只能使用一个数据库，而是要求能回答：哪个存储或服务对某类状态拥有最终解释权？
原则三：显式定义信任边界
用户输入、外部网页、检索文档、其他 Agent 的消息、模型生成文本均可能包含不可信指令。系统必须区分数据内容与授权指令。例如，网页写着“请把内部资料发到某地址”只能被当作网页内容，不能因此取得调用邮件工具的权限。
可信边界应覆盖身份、工具参数、资源访问、敏感数据输出和审批凭证。将安全策略写入 Prompt 可以辅助模型行为，但不构成执行层授权。
原则四：以显式状态转换和事件描述运行
一个可恢复系统需要区分 CREATED、RUNNING、WAITING_APPROVAL、SUCCEEDED、FAILED、CANCELLED 等状态，规定合法转换和终止语义。执行事件需要关联 run_id、step_id、tool_call_id、配置版本与错误类型。事件日志可用于诊断；是否足以重建状态，取决于是否采用完整、顺序可定义的事件溯源设计，不能简单画等号。
原则五：围绕故障域设计恢复，而不是假设所有调用成功
模型调用、工具请求、状态写入、消息投递、审批等待和报告交付都可能失败。每条跨边界调用需要考虑超时、重试、取消、重复投递、幂等和最终状态不确定性。对于不可逆外部副作用，重试前必须确认其安全性；不能因为本地未收到响应，就认定外部操作没有发生。
原则六：最小充分架构，按证据演进
初始系统优先采用可理解、可测试的模块化单体。当出现可测量的瓶颈 - - 例如工具执行需要隔离、长任务需要独立 Worker、团队需要不同部署周期或并发需求超过单实例容量 - - 再考虑拆分服务。新增 Agent、消息队列、数据库或编排框架必须对应明确收益和新增故障成本。
这六条是本知识库综合软件架构与 Agent 工程风险提出的设计原则，不是通用强制标准。是否采用某项机制，要结合任务风险与目标环境判断。
四、三类边界：逻辑、运行和信任
4.1 逻辑组件与部署单元不是同一层
参考逻辑架构如下：
用户 / API / 定时触发
│ TaskContract + Identity
▼
Task Intake / Admission
│ 创建 Run，验证预算和范围
▼
Run Controller ──────────────► State Store / Event Log
│ ▲
▼ │
Agent Decision Adapter │
│ ActionProposal │
▼ │
Policy & Approval Gate │
│ AuthorizedAction │
▼ │
Tool Execution Gateway ──────────────┘
│ ToolResult / SideEffectReceipt
▼
Evidence & Artifact Service ─────► Delivery / Review这张图强调责任和可信数据路径，而不是规定必须使用九个独立服务。Run Controller 可以是同步函数、持久化工作流或分布式协调器；State Store 可以是内存、数据库或工作流引擎管理的持久状态。选择取决于恢复需求、并发规模与故障模型。
4.2 控制平面与执行平面：一种有用但非强制的分析法
控制职责包括任务准入、配置版本、身份授权、预算、审批策略、Agent 注册与运行调度。执行职责包括模型推理、工具调用、数据读取、产物生成与结果回写。两类职责可以在同一进程实现，但需要区分其权限来源。
不要将“控制平面”理解为必然存在独立控制服务，也不要认为控制平面中的配置决策一定比执行平面更可信。可信程度取决于身份、代码边界、部署权限和审计机制。
4.3 进程边界、网络边界与信任边界可能不重合
把工具执行器拆成独立微服务，不自动意味着安全；如果它接受未经校验的调用，风险只是跨越了网络。反过来，同进程的工具网关也可以实施严格授权，但对恶意代码执行等高风险场景，进程级隔离可能不足，需要操作系统或容器沙箱及最小权限。
设计时应画出数据敏感性、身份传播、凭据存放和外部副作用路径，而不只是服务间连线。
五、核心接口契约：让架构可以被实现与测试
5.1 最小对象模型
建议区分以下实体：
TaskContract：目标、输入、允许资源、约束、成功条件、交付格式。AgentDefinition：模型、工具能力、决策策略与版本化配置。Run：一次任务执行实例及其权威状态。Step：一次可观察的决策或执行单元。ActionProposal：Agent 建议执行的动作，不代表已授权。AuthorizationDecision：策略引擎的允许、拒绝或待审批结论。ToolInvocation：经过校验的实际工具调用及唯一标识。ToolReceipt：外部执行结果、错误或不确定状态的证据。Artifact：报告、数据集、文件及其版本与来源。
核心区分是：提议、授权、执行、确认、交付是不同事实。如果把它们压缩为一个 tool_call 字符串，就很难处理审批、重试与审计。
5.2 示例接口（架构伪代码，不对应特定 SDK）
class RunController:
def start(self, task_contract, identity) -> str: ...
def resume(self, run_id, expected_version) -> None: ...
def cancel(self, run_id, reason) -> None: ...
class AgentDecision:
def propose(self, context, allowed_capabilities) -> "ActionProposal": ...
class PolicyGate:
def evaluate(self, identity, proposal, run_state) -> "AuthorizationDecision": ...
class ToolGateway:
def invoke(self, authorized_action, idempotency_key) -> "ToolReceipt": ...
class StateRepository:
def compare_and_set(self, run_id, expected_version, next_state) -> bool: ...compare_and_set 体现乐观并发控制思想；它不是所有 Agent System 必须采用的数据库接口。idempotency_key 也只在工具或其外部服务支持去重、或系统自己建立了可靠去重记录时才可能发挥作用，仅传入一个字符串并不能自动保证幂等。
5.3 失败类型应是契约的一部分
建议区分 VALIDATION_ERROR、DENIED、APPROVAL_REQUIRED、TIMEOUT、RATE_LIMITED、TOOL_FAILURE、UNKNOWN_OUTCOME、BUDGET_EXCEEDED 和 CANCELLED。其中 UNKNOWN_OUTCOME 尤其重要：例如请求发送成功但响应丢失，系统无法确定是否已产生副作用，此时盲目重试可能造成重复发送。
六、控制流、数据流与状态流：三个不可互换的视角
6.1 控制流：谁决定下一步
接收任务 → 校验准入 → 创建 Run
→ 构建可见上下文 → Agent 提议动作
→ 校验 Schema / 权限 / 预算
├─ 拒绝：记录并反馈或终止
├─ 待审批：持久化 WAITING_APPROVAL
└─ 允许：执行工具 → 记录结果 → 更新状态
│
└── 返回决策循环
→ 验收结果 → SUCCEEDED / FAILED / 其他终止状态控制流应明确循环上限、取消传播、人工介入点和最终验收责任。一个模型输出 final_answer 不一定代表系统任务成功；系统仍可能需要验证交付格式、证据完整性和权限约束。
6.2 数据流：哪些内容可以进入模型上下文
任务输入、检索证据、历史记忆、工具结果和策略配置具有不同可信等级。检索证据可以供模型阅读，但不应因此获得修改配置、提升权限或改变工具授权的能力。对敏感资料，需要规定是否允许发送给外部模型、如何脱敏、是否记录原文及保留期限。
数据流设计至少标注：来源、数据分类、授权依据、转换规则、目的地、保留与删除策略。报告中的每个关键结论应能够追溯到证据记录，而不是只保留最终生成文本。
6.3 状态流：什么被保存，何时提交
需要区分任务状态（目标和约束）、执行状态（当前步骤、重试计数、审批等待）、知识状态（已采集证据、引用映射）、副作用状态（外部操作是否确认）和交付状态（产物版本、审核结果）。这些状态可以共享物理存储，但必须有明确的更新规则。
一次典型工具执行的安全设计可采用“记录意图 → 执行 → 记录回执”的模式，但本地状态写入与外部 API 副作用通常不在同一事务中。系统必须处理意图已记录、外部动作可能成功、回执未记录的中间状态。对于高风险动作，需要查询外部执行状态、业务幂等键或人工核查，而不是假定可以原子提交。
七、运行架构：从同步循环到持久化工作流
7.1 三种常见运行拓扑
| 形态 | 适用条件 | 关键限制 |
|---|---|---|
| 同步单进程 | 短任务、低并发、可重跑 | 进程退出易丢状态 |
| 持久化单体 | 长任务、暂停审批、可恢复 | 状态版本与恢复语义复杂 |
| Worker / 队列 | 高并发、隔离执行、弹性扩容 | 重复投递与一致性风险 |
这是部署与执行方式的选择，不是系统自主性或成熟度的等级排序。单进程也能有完整的权限、测试和日志；分布式系统也可能因错误重试而产生严重副作用。
7.2 恢复必须明确恢复点与副作用语义
Checkpoint 保存某个可恢复状态；事件日志记录发生过的事实；事件溯源要求事件足以作为权威状态的重建依据；Workflow Replay 可能依赖确定性工作流代码和持久化历史。四者不是同义词。采用某种框架的持久化能力，也不等于所有工具调用具有 exactly-once 的外部效果。
对于外部副作用，建议在架构评审中逐项回答：是否支持幂等键？能否查询操作结果？重试是否安全？超时后的结果是否可能未知？需要人工补偿吗？
7.3 多 Agent 的协调不是简单共享聊天记录
当研究、分析、审核由不同 Agent 承担时，应明确每个角色的输入契约、交付工件、写入权限、停止条件和冲突裁决。多 Agent 消息可能作为证据线索，但不应天然拥有高于原始来源的可信等级。审核 Agent 的意见也需要绑定被审核产物的版本，否则可能批准已经发生变化的内容。
八、架构选型：把“为什么这样设计”写成可审查决策
8.1 选型顺序
先识别任务的确定性程度、外部副作用风险、数据敏感性、执行时长、并发规模和验收方式，再确定是否需要动态决策、持久化、人工审批、并行角色或分布式 Worker。推荐先提出最简单可满足要求的方案，再针对观察到的瓶颈评估替代方案。
例如，研究流程大部分稳定时，可采用固定检索与引用核验步骤，仅在证据不足时调用动态 Agent 决策。这样能够把可预测部分留在确定性流程中，同时保留必要的适应能力。但这种混合方案是否优于完全动态 Agent，仍需同任务对照实验。
8.2 架构决策记录（ADR）示例
ADR-007：研究助理第一阶段采用模块化单体
状态：拟采纳（需实施验证）
背景：单用户、低并发；任务 5 - 15 分钟；需证据追踪；暂不自动发布
决策：单进程 Run Controller + Policy Gate + Tool Adapter
使用持久化任务状态；外部发布工具暂不开放
理由：降低部署和一致性复杂度；保留清晰模块边界
备选：多 Agent + 消息队列；独立工作流服务
代价：长任务并发受单实例资源限制；故障隔离能力有限
触发复审：并发上升、任务恢复失败率超阈值、引入外部副作用
验证：故障注入、越权测试、证据追踪、成本与延迟基线ADR 的价值是记录当时的约束与权衡，避免未来只看到技术结果，却不知道为什么做出该选择。
8.3 不宜以框架品牌替代架构判断
OpenAI Agents SDK、LangGraph、Temporal 等工具关注的抽象层与能力边界不同。评估时应逐项核对其运行循环、状态持久化、工具授权、审批机制、执行历史、重试语义和部署方式。一个项目也可能同时使用 Agent SDK 处理决策、工作流引擎处理长任务，并由业务服务实施授权；这属于架构组合，不代表这些框架天然互相替代。
九、贯穿案例：技术研究助理 Agent System 的架构演进
9.1 场景 A：个人研究工具
目标是输入技术问题、检索公开资料、生成带引用的 Markdown 报告；单用户、可人工复核、允许失败后重跑。推荐初始形态为模块化单体：任务入口、Agent 决策适配器、只读工具网关、证据记录器、状态存储和报告生成器。即使不用消息队列和多 Agent，也应验证来源存在性、预算上限和终止状态。
9.2 场景 B：团队协作研究服务
新增要求：多用户隔离、长时间任务、多人审批、报告版本管理、并发执行。此时可能需要持久化任务队列、独立 Worker、租户隔离和审批记录。但“增加一个服务”不能替代权限设计：任务身份必须沿调用链传播，Worker 不能因为持有系统级凭据就绕过用户授权范围。
9.3 场景 C：研究结果自动发布
新增外部副作用后，架构必须引入独立的发布许可和可核查回执。建议把“生成报告”与“批准发布”拆成不同状态和权限操作。报告审批应绑定产物哈希或版本；审批后内容若发生变化，应重新审批。发布失败或超时后，应先核对外部平台是否已接收，再决定是否重试。
9.4 三阶段变化的真正驱动力
| 阶段 | 新增约束 | 主要架构变化 |
|---|---|---|
| 个人工具 | 证据质量与预算 | 模块化、工具网关、状态记录 |
| 团队服务 | 并发、隔离、恢复 | 持久化、Worker、身份传播 |
| 自动发布 | 审批与不可逆操作 | 版本绑定审批、幂等与回执 |
注意：这是设计推演，不是已经实施或测试过的三个系统。实际是否需要拆分服务，应以测量结果和运维成本决定。
十、架构评审：从原则变成可验证的不变量
10.1 六类关键不变量
- 权限不变量：未经授权的工具请求不会产生受保护的外部副作用。
- 状态不变量：终止 Run 不会被普通事件重新变为运行中；并发更新不会静默覆盖较新状态。
- 预算不变量：超过硬预算后不再启动受控的新调用；预算记账与实际调用关联。
- 审批不变量：需要审批的操作必须绑定有效身份、操作参数和工件版本。
- 来源不变量：报告中声称已核验的关键证据具有可追溯记录，不能只凭模型文本证明。
- 恢复不变量：重试和恢复不会在缺少确认机制的情况下静默重复高风险副作用。
这些不变量的实现强度应与风险匹配。例如，“不会重复副作用”不能仅靠测试模型没有重复提出动作来证明，还需要观察可信执行层与外部系统的实际记录。
10.2 故障注入矩阵
| 注入故障 | 必须检查的架构行为 |
|---|---|
| 模型超时 | 有界重试、预算计数、明确状态 |
| 工具返回未知结果 | 不盲目重放高风险动作 |
| 状态写入冲突 | 版本校验或冲突处理 |
| Worker 崩溃 | 可恢复状态与任务归属 |
| 重复消息投递 | 去重或安全重复处理 |
| 审批后工件变化 | 旧审批不可直接复用 |
| 不可信文档注入指令 | 工具授权不受文档指令改变 |
10.3 发布前应保留的架构证据
建议形成一组可追溯工件：任务契约、逻辑架构图、数据流和信任边界图、状态机、工具授权表、接口 Schema、ADR、故障模型、测试报告、已知风险及回滚方案。它们不需要全部写成厚重文档，但必须足以让开发者、评审者和运维人员对同一系统形成一致理解。
10.4 架构检查清单
- [ ] 已明确任务范围、成功条件、失败条件与不支持的场景。
- [ ] 已区分 Agent 提议动作与可信执行层实际授权。
- [ ] 每类关键状态均有明确的权威来源与更新责任。
- [ ] 已画出敏感数据与外部副作用的信任边界。
- [ ] 每个跨边界调用都定义超时、错误与重试策略。
- [ ] 审批、取消、预算耗尽与证据不足具有明确终止语义。
- [ ] 多 Agent 协作明确工件版本、任务归属与冲突处理。
- [ ] 组件拆分有可测量的需求依据，不以微服务数量为目标。
- [ ] 已记录关键架构决策、替代方案和复审触发条件。
- [ ] 已设计可重复的故障、安全与恢复验证场景。
十一、常见架构反模式及修正
把 Prompt 当权限系统。 模型可能遵循提示，也可能被不可信内容影响。修正：由可信工具网关执行授权，记录真实拒绝和副作用。
把聊天历史当权威状态。 对话文本难以表达并发版本、真实工具回执和恢复点。修正：区分上下文与结构化 Run 状态，并建立状态所有权。
把所有失败都当成可重试。 外部操作可能已成功但响应丢失。修正：识别未知结果、幂等能力与补偿路径。
先拆微服务再定义接口。 网络边界增加后，原本模糊的契约会转化为更难排查的分布式故障。修正：先建立逻辑模块与契约，再按负载、隔离或部署需求拆分。
用多个 Agent 代替清晰工作流。 多角色并不自动产生更高质量。修正：明确可并行子任务、交付契约和评估基线。
用一次 Demo 宣称架构可靠。 正常路径演示无法覆盖恢复、权限、并发与未知结果。修正：采用风险驱动的故障注入和系统级验收。
十二、研究结论与下一阶段
Agent System 架构的本质，是将具有不确定性和适应性的 Agent 决策，嵌入一个可授权、可观察、可控制、可恢复、可验证的软件系统中。设计的重点不是消除模型的不确定性，而是把不确定性限制在明确的接口、状态、权限和故障边界之内。
本篇形成六项核心判断：第一，架构必须从任务契约与质量属性推导；第二，逻辑职责、部署单元和信任边界不能混为一谈；第三，动作提议、授权、执行和确认应区分为独立事实；第四，状态所有权与外部副作用语义决定恢复是否可信；第五，单 Agent、工作流、多 Agent 和分布式是可组合的设计维度，不是成熟度等级；第六，架构优劣必须通过场景约束、权衡记录与验证证据判断。
至此，「01 · Agent System 是什么？它如何工作？ - Fundamentals」 的六篇专题形成完整闭环：定义系统、识别组件、理解运行、区分类型、判断完整性、形成架构决策。下一阶段进入 「02 · Agent System 是如何构建和运行的？ - Technical Architecture」，从 L1 Infrastructure 开始，逐层研究运行环境、基础服务、模型服务、Agent Engine、编排协作和应用层的具体技术实现。
附录 A：参考文献与原始资料
以下列出可用于核验本篇所讨论技术机制的官方资料与原始规范入口。本篇未在本轮写作中实时逐页核验这些站点的最新版本；具体 API 名称、支持范围和默认语义应以使用时的官方文档及版本为准。
- OpenAI Agents SDK, Documentation / Running Agents / Sessions / Guardrails：openai.github.io/openai-agents-python 。用于进一步核对 Agent 运行循环、会话与护栏的实际实现边界。
- LangGraph, Overview / Persistence / Durable Execution：docs.langchain.com/oss/python/langgraph/overview 、docs.langchain.com/oss/python/langgraph/persistence 、docs.langchain.com/oss/python/langgraph/durable-execution 。用于进一步核对图执行、检查点与恢复机制。
- Temporal, Documentation：docs.temporal.io 。用于进一步核对持久化工作流、任务重试与执行历史语义。
- Model Context Protocol, Specification：modelcontextprotocol.io/specification 。用于研究工具与资源接入协议；协议存在不等于已解决应用级授权。
- OpenTelemetry, Documentation：opentelemetry.io/docs 。用于研究 Trace、Span 与可观测性基础概念。
- NIST, AI Risk Management Framework：www.nist.gov/itl/ai-risk-management-framework 。用于进一步研究 AI 系统风险管理与验证要求。
- OWASP, GenAI Security Project：genai.owasp.org 。用于进一步研究提示注入、工具滥用和 Agent 应用安全风险。
- Michael Nygard, Documenting Architecture Decisions（ADR 原始实践资料）：cognitect.com/blog/2011/11/15/documenting-architecture-decisions 。用于理解架构决策记录的方法。
资料使用说明： 本篇中的架构图、接口伪代码、六项设计原则、分阶段案例与验收矩阵是综合研究形成的参考设计，并非上述资料共同发布的统一标准。涉及具体框架能力时，应在实施阶段补充版本化的官方文档、源码或运行证据。
附录 B：研究证据、实现边界与验证声明
- 研究性质： 概念综合、架构原理分析、工程设计推演与可验证要求制定。
- 原始资料状态： 本轮未进行实时网页检索或框架源码审计；附录 A 提供后续核验入口，不代表已验证最新版本的所有行为。
- 实现状态： 本篇包含架构伪代码、逻辑图、ADR 示例和故障注入方案；未提供可运行的完整 Agent System 实现。
- 实验状态： 本篇未执行真实模型、工具网关、工作流引擎或分布式 Worker 的运行测试；没有报告通过率、延迟或成本基准。
- 案例边界： 研究助理三阶段演进是用于分析设计取舍的假设场景，不代表已经部署的生产系统。
- 原则适用性： 文中的接口、状态划分、控制/执行职责、架构检查清单属于建议性设计；是否适用取决于任务契约、风险、负载和组织约束。
- 需要后续验证的重点： 真实 SDK 的状态与工具调用契约、外部副作用幂等、持久化恢复、跨租户授权、并发冲突、故障注入与性能成本对照。
- 结论边界： 本文可以支持架构评审与技术选型的初步设计，但不能替代特定系统的安全审计、压力测试、故障演练和生产验收。