huaAgentStudyAgent

外观

zmh.life

02 · Agent System 由什么构成？ - Core Components ​

所属知识库：Agent 全栈技术地图
所属领域：03 · Agent System
所属章节：01 · Agent System 是什么？它如何工作？ - Fundamentals
文档类型：系统组件、接口契约与工程实现研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent System 的最小职责集合是什么？任务、Agent、执行器、协调器、模型与工具服务、状态、控制与观测如何通过明确的契约协同？哪些组件是概念上必要的，哪些只在特定规模或可靠性目标下引入？如何用可检验的组件图和执行追踪判断系统是否完整？

专题导读 ​

本篇属 Fundamentals。研究 Agent System 的组件，首先需要把“系统必须承担的职责”与“必须部署的服务”分开。一个单进程应用可以同时完成任务入口、模型调用、工具执行、状态管理和权限控制；把它拆成多个服务并不会自动提高可靠性。本篇以任务执行契约为主线，追踪组件之间的调用、状态所有权、失败传播和外部副作用。

在原有组件清单与教学实现的基础上，本次修订补充了接口不变量、故障归属、部署映射和组件协作的验收思路。研究重点是组件如何形成可执行系统，而不是重复下一篇的运行时序，也不将概念接口误写为具体 SDK 的现行 API。

一、为什么不能把 Agent System 简化为组件清单？ ​

组件（Component）是承担某种职责的可识别软件单元；能力（Capability）是系统对外或对内能够完成的行为；机制（Mechanism）是输入、控制、状态与输出之间的实际变换过程。例如“任务可恢复”是一项能力，“检查点存储”是组件，“在安全边界记录状态、重启后重建执行并处理外部副作用”才是机制。三者并不一一对应。

因此，本篇不从“必须使用 Redis、Kafka、Kubernetes”开始，而是从一次任务需要哪些不可缺失的职责开始。一个 Python 进程可同时承担任务接收、执行、状态与控制；大规模部署可把它们拆成服务。职责不可缺位不等于必须独立部署。

本文沿用上一篇的工作定义：Agent System 是围绕一个或多个 Agent 的目标导向任务，组织决策与行动、运行控制、必要资源、状态反馈和外部交互，形成实际可执行的软件系统。它不以多 Agent、分布式或专用框架为成立条件。

二、从职责到组件：最小核心与可选扩展 ​

为避免把成熟度误当作定义，先分清三类：逻辑上必须覆盖的职责、常见实现组件、由规模和风险触发的扩展组件。

功能职责最小系统需要回答常见组件实现何时需要拆分或增强
任务契约与入口输入、目标、完成/失败条件是什么？Task API、CLI、Task Service多用户、排队、优先级、幂等提交
Agent 定义与决策谁根据目标和状态选择行动？Agent Definition、Policy/Model Adapter多版本、多模型、多 Agent
执行驱动谁启动下一步并落实行动？Runner、Agent Engine、Runtime长任务、暂停恢复、隔离 Worker
资源与外部交互行动通过什么接口真正发生？Model Client、Tool Executor、Environment Adapter工具网关、沙箱、模型路由
状态与反馈如何记录执行进展并利用结果？In-memory State、Event Log、State Store持久化、检查点、共享状态
控制与终止谁实施权限、预算、超时与停止？Guard、Policy Enforcement、Supervisor审批、配额、审计、租户隔离
结果与错误如何交付成功、失败或取消？Result Contract、Error Model异步回调、通知、交付流水线

核心判据： 以上是逻辑职责，不是七个必需的微服务。观测与测试是工程质量的基础，但不应作为概念上是否存在 Agent System 的硬性门槛；面向真实用户时，则必须根据风险和服务目标配置足够的可观测性、审计与验证机制。

三、统一对象模型：先把名称和身份定义清楚 ​

对象关键字段（示例）生命周期与所有权不应混淆的对象
AgentDefinitionagent_id, version, instructions, tool_policy发布与版本管理；定义所有者运行中的实例
Tasktask_id, input, success_criteria, priority请求进入到终态；任务服务单次模型请求
Runrun_id, task_id, definition_version, status一次具体执行；RunnerTask（可重试多次 Run）
Stepstep_id, run_id, action, status单步决策/执行；RunnerToolCall（一个 Step 可含多次调用）
ToolCallcall_id, tool, args, approval, outcome工具执行器；有外部副作用模型输出的调用意图
Observationstep_id, result/error, provenance由环境/工具返回；进入 Agent 上下文经过验证的事实
Staterun_id, revision, progress, pending状态存储；按运行隔离长期 Memory、原始日志
Eventevent_id, run_id, type, timestamp, payload追加/发布；用于追踪与投影状态快照
Artifactartifact_id, run_id, checksum, location结果服务；可有保留策略日志消息

