首页 › ai-agents › Harness工程六层栈:Agent量产基础设施全拆解

Harness工程六层栈:Agent量产基础设施全拆解

2026年,一个词从Anthropic、OpenAI、LangChain三家核心厂商的工程博客中同步涌现——Harness Engineering(缰绳工程)。核心等式只有五个字:Agent = Model + Harness。模型是大脑,Harness是围绕模型构建的系统层——提示词、工具、记忆、编排逻辑、测试、沙盒、部署管道的总和。Anthropic声称"70%的Agent性能来自Harness而非模型";OpenAI发布专门页面讲解Harness工程实践;LangChain将其定义为"将demo级Agent变为生产级系统"的核心学科。与此同时,一篇arXiv论文(2605.12239)甚至用范畴论为Harness建立了形式化架构——ArchAgents框架。这不是营销概念,而是一整个工程学科正在成形。

本文拆解Harness工程的六层架构(L1-L6),对比五大沙盒运行时,实测四类部署策略,并给出从零到生产的六个月路线图。


一、Harness工程定义:为什么模型能力只占30%

传统软件工程的经验是:代码写完只是开始,测试、部署、监控、运维才是大头。Agent领域正在经历同样的认知转变。

核心公式:

Agent = Model + Harness

Harness的四大支柱(来自arXiv:2605.12239 ArchAgents框架):

支柱 范畴论映射 工程含义
Prompts(提示词) 态射(Morphism) 输入到行为的映射规则
Tools(工具) 函子(Functor) Agent对外部世界的结构化访问
Memory(记忆) 余极限(Colimit) 历史信息的聚合与压缩
Orchestration(编排) 自然变换(Natural Transformation) 组件间的协调与流程控制

这个形式化框架的价值不在于学术优雅,而在于它揭示了一个关键事实:每一层都是独立的工程优化面。你可以用同一个模型,通过优化Harness的不同层,获得数量级的性能提升。

Anthropic在2026年3月的工程博客中展示了实证数据:在长任务(>100步)场景下,一个精心设计的Harness可以让Claude的完成率从23%提升到89%——不换模型,只换Harness。


二、六层架构:从内到外的Harness栈

根据LangChain、Anthropic和社区的共识,Harness工程被划分为六层(L1-L6)。一个关键的反直觉洞察是:应该从L6向L1反向构建,而非从L1向L6正向构建。

graph TB
    subgraph "Harness六层架构"
        L6["L6 部署与运维<br/>Canary/Shadow/Rollback"]
        L5["L5 评估与测试<br/>Trajectory/Eval Gate"]
        L4["L4 沙盒与隔离<br/>E2B/Daytona/Firecracker"]
        L3["L3 编排与流程<br/>DAG/Loop/Retry"]
        L2["L2 工具与记忆<br/>Function/VectorStore"]
        L1["L1 提示与模型<br/>SystemPrompt/Model"]
    end
    L1 --> L2 --> L3 --> L4 --> L5 --> L6
    style L6 fill:#e74c3c,color:#fff
    style L5 fill:#e67e22,color:#fff
    style L4 fill:#f1c40f,color:#333
    style L3 fill:#2ecc71,color:#fff
    style L2 fill:#3498db,color:#fff
    style L1 fill:#9b59b6,color:#fff

L1 提示与模型层(Prompt & Model)

最内层。包含系统提示词、few-shot示例、模型选择和参数配置。这是大多数人关注的层,但恰恰是投入产出比最低的优化面。

关键组件: - System Prompt模板化(变量注入、条件分支) - 模型路由(按任务复杂度分配不同模型) - 温度/Top-P调优 - 结构化输出约束(JSON Schema、约束解码)

代码示例——结构化输出约束:

from anthropic import Anthropic

client = Anthropic()

