Dingtalk

上周一个钉钉校招生来找我抱怨。他帮在校的师弟调毕业设计，想做一个「钉钉里 @ 一下机器人，就能让本地 Agent 帮忙跑数据分析、回传结果」的小系统。思路很清楚，卡壳的地方很尴尬——卡在了第一步：钉钉开放平台管理后台。

他注册了开发者账号，进了那个后台，对着「企业内部应用 → 创建应用 → 机器人配置 → 权限申请 → 版本发布」一长串表单发呆，搞了一下午连机器人 token 都没拿到。他来找我吐槽：「是不是还得租个服务器写个后端，机器人才能跑起来？这门槛也太高了吧。」

我把他从那个后台里拽了出来，敲了一条命令给他看：

dws dev connect --channel opencode --unified-app-id <你的应用ID>

三十秒后，他在钉钉里 @ 那个机器人说「hi」，本地 opencode 接到消息、生成回复、回传钉钉，整个链路通了。没有碰管理后台，没有写后端服务，没有租服务器。

这篇文章就是把这个过程从浅到深讲一遍： 先一条命令把通用 Agent 接进钉钉，再用 opencode 本体搭出一个鲁棒、自愈、能实时回传进度的垂直 Agent 协同系统。面向的就是在校同学——你有一台笔记本、会用命令行、装了 opencode，就能跟着跑通。

上周我让一个 Coding Agent 帮我用飞书发一条群消息。

它读完了 lark-cli im --help，看到了 messages 子命令，继续往下翻——发现 messages 下面只有 delete、forward、urgent_app 这些操作。 没有 send。

Agent 懵了。发消息这么基础的操作，怎么可能没有？

它又去翻了 raw API 路径 lark-cli api POST /open-apis/im/v1/messages，拼了一大坨 JSON body，调通了。但这条路绕过了 CLI 的所有设计——参数校验、身份管理、错误处理——全部自己来。

后来我告诉它：你应该用 lark-cli im +send。这个 +send 是一个 shortcut——飞书 CLI 为高频操作预置的语义快捷方式，比 raw API 路径短得多，也比它好用得多。

Agent 不知道有这回事，因为 --help 的输出里没有明显标记 shortcut 的存在。

同样的事情也发生在钉钉上。我让另一个 Agent 用 DWS 给同事发一条消息，它调了 dws chat message send，参数都对了，返回结果是：

{"success": true, "result": {"openTaskId": "..."}}

Agent 认为发送成功了，继续下一步。但十分钟后我打开钉钉——消息根本没到。

Agent 不知道发生了什么。success: true 告诉它「成功了」，但现实是消息石沉大海。后来排查发现是 PAT 权限不够——API 返回了「成功」，但实际投递被权限系统拦截了。

对人类来说，打开手机看一眼就知道没收到。但对 Agent 来说，success: true 就是真理——它没有能力验证现实，只能信任返回值。

这就是「API 友好」和「模型友好」之间的鸿沟。

上周一个朋友跟我说，他们公司「上线了数字员工」。

我问：干了什么？

他说：在 HR 群加了个机器人，员工可以问请假政策、查工资条、提交报销。

我问：那和三年前上线的 FAQ 机器人有什么区别？

他愣了几秒：「……好像就多了个大模型，回答更像人话了。」

这不是段子。2026 年，钉钉、飞书、企业微信上跑着成千上万个「数字员工」，大多数落地形态惊人地相似： 一个大模型，挂在一个群里，回答预设范围内的问题。 换了个「数字员工」的名字，骨子里还是个聊天机器人。

真正的数字员工应该是什么样子？Anthropic 的 Claude Tag 给出了一个方向——Agent 以组织成员身份加入 Slack，有自己的记忆、权限和行为日志。我在 Claude Tag 的 Agent Identity：为什么这是 Agent 时代的 OAuth 中详细分析过这个「身份层」的设计。

但身份只是第一步。把 Agent 的名字写进通讯录，工程量大概只占 10%。剩下的 90% 是什么？

昨晚我用 OpenCode 在钉钉上写一个会议通知 Agent。需求很简单：查日历找到明天的会议，给参会人发一条钉钉消息。

OpenCode 读完了 DWS CLI 的 help 文档，开始生成调用代码。它要发消息，看到了三个命令：dws chat message send、dws chat message send-by-bot、dws chat message send-by-webhook。它选了 send，传了 --group 和 --text，没传 --title。

返回了一个错误：「发群服务窗会话消息失败」。

OpenCode 懵了。我也懵了。什么「服务窗」？我在发群消息，跟服务窗有什么关系？

后来我翻了 dws chat message send --help，在最底下发现了一行小字：

--title 是消息标题，群聊与单聊都必填（API 强制要求；缺失时返回误导性的「发群服务窗会话消息失败」）。

平台团队知道这个错误信息是误导性的，他们选择在 help 文档里标注「误导性」，而不是修复 API 的返回。

但这还没完。OpenCode 继续工作，又遇到了第二个问题：send 命令有三个互斥的目标参数——--group（群聊）、--user（userId）、--open-dingtalk-id（openDingTalkId）。help 文档说「三者只能选其一」，但没有解释什么时候该用哪个。userId 和 openDingTalkId 的区别是什么？Agent 无从推理——它只能猜，猜错了再换。

这整个过程花了十几分钟。但这十几分钟本来不应该存在。

这不是假设场景，这是 DWS 今天的真实状态。

