从Prompt到Harness：三年间，我们驾驭大模型的方式经历了怎样的进化？

2022年底，ChatGPT横空出世，整个世界为之震动。但你有没有意识到——三年过去了，我们和AI的交互方式，已经悄悄换了人间？

写在前面

如果你在2023年初问一个人"你怎么用ChatGPT"，他的回答大概率是："问它问题，它回答。"

如果你在2026年问同样的问题，他的回答可能是："我让一个Agent去帮我调研，另一个Agent写初稿，第三个Agent做Review，最后我自己过一遍。"

从「问答」到「多Agent协作交付」，这中间发生了什么？

这不是一个技术迭代的故事，这是一个交互范式迁移的故事。每一次跃迁，本质上都是同一件事：把人的负担，往系统那边再推一步。

我想把这三年的变化拆成四个层次来讲：Prompt → MCP → Skill → Harness。每一层不是取代上一层，而是在上一层的基础上叠加。就像TCP/IP协议栈，越往上越接近人的意图，越往下越接近机器的执行。

第一章 Prompt时代：人适应模型（2022-2023）

1.1 一切的起点：对话即编程

2022年11月30日，ChatGPT上线。五天，一百万用户。两个月，一亿用户。

那段时间，所有人都在做同一件事：试探这个模型的边界。

"给我写一首李白风格的诗""用莎士比亚的语气写一段代码注释""假如你是一个精神病学家……"

这些看似好玩的尝试背后，隐含着一个深刻的发现：大模型的输出质量，极度依赖于你输入的方式。

同一个问题——

• "Python怎么读文件？" → 得到一段基础代码
• "你是一个资深Python工程师，请用最佳实践实现一个健壮的文件读取函数，处理编码、异常、路径校验，附单元测试" → 得到一段生产级代码

差距是惊人的。

于是，Prompt Engineering（提示词工程）作为一个领域诞生了。

1.2 提示词的武器库

到2023年中，Prompt Engineering已经发展出一套相当成熟的方法论：

Zero-shot Prompting — 直接问，不给示例。最原始的方式，但模型足够强时也够用。

Few-shot Prompting — 给几个示例，让模型"照猫画虎"。OpenAI的GPT-3论文就证明了，短短几个例子，效果可以质变。

Chain-of-Thought（CoT） — 让模型"一步一步思考"。2022年1月Google Brain的论文提出，简单到令人难以置信：只要在Prompt末尾加上"Let's think step by step"，模型在推理任务上的表现就能大幅跃升。这可能是Prompt Engineering历史上性价比最高的发现。

ReAct — Reasoning + Acting。让模型交替进行"思考"和"行动"，先分析问题，再决定下一步做什么，然后观察结果，再继续思考。这个范式直接催生了后来的Agent概念。

角色扮演 — "你是一个资深的xx专家"，赋予模型一个身份和视角，让它的回答更有针对性和一致性。

结构化输出 — 要求模型以JSON、Markdown表格等格式输出，方便下游程序解析。

1.3 Prompt时代的本质

这些技巧看上去五花八门，但都指向同一个现实：模型够聪明，但我们需要学会怎么"跟它说话"。

这是一种人适应模型的范式。

你需要理解模型的"脾气"——它擅长什么、不擅长什么、什么样的指令格式它理解得最好、什么样的措辞会让它产生幻觉。你像一个驯兽师，需要学会用鞭子和糖果让猛兽表演。

但鞭子和糖果都有极限。

2023年中，人们开始碰壁：不管Prompt写得多精妙，模型也只能「说话」，不能「做事」。

你让它帮你订机票，它会说"很抱歉，我无法访问外部系统"。你让它查今天的天气，它会编一个看起来像真的但完全虚构的天气预报。你让它读你电脑上的文件，它做不到。

Prompt的时代，模型是一个有着惊人知识量但被困在玻璃缸里的学者——什么都知道，但什么都做不了。

于是，第二层进化开始了。

第二章 MCP与Tool Use时代：模型长出手脚（2023-2024）

2.1 从Function Calling到工具调用

2023年6月，OpenAI在GPT-4的更新中引入了Function Calling。这是一个看起来不起眼但意义深远的功能：模型不再只能输出文本，它还可以输出一个结构化的函数调用请求。

什么意思？

以前你问"杭州今天天气怎么样"，模型会说"我无法获取实时天气信息"。现在，模型可以输出：

{
  "function": "get_weather",
  "arguments": {"city": "杭州"}
}

然后你的系统调用天气API，把结果返回给模型，模型再输出："杭州今天多云，气温22°C，适合出行。"

模型第一次长出了手脚。