# L1层:通过Harness约束模型输出格式
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "分析这段代码的安全性"}],
    # Harness约束:强制JSON输出
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "code_analysis",
            "schema": {
                "type": "object",
                "properties": {
                    "risk_level": {"type": "string", "enum": ["low", "medium", "high", "critical"]},
                    "vulnerabilities": {"type": "array", "items": {"type": "string"}},
                    "recommendation": {"type": "string"}
                },
                "required": ["risk_level", "vulnerabilities", "recommendation"]
            }
        }
    }
)

L2 工具与记忆层(Tools & Memory)

工具子层:函数定义、参数校验、错误处理、超时控制。核心挑战不是"能用",而是"用得稳"。

记忆子层:短期(对话上下文)、中期(会话摘要)、长期(向量存储)。关键设计决策:何时压缩、何时遗忘、何时召回。

# L2层:工具定义 + 记忆管理
from langchain_core.tools import tool
from langchain_community.vectorstores import Chroma

@tool
def search_knowledge_base(query: str, top_k: int = 3) -> list[dict]:
    """搜索知识库,返回最相关的top_k条结果"""
    # 参数校验是Harness的责任,不是模型的
    if top_k > 10:
        top_k = 10  # 防止模型请求过多结果
    results = vectorstore.similarity_search(query, k=top_k)
    return [{"content": r.page_content, "score": r.metadata.get("score", 0)} for r in results]

# 记忆压缩策略
class CompressedMemory:
    def __init__(self, max_tokens=4000):
        self.max_tokens = max_tokens

    def compress(self, messages: list) -> list:
        """当上下文超过阈值时,自动压缩旧消息"""
        total = sum(len(m["content"]) for m in messages)
        if total > self.max_tokens:
            # 保留最近5条 + 压缩历史为摘要
            recent = messages[-5:]
            history = messages[:-5]
            summary = self._summarize(history)
            return [{"role": "system", "content": f"历史摘要: {summary}"}] + recent
        return messages

L3 编排与流程层(Orchestration)

Agent Loop的执行控制。包含步骤预算(step budget)、决策路由、重试策略、并行/串行控制。这一层决定了Agent是"有计划的执行"还是"无方向的游荡"。

Anthropic的Harness设计原则(来自其2026年3月博客): 1. 设定明确的步骤预算上限 2. 每步之后检查"是否仍在正确的轨道上" 3. 在关键决策点插入人类检查点(可选) 4. 失败时优雅降级,而非无限重试

L4 沙盒与隔离层(Sandbox & Isolation)

Agent执行代码或访问外部资源时的安全隔离。这是2026年最热门的Harness子领域之一。

L5 评估与测试层(Evaluation & Testing)

Agent的测试策略。区别于传统软件测试的确定性断言,Agent测试需要处理非确定性输出。

L6 部署与运维层(Deployment & Operations)

Agent的上线策略、版本管理、金丝雀发布、回滚机制。


三、沙盒运行时五强对比:Agent代码执行的隔离之道

当Agent需要执行代码、操作文件系统或访问网络时,沙盒是L4层的核心组件。2026年形成了五大主流方案:

平台 隔离技术 启动延迟 适用场景 月费起步
E2B Firecracker微VM ~150ms 轻量代码执行、数据分析 $29/月
Daytona Docker + microVM ~90ms 开发环境、IDE集成 免费开源
Modal 容器 + GPU直通 ~300ms GPU计算、ML推理 按用量计费
Fly.io Sprites Firecracker ~200ms 边缘部署、低延迟 按用量计费
Cloudflare Sandboxes V8 Isolates ~50ms 无状态函数、Web API 免费/按量

关键发现:

  1. E2B是当前生态最完善的Agent沙盒。OpenAI的Agents SDK在2026年4月更新中将其作为原生集成选项之一。SDK简洁(pip install e2b-code-interpreter),但成本在批量使用时会快速攀升。

  2. Daytona以90ms的启动速度和完全开源的策略,在企业市场获得强劲势头。其核心卖点是"开发环境即沙盒"——开发者可以在Daytona环境中编码、测试,然后直接将该环境作为Agent的执行沙盒。

  3. Firecracker微VM正在成为底层标准。E2B、Fly.io和Daytona的高端方案都基于Firecracker。它提供虚拟机级别的安全隔离,但启动时间接近容器。

  4. 实际选型建议:需要快速原型→E2B;需要GPU→Modal;需要企业合规→Daytona自建;需要边缘低延迟→Fly.io;只需要隔离函数→Cloudflare。

