从 Prompt 到 Harness：AI 能力边界扩展的完整脉络

一名 FDE（AI 前沿工程师）的视角：AI 应用从 0 到 1 的过程，本质上是不断重新划分"模型能做什么"与"工程要补什么"的边界。每一次技术浪潮，都是这条边界的一次外推。

一、一个前置判断

在人工智能从"实验室成果"走向"产业生产力"的进程中，前沿部署工程师（FDE）扮演着打通"最后一公里"的关键角色。FDE 的核心使命不仅是完成从需求到 AI 应用 0 到 1 的技术实现，更是对 AI 能力边界的持续探索与拓展。

回顾大语言模型（LLM）的演化史，其本质是一部 "AI 能力边界不断外延与工具化" 的进化史。但需要先明确一个前提：这条线------Prompt → Function Call → MCP → Skills------不是一条"线性淘汰"的线 。每一层都不是被下一层取代，而是被重新定位。

Function Calling 解决的是"要不要调用工具"，MCP 解决的是"怎么标准化地连接工具"，Skills 解决的是"怎么教 Agent 聪明地使用工具"。这几个问题叠在一起，而不是依次替换。理解这一点，是理解后面所有问题的前提。

二、总览：一条时间线看懂演进

时间	阶段	代表技术 / 协议	解决的核心问题
2022--2023	Prompt Engineering	Few-shot、CoT、结构化输出	让模型"听懂人话、按格式回答"
2023	Function Calling	OpenAI tools API、JSON Mode	让模型从"会说"到"会做"
2023	RAG	Embedding、向量数据库	突破模型知识的时间与私有边界
2024.11	MCP	Model Context Protocol	工具接入的 N×M 标准化
2023--2026	编排框架爆发	LangChain/LangGraph、Spring AI 系	把单次调用变成可运行的应用
2025.4	A2A	Agent2Agent Protocol	Agent 之间如何分工协作
2025.5	AG-UI	Agent-User Interaction	Agent 与前端的实时事件流
2025.10	Agent Skills	SKILL.md 规范	上下文经济学：工具/知识太多怎么装
2025.12	A2UI	Agent-to-User Interface	Agent 输出结构化界面而非纯文本
2025--2026	Harness Engineering	DeepSeek Harness 等	承认"Agent = Model + Harness"

三、AI 能力演化的五个核心阶段

1. 认知与对齐阶段：Prompt 与自然语言的魅力（2022--2023）

LLM 诞生之初，其核心能力在于自然语言理解与生成。人们发现的第一件事是：自然语言本身就可以是编程接口。通过 Prompt（零样本/少样本示例、思维链 CoT、角色设定、输出格式约束），不用写一行训练代码，就能让模型按要求完成任务。

这一阶段 AI 展示的是"理解与生成"的语言魅力，但边界清晰可见：只有训练截止前的公开知识，没有工具、没有记忆、不能行动。所有"让模型听话"的技巧，本质是在模型外部做控制------这埋下了后面所有工程的伏笔。

2. 工具调用启蒙阶段：Function Call（2023）

2023 年 OpenAI 在 GPT-4 上推出 Function Calling：模型推理时可以输出结构化的工具调用请求（函数名 + 参数 JSON），由外部程序执行后把结果回填给模型。

这一步的革命性在于：模型第一次获得了"手"。查天气、查数据库、调内部 API------只要封装成函数描述（name + description + parameters schema），模型就能自己决定何时调用、传什么参数。模型输出的不再只是自然语言文本，而是一个结构化的函数调用指令。

但 Function Calling 有一个严重的工程问题：N×M 的连接爆炸。N 个 AI 应用要对 M 个工具，每个组合都需要定制适配代码。接一个工具就写一套集成，脆弱且不可复用。Function Calling 是"能力"，但还不是"标准"。

3. 协议标准化阶段：MCP（2024.11）

2024 年 11 月 Anthropic 发布 MCP（Model Context Protocol），把"工具怎么接入模型"标准化为三层原语：Tools（可执行动作）、Resources（可读数据）、Prompts（预置提示模板），通过 JSON-RPC 通信。

它解决的核心问题是适配器矩阵爆炸 ：没有协议时，N 个客户端 × M 个工具要写 N×M 套胶水代码；有了 MCP，任何客户端都能接任何 Server------业内称之为"AI 工具的 USB-C"。MCP 的核心承诺是把 N×M 降到 N+M------工具方写好一个 MCP Server，所有支持 MCP 的 Host 都能调用。

