Harness Agent 深度解析：从入门到企业级架构实践
一、引言：Agent 进入软件交付流水线
2026年6月30日，Harness 正式发布 Autonomous Worker Agents，标志着 AI Agent 从"聊天窗口辅助工具"正式进入企业级软件交付流水线。这不是一个简单的产品发布——它代表了一种架构范式的转变：AI 不再只是"建议者"，而是流水线中的一等公民，继承企业级治理、安全与审计机制。
过去两年，AI 编码助手主要停留在 IDE 补全和聊天问答层面，核心问题是"它能不能给出有用建议"。一旦 Agent 进入软件交付流水线，核心问题就变成了：
- 这个 Agent 以谁的身份行动？
- 它能读哪些上下文，不能读哪些？
- 它能调用哪些工具，是否有参数级权限限制？
- 它运行在什么沙箱里？能否访问外网和生产系统？
- 它的每一步是否可审计、可追踪、可回滚？
Harness Agent 正是为了解决这些问题而生。它不是一个独立产品，而是一个深度集成在 Harness 平台中的 AI 执行架构，覆盖 CI/CD、测试、安全、成本优化等全链路。
二、基础概念：什么是 Harness Agent
2.1 定义与定位
Harness Agent 是运行在 Harness 流水线内部的自治 AI 工作单元。它使用大语言模型（LLM）进行推理，通过 MCP 协议连接工具和数据源，在受控的治理边界内执行软件交付任务。
每个 Agent 由三部分组成：
Agent = Instructions（提示词指令） + Model Connector（模型连接器） + MCP Servers（可选工具层）
2.2 执行流程：从触发到 PR
所有 Harness Agent 遵循统一的执行生命周期，无论其具体任务是什么：
Trigger → Clone → Analyze → Execute → Review → No Auto-Merge
- 触发（Trigger）：通过 Harness UI、API 或自动事件（如 CI 失败、新 PR）触发
- 克隆（Clone）：使用配置的 SCM 凭证克隆目标仓库
- 分析（Analyze）：AI 分析代码库、日志或 PR diff 以理解上下文
- 执行（Execute）：执行核心任务——写代码、生成测试、创建修复
- 审查（Review）：变更推送到新分支，创建 PR 供人工审查
- 禁止自动合并（No Auto-Merge）：所有 Agent 生成的变更必须经过人工审批
关键原则：所有修改都通过 PR 流程，没有自动合并，每一次变更都经过团队的标准审查流程。
2.3 统计数据
根据 Harness 官方数据：
| 指标 | 数值 |
|---|---|
| 预置 Agent 数量 | 13+ |
| 支持的模型供应商 | OpenAI, Anthropic, Gemini, MCP |
| 治理控制 | RBAC, OPA, 审计日志 |
| 源代码管理 | GitHub, GitLab, Bitbucket, Harness Code |
三、Agent 分类：System Agents vs Custom Agents
Harness Agent 分为两类，来源不同但受相同的 RBAC 和策略控制。
3.1 System Agents（系统级 Agent）
由 Harness 官方提供和维护的 Agent 模板，覆盖代码质量、安全、生产力等场景。
| 特性 | 说明 |
|---|---|
| 来源 | Harness 官方提供和维护 |
| 可编辑性 | 不可直接编辑（可 Fork 后自定义） |
| 交付方式 | 自动加载为流水线模板 |
| 版本管理 | 随 Harness 发布管理 |
3.2 Custom Agents（自定义 Agent）
由团队自行构建的 Agent，拥有完全控制权。
| 特性 | 说明 |
|---|---|
| 来源 | 团队自行构建 |
| 可编辑性 | 完全可控 |
| 创建方式 | 通过 Agent 步骤 + 标准步骤创建 |
| 版本管理 | 通过 GitX 版本化管理 |
3.3 Fork System Agents
你可以 Fork 任何 System Agent 来创建完全可控的 Custom Agent。这允许你从经过验证的模板出发，调整提示词、目标语言、容器和审批流程。
text
System Agent (官方维护)
│
└── Fork → Custom Agent (团队控制)
│
├── 修改 prompts
├── 调整容器配置
├── 自定义审批流程
└── 通过 GitX 版本化管理
四、架构设计：四层模型
Harness Agent 的核心架构设计哲学是将 AI 的推理能力与工程体系的控制能力分离——模型负责生成候选动作，平台负责约束与验证。这一原则通过四层架构实现：
┌─────────────────────────────────────────────────┐
│ Governance（治理层） │
│ RBAC · Secrets · OPA Policy · Audit Logs │
├─────────────────────────────────────────────────┤
│ Tools（工具层） │
│ MCP Server · Harness APIs · Connector 边界 │
├─────────────────────────────────────────────────┤
│ Intelligence（智能层） │
│ BYOM · Knowledge Graph · 多模型接入 │
├─────────────────────────────────────────────────┤
│ Runtime（运行时） │
│ Pipeline Step · 触发机制 · 回滚 · 审批门禁 │
└─────────────────────────────────────────────────┘
4.1 Runtime（运行时层）
将 Agent 作为流水线的一等公民。Agent 继承流水线的所有运行时能力：
- 触发机制：事件驱动、定时触发、API 调用
- 并发策略：支持多 Agent 并行执行
- 失败回滚：执行失败时自动回滚
- 审批门禁：高风险操作强制人工审批
4.2 Intelligence（智能层）
支持多模型接入，通过 Knowledge Graph 提供服务、环境和配置等上下文事实，让模型基于真实系统状态推理，而非泛化建议。
Knowledge Graph 是 Harness 的核心差异化能力——它是一个连接了服务、流水线、部署、基础设施、事件和安全发现的知识图谱，Agent 可以基于这些真实数据做出决策，而不是凭空推理。
4.3 Tools（工具层）
整合 MCP Server 与 Harness APIs，通过 Connector 显式定义能力边界，防止权限滥用。
4.4 Governance（治理层）
利用 RBAC 和 Secrets 管理凭证，通过 OPA Policy 策略引擎与人工审批确保行动合规，并留存全链路审计日志。
五、核心设计模式：12 个可复用的企业级模式
Harness Agent 的架构可以提炼为 12 个可复用的设计模式，这些模式定义了企业级 Agent 的工程化标准：
| 模式名称 | 核心解决的问题 | 关键实践 |
|---|---|---|
| Pipeline-Native Agent | 运行时脱离 CI/CD 导致的治理割裂 | 将 Agent 封装为流水线 Step，复用控制面能力 |
| Context Inheritance | 缺少环境上下文导致决策偏差 | 自动注入 Repo、Service、Env 等流水线上下文 |
| Connector as Boundary | 模型权限不可控，token 散落 | 通过 Connector 定义能力边界，实现授权与轮换 |
| Model Connector Abstraction | 逻辑与特定模型供应商强绑定 | 模型作为插件接入，支持 BYOM 与 A/B 测试 |
| Template-as-Agent | Agent 配置难以复用与版本化 | 将 Agent 定义为 Step Template，支持 Fork 与分发 |
| Knowledge Graph Grounding | 建议泛化，缺乏企业真实依据 | 基于服务、流水线、历史记录构建事实层 |
| MCP Gateway Proxy | 开放协议扩大攻击面 | 通过网关代理进行 Allow-list 过滤与审计 |
| Policy-Gated Action | 执行有副作用操作的风险 | 关键动作必须通过 OPA 策略引擎校验 |
| Visible Artifact Only | 静默修改系统导致追责困难 | 强制输出 PR、评论或报告，确保留痕 |
| Human-in-the-Loop Gate | 高风险动作的全自动风险 | 分级管控，高风险操作强制触发人工审批 |
| Observable Reasoning | 黑盒决策阻碍信任建立 | 记录输入、输出及决策链路，支持合规审计 |
| Marketplace/Forkable | 重复造轮子导致质量参差 | 提供基线 Agent，允许团队自定义与共享 |
5.1 关键模式详解
Pipeline-Native Agent（流水线原生 Agent）：这是最核心的模式。Agent 不是独立运行的服务，而是作为流水线中的一个 Step 存在。这意味着 Agent 继承流水线的所有控制面能力——触发、并发、回滚、审批——而不是从零开始构建一套独立的安全体系。
Template-as-Agent（模板即 Agent）：每个 Agent 是一个标准的流水线模板，包含 YAML 定义、元数据、文档和图标。这种设计让 Agent 可版本化、可分发、可 Fork，就像管理代码一样管理 Agent。
Observable Reasoning（可观测推理）：记录 Agent 的完整决策链路——输入了什么提示词、模型返回了什么、调用了什么工具、输出了什么结果。这些信息用于合规审计和事后分析。
六、模板架构：如何定义 Agent
每个 Agent 模板是一个目录，包含以下文件：
templates/
├── my-agent/
│ ├── metadata.json # Agent 元数据（必需）
│ ├── pipeline.yaml # 流水线定义（必需）
│ ├── wiki.md # 用户文档（可选）
│ └── logo.svg # 图标（可选）
6.1 metadata.json
定义 Agent 的名称、描述和版本：
{
"name": "code-review",
"description": "Reviews code changes in pull requests and posts intelligent feedback",
"version": "1.0.0"
}
6.2 pipeline.yaml
定义 Agent 的流水线逻辑，包括阶段、步骤、容器和输入。每个 Agent 步骤的核心配置：
- step:
name: "AI Code Review Agent"
identifier: AI_Code_Review
type: Agent
spec:
agentId: code-review
agentVersion: 1.0.0
connectorRef: my_llm_connector
inputs:
repo: <+pipeline.variables.repoName>
branch: <+codebase.branch>
pr_number: <+trigger.prNumber>
6.3 自定义 Agent 的插件架构
对于需要深度自定义的 Agent，Harness 采用 Drone 插件架构——每个插件是一个 Go 二进制文件，运行在 Docker 容器中，通过环境变量接收配置。
my-agent-plugin/
├── main.go # CLI 入口，定义 flag 和参数
├── plugin.go # 核心业务逻辑，Plugin 结构体和 Exec() 方法
├── Dockerfile # 多阶段 Docker 构建
├── Makefile # 构建自动化
└── bin/ # 预编译的 Agent 二进制文件
核心代码示例（plugin.go）：
type Plugin struct {
WorkingDirectory string
AnthropicAPIKey string
DetailedLogging bool
}
func (p *Plugin) Exec() error {
// 1. 验证配置
// 2. 设置日志
// 3. 执行 Agent 二进制
cmd := exec.Command("/root/bin/ai-code-agent",
"--working-dir", p.WorkingDirectory,
)
cmd.Env = append(os.Environ(),
"ANTHROPIC_API_KEY="+p.AnthropicAPIKey,
)
return cmd.Run()
}
七、BYOM（Bring Your Own Model）：模型连接器
Harness Agent 支持自带模型，通过 AIModel 类型的 Connector 接入 LLM。
7.1 支持的模型供应商
| 供应商 | SaaS | 自托管 | MCP 支持 |
|---|---|---|---|
| OpenAI | ✅ | ✅（自定义端点） | ✅ |
| Anthropic | ✅ | ✅（自定义端点） | ✅ |
| Gemini | ✅ | ✅（自定义端点） | ✅ |
7.2 连接器配置示例
SaaS 模式：
connector:
name: Anthropic_SaaS
identifier: Anthropic_SaaS
type: AIModel
spec:
provider: Anthropic
credentials:
type: Token
tokenRef: account.anthropic_api_key
自托管模式：
connector:
name: Anthropic_SelfHosted
identifier: Anthropic_SelfHosted
type: AIModel
spec:
provider: Anthropic
credentials:
type: Token
tokenRef: account.anthropic_api_key
endpoint: https://anthropic.mycompany.internal/v1
7.3 Connector 作用域
AIModel 连接器遵循 Harness 的标准作用域规则——可以在 Account、Org 或 Project 级别定义，取决于团队的访问需求。创建后，连接器可以作为 llm 输入传递给任何 Agent。
八、企业级治理与安全控制
这是 Harness Agent 最核心的差异化能力。当 Agent 从"给出建议"升级为"执行动作"时，治理和安全成为决定企业能否信任 Agent 的关键。
8.1 六大安全控制
┌──────────────────────────────────────────────────────────────┐
│ Autonomous Worker Agents │
│ │
│ 1. Sandboxing（沙箱） │
│ └── 容器化隔离，只读文件系统，网络可配置 │
│ │
│ 2. Scoped Credentials（范围凭证） │
│ └── 临时令牌，权限取 Agent 与用户的交集，用完即销毁 │
│ │
│ 3. Policy Enforcement（策略执行） │
│ └── OPA 策略，覆盖运行态和配置态 │
│ │
│ 4. Audit Trails（审计追踪） │
│ └── 全链路溯源：谁触发、做了什么、结果如何 │
│ │
│ 5. Cost Tracking（成本追踪） │
│ └── 按执行、Agent、流水线维度展示 Token 消耗 │
│ │
│ 6. Chaining（链式编排） │
│ └── Agent 可组合为多步骤工作流，输出传递给下一个 │
└──────────────────────────────────────────────────────────────┘
沙箱（Sandboxing）
Agent 运行在容器化环境中：
- 非 root 执行（UID 65534，“nobody”）
- 文件系统除工作区外只读
- 网络访问按 Agent 配置：无限制、仅允许 MCP 服务器、或完全禁用
- 即使 Agent 生成了恶意命令，也没有地方发送数据
范围凭证（Scoped Credentials）
流水线触发时，Harness 生成一个临时范围令牌：
- 权限范围 = Agent 权限与触发用户 RBAC 的交集
- 执行完成后令牌自动删除
- TTL 作为安全失效机制
- MongoDB TTL 索引作为最终兜底
策略执行（Policy Enforcement）
OPA 策略——与 Harness 客户用于治理生产部署的同一框架——应用于 Agent：
- 运行态策略：Agent 执行时的行为约束
- 配置态策略：Agent 创建和修改时的校验
审计追踪（Audit Trails）
每次执行都记录在 Harness 审计日志中，包含完整溯源链：
- 谁/什么触发了 Agent
- 使用的模板版本
- 执行的每个动作
- 最终结果
提示词和推理链在持久化前经过脱敏处理：移除 Secrets 和 PII。
8.2 治理继承
Autonomous Worker Agents 的最大优势是治理继承。Agent 不需要学习一套全新的安全规则，而是直接继承企业已有的流水线治理机制：
- OPA 策略：用于生产部署的策略，同样约束 Agent
- RBAC：控制谁能推送到生产环境的权限，同样控制谁能触发 Agent
- 审批门禁：Agent 的修复在生产环境生效前，需要经过与正式发布相同的审批流程
8.3 动作分级
企业级 Agent 落地时，所有动作应分为四个级别，每个级别匹配不同的控制策略：
| 级别 | 动作类型 | 控制策略 |
|---|---|---|
| Read | 读取代码、日志、配置 | 仅需审计日志 |
| Suggest | 提出建议、生成报告 | 输出为评论/报告 |
| Prepare | 创建分支、修改代码 | 强制 PR 流程 |
| Execute | 合并、部署、修改生产环境 | 人工审批 + OPA 策略 |
九、Agent DLC：全生命周期管理
2026年7月，Harness 进一步发布了 Agent DLC（Developer Lifecycle Control），将 AI Agent 的开发、部署、配置和安全纳入了完整的生命周期管理。
9.1 五大产品能力
| 产品 | 功能 |
|---|---|
| AI Evals | 构建评估数据集、评分函数和自动化质量门禁 |
| Agent Deployments | 将金丝雀发布、人工审批、OPA 控制扩展到 Agent 环境 |
| AI Configs | 解耦提示词工程和模型选择与应用部署 |
| AI Asset Catalog | 扫描代码仓库，索引每个活跃 Agent、技能和插件 |
| AgentTrace | 捕获多轮会话的逐步执行路径、工具调用和模型决策 |
9.2 安全工具
- 原始扫描：在部署前发现技能配置错误
- AI BOM：自动生成 AI 物料清单
- 对抗性测试：针对 OWASP Top 10 for LLMs 进行测试
- 运行时防火墙：拦截提示注入攻击，阻止数据泄露
十、企业级落地实践
10.1 实战案例：Verint Systems
Verint Systems 的云基础设施总监 John Jones 分享了一个实战案例：
“我们构建了一个 Kubernetes 故障排除 Agent，它从简单地读取日志快速演变为实际排查问题。这个 Agent 将在组织级别推广，帮助超过 200 名运维团队成员和约 1000 名开发者。我们只花了四天时间就学会并构建了一个生产级 AI Agent，用于处理我们最常见也最耗时的任务——排查流水线故障。”
关键数据：
- 构建时间：4 天
- 受益团队：200+ 运维人员 + 1000+ 开发者
- 应用场景：Kubernetes 故障排查
10.2 实战案例：United Airlines
Ratna Devarapalli（United Airlines IT 总监）评价：
“我们构建了 RiskSentinel，一个 Harness Autonomous Worker Agent，用于证明受治理的 AI 可以超越识别安全问题，在保持企业控制、可审计性和合规性的同时安全地修复它们。最令人印象深刻的是，我们从一个创意到生产级 Agent 只用了四天。”
10.3 企业落地评估清单
架构治理要求：
- 运行在现有控制面内，非旁路 Worker
- 继承现有 RBAC，无独立超级 Token
- Secrets 经由 Manager 引用，拒绝明文
- 工具需 Allow-list，定义可版本化
- 区分 Read/Suggest/Prepare/Execute 级别
安全与合规要求：
- Effectful Action 需经过策略引擎校验
- 高风险操作必须包含人工审批节点
- 日志覆盖全链路决策且支持脱敏
- 输出优先生成 PR、报告等可审查产物
- 支持成本、成功率等关键指标监控
十一、竞争格局与行业定位
Harness Agent 并非孤立的竞品，而是处在 AI 软件交付基础设施的竞争格局中：
| 产品 | 定位 | 核心差异 |
|---|---|---|
| Harness Agents | 流水线内 Agent，覆盖代码之后的全链路 | 治理继承、Knowledge Graph、企业级安全 |
| GitHub Copilot Coding Agent | Issue 到 Draft PR 的异步协作 | 依赖 GitHub Actions 和 PR Review |
| GitLab Duo Agent Platform | GitLab 生命周期内的 Flow 和 Session | 与 GitLab 深度集成 |
| Atlassian Rovo Dev | Jira Work Item 到代码生成 | 从项目管理到代码的闭环 |
Harness 的核心差异化在于：Agent 不是"模型外面的薄包装"，而是深度嵌入工程体系的治理底座。
十二、总结与展望
核心结论
-
Harness Agent 的本质不是模型智能，而是治理能力。它将 AI 的推理能力与工程体系的控制能力分离，确保模型在受控边界内执行。
-
治理继承是最重要的架构决策。Agent 不需要学习一套新的安全规则，而是直接继承企业已有的流水线治理机制——OPA 策略、RBAC、审批门禁、审计日志。
-
企业级 Agent 落地应优先定义执行边界和动作分级，而非从多智能体框架入手。先做好 Read/Suggest/Prepare/Execute 四级控制，再扩展 Agent 的能力范围。
未来趋势
随着 Agent DLC 的发布，Harness 正在将 AI Agent 从"流水线中的自动化步骤"升级为"受治理的 AI 开发全生命周期"。这预示着一个更广泛的趋势：
未来不再区分"自动化"与"智能体"，而是将受控的智能作为标准的软件交付原语。
对于企业而言，关键不是追求"最聪明的 AI"，而是建立"最可靠的 AI 治理底座"。模型能力会继续迭代变化，但治理底座将决定 AI 能否从个人效率工具升级为可治理的软件交付能力。
本文基于 Harness 官方文档、开发者文档、Harness Blog 及行业分析整理，数据截止 2026 年 8 月。
欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！
更多推荐
5
0- 0
已为社区贡献2条内容
所有评论(0)