1. 从“助手”到“系统”WorkBuddy 到底在解决什么问题第一次看到 WorkBuddy 这个定位我脑子里冒出来的第一个念头是又一个套壳助手但把它的能力边界和工程化路径拆开看之后我发现它想做的事情和市面上大多数“对话式助手”根本不在一个层面上。它要做的不是帮你写一段文案、查一个接口而是把 Agent 当成一个可被调度、可被编排、可被复用的“操作系统级”存在。这个跃迁才是它真正值得聊的地方。先说清楚它是什么。WorkBuddy 本质上是一个面向 Agent 的运行时与工作台你可以把它理解成一台“给智能体用的电脑”上面有任务调度、有技能注册、有上下文管理、有权限隔离、有执行沙箱。你写好的 Agent 不是一段孤立的提示词而是被注册进这个系统里的一个“进程”它可以被其他 Agent 调用也可以调用别人。这个思路和传统“AI 助手”最大的区别在于助手是单次交互的而 WorkBuddy 是持续运行、可组合、可观测的。它能做什么举几个我实际跑过的场景。第一个是自动化工作流我让一个 Agent 负责读取需求文档另一个 Agent 负责拆解成任务清单第三个 Agent 负责把任务分派给对应的执行技能整个过程不需要我手动复制粘贴。第二个是技能复用我把“生成周报”这个能力封装成一个 skill注册进 WorkBuddy之后任何 Agent 都能直接调用它不用重复写提示词。第三个是跨会话记忆WorkBuddy 会把上下文持久化Agent 在第二天继续处理同一个项目时不需要我重新交代背景。它解决的核心问题其实是 Agent 开发里最痛的那几个点上下文丢失、技能无法复用、执行过程不可观测、多 Agent 协作没有统一调度。传统做法是每个 Agent 单独写一套逻辑互相之间靠人工传话一旦任务链变长整个系统就变成一团乱麻。WorkBuddy 的思路是把这些公共能力下沉到“操作系统层”让 Agent 只关注自己的业务逻辑。适合谁看如果你只是想让 AI 帮你写写邮件那 WorkBuddy 对你来说可能太重了。但如果你正在做 Agent 开发、想搭建多智能体协作系统、或者被“Agent 执行到一半报错就断了”这种问题折磨过那这套东西值得你花时间研究。前端工程化背景的同学会更容易上手因为它的很多设计思路和前端模块化、依赖注入、运行时沙箱是相通的。提示WorkBuddy 和 CodeBuddy 经常被放在一起讨论但两者定位不同。CodeBuddy 更偏向编码场景的辅助WorkBuddy 更偏向 Agent 的运行时与编排。别把两者混为一谈选型时先想清楚你要的是“写代码更快”还是“让 Agent 跑得更稳”。2. 核心设计思路拆解为什么是“操作系统”而不是“框架”2.1 框架和操作系统的本质区别很多人第一次接触 WorkBuddy 会问这不就是一个 Agent 框架吗和 LangChain、AutoGPT 那些有什么区别这个问题问得好因为答案决定了你对它的理解深度。框架的本质是“库”你引入它然后按它的约定写代码最终产物是一个你自己的应用。操作系统的本质是“运行时”你的 Agent 跑在它上面它负责资源分配、任务调度、权限控制、生命周期管理。区别在于框架是你代码的一部分操作系统是你代码的运行环境。这个区别在实际使用中非常明显。用框架的时候你的 Agent 逻辑和框架代码是耦合的升级框架版本可能要把你的代码改一遍。用 WorkBuddy 的时候你的 Agent 是一个独立的“应用”注册进系统就能跑系统升级不影响你的业务逻辑。这就是为什么它敢叫自己“Agent 操作系统”——它把 Agent 当成了可插拔的进程而不是代码里的一个函数。2.2 技能注册机制为什么不用传统的函数调用WorkBuddy 里有一个核心概念叫 skill你可以把它理解成“Agent 可以调用的能力单元”。传统做法是直接在代码里写函数调用但 WorkBuddy 要求你把能力注册成 skill然后通过系统来调用。这个设计乍看有点绕但背后的逻辑很扎实。第一解耦。你的 Agent 不需要知道某个能力具体是怎么实现的它只需要知道“有一个叫 generate_weekly_report 的 skill 可以用”。实现这个 skill 的代码可以随时替换Agent 不用改。第二权限控制。不是所有 Agent 都能调用所有 skill。WorkBuddy 在系统层做了权限隔离你可以规定某个 Agent 只能调用只读类 skill不能调用写入类 skill。这在多 Agent 协作场景里非常关键避免了一个 Agent 误操作把整个流程搞崩。第三可观测。每次 skill 调用都会被记录包括入参、出参、耗时、是否成功。出了问题你可以直接查调用链而不是在一堆日志里翻。第四复用。同一个 skill 可以被多个 Agent 调用不用重复实现。我见过太多项目同一个“发送通知”的功能在五个 Agent 里各写了一遍改的时候要改五个地方。WorkBuddy 的 skill 机制直接把这个坑填了。2.3 上下文管理Agent 的“记忆”到底该怎么存Agent 开发里最容易被低估的就是上下文管理。很多人以为把对话历史塞进 prompt 就行了但实际跑起来会发现token 爆炸、关键信息被淹没、跨会话丢失。WorkBuddy 在这块的设计思路是“分层存储 按需注入”。分层的意思是上下文不是一坨而是分成几层会话级上下文当前对话的短期记忆、任务级上下文当前任务相关的信息、项目级上下文跨会话的长期记忆。每层有不同的生命周期和存储策略。按需注入的意思是Agent 在执行某个步骤时系统只把相关的上下文注入进去而不是把所有历史都塞进去。这个设计的好处是显而易见的。我实测过一个场景一个 Agent 需要处理一个持续两周的项目如果每次调用都把两周的对话历史塞进去token 消耗会非常夸张而且模型很容易被无关信息干扰。用 WorkBuddy 的分层上下文之后每次只注入当前任务相关的信息token 消耗降了大概六成输出质量反而更稳定。2.4 执行沙箱为什么 Agent 不能直接跑在宿主机上WorkBuddy 的另一个关键设计是执行沙箱。Agent 执行代码、调用工具、访问文件都不是直接在宿主机上跑的而是在一个隔离环境里。这个设计在 demo 阶段可能感觉不到价值但一旦进入工程化落地它就是保命的东西。我踩过的坑早期做 Agent 项目时直接让 Agent 在宿主机上执行 shell 命令结果有一次 Agent 误判了任务执行了一个删除操作把测试环境的数据清了一大片。从那以后我就明白了Agent 的执行必须隔离。WorkBuddy 的沙箱机制把文件系统、网络、进程都做了隔离Agent 在里面怎么折腾都不会影响宿主机。注意沙箱不是万能的它解决的是“误操作”问题不解决“恶意操作”问题。如果你的 Agent 会处理不可信输入还需要在沙箱之上加一层输入校验和权限控制。3. 工程化落地的关键环节与实操要点3.1 环境准备与安装别在第一步就卡住WorkBuddy 的安装本身不复杂但有几个细节容易卡人。我按实际操作的顺序说一遍。第一步是确认运行环境。WorkBuddy 支持 Linux 和 macOSWindows 用户建议用 WSL2。如果你用的是麒麟操作系统或者统信 UOS 这类国产系统需要额外确认依赖库的版本尤其是 glibc 的版本。我遇到过在麒麟系统上安装时提示“客户机操作系统已禁用 CPU”的情况那是虚拟机配置问题不是 WorkBuddy 本身的问题把虚拟机的 CPU 虚拟化选项打开就行。第二步是安装运行时。WorkBuddy 的核心运行时是一个常驻进程安装命令大概是这样的# 添加软件源 curl -fsSL https://workbuddy.example.com/install.sh | bash # 安装核心运行时 workbuddy install runtime # 验证安装 workbuddy --version第三步是初始化工作区。WorkBuddy 需要一个工作目录来存放 Agent 定义、skill 注册信息、上下文数据。初始化命令会创建这个目录结构workbuddy init my-workspace cd my-workspace初始化完成后你会看到几个关键目录agents/存放 Agent 定义skills/存放 skill 实现contexts/存放上下文数据logs/存放执行日志。这个结构建议不要随意改动因为 WorkBuddy 的运行时是按这个约定来加载资源的。提示如果你之前用过 CodeBuddy注意两者的配置目录不要混用。我见过有人把 CodeBuddy 的配置直接拷到 WorkBuddy 里结果运行时加载了一堆不兼容的 skill排查了半天。3.2 Agent 定义从“写提示词”到“写配置”WorkBuddy 里定义一个 Agent不是写一段提示词就完事而是写一份结构化的配置。这份配置描述了 Agent 的身份、能力、权限、上下文策略。我拿一个实际用过的例子来说明# agents/weekly-report-agent.yaml name: weekly-report-agent description: 负责生成周报的 Agent model: default skills: - read_project_data - generate_summary - format_markdown permissions: - read:project_data - write:reports context: layers: - session - task max_tokens: 8000这份配置里skills列出了这个 Agent 可以调用的能力permissions定义了它的权限边界context定义了它的上下文策略。运行时加载这份配置后会为这个 Agent 创建一个独立的执行环境。这个设计的好处是Agent 的行为是可审计的。你不需要去读它的提示词猜它可能做什么直接看配置就知道它的能力边界。这在团队协作场景里特别重要新人接手时看一眼配置就能理解这个 Agent 是干什么的。3.3 Skill 实现把能力封装成可复用的单元Skill 是 WorkBuddy 里最核心的复用单元。一个 skill 本质上是一个函数有明确的输入输出定义注册进系统后可以被任何有权限的 Agent 调用。我拿“生成周报”这个 skill 举例# skills/generate_summary.py from workbuddy.skill import skill skill( namegenerate_summary, description根据项目数据生成周报摘要, inputs{project_data: dict}, outputs{summary: str} ) def generate_summary(project_data: dict) - dict: # 实际实现逻辑 summary process_data(project_data) return {summary: summary}这个 skill 注册之后任何 Agent 都可以通过generate_summary这个名字来调用它不需要知道它的实现细节。如果哪天你想换一个实现方式只需要改这个文件所有调用方都不用动。我实测下来的经验是skill 的粒度要控制好。太粗了复用性差太细了调用链太长。我的建议是一个 skill 对应一个完整的业务动作比如“读取项目数据”“生成摘要”“格式化输出”各是一个 skill而不是把整个周报生成做成一个 skill。这样组合起来更灵活。3.4 多 Agent 协作调度器怎么配WorkBuddy 支持多 Agent 协作核心是调度器。调度器负责决定哪个 Agent 在什么时候执行、执行结果传给谁。配置调度器的方式有两种一种是声明式的用 YAML 描述流程另一种是编程式的用代码控制流程。声明式的方式适合流程固定的场景# workflows/report-workflow.yaml name: weekly-report-workflow steps: - agent:>from workbuddy.workflow import Workflow wf Workflow() data wf.run(data-reader) if data.needs_deep_analysis: summary wf.run(deep-analyzer, inputdata) else: summary wf.run(summary-generator, inputdata) report wf.run(formatter, inputsummary)两种方式可以混用。我的经验是主流程用声明式分支逻辑用编程式这样既清晰又灵活。注意多 Agent 协作时最容易出问题的地方是数据格式不一致。Agent A 输出的 JSON 结构Agent B 可能解析不了。建议在 skill 定义里严格声明输入输出的 schemaWorkBuddy 会在调用时做校验提前发现问题。4. 实操过程与核心环节实现4.1 从零搭建一个多 Agent 工作流我拿一个实际跑过的项目来演示自动生成项目周报。这个工作流涉及三个 Agent数据读取 Agent、摘要生成 Agent、格式化 Agent。第一步创建 Agent 定义。在agents/目录下创建三个 YAML 文件分别定义三个 Agent 的身份、技能和权限。数据读取 Agent 只需要read_project_data这个 skill权限是只读。摘要生成 Agent 需要generate_summary这个 skill权限是只读。格式化 Agent 需要format_markdown这个 skill权限是只读。第二步实现 skill。在skills/目录下创建对应的 Python 文件。read_project_data负责从数据源读取项目数据generate_summary负责调用模型生成摘要format_markdown负责把摘要格式化成 Markdown。第三步定义工作流。在workflows/目录下创建 YAML 文件描述三个 Agent 的执行顺序和数据传递关系。第四步运行工作流。执行命令workbuddy run weekly-report-workflow运行过程中WorkBuddy 会依次调度三个 Agent每个 Agent 执行完后把输出传给下一个。你可以在终端看到实时的执行日志包括每个 Agent 的输入输出、耗时、是否成功。第五步查看结果。执行完成后最终报告会输出到指定的目录。同时logs/目录下会有完整的执行记录包括每个 skill 的调用详情。这个流程跑通之后我实测的耗时大概是两分钟左右其中模型调用占了大头。如果数据量不大可以做到一分钟以内。4.2 参数选择与性能调优WorkBuddy 有几个关键参数会直接影响性能我逐个说明。上下文窗口大小这个参数决定了每次注入给模型的上下文上限。设得太小模型可能缺少必要信息设得太大token 消耗高且容易被干扰。我的经验值是 8000 到 12000 token具体取决于任务复杂度。对于周报生成这种任务8000 足够了。并发数WorkBuddy 支持多个 Agent 并发执行。如果你的工作流里有多个独立的任务可以调大并发数来提速。但要注意并发数受限于模型 API 的速率限制和沙箱的资源配额。我一般设成 3 到 5再高就容易触发限流。超时时间每个 skill 调用都有超时设置。默认是 30 秒对于模型调用来说可能不够。我一般设成 120 秒给模型足够的生成时间。但也不能设太长否则一个卡住的调用会拖垮整个工作流。重试策略WorkBuddy 支持自动重试。对于模型调用这种可能因为网络波动失败的场景建议开启重试重试次数设成 2 到 3 次重试间隔用指数退避。这些参数没有万能值需要根据你的实际场景调。我的建议是先用默认值跑通然后根据日志里的耗时和失败率逐步调整。4.3 上下文持久化与跨会话恢复WorkBuddy 的上下文持久化是我最喜欢的功能之一。它把上下文存在contexts/目录下按 Agent 和会话分开存储。这意味着即使你重启了 WorkBuddy 运行时Agent 下次执行时仍然能读到之前的上下文。这个功能在实际使用中非常有用。比如你有一个 Agent 负责跟踪一个长期项目它需要记住上周的进展。传统做法是你每次都要把上周的信息重新喂给它但 WorkBuddy 会自动从持久化存储里加载。配置上下文持久化的方式很简单在 Agent 定义里指定context.layers包含project层即可。WorkBuddy 会自动把项目级上下文持久化到磁盘并在下次执行时加载。提示上下文持久化会占用磁盘空间建议定期清理过期的上下文。WorkBuddy 提供了清理命令可以按时间或按 Agent 清理。4.4 执行日志与可观测性WorkBuddy 的日志系统是我见过比较完善的。每次 Agent 执行、每次 skill 调用、每次模型请求都会生成结构化日志。日志里包含时间戳、Agent 名称、skill 名称、输入输出摘要、耗时、状态。这些日志可以直接用workbuddy logs命令查看也可以导出成 JSON 格式做进一步分析。我一般会把日志导入到一个简单的分析脚本里统计每个 skill 的平均耗时和失败率找出性能瓶颈。可观测性这块WorkBuddy 还支持接入外部的监控系统。如果你有 Prometheus 或 Grafana可以配置 WorkBuddy 把指标推过去。不过对于大多数场景内置的日志系统已经够用了。5. 常见问题与排查技巧实录5.1 Agent 执行中断从报错信息定位问题“Agent execution terminated due to error”是 WorkBuddy 里最常见的报错之一。这个报错本身信息量不大但结合日志就能定位到具体原因。我整理了一个排查表报错关键词可能原因排查方法timeoutskill 执行超时检查 skill 实现是否有阻塞操作调大超时时间permission denied权限不足检查 Agent 定义的 permissions 是否包含所需权限skill not foundskill 未注册检查 skills 目录下是否有对应文件是否注册成功context overflow上下文超限检查上下文窗口设置减少注入的上下文量model rate limit模型限流降低并发数或增加重试间隔我遇到最多的是 timeout 和 permission denied。timeout 通常是因为 skill 里有网络请求或者模型调用耗时超过了默认的 30 秒。解决办法是把超时时间调大或者把耗时操作拆成多个 skill 异步执行。permission denied 通常是因为 Agent 定义里漏了某个权限加上就行。5.2 Skill 注册失败路径和依赖的坑Skill 注册失败的原因通常有两个路径不对或者依赖缺失。WorkBuddy 加载 skill 时会扫描skills/目录下的所有 Python 文件并尝试导入。如果文件里有语法错误或者依赖的库没安装就会注册失败。排查方法是先手动导入一下 skill 文件看看有没有报错python -c from skills.generate_summary import generate_summary如果报 ImportError说明依赖缺失装一下就行。如果报 SyntaxError说明代码有问题改一下。如果都没报错但 WorkBuddy 还是说 skill not found那可能是文件命名或目录结构不符合约定检查一下文件名是否和 skill 名称一致。5.3 多 Agent 协作时的数据格式问题多 Agent 协作时最常见的问题是数据格式不一致。Agent A 输出的 JSON 里字段叫project_nameAgent B 期望的字段叫projectName结果 B 解析失败。解决办法是在 skill 定义里严格声明输入输出的 schemaWorkBuddy 会在调用时做校验。如果格式不对会在调用前就报错而不是等到 Agent 执行时才失败。这样排查起来容易得多。另外建议在 Agent 之间传递数据时统一用 JSON 格式并且字段命名保持一致。如果实在无法统一可以在中间加一个转换 skill专门做格式适配。5.4 性能瓶颈从日志里找答案WorkBuddy 跑得慢通常是因为某个 skill 耗时太长或者模型调用太频繁。排查方法是看日志里的耗时统计找出最耗时的 skill。我遇到过一个案例一个工作流跑一次要五分钟看日志发现 80% 的时间花在一个“读取数据”的 skill 上。原因是这个 skill 每次都要从远程 API 拉全量数据而实际上只需要增量数据。改成增量读取后耗时降到了 30 秒。另一个常见瓶颈是模型调用。如果工作流里有多个 Agent 都调用模型可以考虑合并一些调用或者用更小的模型处理简单任务。WorkBuddy 支持为不同的 Agent 配置不同的模型这个功能很实用。5.5 沙箱环境下的文件访问问题WorkBuddy 的沙箱默认不允许访问宿主机的文件系统。如果你的 skill 需要读写文件需要显式配置文件访问权限。配置方式是在 Agent 定义里加上filesystem权限permissions: - read:project_data - write:reports - filesystem: read: [/data/project] write: [/data/reports]这个配置的意思是这个 Agent 可以读/data/project目录可以写/data/reports目录其他路径一律禁止。这样既满足了业务需求又保证了安全。我踩过的坑是配置了文件权限但路径写错了结果 Agent 一直报“文件不存在”。排查了半天才发现是路径拼写问题。建议配置权限时用绝对路径并且先在宿主机上确认路径存在。6. 从工程化视角看 WorkBuddy 的生态价值6.1 为什么 2026 是 Agent 工程化的分水岭最近在 WAIC 上有一个共识2026 年是工业智能体从概念演示走向工程化落地的分水岭。这个判断我认同而且 WorkBuddy 这类产品的出现本身就是这个趋势的佐证。概念演示阶段的 Agent追求的是“能跑通”一个 demo 能完成一个任务就算成功。但工程化落地阶段追求的是“跑得稳、跑得久、跑得可观测”。这需要一整套基础设施运行时、调度器、沙箱、日志、权限控制。WorkBuddy 把这些基础设施打包成了一个“操作系统”让 Agent 开发者不用从零造轮子。这个转变的意义在于Agent 开发的门槛降低了但天花板提高了。以前一个人写一个 Agent 可能只能做一个小工具现在借助 WorkBuddy 这样的平台一个人可以维护一整套 Agent 协作系统。6.2 开放平台与生态扩展WorkBuddy 的开放平台能力是它生态价值的关键。它允许第三方开发者注册自己的 skill也允许其他系统通过 API 调用 WorkBuddy 的 Agent。这意味着 WorkBuddy 不只是一个工具而是一个平台。我实测过通过 API 调用 WorkBuddy 的 Agent。流程大概是先在 WorkBuddy 里注册一个 Agent然后通过 HTTP API 触发它执行执行结果通过回调返回。这个能力让 WorkBuddy 可以嵌入到现有的业务系统里比如和淘宝开放平台、拼多多开放平台这类电商系统对接实现自动化的订单处理、客服响应等。生态扩展的另一个方向是 skill 市场。如果 WorkBuddy 能建立一个 skill 共享机制开发者可以把自己写的 skill 发布出来其他人可以直接引用那整个生态的复用效率会大幅提升。这个方向目前还在早期但潜力很大。6.3 和 CodeBuddy 的协同关系WorkBuddy 和 CodeBuddy 的关系我理解是“运行时”和“开发工具”的关系。CodeBuddy 负责帮你写代码WorkBuddy 负责让写好的 Agent 跑起来。两者可以协同你用 CodeBuddy 写 Agent 的逻辑用 WorkBuddy 部署和运行。实际使用中我一般是在 CodeBuddy 里写 skill 的实现写完直接放到 WorkBuddy 的 skills 目录下注册。调试的时候用 CodeBuddy 的调试功能跑通了再放到 WorkBuddy 里做集成测试。这个流程比纯手工写代码效率高不少。提示CodeBuddy 和 WorkBuddy 的配置不要混用两者的配置文件格式不同。建议分开目录管理避免互相干扰。6.4 学习路径建议如果你刚接触 WorkBuddy我建议按这个顺序学第一周跑通官方示例。把官方提供的示例工作流跑一遍理解 Agent、skill、workflow 这三个核心概念。第二周写一个自己的 skill。从最简单的开始比如一个“读取文件内容”的 skill注册进 WorkBuddy然后写一个 Agent 调用它。第三周搭建一个多 Agent 工作流。把两三个 Agent 串起来理解调度器的工作原理。第四周研究上下文管理和权限控制。这是 WorkBuddy 区别于普通框架的核心能力值得花时间深入。这个路径走下来大概一个月能到熟练使用的程度。如果要深入源码级别那还需要更长时间。7. 一些实操心得和避坑建议7.1 关于 Agent 粒度的经验Agent 的粒度怎么定是我被问得最多的问题。我的经验是一个 Agent 对应一个角色而不是一个任务。比如“数据分析师”是一个 Agent“生成图表”是一个 skill。这样设计的好处是 Agent 的职责清晰skill 的复用性高。如果按任务来划分 Agent比如“生成周报 Agent”“生成月报 Agent”那这两个 Agent 会有大量重复的逻辑。按角色划分的话“数据分析师”这个 Agent 既可以生成周报也可以生成月报只是调用的 skill 不同。7.2 关于上下文管理的经验上下文不是越多越好。我见过有人把所有的对话历史都塞进上下文结果模型被无关信息干扰输出质量反而下降。我的做法是只注入当前任务相关的上下文历史信息按需检索。WorkBuddy 的分层上下文机制就是为这个设计的。session 层放当前对话task 层放当前任务project 层放长期记忆。每次执行时系统只注入相关的层而不是全部。7.3 关于错误处理的经验Agent 执行失败是常态关键是怎么处理。我的做法是每个 skill 都要有明确的错误返回而不是抛异常。WorkBuddy 会根据错误返回决定是否重试以及是否继续执行后续步骤。另外建议在工作流里加一个“错误处理 Agent”专门负责处理失败的情况。比如某个 skill 失败了错误处理 Agent 可以决定是重试、跳过还是终止整个流程。这样比在每个 skill 里写错误处理逻辑要清晰得多。7.4 关于性能优化的经验性能优化的大头在模型调用。我的经验是能用小模型解决的不要用大模型。WorkBuddy 支持为不同的 Agent 配置不同的模型这个功能要充分利用。比如数据读取 Agent 可以用小模型摘要生成 Agent 用大模型。另一个优化点是缓存。如果某个 skill 的输入输出是确定的可以加缓存避免重复计算。WorkBuddy 支持 skill 级别的缓存配置开启后会自动缓存结果。7.5 关于团队协作的经验如果是团队使用 WorkBuddy建议把 Agent 定义和 skill 实现都纳入版本控制。每个 Agent 的配置变更都要走代码审查避免有人改了一个权限导致安全问题。另外建议给每个 Agent 写清楚文档说明它的职责、输入输出、依赖的 skill。WorkBuddy 的 Agent 定义本身就是一份文档但可以补充更详细的说明。这样新人接手时能快速理解。8. 后续可以扩展的方向WorkBuddy 目前的能力已经覆盖了 Agent 运行时的核心需求但还有几个方向值得关注。第一个是 skill 市场的建设。如果 WorkBuddy 能建立一个官方的 skill 仓库开发者可以发布和引用 skill那整个生态的复用效率会大幅提升。目前这个方向还在早期但已经能看到一些雏形。第二个是和外部系统的深度集成。WorkBuddy 目前支持通过 API 和外部系统对接但集成的深度还不够。比如和电商开放平台对接时如果能预置一些常用的 skill比如“查询订单”“发送通知”那开发者的工作量会小很多。第三个是多模态能力的支持。目前的 Agent 主要还是处理文本未来如果能支持图像、音频等多模态输入输出应用场景会大大扩展。第四个是边缘部署。WorkBuddy 目前主要跑在服务器上如果未来能支持边缘设备部署那在工业场景下的应用会更广泛。这些方向目前都还在演进中但可以确定的是Agent 工程化这个趋势不会变。WorkBuddy 作为这个趋势里的一个代表性产品值得持续关注。我个人在实际操作中的体会是WorkBuddy 最大的价值不在于它提供了多少功能而在于它把 Agent 开发从“手工作坊”推向了“工程化”。以前写 Agent 像是在拼乐高每个零件都要自己造现在有了 WorkBuddy很多基础零件已经现成了你可以把精力放在业务逻辑上。这个转变对于 Agent 开发这个领域来说意义重大。