graph LR
    subgraph "Agent沙盒选型决策树"
        A[Agent需要执行代码?] -->|是| B{需要GPU?}
        A -->|否| C[无需沙盒<br/>纯文本交互]
        B -->|是| D[Modal<br/>GPU直通]
        B -->|否| E{需要文件系统?}
        E -->|是| F{企业合规要求?}
        E -->|否| G[Cloudflare V8<br/>最轻量]
        F -->|是| H[Daytona自建<br/>完全控制]
        F -->|否| I{延迟敏感?}
        I -->|是| J[Fly.io Sprites<br/>边缘部署]
        I -->|否| K[E2B<br/>生态最完善]
    end

四、Agent测试四层栈:从轨迹回放到语义回归

Agent测试是Harness工程中认知变革最大的领域。传统软件的assert(expected == actual)在Agent世界失效了——因为输出本质上是概率性的。

第一层:单元测试(Prompt Testing)

测试单个提示词是否产生预期类型的输出。不是检查精确值,而是检查结构。

# 第一层:结构化断言
def test_code_analysis_prompt():
    result = agent.analyze("def foo(): pass")
    assert result.risk_level in ["low", "medium", "high", "critical"]
    assert isinstance(result.vulnerabilities, list)
    assert len(result.recommendation) > 10

第二层:轨迹测试(Trajectory Testing)

测试Agent的执行路径是否合理。不是检查最终输出,而是检查Agent"走过的路"是否正确。

# 第二层:轨迹断言
def test_agent_trajectory():
    session = agent.run("帮我重构这个函数并写测试")

    # 检查Agent是否按正确顺序执行了正确的工具
    assert session.tool_calls[0].name == "read_file"
    assert session.tool_calls[1].name == "write_file"
    assert session.tool_calls[2].name == "run_test"

    # 检查步骤数在合理范围
    assert 3 <= len(session.tool_calls) <= 10

    # 检查没有循环(同一工具+同一参数调用>3次)
    call_signatures = [(c.name, c.args) for c in session.tool_calls]
    for sig in call_signatures:
        assert call_signatures.count(sig) <= 3

第三层:集成测试(Workflow Testing)

测试多步工作流的端到端行为。使用"语义断言"——用另一个LLM来评判输出质量。

# 第三层:语义断言
async def test_refactor_workflow():
    result = await agent.run("重构src/auth.py,添加类型注解")

    # 用评判LLM检查质量
    judge_prompt = f"""
    评估以下重构结果的质量(1-5分):
    原始代码:{result.original_code}
    重构后代码:{result.refactored_code}
    测试结果:{result.test_output}

    评估维度:类型注解完整性、功能保持、代码风格
    """
    score = await judge_llm.evaluate(judge_prompt)
    assert score >= 4.0  # 至少4分才算通过

第四层:回归测试(Regression Testing)

检测Agent行为在版本更新后的退化。核心是"语义快照"——不是比较文本差异,而是比较行为差异。

# 第四层:回归测试
def test_regression_against_baseline():
    baseline = load_baseline("v2.3.1")  # 加载基线行为
    current = agent.run_batch(regression_test_suite)

    for test_name, (base_result, curr_result) in zip(baseline, current):
        # 语义相似度而非文本匹配
        similarity = semantic_similarity(base_result.output, curr_result.output)
        assert similarity > 0.85, f"{test_name} 回归: 相似度 {similarity:.2f}"

        # 工具调用序列一致性
        base_tools = [c.name for c in base_result.tool_calls]
        curr_tools = [c.name for c in curr_result.tool_calls]
        tool_overlap = len(set(base_tools) & set(curr_tools)) / max(len(base_tools), len(curr_tools))
        assert tool_overlap > 0.7, f"{test_name} 工具调用变化过大"

