🏠 home › concepts › amphiflow-pattern
tags
[AI, Agent, 架构, workflow, 设计]
created
2026-04-27
updated
2026-04-27
sources
[raw/notes/zhang-tielei-amphiflow-agent-workflow-fusion-2026-04-25.md]

定义

Amphiflow（amphibious flow，两栖流）是张铁蕾 AmphiLoop / bridgic 项目 2026-04 提出的 agent 架构模式：默认运行 workflow 模式（确定性、不依赖 LLM、节省 token），出错时自动切换到 agent 模式（自主修复或重新规划），可在两种模式之间自动切换。

作者自称这是"世界上第一个决策与执行解耦的架构"（未独立核实），从 2026-04 时点已知 agent runtime 看（OpenClaw / Hermes / n8n / dify / Claude Code），它确实是第一个把 workflow 与 agent 作为两种可自动切换的运行模式提供给应用层的方案。

与"workflow vs agent"两条路的关系

2026 行业语境里 workflow 类（n8n / dify）和自主性 agent 类（OpenClaw / Hermes / Eigent CoWork）是两条互斥的路。Amphiflow 的定位是"克制的扬弃"——不全盘否定其中任何一方，把两者当成同一架构里的两种运行模式：

维度 workflow 模式 agent 模式 amphiflow
决策来源 编程时确定 LLM 实时产生 默认前者 + 出错切后者
token 成本 极低 高 大部分 token 成本省掉
异常处理 失败 自主绕过 workflow 失败自动降级到 agent
路径动态性 算法可动态计算路径，但障碍非预期就失败 完全动态 默认确定路径 + 异常路径 LLM 接管

工作流程

默认 workflow 模式

走预定义的 ActionCall 序列。每次循环： 1. Observe：读环境状态 2. Think：从 workflow 代码（generator）拉下一个 Decision——不调用 LLM 3. Act：执行 Decision 对应的 tool

出错时两级降级

workflow 步骤失败
    ↓
consecutive_failures += 1
    ↓
是否 < max_consecutive_fallbacks 阈值？
    ├── 是 → 小降级：snapshot + agent loop 修复当前 step
    │       ├── 修复成功 → 重回 workflow 模式继续
    │       └── 修复失败 → 累计失败次数
    └── 否 → 大降级：on_agent(ctx)，整个程序切到 agent 模式
            └── 共享 ctx + 考虑 workflow 已完成的部分 + 重新规划剩余路径

小降级（step-level fallback）：在独立 snapshot 上下文里跑 agent，目标是"修好这一步 + 完成原始 step intent"，修完切回 workflow。

大降级（full fallback）：彻底放弃 workflow，启动一个 big agentic loop，目标是"在已完成部分基础上完成原始 task goal"。

失败阈值的语义

max_consecutive_fallbacks 控制"小降级失败几次后转大降级"。这不是简单的 retry 次数——而是给系统一个判断"原 workflow 是否还可救"的机制。如果同一个 step 连续多次需要 agent 修复，说明环境已经偏离 workflow 假设太远，整体重规划比逐步修复更省。

实现的两个核心机制

1. 共享的 OTA 循环

两种模式都走 Observe → Think → Act，共享 Observe 与 Act，Think 各自独立。这就是为什么可以无缝切换——切换只是换 Think 的实现，循环本身不变。

2. 决策-执行解耦

执行层（_action）只认 Decision 对象，不关心来源。LLM 和 workflow 代码都是合法的 Decision 产生者。Python yield ActionCall(...) 是关键技术手段——workflow 函数描述出来的 ActionCall 序列被外层循环 __anext__ / asend 拉取，与 LLM 产生 Decision 走同一套执行管线。

优势

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

七层模型的 Layer 3 Query Loop 是单一 LLM agent loop。amphiflow 给 Layer 3 加了一个"模式维度"——同一个 agent runtime 可以跑两种 Layer 3 实现，按需切换：

七层模型 Layer 3 状态 amphiflow 状态
messages, toolUseContext, autoCompactTracking, turnCount, ... + mode: workflow \| agent、consecutive_failures、workflow_generator、fallback_goal

对七层模型的补强：Layer 3 不必假设决策源唯一是 LLM，可以包含"决策源切换"作为 runtime 状态的一部分。

与 harness-engineering iOS vs Android 模式的关系

amphiflow 在 Harness 两层定义里偏 iOS 模式（封闭定义运行环境，承诺可靠）： - workflow 部分由 AmphiLoop 根据 TASK.md 引导生成代码（不是用户自己拼的开放配置） - 模式切换逻辑由框架统一管理 - max_consecutive_fallbacks 等阈值由框架默认提供

但 workflow 内部用户可写动态控制流（for / while / if / continue），这又给开发者保留了 Android 风格的灵活度。amphiflow 是 iOS 外壳 + Android 内核的混合——这与传统纯 workflow 工具（n8n 拖拽 GUI）和纯 agent 框架（OpenClaw 完全开放）都不同。

与其他 Agent runtime 的对照

系统 默认模式 是否能切换 异常处理
n8n / dify workflow 不 失败终止或人工介入
OpenClaw / Hermes Agent / Eigent CoWork agent 不 LLM 自己绕
Claude Code Agent Loop agent 不 LLM 自己重试 + Layer 5 Permission 兜底
AmphiLoop amphiflow workflow 是（自动） 小降级 / 大降级两档

amphiflow 的位置："workflow 优先 + agent 兜底"是一条独立的第三条路，区别于"全 workflow"和"全 agent"。

适用边界

对 sentino-agent Standalone Agent 的具体含义

当前 Sentino Standalone Agent 形态：纯 agent loop（指令 + 工具选择 + 触发条件 + LLM 自判完成）。amphiflow 视角给一个潜在的 v2 演进方向：

方面 当前 amphiflow 视角下的可能升级
高频 standalone agent 每次触发跑完整 LLM loop 第一次跑通后凝固为 workflow，后续走 workflow + 异常降级
token 成本 与触发频率线性增长 大部分调用走 workflow，token 成本主要花在异常
稳定性 完全依赖模型当下表现 workflow 部分确定性，agent 兜底保留灵活性
架构复杂度 中（Agent Loop + Memex） 高（+ workflow 序列化 + 异常切换状态机 + sandbox 隔离）

张力： - 与 agent-tool-design "逃生工具"原则有张力——逃生工具假设运行时始终保留"现造工具"自由度，workflow 凝固后这种自由度受限 - 与 CREAO "Coding Agent 是 connector 元工具"判断（ai-first-engineering）方向相反——CREAO 主张让 agent 现写代码扩展长尾，amphiflow 主张让 workflow 凝固通用路径

判断：Sentino 当前阶段（早期 standalone agent + 客户量未起量）不引入 amphiflow。但当 standalone agent 实例数 >10K + 高频固定模式占比高时，amphiflow 是节省 token + 提升稳定性的潜在杠杆——值得在 Standalone Agent v2 阶段重新评估。

待观察

相关概念