企业官网建设流程全解析

说实话，第一次在开发者社区里看到 WorkBuddy 开放平台上线消息时，我并没有太在意。当时我刚在扣子（Coze）上做完两个 Agent 原型，正被“Demo 一时爽、落地火葬场”的坑折磨着——演示的时候一切正常，一放到真实业务场景里，工具调用中断、参数格式漂移、权限边界模糊，一个接一个地冒出来。直到我发现 WorkBuddy 并不是又一个“低代码聊天机器人平台”，而是把注意力放在了“Agent 能不能真正替你把手头的事办完”这个方向上，我才决定认真过一遍它的接入流程。

这篇文章就是我作为一个个人开发者，从注册开放平台、创建应用、拿密钥，到跑通第一个 API 请求、写自定义 Skill、编排出一个能稳定干活的 Agent 应用的完整记录。我会把过程中踩到的坑、绕过的弯路，以及那些我翻遍文档也没人告诉我的细节全部摊开来讲。适合正在做 Agent 开发、想接开放平台但还没动手的开发者阅读；如果你已经在做工具调用类应用，这篇也能帮你补上不少容易忽略的边界问题。

1. 先想清楚 WorkBuddy 开放平台到底要解决什么问题

1.1 它和聊天机器人平台的本质区别

很多人在刚接触 WorkBuddy 时，第一个问题是：它跟 Coze、Dify 这类平台有什么区别？

我在实际接入后最大的感受是：传统智能体平台的核心是“对话编排”，把大模型、知识库、插件串成一个能聊天的机器人；而 WorkBuddy 开放平台的核心是“任务执行”——它更关心一个 Agent 能不能在一连串工具调用中真正完成一件完整的事，而不是仅仅把一句用户指令变成一段像样的回复。

这个定位差别会在接入过程中不断体现。比如，在 WorkBuddy 里，一个 Skill 不只是给模型“多一个工具”这么简单，它需要按照平台约定的清单格式描述自己的能力边界、输入输出结构、触发条件，甚至要标明这个能力在什么情况下不要去调用。这个设计背后的原因很实际：如果一个 Agent 要在无人值守的情况下连续执行多个步骤，模型就必须要非常清楚每个工具的能力边界，否则它会在中间某一步产生幻觉，把整个任务链带偏。

我自己的项目就是一个典型例子。我要做的 Agent 需要定时去抓取某个行业站点的公开数据，做一轮清洗和汇总，再按固定模板生成报告草稿。放在传统平台里，这会被拆成“采集插件 + 知识库 + 撰写 Prompt”三段式；但在 WorkBuddy 里，我需要把它理解成一段“可执行的工作流”：采集是第一个 Skill，清洗是第二个 Skill，报告草稿是第三个 Skill，Agent 负责在用户给出模糊指令后，自己决策什么时候调哪个、按什么顺序调、失败之后怎么回退。

这让我重新理解了“Agent 应用”这件事：不是把功能封装成一个接口就叫 Agent，而是要让模型具备“在正确时机调用正确工具、并对结果负责”的能力。WorkBuddy 开放平台提供的就是承载这种能力的容器。

1.2 开放平台给个人开发者留了哪几条路

从我的接入经验来看，WorkBuddy 开放平台对个人开发者提供了几个不同层次的入口，你可以根据自己的能力和需求选：

• 纯 API 接入：如果你已经有自己的应用，只是想调用 WorkBuddy 的底层能力，比如对话、工具执行，或者想把它封装成自己产品里的一个功能模块，走 API 是最轻量的方式。它不要求你必须把业务逻辑搬进来，只需要在应用里集成一个 SDK 或直接发 HTTP 请求。
• Skill 开发与上架：这是我觉得对个人开发者比较友好的入口。你可以把一个垂直领域的小能力封装成一个 Skill，比如“PDF 发票信息抽取”“售前报价单生成”“周报素材归类”，然后上传到开放平台，别的开发者甚至 WorkBuddy 用户在场景里都可以调用。这种模式很像早期移动互联网时代的插件生态，一个人靠一个足够垂直的插件撬动整个平台流量是有可能的。
• Agent 编排与发布：如果你想做的不是“一个工具”，而是一个“能自动把事情干完”的应用，就可以在 WorkBuddy 里创建一个 Agent，把 Skill 作为工具绑定进去，设计它的行为规则、工作流和兜底策略，最后通过平台发布出去。这一步是从“接口开发者”升级为“应用开发者”的关键跨越。

