企业官网建设流程全解析

先说结论：WorkBuddy 开放平台真正适合的不是冲着“平台补贴”来的流量玩家，而是手里已经有一个具体业务场景、想把 Agent 能力沉淀成可复用资产的开发者。我花了两个完整周末，从注册开发者账号到把一个带工具调用的 Agent 应用跑通并发布上线，中间踩了不少文档没写清楚的坑。这篇文章把我走通的完整路径、每一步的取舍理由、以及排错过程全部整理出来，给正在做同类接入的同学一份可以直接照着抄的作业。

这一轮接 Agent 应用，业内已经不再停留在“调 prompt 拽上下文”的阶段了。大家更关心的是：工作流怎么编排、工具怎么注册、模型怎么切换、Skill 怎么沉淀。WorkBuddy 开放平台在这波里做得比较讨巧的地方是，它把 Agent 运行时的底座抽出来了，开发者只需要聚焦应用逻辑本身，不用自己从头搭模型网关、会话管理、工具协议这些重活。对于个人开发者来说，这意味着可以用较小成本把一个能真正干活的 Agent 应用挂到开放平台上，然后被 WorkBuddy 的终端用户直接使用。

我这一篇不打算写官方文档的复述，而是从个人开发者的实操视角，把从零接入、创建应用、编写 Skill、对接模型、调试发布这整条链路拆开讲。内容会尽量保持“可复现”，也就是说，你跟着我写的步骤走，大概率也能在一天内跑通自己的第一个 Agent 应用。

1. 接入前先把思路理清：你要做的不是一个 Bot，而是一个 Agent 应用

很多第一次接触开放平台的人会把 Agent 应用理解成“聊天机器人”，这个思维定式会带来连锁错误。WorkBuddy 开放平台上的 Agent 应用，更接近“具备模型推理能力 + 工具调用能力 + 状态管理能力”的一个独立服务单元。它默认不是给人聊天的，而是被 WorkBuddy 工作台在合适时机调用，去完成某个任务。比如：让 Agent 读取开发者上传的日志文件并自动归类、让 Agent 根据用户描述自动创建待办并绑定时间线、让 Agent 调用外部天气接口辅助行程规划。

1.1 明确应用边界，不要一上来就做“万能助手”

我在准备接入时先做了一件事：把“应用能做什么”和“应用不做什么”写在一张卡片上。这个动作很多人忽略，但恰恰是官方文档里没有强调但最重要的一件事。比如我做的第一个应用是“会议纪要与待办提取器”，它的职责是从用户提供的会议文本中提取决策项、负责人和截止时间，然后通过 Skill 写入 WorkBuddy 的待办列表。边界非常清晰，不聊闲天，不做情感陪伴，不回答跟会议无关的问题。

边界清晰带来的直接好处是：提示词（System Prompt）不需要写得很长很复杂，工具调用的触发逻辑也很容易判断，后续排查问题时定位快得多。相反，如果你一上来就想做一个“什么都能干”的超级 Agent，你会花大量的时间在意图识别和兜底回复上，而且效果还未必好。

1.2 理解开放平台的运行时角色

WorkBuddy 开放平台的接入逻辑，跟常见的“网页应用对接第三方登录”不是一个路子。它的核心模型其实是这样的：

• WorkBuddy 客户端（工作台）承担交互入口，把用户输入和上下文发给 Agent 运行时；
• Agent 运行时负责推理决策，决定是否需要调用某个 Skill 或外部工具；
• Skill 是实际干活的“手”，可以操作 WorkBuddy 内部的能力（比如创建待办、写文档），也可以请求外部 API；
• 模型层是推理大脑，WorkBuddy 开放平台允许你配置多种模型后端，支持通过 OpenAI 兼容接口接入第三方模型。

所以，你作为开发者，最重要的工作是定义“大脑如何做决策、手有哪些动作可以调用、两者之间用什么协议沟通”，其他的会话存储、模型接口稳定性、多轮上下文管理，开放平台已经帮你处理了一部分。