对象模型不是通用标准；实际框架可以合并或拆分对象。特别注意 Task 与 Run：任务是目标契约，Run 是一次执行尝试。若失败后重新运行，保留同一 task_id、生成新的 run_id 有利于区分业务任务与执行尝试；但这是一种设计建议，不是所有框架的强制接口。

四、核心组件的责任边界与接口 ​

4.1 任务入口与 Task Service ​

**职责：**接收输入、校验任务契约、创建任务身份、处理重复提交、暴露查询和取消入口。

接口契约示例： submit(TaskSpec, idempotency_key) -> TaskRef；get_task(task_id) -> TaskView；cancel(task_id) -> Decision。

**关键数据：**用户请求、任务元数据、提交幂等键。

**典型失败模式：**把用户请求直接交给模型后丢失任务标识；HTTP 请求超时却无法知道后台任务是否启动。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.2 Agent Definition 与决策适配器 ​

**职责：**提供 Agent 身份、模型/策略选择、指令与工具能力的逻辑定义；把状态和观测转为下一步行动意图。

接口契约示例： decide(goal, context, observations) -> ActionProposal | FinalAnswer。

**关键数据：**Agent 定义版本、输入上下文、允许的行动集合。

**典型失败模式：**把 Agent Definition 与 Run 混为一谈；模型输出直接当作已执行的操作。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.3 Agent Engine / Runner ​

**职责：**驱动 Agent 的步骤执行，协调决策、验证、工具执行、反馈、终止；拥有运行状态机和步骤预算。

接口契约示例： start(task, definition) -> RunRef；advance(run_id) -> StepResult；stop(run_id, reason)。

**关键数据：**运行状态、步骤序号、错误与终止事件。

**典型失败模式：**多个模块都能修改状态导致竞态；工具调用失败后不明确是重试、失败还是继续。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.4 Model Service Adapter ​

**职责：**把具体模型服务的认证、请求格式、流式响应、错误和限流转换为内部统一接口；与 Agent 决策策略分离。

接口契约示例： generate(request, timeout, budget) -> ModelResponse。

**关键数据：**模型输入、模型标识、调用 ID、token/成本元数据。

**典型失败模式：**把厂商响应结构泄露给全部业务组件；对所有模型异常一律重试。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.5 Tool Executor 与 Environment Adapter ​

**职责：**把已批准的行动请求映射为真实外部操作，执行参数校验、身份传播、超时、隔离和结果归一化。

接口契约示例： execute(AuthorizedToolCall) -> ToolOutcome。

**关键数据：**工具 Schema、授权上下文、调用 ID、外部操作结果。

**典型失败模式：**工具白名单存在但调用绕过检查；将工具异常字符串误认为可信指令。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.6 State Store 与 Event Recorder ​

**职责：**保存足以推进或解释执行的信息；区分当前状态快照、事件记录、外部结果和长期记忆。

接口契约示例： load(run_id) -> State；compare_and_swap(run_id, expected_revision, next_state)；append_event(event)。

**关键数据：**状态版本、检查点、事件 ID、时间戳。

**典型失败模式：**多 Worker 覆盖彼此状态；认为保存对话文本即可恢复外部副作用。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.7 Control / Policy Enforcement ​

**职责：**对模型提出的行动实施独立的授权、预算、审批和终止判定；控制逻辑必须在实际执行路径上。

接口契约示例： authorize(principal, task, action, context) -> Allow | Deny | RequireApproval。

**关键数据：**主体身份、资源范围、行动风险、预算和审批记录。

**典型失败模式：**仅靠系统提示词禁止危险操作；审批在 UI 中显示但执行器不检查。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.8 Result / Artifact Service ​

**职责：**明确成功、失败、取消、等待审批等结果状态，持久化或交付产物并记录来源。

接口契约示例： finalize(run_id, outcome, artifacts) -> ResultRef。

**关键数据：**输出契约、产物 URI/哈希、失败码。