这里需要修正一个常见误解：MCP 的架构里，Host（AI 应用）通过 Client 连接 Server，Server 暴露 tools、resources、prompts 三类能力。这些能力确实在外部，但 MCP 做的不是"让模型内部拥有能力"，而是让模型应用以一种统一的方式去发现和调用外部能力。模型本身没有变，变的是它周围的那套连接层。

MCP 的现状：热度退了，地位升了

热度确实退了，但没有死，而且正在从"狂热期"进入"务实期"。

2025 年 3 月是 MCP 的舆论巅峰，铺天盖地的教程和"不追就落后"的紧迫感。到 2026 年，那种喧嚣已经消失。但数据层面，MCP 的采用规模其实在持续增长：

2025 年 12 月 9 日，Anthropic 把 MCP 捐赠给 Linux 基金会下新成立的 Agentic AI Foundation（AAIF），白金会员包括 AWS、Google、Microsoft、OpenAI 等。
发布一周年时已有 9700 万+ 月 SDK 下载、1 万+ 活跃 Server，被 ChatGPT、Claude、Cursor、VS Code、Copilot 等原生支持。
2026 年 9 月 AAIF 脉搏调查（n=186）：81% 的组织在生产环境运行 Agent，89% 使用或评估 MCP；Claude 累计 MCP 工具调用突破 10 亿次。
协议仍在进化：2026-07-28 版规范转向无状态核心（每请求自包含，便于水平扩展）、可选扩展框架（Tasks、MCP Apps）和免握手发现。

但与此同时，质疑声音非常具体且来自一线。Perplexity CTO 公开表示内部在降低 MCP 优先级，转回 API 和 CLI。YC CEO Garry Tan 在推特上直接说"MCP sucks"。ScaleKit 的基准测试显示，CLI 方案的任务完成率 100% ，MCP 只有 72%，失败原因主要是超时和连接不稳定。

所以"是否还是主流"要看场景：多 Agent 共享同一工具、需要"一次开发多端复用"的企业场景，MCP 仍然有结构性的价值。但对于单 Agent、工具集固定、追求 token 效率的场景，CLI + Skills 的组合正在成为更务实的选择。

结论：MCP 在"为 AI 扩展外部能力"上仍是绝对主流，且已从"厂商方案"毕业为"行业标准"。

不用 MCP 的替代方案

主要替代方案是 CLI + API + Skills 文件的模式，正在被越来越多的大厂采用。

裸 Function Calling：工具少、变化慢的业务直接代码内定义 schema，无协议开销；
框架原生工具抽象 ：LangChain Tools、LlamaIndex、Spring AI 的 @Tool 注解；
CLI + Skills 文件 ：字节跳动的飞书/Lark 开源了官方 CLI，覆盖 11 个业务域、200+ 命令，内置 19 个 Agent Skills。Google 推出了 gws 用于 Google Workspace。Zilliz 也走了同样的路线：发布 Zilliz CLI + Skills，让 Claude Code 和 Codex 通过自然语言管理向量数据库。这个模式的核心优势是 token 效率 ------实测中，CLI 方案比 MCP 方案便宜约 17 倍 ，可靠性接近 100%。直接 API 调用配合 Agent Skills，在 token 效率上比 MCP 高 33% ，批量吞吐量高 30 倍。
不同层协议（非替代而是分层）：AG-UI/A2UI 管人机交互，A2A 管 Agent 间协作（IBM 的 ACP 已于 2025.8 被 A2A 吸收）。

但这不是"MCP 被淘汰"的故事。更准确的判断是：如果工具自带成熟的官方 CLI，用 CLI + Skill 文件替代 MCP 是合理的；如果需要跨多个 Agent 共享同一套工具接口，MCP 的标准化价值仍然不可替代。

4. 动态路由与上下文优化阶段：Skills（2025.10）

随着 MCP 工具集越来越庞大，一次性将所有工具能力平铺给 LLM 会导致上下文爆炸和选择精度下降。一个标准的 MCP 配置可以在 Agent 执行任何操作之前，就消耗掉大约 72% 的上下文窗口。接三个 Server（GitHub、Playwright、IDE），在 200K token 的模型上，光工具定义就占掉约 143K token。

