这段时间AI圈子里“Agent”几乎被喊成了标准答案朋友圈动不动就是“Agent即将取代xx”。但说实话真正能用起来、能接进自己工作流的Agent工具并不多。大多数号称Agent的产品打开以后无非是“带记忆的聊天框”让你问它问题它打一段字完事。直到我把WorkBuddy装好、把第一个Skill跑通才对“Agent工作台”这个词有了实感。WorkBuddy是开发工具领域里一个特殊的存在它不是一个单纯的对话机器人也不是一个IDE插件而是一个可以“生产Agent”的工作台。你可以通过自然语言定义一个任务把大模型当大脑把Python脚本、命令行、API调用当成手脚让它按步骤完成一份报告、整理一批数据、甚至去做一个跨系统的流程编排。它能做什么很大程度取决于你给它装什么“技能”。这篇内容我会按我自己的上手指路来写安装、初始化、核心概念、写第一个Skill、踩坑记录都覆盖到适合刚接触Agent、想把手头重复事务真正自动化的人。1. WorkBuddy是什么先把它和普通聊天机器人掰开1.1 一句话定义可扩展的Agent运行工作台先说一个我在社区里观察到的现象很多人第一次用WorkBuddy会下意识把它当成“又一个ChatGPT网页壳”点开界面就想聊天。实际上它的定位完全不同。WorkBuddy更像一个“Agent运行时环境”它负责调度模型、编排步骤、加载工具、管理记忆、执行脚本并提供可观测的日志。如果做个类比普通聊天机器人是一个“问答收银台”你问一句它答一句WorkBuddy则像一个“带操作间的厨房”。你给它一份菜谱Skill它按照菜谱洗菜、切菜、下锅最后端出来的不是文字建议而是一盘真实的菜。这里的关键是“执行”它会真的去读写文件、调用接口、操作浏览器、运行代码然后把结果交给你确认或继续加工。这个设计解决了一个很实际的问题大模型擅长“说”但不擅长“做”。让大模型直接生成一段步骤建议剩下的活还是得你自己干这样的Agent就没有闭环。WorkBuddy把“决策”和“执行”拆开决策交给模型执行交给你定义的Skill和工具两头一接才真正有“数字员工”的样子。1.2 与CodeBuddy的分工一个偏代码一个偏业务讨论WorkBuddy时经常绕不开CodeBuddy。两者同属一个技术体系下的Agent产品但侧重点明显不同。CodeBuddy更聚焦软件研发场景嵌在IDE里帮你改代码、跑测试、查报错服务的对象是开发者WorkBuddy则更通用适合跨系统的任务自动化服务对象可以是产品、运营、测试甚至完全不懂代码的业务人员。实际使用中我通常这么分工写代码、修Bug这类工作丢给CodeBuddy而把“整理会议纪要并生成待办”“定时抓取页面数据生成报表”“把散落各处的文本归类存档”这类流程性事务交给WorkBuddy。两者可以配合使用比如WorkBuddy通过脚本调用代码仓库接口再把结果喂给CodeBuddy做分析。之所以强调这个区别是因为很多新手会把两个产品搞混下载了CodeBuddy以后到处找“工作流编排”入口找不到就得出“不好用”的结论。工欲善其事必先利其器先确认你要解决的是哪类问题。1.3 到底适合谁人群与场景边界我根据自己的使用体验把适合用WorkBuddy的人分成三类。第一类是产品经理和运营他们的痛点是重复整理信息比如每周汇总各渠道反馈、生成周报、归档文档这类工作用自然语言描述给Agent就能完成。第二类是开发者WorkBuddy可以作为一个“胶水层”把公司内部各种API、数据库、脚本用一个统一的自然语言入口暴露出来省得每次都手写调用Demo。第三类是团队负责人通过搭建标准化的Skill库让同一套自动化流程被团队反复使用从“个人效率工具”升维成“团队数字助理”。但也要说清楚它的边界。WorkBuddy不适合用来做毫秒级响应的在线服务它本质是一套Agent编排系统执行链路里有模型推理、工具调用、人工审批多个环节更适合“分钟级或定时触发的任务”而不是“用户点击后必须100毫秒返回结果”的业务接口。理解这个边界后面很多使用上的困惑都会迎刃而解。2. 安装与初始化从0到1跑通第一个Agent2.1 环境准备该花的力气别省WorkBuddy的安装包对操作系统比较友好Windows、macOS、主流Linux都有对应版本安装包里一般自带运行时不需要你先配好Java或Node环境这点对新手很友好。我首次安装是在一台Windows笔记本上双核CPU、8GB内存跑小任务完全够用如果打算同时开多个Agent或者接入大文档处理建议16GB内存起步能给模型上下文留出余量。有两个环境问题值得提前说。第一老旧的Windows 7系统大概率不在支持列表里我看到社区里有用户在问Win7安装的问题我的建议是别折腾Agent平台需要依赖现代系统的进程管理和网络能力Win7的兼容性风险太高。第二如果你的电脑开启了严格的企业安全策略安装时可能触发拦截原因是WorkBuddy执行器要调用本地脚本和终端这类行为常被安全软件标记安装前先把目录加入信任区或者选择Docker方式部署服务端把执行环境隔离到容器里。另外生产环境我更推荐Linux服务器加Docker方式。用容器跑的好处是环境可销毁重建Agent乱写文件、装坏依赖都不怕重置成本极低。安装完成后默认的工作台界面会提供一个访问地址浏览器打开就能操作这点很像常见的本地工具。2.2 配置模型服务让Agent睁开眼睛装好之后最重要的一步是配置大模型服务。WorkBuddy本身不带模型推理能力它需要对接一个模型API通过“思考”来决定下一步动作。目前主流做法是配置一个兼容OpenAI接口的模型端点你在配置里填三个核心参数接口地址、API Key、模型名称。我用过一个很省心的配置方式把环境变量一次性写好之后启动工作台自动加载。示例配置大概是这样的# 基础模型配置 LLM_BASE_URLhttps://your-api-endpoint/v1 LLM_API_KEYsk-xxxxx LLM_MODELgpt-4o-mini如果你用的是本地模型比如通过Ollama启动的开源模型也可以把接口地址指到本机的11434端口只要模型支持工具调用和函数参数输出就可以。这里我强烈建议第一次调通别纠结“哪个模型最强”先用一个稳定的通用模型把整条链路跑通再根据任务类型微调。把模型换来换去只会给你排查问题增加变量。配置里还有一个“温度”或“随机性”参数建议先设置为0或接近0。Agent任务通常要求稳定输出不需要创意发散温度太高容易让模型天马行空严重的时候格式都会乱掉。调试阶段固定参数能减少很多莫名其妙的失败。2.3 首次启动用一个小任务验证链路配置完成后工作台会引导你创建第一个Agent。我的建议是从“自由任务”模式开始先用一句话让Agent做一件极其简单的事。我当初用的测试指令是“帮我读取当前目录下的文件列表按文件大小从大到小排序输出到一个名为file_summary.md的文件里”。这个任务的妙处在于它虽然简单但完整覆盖了模型的规划、文件工具调用、脚本执行和结果落盘四个环节。如果这四个环节都能跑通说明工作台安装、模型连接、工具权限都没问题。我第一次跑的时候Agent确实按步骤列出了文件生成了排序后的Markdown虽然排序逻辑有点小瑕疵但整个链路是通的那种感觉就像第一次点亮了一盏灯。跑通之后记得去看一眼运行日志。WorkBuddy会把每次模型调用、工具执行、输出结果都记录下来这是后续排查问题最重要的信息来源。如果你看到一个任务执行得“不符合预期”第一反应不应该是“这Agent真笨”而是打开日志看它在哪一步跑偏了是模型理解错了还是脚本报错了。3. Agent的核心机制Skill、Tool、Harness、记忆3.1 Agent不是聊天机器人决策与执行分离很多人对Agent的理解还停留在“对话式AI”这会导致使用思路跑偏。我从工程角度拆一下Agent系统里至少有两层上层是模型推理层负责理解用户意图、拆解步骤、决定调用哪个工具下层是执行层负责真正运行代码、访问网络、读写文件。WorkBuddy的Agent把这两层粘合起来既有“大脑”又有“手脚”。这种分层带来一个直接好处模型可以换执行器不用动。你昨天用聊天模型跑通的Skill今天换成推理能力更强的模型脚本和工具照常用。反过来说如果模型没变只是工具脚本出了问题那也是独立排查。这和写代码时的“接口隔离”是一个思路各自升级互不阻塞。用的时候也要有这个意识Agent说错了不一定是模型笨也可能是你给它的描述不清楚或者工具返回的数据格式和非预期。学会把问题定位到具体层排查效率会高非常多。3.2 Skill给Agent的“工作说明书”加“工具箱”WorkBuddy里最重要的概念是Skill。一个Skill就是把某一类任务的完成方法封装成包里面通常有一份描述文件说明“这个技能是干什么的、适合什么场景”以及一个或几个执行脚本。Agent拿到任务后会在大模型的辅助下判断“这个任务可以调用哪个Skill”然后加载Skill进入执行流程。我对Skill的理解它在本质上是“工作说明书SOP加工具箱”。想象一下你带实习生你不会告诉他“随便干”而是给一份步骤文档告诉他第几步干什么、用什么工具、输出什么格式。Skill就是给Agent的这份材料。定义清晰、边界明确的Skill能让Agent的执行稳定性直线上升。具体到实践一个完善的Skill通常包含以下要素名称和用途描述、输入参数的说明、执行步骤、依赖的工具或脚本、输出格式约定。尽量把输出格式定死比如“输出JSON”“输出Markdown表格”这样后续步骤处理起来会非常顺畅。我在实操中吃过亏前面几步都是自由文本输出到汇总步骤时解析全靠猜最后产物乱七八糟后来强制每个步骤输出结构化格式问题立刻缓解。3.3 Harness与Agent的分工别把两个概念搅在一起搜索热词里“harness和agent区别”能排这么靠前说明不少人在这一步卡住了。我用自己的话解释Harness是Agent运行的“外部支撑系统”负责生命周期管理、日志收集、错误重试、资源限制、权限管控Agent本身是“决策和执行单元”负责思考任务该怎么完成。没有HarnessAgent只是裸奔的模型加脚本有了HarnessAgent才变成可控、可观测、可审计的服务。用做饭类比Agent是大厨Harness是厨房。大厨负责想菜谱、动刀、下锅厨房负责水电、排烟、消防、洗碗。好的厨房能让大厨专注炒菜坏的厨房会让大厨一边炒菜一边担心着火了怎么办。WorkBuddy作为工作台本身就是一套精心设计的Harness你在里面定义Agent时实际上是在搭“厨房配置”。理解Harness以后很多概念就不再神秘。比如“并发”问题本质是Harness的资源调度能力比如“安全”问题本质是Harness的权限闸门。当你觉得Agent运行不稳很多时候不是模型不行而是Harness层面的策略没配好比如并发太高触发限流、重试次数不够、超时设置太短。3.4 记忆、上下文与并发那些容易误读的术语Agent社区里有几个高频词用不好容易翻车。先说记忆Agent有短期记忆和长期记忆之分。短期记忆就是一个会话里保留的对话上下文和中间结果WorkBuddy通过会话窗口维护它。长期记忆则需要自己规划比如把重要的结论写入文件或数据库下次任务开始时再次加载。别指望Agent自带“无限记忆”那是在为难模型和你的显存。再说上下文超限这是实际使用中最常见的拦路虎。每次任务塞给模型的文本太多会触发长度上限。解决思路是“摘要压缩”和“分段处理”长文档先切片分批让模型抽取关键信息最后汇总历史对话超过阈值时让模型生成一段摘要替换旧消息而不是继续往上堆。我在处理一本几十页的PDF时就是把每个章节单独过一遍再汇总成整书摘要效果远好于一次性全塞进去。最后是并发很多人问“AI Agent怎么扛并发”。我的回答比较现实不要试图让Agent本身承受巨大并发。模型调用是慢操作单次推理可能要几秒到几十秒并发太高只会带来超时和费用激增。正确姿势是通过队列把任务串行化或有限并发化每个任务独立运行失败就重试。需要给外部系统提供高并发接口时前置一个HTTP服务做请求接收和任务排队Agent在后台慢慢执行完再回调通知结果。4. 从0到1实操构建一个“周报整理Agent”4.1 需求拆解先想清楚输入和输出理论说再多不如动手做一个。我做的是“周报整理Agent”适用场景是这样的团队里的人习惯在群里甩流水账比如“周一改Bug周二开会对需求周三做了个原型”到了周末要交周报时每个人都得把这些碎片整理成规范的“本周完成、下周计划、风险求助”三段式。这个过程重复、低价值完全适合交给Agent。需求拆解其实很简单。输入是一段或多段不固定的原始文字输出是一份结构化的Markdown周报并且自动保存到指定目录。为了让流程更完整还可以加一步把周报内容发送到一个Webhook地址模拟“提交到内部系统”的动作。这个任务不涉及复杂的外部系统正好用来验证Agent工作台的基本功。拆解时最需要注意的是边界。一开始别贪心不要试图让Agent自动登录公司OA、自动发邮件。先让它在本地把文本整理成文件跑通以后再加集成步骤。这样即使后面的Webhook步骤失败你也能拿到一份能用的周报产物不至于整个流程一起崩掉。4.2 创建Skill定义把步骤写清楚创建Skill时我倾向于把定义文件写成“给模型看的菜谱”。典型结构包括Skill名称、描述、支持的触发例句、参数定义、处理步骤。不同版本的WorkBuddy在字段命名上可能略有差异但核心思想一致。下面是我项目中使用的配置示例结构上可以作为通用模板参考name: weekly_report_builder description: 将零散的工作记录整理为结构化周报 supports: - 周报 - weekly report parameters: input: type: string description: 零散的原始工作记录 steps: - name: summarize_weekly tool: model prompt: | 你是周报整理助理。请把用户提供的零散工作记录整理为三个部分 1. 本周完成 2. 下周计划 3. 风险与需要帮助 如果原文没有相关信息对应部分写“暂无”。 输出格式为纯Markdown不要输出额外说明。 - name: save_report tool: script script: scripts/write_report.py input: result这里面最关键的是第一个步骤的提示词。我发现很多人写Skill时提示词过于笼统比如“帮我整理周报”模型不知道要分成几部分、用什么格式、没有信息时怎么办。把输出要求写死能省下大量返工。我特意加了“没有相关信息写暂无”这一条就是为了让模型遇到信息缺失时不要自行脑补。第二个步骤调用Python脚本把模型的输出保存成文件。这里体现的是“模型负责生成内容脚本负责落地执行”职责分离。模型不直接操作文件系统避免了大模型乱改文件的风险所有写操作都收敛到受控脚本里。4.3 编写执行脚本让产物安全落地保存报告这一步用Python脚本实现逻辑非常简单接收上一步传入的内容生成带日期的文件名写入报告目录再模拟调用一次Webhook。脚本写得越简单越好它的核心价值是“可控地执行文件写入”而不是承担复杂的业务逻辑。import json import datetime import urllib.request def main(payload): content payload.get(content, ) date_str datetime.date.today().isoformat() path freports/weekly_{date_str}.md with open(path, w, encodingutf-8) as f: f.write(content) # 模拟发送到内部系统的Webhook # webhook_url https://your-internal-system.example/webhook # req urllib.request.Request( # webhook_url, # datajson.dumps({content: content}).encode(utf-8), # headers{Content-Type: application/json}, # ) # urllib.request.urlopen(req, timeout5) return {saved: path, preview: content[:80]}写脚本时有几个细节值得注意。第一路径尽量不要写死用相对路径会让Skill的复用性更强第二Webhook调用要加超时时间否则远程接口卡住会拖死整个Agent执行链第三脚本要返回一个简短的结果摘要方便在日志里确认执行状态。在真实项目中我不会把Webhook地址明文写在脚本里而是通过环境变量传入。Agent的脚本必然会涉及访问密钥、内部地址这类敏感信息把它们散落在代码里后期审计就是个灾难。环境变量统一管理既方便不同环境切换也降低泄露风险。4.4 在工作台挂载并测试Skill定义文件和脚本都准备好以后把它放到WorkBuddy的Skill目录里然后在工作台刷新新建一个Agent并关联这个Skill。WorkBuddy的界面逻辑是“Agent绑定Skill”一个Agent可以加载多个Skill执行时由模型判断该用哪个。测试输入我随手写了一段模拟数据“周一处理了两个用户投诉跟产品反馈了问题周二给客户做了产品演示反馈不错周三开始做新功能原型目前完成一半周四和法务过了一遍合同初稿还有几个条款要确认周五请假半天。下周需要把原型做完并内部评审可能需要前端同学支持。”Agent跑完之后生成的Markdown大概是这样的结构本周完成部分列出了投诉处理、产品演示、原型开发、合同确认四条下周计划写了原型收尾和内部评审风险部分准确识别出“需要前端同学支持”和“合同条款待确认”这两项。整体判断是符合预期的模型把零散流水账归纳得很干净脚本也成功把文件写入了reports目录。测试时要抱着“发现问题很正常”的心态。我第一次跑的时候模型把“请假半天”也写进了本周完成后来我在提示词里加了一句“只统计实际工作事项请假、开会等事务性记录不需要单独列出”再次运行就正常了。这就是迭代式调优的过程别指望一次成功。4.5 复盘与扩展方向从跑通到跑顺周报Agent跑通以后我顺手做了几个扩展这里分享给想继续深入的人。第一把“保存结果”和“发送通知”分开处理即使Webhook失败周报文件也已经生成任务不算完全浪费。第二把Skill的输入参数设计成支持文件路径这样Agent可以直接读取一个txt文件里的原始记录而不是只能在对话框里粘贴文本。第三给输出目录加一个按周归档的逻辑自动创建以年份和周数命名的子目录时间久了文件也好管理。本质上Agent的演化路径就是不断把“不稳定的人为操作”变成“稳定的脚本逻辑”。一次成功的Skill开发不只是让某个任务自动化更是沉淀出一套“遇到这类任务该怎么处理”的模板。下次遇到类似需求直接复制一份改改参数就行不需要从头设计。5. 常见问题与排查技巧实录5.1 模型连不上找到是哪一层的锅Agent任务执行到一半突然报错最常见的就是模型服务失联。现象是日志里出现连接超时、HTTP 401或429状态码。排查思路按顺序来先确认网络能不能访问模型接口再确认API Key是否有效最后看是否触发了频控或余额不足。我曾经遇到过一个问题本地网络正常但模型接口需要走内网代理WorkBuddy里没配置代理导致请求一直超时加上代理配置后立刻恢复。重试策略也很重要。模型接口偶尔抖动是常态一次性失败就放弃的任务太脆弱。比较稳妥的方案是设置2到3次重试重试间隔用指数退避比如第一次等1秒第二次等2秒第三次等4秒。高频重试反而会加剧服务端压力把问题从“临时抖动”变成“持续雪崩”。5.2 Agent输出格式混乱让它先给JSON再转文档做Agent最头疼的问题之一就是模型随机发挥导致输出格式不稳定。比如你让它输出Markdown表格它有时给你一段散文你让它输出JSON它偶尔多包一层注释。我的解决办法是“中间态用JSON最终态再转文档”。具体做法是第一步让模型严格输出一个JSON对象字段固定并在提示词里给出示例第二步用脚本解析JSON并生成最终的可读文档。这样即使模型在第一步稍有瑕疵你也能通过脚本做修正而不是面对一堆乱七八糟的文本干瞪眼。关键是在提示词里写明“只输出JSON不要多余解释”必要时在脚本里做二次清洗比如去掉被错误包裹的代码块标记。5.3 上下文过长学会做减法处理长文档时Agent经常遇到“越到后面越笨”的情况本质上是上下文窗口被塞满模型注意力被稀释。有几个实用手段。第一分段处理把长文档切成小段逐段让模型抽取关键信息或生成摘要最后汇总第二滑动窗口在一个长对话里超过一定轮次就把旧内容总结成一段摘要替换掉原始消息第三按需加载不要把所有资料一次性交给Agent让它先检索再确定需要看哪些内容。WorkBuddy的会话机制通常支持窗口配置找到相关参数把历史摘要开关打开。如果任务真的需要读取整本图书级别的材料我会先把书转成若干章节文本再给Agent一份“章节目录索引”让它只加载当前需要的章节。这和读书时先看目录再翻正文是一个道理。5.4 磁盘缓存与权限小事也能翻车有几个实际的小坑值得记录。一是缓存目录的默认位置可能在系统盘跑多了会占掉好几个G的空间。可以在配置里把缓存目录改到数据盘或专门建的目录避免把系统盘塞满。如果你用的是Windows路径里有中文或空格也可能引发微妙的问题尽量统一用英文路径。二是权限问题。WorkBuddy的Agent执行本地脚本时权限边界由启动用户的身份决定。如果Agent脚本需要写系统目录而工作台以普通用户身份运行就可能写入失败。反过来如果你为了省事直接用管理员启动Agent一旦被提示词注入恶意指令后果会更严重。正确的做法是保持普通用户身份只给Agent需要操作的特定目录写权限。5.5 常见问题速查表现象可能原因快速处理建议请求模型超时网络策略、接口地址错误检查网络连通性确认接口地址和路径返回401或403API Key无效或过期更新密钥检查是否有多套环境变量覆盖返回429触发频控或额度不足增加重试退避降低并发数任务执行到一半中断JSON解析失败、脚本异常打开日志定位是哪一步修复对应环节输出内容答非所问上下文过长、提示词太模糊精简上下文细化提示词并给示例文件写入失败目录权限不足、路径不存在检查工作目录权限用绝对路径创建目录磁盘空间暴涨缓存和历史文件累积修改缓存目录定期清理旧会话数据这个表是我日常排障的浓缩版遇到问题先按行对照能省下很多瞎猜的时间。排查的前提是日志完整所以从一开始就要养成看日志的习惯不要只盯着最终结果。6. 关于Agent安全与工程化的几条硬经验6.1 权限边界像给实习生权限一样对待AgentAgent安全是我最想强调的事。一个能执行脚本、能访问网络、能调API的Agent本质上就是一个“自动运行的代码”。你给它多少权限它就可能造成多大影响。我的原则很简单像带第一周实习生一样只给它完成任务所需的最小权限。具体来说不要让Agent以管理员身份运行不要给它“万能终端”式的工具不要让它无限制访问公网。对涉及删除、覆盖、转账、发布等不可逆的操作一定要加上“人工审批”环节。WorkBuddy这类工作台一般支持审批机制执行到高风险步骤时暂停由人在界面上确认后继续。我见过一个活生生的教训有人给Agent配了一个能执行任意shell命令的Skill结果模型被一段恶意文本引导在服务器上执行了递归删除命令。这个Agent本身没有恶意但它太“热心”完全照做了模型被诱导后输出的指令。事后排查时唯一庆幸的是权限有限没有波及系统核心目录。这个教训让我此后把“最小权限”当作铁律。6.2 可观测性不给Agent上“黑盒”Agent运行过程中每一步干了什么、调用了哪个工具、传入了什么参数、输出了什么结果都应该有日志记录。这不只是排查故障的刚需更是安全审计的前提。当你把一个Agent交给团队使用时别人有权知道这个Agent做了什么。没有日志的Agent就像一个没有监控的自动化流水线出了事都不知道从哪里查起。在实践里我会把日志重点记录几个字段时间戳、任务ID、步骤名称、触发的工具、输入摘要、输出摘要、耗时。敏感信息要做好脱敏比如API密钥、个人手机号、邮箱在日志里用掩码显示。工作台自带的运行日志通常满足基本需求但如果你把Agent接入生产流程建议把关键节点日志同步到统一日志平台做长期留存。6.3 工程化路径先小步快跑再全量铺开Agent开发很容易犯一个错误就是一开始就规划宏大的流程试图一步到位自动化所有环节。我的建议是倒过来先挑一个最高频、最少依赖的小任务做成Skill跑通、跑稳再加关联步骤。这样每一轮迭代的复杂度都可控出问题也好定位。踩过几次坑之后我现在的节奏是第一轮做一个单步任务验证模型连接和基础工具第二轮加一个脚本执行验证产物落地第三轮再加外部API或Webhook验证跨系统集成等这些都稳定了才考虑定时触发或多Agent编排。每一步都单独验证不追求一次成型。这个节奏看起来慢但总时间反而要短因为每一步的返工概率大大降低了。7. 最后再分享一点点实操体会WorkBuddy的价值我是在亲手做完三个Skill之后才真正体会到的。第一个Skill是周报整理第二个是批量抓取网页标题生成摘要第三个是自动归档下载目录里的文件。做完这三个以后我突然意识到Agent和普通AI助手的本质区别普通AI给你建议Agent替你把事情办了。那种“上班摸鱼Agent在写文档”的感觉确实让人上瘾。在WorkBuddy上花的时间越多我越觉得核心护城河不是模型而是Skill库的积累。同一个模型配上不同的Skill能干的活天差地别。我建议所有刚上手的朋友不要沉迷于换模型、调参数把精力放在“把一类任务彻底想清楚并封装成Skill”上。一个高质量的Skill比十个泛泛而谈的prompt模板都有用。如果你也正在用WorkBuddy做自动化我的建议是从今天手头的重复劳动里挑一个最让你烦躁的任务把它写成一个Skill。完成那一刻你会明白的Agent不是未来它是现在的工具箱就看你愿不愿意弯下腰去拿。