AI Agent 这个词在过去一年里被用得太泛了。能调个 API 就叫 Agent，能写段代码的叫 Coding Agent，帮你订会议室的也管自己叫 Personal Agent。但如果你真的把一个 Agent 放到企业环境里，让它完成一个涉及三个系统、五个步骤的实际业务流程，大概率会发现：它想得挺好，执行起来一塌糊涂。
问题出在哪里？Agent 的决策能力确实在快速提升——GPT-4 级别的模型已经可以做复杂的多步推理和任务规划。真正的瓶颈在两处：决策之后谁来约束执行过程？决策结果如何真正落地到具体的操作界面上？
前一个问题，业界最近给出了一个方法论层面的回答，叫 Harness。后一个问题，需要 GUI Agent 来补位。
什么是 Harness
Harness 这个词在英语里的原始含义是马具、缰绳。用在 AI Agent 语境下，指的是一套约束 Agent 行为的工程方法论。
Anthropic 在 2024 年 12 月发布的《Building Effective Agents》中系统性地阐述了 Agent 系统的设计模式——从最基础的 Prompt Chaining，到 Routing（任务路由）、Parallelization（并行处理）、Orchestrator-Workers（编排调度），再到 Evaluator-Optimizer（评估优化循环）。这些模式的共同特征是：LLM 在每一步都受到明确的结构约束，而非自由发挥。OpenAI 则在《Practices for Governing Agentic AI Systems》中提出了 Agent 治理的基本原则，强调安全性、可审计和人类监督。
综合两家的思路，Harness 作为一种工程范式，核心解决三件事：
任务路由（Routing）。Agent 收到一个请求后，先做分类判断——这是一个简单查询还是一个复杂操作？该走轻量级模型还是走完整推理链路？路由层决定了请求进入哪条处理管道。路由判断出错，后面所有步骤都白费。
流程门禁（Approval Gates）。Agent 执行到关键节点时暂停，等待人工确认或自动规则校验。比如"修改客户数据前需要二次确认"，或者"花费超过 1000 元的操作需要审批"。门禁的粒度可以根据风险等级动态调整——高风险操作强制人工审批，低风险操作自动通过。
验证回顾（Verification / Retro）。Agent 完成一个步骤之后，先验证上一步的输出是否符合预期，确认无误后再进入下一步。如果偏离了，可以回退重做，也可以触发报警。Anthropic 把这个模式叫 Evaluator-Optimizer Loop。
把这三个组件串起来，就构成了 Agent 行为的"缰绳"。它让 Agent 可以自主决策，但每一步决策都在可控范围内。
Harness 解决了什么
在没有 Harness 的时代，Agent 的行为约束基本靠两种方式：要么在 Prompt 里写一堆规则（"你不能做 X"、"做 Y 之前必须确认"），要么在代码里硬编码一套 if-else 逻辑。前者不可靠，LLM 对 Prompt 指令的遵从度会随上下文长度衰减。后者太脆，每次需求变更都要改代码。
Harness 把约束从 Prompt 和业务代码中抽离出来，变成一个独立的控制层。Agent 的能力模块负责"能做什么"，Harness 层负责"什么条件下可以做、做完之后怎么验证"。两层解耦之后，迭代 Agent 能力时不会意外放松安全约束，调整流程规则时不需要重新训练或改写 Agent 逻辑。
开源社区已经出现了探索 Harness 理念的项目，比如 cow-harness 这类轻量级脚手架。它们尝试把 Routing、Gate、Verification 这几个基础组件做成可插拔的 SDK，开发者可以像搭积木一样组装自己的 Agent 约束层。
这个趋势背后的逻辑很直接：Agent 的决策能力越强，越需要好的约束机制。就像发动机马力越大的车越需要好的制动系统——没人会开一辆 600 马力但只有鼓式刹车的车上高速。
Harness 没解决什么
Harness 管的是决策流程，管不了执行落地。
举个具体例子：一个企业客服 Agent 接到用户投诉，经过 Routing 判断这是一个退款请求，经过 Approval Gate 确认该用户符合退款条件，Agent 做出决策——"执行退款操作"。
然后呢？
执行"退款"这个动作，意味着要打开公司的 CRM 系统，找到对应订单，点击退款按钮，填写退款原因，提交审批流。这个过程涉及具体的 GUI 交互。
当前 Agent 执行操作的主流方案有这么几种：CLI 命令行（覆盖面窄，绝大多数企业应用没有命令行接口）、API 调用（很多系统的 API 覆盖面极其有限，大量功能只能通过界面操作）、HTML 解析 + DOM 操作（只对 Web 应用有效，页面一改版定位规则全部失效）、RPA 脚本（每个流程单独写脚本，维护成本和业务流程数量成正比）。
这四种方案有一个共同的前提假设：你必须预先知道目标系统的技术接口。对于 CLI 要知道命令和参数，对于 API 要有文档和 Key，对于 DOM 要知道元素选择器，对于 RPA 要逐步录制流程。
但企业环境里大量核心系统是黑盒。老旧的 ERP、定制开发的内部工具、第三方 SaaS 的管理后台——你能看到界面、能用鼠标操作，但就是没有技术接口可以调用。
GUI Agent：给决策补上"手"
解决黑盒系统操作问题的一条路径是 GUI Agent——纯视觉驱动的操作方案。
它的工作方式跟人类操作电脑完全一样：看到屏幕画面，理解画面里有哪些可交互元素，然后输出鼠标点击坐标或键盘输入指令。输入是屏幕截图，处理依赖视觉-语言模型来识别 UI 元素和理解任务意图，输出是具体的操作序列。
这个方案的核心优势在于：对目标系统零依赖。不需要 API 文档和 DOM 结构知识，也不需要预先录制流程。只要人类能看到界面、用鼠标键盘操作的东西，GUI Agent 理论上都能操作。系统换了皮肤、升级了版本、调整了布局——只要功能入口还在界面上可见，GUI Agent 就能继续工作。
一个具体实现：Mano-P
明略科技开源的 Mano-P 是这条技术路线上的一个实践。Mano 是西班牙语里"手"的意思，P 代表 Private——私有部署、数据不出设备。项目以 Apache 2.0 协议开源，代码在 GitHub 上。
技术架构上，Mano-P 基于 VLA（Vision-Language-Action）模型，核心推理机制是 think-act-verify 循环：先观察屏幕状态和理解任务、然后规划并执行操作、最后验证操作结果是否符合预期。如果验证不通过，回退到思考阶段重新规划。这个循环结构本身就是 Harness 中 Verification 理念在执行层的落地。
端侧部署能力是 Mano-P 比较有特点的一个方面。4B 参数量化后的模型可以在 Apple M4 + 32GB RAM 的 Mac 上本地运行，推理过程数据完全不经过网络。在 M5 Pro 芯片（64GB RAM, 307 GB/s 带宽）上实测，decode 速度约 80 tok/s。配合 Cider 推理加速 SDK（提供 W8A8 在线激活量化），prefill 阶段加速约 12.7%。
更完整的落地场景可以看 Mano-AFK——一个基于 Mano-P 的自主应用构建系统。它的工作流程是这样的：自然语言描述需求 → 生成结构化 PRD → 架构设计 → 代码生成 → 本地部署 → E2E 测试 → 缺陷定位 → 修复 → 重新验证。其中 E2E 测试环节直接用 Mano-P 的视觉模型驱动浏览器，像人类 QA 一样看着屏幕验证功能是否正常。
这条链路如果用 Harness 的框架来看：PRD 阶段做的是任务路由和分解，每个环节之间有 Gate（只有前一步验证通过才进入下一步），整个循环本身就是一个 Evaluator-Optimizer Loop。Harness 管流程约束，Mano-P 管执行落地，两层拼在一起形成完整链路。
说说边界
任何技术方案都有适用边界，GUI Agent 也一样。
纯视觉路线在处理简单任务时存在额外开销——一个 API 调用 200ms 能完成的事，GUI Agent 需要截图、推理、定位、操作，整个链路可能要 3-5 秒。在目标系统有稳定 API 的场景下，直接走 API 显然更高效。
端侧 4B 模型在极度复杂的界面上精度有损。密集信息面板、大量相似按钮、超深层级的嵌套菜单——这些场景对视觉理解能力的要求很高，小模型确实不如云端大模型准确。
最适合 GUI Agent 的场景集中在三类：企业遗留系统自动化（系统老旧、无 API、改造成本过高），跨平台操作（同一个流程涉及多个不同技术栈的系统），以及对数据安全有强需求的场景（数据不能上云、不能经过第三方服务）。
结束
LLM 的决策能力已经不是瓶颈。如何安全地约束决策过程、如何把决策结果落地到真实的操作界面——这两个问题才是 Agent 从 demo 走向生产的关键障碍。Harness 提供了决策约束的方法论框架，GUI Agent 补上了执行层的最后一环，两者结合才是 AI 自动化的完整解法。方向还很早期，工具链成熟度和跨场景泛化能力都有很大提升空间，但路径已经看得见了。
GitHub： 欢迎在 GitHub 上Star⭐、提交 Issue 或参与贡献