**典型失败模式：**仅凭 Agent 说“完成了”就判定成功；输出文件存在但内容未验证。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.9 Orchestrator / Coordinator（条件性） ​

**职责：**在多个任务、多个 Agent 或复杂依赖下协调任务图、并发、消息和结果汇聚；简单单 Agent 系统可不设独立编排器。

接口契约示例： schedule(workflow, dependencies) -> ExecutionPlan；dispatch(unit) -> Assignment。

**关键数据：**任务 DAG、依赖、队列、消息、协作状态。

**典型失败模式：**把任务拆成多个 Agent 却没有明确交接契约；错误地假设消息只会送达一次。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

4.10 Observability 与运维服务（质量增强） ​

**职责：**跨组件关联日志、Trace、指标与审计事件；支撑诊断、SLO、容量和安全分析。

接口契约示例： record(event, correlation_ids)；trace(run_id)；metrics(window)。

**关键数据：**trace_id、run_id、step_id、耗时、成本、失败类型。

**典型失败模式：**仅记录模型回复而没有工具执行证据；敏感输入直接写入日志。

边界原则： 组件可以共用进程与存储，但调用方应通过明确的输入输出契约交互。示例接口是分析性设计，不是某个 SDK 的原生 API。

五、组件关系：控制流、数据流、状态流与信任边界 ​

text
User / API
    │ TaskSpec
    ▼
Task Service ──────────────> Task Store
    │ TaskRef
    ▼
Orchestrator（可选） ──────> Queue / Worker（可选）
    │
    ▼
Agent Engine / Runner ──────────────> State Store / Event Log
    │           ▲                            ▲
    │ context   │ observation                │ checkpoint/events
    ▼           │                            │
Agent Decision  │                            │
    │ proposal  │                            │
    ▼           │                            │
Policy Enforcement ──deny/approve────────────┤
    │ authorized action                       │
    ▼                                         │
Tool Executor / Model Adapter ────────────────┘
    │             │
    ▼             ▼
External APIs   Model Provider
    │             │
    └── result ───┘
           │
           └──────────> Runner -> Result / Artifact

横切：身份与权限 / 日志追踪 / 配置 / 预算 / 安全策略

控制流由 Task Service、Runner、Policy 和 Orchestrator 等决定“谁有权推动下一步”；数据流携带任务输入、模型输出、工具结果和产物；状态流记录运行阶段与检查点；信任边界出现在用户输入、模型输出、第三方工具结果、外部执行环境和跨租户数据访问处。不能因为某段内容来自模型或工具，就将其视为可信指令。

5.1 关键设计：Propose → Authorize → Execute → Observe ​

一个可审计的工具调用应经历四个阶段：Agent 提出结构化行动意图；系统依据真实用户与任务授权判断是否允许；执行器实施操作；系统记录外部结果并更新状态。即使模型使用 Function Calling，模型仍只生成调用意图，真实调用由程序完成。

text
ActionProposal(tool="write_file", args={...})
  -> PolicyDecision(allow/deny/approval_required)
  -> ToolExecution(call_id, deadline, principal)
  -> ToolOutcome(success/error, external_reference)
  -> StateUpdate(revision + 1, observation)

如果动作具有不可逆外部副作用（例如发送邮件、转账、删除数据），审批、幂等键、外部操作回执和恢复策略必须依据具体风险单独设计。检查点不能自动撤销已发生的外部副作用。

5.2 组件责任矩阵（RACI 式简化） ​

行为主要负责参与不应单独决定
解释目标和提出下一步Agent DecisionModel Adapter、ContextTool Executor
校验行动权限Policy EnforcementTask Service、Identity模型提示词
驱动执行状态转移RunnerState Store、Orchestrator前端 UI
真正调用外部工具Tool ExecutorPolicy、Environment模型输出
记录可恢复状态State Store / RunnerTool Executor仅有聊天记录
判断结果交付条件Result Contract / RunnerAgent、ValidatorAgent 自述

六、单 Agent 与多 Agent 的组件组合 ​

6.1 最小单进程系统 ​

最小系统可以只有一个入口函数、一个 Agent 决策函数、一个 Runner、一个工具注册表、一个内存状态对象和一个权限检查器。它仍应能区分行动意图与实际执行，并产生可识别的成功或失败终态。此形态适合学习、低风险自动化和原型验证。

6.2 面向业务的单 Agent 系统 ​

