Kimi Writing Agent：让 AI 自己写完一部小说

想象这样一个场景：凌晨两点，你突然有了一个绝妙的故事灵感——一个发生在维多利亚时代的侦探故事，十章，从伦敦雾都的阴暗街巷到白金汉宫的舞会暗流。你想把它写出来，但第二天还要上班，坐到电脑前时灵感已经模糊了大半。

Kimi Writing Agent 就是来解决这个问题的：给它一个写作指令，比如「写一部发生在维多利亚伦敦的悬疑小说，十章」，然后你可以去睡觉了。醒来后，一部完整的小说已经躺在你的文件夹里。

这不是天方夜谭。这是 Doriandarko/kimi-writer 正在做的事——一个基于 kimi-k2-thinking 模型驱动的自主写作 Agent，目前在 GitHub 拥有 572 颗星，被开发者社区称为「最接近真正 AI 小说家的开源工具」。

一、技术起源：从「AI 能不能写小说」到 Agentic Loop

在 Kimi Writer 出现之前，AI 写作工具面临一个根本矛盾：

短内容强，长内容弱。 让 ChatGPT 写一段对话、一封邮件，它比大多数人都强。但让它写一部 10 万字的小说？它会在第 3 章就开始重复自己，第 5 章彻底崩溃，原因是模型上下文窗口（Context Window）有限，长篇小说需要维持的人物设定、世界观、情节逻辑远远超出了 AI 的「记忆」容量。

Doriandarko（项目作者）从 Kimi API 的 200,000 token 上下文窗口中看到了可能性。200k token 约等于 15 万汉字——足以容纳一部中篇小说的全部上下文。但这需要一个前提：必须有一套机制，让 AI 在这个巨大的上下文中始终知道自己「在哪里」「要做什么」「还剩多少」。

这就是 Agentic Loop（智能体循环）架构的核心思路。Kimi Writer 的工作流如下：

1. 接收指令：用户给出一个写作任务
2. 规划与执行：Agent 调用 kimi-k2-thinking 模型进行深度推理，决定下一步调用哪个工具
3. 工具调用：Agent 可以调用三个内置工具——create_project（创建项目文件夹）、write_file（写 markdown 文件）、compress_context（压缩上下文）
4. 循环迭代：最多 300 次迭代，每次迭代 Agent 都会评估当前进度，直到任务完成
5. 上下文管理：在 token 消耗达到 180,000（90%）时自动触发压缩，将之前的内容总结为摘要，释放空间继续写作

这套流程看起来简单，但实现细节中藏着大量工程挑战。最关键的一点是：写作过程中 AI 的输出既是内容又是元数据——它需要同时生成故事情节、记录自己在做什么、评估质量、决定下一步。这个「三重任务」在没有精心设计的 Prompt 和工具链的情况下，极容易导致 AI 陷入重复或跑偏。

Kimi Writer 通过三个精心设计的工具和一个状态管理系统解决了这个问题。

二、核心架构：三个工具撑起的写作流水线

2.1 工具一：create_project —— 项目生命周期管理

这个工具负责在 output/ 目录下创建项目文件夹（默认以项目名命名，自动清理特殊字符），并维护一个全局状态变量 _active_project_folder，确保后续的 write_file 操作都落在正确的目录里。

一个典型项目结构如下：

output/
├── my_victorian_mystery/    # 由 Agent 创建
│   ├── chapter_01.md        # Agent 逐章写出
│   ├── chapter_02.md
│   ├── chapter_03.md
│   └── .context_summary_20250107_143022.md  # 自动备份的上下文摘要
└── another_project/

每个项目文件夹中的 .context_summary_*.md 文件是 Kimi Writer 的「断点续传」机制的核心。

2.2 工具二：write_file —— 三模式文件写入

write_file 支持三种写入模式，设计极为精妙：

• create：创建新文件，如果文件已存在则报错。这防止 Agent 意外覆盖已有的章节。
• append：追加内容到现有文件末尾。Agent 可以在一个章节内多次追加，逐步完善内容。
• overwrite：覆盖整个文件内容。用于 Agent 需要重构某个章节的场景。

这套设计对应了真实的写作流程：先创建章节文件，然后逐步追加内容，如果需要修改则覆盖重来。

2.3 工具三：compress_context —— 上下文蒸馏引擎

这是整个项目最具技术含量的部分。当对话历史超过 180,000 token 时，Agent 会调用这个工具：

1. 分离系统消息、待压缩历史消息、近期消息（保留最近 10 条）
2. 调用 Kimi API，将所有待压缩历史消息浓缩为一个摘要
3. 将摘要写入时间戳命名的 .context_summary_*.md 文件
4. 用摘要替换压缩掉的历史消息，释放上下文空间

压缩后的上下文仍然保留了故事的完整「地图」——人物关系、世界观设定、已发生的情节节点。新生成的内容会自然地延续之前的叙事方向，不会出现「失忆」现象。

三、技术栈与代码质量

Kimi Writer 的技术栈极为精简，只有三个生产依赖：