昨天一个校招生在钉钉上问我：「日报能不能让 AI 帮我写？我每天花 30 分钟凑那些东西，感觉像在演戏。」

我没有急着回答「能」或「不能」。因为这个问题的背后藏着一个更大的矛盾——

如果日报真的只是「写给主管看的汇报」，那让 AI 写完全合理，甚至应该让 AI 写。但如果日报的价值远不止于此，那用 AI 替代的可能恰恰是最不该被替代的部分。

问题不是「AI 能不能写日报」，而是： 在一个 AI 能替你写字的时代，人还应该写什么？

周五下午 4 点。你打开钉钉，你的 D 群里「本周的重点事项」消息已经发了 24 小时。16 位负责人被 @，每个人的进展回复散落在三个地方：有人私聊你说了三段话，有人在群里回了一个 emoji，还有人到现在一个字没发。

你要整理的，是一份让所有人都看得懂、能 action 的结构化进度报告。

手动做这件事需要 2-3 小时（经验估算）。你打开 16 个单聊窗口 + 群聊消息列表，翻来翻去。做得再仔细，也跑不掉三个 bias： recency bias ——最后看到的记得最清， salience bias ——写了一大段的人得到最多篇幅，写了三个字的人被一笔带过。 survivorship bias ——没回复的人直接消失在你的视野里，而不是被明确标记。

我手动做了这件事好几个月。然后写了一个 Agent Skill 文件——不到 200 行的 Markdown，把你的工作流程像岗位说明书一样写清楚。跑起来之后的效果不是「更快了」，而是 总结质量比手动好：每条来源可溯源、16 人全覆盖、没回复的标 ⚠️ 而不是消失。从 12 人扩到 16 人时，只改了 4 行映射表。

这篇文章讲的就是这个案例——以及如何把 Loop Engineering（让 Agent 自主跑到终点的工程方法）从写代码的场景，搬到管理协调的场景。

这个工程能落地，最关键的工具是 钉钉 DWS（DingTalk Workspace CLI）。DWS 是 Agent 与钉钉的统一接口层，它的设计让钉钉对 Agent 友好、对开发者友好。无论你使用哪款 Agent——OpenClaw、Hermes、OpenCode、悟空、MuleRun、WorkBuddy——都能通过 DWS 应用这套 AI 驱动的管理方法。Agent 是 fungible 的，接口层才是杠杆。

上周在钉钉里看到一条消息，让我意识到一个根本性的转变正在发生。

一位产品经理在群里 @AI 助理：「帮我总结一下今天会议的要点。」AI 很快给出了回复。几分钟后，她又 @采购 Agent：「根据这份 PRD，生成采购计划并提交审批。」

同样是 @AI，但两次操作的性质完全不同。第一次是 问一个问题，第二次是 派一个任务。

这个细微的差别，恰恰是 AI 时代 IM（即时通讯）正在发生的最深刻的范式转移： 沟通正在从「对话」演进为「协同」。

接着 销售流程 AI 化系列 的汽配分销商案例讲。

上一篇讲的是理念：解决方案对象、拜访质检、履约 SOP 编译。这一篇讲落地：FDE 到客户现场，怎么用基础设施在一天内把这些理念变成可运行的 Agent。

老周（售前）和小林（FDE）一起到了汽配客户现场。客户有 200 家门店，销售团队 30 人，每天处理 50+ 客户咨询、20+ 报价单、10+ 合同审批。

问题是：销售流程全靠人肉，信息散落在微信、Excel、邮件里，老周那份 80 页 PPT 签完单就死了。

周一早上，运营群里有人 @了运营 Agent：「帮我看看上周退款率为什么涨了」。

Agent 开始干活。它先查了 AI 表格里的退款明细，又调了客服工单系统的投诉分类，接着跑了一段 SQL 算出各渠道的退款占比，最后生成一份带趋势图的分析报告发到群里。整个过程 40 分钟，中间还主动追问了一句：「要不要把退款金额 > 500 的单独拉出来？」

报告质量不错。但安全团队事后审计时发现了三个问题：

1. Agent 查退款明细时，用的是 @它那个人的 App Token——这个人恰好是运营总监，有全量数据权限。群里其他人没有这个权限，但他们都看到了报告。
2. Agent 调工单系统时，用的是一个 写死在环境变量里的 API Key，这个 Key 的权限范围是 read:all，理论上 Agent 可以读任何人的工单。
3. 日志里只记了「运营总监访问了退款表」， 没有记录是 Agent 在执行。

这是一个典型场景，我在不同企业里见过不同程度的版本。

在 Claude Tag 的 Agent Identity：为什么这是 Agent 时代的 OAuth 中，我讨论了 Agent 为什么需要自己的身份。这篇接着往下走： 当 Agent 进入钉钉群，权限、凭证、审计这套架构具体怎么设计？

周一早上九点，小林到了客户的运营部。

他不是来做产品演示的，也不是来签合同的。他的工牌上写的是「Forward Deployed Engineer」——一个在钉钉内部新设立的岗位，外部还没有对应的职称。

上周客户提了一个需求：「每天有 20 个人整理会议纪要，能不能用 AI 提效？」

普通工程师听到这句话，想到的是做一个会议纪要工具。

小林想到的是：

会议
    ↓
纪要
    ↓
任务拆解
    ↓
责任人
    ↓
审批
    ↓
提醒
    ↓
知识沉淀

他要做的不是一个纪要工具，而是一个 会议 Agent。