写在前面

  • 博文内容涉及通过认知 Agent Harness 与 Harness Engineering
  • 理解智能体怎么被约束、被观测、被评测、被回放”
  • 以及一些如何实现 Agent Harness 方法论
  • 一些场景Demo，和开源项目介绍
  • 理解不足小伙伴帮忙指正 😃,生活加油

我看远山，远山悲悯

持续分享技术干货，感兴趣小伙伴可以关注下 _

过去很长一段时间，大家讨论 AI Agent ，常常把注意力放在：

  • 模型够不够强；
  • 提示词写得好不好；
  • 工具调用会不会；
  • 多智能体编排炫不炫。

这些当然重要，但如果把一个 Agent 真正放进生产环境，很快就会发现另一个更硬的问题：

  • 它到底在什么环境里执行；
  • 它调用过哪些工具；
  • 它为什么做出这个决策；
  • 它失败时能不能复现；
  • 它越权时谁来拦住；
  • 它升级后效果到底是变好了，还是只是“看起来更聪明了”。

这时，问题已经不再是 Prompt Engineering，而开始进入 Harness Engineering。

如果把模型比作“智能体的大脑”，那么 Agent Harness 更像是它的飞控系统 + 黑匣子 + 地面管制台 + 测试台。Agent 能不能跑起来，取决于模型； Agent 能不能可控地跑、稳定地跑、可审计地跑，取决于 Harness。

一些术语

  • Agent Harness：围绕智能体执行过程构建的控制、观测、评测与治理系统。
  • Harness Engineering：设计、实现、运维和演进 Agent Harness 的工程实践。
  • Execution Harness：关注工具执行、运行时、隔离与生命周期管理的部分。
  • Policy Harness：关注权限、预算、审批、风控和合规的部分。
  • Telemetry Harness：关注 trace / metric / log / event 采集与关联的部分。
  • Evaluation Harness：关注 benchmark、回放、打分、回归验证的部分。
  • Replay：基于固定输入和受控环境重放一次历史任务。
  • Shadow Evaluation：线上真实流量不直接影响结果，只做旁路评测。
  • Human-in-the-Loop：人在关键节点参与确认、纠偏或审批。
  • Taint-style vulnerability：由不可信输入穿透到敏感操作链路所形成的污染式漏洞。

一、为什么 Agent 正在进入 Harness 时代

过去一年多，学界和工业界已经用大量基准说明了一件事：Agent 的难点不只是答案生成，而是和真实环境交互时的长链路执行能力。

AgentBench（ICLR 2024）提出了一个跨 8 类交互环境的统一评测框架，核心关注点已经不是静态问答，而是推理、决策、环境反馈和多轮动作的联动。

WebArena 进一步把问题带到了真实网页操作环境里。论文中，最佳 GPT-4 风格基线在端到端任务成功率上只有 14.41%，而人类是 78.24%。这说明“会说”距离“会做”还有很长一段路。

VisualWebArena 把视觉接地问题也纳入进来，强调很多网页任务不是纯文本规划问题，而是视觉识别 + 交互执行 + 状态跟踪的组合问题。

OSWorld 则把环境进一步扩展到真实桌面与多操作系统，包含 Ubuntu、Windows、macOS。在 369 个真实计算机任务上，人类成功率超过 72.36%，最佳模型只有 12.24%。

到了软件工程场景，SWE-bench 说明问题更尖锐：Agent 不是生成一段代码就结束，而是必须在真实仓库里读代码、改代码、跑测试、看失败、继续迭代。也正因此，SWE-bench 自己就内置了一整套 evaluation harness。

WorkArena（ICML 2024）又把场景拉回企业知识工作流，告诉我们：即便是表单、工单、知识库、列表筛选这些“看上去不难”的业务界面，现阶段智能体距离完全自动化依然有明显差距。

这些工作共同说明了一件事：

  • Agent 的主战场，已经从“单轮生成”迁移到“真实环境中的可执行系统”；
  • 一旦进入真实环境，系统的瓶颈就会从模型能力转移到执行控制、状态管理、观测审计、回放评测与安全治理；
  • 这套东西，单靠 Prompt 是补不上的。

换句话说，Agent 时代真正缺的，不只是更强模型，而是一套围绕执行、约束、观测和评估构建出来的管控外骨骼。

二、两个词先说清：什么是 Agent Harness，什么是 Harness Engineering

