1. 别再被 AI 黑话忽悠了:拆解 Agent/RAG/MCP/Skill 的工程本质
最近刷到各种 AI 黑话是不是有点懵?Skill、MCP、RAG、Agent...这些听起来高大上的术语,本质上都是在解决同一个问题:如何让只会生成文本的大模型,真正具备完成任务的能力。作为一个在 AI 工程化领域摸爬滚打多年的老司机,今天我就带大家把这些概念拆解得明明白白,让你不再被名词牵着鼻子走。
先抛结论:所有这些新名词,本质上都在补大模型的三大短板:
- 缺乏私有知识(不知道你公司的内部信息)
- 缺乏实时性(训练数据是历史快照)
- 缺乏执行能力(不会主动操作系统)
理解了这一点,你就会发现这些"黑科技"其实都是可拆解、可替换的系统组件。下面我们就从工程角度,一层层揭开它们的神秘面纱。
2. 大模型的能力边界与补强方案
2.1 大模型的核心能力与三大短板
大语言模型(LLM)本质上是一个"在给定上下文中预测下一个token"的统计模型。这个能力很强,但也存在三个致命短板:
- 私有知识缺失:模型不知道你公司的代码库、业务规则等非公开信息
- 实时性不足:训练数据截止后发生的事件,模型完全不了解
- 执行能力缺失:模型可以告诉你如何解决问题,但不会实际去执行
2.2 补强方案的工程本质
针对这三个短板,业界发展出了几种主要的补强方案:
| 短板 | 解决方案 | 工程实现 |
|---|---|---|
| 私有知识缺失 | RAG(检索增强生成) | 先检索相关材料,再喂给模型 |
| 实时性不足 | 工具调用 | 让模型先获取最新信息再回答 |
| 执行能力缺失 | Agent/Function Calling | 将"执行"转化为结构化调用 |
3. RAG:检索增强生成的工程实践
3.1 RAG 的本质与价值
RAG(Retrieval-Augmented Generation)不是什么神秘技术,它的核心思想很简单:当模型不知道答案时,先去找相关资料,再把资料和问题一起喂给模型。
这个过程中,真正的工程难点在于:
- 如何保证检索质量(召回率、排序准确性)
- 如何有效组织检索结果(切片、去重、净化)
- 如何构建评估闭环(引用覆盖率、事实一致性)
3.2 RAG 的工程流水线
一个典型的 RAG 流水线包含以下步骤:
- 检索(Retrieve):从知识库中获取相关候选片段
- 重排序(Rerank):对候选片段进行精细排序
- 切片处理(Chunk):将长文档切分为可用片段
- 去重(Dedupe):去除重复或高度相似的片段
- 净化(Sanitize):过滤噪声和潜在有害内容
- 上下文组装:在token预算内拼装最终上下文
- 生成答案:让模型基于材料生成带引用的回答
3.3 Android 开发中的 RAG 实践
以Android开发为例,当新人问"登录态为什么会丢?token是在哪写入/读取的?"时,RAG的典型工作流程是:
- 在代码库中搜索关键词:token、interceptor、auth等
- 只读取与问题直接相关的关键文件片段
- 去除重复片段和无关内容
- 让模型基于这些代码片段生成回答,并要求标注引用位置
最终输出示例:
json复制{
"answer": "登录态丢失通常发生在两类场景:1) token持久化失败或被覆盖 2) 网络层刷新失败但上层未做降级处理...",
"citations": [
{"path": "app/src/main/java/com/example/auth/TokenStore.kt", "lines": "45-78"},
{"path": "app/src/main/java/com/example/network/AuthInterceptor.kt", "lines": "32-65"}
]
}
这种带引用的回答,让结论可以直接追溯到具体代码,极大提高了可信度。
4. Agent:循环控制器的工程实现
4.1 Agent 的本质解析
很多人把Agent想象成有自主意识的"机器人",但在工程视角下,Agent就是一个"带工具的循环控制器",由四个核心部分组成:
- 模型:负责决策和规划
- 工具:提供执行能力
- 循环机制:计划→执行→观察→再计划
- 停止条件:定义任务完成的判断标准
4.2 Agent 的典型工作流程
一个最小化的Agent循环可以表示为:
code复制Goal
-> Plan
-> Act (tool call)
-> Observe (tool result)
-> Update context
-> Check stop condition
-> Repeat if not done
4.3 Android 问题排查案例
假设要解决"Gradle单测在CI失败但本地通过"的问题,Agent的工作流可能是:
- 规划:定位NPE触发路径 → 找出null来源 → 修复并补测试
- 执行:搜索崩溃堆栈中的关键符号
- 观察:发现null来自网络字段缺失
- 更新:记录已确认事实,规划下一步动作
- 停止条件:单测通过 + 关键路径有回归覆盖 + 变更可解释
这个过程中,"能停得住"是关键。必须明确定义停止条件,否则Agent可能会陷入无限循环。
5. Function Calling:结构化调用的工程契约
5.1 工具调用的核心挑战
让模型调用工具的最大难点不是"能不能调用",而是如何确保:
- 调用意图能被准确解析
- 参数符合预期格式
- 输出能被可靠处理
5.2 Schema 的核心作用
通过定义严格的Schema,我们可以建立模型与工具之间的"契约"。例如:
json复制{
"name": "search_code",
"description": "Search code repository",
"parameters": {
"type": "object",
"properties": {
"query": {"type": "string"},
"limit": {"type": "integer", "minimum":1, "maximum":10}
},
"required": ["query"]
}
}
这个Schema明确规定了:
- 工具名称(search_code)
- 参数类型(query必须是字符串,limit必须是1-10的整数)
- 必填字段(query)
5.3 端到端调用流程
一个完整的工具调用流程包括:
- 将工具Schema提供给模型
- 模型生成结构化调用请求
- 程序校验参数是否符合Schema
- 执行实际工具调用
- 将结果返回给模型继续处理
这种结构化交互方式,确保了调用的可靠性和安全性。
6. MCP:工具生态的标准化连接
6.1 MCP 的定位与价值
MCP(Model Context Protocol)解决的是"如何标准化连接各种工具和服务"的问题。它就像是LLM世界的USB接口,让不同工具可以即插即用。
需要注意的是:
- Function Calling 是模型与程序间的契约
- MCP 是程序与外部工具间的连接规范
6.2 典型应用场景
场景一:文档问答
- 通过MCP从飞书获取最新SOP文档
- 使用RAG检索相关段落
- 生成带出处的回答
场景二:设计转代码
- 通过MCP从Figma获取设计稿
- 让模型解释设计元素
- 生成对应的UI骨架代码
6.3 安全注意事项
使用MCP时必须考虑:
- 权限隔离:不同用户/租户的数据访问权限
- 审计追踪:记录所有工具调用
- 沙箱保护:限制工具的执行环境
7. Skill:可复用工作流的工程实践
7.1 Skill 的两种形态
在实践中,Skill通常表现为:
- 提示词模板:高质量prompt+输入槽位+约束
- 轻量工作流:固化"先A后B"的执行步骤
7.2 Skill 的工程化管理
一个规范的Skill应该包含:
- 触发条件(何时使用)
- 输入要求(需要哪些信息)
- 工具依赖(需要哪些工具)
- 输出格式(严格的输出规范)
- 自检清单(质量检查要点)
示例:代码修复Skill
markdown复制# Repo Bugfix Workflow
## 使用时机
- 有明确错误现象/堆栈信息
- 目标是修复并验证
## 输出要求
1) Root Cause分析
2) 具体改动点(文件+行号)
3) 验证方法及结果
4) 风险及回滚方案
## 自检清单
- [ ] 是否提供了可复现的证据?
- [ ] 是否运行了所有相关测试?
- [ ] 改动是否控制在最小范围?
8. 工程选型的三问法则
面对任何新概念,只需回答三个问题:
-
补什么短板?
- 缺知识 → RAG/搜索
- 缺记忆 → 记忆管理
- 缺执行 → 工具调用
-
确定性来源?
- Schema/结构化输出
- Workflow编排
- 评估闭环
-
风险与成本?
- 权限与数据安全
- Token成本与延迟
- 可观测性与回滚
9. 工程实施检查清单
在实际落地前,请确认:
-
问题定位:
- 是知识类问题(RAG优先)?
- 还是执行类问题(需要工具调用)?
-
证据标准:
- 知识类:答案+可追溯引用
- 执行类:补丁+验证结果
-
安全防护:
- 结构化输出约束
- 最小权限原则
- 审计日志完备
-
兜底方案:
- 评估指标(命中率/事实一致性)
- 回滚机制(禁用工具/回滚提交)
10. 趋势判断与建议
未来的发展方向很明确:
- 更多能力会封装成开箱即用的默认配置
- 安全与治理将成为标配功能
- Workflow与Agent会长期共存:
- 核心链路用Workflow保证稳定性
- 探索性任务用Agent提供灵活性
作为工程师,我们要关注的是系统如何补足模型短板,而不是追逐新名词。掌握了Context、Search、Tool、Workflow、Schema这五个核心组件,你就能游刃有余地应对各种"AI黑话"的挑战。