三条路不是互斥的，实际项目中往往交替使用：你既写 Skill，也编排 Agent，同时还会用 API 把它接到自己的系统里。

1.3 平台能力边界：什么是它擅长做的，什么是它做不了的

接入之前还有一件事必须想清楚——WorkBuddy 开放平台擅长的是“执行编排”，而不是“模型能力竞赛”。

什么意思呢？就是说，你在设计 Agent 时，不要指望平台自带的模型比你单独调一个最强模型在智商上高出多少；它的价值在于，当任务需要多个步骤协作时，平台的调度机制能降低你把步骤串起来的成本。我的体会是：如果你要做的是“单轮问答”，直接用任意一家模型 API 就够了，没有必要引入整个 Agent 框架；但如果你要做的是“收集信息-分析-输出——失败后调整策略再试”这类多环节任务，平台的编排能力才会真正体现价值。

举个例子，我第一次尝试让 Agent 自动完成“从一段会议录音转写里提取所有人名并汇总到表格”的时候，如果只是调模型，每次都能得到不错的结果；但一旦我把“提取人名”和“把结果写入表格”拆成两个环节，中间就开始出现各种问题——模型生成的人名列表格式不固定、表格写入时因为字段匹配不上而报错、Agent 在异常发生后不知道是重试还是放弃。这些问题的根因不是模型不够聪明，而是缺少“执行框架”。

WorkBuddy 开放平台解决的就是这个框架问题。但对应的代价是，你需要花时间学习它的 Skill 规范、理解它的执行引擎怎么处理异常、掌握它的调试手段。这个学习成本是绕不过去的。

2. 接入前的准备：开放平台注册、应用创建与密钥管理

2.1 注册开发者账号与企业认证的取舍

第一步没什么悬念：进 WorkBuddy 官网，找到开发者中心，用手机号注册个人开发者账号。这里要注意一个选择：个人主体和企业主体到底选哪个？

我当时图省事，直接用个人身份完成了认证。对于我这种做小工具、想验证场景的个人开发者来说，个人认证完全够用。但你要清楚个人账号的边界：部分权限——比如发布到严肃商业场景、申请更高频次的 API 配额——大概率会有限制。如果你的目标是从第一天起就是做 To B 的商业应用，我建议还是花点时间走企业认证，后续省得再补材料。

还有一个容易忽略的点：开发者协议里关于数据使用的条款。Agent 执行任务时会涉及用户数据、第三方系统信息，你作为应用所有者，有责任向 WorkBuddy 明确申报数据用途。我第一次没细看，结果在创建某个涉及外部数据抓取的 Skill 时，因为没填数据使用声明被拒了一次，后来补材料才通过。

2.2 创建应用时要抄下来的关键参数

在控制台创建应用后，你会拿到三样东西：App ID、App Secret、API Key。我强烈建议你在拿到这三个值的瞬间就把它存进本地密码管理器里，并且养成“环境变量管理密钥”的习惯，而不是直接写死在代码中。

原因很简单——一旦代码被同步到公开仓库，密钥泄露是分分钟的事。我见过不少开发者直接把 API Key 贴在博客教程里，这个习惯非常危险。密钥泄露不仅会导致你的配额被刷爆，更严重的是，别人可以冒充你的应用身份调用接口，做出完全不受你控制的操作。

我自己的环境变量配置文件长这样：

WORKBUDDY_APP_ID=your_app_id WORKBUDDY_APP_SECRET=your_app_secret WORKBUDDY_API_KEY=your_api_key WORKBUDDY_BASE_URL=https://api.workbuddy.example.com/v1

这只是本地开发环境。如果你要部署到服务器，建议用部署平台自带的密钥管理服务，不要把它放进代码仓库。

2.3 必须提前想好的重定向配置与权限范围

创建应用时，有一项“重定向 URI / 回调地址”的配置要格外小心。如果你要做的是 Web 应用，需要设置 OAuth 回调地址；如果只是服务端到服务端的调用，这一项可能用不上。但是一旦你的 Agent 需要代表用户访问第三方服务，回调地址就变成了必配项。

我在这里踩过一个印象很深的坑：第一次配置回调地址时，我把测试环境的地址填成了http://localhost:8080/callback，本地跑没问题；后来部署到服务器，域名从 HTTP 换成了 HTTPS，回调地址也跟着改了。但我忘了在开放平台控制台同步更新，结果线上应用在用户授权后统一跳到一个错误页面，排查了很久才发现是回调地址不一致导致的。

