Case - Tessl - Agent 技能的 npm

✅ 强案例 — Agent 时代的包管理器。不是做 Agent，而是做 Agent 的”知识供应链”。核心洞察：当所有人都在造 Agent 时，Tessl 在做 Agent 需要的燃料——结构化上下文。

基本信息

官网: https://tessl.io
创始人: Guy Podjarny（上一家公司 Snyk，估值 80 亿美元，创造了 Developer Security 品类）
融资: $125M，投资方 Index Ventures、GV（Google Ventures）、Accel、Boldstart
总部: 伦敦
成立: 2024 年
定位: “The package manager for agent skills and context”
客户: Cisco、Zillow、HashiCorp/IBM、JetBrains、DoubleVerify、ElevenLabs

核心概念

SSD（Spec-Driven Development）

Tessl 提出的新开发范式：

传统开发：  人类写代码 → 代码审查 → 部署
Vibe Coding：人类用自然语言 → Agent 写代码 → 人类审查
SSD：        人类管理 Spec → Agent 扫描大仓库/大词典 → 保证 API 版本绝对正确 → 自动部署

人类不碰代码，只管理 Spec。 Agent 负责理解组织内的所有 API、库、约定，写出符合规范的代码。

但要实现这个愿景，Agent 需要一个关键能力：知道你的组织里用什么库、什么版本、什么约定。这就是 Tessl 的切入点。

Tiles / Skills（Agent 的知识包）

Tessl 的核心产品单元：

Tile/Skill = 一个结构化的上下文包，告诉 Agent “如何正确使用某个 API/库”
包含：正确的 import、调用方式、约束条件、常见陷阱、惯用模式
版本化管理，像 npm package 一样安装：npx tessl i cisco/software-security
Agent 无关（跨 Claude Code / Cursor / Gemini / 任何 Agent）
Model 无关（跨 GPT / Claude / Gemini / 任何 LLM）

Registry（注册中心）

3,000+ 已评估的 Skills
10,000+ 开源包的文档上下文
覆盖 npm 和 PyPI 生态
安全评分（与 Snyk 集成）
每个 Skill 有量化的 Agent 性能提升数据

Evaluation Framework（评估框架）

这是真正的护城河：

在隔离容器中运行 Agent 完成真实场景任务
量化指标：Abstraction Adherence（Agent 是否正确使用库的公共 API）
300+ 库的基准测试，结果：
- 平均提升 1.2x
- 低分库提升最高 3.3x
- Agent 不认识的库提升 1.4x
回归检测：当模型/库/Skill 更新时自动重跑评估

Agent 基线表现	使用 Tessl Tile 后提升
0-60%	1.4x
60-80%	1.2x
80-100%	1.0x（已经够好了）

为什么这很重要

问题的本质

Agent 写代码的核心失败模式不是”写不出来”，而是用错 API：

LLM 训练数据里的库版本可能已经过时
小众库或内部 API 不在训练数据里
Agent 会”猜”——代码能编译，但实现脆弱、难维护
越大的组织、越多的内部 API，问题越严重

类比：Agent 是一个”聪明但没经验的新人”。Tessl 做的是”入职培训资料库”——告诉这个新人”我们公司用什么库、怎么用、有什么坑”。

Tessl 的解法

传统：Agent 猜 API 用法 → 出错 → 人类 review → 修改 → 重试
Tessl：Agent 查 Tile → 精确知道 API 用法 → 一次做对 → 人类 review 通过

框架评估

维度 1: 时代定位 ⭐⭐⭐⭐⭐

精准站在 Vibe Coding / SSD 时代的结构性卡点上。

✅ 不是做 Agent（供应过剩），而是做 Agent 的”燃料”（结构性稀缺）
✅ Agent 无关、Model 无关——不赌谁赢，赌所有 Agent 都需要上下文
✅ 完美符合 “Make something agents want”
✅ 随着 Agent 数量增长，对 Tessl 的需求线性增长

陈天桥三阶段定位：基础设施层——不在 Enable/Native/Awaken 的轴上，而是在所有阶段都需要的底层。类比：不管你是用马车还是汽车，都需要加油站。

维度 2: 场景边界 ⭐⭐⭐⭐⭐

精准命中效率型场景中最痛的点：

Agent 用错 API → 反复修改 → 人类疲劳 → 放弃 Agent ❌
Agent 用对 API → 一次通过 → 人类信任 Agent → 更多使用 ✅

不碰连接型场景。纯粹的知识供应链。

维度 3: 叙事策略 ⭐⭐⭐⭐⭐

“The package manager for agent skills and context” — 一句话，完美类比。

开发者立刻理解：

npm 管理代码依赖 → Tessl 管理 Agent 的知识依赖
npm registry 有百万 package → Tessl registry 有千级 Skill
npm install → npx tessl i

SSD（Spec-Driven Development） — 更高层的叙事，对标 TDD（Test-Driven Development）的命名结构。开发者感觉”这是下一个范式”。

创始人的 Snyk 背景给叙事加了信用加持——“创造了 Developer Security 品类的人，现在在创造 Agent Context 品类”。

维度 4: 技术护城河 ⭐⭐⭐⭐

技术层级 L2-L3：

评估框架是核心护城河 — 在隔离容器中运行 Agent、量化 Abstraction Adherence、回归检测。这不是简单的包装，需要大量工程投入
Registry 数据飞轮 — 3,000+ Skills，每个带量化评估数据，社区贡献 → 更多 Skill → 更多用户 → 更多数据
Snyk 集成 — 安全评分是独特差异化（创始人的上一家公司）
版本匹配 — 确保 Tile 和实际库版本对齐，解决 LLM 训练数据过时问题

