Harness Engineering —— 系统的安全护栏

本文基于"模智空间"PPT《Prompt · Context · Harness · Loop 四大AI工程支柱》的 Harness Engineering 部分内容扩展创作，结合 ETCLOVG 七层架构框架，系统性地阐述 Agent 系统的安全、可靠、可控运行体系。

一、Agent 行业重心的迁移：从"能用"到"好用"

1.1 行业演进的三个阶段

AI Agent 行业的发展经历了三个明显的阶段：

阶段	时期	核心关注点	典型特征
基础探索期	2022-2023	工具调用与简单任务执行	单循环 Agent，Demo 级应用
全栈建设期	2023-2024	执行环境、上下文管理、生命周期编排	多智能体协作、MCP 协议等基础设施
企业落地期	2024-至今	安全、可靠、可控、可规模化	治理体系、安全护栏、全链路观测

尤其是 2024 年后，随着 Context Engineering、多智能体协作协议、标准化接口（如 MCP / A2A）等关键领域的突破，Agent 行业正从"能用的 Demo"向"可稳定、安全、大规模落地的企业级平台"演进。

1.2 核心瓶颈：模型"可用但不可靠"

当前 AI Agent 的通用能力持续迭代成熟，但可靠性与可控性并未同步提升。行业瓶颈已不再是"模型能否完成任务"，而是：

如何保障模型执行过程的安全？（不会误删数据库、不会泄露敏感信息）
如何确保执行过程的稳定？（不会陷入死循环、不会因单步失败而整体崩溃）
如何让系统行为可审计？（出错时能追溯根因，而非只知道"最后结果不对"）

正是在 AI Agent"可用但不可靠"的阵痛之下，Harness Engineering 应运而生。

二、什么是 Harness Engineering？

2.1 概念的起源

"Harness" 一词最早出现在工业工程和传统软件测试领域，有两个核心含义：

线束工程（电气工程）：通过标准化的线束（Wire Harness）连接和管理复杂的电气系统，实现信号传输的规范化和可控性。
测试基座（软件测试）：围绕被测系统搭建测试环境、约束条件和监控机制，确保测试过程的可控性和可复现性。

这两个理念被迁移至 AI 领域后，形成了 Harness Engineering 的核心思想：通过基础设施实现管控、隔离与风险防护。它把模型视为系统的一部分，围绕模型搭建一整套基础设施，专门解决安全、可靠、可控相关的问题。

2.2 Harness Engineering 的定义

Harness Engineering 关注的是整个 Agent 系统如何安全、可靠、可控地运行。它不直接参与模型的推理过程，而是为推理过程提供运行环境和安全保障。

其核心关注点包括：

关注领域	核心问题	典型手段
权限控制	哪些工具能调？哪些操作需要人工审批？	角色权限模型、操作审批流
错误恢复	模型陷入死循环时如何强制中断？如何安全回滚？	超时中断、状态快照、回滚机制
状态持久化	任务中断后如何保存进度？会话断开后如何恢复？	快照存储、增量状态保存
验证与重试	如何验证任务完成度？执行失败后如何自动重试？	校验规则、重试策略、熔断机制
全链路观测	追踪每一步执行细节，统计 Token 消耗与成本	链路追踪、日志聚合、成本监控
模块化架构	记忆、工具、规划等组件解耦，支持独立替换与升级	插件化、接口标准化

三、ETCLOVG 七层架构

Harness Engineering 可以拆分为 ETCLOVG 七个独立的层级，分为两大模块：

核心运行底座（E/T/C/L）：支撑 Agent 完成基础任务执行，是 Agent 的"身体与行动系统"
全局管控平面（O/V/G）：负责监控、质检、安全约束，是 Agent 的"大脑与风控系统"

ETCLOVG 七层架构

┌──────────────────────────────────────────────┐
│ 全局管控平面 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Observe │ │Verify │ │Govern │ │
│ │可观测性 │ │验证评估 │ │治理安全 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
├──────────────────────────────────────────────┤
│ 核心运行底座 │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────┐ │
│ │Execution│ │Tool │ │Context │ │Life │ │
│ │执行环境 │ │工具接口 │ │上下文 │ │周期 │ │
│ └─────────┘ └─────────┘ └─────────┘ └─────┘ │
└──────────────────────────────────────────────┘

四、核心运行底座（E/T/C/L）详解

4.1 执行环境与沙箱（Execution）------ E 层

执行环境是 Agent 动作的物理载体，沙箱是其核心标配。

沙箱的三大核心价值：

安全隔离：Agent 执行的代码、命令、文件操作在隔离环境中运行，不会影响宿主机或生产环境。即使 Agent 产生恶意行为或意外操作，其影响范围也被限制在沙箱内。
可复现性：沙箱提供标准化的运行环境，确保 Agent 的执行结果可复现。这对于调试、审计和回归测试至关重要。
提升自主性：在沙箱内，Agent 可以自主执行更多操作，无需频繁弹出人工授权确认，从而提升执行效率。

