MODEL → TOOLS → CONTEXT → WORKFLOW
Agent 如何
真正完成任务
从模型能力、MCP 工具协议到 Skill 上下文工程
内部技术教学
整理自 3 场视频会议
45–60 MIN
模型推理＋工具能力＋正确上下文＝可执行的 Agent
00 / LEARNING MAP
学完以后，你应该能回答 5 个问题
01 / MENTAL MODEL
先分清：模型能力与 Agent 工程
大模型本身
像“刚毕业的全科研究生”
- 理解与生成文字
- 拆解任务、推理、判断
- 根据上下文预测下一步
＋
Agent 执行环境
给“聪明人”配工作台
- 工具与权限
- 循环、状态与反馈
- 规则、知识与上下文
模型决定上限·工程决定它能否稳定到达上限
02 / AGENT LOOP
Agent 的核心不是“一次回答”，而是 闭环
1理解目标拆任务、补条件
→
2选择工具匹配描述与参数
→
3结构化调用输出 tool call
→
4接收结果观察成功或报错
→
5修正 / 完成继续调用或回答
工具结果重新进入上下文↺模型据此决定下一步
缺少 page 参数
→
模型读懂错误
→
补齐参数后重试
03 / TOOL CALL ANATOMY
模型没有直接“按按钮”——它输出的是 结构化意图
模型看到的工具定义
{
"name": "search_patents",
"description": "按企业与年份检索专利",
"inputSchema": {
"company": "string",
"year": "number?",
"page": "number",
"page_size": "number"
}
}
模型输出
tool_call
宿主执行
工具返回给模型
{
"ok": true,
"total": 284,
"items": [ ... ],
"next_page": 2
}结果再次进入对话上下文
04 / MCP
MCP：让 Agent 与外部能力之间有一座 通用桥梁
AGENT
理解目标
选择能力 不关心每个系统内部怎么实现
选择能力 不关心每个系统内部怎么实现
MCP
统一发现 · 统一描述 · 统一调用
数据库
专利检索
WPS / 文档
浏览器
内部平台
远程 API
“MCP 不是让模型更聪明，而是让它能用一致的方式连接世界。”
05 / TOOL DESIGN
不是“限制模型”，而是 规范输入输出
含糊接口高试错
size到底是页码还是数量？page从 0 还是从 1 开始？name公司全称还是关键词？模型需要猜 → 错误增多 → 上下文膨胀
清晰 Schema低歧义
page_index从 1 开始的页码page_size每页 1–100 条company_name企业工商全称含义自解释 → 一次用对 → 结果可验证
名字可判断描述说清边界必填项明确错误可行动
06 / CASE STUDY
案例：一句“查锐捷网络专利”如何变成 可执行调用
用户“查一下锐捷网络有哪些专利”
↓
company_name锐捷网络
year未指定
page_index1
page_size100
↓
工具返回284 条 · 共 3 页
→
Agent 判断继续翻页 / 汇总 / 询问范围
重点：从自然语言到参数，再从结果决定下一步——每一步都需要可观察、可纠错。
07 / GUARDRAILS
成熟规则不是“想出来的”，是从 输入输出轨迹里长出来的
搜索优先专用工具
减少无关输出，结果更容易定位。
读文件先判断规模
避免一次读爆上下文，必要时分段或摘要。
创建前先检查目标
确认路径与现有内容，降低覆盖和重复风险。
高风险操作加边界
Git、删除、移动等操作需要更清晰的约束。
观察失败→定位原因→补充规则→再次验证
08 / CONTEXT COST
一个“读文件”动作，也可能瞬间 挤爆上下文
FILE
1.8 MB 文本 / 大型 JSON
原样读取：内容巨大、结构噪声多
对话上下文已占用
系统规则工具描述历史对话文件内容
专用读取策略
- 先检查大小与类型
- 按行 / 片段读取
- 对 JSON 提取结构
- 必要时摘要或压缩
上下文有限，真正稀缺的是“与当前决策有关的信息”。
09 / CONTEXT ENGINEERING
从提示词工程到上下文工程：在正确时刻加载正确信息
当前任务我要完成什么？
规则必须遵守什么
工具现在能调用什么
知识这个领域怎么做
证据刚刚查到了什么
不是把所有知识常驻而是干什么活，读什么内容
10 / SKILL
Skill：把“会做这件事”的方法，封装成 可复用模块
专业知识
术语、判断标准、输出质量要求
业务流程
先做什么、何时询问、失败怎么处理
参考与脚本
模板、示例、校验脚本、可复用资产
没有 Skill
每次都重新解释业务，或让 Agent 临时摸索
→
有 Skill
命中任务后加载成熟方法，跨会话保持一致
11 / SKILL ANATOMY
一个 Skill 是一个目录，入口必须是 SKILL.md
patent-novelty-report/
├─SKILL.md入口与路由
├─references/专业规则
│ ├─report-format.md报告格式
│ └─search-strategy.md检索策略
├─scripts/可执行工具
│ └─validate_report.py校验脚本
└─assets/模板与资源
SKILL.md
---
name: patent-novelty-report
description: 为专利查新任务检索、
对比并生成结构化报告
---
# Workflow
1. 确认主题与申请主体
2. 调用检索工具收集证据
3. 按需读取报告规范
4. 生成并校验报告12 / PROGRESSIVE DISCLOSURE
渐进加载：只在需要时，才付出 上下文成本
发现
name + description
→ 命中任务
加载方法
SKILL.md 正文
→ 确有需要
展开资源
references / scripts / assets
只读或执行相关部分全部常驻浪费
渐进加载聚焦
13 / RESOURCE STRATEGY
文档要“读懂”，脚本常常只需 执行并看结果
MD
参考文档
模型需要读取内容，理解规则后再做判断。
- 报告结构
- 领域术语
- 判断标准
消耗上下文：按需读取
RUN
确定性脚本
模型不必阅读实现，只需按约定传参并使用输出。
- 格式校验
- 批量转换
- 稳定计算
消耗上下文：输入与结果
判断：需要“理解”的放文档；可以“确定执行”的放脚本。
14 / MCP × SKILL
MCP 负责“接入”，Skill 负责“教会”
MCP
Skill
核心问题
我能访问什么？
这件事应该怎么做？
主要内容
工具、参数、资源、返回值
知识、流程、模板、判断标准
典型例子
查专利、查数据库、写文档
如何完成专利查新报告
上下文角色
能力说明常驻或可发现
命中任务后渐进加载
MCP 没有 Skill＝有工具，但不会业务方法
Skill 没有 MCP＝懂方法，但拿不到数据
15 / END-TO-END DESIGN
把两者组合：一套 专利查新报告 Agent
用户需求主题 / 公司 / 时间范围 / 输出位置
↓
SKILL · 专利查新流程
澄清条件制定检索式证据去重相似性对比生成报告
↓ ↓ ↓
MCP内部专利库
MCP公开检索 / Web
MCP文档写入
↓
交付物可追溯证据 + 结构化查新报告 + 校验结果
16 / BUILD & DEBUG
落地顺序：先把业务做清楚，再让 Agent 做稳定
收集真实样例，明确合格标准。
接口、认证、字段、分页、错误。
把杂乱 API 变成清晰工具。
沉淀流程、判断与输出模板。
逐次检查调用输入与输出。
只为真实失败补规则并回归。
需求→轨迹→失败模式→最小修正→回归测试↺
17 / PRACTICE
课后练习：用一个真实任务，画出你的 MCP × Skill
30 MIN
选择一个你熟悉的业务任务
例如：专利检索、网络巡检、招标书生成、数据库变更检查。
- 1列出外部能力
哪些数据或动作需要 MCP？
- 2画出任务闭环
调用后会收到什么反馈？如何纠错？
- 3写出 Skill 入口
name、description、核心 4–6 步。
- 4定义一个失败用例
观察轨迹，再补一条最小规则。
交付：一张架构图 + 一个工具 Schema + 一份 SKILL.md 骨架 + 一条测试轨迹
18 / TAKEAWAYS
最后只记住这条链路
MODEL会推理理解目标，决定下一步
→
MCP能行动用标准方式接入外部能力
→
SKILL懂业务按需加载知识与流程
→
TRACE可改进从输入输出中持续优化
好的 Agent 不是“提示词更长”，而是能力清楚、上下文克制、反馈闭环。
Q&A
从你们的业务场景开始聊