1.3 选型判断：什么时候该用开放平台，什么时候没必要

这里说句实在话：如果你的 Agent 应用只在本地跑，只服务你自己一个人，那没必要上 WorkBuddy 开放平台。直接用 Claude Code、Codex 这类本地工具，配合 deepseek 这类模型 API 就够了，成本更低、迭代更快。但是，如果你想把自己的 Agent 能力分发给更多用户，或者想让别人也在 WorkBuddy 工作台里直接调用你做的 Skill，那开放平台几乎是绕不开的。它的价值不在于模型推理，而在于“分发渠道 + 运行时兼容 + 统一调用协议”。

我当时的判断依据很简单：我不想维护一套多端适配的 Agent 运行环境，也不想让用户去安装配置复杂的依赖。放在开放平台上，用户的 WorkBuddy 装上就能用，这就值得做了。

2. 接入前置准备：开发者账号、应用凭据与运行环境

接入的第一步是在 WorkBuddy 开放平台注册开发者账号。这个步骤本身不难，但因为涉及创建应用、拿密钥、配置回调地址，细节比较多，任何一个环节出错都会导致后续调用失败。我把整个过程拆成了三步来讲。

2.1 创建开发者账号并完成实名认证

WorkBuddy 开放平台目前要求开发者完成实名认证才能创建应用。个人开发者需要准备身份证信息进行验证，这个过程通常在几分钟内完成，但我遇到过认证照片光线不对被驳回的情况，所以建议你在光线充足的环境下拍摄证件照，不要用手机翻拍旧照片。

认证通过后，进入开放平台控制台，首页会有一个“创建应用”按钮。你要想清楚应用的类型：是作为一个完整的 Agent 应用上线，还是只提交一个 Skill 给其他应用复用。两者的开发方式不太一样，但初始入口一致。我的建议是，如果你第一次接触，先从完整的 Agent 应用做起，跑通之后再拆 Skill，因为整条链路完整，你的理解会更扎实。

2.2 创建应用并获取 App ID / API Key / Secret

创建应用时，你需要填写应用名称、应用描述、可见范围等信息。这里有一个技巧：应用名称不要起“智能助手”“AutoGPT”这类通用名，尽量体现具体场景，比如“会议纪要提取助手”。原因是 WorkBuddy 开放平台的应用市场将来可能会做语义搜索和场景匹配，描述里的关键词会直接影响分发效果。

创建完成后，控制台会生成三样关键凭据：

我建议你拿到这三样东西后，第一时间在本地用.env文件存好，并将.env加入.gitignore。顺便说一句，我见过好几个开发者因为把 API Key 直接写在代码里提交到 GitHub，导致密钥泄露被恶意刷量。这个问题如果不重视，后面会非常麻烦。

2.3 配置回调地址与权限范围

如果你是第一次创建应用，配置页会有一个“回调地址（Redirect URI）”的输入框。这个地址用于 WorkBuddy 授权服务在完成身份授权后跳转回你的服务端。开发阶段可以先用本机地址，比如http://localhost:9000/callback，但上线前必须改成 HTTPS 域名。

配置回调地址时有一个常被忽略的点：WorkBuddy 开放平台校验回调地址是通过精确匹配，不是前缀匹配。也就是说，你填了http://localhost:9000/callback，那回调跳转时必须完全一致，多一个斜杠都会报错。我在第一次配置时就因为回调地址末尾多了一个/导致 OAuth 授权一直失败，排查了很久才发现是这个原因。

权限范围（Scopes）方面，我的建议是采用最小授权原则。先只申请你真正会用到的权限，之后需要再加。比如我的会议纪要应用只需要“读取待办列表”“创建待办事项”这两个权限，那就只申请这两个。这样做的原因是：审核更容易通过，泄露风险面更小，用户授权时也更信任你的应用。

2.4 本地开发环境搭建

