从 Prompt 到 Graph：AI 工程的进化史

转写说明

本文基于已校验的公开原文进行结构化转写与事实梳理，非原文转载。转写保留可核验的技术事实，并将工程建议与来源观点明确分开。

AI工程方法论在过去几年间经历了五层演进：Prompt、Context、Harness、Loop、Graph。这五层并非相互替代，而是将问题的杠杆逐步上移的过程。早期关注单次交互的提问技巧，后期转向整个工作流程的组织方式。

文章指出，当前许多自动化流程的问题不在于模型能力不足，而在于验证环节的缺失——代码通过单测不代表产品在真机上可用。有效的做法是将验收锚点放置在系统外部，确保单测绿、真机验证通过、人工批准交付这些条件不被绕过。

Prompt层解决的是单次交互的提问方式。2020年GPT-3证明了few-shot示例的有效性，2022年Chain-of-Thought引导模型输出中间推理步骤。这些技巧在当前仍发挥作用，但只管单轮对话的质量。

Context层管理模型在特定时刻能看到什么。2024年Anthropic开源的MCP协议将工具调用、数据查询统一为标准化接口。注意力预算有限意味着需要主动选择进入上下文的token，而非简单塞满。

Harness层构建单个Agent的运行环境。Anthropic提出的长任务范式将规划、生成、评估分离，使用文件交接、必要时清空上下文再续。这层补足了模型本身做不到的能力，如工具权限控制、沙箱隔离、会话重置等。

Loop层用系统调度替代人工操作员。设计Automations、Worktrees、Skills、Connectors等组件，配合落在磁盘上的State实现自动化调度。核心价值在于把人从反复的Prompt操作中解放出来。

Graph层处理多条Loop或多个Agent之间的组织关系。包括依赖顺序、并行汇合、失败回退路径、检查点设置等。LangGraph在2024年已提供有状态图的实现框架。

文章介绍的Munk AI将上述能力落地为具体实现：Work对应单条需求的闭环执行，WorkSet对应多条需求的图结构编排，Device MCP提供真机验证能力。

当前版本支持MacOS和Android端。桌面端下载地址为munk.sh/zh/install，可访问官网获取安装包。

运行时的外部依赖通过环境变量配置，具体变量名称参考官方文档说明。应用启动后可创建Work处理单条需求，或创建WorkSet编排多条Work的依赖关系。

这套方法论主要面向需要持续运行的自动化工作场景，尤其是跨越编码、检查、部署、验证、交付多个环节的完整流程。个人和小团队可将默认工作单元从单次对话转变为可自动迭代的Loop。

对于简单的单次问答场景，基础Prompt技巧已足够，无需引入完整的Harness或Loop机制。当工作涉及多角色协作、多步骤依赖、或需要跨真机验证时，Graph层的组织能力和Device MCP的验证能力才真正发挥价值。

文章特别指出，Graph层适合的场景是“需要把流程画清楚”的情况。一旦画出来，许多以前靠聊天隐含过去的步骤就会暴露问题。如果流程本身尚未理清，强行上Graph可能反而增加复杂度。

检查当前任务是否真的需要Loop机制。如果每次只需一条Prompt就能完成，Prompt层已足够，不必过度工程化。

确认验收标准是否明确定义且外部化。单测通过不等于产品可用，需要明确哪些步骤必须在真机或真实环境中验证通过。

评估Harness层的组件是否与当前模型能力匹配。Anthropic的建议是模型变强后，过时的脚手架应当拆除，而非保留所有历史配置。

验证多Agent或多条Work的依赖关系是否已梳理清楚。使用Graph结构前，确保每个节点的输入输出、失败回退路径、人工介入点都已明确。

确认Device MCP的验证结果能够回传到执行侧。真机验证的截图和界面结构数据需要成为闭环的一部分，而非仅作为人工参考。