Workflow：Harness Engineering 的骨架
本文是「企业级应用中 Harness Engineering 的实践与思考」系列的第 2 篇。
为什么不能让 Agent 直接开始实现
在很多 vibe coding 的实践里，最常见的路径是这样的：给 Agent 一个模糊的需求，Agent 思考一阵后就开始不断生成代码。经过一段不短的等待之后，它交付出一个看起来确实还不错的结果：页面能打开，流程能跑通，功能也大致可用。
这种体验很容易让人产生一种错觉：只要模型足够强，需求就可以直接通向实现。
但在企业级应用里，这条路径往往会带来问题。Agent 直接实现出来的东西，可能充满了大量猜测、臆想和自我设计。它不一定明显错误，甚至可能看起来很完整、很合理、很可用，但它并不一定是业务真正需要的东西，也不一定符合已有系统的边界、规则和协作方式。
这也是软件工程一直试图解决的问题。真实开发很少是从一个模糊想法直接跳到代码，而是通过 workflow 中的一系列阶段，把大的业务目标、产品意图或 use case，逐步拆解成可以理解、可以追踪、可以协作、可以开发、可以管理、可以验证的工程单元。
这些阶段并不是形式主义。它们让一个复杂需求从“想要什么”逐渐变成“要做什么”“谁来做”“做到什么程度”“如何判断完成”。需求被拆解之后，协作才有边界，开发才有入口，验证才有依据，管理才有对象。
AI 的 Harness 也是一样的。它不是要跳过软件工程，也不是凭空发明一套新的管理概念，而是要把 workflow 中这套拆解、流转、确认和验证机制重新应用到 AI Agent 上。Workflow 的意义，不是让 Agent 慢下来，而是让它先进入正确的问题结构，再开始加速。
Plan：把长期目标变成可治理的范围
在传统软件工程实践中，当需求大到接近 epic 的规模时，进度管理就变得必要。因为这个粒度已经不再是一个人、一两次提交、一次简单验证就能完成的任务。它通常包含多个功能点、多轮实现、多次反馈，也会跨越一段时间和多个上下文。
AI Harness 也需要这样的最大工作粒度。它需要一个容器，把长期目标从开放的想法中圈出来，让它拥有边界、状态和可追踪的进度。这个容器不能太大，大到只剩愿景；也不能太小，小到只是一个普通任务。它应该刚好承载一个可以被拆解、推进和验证的工程目标。
在这套实践中，这个粒度被称为 plan。
这里没有直接沿用 epic 这个词，并不是为了制造新概念，而是为了避免机械照搬传统项目管理语境。plan 更强调“一个需要被持续推进和治理的目标范围”：它可以对应一个功能集合、一次架构调整、一次迁移计划，也可以对应一个阶段性的工程目标。
plan 也是 spec 所对应的主要规模。也就是说，一个 plan 不只是任务列表的外壳，它通常承载着一个需要被说明、拆解、实现和验证的较大工程意图。
但 plan 本身并不是 AI Agent 直接执行的最小单位。plan 更重要的作用，是创建、组织和管理一组 stories。它定义这一组 stories 属于哪个目标，当前整体推进到什么状态，哪些 stories 已经完成，哪些还在分析、实现、审查或暂停。
换句话说，plan 管理的不是一条线性的待办事项，而是一组围绕共同目标展开的执行单元。通过 plan，长期目标获得了边界；通过 stories，这个目标被拆成可以真正进入 workflow 的工作。
Story：把意图变成可执行的工程单元
如果说 plan 负责把长期目标组织成可治理的范围，那么 story 则把这个范围进一步拆成可以进入具体实现、审查和验证的工程单元。
story 这个概念并不是凭空出现的。它脱胎于软件工程实践中的 story card：一个足够小、可以被理解、讨论、实现和验收的工作单元。
在 AI Harness 中，story 继承了这个概念的核心。它仍然承载需求、增强点、验收标准、范围边界、优先级、依赖关系和必要上下文。它的目标也仍然相似：把一个较大的工程意图，拆成一个可以真正进入开发过程的工作单元。
但 story 在 AI Agent 面前也需要被重新裁剪。
传统 story 中常见的 story point 或 human day，本质上是围绕人类团队产能、排期和成本建立的度量。它们在团队管理中有意义，但对于 AI Agent 的执行过程来说，并不是最关键的信息。Agent 不会按照人天估算来理解任务，也不会因为 story point 更小就天然更可靠。
与此同时，AI Harness 中的 story 也增加了传统 story card 中不一定显式存在的内容，尤其是对 spec 或需求描述的分析结果。当前需求是否足够清晰，是否存在歧义，是否有遗漏，是否已经可以进入实现，这些判断都需要在 story 层面被记录下来。
这使得 story 不只是一个“要做什么”的容器，也是一处分析结果的沉淀点。AI Agent 在进入实现之前，需要先在 story 层面把问题理解清楚：目标是什么，边界在哪里，哪些假设不能擅自做，哪些问题需要追问，哪些验收标准还不够明确。
这种分析结果有时会非常具体。对于前端界面类 story，它可能精确到按钮的颜色、尺寸、间距、圆角、阴影、交互状态和响应式表现；对于业务流程类 story，它可能精确到字段校验、权限分支、异常提示和边界数据。只要这些信息会影响实现和验收，就应该成为 story 的一部分。
对 AI Agent 来说，story 的关键不是估算工作量，而是定义一个清晰的任务边界：它要解决什么问题，不能越过什么范围，依赖哪些上下文，完成后如何判断结果，失败时应该回到哪里。
因此，AI Harness 中的 story 更关注可理解、可执行、可审查和可验证。它不是为了衡量人类要花多少时间，而是为了让 Agent 知道当前任务到底是什么、应该做到哪里、开发需要知道哪些信息，以及如何证明已经完成。
这样看，story 不只是 plan 下面的一条待办事项。它是 workflow 中真正进入执行的工程单元。但无论是管理范围的 plan，还是承载执行的 story，只要它们存在于 workflow 中，就必须有一种方式表达自己当前处在什么阶段。
Status：让任务进入正确的阶段
plan 和 story 都需要一种方式表达自己处在 workflow 的哪个阶段。这个方式就是 status。
status 不是一个装饰性的标签，也不只是给界面展示用的字段。它的意义在于，让人和 Agent 对当前工作的阶段形成共同理解：现在应该做什么，不应该做什么，下一步可以往哪里走，什么时候必须停下来。
最自然的状态是 todo、implementing 和 completed。一个工作单元要么还没有开始，要么正在推进，要么已经完成。如果只是处理一次性的简单任务，这三个状态似乎已经足够。
但在企业级应用和 AI Agent 的协作中，它们很快就不够了。
首先，分析和实现必须分开。一个 story 不能从 todo 直接跳到 implementing，因为模糊需求不能直接进入代码修改。它需要先进入 analyzing：读取上下文，理解需求，发现歧义，补充遗漏，形成方案，并判断是否已经具备实现条件。
这种分离也和 spec-driven 的工作方式一致。spec 或需求描述并不会自动变成可执行任务，中间必须有一个分析阶段，把“需求写了什么”转化成“实现需要知道什么”。只有当这个阶段完成之后，实现才有清晰边界。
其次，plan 和 story 虽然都在 workflow 中流转，但它们关心的问题并不完全相同。plan 管理的是一条较大的工作线，它的完成更像是一个范围被确认关闭，所以 plan 层级需要面向整体完成的确认和归档。story 承载的是具体实现单元，它的完成更依赖审查和验证，所以 story 层级需要 in-review 这样的状态，让实现结果先进入人工审查，而不是由 Agent 自己宣布完成。
除了正常路径，真实项目还需要异常状态。工作可能因为优先级变化被 paused，也可能因为需求变化变成 not-required，已经完成的内容也可能因为新的问题重新进入 analyzing。这些状态看起来像边角情况，但它们恰恰说明 workflow 面对的是真实工程，而不是一条永远顺利的流水线。
有了 status，plan 和 story 才能被暂停、恢复、转交、协作和管理。一个人或另一个 Agent 接手时，不需要只依赖聊天记录猜测当前进展，而是可以先看到工作处在什么阶段，再继续读取对应的上下文和产物。
更进一步，status 不应该只有当前值，还应该有历史。当前状态回答的是“现在在哪里”，status history 回答的是“怎么走到这里”。它让 workflow 具备时间维度：什么时候开始分析，什么时候进入实现，什么时候暂停，什么时候返工，什么时候完成。这些记录让协作、追踪和复盘变得可能。
因此，status 的意义不是给任务贴标签，而是让工作进入正确的阶段。它告诉 Agent 现在应该分析、实现、等待审查、暂停，还是回到前一步重新理解问题。
Human in the Loop：权限与责任必须对等
在 AI Harness 中，人并不是只出现在某几个审批点上。人在所有阶段都应该参与：选择下一项工作，调整优先级，补充上下文，打断错误方向，要求重新分析，确认实现结果，决定是否暂停或放弃。
这里有一个基本原则：权限和职责必须对等。
最终为系统负责的是人，所以人在 workflow 中必须拥有最高权限。这个最高权限主要体现在两个地方。
第一个地方，是关键状态转换上的 human gate。Agent 可以推进很多常规工作，但有些门不能由 Agent 自己打开。尤其是 analyzing → implementing 和 in-review → completed 这样的转换，必须由人确认。
analyzing → implementing 是方向门。这个阶段，人需要阅读 story 中沉淀下来的需求、增强点、验收标准、spec 相关内容和分析结果，判断需求是否已经足够清晰，边界是否明确，歧义是否消除，遗漏是否补齐，验收依据是否成立。只有这些问题被确认之后，Agent 才应该进入实现。
in-review → completed 是质量门。这个阶段，人需要阅读开发报告、review 报告和测试报告，并且必须直接验证功能行为。必要时也可以阅读代码，但不应该把人工验收变成以读代码为主的工作。对于单个 story，或者一组相关 stories，人需要像产品验收一样判断：实现是否符合预期，问题是否真的解决，风险是否可以接受，结果是否可以被关闭。
human gate 之所以必须硬，是因为它极度依赖人的经验、判断和责任。Agent 需要准备材料、总结风险、执行检查、修复问题，但不能替人完成最终授权。否则，系统就会变成由执行者自己批准自己的方向和质量。
第二个地方，是异常状态流转。happy path 中的常规推进可以由 Agent 协助完成，甚至在明确规则下自动推进。但异常流转一定应该由人做出决定：暂停一个 plan，放弃一个 story，把已完成内容拉回分析，把 review 中的问题退回实现，或者判断一个看起来需要做的任务其实已经不再需要。
异常流转往往意味着目标、优先级、范围或质量判断发生了变化。这些变化不只是执行问题，而是责任问题。Agent 可以发现异常、解释异常、建议下一步，但最终决定必须属于人。
因此，Human in the Loop 不是为了让人机械地点确认按钮，也不是为了把 AI 的效率拖慢。它是为了让 workflow 中的权限、责任和判断保持一致：Agent 负责执行和准备，人负责方向、授权和最终判断。
回到 Harness：Workflow 是 AI 进入工程过程的骨架
回到最开始的问题：为什么不能让 Agent 在模糊需求之后直接开始实现？
不是因为 Agent 不够强，也不是因为 workflow 要把 AI 的能力束缚住。恰恰相反，越强的能力，越需要被放进一个能够确认目标、校准方向、管理范围、沉淀上下文、验证结果的工程过程中。
plan 让长期目标获得边界，story 让目标被拆成可执行、可审查、可验证的工程单元，status 让每个单元知道自己处在什么阶段，Human in the Loop 则让方向、授权和最终判断始终落在人身上。它们合在一起，才构成了 AI Harness 中真正有用的 workflow。
Workflow 不是枷锁，而是方向盘、仪表盘和刹车系统。它让 Agent 知道应该朝哪里走，也让人能够判断它是否偏离了方向；它让 AI 的速度成为助力，而不是在错误路径上不断加速。
因此，Harness Engineering 中的 workflow，并不是传统流程管理在 AI 时代的简单复刻。它是把软件工程长期积累下来的拆解、流转、确认和验证机制，重新组织成一套适合 AI Agent 参与真实开发的执行结构。
如果说 Harness 的目标，是让 AI 在真实工程约束下做正确的事，那么 workflow 就是这件事最基础的骨架。
