缘起：当人类成为 AI 的瓶颈
在过去的两年里，AI 编程的演进速度超出了许多人的预期。借助于 Trae 这类 AI 工具以及底层大模型的迭代，Vibe Coding已经从概念逐渐落地为开发者的日常。
只需输入自然语言指令，AI 就能在短时间内生成大段业务代码。我们似乎正在接近一个"代码廉价"的时代。
然而，代码生成速度的提升，是否等同于交付效率的提升？
现实中，每一次 AI 生成代码后，验证其正确性的工作依然需要人工介入。我们需要逐行 Review 这些非手写的代码，需要编译运行，甚至需要在真机或浏览器上手动点击，以排查深藏在交互逻辑中的 Bug。
当代码生成的耗时被极度压缩时，人类的 Review 和手动测试，反而成为了整体研发效率的瓶颈。
近两年，在探索 AI 编程的过程中，这个问题一直困扰着我。
望着 AI 生成的一大堆代码，我经常问自己：到底该怎么办？
一个自然的解法是：让 AI 直接参与 Review 和自动化测试。
但阻碍这一设想落地的，是高昂的云端算力成本。如果采用顶尖的云端视觉大模型（Vision Model）来替代人工进行 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 强调通过"设计环境与约束（Constraints）"来驾驭大模型，那么这种宏观的编排就是补齐端到端物理测试闭环的关键实践。
它的核心理念是：不再让人类单向地向大模型下达指令并承担最终的验收工作，而是通过"编码智能体"与"测试智能体"的协同，在机器内部构建一个完整的、自动化的物理测试与反馈闭环。
在这个由 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 的流转。在达到终止条件（成功、无法继续或达到步数限制）后结束该 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")）。这就导致了一个致命的死穴：测试脚本与 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 获得了惊人的跨平台能力。同样的自然语言测试意图（比如"点击首页的头像"），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...
- 🐦 关注我的 X/Twitter ：x.com/iBoyCoder
- 💬 加入开发者社群，探讨 Harness Engineering 的落地实践 ：关注公众号:
朱涛的自习室，获取进群方式；
AI 编程的时代已经到来。
现在，是时候成为一名真正的 Harness Engineer 了。
让我们给 AI 装上感知现实的眼睛，赋予它操作真实设备的手，并用严密的工程护栏，去真正"驾驭"这股庞大的 AI 生产力。