这不是简单的"搜索增强"。搜索增强是把搜索结果塞进上下文，模型依然是被动的。Function Calling让模型主动决定需要什么信息、调用什么工具，然后根据结果继续推理。

这是一个从"被动回答"到"主动行动"的质变。

2.2 工具生态爆发

Function Calling之后，工具生态如雨后春笋：

• 代码执行器 — 让模型写Python代码并实际运行
• 文件系统 — 让模型读写本地文件
• 搜索引擎 — 让模型实时搜索互联网
• 数据库连接 — 让模型查询企业内部数据
• API网关 — 让模型调用各种外部服务

OpenAI推出了Plugins生态，微软的Copilot全家桶把大模型接入了Office全家桶，各种"AI + X"的产品如潮水般涌现。

2.3 MCP：工具调用的"USB协议"

工具多了，问题也来了：每家厂商的工具调用格式都不一样。

OpenAI有自己的Function Calling格式，Google有自己的一套，Anthropic也有。每个工具提供方都需要为不同的模型做适配。这是一个典型的N×M问题——N个模型，M个工具，需要N×M个适配器。

2024年底，Anthropic提出了MCP（Model Context Protocol）——模型上下文协议。

MCP的核心思想很简单：定义一个统一的协议，让任何模型都能和任何工具通信。

就像USB协议统一了设备接口一样——你不需要为每个设备定制接口，只要都遵循USB标准就行。

MCP的架构：

• MCP Host — 需要使用工具的应用程序（比如Claude Desktop、Cursor）
• MCP Client — 和MCP Server通信的协议客户端
• MCP Server — 提供工具的服务端，每个Server暴露一组Tool和Resource

这个设计优雅地解耦了模型和工具：模型只管"我要做什么"，MCP协议负责"怎么和工具通信"，工具Server负责"具体执行什么"。

此后，MCP生态迅速壮大。从数据库连接到文件操作，从搜索引擎到企业内部API，几乎你能想到的工具都有人做了MCP Server。甚至出现了MCP Server的聚合平台，像npm一样安装和使用工具。

2.4 Tool Use时代的本质

MCP和Tool Use解决了Prompt时代最核心的局限：模型不能做事。

现在模型可以查天气、写代码、操作文件、调用API——它从一个"知识丰富的聊天者"变成了一个"能干活的助手"。

但新的问题出现了：工具是零散的。

就像给一个人配了一整间工具房——锤子、螺丝刀、扳手、电钻应有尽有——但如果你不知道修桌子应该先用哪个、后用哪个、遇到螺丝滑丝怎么办，工具再多也白搭。

你每次都需要明确告诉模型"先查这个API，再用那个工具处理数据，然后用另一个工具生成报告"——工具调用的编排负担仍然在人身上。

于是，第三层进化开始了。

第三章 Skill与Agent时代：模型学会方法论（2024-2025）

3.1 从"给你工具"到"给你手册"

Skill这个词，在AI领域并没有一个完全统一的定义。但在我看来，它的核心含义是：

Skill = 领域知识 + 工作流编排 + 工具调用策略

如果说工具是零件，Skill就是装配手册。不，比手册更高级——Skill更像是一个经验丰富的老师傅，他不仅知道用什么工具，还知道什么时候用、以什么顺序用、遇到意外情况怎么办。

举一个具体的例子。假设你要用AI帮你做代码Review：

只有Prompt的时代：你把代码贴给模型，说"帮我review一下"。模型给出一些泛泛的建议，常常遗漏关键问题。

有了Tool的时代：你可以让模型调用Git工具读代码、调用Linter检查格式、调用测试框架运行测试。但你需要一步步告诉它该做什么。

有了Skill的时代：你只需要说"Review这个PR"，Skill里的代码审查技能会自动：

1. 分析PR的变更范围和影响
2. 逐文件检查代码质量
3. 运行静态分析工具
4. 检查是否有安全漏洞
5. 验证测试覆盖率
6. 生成结构化的Review报告

你不需要指定每一步，因为方法论已经编码在Skill中了。

3.2 Agent：有策略的执行者

Skill解决的是"怎么做"的问题，Agent解决的是"做什么"和"为什么这样做"的问题。

Agent = 感知 + 规划 + 行动 + 反思

一个真正的Agent具备：

感知能力 — 理解当前的状态和上下文。不只是接收用户输入，还能主动获取信息（读文件、查API、搜索网页）。

规划能力 — 把大目标拆解成可执行的步骤。不是机械地执行预设流程，而是根据具体情况动态调整策略。

行动能力 — 调用工具执行操作。写代码、发邮件、改配置、跑测试……