所以这里给个实操建议：把回调地址的配置当成代码版本管理的一部分来对待。每次变更，先在控制台同步修改，再更新代码，不要只改一头。

另外，申请权限范围时，原则是“最小够用”：只申请你的应用真正需要的权限。因为每次因为权限不足而调用的失败，都会在运维日志里变成一条错误记录；而权限申请得越多，审核方对你的数据使用方式的质疑就越多，反而拉长上线周期。

3. 第一个 API 请求：从 Hello World 到理解 Agent 的运行逻辑

3.1 用一条 curl 命令验证链路通了没

配好环境和密钥后，老规矩，先用最简单的请求验证链路。我习惯不用 SDK，而是先用 curl 把认证流程和接口结构摸清楚，再动手写代码。

一个典型的流程是这样的：先用 App ID 和 App Secret 换取访问令牌，然后拿令牌调用 Agent 接口。伪代码如下：

# 第一步：获取 access token curl -X POST "$WORKBUDDY_BASE_URL/auth/token" \ -H "Content-Type: application/json" \ -d "{\"app_id\": \"$WORKBUDDY_APP_ID\", \"app_secret\": \"$WORKBUDDY_APP_SECRET\"}" # 第二步：调用一个最简的 Agent 接口 curl -X POST "$WORKBUDDY_BASE_URL/agent/run" \ -H "Authorization: Bearer $ACCESS_TOKEN" \ -H "Content-Type: application/json" \ -d '{"query": "你好，请介绍一下你自己"}'

如果顺利，你会得到一个 JSON 响应，里面通常包含 Agent 回复的正文、这次调用的任务 ID，以及一些元信息。这个任务 ID 非常关键，后面排查问题全靠它。

3.2 为什么第一次测试就失败反而是一件好事

我第一轮测试时，请求报了一个“invalid_argument”错误。原因是我没有传 Agent ID——WorkBuddy 的接口里，一个开放平台账号下可以创建多个 Agent，调用时必须明确指定要跑哪个实例，而不是只给一句“你好”。

这个细节其实体现了一个重要的产品逻辑：WorkBuddy 开放平台把 Agent 当成一个资源实体来管理，而不是一个单纯的模型对话接口。你创建每个 Agent，就是创建了一个独立的任务执行环境；它对模型、工具、执行策略的配置是相互隔离的。这样做的好处是，线上跑一个 Agent 出了问题，不会影响开发环境。

所以接入 WorkBuddy 的正确思路是：给不同用途创建不同的 Agent 实例，而不是在一个 Agent 里塞下所有功能。比如我的日报生成 Agent 和会议纪要总结 Agent，虽然是同一个底层模型，但它们的工具集、执行策略完全不同，分开实例管理会让后续的迭代和排查舒服很多。

3.3 异步执行与任务状态轮询：理解 Agent 不是瞬时响应

第一次跑通用对话请求时，我发现一个和普通模型 API 不太一样的地方：Agent 接口的返回往往不是一次性的。

原因是，Agent 需要规划执行步骤、多次调用工具、甚至在不同工具之间切换，整个过程可能持续几秒甚至几十秒。如果像普通 LLM 接口那样同步等待，体验会很差。于是 WorkBuddy 采用了异步任务的模式：你发起一个运行请求，它会返回一个任务 ID，客户端通过轮询或回调方式获取最终结果。

我的第一个真实 Agent 任务就花了 40 多秒才跑完，这让我意识到一个很重要的工程问题：你要在什么维度上定义“超时”。用户没有耐心干等一个 40 秒的请求，所以我的后端在转发 WorkBuddy 任务时，会立即给用户返回“任务已受理”的状态，然后通过 WebSocket 或轮询同步进度。这套异步感知的设计是 Agent 应用和普通 API 应用的一个关键区别。

我处理异步任务的标准姿势是这样的：

import time import requests # 发起 Agent 运行任务，返回 task_id run_resp = requests.post( f"{BASE_URL}/agent/run", headers={"Authorization": f"Bearer {token}"}, json={"agent_id": agent_id, "query": query} ) task_id = run_resp.json()["task_id"] # 轮询任务状态，直到最终完成或失败 for _ in range(120): status_resp = requests.get( f"{BASE_URL}/agent/task/{task_id}", headers={"Authorization": f"Bearer {token}"} ) data = status_resp.json() if data["status"] in ("completed", "failed"): print(data["result"]) break time.sleep(2)

这里的 2 秒轮询间隔是我实际用下来的折中方案——太频繁会白白消耗配额，太久又会让用户端感觉卡顿。具体间隔要根据你自己的任务耗时分布来定。

