一、LLM（Large Language Model，大语言模型）

1.1 本质理解

LLM是参数量在十亿到千亿级的深度神经网络，通过海量文本自监督训练获得语言统计规律与一定推理能力。作为前端工程师，理解LLM的三个本质属性至关重要：

1. 概率性输出 - 同一输入可能产生不同输出
2. 上下文窗口限制 - 有最大token数量限制
3. 知识截止日期 - 训练数据有时间边界

1.2 模型生态全景（截至2026年4月）

国外闭源阵营

模型	开发方	核心优势	实战备注
Claude Opus 4.6	Anthropic	编程能力天花板，SWE-bench Pro领先	主动做可用性检查，长程任务最稳
GPT-5.4 Pro	OpenAI	原生Computer Use，可操控桌面软件	价格极高，输出$180/百万Token
Gemini 3.1 Pro	Google DeepMind	多模态融合原生支持视频/音频	适合多媒体应用场景
Mythos Preview	Anthropic	网络安全专项，SWE-bench Pro 77.8%	漏洞分析场景专用

国外开源阵营

• Llama 系列 - Meta开源，社区活跃
• Mistral 系列 - 欧洲开源力量

国产模型：第一梯队的现实

模型	开发方	特点	落地注意事项
GLM-5.1	智谱AI	全球最强开源模型之一，SWE-bench Pro刷榜	少数达8小时级持续工作能力的开源模型
MiniMax 2.7	稀宇科技	2026.4.12开源，性能接近Claude/GPT-5.4	推理成本低，但实际调用有稳定性问题
DeepSeek-V3	深度求索	中国本土研发，部分版本开源，开源社区高关注度	V4预计2026.4下旬发布，将原生集成多模态
Qwen系列	阿里通义	中文理解最优，合规性好	国内企业部署首选
文心一言	百度	国内合规第一梯队	中文场景稳定

1.3 前端实践路径

三种主流调用方式：

1. 直接API调用 - 通过HTTP请求调用模型API
2. SDK集成 - 使用官方或社区SDK
3. 中间层路由 - 通过OpenRouter等统一接口调用多模型

前端工程师的核心工作不是训练模型，而是为LLM搭建一个可靠的运行环境——这正是后续概念要解决的问题。

---

二、Prompt（提示词）

2.1 本质：与模型的"编程语言"

Prompt设计本质是给模型搭思考脚手架。关键技巧：

• 角色设定 - 明确AI扮演的角色
• 任务分解 - 将复杂任务拆解为步骤
• 输出格式 - 指定期望的输出结构
• Few-shot示例 - 提供示例引导输出

2.2 工程化实践

src/
  prompts/
    code-review.md          # 代码审查提示模板
    api-doc-gen.md          # API文档生成模板
    component-builder.md    # 组件代码生成模板
    __tests__/
      prompt.spec.ts        # Prompt版本对比测试

版本管理要点：

• 使用Git管理Prompt版本
• 建立Prompt评估基准
• A/B测试不同版本效果

调试工具：

• LangSmith
• Weights & Biases
• 自建评估流水线

---

三、MCP（Model Context Protocol，模型上下文协议）

3.1 什么是MCP

Anthropic提出的开放协议，标准化AI应用与外部数据源、工具的交互。类比：AI世界的USB-C接口——任何MCP客户端都能调用任何MCP服务器暴露的能力。

3.2 三层架构

组件	职责	示例
Host	运行LLM的客户端程序	Claude Desktop、Cursor、VS Code插件
Client	与服务器保持1:1连接的会话层	SDK中的Client实例
Server	暴露具体能力的轻量级程序	读文件、查数据库、调用内部API

协议定义了三种原语：Tool（执行操作）、Resource（暴露数据）、Prompt（可复用模板）。

3.3 前端实践：MCP Apps

2026年1月Anthropic推出MCP Apps（SEP-1865），允许服务器在对话窗口内直接渲染富交互UI：

