boss-skill v3.9.5 发布,聊聊对 Harness 的一点新理解

查看 16|回复 1
作者:echoVic   
Harness 不是让 Agent 更聪明,而是让 Agent 的工作更可信。
所以这次变更给 Boss 的整条研发流水线加一层工程化的骨架。
它要管五件事:流程怎么定义,当前跑到哪,产物以什么为准,什么时候允许继续,失败后怎么恢复。
这次最关键的变化,是加了一层 workflow-plan.json 。
过去 Boss 里已经有 pipeline pack 、artifact DAG 、runtime commands 。DAG 能表达"哪个产物依赖哪个产物",runtime 能记录阶段和 Agent 状态。但它们之间还缺一层明确的执行定义。
现在初始化时,会把 pipeline pack 和 artifact DAG 编译成一份 workflow plan 。它描述这条流水线有哪些 phase 、哪些 agent node 、哪些 gate node ,以及这些节点之间的依赖关系。与此同时,workflowHash 、packHash 、artifactDagHash 描述的是"这条流程定义是什么",runId 描述的是"这一次具体执行"。
这个拆分很重要。
因为流程定义和运行实例不是一回事。定义可以被审计、比较、缓存;运行实例可以暂停、恢复、失败、重试。以前这些东西混在一起,很多恢复逻辑只能靠约定。现在它们开始有了明确边界。
我现在会把 Harness 分成几层看
第一层是定义层。 它回答:这条流水线到底是什么?比如 pack 、DAG 、workflow plan 、各种 hash 。它应该稳定、可比较。
第二层是运行层。 它回答:这一次跑到哪了?这里靠的是事件流和 execution.json ,而不是聊天上下文。聊天记录不可靠,事件流才是状态真相源。
第三层是产物层。 PRD 、架构文档、任务拆解、QA 报告、部署报告,这些落盘并被 runtime 记录后,才算正式产物。Agent 说自己完成了,不等于完成了。
第四层是门禁层。 测试、Evidence Wave 、QA 、final gate ,本质上都是在问同一个问题:凭什么继续?这层是防止"看起来完成了"的关键。
第五层是恢复层。 比如 promptFingerprint 、inputDigest 、resume --from-run 。它们的目标不是炫技,而是让中断之后不用靠人脑捡现场,也不用全量重跑。
关于 SKILL.md 的瘦身
另外这次变更还把主 SKILL.md 从 474 行压到了 99 行。之前它太像一个巨型总控 prompt ,什么都写在里面。这样越复杂,越依赖模型一次性记住,最后又回到"让模型自己记流程"的老路。
现在主 Skill 只保留入口、不变量和索引。长流程、runtime 命令、Evidence Wave 、platform driver 、hooks ,都拆到 references 里按需读取。

harness, 流程, 可信

clemente   
Harness != skill
您需要登录后才可以回帖 登录 | 立即注册

返回顶部