反思能力 — 检查自己的输出，发现错误，回退重来。这是Agent和简单脚本最本质的区别——脚本只会傻跑，Agent会"想想自己做对了没有"。

2024年，Agent框架爆发式增长：

• LangGraph — 把Agent的工作流建模为图（Graph），支持分支、循环、条件跳转
• CrewAI — 多Agent协作框架，每个Agent有角色和目标
• AutoGen — 微软出品，强调多Agent对话协作
• OpenClaw — 个人AI助手框架，集成Skill、MCP、Cron等能力

这些框架的共同目标是：让Agent从"按指令干活"进化为"按目标干活"。

3.3 Agent的"顿悟时刻"

2024年有几个让我印象深刻的"Agent时刻"：

Devin — Cognition推出的"第一个AI软件工程师"。它不仅能写代码，还能自己打开浏览器看文档、调试运行错误、自主修复bug。虽然Demo和现实之间有差距，但它第一次让人看到了"AI自主完成开发任务"的可能性。

SWE-bench上的突破 — AI在真实软件工程任务上的表现快速提升。从最初的几乎无法解决任何问题，到解决20%+、30%+的真实GitHub Issue。

Claude的Computer Use — Anthropic让Claude直接操作电脑界面——看屏幕、移动鼠标、点击按钮。这是一种极端的"工具调用"方式：如果所有软件都是工具，那操作系统本身就是最大的工具。

3.4 Skill时代的本质

Skill和Agent解决的核心问题是：工具调用的编排。

以前：人想要一个结果，需要自己编排「用什么工具、按什么顺序、异常怎么处理」。

现在：人只需要给出目标和边界，Agent和Skill负责处理中间的所有细节。

用管理学的话说：我们完成了从"微观管理"到"目标管理"的跨越。

你不再需要告诉AI每一步做什么，你只需要告诉它"我想要什么"和"不要做什么"，中间的过程它自己搞定。

但人真的能完全放手吗？显然不能。Agent会犯错，会产生幻觉，会在错误的方向上越走越远。于是，第四层进化登场了。

第四章 Harness时代：驯服一群智能体（2025-）

4.1 从单兵作战到军团作战

Harness，英文原意是"马具、挽具"，引申为"驾驭、驯服"。

这个词汇的选择非常精准：我们面对的不再是一匹马，而是一群马。问题不是"怎么骑"，而是"怎么驾驭整个马队"。

2025年，AI使用的核心范式开始从"单Agent"向"多Agent协作"迁移：

Coding Agent + Review Agent — 一个写代码，一个审查代码。写的人激进，查的人保守，互相制衡。

Research Agent + Writer Agent — 一个负责调研收集素材，一个负责组织语言写文章。专业分工，各展所长。

Planner Agent + Executor Agent + Checker Agent — 规划者分解任务，执行者落实细节，检查者验证结果。三权分立，减少犯错。

这不是简单的"并行"，而是有组织的协作——每个Agent有自己的角色、职责、权限和沟通方式。

4.2 人在回路（Human-in-the-Loop）

Harness时代最重要的设计原则之一：Human-in-the-Loop。

完全自主的Agent？听起来美好，实际很危险。AI会自信满满地犯下人类绝不会犯的错误——删除重要文件、发送错误邮件、花掉不该花的钱。

所以Harness架构的核心不是"完全自动化"，而是**"关键节点有人把关"**：

• Agent写完代码 → 人工Review后再合并
• Agent发邮件 → 展示草稿，人工确认后发送
• Agent做决策 → 重要的决策需要人工批准

非关键路径完全自动化，关键路径必须人工确认。这就像公司里的审批流——日常采购部门自己定，大额支出必须CEO签字。

4.3 会话式编排

Harness时代的另一个关键变化：编排方式从"写代码"变成了"说话"。

以前的Agent编排需要写Python脚本、画状态机、定义转移条件。现在？你只需要说：

"帮我调研一下Flink在流式数据处理方面的最新进展，生成一份报告，然后发给团队。"

系统会自动：

1. 调度Research Agent去做调研
2. 调度Writer Agent来组织报告
3. 调度通知Agent发送消息

你不需要知道底下有多少个Agent在工作，不需要知道它们怎么通信，不需要知道它们的Prompt是什么。你只需要用自然语言描述你的意图。

这和软件工程的发展轨迹一模一样：从机器语言 → 汇编语言 → 高级语言 → 自然语言编程。每一层抽象，都让离"机器怎么执行"更远、离"人想什么"更近。

4.4 自愈与弹性

好的Harness还具备一个前沿能力：自愈（Self-healing）。