官方文档给的是 Node.js 的示例 SDK，但本质上开放平台的接口形态是标准的 REST API，你用 Python、Java、Go 都可以对接。我本地用的是 Node.js 20 + TypeScript，主要原因是 WorkBuddy 的官方 SDK 对 TypeScript 的支持比较完善，类型推导能帮我减少一些低级错误。

开发环境的依赖没有想象中复杂，核心是把以下四件事准备齐：

• 能访问外网的开发机或者云服务器（用于接收回调）；
• Node.js 20+ 环境（或者你熟悉的其他语言环境）；
• 一个用于内网穿透的开发调试工具（这一项不是必须，但能极大提升联调效率）；
• 一个模型 API 的 Key（我用的是 deepseek 的 API，后面细说）。

3. 从零跑通第一个 Agent 应用的完整实操流程

这一部分是我踩坑最多的地方。很多人卡在回调、鉴权、模型配置这几个环节，尤其是“回调地址校验不通过”和“工具调用参数格式不符合预期”这两个问题，几乎每个人都会遇到至少一次。我把完整流程走一遍，包括每一步的配置内容和结果验证方式。

3.1 第一步：搭建最小后端服务

我用 Express 搭建了一个测试服务，只做了两件事：处理 OAuth 回调，接收开放平台的事件回调。代码结构大致如下：

import express from "express"; import crypto from "crypto"; import dotenv from "dotenv"; dotenv.config(); const app = express(); app.use(express.json()); const APP_SECRET = process.env.WORKBUDDY_APP_SECRET; const PORT = process.env.PORT || 9000; // 处理 OAuth 回调 app.get("/callback", async (req, res) => { const { code } = req.query; if (!code) { res.status(400).send("Missing code"); return; } // 用 code 换取 access_token const tokenRes = await fetch("https://open.workbuddy.com/api/oauth/token", { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify({ code, app_id: process.env.WORKBUDDY_APP_ID, app_secret: APP_SECRET, grant_type: "authorization_code", }), }); const tokenData = await tokenRes.json(); // 开发阶段直接打印 token，方便后续测试 console.log("Token data:", tokenData); res.json({ ok: true, data: tokenData }); }); // 处理开放平台事件（比如用户触发 Agent） app.post("/webhook", (req, res) => { const signature = req.headers["x-workbuddy-signature"]; const rawBody = JSON.stringify(req.body); const expectedSignature = crypto .createHmac("sha256", APP_SECRET) .update(rawBody) .digest("hex"); if (signature !== expectedSignature) { res.status(401).send("Invalid signature"); return; } const { event_type, payload } = req.body; console.log("Received event:", event_type, payload); // 开发阶段先回复一个确认接收 res.status(200).send("ok"); }); app.listen(PORT, () => { console.log(`Server running at http://localhost:${PORT}`); });

这里有一个极其重要的点：Webhook 的签名校验。WorkBuddy 开放平台对事件回调采用 HMAC-SHA256 签名，你在本地调试时，如果直接关闭签名校验，确实能跑通，但会埋下安全风险。我建议从第一天就开始做签名校验，因为一旦你的应用部署上线，如果请求伪造没有拦截，恶意攻击者可以直接操控你的 Agent 逻辑，后果非常严重。

3.2 第二步：创建 Agent 应用定义

后端服务搭好之后，打开开放平台控制台，进入你刚才创建的应用，找到“Agent 配置”或者“Agent 定义”页面。这里需要填写的核心内容包括：

• 系统提示词（System Prompt）：也就是 Agent 的“人设 + 任务说明 + 工作流程”；
• 模型选择与参数：选择你配置好的模型（我接的是 deepseek-chat），并设置 temperature、max_tokens 等参数；
• 工具注册：列出这个 Agent 可以调用的 Skill；
• 开场白（可选）：面向终端用户的默认欢迎语。

我的系统提示词写法供参考：

