总体架构：AI 执行引擎与人类验收层

第七章的追问#

第七章让我们看到了 Harness 角色体系的完整图景：Planner（设计规划）、Generator（实现者）、Evaluator（验收方）三种角色家族，每个家族内部有多种专业化变体，通过"交响乐团模型"协作运转。但这个图景回答的是"谁来做"，没有回答"在哪里做"——这些角色运行在什么样的系统里？它们如何被调度？人类如何与它们交互？

更重要的是，前七章的理论框架是抽象的。我们讨论了验收驱动模型、上下文交接、监控反馈回路，但没有讨论这些机制需要什么样的技术载体。一个验收驱动模型需要状态机来追踪验收结果；一个上下文交接需要消息队列来传递文件；一个监控反馈回路需要可观测性平台来收集信号。

抽象的框架需要具象的系统来承载。 第八章的目标就是设计这个系统——Harness 的总体架构。它不是一份详细的技术白皮书（那属于后续各阶段章节），而是一份工程蓝图：定义系统由哪些核心组件构成、这些组件如何协作、AI 何时介入、人类如何管控、DevOps 工具如何整合、以及架构如何演进。

8.2 核心服务设计#

8.2.1 三大核心组件#

Harness 系统由三个核心组件构成：

Lifecycle 服务（项目管理服务）：项目的"指挥官"。它内置项目生命周期状态机，推动项目从需求阶段到上线并进入多轮迭代。它决定什么时候调用 AI、什么时候需要人类审批、什么时候推进到下一个阶段。

AI 服务（AI 能力服务）：系统的"智能大脑"。它封装了 Planner（设计规划）、Generator（实现者）、Evaluator（验收方）三种 AI 能力，对外暴露为统一的能力接口。但更重要的是，它遵循"不要为了 AI 而 AI"的原则——成熟机制优先，AI 按需扩展。

DevOps 平台：系统的"执行臂膀"。它不重复造轮子，而是整合成熟的开源产品：GitLab 管理代码、GitLab CI 执行构建、ArgoCD 处理部署、Nexus 存储制品、SkyWalking 提供可观测性、RocketMQ 处理异步消息。

┌─────────────────────────────────────────────────────────────┐
│                    Harness 总体架构                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ┌─────────────────┐    gRPC    ┌─────────────────────────┐│
│  │ Lifecycle 服务   │◄──────────►│       AI 服务           ││
│  │    (Java)       │            │      (Python)           ││
│  │                 │            │  ┌───────────────────┐  ││
│  │ • 状态机        │            │  │     MCP 网关      │  ││
│  │ • 流程编排      │            │  │                   │  ││
│  │ • 审查调度      │            │  │ • 协议转换        │  ││
│  │ • 领域拆分      │            │  │ • 认证管理        │  ││
│  │   (需求/开发/   │            │  │ • 审计日志        │  ││
│  │    部署/评审)   │            │  │ • 限流熔断        │  ││
│  └─────────────────┘            │  └───────────────────┘  ││
│         │ Webhook              │  • Planner              ││
│         │ GitHook              │  • Generator            ││
│         ▼                      │  • Evaluator            ││
│  ┌─────────────────────────────────────────────────────┐  ││
│  │                   DevOps 平台                        │  ││
│  │  GitLab  GitLab CI  ArgoCD  Nexus  SkyWalking       │  ││
│  │  RocketMQ  [未来: OTel + Prometheus + Grafana]      │  ││
│  └─────────────────────────────────────────────────────┘  ││
│                                                             │
└─────────────────────────────────────────────────────────────┘

8.2.2 为什么拆成这三部分#

服务拆分的核心原则是职责边界清晰、内聚性高、耦合度低。

Lifecycle 服务独立：项目管理是一个独立的业务域。它需要维护状态机、处理审批流、管理项目生命周期——这些和 AI 能力无关。把 Lifecycle 独立出来，即使未来替换 AI 引擎（比如从 Claude 切换到 GPT），Lifecycle 服务也不需要改动。

AI 服务统一：Planner、Generator、Evaluator 虽然角色不同，但它们共享同一个核心能力——大语言模型的上下文理解和生成能力。把它们放在同一个服务里，可以避免重复的模型初始化、上下文管理、Token 消耗。更重要的是，很多任务需要多个角色协作完成（比如 Planner 生成的 Design 需要 Generator 理解后才能执行），同进程通信比跨服务调用快得多。

