Hugo Zhu's Blog

上个月面试一个候选人，简历很漂亮，做过三年 LLM 应用开发。我问他：「你觉得你做的东西，本质上是在交付什么？」

他说：「交付模型能力。把 LLM 的能力封装成 API，让业务方能用。」

我又问：「如果业务方说，我要一个能自主完成端到端任务的系统，不只是回答问题——你交付的东西能做到吗？」

他愣了一下：「那得加很多工程，不只是调 API。」

我说：对，这就是我今天想聊的——当交付物从「模型能力」变成「自主系统」时，你的工程标准该是什么样。

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

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

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

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

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

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

上个月，一个做消费品牌的朋友找我聊他们的 AI 项目。

他们花了三个月，让技术团队给 CEO 做了一个「数字分身」——能模仿 CEO 的语气给全员发周报、回答战略问题、甚至在新人培训里做公司介绍。演示那天，CEO 本人看了都觉得「挺像我的」。

然后他问了我一个问题：「这个东西，除了我自己觉得好玩，到底该给谁用？」

我说：你做了一个 分身，但你需要的是一个 员工。

他愣住了。

这不是个例。我观察到大量企业在启动 AI Agent 项目时，第一步就搞混了这两个概念——不是因为技术理解不够，而是因为 没有想清楚锚点在哪。

上周 review 一个团队的代码。他们想做一个能自主修 bug 的 Agent，架构设计得很漂亮，模型选的也是最新的。但 Agent 跑起来后，改完代码就停了——它不知道怎么验证自己改得对不对。

我问他们：「测试覆盖率多少？」

「大概 30%，而且跑得慢，本地跑一次要 15 分钟。」

「日志呢？有结构化日志吗？」

「有，但格式不太统一，有时候打 JSON，有时候打纯文本。」

「Health Check 呢？」

「有个 /ping 接口，返回 200。」

我说：那你的 Agent 改完代码之后，怎么知道改对了？怎么知道部署上去没炸？怎么知道要不要回滚？

他想了想：「只能让人看一眼。」

我说：对，这就是问题所在——你的系统不是为 Agent 设计的，是为人设计的。 人可以用经验判断「这个改动应该没问题」，Agent 不行。Agent 只能依赖 可以调用、可以验证、可以反馈 的能力。

上周我让一个 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 能替你写字的时代，人还应该写什么？

前几天刷社交媒体，看到一个技术总监发的帖子：「AI 帮我把周报、PPT、邮件全干了之后，我突然不知道该干嘛了。」底下几百条评论，清一色共鸣。

这不是段子。越来越多管理者发现，当 AI Agent 把开会、写文档、review 代码、处理审批从每天 8 小时压缩到 2 小时之后，他们面对一个从未想过的问题——多出来的 6 个小时，用来做什么？

这个问题，林语堂在 1937 年就回答了。

周五下午 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 的，接口层才是杠杆。