xhj的博客

第十节：Conclusion（总结） 作为本课程的回归讲师，Elie Schoppik 在本节中全面回顾了整套 agent-skills-with-anthropic 课程的核心内容和学习要点。 从基础概念到实践应用，从内置 Skills 探索到自定义 Skills 开发，课程系统地介绍了如何利用 Skills 扩展 AI agent 的能力边界，构建智能化、专业化的工作流程。 课程深度回顾：构建智能体的“第二大脑”回顾整门课程，我们不仅仅是在学习一个名为 “Skills” 的功能，更是在探索大模型时代下“知识工程”的新形态。 1. 从指令到资产 (From Instructions to Assets)我们在 Chapter 2 和 Chapter 3 中定义了 Skills 的本质：它不是一次性的 Prompt，而是标准化的领域认知。通过 YAML 元数据与 Markdown 正文的解耦，我们将“业务逻辑”封装为可复用、可迁移的数字资产。这正是将人类隐性知识显性化的过程。 2. 系统架构的演进 (Evolution of Architecture)Chapter 4 揭示了...

第一节：Introduction（课程介绍） 1、课程概述本课程是 DeepLearning.AI 与 Anthropic 合作打造的 Agent Skills 专项课程，由回归讲师 Elie Schoppik 主讲。 在本课程中，我们将探讨 Skills 如何赋能 Claude 及其他 AI 智能体执行复杂任务。技能通过向智能体提供专门的指令和知识来扩展其能力。 理解 Skills 的工作原理 掌握创建 Skills 构建适用于不同场景的 Skills（包括编程、研究、数据分析等） 2、什么是“Skills”？什么是 Agent Skills？Agent Skills 是一种扩展智能体能力的模块化指令集合。通过技能，Claude 和其他 AI 智能体可以获得执行特定任务的新能力。 Skills 是文件夹形式的指令集合，用于扩展智能体的能力，赋予其专门的知识来执行任务。 Skills 的核心特点 开放标准：Skills 现在是一个开放标准，采用标准化格式，可与任何兼容的智能体产品配合使用 一次构建，多处部署：你可以构建一次技能，然后在多个智能体产品中部署使用 渐进式披露：技...

06. 验证与质量保证需求文档1. 为什么“做完”不等于“完成”在 AI 编程产品里，最大的风险之一是：模型会把“代码改了”误当成“任务完成了”。 因此，这个产品必须把“验证”设计成一个独立能力，而不是可有可无的附属步骤。 2. 验证系统的产品目标 独立检查实现是否真的可用 防止只读代码就宣称完成 防止 happy path 偏见 让验证结果带证据而不是口头判断 3. 验证 Agent 的需求3.1 独立角色验证角色需要与实施角色分离，避免实现者偏见。 3.2 默认心智模型验证角色的工作不是“帮实现找理由通过”，而是主动尝试发现问题。 3.3 必须禁止的行为验证角色不能： 修改项目文件 安装依赖 用写操作掩盖问题 3.4 必须支持的检查类型 build test suite lint / type-check 接口调用验证 UI 自动化验证 CLI 输入输出验证 migration 验证 adversarial probe 4. 输出格式需求验证结果必须满足： 有检查项标题 有实际执行命令 有真实输出 有 PASS / FAIL / PAR...

14. 配置系统规格1. 目标配置系统负责把产品的默认行为、用户偏好、项目约束和扩展能力统一管理，而不是散落在代码里。 2. 配置来源Python 版建议支持以下来源： 全局用户配置 项目级配置 session 级配置 plugin / skill frontmatter 配置 环境变量 CLI 参数覆盖 3. 配置优先级建议优先级从高到低： runtime override / CLI 参数 session 配置 项目配置 用户全局配置 默认配置 4. 必须可配置的项目 默认模型 语言 输出风格 permission mode hook 开关与 hook 配置 MCP server 配置 plugin 路径 skill 路径 token / task budget 自动 compact 开关 transcript 持久化开关 5. Agent 级配置需求每个 agent 定义建议支持： agent_type when_to_use allowed_tools / disallowed_tools model memory sc...

04. 记忆与会话系统需求文档1. 为什么需要记忆系统如果产品只靠当前窗口上下文工作，会出现几个问题： 用户长期偏好无法沉淀 项目背景每次都要重新解释 复杂任务容易因上下文压缩而丢失关键事实 系统无法逐步形成“协作连续性” 因此，这个产品需要一个多层级记忆系统。 2. 记忆系统的产品目标 保存长期有效的用户偏好和协作约束 保存项目级背景信息 在上下文压缩后仍能恢复关键事实 支持会话恢复与后续继续执行 为子任务和后台任务提供必要的上下文继承 3. 记忆层级反推从目录结构与调用链可以推断，产品至少需要以下记忆层级： 3.1 用户级记忆保存： 用户语言偏好 输出风格偏好 常见工作习惯 可长期生效的协作规则 3.2 项目级记忆保存： 项目目录背景 常用命令 测试 / 构建约定 项目规范文件中的持续性要求 3.3 会话级记忆保存： 当前任务目标 当前已知上下文 本轮执行中的中间状态 当前阶段的局部决策 3.4 子任务级记忆保存： 子 agent 的任务目标 子 agent 的局部上下文 fork 继承的父上下文 验证 / 探索 / 规划等专...