DevOps 平台外置：代码管理、CI/CD、部署、监控都是已经高度成熟的领域。GitLab 的代码审查功能、ArgoCD 的 GitOps 能力、SkyWalking 的链路追踪——这些不是 Harness 的差异化竞争力，而是基础设施。Harness 的核心创新不在于重新发明这些工具，而在于用 AI 和状态机把它们串联成一个智能工作流。

8.2.3 “不要为了 AI 而 AI"的设计哲学#

Harness 系统有一条铁律：成熟机制优先，AI 按需扩展。

什么是"成熟机制”？Webhook 通知构建完成、gRPC 传递结构化数据、规则引擎判断分支是否可合并、模板引擎生成标准接口文档——这些不需要 AI，用传统技术更可靠、更快、更可控。

什么是"需要 AI"的场景？需求分析（理解模糊的人类意图）、架构设计（在约束条件下做权衡）、Bug 根因分析（从日志和代码中推理）、代码审查（理解业务逻辑判断实现是否正确）——这些需要理解上下文、做判断、做权衡，才是 AI 的用武之地。

这个原则体现在架构的每一处：Lifecycle 服务用 Java 编写，因为状态机和流程引擎是工业化成熟的技术；AI 服务用 Python 编写，因为 Python 有最丰富的 LLM SDK 生态。通信优先用 gRPC 和 Webhook，只有在需要 AI 理解上下文时才调用 AI 服务。

8.2.4 技术栈选型#

服务	语言	理由
Lifecycle 服务	Java	工业化成熟，Spring 生态完善，适合构建企业级状态机和流程引擎
AI 服务	Python	生态丰富，Anthropic SDK、LangChain、MCP 等工具链成熟，易于接入 Claude API

8.2.5 通信机制分层#

Harness 的通信不是"一刀切"，而是按场景分层：

服务间通信：gRPC Lifecycle 服务与 AI 服务之间的调用使用 gRPC。原因很直接：结构化数据（状态、审批结果、任务描述）用 Protocol Buffer 序列化效率高，且 Java 和 Python 的 gRPC 支持都很成熟。

工具调用：MCP 协议 AI 服务通过 MCP（Model Context Protocol）网关与 DevOps 平台交互。MCP 是 Anthropic 推出的标准化协议，让 AI 能够安全、结构化地调用外部工具。MCP 网关作为 AI 服务内部的独立模块，负责协议转换、认证管理、审计日志和限流熔断。

事件通知：Webhook / GitHook DevOps 平台（GitLab CI 完成构建、ArgoCD 完成部署）通过 Webhook 回调 Lifecycle 服务，通知状态变更。这是行业标准做法，无需额外发明。

异步任务：RocketMQ 耗时的 AI 生成任务、批量测试执行、大规模日志分析等通过 RocketMQ 异步处理，削峰填谷，避免阻塞主流程。

8.2.6 MCP 网关：统一的工具接入层#

MCP 网关是 Harness 架构的一个关键设计。它回答了这个问题：当 AI 需要操作 GitLab、查询监控指标、触发部署时，如何通过统一的协议完成？

MCP 网关的职责边界：

协议转换：将 MCP 协议转换为各 DevOps 工具的原生 API
认证管理：统一管理各工具的访问令牌和权限
审计日志：记录 AI 对工具的所有操作，可追溯、可审查
限流熔断：防止 AI 在异常状态下对工具发起过多请求

为什么不用 Spring AI？ Lifecycle 服务是 Java 写的，但 MCP 网关统一放在 Python 的 AI 服务中。原因有三：一是 MCP 的 Python 生态更成熟（Anthropic 官方 SDK 优先支持 Python）；二是避免 Java/Python 两套 MCP 实现，降低维护成本；三是工具对接集中管理，便于版本升级和故障隔离。

Lifecycle 服务需要调用工具时，通过 HTTP/gRPC 调用 MCP 网关，无需关心底层协议。简单的 Webhook 回调和状态查询则直接使用 HTTP client，无需经过 MCP 网关。