但：核心产品是”结构化文档 + 评估”，不是算法创新（非 L1）。理论上，一个足够大的团队可以复制这套系统。

维度 5: 竞争与护城河 ⭐⭐⭐⭐

直接竞品：

MCP（Model Context Protocol）— Anthropic 推的上下文协议，但 MCP 是协议层，Tessl 是内容层。互补大于竞争
Cursor Rules / Claude CLAUDE.md — 单项目级别的上下文，不是跨组织的注册中心
Smithery — MCP server registry，但偏向工具调用，不是知识上下文

护城河：

数据网络效应 — 更多 Skill → 更多评估数据 → 更好的推荐 → 更多用户
企业客户锁定 — 内部 API 的 private Tile 一旦建立，切换成本极高
创始人信用 — Guy Podjarny 的 Snyk 声誉 = 企业采购的绿色通道
评估数据壁垒 — 300+ 库 × 多个 Agent × 多个 Model 的交叉评估矩阵，后来者需要巨大投入才能追赶

风险：

GitHub Copilot 如果内置类似的 context registry → 最大威胁
Agent 变得更聪明后，是否还需要外部上下文？（长期风险）
MCP 如果扩展到覆盖知识上下文（不只是工具调用）→ 可能被吸收

关键洞察

好的地方

解决的问题是真的 — 每个用 Agent 写代码的人都遇到过”Agent 用错 API 版本”。Tessl 有 300+ 库的量化数据证明这个问题的普遍性
创始人是 category creator — Guy Podjarny 不是第一次创造品类。Snyk 证明了他能从零定义一个市场（Developer Security），现在做 Agent Context
商业模式清晰 — 开源 registry（增长引擎）+ 企业 private context（收入引擎）。和 Snyk 的模式一样，验证过的 playbook
评估框架是杀手锏 — 不只是”给你一个 Tile”，而是”告诉你这个 Tile 让 Agent 好了多少”。量化价值 = 企业采购的理由
Agent/Model 无关 — 不赌谁赢，赌所有 Agent 都需要上下文。这是最安全的赌注
企业客户已就位 — Cisco、HashiCorp/IBM、JetBrains 不是小客户

需要警惕的

GitHub 的阴影 — 如果 GitHub 在 Copilot 中内置 context registry，Tessl 的独立存在价值会被质疑。但创始人有经验（Snyk 也面对过 GitHub 内置安全扫描的竞争）
Agent 智能天花板 — 如果未来 Agent 训练数据覆盖了所有 API 文档，Tessl 的价值会缩水。但内部 API 永远需要外部上下文
“Tile 质量”依赖社区 — Registry 的价值取决于 Tile 质量。如果社区贡献的 Tile 质量参差不齐，会损害信任
$125M 融资 = 高期望 — 这个估值对应的是”成为品类标准”的预期。如果增长不够快，投资人压力会很大

与我们框架的连接

”协议即软件”的验证

回顾我们的分析框架——一旦成为某个 Agent 工作流里的默认调用，后来者便很难替代你。

Tessl 做的正是这件事：

npx tessl i hashicorp/terraform-stacks 一旦成为 Agent 工作流的标准步骤
所有 Agent 都依赖 Tessl registry 获取上下文
切换成本 = 重建所有 Tile + 重跑所有评估

对比 Linear AIG

Linear AIG	Tessl
定义 Agent 如何在平台中行动	定义 Agent 如何正确使用 API
交互协议	知识供应链
平台侧	Agent 侧
互补关系	互补关系

两者不竞争。一个 Agent 可以同时遵循 Linear AIG 的交互协议，并使用 Tessl 的 Tile 来正确调用 API。

Cloudflare 类比是否成立？

Cloudflare	Tessl
Web 的基础设施层	Agent coding 的基础设施层
CDN（让内容更快到达用户）	Registry（让知识更快到达 Agent）
不关心你用什么前端框架	不关心你用什么 Agent/Model
网站越多 → Cloudflare 越有价值	Agent 越多 → Tessl 越有价值
免费层 + 企业层	免费 Registry + 企业 private context

成立，但有一个关键区别：Cloudflare 的护城河是物理的（全球 CDN 节点），Tessl 的护城河是数据的（评估矩阵 + Tile 质量）。数据护城河比物理护城河更容易被攻破。

“新时代的 GitHub”？

过于乐观，但方向正确。

GitHub = 代码的 single source of truth + 协作平台。 Tessl = Agent 知识的 single source of truth + 评估平台。

差距在于：GitHub 拥有开发者的工作流（commit → PR → merge），Tessl 还没有拥有 Agent 的工作流。Tessl 目前是”Agent 的参考书”，不是”Agent 的工作台”。要成为”新时代的 GitHub”，Tessl 需要从 registry 扩展到工作流——但这可能不是他们的目标，他们更像”新时代的 npm”。

结论

这是我们案例库中第一个让我看到”品类标准”潜力的产品。

Tessl 做对了最难的一件事：不追 Agent 热潮，而是挖 Agent 热潮背后的结构性需求——Agent 需要正确的上下文才能工作。这个需求不会随某个 Agent 的衰落而消失，只会随 Agent 数量的增长而增长。

创始人是验证过的 category creator，融资充足（$125M），企业客户已就位（Cisco/HashiCorp/JetBrains），评估框架提供了量化价值证明。

最大的判断：Tessl 能否成为 Agent 上下文的”npm”？如果能——这是一个十亿美元级别的公司。如果只是一个好的企业工具——也是一个健康的 SaaS 业务。无论哪种结果，这都是 Agent 时代最值得关注的基础设施公司之一。

Product Hunter

探索

Case - Tessl - Agent技能的npm