4. 深入 Skill 开发：把“一个能力”封装成 Agent 能用的工具

4.1 先拆解需求：一个 Skill 的边界怎么划

Agent 要想真正干活，离不开工具。在 WorkBuddy 开放平台里，这个工具单位叫做 Skill。我的理解是，Skill 就是一个可以被 Agent 动态调用的能力单元，它既可以是：“调用一个外部 API”，也可以是“执行一段本地脚本”，关键是你得让 Agent 在运行时理解它。

Skill 的边界划分直接决定了 Agent 干活的质量。我自己总结出一个原则：一个 Skill 只做一件不能被继续拆分的事情，并且它的输入输出必须是结构化、可验证的。

举个例子。我想让 Agent 自动判断“某篇公众号文章有没有被删”。我不能建一个叫“判断文章是否被删”的 Skill，因为这里其实包含了两步：先发请求拿到文章状态码，再根据状态码做出判断。正确做法是把“获取文章状态码”做成 Skill，而“根据状态码判断是否被删”是 Agent 在规划时自己完成的推理，不应该写死在 Skill 里。

这样划分有实际好处：一旦某个 Skill 出问题，影响范围可控，而且复用率高。今天可以让 Agent 用它判断文章状态，明天还可以让 Agent 用它做批量链接体检，边界清晰的 Skill 天然具备组合价值。

4.2 一个标准 Skill 的清单长什么样

在 WorkBuddy 开放平台里，定义一个 Skill 的核心是写一份结构化的能力描述清单。我习惯把它类比成“写给模型的一份岗位说明书”：你负责什么、输入是什么、输出是什么、什么情况不要干。

当时我写的一个“从文本中抽取结构化字段”的 Skill，清单大致类似这样：

name: 抽取结构化字段 description: | 从一段文本中抽取指定的结构化字段，比如日期、人名、公司名、金额等。 当用户提供了原始文本，并且明确提出需要抽取其中某些字段时使用。 如果文本为空或未指定字段，不要使用本工具。 input: text: string fields: string[] output: records: object[]

description 里那几句看起来不起眼的话，其实远比想象中更重要。因为 Agent 是靠语义匹配来决定“要不要调用这个 Skill”的，如果你的描述写得太窄，模型在遇到类似的但措辞不同的需求时，就不敢调用；写得太宽，又会在不合适的场景里被滥调。这就像在招人，JD 写不好，来的人一定不对。

4.3 参数 Schema：模型能不能把参数填对，取决于你写得多清楚

Skill 有了描述还不够，关键的参数定义必须严格使用 JSON Schema。这里我踩过一个很真实的坑：第一次定义 number 类型参数时，我在 Schema 里只写了类型，没有做任何范围约束，结果模型在一次运行时传出了负数，导致外部 API 直接拒绝。

后面我养成了一个习惯：凡是能被枚举、被限定范围、被正则校验的参数，全部在 Schema 里写死。比如：

{ "type": "object", "properties": { "format": { "type": "string", "enum": ["markdown", "plain", "json"] }, "max_results": { "type": "integer", "minimum": 1, "maximum": 50 } }, "required": ["format"] }

这样做的直接好处是，模型在生成参数时就有了“边界意识”，你不会在日志里看到离谱的越界输入。从我实际调试的情况看，补上约束之后，因为参数非法导致的工具调用失败至少减少了一半。

4.4 本地调试 Skill：先把工具当成普通函数测透

关于 Skill 的调试，我强烈建议先在本地把它当成一个普通函数测透，再挂到开放平台上。不要一上来就让 Agent 在各种场景里试——那样出了问题，你很难判断是模型规划错了，还是 Skill 本身有 bug。

我的做法很简单：先写一个标准的 Python 文件做单元测试，手动构造输入，检查输出，确认逻辑没问题后再接入平台。比如你写了一个能查天气的 Skill，就应该先在命令行里手动跑一下“北京今天天气怎么样”对应的函数，拿到稳定的 JSON 输出，再让 Agent 去调用它。

之所以要把这一步骤单独拎出来说，是因为我见过太多开发者直接在 Agent 对话里测试 Skill，一旦 Agent 返回“工具调用失败”，根本分不清是参数问题、网络问题还是代码 bug，排查效率极低。

5. 从 Skill 到 Agent：编排一个能真正完成任务的执行流

5.1 System Prompt 怎么写，才能让 Agent 既听话又不死板

