WorkBuddy接到阿里云百炼上，这件事我拖了一个星期才动手。不是因为难，而是总觉得现在用的模型还能凑合，没必要折腾。直到有一次跑一个自动签到的定时任务，它连续三次在关键步骤上犯了同样的逻辑错误，我才意识到问题不在WorkBuddy本身，而在背后的大模型。换上百炼的通义千问之后，同一套任务流程一次就过，输出质量稳定多了。这篇就完整记录我是怎么把WorkBuddy的模型入口切到阿里云百炼的，包括账号准备、配置步骤、自定义指令和Skill的搭配，以及我踩过的几个坑。适合已经在用WorkBuddy但觉得模型效果不够好的人，也适合刚接触想少走弯路的新手。

1. WorkBuddy 是什么？为什么我最终选了阿里云百炼

1.1 WorkBuddy 的本质：终端里的 AI 工作流代理

很多人第一次听说WorkBuddy，会以为它又是一个聊天机器人。其实它不是。WorkBuddy是跑在终端里的AI代理，你给它一个目标，它可以自己拆解步骤，自己调用命令、读写文件、执行脚本，然后根据执行结果决定下一步动作。你可以把它理解成一个坐在你服务器或电脑面前的实习生，你只告诉它“我要什么”，它自己想办法完成。这种工作方式特别适合那些需要反复操作、只有一堆命令行工具却没人愿意一步步敲的场景。

我最初用WorkBuddy是为了维护几个自动化脚本。平时手动执行很繁琐，而WorkBuddy能直接读取代码、定位问题、改代码，甚至帮我跑测试。它和Claude Code这类工具属于同一赛道，区别在于WorkBuddy更强调本地工作流的可定制性，尤其是自定义指令和Skill这两个功能，能把常用操作沉淀成固定资产。热词里很多人拿Claude Code和WorkBuddy对比，我的感受是：Claude Code更偏“开箱即用的编码代理”，而WorkBuddy更像一个“能按你的规则办事的执行框架”，尤其在接外部模型这件事上，WorkBuddy的灵活性高不少。

1.2 默认模型的问题：质量不稳定，成本还不透明

很多同类工具默认用自己的云端模型，WorkBuddy在桌面版或某些版本里也一样。我用了一段时间，发现两个问题。首先是逻辑稳定问题，遇到多步骤任务时，默认模型偶尔会“偷懒”，比如自动签到脚本需要先判断元素存不存在，再进行点击，它经常跳过判断直接点击，导致失败。其次是成本，按额度或者按token计费时，默认模型的单价并不透明，跑一次大型重构可能会消耗大量额度。

最让我受不了的是：一个任务失败后，你需要不断重复描述错误信息，模型才能意识到自己哪里错了。有时候同一类错误会反复出现，反而浪费了大量时间。这时候我开始考虑换模型，于是把目光放到阿里云百炼上。

1.3 阿里云百炼的四个优势

换成阿里云百炼后，我的体感提升明显。百炼是阿里云的大模型服务平台，可以调用通义千问系列模型，同时也提供OpenAI兼容接口。我选择它的原因可以归结为四件事：

• 兼容性好：百炼的API兼容OpenAI格式，WorkBuddy可以通过OpenAI兼容模式直接对接，不需要特殊插件。
• 国内访问稳定：服务部署在国内，不需要额外的网络设施就能稳定访问，延迟相对可控。
• 模型覆盖面广：从轻量的qwen-turbo到强推理的qwen-max，再到代码专用的qwen-coder系列，按任务选择空间大。
• 计费透明：百炼控制台有详细的用量账单，每个模型的定价是公开的，我可以按预算选模型。

这四点里，前两点对我来说最实际。一个能直接对接、访问稳定的API，是WorkBuddy这种终端工具能长期跑下去的前提。后面你配置的时候会发现，正是因为兼容OpenAI接口，整个接入过程比想象中简单。

2. 接入前的准备：账号、API Key 与模型选型

