企业官网建设流程全解析

最近在整理 Agent 开发相关的开源资料时，发现社区里反复出现四个关键词：Agent工作流、钩子、技能、MCP服务。很多读者在问它们到底有什么关系、从哪入手、能不能跑通一个最小示例。本期 GitHub 快报不追求罗列一堆仓库，而是围绕这四个高频方向拆开讲透，配合可以直接运行的最小示例，同时把近期热搜里反复出现的 GitHub 使用问题一起收进来，整理成一份可执行的学习笔记。

适合的读者有两类：一类是第一次接触这些概念、想快速建立整体认知的新手；另一类是有一定开发基础、想直接找到代码和配置思路的开发者。前者可以从第 2 节顺序往下读，后者可以直接跳到第 5 节看 MCP 服务的搭建与调用流程。

仓库列表会随着时间不断变化，但概念、协议和工程套路可以长期复用，所以本文的知识点优先于具体仓库推荐。

1. 本期快报关键词全景

1.1 四个关键词分别解决什么问题

先建立一个整体认知。这四个词不是并列关系，而是分别回答了 Agent 应用开发中的四类问题：

从近期热搜词来看，社区关注度最高的几个方向是：

• 开发一个个人任务管理 Agent 工作流；
• 钩子函数 C 语言示例；
• 把重复工作流程保存为自定义技能；
• MCP 服务搭建及实施调用流程；
• Dify Agent 工作流中使用 MCP；
• 以及大量围绕 GitHub 使用、下载、评估仓库的经验类问题。

这些热词恰好覆盖了“构建一个 AI 应用”从 0 到 1 的完整路径，所以本期快报选择直接把它们作为主线。

1.2 四者如何组合成一个完整 Agent 应用

只看概念比较抽象，可以用一个贯穿全文的场景来理解：做一个“个人任务管理 Agent 工作流”。

• 用户输入一段原始任务文字，Agent 工作流负责把任务拆解、排优先级、逐步执行、汇总结果；
• 在任务执行节点前后，钩子负责记录日志、校验数据、做审计；
• 如果每周都需要把任务汇总成周报，把“周报生成”这个固定流程沉淀为技能；
• 如果还需要查询日历、天气、待办事项，就通过 MCP 服务把这些外部能力接入进来。

所以四者的关系可以这样描述：MCP 服务提供“工具能力”，钩子提供“扩展插槽”，技能提供“可复用模板”，Agent 工作流负责把前三者组织成一条完整的执行链路。

2. Agent工作流：从概念到最小实现

2.1 什么是 Agent 工作流

工作流在传统软件里是流程图、状态机，在 Agent 场景下则变成“LLM 节点 + 工具节点 + 分支条件 + 循环 + 上下文传递”的编排产物。

最简单的理解：不直接让大模型一次性回答，而是把任务拆成若干个可控步骤，每一步可以交给大模型、普通代码或外部工具去完成。

这样做有两个明显好处。

第一，可控性更强。任务拆解规则、执行顺序、超时和重试都可以由流程控制，不至于让大模型自由发挥导致结果不可预期。

第二，可观测性更好。每一步都有明确输入输出，哪一步出问题可以单独定位和修复，这在生产环境里非常重要。

实际项目中，Agent 工作流往往需要平衡“确定性”和“灵活性”：确定性的流程容易测试和排错，适合固定业务；灵活性则交给大模型决策，适合开放域问题。一个合格的工作流设计，应该把“决策点”留给大模型，把“执行步骤”交给代码和工具。

2.2 一个人人可用的场景：个人任务管理 Agent

用“个人任务管理 Agent 工作流”作为示例最合适，因为它场景清晰、门槛低，且和近期热搜词完全对应。

这个工作流可以拆成四个节点：

1. 解析任务：把用户输入的原始文本拆分成结构化任务项；
2. 分配调度：根据规则或 LLM 决策给任务排优先级；
3. 执行任务：逐个执行，这里可以接入普通函数、API 或工具调用；
4. 汇总结果：把每个任务的执行结果整理成最终输出。

先不引入任何外部框架，用 Python 写一个极简的工作流引擎，理解核心机制之后再上 Dify 等平台就很简单了。

2.3 极简 Python 工作流引擎示例

下面这份代码演示了“节点 + 上下文”的工作流核心模式。每个节点接收一个上下文 dict，执行后把结果写回 dict，下一个节点继续读取。

