1. 项目概述:从“感觉”到“技能”,重新定义AI智能体开发
如果你在过去一年里尝试过构建一个真正能在生产环境中稳定运行的AI智能体,大概率会和我有同样的感受:兴奋开始,混乱进行,最终陷入维护的泥潭。问题往往不在于大语言模型本身,而在于我们如何将那些模糊的业务逻辑——“感觉上应该这么处理”——转化为机器可以稳定、可靠执行的“技能”。这正是Refly试图解决的核心痛点。
Refly将自己定位为第一个开源的“Agent Skills Builder”(智能体技能构建器)。它不是一个简单的低代码工作流工具,也不是另一个需要你从头编写大量胶水代码的框架。它的核心思想是引入“技能”(Skill)这一概念,将你企业中的标准操作流程、业务逻辑封装成一个个原子化、可版本控制、可复用的执行单元。你可以把它想象成是给AI智能体世界带来了“函数”或“微服务”的概念,只不过这些“函数”是通过一种名为“Vibe Workflow”的模型原生DSL(领域特定语言)来构建的,整个过程更接近用自然语言描述你的意图。
我花了几天时间深度体验了Refly的社区版,从本地部署到构建第一个技能,再到将其导出为API和Claude Code工具。我的结论是:对于那些厌倦了在n8n、Zapier的图形化连线与LangChain、AutoGen的代码脚手架之间反复横跳的开发者来说,Refly提供了一个颇具吸引力的“第三条道路”。它试图在可视化构建的便捷性与代码级控制的灵活性之间找到一个平衡点,而其“技能即资产”的理念,可能是团队规模化部署AI应用的关键。
2. 核心理念与架构解析:为什么是“技能”,而不是“工作流”?
要理解Refly的价值,首先要厘清它提出的几个关键概念与传统自动化工具的区别。这不仅仅是术语的变化,背后是设计哲学的根本不同。
2.1 “技能”与“工作流”的本质区别
在传统的自动化平台(如n8n, Make)或AI应用平台(如Dify)中,核心构建块是“工作流”。一个工作流是一系列按顺序或条件执行的节点,它通常由某个事件(如Webhook、定时器)触发,执行完毕后结束。工作流是“一次性”的、黑盒的。如果你想在另一个场景复用其中的部分逻辑,通常需要复制整个工作流或手动提取节点,这导致了逻辑的碎片化和维护噩梦。
Refly提出的“技能”则不同。一个技能是一个确定的、原子的能力单元。它就像编程中的一个函数:有明确的输入、输出和执行逻辑,内部可以很复杂(包含多个步骤),但对调用者而言,它是一个黑盒接口。技能可以被版本化、被多个不同的工作流或智能体调用、被独立测试和部署。
举个例子:假设你有一个“生成周报”的业务需求。
- 传统工作流方式:你会创建一个包含“获取JIRA任务”、“查询GitHub提交”、“调用LLM总结”、“发送邮件到Slack”节点的工作流。这个工作流绑定于“每周五触发”这个场景。
- Refly技能方式:你会创建一个名为
generate_weekly_report的技能,它内部封装了上述所有逻辑。然后,你可以:- 创建一个定时工作流来调用这个技能。
- 在Claude Code中,让AI助手直接调用这个技能。
- 通过一个Slack命令触发这个技能。
- 在另一个需要报告摘要的复杂工作流中,将其作为一个子步骤调用。
技能变成了可组合的乐高积木,而工作流则退化为组装和调用这些积木的“胶水”。
2.2 Vibe Workflow:模型原生的构建体验
“Vibe Coding”或“Vibe Workflow”是Refly宣传的一个亮点。简单说,它允许你用自然语言描述你想让智能体做什么,系统会利用大语言模型的理解能力,自动生成或建议一个技能的工作流结构。
在实际操作中,这体现在两个层面:
- 引导式创建:当你新建一个技能时,可以选择“从描述创建”。输入如“一个能根据用户提供的产品URL,搜索竞品信息并生成市场分析报告的技能”,Refly的AI助手会尝试理解你的意图,并自动建议添加“HTTP请求(获取URL)”、“网络搜索”、“LLM分析”、“结构化输出”等节点,并初步连接它们。
- 节点配置辅助:在配置每个节点(如LLM节点)时,你可以用自然语言描述你希望这个节点完成的任务,系统会帮助你生成或优化提示词(Prompt)。
这大大降低了构建门槛,但重要的是,它生成的并非不可控的“黑魔法”。最终,你的意图被编译成Refly的Streamlined DSL——一种结构化的、可读的、可版本控制的配置。这意味着你既享受了AI辅助的便捷,又保留了代码级的可审查性和可控制性。
2.3 可干预运行时:打破执行黑盒
这是Refly与传统工作流引擎另一个关键区别。大多数工作流一旦触发,就会从头跑到尾,除非出错,否则你无法介入。对于涉及AI生成、外部API调用的复杂流程,这很危险。
Refly的运行时是状态化且可干预的。当一个技能执行时:
- 实时监控:你可以看到执行流经哪个节点,每个节点的输入输出是什么。
- 中途暂停与干预:如果LLM节点的输出不符合预期,你可以在运行时暂停执行,手动修正输入或调整参数,然后继续,而无需从头开始。
- 热修复:你甚至可以在技能运行过程中,直接编辑技能的逻辑(比如修改某个节点的提示词),然后让执行从当前点继续。
这对于构建高可靠性的生产级应用至关重要。它允许人类专家在关键决策点进行监督,确保AI的行为符合业务规则,实现了“人在回路”的混合智能。
3. 实战:从零构建并部署一个Refly技能
理论说得再多,不如亲手做一遍。下面我将以一个实际的例子,带你完整走一遍使用Refly构建、测试并部署一个技能的流程。我们的目标是构建一个“智能客服问答路由”技能:用户输入一个问题,技能能判断其所属类别(如“账单问题”、“技术故障”、“产品咨询”),并返回预设的解决方案模板或转接指引。
3.1 环境准备与部署
Refly提供了云工作空间供快速体验,但对于想要深度集成或关注数据隐私的团队,自部署是首选。官方推荐使用Docker Compose,过程非常顺畅。
步骤一:获取部署文件
git clone https://github.com/refly-ai/refly.git cd refly项目根目录下已经提供了docker-compose.yml文件,包含了Refly服务端、数据库(PostgreSQL)、缓存(Redis)等所有依赖。
步骤二:配置环境变量复制示例配置文件并进行关键修改:
cp .env.example .env你需要编辑.env文件,重点设置以下几项:
DATABASE_URL:确保PostgreSQL连接信息正确。ENCRYPTION_KEY:用于加密敏感信息,务必使用一个强随机字符串。OPENAI_API_KEY或ANTHROPIC_API_KEY:至少配置一个AI模型提供商,这是运行业务逻辑的核心。
实操心得:在本地测试时,数据库和Redis使用默认的Docker镜像即可。但在生产环境,强烈建议将数据库卷(volumes)映射到宿主机持久化目录,并考虑Redis的持久化配置,避免数据丢失。
步骤三:启动服务
docker-compose up -d等待所有容器启动完毕,通常需要一两分钟。之后,在浏览器中访问http://localhost:5700,你应该能看到Refly的登录界面。
步骤四:初始化账号与模型
- 首次访问需要注册一个账号。
- 登录后,点击右上角头像进入“Settings” -> “Model Providers”。
- 添加你的AI提供商(如OpenAI),并填入API密钥。
- 在“Chat Models”标签页下,点击“Add Model”,选择你刚配置的提供商(如OpenAI),然后选择具体的模型(如gpt-4o-mini)。将其设为默认模型。
至此,你的私有Refly平台就准备就绪了。
3.2 使用Vibe模式创建第一个技能
现在我们进入控制台,开始构建“客服路由”技能。
- 创建新技能:在首页点击“New Skill”。在弹出的窗口中,选择“Describe with AI (Vibe Mode)”。
- 描述你的意图:在文本框中输入:“创建一个客服问答路由技能。输入是用户的一段文本问题。技能需要先判断问题的类别,类别包括:‘账单与支付’、‘技术故障’、‘产品功能咨询’、‘账号管理’、‘其他’。然后,根据类别返回一个标准的回复模板,模板中应包含问候语、问题归类说明、建议的解决步骤或转接指引。”
- AI生成骨架:点击“Generate”,Refly的AI助手会解析你的描述,并自动生成一个技能的工作流骨架。你可能会看到它创建了以下节点:
- Input:定义输入参数,例如
user_query。 - LLM (Classifier):一个LLM节点,配置了系统提示词,要求它对输入进行分类。
- Switch:一个条件分支节点,根据分类结果路由到不同的分支。
- 多个 Text节点:每个分支对应一个,里面写着该分类的标准回复模板。
- Output:合并或选择其中一个分支的输出作为最终结果。
- Input:定义输入参数,例如
- 审查与调整:AI生成的骨架是一个很好的起点,但通常需要微调。你需要:
- 检查LLM节点的提示词:点击LLM节点,查看AI生成的系统提示词。你可能会发现它过于简单。我通常会将其修改得更具体、更具约束性,例如:
你是一个客服问题分类器。用户将输入一个问题。你必须且只能从以下五个类别中选择一个输出: 1. 账单与支付 - 涉及费用、扣款、发票、订阅等问题。 2. 技术故障 - 涉及软件无法使用、报错、连接失败、性能问题等。 3. 产品功能咨询 - 询问某个功能如何使用、是否有某功能、功能对比等。 4. 账号管理 - 涉及注册、登录、密码修改、账号绑定/解绑等。 5. 其他 - 不属于以上任何类别的问题。 只输出类别编号(1-5),不要输出任何其他文字。 - 完善回复模板:点击各个Text节点,将预设的模板修改得更符合你公司的口吻和实际流程。例如,对于“技术故障”,模板可以是:“您好!您遇到的问题属于【技术故障】。建议您:1. 尝试刷新页面或重启应用;2. 检查网络连接;3. 提供具体的错误截图。如果以上步骤无法解决,请转接至技术客服工单系统:[链接]。”
- 优化连接逻辑:确保Switch节点的输入是LLM节点的输出,并且每个分支条件设置正确(例如,
{{output}} == “1”对应“账单与支付”)。
- 检查LLM节点的提示词:点击LLM节点,查看AI生成的系统提示词。你可能会发现它过于简单。我通常会将其修改得更具体、更具约束性,例如:
- 保存技能:点击右上角的“Save”,为你的技能命名,例如
customer_service_router_v1。
3.3 测试与迭代:利用可干预运行时
技能构建完成后,立即测试是验证逻辑的关键。
- 运行测试:在技能编辑页面,点击右上角的“Run”。在输入面板中,填入测试用例,例如
user_query: “我上个月被多扣了一笔钱,怎么回事?”。 - 观察执行流:点击运行后,你会看到节点被依次高亮,数据流沿着连线移动。在LLM节点处,你可以展开查看其输入(你的提示词和问题)和输出(应该是一个数字“1”)。
- 关键:干预与调试:假设LLM节点错误地将一个技术问题归类为“其他”。你不必停止整个流程。你可以:
- 在执行到该节点时,暂停运行。
- 点击LLM节点,直接修改其输入或提示词。
- 点击“从该节点继续运行”。 这样,你就能在不重新触发整个技能的情况下,实时修正AI的“错误判断”,并验证后续流程是否正确。这个功能在调试复杂技能时无比高效。
- 版本控制:当你对技能满意后,可以创建一个新版本。Refly会保存每次发布的版本,你可以随时回滚到旧版本,这对于生产环境的稳定至关重要。
4. 技能的多渠道部署:一次构建,处处运行
技能构建完成并测试通过后,真正的价值在于将其部署到各种执行环境中。Refly提供了多种导出方式,这正是其“统一技能栈”理念的体现。
4.1 部署为REST API
这是最通用、最直接的集成方式。任何能发送HTTP请求的应用都可以调用你的技能。
- 获取API凭证:在Refly设置页面,进入“API Keys”,生成一个新的密钥。妥善保管,它代表了调用权限。
- 获取技能ID:在技能详情页或列表页,找到该技能的唯一ID。
- 发起调用:使用任何HTTP客户端(如curl, Postman, 或你应用中的代码)调用Refly的API端点。
curl -X POST http://localhost:5700/api/v1/skills/{skill_id}/execute \ -H “Authorization: Bearer YOUR_API_KEY_HERE” \ -H “Content-Type: application/json” \ -d ‘{ “input”: { “user_query”: “我的账号登录不上了,提示密码错误” } }’ - 处理异步响应:复杂的技能执行可能需要时间。API调用通常会立即返回一个
execution_id。你需要用这个ID轮询另一个API端点来获取最终结果。
这种异步模式确保了长时间运行任务的可靠性。curl http://localhost:5700/api/v1/executions/{execution_id} \ -H “Authorization: Bearer YOUR_API_KEY_HERE”
注意事项:在生产环境,你需要将
localhost:5700替换为你部署Refly的真实域名或IP地址,并配置好HTTPS。同时,考虑在调用方实现重试和超时机制,以处理网络波动或技能执行时间过长的情况。
4.2 集成到飞书/Lark或Slack机器人
将技能作为聊天机器人的后端,可以让非技术同事直接通过自然语言触发复杂的自动化流程。
以飞书/Lark为例,核心步骤是配置一个“事件回调”:
- 在Refly中启用Webhook触发器:打开你的技能设置,找到“Triggers”部分,启用“Webhook Trigger”。系统会生成一个唯一的Webhook URL,例如
https://your-refly.com/api/webhooks/trigger/abc123。 - 在飞书开放平台创建应用:
- 访问飞书开放平台,创建一个“企业自建应用”。
- 在“事件订阅”部分,将Refly提供的Webhook URL填入“请求地址”。
- 订阅“接收消息”事件。飞书会向你提供的URL发送一个包含挑战码的验证请求,Refly的服务会自动处理此验证。
- 发布应用,并将机器人添加到你的飞书群组中。
- 配置技能处理逻辑:你的技能需要调整输入,以接收飞书的事件数据。通常,你需要一个初始节点来解析飞书Webhook的JSON体,提取出
event.message.content中的用户消息,然后将其作为user_query传入后续的分类和回复逻辑。最后,输出节点需要格式化成飞书机器人API要求的响应格式,以便将消息发送回群聊。 - 测试:在飞书群里@你的机器人并提问:“账单有问题怎么办?”。消息会触发飞书事件,飞书服务器将事件POST到你的Refly Webhook URL,触发技能执行,并将结果返回给飞书,最终在群里呈现回复。
这个过程将一个复杂的AI决策流程,变成了一个简单的聊天交互,极大地提升了易用性。
4.3 发布为Claude Code或Cursor技能
这是Refly最前瞻性的功能之一。它允许你将技能直接转化为AI编程助手(如Claude Code、Cursor)可以调用的“工具”。
- 安装Refly CLI:这是一个命令行工具,用于管理技能。
npm install -g @powerformer/refly-cli - 登录并发布技能:
发布后,你的技能会出现在Refly的技能注册中心。refly login # 使用你的Refly账号登录 refly skill publish <your-skill-id> - 在Claude Code中使用:
- 在Claude Code的聊天界面,你可以通过特定的命令来添加技能,例如
@refly add customer_service_router。 - 添加后,当你在Claude Code中描述任务时,比如“帮我写一段代码,并分析一下如果用户反馈登录失败,客服应该怎么处理?”,Claude Code可以自动识别出需要调用
customer_service_router这个技能来获取标准的客服处理流程,并将其作为上下文或建议提供给你。
- 在Claude Code的聊天界面,你可以通过特定的命令来添加技能,例如
这意味着,你将企业的内部知识和工作流程,直接赋能给了开发者的AI编程伙伴,让AI助手不仅懂代码,也懂你的业务。
5. 进阶技巧与避坑指南
在实际使用Refly构建更复杂技能的过程中,我积累了一些经验教训,这些在官方文档中不一定着重强调。
5.1 技能设计模式:保持原子性与可组合性
- 单一职责原则:一个技能最好只做一件事,并且做好。不要构建一个“超级技能”来处理用户注册、发送欢迎邮件、分配客户经理、创建初始项目等所有事情。应该拆分成
register_user、send_welcome_email、assign_account_manager等多个原子技能。这样每个技能都更易于测试、维护和复用。 - 输入输出标准化:尽量使用简单、通用的数据结构作为技能的输入输出。例如,使用
{“query”: “string”}或{“data”: “object”}。避免在技能间传递过于复杂、嵌套很深的对象,这会增加耦合度和调试难度。可以在技能内部处理复杂逻辑,但对外接口保持简洁。 - 版本命名策略:为技能版本使用语义化版本控制,如
v1.0.0。重大逻辑变更升级主版本号(v2.0.0),新增功能升级次版本号(v1.1.0),问题修复升级修订号(v1.0.1)。在调用API时,可以指定版本号,确保上游应用不会因技能更新而意外崩溃。
5.2 性能与成本优化
- LLM调用优化:LLM节点通常是技能中最耗时、最昂贵的部分。
- 缓存:对于输入相同、输出确定的LLM调用(如分类、标准化),可以在Refly中尝试配置缓存(如果支持),或者自己在技能前添加一个检查缓存(如Redis)的节点。
- 精简提示词:不断优化你的系统提示词,移除不必要的指令和示例。使用更高效的模型(如
gpt-4o-mini而非gpt-4o)处理简单任务。 - 并行化:如果技能中有多个独立的LLM调用(例如,同时分析一份文档的情感、主题和关键实体),尝试使用Refly的“并行执行”节点(如果可用)或拆分成子技能并行调用,而不是顺序执行。
- 错误处理与重试:对于调用外部API(如数据库、第三方服务)的节点,务必配置合理的超时时间和重试策略。Refly的节点配置中通常有相关选项。对于非致命错误,考虑使用“条件分支”节点来提供降级方案(例如,调用A服务失败后,尝试调用备用的B服务,或返回一个友好的默认值)。
5.3 常见问题与排查
技能执行超时或卡住:
- 检查点:首先在运行日志中查看执行停在了哪个节点。
- 外部依赖:最常见的原因是外部API响应慢或未响应。检查该节点的超时设置,并尝试在外部测试该API。
- LLM问题:如果卡在LLM节点,可能是提示词导致模型陷入了长思考或循环。简化提示词,或增加
max_tokens限制。 - 资源限制:检查服务器资源(CPU、内存)是否充足,特别是同时运行多个复杂技能时。
Webhook触发失败(如飞书收不到回复):
- 验证URL:首先确认飞书开放平台配置的Webhook URL完全正确,且网络可达(公网可访问)。
- 查看Refly日志:在Refly的管理后台或服务器日志中,查看是否有飞书的事件请求进来,以及技能是否被触发。
- 检查技能输出格式:飞书、Slack等平台对机器人返回的消息格式有严格要求。确保你技能的最后输出节点生成的JSON结构符合对应平台的API文档。一个常见的错误是返回了纯文本,而不是平台要求的
{“msg_type”: “text”, “content”: {“text”: “你的回复”}}这样的结构。 - 权限与加密:确认飞书应用的事件订阅已成功通过验证,并且所需的权限(如发送消息)已开通。
Claude Code中找不到已发布的技能:
- 确认发布状态:使用
refly skill list命令查看技能是否已成功发布且状态为公开。 - 检查CLI版本:确保你安装的Refly CLI是最新版本。
- 技能命名:避免使用特殊字符或过长的名字,可能在某些环境下兼容性不好。
- Claude Code插件:确认你已在Claude Code中正确安装并配置了Refly插件,并且已登录同一个账号。
- 确认发布状态:使用
经过这一番深入的探索和实践,Refly给我的感觉更像是一个“智能体时代的后端即服务”。它不试图取代你的整个应用,而是专注于解决AI智能体与真实世界交互中最混乱、最易出错的那一层——业务逻辑的封装与执行。将飘忽不定的“Vibe”转化为稳定可靠的“Skill”,这个想法本身就极具价值。对于中小团队和独立开发者,它大幅降低了构建生产级AI应用的门槛;对于大型企业,其技能注册中心和治理能力为规模化部署提供了可能。当然,作为一个较新的开源项目,它在企业级功能(如细粒度权限控制、更复杂的计费)和社区生态上还有很长的路要走。但如果你正在为如何让AI智能体可靠地执行具体任务而头疼,Refly绝对值得你花一个下午的时间去深度尝试一下,它可能会彻底改变你构建AI应用的方式。