定义¶

Agent 循环的最基础抽象：Observe（观察） → Think（思考） → Act（行动）。

• Observe：把环境原始数据加工成适合思考的形式（"感知"）
• Think：基于观察产生一个决策（Decision）——决定下一步如何行动（"认知"）
• Act：调用工具，对环境产生影响（"执行"）

OTA 是 SEAL 架构 的基础抽象（SEAL = Sense-Think-Act 在语音交互场景的特化），也是 amphiflow / 决策-执行解耦 的核心循环对象。本页独立成页是因为 OTA 自身的抽象边界比 SEAL 或 amphiflow 都更基础——值得作为 agent 架构讨论的"原子词"。

与 SEAL 架构的关系¶

seal-architecture 是 Bojie Li 为语音交互场景设计的 OTA 特化版本，重点在三件事：

OTA 本身不假设语音场景，也不假设 Think 必须由 LLM 产生（amphiflow 里 workflow 模式 Think 由代码产生）——是更基础的循环抽象。

与 agent-runtime-architecture 七层模型的关系¶

七层模型的 Layer 3 Query Loop 是 OTA 的具体工程化：

while (true) {
  prefetchMemoryAndSkills()                    # Observe 准备
  messages = applyBudget → snipAndCompact      # Observe 收尾
  assistant = streamModel(messages)            # Think
  if (!hasToolUse) return finishTurn()
  toolResult = runToolUse()                    # Act
  messages = writeBack(messages, ...)          # 进入下一轮 Observe
}

七层模型把 OTA 拓展成完整的 runtime——加上上下文治理（snip/microcompact/collapse/autocompact）+ 失败恢复 + 工具结果回灌 + 预取优化。OTA 是 Layer 3 状态机的内在循环结构。

与 agency-framework Agency 时序框架的关系¶

Agency 三步：定义边界 → 执行 → 评估。OTA 三步：观察 → 思考 → 行动。

两个框架不是同义改写： - Agency 是元层的循环——人或 agent 在更高时序上设标准、跑、回看调整 - OTA 是 agent 内部的执行循环——一次 turn 内的感知-决策-行动微闭环

Agency "评估"环节的输出可能是"调整下一轮 Agent 的边界"，对应 OTA 多次循环之后整体外层的反馈。两者在时间尺度上不同。

决策来源不必是 LLM：amphiflow 的洞察¶

amphiflow-pattern 的关键观察：OTA 循环的 Think 步骤产生的是 Decision 对象，不是必须由 LLM 产生。

agent 模式：
    decision = llm.think(context)        # LLM 产生

workflow 模式：
    decision = next(workflow_generator)  # 代码产生（Python yield）

只要执行层（Act）只看 Decision 不关心来源，两种模式可以共享同一个 OTA 循环——这就是 decision-execution-decoupling 的核心。

含义：OTA 是 agent 与传统软件的共同抽象——传统软件的"读输入 → 调函数 → 写输出"也是 OTA，只是 Think 是程序员预先写好的；agent 的 OTA 是 Think 由 LLM 实时生成。

多次循环的连续性¶

单次 OTA 循环不是 agent 的全部——agent 系统的特征是"OTA 循环跑很多轮直到完成"。每轮的 Observe 包含上一轮 Act 的结果，Think 基于累积上下文。

这就是 agent-runtime-architecture Layer 3 强调"Query Loop 不是 API 调用，是状态机"的核心——状态在 OTA 循环之间持续传递，包括 messages、turnCount、autoCompactTracking 等等。

适用边界¶

• OTA 是描述抽象，不是实现规范——具体实现可以在每一步加上很多工程细节（流式、并发、缓存、压缩）
• 不是所有 agent 都需要"Think"环节调 LLM——纯 reactive agent（输入到输出的直接映射）可以省略 Think；但只要有"基于上下文做选择"的需要，Think 就必须存在
• Observe 不是"把所有数据塞进上下文"——上下文窗口有限，Observe 必须做选择和压缩，对应 Layer 3 的五层压缩管线

在已知 agent runtime 中的具体形态¶

待观察¶

• OTA 是否会成为 agent 架构讨论的"基础术语"？目前张铁蕾博文使用，seal-architecture 用 Sense-Think-Act，业界没有统一术语
• OTA 抽象层级与 ReAct（Reasoning + Acting）框架的关系是什么？ReAct 主要描述 LLM 怎么交替"推理"和"行动"，OTA 多了 Observe 这一步——Observe 显式化是有价值的还是多余的？

相关概念¶

• seal-architecture — OTA 在语音交互场景的特化（+ 流式 + 并发 + 边听边想/边想边说）
• amphiflow-pattern — OTA 在"workflow + agent 自动切换" 维度上的扩展
• decision-execution-decoupling — Think 步骤的产物（Decision）与 Act 步骤的执行可以解耦
• agent-runtime-architecture — Layer 3 Query Loop 是 OTA 的工程化具体实现
• agency-framework — 元层时序循环 vs OTA 内部执行循环
• orchestration-free-agents — 多 Agent 协作里每个 Agent 内部都是 OTA 循环