# 文件路径：task_agent_workflow.py # 一个极简的个人任务管理 Agent 工作流演示 # 核心思路：把“解析 -> 调度 -> 执行 -> 汇总”编排成节点流水线 from dataclasses import dataclass from typing import Callable, Dict, Any class WorkflowNode: def __init__(self, name: str, fn: Callable[[Dict[str, Any]], Dict[str, Any]]): self.name = name self.fn = fn def run(self, ctx: Dict[str, Any]) -> Dict[str, Any]: print(f"[node: {self.name}] start") # 执行节点逻辑，并把返回的字段合并进上下文 result = self.fn(ctx) or {} ctx.update(result) print(f"[node: {self.name}] done") return ctx @dataclass class Task: title: str priority: str = "普通" status: str = "待处理" def parse_task(ctx): # 真实项目这里可以调用 LLM 做语义拆解，这里用换行符演示固定解析 raw = ctx.get("raw_task", "学习MCP服务") lines = [line.strip() for line in raw.split("\n") if line.strip()] tasks = [Task(title=line) for line in lines] return {"tasks": tasks} def dispatch_task(ctx): # 模拟按规则调度：标题中包含“紧急”则提升优先级 for t in ctx["tasks"]: if "紧急" in t.title: t.priority = "高" # 高优先级排前面，稳定排序 ctx["tasks"].sort(key=lambda x: x.priority != "高") return {"plan": [f"{t.priority}:{t.title}" for t in ctx["tasks"]]} def execute_task(ctx): # 模拟执行任务，实际项目可在这里调用 API 或 MCP 工具 results = [] for t in ctx["tasks"]: results.append({"title": t.title, "result": f"[{t.priority}] 已完成"}) return {"results": results} def summarize(ctx): lines = [f"- {r['title']}：{r['result']}" for r in ctx["results"]] return {"summary": "执行计划：\n" + "\n".join(lines)} def run_workflow(nodes, initial_ctx): ctx = dict(initial_ctx) for node in nodes: node.run(ctx) return ctx if __name__ == "__main__": workflow = [ WorkflowNode("解析任务", parse_task), WorkflowNode("分配调度", dispatch_task), WorkflowNode("执行任务", execute_task), WorkflowNode("汇总结果", summarize), ] ctx = run_workflow( workflow, {"raw_task": "学习MCP\n准备技能包\n处理紧急需求"} ) print("\n最终输出：") print(ctx["summary"])

运行方式：

python task_agent_workflow.py

预期输出大致如下：

[node: 解析任务] start [node: 解析任务] done ... 最终输出： 执行计划： - 处理紧急需求：[高] 已完成 - 学习MCP：[普通] 已完成 - 准备技能包：[普通] 已完成

这个示例的关键点在于：

• 所有节点通过ctx上下文对象传递数据，节点之间不直接依赖，方便插入、替换、删除；
• 返回值为 dict，与上下文合并时只更新自己的字段，避免覆盖其他节点的数据；
• 每个节点打印开始和结束日志，这是最简单也最有效的可观测性手段。

2.4 在 Dify 中编排 Agent 工作流的常见节点

很多读者搜索“Dify agent 工作流中使用”，其实是想知道平台上的工作流怎么和代码实现的思路对应。Dify 的工作流编辑器中，常见节点包括：

• 开始节点：定义用户输入变量；
• LLM 节点：配置模型、系统提示词和输出变量；
• 工具节点：调用插件、API 或 MCP 工具；
• 条件分支节点：根据变量值走不同路径；
• 迭代节点：对数组变量循环处理；
• 知识库检索节点：从知识库召回相关内容。

Dify 中有两个容易混淆的概念：Agent 应用更适合多轮自由对话，大模型自主决定调用哪些工具；工作流应用则适合固定流程，每一步由编排决定。实际项目经常是两者结合：外部用 Agent 做意图判断，内部用工作流保证关键步骤严格执行。

3. 钩子：让工作流具备“插拔”能力

3.1 钩子的本质与常见形态

钩子的本质是在固定执行点预留回调入口。主流程不需要关心钩子内部逻辑，只需要在特定时机触发注册进来的函数。

一个完整的钩子机制通常包含三个要素：

1. 触发时机：在什么事件或状态变化时触发；
2. 注册机制：使用者如何把自己的函数挂载上去；
3. 执行上下文：钩子能拿到哪些数据，能不能修改主流程状态。

钩子在工程中非常常见：Git 钩子、CI/CD Webhook、Web 框架中间件、事件总线回调都是钩子的变体。在 Agent 工作流中，钩子通常用于日志、鉴权、数据校验、上下文补全和审计。