8.3 项目生命周期状态机#

8.3.1 状态机核心流程#

Harness 的项目生命周期是一个状态机。项目由人类发起，经过一系列阶段推进，最终上线并进入评审演进的循环。

人类立项 → 需求准入审查 → 设计/开发/测试迭代 → 功能提交审查 → 生产准入审查 → 部署上线 → 运维监控 → 评审演进
    ↑                                                                                                │
    └────────────────────────────────────────────────────────────────────────────────────────────────┘

这个状态机不是线性的——在"设计/开发/测试迭代"阶段，项目可能在"设计→开发→测试→修复"的循环中多次迭代。Lifecycle 服务的职责就是管理这个状态流转：什么时候该推进、什么时候该回退、什么时候需要人类介入。

8.3.2 三个审查点#

状态机中有三个关键审查点，每个审查点决定项目能否进入下一阶段：

审查点一：需求准入

触发时机：人类提交需求后，项目正式启动前
审核模式：AI + 人工共同审核
审核内容：需求是否清晰、是否可验收、是否与现有系统冲突、是否存在合规风险
可配置性：系统完善后可配置为"仅 AI 审核"。因为需求准入的标准相对明确（有验收标准、无歧义、技术可行），当 AI 的判断准确率足够高时，可以取消人工审核

审查点二：功能提交

触发时机：开发完成，进入多轮测试前
审核模式：AI + 人工共同审核
审核内容：代码是否通过静态检查、单元测试是否通过、是否满足验收标准、是否存在已知缺陷
可配置性：系统完善后可配置为"仅 AI 审核"。功能提交的验收标准（测试通过、代码规范、无已知缺陷）是明确的，AI 可以自动判断

审查点三：生产准入

触发时机：测试通过，准备部署到生产环境前
审核模式：始终人工 + AI 共同审核，不可配置为纯 AI
审核内容：发布计划是否完备、回滚方案是否就绪、监控告警是否配置、团队是否准备好值班、是否存在未解决的 P0/P1 缺陷
不可配置的原因：生产环境的影响范围最大，一旦出现问题可能导致业务损失。即使 AI 的判断准确率再高，生产准入也必须保留人类决策权——这是 Harness 的安全底线

8.3.3 审查点的可配置性设计#

为什么需求准入和功能提交可以交给 AI，而生产准入不行？

核心差异在于决策的不可逆性和影响范围：

审查点	决策不可逆性	影响范围	可配置性
需求准入	低（需求可修改）	单个功能	可配置为仅 AI
功能提交	中（代码可回退）	单个版本	可配置为仅 AI
生产准入	高（影响线上用户）	全量用户	不可配置

需求准入和功能提交的决策即使出错，修复成本也相对有限。需求理解错了可以重新澄清，代码有 bug 可以修复后重新提交。但生产准入一旦出错，可能影响全量用户，修复成本极高。因此生产准入必须保留人类决策权。

这种设计体现了 Harness 的渐进式自动化理念：从人机协作开始，在低风险环节逐步扩大 AI 自主权，但在高风险环节永远保留人类决策权。

8.3.4 Lifecycle 服务的领域拆分#

为了避免 Lifecycle 服务变成"上帝服务"，即使初期部署为单一进程，代码层面也按领域拆分模块：

需求域：需求准入、需求变更管理、需求追溯
开发域：功能提交、多轮测试迭代、代码审查调度
部署域：生产准入、部署上线、运维监控
评审域：评审演进、知识沉淀、经验反馈

每个领域有独立的模块边界，有自己的状态模型和业务规则。当系统发展到需要拆分为独立服务时，这些模块可以直接拆出去，而不会影响其他领域。

8.3.5 Lifecycle 的"指挥者"定位#

Lifecycle 服务在 Harness 架构中的角色是指挥者，不是执行者。它不直接生成代码、不直接运行测试、不直接部署应用。它的核心职责是：

状态管理：维护项目当前处于哪个阶段、哪些任务已完成、哪些决策待做出
调度决策：根据状态和规则，决定什么时候调用 AI 服务、什么时候调用 DevOps 平台、什么时候需要人类介入
结果收集：接收 AI 服务的生成结果、接收 DevOps 平台的构建/部署/测试结果、接收人类的审批决策
状态推进：根据收集到的结果，推进状态机到下一个阶段，或触发回退/重试

