Agentic Flow 不是 Harness：控制流、运行时与全栈研究模型

Agentic Workflow 的讨论里，Flow 是一个多义词，比 Harness 更容易被误用。

本文里的 Flow 不是某个框架的官方统一术语，而是一个作者抽象。它把 Anthropic 和 LangGraph 所说的 workflow、OpenAI Agents SDK 所说的 orchestration、CrewAI 的 Flows、Google ADK 的 graph-based workflows，以及研究实验里的循环、路由和门禁，统一放到“控制流规格”这一层讨论。

这个限定很重要。CrewAI 的 Flow 是产品概念；OpenAI 文档谈的是 agent orchestration；LangGraph 和 ADK 更常使用 workflow、graph、node、edge 这组词。它们不是同一个标准术语，但都触及同一个工程问题：任务的入口、路径、分支、循环、状态和终止条件，应该留在提示词里，还是成为可检查、可复用、可恢复的控制结构。

Harness 像运行时底座：它负责把模型、工具、文件系统、权限、日志、状态、检查点和评测装进一个可控环境。Flow 像控制规格：它定义任务从哪里开始，经过哪些节点，何时分支，何时并行，何时回环，何时结束，哪些结果能进入下一关。

把所有东西都叫 Harness，会丢掉一个关键层：研究过程本身也需要被建模、被版本化、被复盘。尤其在大模型全栈研究里，算法、训练内核、推理系统、GPU 微架构、KV Cache、调度系统、芯片互联不是一个长提示词能串起来的。它们更像一组相互耦合的实验工厂，需要控制流负责组织研究拓扑，需要运行时负责承载执行。

一个更干净的分层

可以把 Agentic Research System 拆成四层：

flowchart TB
  Goal["Research Goal<br/>研究目标与约束"] --> Flow["Flow Spec<br/>控制流规格"]
  Flow --> Policy["Agent Policy / Skill<br/>角色、方法、上下文"]
  Policy --> Harness["Harness Runtime<br/>工具、沙箱、状态、追踪"]
  Harness --> Eval["Evaluation / Governance<br/>指标、门禁、审计"]
  Eval --> Flow

这四层分别回答不同问题。

层级	关注点	典型产物
Flow Spec	研究流程如何流动	DAG、状态机、路由器、并行分支、循环、人工门禁
Agent Policy / Skill	每个节点如何思考和行动	提示词、技能文档、角色边界、领域上下文
Harness Runtime	节点如何被可靠执行	工具调用、沙箱、权限、文件读写、checkpoint、trace
Evaluation / Governance	结果如何被判断和约束	指标、回归测试、验收门槛、预算、风险审计

这四层不是互斥模块，而是四个设计视角。状态结构可以属于 Flow Spec，状态持久化和恢复属于 Harness Runtime；“指标是否达标”属于 Evaluation，“达标以后走哪条边”又回到 Flow Spec。分层的目的不是把系统切成四个孤岛，而是避免把“流程怎么走”“节点怎么判断”“动作怎么执行”“结果怎么验收”混成一个主循环。

这个分层能解释一个常见误会：早期 Agent demo 里，Flow、Policy 和 Harness 经常揉在一个主循环里。模型拿到提示词，调用工具，改代码，跑测试，读日志，再决定下一步。小规模任务看起来没问题，但一进入研究型任务，混层会迅速失控。

Flow 负责“下一步是什么”。Harness 负责“这一步能否安全、可观测、可恢复地跑完”。Policy 负责“这一类节点该怎样做判断”。Eval 负责“这个结果是否值得进入下一轮”。

这四个问题合在一起，才是一个完整的 Agentic 系统。

本文所说的 Flow 是控制规格

Anthropic 在《Building effective agents》里把 workflow 和 agent 做了区分：workflow 是预先定义的代码路径，agent 则由模型动态决定流程和工具使用。LangGraph 文档沿用了类似区分，并把 prompt chaining、routing、parallelization、orchestrator-worker、evaluator-optimizer、agent 列为常见模式。