AI调用工具 → 客户端获取UI资源 → 沙盒iframe渲染 → postMessage双向通信

这意味着AI输出可以超越纯文本——渲染表单、图表、拖拽面板。前端工程师的核心价值转向设计这些MCP UI，让AI从"回答问题"升级为"交付可交互的工作成果"。Slack、Figma、Asana已率先集成。

3.4 争议与路线图

• 协议仍在快速迭代中
• 安全性和权限模型待完善
• 社区生态正在形成

---

四、Skill（技能）

4.1 定义

Skill是可复用的"AI能力包"，封装完成特定任务所需的知识、流程、工具和成功标准。通常以Markdown文件形式存在。

Skill vs Prompt：Prompt是一次性指令，Skill包含流程纪律——会引导AI按固定顺序执行多个步骤，每一步都有明确验证条件。

4.2 社区热度

Anthropic官方Skill仓库在GitHub已收获超116K星标，成为社区重要参考。典型的Skill结构：

# code-review-skill.md

## 角色
你是一位资深前端代码审查专家。

## 检查清单
- [ ] 类型定义完整性
- [ ] 组件可访问性
- [ ] 性能隐患
- [ ] 单元测试覆盖

## 输出格式
### 严重问题（必须修复）
### 建议优化
### 优秀实践表扬

## 可用工具
- run_eslint
- run_tsc
- get_file_diff

4.3 前端落地

src/
  skills/
    frontend-component-builder.md   # 规定：先写测试→类型定义→组件实现→Storybook
    api-client-generator.md         # 从OpenAPI生成TypeScript客户端
    accessibility-audit.md          # a11y审查流程

这种"技能即代码"的思路正成为AI Agent工程化的标准实践。

---

五、RAG（Retrieval-Augmented Generation，检索增强生成）

5.1 为什么需要RAG

LLM的三大硬伤：

1. 知识截止 - 训练数据有时间边界
2. 幻觉问题 - 可能生成看似合理但错误的内容
3. 私有知识缺失 - 无法访问企业内部数据

RAG在生成前先从外部知识库检索相关文档，将检索结果作为上下文注入——不改变模型本身，但效果显著：知识实时更新、答案可溯源、幻觉大幅降低。

5.2 核心工作流

用户提问 → Embedding向量化 → 向量检索(TopK) → 重排序(Rerank) → 拼接Prompt → LLM生成

5.3 召回率：RAG系统的"七寸"

有团队经过半年迭代才将召回准确率从63%提升至91%。纯向量检索的核心问题是语义塌陷：向量距离近的不一定是真正需要的答案。

优化策略全景

策略	原理	效果
混合检索	BM25关键词+向量语义，RRF合并	IBM证实三路召回(向量+全文+稀疏向量)最优
分块优化	递归分块400-512 token，重叠10-20%	基准测试达85-90%召回率
重排序	ColBERT对Top100-1000结果二次排序	效率比交叉编码器高两个数量级
Query重写	LLM生成2-3个同义问法扩展查询	显著提升匹配广度
HyDE	先让模型生成假想答案，用答案向量检索	在特定场景有奇效

5.4 生产环境实际坑位

阶段	典型问题	应对方案
文档预处理	PDF表格与文本分离、架构图识别为乱码、Excel关联字段被拆散	建立文档预处理流水线，提取图文关系和表格结构
检索环节	业务术语召回缺失（“KYC流程"查不到"客户尽职调查”）	建立术语同义词映射，混合检索兜底
生成环节	表格解析残留XML标签干扰输出	生成前清洗流水线：格式转换→噪声过滤→冗余检测

5.5 向量数据库选型

数据库	特点	适用场景
Pinecone	零运维托管，上手最快	快速验证，中小规模
Weaviate	原生混合搜索+知识图谱	需要多模态检索
Milvus	十亿级向量处理能力	大规模生产部署
Qdrant	复杂元数据过滤	需要强过滤条件