这个"指挥者"定位的关键在于Lifecycle 服务只负责"什么时候做什么"，不负责"怎么做"。“怎么做"交给 AI 服务（AI 负责生成和判断）和 DevOps 平台（工具负责执行）。

8.4 AI 服务的职责与边界#

8.4.1 “能力提供者"定位#

AI 服务在 Harness 架构中不是"决策者”，而是**“能力提供者”。它不决定项目什么时候推进、什么时候回退——这是 Lifecycle 服务的职责。它提供的是专业能力**：理解需求、生成设计、编写代码、验证质量。

这种定位避免了两个常见陷阱：

陷阱一：AI 越权决策 如果 AI 服务既负责生成代码又负责决定代码是否合格，就会陷入"既当运动员又当裁判员"的困境。Harness 通过角色分离来避免这个问题：Generator（实现者）生成代码，Evaluator（验收方）验证代码，Lifecycle（指挥者）根据 Evaluator 的结果决定下一步。

陷阱二：AI 万能论 如果认为 AI 可以处理一切任务，就会陷入"为了 AI 而 AI"的误区。Harness 明确区分了"需要 AI 的任务"和"不需要 AI 的任务”——前者交给 AI 服务，后者用规则引擎、模板化工具或传统算法解决。

8.4.2 内部模块：Planner、Generator、Evaluator#

AI 服务内部包含三个逻辑模块，对应 Harness 的三角色体系：

Planner（设计规划）：负责"做什么"。接收 Lifecycle 服务传递的任务描述，输出可执行的设计方案（Design）。包括需求分析、架构规划、接口设计、任务拆解。

Generator（实现者）：负责"怎么做"。接收 Planner 产出的 Design，输出具体的代码、配置、文档。包括代码生成、脚本编写、配置文件生成。

Evaluator（验收方）：负责"做得对不对"。接收 Generator 产出的实现，对照验收标准进行验证。包括代码审查、测试用例生成与执行、性能评估、安全检查。

这三个模块不是物理隔离的独立服务，而是 AI 服务内部的逻辑分层。它们共享同一个 LLM 上下文，可以在同一次推理中协作（比如 Planner 生成的 Design 直接作为 Generator 的输入，无需跨服务序列化）。

8.4.3 AI 介入决策树#

Harness 的核心设计原则之一是"不要为了 AI 而 AI"。那么，什么任务该用 AI、什么任务用规则引擎、什么任务必须人类主导？

任务进入系统
    │
    ├─ 结构化、重复性高、有明确验收标准？
    │       ├─ 是 → 规则引擎 / 模板化工具（不用 AI）
    │       │       例如：生成标准 CRUD 接口、格式化代码、检查代码风格
    │       │
    │       └─ 否 → 需要理解上下文、做判断、做权衡？
    │               ├─ 是 → AI 介入
    │               │       例如：需求分析、架构设计、Bug 根因分析、代码审查
    │               │
    │               └─ 否 → 人类主导
    │                       例如：战略决策、创意探索、伦理判断、应急处理
    │
    └─ 风险等级如何？
            ├─ 低风险 → AI 全自动执行
            ├─ 中风险 → AI 生成 + 人类确认
            └─ 高风险 → AI 辅助 + 人类决策

第一维度：任务性质

结构化任务（有明确输入输出、可穷举规则）→ 规则引擎
需要理解上下文的任务（涉及语义理解、业务逻辑判断）→ AI
涉及价值判断的任务（战略取舍、伦理权衡）→ 人类

第二维度：风险等级 即使是需要 AI 的任务，也要根据风险等级决定人类的参与程度：

低风险（内部工具、非核心功能）→ AI 全自动
中风险（核心功能、用户可见）→ AI 生成，人类确认后执行
高风险（支付系统、安全敏感）→ AI 辅助分析，人类做最终决策

8.4.4 场景示例#

