Hugo Zhu's Blog

前几天有人给我发了一份「2026 年 Agent 开发者工具箱」清单，整整 15 个名字：git、gh、docker、uv、node、pnpm、nvm、rg、jq、curl、fzf、just、direnv、python、go。分层清晰，还配了星级。

我顺手在自己这台跑 Agent 的机器上核对了一遍，结果很有意思：15 个里我只装了 7 个。

for t in git gh docker uv node pnpm nvm rg jq curl fzf tmux direnv just mise; do
  command -v "$t" >/dev/null && echo "$t: yes" || echo "$t: NO"
done
# generated by hugo AI

git、gh、uv、node、pnpm、rg、curl 在；docker、jq、fzf、tmux、direnv、just、mise 一个都没有。机器没罢工，Agent 每天照样在上面干活。

所以我没有急着去补齐那 8 个缺口，而是先问了一个更基本的问题：这份清单是按什么标准选的？是给人用的，还是给 Agent 用的？

这两个问题的答案，会导出两份完全不同的清单。

最近读了一篇关于 Harness 自进化的报道，里面有个细节让我停下来想了很久。

停下来的原因，是我们自己也卡在这里：数字员工上线一段时间了，它好像变「顺手」了，但说不清是不是变「聪明」了。这个模糊感，恰好被报道里的三个数字点破。

报道里那家公司说（厂商自报口径）：他们平台上 95% 以上的 Agent 被每天重复运行；在留存用户中，93.4% 的操作是系统自触发的；超过六成的自动化流程持续运行了一个月以上。

大多数人读到这三个数字，看到的是「这家公司用户很多」。我看到的是另一件事：这三个数字加起来，恰好是递归式自我改进（RSI）最稀缺的原料。

8 月 31 日，离职高发的异动日。下定决心的已经走了，还在犹豫的，犹豫到最后一刻。

今晚和一位同事吃饭，酒过三巡，他问我：你对未来怎么看？

我没给宏图大略，只说了几件我越来越相信的事。写下来，分享给所有觉得自己无从选择的朋友。

岗位真实，人名与数据已脱敏。这是一篇可以被复制的实践——文末有千问办公实操路径。

我是某条业务线的一号位，每周要向 CEO 汇报商业化、产品与组织三条线的进展。10 位直接下属，周报形态五花八门——有人发长文消息，有人甩一个文档链接，有人发文件附件；同一个指标，业务线和 BI 各有一个数，谁也不服谁。

上周日，我第一次让 AI 同事全程接管这件事。没有 SOP，没有模板，纯靠对话指挥：一个个群、一个个单聊地读，一份份总结、比对、入稿。从早到晚干了三个多小时，周报是交出来了，token 烧了上亿。

贵，但值——因为做完之后，我让 AI 把整个过程复盘了一遍： 哪一步是固定动作？哪一步踩过坑？哪个数字要过谁的口径？ 然后把这些蒸馏成了一份 weekly-report 技能文档：固定坐标、模版结构、素材来源对应表、指标字典、历史教训，一条不落。

这周日，我只说了一句话：开始整理本周的周报。

AI 同事加载技能，按流程执行：读上周远端文档定结构、批量收集十个来源、报「已收/未交」清单、按字典压缩入稿—— 不到十五分钟，一份质量过关的周报草稿出来了，全是重点信息。

省下来的时间，我去做了真正值钱的事：写下业务、产品、组织面对客户与竞争的方向判断，预演 CEO 的追问，补上风险与决策请求，再把待确认的问题分发给责任人。下面是这份周报背后的五个细节。前四个发生在十五分钟里，第五个，是十五分钟和 AI 都替代不了的。

本文全部时间线与数字来自 2026-08-30 一次真实执行记录，可在本机数据库逐条复核。

昨天傍晚六点三十七分，我中断了一个正在跑的任务。

任务叫 wx post 376——一句话，AI 同事全套接管：把博客文章排版成公众号 HTML、钉钉投递、生成朋友圈文案、发到“数字员工协作群”让另一个 agent 转发到 X.com，最后驱动已登录的 Chrome 进公众号后台，把标题、正文、作者、封面、原创声明一项项填进编辑器存草稿。

它跑了四十分钟，干完了八成。然后，在原文链接设置成功后的第十四秒，会话被我中断，留下一份半成品草稿。

今天我对 AI 同事说了一句话：「回顾下处理 376 的整个过程，找出优化空间。」

它做了三件事：从本地数据库里挖出自己的完整执行历史，重建逐分钟时间线；找出六个优化点；当场把 Skill 改写为 v2.2.0。