容量估算：1000万文档、1024维嵌入 ≈ 40GB向量存储。

5.6 可视化工具

工具	定位	特点
Flowise	零代码拖拽式	本地优先，npm安装即用
Langflow	可视化LangChain实验平台	可导出Python代码，适合深度定制
Dify	生产级一体化平台	内置监控、日志、用户管理，GitHub 138K星标

---

六、Vibe Coding：用自然语言"说"出应用

6.1 概念起源

Vibe Coding由OpenAI联合创始人Andrej Karpathy于2025年2月在社交平台提出，他将其描述为"完全沉浸于氛围，拥抱技术发展的指数级增长，并且彻底忘记代码的存在"。2025年，该词被《柯林斯词典》评为年度词汇。哈佛大学教育研究院的Karen Brennan教授甚至专门开设了一门为期六周的Vibe Coding课程。

定义：Vibe Coding是通过自然语言描述意图，让AI直接生成可运行的代码，开发者无需逐行编写代码，甚至可以不看生成的代码，只通过迭代对话完成开发。

6.2 AI Coding vs Vibe Coding

业内普遍认为两者不是一回事：

维度	AI Coding	Vibe Coding
目标用户	专业开发者	非专业开发者/快速原型
工作模式	人类主导+AI辅助，逐行审查	AI主导生成，人类只管验收
代码理解	开发者必须理解每行代码	可以不看代码，只看结果
适用场景	生产级项目、核心架构	个人项目、原型、低风险场景

Anthropic研究员Erik Schluntz的区分更为精辟：“只要开发者依然与模型保持着逐行修改与审查的紧密反馈循环，这就无法称之为真正的’氛围’。”

6.3 Vibe Coding的两面性

案例一：非技术者创造 — 北大文科博士刘耕使用Vibe Coding，在49天内独自开发出AI开放世界游戏ElseLand。

案例二：AI泔水陷阱 — 有开发者让GPT-5.2连续运行7天写出了数百万行代码的Chrome项目，最终发现完全无法运行、无法修复、无法复现，连被称为"屎山代码"的资格都没有。

6.4 行业共识与安全边界

谷歌云AI总监、Chrome前工程负责人Addy Osmani发出警告："Vibe Coding正在成为一种风险，而不是优势。“他指出AI永远没有质量保证——质量只能来自人类的专业判断。AI面临著名的"70%问题”：能在项目前70%阶段如鱼得水，但剩下30%（边界情况、性能优化、安全加固）只有经验丰富的工程师才能搞定。

Anthropic的Erik Schluntz为生产环境中的Vibe Coding提出了"叶子节点"策略：AI可以安全地接管不被其他模块依赖的末端功能或附加组件，这些区域即便产生一定技术债也是可接受的。但对于系统的主干与底层架构部分，工程师仍需深入理解并严密保护其可扩展性。

6.5 风险数据

GitLab与哈里斯民意调查机构的报告显示：73%的受访者遇到过"氛围编码"问题，即通过自然语言提示生成的代码缺乏对代码的清晰理解；76%的人指出大多数合规问题在部署后才被发现。

---

七、Spec-to-Application：AI时代的软件工程范式

7.1 从"写代码"到"定义规格"

在2026年，AI应用开发已迈入"AI原生"时代。开发重心从"编写代码"上移至"定义规格（Spec）"——开发者通过详尽的自然语言或结构化文档描述软件行为，由AI编程智能体直接生成可运行的代码、测试用例和部署脚本。

确定性 vs 概率性：传统软件追求100%的确定性，而AI应用软件是概率性的。开发者的核心任务是通过"护栏（Guardrails）"技术，将AI的不确定性限制在业务允许的范围内。

7.2 Spec Coding：AI开发的质量保证

Spec Coding通过显式规范约束生成过程，确保代码符合业务要求。