场景	任务性质	风险等级	处理方式
生成标准 RESTful API 接口	结构化	低	规则引擎 / 模板生成
根据 PR 描述生成单元测试	需理解上下文	中	AI 生成 + 人类确认
分析生产环境故障根因	需理解上下文	高	AI 辅助 + 人类决策
判断新功能是否符合公司战略	价值判断	极高	人类主导
格式化代码、检查代码风格	结构化	低	规则引擎（如 Checkstyle）
设计微服务拆分方案	需理解上下文	高	AI 辅助 + 人类决策
重构遗留代码	需理解上下文	中	AI 生成 + 人类确认

这个矩阵体现了 Harness 的务实态度：AI 不是万能的，也不是唯一的。它是在合适的场景下使用的合适工具。

8.5 人类观测与干预机制#

8.5.1 观测面：看板、审计日志、迭代历史#

人类验收层的第一个职责是观测——了解系统正在做什么、已经做了什么、结果如何。

项目看板：展示所有项目的当前状态。每个项目卡片显示：当前阶段、待决策项、最近一轮的 AI 产出摘要、最近的审查结果。看板是人类了解全局的窗口，类似于传统项目管理工具中的"仪表盘"，但多了 AI 产出的实时展示。

审计日志：记录 AI 和系统的所有关键操作。谁（或哪个 AI 角色）在什么时候做了什么、结果是什么、为什么这么做。审计日志不是调试日志，而是决策轨迹——它回答"这个决策是怎么做出来的"这个问题。

迭代历史：展示项目的完整演进轨迹。从最初的模糊需求，到第一轮 Design，到第一次代码生成，到第一次测试失败，到修复后的第二次尝试——所有版本、所有决策、所有反馈都被记录。迭代历史让人类能够理解项目的"成长过程"，而不是只看最终结果。

8.5.2 干预面：中断、放行、回退、参数调整#

人类验收层的第二个职责是干预——在关键时刻改变系统的行为。

中断（Halt）：当人类发现 AI 的产出存在严重问题时，可以中断当前流程，阻止状态机推进到下一阶段。中断后，Lifecycle 服务暂停调度，等待人类给出新的指令。

放行（Approve）：当人类确认 AI 的产出满足要求时，可以放行当前阶段，允许状态机推进到下一阶段。放行是 Harness 闭环运转的关键信号——没有人类的放行（或 AI 的自动判断），流程不会前进。

回退（Rollback）：当人类发现已经放行的决策存在问题时，可以触发回退，将状态机退回到之前的阶段。回退不是简单的"撤销"，而是带着新的上下文重新执行——比如回退到设计阶段时，人类可以补充新的约束条件，让 Planner 重新生成 Design。

参数调整（Tune）：人类可以调整 AI 的行为参数。比如调整 Planner 的"创造性"（保守 vs 激进）、调整 Generator 的"代码风格"（简洁 vs 详尽）、调整 Evaluator 的"严格程度"（宽松 vs 严苛）。这些参数不是随意设置的，而是基于项目的特点和团队的习惯。

8.5.3 三个审查点中人类的角色#

在不同的审查点，人类的参与程度不同：

需求准入和功能提交：初期需要人类参与审核，因为 AI 的判断标准可能和团队的实际要求存在偏差。但随着系统运行，AI 会逐渐学习团队的偏好和项目的特点，判断准确率不断提升。当准确率达到团队可接受的水平时，这些审查点可以配置为"仅 AI 审核"——人类从"审核者"转变为"抽查者"，只在异常情况下介入。

生产准入：无论系统多么成熟，生产准入始终需要人类参与。这不是因为 AI 不够聪明，而是因为生产环境的影响不可逆。即使 AI 的判断准确率达到了 99.9%，那 0.1% 的误判在线上环境的影响也可能是灾难性的。生产准入是人类守护的最后一道防线。

8.5.4 干预衰减机制#

“干预衰减"是 Harness 架构的一个独特设计：随着系统稳定性的提升，逐步减少非关键中断点，推进全面自动化。

初始阶段，Harness 在每个审查点都暂停等待人类审批。这是为了建立信任——让人类看到 AI 的决策过程、验证 AI 的判断质量、校准 AI 的行为参数。

当系统运行一段时间后，团队对 AI 的判断建立了信心，可以逐步取消低风险的中断点：

需求准入：从"每次暂停"变为"AI 自动判断，异常时通知”
功能提交：从"每次暂停"变为"AI 自动判断，异常时通知"
生产准入：始终保持"每次暂停"

