使用Cline SDK构建智能体

# 使用 Cline SDK 构建一个 Agent 来源：https://packagemain.tech/p/building-an-agent-with-the-cline-sdk [](https://substackcdn.com/image/fetch/$s_!86SY!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Ff9ee246e-795a-464e-a37e-247430ae8b35_2786x1554.png) Cline (https://cline.gg/alex) 是一个专注于真实软件工作的开源 AI 编码 agent。大多数开发者初次接触 Cline 是在编辑器或终端中作为助手，但 Cline 不止于单一界面。 它同时拥有 **CLI** 和 **SDK**： - **CLI** 用于直接从终端运行 agent 工作流 - **SDK** 用于将相同的 agent 运行时嵌入到你自己的脚本、产品、CI 任务和内部工具中 这种区别很重要。在 Cline SDK 发布公告 (https://cline.bot/blog/introducing-cline-sdk-the-upgraded-agent-runtime) 中，团队解释说最初的产品始于 VS Code 扩展，随着时间的推移，运行时变得难以与周围的 IDE 分离。SDK 正是为了解决这个问题：agent 运行时被视为一个共享服务，而不是隐藏在一个应用程序内部的实现细节。 这也是为什么 SDK 比一个简单的 API 封装更有趣——相同的运行时现在在 CLI 和 IDE 界面上为 Cline 提供支持，同时保持开放，允许其他团队将其嵌入到自己的产品中。底层的 agent 循环保持可复用，而围绕它的有状态运行时变得更加持久、可移植且与产品无关。 SDK 文档将 Cline SDK 描述为一个开源的 **TypeScript** 框架，用于构建 agent 应用程序。发布公告还补充了几个重要理念： - Cline 2.0 构建为一个分层的 TypeScript 栈 - 团队可以从较小的功能面开始，后续再添加更多运行时组件 - 运行时通过工具、插件、MCP 服务器、技能和钩子进行扩展 - 提供商选择不锁定单一模型供应商 这使得 TypeScript 成为第一个项目的自然选择。 在本文中，我们将构建一个小型的发布说明生成器，使用 Cline SDK 检查最近的 git 历史记录，并将其转化为可读的 Markdown。 [](https://substackcdn.com/image/fetch/$s_!Hbzr!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Faefe5459-a3a0-42e0-9b00-a7e708b565a2_1422x673.png) 这个发布说明项目很小，但它非常适合 SDK，因为它使用了 Cline 最重要的部分：用于工具使用型 agent 的运行时。 我们并不是要重建整个 Cline 产品。我们只是借用运行时的结构： - 定义一个专注的工具 - 将该工具交给一个 agent - 让 agent 检查真实项目状态 - 将结果转化为有用的制品 这种模式与 Cline 团队在发布公告中对 SDK 的定位高度一致：你可以将其嵌入到脚本、内部工具、CI 工作流和其他产品界面中，而不仅仅是 IDE。 该项目暴露了一个命令： 它专精于一项工作： 1. 启动一个 Cline agent 2. 给 agent 一个自定义工具 `get_recent_commits` 3. 让该工具从当前仓库读取最近的 git 历史 4. 让 agent 将这些数据转化为发布说明 5. 将结果输出到 stdout 有趣的部分并不是 CLI 本身。有趣的部分是架构：我们的应用程序提供了一个狭窄但有价值的能力，而 Cline 运行时决定如何使用它。 这正是 SDK 所要解决的问题类型。正如发布公告所说，运行时不再应该只存在于一个 UI 界面内。它是你可以引入自己栈中的东西。 ``` cline-demo/ ├── .env.example ├── package.json ├── tsconfig.json └── src/ ├── git.ts ├── index.ts └── prompt.ts ``` Cline SDK 需要 **Node.js 22+**。 安装依赖： 创建你的环境文件： 然后填写你的 OpenAI 密钥： 该项目使用 Cline 的 `openai-native` 提供商。 在任何 git 仓库内运行： 这是入口点。它做三件事： - 解析 `--since` 参数 - 创建自定义工具 `get_recent_commits` - 运行一个 Cline `Agent` 并打印最终结果 核心结构故意保持小巧： 这是需要记住的思维模型：**你的应用程序定义工具，Cline 提供 agent 运行时**。 换句话说，我们不是自己重新实现 agent 编排。我们复用了 Cline 内部使用的同一个理念：一个可以推理、调用工具并产生最终制品的运行时。 这个文件将仓库访问逻辑与主程序分离。 它使用： - `git log` 收集最近的提交 - `git show --name-only` 收集每个提交中变更的文件路径 每个提交以结构化数据返回： - sha - shortSha - author - date - subject - body - files 这种结构很重要。它为模型提供了足够的上下文，以推断变更属于功能、修复、维护任务还是可能需要升级说明的事项。 这个文件包含提示词约定。 系统提示告诉 agent： - 在回答之前调用 `get_recent_commits` - 只使用工具证据 - 只返回 Markdown - 将答案组织为： - 概览 - 功能特性 - 修复 - 文档/杂项 - 升级说明 将提示词分开使得项目更容易解释和修改。运行时代码保持小巧，而输出规则集中在一个地方。 项目中最重要的部分是工具定义： 如果没有这个工具，agent 只会重写我们粘贴到提示词中的文本。有了这个工具，它可以通过受控接口主动检查仓库。 这就是 SDK 变得有趣的地方：它不仅仅是一个文本包装器包裹模型。它是一个用于工具使用型 agent 的运行时。 如果这个项目未来需要扩展，SDK 已经为此留出了空间。Cline 团队将插件、自定义工具、MCP 集成、技能和多 agent 能力列为扩展点。我们在这里故意没有全部使用它们，但了解简单版本和更高级版本可以建立在相同基础上是有用的。 发布说明在 agent 自动化中处于一个甜点区域： - 输入杂乱但结构足够可供检查 - 输出有明确的形状 - 该任务在真实项目中有用 - 问题足够狭窄，可以快速理解 换句话说，这不是一个玩具聊天机器人，但也不是一个过度设计的自主系统。它是一个可信的 SDLC 自动化组件。 以下是该工具生成的 Markdown 示例： Cline 的 CLI 版本是关于**从终端使用** agent。SDK 版本是关于**将 agent 嵌入到你自己的软件中**。 这也是 Cline SDK 发布背后的主要理念：将运行时从单一产品界面中抽离出来，使其可复用，并让其他开发者在其基础上构建。 本项目以紧凑的形式展示了这一理念： - 定义一个有用的工具 - 将其交给 Cline agent - 让 agent 检查真实项目数据 - 将结果转化为精致的制品 一旦掌握了这种模式，同样的结构可以复用于 PR 摘要、变更日志草稿、测试计划生成、问题分类以及其他软件交付工作流。 - 源代码 (https://github.com/plutov/packagemain/tree/main/cline-demo) - Cline (https://cline.gg/alex) - Cline SDK (https://cline.bot/sdk)