企业官网建设流程全解析

1. 项目概述：WorkBuddy 开放平台到底解决什么问题

1.1 为什么个人开发者值得关注这个平台

说实话，这两年做 AI 应用最痛苦的事情不是模型不够聪明，而是“从想法到能跑起来的东西”之间那条路太长了。你要自己去接模型 API、设计提示词、写工具调用逻辑、处理上下文、再做前端交互，最后还得折腾部署。很多人写着写着就放弃了，因为 80% 的精力都耗在了“基础工程”上，而不是“你的业务逻辑”上。

WorkBuddy 开放平台的出现，把这条链路压缩了一大截。它本质上是一个面向 Agent 应用开发的一体化平台，核心解决三件事：让 Agent 有“工作台”可以跑、让 Agent 能调用外部工具、让 Agent 的构建过程对个人开发者友好。你不需要从零搭一套完整的 Agent 框架，也不需要自己维护模型推理服务，注册开发者账号之后，直接在平台上把智能体搭起来，再通过 API 把能力对接到自己的应用里就行。

我自己第一次跑通的时候，最大的感受是：终于有个平台是把“Agent 开发”当作第一优先级来设计的，而不是把 Agent 当作模型 API 的一个附属功能。这个定位上的差异，决定了整个开发体验完全不同。

1.2 WorkBuddy 和 CodeBuddy 到底什么关系

很多人在热搜里问“codebuddy和workbuddy区别”，这俩名字太像了，确实容易搞混。简单说，CodeBuddy 更偏“结对编程助手”，主打的是代码补全、代码解释、单元测试生成这些围绕写代码本身的能力，使用场景是 IDE 内部。而 WorkBuddy 的侧重点在“智能体”，也就是能自主完成任务的执行单元，强调的是工具调用、流程编排、任务拆解这些更上层的 Agent 能力。

用生活化的类比来说：CodeBuddy 像是给你配了一个随时在旁边接话的资深程序员，你写一行它帮你补十行；WorkBuddy 更像你雇了一个能自己安排工作的小助理，你给它一个目标，它自己去拆任务、调工具、跑流程，最后把结果给你。两者可以配合使用，但如果你的目标是做 Agent 应用，那 WorkBuddy 才是你要重点关注的那条线。

1.3 谁适合跟着这条路径走

我把话放前面，这篇文章不是写给大厂 AI Infra 团队看的，而是写给三类人：

第一类是手里有具体场景但不会写复杂工程代码的人。比如你是个运营，想做一个能自动汇总行业资讯并生成日报的 Agent；或者你是个产品经理，想搭一个能自动分析用户反馈的机器人。这类人不需要精通大模型原理，但要会用平台、会配 Skill、会调参数。

第二类是本身会写 Python 或 JavaScript，但没系统做过 Agent 项目的开发者。你要补的东西是 Agent 的架构思维——怎么拆任务、怎么管工具、怎么处理记忆和上下文。

第三类是想把 Agent 能力做成产品对外提供服务的人。开放平台的价值在于它有一套完整的发布和调用链路，你做的 Agent 不只是自己玩，还能通过 API 让别人用。

如果你属于以上任何一类，这篇文章可以帮你少走很多弯路。接下来我会按照我自己从零接入的完整流程来讲，每一步都尽量给到可以直接抄作业的配置和注意事项。

2. 接入前的准备：账号、环境与工具链

2.1 开发者账号与开放平台的申请流程

WorkBuddy 开放平台的入口在官网的开发者导航里，第一次用需要先注册开发者账号。这个流程和大多数云平台类似，手机号验证之后进入开发者控制台，然后要做实名认证。这里提醒一句：如果你打算后续发布 Agent 应用让别人调用，实名认证是绕不过去的，别拖到最后才弄。

认证通过之后，控制台里能看到几个核心模块：应用管理、智能体管理、Skill 管理、API Keys、调用日志。我第一次点进去的时候其实有点懵，不知道从哪下手。实际用下来，正确的路径应该是这样的：先去“API Keys”创建一个密钥，因为后续所有操作都会用到鉴权；再去“智能体管理”新建一个 Agent，这时候可以选择模板或者从空白开始；最后才是配 Skill 和写编排逻辑。