更严重的是，工具数量增加反而降低了工具选择准确率。有实测数据显示，随着工具数量上升，选择准确率从 43% 跌到了 14% 以下 。这就是所谓的 context rot------上下文过载导致推理质量下降。

2025 年 10 月 16 日 Anthropic 推出 Agent Skills：一个 Skill 是一个带 SKILL.md 的文件夹，核心设计是渐进式披露（Progressive Disclosure）：

第一层（常驻）：名称+描述，约 100 tokens/个，模型据此路由；
第二层（触发时）：加载 SKILL.md 正文，约 5K tokens；
第三层（执行时）：按需读取参考文件、运行脚本。

效果：几十个 Skill 共存不撑爆上下文；Skill 成为团队知识的 token 化封装。2025 年 12 月 18 日规范开放，数周内 OpenAI（Codex CLI/ChatGPT）、Google（Gemini CLI）、GitHub Copilot、Cursor 全部跟进。

注意：Skills 不只是"工具目录"，它管知识和流程；MCP 管连接。2026 年两者互补------MCP 是接口层，Skills 是规范层。

"Skills 类似一本书的目录"这个类比接近但不完全对 。Skills 更像是一本按需翻开的操作手册 ：目录阶段确实只给你条目，但一旦翻到某一页，它不只是告诉你"去用某个工具"，而是直接给出"遇到 X 情况按 Y 步骤做，出错时走 Z 分支"的完整流程。Skills 教的是过程知识，不是工具清单。

5. 交互与协同智能阶段：A2UI 与 A2A（2025.4--2025.12）

A2A（Agent-to-Agent，2025.4）：突破了单 Agent 的局限。2025 年 4 月 Google 推出 A2A 协议：Agent Card 声明能力、Task 分发任务、Artifact 传递成果；2025 年 6 月捐给 Linux 基金会，后吸收 IBM 的 ACP，成为 Agent 间通信统一标准。主 Agent 可以将复杂任务拆解并布置给其他专职 Agent（如代码 Agent、检索 Agent），最后由主 Agent 进行结果汇总。这标志着 AI 从单体智能迈向了群体协同智能。
AG-UI（2025.5）：CopilotKit 推出，事件传输层，约 16 种标准事件（文本流、工具调用、状态补丁、生命周期），跑在 SSE/WebSocket 上。
A2UI（Agentic UI / 生成式 UI，2025.12）：突破了纯文本交互的限制。Google 推出 A2UI，v0.8，声明式内容层------Agent 输出 JSON 组件树（按钮、表单、图表），客户端从预审批组件目录渲染原生 UI，而非执行任意 HTML/JS，从设计上规避 XSS；2026 年 4 月发布 v0.9。AI 不仅能返回文字，还能根据意图动态渲染前端组件，使得人机交互更加人性化，降低用户的输入成本。

时间线修正：A2A（2025.4）→ AG-UI（2025.5）→ A2UI（2025.12）。三者分层互补：MCP 给 Agent 工具、A2A 给 Agent 同事、AG-UI/A2UI 给 Agent 用户。AG-UI 是管道（怎么传），A2UI 是载荷（传什么界面），常配合使用。

四、技术演进背后的框架生态

在上述技术演进的每一个阶段，都涌现出了相应的开发框架来解决特定的工程痛点。按照技术栈和解决的问题，可归类如下：

1. 基础调用与链式编排（解决 0 到 1 的连通问题）

OpenAI SDK (Python) ：解决最基础的 LLM 对话与原生 Function Call 调用，是所有 AI 应用的底层基石。→ 2025 年演进为 Agents SDK，提供轻量 Agent 循环（handoff/guardrails/tracing）。
LangChain (Python, 2022.10)：解决早期 AI 应用开发中的"胶水"问题，提供统一的接口封装、记忆管理和链式调用，适合快速构建线性的 AI 工作流。LCEL 链式编排。
LlamaIndex (2023)：数据/RAG 优先，百种数据源连接器。

2. 状态管理与动态路由（解决复杂逻辑与循环控制问题）