2.1 开通百炼服务并创建 API Key

接入的第一步不是碰WorkBuddy，而是先去阿里云百炼控制台把钥匙拿到手。具体路径是这样：注册并登录阿里云账号，在控制台搜索“百炼”，进入百炼管理页面。首次使用需要开通百炼服务，这一步是免费的，开通后找到页面左侧的“API-KEY”菜单，点创建密钥，会生成一串以 sk- 开头的字符串。这个字符串就是WorkBuddy调用百炼模型的凭证，建议复制后先存到一个安全的地方，因为关闭弹窗后再完整查看的机会并不多。

这里有个容易卡住的点：有些账号需要先完成企业认证或实名认证才能正常调用。我一开始用的个人账号，开通服务没问题，但第一次发请求时报了权限错误，去控制台一看，是实名认证等级限制了API调用。所以如果你的WorkBuddy接上后返回 InvalidApiKey 或者 Forbidden ，不要急着怀疑配置，先检查账号认证状态。

2.2 模型选型：qwen-系列该怎么选

百炼上的模型很多，但接入WorkBuddy之后，真正需要关心的就那几个。我整理了一张表，是我自己实测下来的选择结论：

模型	适用场景	速度	单价	我的建议
qwen-turbo	简单问答、分类、格式化	最快	低	日常批量任务用
qwen-plus	中等复杂度任务、脚本编写、数据整理	快	中	主力模型，综合性价比最高
qwen-max	复杂推理、长文档分析、难度大的代码重构	中	高	只在高难度任务时切
qwen2.5-coder-7b-instruct	代码生成、代码补全、Debug	快	低	写代码时可以单独给WorkBuddy切到这个模型

WorkBuddy通常在一个会话里只能指定一个模型，所以我会用主力 qwen-plus 跑日常，遇到特别复杂的任务再手动切到 qwen-max 。如果你的任务以写代码为主，那可以直接把默认模型设为coder系列，代码理解能力会更聚焦。热词里有人问“workbuddy和豆包哪个好用”，其实选了百炼之后，豆包、DeepSeek这些都可以通过类似方式接进来，关键看你想要什么模型能力。

2.3 确认 WorkBuddy 的版本和配置入口

在配置之前，最好先确认一下你本机的WorkBuddy版本。在终端里运行：

workbuddy --version

不同小版本的配置方式会有差异，我用的版本是0.7.x，支持两种方式：环境变量和配置文件。如果你看到的是0.6.x或更早，可能只支持环境变量，不急着升级，先用环境变量跑通，后面再考虑迁移到配置文件。

配置文件的位置可以在终端里运行：

workbuddy doctor

它会列出当前版本、数据目录、配置目录等基础信息。看到实际路径后，再往里面写配置，就不会找错地方。顺带说一句，如果你是第一次安装WorkBuddy，装完后先跑一次初始化命令，确认能正常对话，再来接百炼，这样排查问题时不容易混在一起。

3. 三个步骤把 WorkBuddy 切到百炼 API

3.1 方法 A：环境变量方式（适合临时切换）

环境变量是最快、也最容易回滚的方式。如果你用的WorkBuddy版本适配了OpenAI兼容接口，可以在当前终端会话里直接设置：

export OPENAI_API_KEY="sk-你的百炼key"
export OPENAI_BASE_URL="https://dashscope.aliyuncs.com/compatible-mode/v1"
export WORKBUDDY_MODEL="qwen-plus"

设置后启动WorkBuddy，发送一条“你好”测试一下。能正常收到回复，说明已经接上了。

这里要注意两点。第一， OPENAI_BASE_URL 一定要带 /compatible-mode/v1 ，很多人只填到 https://dashscope.aliyuncs.com ，导致WorkBuddy在请求 /chat/completions 时拼出错误的地址，报404。第二，环境变量方式只对当前终端窗口有效，关掉终端就失效了。如果你希望长期使用，建议配合配置文件。

3.2 方法 B：配置文件方式（适合长期使用）