这里有个容易忽略的点：开放平台的开发者账号和 WorkBuddy 客户端的登录账号是同一个体系，但控制台权限需要在网页端单独激活。我遇到过在客户端里已经能正常对话，但控制台 API 调用一直报权限错误的情况，折腾了半天才发现是控制台的开发者权限没点开。所以注册完第一件事，确认一下控制台右上角能看到“开发者模式”的标识。

2.2 不同平台的安装方式

这部分主要针对那些想把 WorkBuddy 作为 Agent 运行时环境的同学。WorkBuddy 提供了桌面客户端，也支持 Ubuntu、Linux 服务器环境安装。两者的用途不同：桌面客户端适合日常开发和调试，服务器端适合把 Agent 部署成常驻服务。

桌面版的安装没什么好说的，官网下载对应操作系统的安装包一路下一步就行。Linux 端的安装建议用命令行方式，方便后续维护和升级。我自己的服务器是 Ubuntu 22.04，安装流程大概是先下载对应的安装脚本，然后给执行权限运行，装完之后用workbuddy --version验证一下版本。

这里有一个很多人都会踩的坑：Linux 服务器上如果没有图形界面，WorkBuddy 的某些依赖会缺。最简单的处理方式是安装xvfb之类的虚拟显示工具，或者在部署的时候选用 headless 模式。官方文档里对这一块的说明比较零散，我建议你在搜“workbuddy ubuntu 安装教程”的时候，把系统版本和是否带桌面环境这两个信息一起带上，不然很容易照着教程装到一半才发现环境不对。

2.3 找密钥和配终端环境

创建 API Key 的位置在控制台的“API 访问”菜单下面，密钥只显示一次，生成之后记得复制保存。丢了就只能删掉重建，别问我怎么知道的，问就是重建过三次。

拿到密钥后，本地开发环境需要把密钥配置到环境变量里。在 Linux 或 macOS 终端执行：

export WORKBUDDY_API_KEY="你的密钥" export WORKBUDDY_BASE_URL="https://api.workbuddy.ai/v1"

这里我强烈建议不要直接在终端里用export配置，因为终端一关配置就没了，而且有可能被 shell 历史记录留存。更稳妥的方式是写进项目的.env文件里，然后用source .env加载，同时把.env加进.gitignore。我用 Python 写调用脚本时，通常是配一个简单的.env文件配合python-dotenv读取，一条条os.getenv()取出来用，干净利落。

2.4 Skill 机制和自定义指令是个什么概念

在讲实操之前，得先把 WorkBuddy 最核心的两个概念说清楚：Skill 和自定义指令。

Skill 你可以理解成 Agent 的“插件”或者“工具箱”，它封装了一个 Agent 可以执行的具体能力。举个例子，如果我想让 Agent 能查天气，我可以写一个名为weather_query的 Skill，里面定义了输入参数（城市名、日期等）、调用方式（调用某个天气 API）、返回格式（温度、天气状况等）。Agent 在运行过程中，如果判断当前任务需要天气信息，就会自动触发这个 Skill。

自定义指令则更像是“行为准则”，它不直接提供能力，而是约束 Agent 怎么思考、怎么输出、怎么分工。比如你可以通过自定义指令告诉 Agent：“在回答之前先列出你的思考步骤”“遇到不确定的信息必须明确标注”“如果用户要求超出你的能力范围，必须直接说明而不是编造”。这些指令对 Agent 的稳定性影响非常大，很多人觉得 Agent 输出质量不稳定，问题往往就出在没写好自定义指令上。

Skill 是给 Agent 装“能力”，自定义指令是给 Agent 定“规矩”。两个配合用，才能让 Agent 既干得了活，又不乱来。这个概念在后文实操里会反复用到，先在这里建立基础认知。

3. Agent 应用的核心设计：从技能拆分到编排联动

3.1 别一上来就写复杂框架，先学会拆任务

做 Agent 应用最容易犯的错误，是一上来就想着套一个多智能体框架，什么规划器、执行器、记忆模块、反思机制全堆上去。结果往往是框架搭得很漂亮，真正跑起来的时候，连第一个业务场景都走不通。

我的建议是：哪怕你最终要做的 Agent 很复杂，第一版也要先从“单 Agent + 几个 Skill”开始。原因很简单，Agent 的复杂度是逐步长出来的，不是一开始设计出来的。你把 Agent 当成一个真人新员工来想：新员工入职第一天，你不会让他同时管十个项目，而是先让他熟练一件事，再扩展到更多。Agent 开发也是一样的逻辑。

