最近被问得最多的一个问题就是：个人开发者想上手做 Agent，到底该从哪里开始？市面上框架一大堆，从 LangChain 到各类编排引擎，光选型就能劝退一半人。我自己试了一圈下来，最后反而是在 WorkBuddy 开放平台上把第一个能上线的 Agent 应用跑通了。这个平台乍一看不算张扬，但它的设计思路很对像我这种“想验证想法、又不想被框架绑架”的开发者的胃口。这篇文章我不讲虚的，就把从注册开放平台、配置环境、写第一个 Agent，到落地一个真实内部工具的完整过程拆开给你看，所有踩过的坑和最终可复用的方案都在里面。
1. 先搞清楚要接入的到底是什么：WorkBuddy 开放平台的定位
1.1 它不是聊天机器人壳子，而是“工作伙伴”型 Agent 平台
WorkBuddy 这个名字挺有意思，它是 Work 加 Buddy，而不是 Work 加 Tool。这个命名其实已经把产品的立场说清楚了：平台想解决的不是单点问答，而是让 Agent 像同事一样帮你把一套完整的工作流程跑完。
我理解它的核心架构可以拆成几块：应用（Application）、技能（Skill）、工作流（Workflow）、记忆（Memory）和工具（Tools）。你在控制台创建一个应用，给它配上大模型参数，挂上几个 Skill，再定义一个触发方式，一个能实际干活的 Agent 应用就算成型了。
这里最关键的概念其实是 Skill，而不是普通意义上的“插件”。Skill 在 WorkBuddy 里的定位是一段可复用的“能力封装”：它包含触发条件、执行步骤、提示词模板，甚至可以带上外部 API 的调用配置。你可以把一个 Skill 理解成“教 Agent 怎么完成某一类任务的操作手册”，比如“把 Git 提交记录整理成周报”、“把会议纪要转成 Todo 列表”、“定时抓取某个页面并做摘要”。多个 Skill 挂在一个 Agent 下，Agent 就能根据用户输入决定调用哪一个。这个设计和 OpenAI 的 Assistant、Claude 的 Tools 思路接近，但 WorkBuddy 做了更面向业务场景的封装，门槛低不少。
1.2 个人开发者为什么要重点盯住这类开放平台
我的判断是：Agent 开发正在经历从“造框架”到“做应用”的转变期。早期玩 Agent，大家沉迷搭编排框架、研究各种 Memory 方案，折腾一个月可能产不出一个能用的东西。但 WorkBuddy 这类开放平台把基础设施打包成了托管服务，个人开发者的精力可以全部放在业务逻辑本身。
具体来说，开放平台对个人开发者有三个很实际的帮助。第一是省掉基建成本，模型 API、会话管理、工具调用协议、并发调度这些不需要你从头实现了，控制台点几下就能用。第二是降低踩坑概率，Agent 开发真正难的部分其实在工程侧，比如上下文管理、工具返回异常、模型输出不稳定，平台做了大量默认处理。第三是生态复用，官方 Skill 市场和社区贡献的 Skill 可以直接拿来改，很多通用场景根本不需要从头写提示词。
当然，这不是说框架完全没用。对于那些需要深度定制、有自己的模型部署和私有数据管道的场景，自研框架依然是必要的。我的建议是：先用 WorkBuddy 这类平台把业务跑通，验证 ROI，再根据瓶颈决定要不要下沉到自研层。不要一上来就自己造轮子。
1.3 WorkBuddy 与扣子、自研框架的差异在哪
很多朋友会问，WorkBuddy 和扣子（Coze）、Dify 这类平台有什么区别，和 LangChain 又是什么关系。我用过这几个，简单总结一下差异：
- 扣子和 Dify 更偏“低代码应用搭建”，面向的很多是运营和产品同学，它们的强项是把 Bot 快速发布到各个渠道，但底层的编排灵活性相对受限。
- LangChain 这类框架是给开发者用的积木库，灵活度最高，但你需要自己解决部署、监控、记忆持久化、多租户隔离等等一堆工程问题。
- WorkBuddy 给我的感觉是介于两者之间：它对开发者友好，有完整的 API 和 CLI，不是纯拖拽页面；同时它把运行时的脏活累活接住了，省去自己维护基础设施的麻烦。
我做个简单对比表格，方便你判断：
| 维度 | WorkBuddy 开放平台 | 扣子这类低代码平台 | LangChain 自研方案 |
|---|---|---|---|
| 上手门槛 | 中低，会 API 就能接 | 低，拖拽为主 | 高，需掌握框架与工程化 |
| 灵活性 | 中高，支持自定义 Skill 和工具 | 中，受平台能力限制 | 极高 |
| 运维成本 | 低，平台托管 | 低，平台托管 | 高，自行负责 |
| 私有化部署 | 支持本地部署 | 部分商业化版本支持 | 完全自主 |
| 适合人群 | 想做真实应用的独立开发者 | 快速验证想法、偏运营场景 | 有工程团队、深度定制需求 |
所以我的建议很直接：如果你是想靠 Agent 做点实际产出的独立开发者，优先走 WorkBuddy 开放平台，先跑通一条完整链路再说，不要一头扎进框架的海洋。
2. 接入前的准备工作：控制台、密钥与运行环境
2.1 注册账号并创建第一个应用
WorkBuddy 开放平台的接入流程不算复杂，分三步：注册开发者账号、创建应用获得密钥、配置模型供应商。
打开官网后进入开发者控制台，用手机号或邮箱注册即可。登录后进入“工作台”，左侧菜单找到“应用管理”，点击“创建应用”。这里需要填写几个基本信息：应用名称、用途描述、默认模型。用途描述我建议认真写，因为平台会给应用自动生成初始的助手人格和系统提示词，描述越清晰，初始配置越接近你想要的效果。
创建完成后，进入应用详情页，你会看到三个关键凭证：App ID、API Key、App Secret。API Key 和 App Secret 务必备份好，这个页面关掉后密钥不会完整显示第二次。平台会提供“沙箱环境”和“生产环境”两套密钥，开发阶段先用沙箱，避免误操作消耗生产配额。
这里有一个小提醒：不要把密钥硬编码进前端代码或者公开仓库。个人开发者图省事最容易犯这个错。正确的做法是把密钥放在后端环境变量里，或者用平台提供的密钥管理接口动态获取。
2.2 本地部署模式：Ubuntu 22.04 安装实测
除了云上托管，WorkBuddy 支持本地部署，特别适合对数据安全有要求的场景。我实测的是 Ubuntu 22.04 服务器，配置是 4 核 8G，跑轻量 Agent 应用足够了。
本地部署通常有两种方式：一种是通过官方安装脚本，适合快速体验；另一种是拉源码自行编译，适合二次开发。我用的是安装脚本方式，命令很简单：
curl -fsSL https://get.workbuddy.dev/install.sh | bash脚本会检测系统环境，自动安装 Python 3.10+、Node.js 18+ 和 Docker（如果你选择用 Docker 方式运行）。安装完成后，需要设置环境变量：
export WORKBUDDY_HOME=/opt/workbuddy export WORKBUDDY_MODEL_API_KEY=你的模型服务商Key export WORKBUDDY_DATABASE_URL=sqlite:///$WORKBUDDY_HOME/data/workbuddy.db然后是启动服务：
workbuddy server start --host 0.0.0.0 --port 8080启动成功后访问http://服务器IP:8080就能看到自托管的 Web 控制台，功能与云端版基本一致。这里有个细节容易踩坑：默认情况下服务只监听 127.0.0.1，如果你在远端服务器部署，一定要显式加--host 0.0.0.0，否则外网访问不到。
为了让服务在重启后自动拉起，我还配了一个 systemd 服务。配置文件放在/etc/systemd/system/workbuddy.service，内容大致如下：
[Unit] Description=WorkBuddy Server After=network.target [Service] Type=simple User=workbuddy EnvironmentFile=/etc/workbuddy.env ExecStart=/usr/local/bin/workbuddy server start --host 0.0.0.0 --port 8080 Restart=always RestartSec=10 [Install] WantedBy=multi-user.target配置完执行systemctl daemon-reload && systemctl enable --now workbuddy即可。
2.3 网页版还是本地部署，怎么选
我个人的建议是分场景来看：
- 追求快速验证、不想管服务器：直接用云端版，注册即用，平台帮你处理扩容和更新。
- 涉及公司内部数据、有隐私合规要求：必须本地部署，数据不出内网。
- 想深度定制平台行为、改源码：本地部署更适合，因为你能改到每一层。
成本上，云端版是按 token 消耗计费的，本地部署则主要是服务器成本。如果你的 Agent 调用量稳定且较大，本地部署长期看更划算。另外提醒一句，本地部署不等于不用付模型接口费用，你仍然需要接入大模型 API，模型费用省不掉。
2.4 模型接入：DeepSeek、Qwen 与 OpenAI 兼容接口配置
WorkBuddy 本身不生产模型，它做的是“模型无关”的接入层。平台支持的模型来源很广，包括 DeepSeek、通义千问、以及各类提供 OpenAI 兼容接口的服务商。
在控制台的“模型供应商”页面，你可以添加多个模型来源。我目前主力用的是 DeepSeek 的 deepseek-chat，性价比确实高。配置方式很简单：选择供应商类型，填写 API Key，设置模型名称，平台会自动拉取模型列表。如果你用的是 OpenAI 兼容接口，选择供应商类型时选“OpenAI Compatible”，然后填写 Base URL 和模型名，像这样：
Base URL: https://你的模型服务地址/v1 Model Name: qwen-plus这里有一个很关键的坑：很多 OpenAI 兼容服务商的 Base URL 末尾自带/v1，WorkBuddy 的配置框里有时又会自动拼接/v1，如果你两边都填了就变成了/v1/v1，请求直接 404。我的经验是：先看平台右上角的接口文档，里面有标准的 URL 拼接示例，照着填最稳。最简单的方式是在 Base URL 里只填到域名那一级，模型后缀由平台自动处理。
3. 实战：从零搭一个自动周报生成 Agent
3.1 为什么第一个项目选周报生成
我见过太多人一上来就想做个“全能助手”，结果做出来的东西啥都能聊两句，却没有任何一个任务能稳定交付。我的建议是，第一个 Agent 一定要选一个边界清晰、数据可得、产出明确的场景。
“项目周报自动生成”就是典型的合适场景。它有明确输入：Git 提交记录、任务管理平台状态、文档链接；有明确输出：结构化周报 Markdown；有可评价的标准：内容准确、格式统一、无需大改。而且这个任务重复性强、耗时又烦，自动化价值立竿见影。
我当时的诉求很简单：每周五下午，Agent 自动拉取我这周的 Git 提交和 Issue 变更，生成一份分栏的周报草稿，我用十分钟改改就能交付。不要小看这个“草稿”定位，它决定了 Agent 的容错空间，也决定了你第一版能不能顺利落地。
3.2 创建 Agent：系统提示词与模型参数
在控制台创建一个名为“周报助手”的 Agent。创建时会让你填系统提示词，这个环节值得好好琢磨。我给自己的 Agent 写的系统提示词核心逻辑是这样的：
你是一名项目助理，负责把开发数据整理成周报。 工作流程： 1. 分析用户提供的 Git 提交记录和任务状态； 2. 按「本周完成」「进行中」「风险与阻塞」三栏重组信息； 3. 技术细节保留关键信息，去除冗余； 4. 最终输出 Markdown 格式周报。 约束： - 不得编造不存在的提交记录； - 风险与阻塞栏必须有具体描述，不得为空； - 使用中文输出。模型参数方面，我做了一组实际测试。temperature 默认是 0.7，但对周报这种强结构化任务，我调低到了 0.3，生成结果稳定性明显提升。max_tokens 建议设置，周报输出一般几百 token 就够，我设了 1500，避免模型发挥太多导致输出过长。top_p 保持默认即可，对于确定性任务作用不大。
这里顺便说一个通用经验：面向“总结、整理、分类”这类任务，温度调低；面向“头脑风暴、创意文案”这类任务，温度可以拉到 0.8 以上。很多人开发 Agent 效果不稳定，第一步就是栽在参数没调好上。
3.3 配置 Skill：把工作流沉淀为可复用技能
WorkBuddy 和普通聊天 Bot 的一个核心区别，就是 Skill 机制。我把“周报生成”做成了一个 Skill，这样这个能力不仅可以挂给周报助手，以后还能挂给其他 Agent 使用。
在控制台的“技能管理”里创建技能，需要填写两个关键部分：技能描述和技能逻辑。技能描述决定了 Agent 在什么时候调用它，我写的是：“当用户要求生成周报、日报、或者整理开发进度时调用此技能。支持输入 Git 提交记录、Issue 列表、项目文档等”。这个描述千万不能乱写，Agent 是否在正确时机触发 Skill，靠的就是这段描述。
技能逻辑部分，支撑一个 YAML 结构的模板：
name: weekly_report_generator version: 1.0.0 description: 根据开发数据生成周报 inputs: - git_logs - issues - documents steps: - name: parse_inputs action: llm prompt_template: "请提取以下数据中的关键信息... \nGit记录：{{git_logs}}\nIssue列表：{{issues}}" - name: classify action: llm prompt_template: "将上述信息分为三栏：本周完成、进行中、风险与阻塞" - name: format_output action: llm prompt_template: "按模板输出 Markdown 周报"Skill 写好后点击“发布”，在周报助手的“已安装技能”里选中它，Agent 就会在适当的时机自动调用。这个封装的价值是：你的处理逻辑改一次，所有挂载了这个 Skill 的 Agent 同步生效。
3.4 通过 API 把 Agent 接入自己的工具链
画龙点睛的一步，是让 Agent 可以被外部程序调用。WorkBuddy 开放平台提供了标准的 REST API，我直接用 Python 写了个脚本，每周五由 Cron 触发。
API 调用的核心是获取一次运行任务的 ID，然后轮询结果。我封装了一个非常简洁的调用方式：
import requests import time API_BASE = "https://api.workbuddy.dev/v1" APP_ID = "your_app_id" API_KEY = "your_api_key" AGENT_ID = "your_agent_id" headers = { "X-App-Id": APP_ID, "Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json" } def run_agent(input_data: str): resp = requests.post( f"{API_BASE}/agents/{AGENT_ID}/runs", headers=headers, json={"input": input_data, "stream": False} ) resp.raise_for_status() run_id = resp.json()["run_id"] # 轮询运行状态 while True: status = requests.get( f"{API_BASE}/runs/{run_id}", headers=headers ).json() if status["status"] in ("succeeded", "failed"): return status time.sleep(3) if __name__ == "__main__": git_logs = open("weekly_git_log.txt").read() issues = open("weekly_issues.json").read() result = run_agent(f"以下是本周数据，请生成周报：\nGit: {git_logs}\nIssues: {issues}") with open("weekly_report.md", "w") as f: f.write(result["output"])跑完一次，一份周报草稿就静静躺在文件里了。整个过程无人工干预，体验非常顺滑。更大的意义在于：Agent 不再局限于网页对话框，而是变成了可以被脚本、定时任务、甚至其他系统调用的基础设施。
4. 进阶玩法：记忆、工具调用与多 Agent 编排
4.1 记忆机制到底该怎么用
一个成熟 Agent 和简单对话 Bot 的分水岭，就是记忆。WorkBuddy 把记忆分了两层：会话记忆和长期记忆。
会话记忆很好理解，就是同一轮对话里 Agent 能记住你前面说了什么。默认情况下平台会自动维护上下文，你不需要管。但要注意，上下文不是越多越好，token 是有限的，会话太长会导致后续响应质量下降。建议在需要“从头开始新任务”时，显式调用清空会话接口，或者在代码里重新开启一个 conversation_id。
长期记忆是平台的亮点，它允许 Agent 把重要信息“沉淀”下来，跨会话使用。比如我让周报助手记住每个项目的项目代号和负责人，下次生成周报时它就不需要我重新解释一遍。实现方式是平台内置的向量库，你可以在 Skill 里加一个“记住”步骤：
- name: remember_project_info action: memory.save key: project_info value: "{{extracted_project_info}}"下次对话时，只需要在提示词模板中引用{{memory.project_info}}，Agent 就会自动检索相关记忆供参考。这个功能用得好，Agent 的体验完全是质的飞跃。
4.2 工具调用：给 Agent 接上真正的“手”
很多任务光靠模型生成是不够的，还需要读取真实数据、操作外部系统。这就靠工具调用。WorkBuddy 支持的底层能力和 Function Calling 一致：模型生成一个结构化的调用请求，平台帮你执行，并把结果返回给模型继续处理。
我在周报助手上挂了一个“读取 GitLab 提交记录”的自定义工具。你只需要在控制台创建一个工具，提供一个能描述清楚功能和入参的 JSON Schema 就行：
{ "name": "get_gitlab_commits", "description": "获取指定项目在指定时间段的提交记录", "parameters": { "type": "object", "properties": { "project_id": {"type": "integer", "description": "项目ID"}, "since": {"type": "string", "description": "开始时间，ISO格式"}, "until": {"type": "string", "description": "结束时间，ISO格式"} }, "required": ["project_id", "since", "until"] } }平台会根据这个 Schema 自动生成工具调用协议。当 Agent 觉得需要最新提交数据时，它会自己决定调用这个工具，填入参数，等待结果返回后继续执行后续步骤。这里有一个非常实用的经验：工具的描述一定要写清楚“什么时候用、每个参数是什么”，因为模型就是靠 description 来决定是否调用以及怎么填参数的。描述写得含糊，模型就会频繁误调用或者拒绝调用。
4.3 多 Agent 协作与工作流编排
当你手上有了不止一个 Agent，下一步自然就是想让他们协作。比如我把“周报生成 Agent”和“数据预处理 Agent”分开，前者负责产出内容，后者负责从多个数据源清洗数据。两个 Agent 之间通过工作流编排串联起来。
在 WorkBuddy 的“工作流”模块里，可以拖拽节点定义流程：一个节点调用预处理 Agent，输出作为下一个节点的输入，传给周报 Agent。节点之间还支持条件分支，比如“如果数据量超过阈值，先执行分段摘要”。这种编排方式有图形化界面，但又保留了足够的逻辑控制能力，不用写一堆胶水代码。
这里想说清楚一个概念：Agent 框架和编排不是一回事。框架（Framework）是构建 Agent 运行机制的底层工具，比如管理模型调用循环、记忆读写、工具执行；编排（Orchestration）是把多个 Agent 和工具组织成一个流程去完成复杂任务。用 WorkBuddy 的时候，框架层逻辑由平台替你消化了，你只需要关注编排层怎么设计业务流。这也是我强烈建议新手从这类开放平台入门的原因：不要把精力耗在底层机制上，先学会设计流程。
4.4 进阶选型：什么时候该自研框架
话虽如此，我还是得客观说一句：WorkBuddy 这类平台适合大多数应用场景，但不适合所有场景。如果你需要极低延迟的实时流式响应、需要在 Agent 内部集成自研的强化学习控制逻辑、或者要对每一个模型的输出做复杂的后处理，那平台的黑盒部分就会成为瓶颈。
到这一步，你再考虑引入 LangChain、AutoGen 或者自己写 Harness。实际上我刚接触 Agent 时也不太清楚 Harness 到底指什么，后来才搞明白：Harness 可以理解成“承载 Agent 循环的外壳”，它定义了模型怎么被调用、工具结果怎么回填、循环什么时候终止、异常怎么处理。简单说，框架更偏编程接口，Harness 更偏运行机制。用 WorkBuddy 时平台已经把 Harness 打包好了，你不需要关心；自研一旦启动，就要自己面对这些细节。
我的个人建议是：先用开放平台跑通业务模型，确认需求真实成立，再逐步把瓶颈模块替换成自研组件，而不是一上来就全栈自研。这不仅是技术选型，也是成本控制。
5. 实操中必踩的坑：常见问题与排查实录
5.1 认证失败（401）到底错在哪
在我接入早期，遇到最多的就是 401 认证失败。排查下来，绝大多数情况是请求头写错了。WorkBuddy 对 API 请求的认证要求是：App ID 放在请求头指定参数里，API Key 以 Bearer Token 形式传递。很多人会把 API Key 当成 query 参数拼接在 URL 上，结果就是反复 401。
还有一个隐蔽问题：沙箱环境的密钥和生产环境的密钥不通用。本地调试时用沙箱密钥没问题，但如果你通过环境变量去读，而环境变量里混着另一套密钥，就会非常困惑。我的建议是：把密钥按环境严格隔离，本地使用.env文件，部署到服务器使用独立的 systemd EnvironmentFile，千万别图省事写死在代码里。
5.2 Token 超限与上下文截断
第二个高频问题是运行到一半报 token 超限（context length exceeded）。这通常不是模型参数的问题，而是上游输入数据太大了。比如我最初让周报助手直接读整年的 Git 提交，一次性塞进去，直接超限。
解决办法是“分段处理”：先用一个 Skill 把原始数据按时间或模块切成小段，逐段生成摘要，最后再合并成最终产出。WorkBuddy 的高级模式里有一个“并行处理”选项，可以在工作流里同时处理多个分段，然后汇总结果。这样既绕开了单次上下文限制，还加快了响应速度。
另一个技巧是清理会话历史。如果 Agent 已经跑了很多轮，上下文里积累了太多无关信息，及时开启新会话能有效避免 token 浪费和上下文污染。
5.3 Agent 执行中断："Agent execution terminated due to error"
这个报错我印象太深了，因为最初我一看到它就头大。后来复盘发现，绝大多数“执行中断”是因为 Agent 在工具调用环节出了问题：要么工具返回的格式不是模型期望的 JSON，要么工具超时导致循环卡住，要么模型陷入了“调用工具—看结果—再调用工具”的死循环，最终触发平台的保护机制被强制终止。
排查思路是按顺序检查：先看运行日志里最后一次工具调用的结果返回了什么；再看工具返回内容是否被正确截断或转义；最后检查是否需要给 Agent 设置迭代上限。在 WorkBuddy 的 Agent 配置里有一个“最大工具调用次数”参数，默认是 5，如果你设计的任务需要模型多次查数据，这个值要适当调高，比如 10。反过来，如果你的 Agent 总在反复调用同一个工具，说明工具描述或者提示词引导有问题，压住循环的次数只是一个治标方案，根本解法是优化工具 Schema。
排查顺序建议： 1. 打开本次运行的详细日志； 2. 定位失败前的最后一个节点； 3. 如果是工具节点，检查输出结果和前一个/后一个节点的输入格式； 4. 如果是大模型节点，尝试降低输入长度或调低温度； 5. 加入错误处理节点，捕获工具执行异常，避免整个 Run 中断。5.4 Linux 本地部署的依赖问题
本地部署这一路也不是没坎坷。Ubuntu 20.04 和 22.04 上最容易出问题的是 Python 版本，WorkBuddy 要求 3.10 以上，但系统自带的可能是 3.8。装完脚本如果执行workbuddy --version没反应，先检查是不是 PATH 没刷新，执行source ~/.bashrc再看。
还有一类常见问题是缺少编译依赖，比如安装某些 Python 包时提示缺libffi-dev、libssl-dev。解决办法很简单：
sudo apt update sudo apt install -y python3-pip python3-dev build-essential libssl-dev libffi-dev装完再重新执行安装脚本，基本就顺了。另外，如果你用了 Docker 部署，注意把数据目录挂载出来，否则容器一销毁，你配置好的 Skill 和应用全没了。这个坑我亲身遇到过，重来一遍非常痛苦。
5.5 常见问题速查表
我把实战中最常遇到的问题整理成一个速查表，方便你直接对照：
| 现象 | 可能原因 | 解决思路 |
|---|---|---|
| 接口返回 401 | 请求头认证信息缺失或错误、密钥环境不一致 | 检查 X-App-Id 与 Authorization 格式，核对沙箱/生产密钥 |
| 请求成功但空输出 | 模型参数过低、输入太短、提示词引导不足 | 调高 max_tokens，优化系统提示词，检查是否命中 Skill |
| 工具调用无效 | JSON Schema 参数描述不清、参数类型错误 | 重写工具 description，严格校验参数格式 |
| Agent 执行中断 | 工具循环、异常未捕获、上下文过长 | 查看详细日志，限制迭代次数，增加错误处理节点 |
| 本地服务启动失败 | Python 版本过低、依赖缺失 | 安装 Python 3.10+，补齐系统编译依赖 |
| Web 控制台无法外网访问 | 服务未监听 0.0.0.0 | 启动时加 --host 0.0.0.0，检查防火墙 |
| Token 消耗异常偏高 | 上下文冗余、重复调用工具 | 分段处理输入，必要时清空会话，压缩工具结果 |
这张表我建议收藏，哪怕过几个月回来看也还有用。很多问题表面上前因后果完全不同，排查到最后你会发现根因都集中在配置、上下文和工具调用这三个源头。
6. 最后分享几点个人经验
第一件事，一定要给提示词和 Skill 做版本管理。我在 WorkBuddy 里调好的周报提示词，后来改了一版“更简洁”的，上线后效果反而变差，最后还得靠 Git 回滚。现在我会把所有 Skill 的定义文件同步到 Git 仓库里，任何改动都走 commit，比在平台上瞎试靠谱得多。
第二件事，尽量让 Agent 输出结构化数据而不仅仅是自然语言。在提示词里明确要求“以 JSON 格式输出关键结果”，后续再接其他系统或者做自动化处理会轻松很多。这个习惯越早养成，后面做复杂编排时越省力。
第三件事，踩坑不可怕，可怕的是不看日志。WorkBuddy 每一次运行都保留完整轨迹，包括模型调用、工具返回、节点耗时，全部可视化。遇到问题第一反应应该是打开运行详情，而不是盲改提示词。我见过太多人一个报错截图发群里问原因，其实日志里写得清清楚楚。
如果你也是个人开发者，想认真做 Agent 应用，我给的建议是：今天就把第一个最小闭环搭起来，哪怕只是让 Agent 帮你读一个文件、总结一段话。先跑通，再谈优化。这条路我走下来了，没有想象中那么难，但每一步都需要动手。