你是一名会议纪要助手。你的任务是从用户提供的会议文本中提取： 1. 决策事项 2. 待办任务 3. 负责人 4. 截止时间 提取完成后，如果存在待办任务，请调用 create_todo 工具将待办写入 WorkBuddy 待办列表。 如果用户提供的文本不是会议内容，请礼貌提示用户提供会议文本。

这段提示词看起来简单，但边界非常清晰。它明确告诉模型“什么时候该用工具”“什么时候不该动手”，这比写一大堆“你可以帮我做任何事”要高效得多。

模型参数设置上，我的建议：temperature 设置为 0.3 左右，不要太高。因为 Agent 的任务是执行动作而不是创意生成，过高的温度会导致模型输出的工具调用参数不稳定，出现字段格式错误的问题。max_tokens 则根据任务复杂度设定，一般 1024 就够用了，但如果你需要模型输出长文本，可以调到 2048。

3.3 第三步：对接模型 API，打通推理链路

WorkBuddy 开放平台支持配置多种模型提供商，其中最通用的方式是使用 OpenAI 兼容接口。我选择的是 deepseek 的 API，因为它的 OpenAI 兼容性比较好，且上下文窗口够大，价格在同类模型里对个人开发者友好很多。配置方式不复杂：在开放平台的模型设置里，填入对应的 Base URL 和 API Key 即可。

这里我想额外说明一点：deepseek 开放平台的 API 调用，在个人开发者群体里使用率确实很高，因为它的支持成本低、文档清晰、SDK 也完整。它的 API 设计上对于 tools 调用（function calling）的支持比较稳定，这在 Agent 场景中特别重要——因为 Agent 的核心能力不是“聊天”，而是“根据用户意图调用正确的工具”。

我接入时在 tools 参数上踩了一个坑。WorkBuddy 开放平台要求模型按照特定格式返回工具调用请求，比如name和arguments必须是顶层字段，而 deepseek API 返回的 tool_calls 格式里部分字段嵌套层级不同。解决办法是写一个很轻量的适配层，把 deepseek 的 tool_calls 响应转换成 WorkBuddy 希望的结构。这个适配层不复杂，代码如下：

function transformToolCalls(toolCalls) { return toolCalls.map((call) => ({ id: call.id, name: call.function.name, arguments: JSON.parse(call.function.arguments || "{}"), })); }

这里强烈建议：无论你用哪个模型的 API，都不要把模型返回的原始结构直接透传给 WorkBuddy。不同模型在 function calling 上的返回结构有差异，中间加一层转换能避免大量“非预期格式”的报错。

3.4 第四步：本地联调与日志观测

本地联调是整个流程里耗时最长、也最考验耐心的环节。WorkBuddy 开放平台提供了沙箱环境，你可以在沙箱里模拟终端用户发起请求，然后观察事件回调、Agent 日志和工具执行结果。

我建议你像这样观测：

• 请求进入时，先看 Webhook 签名是否校验通过；
• 再看事件类型是否正确识别；
• 然后观察模型调用的入参和出参，特别关注 tool_calls 是否正常；
• 最后检查工具执行结果是否写回了正确的地方。

为此，我把日志打得很细，控制台会输出每一轮的完整 JSON。很多诡异问题其实都能靠“回到日志看原始数据”来解决，尤其是模型返回了不符合预期的内容时，日志是最直接的证据。

简述一个我调试时的真实案例：第一次跑通时，Agent 已经成功提取出待办事项，但 create_todo 工具执行时一直报“负责人字段缺失”。我看日志发现，模型在生成工具调用参数时，把assignee字段拼成了assignee_name，因为我在系统提示词里用了“负责人姓名”这个说法。解决办法很简单：把工具参数的字段描述改成“负责人（使用英文 assignee 字段）”，模型一下就输对了。这说明开放平台的模型对字段名的敏感度很高，写工具描述时务必把字段名写清楚。

4. Skill 开发与自定义指令：让 Agent 真正能干活的进阶设计