这篇想写的就是这个过程给我的冲击——一个 Skill 里最值钱的不是流程，是翻车记录；而这份事故报告，可以不用人来写。

客户第一次见面说：「我们想做一个销售 Agent。」

多数团队会立刻追问：想用哪个模型？知识库有多少文档？要不要私有化？

「FDE 前线」最近发了一篇文章，给出了另一套问法——20 个问题，分五组：业务结果、真实流程、数据与系统、风险与权限、采用与责任。第一问就不是「用什么模型」，而是「这条流程最终要产生什么业务结果」。

这 20 问在网上被当成销售技巧清单转发。但我读完后的判断不一样：这不是一份访谈提纲，而是一份组织上下文的采集协议。它真正的价值，和它最大的问题，是同一件事——它太贵了。

先看一个反直觉的场景。6 月 12 日，Warp 创始人 Zach Lloyd 的 GitHub 账号向开源 demo 仓库 issue-triage-loop 提交了一个 PR #21。PR 的真正作者不是他，而是一个在 Oz 上运行的 Agent。它做的事很克制：回看 issue #16 到 #20 这 5 次 triage 判断，发现其中 4 次被人类维护者纠正，于是把这些纠正压缩成 3 条可复用的规则，diff 只有 8 行新增、6 行删除，最后提出把 triage Skill 从 v1 升到 v2。

一个 Agent，给自己交了一份只有 14 行的「改进申请」，等人批准。这就是 Anthropic 笔下「self-improving agent」的真实形态——它让人联想到模型在线训练、自动改权重，但讲的并不是这些。我把官方文章、Warp 公开 demo、这个 PR 和当前开源实现放在一起看，结论很清楚：持续变化的是版本库里的 Skill 与相关配置。 Claude 负责执行任务、归纳反馈和生成候选修改；Git、评测、权限与人审决定修改能否进入生产。

8 月 27 日晚上，我做了一场《钉钉数字员工架构与落地实践》的分享。六十分钟的正题讲完，真正让我反复回味的，是 Q&A 环节的四个问题。

最后一个最尖锐。提问者先铺垫了他的观察：从演示看，数字员工做的是秘书、提醒、传话、会议纪要这类辅助性工作。然后他话锋一转：

如果我让数字员工承担一部分技术开发工作，它将面对非常复杂的场景和长周期的任务。长周期任务下，执行的成功率会一路衰减。请问你们的数字员工能不能解决复杂的长期问题？如果不能……

「如果不能」悬在半空。我当时的回答很直接： 钉钉做的是让 AI 能进入企业组织架构的基建——数字员工账号、连接多 Agent，权限管控、运行审计、知识管理，为任务提供上下文等基础能力，还提供入转调离全生命周期管理、执行前主管审批确认放行、岗位能力评估和考核、拟人化交互等功能，但还不能对企业自建或生态交付给企业客户的数字员工的产出效果来负责。

分享结束后，我把这四个问题记了下来。它们看似散，其实指向同一件事： 数字员工的落地卡点，从来不是模型能力，而是四个组织问题。 而四个问题说到底，又可以归到一个词上： 委托 ——把工作交给 AI 之后，这份委托如何在组织里被信任。

上周一个老板问我：他想像同行那样，用 3 个真人带 30 个数字员工跑业务（这个比例是我们推演的示意，不是他的真实编制）。卡点在哪？

不是模型不够聪明，也不是工具不够多。卡在一个很朴素的地方：没有一个中层愿意把自己的判断标准写成文档。

审批到什么金额要上报、哪种客户投诉要升级、什么情况下可以破例——这些判断每天都在发生，但全装在某个管理者的脑子里。数字员工问他，他口头答；换一个场景，又得重新问。

于是 30 个数字员工，每一个都变成了「等他拍板」的排队窗口。

上周，我翻我们数字员工的一条真实执行链路：一条消息进来，Agent 理解意图，调用 dws 能力执行，结果回到钉钉。全程没有「人看报表」这一环——数据的终点不是被谁看见，而是业务本身被改变。

这条链路短到不起眼。但它让我意识到，自己正在做一件大多数企业 AI 还没做成的事——同一时间，绝大多数企业的 AI 项目，正卡在「把结果给人看」这一步出不来。

最近读到「森林瀑布」的一篇长文《Palantir 还是太全面了》，把 Palantir 的官网和产品文档逐页扒了一遍。文章里有一句话，我认为点破了企业 AI 的分水岭：

「AI 到底连接到了什么。如果 AI 连接的只是一个搜索框，它还是聊天机器人。如果 AI 连接的是企业 Ontology、业务规则、Action 和真实业务系统，它才真正开始进入企业的操作层。」