当任务可能长时间运行或需要多个用户并发提交时，常见扩展是 Task Service、持久化 State Store、Queue/Worker、Artifact Store、Trace 与审批入口。系统的复杂性主要来自任务生命周期、外部副作用与可靠性要求，而不是 Agent 的数量。

6.3 多 Agent 协作系统 ​

多 Agent 通常新增 Agent Registry/Definition Catalog、Coordinator、消息或任务交接协议、共享产物与冲突处理。关键不在“多几个角色”，而在任务责任、通信内容、状态所有权、并行依赖和汇总验证。编排器可集中决策，也可以让 Agent 通过约定协议分散协作；两者在可控性、伸缩性和故障传播上有不同取舍。

七、组件拆分的工程判断：什么时候需要独立服务？ ​

触发条件候选拆分收益代价与风险
模型供应商多、限流差异大独立 Model Gateway统一认证、路由与调用治理额外延迟、单点故障
任务长且需要排队Task Service + Worker异步调度、容量隔离重复投递、状态同步
工具具有高风险副作用Tool Gateway + Sandbox强制授权、环境隔离权限传播、审计复杂度
多 Agent 需要并行依赖Orchestrator / DAG Engine明确任务依赖和重试边界协作协议与状态复杂度
需要跨进程恢复Durable State Store中断后恢复执行检查点一致性、外部副作用
多租户、多环境Identity / Quota / Policy Services租户隔离与集中治理配置漂移、策略误配

拆分决策可用五个维度检验：故障域、信任域、状态所有权、独立扩缩容需求、变更频率。仅因架构图看起来整齐而拆服务，通常会增加部署与调试成本。

八、贯穿案例：研究助理系统的组件设计 ​

假设任务为“研究某项 Agent 技术，生成包含可追溯来源的比较报告”。任务契约规定交付格式、最少来源要求、允许的搜索工具、预算和完成标准。系统可以采用以下组件配置：Task Service 创建任务；Agent Definition 定义研究策略；Runner 推进执行；Model Adapter 调用模型；Tool Executor 访问搜索与阅读工具；Policy 限制工具和预算；State Store 保存检索进度；Artifact Service 保存报告；Trace 关联执行事件。

一次执行可能产生如下逻辑事件（示意，不是真实实验日志）：

json
{"type":"task.created","task_id":"t-01","run_id":"r-01"}
{"type":"step.proposed","run_id":"r-01","step":1,"tool":"search"}
{"type":"policy.allowed","run_id":"r-01","step":1}
{"type":"tool.completed","run_id":"r-01","step":1,"source_count":3}
{"type":"state.updated","run_id":"r-01","revision":1}
{"type":"step.proposed","run_id":"r-01","step":2,"tool":"read"}
{"type":"run.completed","run_id":"r-01","artifact":"report.md"}

该事件序列只证明各职责可被概念性串联；要判断“报告可信”，还需单独验证来源质量、证据引用和内容准确性。若任务需要人工确认，Runner 应进入可识别的 WAITING_APPROVAL 状态，批准后从合法状态继续，而不是由前端简单隐藏或显示按钮。

九、参考实现：无外部依赖的组件契约实验 ​

下面的 Python 代码展示最小组件边界：Agent 产生行动提案，Policy 在工具执行前校验，Runner 记录事件并处理终止。它不接入真实 LLM、不做持久化、不提供分布式恢复，不能代表生产 Agent System。配套文件 02-Agent-System-Core-Components-v1.1-demo.py，Python 3 标准库（含 3.9）。运行：python3 02-Agent-System-Core-Components-v1.1-demo.py。

python
from __future__ import annotations
from dataclasses import dataclass, field
from typing import Callable

@dataclass(frozen=True)
class Proposal:
    tool: str
    argument: str

@dataclass
class RunState:
    events: list[str] = field(default_factory=list)
    result: str | None = None
    status: str = "CREATED"

class Policy:
    def __init__(self, allowed: set[str]):
        self.allowed = allowed
    def authorize(self, proposal: Proposal) -> bool:
        return proposal.tool in self.allowed

class ToolExecutor:
    def __init__(self, tools: dict[str, Callable[[str], str]]):
        self.tools = tools
    def execute(self, proposal: Proposal) -> str:
        return self.tools[proposal.tool](proposal.argument)