这些资料不能推出统一命名结论，但能推出另一个更稳的判断：agentic system 里存在一类需要外显的控制结构。Prompt chaining、routing、parallelization 的控制路径比较硬；orchestrator-worker 和 evaluator-optimizer 会把一部分决策交给模型；autonomous agent 的控制权更偏模型侧。它们不是同一种模式，但都需要回答控制权在哪里、状态怎么传、失败怎么回、什么时候停。

Flow 原语	对应模式	作用
Chain	Prompt chaining	把复杂任务切成稳定阶段，每一段产出都成为下一段输入
Router	Routing / Semantic routing	根据任务类型、风险、上下文选择不同路径
Fan-out / Join	Parallelization / Parallel delegation	并行探索多个候选，再汇总、投票或裁判
Planner-Worker	Orchestrator-worker / Task decomposition	由规划节点拆任务，由工作节点执行子任务
Loop	Evaluator-optimizer / Reflection	基于评测反馈迭代，直到达标或耗尽预算
Graph	Graph workflow / Dependency graph	把有依赖关系的实验组织成可追踪图

Flow 的工作，是把隐含在提示词里的流程规则外显出来：

规则	不外显时的后果	外显后的收益
入口条件	模型拿到任何输入都试图直接执行	可以先分类、澄清、拒绝或降级
分支条件	研究路径靠临场判断漂移	每条路径有可审计的进入条件
并行策略	候选方案串行试错，探索空间窄	多路线并行搜索，最后统一评估
循环停止条件	反复改、反复测，预算不可控	能用指标、次数、时间和风险切断循环
状态结构	上下文越积越乱	关键状态成为结构化对象，可以恢复和复盘

几个框架的说法需要分开看：CrewAI 把 Flow 做成事件驱动 workflow，支持 task、state、@start()、@listen()、持久化与恢复；Google ADK 的 graph-based workflows 用节点和边定义 agent logic，并强调比长提示词更精确的执行顺序和路由；OpenAI Agents SDK 的 orchestration 文档把多 agent 流程拆成模型决策和代码编排两类；LangGraph 则用 graph/state/persistence/debugging 等机制承载 workflow 与 agent pattern。

更稳妥的说法是：这些框架没有共享一个名叫 Flow 的标准概念，但都在把流程、路由、状态、分支和循环从提示词中抽出来，交给代码、图、事件或框架对象承载。本文把这层抽象统一叫 Flow Spec。

模式：控制流外显化

问题：研究任务跨过多个阶段后，提示词里写的“先做 A、再做 B、失败就 C”会变得不可测试、不可审计、不可复用。

结构：把任务入口、节点、边、状态、分支、并行、循环和停止条件写成显式规格。模型仍可做局部判断，但流程骨架不依赖模型临场发挥。

反模式：把控制逻辑全塞进一个超长 system prompt，再期待模型稳定遵守。

Harness 是运行时底座

Harness 处理的是另一组问题：

运行时能力	解决的问题
Tool dispatcher	工具如何被调用、参数如何校验、失败如何回传
Sandbox	哪些文件能改，哪些命令能跑，哪些网络访问被禁止
State / Memory	当前任务状态、历史实验、长期知识如何保存
Checkpoint / Resume	失败后从哪里恢复，哪些中间产物可信
Trace / Observability	每一步输入输出、工具调用、指标变化如何追踪
Permission / Policy	高风险动作如何审批，敏感信息如何隔离
Artifact store	代码、日志、模型权重、图表、评测结果如何沉淀

因此，Harness 的判断标准落在执行可靠性上。同一个 Flow，可以跑在很弱的 Harness 上，也可以跑在强 Harness 上。前者看起来像脚本，后者才像工程系统。

举例说，训练实验里“先跑 baseline，再尝试改学习率，再比较 val loss”是 Flow；“每次实验必须固定时间预算、抓取日志、记录显存、失败后保留堆栈、只能改指定文件”是 Harness。流程决定研究路径，运行时决定结果是否可信。

这里也容易出现反向误解：Harness 不只是一个工具调用壳，也不等于“没有控制流”。成熟运行时通常会内置 retry、timeout、checkpoint、trace、permission gate 和 artifact store，这些能力本身就会影响控制路径。更准确的边界是：Harness 提供可执行性和可观测性；Flow Spec 决定这些执行结果如何进入下一步。