这种渐进式衰减不是"放任不管"，而是基于数据的信任积累。Lifecycle 服务会记录每个审查点的 AI 判断准确率、人类干预频率、干预后发现的误判率。当这些数据表明 AI 已经可靠时，才允许取消对应的中断点。

8.5.5 生产准入不可配置为纯 AI 的安全原则#

生产准入不可配置为纯 AI，这是 Harness 架构的一条不可违背的安全原则。它体现了 Harness 的核心设计哲学：

AI 是助手，不是主人。 AI 可以分析、建议、执行，但涉及影响全量用户的关键决策，必须由人类做出。这不是对 AI 的不信任，而是对用户的责任——用户把业务托付给我们，我们有义务确保关键决策经过人类的审慎判断。

这个原则被硬编码在 Lifecycle 服务的核心逻辑中，不是可配置项。即使未来的 AI 能力超越了人类，生产准入也必须保留人类决策权。这是 Harness 对"安全"的承诺。

8.6 DevOps 平台集成#

8.6.1 “被调用"定位#

DevOps 平台在 Harness 架构中的定位是被调用者，不是主动参与者。它不感知 Harness 的存在，不主动与 AI 服务通信，不做智能决策。它只是执行 Lifecycle 服务下发的指令，并通过 Webhook 返回执行结果。

这个定位的重要性在于解耦：DevOps 平台可以独立升级、替换、维护，而不影响 Harness 的核心逻辑。Lifecycle 服务通过标准化的 API/Webhook 与 DevOps 平台交互，即使把 GitLab 换成 Gitea、把 ArgoCD 换成 Flux，Lifecycle 服务的核心逻辑也不需要改动——只需要调整 MCP 网关中的适配器。

8.6.2 MVP 选型#

Harness 的 DevOps 平台采用成熟开源产品组合：

功能	选型	理由	开源协议
代码管理	GitLab	API 完善，生态成熟，内置代码审查、Issue 追踪	需研读
CI	GitLab CI	与 GitLab 天然集成，配置即代码（`.gitlab-ci.yml`）	需研读
部署	ArgoCD	GitOps 模式成熟，声明式配置，支持多集群	需研读
制品库	Nexus	支持 Maven/npm/Docker 等多种制品，权限管理完善	需研读
可观测性（短期）	SkyWalking	APM 能力强，自动埋点，部署简单	需研读
可观测性（长期）	OTel + Prometheus + Grafana	云原生标准，可扩展，社区活跃	需研读
消息队列	RocketMQ	事务消息支持强，顺序消息，业务功能完善	需研读

⚠️ 开源协议审查是所有选型的前提。 在商业环境中使用开源产品，必须研读其开源协议（如 GPL、Apache 2.0、MIT 等），评估商业使用风险。某些协议可能要求衍生作品也必须开源，或限制商业用途。选型表中标注"需研读"的组件，必须在正式使用前完成协议审查。对于高风险组件（如 Nexus），应准备替代方案（如 Harbor）。

8.6.3 集成模式#

Lifecycle 服务与 DevOps 平台的集成遵循"命令-结果"模式：

Lifecycle 下发指令：“触发 GitLab CI 构建分支 feature-X”、“查询 ArgoCD 应用状态”、“获取 SkyWalking 最近一小时的错误率”
DevOps 平台执行：GitLab CI 开始构建、ArgoCD 返回应用状态、SkyWalking 返回监控数据
DevOps 平台回调结果：通过 Webhook 通知 Lifecycle 服务"构建完成/失败”、通过 API 返回查询结果
Lifecycle 更新状态机：根据结果推进到下一阶段，或触发重试/回退

这个模式的优点是简单：DevOps 平台不需要知道 Harness 的存在，它只做自己擅长的事情。Harness 也不深入 DevOps 平台的内部实现，它只通过标准接口调用。

8.6.4 开源协议审查原则#

Harness 的架构设计将开源协议合规作为必要条件，不是可选项：

选型前审查：任何开源组件进入技术栈前，必须完成协议研读和风险评估
建立审查清单：记录每个组件的协议类型、商业使用限制、衍生作品要求
准备替代方案：对高风险组件（如 GPL 协议），准备功能等价的替代方案
定期复审：开源协议的解读可能随法律环境变化，定期复审技术栈的合规性