class Runner:
    def __init__(self, policy: Policy, executor: ToolExecutor):
        self.policy, self.executor = policy, executor
    def run(self, proposal: Proposal) -> RunState:
        state = RunState(status="RUNNING")
        state.events.append("action.proposed")
        if not self.policy.authorize(proposal):
            state.status = "DENIED"
            state.events.append("policy.denied")
            return state
        state.events.append("policy.allowed")
        try:
            state.result = self.executor.execute(proposal)
            state.status = "COMPLETED"
            state.events.append("tool.completed")
        except Exception:
            state.status = "FAILED"
            state.events.append("tool.failed")
        return state

if __name__ == "__main__":
    tools = ToolExecutor({"lookup": lambda q: f"evidence:{q}"})
    runner = Runner(Policy({"lookup"}), tools)
    ok = runner.run(Proposal("lookup", "Agent System"))
    denied = runner.run(Proposal("delete_file", "/important"))
    assert ok.status == "COMPLETED" and ok.result == "evidence:Agent System"
    assert denied.status == "DENIED" and "policy.denied" in denied.events
    print(ok.status, ok.events)
    print(denied.status, denied.events)

本地执行通过：COMPLETED ['action.proposed', 'policy.allowed', 'tool.completed']；DENIED ['action.proposed', 'policy.denied']。

实验能验证什么： 工具提案与工具执行分离；权限拒绝发生在执行前；结果与事件进入统一 RunState；失败有独立终态。不能验证什么： 模型决策质量、持久化、并发、网络超时、审批恢复、真实安全隔离和外部操作幂等。若要继续工程化，首先引入明确的 run_id、状态版本与持久化事务，再测试重复请求、并发写入、失败重试和外部副作用。

十、真实框架的组件映射：用官方资料校准概念 ​

项目/规范可用于研究的组件切面对本篇的启示不应直接推断
OpenAI Agents SDKAgent、Runner、Tools、Sessions、Tracing单 Agent 执行与会话管理可以在 SDK 中组合SDK 自带完整多租户平台、生产级调度集群
LangGraphGraph/Node、State、Checkpoint、Interrupt状态驱动与图执行可承载 Agent 运行检查点自动解决外部副作用的 exactly-once
Model Context ProtocolTools、Resources、Prompts 与客户端/服务端交互工具连接协议与执行系统边界应区分采用 MCP 即自动实现授权与安全隔离

上述为官方文档层面的功能映射，并非本篇实际运行上述项目或对源码完成审计。具体 SDK 版本、接口签名、恢复语义和安全限制，必须在对应技术专题重新核验。

十一、常见架构错误与排查方法 ​

误区实际风险应检查的证据
组件越多系统越成熟复杂度与故障面增加需求、SLO、组件责任与依赖
模型能输出工具调用就等于完成执行行动意图与真实副作用混淆Tool Executor 调用记录与回执
有数据库就支持恢复状态与外部操作不一致检查点、恢复策略、幂等测试
有多个 Agent 就有有效协作交接不清、重复劳动、结果冲突协作契约、任务图、共享状态
在 Prompt 写禁止操作就足够安全模型输出无法构成强制授权执行路径上的 Policy 检查
所有错误都可以重试重复副作用、成本失控错误分类、幂等键、重试预算
有日志就有可观测性无法关联跨组件行为run_id/step_id/trace_id 与指标
单进程不是系统混淆逻辑职责与部署规模任务、执行、状态、控制是否闭环

排查顺序建议先找任务入口 → Runner → 权限执行点 → 真实工具接口 → 状态写入 → 结果终态，再讨论技术选型。若任一关键职责找不到所有者，组件图就尚未闭合。

十二、从 Core Components 进入后续研究 ​

本篇回答“系统由哪些职责构成，以及组件如何通过契约协作”，不展开各组件的全部实现。后续研究分工如下：

后续专题需要深入的问题
03 · Execution Mechanism任务状态机、事件时序、执行与恢复的真实机制
04 · System Types集中/分散、工作流/动态决策、单/多 Agent 类型比较
05 · Completeness & Maturity按需求、风险与服务目标判断系统完整性
06 · Architecture & Design Principles故障域、信任域、状态所有权和部署边界
L2 · Platform Services数据库、队列、缓存和对象存储的真实语义
L4 · Agent EngineRunner、Step、State Machine、Tool Dispatch 的实现
L5 · Orchestration & CollaborationDAG、消息、任务分配、协作协议与冲突处理
H2 / H4 / H7 / H10安全、状态、可靠性与系统级测试

