Agentic Workflow 的讨论里，最容易混在一起的两个词是 Flow 和 Harness。

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

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

一个更干净的分层

可以把 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 结果如何被判断和约束 指标、回归测试、验收门槛、预算、风险审计

这个分层能解释一个常见误会：早期 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 列为常见模式。

这些模式的共同点，是“有一个可描述的控制结构”，大模型只是控制结构中的执行与判断单元。

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

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

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

CrewAI 把 Flow 定义成事件驱动 workflow，包含 task、state、@start()、@listen()、持久化与恢复；Google ADK 的 graph-based workflows 把节点和边当作 agent logic；OpenAI Agents SDK 的 orchestration 文档也把多 agent 的流程拆成模型驱动和代码驱动两类。这些框架名称不同，但都在把 Flow 从“提示词里的顺序感”提升成“一等控制对象”。

模式：控制流外显化

问题：研究任务跨过多个阶段后，提示词里写的“先做 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 Engineering 讨论可以保留：Harness 仍然是 Agent 进入真实工程世界的关键层。需要修正的是边界：Harness 不应该吞掉所有编排概念。编排一旦包含可复用的分支、并行、回环、门禁和状态机，就已经进入 Flow 层。

模式：运行时承重

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

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

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

Autoresearch 是最小标本

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

它只有三个核心文件：

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

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

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 调度、算法硬件协同和芯片互联等方向。

这些内容不宜被理解成“一个超级 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、并行策略和芯片相关探索，可以放进这张表。每个方向都有自己的研究对象和测量指标，但它们共享一个共同原则：研究过程必须被控制流化，实验执行必须被 Harness 化，结果进入下一轮前必须经过评测门。

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

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

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

模式：跨层研究路由

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

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

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

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

Anthropic 在《When AI builds itself》中讨论了 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 的关系压成一个模型：

1
2
3
4
5
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 只能托住一堆局部动作。

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

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

参考资料