先说明一点：Agent Harness 和 Harness Engineering 目前还不是像 Transformer、Kubernetes 那样已经被严格标准化的学术名词。这里我给出的是一个更贴近工程实践的定义。

2.1 Agent Harness

我更倾向于把 Agent Harness 理解成：

围绕智能体执行过程构建的一层控制与观测系统，用来统一管理 上下文、工具、运行环境、策略约束、遥测数据、评测回放 与 生命周期。

它不是模型本身，也不是单一的工作流引擎，更不是某个具体的 Agent Framework。
它是把这些东西串起来并管起来的那一层。

一个最小可用的 Agent Harness，通常至少包括下面几件事：

  • Invocation：谁在调用这个 Agent，请求入口是什么；
  • Context：给模型看哪些上下文，哪些不能看；
  • Tools：有哪些工具能用，工具契约是什么；
  • Runtime：代码、浏览器、文件系统、网络在什么隔离环境里执行；
  • Policy：预算、审批、权限、速率限制、越权拦截怎么做；
  • Telemetry：每一步调用、耗时、报错、消耗、轨迹如何记录；
  • Evaluation：结果如何回放、如何打分、如何做回归对比。

2.2 Harness Engineering

Harness Engineering 则是：

针对 Agent Harness 的设计、实现、运维与持续演进所形成的一套工程方法论。

它关心的不是“模型会不会调用工具”，而是：

  • 工具调用如何被标准化；
  • 会话如何被隔离；
  • 决策如何被追踪；
  • 失败如何被复现；
  • 性能如何被优化；
  • 风险如何被治理；
  • 升级如何被验证。

所以，Harness Engineering 并不是 Prompt Engineering++。
它更像是 AI Agent 时代的 Platform Engineering + SRE + Security Engineering + Evaluation Engineering 的交叉体。

三、Agent Harness 到底在“管”什么

很多团队第一次做 Agent 时，会把 Harness 理解成“沙箱”或者“工具注册表”。这太窄了。

真正的 Agent Harness，至少同时在管下面七件事。

3.1 管能力边界

一个 Agent 可怕的地方，不是它会输出错误答案，而是它开始真的能做事：

  • 发请求；
  • 改文件；
  • 下命令；
  • 调数据库；
  • 操作浏览器；
  • 触发外部系统动作。

所以第一层管理一定是能力面收缩：

  • 哪些工具可见；
  • 哪些参数可传；
  • 哪些域名可访问；
  • 哪些动作需要审批；
  • 哪些调用需要预算上限。

这本质上是把“语言能力”翻译成“受约束的执行能力”。

3.2 管执行环境

Agent 一旦进入代码执行、浏览器执行、桌面操作，就必须要有运行时隔离。

这里的运行时未必只有一种：

  • 低风险任务可以是受限容器；
  • 中风险任务可以是增强型容器；
  • 高风险任务可能要上 MicroVM；
  • 多工具协同任务则可能要使用 All-in-One Sandbox。

注意：Sandbox 只是执行面的隔离单元，Harness 则是把这些执行单元纳入统一生命周期管理的系统。
Sandbox 解决“怎么安全跑”，Harness 解决“怎么可控地调度、审计、回收、评测这些执行单元”。

3.3 管上下文与状态

很多 Agent 失控，不是因为模型太弱，而是因为上下文太乱。

比如：

  • 历史消息无限膨胀；
  • 工具输出直接原样塞回上下文；
  • 记忆没有版本边界；
  • 敏感凭据进入了长期记忆；
  • 一个会话的脏状态污染了下一个任务。

因此，Harness 还要负责：

  • 会话切分；
  • 记忆写入与失效策略；
  • 上下文裁剪；
  • 结构化中间态沉淀；
  • 敏感数据脱敏。

3.4 管策略与审批

真正可上线的 Agent，几乎都不可能是“完全自由行动”的。

你迟早会遇到这些问题：

  • 发邮件前要不要二次确认；
  • 提交代码前要不要过测试阈值；
  • 创建工单前要不要校验工单模板；
  • 消耗预算超过阈值时要不要停止；
  • 调用高风险工具前要不要人工批准。

这意味着 Harness 里必须有策略层：

  • allow / deny / ask 三态决策；
  • 预算门控；
  • 风险分级；
  • 人在回路（Human-in-the-Loop）；
  • 审批记录与审计链路。

