定义¶

把 Agent 循环里的"决策来源"（Decision）与"执行机制"（Execution）拆成两件事的架构原则——同一套执行框架可以接受 LLM 产生的决策，也可以接受确定性代码产生的决策，对执行层不可见。

张铁蕾 AmphiLoop / bridgic 项目 2026-04 提出该术语（作者自称是"世界上第一个决策与执行解耦的架构"，未独立核实）。但概念本身的独特之处不在"是不是世界第一"，而在它给 amphiflow 模式提供了实现机制——让 workflow 模式与 agent 模式可以共享同一套 OTA 循环（observe-think-act-cycle），只在"思考"环节差异化。

关键要点¶

传统理解：决策与执行耦合¶

通常实现里两者是绑死的： - agent 模式：LLM 既产生决策也驱动循环——while not finish: decision = llm.think(); execute(decision) - workflow 模式：代码既描述步骤也直接执行——step1(); step2(); step3()

两套基础设施完全不同，互不兼容。如果要从 workflow 切到 agent（出错时），需要重启整套 runtime。

解耦后：执行层只认 Decision 对象¶

AmphiLoop 的实现里执行层不关心 Decision 来自 LLM 还是代码——它只看到一个 ActionCall(tool_name, args) 对象。这就让两种模式可以共享同一个执行循环：

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

workflow 模式 OTA：
    decision = next(workflow_generator)  # 代码产生 Decision
    execute(decision)

关键技术手段：Python yield + generator——workflow 函数用 yield ActionCall(...) 描述步骤，"描述"和"执行"被自然分开。yield 那一刻只是产生 Decision，真正执行延迟到外层循环的 _action(decision, ctx) 调用。

这不是简单的录制重放¶

AmphiLoop 的 workflow 不是固定动作序列——on_workflow 函数里可以包含分支、循环、条件判断（for row in rows、while True、if order_id in ctx.processed_order_ids: continue）。workflow 是"动态程序"，但描述层与执行层依然解耦。

含义：workflow 的"动态性"不依赖 LLM，依赖普通编程语言的控制流。对应的就是节省 token + 不依赖 LLM + 稳定。

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

七层模型的 Layer 4（Tool Runtime）已经把"工具调用变成受控 syscall"——把 tool 解析、校验、权限、执行归一化。决策与执行解耦走得更远一步：不只把 tool execution 标准化，连"产生 tool call 的源"也抽象成统一的 Decision 对象，LLM 与确定性代码都是合法的源。

对七层模型的补强角度：Layer 3 Query Loop 的状态机里，"决策源" 维度可以独立出来——这给 sentino-agent Standalone Agent 引入"workflow 优先 + agent 兜底"提供了架构参照。

与 agent-tool-design 的关系¶

agent-tool-design 关注"工具的接口长什么样让 LLM 好用"。决策-执行解耦补一层"工具的产生者可以不是 LLM"。

具体含义：agent-tool-design 里"AskUserQuestion 经过三次迭代才成功" 是因为 LLM 不会用——但如果决策源也可以是确定性代码，那"AskUserQuestion 什么时候触发"可以由代码而非 LLM 判断，工具接口设计的一些 LLM-friendly 妥协可以省掉。

实现技术细节¶

Python yield 是关键¶

async def on_workflow(self, ctx):
    yield ActionCall("click_element_by_ref", description="Click Search button", ref="...")
    yield ActionCall("wait_for", description="Wait for results", time_seconds=4)
    for row in rows:
        if row.order_id in ctx.processed_order_ids:
            continue
        yield ActionCall("click_element_by_ref", ref=row_ref)

外层 _run_workflow 通过 __anext__ 和 asend 拉 Decision，每次循环走完整 OTA：observe → 拿 decision → action。

无 LLM 调用的 OTA 循环¶

workflow 模式的 OTA 循环里 Think 步骤实际上没有调用 LLM——log 还会 log "Think" 但不消耗 token。这是 amphiflow 模式"节省 token"承诺的实现基础。

适用边界¶

• 不适用纯 agent 任务：如果任务本质开放（如开放式研究、对话陪伴、创意生成），描述不出 workflow 模板，决策源只有 LLM 一种，解耦没有额外价值
• 不适用一次性任务：解耦的价值在于"同一任务跑很多次时让大部分跑 workflow，只异常路径走 agent"——一次性任务的 LLM 成本 vs workflow 维护成本不划算
• 依赖任务可被分解为 ActionCall 序列：如果任务步骤难以离散化（如生成连续的自然语言段落），yield ActionCall 模型就不合适

对 sentino-agent 的具体含义¶

Sentino Standalone Agent 当前是纯 agent loop（指令 + 工具选择 + 触发条件 + LLM 自判完成）。决策-执行解耦视角给一个潜在演进方向：

• 当前形态：每次触发都是完整 LLM agent loop，token 成本与稳定性完全依赖模型当下表现
• 潜在升级：高频固定模式的 standalone agent 可以由 LLM 第一次跑通后"凝固"为 workflow（捕获 ActionCall 序列），后续运行直接走 workflow，遇异常再降级到 agent。对 Sentino 这种以陪伴/语音 24/7 高频运行为主的产品，省 token 价值很高

但有显著架构复杂度代价： - 需要 sandbox + workflow 序列化 + 异常切换状态机配套 - 与 agent-tool-design "逃生工具"原则有张力——逃生工具假设用户/agent 始终保留"现造工具"自由度，workflow 凝固后这种自由度受限 - 与 harness-engineering "iOS 模式 vs Android 模式" 选择对应——决策-执行解耦更靠 iOS 模式（封闭定义工作流）

判断：Sentino 当前阶段不引入。但作为 Standalone Agent v2 演进的备选路径，值得在产品规模化（>100 个客户、>10K standalone agent 实例）时重新评估。

与其他 agent runtime 的对照¶

架构独特性的真正所在：AmphiLoop 是已知 agent runtime 里第一个把"决策源"和"执行机制"明确做成两个解耦的轴并提供两种模式自动切换的——这条比"世界第一"自称更精确。

相关概念¶

• amphiflow-pattern — 决策-执行解耦给 amphiflow 提供了实现基础
• observe-think-act-cycle — 解耦后 workflow 与 agent 共享同一个 OTA 循环
• agent-runtime-architecture — 与 Layer 4 Tool Runtime 关系：解耦走得更远一步
• agent-tool-design — 工具的产生者可以不是 LLM，给工具接口设计松绑
• harness-engineering — iOS 模式（封闭定义工作流）的具体技术路径
• sentino-agent — Standalone Agent 引入"workflow 优先 + agent 兜底"的架构参照
• agent-creator-refiner-operator — DED 是 agent 内部架构原则（Decision 由谁产生），三元论是 agent 外部角色分类（agent 在系统中扮演什么）——两个维度正交可叠加