3.2 钩子函数 C 语言示例

近期热搜里“钩子函数 c 语言示例”出现频率很高，这里用函数指针实现一个最简单的事件钩子。

// 文件路径：hook_demo.c // 通过函数指针实现简单的事件钩子：在事件触发时回调用户注册的函数 #include <stdio.h> // 定义钩子函数类型：接收事件名和事件数据 typedef void (*HookFn)(const char* event, const char* data); // 一个简单的事件循环结构，内部保存用户注册的钩子函数 typedef struct { HookFn on_event; } EventLoop; void event_loop_init(EventLoop* loop) { loop->on_event = NULL; } // 注册钩子 void event_loop_register_hook(EventLoop* loop, HookFn fn) { loop->on_event = fn; } // 事件分发：主流程只负责触发，具体逻辑交给钩子 void event_loop_dispatch(EventLoop* loop, const char* event, const char* data) { printf("[event] %s -> %s\n", event, data); if (loop->on_event != NULL) { loop->on_event(event, data); } } // 用户自定义钩子实现 void my_hook(const char* event, const char* data) { printf("[hook] 收到事件 %s，附带数据 %s\n", event, data); } int main(void) { EventLoop loop; event_loop_init(&loop); event_loop_register_hook(&loop, my_hook); event_loop_dispatch(&loop, "before_run", "task-001"); return 0; }

编译运行：

gcc hook_demo.c -o hook_demo ./hook_demo

预期输出：

[event] before_run -> task-001 [hook] 收到事件 before_run，附带数据 task-001

这个例子的核心在于event_loop_dispatch只负责分发事件，不关心my_hook内部做了什么。新增一个钩子不需要修改主流程代码，这就是“插拔”能力。

3.3 Git 钩子：一次提交前的校验实践

Git 钩子是开发者最常接触的钩子机制。下面实现一个pre-commit钩子，在提交前检查暂存区是否包含疑似敏感文件。

#!/bin/sh # 文件路径：.git/hooks/pre-commit # 提交前检查暂存区是否包含疑似敏感文件 if git diff --cached --name-only | grep -E "\.(env|pem|key)$"; then echo "错误：检测到疑似敏感文件被暂存，请移除后再提交。" exit 1 fi echo "pre-commit 校验通过" exit 0

保存后需要添加可执行权限：

chmod +x .git/hooks/pre-commit

之后如果执行git add .env && git commit，提交会被拦截。这是用最小成本避免密钥入库的有效手段。

3.4 在 Agent 工作流中设计节点钩子

把钩子思路移植到 Agent 工作流中，就是给每个节点增加 before 和 after 两个扩展点。

# 文件路径：agent_hooks.py # 为工作流节点增加 before/after 钩子 from typing import Callable, Dict, Any, List class HookableWorkflowNode: def __init__(self, name: str, run_fn: Callable): self.name = name self.run_fn = run_fn self.before_hooks: List[Callable] = [] self.after_hooks: List[Callable] = [] def add_before_hook(self, hook: Callable): self.before_hooks.append(hook) def add_after_hook(self, hook: Callable): self.after_hooks.append(hook) def execute(self, ctx: Dict[str, Any]) -> Dict[str, Any]: for hook in self.before_hooks: hook(self.name, ctx) self.run_fn(ctx) for hook in self.after_hooks: hook(self.name, ctx) return ctx def logging_hook(node_name: str, ctx: Dict[str, Any]): print(f"[log] 节点 {node_name} 准备执行，上下文键: {list(ctx.keys())}") def audit_hook(node_name: str, ctx: Dict[str, Any]): print(f"[audit] 节点 {node_name} 已记录审计日志") def run_node(ctx: Dict[str, Any]): ctx["step_count"] = ctx.get("step_count", 0) + 1 print(f" 执行核心逻辑，当前步数: {ctx['step_count']}") if __name__ == "__main__": node = HookableWorkflowNode("任务执行", run_node) node.add_before_hook(logging_hook) node.add_before_hook(audit_hook) node.add_after_hook(logging_hook) node.execute({"task": "写日报"})

运行python agent_hooks.py可以看到执行顺序是：before 钩子 → 核心逻辑 → after 钩子。

这种设计的价值在于：日志、鉴权、审计这些横切关注点从核心逻辑中剥离出来，不会污染业务代码。在生产项目中，建议在钩子内部自行捕获异常，避免钩子崩溃导致主流程中断。

