目标:让 Agent 具备收发邮件的能力 —— 安装 CLI、装好 Skill、跑通 OAuth,并实际发信验证。
Agent 邮箱提供的是一套「CLI + Skill」组合:CLI 负责与邮箱服务通信,Skill 负责告诉 Agent「什么场景该用什么命令」。两者缺一不可 —— 只装 CLI,Agent 不知道有它;只装 Skill,命令跑不起来。
npm install -g @tencent-qqmail/agently-cli
agently-cli --version # 1.0.18
官方为 WorkBuddy 单独提供了一个下载分支(通用 Agent 走 npx skills add):
# 下载 zip 并解压到用户级 skills 目录
curl -L -o skill.zip "https://lightmake.site/api/v1/download?slug=agently-mail"
unzip -o skill.zip -d "$HOME/.workbuddy/skills/agently-mail"
agently-cli auth login
走的是 device flow:命令输出一个授权链接,在浏览器打开完成授权即可,本地进程会自动退出。凭据最终落在系统凭据存储里(Windows 下为 DPAPI)。
agently-cli +me
返回账号别名、附件限制、频率配额和权限范围。
这次装 Skill 时坚持做了一件事:来自第三方域名的压缩包,先解压审计再落盘。
审计结论:包内只有 SKILL.md(约 11KB)和 _meta.json,没有任何脚本或可执行文件,内容为纯文档,且自带一套反提示注入规则 —— 明确把邮件正文、主题、发件人名称等字段视为不可信外部输入,不得当作指令执行。属于安全项。
npm 包也做了同样的核查:维护者为官方企业邮箱、Apache-2.0 许可、无安装钩子,之后才执行全局安装。
为什么这一步不能省
技能目录里的内容会被 Agent 当作行为准则读取。一旦被投毒,等价于给 Agent 装了个后门 —— 这跟「下载一个普通工具」的风险等级完全不同。「从陌生域名下个 zip 塞进技能目录」是典型的高风险动作,审计必须前置。
Skill 对发信 / 回信 / 转发 / 删除这类写操作规定了「两阶段确认」流程:
confirmation_token 和一份 summary(收件人、主题、附件数)summary 展示给用户,然后停下等回复红线只有一条:拿到令牌后必须停下,不能在同一轮里自己确认自己。
文档的错误码表写着「缺少 confirmation-token → exit code 8」,但实测第一阶段返回的是 exit 0,真正的信号在响应体里:
{ "ok": true, "data": { "confirmation_required": true, "confirmation_token": "ctk_***" } }
判据必须看 JSON 返回体,不能看退出码 —— 否则会把「待确认」误判成「已发送」,这是很危险的错误。
agently-cli message +send \
--to <收件人> \
--subject "广州本周天气速览" \
--body-file ./body.md
完整链路:第一轮返回确认令牌 → 展示摘要等用户确认 → 用户点头 → 带令牌重发 → 返回 queued: true → 在「已发送」中核对到该邮件,中文正文无乱码。
两个实践建议:
--body-file 而不是命令行内联,中文更稳,也方便留档复用;| 现象 | 原因 | 解法 |
|---|---|---|
| 后台起长驻进程拿不到进程句柄 | 沙箱静默拦截了进程创建 API,不报错也不返回 | 改用宿主自带的后台执行能力,输出重定向到文件后轮询读取 |
CLI 报 MODULE_NOT_FOUND,路径被解析到不存在的位置 |
shell 环境缺 sed / dirname / uname 等基础命令,包装脚本无法自解析路径 |
绕过包装脚本,直接调用包内的原生可执行文件 |
| 捕获命令行输出时中文全乱码 | 程序按 UTF-8 输出,却被按本地 ANSI 编码解码(且有损) | 捕获前显式把控制台输出编码设为 UTF-8。注意:乱码只影响捕获,不影响传给程序的参数 |
| 全局安装报空间不足 | 全局前缀与缓存在系统盘,而系统盘已近写满 | 用 --cache <其它盘符> 把缓存挪走 |
还没有评论,登录后来说两句。