阿里云大模型ACP认证 · C3 构建Agent系统 知识点总结
课程地址：ACP认证教程C3_构建Agent系统
最近笔者也是以94分通过了阿里云大模型ACP认证，分享一下备考时自己做的一些笔记
目录
- Agent概述与课程体系
- Agent基础与工具调用
- Agent规划与执行
- 多Agent团队协作
- Agent记忆系统
- Skill技能封装
- Agent评测驱动开发
- Qwen Code实践
- Harness Engineering与Loop Engineering
- 考试重点与权重分布
1. Agent概述与课程体系
1.1 从LLM到Agent的跃迁
LLM的四大天花板：
| 局限 | 说明 |
|---|---|
| 只会说不会做 | 能告诉你"可以去天气App查"，但自己不会查 |
| 没有记忆 | 上下文窗口一满就"失忆"，跨会话什么都没留下 |
| 知识截止 | 训练数据有截止日期，实时信息不知道 |
| 不会规划 | 让做"竞品分析"，只会线性回答，不会自己拆解步骤 |
Agent的定义： Agent = LLM + 工具 + 记忆 + 规划，在循环中自主完成目标。
LLM vs Agent 的本质区别：
- LLM：告诉你怎么做（建议）
- Agent：直接帮你做完（执行）
1.2 Agent的完整四模块
| 模块 | 角色 | 职责 |
|---|---|---|
| LLM（大脑） | 理解意图、推理判断 | 核心决策引擎 |
| 规划模块 | 任务拆解、步骤排序 | 把大目标拆成小步骤 |
| 记忆模块 | 短期上下文 + 长期知识存储 | 跨会话记忆 |
| 工具模块 | 调用外部API、数据库、代码执行器 | Agent的"手和脚" |
1.3 Agent vs Workflow
| 维度 | Workflow | Agent |
|---|---|---|
| 控制者 | 代码/开发者 | LLM |
| Token消耗 | 低（约1x） | 高（约4-8x） |
| 可预测性 | 高 | 低 |
| 灵活性 | 低 | 高 |
| 适合任务 | 固定流程 | 开放式目标 |
| 调试难度 | 容易 | 困难 |
生产最佳实践： 大多数系统采用 Workflow + Agent 混合架构——Workflow提供稳定骨架，Agent负责处理异常和复杂情况。
1.4 课程结构
| 课时 | 标题 | 核心知识点 |
|---|---|---|
| 3.1 | Agent基础与工具调用 | Function Calling、ReAct、MCP |
| 3.2 | 让Agent学会规划与执行 | 反思(Reflection)、工作流、自主规划 |
| 3.3 | 用多Agent实现团队协作 | 分层规划(Leader-Worker)、共创协作(Blackboard) |
| 3.4 | 用Memory让Agent积累经验 | 短期/长期记忆、主动记忆管理 |
| 3.5 | 用Skill将能力固化为可复用流程 | 渐进性披露、Skill结构 |
| 3.6 | 用评测驱动Agent开发 | 端到端评测、白盒化评测 |
| 3.7 | Qwen Code实践 | Coding Agent工作方式 |
| 3.8 | Harness & Loop Engineering | 标准、验证、记录、写回闭环 |
2. Agent基础与工具调用
2.1 Function Calling（函数调用）
核心思想： 让LLM输出结构化JSON指令（而非自然语言），指定要调用的函数名和参数。
四步流程：
Step 1: 定义工具 → 用JSON Schema描述工具名称、参数
Step 2: LLM判断 → 判断是否需要调用工具，输出tool_calls
Step 3: 执行工具 → 应用解析tool_calls，执行真实函数
Step 4: 反馈生成 → 将工具结果传回LLM，生成最终回答
工具定义示例（OpenAI兼容格式）：
{
"type": "function",
"function": {
"name": "get_current_weather",
"description": "查询指定城市的当前天气",
"parameters": {
"type": "object",
"properties": {
"location": {"type": "string", "description": "城市名"}
},
"required": ["location"]
}
}
}
支持Function Calling的模型： OpenAI GPT系列、Claude 3、阿里Qwen-Max/Plus、GLM-4、DeepSeek-V2
优势与局限：
| 优势 | 局限 |
|---|---|
| 高精度，结构化输出避免解析歧义 | 依赖模型原生支持 |
| 低延迟，单次调用即可完成决策 | 灵活性有限，难以处理多跳任务 |
| 工程友好，易于集成 | 不支持复杂规划，无法自动拆解子任务 |
| 安全性高，参数强类型校验 | 调试困难，黑盒决策 |
2.2 ReAct架构（推理+行动）
核心思想： 模拟人类"思考→行动→观察→反思"的认知循环。
标准格式：
Thought: 我需要先搜索"通义千问最新版本"来获取信息。
Action: search("通义千问最新版本")
Observation: Qwen3-Max-Preview 于2025年9月发布...
Thought: 现在我知道最新版本是Qwen3-Max-Preview。
Action: Finish("通义千问最新版本是Qwen3-Max-Preview...")
ReAct与Function Calling的对比：
| 对比维度 | Function Calling | ReAct |
|---|---|---|
| 输出格式 | 结构化JSON | 自然语言+格式化文本 |
| 推理过程 | 隐含在模型内部 | 显式输出Thought |
| 可调试性 | 黑盒 | 高度透明，可追踪 |
| 适用场景 | 单步、明确的任务 | 多步推理、复杂场景 |
| 实现复杂度 | 低（原生支持） | 高（需框架支持） |
2.3 MCP协议（Model Context Protocol）
MCP的定义： 一个开放标准协议，规定AI应用和外部工具、资源之间如何通信。
三层关系：
| 层级 | 作用 | 类比 |
|---|---|---|
| Function Calling | 模型"怎么描述我要调用哪个函数" | 说出意图 |
| MCP | 工具"怎么标准化暴露给AI应用" | 统一接口 |
| Agent | 系统"怎么围绕目标自主选择、调用、检查这些工具" | 自主执行 |
MCP的核心价值：
- 标准化工具调用接口
- 工具可被不同AI客户端发现和复用
- 内置安全机制（权限控制、审计）
3. Agent规划与执行
3.1 反思模式（Reflection）
核心思想： 让模型自己检查自己的工作，循环改进。
生成初稿 → 送审 → 发现问题 → 修正 → 再送审 → 输出
为什么有效： LLM在"审视已有输出"时，比"直接生成正确输出"表现更好。因为审查时认知负荷大幅降低。
三种实现方式：
- 同一模型反思：用一个system prompt生成，另一个system prompt审查
- 不同模型审查：生成用GPT-4，审查用Claude（不同模型发现不同问题）
- 多层反思：表层（格式语法）→ 逻辑层（推理过程）→ 结果层（目标达成度）
3.2 三种规划范式
| 范式 | 说明 | 适用场景 |
|---|---|---|
| Plan-and-Execute | 一次性制定完整计划，然后逐步执行 | 任务明确、步骤可预测 |
| ReAct | 边思考边行动，每步交替推理和行动 | 需要动态调整的复杂任务 |
| 自主规划（Self-Plan） | Agent自主规划执行路径，不预设流程 | 开放式、不确定任务 |
CoT（思维链）：让LLM把中间推理步骤显式写出来，是赋予规划能力的基础方法。
3.3 Andrew Ng的四种Agent设计模式
| 模式 | 说明 |
|---|---|
| Reflection（反思） | 让模型自我审视和改进输出 |
| Tool Use（工具调用） | 让模型学会使用外部工具 |
| Planning（规划） | 让模型先制定计划再执行 |
| Multi-Agent（多智能体协作） | 让多个AI角色协作 |
4. 多Agent团队协作
4.1 两种主流协作模式
模式一：分层规划（Leader-Worker）
项目经理(Leader) → 分配任务 → Worker1 (写代码)
分配任务 → Worker2 (写测试)
分配任务 → Worker3 (写文档)
汇总结果 → 最终输出
- 实现方式：handoff（任务交接）
- 适用场景：任务可明确拆分为独立子任务
- 类比：项目经理带团队
模式二：共创协作（Blackboard）
┌── Worker1 (写作) ──┐
│ │
用户需求 → 共享白板 ── Worker2 (设计) ──→ 集成输出
│ │
└── Worker3 (审查) ──┘
- 实现方式：MsgHub（消息总线）
- 适用场景：需要多方协作、迭代优化的任务
- 类比：头脑风暴团队围绕白板协作
4.2 多Agent的成本意识
- Token消耗是单Agent的3-5倍
- 根据任务复杂度选择合适模式
- 简单任务不要使用多Agent架构
4.3 从人类团队协作中提炼Agent架构
| 人类团队角色 | Agent对应角色 | 职责 |
|---|---|---|
| 项目经理 | Leader Agent | 任务分解、分配、汇总 |
| 开发工程师 | Worker Agent | 执行具体任务 |
| 测试工程师 | Reviewer Agent | 检查输出质量 |
| 产品经理 | Orchestrator | 理解需求、制定目标 |
5. Agent记忆系统
5.1 记忆的层次
短期记忆（对话上下文）
↓ 上下文过长时
滚动摘要（压缩历史）
↓ 跨会话时
长期记忆（向量化存储）
5.2 三种记忆管理策略
| 策略 | 说明 | 优点 | 缺点 |
|---|---|---|---|
| 上下文截断 | 超过窗口长度时丢弃最早消息 | 简单直接 | 丢失早期重要信息 |
| 滚动摘要 | 定期对历史对话进行摘要压缩 | 保留核心信息 | 摘要可能遗漏细节 |
| 向量化召回 | 将历史信息向量化存储，按需检索 | 精准召回 | 实现复杂，需向量数据库 |
5.3 主动记忆管理
从被动到主动：Agent自主决定何时记、何时读。
- 写记忆：Agent判断当前信息是否重要，主动写入记忆库
- 读记忆：Agent判断当前任务需要哪些历史信息，主动检索
5.4 混合记忆系统架构
用户输入
│
▼
┌─────────────────────┐
│ 短期记忆（上下文） │ ← 当前对话窗口
│ Token限制管理 │
└─────────┬───────────┘
│ 超出窗口 → 摘要压缩
▼
┌─────────────────────┐
│ 中期记忆（滚动摘要） │ ← 压缩后的对话历史
└─────────┬───────────┘
│ 跨会话 → 向量化存储
▼
┌─────────────────────┐
│ 长期记忆（向量数据库）│ ← 持久化知识
│ 按需检索 │
└─────────────────────┘
6. Skill技能封装
6.1 为什么需要Skill
传统Prompt的三大痛点：
| 痛点 | 说明 |
|---|---|
| 上下文膨胀 | 项目越复杂，Prompt越长，关键信息被稀释 |
| 耦合严重 | 领域知识与具体项目深度绑定，难以复用 |
| 复用性低 | 相同逻辑在不同项目中反复描述 |
Skill的核心理念：渐进性披露（Progressive Disclosure）
- 不再一次性灌入所有知识
- 只有Agent真正需要时，才加载对应Skill
- 用最小上下文成本换取最大知识覆盖
6.2 Skill vs Tool vs Prompt
| 概念 | 本质 | 类比 |
|---|---|---|
| Prompt | 一次性提示词/指令 | 口头交代任务 |
| Tool | 原子能力（函数接口） | 锤子、锯子 |
| Skill | 可复用能力包（SOP+知识+工具） | 木工完全指南 |
| Agent | 规划执行的主体 | 工匠 |
6.3 Skill的标准结构
skill_name/
├── SKILL.md # 唯一入口：名称、描述、触发条件
├── scripts/ # 可执行脚本
├── references/ # 参考文档
└── assets/ # 资源文件
SKILL.md的核心内容：
# Skill: [技能名称]
## Description
[简述：这个技能是干嘛的？什么时候用？]
## Steps (SOP)
1. [步骤1]
2. [步骤2]
- 注意：[关键细节]
3. [步骤3]
## Constraints
- [红线1]
- [红线2]
## Examples (Few-shot)
User: [用户指令]
Assistant: [AI应该怎么做]
6.4 Skill vs Workflow
| 对比维度 | Skill | Workflow |
|---|---|---|
| 能力粒度 | 功能级原子能力 | 业务级流程组合 |
| 调用方式 | 被Agent、其他Skill调用 | 独立执行、定时触发 |
| 执行灵活性 | 支持内部条件分支 | 执行路径相对固定 |
6.5 Skill工程化最佳实践
- 工具隔离与权限最小化：每个Skill只访问所需资源
- 脚本化确定性计算：突破LLM能力边界，将确定性步骤用脚本实现
- 参数传递的快照机制：记录Skill执行时的上下文快照
- 测试维度：功能测试、边界测试、异常测试
7. Agent评测驱动开发
7.1 为什么Agent评测不能只看最终答案
Agent出问题往往不在最终答案，而在：
- 工具路径走错了
- Token超支了
- 某个中间步骤格式不对导致后续全崩
核心原则： 过程同样重要，不能只看结果。
7.2 端到端评测（Task + Metric框架）
# 定义评测任务和指标
task = AgentTask("编写课程文档")
metrics = [
TaskCompletionMetric(), # 任务完成率
ToolCallAccuracyMetric(), # 工具调用准确率
TokenEfficiencyMetric(), # Token效率
ResponseLatencyMetric(), # 响应延迟
]
7.3 白盒化评测（检查工具调用序列）
核心思想： 将Agent的内部过程暴露出来，逐项检查。
理想工具路径:
[search] → [read_file] → [write_draft] → [review] → [finish]
实际工具路径:
[search] → [search] → [read_file] → [write_draft] → [search] → [finish]
问题诊断:
- 两次search → 检索效率低，可能需要优化检索策略
- 缺少review步骤 → 输出质量可能不达标
检查维度：
- 工具调用顺序是否正确
- 是否有不必要的重复调用
- 是否遗漏了关键步骤
- 工具参数是否正确
7.4 评测-诊断-优化闭环
评测 → 发现问题 → 诊断根因 → 优化 → 再评测
常见问题诊断：
| 现象 | 可能原因 | 优化方向 |
|---|---|---|
| 工具路径错误 | 提示词不清晰 | 优化System Prompt |
| 反复调用同一工具 | 检索结果不准确 | 优化检索策略 |
| 跳过关键步骤 | 规划能力不足 | 使用Plan-and-Execute |
| 输出格式错误 | 缺少格式约束 | 添加输出格式规范 |
8. Qwen Code实践
8.1 Qwen Code概述
Qwen Code是通义千问团队开源的终端AI智能体（Coding Agent），将工具调用、规划、记忆、外部工具连接和Skill整合到一个成熟工具中。
核心工作流：
先理解 → 再计划 → 再编码 → 再提交
8.2 Qwen Code的核心能力
| 能力 | 说明 |
|---|---|
| 代码理解 | 分析项目结构、代码逻辑 |
| 自主规划 | 拆解任务、制定执行计划 |
| 工具编排 | 文件读写、命令执行、代码搜索 |
| 上下文管理 | 压缩或清理会话，控制窗口大小 |
| Skill扩展 | 加载自定义技能包 |
| 外部工具连接 | 集成MCP Server等外部工具 |
8.3 配置管理
项目配置文件（AGENTS.md / CLAUDE.md）：
- 面向Agent的配置文档
- 包含技术选型、编码规范、项目结构
- 每次会话自动加载，Agent直接进入高效协作模式
8.4 能力边界与反模式
Coding Agent的边界：
- 不能完全替代人工审查
- 复杂架构决策仍需人类判断
- 长项目需注意上下文管理
常见反模式：
- 一次性要求完成过多任务
- 不提供项目背景直接要求编码
- 忽略上下文窗口限制
9. Harness Engineering与Loop Engineering
9.1 AI工程化的四次跃迁
| 阶段 | 时期 | 核心关注 | 类比 |
|---|---|---|---|
| Prompt Engineering | 2022-2023 | 怎么问 | 对马喊话 |
| Context Engineering | 2024-2025 | 喂什么 | 给马地图 |
| Harness Engineering | 2025-2026 | 如何确保单次可靠 | 给马套缰绳 |
| Loop Engineering | 2026- | 如何持续循环 | 修赛道 |
9.2 Harness Engineering（驾驭工程）
定义： 围绕LLM构建一套完整的工程系统，让模型的能力可以被稳定、重复地驾驭。
核心公式： Agent = Model + Harness
LLM的四大结构性缺陷及Harness的解法：
| 缺陷 | Harness解法 |
|---|---|
| 无状态 | 记忆系统（上下文管理、向量存储） |
| 无法操作外部世界 | 工具调用（Function Calling、MCP） |
| 输出概率性 | 规则约束、验证器、Gate门禁 |
| 上下文限制 | 上下文管理、滚动摘要、分层加载 |
Harness的四大支柱：
| 支柱 | 说明 | 实现 |
|---|---|---|
| 上下文工程 | 结构化、精准投喂信息 | AGENTS.md、Skill |
| 架构约束 | 硬性规则，不靠AI自觉 | Linter、CI检查、Gate |
| 反馈循环 | AI审AI | Generator + Checker模式 |
| 循环层 | 解决复杂任务分解 | 多步循环、重试机制 |
9.3 Loop Engineering（循环工程）
定义： 让Agent根据验证反馈，自己判断下一轮该改什么（作品、Skill、验证器还是标准），形成持续改进的闭环。
Harness vs Loop：
| 对比 | Harness Engineering | Loop Engineering |
|---|---|---|
| 关注点 | 单次跑稳 | 持续循环改进 |
| 类比 | 缰绳、马鞍、刹车 | 环形赛道 |
| 核心问题 | 怎么保证安全可靠 | 怎么持续自主工作 |
| 输出 | 标准、工具、验证、记录 | 反馈、改进、迭代 |
Loop Engineering的完整闭环：
标准定义 → 工具执行 → 截图验证 → 运行记录
↑ │
└──────── 反馈改进 ──────────┘
│
├── 改作品（内容问题）
├── 改Skill（流程问题）
├── 改验证器（检查标准问题）
└── 改标准（目标问题）
9.4 实践要点
Harness搭建步骤：
- 定义标准（什么是"做好"）
- 配置工具（Agent需要哪些能力）
- 建立验证（如何检查输出）
- 设置边界（什么不能做）
- 记录审计（追踪执行过程）
- 设计Reviewer角色（AI审AI）
- 配置停止条件（何时结束）
Loop搭建要点：
- 先搭Harness，再建Loop（底盘不稳，跑得越快翻得越惨）
- 反馈机制要明确（什么情况该改什么）
- 停止条件要清晰（避免无限循环）
10. 考试重点与权重分布
10.1 C3章节考点权重
| 知识点 | 权重 | 核心考点 |
|---|---|---|
| Agent智能体 + Function Calling | 16% | 四步流程、ReAct架构、安全边界 |
| 工具调用策略 | 高频 | Function Calling vs ReAct对比、适用场景 |
| 多Agent架构 | 中频 | 分层规划、共创协作、handoff机制 |
| 记忆系统 | 中频 | 短期/长期记忆、滚动摘要、向量化召回 |
| Skill体系 | 中频 | 渐进性披露、Skill结构、Skill vs Tool |
| Harness Engineering | 新增考点 | 四大支柱、LLM四大缺陷、Gate/Validator |
| Loop Engineering | 新增考点 | 闭环改进、反馈机制 |
| Qwen Code | 新增考点 | Coding Agent工作流、配置管理 |
10.2 核心考点速记
Function Calling四步流程：
定义工具 → LLM判断 → 执行工具 → 反馈生成
ReAct标准格式：
Thought → Action → Observation → Thought → ... → Finish
Agent四模块：
LLM（大脑）+ 规划 + 记忆 + 工具
Harness四大支柱：
上下文工程 + 架构约束 + 反馈循环 + 循环层
Skill核心设计理念：
渐进性披露（Progressive Disclosure）—— 按需加载，最小上下文成本
Coding Agent工作流：
先理解 → 再计划 → 再编码 → 再提交
10.3 高频考点真题
Q: Function Calling的核心流程是什么？
A. LLM直接生成最终答案
B. LLM判断需要调用工具，输出结构化指令，执行后返回结果 ✅
C. 用户手动选择工具
D. 随机选择工具执行
Q: ReAct架构中，Thought的作用是什么？
A. 直接输出最终答案
B. 模型的内部推理过程，决定下一步行动 ✅
C. 执行工具调用
D. 格式化输出结果
Q: Skill与Tool的核心区别是什么？
A. Skill是原子能力，Tool是流程组合
B. Tool是原子能力，Skill是流程+知识+SOP ✅
C. 两者没有区别
D. Skill只能用于RAG场景
考试技巧： Function Calling和ReAct的对比是必考题，务必理解各自适用场景。多Agent的两种协作模式（分层规划 vs 共创协作）需要掌握。Harness和Loop是2026年新增考点，注意理解两者的关系（先有Harness再有Loop）。
扫一扫
2109
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