沙箱类型与演进方向：

沙箱类型	隔离级别	适用场景	代表产品
通用云沙箱	容器级	通用任务执行	E2B, Daytona
代码专用沙箱	进程级	代码生成与执行	Code Interpreter
高隔离微虚机	虚拟化级	高风险操作、多租户	Firecracker, gVisor
轻量化权限控制	系统调用级	低风险操作	seccomp, Landlock

当前行业正朝着高隔离度微虚机 与轻量化权限限制双线发展------前者追求极致安全，后者追求极致效率。

沙箱逃逸与提示注入仍是当前最严峻的安全挑战。研究表明，即使经过安全训练的模型，仍有相当比例的攻击成功率。防御方案零散，缺乏统一标准。

4.2 工具接口与协议（Tool）------ T 层

大模型本身无法操作软件、调用接口、执行命令，必须依靠工具完成外部动作。T 层定义了 Agent 如何发现、调用、管理各类工具。

核心是协议与工具选型：

工具协议标准化：

MCP（Model Context Protocol）：Anthropic 提出的模型-工具通信协议，定义了工具发现、调用、结果返回的标准格式
Function Calling：OpenAI 原生的工具调用机制
A2A（Agent-to-Agent）：Google 提出的 Agent 间通信协议

工具选型的关键原则 ：工具并非越多越好。

工具列表过长会增加模型的选择难度、暴涨 Token 消耗，反而降低准确率。精简且精准的工具集远优于大而全的工具列表。推荐实践：

工具数量控制在 10-20 个以内
工具描述精确、包含参数说明和返回值格式
按场景动态加载工具，而非一次性全部暴露
为工具设置优先级和风险等级

工具管理的工程实践：

yaml 复制代码

tools:
  - name: search_docs
    description: 搜索内部知识库
    risk_level: low
    auto_approve: true
    parameters:
      query: string  # 搜索关键词
      top_k: int     # 返回结果数，默认5
    
  - name: deploy_service
    description: 部署服务到生产环境
    risk_level: critical
    auto_approve: false  # 需要人工审批
    parameters:
      service_name: string
      version: string
      environment: string  # staging | production

4.3 上下文与内存管理（Context）------ C 层

C 层专门管理 Agent 的所有信息输入与记忆存储。这一层与 Context Engineering 高度重叠，但在 Harness 语境下，更强调工程化的存储架构和状态管理。

三级内存架构：

scss 复制代码

┌──────────────────────────────────────────────────┐
│  短期记忆 (Working Memory)                        │
│  ├─ 当前对话上下文                                 │
│  ├─ 正在执行的任务状态                             │
│  └─ 最近的工具调用结果                             │
│  存储位置：上下文窗口 | 生命周期：当前推理轮次        │
├──────────────────────────────────────────────────┤
│  中期记忆 (Task Memory)                           │
│  ├─ 任务目标与计划                                 │
│  ├─ 已完成步骤与中间产物                            │
│  └─ 失败记录与重试策略                              │
│  存储位置：Session Storage | 生命周期：当前任务会话    │
├──────────────────────────────────────────────────┤
│  长期记忆 (Persistent Memory)                     │
│  ├─ 用户偏好与编码规范                              │
│  ├─ 项目架构知识                                   │
│  └─ 历史踩坑经验与解决方案                           │
│  存储位置：Vector DB / KV Store | 生命周期：持久化     │
└──────────────────────────────────────────────────┘

当前两大挑战：

上下文衰减（Context Decay）：即使上下文窗口未满，随着对话轮次增加，模型对早期信息的关注度也会持续下降，导致模型性能逐渐降低。这是当前学术界的热点研究方向。
上下文漂移（Context Drift）：长时间运行后，Agent 逐渐偏离原始任务目标。微小的偏差在循环中不断累积，最终导致 Agent 完全偏离既定轨道。

4.4 生命周期与编排（Lifecycle）------ L 层

L 层管控任务的全流程流转，包括步骤拆解、状态维护、错误重试、多角色协作。

三个层级：

层级	描述	复杂度	典型场景
单智能体循环	单个 Agent 自主完成"规划→执行→检查→修正"	低	代码生成、文档撰写
多智能体编排	多个 Agent 协作，各自负责不同子任务	中	软件开发流水线（设计+编码+测试）
全流程流水线	多智能体 + 多工具 + 多阶段的有向无环图（DAG）	高	企业级自动化流程

核心权衡：有状态 vs 无状态