某物流系统的实践数据显示，引入Spec体系后，AI生成的代码一次通过率从31%提升至89%，缺陷密度下降76%。某金融科技企业的数据更触目惊心：未经规范约束的AI代码返工率高达67%。

Spec的四层结构模型：

1. 行为契约 - 定义系统应该做什么
2. 接口定义 - 规定输入输出格式
3. 数据格式 - 约束数据结构
4. 业务规则 - 嵌入领域逻辑

7.3 CodeSpeak：用形式化规约替代模糊Prompt

Kotlin语言创造者Andrey Breslav推出了全新的编程语言项目CodeSpeak，核心理念是"Talk to LLMs in specs, not English"。

自然语言与AI交流的根本问题：语义漂移（歧义导致理解偏差）、可维护性差（长Prompt难以版本管理）、缺乏类型约束（LLM无法感知复杂类型系统）。CodeSpeak通过形式化规约来指导AI生成代码——开发者首先定义数据结构和逻辑边界，使用类DSL的语法描述"程序应该做什么"而非"怎么做"，通过规约建立确定性的防护栏。

7.4 实战架构：Spec + MCP + Hook协同链路

复杂UI的Spec开发实践，完整流程如下：

输入原型URL → 激活Hook B（视觉协议桥接）
    ↓
MCP感知层：navigate_page（访问） → take_snapshot（DOM审计） → take_screenshot（视觉采样）
    ↓
生成结构化Spec & Task.md（动态校准闭环：循环采样探测 → 特征反馈 → Spec优化）
    ↓
Rules注入（组件映射约束 + 视觉规范约束 + 架构模式约束）
    ↓
原子任务执行（配置环境锚点 → 阶段1-4执行 → 前后MCP截图对比校验）
    ↓
偏差检测 → 重新生成 / 校验一致 → 高质量交付

这套机制的价值在于：消除幻觉约束（Spec为AI提供了清晰的操作边界）、解决逻辑断层（通过预定义架构协议确保代码逻辑自洽）、规模化交付的共性（团队所有AI开发遵循同一套Spec，避免"千人千面"的代码污染）。

---

八、SDD（Spec-Driven Development，规格驱动开发）

8.1 定义与四阶段工作流

Spec-Driven Development的核心思想是：在AI智能体编写一行代码之前，它首先依据一份结构化的、上下文丰富的规格说明来工作，这份规格定义了系统应该做什么、具备什么属性，以及"正确"的含义。

GitHub主导推广的SDD方法论采用标准化的四阶段工作流：

1. Specify - 定义规格
2. Plan - 制定计划
3. Tasks - 拆解任务
4. Implement - 执行实现

这不是单纯追求"写得快"，而是追求"写得对"——让每一行生成的代码都有据可依、可追溯、可验证。

8.2 为什么SDD是Vibe Coding的终结者

SDD的兴起背景是Vibe Coding暴露出的问题：代码质量不稳定、架构设计混乱、安全漏洞频出、生成结果不可预期。SDD通过以下机制解决了这些顽疾：

Vibe Coding痛点	SDD解决方案
生成代码质量随机	规格作为"单一事实来源"，每行代码都对照规格生成
缺少全局架构约束	规格定义完整的系统边界和架构决策
无法验证正确性	结合TDD，规格自动生成验证测试
上下文丢失	规格作为持续锚点，Agent始终知道"该做什么"

实践数据：Constitutional Spec-Driven Development研究显示，将安全原则嵌入规格层后，与无约束AI生成相比，安全缺陷减少了73%，同时保持了开发效率。

8.3 企业级落地案例

团队	成果	数据
AWS工程团队	18个月重架构项目	原计划30人，实际6人76天完成
Amazon.com	"添加到配送"功能	提前2个月上线
Kiro IDE团队	用Kiro构建Kiro IDE	功能构建从2周压缩到2天
Alexa+、Amazon Finance等	全面集成SDD	构建流程标准化

以上数据均来自AWS官方发布的企业实践报告。