3.5 管遥测与可观测性

如果没有轨迹数据，Agent 的线上问题基本无法排。

OpenTelemetry 已经开始为 GenAI 定义专门的语义约定，覆盖：

  • Agent spans
  • Model spans
  • Events
  • Metrics
  • MCP 相关语义约定

这其实是一个非常强的信号：Agent 不再只是应用逻辑，而正在进入标准化可观测体系。

没有这些数据，你就无法回答：

  • 哪一步最慢；
  • 哪个工具最容易失败；
  • 哪个模型版本更贵；
  • 哪类任务最容易触发回退；
  • 哪次执行为什么越权。

3.6 管评测与回放

这件事经常被低估。

很多团队做 Agent，上线前只看几条人工案例，感觉“能用”，就发布了。然后一升级模型、改一个提示词、换一个工具实现，系统行为就漂了。

所以 Harness 必须内建：

  • 基准任务集；
  • 固定输入与期望输出；
  • 执行轨迹回放；
  • 自动打分；
  • 版本间回归对比；
  • Shadow Evaluation。

这也是为什么像 HELM、SWE-bench、AgentBench、WebArena、OSWorld 这些工作如此重要。
它们真正贡献的，不只是榜单，而是可重复评测的 harness 思维。

3.7 管资源与调度

当 Agent 从单次调用变成海量任务流之后，另一个问题会突然出现：程序级调度。

Parrot（OSDI 2024）指出，今天很多公共 LLM 服务只会优化单个请求，丢失了多步工作流的应用级信息，于是端到端体验并不好。

Agentix（NSDI 2026）更进一步，直接把 Agentic Program 当成一等公民来调度，论文里在相同延迟下实现了 4-15x 的程序吞吐提升。

这说明一件事：
一旦 Agent 真正进入生产，调度单元已经不该只是“单个模型请求”，而应该是“带依赖关系的智能体程序”。

四、一个更工程化的理解：Harness 不是组件，而是三条闭环

我更喜欢把 Harness 看成三条同时运行的闭环，而不是一个静态模块集合。

4.1 执行闭环

目标输入
  -> 规划
  -> 调用模型
  -> 选择工具
  -> 执行环境反馈
  -> 修正计划
  -> 产出结果

这是大家最熟悉的一条环。

4.2 治理闭环

动作申请
  -> 风险判断
  -> 权限校验
  -> 预算检查
  -> 审批/拒绝/降级
  -> 审计留痕

这条环决定它是不是“能被放心地上线”。

4.3 评测闭环

采集真实轨迹
  -> 建立基准集
  -> 回放执行
  -> 自动评分
  -> 对比版本
  -> 反哺提示词/工具/策略/模型选择

这条环决定它是不是“能持续演进，而不是越改越玄学”。

所以，所谓 Harness Engineering，本质上就是在构建并打通这三条闭环。

五、一个可落地的 Agent Harness 参考架构

如果从系统视角看，一个比较清晰的拆法通常是控制平面 + 执行平面 + 评测平面。

控制平面负责：

  • Agent 注册与版本管理；
  • 工具注册与权限模型；
  • 策略下发；
  • 会话生命周期；
  • 配额、预算、审批；
  • 模型/路由选择。

执行平面负责：

  • 模型调用；
  • 工具执行；
  • Sandbox / Browser / IDE / MCP 运行时；
  • 文件系统与网络访问；
  • Artifact 存储；
  • 中间状态持久化。

评测平面负责：

  • Benchmark 数据集；
  • 回放器；
  • Judge / Rule-based Scorer；
  • 回归报表；
  • 线上轨迹抽样；
  • 离线复盘。

可以用一张简化链路图来理解：

用户/上层系统
    -> Agent API / Session API
    -> Context Manager / Planner / Router
    -> Policy Engine / Approval Gate / Budget Gate
    -> Tool Registry / Sandbox / Browser / MCP Runtime
    -> Trace / Metrics / Logs / Artifact Store
    -> Replay / Benchmark / Judge / Regression Report

很多框架只覆盖了这里面的某一段。 真正成熟的 Harness，关键不是“某个模块先进”，而是这些模块之间能不能形成稳定的控制链路。

六、Harness Engineering 的五个核心工程问题

6.1 第一个问题：怎么把 Agent 从“函数调用器”变成“受控程序”