当你有了一组 Skill 后，接下来就是把这些 Skill 编排进 Agent 的思考过程。WorkBuddy 允许你为 Agent 设定系统提示词，我的经验是：提示词里不应只写“人设”，而应该写清楚“任务边界”和“行为准则”。

举个例子，我做的日报 Agent，系统提示词里就写了几条硬性规则：

• 优先调用“拉取任务数据”的 Skill，没拿到数据前不要编造内容；
• 如果数据拉取失败，重试一次；重试仍失败就明确告诉用户，而不是给出一份空模板；
• 输出格式严格按模板，日期字段必须为当前自然日。

这套“边界式提示词”的核心逻辑是：不要让模型自由发挥，而是把容错机制内嵌到行为规则里。模型执行多个工具调用时，最大的风险不是它不知道用什么工具，而是在中间任意一步出错后直接“放飞自我”——要么忽略错误继续往下编，要么彻底放弃。把失败应对策略写进提示词，效果立竿见影。

5.2 工具编排背后的任务循环：理解 Agent 为什么能自动连招

WorkBuddy 的 Agent 之所以能把多个 Skill 串起来，是因为它的执行引擎内置了一个“规划-调用-观察-再规划”的循环。

我把它理解成一个项目管理器：你给 Agent 一个目标，它会自己拆成步骤，每一步从 Skill 清单里挑一个工具，调用之后把结果当作上下文的一部分，继续决定下一步怎么走。这个循环不是写死的，而是由模型动态决策的。

这带来一个重要启发：每个 Skill 的输出描述也要写得清楚。因为下一个 Skill 是靠上一个 Skill 的输出决定怎么调的。如果你的 Skill 返回的是一个大 JSON，但 description 里没说明“这个 JSON 里的 xxx 字段表示什么”，模型下一次决策的时候就容易理解错。

因此，我在设计 Skill 的 output 描述时，会刻意写清楚结构，例如：

output: records: object[] # 每条记录包含 title, url, publish_date, author 字段

这种“元描述”的收益在复杂任务里特别明显，它保证了整条工具链的信息在每个决策节点都是可理解的。

5.3 编排时必须考虑的特例：Agent 在异常分支里怎么选

真实场景里，最容易出问题的是异常分支。正常的路径大家都设计得很好，一旦接口超时、返回空值、或者外部服务临时不可用，Agent 的决策质量直接决定整个应用的可用性。

我的做法是在编排时主动设计“降级路径”。比如，我的 Agent 会先尝试调用精准搜索 Skill，如果返回结果为空，再调用一个更宽松的关键词搜索来兜底。

为了让模型能走降级路径，我在 Skill 的 description 里做了明确引导：“如果当前输入匹配不到任何内容，可以考虑调用 XX Skill 获取近似结果。”这样模型在决策时就有了处理空结果的依据。

另外，我还学到一个经验：不要在编排时把 Skill 数量堆太多。一旦工具列表超过一定数量——我自己体感是十五个左右——模型就会开始出现“选择困难”，调用错误的概率明显上升。能用组合解决的问题，就不要拆出多余的 Skill。

6. 典型故障的排查链路：那些让我反复重试的真实报错

6.1 高频错误之一：执行中断（execution terminated due to error）

我在搜索热词时看到不少人在问“execution terminated due to error. ”这个问题，我几乎可以肯定，这是很多 Agent 初学者会撞上的第一堵墙。

我第一次遇到“execution terminated due to error”时，第一反应是查代码、查网络。结果代码没有任何改动，网络也是通的。后来通过任务详情接口仔细翻看运行日志，才发现问题出在中间一个 Skill 调用上：外部接口返回的数据格式和 Skill 里定义的输出结构不一致，模型在解析的时候直接抛了异常，整个任务被终止。

这个错误的根源在于：Skill 的输出契约和实际返回值不匹配。你定义的输出字段叫content，但底层 API 返回的字段叫body，模型拿到数据后无法映射到预期结构，只能终止。

所以，后来我养成了一个习惯：每次写 Skill 时，先拿真实返回样本去对照输出描述，而不是凭猜测写 schema。如果一个外部 API 的返回字段不稳定，我会在 Skill 内部先做一层标准化转换，再把它暴露给 Agent。虽然多写几行代码，但能省下大量排障时间。

6.2 高频错误之二：工具调用参数幻觉

另一个常见故障是工具参数幻觉。模型在生成参数时，偶尔会凭空捏造一个枚举值，或者传一个超出范围的数字——最常见的表现是，接口返回“invalid_parameter”错误，但看日志时你会觉得模型没有做错什么。