InnoGames实践：在一款超100万行代码的多平台游戏上使用SDD工作流，实现了"即使在大型生产级代码库上，也能100%由AI编写代码，而不牺牲代码质量、架构完整性和开发者心智健康"。

8.4 工具生态

• Kiro - AWS推出的SDD原生IDE
• Cursor - 支持Spec文件的AI编辑器
• GitHub Copilot Workspace - 集成SDD工作流

8.5 什么场景不适合SDD

SDD也有其局限性：

• 小型Bug修复（规格撰写成本高于收益）
• 快速原型验证（需要快速试错而非严密规划）
• 单人独立项目（流程开销超过价值）

8.6 Spec和SDD关系

在当前的AI工程化语境下，Spec 与 SDD 并非对立概念，而是"内容"与"方法"的关系：

• Spec = 规格文档本身（内容）
• SDD = 围绕Spec的开发方法论（流程）

一句话区别：Spec是"写什么"，SDD是"怎么用Spec来开发"。

落地建议：

• 先学会写好Spec
• 再按SDD流程组织开发
• 工具只是辅助

---

九、WebMCP：浏览器端的AI工具协议

9.1 定义与定位

WebMCP（Web Model Context Protocol）是2026年2月由谷歌Chrome团队推出的浏览器API，允许网站将结构化的工具暴露给AI智能体直接发现和执行。

生态定位：如果说MCP解决了AI与后端服务的连接，那么WebMCP则补齐了AI与浏览器前端业务上下文交互的最后一块版图。用开发者Alex Volkov的话来说：“WebMCP就相当于UI里的API。”

9.2 理解AI操控网页的三层架构

无头浏览器工具是AI的"手和眼"；而WebMCP是网站主动为AI伸出的"标准接口"。它们在不同层面上，共同解决AI操控网页的问题。

第一层：MCP——AI的"USB-C通用接口"

无论是无头浏览器工具，还是WebMCP，都建立在一个共同的基础上——模型上下文协议（Model Context Protocol, MCP）。

可以把它理解为一个标准化的"USB-C接口"。MCP协议为AI模型提供了一套统一的"插头"，让它可以安全、标准地连接和使用各种外部工具（比如文件系统、数据库、以及浏览器），从而极大地扩展了AI的能力边界。

第二层：当前主流方案——MCP浏览器服务器（“AI驾驶浏览器”）

这指的是各类无头浏览器工具（如Playwright、Puppeteer等）。它们的运作模式是：AI通过MCP协议，向外部的浏览器自动化服务器下达指令。就像AI在驾驶一辆名为"浏览器"的汽车。

这套方案非常成熟，目前几乎所有基于MCP的浏览器自动化都采用这个模式：

• AI充当"驾驶员"：AI Agent通过MCP客户端，向一个作为"MCP服务器"的独立程序发送指令
• 服务器是"方向盘和踏板"：MCP服务器（例如 Playwright MCP Server）接收到AI的指令后，再调用底层的自动化工具库去实际控制浏览器
• 浏览器是"汽车本身"：被控制的浏览器通常是"无头"模式（Headless），即没有图形界面。也有工具能直接控制真实浏览器

一个典型的MCP服务器会通过工具集（Tool Set），向AI提供一系列浏览器操作能力：navigate（导航）、click（点击）、fill（填写表单）、screenshot（截图）等。

第三层：未来新范式——WebMCP（“网站主动服务AI”）

WebMCP是完全不同的新思路，目前由谷歌Chrome团队主导，处于早期实验阶段。

如果说当前方案是AI去"驾驶"浏览器，那么WebMCP就是网站自己从后台主动走出来，为AI提供直接的"服务接口"。它允许网站在其前端代码中，直接向AI暴露结构化的功能调用，比如searchFlights()（搜索航班）或bookTicket()（预订机票）。

9.3 MCP浏览器服务器 vs WebMCP 详细对比

