用 Claude Code + 飞书 API 搭建双 Agent 数字员工系统

缘起
学校课程要求做一个「数字员工」——能生成 PPT、写文档、辅助完成作业，而且要求两名员工能相互协作，而不是单打独斗。想了几个方案后，最终定下的技术路线是：Claude Code 当大脑，飞书 CLI 当手，跑出了一套响应快、Token 消耗低的双 Agent 协作系统。

系统怎么分工
整体思路很朴素：一个负责"生"，一个负责"审"。
┌─────────────────────────────────────────────┐
│ 数字员工协作组 │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ DE-001 │ │ DE-002 │ │
│ │ 生成员 │───▶│ 审核员 │ │
│ │ │ │ │ │
│ │ PPT 生成 │ │ 内容审核 │ │
│ │ 文档生成 │ │ 格式检查 │ │
│ │ 作业辅助 │ │ 来源验证 │ │
│ └──────┬───────┘ └──────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────────────────┐ │
│ │ 飞书 CLI (lark-cli) │ │
│ │ Slides API │ Docs API │ │
│ └──────────────────────────────┘ │
└─────────────────────────────────────────────┘
DE-001（生成员）：接需求 → 生成内容 → 调飞书 API 建文档/PPT → 甩出链接
DE-002（审核员）：读飞书内容 → 按清单审 → 给修改意见 → 打回给 DE-001

两名员工分别跑在两个独立的 Claude Code 会话里，各自有一份独立的上下文窗口，谁的 Token 消耗都不会拖累另一个。
技术栈很轻
组件 用途
Claude Code Agent 运行环境
飞书 CLI (lark-cli) 调用飞书 Slides/Docs API
飞书开放平台应用 API 认证凭证

搭建过程
安装飞书 CLI、并把技能包接进来：

bash
npm install -g @larksuite/cli
npx skills add https://open.feishu.cn --skill -y -g

创建应用并完成授权：
bash
lark-cli config init --new
lark-cli auth login --recommend

项目结构分得很清楚，DE-002 单独一个子目录，方便独立起会话：
digital-employee/
├── CLAUDE.md # DE-001 配置
├── de002-reviewer/
│ └── CLAUDE.md # DE-002 配置（独立会话）
├── skills/
│ ├── gen-ppt.md
│ ├── gen-doc.md
│ └── homework.md
├── prompts/
│ └── README.md
├── memory/
└── README.md

常用命令速查
PPT 生成，10 页以内一步到位，超过则先建空白再逐页追加：

bash
lark-cli slides +create --as user --title "标题"
--slide @./slide-01.xml
--slide @./slide-02.xml

lark-cli slides +add-slide --as user
--presentation "" --slide @./slide-03.xml

文档生成走管道，把 Markdown 内容直接喂给飞书：
bash
Get-Content draft.md -Raw | lark-cli docs +create
--doc-format markdown --title "标题" --content -

读取与更新：
bash
lark-cli docs +fetch --doc "<链接或ID>"
lark-cli docs +update --doc "" --content @./updated.md

配了几套即用提示词模板，用的时候直接替换括号里的内容就行，比如生成 PPT 就丢一句"生成 PPT：【主题】，【页数】页，要求：【风格】"，审核就丢一句"审核这个：【飞书链接】，重点检查：【范围】"，省去每次重新组织语言的功夫。

Token 控制才是重点
这套系统里花心思最多的其实不是功能实现，而是怎么把 Token 消耗压下去。Claude Code 按 Token 计费，CLAUDE.md 每次对话都会被完整加载进上下文，控制不好很容易烧钱。做了几件事：
配置文件往死里精简。 CLAUDE.md 从 140 行压到 40 行左右，固定开销降了大概六成。教程性的内容全部挪到 skills/ 目录，按需加载，不再随对话常驻。
正文内容不进上下文，走管道直传。

bash
Get-Content draft.md -Raw | lark-cli docs +create --content -
文档正文不会出现在 Claude 的对话历史里，哪怕生成的是长文档，也几乎不额外吃 Token。
双窗口物理隔离。 DE-001 和 DE-002 各自独立起 Claude Code 会话，上下文互不干扰，一个员工的消耗不会拖累另一个。
手册按需读，不预置。 详细的 API 说明通过 lark-cli skills read 现用现查，不塞进 CLAUDE.md 里当摆设。
提示词结构化。 用模板一次性把需求交代清楚，避免来回补充、反复修改造成的隐性 Token 浪费。
怎么跑起来
两个员工各开一个终端：

bash

终端1：DE-001 生成员

cd C:\Users\97429\digital-employee
claude

终端2：DE-002 审核员

cd C:\Users\97429\digital-employee\de002-reviewer
claude

协作流程也很直接：DE-001 生成内容并输出飞书链接 → DE-002 拿到链接读取内容、给出审核报告 → DE-001 收到反馈修改 → 交付最终版本。

效果
测试项 结果
飞书文档创建 ✅ 秒级生成，直接返回可访问链接
飞书 PPT 创建 ✅ 一步多页、分步追加都跑通了
双员工协作 ✅ 各自独立运行，互不干扰
Token 消耗 ✅ 比常规方案省了六到七成
小结

整个项目的思路其实就一句话：Claude Code 负责理解需求、规划结构、质量把控，飞书 CLI 负责实际生成文档和 PPT。靠精简配置、管道传参、双窗口隔离这三板斧，在功能不打折的前提下把 Token 消耗压得很低。一个生成、一个审核，各司其职，跑通了一条从需求到交付的完整链路。