深入排查之后，我发现这类问题在“系统提示词模糊 + 参数约束不严格”这两个条件同时满足时最容易出现。模型的推理链路长了之后，会“忘记”某个参数的具体约束条件，然后按自己的理解生成。

解决这个问题，除了补全 JSON Schema 约束之外，还有一个非常实用的技巧：在 Skill 描述里显式加上参数示例。比如：

description: | 按关键词搜索公开资料。示例：{"query": "人工智能", "limit": 10}

这比抽象描述有效得多。模型看到示例后，生成参数的准确率会明显提升。我实测过，给三个 Skill 加上参数示例后，因为参数生成错误导致的调用失败率下降了大概六成。

6.3 排查链路：日志、回放、最小复现

聊几个我实际用来排查 WorkBuddy 运行问题的手段。

首先是日志。WorkBuddy 的开放平台控制台里，每个任务都对应一条完整的运行流水，包括模型在每一步的思考输出、每次工具调用的请求和响应、以及任务的整体状态。排查问题先看这里，不要凭感觉去改代码。

其次是回放。有些问题是偶发的，当时看日志只觉得“某一步失败了”，但看不出原因。我会把触发任务的那段原始输入 copy 下来，重复发起几次，观察是否稳定复现。如果无法稳定复现，大概率不是 Skill 逻辑问题，而是外部依赖不稳定或参数取值范围离散，需要给 Skill 增加重试和降级逻辑。

最后是最小复现。如果某个故障稳定出现，我会绕过 Agent 编排，直接单独调用那个 Skill，用最简的输入测试它，把问题限制在“工具层”还是“编排层”。这个思路和排查普通代码 bug 一样，唯一不同的是，Agent 场景多了一层“模型决策”的不确定性，必须先把变量控制住。

7. 发布前的收尾工作：审核、安全边界与个人开发者的成本账

7.1 上架审核背后的隐性要求

如果你的目标不只是自用，而是把你的 Agent 或 Skill 发布到 WorkBuddy 市场，那么在开发阶段就要把审核要求纳入进来。

第一次提交 Skill 时，我因为“名称不规范”被打回来过。后来仔细读了平台规范，才发现 Skill 名称有一套命名约定：要能直观体现能力，不能夸大，不能用未授权的品牌词。这些细节看起来琐碎，但如果目标是通过平台获客，它们是不可避免的成本。

审核还会关注数据安全问题。如果你的 Skill 会获取第三方数据，最好在开发阶段就把数据来源、更新频率、使用范围在文档里写清楚，审核时能少一轮沟通。

7.2 个人开发者必须算清的成本账

成本控制这块，个人开发者和企业开发者的策略完全不同。我的原则是：把每一次计算资源都花在刀刃上。

WorkBuddy 开放平台的成本大头绝对是模型算力——尤其是一个 Agent 任务往往包含多轮模型调用，单次任务的总体 token 消耗量可能远超预期。我第一次跑一个带三个 Skill 的 Agent 时，一个任务烧掉的 token 比直接调模型完成同样任务的消耗高出近一倍，这就是编排带来的“思考开销”。

控制成本我常用的几个手段：

• 尽量复用短期上下文，不要让 Agent 在无关信息上浪费 token；
• 给容易出错的 Skill 加上前置校验，避免无意义的重试；
• 如果是固定模板的内容生成，把模板放在 System Prompt 里，而不是每次由模型重新推理输出格式。

7.3 我的选型结论：自建 Agent 还是使用 WorkBuddy

用了 WorkBuddy 一段时间后，我对“是否要自建 Agent 框架”这个问题有了更切身的体会。如果你只是做一两个原型验证，自建成本和 WorkBuddy 差不多；但如果你要把 Agent 真正投入高频、复杂的任务流中，平台在任务追踪、异常处理、权限管理上的成熟度，能帮你省掉至少两周的框架搭建时间。

我现在的工作方式是：无状态的单次问答直接调模型 API；涉及多步骤工具编排、需要任务追踪和权限隔离的场景，就放 WorkBuddy 上。两套体系并行，互不干扰，这可能也是个人开发者在资源和效率之间比较务实的平衡点。

最后再分享一个我自己的小习惯：每次在开放平台完成一次配置变更，我都会截一张图或者写一条变更记录，放在项目的 doc 目录里。这个习惯帮我解决过好几次“当时明明改了、后来忘了改成什么”的问题。开放平台类的工具，开发工作有相当大一部分在控制台里完成，版本意识跟不上，迟早会吃亏。