Agent Spec 是数字员工的劳动合同

Agent Spec Is the Labor Contract of a Digital Employee

前几天有人问我:Agent Builder 的终局是什么?

我没直接回答,先让他做了个实验:在 Builder 里输入一句话——「帮我创建一个采购数字员工」。

Builder 吐出来一份 YAML:

employee:
  role: 采购专员
mission:
  - 处理采购申请
context:
  - ERP
  - DingTalk
  - Supplier DB
permissions:
  - read_inventory
  - create_purchase_draft
boundaries:
  - cannot_approve_purchase
evals:
  - ...
# generated by hugo AI

我问他:你觉得这份 YAML 是什么?

他说:Agent 的配置文件。

我说:逐字段再看一遍。

他看了几秒,声音不太确定了:「这……是一份 JD?」

对。这就是这篇文章的核心判断:Agent Spec 不是软件描述,它是劳动关系的一份抽象。

Agent Spec Is the Labor Contract of a Digital Employee

[Read More]

Palantir 从本体长到 Agent,我们从 Agent 长回本体

Palantir Grows Agents from Ontology — We Should Grow Ontology Back from Agents

前几天有人抛了一个问题:「哪些客户的续约风险正在上升,今天由谁介入?」

我把它原样丢给了一个 AI 助手,想看看它怎么答。

它的回答很诚实:答不了。它列出了这个问题需要同时拉齐的五个系统——CRM 里的客户关系、合同系统里的到期日、产品日志里的用量变化、工单里的故障、财务系统里的回款——然后说:「任何一个单独看都不够,五个信号交叉才能定位谁在恶化。」

这个回答本身没问题。但它暴露了企业 AI 的真实现状:AI 不缺智能,缺的是跨系统取数的资格。 它能看到每一个系统,如果它有资格的话。

有意思的是,最近两篇文章,从两个完全不同的方向,撞上了同一个问题。一篇是 Carlos Perez 的企业版 OpenClaw 万亿清算论,一篇是《读懂 Palantir Ontology》的完结篇——后者举的范例决策,一字不差就是上面那个续约风险问题。

两篇文章各讲了企业 AI 的一半。把它们拼起来,你会看到一条没人明说的路线。

Palantir Grows Agents from Ontology — We Should Grow Ontology Back from Agents

[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]

如何判断你的团队真的工程 AI 化了:六条验收标准

Six Acceptance Criteria for a Truly AI-Native Engineering Team

上周我在准备和团队 9 月初的一次对焦,主题是工程 AI 化。

预对齐时有人说:「我们 AI 用得挺好的——一半的 PR 是 AI 写的,Copilot 全员开通,还有人用 Claude Code 重构了老模块。」

我问了一个问题:「那挑一个 5 人天的真实需求,从提 Issue 到验收关闭,让 AI 端到端跑一遍给我看。」

会议室安静了几秒。安静不是因为没用过 AI,而是因为这条链路从来没有人完整走通过。AI 写过代码的片段,但片段之后是谁在收尾,说不清楚。

这个安静就是分界线:AI 写过代码,不等于工程 AI 化

Six Acceptance Criteria for a Truly AI-Native Engineering Team

[Read More]

软件工厂 3.0:从卖人月到卖模具

Software Factory 3.0 — From Selling Person-Months to Selling Molds

一个做外包的朋友上个月跟我抱怨:客户现在拿 AI 写的代码来压价。「你们报 30 人月,客户自己用 Claude Code 一周出了个 demo,问你们凭什么值这个钱。」

我问他:那个 demo 上线了吗?

他说没有。客户自己人测了一周,测出一堆问题,又回来找他们修。

我说:那你应该换个报价方式。不报人月,报模具费。

他没听懂。这就是这篇文章要讲的事。

Software Factory 3.0 — From Selling Person-Months to Selling Molds

[Read More]

Anthropic 领先行业 6 个月——但只有前两层算数

Anthropic Leads by Six Months — but Only in the First Two Layers

发完 从 Cowork 到 Tag:AI 的竞争单位,正在从个人变成组织 第二天,那个年轻人又发来一条消息。这次他没提问,而是直接甩了一个判断:

「对 AI 创业者来说:Anthropic 领先行业 6 个月。」

他还给了自己的三层拆解:

层次Anthropic 的领先点领先幅度
Foundation ModelClaude 系列整体非常强0-6 个月,且会快速收敛
Agent HarnessClaude Code / Cowork / Tag 形成完整 Agent 工作范式~6 个月
Agent-native Organization从「人使用 AI」走向「Agent 成为组织成员」~6-12 个月

他的结论是:模型层的领先会快速收敛,真正值得关注的是后两层。而且第三层,恰好是钉钉「数字员工」可以承接的位置。