openai>=1.0.0        # OpenAI SDK，兼容 Moonshot API
httpx>=0.24.0        # HTTP 客户端，用于 token 计数 API
python-dotenv>=1.0.0  # .env 文件读取

这种极简依赖策略值得称道——没有 LangChain，没有 LangSmith，没有复杂的编排框架。用最少的抽象层，直接调用 Moonshot API 的 /chat/completions 和 /tokenizers/estimate-token-count 两个端点，实现了一个完整的 Agent 系统。

主文件 kimi-writer.py 约 400 行，utils.py 约 200 行，tools/ 目录三个文件各司其职。代码风格统一，类型注解完整，Docstring 覆盖了所有公开函数。测试覆盖方面，项目没有包含测试套件，这是目前最大的改进空间。

架构上，kimi-writer.py 是唯一的入口文件，包含主 Agent 循环和 CLI 参数解析；utils.py 提供 Token 计数、工具定义和 System Prompt；tools/ 目录是工具注册和实现。这种单入口 + 模块化工具的架构，非常适合学习 Agent 开发。

四、使用体验：实时流式输出的魅力

Kimi Writer 最令人惊艳的体验是它的实时流式输出。

当你运行 uv run kimi-writer.py 后，你会看到三个流同时输出：

1. 🧠 Reasoning 流：Agent 的思考过程实时显示——它在想什么、为什么选择这个情节走向、当前章节和整体故事的衔接逻辑
2. 💬 Content 流：故事正文逐字出现，就像看一个真实作家在打字
3. 🔧 Tool Call 流：当 Agent 调用工具时，显示进度（chapter_01.md: 1,234 characters）

这三种输出用不同颜色和前缀区分，用户可以随时看到 Agent「脑子里在想什么」，而不是只能看到最终结果。这种透明性对于调试 Prompt 和理解 AI 行为模式非常有价值。

另一个亮点是恢复模式（Recovery Mode）。运行 python kimi-writer.py --recover output/my_project/.context_summary_20250107_143022.md，Agent 会从上次保存的上下文摘要恢复，继续之前的工作。断电、程序崩溃、网络中断都不影响写作进度。

五、局限与争议：Agent 真的能写好小说吗？

尽管 Kimi Writer 在技术上令人印象深刻，但它也面临 AI 写作的共同困境：

情节一致性问题：在超长文本生成中，Agent 仍然可能出现人物设定漂移（某章主角的性格和前面明显不一致）。kimi-k2-thinking 的推理能力能显著缓解这个问题，但无法彻底消除。

创意同质化风险：当 Agent 被训练出「最有效」的写作模式后，生成的故事可能会趋向同质化——类似的情节转折、相似的人物弧线。对于追求独特文学表达的创作者来说，这可能是个顾虑。

API 成本：200,000 token 的上下文窗口意味着每次 API 调用的成本较高。一部 10 章小说的生成可能需要多次完整的上下文传递。

无版本管理：Agent 写入的章节文件没有内置的版本控制，如果 Agent 决定重写某一章，之前的版本会丢失。需要用户自己维护备份。

六、行业意义：长文本生成的 Agent 范式

Kimi Writer 的价值不仅在于它能写小说，更在于它验证了长文本生成的 Agent 范式是可行的：

• 300 次迭代上限：通过设置最大迭代次数，防止 Agent 陷入死循环，同时给用户一个可预期的运行时间
• 显式工具设计：每个工具（创建项目、写文件、压缩上下文）都有清晰的语义边界，Agent 可以准确地选择工具
• 自动备份 + 恢复：将中间状态持久化为文件系统，用户体验从「一气呵成」变为「可中断、可恢复」
• Token 监控：实时显示 token 消耗，让用户对 AI 的「记忆容量」有清晰的感知

这些设计理念已经被后续的多个长文本生成项目所借鉴，形成了「上下文管理 + 工具调用 + 状态持久化」的标准 Agentic 写作架构。

七、部署与上手

Kimi Writer 是一款纯 Python CLI 工具，无需 Docker，无需 GPU，直接 pip install -r requirements.txt 即可运行。

唯一的配置是创建一个 .env 文件，设置 MOONSHOT_API_KEY（从 Moonshot 控制台获取）。也可以通过 MOONSHOT_BASE_URL 配置自定义 API 地址。

适合用户：

• 有大量写作需求的内容创作者（小说、书籍、技术文档）
• 想研究 Agent 系统开发的 AI 工程师
• 需要批量生成格式化文本（如营销文案、产品描述）的运营人员

不适合：需要图形界面、实时协作或云端托管的用户。

---

总结：Kimi Writing Agent 是长文本 AI 生成领域的一个里程碑式项目。它用最精简的技术栈（纯 Python + Moonshot API）实现了一个功能完整的自主写作 Agent，验证了「上下文管理 + 工具调用」模式在创意写作场景下的可行性。对于开发者而言，它的代码结构清晰、依赖极简，是学习 Agent 系统设计的优秀参考；对于写作者而言，它提供了一个真正「放手让它写」的 AI 搭档——你给出方向，AI 负责执行。