长期使用我更推荐配置文件方式。在确认配置目录后，找到WorkBuddy的配置文件，比如 config.json ，在JSON里加入以下内容：

{
  "provider": "openai",
  "api_base": "https://dashscope.aliyuncs.com/compatible-mode/v1",
  "api_key": "sk-你的百炼key",
  "model": "qwen-plus",
  "max_tokens": 8192,
  "temperature": 0.7,
  "timeout": 120
}

配置好之后，重启WorkBuddy让它重新加载配置。如果你的版本不支持 provider 字段，可以直接删掉它，默认就会按OpenAI兼容模式走。

为什么我建议配置 /compatible-mode/v1 这个路径？因为百炼同时提供了原生DashScope API和OpenAI兼容API两套接口。原生接口的协议和OpenAI格式有差别，WorkBuddy这类工具不一定直接支持。而 /compatible-mode/v1 是百炼官方为兼容OpenAI调用而提供的路径，工具可以直接复用现成的OpenAI客户端逻辑，省去中间翻译层，问题也少一些。

3.3 验证是否接通：第一条消息和调试日志

配置完成后，我习惯先用一条明确的指令来验证，而不是直接跑复杂任务。比如：

请确认你当前使用的模型名称和API基础地址，并输出在你之后执行任务时会在哪一步读取这两个信息。

这条指令会逼模型自己反馈上下文里的配置信息。如果回答里显示的是 qwen-plus 和 dashscope.aliyuncs.com ，说明已经接通。

如果没反应或者报错，可以开启WorkBuddy的调试日志。通常命令是：

workbuddy --debug

在调试输出里重点看两个地方：一是请求URL是不是 https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions ，二是HTTP状态码。如果是401，查API Key；如果是404，查base URL结尾；如果是429，说明触发了限流，等一下再试或者降低并发。

3.4 常见配置项的作用参考表

WorkBuddy和百炼对接时，有几个参数会直接影响体验，我列成表格方便对照：

配置项	建议值	作用说明
api_base	dashscope的compatible-mode地址	决定请求发到哪里
model	qwen-plus / qwen-max 等	决定用哪个模型推理
max_tokens	8192	控制单次回复最长长度，太长会拖慢首字返回
temperature	0.7	控制随机性，代码任务可以降到0.2
timeout	120	防止长任务被误判超时
stream	true	开启流式输出，边生成边显示，体感更快

其中 stream 在配置里不一定叫这个名字，如果你的版本支持，尽量开启。因为终端工具跑复杂任务时，流式输出能让你第一时间看到模型在干嘛，而不是干等着转圈。接入百炼之后，我第一件事就是把 stream 打开了，整个人感觉从“发邮件等回执”变成了“看实况直播”。

4. 让百炼模型在 WorkBuddy 里更好用：自定义指令与 Skill

4.1 自定义指令：把项目规范固化到每次对话

WorkBuddy的“自定义指令”是我最喜欢的功能，简单说就是给AI设定一套固定的行为规则，它会在每次任务开始时自动加载。接入百炼模型后，这套指令依然有效，而且对通义千问这类模型特别管用。

我的做法是给每个项目建一个 .workbuddy/instructions.md ，里面写清楚约束。比如我维护一个店铺数据采集项目时，会写：

- 每次读取数据前，先检查文件是否被其他进程占用
- 写入文件之前，先备份原文件到 archive/ 目录
- 所有脚本运行前必须打印一句“开始执行”和“执行结束”
- 遇到异常时不要擅自继续，先输出可能的解决方案再询问我

这些规则写明白后，百炼模型会在每次任务中记住约束，减少它“自由发挥”的概率。实际测试下来，输出稳定性至少提高了一半。自定义指令的写法并不难，关键是明确、条目化，不要写一堆形容词，AI更需要的是可执行的判断标准。热词里有人问“workbuddy自定义指令怎么写”，答案就是：别写废话，写边界条件，写失败处理，写输出格式。