LangGraph (Python, 2024)：随着 SKILLS 和动态工具选择的出现，线性链路无法满足"条件判断、循环重试、状态回溯"的需求。LangGraph 引入了图结构，将 Agent 的决策过程建模为状态机，解决了复杂多步推理与动态路由的编排问题。支持循环、持久化、断点恢复、人在环。
AutoGen（微软）/ AG2 (2023.9)：多 Agent 对话式协作鼻祖。
CrewAI (2024)：角色+任务式团队编排，低门槛。
smolagents（HF, 2025.1）：极简：让模型写代码当工具（Code Agent）。
PydanticAI / Agno (2025)：类型安全、高性能轻量框架。
FastMCP (2025)：几行代码写出 MCP Server。

3. 企业级集成与标准化（解决工程化落地与现有 IT 架构融合问题）

Spring AI (Java, 2024) ：面向 Java 企业级生态，解决 AI 能力与传统 Spring Boot 微服务架构的无缝集成问题。它将 MCP、Function Call 等概念抽象为 Spring 标准的 Bean 和注解，降低了 Java 企业级应用接入 AI 的门槛。提供 Spring 风格统一抽象：ChatModel/EmbeddingModel/VectorStore/Advisor，@Tool POJO 即工具。
Spring AI Alibaba (2025)：国产模型适配、Graph 工作流编排、McpRouter/McpServer、RAG 全家桶。
LangChain4j：LangChain 的 Java 移植，AI Services 声明式接口。
Semantic Kernel（微软）：插件+规划器抽象，C#/Python/Java 三语言。
AgentScope (Java/Python 多语言)：专注于多 Agent 系统的构建，解决 A2A 阶段的协同问题。它提供了角色定义、消息传递和群组聊天的底层支持，让主 Agent 能更高效地调度子 Agent。

勘误：AgentScope 是阿里 ModelScope 开源的多智能体框架，主体是 Python（非 Java）；低代码侧另有 Dify、Coze、n8n、Flowise 解决业务编排与接入。

4. 业务判定与自我纠错（解决"最后一公里"的确定性问题）

Jev 模型（Judge/Execute/Verify 业务判定体系） ：

在真实业务场景中，LLM 的几率性输出往往无法满足工业级的确定性要求。Jev 体系（或类似 LLM-as-a-Judge 机制）专门用于业务判断：
- Judge（判定）：预判需求是否在 AI 能力边界内，选择合适的 SKILL。
- Execute（执行）：调用工具或子 Agent 执行任务。
- Verify（校验）：对 AI 生成的结构化数据或执行结果进行业务规则校验（如时序校验、格式校验）。如果不通过，则触发重试或回退机制。这一体系确保了 AI 从"能说话"向"能可靠干活"的跨越。
旁支：Judge / Eval 模型------让 AI 评判 AI

即 LLM-as-a-Judge（裁判模型）：输出质量打分、业务规则校验、工具调用结果验收、RAG 忠实度检测，或作为 Reward Model 参与强化学习。前面所有阶段在扩展"做事的能力"，Judge 模型补上"验收的能力"------没有它，Agent 系统无法闭环、无法进生产。

五、Harness Engineering：Agent = Model + Harness（2025--2026）

社区在分析 DeepSeek-V3.2-Exp 等模型时发现：同样的模型，换不同的外围代码（Agent 循环、重试、上下文压缩、工具管线），得分天差地别。于是 Harness Engineering 成为显学：

Agent = Model + Harness

模型是引擎，Harness 是车身：Prompt 编排、上下文管理、记忆、权限审批、子 Agent 协调、错误恢复、UI------模型之外的一切都是 Harness。

一个被反复引用的公式是：Agent = Model + Harness。Harness 涵盖系统提示词、工具调用逻辑、文件系统访问、沙箱环境、编排流程、钩子中间件、反馈回路、约束机制------所有让一个语言模型变成"能干活的 Agent"的运行时脚手架。

这个概念在 2026 年 2 月被正式命名，随后由 OpenAI 通过一个实验推向主流：3 名工程师，5 个月，零手写代码，交付百万行代码。他们做的工作不是写代码，而是设计约束模型行为的环境、工具、验证和反馈回路。

DeepSeek Harness 与 MCP 不是同一维度

