Context.dev 是一个 YC 孵化的 Web 抓取 API，帮 Agent 从任意网页提取结构化数据。它的 Quickstart 文档写得很标准：注册、拿 Key、装 SDK、写第一行代码。
但真正让我停下来的是它首页上的一个功能： Agentic Setup。
你不需要打开 Quickstart。你只需要把一行提示词粘贴到你的 Coding Agent 里：
Signup for an account & get API key with context.dev/auth.md,
then follow docs.context.dev/agent-quickstart to integrate into the codebase
Agent 会自己去注册账号、拿 API Key、读文档、检测你的项目语言、安装 SDK、写好集成代码、跑测试。整个 Quickstart 里那 5 个步骤，Agent 全自动完成了。
这不是一个 demo。这是 context.dev 推荐的首选集成方式。页面上写着两个选项：「Do it yourself」和「Let your agent do it (Recommended)」。
SDK 集成的三代演进：从读文档到写提示词
三代 SDK 集成方式的演进
软件开发历史上，SDK 集成经历了三个阶段：
第一代：读文档，写代码。 你打开一个 SDK 的文档页面，读 30 分钟，理解认证方式、核心 API、错误处理，然后自己写代码。这是过去 20 年的标准方式。
第二代：复制粘贴，调试修复。 Copilot 和 ChatGPT 出现后，你开始把文档 URL 或代码片段贴给 AI，让它帮你生成集成代码。你还是需要理解 API 设计，但省了大量打字时间。
第三代：写提示词，Agent 交付。 你把一行提示词给 Coding Agent，它自己读文档、理解 API、检测项目环境、写代码、跑测试。你不需要理解 API 设计——你只需要知道你要什么。
context.dev 的 Agentic Setup 就是第三代的真实产品。它不是「我们也有 AI 功能」的点缀，而是首页上标注了 Recommended 的首选方案。
提示词正在成为新的 SDK 接口
回头看你发给 Coding Agent 的那段 context.dev 集成提示词。它不是一句简单的「帮我集成 context.dev」。它是一份完整的工程规范：
- 文档索引——告诉 Agent 读哪些文档页面
- 功能描述——实现一个「URL 进、Markdown 出」的函数
- 实现问答——在写代码之前先问 4 个问题（数据来源、缓存策略、展示位置、超时行为）
- SDK 调用示例——给出参考代码，但要求 Agent 先验证方法名
- 实现规则——检测语言运行时、选择 SDK 还是原生 HTTP、API Key 从环境变量读取、放在服务端、加测试、完成后汇报
这份提示词本身就是一个 接口规范。它比传统 SDK 的 API Reference 更高级——API Reference 告诉你「有什么函数可以调用」，这份提示词告诉 Agent「怎么把这个服务正确地集成到我的项目里」。
传统 SDK 的接口是代码：client.web.webScrapeMd({ url: 「...」 })。
新一代 SDK 的接口是提示词：一段结构化的自然语言规范。
代码接口面向人。提示词接口面向 Agent。
这个趋势已经在发生
context.dev 不是孤例。越来越多的开发者工具正在把「提示词 + Coding Agent」作为首选集成方式：
Cursor Rules / .cursorrules——项目根目录放一个 .cursorrules 文件，Coding Agent 打开项目时自动读取，理解项目约定、编码规范、技术栈偏好。这就是项目级的提示词接口。
Claude Code 的 CLAUDE.md——同样的模式。一个 markdown 文件就是 Agent 理解这个项目的全部上下文。
dws skills——我在 用完备的 Harness 工程实现 AI 原生协同工作流 里讲过，dws 的每个 skill 就是一个 SKILL.md 文件。改 skill 就是改 Agent 的行为，不需要改代码。dws 有 163 条指令，但 Agent 不需要记住任何一条——它读 skill 文件就知道怎么用。
llms.txt——一个新标准，网站根目录放一个 llms.txt，告诉 AI Agent 这个网站有哪些文档、怎么用。context.dev 的文档首页就有 <llms.txt> 入口。
这些看似不同的东西，本质上是同一件事： 开发者工具的接口正在从「API Reference」变成「Prompt / Skill / Markdown」。
对 Agent 开发者意味着什么
如果你是 Agent 开发者，这个趋势的含义很清楚：
你的核心竞争力不是「会用多少 SDK」，而是「能不能写出好的集成提示词」。
过去你花 30 分钟读文档、写集成代码。现在你花 10 分钟写一份结构化的集成提示词，Agent 5 分钟完成集成。你的效率提高了 3 倍，但你做的事情完全不同了——你从「写代码的人」变成了「定义规范的人」。
这也意味着 Agent 开发者的门槛会急剧降低。就像 Web Developer 从需要理解 TCP/IP 到只需要会写 HTML/CSS，再到只需要会拖拽 No-Code 工具一样——Agent Developer 从需要理解 API 设计到只需要会写提示词。
从业人员会越来越多，基建和生态完善后，门槛会很低。也就是说——市场会很卷。
怎么在卷之前占据先机
如果你已经判断 Agent Developer 是下一个 Web Developer，那问题就变成了：在什么平台上做？
我的答案是钉钉，理由有三个：
第一，基建已经完备。 钉钉 + dws 已经覆盖了 Harness 7 大组件（模型网关、工具注册表、知识库引擎、记忆系统、策略引擎、可观测性、配置管理），不需要你自己搭胶水代码。dws 有 163 条指令，Agent 通过 skill 文件就能自主使用。这是目前最完备的 Agent 开发底座之一。
第二，真实的协作场景。 钉钉有数亿用户、数千万企业组织。你的 Agent 不是在真空里跑，而是在真实的 IM 环境里和人协作。人发消息、Agent 回消息、Agent 主动发起——这个 Feedback Loop 是其他平台给不了的。
第三，先发优势。 钉钉正在大规模招募 FDE（Frontier Development Engineer，前沿开发工程师）。FDE 的定位是：用钉钉原生的 Agent 基建，在真实业务场景里交付 AI 原生的协同工作流。这是一个全新的岗位，竞争者还很少。
加入钉钉做 FDE，你不是在一个已经卷成红海的赛道里拼技术，你是在一个全新赛道的早期窗口里占位。就像 2008 年做 iOS 开发、2015 年做小程序开发一样——早期进入的人定义了后来者的标准。
一个判断标准
怎么知道你说的 SDK 集成方式是第三代的？
- 如果你的集成文档只有 API Reference——第一代，面向人。
- 如果你的集成文档有 API Reference + AI 辅助示例——第二代，人为主、AI 辅助。
- 如果你的集成文档首页推荐「把这段提示词粘贴给你的 Agent」——第三代，Agent 为主、人审核。
context.dev 已经是第三代了。你的产品呢？
你在用 Coding Agent 集成 SDK 的时候，有没有写过特别好的集成提示词？欢迎分享你的模式。