补充研究：组件契约、失败归属与部署映射 ​

接口契约应表达的不变量 ​

任务入口至少要保证任务身份与请求契约可追溯；Runner 必须区分模型提出的行动意图与工具实际执行的结果；工具执行层必须在执行前完成授权；状态存储必须能够识别状态版本，防止并发更新静默覆盖；交付层必须区分成功、拒绝、证据不足、取消与故障。接口名称可以变化，但这些不变量应能在测试中观察。

下面是概念性接口设计，不是特定框架的真实 SDK：

python
class ToolGateway:
    def execute(self, run_id, call_id, tool_name, arguments, principal):
        # 1. 验证调用参数；2. 按 principal 授权；3. 执行；4. 记录结果或错误
        raise NotImplementedError

class StateRepository:
    def compare_and_swap(self, run_id, expected_revision, new_state):
        # 仅当当前 revision 与 expected_revision 一致时写入
        raise NotImplementedError

call_id 只提供调用身份，不自动保证幂等；外部副作用是否可安全重试取决于目标系统是否支持去重键、事务或业务补偿。compare_and_swap 用于解释乐观并发控制，不表示所有 Agent System 都必须采用该算法。

组件故障的责任划分 ​

故障场景首要责任边界应保留的证据
模型输出无效参数解析器／Runner原始响应摘要、校验错误
未授权工具调用Tool Gateway身份、策略版本、拒绝事件
状态版本冲突State Repository期望版本、实际版本
工具超时且结果未知Tool Gateway／Runner调用标识、超时与副作用状态
重复交付Result Service产物标识、交付幂等键

同一逻辑组件的三种部署映射 ​

单进程将入口、Runner、工具网关和内存状态合并为模块，适合低并发、短任务及本地原型；其局限是进程故障可能丢失状态。模块化单体保留明确接口与持久化存储，适合多数初期产品，可减少分布式协调成本。多服务部署把执行 Worker、任务队列、工具网关和状态服务分离，适合需要隔离、扩缩容或不同故障域的场景，但会引入网络失败、重试、版本兼容和可观测性要求。

组件契约的最小验收 ​

针对组件边界应分别测试：重复提交是否创建重复任务；未授权调用是否在副作用前被拒绝；工具超时是否保留“结果未知”而非伪造失败；并发状态写入是否检测冲突；取消请求是否阻止后续可阻止的行动；失败是否能追溯到对应的 run_id 和 call_id。这些属于建议测试项目，不能仅凭接口设计就宣称已通过。

研究结论 ​

Agent System 的核心组件应首先被理解为一组不可遗漏的系统职责：任务契约、Agent 决策、执行驱动、外部资源调用、状态反馈、控制终止与结果交付。它们可以在单进程中合并，也可以在复杂系统中拆分。Orchestrator、队列、持久化、沙箱、审批与观测系统的重要性取决于规模、风险和可靠性要求，不应作为定义上的固定清单。

工程设计的关键是让每一次行动都有可追溯的路径：提出行动 → 授权校验 → 实际执行 → 观察结果 → 更新状态 → 判断继续或终止。组件的价值来自责任清晰、契约可验证、失败可处理，而不是组件名称或数量。

附录 A：参考文献与原始资料 ​

参考资料与核验状态 ​

以下均为官方资料入口，用于进一步核验技术概念；本篇没有实时联网确认其截至 2026-10-28 的最新版本或逐行核对源码。

证据边界： 本文的“七项最小职责”“组件责任矩阵”“拆分触发条件”是知识库提出的综合性分析框架，不是官方联合标准。参考代码为教学级实现；是否通过本地测试以实际运行记录为准。

附录 B：研究证据与验证声明 ​

  • **研究基准日期：**2026 年 10 月 28 日。
  • **本次修订检索状态：**未新增实时网页检索；保留原文来源及其原有核验声明，不将旧资料冒充重新核验的最新版本。
  • **本次修订验证状态：**原文包含教学级参考代码。本次修订未重新执行其测试；新增的接口片段是概念示意，不是可直接部署的 SDK。
  • **结论适用范围：**定义、组件划分、架构选型及成熟度分级均需结合任务目标、风险等级、实际框架版本与目标环境进行核验。
  • **实验声明：**本次修订不宣称新增实验已经通过；历史文档中的运行或测试表述仅代表原文所述范围，需由独立可重现的执行记录支持。