Agent执行任务时出错了怎么办？

早期：任务失败，等人工处理。

现在：Agent可以自己——

• 回退 — 回到上一步，换个策略重试
• 降级 — 如果Plan A不行，自动切换到Plan B
• 求助 — 自己搞不定时，主动向其他Agent或人类求助
• 学习 — 记住这次失败，下次避免类似错误

这就像一个有经验的员工——新人遇到问题会卡住，但老手会调整策略、找同事帮忙、换个方法再试。

4.5 Harness时代的实例

一个典型的Harness系统：

主Agent（Main Agent） — 负责理解用户意图，调度子Agent，整合结果。它是整个系统的"大脑"。

子Agent（Sub-Agent） — 被主Agent调度，执行具体任务。比如Coding Agent写代码，Research Agent做调研。每个子Agent是隔离的，有自己的上下文和生命周期。

Skill — 预制的工作流。比如"代码审查"Skill包含了整个Review流程的最佳实践。

MCP工具 — 底层能力。数据库访问、文件操作、搜索等。

Cron — 定时任务系统。让Agent不需要人盯着也能按时干活。

人在回路 — 发消息、写代码等敏感操作需要人工确认。

用户只需要说一句话，整个Harness系统就会自动编排、调度、执行、回报。

4.6 Harness时代的本质

Harness解决的核心问题是：多Agent系统的编排与治理。

当AI的能力足够强之后，瓶颈不再是"单个Agent能做什么"，而是"如何让多个Agent高效、安全、可控地协作"。

这就像从"个人贡献者"到"技术管理者"的转变：

• IC（单Agent）关注的是"我能不能做好这件事"
• Manager（Harness）关注的是"团队（多Agent）能不能高效、高质量地交付"

两种能力完全不同。前者需要技术深度，后者需要系统设计和治理能力。

第五章 四层的关系：不是替代，是叠加

5.1 协议栈类比

理解这四层演进，最直观的方式是把它类比为网络协议栈：

┌─────────────────────────────────┐
│       Harness（应用层）          │  意图表达 → 多Agent编排与治理
├─────────────────────────────────┤
│       Skill/Agent（传输层）       │  工作流编排 → 方法论与策略
├─────────────────────────────────┤
│       MCP/Tool（网络层）         │  工具调用 → 能力接入
├─────────────────────────────────┤
│       Prompt（数据链路层）       │  指令编码 → 人机沟通
└─────────────────────────────────┘

每一层依赖下层的支撑，同时为上层提供服务：

• 没有Prompt，模型都不知道你要它做什么
• 没有MCP/Tool，模型只能动嘴不能动手
• 没有Skill/Agent，模型没有方法论，每件事都要人从头编排
• 没有Harness，多个Agent各自为战，无法协作

同时，上层并不"取代"下层：

• 即便到了Harness时代，你依然需要写好Prompt（只是这件事被Skill封装了）
• 即便有了Agent，你依然需要工具调用（只是Agent替你决定调哪个）
• 即便有了Harness，每个Agent内部依然在做推理和规划

5.2 人的介入点上移

四层演进的趋势，用一句话概括：

人的介入点，从「操作层」持续上移到「意图层」。

层次	人做什么	模型做什么	类比
Prompt	精心措辞提问	回答问题的专家	教授答疑
MCP/Tool	挑工具、写调用	按指令执行的操作员	实习生跑腿
Skill/Agent	定义目标和边界	规划+执行+反思的项目经理	项目经理带项目
Harness	描述想要什么	多Agent协作交付的团队	CEO管公司

在Prompt时代，人要细化到"怎么说"；在Harness时代，人只需要"说什么"。

这和人类社会的管理演进一样：

• 微观管理（Micromanagement）→ 你告诉下属每一步怎么做
• 过程管理（Process Management）→ 你定义流程和规范
• 目标管理（MBO/OKR）→ 你定义目标和约束，过程交给团队

每一层，人都在"放手"更多细节，同时"掌控"更核心的决策。

第六章 还没解决的问题

讲到这里，容易给人一种"一切顺利、问题已解"的错觉。但现实远没有那么乐观。每一个时代都有它的"未解之痛"。

6.1 Prompt时代的遗留问题

• Prompt Injection — 恶意指令可以通过Prompt注入劫持模型行为。这是一个安全层面的根本性问题，直到今天也没有完美解决。
• Prompt的脆弱性 — 同一个Prompt，换一个模型、甚至换一个版本，效果可能天差地别。Prompt Engineering的"工程"二字，含金量存疑。

6.2 MCP/Tool的问题

