Yige
aec2e7c28b
## 概述 / Overview 两件事：新增「企业微信助手」Agent（自带 15 个技能），并修正 `wecom-cli` 条目钉在 6 月快照的 ref 漂移。 Two changes: adds the **WeCom Assistant** agent (bundling 15 skills), and fixes the `wecom-cli` entry whose pinned ref was stuck on a June snapshot. ## 1. 新增企业微信助手 Agent 覆盖企业微信 **14 类服务、95 个方法**：消息、群聊历史、通讯录、日程、会议、待办、邮件、在线文档、在线表格、智能表格、智能文档、文档管理、微盘、媒体文件。 **采用内联形态 + 自带私有技能**：Agent 安装对 `agents/<id>/` 整目录递归复制且 `skills/` 不在排除集合里，因此装 Agent 即带全部技能，用户无需再单独获取技能合集。 ### 技能集（15 个，约 5000 行） - 基于上游 [wecom-cli](https://github.com/WecomTeam/wecom-cli) 官方 Skill（MIT，© WecomTeam）改写，每个技能末尾保留归属声明 - **新增 `wecom-chat`**：补齐上游零覆盖的群聊历史读取 - 补齐上游未覆盖的 `message.send`、`doc.create`，方法覆盖达 **95/95** - 修正上游三处文档漂移：邮件能力描述与实际相反、会议室参数名已过时、`title_highlight` 字段不存在 ### 相对上游的核心增量：风险治理 - 26 个对外可见或不可逆的方法逐个写明**执行前确认要求** - 4 个条件升级方法给出**参数级判据**，而非按方法名一刀切 - 文档权限扩散两项加重处理，涉及**企业外可见**时单独再确认一次 - 内部标识禁止外露，不因用户索要而放宽 - 拒绝导出可识别到具体自然人的隐私字段 ### 三条真机实测得出、上游未覆盖的硬约束 1. 机器人**只能写入/修改自己创建的数据**，真人创建的只能读 2. 每次响应携带的 `extra_identity_context` **禁止透露给用户** 3. 权限错误（`850002`/`851008`/`853006`）**不得重试**，须将 `help_message` **逐字原样**转给用户 ## 2. 修正 wecom-cli 条目 ref 漂移 `source.ref` 原钉在 2026-06-28 的 `72e14f7`，该快照只有 7 个子技能且用已废弃的旧命名（`msg`/`schedule`）。上游 v1.2.0 已扩展到 **14 个**技能。按旧 ref 安装的用户拿到的是三个月前的快照。 - `source.ref` → `78c514b2afee7c0d3d7be715628478421f37ee63` - `children` 由 `scripts/gen-collection-children.py` 重新生成，**7 → 14** - sidecar 同步 `provenance.content.ref`、`childCount` 与 `children` ## 验证 / Verification **静态** - 215 条示例命令追加 `--dry-run` 实跑，**215/215 退出码 0** - 未知方法 0、未知参数 0、`--json` 未知字段 0、枚举违规 0 - 15 个 `SKILL.md` 的 frontmatter 经客户端 `skillFrontmatterSchema` 校验全部通过 - `validate_catalog_metadata.py --require-complete` 与 `gen-collection-children.py`：**0 error** **真机（在真实企业微信账号上端到端）** - **待办域 6/6 方法全通**（含 2 个 write-high），`items` 必填的隐蔽坑实测证实 - **日程域 5 个方法全通**（含 3 个 write-high） - 消息发送、通讯录解析、微盘列表、邮件搜索、文档搜索、会议列表、智能表格创建均已实测通过 - 测试数据已全部清理，未污染真实账号 **尚未实测**：群聊历史（机器人未开通该品类）。相关文档已明确标注验证状态，未实测的能力不写「实际效果」段落。
7.7 KiB
在线文档
企业微信的 Word 类在线文档：新建、把本地 .docx/.doc/.txt 传上去变成在线文档、读正文、 往末尾追加内容、整篇覆盖。只管一份文档里的文字——文档叫什么名字、谁能看， 归 13 文档管理。
注意路由：你只说「写个文档 / 整理成文档 / 输出到文档」而没指明类型时，
默认落到 12 智能文档，不是这里。要用这一域，得明确说「Word 文档」「在线文档」「docx」，
或者给出一个 /doc/ 开头的文档链接。
你可以怎么说
「给我建个 Word 文档写周报」 「新建一个在线文档」 「把这份 docx 传到企微上」 「这份文档写了什么？」 「在这个文档里再加一段：今天完成了联调」 「把这个文档整个重写」
📋 验证状态
| 项 | 状态 |
|---|---|
| 创建在线文档 | ✅ 已实测 |
| 向文档末尾追加内容 | ✅ 已实测 |
| 读取文档正文 | ✅ 已实测，读回内容与写入完全一致 |
| 导入本地 .docx / .txt | ⚠️ 未实测 |
| 整篇覆盖正文 | ⚠️ 未实测（高风险写入，未做破坏性验证） |
| 完整链路（你说一句话 → 助手自动写完） | ⚠️ 未实测 |
实测记录（命令层，人工在真实账号上执行）：
doc create → ✅ 建出一份在线文档
doc contents append → ✅ 追加成功
doc contents get → ✅ 读回内容与追加的内容完全一致
doc names update → ✅ 重命名成功（用于清理测试数据）
「写 → 读」闭环成立，这是这一域最有价值的一条实测结论。
同时印证了一件事：企业微信的四种文档在标识上有前缀路由——在线文档是 w3_、
在线表格是 e3_、智能表格是 s3_、智能文档是 a1_。助手就是靠这个判断你给的链接是哪种文档，
实测结果与技能里写的规则一致。
测试数据处置：命令行没有删除文档的接口，4 份测试文档已全部重命名为 「【可删除】DesireCore验收测试-*」，需要在企业微信里手动删除。
关于创建方式的一个说明：实测确认 doc create 直接可用。
但助手的默认流程走的是另一条路——先在本地生成一份 .docx，再导入。
原因见下方「注意事项」。两条路都记在这里，是为了让你知道助手有时候多花的那一步在做什么。
能力清单
| 能做什么 | 命令 | 风险 |
|---|---|---|
| 把本地文件导入成在线文档（助手默认的新建方式） | wecom-cli doc import |
低风险写入 |
| 直接新建在线文档 | wecom-cli doc create |
低风险写入 |
| 读取文档正文 | wecom-cli doc contents get |
读取 |
| 向文档末尾追加文本 | wecom-cli doc contents append |
低风险写入 |
| 整篇覆盖文档正文 | wecom-cli doc contents overwrite |
高风险写入（不可逆覆盖） |
搜索文档不在这里——搜索是 13 文档管理 的专属能力，四种文档类型都走那边。
注意事项
「新建」有两条路，助手默认走导入那条。
- 默认路径：先在本地生成一份 .docx，再导入成在线文档。这样能一次带进封面标题、多级标题、 列表、表格、局部加粗与配色这些排版。
- 另一条路：直接新建。它也能带初始内容，但只能灌一段没有结构的纯文字或 markdown—— 你说「生成一份 Word 周报」时期待的多半不是这个。
所以你会看到助手在建文档时多花一步。内容确实是纯文本、你也没有排版要求时， 它会跳过生成 .docx，直接写个 .txt 导进去。
文档名由文件名决定。 导入时的文件名（含后缀）就是最终的文档标题——想让文档叫《项目周报》，
文件名就得是 项目周报.docx。
默认是「追加」不是「覆盖」，判不准也按追加。 你说「写入 / 记录 / 补充 / 加进去 / 写进去」这类中性说法，助手一律追加到末尾。 只有出现「覆盖 / 重写 / 替换 / 清空重写 / 整个换成」这类强语义词，才会整篇覆盖。 理由很直接：追加错了可以再覆盖修正，覆盖错了原文就没了。
覆盖之前它一定会先读一遍。 整篇覆盖是不可逆的，原文没有备份，也没有回滚接口。 所以助手会先把现有正文读出来，在确认里告诉你「这份文档现在有什么」（一两句摘要）， 让你知道自己要毁掉的是什么。跳过这一步的覆盖等于蒙眼删除。 含糊的「嗯」「你看着办」不算同意。
追加和覆盖的容量差两个数量级。 追加单次上限一万字符，覆盖上限一百万。 内容特别长时助手会自己分段追加。
追加进去的内容不认 markdown 标记。 追加只支持纯文本，写 **加粗** 是不会被渲染的，
会原样出现在文档里。读取和覆盖则支持 markdown——这三个动作的格式能力不一致，
所以你会发现「读出来是带格式的，加进去却是纯文本」，这是接口本身的差异。
内容很长时读取会走本地文件。 文档正文超长时接口不直接返回内容，而是落到本地文件。 助手会自动再读一次那个文件，然后告诉你「内容较长，我已读取完」——它不会把本地路径贴给你。
清空文档不是传空。 想把一份文档清空，传空内容是会被拒的，正确做法是写一个空格。 你不需要知道这个，但如果看到助手在「清空」时留了个空格，那是对的。
这些类型读不了正文：ppt / journal / collect / mind / flow / pdf。
整套能力里都没有读它们正文的方法，助手会直接说明并给你文档链接，让你在客户端打开。
要结构化数据就别用文档。 你的需求里出现「字段 / 记录 / 筛选 / 排序 / 统计 / 分组」时， 助手不会用「文档 + 一张静态 markdown 表格」凑合，而是改用 11 智能表格 或 12 智能文档。
三条通用边界在本域怎么体现
- 只能改它自己建的东西——你自己在企业微信里建的那份文档，助手改不了： 追加不进去、更覆盖不了。它会说明这条边界，并建议「由我新建一份」或者你自己在客户端改。 反过来，助手自己建的文档它可以随便改——实测的「写 → 读」闭环就是在自己建的文档上完成的。
- 能力按品类逐项开通——文档是独立品类（实测账号是后来单独补开的）。 未开通时助手会把官方开通指引原样转给你，然后停下，不重试。
- 危险动作先问你——整篇覆盖是高风险写入，会先读原文、再复述 「将把《文档名》的全部现有正文替换为新内容（约 N 字），原内容不可恢复」并等你明确同意。 创建和追加是低风险，直接执行。见 99 风险与确认。