此前的 Harness Engineering 讨论可以保留：Harness 仍然是 Agent 进入真实工程世界的关键层。需要修正的是边界：Harness 不应该吞掉所有编排概念。编排一旦包含可复用的分支、并行、回环、门禁和状态机，就已经进入 Flow 层；运行时一旦包含工具、权限、沙箱、日志、恢复和审计，就仍然是 Harness 层。

模式：运行时承重

问题：Agent 生成的动作只有在工具、权限、日志、状态和评测都被托住时，才有工程意义。

结构：Harness 提供统一执行语义，让每个 Flow 节点在相同约束下运行。节点可以失败、重试、回滚、恢复，但不可绕过运行时边界。

反模式：只追求“模型会不会想”，不建设文件边界、权限边界、指标边界和恢复边界。

Autoresearch 是最小标本

karpathy/autoresearch 很适合作为最小标本。这个 repo 的目标很具体：给 AI agent 一个小而真实的单 GPU LLM 训练设置，让 agent 通宵自动做实验。agent 修改训练代码，训练 5 分钟，检查指标是否改进，保留或丢弃修改，然后继续循环。

这个例子的价值在于边界足够窄。它不证明“全自动科学发现”已经成立，只证明一个更小、更硬的东西：可修改面只有一个文件，时间预算固定，评价指标固定，失败与回退规则写清楚时，agent 可以在可验证的研究闭环里工作。正因为小，Flow、Harness、Eval 的边界反而更容易看见。

README 把 repo 的关键面收缩到三个文件：

文件	层级含义
`prepare.py`	固定数据、tokenizer、评测函数和运行工具，属于 Harness/Eval 边界
`train.py`	agent 可修改的实验对象，属于研究状态
`program.md`	给 agent 的研究组织规则，接近轻量级 Skill 与 Flow 混合规格

README 和 program.md 里的设计选择尤其关键：只允许 agent 改 train.py，固定 5 分钟训练预算，用 val_bpb 作为统一指标，results.tsv 记录实验结果，改进则保留，不改进则回退。它把“让模型写代码”收缩成一个可评测的研究闭环：

flowchart LR
  Baseline["建立 baseline"] --> Idea["提出实验想法"]
  Idea --> Patch["修改 train.py"]
  Patch --> Run["固定 5 分钟训练"]
  Run --> Metric["读取 val_bpb / VRAM"]
  Metric --> Gate{"是否改进"}
  Gate -- yes --> Keep["保留 commit"]
  Gate -- no --> Revert["回退修改"]
  Keep --> Idea
  Revert --> Idea

这张图里，Flow 和 Harness 的边界很清楚：

元素	属于 Flow	属于 Harness / Eval
baseline -> idea -> patch -> run -> gate 的循环	是	否
只能改 `train.py`	否	是
每次训练固定 5 分钟	否	是
用 `val_bpb` 作为保留门槛	是	是
记录 `results.tsv`	否	是
改进保留，不改进回退	是	是

最后两行横跨两层，因为研究系统里最有价值的边界常常同时包含控制流和运行时：控制流驱动评测，评测反过来收紧控制流。

program.md 也说明了 Skill 和 Flow 的微妙关系。它既写了 agent 的行为规则，又写了实验循环，还写了结果记录格式。Karpathy 在 README 中把它称为一个很轻量的 skill。更严格地看，它同时承担三件事：

内容	更合适的层级
读哪些文件、不能改哪些文件	Harness / Policy
每次实验怎么循环	Flow
改进、崩溃、回退如何判断	Eval / Governance

这正是早期 Agent 系统常见形态：一个 Markdown 文件里同时装着技能、流程和运行规则。随着任务复杂度上升，这些职责需要拆出来。否则，program.md 会从轻量 skill 变成不可维护的研究操作系统。

模式：研究闭环最小化

问题：开放式研究太大，模型容易在无约束空间里随机游走。