对比维度	MCP浏览器服务器（如Playwright）	WebMCP（如Chrome WebMCP）
交互方式	AI模拟人类行为："看"屏幕截图找元素、“点"击坐标。需要"看到"并"点击”	AI直接调用API："问"网站能做什么，“调"用功能。是一种功能性的"对话”
核心原理	外部控制浏览器，依赖视觉识别或DOM解析	网站内置标准接口，AI可原生发现和调用
主要优势	通用性强：适用于几乎所有现有网站，无改造负担	稳定高效：不依赖UI变动，速度快，无需消耗Token解析页面
关键劣势	成本高、稳定性差：易受网站改版影响，需消耗大量Token分析页面	依赖网站改造：需要网站开发者主动集成该标准
Token消耗	一次搜索可能消耗数千token处理截图和页面解析	仅传输结构化参数和结果，消耗极低
发展阶段	生产可用，生态成熟	早期实验，仅在Chrome Beta版中可用

核心区别：传统方案提供的是"自动化工具"，而WebMCP提供的是一种更智能的"原生协作协议"。

9.4 演进路径：从机械操作到逻辑直连

AI与网页的交互正在经历一次范式升级：

过去与现在：AI像人一样，通过模拟视觉和点击来操作网页
     ↓      （由Playwright、Puppeteer等工具驱动）
     
现在与未来：MCP协议定义了AI连接外部工具的"USB接口"
     ↓
     
未来趋势：WebMCP将网站的功能接口直接"递"到AI面前
           实现从"机械操作"到"逻辑直连"的跃迁

它们不是取代关系，而是互补和演进的关系。作为开发者，当前阶段深入学习和掌握MCP浏览器服务器是基本功，同时保持对WebMCP的关注，将为你在下一阶段的智能自动化浪潮中占得先机。

9.5 核心API与工作模式

WebMCP通过navigator.modelContext接口提供两套API：

• 声明性API：执行可在HTML表单中直接定义的标准操作
• 命令式API：执行需要JavaScript代码处理的复杂、动态互动

工具注册（业务端）：

// 业务页面：注册一个财务汇总查询工具
navigator.modelContext.registerTool({
  name: 'finance_summary',
  description: '查询本月核心财务指标',
  inputSchema: { /* ... */ },
  execute: async (args) => {
    return { content: [{ type: 'text', text: '收益：¥10,000' }] }
  }
})

工具调用（对话端）：

// 对话组件：发现并调用
const tools = await navigator.modelContextTesting.listTools()
const result = await navigator.modelContextTesting.executeTool('finance_summary', {})

9.6 前端AI三角架构

WebSkill、WebMCP和生成式UI构成了以LLM为中心的浏览器端AI三角架构：

• WebSkill - 定义AI能做什么（能力）
• WebMCP - 定义AI如何调用（接口）
• 生成式UI - 定义AI如何呈现（界面）

9.7 生态与成熟度

WebMCP并非谷歌独角戏——早在2025年8月，谷歌与微软开发者联手在GitHub上提交了WebMCP项目。目前该标准由W3C Web Machine Learning Community Group主导，谷歌和微软工程师共同推进。OpenTiny next-sdk已提供生产级增强方案，解决了原生WebMCP尚处实验性阶段（需开启Chrome标志位）的问题。Cloudflare Browser Run也已支持WebMCP，提供了完整的AI Agent与WebMCP站点交互的端到端方案。

---

十、生成式UI（Generative UI）

10.1 定义与价值

生成式UI是指由AI模型根据自然语言提示词，动态生成结构化用户界面的框架。AI不再只能输出纯文本，而是可以输出可交互的表单、图表、仪表盘。

Vercel CEO Guillermo Rauch评价这种技术为"非常颠覆性的技术"，因为它"将AI直接插入渲染层"。

10.2 主流方案对比