模式	优点	缺点
无状态	流程透明，便于复盘审计；每次执行独立，不受历史影响	长任务效率低，需要重新计算上下文；无法保留进度
有状态	保留进度，支持快速续跑；减少重复计算	状态不一致风险；恢复逻辑复杂

主流产品大多采用混合模式：在关键节点自动保存状态快照，支持断点续跑；同时保留完整的无状态执行日志用于审计。

五、全局管控平面（O/V/G）详解

5.1 可观测性与运维（Observability）------ O 层

当 Agent 规模化部署后，开发者需要实时知道 Agent 做了什么、为什么出错、花了多少成本。

三大核心能力：

链路追踪（Tracing）：

记录每个 Agent 步骤的输入、输出、中间推理
追踪工具调用的请求/响应和耗时
关联多个 Agent 之间的协作关系
类似传统微服务的分布式链路追踪（如 OpenTelemetry），但 Agent 的"链路"更复杂------包含推理步骤、工具调用、重试循环等非线性的执行路径

成本与性能监控：

实时统计 Token 消耗（输入/输出/Cache）
按任务、按用户、按时间维度分析成本
监控延迟、吞吐量、错误率等性能指标
设置成本告警阈值，防止失控

故障运维：

异常检测：模型输出异常、工具调用失败、执行超时
根因分析：从最终结果反推哪一步出了问题
自动恢复：根据错误类型触发对应的恢复策略

行业现状：开源工具（如 LangSmith、Phoenix、Weave）偏向基础追踪，深度运维和智能故障分析能力大多集中在商业平台（如 Datadog、New Relic 的 AI 监控方案）。

5.2 验证与评估（Verification）------ V 层

传统大模型评估只看最终输出分数，但 Agent 是多步交互系统------结果正确不代表过程合规。

五阶段闭环质检体系：

markdown 复制代码

1. 任务定义 ──→ 2. 运行前校验 ──→ 3. 链路采集 ──→ 4. 多维度评判 ──→ 5. 回归迭代
     ↑                                                                    │
     └────────────────────────────────────────────────────────────────────┘

各阶段详解：

任务定义：明确任务的成功标准------不仅是"最终结果正确"，还包括"过程合规"、"成本可控"、"时效达标"。
运行前校验：在 Agent 执行前进行静态检查：
- 权限校验：当前用户是否有权限执行此操作？
- 输入校验：用户输入是否合法、安全？
- 资源校验：是否有足够的 Token 配额？
链路采集：在执行过程中采集完整的执行链路数据，包括每一步的推理、工具调用、中间结果。
多维度评判：从多个维度对执行结果进行评估：
- 结果正确性（Accuracy）
- 过程合规性（Compliance）
- 执行效率（Efficiency）
- 安全性（Safety）
- 可追溯性（Traceability）
回归迭代：将评估结果反馈到系统设计中，持续优化 Agent 行为。评估结果应纳入 CI/CD 流程，确保每次修改都经过验证。

5.3 治理与安全（Governance）------ G 层

Agent 拥有自主执行权限，安全与合规是企业落地的底线。G 层是整套系统的风控中枢。

四大板块：

权限管控：

基于角色的访问控制（RBAC）：不同角色的 Agent 拥有不同的工具权限
最小权限原则：Agent 只拥有完成任务所需的最小权限集
操作审批流：高风险操作（如删除数据、修改生产配置）需要人工审批
权限时效性：临时提权应有时间限制，到期自动回收

审计追踪：

完整的操作日志（谁、什么时间、做了什么、结果如何）
不可篡改的审计链（使用区块链或 WAL 技术）
敏感操作的重点标记

安全防御：

提示注入（Prompt Injection）防护
越狱（Jailbreak）检测
数据泄露防护（DLP）：防止 Agent 将敏感信息输出到不安全的目标
异常行为检测：基于行为基线的异常告警

合规管理：

数据驻留要求（如 GDPR 要求数据不出境）
行业合规标准（如 SOC2、HIPAA）
模型使用合规（如版权、使用条款）

行业现状：安全是开源生态中最薄弱的环节。多数开源框架（如 LangChain、CrewAI）仅实现基础权限控制，完整的治理体系几乎都来自商业产品（如 Anthropic 的 Claude Enterprise、OpenAI 的 ChatGPT Enterprise）。

六、Harness Engineering 设计的核心取舍

七层架构各自独立，但在实际部署中层与层深度耦合，衍生出三个核心矛盾。

6.1 成本-质量-速度的三元悖论

bash 复制代码

      高质量 / 高安全
          /\
         /  \
        /    \
       /      \
      /________\
低成本          高速度

追求高质量、高安全性 → 需要更多验证步骤、人工审批、更严格的沙箱 → 拉高成本，拖慢执行速度
追求极致速度 → 减少验证步骤，降低安全约束 → 容易降低稳定性，引入安全风险
追求低成本 → 使用更便宜的模型、更少的监控 → 牺牲监控精度和执行可靠性