结构：选一个真实但小的研究对象，固定可修改面、固定时间预算、固定指标、固定保留规则，让 agent 在窄而硬的闭环里积累改进。

反模式：给 agent 一个完整代码库和一个笼统目标，然后让它“自行研究”。

从单 GPU 到全栈研究工厂：一个外推模型

本地参考稿讨论的是更大的问题：如何用 Agentic Workflow 支撑大模型全栈研究。材料覆盖了算法研究、训练与推理基础设施、GPU 微架构测试、并行策略、KV Cache、MaaS 调度、算法硬件协同和芯片互联等方向。

这一节是从 Autoresearch 外推出来的系统设计模型，不代表行业已经有一套公认的“全栈 Agentic Research Factory”。Autoresearch 证明的是窄闭环的价值；全栈研究需要额外解决跨层依赖、资源调度、评测口径和人类门禁。两者之间不能直接画等号，只能从小闭环扩展到多闭环网络。

这些内容也不宜被理解成“一个超级 agent 负责全栈”。更合适的模型是多条研究线共享同一套 Flow/Harness/Eval 基础设施：

flowchart TB
  Goal["大模型全栈研究目标"] --> Router["研究路由"]
  Router --> Algo["算法 Flow<br/>注意力、MoE、KV Cache、数学结构"]
  Router --> Kernel["训练/推理内核 Flow<br/>算子、显存、吞吐、稳定性"]
  Router --> Infra["基础设施 Flow<br/>并行策略、调度、MaaS、实验平台"]
  Router --> Hardware["硬件协同 Flow<br/>GPU 微架构、互联、芯片约束"]

  Algo --> Judge["统一评测与证据门禁"]
  Kernel --> Judge
  Infra --> Judge
  Hardware --> Judge

  Judge --> Memory["研究记忆<br/>结果、失败、假设、可复现实验"]
  Memory --> Router

每条研究线都需要自己的 Flow：

研究线	Flow 形态	Harness 重点	Eval 重点
算法探索	文献抽取 -> 假设生成 -> 实验设计 -> 代码改动 -> 指标比较	论文库、代码沙箱、训练脚本、实验追踪	loss、吞吐、参数量、泛化、复杂度
GPU 微架构测试	test plan -> case 生成 -> 编译运行 -> 错误归因 -> 报告生成	编译器、驱动、性能计数器、日志采集	latency、bandwidth、occupancy、异常覆盖
并行策略	工作负载建模 -> 策略生成 -> 模拟/实测 -> 代价分析	集群资源、profile 工具、调度器接口	utilization、通信开销、收敛速度
KV Cache / MaaS	请求模型 -> 缓存策略 -> 压测 -> 成本与延迟分析	trace replay、压测平台、缓存可视化	hit rate、TTFT、TPOT、显存占用
算法硬件协同	算法约束 -> 硬件约束 -> 搜索空间 -> Pareto 前沿	架构模拟器、成本模型、工艺/功耗约束	性能、功耗、面积、可实现性

参考稿里提到的数学知识注入、注意力结构、KV Cache 变体、GPU 微架构 case、并行策略和芯片相关探索，可以放进这张表。每个方向都有自己的研究对象和测量指标，但它们共享一个共同原则：研究过程要有显式控制流，实验执行要有可靠运行时，结果进入下一轮前要经过评测门。

全栈研究的难点不只是“agent 会不会读论文、写代码、跑实验”。更硬的工程问题是跨层反馈：

上游发现	下游影响
新注意力结构降低理论复杂度	可能改变 kernel 实现和缓存布局
GPU 微架构测试发现访存瓶颈	可能反推 batch、sequence、KV 管理策略
MaaS 压测发现长尾延迟	可能要求调度器和模型结构一起改
芯片互联约束改变通信模型	可能改变并行策略和训练 recipe

因此，大模型全栈研究里的 Flow 不只是一个线性 pipeline，而是一个跨层反馈网络。Harness 不只是工具壳，而是把这些反馈变成可验证证据的执行基础。

模式：跨层研究路由

问题：大模型研究的瓶颈可能出现在算法、系统、内核、调度或硬件任一层。单线性流程会把跨层问题误判成局部问题。

