月之暗面把自家全员在用的本地 Coding Agent——Kimi Code——做成了更通用的底座，往上叠加金融、科研、办公等场景的 Skill，打包成 Kimi Work Beta 推向公测。这意味着"本地 Agent"不再只是程序员专属的工具，而是任何知识工作者装上客户端就能跑起来的生产力入口。
Kimi Code：从编程 Agent 到通用底座
Kimi Code 是整个系统的内核。它每天服务几十万程序员，也支撑着 Kimi 团队自身的日常开发。核心能力有三层：
- 本地执行——Agent 直接在你机器上操作文件、终端、浏览器，不依赖远端沙箱。
- Skill 安装与调用——类似插件机制，一个 Skill 封装了一组动作和上下文，Agent 按需加载。
- 任务编排——多步骤任务拆解、执行、纠错，全程可观测。
Kimi Work 把这三层能力从"写代码"这个单一场景抽出来，面向更广的知识工作流：读论文、做数据清洗、写研报、处理表格……底层执行逻辑不变，只是 Skill 的领域变了。
Skill 机制：Agent 的"手艺"怎么装上去
Skill 是 Kimi Work 最关键的概念。一个 Skill 大致包含：
| 组成部分 | 作用 |
|---|---|
| 入口描述 | 告诉 Agent 什么时候该调用这个 Skill |
| 动作序列 | 具体执行步骤（打开文件、调用脚本、写输出等） |
| 上下文模板 | Skill 运行时需要的参数和格式约定 |
| 依赖声明 | 需要哪些本地工具或 Python 包 |
Agent 在收到用户指令后，会先判断需要哪些 Skill，再按顺序组装执行。用户也可以手动安装或卸载 Skill，类似 brew install 的体验。
下面用一个虚构但结构合理的 Skill 定义文件，展示这个机制的大致形态。实际格式以 Kimi Work 官方文档为准，此处仅为理解框架的参考：
# skill-research-paper.yaml — 示例 Skill 定义（结构参考，非官方格式）
name: research-paper-summary
version: 0.1.0
description: "读取本地 PDF 论文，提取摘要、关键图表和引用关系"
trigger:
keywords: ["论文", "paper", "arxiv", "摘要", "文献"]
file_types: [".pdf"]
actions:
- id: extract_text
tool: pdf_parser
params:
input: "{{ user.file_path }}"
output_format: markdown
- id: summarize
tool: kimi_llm
params:
prompt: |
请对以下论文内容生成结构化摘要：
1. 研究问题
2. 核心方法
3. 主要结论
4. 局限性
论文内容：
{{ extract_text.output }}
- id: save_result
tool: file_writer
params:
path: "{{ user.file_path | replace('.pdf', '_summary.md') }}"
content: "{{ summarize.output }}"
dependencies:
tools:
- pdf_parser >= 0.3
- kimi_llm
python_packages:
- pymupdf >= 1.23
这个 YAML 描绘了一条完整链路：解析 PDF → 调用 LLM 生成结构化摘要 → 写回本地文件。{{ }} 模板变量由 Agent 在运行时填充，动作之间通过输出引用串联。
实际上手：从安装到跑通一个任务
Kimi Work 目前随 Kimi 最新测试版客户端发布，Mac 和 Windows 均可获取。基本流程：
# 1. 下载并安装 Kimi 客户端（测试版）
# Mac: https://kimi.moonshot.cn/download 选择 Beta 通道
# Windows: 同页面选择 Windows Beta 安装包
# 2. 启动客户端后，在设置中开启 "Kimi Work" 功能开关
# 3. 安装一个 Skill（假设未来支持 CLI 管理，此处为示意命令）
kimi-work skill install research-paper-summary
# 4. 在客户端对话窗口输入任务
# 例：请帮我总结 ~/Papers/attention-is-all-you-need.pdf 这篇论文
Agent 会自动匹配 research-paper-summary Skill，依次执行解析、摘要、保存，最终在对话窗口返回结果，同时在本地生成 _summary.md 文件。
如果你更习惯用 Python 脚本批量处理，可以借助 Skill 的底层工具单独调用。以下是一个脱离 Agent 编排、直接用 pymupdf 做 PDF 文本提取的独立脚本——即使不用 Kimi Work，这段代码也能跑：
# pdf_extract.py — 独立可运行的 PDF 文本提取脚本
# 安装依赖：pip install pymupdf
import fitz # pymupdf
import sys
from pathlib import Path
def extract_pdf_text(pdf_path: str, output_path: str | None = None) -> str:
"""提取 PDF 全文文本，可选保存为 Markdown 文件"""
doc = fitz.open(pdf_path)
pages = []
for page_num, page in enumerate(doc, start=1):
text = page.get_text("text")
if text.strip():
pages.append(f"## 第 {page_num} 页\n\n{text}")
doc.close()
full_text = "\n\n".join(pages)
if output_path:
Path(output_path).write_text(full_text, encoding="utf-8")
print(f"已保存到 {output_path}")
return full_text
if __name__ == "__main__":
if len(sys.argv) < 2:
print("用法：python pdf_extract.py <pdf路径> [输出md路径]")
sys.exit(1)
pdf_file = sys.argv[1]
out_file = sys.argv[2] if len(sys.argv) > 2 else None
result = extract_pdf_text(pdf_file, out_file)
# 打印前 500 字预览
print(result[:500])
# 运行示例
python pdf_extract.py ~/Papers/attention-is-all-you-need.pdf ~/Papers/attention-is-all-you-need_text.md
这段脚本做的事情，就是 Skill 里 extract_text 动作的简化版。理解了这一层，你就知道 Skill 不是魔法——它只是把"工具调用 + LLM 推理 + 文件操作"串成了一条声明式流水线。
本地 Agent 的边界与取舍
Kimi Work 选择"本地"而非"云端沙箱"，带来几个直接后果：
优势： - 数据不出本机，金融研报、内部文档等敏感内容不用上传。 - 可以直接读写本地文件系统、操作终端，不需要虚拟化中间层。 - 响应链路短，没有远程队列等待。
代价： - 本地环境差异大——操作系统、Python 版本、依赖包都可能不一致，Skill 的兼容性测试负担重。 - 本地资源有限——大模型推理仍需云端 API 支持，"本地 Agent"的"本地"指的是执行环境，不是模型权重。 - 安全风险反转——Agent 能操作本地文件和终端，权限控制必须谨慎，否则误操作代价比云端沙箱高得多。
什么时候值得试
如果你符合以下任一场景，现在就可以装 Beta 客户端体验：
- 金融分析师——每天处理大量 PDF 研报、Excel 数据，需要快速提取关键数字和结论。
- 科研人员——arxiv 论文批量阅读、实验数据清洗、文献综述草稿生成。
- 开发者——已经在用 Kimi Code 写代码，想把同样的 Agent 体验延伸到文档、运维等非编码任务。
试用时建议先从低风险任务开始：让 Agent 处理一份公开 PDF、整理一个 CSV，确认 Skill 执行链路正常后再逐步扩展到敏感文件。同时留意客户端的权限提示——Agent 请求写文件或执行命令时，手动确认比自动放行更安全。
Kimi Work 的公测是一个信号：本地 Agent 正从"程序员玩具"走向"知识工作者工具箱"。Skill 生态是否丰富、执行是否稳定、权限是否可控，将决定它能不能从 Beta 走到日常。