4. 技能：把重复流程沉淀为可复用资产

4.1 技能、技能包、技能树的概念边界

“技能”在 Agent 生态里越来越常见，但很多读者容易把下面几个概念混淆：

近期热词里同时出现了 ComfyUI 技能包、CTFHub 技能树、Trae 技能开发、Cursor 技能等话题，说明技能这个概念已经从配置文件演变成一种可分发、可版本化的资产。在职业竞赛训练、AI 绘画、IDE 辅助开发等场景里，技能都用来沉淀领域专家的经验。

4.2 如何从重复工作流中提炼一个技能

很多读者搜索“把重复工作流程保存为自定义技能”，说明大家真正关心的是方法论。提炼技能可以按四步走：

1. 找重复：找出每周、每天都会做的工作，例如周报、例会摘要、代码审查；
2. 抽模板：把固定的指令部分写成模板，把每次变化的内容抽成参数；
3. 定边界：明确输入字段、输出格式、依赖条件和所需权限；
4. 存版本：把技能放入目录和 Git 仓库管理，记录版本。

一个技能通常至少包含三部分：描述信息（名称、用途）、输入输出 Schema、执行逻辑（提示词模板或代码步骤）。

4.3 用 YAML 定义技能并用 Python 加载

下面用一个“周报生成技能”演示如何把重复工作流封装成技能文件。

# 文件路径：skills/weekly_report.skill.yaml name: weekly-report description: 根据本周完成任务列表生成周报 version: 1.0.0 author: developer input: tasks: type: array description: 本周完成任务列表 items: type: string reviewer: type: string description: 收件人，可空 output: report: type: string description: 生成的周报 prompt: | 你是一个周报助手。请根据以下任务生成结构化周报： {tasks} 收件人：{reviewer}

再写一个简单的加载器：

# 文件路径：skill_runner.py # 安装依赖：pip install pyyaml import yaml def load_skill(path: str) -> dict: with open(path, "r", encoding="utf-8") as f: return yaml.safe_load(f) def render_prompt(skill: dict, params: dict) -> str: return skill["prompt"].format(**params) if __name__ == "__main__": skill = load_skill("skills/weekly_report.skill.yaml") prompt_text = render_prompt( skill, { "tasks": "完成账号体系设计\n修复登录超时问题", "reviewer": "组长", }, ) print(prompt_text)

运行：

pip install pyyaml python skill_runner.py

加载器会把技能里的模板渲染成完整提示词，后续可以交给 LLM 节点执行。实际产品中，技能往往还会包含工具调用定义，例如“查询本周任务列表”这个步骤可以绑定一个 MCP 工具。

4.4 技能包的分发与注意事项

技能包要在团队内分发，需要注意几点：

• 必须包含 README，说明用途和输入输出；
• Schema 要与模板变量一一对应，避免出现{tasks}有定义但代码不传的情况；
• 技能包中不要内置敏感信息，密钥应通过环境变量或配置中心注入；
• 使用语义化版本号，修改模板可能导致生成结果变化，需要评估影响。

5. MCP服务：工具接入的统一协议

5.1 MCP 是什么，解决什么痛点

MCP 全称 Model Context Protocol，是由 Anthropic 提出并推动的开放协议，目标是让 AI 应用通过统一方式连接外部工具和数据源。可以把它理解成 AI 工具接入的“USB-C 接口”：过去每个工具都要单独适配，现在只要实现一套协议就能被多个支持 MCP 的客户端使用。

MCP 架构包含三层：

• Host：宿主应用，例如 Claude Desktop、Dify、自研 Agent 应用；
• Client：运行在 Host 内的 MCP 客户端，负责与服务端通信；
• Server：MCP 服务端，向客户端暴露工具、资源和提示词模板。

传输方式常见有三种：stdio（本地进程间通信）、SSE（服务器推送事件）、Streamable HTTP。本地开发通常用 stdio 最方便，远程部署则需要 HTTP 传输并考虑鉴权。

5.2 MCP 服务端 Demo：用 Python 搭建

下面用一个最简单的 Python 示例演示 MCP 服务端如何暴露两个工具。关键思路是：工具就是普通函数，加上注册装饰器后自动暴露给客户端。

