缘起：当人类成为 AI 的瓶颈
过去两年，AI 编程的演进速度超出了大多数人的预期。借助 Trae 这类工具和底层大模型的不断迭代，Vibe Coding 已经从概念逐步落地为开发者的日常操作。
输入自然语言指令，AI 就能在几分钟内生成整段业务代码——我们似乎正在接近一个“代码廉价”的时代。
但问题在于：代码生成速度快了，交付效率就真的上去了吗？
现实情况是，AI 每生成一次代码，验证其正确性的工作依然需要人工介入。逐行 Review 那些非手写的代码，编译运行，甚至需要在真机或浏览器上手动点击，去排查隐藏在交互深处的 Bug。
当代码生成耗时被极限压缩，人类的手动 Review 和测试，反而成了整体研发效率的瓶颈。
过去两年里，这个问题始终是个绕不开的难题。看着 AI 哗啦啦吐出一大堆代码，总会忍不住问自己：到底该怎么办？
一个自然的解法是：让 AI 直接参与 Review 和自动化测试。但阻碍这一设想的，是高昂的云端算力成本。如果用顶尖的云端视觉大模型来替代人工做 UI 测试，海量的截图分析和 Token 消耗，对大多数团队来说，很难在日常 CI/CD 流水线中常态化运行。
直到前不久，Google 发布了 Gemma 4 家族模型，转机出现了。
其中的 26B-A4B 模型展现了极高的性价比：逻辑推理能力强，成本却极低。云端运行的价格，比顶尖闭源模型 低200倍，而如果你有 24G 显存的本地设备，甚至可以直接免费运行。
Gemma 4 在能力与成本之间的平衡，让我看到了打破算力壁垒的希望。让 AI 亲自执行自动化测试，不再是大厂实验室里的高成本探索，而是具备了工程化落地的条件。
于是下定决心做一次尝试：与其让人类充当 AI 代码的“质检员”，不如构建一个能自主执行测试的 AI 系统。
这场为期 30 天的工程实践，就此展开。
一、30 天的工程实践：从“手写”到“编排”
最终的结果，超出了预期。
30 天时间里，借助 Trae 和 Gemini 的辅助，写了 11 万行代码（项目功能完成度大约 65%）。
项目取名为：Munk AI，来自最喜欢的动物：花栗鼠（Chipmunk）。
Munk AI 并不是传统的自动化测试框架。它是一个将视觉感知与多智能体协同结合的 AI 测试系统——通过 CV 模型理解 UI 界面，通过 LLM 理解自然语言编写的 Test Case。
它是为 Vibe Coding 时代的测试瓶颈而设计，也是下一代自动化测试的探索性引擎。
写这篇文章，不是为了强调代码行数，也不是制造“AI 取代测试工程师”的焦虑。更多是一次关于研发效能的实战复盘，以及对近期爆火的 Harness Engineering 的探索。
在新的范式下，开发者、QA 的核心工作正在从具体编码与执行，向上层位移：成为流程的编排者、规则的制定者。
二、以 Harness Engineering 为基石，从 Vibe Coding 走向 Agent Orchestration
今年 2 月，OpenAI 在其官方博客中正式提出了 Harness Engineering（驾驭工程）的概念，标志着软件工程范式的根本性转移。在这个范式下，人类工程师的核心职责不再是逐行编写代码，而是为强大的 AI 模型设计环境、制定规则，并构建可靠的反馈闭环与机械约束（Mechanical Constraints），从而安全地“驾驭”这股生产力。
但当我们审视目前流行的 Vibe Coding 模式时，会发现它在工程上存在一个致命缺陷：它是一条缺乏系统级护栏的单向开环（Open-Loop）流水线。
在这个模式下，人类发出指令，AI 吐出代码。一旦运行出错，流水线就断了——你需要停下手头的工作，去查看控制台报错，截图出错界面，重新整理上下文，再喂回给 AI 让它修改。
这种高频的人肉充当反馈流程，不仅消耗开发者的精力，更彻底违背了 Harness Engineering 的初衷——我们并没有建立系统来驾驭大模型，反而沦为了 AI 的“人肉质检员”和“搬运工”。
那么，Harness Engineering 到底该如何落地？
Prompt 与 Context 护栏 ≠ Harness Engineering
翻看 GitHub 上近期爆火的 awesome-harness-engineering 仓库，梳理业内最新方案，会发现一个残酷现实：目前大多数对 Harness 的探索，还停留在 Prompt 规范（如定义严密的 AGENTS.md）、上下文管理（Context 压缩）或代码级别的静态检查（Linters）层面。
Web 端，业内勉强有一些基于 Playwright/DOM 的测试沙盒；但在 Android 和 iOS 这样极其复杂的物理真机环境下，几乎没有统一的、跨端的 AI 视觉自动化测试方案来作为 Harness 落地。
单纯靠 Prompt 和 Context 静态层面的 Harness 远远不够。没有真实的端到端 UI 测试反馈，AI 生成的客户端代码永远像是在“盲飞”。要真正落实 Harness Engineering，就必须补上跨端物理测试这一环，把人类从低效的运行验收中抽离出来。
Coding + Testing Agent Orchestration：补齐 Harness Engineering 的物理拼图
这就是基于 Coding 和 Testing 的智能体编排（Agent Orchestration）诞生的意义。如果说 Harness Engineering 强调“设计环境与约束”来驾驭大模型，那么这种宏观的编排，就是补齐端到端物理测试闭环的关键实践。
核心理念是：不再让人类单向地向大模型下达指令并承担最终验收，而是通过“编码智能体”与“测试智能体”的协同，在机器内部构建一个完整的、自动化的物理测试与反馈闭环。
在这个由 Agent Orchestration 驱动的闭环系统中：
- 编码 Agent（如 Trae / Cursor）负责根据需求编写代码。
- 代码提交后，自动触发测试 Agent（即 Munk AI）。
- Munk AI “用眼睛看着屏幕”去执行真实的跨端 UI 交互与回归测试。
- 遇到 Bug 时，Munk AI 会自动抓取物理设备上的真实上下文（截图、DOM 树、报错栈），转化为结构化数据，直接回传给编码 Agent 进行自愈修复。
通过这种“编排”，用真实的端到端测试，为代码生成系统筑起了一道坚不可摧的物理“护栏”。人类彻底从排错和点点点中解放出来，真正退居幕后，成为设定目标、定义验收标准的 Harness Engineer（驾驭工程师）。
而 Munk AI，正是这套 Agent Orchestration 实践中，最锐利、最不可或缺的那个“测试网关”。
三、Munk AI 内部的微观编排（Micro-Agent Orchestration）
理解了宏观闭环愿景，再把视角拉回 Munk AI 内部。
如果以为 Munk AI 只是简单地把截图丢给大模型，然后祈祷它不出错，那就大错特错了——那不叫测试，那叫碰运气。
在工业级测试场景中，要求的是极高的稳定性和严密的逻辑推演。单个无所不能的“巨无霸模型”，往往会在超长上下文和复杂任务中迷失方向，产生致命的“幻觉”。
因此，Munk AI 在架构设计上，坚决摒弃了单体大模型（Single LLM）的思路，采用了一套精密的智能体编排（Agent Orchestration）架构。
Munk AI 内部并非孤军奋战，而是一支分工明确的 Agent 舰队。它们各司其职，通过严密的数据结构（Pydantic Schema）相互传递情报，共同完成复杂的自动化测试与验收。
在这个指挥所里，有两条最核心的协同链路：
协同链路 1：Plan、Runner 与 Judge Agent 的执行闭环
- 规划（Plan Agent）：接收 PRD 或设计文档，解析语义并拆解为结构化的测试计划，明确“测什么”。
- 执行（Runner Agent）：根据计划中的单个 Case，通过视觉模型分析当前界面，决定并执行一系列连续交互动作（如点击、输入），负责完成整个 Case 的流转。在达到终止条件（成功、无法继续或达到步数限制）后结束执行。
- 校验（Judge Agent）：在 Runner Agent 完成 Case 执行后介入。它会拉取该 Case 完整的执行历史摘要（最近的步骤信息）以及最终截屏，进行综合的结构化判定，确认“是否达到了预期的业务结果”。这种执行与判定分离的架构，既保证了执行的流畅度，又确保了最终结果的客观性。
协同链路 2：基于 Review Agent 的智能回归（Vibe-Gate）
- 在敏捷开发中，每一次代码合并都伴随着风险。无论是人类开发者还是 AI Coding Agent 提交的代码变更（Diff），Review Agent 都会像一个不知疲倦的高级 QA，进行实时分析。它能智能推断出这次变更可能影响的业务范围，并在 MR（Merge Request）阶段自动组合出 Review-first 的回归验证计划，交给 Runner 和 Judge 去执行。这是防患于未然的“智能体研发网关”。
在这个微观的 Agent 编排网络中，没有谁是全知全能的，但当它们组合在一起时，就形成了一个既能听懂人类语言、又能精准操控物理设备、还能自我校验对错的“超级测试专家”。
注：Trae 接入 Munk AI 打通 Android 研发 + 测试
四、Munk AI 对比传统方案的优势在哪里？
除了精密的 Agent 编排，Munk AI 真正能替代人类去执行测试的杀手锏，是它碘伏性的底层驱动逻辑。
传统测试的泥潭（XPath/ID 驱动）
写过 Appium 或 Selenium 的人都知道，传统自动化测试脚本极其脆弱——因为它们是“瞎子”。
传统脚本必须强依赖底层的 DOM 树或 XPath/ID 进行控件寻址（比如 driver.find_element_by_id("login-btn")），导致致命的死xue：测试脚本与 UI 框架代码被死死绑定在一起。
一旦开发人员重构了 UI 层代码——哪怕只是把一个 div 换成 button，或者调整了层级嵌套——界面视觉上完全没变，自动化脚本也会瞬间瘫痪。这种“代码一动，脚本全崩”的高昂维护成本，让无数团队对自动化测试望而却步。
Munk AI 的破局：像人一样“看懂”界面
人类怎么做测试？从不关心底层代码写的是什么，而是用眼睛看界面上的元素，用大脑理解意图。
Munk AI 完全复刻了人类的这种工作模式，实现了对传统自动化的“降维打击”：
- 自然语言驱动，打破代码绑定：在 Munk AI 里，不再需要抓取和写死晦涩的选择器。只需要在计划里写下一句自然语言：“点击登录按钮”或“在搜索框输入 iPhone”。Munk AI 实现了从“XPath 驱动”到“自然语言意图驱动”的跨越。
- 纯视觉感知（Perception）的威力：Munk AI 能读懂这些自然语言，因为它不再把底层的 DOM 树当作唯一真理。它拥有一套强悍的“感知层（Perception）”。通过图标检测模型 + OCR 模型 + 视觉大模型（Vision Model），它能像人类一样直接“看懂”屏幕内容，识别出哪里是“购物车”，哪里是“返回键”。底层的 DOM/UI Tree 退居二线，仅作为辅助的坐标定位线索（增强）。
- 一套逻辑，多端通用：正因为不再强依赖底层 UI 框架代码，Munk AI 获得了惊人的跨平台能力。同样的自然语言测试意图（比如“点击首页的头像”），可以无缝横跨 Android 真机、iOS 真机以及 Web 浏览器执行。
注：Munk AI 的纯视觉感知能力展示（红色为文本元素，绿色为 Icon 元素）
自然语言 + 视觉方案的意义
这意味着，测试资产（用例）彻底与前端 UI 实现代码解耦了。
前端重构、框架迁移、甚至是重写整个 App，都不再意味着历史测试用例的报废。只要界面的核心业务逻辑没变，Munk AI 就能继续稳定地跑下去。
让测试回归所见即所得，这才是让 AI 亲自下场做测试的意义。
五、个体效能的跃迁：Trae 与 Gemini 构建的工程新范式
看到这里，可能有人会问：一个深耕 Android 的客户端工程师，是怎么在短短 30 天内，完成横跨多智能体架构、Python 调度引擎、Vue 3 前端，并打通多端物理设备的复杂工程的？
这在过去通常需要一个中型研发团队的建制。11 万行代码背后，包含着跨端双向通信桥接（Bridge）、视觉模型本地推断、基于 Pydantic AI 的状态机流转等高密度逻辑。
答案并非 AI 有了某种“魔法”，而是工程抽象层级的改变。AI 将繁杂的语法细节和 API 拼凑变成了标准化产出，让人类得以将全部精力倾注于系统架构与边界设计。
换句话说：架构思想是通用的，编程语言的范式理解是通用的，大前端（Android, iOS, Web）的框架原理是通用的——具体 API 细节，已经没有门槛了。
在这场高强度开发中，Trae 和 Gemini 展现出了截然不同但又互补的工程价值：
- Trae 的全局上下文理解：面对 11 万行代码的复杂工程，单文件补全毫无意义。Trae 的优势在于其 Workspace 级别的全局视野。在底层修改一个核心的交互 Schema 时，它能精准推演并同步重构上层的 Vue 组件和 Python 调度逻辑，极大降低了跨技术栈开发的心智负担。
- Gemini 的逻辑连贯性：Munk AI 的基石是基于 Pydantic 的结构化数据约束。在处理复杂的 Agent 异步状态机轮转时，底层驱动的 Gemini 展现了出色的逻辑推演能力，能够在严密的数据护栏内保持输出的稳定性。
人机协作的黄金边界
高产出的关键，在于找到人机协作的黄金边界。这 30 天里，切实实践了“驾驭工程师（Harness Engineer）”的工作模式：
- 人类负责确立边界：将绝大部分时间用于定义架构骨架、设计核心的 Pydantic Schema，以及攻克“纯视觉替代 DOM”等关键技术决策。
- AI 负责填充逻辑：在明确的边界和约束内，具体的业务逻辑实现、前端页面组件编写、甚至跨端 API 的粘合代码，均交由 AI 高效完成。
如何让大模型不跑偏？为上下文套上“护栏”
为了防止大模型在庞大的工程中产生“幻觉”，通过详尽的 project_memory.md、architecture.md、roadmap.md 文档，为 AI 设定了严格的上下文约束（例如：必须坚持本地优先、必须走结构化输出）。
每当 Trae 准备进行大规模代码生成或重构时，它都会首先读取这些规则。相当于为 AI 的运行设定了边界，确保其在生成代码的过程中，始终遵循项目的架构规范，避免逻辑错乱。这是 Harness Engineering 在开发阶段的具体应用。
六、架构实践：面向机器与人类的双向“驾驭”网关
在 Munk AI 的架构设计中，Harness Engineering 的理念不仅体现在开发过程中，更深度融入了系统的最终形态：既需要为不可控的代码生成 Agent 提供验证护栏，也需要为人类保留全局的控制权。
面向机器的物理护栏：MCP 协议双端点
当下的 Coding Agent 往往运行在缺乏真实物理反馈的真空中。为了打破这一隔离，Munk AI 实现了标准化的双 MCP 接口（/mcp 用于通用编排，/mcp/device 用于设备控制）。
通过这套接口，外部的 Coding Agent（如 Trae 本身）可以将其生成的代码变更，自动交由 Munk AI 在真实的移动端或 Web 环境中进行渲染和交互验证。遇到阻碍或报错时，Munk AI 会提取截图与错误栈反馈给 Coding Agent。这实质上是利用 Agent Orchestration，为代码生成工具提供了一套底层的物理验证“护栏”。
面向人类的指挥中心：Local Web UI
注：Munk AI 提供的开箱即用的本地可视化控制台
Harness Engineering 并非将人类排除在系统之外。相反，人类比以往任何时候都更需要一个高信噪比的决策面板。
为此，Munk AI 提供了本地可视化控制台。它允许开发者或 QA 团队在无需编写任何代码的情况下，直观地管理测试资产、选择目标设备并下发验证计划。
特别是在企业级场景中，测试团队可以通过该面板一键勾选多台物理设备，批量执行发版前的全量回归测试，或是跨平台、跨机型的兼容性测试。
每一次 Agent 的交互轨迹和判定结果，都会以可视化的方式结构化呈现。这使得 Harness Engineering 能够平滑地融入现有的研发工作流。
七、终局探讨：QA 的进化与 100% 开源路线
随着代码成本的边际递减，软件工程的重心正在发生不可逆的转移——从如何高效地编写代码转向如何建立有效的验证与验收系统。
这也是 Harness Engineering 概念提出的核心时代背景。当 AI 成为主要的生产者时，能够为 AI 提供护栏的验证体系将成为研发链条上的新基建。
在这个范式转移中，传统测试与 QA 角色并不会消亡，而是会向上游演进。未来的质量保障工作，将不再是编写脆弱的 XPath 脚本，而是转变为定义验证标准、设计用例结构，并编排复杂的 AI 工具链。他们将成为新一代的 Harness Engineer（驾驭工程师）。
拥抱开源
Munk AI 诞生于对新一代研发范式的个人探索。它目前也许还不够完美，但它验证了“视觉感知 + 智能体编排”在自动化测试领域的巨大潜力。
随着 Munk AI 核心的 MCP 协议与 Agent 交互机制的逐步重构与稳定，核心代码将会 100% 开源。希望与社区的开发者一起，共建 Harness Engineering 时代的基础设施。
如果你对这种全新的验证范式感兴趣，或者同样在思考如何为 AI 编程建立护栏，欢迎进一步了解：
- 探索最终产物：munk.sh
- 关注 GitHub 仓库：github.com/chaxiu/munk…
AI 编程的时代已经到来。
现在，是时候成为一名真正的 Harness Engineer 了。
让我们给 AI 装上感知现实的眼睛，赋予它操作真实设备的手，并用严密的工程护栏，去真正“驾驭”这股庞大的 AI 生产力。