以我自己做过的一个“行业资讯自动摘要 Agent”为例，第一版拆出来的任务清单是这样的：

• 定时抓取指定网站的新闻内容
• 对抓取到的原文做去重和清洗
• 调用大模型生成摘要
• 把摘要汇总成日报格式发送到指定渠道

这个拆法看起来很简单，但它把每个任务都对应到了一个可落地的模块。抓取用 requests，清洗用正则和字符串处理，摘要调用大模型接口，发送走机器人的 webhook。每个模块独立测试，最后再串起来。这套流程跑通了，再去考虑加“自动选题”“情绪分析”“竞品监控”这些更高级的 Skill，一步步扩展。

3.2 用 Skill 封装原子能力

我建议你把 Skill 当成“函数”来设计，而不是当成“插件包”来设计。一个 Skill 最好只干一件事，职责单一，输入输出明确，这样调试起来非常轻松。

在实际操作中，Skill 一般包含两部分：一个是描述文件，用来告诉 Agent 这个 Skill 是干什么的、什么时候该用、参数有哪些；另一个是执行代码，用来真正干活。描述文件的编写质量直接决定了 Agent 会不会在正确的时候调用这个 Skill。我见过太多人写的 Skill 描述含糊不清，结果 Agent 该调的时候不调，不该调的时候瞎调。

举个例子，假设你写了一个发邮件的 Skill，这里有两种描述方式。第一种：“send_email，用于发送邮件。”第二种：“send_email，当用户需要给指定收件人发送邮件时调用。参数包括收件人地址（to，必须）、主题（subject，必须）、正文内容（body，必须）、抄送人（cc，可选）。调用前必须确认收件人地址格式正确。”显然后者能让 Agent 更准确地理解什么时候该用、参数怎么填。

3.3 编排层怎么设计，记忆怎么处理

当你有了多个 Skill 之后，就需要一个编排层来管理它们的调用顺序和条件逻辑。WorkBuddy 的编排逻辑是基于“任务规划-执行-检查”这个循环来设计的。Agent 拿到一个目标之后，会先拆解成步骤，然后逐步选择工具执行，执行完检查结果是否符合预期，不符合就调整策略重试。

这里面最容易出问题的是记忆处理。Agent 的上下文窗口是有限的，你不能把用户所有的历史消息都一股脑塞进去。实际操作中，我会把记忆分成三层：短期记忆，也就是当前这轮对话的上下文；工作记忆，也就是当前任务执行过程中产生的中途结果；长期记忆，也就是跨会话仍然需要保留的用户偏好、历史任务结论等。

在 WorkBuddy 里，短期记忆和工作记忆一般由运行时自动管理，长期记忆则需要你自己设计存储方案。简单场景下，用一个本地文件或者数据库表就行；复杂场景下，可以用向量数据库做语义检索，Agent 在执行任务前先检索一下和历史记忆最相关的内容，再决定怎么处理当前任务。

3.4 Python 和命令行工具的定位

聊了这么多设计和架构，最后落到具体实现的时候，你会发现 Python 和命令行工具依然是绕不开的基本功。WorkBuddy 的 Skill 支持通过 Python 脚本或命令行调用来执行，这也意味着你积累的 Python 工具函数，可以直接变成 Agent 的 Skill。

我个人的习惯是先把核心逻辑写成独立的 Python 模块，每一块功能对应一个函数，然后用一个统一的入口脚本包装成命令行工具。这样做有几个好处：第一，单独调试方便，Agent 层面出问题的时候可以先绕开 Agent 直接测工具；第二，复用性好，同一个工具既能给 Agent 用，也能自己手动调用；第三，迁移成本低，如果以后要换 Agent 框架，工具层基本不用重写。

这不是让你系统学一遍 Python，而是至少要会用 requests 调接口、会用 argparse 写命令行参数、会处理 JSON 数据。你的 Python 能力决定了你 Skill 的工具边界，而工具边界决定了 Agent 能帮你做什么事。

4. 实操过程：一个资讯聚合 Agent 的完整搭建

4.1 先定义业务场景和 Skill 清单