# 文件路径：mcp_time_server.py # 一个极简的 MCP 服务端 Demo # 安装依赖：pip install "mcp[cli]" from mcp.server.fastmcp import FastMCP import datetime mcp = FastMCP("demo-time-server") @mcp.tool() def get_current_time(timezone: str = "Asia/Shanghai") -> str: """返回当前时间。 参数 timezone 用于兼容客户端传参，演示时以服务器本地时间为准。 """ now = datetime.datetime.now() return f"当前时间（服务器本地）：{now.isoformat()}，请求时区：{timezone}" @mcp.tool() def add_numbers(a: float, b: float) -> float: """一个简单的计算工具，用于演示 MCP 工具的参数传递。""" return a + b if __name__ == "__main__": # 默认以 stdio 传输方式启动；远程调试可改为 mcp.run(transport="sse") mcp.run()

本地直接运行：

python mcp_time_server.py

程序会以 stdio 模式常驻，等待客户端请求。如果需要可视化调试，可以安装较新的mcp[cli]后使用官方调试面板：

mcp dev mcp_time_server.py

不同版本 SDK 的命令入口可能存在差异，如果mcp dev不可用，直接运行脚本也能通过测试客户端验证。

5.3 从“搭建”到“调用”的完整实施流程

结合热搜词“MCP 服务搭建及实施调用流程”，把完整流程拆成七个步骤：

1. 在服务端定义并注册工具函数；
2. 启动 MCP 服务，监听指定传输方式；
3. 在客户端配置 MCP 服务器地址或启动命令；
4. 客户端启动后自动发现服务端工具列表；
5. 用户请求触发 Agent 决策，Agent 按需调用工具；
6. 服务端执行工具并返回结构化结果；
7. Agent 把工具结果和原始问题一起组织成最终回答。

注意事项：工具调用一定要设置超时，服务端要做好输入校验，日志中不要记录完整敏感参数。

5.4 在 Dify Agent 工作流中接入 MCP 服务

近期搜索热度很高的“Dify agent 工作流中使用 mcp”也在这里一并说明。Dify 不同版本的工具菜单名称存在差异，但整体思路一致：

• 在 Dify 的“工具”或“插件”页面添加自定义 MCP 服务器；
• 本地 stdio 类型需要填写启动命令和参数，例如python /path/mcp_time_server.py，并且 Dify 服务所在机器必须安装对应的 Python 依赖；
• 远程 SSE 或 HTTP 类型需要填写服务地址，并确保 Dify 到该地址的网络可达；
• 接入成功后，在 Agent 工作流中添加“工具节点”，选择对应的 MCP 工具，把上游变量绑定到工具参数上；
• 工具返回结果通过节点输出变量传回，后续 LLM 节点可以引用。

如果遇到“工具加载不出来”，优先检查传输类型是否匹配、服务地址是否可达、服务端进程是否正常启动、Python 依赖是否完整。

6. GitHub 使用经验：这一周被反复问到的问题

6.1 仓库访问与下载的实用技巧

本期热搜里出现了大量 GitHub 使用相关问题。对于访问不稳定、下载慢的场景，可以先从下面几个方向解决：

• 优先使用仓库 Releases 页面下载打包好的源码或二进制，很多情况下比git clone更快；
• 只想要最新代码做研究时，使用浅克隆减少传输量：

git clone --depth 1 https://github.com/owner/repo.git

需要完整历史时再执行git fetch --unshallow；

• 使用 GitHub 官方命令行工具gh管理仓库和搜索：

gh search repos "mcp server" --language Python --sort stars gh repo clone owner/repo

• 如果网络环境确实不稳定，可以把仓库导入 Gitee 等国内代码托管平台，再从同步仓库拉取，这种方式不依赖额外工具，适合团队内部协作；
• 使用 GitHub Codespaces 可以在浏览器中打开仓库并在线编辑运行，不需要把大仓库完整下载到本地。

6.2 如何从“看热搜”升级为“拆源码”

本周热搜里出现了一些陌生的仓库名称，比如 qzonearchive、omniroute、deepseek hermes 等。单看名字很难判断具体能力，建议按下面清单评估一个仓库值不值得深入：

不要因为仓库星数高就直接拿进生产环境，也不要因为星数少就完全忽略。先 fork 到自己的账号下跑一遍 README，验证通过后再评估是否引入依赖。

6.3 值得收藏的 GitHub 搜索姿势

除了在网页上搜索，还可以使用 GitHub 高级搜索语法快速过滤：

topic:mcp lang:python stars:>200 agent workflow created:>2025-01-01

用topic:可以发现同一主题的项目集合，用lang:过滤编程语言，用日期范围筛选新项目。另一个思路是去找维护较好的 awesome 列表，通常这些列表会按主题整理优质仓库，比搜索引擎结果更可靠。