测试覆盖率的新定义:在Agent世界,覆盖率不是"代码行覆盖",而是"场景覆盖"。Zylos的研究指出,一个生产级Agent至少需要覆盖以下场景矩阵:

维度 测试点
输入边界 空输入、超长输入、多语言、特殊字符
工具失败 网络超时、权限拒绝、返回格式异常
状态异常 上下文溢出、会话中断、部分完成
并发冲突 多Agent同时修改同一资源
成本控制 单次运行Token超限、工具调用次数超限

五、Agent-Native CI/CD:四类部署策略实战

传统CI/CD假设代码是确定性的。Agent的CI/CD必须处理概率性行为。2026年形成了四种主流部署模式:

模式一:影子部署(Shadow Deployment)

新版本Agent与旧版本并行运行,但只有旧版本的输出返回给用户。新版本的输出被记录和比较。

graph LR
    User[用户请求] --> Router[流量路由器]
    Router -->|"100%流量"| Old[旧版Agent v2.3]
    Router -->|"100%镜像"| New[新版Agent v2.4]
    Old --> Response[返回用户]
    New -->|静默记录| Comparator[行为比较器]
    Comparator --> Alert[差异告警]

适用场景:重大版本升级、模型切换、提示词大改。 优势:零用户风险。 劣势:双倍计算成本。

模式二:金丝雀发布(Canary Release)

将5%的流量导向新版本,监控关键指标,逐步扩大。

# 金丝雀发布配置示例
canary_config = {
    "agent_v2.4": {
        "traffic_percentage": 5,  # 初始5%
        "step_up_interval": "1h",  # 每小时评估一次
        "step_up_percentage": 10,  # 每次增加10%
        "rollback_thresholds": {
            "error_rate": 0.05,       # 错误率>5%回滚
            "latency_p99_ms": 5000,   # P99延迟>5s回滚
            "tool_failure_rate": 0.1,  # 工具失败率>10%回滚
            "cost_per_request": 0.15,  # 单次成本>$0.15回滚
            "semantic_score": 3.5,     # 语义评分<3.5/5回滚
        },
        "evaluation_window": "30m",    # 评估窗口30分钟
    }
}

模式三:评估门控部署(Eval Gate Deployment)

每次部署前必须通过自动化评估套件。评估不通过,部署自动阻断。

# eval-gate.yaml
eval_gates:
  - name: "trajectory_correctness"
    type: trajectory
    threshold: 0.85
    test_cases: 50

  - name: "tool_selection_accuracy" 
    type: tool_usage
    threshold: 0.90
    test_cases: 30

  - name: "output_quality"
    type: semantic
    judge_model: "claude-haiku-4-5-20251001"
    threshold: 4.0  # 5分制
    test_cases: 100

  - name: "cost_regression"
    type: cost
    max_increase_percentage: 20
    test_cases: 200

deployment:
  requires_all_gates: true
  auto_rollback_on_regression: true

模式四:功能标志部署(Feature Flag Deployment)

通过功能标志控制Agent的能力范围,而非版本切换。可以按用户、地域、任务类型灰度。

# 功能标志控制Agent能力范围
from flags import get_flag

class AgentWithFlags:
    def __init__(self, user_id: str):
        self.user_id = user_id

    def get_tools(self):
        tools = [read_file, write_file]  # 基础工具
        if get_flag("agent.code_execution", self.user_id, default=False):
            tools.append(execute_code)  # 渐进开放
        if get_flag("agent.internet_access", self.user_id, default=False):
            tools.append(web_search)  # 高风险能力
        if get_flag("agent.database_write", self.user_id, default=False):
            tools.append(db_query)  # 最高风险
        return tools

    def get_step_budget(self):
        if get_flag("agent.extended_thinking", self.user_id, default=False):
            return 50  # 高信任用户给更多步骤
        return 20