纸上谈兵聊完了，下面进入完整的实操环节。我以“行业资讯聚合 Agent”为例，带着大家从零跑通一条路径。这个场景很适合新手练习，因为它逻辑清楚、Skill 边界明显、最终产出可验证。

业务需求是这样的：每天早上 9 点，Agent 自动抓取几个指定技术资讯网站的内容，过滤掉重复信息，生成一份不超过 500 字的摘要简报，推送到一个群机器人。

我把这个需求拆成了四个 Skill：

• fetch_news：抓取指定 RSS 源或网页内容的标题和链接
• deduplicate：对抓取到的内容做去重处理
• summarize：调用大模型对内容做摘要生成
• push_message：把摘要内容推送到聊天工具的 webhook

这个 Skill 清单不是一步到位的。第一版其实只有fetch_news和push_message，摘要是我手动跑大模型生成的。跑通之后发现手动摘要在流程上太割裂，才逐步加上了去重和摘要的自动化。我的建议是，你也按照这个“先窄后宽”的顺序来做，每次只增加一个 Skill，验证通过后再加下一个，不要一次性铺开。

4.2 写公共工具层：RSS 抓取和内容清洗

第一步先写抓取模块。我选择了 RSS 作为主要信息源，因为相比直接抓网页，RSS 的输出格式更稳定，解析成本低得多。Python 里解析 RSS 用feedparser这个库就够了，很轻量，接口也简单。

import feedparser from urllib.parse import urlparse import re def fetch_news(source_url, limit=20): """从 RSS 源抓取最新文章条目""" feed = feedparser.parse(source_url) items = [] for entry in feed.entries[:limit]: items.append({ "title": entry.get("title", ""), "link": entry.get("link", ""), "published": entry.get("published", ""), "source": urlparse(source_url).netloc }) return items

这里有两个小坑。第一个是不同网站的 RSS 结构略有差异，有的把时间字段放在published，有的放在updated，稳妥做法是两个都取，优先非空的那个。第二个是编码问题，有些网站返回的内容编码不规范，feedparser解析出来的字符串可能带乱码。处理方案是抓取后用正则做一层清洗，把常见的不可见字符和 HTML 标签剥掉。

def clean_text(text: str) -> str: """清洗正文中常见的噪声内容""" text = re.sub(r'<[^>]+>', '', text) # 去掉 HTML 标签 text = re.sub(r'\s+', ' ', text).strip() # 合并空白字符 return text

清洗这一步看着简单，实际上特别重要。直接拿原始抓取内容去喂给大模型做摘要，不仅浪费 token，而且生成质量会明显下降。信息过载会稀释重点，噪声内容会让模型抓错方向。

4.3 编写并注册第一个 Skill

工具函数写完之后，下一步就是把它变成一个 Agent 能识别的 Skill。在 WorkBuddy 开放平台里，Skill 的创建入口在“Skill 管理”模块，我建议直接在网页控制台创建，后期再用代码管理。

Skill 需要填的信息包括名称、描述、输入参数定义和执行代码。以fetch_news为例，描述我写的是：“当用户需要获取最新行业资讯或科技新闻时调用。输入参数为 RSS 源地址，输出为文章条目列表。此 Skill 适用于定时任务或即时查询场景。”输入参数定义那栏，我用 JSON Schema 的格式声明了source_url字段，类型为 string，格式为 uri。

注册完成之后，Agent 在规划环节就能通过描述匹配到这个 Skill。这里有个很关键的体验：描述写得好不好，直接决定 Agent 检索 Skill 的准确率。如果你想把同一个 Skill 用在多个不同 Agent 里，描述就得写得通用一些；如果只给某一个 Agent 用，描述可以更具体，甚至可以带上触发场景的关键词来提高命中率。

4.4 写 Python 工具并接入平台 API

Skill 的注册在网页上做好之后，需要用代码把几个 Skill 串起来。我当时的做法是写一个 orchestrator.py，负责调度整个流程。这个脚本不直接和 WorkBuddy 客户端交互，而是通过平台提供的 API 来触发 Agent 执行，然后拿到执行结果。

先封装一个统一的 API 调用函数：

