当 AI 从"玩具"走向"生产工具"，我们需要什么样的工程化体系？
一、引言：AI 开发的工程化困境
过去两年，AI 编程工具经历了爆发式增长。从 GitHub Copilot 到 Claude Code，从 Cursor 到 JetBrains AIR，每一个新工具都在试图回答同一个问题：如何让 AI 真正融入开发 workflow？
但生产环境的现实是残酷的：
- AI 写的代码"看起来对，跑起来错"
- 长任务执行中模型会"跑偏"
- 工具调用缺乏标准化，每个平台都有自己的协议
- 安全边界模糊，一个配置失误就可能泄露核心代码
这些问题不是模型能力问题，而是工程化问题。
本文将从今天阅读的技术文章出发，解析 AI Agent 工程化的核心技术栈：MCP 协议、Harness 架构、以及新兴的 AI 原生 IDE 范式。
二、MCP：AI 工具调用的标准化之路
2.1 什么是 MCP？
MCP (Model Context Protocol) 是一种标准化的「工具调用协议」，由 Anthropic 提出，正在被越来越多的 AI 工具和平台采纳。
简单来说，MCP 想解决的核心问题是：如何让 AI 安全、标准化地调用外部工具？
在没有 MCP 之前，每个 AI 应用都要为每个工具写特定的适配代码：
- 调用数据库？写一套数据库适配器
- 调用 API？写一套 HTTP 客户端
- 读取文件？写一套文件系统接口
MCP 的出现，让这些工具调用有了统一的标准。
2.2 MCP 的工作原理
┌─────────────┐ SSE长连接 ┌─────────────┐
│ Claude │ ◄─────────────────► │ MCP Server │
│ (Client) │ (实时通信) │ (日志平台) │
└─────────────┘ └─────────────┘
│ │
│ 1. 发送工具调用请求 │
│ ─────────────────────────────────►│
│ │
│ 2. 返回执行结果 │
│ ◄─────────────────────────────────│
核心技术点：
- SSE (Server-Sent Events)：长连接实时通信
- 标准化接口：统一的工具定义和调用方式
- 鉴权机制：accessToken 管理，支持自动刷新
2.3 得物技术的实践案例
得物技术团队基于 MCP + Claude Code Skill 开发了日志诊断工具，核心流程：
用户输入 traceId
↓
Claude 加载 Skill 配置
↓
检查 accessToken → 过期自动刷新
↓
调用日志平台 MCP 分页拉取（最多20页）
↓
切换到代码分支，结合日志检索代码
↓
综合分析 → 生成诊断报告
关键设计：
- Token 自动管理：1小时有效期，过期自动刷新
- 分页全量拉取：禁止只查第一页就下结论
- 跨服务分析：自动识别上下游服务日志
- 代码联动：日志中的类名/方法名精确定位代码
2.4 MCP 的生态意义
MCP 的价值不仅在于技术层面，更在于生态层面：
| 维度 | 传统方式 | MCP 方式 |
|---|---|---|
| 工具集成 | 每个工具单独适配 | 一次适配，处处可用 |
| 开发成本 | 高（N个工具×M个平台） | 低（标准化接口） |
| 可移植性 | 差 | 好 |
| 安全性 | 参差不齐 | 统一鉴权机制 |
趋势判断： MCP 正在成为 AI 工具集成的"USB 接口"，未来会有越来越多的工具支持 MCP。
三、Harness：AI Agent 的系统化架构
3.1 什么是 Harness？
Harness 是 AI Agent 的"操作系统"或者说调度框架——核心作用是把大模型、各类工具、记忆模块、权限管理、任务流程整合在一起，让 AI 不再只是能聊天的工具，而是能真正自主完成任务的"助手"。
但 Harness 之所以容易越讲越糊，不是因为它空，而是因为它本来就是一个上位系统问题。
3.2 Harness 的三层架构
基于 OpenAI 和 Anthropic 的技术文章，我们可以把 Harness 拆成三层：
┌─────────────────────────────────────────┐
│ 第一层：知识层 (Knowledge Layer) │
│ - 仓库作为唯一知识源 │
│ - AGENTS.md 当地图而非百科 │
│ - 架构边界靠 linter 机械执行 │
├─────────────────────────────────────────┤
│ 第二层：约束与流程层 │
│ (Constraint & Flow Layer) │
│ - Planner / Generator / Evaluator 分离 │
│ - 职责分离，避免单点失效 │
├─────────────────────────────────────────┤
│ 第三层：反馈与运行时层 │
│ (Feedback & Runtime Layer) │
│ - context reset 对抗长任务失真 │
│ - 外部评估替代自评 │
│ - 权限、回放、运行时控制 │
└─────────────────────────────────────────┘
3.3 震撼的数据对比
Anthropic 在实验中给出了一个令人震惊的对比：
| 方案 | 时间 | 成本 | 结果 |
|---|---|---|---|
| 单 Agent | 20分钟 | $9 | 界面有了，功能不能用 |
| 完整 Harness | 6小时 | $200 | 真正可用的应用 |
核心洞察： 差距不在模型，在系统。
同样的模型、同样的 Prompt，不同的 Harness，结果天差地别。
3.4 各层详解
第一层：知识层
OpenAI 在《工程技术：在智能体优先的世界中利用 Codex》中强调：
- 仓库作为唯一知识源：不要把知识分散在文档、Wiki、脑子里
- AGENTS.md 当地图：告诉 AI 代码库的结构，而不是详细的 API 文档
- 架构边界靠 linter：机械执行，而不是靠人记忆
第二层：约束与流程层
Anthropic 在《Harness design for long-running application development》中提出：
- Planner：负责制定计划
- Generator：负责生成代码
- Evaluator：负责评估结果
三者分离，避免单点失效。
第三层：反馈与运行时层
长任务的最大问题是"跑偏"：
- context reset：定期重置上下文，对抗长任务失真
- 外部评估：用外部工具验证，而不是模型自评
- 权限控制：明确 AI 能做什么、不能做什么
3.5 Harness 的工程化启示
- 系统 > 模型：不要迷信更大的模型，好的 Harness 比模型更重要
- 分层设计：知识层、约束层、反馈层，每层都有明确的职责
- 可观测性：任务执行过程要可追踪、可回放、可调试
- 渐进式交付：不是一次性完成，而是迭代式逼近目标
四、AI 原生 IDE：开发工具的范式转移
4.1 从"AI 辅助"到"AI 原生"
JetBrains 最新发布的 AIR（AI IDE）代表了一种新的范式：
"不是把 AI 塞进 IDE，而是用 AI 重构 IDE 本身"
传统 IDE + AI：
- AI 是插件，是可选功能
- 人主导，AI 辅助
- 代码是核心，AI 是增强
AI 原生 IDE：
- AI 是底层架构
- 人机协作，AI 是平等参与者
- 任务定义和审查是核心，代码生成是过程
4.2 AIR 的核心设计
核心理念：
- AI 即默认工作流：AI 不是可选增强，而是默认模式
- 确定性与可解释性：避免"黑箱魔法"
- 开发者主导权：开发者始终掌握代码控制权
核心流程：
定义任务（结合上下文与逐步引导）
↓
配置执行环境与权限（平衡效率与安全）
↓
审查并提交变更（确保代码质量可控）
权限模式设计：
| 模式 | 适用场景 |
|---|---|
| 询问权限 | 敏感操作，需要确认 |
| 自动编辑 | 常规重构，提高效率 |
| 规划模式 | 复杂任务，先规划再执行 |
| 完全访问 | 可信环境，完全自动化 |
4.3 AI 原生开发的关键特征
- 任务驱动：不再是"写代码"，而是"定义任务"
- 上下文优先：AI 需要充分的上下文才能做好工作
- 审查即开发：Code Review 成为开发的核心环节
- 多任务并行：一个任务写测试，另一个修 Bug
- 工具生态：通过 MCP 连接各种外部工具
五、技术栈整合：未来的 AI 开发环境
把 MCP、Harness、AI 原生 IDE 放在一起看，我们可以勾勒出未来的 AI 开发环境：
┌─────────────────────────────────────────┐
│ AI 原生 IDE (AIR) │
│ - 任务定义与审查界面 │
│ - 多任务并行管理 │
│ - 可视化 Harness 编排 │
├─────────────────────────────────────────┤
│ Harness 层 │
│ - 知识层：仓库、文档、上下文 │
│ - 约束层：Planner/Generator/Evaluator │
│ - 反馈层：运行时监控、评估、重置 │
├─────────────────────────────────────────┤
│ MCP 层 │
│ - 标准化工具调用协议 │
│ - 数据库、API、文件系统、日志平台... │
├─────────────────────────────────────────┤
│ 底层模型 │
│ - Claude、GPT、Gemini... │
└─────────────────────────────────────────┘
六、给开发者的建议
6.1 短期（现在就能做）
- 学习 MCP：关注 MCP 协议的发展，评估是否可以在项目中应用
- 实践 Harness 思维：即使不用复杂的 Harness 框架，也要有分层设计的意识
- 尝试 AI 原生 IDE：体验 AIR、Cursor 等工具，理解新的开发范式
6.2 中期（未来6个月）
- 构建自己的工具链：基于 MCP 连接常用的开发工具
- 设计项目的 Harness：为团队设计适合的知识层、约束层、反馈层
- 建立评估体系：不要只看 AI 生成了多少代码，要看生成了多少可用的代码
6.3 长期（未来1-2年）
- 参与生态建设：为开源的 MCP Server、Harness 框架贡献代码
- 沉淀最佳实践：把团队的 AI 开发经验整理成可复用的模式
- 关注安全与伦理：AI 开发不仅是技术问题，更是责任问题
七、结语
AI 开发工具正在经历从"玩具"到"工具"再到"基础设施"的演进。
MCP 解决了工具集成的标准化问题，Harness 解决了系统架构的工程化问题，AI 原生 IDE 解决了人机协作的交互问题。
这三者合在一起，构成了 AI Agent 工程化的核心技术栈。
智能是上限，工程化是下限。 只有当工程化基础打牢了，AI 的真正潜力才能被释放出来。
这个时代，才刚刚开始。
参考来源：
- 日志诊断 Skill：用 AI + MCP 一键解决BUG｜得物技术
- 大家都在讲 Harness，但它到底该怎么理解
- 重磅！JetBrains 正式发布全新的 AI 开发工具，定名 AI IDE AIR
- OpenAI《工程技术：在智能体优先的世界中利用 Codex》
- Anthropic《Harness design for long-running application development》