结构：先用路由节点判断问题归属，再派发到专门 Flow。每条 Flow 产出结构化证据，统一进入评测门，必要时反向触发其他研究线。

反模式：算法结果差就只改算法，吞吐差就只改 kernel，延迟差就只改 serving。

人类位置：目标、品味与门禁

Anthropic 在《When AI builds itself》中讨论了 AI 参与 AI 研发的趋势：AI 已经能承担更多编码、实验执行和局部优化工作；但在目标选择、研究判断、问题 framing、验证与安全边界上，人的角色仍没有消失。

这和 Autoresearch 的设计是一致的。机器可以跑大量局部实验，但研究目标、可接受风险、复杂度偏好、指标选择和停止条件仍需要被显式写进系统。没有这些边界，实验数量只会放大漂移。

在人机协同的研究系统里，人类不必站在每个 tool call 旁边审批。更重要的位置有五个：

人类职责	系统化表达
选择值得研究的问题	Goal spec、研究路线、资源预算
定义什么算好	Eval metric、复杂度惩罚、验收门槛
提供跨域联想	路由规则、知识注入、候选方向
设置信任边界	权限、沙箱、人工门禁、发布流程
判断何时停止	budget、convergence、risk、opportunity cost

这也是参考稿里“人的核心价值是跨域激活”的工程化版本。跨域激活不能只停留在灵感层，它需要变成 Flow 的路由规则、Agent Policy 的知识边界、Harness 的资源边界和 Eval 的通过标准。

模式：Human as Research Governor

问题：把人类放在每一步执行里，会拖慢系统；把人类完全移出系统，会让研究目标和风险边界漂移。

结构：人类负责目标、边界、指标、资源和最终验收。Agent 负责候选生成、实验执行、证据整理和局部优化。Flow 把二者连接起来。

反模式：把“自主研究”理解成无人设定目标、无人定义指标、无人审计结果。

一个可复用模型

在本文术语里，可以把 Agentic Flow 和 Harness 的关系压成一个模型：

Agentic Research System
  = Flow Spec
  + Agent Policy / Skill
  + Harness Runtime
  + Evaluation / Governance

其中：

组件	设计问题
Flow Spec	任务如何被拆解、路由、并行、循环和终止
Agent Policy / Skill	每类 agent 的知识、角色、方法和输出格式是什么
Harness Runtime	工具、文件、权限、状态、日志和恢复如何被托住
Evaluation / Governance	哪些指标决定保留、回退、升级、人工介入和发布

这个模型能直接指导系统设计：

症状	优先检查层
agent 总是跳步骤	Flow Spec
agent 不知道该找哪个工具	Agent Policy / Skill
实验结果无法复现	Harness Runtime
指标提升但复杂度失控	Evaluation / Governance
多条研究线互相打架	Flow Spec + Governance
上下文越来越乱	Harness State + Agent Policy
一次失败导致整轮研究报废	Harness Checkpoint

它也能解释为什么“Flow 不是 Harness”这个区分重要。Harness 是 agent 能够进入真实系统的承重结构；Flow 是研究活动能够被组织成可执行知识生产过程的控制结构。没有 Harness，Flow 跑不稳。没有 Flow，Harness 只能托住一堆局部动作。

但这个模型有一个前提：Flow 在这里是分析抽象，不是行业统一命名。CrewAI 的 Flow、OpenAI 的 orchestration、LangGraph 的 workflow、ADK 的 graph workflow，各自都有产品边界和 API 语义。把它们放进同一张图，是为了抓住“控制流外显化”这个共同趋势，不是为了抹平术语差异。

Autoresearch 证明了最小闭环的价值：固定可修改面、固定预算、固定指标、固定保留规则，agent 就能在一个窄任务里形成可观察的研究循环。全栈研究则要求把这个闭环扩展成多条研究线、多种评测门、多层资源约束和跨层反馈网络。

Agentic Workflow 的长期价值，不在于把研究员替换成一个更大的聊天窗口，而在于把研究过程本身变成可执行、可测量、可复盘、可进化的系统。