import os import requests from dotenv import load_dotenv load_dotenv() WORKBUDDY_API_KEY = os.getenv("WORKBUDDY_API_KEY") WORKBUDDY_BASE_URL = os.getenv("WORKBUDDY_BASE_URL") def run_agent(agent_id: str, task: str) -> dict: """调用 WorkBuddy 开放平台 API 触发 Agent 执行""" headers = { "Authorization": f"Bearer {WORKBUDDY_API_KEY}", "Content-Type": "application/json" } payload = { "agent_id": agent_id, "task": task, "stream": False } response = requests.post( f"{WORKBUDDY_BASE_URL}/agents/{agent_id}/run", headers=headers, json=payload, timeout=120 ) response.raise_for_status() return response.json()

这个接口是整个接入过程的关键。注意几个细节：timeout一定要设置，因为 Agent 执行可能比较慢，不设超时请求会一直挂着；stream参数可以根据场景调整，如果要做实时展示就把流式打开，如果只是后台跑任务就用非流式。

4.5 在 WorkBuddy 工作台里编排和调试

代码层面串起来之后，回到 WorkBuddy 桌面客户端或网页控制台，还有一个编排的环节。这里的“编排”是指定义 Agent 拿到一个任务后，Skill 的调用顺序和状态迁移规则。

我通常在“智能体管理”里新建一个 Agent，然后把需要用到的 Skill 全部关联上去，接着在编排面板里设置默认规划逻辑。WorkBuddy 默认的规划模式是“动态规划”，也就是 Agent 自己根据任务内容决定调用哪些 Skill、按什么顺序调用，这也是 Agent 和传统自动化流程最核心的区别——传统流程是固定的 if-else，Agent 是模型驱动的动态决策。

调试阶段有个技巧：先把动态规划关闭，手动指定 Skill 的执行顺序，等每一步都验证没问题了，再打开动态规划，观察 Agent 的自主决策是否符合预期。这就像是先给新人做一整套标准操作流程培训，然后再让他自己发挥。我见过很多开发者一开始就开动态规划，结果 Agent 经常在不该调用的时候调用了某个 Skill，又找不到原因，其实就是因为基础流程还没验证扎实。

4.6 定时触发和推进消息

最后一步是把 Agent 跑起来，并且定时执行。如果你有服务器，最简单的方案是直接用 cron 定时任务，每天 9 点执行一次 orchestrator 脚本。

0 9 * * * cd /data/workbuddy-demo && /usr/bin/python3 orchestrator.py >> logs/run.log 2>&1

如果暂时没有服务器，也可以用 WorkBuddy 平台自带的定时触发功能，在控制台配置一个计划任务，到点自动调用 Agent。这个功能支持设置 cron 表达式，比自己在服务器上维护任务省事得多。

推送环节我用的是一个通用的 webhook 推送函数，把最终的摘要文本通过机器人消息发到群里。这里有一个我踩过的坑：不要在推送前直接拿大模型的原始输出去发。大模型生成的摘要偶尔会带 Markdown 格式或者其他格式符号，很多群机器人对格式的支持很有限，直接发出去就会满屏乱码。我在推送前加了一层简单的格式清洗，只保留纯文本，删掉 Markdown 符号，实测下来稳定多了。

import re def clean_markdown(text: str) -> str: """去掉常见 Markdown 符号，避免推送时格式错乱""" text = re.sub(r'[#>*`\-]', '', text) text = re.sub(r'!\[.*?\]\(.*?\)', '', text) text = re.sub(r'\[(.*?)\]\(.*?\)', r'\1', text) return text.strip()

到这一步，一个“能自动干活”的 Agent 应用就算完整跑通了。从定时触发，到抓取信息，到生成摘要，再到推送结果，整条链路没有断点。

5. 常见问题与排查技巧实录

5.1 我踩过的几个典型坑

这套流程看起来不复杂，但实际从零跑通，我前后花了大概一周时间，大部分时间都耗在排查各种莫名其妙的问题上。这里挑几个最典型的坑说一下，希望能帮你避开。

第一个坑是 Agent 找不到对应的 Skill。Skill 注册成功，但执行的时候 Agent 就是不调用。排查了很久才发现，问题出在 Skill 描述里用了一些 Agent 不太理解的词汇。比如我在描述里写了“采集”，但实际上 Agent 内部对这个概念的理解更倾向于“获取”“抓取”“拉取”。把描述改成和 Agent 训练数据对齐的表达方式之后，问题立刻解决了。这种问题在传统编程里根本不会出现，但在 Agent 开发中非常常见，因为它不是编译错误，而是“理解偏差”。