方案	推出方	时间	特点	生态支持
JSON-Render	Vercel	2026.1	开发者定义组件目录+Zod Schema，LLM生成约束内JSON，流式渲染	React/Vue/Svelte/Solid/React Native
A2UI 0.9	Google	2026.4	AI智能体动态构建UI元素，调用现有应用组件资源	React/Flutter/Lit/Angular，Agent SDK
OpenTiny NEXT	华为/OpenTiny	2026.4	生成式UI+MCP深度融合，企业级前端革新方案	智能表单/预测性输入框/数据库适配器

JSON-Render：截至2026年4月已累积超13,000 GitHub星标和200次发布。核心思想是开发者定义组件目录，AI在约束内生成JSON规范，渲染器流式映射为真实组件。这种约束式的设计天然防止了LLM生成恶意React代码。

A2UI 0.9：谷歌2026年4月19日正式推出，提供共享Web核心库、官方React渲染器，并新增Agent SDK支持通过Python安装。支持跨Web、移动端等多平台界面生成。

10.3 与WebMCP的协同

生成式UI与WebMCP的结合构成了AI在浏览器端"意图→执行→呈现"的完整闭环：

1. 意图理解 - LLM理解用户需求
2. 工具调用 - 通过WebMCP执行操作
3. 界面生成 - 生成式UI呈现结果

这种架构使得AI应用在浏览器端可以实现无需后端中转的全闭环体验。

---

十一、Harness Engineering（驾驭工程）

11.1 概念起源

2026年2月5日，HashiCorp联合创始人Mitchell Hashimoto在一篇博客中首次提出"Harness Engineering"。

“模型是马，Harness才是缰绳、马鞍与路。”

六天后，OpenAI发布内部实验报告，标题直接用了这个词。Martin Fowler随后在Twitter上为报告站台。一个月内，Harness Engineering成为开发者社区高频词。

11.2 三层角色演进

阶段	时间	关注点	局限
Prompt Engineering	2023	如何与模型对话	无法注入私有知识、无状态、无工具调用
Context Engineering	2025中	设计动态上下文组装系统	只有信息注入，没有行为约束
Harness Engineering	2026	构建可信执行系统	—

2025年6月，Andrej Karpathy发帖力推Context Engineering，称其为"用恰到好处的信息填充上下文窗口的艺术"。

三者关系：非替代而是分层——Prompt管表达，Context管信息环境，Harness管系统约束。模型是马，Harness才是缰绳、马鞍与路。

11.3 Harness解决的四类Agent问题

问题	表现
Agent漂移	长对话中逐渐偏离初始目标
循环卡死	反复执行相同的失败操作
静默失败	看起来在工作，实际无产出
边界突破	执行了超出授权范围的操作

11.4 Harness四套核心机制

1. 输入约束 - 限制Agent可接收的输入类型和范围
2. 输出验证 - 检查Agent输出是否符合预期
3. 行为边界 - 定义Agent可执行的操作范围
4. 错误恢复 - 异常情况的自动处理机制

11.5 实战数据

案例	改进内容	效果
LangChain团队	仅改进Harness配置，模型不变	Terminal Bench 2.0从52.8%→66.5%，排名前30→前5
安全研究员Can Boluk	仅改变代码编辑格式	Grok Code Fast 1从6.7%→68.3%
OpenAI Codex实验	5名工程师，5个月	交付超100万行生产级代码，零手写
Stripe Minions	全自动PR流程	每周产出超1,000个合并PR，全程无需开发者介入

11.6 三层诊断框架

症状	问题层级	解决方向
输出格式错误	Prompt Engineering	优化指令措辞和输出约束
模型杜撰事实、选错工具	Context Engineering	改善信息供给质量和时机
Agent漂移、循环、静默失败	Harness Engineering	强化行为约束和验证机制

---

十二、Agent完整构成

12.1 定义与核心四件套

Agent是能够自主感知环境、规划任务、调用工具、执行动作的AI系统。

Agent = LLM(大脑) + Memory(记忆) + Planning(规划) + Tool Use(手脚)