前两层,我认同。第三层,我认为 写反了

在 Agent-native Organization 这一层,Anthropic 不是领先者,是刚入场的人。

Anthropic Leads by Six Months — but Only in the First Two Layers

[Read More]

从 Cowork 到 Tag:AI 的竞争单位,正在从个人变成组织

Cowork Is AI Times a Person, Tag Is AI Times a Team, and the Organization Comes Next

发完 Grok Bot 的跟班学习,会先干掉 RPA 市场 第二天,那个年轻人又发来一张截图:Anthropic 内部的 Slack 频道里,有人 @Claude 派了个活,Claude 接过去干,下一个人直接在它停下的地方接着做。

他问我一个问题:「这不就是多人版的 Cowork 吗?」

我的第一反应也是——Cowork 一月发,Tag 六月发,都是 Anthropic 家的,一个跑在你自己的电脑上,一个住在 Slack 里,看起来只是场景不同。

但想了两天,我的答案变了:Tag 和 Cowork 的区别不是「几个人能用」,而是 Agent 的身份变了——从「我的 AI」,变成「团队的 AI」。

把这两个产品连起来看,你会发现 Anthropic 其实画出路线图来了:AI × 人 → AI × 团队 → AI × 组织。前两段他们已经画完。而第三段,恰好是模型层的盲区。

这条路上还藏着一个更隐蔽的变化:贡献第一次变得可观测了——组织度量贡献的方式,即将跟着变。

Cowork Is AI Times a Person, Tag Is AI Times a Team, and the Organization Comes Next

[Read More]

Grok Bot 的跟班学习,会先干掉 RPA 市场

RPA Is Low-Code Programming, and Demonstration Is Its Final Compiler

今年 2 月,我写过一篇工程文章 通过桌面录屏实现自动化 RPA 的最佳实践:用录屏捕获屏幕画面和鼠标键盘事件,让多模态大模型理解操作序列,再自动复现。为了验证可行性,我自己写了实现——光录制模块和关键帧提取就是几百行代码,文末我还特意提醒:这条路离可用产品有距离。

六个月后,8 月 11 日,SpaceXAI 把这个机制直接做成了正式产品 Grok Bot。每个 Bot 拥有一台独立的云端 Linux 虚拟机,学会一个流程不需要任何配置:你像平常一样操作一遍,Bot 在旁边看着、记下来,下次它自己干。想用,先买 $200/月的 SuperGrok Heavy 订阅,或者 $120/人/月的团队版。

媒体标题都在喊「马斯克终极大招」「数字同事上岗」「硅谷炸锅」。但我想聊一个被忽略的部分:Grok Bot 最狠的不是「能干活」——能干活这件事,Claude Cowork 能做,OpenAI 也能做。真正狠的是 跟班学习 这四个字。它第一个会干掉的市场,不是聊天框,不是 Office,而是 RPA 行业。

RPA Is Low-Code Programming, and Demonstration Is Its Final Compiler

[Read More]

别再用技能衡量自己:AI 时代的成长单位是闭环

The Loop, Not the Skill, Is the Unit of Career Growth

前几天,那个年轻人又给我发消息了。

月初我在 从用好 AI 到管理 AI 里记录过他的困惑:每天都在用 AI,prompt 也调得不错,但总觉得还是在「自己干活」。我当时的回答是,他卡在「用好 AI」这一级,要往「带 AI」「管理 AI」走。

他回去照做了。这次他告诉我:又订了三个工具,整理了 30 条常用 prompt,还刷完了两门 AI 课程。然后他问了一个新问题:

「我的工具更多了,效率也确实高了。但为什么反而更焦虑了?如果明天出一个更好的工具,把这些全做了,我还剩下什么?」

我当时没有马上回答。不是问题难,而是他问的已经不是「怎么用好 AI」,而是一个更根本的问题:AI 时代,衡量一个人成长的单位,到底是什么?

几天后,吴恩达在 The Batch 上发了他的新来信,标题是「AI 奖励能构建新技能的通才」。这封信把这个问题往前推了一步——但我觉得,还可以再推一步。

The Loop, Not the Skill, Is the Unit of Career Growth

[Read More]

Eval 是品位

Evals Are Taste

上周发完 一切皆插件:DeepSeek Harness 的野心与收敛鸿沟,一位带研发团队的读者给我发消息:「十次修改能不能收敛,你说取决于 eval。那我们让团队多写点测试用例,是不是就能收敛了?」

「多写点测试」是标准答案,也是错误答案。

它错在把 eval 当成一个纯的工程问题——好像数量上去了,收敛自然就来。但真正决定收敛的,不是 eval 有多少,而是 eval 集长什么样。而 eval 集长什么样,取决于一个更不好量化的东西。

品位。

Evals Are Taste

[Read More]