2026 年 8 月 DeepSeek 开源 DeepSeek Harness（dsh）：MIT 协议、TypeScript、基于 Cordis 插件内核的 Agent 运行时，"一切皆插件"------模型适配器、工具、Skills、会话、沙箱、存储、甚至 Agent Loop 本身都可插拔替换；工具调用拆成 Hook→审批→权限→沙箱→超时→结果改写的可扩展流水线，内置 PTC（Programmatic Tool Calling）模式。

	MCP	DeepSeek Harness
本质	协议（连接标准）	运行时框架（装配底座）
解决的问题	工具/资源如何被发现和调用	模型如何被组装成可靠 Agent
类比	USB-C 接口标准	整车底盘+电气架构
关系	dsh 把 MCP 当插件之一接入外部工具	可消费 MCP，也有自有工具系统

打个更完整的比方：MCP 像是 USB 协议，Harness 像是操作系统。USB 协议让设备之间能通信，操作系统负责调度这些设备、管理进程、提供用户界面。

dsh 的独特之处在于它的 "Everything is a Plugin"架构 。在 Claude Code 和 Codex 里，harness 是一个固定外壳，你只能通过 MCP 或 API 扩展，但换不掉核心。而在 dsh 里，连 Agent 循环本身都是插件，产品和扩展之间的界线根本不存在。官方架构文档明确列出了最核心一层的 7 个包，全部以插件形式组织。

简单说：Harness 就是模型之外的一切 。DeepSeek Harness 是这个范式的一个具体实现。它把传统上属于 harness 底层框架的东西全部拆成了插件，底层使用 Cordis 插件系统。当前版本是 0.1.6-alpha.2，仍处于 developer preview 阶段，官方明确提醒会有破坏性变更。

六、总结：一张分层图

复制代码

┌─────────────────────────────────────────────────┐
│ 交互层   AG-UI（事件流） + A2UI（声明式界面）      │
├─────────────────────────────────────────────────┤
│ 协作层   A2A（Agent ↔ Agent 任务委派）            │
├─────────────────────────────────────────────────┤
│ 知识层   Skills（SKILL.md 渐进披露）+ RAG         │
├─────────────────────────────────────────────────┤
│ 能力层   MCP（工具/资源/提示 连接协议）            │
├─────────────────────────────────────────────────┤
│ 运行时   Harness（Agent Loop/上下文/权限/容错）    │ ← LangGraph、Spring AI、dsh 都在这层
├─────────────────────────────────────────────────┤
│ 模型层   LLM（DeepSeek/GPT/Claude/Qwen...）       │
└─────────────────────────────────────────────────┘
   横切：Judge/Eval 模型（验收） · 编排框架（胶水）

从 Prompt 的文本对齐，到 MCP 的标准化工具接入，再到 Skills 的动态路由与 A2A 的多智能体协同，AI 的能力边界正在以惊人的速度向外拓展。作为前沿部署工程师（FDE），掌握这些技术演进的时间线与底层逻辑，不仅是构建现代 AI 应用的需要，更是精准识别业务场景、定义产品边界、最终打通技术到现实生产力"最后一公里"的核心武器。

七、回到最初的问题：AI 的能力到底是什么？

如果一定要给一个答案，我倾向于这样说：

AI 的能力边界，不取决于模型本身知道什么，而取决于你为它设计了多少"可操作的接口"和"可遵循的流程"。

Prompt 时代，接口是自然语言。Function Call 时代，接口是结构化函数签名。MCP 时代，接口是标准化的工具发现协议。Skills 时代，接口变成了"你教它怎么做一件事"的过程文档。Harness 时代，接口是整个运行时环境本身。

每往前一步，模型本身的能力并没有发生本质变化。变化的是我们怎么把外部世界翻译成模型能理解和操作的形态 。这就是 FDE 和 AI 前沿工程师真正在做的事情------不是训练更好的模型，而是设计更好的接口、更好的流程、更好的约束，让同一个模型在不同的 harness 下表现出从"只能聊天"到"能交付百万行代码"的巨大差异。

给 FDE 的三点启示

边界不断上移：难点从"怎么让模型听话"变成"怎么在协议与框架的分层地图里选对积木"。
协议是地基，框架是装配：MCP/A2A/AG-UI 解决互操作，LangGraph/Spring AI/dsh 解决可运行，Skills 解决知识封装，Judge 解决可信度。
范式公式已改写：别再问"这个模型能干什么"，要问"这个模型 + 哪套 Harness，在我的业务验收标准下能干到什么"。