如果只是让 Agent “聊两句”，那接入开放平台的价值就大打折扣。真正让 Agent 有价值的是它能调用工具、执行动作。在 WorkBuddy 开放平台里，这套能力的载体叫 Skill。我最初的理解是“Skill 就是给模型加几个函数”，实际上远不止这些。

4.1 Skill 的本质是“能力插件”

Skill 是一段可复用的能力模块，它包含：

• 元信息：名称、描述、参数声明；
• 执行逻辑：实际调用 WorkBuddy 内部 API 或外部 API 的代码；
• 权限声明：这个 Skill 需要哪些权限。

它的设计理念是：让模型在推理时根据用户意图自动选择是否调用某个 Skill，而 Skill 内部的具体实现细节不需要模型关心。这类似于你在 IDE 里装插件：编辑器本身不提供所有能力，但插件会按需扩展。

Skill 的参数声明非常重要，因为模型要靠这个描述来判断何时调用、传入什么参数。我的建议：每个参数都写清楚“它是什么、单位是什么、有没有枚举值、必填还是选填”。写得越清楚，模型对参数的理解就越准确，调用失败率就越低。

4.2 从零编写一个 Skill：以“创建待办”为例

我做的第一个 Skill 是create_todo，功能是向 WorkBuddy 工作台的待办列表里写入一个新的待办事项。它的定义大致如下：

{ "name": "create_todo", "description": "创建一条待办任务，用于将用户提出的待办内容写入待办列表", "parameters": { "type": "object", "properties": { "title": { "type": "string", "description": "待办任务的标题，如：完成项目报告" }, "assignee": { "type": "string", "description": "负责人的用户名，如果没有明确指定则为空" }, "due_at": { "type": "string", "description": "任务的截止时间，ISO 8601 格式，如 2025-07-01T18:00:00Z" }, "priority": { "type": "string", "description": "优先级，只能取 low、medium、high 三选一", "enum": ["low", "medium", "high"], "default": "medium" } }, "required": ["title"] } }

写 Skill 描述时的关键心得：描述里要包含“什么时候该用”和“什么时候不该用”。比如 create_todo 的描述是我上面写的那种“将待办内容写入列表”，如果你写成“可以创建任何任务”，模型会在不该调用的时候也去调用，导致一堆空待办。

Skill 执行逻辑的实现不复杂，本质就是拿到模型的参数，然后请求 WorkBuddy 的内部 API。这里我就不贴完整代码了，因为不同团队的内部 API 地址和权限模型略有差异。但我可以给一个执行逻辑的结构参考：

export async function execute(params) { const { title, assignee, due_at, priority } = params; const response = await fetch("https://open.workbuddy.com/api/v1/todos", { method: "POST", headers: { "Content-Type": "application/json", Authorization: `Bearer ${context.accessToken}`, }, body: JSON.stringify({ title, assignee, due_at, priority, source: "agent", }), }); const result = await response.json(); return result; }

注意：这里我用了context.accessToken这样的环境注入值，它是在 Agent 运行时由 WorkBuddy 开放平台自动注入的，你不需要在 Skill 代码里硬编码任何密钥。这是开放平台的另一个安全设计，也是为了减少开发者自身的保管成本。

4.3 自定义指令：比 Skill 更轻量的“小套路”

除了 Skill，WorkBuddy 还支持自定义指令，本质上是一段自动追加到系统提示词里的规则。它不是完整的能力模块，更像是一种“工作习惯约束”。比如你可以写这样的自定义指令：

当用户提出任何请求时，先判断是否属于当前权限范围内的事项，如果不是，礼貌拒绝并说明原因。

我目前用的是下面这组自定义指令，个人体验不错：

• “回答前先做一次确认：如果指令存在歧义，先向用户确认，再行动；”
• “在需要修改或删除数据时，必须先列出将要操作的数据项，等待用户确认后再执行；”
• “如果用户在对话中提供了时间信息，自动换算为当前时区的时间再做理解；”
• “当工具调用失败时，不要假装成功，请明确告知用户失败原因和可能的解决办法。”