四类策略对比:

策略 安全性 成本 上线速度 适用场景
影子部署 最高 2x 慢 大版本升级
金丝雀 高 1.05-1.5x 中 常规迭代
评估门控 中 1x 快 CI/CD集成
功能标志 灵活 1x 最快 能力灰度

六、AgentOps全生命周期:从LangSmith到Azure AI Foundry

AgentOps——Agent的操作运维——正在从MLOps/LLMOps中独立出来。2026年形成了三大平台格局:

1. AgentOps.ai(开源开发者平台)

定位:Agent领域的Datadog。专注开发者体验。

核心功能: - Session Replay:逐步回放Agent的每一步决策,像看视频一样调试 - 成本追踪:精确到每次工具调用的Token消耗和成本 - 性能分析:延迟分布、错误率、成功率 - 合规审计:记录每个决策的输入/输出,满足审计需求

技术集成:两行代码接入——import agentops; agentops.init(),支持OpenAI、Anthropic、LangChain、AutoGen等主流框架。

2. LangSmith(LangChain生态)

定位:LangChain生态内的全链路可观测 + 评估平台。

差异化: - 原生支持LangGraph的多Agent图追踪 - 内置评估套件(自定义评估器 + 预设评估器) - 提示词版本管理(git-like的版本控制) - 数据集管理(测试用例集 + 基线集)

3. Azure AI Foundry(企业级)

定位:从开发到生产的端到端AgentOps。

微软在2026年1月的博客"From Zero to Hero: AgentOps"中,定义了企业级Agent全生命周期的五个阶段:

graph LR
    subgraph "Azure AgentOps五阶段"
        D[开发<br/>Dev] --> T[测试<br/>Test] --> S[预演<br/>Staging] --> P[生产<br/>Prod] --> M[运维<br/>Operate]
    end
    D -->|代码+提示词| T
    T -->|评估套件| S
    S -->|影子流量| P
    P -->|金丝雀+回滚| M
    M -->|反馈数据| D

关键差异化:企业合规(SOC2、HIPAA)、多环境部署(Dev/Test/Staging/Prod)、自动缩放、成本治理。


七、三大厂商的Harness设计哲学对比

Anthropic、OpenAI、LangChain各自对"什么是好的Harness"有不同回答。以下是基于其2026年公开资料的对比:

维度 Anthropic OpenAI LangChain
核心隐喻 初始化器Agent(Initializer Agent) 脚手架(Scaffold) 编排器(Orchestrator)
设计哲学 渐进式委托:从简单任务开始,逐步增加复杂度 结构先行:先建好CI/CD和测试,再让Agent写代码 组件化:每个Harness组件可独立替换
L1优化重点 System Prompt的版本化A/B测试 模型路由(按任务分派不同模型) 提示词模板市场
L3编排特点 步骤预算硬上限 + 轨迹监控 长时运行的分段检查点 LangGraph的有向图
L5测试策略 人类评审 + 自动评估混合 Codex的自动Harness生成 LangSmith评估套件
开源程度 Harness设计指南(博客) Codex CLI(部分开源) LangGraph完全开源
变现模式 API调用 + Managed Agents API调用 + Codex Pro LangSmith订阅

Anthropic的Harness洞察(来自2026年3月博客)最有价值的一点是:长时运行Agent的Harness设计原则与短时Agent完全不同。长时Agent需要: 1. 定期保存检查点(防止中途失败丢失所有进度) 2. 资源消耗的实时监控(Token、API调用、时间) 3. 中途退出策略(当成本超过阈值时优雅终止) 4. 进度可视化(让开发者/用户看到Agent"正在做什么")


八、从零到生产的六个月路线图

基于Harness Engineering Academy和社区实践,以下是一个团队从零建立Agent Harness的推荐路线:

第1-2月:建立L1-L2(提示词 + 工具记忆) - 定义标准化的System Prompt模板 - 建立工具注册表(Schema、错误处理、超时) - 实现基础的记忆管理(对话历史 + 摘要) - 建立Prompt版本控制(Git管理)