4.2 Skill：把常用能力打包成可复用技能

如果说自定义指令是“规则”，那Skill就是“工具包”。我在WorkBuddy里会搭配几个Skill来减少重复劳动。

以“自动签到”为例，我会建一个叫 auto_checkin 的Skill，内部包含：

• 登录网页并获取cookie的脚本模板
• 判断是否已签到的正则表达式
• 签到成功后返回的消息格式
• 失败时需要截图并发送通知的逻辑

然后在WorkBuddy里输入“用auto_checkin处理当天的签到任务”，它会自动加载Skill里的步骤，结合百炼模型的能力执行。这时候模型的作用是理解任务、调度脚本、处理异常，而脚本本身是我提前验证过的，成功率会高很多。

Skill和百炼模型是互补关系。模型提供推理和生成能力，Skill提供确定性的操作流程。我建议你把那些“你闭着眼都会做，但AI每次都会复述一遍”的操作，尽量沉淀成Skill。这样每次跑任务时，AI只需要去执行，不需要重新发明轮子。

4.3 针对通义千问的 Prompt 细节

通义千问和Claude系模型在Prompt敏感度上略有不同，接入百炼后我发现几个值得注意的点。

第一，指令要带“格式预期”。比如我让它输出JSON，如果只说“生成JSON”，它偶尔会在JSON前后加解释。但我在自定义指令里写清楚“只输出JSON，不要任何额外文字”之后，问题基本消失。这个差异在Claude上没那么明显，确定模型后值得专门调一版指令。

第二，代码任务中加“约束条件”。通义千问的coder模型对“你只能修改XX文件”这类约束理解得比较透。所以我在写代码类任务时，一般会明确“不要动test/目录”、“不要修改已有的函数签名”，避免模型自作主张。

第三，长任务尽量分步。百炼模型不是不能处理长会话，但终端工具一次会传入大量上下文，超长上下文后，理解准确率会下降。我通常把一个大需求拆成“先列方案，再写代码，最后跑测试”三步，每一步单独下指令，效果明显好于一次性丢一大段需求。

5. 实测表现与性能调优：从“内容输出慢”到跟手

5.1 内容输出慢的根因排查

接入百炼后，我最先遇到的问题是“内容输出慢”。一开始以为是网速问题，后来发现不是，问题出在三个环节。

第一， max_tokens 设得太大。如果你设成32768，模型会倾向于生成更长的内容，响应时间自然变长。我调整到8192后，日常任务速度提升明显。

第二，没有开启流式输出。WorkBuddy如果不开启stream，会等模型生成完整内容后才一次性显示，体感就是“卡半天然后突然涌出”。开启流式输出后，文字是边生成边显示的，从用户视角看会流畅很多。

第三，网络请求方式。某些版本的WorkBuddy默认走HTTPS代理或本地代理中转，如果这台机器上还跑着别的网络服务，可能会抢连接或延迟。可以尝试把代理环境变量临时清掉，比较一下响应速度。

5.2 模型参数调整：让回复更贴近需求

WorkBuddy里可以调整模型参数。我在不同任务上总结了这几组参数：

任务类型	temperature	top_p	推荐模型
代码生成修正	0.2	0.9	qwen2.5-coder系列
数据提取整理	0.4	0.9	qwen-plus
文案写作	0.8	0.95	qwen-max
多步任务规划	0.3	0.8	qwen-plus

这里最重要的是 temperature。很多人在终端工具里期待AI稳定执行，但默认temperature是0.7，随机性偏大。跑代码任务时我建议降到0.2或0.3，输出会更稳定。文案写作再调高，让表达更灵动。

5.3 限流（429）与并发控制

百炼的API是按QPM和TPM等指标限流的，普通个人用户开通后，qwen-plus的并发额度并不高。如果WorkBuddy同时跑了多个任务，很容易撞上429。

