Agent 开发者的工具箱:标准比清单重要

An Agent-First Toolchain — Criteria Matter More Than the List

前几天有人给我发了一份「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 用的?

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

An Agent-First Toolchain — Criteria Matter More Than the List

[Read More]

数字员工的自我进化:从 Harness 开始,每天重复干同一件事

Harness RSI Runs on Production Data, Not Algorithms

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

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

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

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

Harness RSI Runs on Production Data, Not Algorithms

[Read More]

我的公众号排版 Skill,每一行都是一次翻车

Every Line of My Publishing Skill Is a Crash Report

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

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

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

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

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

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

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

Every Line of My Publishing Skill Is a Crash Report

[Read More]

AutoHarness:Warp 的 Agent 自我改进循环

Self-Improving Means Shipping Config, Not Updating Weights

先看一个反直觉的场景。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、评测、权限与人审决定修改能否进入生产。

Self-Improving Means Shipping Config, Not Updating Weights

[Read More]

钉钉数字员工架构与落地实践

DingTalk Digital Employee: Architecture and Implementation Practices

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

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

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

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

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

DingTalk Digital Employee: Architecture and Implementation Practices

[Read More]

组织的损失函数:为什么你的 OKR 只是许愿

Your OKRs Are Just Wishes: What Organizations Really Need Is a Loss Function

和朋友讨论组织的 AI 化时,有一句话点破了本质:

「训练过模型的人都懂:损失函数错了,训练步数越多,跑得越偏。」

组织也一样。目标错了,团队越勤奋,死得越快。

训练速度从来不是问题,梯度方向才是。而大多数组织最大的危机是:它们从未认真检查过,自己正在优化的那个东西,到底是一个目标,还是一个愿望。

Your OKRs Are Just Wishes: What Organizations Really Need Is a Loss Function

[Read More]

健康检查全绿,数字员工失联了 16 分钟:生产交付的几个关键实践

When All Health Checks Are Green but the Brain Is Gone

2026 年 8 月 8 日下午,我们的数字员工失联了 16 分钟。监控这边,它一切正常。

说「失联」其实不准确——从所有监控指标的视角看,它一直活得好好的:进程存活检查正常,HTTP /session 探测返回 200,健康检查每 5 分钟跑一次,次次报「健康」。唯一的异常是:群里任何人 @ 它,它都不回。最早的「告警」是一个人在钉钉里发现不对劲——这比我们任何一条监控都快。

16 分钟不长,但足够让人意识到一件事:我们精心搭建的监控体系,监控的根本不是「数字员工在工作」,而是「装着数字员工的那个容器还在」。

这篇文章讲的,就是从这类事故里长出来的几个生产级实践。它们已经沉淀进数字员工的 harness 模板——三步上线一个数字员工 里讲过这个脚手架是什么、怎么三步上线;模板本身也在持续迭代,从内部生产版本一路提炼成开源的 dingtalk-opencode-tag。这篇是它的续篇:上线只是开始,生产环境会用它自己的方式告诉你,「能跑」和「生产级」之间还隔着多少坑。

When All Health Checks Are Green but the Brain Is Gone

[Read More]

六大 Coding Agent 的八月:相同的去处,不同的路

Six Coding Agents in August — Same Destination, Different Roads

想知道一家 AI 公司把赌注押在哪里,别看发布会,看它的 release notes。

上周有两份发布说明摆在一起,对比堪称黑色幽默:Claude Code 的 v2.1.239 版本写了 40 多条变更,跨机器通信、预算上限、企业云适配密密麻麻;同一周,Codex 的 release notes 只有五个字——「Release 0.x.y」,功能演进一个字不提,却日更 162 个二进制资产。

同一个行业,同一个星期,一家把底牌全摊开,一家把底牌全藏起来。发布说明是产品策略的 X 光片:什么功能被做成一等公民、什么被顺手带过、什么被刻意藏起来,全写在里面。

我把六大主流 Coding Agent 的八月发布记录拉了一遍——OpenClaw、Hermes Agent、OpenCode、Claude Code、Codex、DeepSeek Harness——发现一件有意思的事:

六家公司,朝着几乎相同的方向走,但走的路线完全不同。

相同的去处暴露了行业共识;不同的路线暴露了各家的底牌。这篇文章把这张 X 光片拆开给你看。数据来自我的 开发者双周观察(2026.08.23)

Six Coding Agents in August — Same Destination, Different Roads

[Read More]

数字员工的第一准则不是可控性

Why Accountability, Not Controllability, Comes First for Digital Employees

今年早些时候,我写过这样一个案例:一家电商公司的 AI Agent 自动调整了 2000 个 SKU 的定价,部分商品以成本价以下售出,一天亏了 80 万。复盘会上——

运营说:是 AI 自动调的。技术说:是数据源有异常。数据团队说:数据是实时抓取的,跟我们无关。

没有一个人为这 80 万负责。(案例详见企业级 AI 必须设计成出错后可以追责到人

那篇文章讲的是工程层面怎么追责:授权链、策略签名、审计日志。但写完之后,有一个更根本的问题一直挂着我:

为什么必须追到「人」?为什么不能追到 Agent 本身?

这个问题听起来像文字游戏,其实不是。它决定了你的数字员工部署从哪里画下第一根线——第一根线画错了,后面每一根都是错的。

前段时间我把这个问题的推导写成了一份内部文档。这篇文章是它的公开版:不做功能罗列,不列合规清单,从第一性原理出发,推导数字员工要成为组织成员必须满足什么条件。

Why Accountability, Not Controllability, Comes First for Digital Employees

[Read More]

同一个任务,AI 第一次折腾了好几分钟,第二次只用了 4.3 秒

From Seven Failed Clicks to 4.3 Seconds — Four Lessons on Buttons, Menus, URLs, and Skills

我给跑在本机的 AI 助手下了一个再普通不过的指令:「打开公众号后台,准备发一篇新文章。」

对我来说这是十秒钟的事:扫码进后台、点左侧「内容管理」、点「新的创作」、点「文章」,编辑器就开了。

但我马上意识到有场好戏要看——屏幕上这些按钮,在 AI 眼里长着完全另一副模样。

From Seven Failed Clicks to 4.3 Seconds — Four Lessons on Buttons, Menus, URLs, and Skills

[Read More]