• 工具选择错误 — 模型有时会"选错工具"，明明该用搜索却用了数据库查询。模型并不真正理解工具的语义。
• 工具调用链的可靠性 — 一个工具调用失败，整条链就断了。容错和重试机制远不如传统软件工程成熟。
• 安全边界模糊 — 给模型越多的工具权限，出事时的后果越严重。一个能"执行任意Shell命令"的Agent，和rm -rf /之间只差一个幻觉。

6.3 Skill/Agent的问题

• 过度自信 — Agent常常对自己的错误毫无察觉，自信满满地输出垃圾结果。反思能力远不如宣传的那样可靠。
• 成本失控 — Agent可能陷入"死循环"：不断重试、不断调用工具、不断消耗Token，直到你的API账单爆炸。
• 方法论僵化 — Skill编码了最佳实践，但"最佳实践"是有时效性的。今天的好方法，半年后可能就过时了。Skill的维护成本被严重低估。

6.4 Harness的问题

• 可观测性差 — 多Agent协作时，出了问题很难定位是哪个Agent的锅。调试一个Harness系统，比调试一个微服务架构还让人头疼。
• 编排复杂度 — "会话式编排"听起来美好，但自然语言的歧义性注定了误解不可避免。你说"调研一下"，Agent理解成"花5分钟搜一下"还是"花5天做深度研究"？
• 人机协作的平衡 — Human-in-the-loop的"度"很难拿捏。确认太多，人成了瓶颈；确认太少，等于没有护栏。

第七章 下一步：我们往哪里去？

预测未来是危险的，但有些趋势已经足够清晰：

7.1 意图的精确表达

从"问答"到"意图表达"，还有很长的路。当前的自然语言指令太模糊，未来的交互可能结合：

• 多模态输入 — 画个草图，AI就知道你要什么UI
• 示例驱动 — 给一个参考，AI就知道你要什么风格
• 渐进式细化 — 先粗略描述，AI提问澄清，逐步逼近精确意图

7.2 Agent的可靠性

Agent最大的问题不是能力不足，而是不够可靠。未来的突破可能在：

• 形式化验证 — 用数学方法证明Agent的某些行为是安全的
• 沙箱化执行 — Agent在受控环境中运行，错误不会扩散
• 置信度校准 — Agent知道"自己不知道什么"，不确定时主动求助而不是编造答案

7.3 Harness的标准化

当前每个Harness框架都是"各自为战"。未来可能需要：

• Agent间通信协议 — 类似MCP，但是Agent对Agent
• 编排DSL — 一种描述多Agent协作流程的标准语言
• 可观测性标准 — 统一的日志、追踪、指标体系

7.4 从"工具"到"伙伴"

最深远的变化可能是心理层面的：我们不再把AI当工具，而是当伙伴。

工具是什么？你拿起来用，放下就忘了。伙伴是什么？你信任它，依赖它，和它磨合，它会了解你的习惯和偏好。

今天，一个人的OpenClaw可以记住他的工作习惯、沟通风格、项目上下文——这不是工具该有的属性，这是伙伴才有的属性。

这种关系的转变，可能比任何技术进步都更深刻。

结语：从学会说话，到学会放手

回顾这三年的演进，我最大的感触是：

我们一直在学习如何"放手"。

Prompt时代，我们学会了怎么跟AI说话——但什么都得自己说。

MCP时代，我们学会了让它动手做事——但每件事都得自己安排。

Skill时代，我们学会了教它方法——但每个方法都得自己想。

Harness时代，我们终于开始学会放手——只说目标，让系统自己搞定过程。

学会放手，不代表不再掌控。恰恰相反——只有当日常的执行不再需要你的注意力，你才能真正专注于战略性的思考和决策。

CEO不需要亲自写代码，但他决定了公司做什么产品。同样，在AI时代，人的价值不在于"做什么"，而在于"想做什么"和"判断做得对不对"。

这不是AI取代人类的故事。这是人类从繁琐的执行中解放出来、专注于真正重要之事的故事。

当然，前提是我们能解决那些还没解决的问题。

但至少方向是清晰的：

人负责"想要什么"，AI负责"怎么做"。
Prompt定义意图，MCP提供能力，Skill编码方法，Harness编排协作。
每一层，都在让这个分工更加清晰、更加高效。

三年，四个层次，我们走了很远。但如果你问我，这一切才刚刚开始。

 

本文写于2026年5月，基于作者对AI行业三年演进的观察和思考。文中观点仅代表个人立场。

如果你觉得有意思，欢迎点赞关注，也欢迎在评论区讨论你对AI使用方式演进的理解。