我的处理方式是：不用WorkBuddy内置的高并发任务功能跑大批量请求，而是在WorkBuddy外面套一层队列。比如要处理100个文件，就写一个bash脚本，每次只并行3个任务，每个任务结束后间隔1秒。这样既不会触发限流，也不会把API额度一次性烧光。

另外，遇到429时不要无脑重试。百炼返回的响应头或错误信息里通常有建议等待时间，WorkBuddy的调试日志里能看到。手动等几秒再继续，比快速重试几十次更靠谱。

5.4 清理临时目录：解决 C 盘膨胀和 502 write EACCES

这部分算是环境问题，但很影响用户体验。WorkBuddy在跑任务时会在临时目录存工作文件，我用了一个星期，C盘就被占了几个GB。更麻烦的是，存储目录的权限不对时会出现 502 write EACCES 错误，任务直接中断。

解决方式很简单，把WorkBuddy的临时目录改到空间大、权限可控的位置。你可以在配置里指定一个目录，比如在 config.json 中加入：

{
  "work_dir": "D:/workbuddy_workspace"
}

如果不想改配置，也可以直接设置环境变量：

export WORKBUDDY_WORK_DIR="D:/workbuddy_workspace"

关键是要确认这个目录有读写权限，并且不要在系统盘根目录下。改完之后把旧的临时文件夹清掉，C盘空间和 502 write EACCES 问题会一起消失。

6. 落地到真实工作流：自动签到、订单抓取与更多玩法

6.1 自动签到：让 WorkBuddy 自己跑定时任务

接入百炼后，我把自动签到完整跑通了一次。这个任务的核心在于：模型需要理解“签到”这件事，但具体动作由脚本执行。

我在WorkBuddy里写了一段自定义指令，要求它每天上午10点检查签到页面，如果未签到，就执行签到脚本，并把结果写入日志。配置好之后，WorkBuddy会调用百炼模型判断当前页面状态，然后调用我准备的脚本。连续跑了一周，成功率保持在高位，只有一次因为页面改版失败，模型也很快定位到了原因。

这里我把Skill的逻辑拆成了两层：第一层是“状态判断”，交给百炼模型，用自然语言描述页面状态；第二层是“动作执行”，交给预置脚本，保证点击和输入这类操作是确定性的。两层配合的好处是，模型不需要理解复杂的DOM结构，只需要根据脚本返回的文本做判断，出错概率大幅下降。

6.2 跨境电商多平台订单抓取：一个可复用的自动化框架

另一个比较典型的场景是多电商平台订单的自动抓取。不同平台的接口、登录方式、数据结构都不一样，但工作流是统一的：登录 -> 拉取订单列表 -> 格式化数据 -> 写入数据库或表格。

我在WorkBuddy里把这个流程定义为一个Skill，名为 order_fetch 。每次只需要说“执行order_fetch抓取昨天的订单”，WorkBuddy会按照Skill里的步骤，结合百炼模型的判断，依次完成登录态检查、接口调用、字段清洗和结果汇总。这套框架的好处是模型只负责调度和异常处理，不负责每次都从零理解业务逻辑，大大降低出错概率。

如果你也想做类似的自动化，我建议先把流程画清楚，再让WorkBuddy生成脚本，最后把脚本固化成Skill。不要一上来就让模型全自动跑，否则你很难判断它到底在哪一步出了错。每个步骤之间加上日志输出，这样出了问题可以顺着日志往回查。

6.3 顺着这个思路继续扩展

接入百炼只是把底座换成更顺手的模型，WorkBuddy的价值在于工作流的定制。后续我打算把更多重复任务，比如数据周报生成、日志异常分析、文档批量整理，都改造成类似的Skill模式。模型更新换代很快，但这些工作流可以持续复用。

如果你也准备折腾，记得先在测试目录里跑通一个最小任务，再逐步扩大范围。这样哪怕出了 502 write EACCES 或者限流错误，也容易定位。模型接入这种事，最忌讳的就是一把梭，把环境、配置、指令全部揉在一起改，出了问题根本不知道是哪一环的锅。