这组指令帮我解决了两个高频问题：一是 Agent 误操作数据，二是 Agent 在出错时“硬编”成功回应，误导用户。自定义指令是调试阶段最便宜的试错方式：不需要发布新的 Skill，改完立即生效，体验非常好。

4.4 多 Agent 协作场景的初次尝试

进阶一点，可以在 WorkBuddy 开放平台上尝试创建多个 Agent 应用，然后让它们协作完成一个复杂任务。比如一个应用负责分析文档，另一个应用负责整理待办，最终由第三个应用汇总输出。这种方式比较新，但开放平台的机制是支持的。

不过我要泼一盆冷水：多 Agent 协作的调试成本会指数级上升。我试过一次“文档解析 -> 提取事项 -> 写入待办”的三 Agent 协作，效果虽然能达到，但排查问题的耗时比单一 Agent 多了三倍不止。我的建议是：个人开发者阶段先用单 Agent + 多 Skill 的组合，等到真的复杂到单 Agent 难以承载时再上多 Agent，否则你的精力会被联调吃掉很多。

5. 发布上线前需要注意的合规与安全检查

很多人把应用开发完就直接点发布，结果审核被驳回或者上线后出现安全隐患。根据我的经验，发布前认真检查一遍能省下一大堆麻烦。

5.1 发布前检查清单

我整理了一份自己一直在用的检查清单，你可以直接复制使用：

• 密钥是否全部从代码和配置中移除，改用环境变量或 Secret Manager；
• Webhook 回调是否完成签名校验，是否对非法请求返回固定错误；
• 权限范围是否最小化，是否在应用描述中说明数据的使用范围；
• 系统提示词是否包含任何违规内容，是否要求模型输出不安全内容；
• 工具参数是否做了必要校验，比如对数字、日期、枚举值做类型检查；
• 日志中是否打印了密钥、token 等敏感信息；
• 是否有“人审兜底”机制，比如高危操作需要用户确认；
• 应用描述是否写清楚“能做什么、不能做什么、数据去哪了”。

这里特别要提醒的是日志脱敏。开发阶段为了方便排查，我会在本地打印完整的请求和响应，但上线前必须清理这些日志输出，尤其是 access_token、API Key 这类信息。如果用日志平台做收集，建议开启脱敏规则。

5.2 版本管理与灰度发布

WorkBuddy 开放平台支持将 Agent 应用配置保存为不同的版本。我的管理习惯是：

• 开发版本：每天都改，随便折腾；
• 测试版本：运行相对稳定后，发给小范围用户试用；
• 正式版本：经过充分验证后发布，所有终端用户可见。

三套版本互不干扰，切换也很方便。如果你想临时修改系统提示词，在开发版本里改，联调通过后再升级到正式版本，不要直接在正式版本上频繁改动，否则用户会感觉到明显的不稳定。

还要强调一个细节：发布正式版本前，把应用的“可见范围”控制好。你可以先设置为“仅自己可见”，模拟用户视角使用两三天，确认各项功能正常后再调整为“所有人可见”。这样可以避免因为自己没测试到位，把有问题的状态暴露给真实用户。

5.3 用户数据隐私与退出机制

如果一个 Agent 应用要处理用户的数据，比如会议纪要、待办内容、文件内容，那开发者必须重视数据隐私。WorkBuddy 开放平台在审核时会检查你是否在应用说明里写清楚“数据用途”和“数据保留周期”。

我的建议是：能不存储用户数据就不存储。比如我的会议纪要应用，每轮对话结束时只保留“提取出来的待办事项”，原始会议内容不落库。这不仅能降低隐私风险，也能减少自己的数据维护成本。

用户退出的处理也同样重要。WorkBuddy 开放平台允许开发者提供“退出登录”或“解除授权”接口，用户解除授权后，你的服务端应该主动删除与该用户相关的缓存数据和 token，而不是继续保留。这个逻辑虽然简单，但在很多个人开发者的应用里并没有实现，算是一个比较容易踩的合规坑。

