一、数字背后的工程事实
先厘清可核实的部分：
Vercel COO Jeanne DeWitt Grosser 访谈口径（经 Tomer Tunguz 博客转述）
- inbound 销售开发 90% 自动化
- 团队规模 10 人 → 1.25 人
- AI 销售开发智能体年成本：数千美元量级
内部工程侧（BestBlogs 转述 X @hongming731，单一二手转述，未见官方声明）
- 开源智能体框架 Eve
- 数据 agent D0 改用文件系统为中心的工作方式后，评估成功率翻倍
- 沉淀约 100 个 skills，约 20 个 agent 达到 PMF
工程上真正值得注意的不是 10 → 1.25，而是**"约 100 个 skills"这个中间量**。
1.25 个 FTE 背后是 100 个可复用流程单元。这两个数字的比值说明了一件事：压缩人力不是靠一个通用智能体，而是靠把工作拆到足够细的粒度，再逐个固化。
二、一条流程可被 Agent 接管的最小条件
把 inbound 销售开发拆开，只有四个环节：
| 环节 | 输入 | 处理 | 验收标准 | 可否自动化 |
|---|---|---|---|---|
| 线索背景查询 | 公司名/域名 | 检索工商、技术栈、规模 | 字段齐全且可溯源 | ✅ |
| 线索分级 | 背景数据 | 套用评分规则 | 命中/未命中阈值明确 | ✅ |
| 开场邮件生成 | 分级结果 + 模板 | 填充与改写 | 模板合规、无幻觉字段 | ✅ |
| 深度跟进判断 | 多轮交互历史 | 综合评估 | 无客观标准 | ❌ |
前三步能被接管，是因为它们满足同一个条件：输出是否合格，事后可以被机器判定。
第四步不能被接管，不是因为它难，而是因为没有可计算的验收函数。"这个客户值不值得多花两周"——这句话无法写成断言。
所以判断标准可以形式化：
一个环节能否交给 Agent
= 是否存在 verify(output, ground_truth) -> bool
∧ 是否存在明确的 input schema
∧ 是否存在稳定的处理规则集
三条缺一不可。现实中最常被忽略的是第三条——很多团队以为写了 prompt 就是规则集，实际上 prompt 里的模糊修饰（"适当""根据实际情况"）会让输出不可复现。
三、Skill 的结构：不是 prompt，是契约
"100 个 skills"如果按文件形态落地，一个最小可用的 skill 定义应当包含四段，缺一段就会退化成不可靠的 prompt：
name: lead_enrichment
version: 1.2.0
input_schema:
company_domain: string # 必填
required_fields: # 明确要求产出的字段
- legal_name
- employee_range
- tech_stack
optional_fields:
- funding_stage
processing:
retrieval:
sources: [public_registry, official_site, tech_detector]
max_retries: 2
rules:
- if tech_stack contains any of TARGET_STACK -> score += 30
- if employee_range in [50, 500] -> score += 20
- if funding_stage in [B, C] -> score += 15
fallback: # 关键：定义检索失败时怎么办
on_missing_field: mark_as_unknown # 不是猜
on_all_sources_fail: return NEEDS_HUMAN
acceptance:
required_fields_completeness: ">= 0.8"
no_fabricated_fields: true # 未检索到的字段必须为 unknown，禁止生成
traceable: true # 每个字段需附来源
human_gate:
enabled: false # 低风险环节可不卡
三个容易被跳过的字段：
fallback —— 没有它，agent 在检索失败时会编造内容。这是生产环境最常见的事故源。
no_fabricated_fields —— 必须显式禁止填充。默认行为是生成，不是留空。
traceable —— 每个字段附来源，既是为了可审计，也是为了后续纠错时能定位到具体数据源。
四、为什么 D0 改成"围绕文件系统"后成功率翻倍
这条转述数据（单一二手来源）如果成立，工程解释是合理的：
文件系统的优势不在存储，而在它提供了确定性的状态与可回溯的中间产物。
上下文全在 prompt 里：
[输入] → [模型一次性生成] → [输出]
中间态不可见，出错只能整体重跑
围绕文件系统：
[输入] → [写入 state.json] → [分步读写] → [每步产物落盘] → [输出]
中间态可检查、可断点续跑、可单步重试
对长链路任务，差别是决定性的。断点续跑意味着第 5 步失败不需要重跑前 4 步；中间态落盘意味着能定位到底是哪一步开始偏移。
这也解释了为什么"skill 的形态本身在迭代"——它不是一次性写死的模板，而是要随失败案例持续修订 rules 与 fallback。
五、审批模式是必需的工程约束
Anthropic 为中小企业产品增加的 43 个工作流默认启用"审批模式"——发送、发布、付款均需人工确认。这不是产品保守，是工程上必须。
风险分级应当写进 skill 定义：
RISK_LEVELS = {
"read_only": {"human_gate": False, "example": "信息检索、摘要"},
"internal_write": {"human_gate": False, "example": "生成草稿、写入内部表"},
"external_send": {"human_gate": True, "example": "发邮件、发帖"},
"irreversible": {"human_gate": True, "require_double_confirm": True,
"example": "付款、删库、对外承诺"},
}
def execute(skill, params):
gate = RISK_LEVELS[skill.risk_level]["human_gate"]
result = agent.run(skill, params)
if gate and not human.approve(result):
return Status.REJECTED
return commit(result)
判断依据只有一条：该动作是否可逆，以及出错后损失多久显现。 可逆且损失即时可见的可以放开；不可逆或损失延迟显现的必须卡人。
六、关于"100 个 skills"的一个冷水
数字之外有个现实约束：让员工把自己的工作流写成可替代自己的说明书，这件事在激励上是反着的。
工程上再完善的 skill 定义，如果产出的文档是敷衍的，rules 里写的规则和实际执行的规则就是两套。这不是技术问题，但会直接决定那 100 个 skills 到底有多少真在跑。
一个可行的落地顺序：
- 先做一条，跑通并量化（耗时、准确率、人工介入率）
- 建立 skill 的版本与回归机制——每次规则变更都要跑一遍历史用例
- 把"沉淀了几个可运行 skill"计入考核，否则只会收获一堆文档
声明：本文技术部分为公开资料整理与工程经验推断。Vercel 内部数据（D0、100 个 skills、20 个 agent）为单一二手转述，未见官方声明，请以此为准。代码块为示例实现，非任何产品的实际源码。