第二个坑是 API 密钥被写进了代码仓库。有一版我图省事，把密钥硬编码在配置里推到了 Git 仓库的提交历史里，后来发现平台提示密钥存在安全风险，只能撤销重建。这个教训让我养成了一个习惯：所有密钥必须通过环境变量注入，代码仓库里只留.env.example模板，里面写变量名不写真值。

第三个坑是超时设置不合理。最初调用 Agent API 的时候没有设置 timeout，结果有一个耗时较长的任务直接让请求挂了 15 分钟，把调用方整个阻塞了。后来在 API 层加了 120 秒的超时，在业务流程层加了整体超时控制，问题才彻底解决。Agent 的执行时间波动很大，同一个任务在模型负载高的时候可能比平时慢好几倍，超时设置一定要留足余量。

5.2 常见报错与处理速查

为了省事，我把接入过程中遇到过的问题整理成了一个速查表，不管是做 WorkBuddy 还是对接其他 Agent 平台，这些思路基本通用。

5.3 几条独家避坑心得

最后，再分享几条不太会写在官方文档里的经验。

第一条：调试 Agent 时，一定要保留完整的执行日志。WorkBuddy 控制台提供了调用链路的追踪能力，可以看到 Agent 每一步做了什么推理、调了哪个 Skill、结果是什么。这基本就是 Agent 的“后台日志”。我习惯把每个任务的真实运行轨迹保存下来，积累一段时间后回头看，对优化自定义指令和 Skill 描述非常有帮助。

第二条：不要追求一个 Agent 做所有事。我一开始设计的 Agent 试图同时处理“资讯聚合”和“竞品分析”和“自动回复”，结果什么都不精。后来拆成了三个不同的 Agent，每个各司其职，整个系统稳定性和可用性都上了一个台阶。Agent 架构里的“团队协作”比“全能单体”靠谱得多。

第三条：善用自定义指令来控制 Agent 的输出风格。如果你的 Agent 最终是给用户直接使用，一定要在自定义指令里明确输出的格式、长度、语气。否则模型默认的输出风格很可能不适合你的业务场景，出现“答非所问”或“啰嗦冗长”的问题。我在所有 Agent 的自定义指令里都写了这么一条：“回答时先给出结论，再给理由；如果用户没有明确要求，不要输出多余的推荐和展望。”这个小改动让整个 Agent 的输出质量提升非常明显。

第四条：版本管理很重要。Skill 的每一次改动都建议记录版本号，调试时如果发现效果变差了，可以快速回退到上一版。千万不要直接在线上服务上用最新版本的 Skill，最好先复制一个 Agent 测试，验证没问题再切换。

6. 更进一步：从单 Agent 到多 Agent 协作

6.1 多 Agent 协作的扩展路径

前面的实操案例是单 Agent 架构，当一个 Agent 拿着所有 Skill 硬跑一个复杂任务的时候，你会很快遇到瓶颈。比如“资讯聚合 Agent”如果再加上“数据清洗后存入数据库”和“按用户偏好推送不同内容”这两个需求，单个 Agent 的上下文处理和规划能力就会变得吃紧。

这时候就需要考虑拆分成多 Agent 协作。我一般按照“职责”来拆分，而不是按照“功能”来拆分。举个例子，一个完整的资讯系统可以拆成四个 Agent：采集 Agent 负责抓取所有数据源；清洗 Agent 负责对抓取结果做去重、格式化、入库；分析 Agent 负责基于清洗后的数据生成摘要和洞察；推送 Agent 负责对接不同渠道，按不同用户的偏好分发内容。Web 层只负责触发，四个 Agent 之间通过平台的消息或任务机制来传递数据。

拆分之后，每个 Agent 的自定义指令可以写得非常聚焦。采集 Agent 只需要知道“抓什么、存哪里”；分析 Agent 只需要知道“读什么、怎么分析、输出什么格式”。这样一来，每个环节的稳定性都更容易保证，排查问题时也不需要从头到尾翻一遍整个链路。

6.2 在 WorkBuddy 中实现 Agent 之间的协作

从单 Agent 到多 Agent，在 WorkBuddy 开放平台里的实现方式比较简单。核心思路是：一个 Agent 的 Skill 调用范围可以扩展到另一个 Agent。也就是说，A 的某个 Skill 不是一个工具函数，而是一个子任务，这个子任务由 B 来执行。