7. 常见问题与排查清单

7.1 常见问题对照表

7.2 各方向排查清单

Agent 工作流：

• 检查每个节点是否都往 ctx 写入了预期字段；
• 检查条件分支的判断表达式；
• 给循环节点设置最大次数；
• 在关键节点打印输入输出摘要。

钩子：

• 确认钩子文件路径是否正确，例如.git/hooks/pre-commit；
• 确认脚本是否可执行；
• 在钩子内部捕获异常并写日志；
• 确认注册顺序符合预期。

技能：

• 用yaml.safe_load提前校验语法；
• 确认模板变量名与传入参数完全一致；
• 确认技能包内的依赖已经安装；
• 技能版本变更后重新测试最小示例。

MCP 服务：

• 确认 Python 环境和mcp包安装正确；
• 确认传输方式匹配：stdio 对应本地命令，SSE/HTTP 对应远程地址；
• 确认服务端工具名称在客户端可见；
• 设置合理的工具调用超时。

8. 最佳实践与工程建议

8.1 工作流设计

工作流设计的第一原则是“确定性优先，LLM 只做决策”。能用规则表达的流程不要交给大模型，比如数据清洗、固定格式转换应该用代码完成；需要理解和生成的环节才使用 LLM 节点。

节点之间通过上下文传递数据时，建议维护一份清晰的上下文结构文档，避免字段命名混乱。幂等性同样很重要：同一个任务因为重试被重复执行时，结果应该可预期，比如任务执行前先检查状态位。

日志和可观测性是生产环境的刚需。每个节点至少记录开始、结束、耗时和关键字段摘要，方便快速定位问题。

8.2 钩子与技能设计

钩子要尽量轻量，避免把重量级逻辑塞进钩子导致主流程变慢。钩子内部必须捕获异常，并根据业务选择“继续执行”还是“中断流程”。幂等性也要考虑，例如审计日志钩子重复执行时不应产生多条脏数据。

技能设计上，输入输出 Schema 要尽量精简，字段含义要写清楚。技能包内不要保存密钥，所有敏感配置通过环境变量或配置中心注入。每次修改技能模板后，建议打一个新的版本号，并记录变更说明。

8.3 MCP 服务安全

MCP 服务对外暴露时必须遵守最小权限原则：只开放当前业务需要的工具，不要顺手开放文件读取、命令执行等高危能力。

服务端必须做输入校验和参数边界检查，防止恶意参数造成资源消耗。生产环境建议增加鉴权机制、速率限制和审计日志。远程传输时使用加密连接，敏感数据在日志中脱敏。

对于任何涉及数据库写入、文件删除、生产环境变更的工具，MCP 服务端要增加二次确认机制，并先在测试环境验证。

8.4 生产上线前检查表

• 是否在测试环境完整跑通业务流程？
• 是否有备份和回滚方案？
• 涉及删除、更新操作是否经过授权？
• 密钥和敏感信息是否从代码库中移除？
• 工作流、钩子、技能、MCP 服务是否有日志和监控？
• 核心工具调用是否设置了超时和限流？
• 是否安排专人负责线上告警处理？

9. 学习路径与动手清单

9.1 建议的下一步

如果今天刚开始接触这四个概念，建议按这个顺序动手：

1. 先跑通 MCP 服务 Demo，理解“工具如何被协议暴露”；
2. 再做一个自己的技能文件，把固定模板和参数分离；
3. 给工作流节点加上 before/after 钩子，体会扩展点设计；
4. 最后把前面几步组合成完整的 Agent 工作流。

顺序的理由是先易后难。MCP 服务是最容易获得反馈的环节，技能封装能让你理解复用边界，钩子设计帮助你写出可维护的代码，最后才是工作流编排。

9.2 四个动手任务

• 任务一：给mcp_time_server.py增加一个“查询待办事项”的工具，返回一个固定的列表；
• 任务二：把周报技能改成你自己的日报格式，并增加一个“截止日期”参数；
• 任务三：给第 2 节的工作流增加一个 after 钩子，记录每个任务的关键字列表；
• 任务四：在 GitHub 上找一个 MCP 相关仓库，按第 6 节的评估清单分析后跑通它的 README。

如果这篇文章帮你跑通了第一个示例，可以收藏备用，等后续把四个环节串成完整项目后，再回来对照第 7 节的排查表做一次系统性检查。