6. 常见问题与排查技巧实录：把实际遇到的坑一次说清

最后列一下我这段时间遇到的高频问题，每条都给出排查思路和解决办法。这不是从文档里抄的，而是实际踩过之后得出结论。

6.1 OAuth 授权失败，回调地址报错

这个问题我在文章前面提过，核心原因大概率是回调地址不一致。排查步骤如下：

• 核对控制台配置的 Redirect URI 与实际跳转地址是否完全一致；
• 检查是否有拼接 query 参数，部分情况下 WorkBuddy 开放平台不允许在回调地址上附带自定义参数；
• 检查本地服务是否用了 HTTPS，如果回调地址填的是 HTTPS，本地调试需要配置证书或改用 HTTP 的测试环境；
• 检查回调响应状态码必须为 200，有些时候因为服务端报 500 导致授权流程中断；
• 确认code是一次性的，同一个 code 不能重复换取 token。

6.2 模型返回内容符合预期，但工具调用失败

工具调用失败很多情况下不是模型的问题，而是参数格式或字段名的问题。我遇到的几个典型原因：

• 模型把参数名改成了描述里的中文词汇，导致后端取不到值；
• 枚举字段传了不在定义范围内的值，比如传了HIGH而不是high；
• 必填字段缺失，模型认为某些字段不需要传就跳过了；
• 时间格式不是 ISO 8601，比如传了中文格式的“明天下午三点”。

解决办法分两路：一是优化工具描述，把字段格式要求写得更具体；二是在 Skill 执行层做参数归一化，比如把字符串类型的时间通过解析器转成标准格式。如果工具调用失败率一直高居不下，可以试试看调整系统提示词，加上一句“调用工具前请先确认所有参数均符合参数描述要求”。

6.3 上下文超限与长文本处理

Agent 应用在处理长文本时，容易出现上下文超限。比如会议纪要提取场景，用户贴了一万字会议记录，模型一次性处理不了。我的做法是采用分段策略：

• 先尝试直接提取，如果文本长度超限，则将文本按章节切块；
• 每个文本块单独做一次提取，得到中间的待办记录；
• 最后将所有块的提取结果合并去重，得到最终输出。

这里也可以调整模型的选择。deepseek 这类模型通常具备较大的上下文窗口，可以用 64K 或 128K 窗口的版本，配合分段策略基本可以覆盖绝大多数场景。上下文管理这块，WorkBuddy 开放平台本身对会话历史也有清理机制，但开发者还是应该在应用层主动控制输入长度，而不是把一切丢给默认清理。

6.4 排查速查表

6.5 两个提升调试效率的小工具

• WorkBuddy 开放平台的沙箱环境支持事件重放。调试时如果一次处理没成功，可以直接在控制台里重新触发同一个事件，不用重复构造请求；
• 开放平台的日志查询支持按 trace_id 回溯整条链路。如果你的应用在某一步出错，把 trace_id 复制出来就能看到完整的调用链，排查效率比看散落日志高很多。

7. 最后一点体会

跑完全程再回头看，WorkBuddy 开放平台对个人开发者的价值并不是“零门槛”，而是“用一套协议帮你省掉 Agent 运行时的重复建设”。它把复杂的地方都收拢了，你用较小的成本就能把一个能调用工具的 Agent 应用推给真实用户使用。

如果你正在准备接入，我的建议是从一个极小的场景切入，先把一个 Skill 跑通，再逐步增加能力和优化提示词。不要一上来就规划一个庞大的多 Agent 协作系统，先让模型在清晰边界内可靠地调用工具，比追求功能多更重要。踩过几次坑之后你会发现，Agent 应用的稳定性，很大程度上取决于你给模型划定的边界是否清楚、工具定义是否严谨、日志是否可追踪。把这三件事做好，你的应用就成功了一大半。