往期文章：
近两年的 AI 圈，大家应该都有同感：术语换得比模型还快。
刚把 Prompt 写顺手，有人说关键其实是 Context ；Context 还没调明白，又开始聊 Harness ；Harness 刚站稳脚跟，Loop Engineering 上了热搜；Loop 的争议还没散，又有人问------是不是该谈 Graph 了？
这五层听起来像新词堆砌，其实是同一条路上的台阶。下面按时间线串一遍，最后落到我们做的 Munk AI 桌面端：本机编排，再加设备控制 MCP，怎么把「AI 打工」真正跑成闭环。
text
Prompt → Context → Harness → Loop → Graph每一层不是打倒上一层，而是把杠杆往上挪一格。
1. Prompt：先学会「对模型说话」（2020--2023）
2020 年 5 月 ，OpenAI 的 Tom B. Brown 等人发表 Language Models are Few-Shot Learners。GPT-3 证明：不必微调，塞几条示例（few-shot），模型就能跟着做。Prompt 第一次从聊天框里的随口一问，变成一门工程活。
2022 年 ，Google Brain 的 Jason Wei、Denny Zhou 等人提出 Chain-of-Thought：先让模型写出中间推理，再给答案。同年 Kojima 等人的 Zero-shot CoT（「Let's think step by step」）把门槛又压低一截。
2022 年底 ChatGPT 把 Prompt 推到大众视野；DAIR.AI 等团队的 Prompt Engineering Guide，成了许多开发者的入门读物。那两年大家比的是：
同一模型，谁 Prompt 写得好，谁产出更好。
这一层今天仍管用------但它只管「这一轮对话怎么问」，管不了「Agent 跑一夜之后，你还信不信结果」。
2. Context：窗口里塞什么，往往比怎么问更重要（2024--2025）
Agent 真用起来以后，大家发现问题经常不在 Prompt 措辞，而在上下文窗口里塞错了东西。
2024 年 11 月 25 日 ，Anthropic 开源 Model Context Protocol（MCP）（David Soria Parra、Justin Spahr-Summers 等）。工具、仓库、数据库不必再各写一套私有插件，统一成「模型可以调用的上下文接口」。
随后 Anthropic 工程博客 Effective context engineering for AI agents 把口径说得很硬：注意力预算有限，要持续挑选进窗口的 token------压缩历史、按需加载工具、用到再检索，而不是一股脑塞满。
一句话：Prompt 管「怎么说」；Context 管「这一刻该看见什么」。
3. Harness：模型外面那一整圈「跑道」（2025--2026 初）
光有好 Prompt、好 Context，还撑不起长任务。真正决定 Agent 能不能连干几天的，是外围那圈脚手架：工具权限、沙箱、hooks、Skills、会话重置，以及「写的人」和「判的人」不能是同一个......
社区把这层叫做 Harness Engineering。
Viv Trivedy 较早把它系统化命名；
Anthropic 在 Harness design for long-running application development 里给出长任务范式（规划 / 生成 / 评估分开、用文件交接、必要时清空上下文再续）。
Google 工程师 Addy Osmani 的 Agent Harness Engineering 则把讨论推到更广的开发者圈。
Anthropic 有句话特别实用：
Harness 里每个组件，都在补「模型自己还做不到」的短板；模型变强了，过时的脚手架就该拆掉。
Harness，就是单个 Agent 的跑道：环境、约束、能用什么工具、停之前查什么。你不再只调一句话，而是在设计整套运行时。
4. Loop：别再亲自当 Prompt 操作员（2026 年 6 月）
跑道有了，下一问就变成：谁去发现任务、谁去 Prompt、谁验收、谁决定下一轮？
2026 年 6 月 2 日前后，Anthropic Claude Code 负责人 Boris Cherny 公开说：他已经不太亲自 Prompt Claude 了，而是写 Loop，让 Loop 去 Prompt。
6 月 7 日，OpenClaw 作者 Peter Steinberger 在 X 上的短句把讨论点燃了：
You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.
6 月 8 日 ，Addy Osmani 发表 Loop Engineering，把概念收成可落地的框架：Automations、Worktrees、Skills、Connectors（MCP）、Sub-agents，再加上落在磁盘上的 State。
说白了：Loop 就是用系统设计，替代你本人当 Agent 的 Prompt 操作员。
Harness 是跑道；Loop 是跑道上的调度。
但多数 Coding Loop 的「收工条件」仍停在 lint 过、单测绿。做 App、做 Web 的人都清楚：代码能合并，不等于产品验过------界面点一遍、真机跑一遍，往往还得人手上阵。Loop 表面上在转，产品验证这条支路却常常是断的。
5. Graph：多条 Loop 怎么接线（2026 年 7 月）
大约六周后，还是 Steinberger，抛出下一层问题：
Are we still talking loops or did we shift to graphs yet?
解读文章很快涌出来：Loop 管的是「单个 Agent 这一圈怎么转」；Graph 管的是「多个 Agent、多条 Loop 怎么组织」------谁先谁后、怎么分支、状态怎么传、卡在哪等你拍板、失败往哪退。
工具其实更早就有了：2024 年 1 月 ，LangChain 团队就推出了 LangGraph（Harrison Chase 等），用「有状态的图」跑能断点续跑的 Agent；AutoGen、各类 ADK 也在做类似事。2026 年中这波「Graph Engineering」热闹起来，新意不在发明新技术，而在大家开始用同一套说法讨论：多 Agent 的关系该不该画清楚。一画，很多以前靠 Chat 蒙混过去的步骤，就藏不住了。
对照着看：
| Loop | Graph | |
|---|---|---|
| 管什么 | 节点里：发现→执行→检查→下一轮 | 节点之间：谁依赖谁、怎么并行汇合、失败回哪 |
| 人干什么 | 设计调度 | 定角色、定检查点、定哪些步骤必须过关 |
| 容易过头 | 又把人嵌回环里点点点 | 为小事画一张五节点组织图 |
有句话说得很直白：Loop 允许你含糊着先转起来；一上 Graph，你就得承认------还有多少流程，其实从没想明白。
6. 未来展望：人定规则与验收，AI 跑节点
AI 工程发展到 Graph，故事并没有结束。近两年更可能出现的日常是：
模型还会继续变强，单靠「再写一句更巧的 Prompt」收益会越来越小。MCP、Skills、沙箱、权限策略会变成标配------Context 和 Harness 慢慢产品化。
个人和小团队的默认工作单元，会从「打开 Chat 开聊」，变成一条条能自己转的 Loop：你先写清目标和停止条件，系统迭代到停。
而一旦工作跨过「写代码」本身------还要过检查、部署、验证、交付------就需要把流程画清楚：谁干什么、失败回哪、卡住等谁、过关查什么。专长分节点，失败能隔离，关键步骤能等你拍板。
这里最关键的，是把验收锚点放在系统外面：单测绿、真机验过、你本人批准交付------这些不能被「更聪明的 Agent」悄悄优化掉。
人不会消失，只是杠杆变了：从「写下一句 Prompt」，变成「写清流程、验收标准，以及哪些步骤绝不能跳」。Cherny 说得对------活没有变轻松，变的是你在哪使劲。
说到底，缺的不是又一个更会聊天的模型，而是一套能把交付跑完、又能在关键处把控制权交回给你的系统。
这正是我们做 Munk AI 的原因。
7. Munk AI：把 Loop 和 Graph 集成进来
前面说的 Loop 和 Graph，听起来像方法论。落到产品里，总得有个能点、能跑的东西。
Munk AI 是跑在你电脑上的编排工作台。打开之后，你打交道的主要是两类对象：一条条 Work ，以及把多条 Work 拢在一起的 WorkSet。
名字可能有些抽象，但底下的分工，正好对应前面两层------
Work ≈ Loop：一条需求的基本单元。目标与收工条件定好之后，系统自己转------澄清、改代码、过检查、部署、验证、失败再修、最后写回仓库；搞不定就停下来等你，你点头后再接着跑。
WorkSet ≈ Graph：多条 Work 按依赖接线。谁先谁后、谁可以并行、谁卡住会堵后面，都画在集合上；每条子 Work 内部仍是自己那条 Loop，不必另起一套引擎。
简单说：简单需求交给 Work 跑完，复杂需求交给 WorkSet 拆分、编排。 手机也能远程看进度、处理卡住的步骤。
还有一块，Loop 文章里反复提到、却经常缺席的：产品验证。代码侧单测绿了不算完，App / Web 还得在真机、真浏览器上点过。
Munk Test 和 Device MCP 接在这条链上：真实界面上操作、验证------通过或不通过，连同截图与界面结构一起送回写代码那边，而不是你半夜截图贴回对话框。
| 像哪一层 | 干什么 | |
|---|---|---|
| Work | Loop | 单条需求转完：阶段推进、可暂停、可继续 |
| WorkSet | Graph | 多条需求按依赖编排：顺序、并行、解堵 |
| Munk Test + Device MCP | Loop 里的验证支路 | 真机 / 浏览器验证 + 独立判定，证据回传 |
一句话，目标很直白：
让 AI 持续打工，搞不定了再叫你。
白天丢进需求，夜里 Work 在本机运行，卡住了早上在 Inbox 或手机上拍板------这已经是我们自己在用的节奏。更复杂的活，就升到 WorkSet：把多条 Work 接成一张图来跑；需要时，再把发布接到交付后面。
术语怎么换都好，一件事用 Loop 跑完，多件事用 Graph 排开------这条主线不变。
写在最后
若按层次来看，大致是这样叠的------越往上，越不管单次怎么问，越管整条活怎么组织：
text
Graph ------ 多条跑道如何接线、在哪设关卡
Loop ------ 谁调度下一轮 Prompt
Harness ------ 单个 Agent 的跑道
Context ------ 这一刻看见什么
Prompt ------ 怎么问Munk AI 做的是上面两层：Work 把单条需求跑成可停可续的 Loop；WorkSet 把多条 Work 接成 Graph 来编排。设备 MCP 则补上验证：把「产品真的在真机上验过」写进收工条件。
术语还会继续换。验收放在外面、关键步骤等你点头、证据能回看------大概不会过时。
想试用 Munk AI 桌面端？ 目前 Macos 、Android 端已上线，欢迎访问官网获取：munk.sh/zh/install。
- 📮 公众号「朱涛的自习室」
- 👀 munk.sh
- 🐦 x.com/iBoyCoder