我在官方开放平台的 API 文档里看到过“agent invoke agent”的接口能力。具体到操作层面，你可以在 A 里定义一个类似invoke_analyzer的 Skill，它描述里写着“当需要生成周报分析时，调用分析 Agent”。这样 Agent A 收到一个“帮我把本周资讯整理成周报”的任务时，会先自己完成资讯抓取和清洗，然后在分析环节，直接调用 Agent B 的接口，拿到结果后继续完成推送。

这个模式的好处是 Agent 边界清晰，每个 Agent 都可以独立开发、独立测试、独立部署。坏处是调用链变长，延迟也会上去。我建议多 Agent 之间的调用尽量用异步任务，不要让用户在线等。比如周报这种场景，可以做成用户提交需求后先返回“正在生成”，等全部 Agent 跑完再主动推送结果。

6.3 什么时候可以引入记忆模块

当你开始做多 Agent 协作，记忆模块就变得非常重要了。单 Agent 场景下，记忆无非是上下文窗口的事；多 Agent 场景下，Agent 之间的信息传递如果处理不好，就会出现“各干各的、信息断层”的问题。

在 WorkBuddy 里做跨 Agent 记忆，我的方案是使用一个共享的存储层。具体来说，用一个 MySQL 或者 SQLite 表，按agent_id + task_id作为维度，存储执行过程中的中间状态。采集 Agent 把抓取结果写入news_raw表，清洗 Agent 读取news_raw，处理后写入news_clean表，分析 Agent 再读取news_clean，生成结果写入news_report表。每一步都有关键状态记录，谁出问题了一查表就知道卡在哪个环节。

这个方案比用消息队列更简单直接，对个人开发者来说也更容易实现和维护。而且绝大多数 Agent 平台的“记忆”本质上就是各种形式的存储，只是封装复杂度不同。不要把“记忆”想得太玄乎，它就是一个可以被检索和写入的存储层，只是存的内容和读取方式跟传统应用相比更动态、更依赖语义而已。

6.4 如何评估 Agent 应用的效果

最后聊一个很容易被忽视的问题：你做了一个 Agent，怎么判断它做得好不好？

传统软件可以用功能测试用例、单元测试覆盖率、响应时间这些指标来评估。但 Agent 应用的核心决策逻辑是模型驱动的，同样的输入可能产生不同的输出，评估方式就不能照搬传统软件。

我自己的做法是建立一个小型的评测数据集，大概五十到一百条典型任务输入，每条输入都预先写好“期望行为标准”。评估的时候不是看 Agent 是否给出了精确答案，而是看它是否走对了流程。比如资讯聚合这个场景，期望行为标准是：Agent 是否访问了正确的数据源、是否做了清洗、是否生成了摘要、是否完成了推送。如果每一步都执行成功，但摘要有几处信息不准确，那这个 Agent 已经算合格了，剩下的可以用更详细的指令约束去修正质量。

这个思维转变非常重要：传统软件开发追求“无错误”，Agent 开发追求“在可控范围内稳定完成流程”。接受这个差异，你才不会在评估阶段过度焦虑。

7. 写在最后的个人体会

这套从零接入的路径，前前后后我走了好几遍，也看着身边不少朋友从“对 Agent 开发一头雾水”到“能独立做出可用的工具”。最大的体会是：Agent 开发的门槛确实在降低，但“会用平台”和“会做 Agent”之间还是有一条很长的路。平台解决了基础设施的问题，比如模型调用、Skill 注册、API 封装，但解决不了业务拆解和指令设计的问题，这恰恰是 Agent 应用能不能真正落地的关键。

还有一个很实际的建议：别等什么都想清楚了再动手。先把最小的闭环跑起来，哪怕它只能完成一个再简单不过的任务。只要链路通了，后面的优化都是在已经稳定的地基上添砖加瓦。如果一开始就跑一个复杂的大而全的 Agent，你会陷入“不知道是能力问题还是配置问题”的泥潭里，非常打击信心。

如果你也在做 Agent 应用，遇到什么问题，欢迎在评论区聊。特别是那些“看起来应该能跑但就是跑不通”的诡异问题，往往是最有价值的经验。