Parrot 和 Agentix 其实都在回答同一个问题： Agent 不该再被看成一串彼此独立的 LLM API 调用，而应该被看成有依赖、有状态、有程序结构的执行体。

这意味着工程上要做三件事：

  • 让工具调用变成结构化动作，而不是自然语言猜测；
  • 让中间状态变成可持久化对象，而不是只存在上下文窗口；
  • 让调度器理解程序依赖，而不是只理解单请求队列。

很多团队在 Agent 性能上遇到瓶颈，本质不是模型慢，而是系统把程序当成了请求，把工作流当成了聊天。

6.2 第二个问题：怎么把 Agent 从“黑盒推理”变成“可观测执行”

OpenTelemetry 已经开始定义 GenAI agent spans、invoke_agent、execute_tool 以及 gen_ai.client.operation.duration 这样的语义和指标。

这背后非常关键的一点是，Agent 的问题排查，必须从“看聊天记录”升级到“看分布式追踪”。

工程上至少要落这几类数据：

  • 每次模型调用的 trace_id / span_id
  • 每次工具调用的输入、输出、耗时、错误类型
  • 每个会话的 token、成本、时延、重试次数
  • 每个动作的策略判定结果
  • 每个任务的最终完成状态与失败归因

没有这些数据，Agent 系统就很难从实验品变成生产系统。

6.3 第三个问题：怎么把 Agent 从“看起来有效”变成“被证明有效”

HELM 给传统语言模型评测带来的启发很重要，评测不能只看一个指标，也不能只挑自己擅长的任务，更不能没有统一适配标准。

到了 Agent 时代，这个问题更严重，因为任务更动态、环境更复杂、奖励设计更脆弱。

NeurIPS 2025 的 Agentic Benchmark Checklist 直接指出，很多 agentic benchmark 在任务设置或奖励设计上存在问题，甚至可能让性能被高估或低估到 100% 的相对量级。

所以在 Harness Engineering 里，评测要坚持三条原则：

  • 不只看最终答案，也看过程质量；
  • 不只看离线样例，也看真实环境回放；
  • 不只看平均分，也看失败模式。

6.4 第四个问题：怎么把 Agent 从“能调用工具”变成“不会被工具反噬”

安全问题不是附属问题，而是 Harness 的核心组成部分。

USENIX Security 2025 的 AgentFuzz 说明，LLM-based Agents 对 taint-style vulnerabilities 很敏感。论文在 20 个开源智能体应用上找到了 34 个高风险 0-day 漏洞，并已有 23 个 CVE 分配。

这意味着：

  • 工具参数污染不是理论问题；
  • 越权执行不是理论问题；
  • 恶意提示词穿透策略层不是理论问题；
  • 审计缺失会把小问题变成不可追责的大问题。

所以 Harness 里的策略系统，不能只是 prompt guardrail，还要有：

  • 参数级校验；
  • 输出级过滤；
  • side effect 分级；
  • 高风险动作审批；
  • 审计日志与证据留存。

6.5 第五个问题：怎么把 Agent 从“单次成功”变成“持续可靠”

一次任务跑通，不代表系统成熟。真正成熟的 Harness Engineering，最终会收敛到这几个工程能力：

  • 同一任务能重复跑出稳定结果；
  • 失败可以回放并定位；
  • 升级模型/提示词/工具后能做回归；
  • 高风险动作可阻断；
  • 性能瓶颈可观测；
  • 成本漂移可监控。

本质上，Harness Engineering 做的是把 Agent 从“概率性灵感系统”，变成“可运营的软件系统”。

七、一个判断标准：什么阶段算进入了 Harness Engineering

如果你的团队还停留在下面这些状态：

  • 本地脚本 + 一个 Agent Framework
  • 出问题靠看控制台日志
  • 模型升级靠拍脑袋
  • 线上失败无法复现
  • 安全策略靠提示词提醒

那你们还在“把 Agent 跑起来”的阶段。而当你们开始具备下面这些能力时，才算真正进入 Harness Engineering：

  • 每个任务有稳定 session id / trace id
  • 工具调用有结构化事件流
  • 执行环境有隔离和回收策略
  • 高风险动作有策略门控
  • 有固定 benchmark 和回放集
  • 每次升级都能出回归报告
  • 成本、时延、成功率能按模型/工具/任务拆分

这时你管理的，已经不是“一个智能体”，而是一套智能体生产系统。

八、怎么落地一个最小可用的 Agent Harness