01. 系统提示词与 Agent 编排需求文档1. 系统提示词为什么不是一段固定文案从源码结构可以反推，这个产品要求系统提示词具备“动态拼装”能力，而不是固定模板。 需求原因用户环境、工具集、语言、输出风格、会话状态、MCP 连接状态都可能变化。如果系统提示词不能动态组装，就会出现： 规则不匹配当前会话 工具说明失效 记忆无法注入 token 成本失控 2. 系统提示词层的核心需求2.1 基础身份定义系统需要明确告诉模型： 你是执行型协作者 你的主要任务是软件工程支持 你的输出直接给用户看 2.2 做任务规范系统需要内建一套工程行为规范，例如： 不要乱加功能 不要过度抽象 不要假装验证过 先读代码再改代码 不要随意创建文件 这不是“风格偏好”，而是稳定性需求。 2.3 风险动作规范系统需要明确哪些操作有 blast radius，需要额外确认。例如： 删除 推送 外部可见动作 修改共享状态 2.4 工具使用语法系统不仅要告诉模型“有什么工具”，还要告诉它： 什么时候读文件 什么时候搜索 什么时候编辑 什么时候用 shell 什么时候并行调用 3. 动态区块需求...

09. 消息模型与状态规格1. 为什么消息模型必须先定义这类 Agent 系统的核心不是“函数调用”，而是“结构化消息驱动状态变化”。如果消息模型不稳定，后面的 memory、resume、工具执行、agent 任务都会混乱。 2. 顶层消息类型Python 版本建议至少定义以下消息类型： system user assistant tool_use tool_result progress attachment summary compact_boundary notification tombstone（可选，用于删除/隐藏历史消息后的链修复） 3. 核心消息字段所有消息建议共享： 123456class BaseMessage: id: str type: str created_at: float parent_id: str | None session_id: str assistant 消息1234class AssistantMessage(BaseMessage): content_blocks: list ...

07. 架构能力地图1. 顶层能力区A. 入口层对应需求： 提供 CLI 入口 提供初始化流程 提供 SDK 接入方式 提供 MCP 入口 B. Prompt 编排层对应需求： 动态生成系统提示词 注入环境信息 注入语言与输出风格 注入记忆、MCP 说明、会话局部规则 C. 工具执行层对应需求： 工具发现 工具输入校验 权限判断 Hook 拦截 执行记录 输出回流 D. Agent 调度层对应需求： 启动子 agent 支持 fork / background / remote / teammate 模式 管理 agent 生命周期 管理 agent 上下文边界 E. 扩展生态层对应需求： Skills Plugins MCP 命令扩展 插件变量替换与配置注入 F. Memory / Session 层对应需求： 项目记忆 用户记忆 会话摘要 transcript resume G. 任务与后台层对应需求： 本地任务 后台 agent 任务 远程 agent 任务 shell 任务 进度追踪与通知 H. 质量保证...

02. 工具、权限与执行链需求文档1. 为什么工具系统是产品核心如果模型不能操作环境，它只是建议生成器。这个产品的目标是帮助用户推进真实工程任务，因此必须具备正式的工具系统。 2. 工具系统需求2.1 基础工具能力产品至少需要以下工具类别： 读文件 改文件 写文件 搜索文件 搜索内容 shell / 命令执行 todo / 任务管理 用户追问 启动子 agent 调用外部 MCP 工具 2.2 工具使用规范系统必须对模型明确规定工具使用优先级，避免： 用 shell 替代专用文件工具 误删或误改文件 低效重复操作 3. 权限系统需求3.1 用户控制边界用户必须能控制哪些工具自动允许，哪些要询问，哪些禁止。 3.2 权限决策来源权限决策至少可能来自： 当前模式 用户规则 项目规则 Hook 决策 特殊工具安全策略 3.3 被拒后的行为要求如果某次工具调用被拒绝，系统不能机械重试，而应： 理解拒绝信号 调整方案 必要时向用户澄清 4. 执行链路需求工具执行不能是“模型决定 -> 直接运行”。产品需要一条正式执行链： 找到工具 校验输入结构 ...

12. 工作区与隔离策略规格1. 目标不同 agent 不能默认拥有相同的文件系统权限。产品必须允许根据角色与场景控制工作区隔离。 2. 隔离模式Python 版建议至少定义： 2.1 shared workspace主线程默认工作区，共享项目目录。 2.2 read-only workspace用于探索、规划、验证等只读角色。 2.3 temp workspace用于临时脚本、临时测试产物。 2.4 worktree workspace用于隔离修改型子任务，避免污染主分支。 2.5 remote workspace用于远程执行环境（第一版可不做）。 3. 为什么隔离必须存在没有隔离会导致： 子任务互相污染 验证角色破坏项目 fork 实验影响主线程 风险动作边界模糊 4. 角色与隔离建议 Explore Agent -> read-only Plan Agent -> read-only Verification Agent -> read-only + temp writable General Agent -> shared 或 worktree...