生产级 Agent Harness 的五层架构

# 弹性生产 Harness 的五层架构

即使选用了世界上能力最强的模型，如果其周围的软件环境丢失状态或错误管理工具，你的 Agent 依然会失败。当 Agent 执行长周期任务、管理持久状态、在多个环境中运行代码时，可靠性已成为当今核心的系统挑战。Agent 开发的重心已转向围绕模型构建的确定性软件基础设施，这被称为 Harness 工程（Harness Engineering）。

作者：@tweetpraveen

以下是一个设计完善的 Harness 的五层架构，可将概率性模型转化为可靠的生产系统，以及你可以采取的若干行动：

## 1. 从"模型优先"转向"系统优先"架构。

Agent 的性能越来越取决于 Harness 中有效的编排、评估、上下文管理、防护栏和沙箱机制，而非底层模型本身。前沿模型提供原始认知能力，而 Harness 则提供确定性的轨道，使 Agent 在多步骤循环中不会脱轨。Firebase 团队近期一项关于评估驱动开发的基准研究表明，在完全相同的模型上，为 Agent 配备结构化的程序化工作流和工具脚手架，可将任务完成率从 31.7% 提升至 78.0%。(https://firebase.blog/posts/2026/08/eval-driven-development-agent-skills)

例如，Google Antigravity 是一个统一的 Agent Harness，将非确定性的模型认知与确定性的文件操作、并行工作树和工具执行相分离。对于我们这些对代码优先模式感兴趣的人来说，ADK 2.0（Agent Development Kit）提供了严格的契约边界和工具编排，使模型能够可靠地与环境 API 交互，而不会产生参数幻觉。(https://antigravity.google/) (https://adk.dev/2.0/)

## 2. 实现带检查点的持久状态。

上下文窗口是易失性的，在长时间运行中会变得嘈杂。完全依赖对话记忆意味着一次网络超时或服务器重启就会丢失多个步骤的进度。应在投入复杂的长期记忆之前，优先考虑持久执行和工作流检查点。将状态存入磁盘或数据库（如 contract.md、progress.md 或任务运行器）可确保：如果 Agent 在第 14 步崩溃，它能直接从该保存的快照恢复，而无需重新执行第 1 到第 13 步，也不会意外触发重复的、非幂等的工具调用。

对于 Google Cloud，Gemini Enterprise Agent Platform 的 Sessions 和 Memory Bank 提供原生的持久化会话存储，可在不连续的用户交互中维护对话历史、中间工具状态和长期记忆。Temporal.io 等平台已建立了持久执行的企业级黄金标准，保证 Agent 循环、重试和多日工作流能从确切的故障点自动恢复，而无需重放副作用。(https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/sessions) (https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/memory-bank)

## 3. 构建带角色分离的验证循环。

将 Agent 划分为三个独立角色，每个角色拥有各自隔离的系统提示词和上下文窗口，有助于在 Harness 中将循环隔离到不同的上下文边界：1) 规划者（Planner）起草技术规范，2) 生成者（Generator）编写代码，3) 评估者（Evaluator）在后台运行测试套件和代码检查器。

反重力测试驱动开发反射循环在工作树中自主运行本地构建和单元测试，将 stderr 和编译器错误日志直接反馈给智能体以进行自我修复。在语义验证方面，Gemini Enterprise 生成式 AI 评估服务使用智能体上下文窗口之外的自动化 AutoRater，在宣告任务完成之前对工具使用准确性、事实依据性和模式合规性进行评分。(https://codelabs.developers.google.com/automating-modernization-with-antigravity#0) (https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview)

## 4. 通过钩子和隔离运行时建立安全边界。

真正的安全必须在运行时执行层强制落实。执行框架应在工具调用触达 API 或数据库之前，以确定性方式对其进行拦截并检查参数。

在 Google 反重力中，PreToolUse 钩子在执行前拦截工具调用。它们根据严格的模式验证参数，执行默认拒绝的权限策略，并阻止未经授权的操作（例如破坏性的 bash 命令或任意文件写入），即使是被注入的智能体发出此类请求也不例外。与 Apigee AI 网关及 MCP 集成的 Model Armor 在网关层拦截提示词注入载荷，并在执行前对敏感 PII 进行脱敏处理。(https://antigravity.google/docs/hooks/) (https://docs.cloud.google.com/model-armor/model-armor-apigee-integration)

此外，自主代码执行必须被隔离。Cloud Run 使用 gVisor（一种安全的用户空间内核）对工作负载进行隔离，代码执行沙箱则提供隔离的运行时环境，防止智能体逃逸至宿主内核或危害生产 VPC。(https://docs.cloud.google.com/run/docs/container-contract) (https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/sandbox/code-execution-overview)

## 5. 记录结构化追踪以进行调试和自动化修复。

当智能体在运行数分钟后出现故障时，你无法通过重新运行提示词并期望好运来调试问题。生产级执行框架应在每个执行轮次记录结构化追踪，捕获精确的工具调用载荷、上下文大小和推理步骤，从而精准定位智能体偏离轨道的确切时刻。你甚至可以将这些结构化错误追踪直接反馈给 AI 编程智能体，由其诊断故障、生成回归测试并起草 PR。但请务必保持人工审核环节，在部署修复方案前进行审查，以避免架构随时间推移发生漂移。

Gemini Enterprise 智能体可观测性与 Cloud Trace 通过 ADK 和 Genkit 与 OpenTelemetry 等开放标准集成，为构建者提供对每个工具调用、延迟峰值和提示词变更的端到端 span 级可见性。(https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/observability/overview) (https://docs.cloud.google.com/gemini-enterprise-agent-platform/scale/runtime/tracing)

模型质量问题通常有办法绕过，但当智能体在生产环境中出现故障时，往往是因为周围的软件管道丢失了状态、上下文管理不当，或缺乏确定性的执行边界。构建一个具备弹性的状态机，将状态外化至存储层，独立进行验证，让模型专注于纯粹的推理。

你正在使用哪些架构模式来让你的智能体保持在护栏之内？欢迎在下方评论区交流讨论！👇