让AI走出屏幕：Agnes Harness 开源，把「Agent执行」与「物理设备」焊进同一套体系
让 AI 真正走出屏幕、走进现实，需要三样东西：一颗足够可靠的大脑，一套能组织它持续工作的执行系统，以及一个能连接物理设备的身体。过去两年，模型能力突飞猛进，Agent 执行框架也层出不穷，但大多数人仍然被一个不起眼的问题卡住——现实世界里形态各异的设备，到底该怎么被一个 Agent 理解、调用和协同？
最近，Agnes AI 给出了自己的回答：正式开源 Agnes Harness（AGH）——一套面向真实任务的 Agent 执行基础设施，同时开放了 MHS（Model Hardware Standard） 设备交互协议及相关组件，还预告了新一代模型 Agnes 3.0 Pro 的能力升级与即将上线的 API。
这不像一次普通的框架发布，它更像是 Agnes AI 在刻意传递一个信号：Agent 的下一个战场，不只在屏幕里的对话框，而在屏幕外的物理世界。 这篇文章，我想带你完整拆解这套开源体系——先搞懂什么叫"Agent Harness"，再看 AGH 如何组织一次持续的真实任务，然后深入 MHS 这套"设备听得懂的协议"到底做了什么，接着用代码演示 Agent 和物理设备接入的工程细节，最后聊聊 Agnes 3.0 Pro 与"从模型到基础设施"这条路的战略意义。
一、先搞懂：为什么 Agent 需要一个"Harness"
在深入 AGH 之前，得先回答一个更基础的问题：什么是 Agent Harness？为什么现代 Agent 离不开它？
如果你把大模型比作"大脑"，那么一个真正能干活、能持续处理多步骤任务的 Agent，需要的远不止一个会思考的模型。它还需要：持续运行的循环（模型想一步、动手一步、看结果、再想下一步）、调用外部工具的通道（读文件、跑命令、调 API、连 MCP）、跨步骤的记忆与会话管理（任务做到一半，别把前面的上下文丢了）、上下文的压缩与整理，以及对关键操作的人工确认机制。
把这些"除了模型思考之外的一切支撑"打包起来的东西，就是 Harness。用一句很形象的话说：Harness 是你围绕模型构建的一切，用来把它从一个"文本生成器"变成能在真实世界里行动的 Agent。 在 Agent 工程里，构建 Harness 的难度，很多时候已经超过了选择模型本身的难度——模型每年都在换代，而真正决定一个 Agent 能不能稳定、持续、安全地把活干完的，恰恰是那套不起眼却处处关键的"执行底座"。
从更宏观的视角看，Agent 生态里其实已经出现了两条路线：一条是"托管式 Harness"（比如 AWS 的 AgentCore，把编排循环、工具执行、记忆、沙箱打包成即开即用的托管服务）；另一条是"开源 Harness"（就像这次 Agnes 开源的 AGH，把源码和协议完全交到开发者手里，你可以装到本地、按需扩展）。开源路线的价值在于可移植、可插拔、可审计——你能看清每一层在做什么，也能把自己的工具、自己的硬件接进同一套体系。AGH 的与众不同，正在于它把"软件工具"和"物理设备"这两个原本割裂的接入，放进了同一套执行环境里。
二、AGH 的日常：一个"Agent Loop"如何组织一次真实任务
我们先不看那些抽象的架构术语，直接看 AGH 作为一个"能用的 Harness"，在日常里是怎么工作的。
AGH 的 Web 工作台打开后，是一个运行在本地环境中的对话界面。你可以指定一个工作目录，发送一条任务指令，然后看着 Agent 去读取文件、执行命令、根据结果继续修改已有的工程。这一切，都由 AGH 的核心机制——Agent Loop——持续推进。
Agent Loop 的工作方式其实是这样一个朴素而强大的循环：
┌──────────────────────────────────────────────────────────────┐
│ AGH 的 Agent Loop │
│ │
│ ┌──────────┐ 判断下一步 ┌──────────────┐ │
│ │ 模型 │ ──────────────────► │ 选择动作/工具 │ │
│ │ (大脑) │ └──────┬───────┘ │
│ └────▲─────┘ │ │
│ │ ▼ │
│ │ ┌──────────────┐ │
│ 把结果交回│ │ Harness 执行 │ │
│ 模型 │ │ 调用工具/命令 │ │
│ │ └──────┬───────┘ │
│ │ │ 执行反馈 │
│ └─────────── 直到任务结束 ─────────────┘ 或需人工介入 │
└──────────────────────────────────────────────────────────────┘
在这个循环里，模型负责"想"，Harness 负责"做"：模型判断下一步该做什么，Harness 调用对应的工具、执行命令，再把执行结果交回给模型，模型据此判断下一步……如此往复，直到任务结束，或遇到需要人工介入的关键步骤。
这个循环本身并不稀奇，很多 Agent 框架都有。但 AGH 有两点设计值得单独拿出来说。
第一，是"轨迹"的可回溯性。 当任务变得复杂（比如一个 Agent 改了十几个文件、执行过多次命令，最终却没通过测试）时，你很难光看对话记录就判断"是哪一步出了问题"——是模型判断失误，还是某个工具执行失败？AGH 的「轨迹」页面给了答案：开发者可以沿着时间轴回看任务执行全过程，看到模型调用了什么工具、每个步骤执行了多久，展开具体记录还能检查工具参数与执行状态。这种"过程可审计"的能力，是 Agent 从玩具走向生产的必备条件。
第二，是"插件 + Skills"的扩展机制。 AGH 开放了插件扩展：你可以通过插件接入自己的业务工具，利用 MCP 连接已有服务，甚至针对不同岗位开发专属界面。更妙的是"Skills"——已经验证过的任务方法可以通过 Skills 保留下来，并在其他项目中继续复用。你可以把它理解成"把一次成功的干活经验，固化成一个可复用的技能包"，这大大降低了重复搭建的成本。
我再用一小段 Python 概念代码，帮你具象化"Agent Loop + 工具反馈"到底在发生什么：
# agent_loop.py
# 概念化演示 AGH 的 Agent Loop：模型决策 → 工具执行 → 反馈回传
class ToolRegistry:
"""一个极简的工具注册表：名字 → 可调用函数"""
def __init__(self):
self._tools = {}
def register(self, name, fn):
self._tools[name] = fn
def call(self, name, **kwargs):
if name not in self._tools:
return {"ok": False, "error": f"unknown tool: {name}"}
try:
return {"ok": True, "result": self._tools[name](**kwargs)}
except Exception as e:
return {"ok": False, "error": str(e)}
def run_agent_loop(model_decision, registry: ToolRegistry, initial_state):
"""直到模型判定任务完成或达上限，否则持续 决策→执行→反馈"""
state = initial_state
for step in range(10): # 上限10步，防止死循环
intent = model_decision(state) # 模型判断下一步
if intent["done"]:
print(f"[DONE] step={step}")
return state
feedback = registry.call(intent["tool"], **intent.get("args", {}))
state = {**state, "last_feedback": feedback} # 反馈回传模型
print(f"[STEP {step}] tool={intent['tool']} ok={feedback['ok']}")
print("[STOP] reached step cap")
return state
# 模拟：模型的三步决策 + 两个工具
def decide(state):
plan = {0: {"tool": "read_file", "args": {"path": "src/main.py"}},
1: {"tool": "run_cmd", "args": {"cmd": "go build ./..."}},
2: {"done": True}}
return plan.get(state.get("step", 0), {"done": True})
reg = ToolRegistry()
reg.register("read_file", lambda path: f"read {path} (24 lines)")
reg.register("run_cmd", lambda cmd: f"exec {cmd} -> exit 0")
result = run_agent_loop(decide, reg, {"step": 0})
# 输出示例：
# [STEP 0] tool=read_file ok=True
# [STEP 1] tool=run_cmd ok=True
# [DONE] step=2
这个极简演示想说明的是：Harness 的本质，就是把"模型想、机器做、结果反馈回来"这个循环，做成可靠、可审计、可打断的基础设施。 AGH 里的真实实现远比我这段复杂得多，但骨架就是这样——这也是所有 Agent 能"持续干活"的根基。
三、重头戏 MHS：让一个从没见过的设备，也能被 Agent 理解
如果说 AGH 解决的是"Agent 如何持续执行任务"，那么 MHS（Model Hardware Standard） 解决的则是那个更难的问题：Agent 如何连接物理世界里那些形形色色的设备。
现实世界设备五花八门：移动小车、机械臂、传感器、气闸、飞行器……每种设备都有自己的接口、自己的控制方式。如果 Agent 每连接一种新设备，都要为它专门写一套适配代码，那 Agent 连接物理世界的成本会高到无法落地。MHS 想做的一件事很朴素也很深刻：通过统一的交互方式，让设备向 Agent 提供自己的"功能和操作信息"，这样智能体在面对一个从没见过的设备时，也能理解它的能力，并根据任务要求调用相应的操作。
你可以把 MHS 类比成"Agent 世界的 USB 协议"：USB 让各种各样的外设能被电脑即插即用、无需为每种设备都写底层的设备驱动理解；MHS 想让各种各样的硬件能被 Agent"即插即用"地理解和调用——设备只要"会说 MHS 这种统一的语言"，Agent 就能读懂它、操纵它。
MHS 并不是孤立的，Agnes 把它和另一套协议 MOS（Model Operating Standard） 一起设计。这两者各司其职：
┌────────────────────────────────────────────────────────────────┐
│ Agnes 设备协议体系 │
├───────────────────────┬────────────────────────────────────────┤
│ MHS (Model Hardware │ 负责「动作层」：设备状态、工具调用、 │
│ Standard) 1.0 │ 动作请求 │
├───────────────────────┼────────────────────────────────────────┤
│ MOS (Model Operating │ 负责「感知层」：相机、传感器、地图等 │
│ Standard) 1.0 │ 观测数据的传输 │
├───────────────────────┼────────────────────────────────────────┤
│ AgnesHub │ 设备连接组件，负责实际的设备接入 │
├───────────────────────┼────────────────────────────────────────┤
│ mhs-check │ 一致性测试套件，检查协议实现是否合规 │
└───────────────────────┴────────────────────────────────────────┘
在这套体系里，角色分工很清晰：AGH 负责组织整个任务，MHS 负责连接具体设备。 模型根据目标判断下一步需要做什么，AGH 协调工具调用与执行反馈，再通过设备接口完成相应操作；遇到涉及关键步骤时，也可以按任务要求引入人工确认。
Agnes 还用两个例子展示了这套体系的实际能力。第一个例子非常直观：让办公室里的移动小车找到指定书籍，并通过语音朗读书中的内容。 在演示里，小车按任务要求完成了找书与朗读，Agent 的执行范围真的从"操作软件"延伸到了"操纵一台物理小车"。第二个例子更具想象空间——Mars World，一座虚拟火星基地。Agnes 在基地里设计了一项救援任务：一名宇航员在基地外失联，Agent 需要利用基地里的设备寻找宇航员、组织救援。在这个虚拟模式里，Agent 调度飞行器搜索目标区域、安排机器人实施救援、协调基地气闸等设施，整个过程要结合地图、设备状态与任务反馈，持续推进多个操作步骤。目前官方仓库已经提供了包含 11 台虚拟设备的 Mars World 示例，以及移动机器人、机械臂、传感器等本地模拟设备，开发者无需实体硬件，就能体验完整的设备接入与任务调用流程。
四、代码视角：用 Go 实现一个"MHS 式的统一设备门面"
理解 MHS 最好的方式，是亲手设计一个类似的抽象。我用 Go 写一个极简的"MHS 式设备门面"，展示"怎么让不同设备向 Agent 暴露统一的能力接口"。
// mhs_device.go
// 一个极简的 MHS 式设备抽象：让不同硬件以统一接口暴露给 Agent
package main
import "fmt"
// DeviceCapability 设备向 Agent 暴露的"能做什么"的统一描述
type DeviceCapability struct {
DeviceID string
Name string
Actions []string // 设备支持的标准动作（如 "move_to", "read_sensor", "grip"）
}
// AgentDevice 统一设备接口：只要实现它，Agent 就能理解并调用
type AgentDevice interface {
Capability() DeviceCapability
Invoke(action string, params map[string]string) (string, error)
}
// ---- 一个移动小车的实现 ----
type Car struct{}
func (Car) Capability() DeviceCapability {
return DeviceCapability{DeviceID: "car-01", Name: "mobile-car",
Actions: []string{"move_to", "stop", "pick_up"}}
}
func (Car) Invoke(action string, params map[string]string) (string, error) {
switch action {
case "move_to":
return fmt.Sprintf("car moved to %v", params["pos"]), nil
case "pick_up":
return fmt.Sprintf("car picked up %v", params["target"]), nil
}
return "", fmt.Errorf("unsupported action %s", action)
}
// ---- 一个机械臂的实现 ----
type Arm struct{}
func (Arm) Capability() DeviceCapability {
return DeviceCapability{DeviceID: "arm-01", Name: "robot-arm",
Actions: []string{"grip", "release", "rotate"}}
}
func (Arm) Invoke(action string, params map[string]string) (string, error) {
switch action {
case "grip":
return "arm gripped object", nil
case "rotate":
return fmt.Sprintf("arm rotated to %v deg", params["angle"]), nil
}
return "", fmt.Errorf("unsupported action %s", action)
}
// ---- 一个"即插即用"的门面：面对从没见过的设备也能读懂并调用 ----
func Main() {
car := Car{}
arm := Arm{}
devices := []AgentDevice{car, arm}
// 模型侧：遍历所有设备，读能力，按名字调用动作
for _, d := range devices {
cap := d.Capability()
fmt.Printf("[device] %s (%s) can: %v\n", cap.Name, cap.DeviceID, cap.Actions)
if cap.Name == "mobile-car" {
out, err := d.Invoke("move_to", map[string]string{"pos": "(2,3)"})
fmt.Printf(" -> %s err=%v\n", out, err)
}
}
// 输出示例：
// [device] mobile-car (car-01) can: [move_to stop pick_up]
// -> car moved to (2,3) err=<nil>
// [device] robot-arm (arm-01) can: [grip release rotate]
}
这段代码的精髓在于 AgentDevice 这个接口：只要一个设备实现了"暴露能力 + 可按动作调用"这套统一接口，Agent 就无需知道它底层的驱动细节，也能理解并操纵它。 这就是 MHS 想做的事情——把"连接一个新设备"的成本，从"为它专门写一套适配"降为"让它说一遍自己会什么"。当越来越多的设备会说这种"统一语言"，Agent 连接物理世界的门槛就会急剧下降。
五、Agnes 3.0 Pro 与"从模型到物理基础设施"的整条链路
AGH 和 MHS 是"执行底座"和"连接协议"，但一个闭环的 Agent 体系，还缺最上面那颗"大脑"——模型。Agnes 同步预告了新一代模型 Agnes 3.0 Pro 的能力升级，API 即将上线。这背后其实是 Agnes 的一个清晰战略：把"模型 → 执行 → 连接物理世界"整合进同一套技术体系。
这个战略可以这样理解：过去的 AI 公司大多只做"模型"，Agent 框架是另一拨人做，物理设备的连接又是另一拨人做，三者之间靠各种拼凑和适配来勉强协作。而 Agnes 想做的，是提供一条"从大脑到身体"的整链：Agnes 系列模型当"大脑"，AGH 当"执行系统"，MHS/MOS 当"连接物理世界的神经"。 三样东西放进同一套技术体系，AI 才有可能在真实的、复杂的、跨平台的任务里稳定地"活着"并"做事"。
我把这整条链路用一张图串起来：
┌──────────────────────────────────────────────────────────────┐
│ Agnes：从模型到物理基础设施的整条链路 │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ Agnes 3.0 │ │ AGH │ │
│ │ Pro (大脑) │ ──────►│ (执行系统) │ │
│ │ 推理/决策 │ │ Agent Loop │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌───────────────────┐ │
│ │ MHS/MOS (神经连接) │ │
│ │ 统一设备交互协议 │ │
│ └─────────┬─────────┘ │
│ ▼ │
│ ┌────────┬────────┼────────┬────────┐ │
│ ▼ ▼ ▼ ▼ ▼ │
│ 移动小车 机械臂 传感器 气闸 飞行器 │
│ (物理/虚拟设备，统一语言即插即用) │
└──────────────────────────────────────────────────────────────┘
这套链路的意义在于打通了"软件 Agent"和"物理世界"的最后一公里。过去我们说"Agent 走出屏幕"，大多还停留在"在屏幕上操作浏览器、调用 API"的程度；而 Agnes 想交付的，是让 Agent 的另一只脚真正踏进物理世界——去操纵小车、机械臂、传感器。对那些正在探索机器人巡检、科研实验、现场作业等场景的开发者来说，这套开源体系提供了一个"从真实设备连接到复杂任务协同"的可落地的起点。
六、开源 vs 托管：AGH 的路，和它留给行业的想象空间
最后，我想把 AGH 放在更大的 Agent 基础设施版图里，聊聊它的定位和它的意义。
Agent 执行基础设施这一层，已经被多个玩家盯上：AWS 的 AgentCore 走的是"托管式"路线，把编排、工具、沙箱做成即开即用的服务；微软的 Agent Framework 也在提供 Harness 的编程模型；而 Agnes 选择把 AGH 全量开源——源码、MHS、MOS、AgnesHub、开发库、一致性测试套件全部开放。选择开源，意味着 Agnes 把"连接物理世界的标准"押在了开放共建上：它希望 MHS 不只是 Agnes 一家设备的协议，而是整个生态都愿意采纳的统一标准。
这一步棋的潜台词很深。能不能让一个名叫"Model Hardware Standard"的协议成为被行业广泛采纳的"事实标准"，很大程度取决于开发者买不买账、设备厂商愿不愿意接入。而把标准开源、附上一致性测试套件（mhs-check），正是降低大家接入门槛、打消"被锁定"顾虑的做法——你想接，就照着公开协议和测试套件接；你怕被锁，协议也明明白白开放给你看。 这种"用开放换生态"的打法，在硬件接入这类天生怕"绑定"的领域，往往比闭源托管更有吸引力。
对开发者来说，AGH 的价值可以落到三句话：
- 如果你在做软件 Agent，AGH 给了你一套"开箱即用 + 可审计轨迹"的执行底座，你可以在本地装上去，用 MCP 接服务、用 Skills 沉淀可复用的干活经验。
- 如果你在做物理/具身 Agent，MHS/MOS 给了你一个"不用为每台设备写适配"的抽象层，配合 11 台虚拟设备示例和本地模拟设备，你在没有实体硬件的条件下就能先把接入和调用逻辑跑通。
- 如果你想避开绑定，开源 + 一致性测试套件意味着这套体系是透明、可审计、可迁移的，你能看清每一层在做什么，也能按需扩展。
结语：AI 的下一个战场，正在从"屏幕"走向"世界"
从一条"让小车找书朗读"的任务，到一座"虚拟火星基地里调度飞行器救援宇航员"的模拟，Agnes 用 AGH 和 MHS 描绘了一个清晰的方向：Agent 的能力边界，正在从"屏幕里的对话框"和"软件里的 API"，一点点延伸到"掌控物理世界"。 而要做到这一点，光有更强的模型还不够，还需要一套能组织 Agent 持续干活、能让 Agent 理解并调用千奇百怪设备的"执行基础设施"。
Agnes 这次把 Harness 和执行协议全盘开源，相当于公开押注了一个判断：Agent 落地的下一波浪潮，属于那些愿意把"大脑、执行系统、物理连接"焊进同一套体系、并且用开放去换取生态的人。 至于 MHS 能不能真成为 Agent 世界的"USB 协议"、Agnes 3.0 Pro 能不能撑起这套体系顶端的"大脑"，还需要时间验证。
但有一点已经越来越清楚：当 agent 不再只是"会聊天的程序"，而是一套能走进真实世界、操纵真实设备的完整系统时，谁先补上"从模型到物理世界"的最后一公里，谁就更有可能吃到 Agent 从屏幕走向世界的下一波红利。 这扇门，Agnes 已经帮大家打开了。