这个原则不是因为 Harness 对开源有敌意，恰恰相反——Harness 高度依赖开源生态。但依赖不等于盲目信任，合规使用是对开源社区和自身商业利益的双重保护。

8.6.5 “不重复造轮子"原则#

Harness 的核心创新不在于重新发明 DevOps 工具，而在于用 AI 和状态机把现有工具链串联成一个智能工作流。

GitLab 的代码审查功能已经很强大了，Harness 不需要重新写一套代码审查系统。Harness 做的是：让 AI 自动分析 PR 的变更，生成审查意见，然后把这些意见提交到 GitLab 的审查流程中。人类审查员可以在 GitLab 的界面上看到 AI 的审查意见，结合自己的判断做出决策。

ArgoCD 的 GitOps 部署已经很成熟了，Harness 不需要重新写一套部署系统。Harness 做的是：让 Lifecycle 服务根据生产准入审查的结果，自动触发 ArgoCD 的同步操作，并在部署完成后通过 SkyWalking 验证系统的健康状态。

Harness 不是替代 DevOps 工具，而是给 DevOps 工具装上"大脑"和"神经系统”。 大脑是 AI 服务（理解、判断、生成），神经系统是 Lifecycle 服务（调度、协调、状态管理），DevOps 工具是四肢（执行具体的工程任务）。

8.7 架构演进路线：短期 vs 长期#

8.7.1 短期架构（MVP）#

短期架构的目标是快速闭环，验证核心假设。

核心策略：

选用成熟开源产品，降低建设成本
最小可用架构，只保留核心能力
三个审查点全部采用"AI + 人工"模式，建立信任
重点验证：状态机能否正确推进、AI 能否生成可用产出、人类是否愿意使用

技术选型：

Lifecycle 服务：Java + Spring Boot，内置固定流程的状态机
AI 服务：Python + FastAPI，接入 Claude API，Planner/Generator/Evaluator 三模块同进程
MCP 网关：Python，支持 GitLab/ArgoCD/SkyWalking 的基础适配器
DevOps 平台：GitLab + GitLab CI + ArgoCD + Nexus + SkyWalking + RocketMQ
通信：gRPC（服务间）+ Webhook（事件通知）+ MCP（工具调用）

里程碑：

第 1 个月：Lifecycle 服务骨架 + GitLab 集成，实现"提交代码 → 触发 CI → 返回结果"的基础闭环
第 3 个月：AI 服务接入，实现"生成代码 → 人类审查 → 合并"的半自动流程
第 6 个月：三个审查点全部运转，完成第一个真实项目的全生命周期交付

8.7.2 长期架构#

长期架构的目标是自主掌控，追求体验升级，模块衔接顺滑。

核心策略：

核心服务（Lifecycle、AI）自研深度优化，形成差异化竞争力
DevOps 组件按需替换，从"用开源"走向"深度定制"
审查点逐步自动化，从"人机协作"走向"智能自治"
架构模块化，支持灵活扩展和定制化

技术演进方向：

Lifecycle 服务：从固定流程状态机演进为支持自定义流程的编排引擎，引入可视化流程设计器
AI 服务：从调用 Claude API 演进为支持多模型切换（Claude/GPT/自研模型），引入本地知识库和 RAG
MCP 网关：从支持基础工具演进为支持企业自定义工具的标准化接入平台
可观测性：从 SkyWalking 演进为 OTel + Prometheus + Grafana 的标准化可观测性栈
消息队列：从 RocketMQ 演进为支持事件溯源的分布式消息总线

里程碑：

第 12 个月：需求准入和功能提交审查点可配置为"仅 AI"，人工参与减少 50%
第 18 个月：支持自定义流程，团队可以根据项目特点定义自己的审查规则
第 24 个月：AI 服务的生成准确率达到 95% 以上，人工干预频率降低 80%

8.7.3 渐进演进策略#

从短期到长期的演进不是"推倒重来"，而是渐进式升级。每个阶段的改进都建立在上一阶段的基础上：