如果现在从零开始，不要一上来就追求“大而全平台”，先把下面这些最小能力做出来。

8.1 第一阶段：最小闭环

  • 为每次任务生成 session_id
  • 为每次模型/工具调用生成 trace_id
  • 工具统一经过注册表，不允许随手直连
  • 所有副作用动作默认记录输入、输出、耗时、状态
  • 代码执行与浏览器执行默认进入隔离环境

8.2 第二阶段：最小治理

  • 做一个简单的 allow / deny / ask 策略引擎
  • 给工具加风险等级
  • 给任务加预算和超时
  • 给敏感动作加人工确认
  • 做基础审计报表

8.3 第三阶段：最小评测

  • 挑 20-50 个最典型任务组成回放集
  • 固定输入、环境、工具版本
  • 做版本间成功率、成本、耗时对比
  • 失败任务自动抽样进入人工复盘池

到这一步，系统就已经和“只有框架、没有管控”的 Agent Demo 拉开差距了。

九、具体的 Demo

上面讲的是方法论，下面补几个更贴近工程落地的 Demo。
这几个 Demo 不一定是完整生产代码，但都能直接映射到真实 Harness 的关键能力。

9.1 Demo 一：一个最小可用的 Tool Harness

这个 Demo 解决的不是“怎么让模型会调工具”，而是“怎么让模型在调工具时留下可观测、可审批、可回放的轨迹”。

import time
import uuid
from dataclasses import dataclass


@dataclass
class ToolCall:
    name: str
    args: dict


class ToolRegistry:
    def __init__(self):
        self._tools = {}
        self._risk = {}

    def register(self, name, fn, risk="low"):
        self._tools[name] = fn
        self._risk[name] = risk

    def get(self, name):
        return self._tools[name]

    def risk(self, name):
        return self._risk[name]


class PolicyEngine:
    def decide(self, tool_name, args, budget_left):
        if budget_left <= 0:
            return "deny"
        if tool_name in {"send_email", "merge_pr", "run_shell"}:
            return "ask"
        return "allow"


class Tracer:
    def log(self, session_id, span_type, payload):
        print({
            "session_id": session_id,
            "span_type": span_type,
            "ts": time.time(),
            **payload,
        })


def run_harness(agent, user_input, registry, policy, tracer):
    session_id = str(uuid.uuid4())
    budget_left = 5

    tracer.log(session_id, "agent.start", {"input": user_input})
    tool_call = agent.plan(user_input)   # 返回 ToolCall(name, args)
    tracer.log(session_id, "tool.plan", {"tool": tool_call.name, "args": tool_call.args})

    decision = policy.decide(tool_call.name, tool_call.args, budget_left)
    tracer.log(session_id, "policy.decision", {"tool": tool_call.name, "decision": decision})

    if decision == "deny":
        return {"status": "blocked", "reason": "policy_denied"}
    if decision == "ask":
        return {"status": "pending_approval", "tool": tool_call.name}

    tool = registry.get(tool_call.name)
    start = time.time()
    try:
        output = tool(**tool_call.args)
        tracer.log(
            session_id,
            "tool.result",
            {
                "tool": tool_call.name,
                "latency_ms": int((time.time() - start) * 1000),
                "status": "ok",
                "output": str(output)[:500],
            },
        )
        return {"status": "ok", "result": output}
    except Exception as e:
        tracer.log(
            session_id,
            "tool.result",
            {
                "tool": tool_call.name,
                "latency_ms": int((time.time() - start) * 1000),
                "status": "error",
                "error": repr(e),
            },
        )
        return {"status": "failed", "error": repr(e)}

这个示例虽然简单，但已经有了 Harness 的几个最小原语：

  • Tool Registry
  • Policy Engine
  • Trace / Span
  • Session ID
  • Approval Gate

也就是说，真正重要的不是“模型会不会调工具”，而是每次工具调用都必须先经过 Harness。

9.2 Demo 二：BrowserGym 跑一个可回放的 Web Agent 任务

如果你想做 Web Agent Harness，我很建议直接从 BrowserGym 入手。
它本身就是一个把 MiniWoB、WebArena、VisualWebArena、WorkArena 等 benchmark 收进统一接口的开源环境。

官方给出的 demo agent 启动方式是：

# openended
python demo_agent/run_demo.py --task_name openended --start_url https://www.google.com

