本次我们来看一个容易被很多人当“概念课”略过的系列内容吴恩达在 DeepLearning.AI 上推出的Agent Skills专题教程。先给结论它不教你背 Agent 的定义而是把 Agent 开发中反复出现的通用能力拆成一个个“可复用技能”比如规划、记忆、工具调用、多 Agent 协作、结果评估。你在实际项目中遇到的绝大多数 Agent 工程问题几乎都能在这些技能里找到对应解法。这系列内容的核心特点我梳理如下不讲空概念直接给能力模块把每个技能按“输入、处理、输出”讲清楚适合直接落地到代码里。学习路径完整从单技能到多技能组合再到多 Agent 协作门槛从低到高。工程导向强自带评测维度训练开发者学会判断 Agent 到底好不好用而不是凭感觉调 Prompt。适合多种 AGI/LLM 技术栈不绑定某个固定数据库或向量库核心思想可以迁移到 LangChain、LlamaIndex、自研框架甚至国内模型平台的 Agent 应用里。这篇文章会帮你把这条学习路线完整拆开先讲基础能力再讲模式组合最后落到接口 API、批量任务、成本观察和排查方法上。无论你是刚接触 Agent 的开发者还是已经在做 Agent 落地的工程师都能在阅读后建立一套清晰的执行框架。1. 核心能力速览能力项说明项目/内容类型AI Agent 开发方法论与实操系列来自 DeepLearning.AI 吴恩达课程体系主要讲解对象Agent SkillsAgent 技能包括规划、记忆、工具使用、多 Agent 协作、反思、评估等最核心解决的问题如何把大模型从“单轮问答”升级为“能执行复杂任务的多步骤智能体”学习方式视频讲解 代码示例 课后练习典型 Jupyter Notebook 风格需要掌握的前置知识Python 基础、Prompt 基础、大模型 API 调用经验是否涉及大模型训练不涉及是否涉及本地部署显存不涉及本地 GPU 训练属于 API 调用层方法是否可以直接复用到工程可以技能思想与代码模式可直接迁移到业务 Agent 项目是否有 API 相关示例有覆盖 OpenAI、Anthropic 等主流模型 API 的调用与组合是否支持批量任务核心思想支持批量任务设计教程中会涉及批处理与评测适合读者LLM 应用开发者、Agent 产品经理、算法工程师、AI 产品技术负责人这段速览看起来更像概念梳理但请你注意一个关键点Agent Skills 不只是一个名词它是一套可执行的能力拆解方法。接下来我会把它拆成三层让你清楚知道每个技能到底在做什么。2. 适用场景与使用边界2.1 适合什么场景Agent Skills 最适用的场景是当你发现自己写的 Agent 经常在“多步骤任务”里失控。典型表现包括让大模型自己规划步骤结果它跳步骤、重复执行、忘记上文。让 Agent 调用外部工具结果工具返回复杂内容后模型不知道下一步该做什么。让 Agent 同时处理多个数据源结果上下文越积越长最终输出质量明显下降。让 Agent 在长任务中保持一致性结果任务进行到一半就丢失了最初目标。需要比较多个 Agent 方案的好坏却没有一套可量化的评价方法。以上问题本质不是模型能力不够而是你没有把“能力”拆成“可复用技能”。Agent Skills 的核心思路是给 Agent 安装可组合的“技能包”让它在恰当的时机调用正确的能力模块。2.2 不适合什么场景如果你只需要做单轮问答、摘要、翻译这类直接生成任务不需要引入复杂的 Agent 框架直接写 Prompt 往往更简单高效。如果你没有大模型 API 调用预算也没有本地模型部署条件那么学习 Agent 开发前需要先解决模型访问问题。如果你追求 100% 确定性流程比如固定字段填表、固定规则处理传统代码比大模型 Agent 更可靠。2.3 使用边界与合规提醒在实际项目里使用 Agent Skills 时请特别注意数据隐私不要把未脱敏的用户隐私数据、企业机密数据直接发送给云端大模型 API。发送前先做脱敏和权限检查。版权合规不要让 Agent 抓取或生成受版权保护的素材用于商业用途涉及第三方内容必须有合法授权。工具权限Agent 调用外部 API、数据库、文件系统时要遵循最小权限原则避免因为 Agent 的自由度过大造成数据误操作。内容安全对 Agent 生成的文本、代码、图片发布前必须做安全审核与事实核查。3. 环境准备与前置条件虽然 Agent Skills 不像本地模型部署那样需要高配显卡但它对开发环境仍然有明确要求。这里给出了一套通用检查清单你可以根据自己的技术栈准备。3.1 硬件与网络一台能正常访问大模型 API 的电脑建议内存不低于 8GB。不需要独立显卡也不需要本地推理引擎。需要稳定的网络连接访问 OpenAI、Anthropic 等 API 服务时网络质量直接影响开发体验。3.2 软件与语言版本Python 3.9 或以上版本建议 3.10/3.11。安装 Jupyter Notebook 或 Jupyter Lab用于边看教程边运行代码。安装常用依赖openai、anthropic、pandas、python-dotenv等。准备一个用于管理 API Key 的环境变量文件.env。# 创建虚拟环境 python -m venv agent_skills_env # 激活虚拟环境Windows agent_skills_env\Scripts\activate # 激活虚拟环境macOS/Linux source agent_skills_env/bin/activate # 安装基础依赖 pip install openai anthropic pandas python-dotenv jupyter3.3 API Key 配置在项目根目录创建.env文件OPENAI_API_KEYsk-xxxxxx ANTHROPIC_API_KEYsk-ant-xxxx MODEL_NAMEgpt-4o然后在代码中加载import os from dotenv import load_dotenv load_dotenv() openai_api_key os.getenv(OPENAI_API_KEY)注意不要把.env文件提交到 Git 仓库建议加入.gitignore。3.4 前置知识清单知识项掌握程度说明Python 基础语法熟练能写函数、类能处理 JSONPrompt 基础理解知道 system prompt、user prompt、few-shot 的作用API 调用熟练能发起一次大模型 completion 请求基本数据结构熟练列表、字典、JSON 转换如果你这些知识点还不熟建议先花一周补齐基础再进入 Agent Skills 学习。4. Agent Skills 学习路线拆解从入门到进阶4.1 理解 Agent Skills 的本质Agent Skills 可以理解为一种“能力模块化”方法。传统 Prompt 是把所有指令写在一段文本里让模型自由发挥。Agent Skills 则是把一个大任务拆成若干技能每个技能有明确的输入、处理逻辑和输出格式。从工程视角看一个 Skill 通常包含以下组成部分dataclass class Skill: name: str # 技能名称 description: str # 技能描述用于告诉 Agent 何时调用 input_schema: dict # 输入格式定义 output_schema: dict # 输出格式定义 execute: Callable # 技能的具体执行函数这个结构很像函数注册表。Agent 在任务执行过程中先根据用户请求判断需要调用哪些 Skill然后按顺序或并行执行。4.2 单技能核心规划、记忆与工具使用4.2.1 规划技能规划技能解决的是“Agent 拿到任务后怎么分解步骤”的问题。最简单的实现方式是让模型先输出一个 JSON 格式的步骤列表然后再逐步执行。例如import json from openai import OpenAI client OpenAI() def plan_task(task: str): planning_prompt f 你是一个任务规划器。请将以下用户任务拆解为不超过5个步骤。 输出格式为 JSON 数组每个元素包含 step、description、inputs 三个字段。 用户任务{task} response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: planning_prompt}], temperature0.2 ) return json.loads(response.choices[0].message.content) def execute_plan(plan, contextNone): results [] for step in plan: # 实际执行时每个 step 对应一个具体函数 result execute_step(step, context) results.append(result) return results这个技能的实际价值是通过步骤约束避免模型一次性生成过长结果导致质量下降。4.2.2 记忆技能记忆技能解决的是“跨会话、跨步骤的信息保持”问题。常见方案有三种短期记忆把当前任务的中间结果存放在内存变量中。长期记忆使用向量数据库保存历史对话或领域知识。结构化记忆将用户偏好、任务状态存入 JSON 文件或数据库。class MemoryStore: def __init__(self): self.short_term {} self.long_term {} def add_short_term(self, key, value): self.short_term[key] value def add_long_term(self, key, value): self.long_term[key] value def get_context(self, user_id): # 实际项目中会结合向量检索 return {**self.short_term, **self.long_term}记忆技能最关键的设计决策不是存什么而是什么时候读、什么时候写。读太多会污染上下文写太少会丢失关键信息。4.2.3 工具使用技能工具使用是 Agent Skills 里最核心也最容易出问题的部分。一个标准的工具调用流程包含四步模型判断需要调用工具。模型输出结构化的工具调用参数。代码执行真实工具并返回结果。模型基于工具结果继续生成。def run_with_tool(user_query): tools [ { type: function, function: { name: search_knowledge_base, description: 从知识库中检索与查询相关的内容, parameters: { type: object, properties: { query: {type: string}, top_k: {type: integer, default: 3} }, required: [query] } } } ] response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: user_query}], toolstools, tool_choiceauto ) return response.choices[0].message工具使用技能在实践中最大的坑是工具返回的数据格式不统一。解决办法是每个工具出口都做一层标准化统一成{status: success, data: {...}}或{status: error, message: ...}。4.3 多技能组合提示链、路由与并行化当你掌握了单项技能下一步是把它们组合成可复用的执行模式。4.3.1 提示链提示链是一种顺序执行模式前一个技能的输出会作为下一个技能的输入。适合处理需要多步变换的任务比如“总结文档 → 翻译摘要 → 提取行动项”。def prompt_chain(initial_input): step1_output summarize(initial_input) step2_output translate(step1_output, target_langen) step3_output extract_action_items(step2_output) return step3_output提示链的优势是每一步都短小可控出错的扩散范围更小。4.3.2 路由路由解决的是“不同需求走不同处理路径”的问题。典型实现是先用一个轻量模型判断任务类型再把任务分发给对应的处理模块。def route_task(user_input): route_prompt f 判断用户请求的类型只能输出以下选项之一 - code_analysis - data_analysis - creative_writing - general_chat 用户请求{user_input} decision client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: route_prompt}], temperature0 ).choices[0].message.content.strip() if decision code_analysis: return analyze_code(user_input) elif decision data_analysis: return analyze_data(user_input) # ...路由的核心收益是降低平均延迟和成本因为只对复杂任务调用强模型。4.3.3 并行化并行化适合处理多个相互独立的任务。比如同时调用多个检索器、同时生成多个候选方案。现代语言模型 API 支持并发请求你可以用ThreadPoolExecutor或asyncio实现。from concurrent.futures import ThreadPoolExecutor, asyncio def parallel_call(task_list): with ThreadPoolExecutor(max_workers3) as executor: results list(executor.map(invoke_llm, task_list)) return results并行化能显著提升批量任务吞吐但要注意 API 速率限制和 token 成本。4.4 多 Agent 协作编排器-工作器模式进阶技能中最值得重点关注的是多 Agent 协作。教程里最常见的设计是“编排器-工作器”模式。编排器 Agent负责理解全局目标、拆解任务、分配任务、汇总结果。工作器 Agent负责执行具体子任务并把结果返回给编排器。class Orchestrator: def __init__(self, workers): self.workers workers def run(self, task): plan self.plan_task(task) sub_results [] for subtask in plan: worker self.workers[subtask.worker_name] result worker.execute(subtask) sub_results.append(result) final_answer self.synthesize(sub_results, task) return final_answer这种模式的优点是职责清晰但要注意编排器的上下文不能无限增长需要及时裁剪。每个工作器返回结果时都要包含置信度方便编排器判断是否需要重跑。工作器之间的状态传递要用结构化数据不要用自然语言长摘要。4.5 反思与评估Agent 开发的闭环能力吴恩达在讲解 Agent Skills 时强调最多的不是如何让 Agent 生成更好而是如何判断 Agent 生成得好不好。这部分通常会引入评估集和评测指标。哪怕教程里代码不复杂你也应该在项目中实践这些思路evaluation_set [ {input: 写一个Python函数计算斐波那契数列, expected_keywords: [def, fib, return]}, {input: 总结以下新闻要点, expected_keywords: [时间, 地点, 影响]} ] def evaluate_agent(agent_func, eval_set): scores [] for item in eval_set: output agent_func(item[input]).lower() missing [k for k in item[expected_keywords] if k not in output] scores.append(1.0 if len(missing) 0 else 0.0) return sum(scores) / len(scores)实际项目中你可以用 LLM-as-a-judge 或规则评分甚至人工抽检。关键是评估必须跑在真实任务样本上而不是已有的理想样例。5. 功能测试与效果验证学习 Agent Skills 时你不可能只看视频就掌握。这里给出一套可以直接照做的验证流程用来测试你已经实现的 Agent 是否真的具备对应技能。5.1 测试规划能力测试输入用户想买一台5000元以内的办公笔记本要求轻便、续航长、能跑日常办公软件。预期结果输出包含 3 到 5 个步骤。步骤之间存在顺序依赖关系。步骤覆盖需求澄清、信息搜集、对比、决策建议。判断成功标准Agent 在后续执行中能按照计划推进没有出现前后矛盾。常见失败原因计划步骤太少不足以覆盖完整任务。计划步骤过于抽象无法映射到实际函数调用。5.2 测试记忆能力按顺序输入两句话“我叫李明喜欢看科幻小说。”“帮我推荐三本适合我的书。”预期结果Agent 推荐的书是科幻类并且推荐理由中引用了用户偏好。判断成功标准Agent 能回忆起第一轮提供的信息不需要用户再次重复。5.3 测试工具调用能力测试输入请查询数据库里所有VIP用户的邮箱并发送一份活动通知。预期结果先调用查询工具获得用户列表。再调用发送通知工具逐条发送。最后返回发送成功/失败统计。判断成功标准工具调用顺序正确失败记录被汇总而不是静默忽略。5.4 测试多 Agent 协作能力测试输入做一个竞品分析报告从技术、价格、用户体验三个维度分析最后给出结论。预期结果编排器把任务拆成三个子任务。三个工作器分别返回对应维度的分析。编排器综合结果生成最终报告。判断成功标准最终报告包含三个维度各维度内容独立无交叉重复结论部分有综合判断。6. 接口 API 与批量任务实战6.1 把 Agent Skills 封装成 API 服务学完技能后最自然的落地方式是用 FastAPI 把 Agent 能力封装成接口。这样其他业务系统可以直接调用也能通过队列机制处理批量任务。下面是一个最小可运行的 API 服务示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class AgentRequest(BaseModel): task: str mode: str plan_and_execute # 可选plan_and_execute / direct class AgentResponse(BaseModel): success: bool message: str result: dict app.post(/api/agent/run, response_modelAgentResponse) async def run_agent(request: AgentRequest): try: result your_agent_execute(request.task, request.mode) return AgentResponse(successTrue, messagesuccess, resultresult) except Exception as e: raise HTTPException(status_code500, detailstr(e)) if __name__ __main__: import uvicorn uvicorn.run(app, host127.0.0.1, port8000)启动服务uvicorn main:app --host 127.0.0.1 --port 8000 --reload6.2 用 curl 测试接口curl -X POST http://127.0.0.1:8000/api/agent/run \ -H Content-Type: application/json \ -d { task: 帮我总结这篇文章并提取行动项, mode: plan_and_execute }6.3 Python 客户端调用import requests url http://127.0.0.1:8000/api/agent/run payload { task: 分析三个竞品产品的定价策略差异, mode: multi_agent } response requests.post(url, jsonpayload, timeout300) print(response.status_code) print(response.json())6.4 批量任务设计批量任务场景下单独同步调接口会阻塞在最长的一个任务上。更稳妥的做法是引入任务队列。这里给出一个基于简单文件队列的批量处理思路import json import os import time from pathlib import Path INPUT_DIR Path(./tasks) OUTPUT_DIR Path(./outputs) PROCESSED_DIR Path(./processed) def process_batch(): for task_file in INPUT_DIR.glob(*.json): task_data json.loads(task_file.read_text(encodingutf-8)) task_id task_file.stem try: result your_agent_execute(task_data[task]) output_path OUTPUT_DIR / f{task_id}_result.json output_path.write_text(json.dumps(result, ensure_asciiFalse, indent2), encodingutf-8) task_file.rename(PROCESSED_DIR / task_file.name) except Exception as e: error_path OUTPUT_DIR / f{task_id}_error.log error_path.write_text(str(e), encodingutf-8) if __name__ __main__: while True: process_batch() time.sleep(10)批量任务的核心原则有三个任务必须有唯一 ID方便定位失败任务。处理结果和错误日志分离。每处理完一个任务就标记完成支持断点续跑。7. 资源占用与性能观察Agent Skills 不需要显卡显存但它的资源消耗反映在 token 使用量、API 请求次数和延迟上。7.1 观察指标指标说明影响Token 消耗每次请求的输入输出 token 数直接影响成本请求次数完成任务所需的 API 调用次数影响总延迟和成本端到端延迟从提交任务到获得最终结果的时间影响用户体验成功率任务在限制时间内正确完成的比率影响系统可靠性上下文长度每个 Agent 维护的上下文长度影响模型质量和成本7.2 成本控制建议用gpt-4o-mini或同等级轻量模型处理路由、摘要、分类任务。用强模型只在最终生成或复杂推理时调用。对重复性任务加入缓存层相同输入直接返回历史结果。对长文档处理先做分段和压缩再把中间结果传给主 Agent。7.3 如何判断性能瓶颈如果你发现 Agent 响应很慢按以下顺序排查是不是某个工具调用的外部 API 慢是不是模型生成步骤太多导致 token 累积是不是上下文太长模型输入计算开销大是不是并行任务没有真正并行而是串行排队其中最常见的问题是第三种Agent 每执行一步都把前面所有历史塞进上下文。解决方案是只保留最近 N 轮关键信息同时把总结后的长文转存到外部存储。8. 常见问题与排查方法问题现象可能原因排查方式解决方案Agent 规划步骤混乱提示词未明确输出格式模型自由发挥检查规划提示词是否限制了 JSON 输出加入强约束的 JSON Schema设置温度0Agent 忘记用户偏好记忆技能未实现跨步骤持久化检查上下文是否包含历史偏好信息引入 MemoryStore在任务开始前载入用户历史工具调用返回格式无法解析工具返回不是标准 JSON打印工具原始返回在工具出口增加标准化处理API 返回 429 错误请求超过速率限制查看 API 错误码加入指数退避重试或限制并发数Agent 生成结果不稳定温度和上下文波动对比多次运行结果固定 temperature控制上下文前缀批量任务卡住不动某个任务内循环或外部接口超时查看任务日志和进程状态为每个任务设置超时时间和最大重试次数最终报告质量差编排器没有合理汇总检查每个工作器返回结果的结构要求每个工作器返回结构化数据和置信度上下文超出模型限制长任务中历史消息不断累积监控 messages 长度加入上下文裁剪和摘要压缩9. 最佳实践与使用建议9.1 最小可运行原则第一次实现某项 Agent 技能时不要一上来就设计复杂的工作流。先跑通一个最小闭环输入一个测试任务。执行一个技能。输出一个结构化结果。打印中间日志。确认这个闭环没问题再增加更多技能和分支逻辑。9.2 日志是 Agent 开发的命脉Agent 是异步、多步骤、调用外部服务的系统一旦出错没有日志根本无从排查。建议至少记录每步技能的名称和输入输出摘要。调用的模型和 token 用量。工具调用的入参和出参。每次任务的开始时间、结束时间、状态。import logging logging.basicConfig( levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s, handlers[ logging.FileHandler(agent.log, encodingutf-8), logging.StreamHandler() ] ) def log_step(step_name, input_data, output_data): logging.info(fSTEP{step_name} INPUT{str(input_data)[:200]} OUTPUT{str(output_data)[:200]})9.3 Prompt 和代码分离把技能对应的 Prompt 模板放到独立的 JSON 或 YAML 配置文件里而不是硬编码在 Python 代码中。这样调整提示词时不需要改业务代码也方便做多版本对比。# skills/planner.yaml name: planner prompt: | 你是一个任务规划器。 将用户任务拆解为不超过5个步骤。 输出格式JSON数组元素包含 step/description/inputs。 temperature: 0.2 max_tokens: 8009.4 评估先行进到进阶阶段后任何 Agent 改动都必须先跑评估集再决定是否上线。评估集建议覆盖正常任务。边界输入空内容、超长内容、错误格式。需要多轮交互的任务。工具调用失败的任务。9.5 安全与授权不能省如果你的 Agent 会调用真实业务系统比如发邮件、修改数据库、执行命令务必加上人类确认环节。Agent 的自由度要分当前等级只读操作可以自动执行。写操作需要二次确认。高危操作必须人工审批。10. 总结与下一步吴恩达的 Agent Skills 系列最大的价值是提供了一套标准化的 Agent 能力拆解框架。学完之后你应该具备以下能力把任意复杂任务拆成规划、记忆、工具调用、协作、评估等技能模块。用提示链、路由、并行化等模式组合基础技能。用编排器-工作器模式实现多 Agent 协作。通过评估集定量判断 Agent 输出质量。用 API 服务和批量任务把技能落地到实际业务。建议收藏备用。后续你可以按这个顺序继续深入先选一个自己业务中最常见、最重复的场景用提示链模式实现最小闭环。再给这个闭环加入工具调用和记忆能力。引入评估集量化对比每次改动的效果。最后把稳定运行的流程封装成 API 服务。这条路走通之后你会发现 Agent 开发不再是“调 prompt 碰运气”而是一套可设计、可测试、可迭代的工程方法。