12.2 各组件详解

① LLM + 推理模式

• 标准推理 - 直接输出答案
• Chain-of-Thought - 逐步推理
• ReAct - 推理+行动交替

② 记忆系统

类型	实现	工具
短期记忆	上下文窗口存储会话历史	LangGraph持久化状态
长期记忆	向量数据库+RAG	Mem0、Zep、Letta(MemGPT工程延续)

③ 规划能力

将复杂目标拆解为子任务，根据环境反馈动态调整——而非死板执行初始方案。

④ 工具使用

• 内置工具 - 代码执行、文件操作
• 外部API - 搜索、数据库查询
• MCP工具 - 标准化工具协议

12.3 开源生态

框架	开发方	星标	特点
Claude Code	Anthropic	113K	Claude原生Agent CLI
Codex	OpenAI	75K	编码场景深耕
LangChain	社区	133K	最成熟的Agent编排框架
MetaGPT	社区	67K	多Agent协作模拟软件公司
Coze Studio	字节跳动	—	一站式可视化开发平台
Deer Flow	腾讯	61K	国产Agent编排

---

十三、概念关系全景图

用户需求
    ↓
  Prompt（指令入口）
    ↓
  Skill（流程与规范封装）
    ↓
  ┌─────────────┐
  │  内部调用    │
  │ RAG → 知识  │
  │ MCP → 行动  │
  └─────────────┘
    ↓
  LLM（核心推理引擎）
    + Memory + Planning + Tool Use
    = 完整Agent
    ↓
  输出结果
    ↓
  Harness（全流程控制与保障）

关系说明：

• Prompt → 进入LLM的指令形式
• Skill → 包含多个Prompt的流程封装
• RAG → 为LLM注入外部知识
• MCP → 让LLM调用外部工具
• Harness → 约束整个系统的运行边界

新范式全景扩展：

用户需求
    ↓
  Spec（结构化规格）或 Vibe（自然语言描述）
    ↓
  SDD工作流（Specify → Plan → Tasks → Implement）
    ↓
  WebMCP（浏览器端工具调用） + 生成式UI（交互界面渲染）
    ↓
  Harness（全流程约束+验证+错误恢复）
    ↓
  可信任的生产级交付

---

十四、前端面试高频速答（2026版）

问题	答题要点
RAG召回率如何优化？	混合检索(BM25+向量+稀疏向量)+递归分块+ColBERT重排+Query扩展，实战从63%→91%
MCP和WebMCP的关系？	MCP解决AI与后端的连接，WebMCP补齐AI与浏览器前端业务上下文的交互版图
Vibe Coding vs AI Coding？	AI Coding面向专业开发者+逐行审查；Vibe Coding面向非专业+AI主导生成+不看代码
Vibe Coding的风险？	73%受访者遇到过氛围编码问题；AI只能搞定70%，剩下30%需人类专家；代码可能无法运行/修复
Spec-Coding如何提升代码质量？	引入Spec后一次通过率从31%→89%，缺陷密度降76%；四层结构：行为契约+接口定义+数据格式+业务规则
SDD四阶段工作流？	Specify（定义规格）→ Plan（制定计划）→ Tasks（拆解任务）→ Implement（执行实现）
WebMCP的两套API？	声明性API（HTML表单标准操作）；命令式API（JavaScript复杂互动）
Skill和Prompt核心区别？	Prompt是一次性指令，Skill包含流程纪律和验证条件，社区官方仓库116K星标
Harness Engineering解决什么问题？	Agent漂移/循环/静默失败/边界突破；三层诊断：Prompt管格式→Context管知识→Harness管行为约束
国产模型实际能用吗？	能用但有坑：跑分接近但实际稳定性存疑，存在蒸馏争议，建议生产环境实测后再上线
生成式UI主流方案？	Vercel JSON-Render（13K+星标）、Google A2UI 0.9、OpenTiny NEXT