# WorkArena
python demo_agent/run_demo.py --task_name workarena.servicenow.order-standard-laptop

# WebArena
python demo_agent/run_demo.py --task_name webarena.4

# VisualWebArena
python demo_agent/run_demo.py --task_name visualwebarena.398

这个 Demo 的价值在于：

  • 你不需要自己从零搭网页环境；
  • 能统一比较不同模型、不同提示词、不同浏览器策略；
  • 能天然进入 Replay + Benchmark + Trace Analysis 工作流。

如果文章里的 Harness 要落实到浏览器智能体，这就是最适合起步的一类实验基座。

9.3 Demo 三：AIO Sandbox 搭一个统一工作区 Harness

如果你的核心不是“只跑一个工具”，而是让 Agent 在 Browser + Shell + File + MCP + IDE 之间连续工作，那么 AIO Sandbox 这种一体化沙箱会更合适。

它的最小启动方式很直接：

docker run --security-opt seccomp=unconfined --rm -it -p 8080:8080 ghcr.io/agent-infra/sandbox:latest

跑起来后，浏览器、VSCode Server、终端、文件接口、MCP 服务都在同一个会话里。它的 Python SDK 用法也比较直观：

from agent_sandbox import Sandbox

client = Sandbox(base_url="http://localhost:8080")

result = client.shell.exec_command(command="ls -la")
print(result.data.output)

content = client.file.read_file(file="/home/gem/.bashrc")
print(content.data.content)

screenshot = client.browser.screenshot()

这个 Demo 很适合做下面这类实战验证：

  • 浏览器下载的文件，终端能不能立即看到；
  • Agent 改完代码，能不能直接在同一工作区运行；
  • MCP Tool 与 Shell Tool 是否共享同一份上下文；
  • 同一个 session 是否能被回放与审计。

十、贴近上线的生产/实战案例

10.1 软件工程智能体：OpenHands + OpenHands Benchmarks

如果你想看最接近“生产级软件工程 Agent” 的开源路线，OpenHands 很值得持续关注。 它已经不只是一个聊天式代码助手，而是在朝着CLI + 本地 GUI + Cloud + Enterprise 的完整产品形态走。

更关键的是，OpenHands 还有单独的 OpenHands/benchmarks 仓库，把评测基础设施拆了出来，当前覆盖：

  • SWE-Bench
  • GAIA
  • Commit0
  • OpenAgentSafety

这件事很重要，因为它说明一个成熟 Agent 项目，最终都会把 evaluation harness 从“零散脚本”升级成独立工程。如果你的场景是：

  • 读仓库
  • 改代码
  • 跑测试
  • 提交补丁
  • 回归评测

那么 OpenHands + SWE-Bench 风格 harness 基本就是最贴近实战的参考样板之一。

10.2 浏览器智能体：browser-use 从本地实验到托管基础设施

browser-use 的定位很清楚：让网站对 AI Agent 可操作。
它开源部分适合本地开发和能力验证，而它自己的 Cloud 又在往生产浏览器基础设施方向走，直接处理：

  • 浏览器持久化
  • 认证状态
  • Cookies
  • 浏览器与 Agent 共置带来的低时延
  • 并行浏览器管理
  • 指纹与代理相关问题

这类项目的价值不在于“它又是一个 Agent 框架”，而在于它已经开始把浏览器智能体真正麻烦的工程细节产品化。

所以如果你的目标是：

  • 电商下单
  • 表单填写
  • 后台工单流转
  • 跨站点检索与操作

那 browser-use 更像是浏览器智能体的执行层，而 BrowserGym / WorkArena 更像是它的评测层。两者结合起来，才比较接近完整 Harness。

10.3 观测与评测控制面：Langfuse / Phoenix / OpenLIT

很多团队到了生产阶段，最先补的其实不是新模型，而是观测面板。当前比较值得看的开源路线有三条：

  • Langfuse：更像开源 LLM engineering platform，覆盖 tracing、metrics、evals、prompt management、datasets；
  • Phoenix：更强调 OpenTelemetry-based tracing + evals + datasets + experiments；
  • OpenLIT：强调 OpenTelemetry-native，把 LLM observability、GPU monitoring、guardrails、evaluations 放在一起。

这三类系统共同说明一件事： Agent Harness 不只是运行系统，还要有一个能看、能比、能回放的控制面。

十一、当前值得关注的一些开源方案