实际工程中的折中策略：

按任务风险等级分级处理：低风险任务自动执行，高风险任务加强验证
动态调整：根据历史表现动态调整验证强度（表现好的 Agent 降低验证频率）
成本分层：核心业务使用高质量模型+完整 Harness，边缘业务使用轻量配置

6.2 能力与管控的此消彼长

Agent 的能力越强，对应的管控难度就越大：

增加工具数量、开放更多权限 → Agent 能完成更复杂的任务 → 但攻击面、误操作风险同步上升
收紧权限、精简工具 → 安全性提升 → 但 Agent 的业务能力会受到限制

这一权衡贯穿 T 层、E 层、G 层，是"智能"与"安全"的永恒博弈。当前没有完美的解决方案，需要在具体业务场景中做出权衡。

6.3 层间耦合：局部优化 ≠ 全局最优

七层架构环环相扣，修改任意一层，都可能产生连锁反应：

修改	直接影响	间接影响
更换沙箱（E层）	执行环境变化	改变评测结果（V层），影响工具兼容性（T层）
调整工具描述（T层）	工具调用成功率变化	增加上下文占用（C层），影响 Token 消耗（O层）
优化监控规则（O层）	监控精度提升	带来额外延迟，影响执行效率（L层）
收紧权限（G层）	安全性提升	限制 Agent 能力，降低任务完成率（V层）

核心启示：不能单独优化某一个组件，所有迭代都需要做全链路测试。这类似于微服务架构中的集成测试理念------组件级别的测试通过，不代表系统级别的行为正确。

七、Harness Engineering 五大技术难题

7.1 执行环境的加固与规模化

现状：沙箱逃逸与提示注入攻击成功率仍高，防御方案零散无标准。

挑战：海量隔离环境需求下，成本高、弹性差。每个 Agent 实例都需要独立的沙箱，大规模部署时资源消耗巨大。

探索方向：

轻量化沙箱技术（如 WebAssembly 沙箱）
沙箱池化（预先创建沙箱池，按需分配）
基于 eBPF 的细粒度权限控制

7.2 长任务下的状态一致性

现状：上下文衰减与漂移是长周期 Agent 的致命问题，现有方案仅能缓解，无法根治。

挑战：如何在长时间运行中保持 Agent 对原始任务目标的忠实度，同时处理中间状态的一致性。

探索方向：

目标锚定机制（定期回验原始目标）
状态快照与差异检测
外部监督 Agent 进行目标对齐检查

7.3 基于执行链路的故障诊断

现状：当前评估过度依赖最终分数，故障难寻根因------只知道"最后结果不对"，不知道"哪一步出了问题"。

挑战：建立链路原生评估体系，实现故障自动诊断与修复。

探索方向：

基于因果推理的故障定位
链路级别的自动化回归测试
故障模式库与自动匹配

7.4 跨角色标准化交接

现状：Agent、工具、人类之间的任务交接尚无统一标准，信息传递不完整。

挑战：需要统一意图、权限、上下文、状态等信息的传递规范。

探索方向：

A2A（Agent-to-Agent）通信协议标准化
人机交互（Human-in-the-Loop）的标准接口
任务状态的标准序列化格式

7.5 随模型迭代动态简化 Harness

现状：Harness 的很多防护措施是针对当前模型能力的"补丁"。当模型能力提升后，部分防护可能变得冗余。

挑战：Harness 需要具备自适应能力，根据模型迭代自动增删管控逻辑，以降低成本、提升速度。

探索方向：

基于模型能力评估的自动化 Harness 配置
可插拔的防护模块
基于强化学习的动态策略调整

八、总结

Harness Engineering 是 Agent 从"Demo"走向"生产"的关键桥梁。当 Prompt Engineering 回答了"怎么问"、Context Engineering 回答了"看什么"之后，Harness Engineering 回答的是最关键的问题："怎么安全地执行？"

ETCLOVG 七层架构为 Agent 系统的工程化提供了系统性的框架：

E（执行环境）：在安全沙箱中运行，隔离风险
T（工具接口）：标准化工具协议，精简工具集
C（上下文管理）：三级记忆架构，对抗衰减与漂移
L（生命周期）：管理任务全流程，支持断点续跑
O（可观测性）：全链路追踪，成本与性能监控
V（验证评估）：多维度评判，过程合规检查
G（治理安全）：权限管控、审计追踪、安全防御、合规管理

Harness Engineering 不只是技术问题，更是工程哲学------它承认模型不可靠，但通过基础设施的设计，让不可靠的组件能够组成可靠的系统。

上一篇：Context Engineering ------ 知识与记忆的窗口

下一篇： $Loop Engineering ------ 循环的设计与自主执行$