最近频繁地使用 Claude Code，体验非常好，使用 Agent 来工作甚至会让人越来越“上瘾”，短暂离开电脑时，Agent 还在继续工作，经常让人有一种时间没有浪费的感受。
随着模型的能力越来越强，让数十个agent 帮助我们工作会成为一种常态。
只要你有一个SOP，就没有 agent完成不了的工作
如果这样的工作范式成为常态，超级个体将会越来越多。作为一个个体，掌握“最小必要知识”和对某个领域的“品味”，这两个能力将会变得格外重要。——制定一套流程，让Agent 开始工作，然后个体检查结果，判断完成质量。
随着探索地慢慢深入发现 Agent 可以帮助我做越来越多的事。
我又创建了一个帮我干活的 Agent
之前我有一个更新了 50 多期的 Newsletter 「草稿拾遗」，不断更新我的阅读和思考。但后来因为个人精力的原因停止更新了。
**在 Kimi-K2 模型发布以后，
我发现可以借助 ClaudeCode + kimi-K2 系列模型，
通过 Subagent 和 Skills 结合的最佳实践，设计一条 Agent 流水线，节省了 90% 的文章写作时间。
所以我决定恢复了「AIGC 草稿拾遗 Weekly」这份 Newsletter 的更新。
这篇文章，我会分享如何用 Kimi-K2 系列模型，巧妙地使用 ClaudeCode 中的 Skills 和 Subagent 来设计一条 Agent 流水线，来帮我干活儿，也是干货满满。
阅读这篇文章你可以了解到：
让我们开始，首先必须要介绍一下 Kimi-K2 这个系列的模型。
从 7 月份开始，月之暗面团队开源了 Kimi-K2 模型。就已经在多个领域渠道取得了 SOTA。
几个月以来， Kimi 不断在 K2 的基础上迭代，推出了速度更快的版本 kimi-k2-turbo-preview，更适合 Agent 的版本 kimi-k2-o9o5-preview
最近，更是开源了支持深度思考，边思考边使用工具的 Kimi-K2-thinking 版本。在多个 Agent 上取得了 SOTA，超过了 OpenAI 和 Claude。
上面这两张图，是我让 Kimi-K2-thinking 制作的。
截止到目前为止，打开到 Kimi 开放平台的官网，可以看到 K2 系列的多个模型。
可以这么说，Kimi-K2 系列是一个原生就为了 Agent 场景训练的模型。
针对不同的 Agent 场景，我们可以使用不同的模型来处理不同的工作。
而我正在研究一个使用 Agent 来进行自动化写作的项目，而早在 7 月份，我就注意到 K2 系列的写作能力，在创意写作测评集上取得了 SOTA，所以我选择使用 K2 系列来作为我的 Agent 模型。
创意写作排行榜：https://eqbench.com/creative_writing.html
即便四个月过去，K2系列的写作能力依旧名列前茅
ClaudeCode 其实是一个 Agent。
从更广义的AI背景看，Agent是一个非常古老的概念。任何能进行自我决策、与环境交互，并试图optimize reward（优化奖励）的系统，都可以被称为Agent。
而在今天使用最新的大语言模型的背景下，我的理解是：
Agent 在一个「环境」里，按照我们的要求使用「工具」完成「任务」。他可以写代码，可以执行终端命令，可以访问浏览器等等。同时还对我们做过的任务有过「记忆」，是一个真正的助手，而不至于 Copilot。
在最新一代的基座模型中，模型厂商们加入了 React 数据的训练，使得模型可以更好地，连续地使用多个工具，来完成任务。带来了这个新一代的 Agent。
那在 Claude Code 这个 Agent 中：
在 ClaudeCode 中，Agent 的上下文工程被很好地安排，工程也非常棒。可以肯定地说，ClaudeCode 是世界上最好的 Agent
Claude Code 的上下文大概像下面这张图一样：
我将这些概念分为了“上下文”和“工程”两种
上下文概念：
工程概念：
最近 ClaudeCode 发布了新的功能 Agent Skills(技能)
可以看到 claudecode 官方的文档里对 skills 的介绍（https://code.claude.com/docs/zh-CN/skills）
ClaudeCode 官方对 skills 的介绍是：
Agent Skills 将专业知识打包成可发现的功能。每个 Skill 包含一个
SKILL.md文件，其中包含 Claude 在相关时读取的说明，以及可选的支持文件，如脚本和模板。
Skills 的功能介绍就好像他的名字一样，让 Agent 掌握一项技能。
一开始 Skills 发布的时候，大家对于 Skills 和 MCP 的讨论层出不穷。
不懂原理的自媒体外行们，把 Skills 吹得神乎其神。
而懂原理的行内人，也一直在想 Skills 和 MCP 之间的关系是什么？
我同样也有这样的困惑，但经过一段时间的研究以后，读了很多文章，并且在本地实践以后，我慢慢理解了为什么会有 Skills 的存在。
今天就让我尽量直白地给你讲明白，什么™的叫「Skills」
我们看到 Skills 的文档介绍，当你创建一个 Skills 的时候。实际上会有这样的几个文件：
├── SKILL.md (required) - 技能描述
├── reference.md (optional documentation) - 参考文档
├── examples.md (optional examples) - 使用案例
├── scripts/
│ └── helper.py (optional utility) - skills 里可以运行的代码脚本
└── templates/
└── template.txt (optional template) - skills 的模板而在 skills.md 的内容模板如下：
---
name: your-skill-name
description: 简要描述该技能的作用以及何时使用它
---
# Your Skill Name
## 指令
为 Claude 提供清晰、一步一步的指导。
## 使用案例
展示使用这个 Skills 的具体示例。内容的顶部，有像 Obsidian 的 yaml 属性一样的一个 skills name 和 description，描述里说明了在什么时候使用 skills，使用 skills 能达到的效果等。在 yaml 属性下方，才是对 skills 的完整描述。
在传入上下文的过程中，在不使用 skills 时，只有 skills name 和 description 会传入上下文中。当需要使用 skills 时，ClaudeCode 才会将完整的 skill.md 文件传入上下文中，让模型更好的执行技能中的操作。
所以 Skills 本质上是一种上下文工程的策略 - 上下文卸载
上下文工程的五种策略：
- 卸载：将上下文的结果，转换到环境中。
- 压缩：总结上下文
- 检索：通过检索的方式来补充上下文，常见的例如 RAG
- 隔离：独立的小任务，让特定的 subagent 去执行；
- 缓存：使用 kv cache 技术来减少token 消耗
要理解上下文工程的策略，首先我们要理解：模型的注意力
模型的注意力并不总是可以持续关注每一个 token 的，因为 Transformer 的原理限制，没多一个 token，推理的成本都会平方级的增长。
所以，虽然现在的模型，经常会有 128k 256k 甚至 1M 的上下文窗口，但随着上下文越来越长，模型的效果也会越来越差。
简单可以理解为：上下文太多的话，模型的脑子过载了，算不过来了。
并且模型的注意力并不是匀速下降的，而是在一个有限的范围内能够保持较好的水平的，而在超过一定范围后，模型可能就会随机在窗口中丢失一部分信息。
这在单轮调用的场景中还可以接受，例如我经常会传一个特别长的文件给到 gemini-2.5 系列的模型，他们支持 1 million 的上下文窗口，然后让模型提取出一些信息，往往效果都还是不错的。
但是在 Agent 的场景里，需要多轮地进行 React 和 Reflexion 的使用场景来说，这是非常灾难的。上下文窗口越长，模型就越容易犯错。
于是，在当前技术的限制下，为了解决这个问题，ClaudeCode 推出的方案就是—— Skills 。
通过我自己的案例来让你更好的理解为什么 ClaudeCode 一定需要 Skills.
在上一篇文章《当 Obsidian 遇上 ClaudeCode》的文章中，我开源了我的 Claude.md 文件，文件定义了以下几个部分
https://github.com/liaocaoxuezhe/Obsidian_ClaudeCode_Prompt/blob/main/CLAUDE.md
- 启动的插件
- 文件目录结构
- 常见的任务及其描述
- 模板使用说明
- Templater 使用说明
- Base 数据库说明及使用案例
- 开发说明
- 最佳实践这个文件洋洋洒洒加起来有 2000 多个字。
Claude.md 是每次都会带到上下文窗口中，但其实大量的内容，不是每一次都会使用到的。我并不是每一次操作都需要使用模板，都需要使用 Base 数据库，都需要使用 Templater。
所以为什么不把这些内容从上下文工程里面卸载下来呢？ 只在需要用到他们的时候使用。
上一期文章的 Claude.md，在有了 Skills 这个新能力以后。我们就可以把 templater 、base、模板等的使用方法，包装成一个 skills，这样就精简了上下文，保证了在执行多轮任务时，模型的回复效果。
Subagent 同样是 ClaudeCode 中一项非常精美的设计。
常规的 Agent 在执行任务时，流程是这样的
- 系统提示词
- 思考
- 执行
- 观察（这是一个React 循环）
...
- 思考
- 执行
- 观察
...
- 思考
- 执行（可能会调用工具）
- 观察（观察结果和环境）
...
直到执行完成任务或者需要人类确定时，停止任务通过这个图，你可以明白 Chat 和 Agent 最大的差别，在于单轮 vs 多轮。
在 Agent 的工作流里，模型天生就是多轮地进行的。
Agent 就好像一个更好的实习生，一点就通，可以连续地完成一项任务。
但问题就在于，当多轮调用不断地累计以后，上下文窗口每一次都会增长，计算难度每次都会指数级地上升，达到一定的窗口时，模型的表现一定会变差，会带来错误的结果。
于是聪明的你就想到，既然这样的话，为什么不把专门的活儿交给专人干，充分发挥大家的“比较优势”呢？
所以就有了 Subagent，可以把一项独立的任务交给一个 Subagnt 去干，这个 Subagent 只负责独立地把这件事干成，不共享其他人的上下文。
于是我们就可以把 Agent 的工作流做成一条流水线
- 系统提示词
- 思考
- 执行
- 观察
-> (这活儿 Subagent1 去干吧)
- 思考
- 执行
- 观察
<- (哥，我干完了)
-> (接下来让 Subagent2 去干吧)
- 思考
- 执行
- 观察
<- (哥，我干完了)
- 观察
- 执行
(不错不错，汇报给我的领导(人类))Agent 和 Subagent 的通信，很类似与人与人之间的通信，在工作中，你想要让同事做什么事，都需要将他需要的“上下文”传输给他，然后他再给你一个结果。
假设我们今天招了一个专门做会议纪要的 subagent，他就只负责干会议纪要这一件事。
好吧，虽然在现实世界里，我们可以招很多人做不同的工作。但在模型这里，其实干活的就只有模型一个“人”。
模型只能...做完你的做你的...做完你的做你的...
现在开始介绍我使用 ClaudeCode Skills Subagent 和 Kimi-K2 系列模型构建的创作流水线
草稿拾遗 Newsletter 的内容分为以下几个模块
过去，我要写作一片 Newsletter，我的工作流程是这样的：
因为我有一套完整运行了多年的阅读工作流《我的阅读工作流 2021 版》，我的阅读，划线、批注和思考。最终都能够被记录下来。
而基于这些内容，我就可以让 Agent 去模仿我之前的写作风格，创作内容。
基于 ClaudeCode 的特点，和 Kimi-K2 的特性，我设计了一套 Agent 的工作流程：
这里面最重要的洞察是：
如果我们把 Skiills 放在 主 agent 中，当然也有些作业，但这和之前的自己写 prompt 的区别并不大。但如果把 Skills 放在 Subagent 中，却产生了 1+1>2 的效果，产生了奇妙的化学反应，非常妙。
所以我先是用 AI ，按照 ClaudeCode 的要求创造了一个 skills
这个 skills 的文件架构是像下面这样的
├── SKILL.md - 技能的说明文件
├── examples.md - 技能的使用案例
├── main.py - 技能的主脚本
├── reference.md - 技能的使用参考说明
├── requirements.txt - 必须的依赖项
└── scripts - 脚本
├── jike_exporter.py - 爬取即刻中里我发布的动态
├── notion_exporter.py - 从 notion 中导出 flomo 的笔记
├── readwise_articles_exporter.py - 导出 reader 中的文章列表
└── readwise_highlights_exporter.py - 导出 readise 中的高亮和批注这里面最重要的是，分别写了从 flomo、即刻、readwise、reader 中到处内容的脚本。
在 skills.md 里说明了。让模型使用这些脚本导出文件，并保存到制定的文件架构。
再创建了一个 Subagent 专门用来执行这个技能，同时指定了这个 subagent 使用 kimi-k2-turvo-preview 这个模型来使用这个 skills。
因为这个工作流程中，比较多都是代码的工作，工作流程也比较固定，适合使用速度又快，又适合 coding 的 kimi-k2-turbo。
同样地又创建了另外一个专门用来生成大纲的 skills
├── SKILL.md - 技能的说明文件
├── assets
│ └── article_template.md - 文章模板
└── references
├── content_analysis.md - 内容分析方法
└── writing_guide.md - 大纲写作风格指导这个 skills 简单，主要是让模型，充分地阅读上一步生成的参考内容，然后分析内容，按照大纲的写作风格指导写作大纲。
同样的，把这个 skill 交给另外一个 Subagent 来完成。Subagent 最终会输出一份大纲，保存到文件系统中。
因为在这个过程中，流程是不固定的，需要大量的阅读和思考，所以我选择使用 kimi-k2-thinking 或者 kimi-k2-thinking-turbo 来完成这项工作。
到最后写作的阶段，回到 主 agent 的视角。
主 agent 只做了几件事：
现在就来到了主 agent 的主场，给定好参考内容和大纲，写作文章对于 Kimi K2 是非常简单的事情。而且上下文中，并没有冗余的地方，所以模型完成得非常漂亮。
回过头来看，如果这四个步骤，都发生在同一个 agent 中，将会带来大量的无用上下文积累。其中第二步中，导出内容的大量上下文，大量的流程积累的数据，对于写作文章，都是我没有帮助的，甚至有负面的影响。
所以经过这样的设计。
大家都有美好的未来。
在我演示的这个任务中，其实只是个人项目中一个稍微复杂的项目。
未来 Agent 如果更加复杂的环境，如何设计好上下文工程，会有更多的挑战。而 Subagent 和 Skills 将会有更多用武之地。
Subagent 的应用场景还有更多，我们在这个项目中使用 Subagent，是并行地让 Subagent 来处理转移的任务。而在 Manus 的 wide research 中，Manus 是横向地并行地调用多个 Subagent 来执行检索任务，在不同的场景可以使用不同的思路。
https://manus.im/zh-cn/features/wide-research
下面，让我在我的 ClaudeCode 里输入指令，给你演示这个任务。
并且我将在文章发布后的两天发布由这次任务生成的 Newsletter，可以关注我的公众号，期待一手。
#任务
## 第一步
在 '草稿拾遗' 中逐个创建下面的文件夹结构。
文件夹的结构是
```
草稿拾遗最新一期/
├── 参考内容/
│ ├── flomo/
│ ├── article_list/
│ ├── highlights/
│ └── jike/
├── 文章大纲/
└── 文章正文/
```
## 第二步，让子代理 newsletter_reference_export_agent 导出 2025-10-27 ~ 2025-11-02 的内容到 参考内容 下方的分别三个文件夹中
## 第三步，让子代理 outline_creator_agent 来生成大纲
- skills 需要输入参考内容，在 '草稿拾遗/草稿拾遗最新一期' 中
- skills 会需要大纲输出到 '草稿拾遗/草稿拾遗最新一期/文章大纲'
## 第四步，按照这个大纲，在[参考内容]文件夹中查看相关的知识，然后按照 '草稿拾遗/草稿拾遗写作风格指南.md' 的写作要求，完成最新一期草稿拾遗 newsletter 的写作。模型先是创建了一个文件架构，然后开始调用 Subagent1 来导出参考内容
模型导出内容后，会保存一份导出报告。
然后再执行下一步，在写大纲时，一开始主 agent 直接调用了生成模型的skills，但是非常有意思的是，因为 Kimi-K2-thinking 具备思考的能力，如果有一些步骤执行错误，他会反思后走回到正确的路线上。
最后，模型模型生成了大纲，并生成了 Newsletter 的初稿
最后看到我们的文件系统
├── 参考内容
│ ├── article_list
│ │ └── articles_list.md
│ ├── flomo
│ │ └── （此处省略 N 条笔记内容）
│ ├── jike
│ │ └── jike_post_20251112_191121.md
│ └── 导出报告.md
├── 文章大纲
│ └── outline.md
└── 文章正文
└── newsletter.mdNewsletter 的局部如下
最后我只要根据里面的内容进行编辑，加入我自己的理解和表述。
就可以发布文章了。
截图中的这篇文章，也会在明天发布。
如果你想要关注我在 AI 领域每周最新的思考，我正在阅读的最前沿的内容，欢迎关注我的公众号。
感谢 ClaudeCode 和 Kimi-k2-thinking，让我复活了我的 Newsletter「AIGC 潦草拾遗」!
最后，我们讲一下如何在 ClaudeCode 中使用 Kimi。
ClaudeCode 虽然是 Claude 创建的 Agent 工具，但也可以使用其他厂商的模型。
在 Kimi 的官方文档中说明了我们如何在把 ClaudeCode 中的文档切换成 Kimi
https://platform.moonshot.cn/docs/guide/agent-support
如果你只需要固定使用一个模型的话，可以参考官方文档中的操作步骤，通过下面这段命令行修改环境变量后再开启 ClaudeCode 即可:
# Linux/macOS 启动高速版 kimi-k2-turbo-preview 模型
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
export ANTHROPIC_AUTH_TOKEN=${YOUR_MOONSHOT_API_KEY}
export ANTHROPIC_MODEL=kimi-k2-turbo-preview
export ANTHROPIC_SMALL_FAST_MODEL=kimi-k2-turbo-preview
claude
# Windows Powershell 启动高速版 kimi-k2-turbo-preview 模型
$env:ANTHROPIC_BASE_URL="https://api.moonshot.cn/anthropic";
$env:ANTHROPIC_AUTH_TOKEN="YOUR_MOONSHOT_API_KEY"
$env:ANTHROPIC_MODEL="kimi-k2-turbo-preview"
$env:ANTHROPIC_SMALL_FAST_MODEL="kimi-k2-turbo-preview"
claude而如果你想要像我一样，自定义地使用不同的模型。
则要分成两步骤
第一步，修改 .claude 中的 config.json文件，在里面加入不同模型对应的 kimi 模型
{
"permissions": {
"allow": [
"Bash(cat:*)"
],
"deny": [],
"ask": []
},
"env": {
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k2-turbo-preview ",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k2-thinking-turbo",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k2-thinking"
}
}第二步，使用命令行修改环境变量后再启动 claude
# Linux/macOS 启动高速版 kimi-k2-turbo-preview 模型
export ANTHROPIC_BASE_URL=https://api.moonshot.cn/anthropic
export ANTHROPIC_AUTH_TOKEN=${YOUR_MOONSHOT_API_KEY}
claude
# Windows Powershell 启动高速版 kimi-k2-turbo-preview 模型
$env:ANTHROPIC_BASE_URL="https://api.moonshot.cn/anthropic";
$env:ANTHROPIC_AUTH_TOKEN="YOUR_MOONSHOT_API_KEY"
claude现在 Kimi 也推出了 Kimi 全家桶活动。
购买 Kimi 的会员，就可以在各个场景畅快地使用 Kimi-K2 系列模型。
而且最近 kimi 还出了一个很有意思的的砍价活动，通过 Kimi 官网的砍价活动进入聊天页，和 kimi 聊天，像是菜市场砍价一样和他聊天，就可以把价格打下来。
最低可以 0.99 月开通首月的会员。
我就通过这个方式订阅了 Kimi Andate，你也可以试试。
好的，这篇文章到这里结束。
简单回顾下
这套 Agent 流水线，表面上只是复活了我的 Newsletter。但往后面想随着 Agent 和模型技术的发展。让数十个agent 帮助我们工作会成为一种常态。沿着这个思路出发，或许你应该思考的是，现在你的什么工作，是可以直接使用 Agent 来完成的呢？
希望听到你的想法。
文章中演示的文章，经过笔者微调后，将在近期发布，欢迎关注我的公众号，期待这篇 AIGC 生产，人类微调的内容。
如果这篇文章对你有帮助的话，请给我的文章点赞，在看，或是转发给你觉得需要的朋友。现在微信中的公众号，上新了内容推荐算法，对创作者的文章阅读和转发比例有了更大的要求，希望可以多帮点点转发，感谢。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。