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） - 消息发送、通讯录解析、微盘列表、邮件搜索、文档搜索、会议列表、智能表格创建均已实测通过 - 测试数据已全部清理，未污染真实账号 **尚未实测**：群聊历史（机器人未开通该品类）。相关文档已明确标注验证状态，未实测的能力不写「实际效果」段落。
5.7 KiB
媒体文件
在你的本地文件和企业微信里的文件形态之间搬运：把本地文件传上去，或者把企业微信里的文件落到本地。 它只搬运，不看内容——不做 OCR、不读 PDF 正文、不做看图问答。
这一域你基本不会直接点名。 它是别的能力在流程中间自动调用的一步： 发图片消息、读邮件附件、把已有素材放进微盘，都要先经过它换一次形态。 写这一篇是为了让你知道「为什么发图片比发文字多花一步」。
你可以怎么说
大多数时候你不会这么说，而是说下面这些话——由助手自己决定要不要调它：
「把这张图发到群里」（发消息前会自动上传一次） 「下载邮件里的附件看看」（读附件内容前会自动下载一次） 「这个 PDF 传到微盘」（这个反而不需要，见下）
📋 验证状态
| 项 | 状态 |
|---|---|
| 上传本地文件 | ⚠️ 未实测 |
| 下载文件到本地 | ⚠️ 未实测 |
| 完整链路 | ⚠️ 未实测 |
本域没有做过独立实测。 它总是被别的能力顺带调用，验收过程中没有单独跑过这两个方法， 也没有跑过任何需要它参与的完整链路（发图片消息、读邮件附件都没测）。
所以本页不写「实际效果」，不附任何命令返回值。 下面「能力清单」与「注意事项」来自接口定义与技能文档，是设计意图，不是实测结论。
能力清单
均未实测。
| 能做什么 | 命令 | 风险 |
|---|---|---|
| 本地文件 → 企业微信媒体形态 | wecom-cli media upload |
低风险写入 |
| 企业微信媒体形态 → 本地文件 | wecom-cli media download |
读取 |
两个动作都不会被别人看见。 上传只是把文件放进企业微信的媒体暂存换一个内部标识， 在被别的能力引用之前谁也看不到；下载只往你自己的本地磁盘写文件。 真正让文件被别人看见的是「引用它」的那一步——发消息、发邮件、传微盘—— 确认闸门加在那里，不在这里。
注意事项
不是所有「带文件」的操作都需要经过这一步。 这是最容易误解的地方：
| 你要做的事 | 需不需要先经过这一步 |
|---|---|
| 发图片 / 文件 / 语音 / 视频消息 | 需要。消息接口只认企业微信内部的媒体形态，不吃本地路径 |
| 传文件到微盘 | 不需要。可以直接给本地路径，上传是内部完成的 |
| 发带附件 / 内嵌图的邮件 | 不需要。附件可以直接给本地路径 |
| 把本地文件导入成在线文档 / 表格 | 不需要。同上 |
| 往智能表格 / 智能文档里传图片、附件 | 不需要。同上 |
| 读邮件附件、内嵌图的内容 | 需要。得先落到本地才能读 |
| 下载微盘文件 | 不需要。微盘自己就能给你本地文件 |
一句话记法：要看内容（下行）几乎总要经过这一步；要发出去（上行）只有发消息一定要经过， 邮件和微盘都能直接吃本地路径。
它下载不了链接，只认内部标识。 把邮件里的附件链接、正文里的图片链接、微盘的分享链接丢给它，一定失败——它只吃企业微信的媒体标识。
防泄漏（DLP）加密链接下不来。 企业微信有一类与你的身份绑定的加密资源链接， 这个能力下载不了也解不开。正确做法是把链接原样给你，你在企业微信客户端里点开看。 助手不会尝试用别的手段绕过去。
类型要和下游对齐。 上传时要声明这是图片、语音、视频还是普通文件； 发消息时消息类型必须跟它一致——不能拿图片当文件发。这一步由助手对齐，你不用管。
它不解析内容。 OCR、看图问答、PDF/Word/Excel 正文提取、音视频转写都不在这一域范围内。 它的职责到「文件已经在本地了」为止，之后的读取由别的能力接手。
它不负责「找」文件。 邮件附件的标识由邮件能力产出，微盘文件的由微盘能力产出。 这一域只接收别人给的标识，不搜索也不猜。
内部标识和本地路径都不会给你看。 你问「文件在哪」时，助手会用自然语言指代 （「你刚发的那个附件」「已取到文件《周报.pdf》」），需要给你可点的东西时用可读链接。
三条通用边界在本域怎么体现
- 只能改它自己建的东西——这一域不修改任何已有内容，只做搬运，所以这条不直接生效。 但它的下游会受限：上传上来的文件要发出去、要放进别人的文档里时，边界就开始生效了。
- 能力按品类逐项开通——它跟着调用它的那个能力所属的品类走。 比如发图片消息需要消息品类、读邮件附件需要邮件品类。相关品类未开通时， 助手会把官方开通指引原样转给你，然后停下，不重试。
- 危险动作先问你——这一域本身不问你，因为上传下载都不产生对外可见的后果。 问你的是下一步：发消息、发邮件、传到共享空间。 见 99 风险与确认。