第3月:建立L3-L4(编排 + 沙盒) - 选择编排框架(LangGraph / OpenAI Agents SDK / 自建) - 设定步骤预算和决策路由 - 集成沙盒环境(推荐从E2B开始,后续迁移Daytona) - 实现失败重试和优雅降级

第4月:建立L5(测试与评估) - 建立四层测试套件(单元 → 轨迹 → 集成 → 回归) - 创建评估数据集(至少50个测试用例) - 实现语义评估器(用Haiku级别模型做评判) - 配置CI/CD自动运行测试

第5月:建立L6(部署与运维) - 实现金丝雀发布管道 - 配置影子部署环境 - 建立成本监控和告警 - 实现自动回滚机制

第6月:优化与规模化 - 基于生产数据优化Prompt - 扩展测试用例到200+ - 建立A/B测试框架 - 编写团队内部的Harness工程最佳实践文档


九、关键洞察与建议

核心发现

  1. Harness是新的护城河。模型能力趋同,差异化来自围绕模型构建的系统层。LangChain的博客标题直接说"The Harness is Moat"。

  2. 反向构建原则。从L6(部署)反向构建到L1(提示词),而非正向。原因:没有部署和测试的基础设施,你无法度量L1优化的效果——优化变成了盲人摸象。

  3. 测试是最大的鸿沟。当前大多数Agent团队的痛点不是"Agent不够聪明",而是"不知道Agent上线后会不会出问题"。四层测试栈(结构 → 轨迹 → 语义 → 回归)是当前最成熟的解决方案。

  4. 沙盒是刚需不是选配。任何需要Agent执行代码、访问文件系统或调用API的场景,都必须有沙盒隔离。2026年的趋势是Firecracker微VM成为标准底层,E2B和Daytona在其上构建开发者友好的抽象。

  5. AgentOps正在从可选变为必需。AgentOps.ai的两行代码接入降低了门槛,而Azure AI Foundry为企业提供了合规级方案。不接入可观测性的Agent,本质上是在"盲飞"。

场景化推荐

场景 推荐Harness栈 预算
个人开发者快速验证 OpenAI Agents SDK + E2B + AgentOps $50-100/月
初创公司首个Agent产品 LangGraph + Daytona + LangSmith $200-500/月
企业内部工具Agent AutoGen + Daytona自建 + Azure AI Foundry $2000-5000/月
面向C端的生产Agent LangGraph + E2B + LangSmith + 影子部署 $5000+/月
多Agent协作系统 LangGraph + Daytona + LangSmith + 金丝雀 $3000-8000/月

变现评估

Harness工程作为训练营/课程有极高潜力: - 受众明确:所有构建Agent应用的开发者都需要 - 实操性强:六层架构天然对应六个模块 - 差异化:市面大多数课程聚焦"怎么用Agent框架",而非"怎么让Agent可靠运行" - 预估市场规模:全球Agent开发者约200万,按5%转化率、$299单价计算,$3000万市场


参考来源

  1. Harness Engineering as Categorical Architecture — arXiv:2605.12239 — 形式化定义Harness四大支柱的范畴论架构
  2. The Anatomy of an Agent Harness — LangChain Blog — "Agent = Model + Harness"的系统性定义
  3. Harness design for long-running application development — Anthropic Engineering — 长时运行Agent的Harness设计原则
  4. Harness engineering: leveraging Codex in an agent-first world — OpenAI — OpenAI对Harness工程的实践指南
  5. Agent-Native CI/CD: Deployment Pipelines for AI Agent Systems — Zylos Research — Agent原生CI/CD的四种部署模式详解
  6. Top 5 Code Sandboxes for AI Agents in 2026 — DEV Community — 五大沙盒平台对比评测
  7. From Zero to Hero: AgentOps — Microsoft Azure Blog — 企业级Agent全生命周期管理指南

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入