如果只看今天比较值得关注的开源方案，我会按下面几类来记。

11.1 编排与状态管理

  • LangGraph：强项是 durable execution、human-in-the-loop、持久化状态与长流程编排，适合做状态型 Agent 的骨架。
  • AutoGen：多智能体协作框架代表之一，生态成熟，但官方也已明确建议新用户关注更新的 Microsoft Agent Framework 路线。
  • CrewAI：偏多角色协作与企业流程编排，Crews + Flows 的组合比较适合业务自动化场景。
  • OpenHands：更偏软件工程执行体，不只是框架，而是正在形成完整产品与 benchmark 体系。

11.2 浏览器与环境 Harness

  • BrowserGym：最适合做 web agent 的 benchmark 与 replay 底座。
  • browser-use：更适合做浏览器执行层与自动化落地。
  • AIO Sandbox：适合做统一工作区、一体化工具环境。
  • Microsandbox：适合高风险代码执行场景，主打 microVM、自托管与硬隔离。

11.3 可观测性、评测与治理

  • Langfuse：适合从 tracing 一路走到 eval、dataset、prompt 管理。
  • Phoenix：适合偏研究和偏工程混合的实验、回放与观测。
  • OpenLIT：适合希望直接拥抱 OpenTelemetry-native 方案的团队。
  • LiteLLM：虽然本质是 gateway / proxy，但对 Harness 很关键，因为它补的是模型路由、成本追踪、鉴权、负载均衡与日志这一层。
  • OpenTelemetry GenAI Semantic Conventions：这不是产品，但我认为它是未来 Agent Harness 最重要的底层标准之一。

11.4 Benchmark 与评测基座

  • SWE-bench
  • BrowserGym
  • WebArena
  • VisualWebArena
  • WorkArena
  • OSWorld
  • AgentBench
  • OpenHands/benchmarks

如果一定要给一个很现实的建议，我会这么选：

  • 做 Software Agent：优先看 OpenHands + SWE-bench + Langfuse/Phoenix
  • 做 Web Agent：优先看 BrowserGym + browser-use + Langfuse/OpenTelemetry
  • 做 Code Execution Agent：优先看 Microsandbox/AIO Sandbox + LiteLLM + Eval Harness
  • 做企业内部流程自动化：优先看 LangGraph/CrewAI + Policy Harness + Audit Trail

十二、一些常见误区

最后补几个特别常见的误区。

  • 把 Agent Framework 当成 Agent Harness：框架主要解决开发体验，不天然等于治理系统。
  • 把 Sandbox 当成 Harness：沙箱只解决执行隔离，不解决策略、观测、评测与回放。
  • 只看最终答案，不看执行轨迹：这样会把大量过程性错误隐藏掉。
  • 只做离线 benchmark，不看线上回放：很多真实故障都来自环境噪声、状态污染和长尾工具失败。
  • 让同一个 Agent 既做执行者又做裁判：没有外部评测 harness，系统很容易自我强化幻觉。
  • 把安全寄托在 prompt 上：真正的控制必须落到参数校验、权限系统和运行时门控上。

十三、总结

Agent Harness 解决的不是“智能体会不会做事”，而是“智能体做事时，系统能不能看得见、拦得住、放得稳、复得现、评得准”。而 Harness Engineering，就是把这套能力工程化。今天很多团队已经不缺 Agent Demo 了，真正稀缺的是：

  • 能把 Agent 放进真实环境运行的执行系统；
  • 能把 Agent 行为完整记录下来的观测系统；
  • 能把 Agent 风险收住的治理系统；
  • 能把 Agent 演进过程量化验证的评测系统。

所以我更愿意把 2025-2026 看成 Agent Harness 开始成形的时间点。 模型还在继续进步，但真正决定智能体能否大规模落地的，很可能不只是下一个更强模型，而是谁先把 Harness Engineering 做对。

博文部分内容参考

© 文中涉及参考链接内容版权归原作者所有，如有侵权请告知 😃

Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

cover

AgentScope Java 2.0 集成生态全景解析：构建企业级智能体系统的集成之道

avatar CSDN-OPC开发者社区
cover

用 kas fragment 最小改动定制 IoT2050 官方镜像：集成 open62541（OPC UA）

avatar CSDN-OPC开发者社区
cover

一人公司应该用 ChatGPT，还是使用 AI Agent？

avatar CSDN-OPC开发者社区