保留接口兼容：MCP 网关的接口设计兼容未来扩展，新增工具适配器不影响已有适配器
数据迁移优先：状态机的历史数据、AI 的迭代记录、审计日志——这些数据是 Harness 的核心资产，迁移时优先保证数据完整性
双轨并行：新功能上线时，旧功能保持运行一段时间（灰度发布），确认新功能稳定后再下线旧功能
回退能力：每次架构升级都保留回退方案。如果新的 AI 模型表现不佳，可以一键切换回 Claude API
自举演进（Harness 迭代 Harness）：Harness 的最终目标是用 Harness 来迭代 Harness。当 Harness 系统足够成熟后，它应该能够管理自己的开发流程：Planner 分析 Harness 的架构演进需求，Generator 生成新模块的代码，Evaluator 验证变更的正确性，Lifecycle 推动整个迭代流程。这不是一个遥远的愿景——当 Harness 在第 24 个月达到高成熟度后，团队可以用 Harness 来管理 Harness 自身的下一版本开发。这种"自举"能力是 Harness 架构设计的终极验证：如果 Harness 不能管理自己的开发，又如何说服用户它能管理用户的项目？

8.7.4 演进里程碑#

时间	里程碑	关键变化
1 月	基础闭环	Lifecycle + GitLab CI，人工触发 CI
3 月	AI 介入	Generator 生成代码，人类审查合并
6 月	全生命周期	三个审查点运转，首个项目交付
12 月	部分自动化	需求准入/功能提交可配置为仅 AI
18 月	自定义流程	支持团队自定义审查规则
24 月	高成熟度	AI 准确率 95%+，人工干预降低 80%

8.8 本章小结#

让我们回顾本章的核心脉络。

三大核心组件：Harness 系统由 Lifecycle 服务（Java）、AI 服务（Python）和 DevOps 平台（成熟开源产品）组成。Lifecycle 是指挥者，AI 是能力提供者，DevOps 是执行者。

项目生命周期状态机：人类立项后，项目经历需求准入、设计/开发/测试迭代、功能提交、生产准入、部署上线、运维监控、评审演进。三个审查点中，需求准入和功能提交可配置为仅 AI 审核，生产准入始终需要人工参与。

AI 按需扩展：“不要为了 AI 而 AI”。结构化任务用规则引擎，需要理解上下文的任务用 AI，涉及价值判断的任务由人类主导。低风险任务 AI 全自动，中风险 AI+人类确认，高风险 AI 辅助+人类决策。

人类观测与干预：看板提供全局视野，审计日志记录决策轨迹，迭代历史展示演进过程。人类可以中断、放行、回退、调整参数。随着系统稳定，非关键中断点逐步取消，但生产准入永远保留人工决策权。

DevOps 平台集成：选用成熟开源产品（GitLab、ArgoCD、Nexus、SkyWalking、RocketMQ），通过 MCP 网关统一接入。Harness 不重复造轮子，而是给现有工具链装上"大脑"和"神经系统"。

架构演进：短期快速闭环验证假设，长期自主掌控追求体验升级。演进是渐进的，保留接口兼容、数据迁移优先、双轨并行、回退能力。

至此，Harness 的总体架构蓝图已经清晰。下篇"落地实践路径"即将展开——从需求阶段开始，我们将逐一深入每个阶段的具体实现。第九章，我们将进入 Harness 工作流的起点：需求阶段——AI 如何主导需求工程，把模糊的人类意图转化为可执行的技术方案。

本章内容说明

论文原意：Harness 三角色（Planner / Generator / Evaluator）体系、验收驱动模型、闭环反馈回路源自 Anthropic《Harness Design for Long-Running Application Development》。
作者分析：三大核心组件的服务拆分逻辑、项目生命周期状态机设计、三个审查点的可配置性策略、AI 介入决策树、干预衰减机制，为本文作者基于 Harness 框架与软件工程实践的分析推导。
工程扩展：MCP 网关的统一工具接入层设计、DevOps 平台的具体选型（GitLab / ArgoCD / SkyWalking 等）、Java/Python 技术栈分工、开源协议审查原则、渐进式架构演进路线，是基于工程落地实践的推导，非论文原文。
虚构示例：本章中的"AI 介入决策树场景矩阵"、“MVP 里程碑规划"为构造的说明性场景，用于辅助理解架构设计原则。