这讲拆解的是 Cursor、Claude Code、Windsurf 这些热门编程智能体背后的核心原理。
从零构建编程智能体
架构其实很简洁：
用户 → 客户端界面 (CLI/IDE) → 编排器 (Orchestrator) ⟷ LLM (Claude)
↓
本地工具 (文件操作等)编排器是核心循环——不断从用户获取输入，与 LLM 通信，在本地执行工具调用。
几个关键术语：
| 术语 | 说明 |
|---|---|
| System Prompt | 定义智能体核心行为和指令的系统提示词 |
| User Prompt | 用户发出的具体指令 |
| Assistant Prompt | LLM 返回的中间推理或工具调用请求 |
构建步骤：
- 读取终端输入，不断追加到对话上下文
- 告知 LLM 可用工具：
Read_file,List_dir,Edit_file等 - LLM 在合适时机主动请求调用工具
- 编排器在本地执行这些工具
- 把执行结果返回给 LLM 继续推理
"秘密武器"
slides 揭示了 Claude Code 等先进智能体的工程优化技巧：
| 技巧 | 说明 |
|---|---|
| 前置上下文 | 使用小巧且针对性强的提示词开头 |
| 系统提醒 | 在各处插入 <system-reminder> 标签，防止模型在长对话中"漂移" |
| 命令前缀提取 | 解析特定的操作指令 |
| 派生子代理 | 通过子代理处理特定任务，防止主代理的上下文窗口超载 |
MCP：解决集成噩梦
为什么需要 MCP？
问题是这样的：
- LLM 有海量但静态的知识
- 构建自主系统需要动态数据（天气、比特币价格、最新新闻）
- 当前最佳方案是 RAG 和 Tool-calling
但第三方 API 集成很痛苦。slides 展示了一个糟糕的 Twitter API 代码示例——参数模糊、文档不完整、错误响应含糊。每接入一个新 API 都需要大量适配工作。
更可怕的是 N × M 噩梦：多个 LLM 应用和多种外部 API（Twitter, Slack, Facebook...）之间的混乱连接。
MCP 的解决方案
把 M × N 简化为 M + N。
优势：统一接口（不用为每个集成重新实现身份验证、错误处理或限流）、JSON-RPC 强制统一输出格式。灵感来自 LSP（语言服务器协议），但支持更主动的代理式工作流。
架构
┌─────────────────────────────────────────────────────┐
│ Host (宿主) - Cursor, Claude Desktop │
│ │ │
│ └── MCP Client (客户端) │
│ ├── 维护状态会话 │
│ └── 列表工具 → 注入模型上下文 │
│ │ │
│ ▼ │
│ MCP Server (服务器) │
│ └── 轻量级工具包装器 │
│ │ │
│ ▼ │
│ Tool (工具) │
│ └── 具体调用函数 │
└─────────────────────────────────────────────────────┘交互流程：
- 用户提问（比如"总结 Jack 发给我的邮件"）
- Client 从 Server 获取工具能力列表
- 问题 + 工具定义发送给 LLM
- LLM 发出工具调用；Server 执行（访问 Gmail 等）
- 结果返回用户
传输协议支持 stdio 和 SSE（Server-Sent Events）。
当前局限
| 问题 | 说明 |
|---|---|
| 工具过载 | 智能体处理过多工具时效率不高 |
| 上下文消耗 | API 调用会迅速消耗模型的上下文窗口 |
| 建议 | 设计"AI 原生"的 API，而不是死板的传统 API |
课程推荐论文: Mitigations
小结
这两份 slides 串起来就是一个完整的技术栈：
- 第一部分教你怎么从零构建一个基础的编程智能体
- 第二部分教你怎么用 MCP 协议赋予智能体标准化、可扩展的能力
这就是 Cursor、Claude Code、Windsurf 的核心技术架构。